[flashrom] report for Intel QM67 | Winbond W25Q64

[Stefan Tauner]

On Wed, 17 Aug 2011 09:16:05 +0200
"Frei, Thomas (GE Germany)" <Thomas.Frei at ge.com> wrote:

> Hi Stefan,
> 
> First of all: thank you for the quick response.
> Yes I work on a prototype from GE :-)
> 
> OK - now to your questions:
> - the flashchip is connected as follows: SPI_CLK + SPI_MOSI are connected via a FET_busswitch, and SPI_MISI is connected directly to the chipset.
> - I can use FPT.EXE from intel, and it successfully reads the content of the flashchip - but only 4MB!!!
> - the file, I got from the hardware development, that should be used here, also has 4MB!!!???

moin!

very interesting. this endorses my theory somewhat that the chipset
prohibits writes outside the address ranges of the regions defined by
the FREGs completely. this is rather bad because it does not work well
with the current concept of flashrom, which basically is founded on the
idea that we can access the whole under normal circumstances - or at
least that the programmer (in your case the chipset) does not get in
our way by unexpected means.

this would be a very good use case for a layout file... if it would
work for reading :/
or a parameter that would tell flashrom to not throw away the data
read, if there is an error later... which does not exist either.

that said, writing could work quite normally with a layout file. you
would need to make the image match the size of the chip though, so
that flashrom accepts it in the first place.
i think cp image.bin test.bin ; cat image.bin >> test.bin would work.
even without a layout file this would probably write correctly... but
flashrom would scream when accessing the second half of the chip.
please see the manpage for details about the layout file option.

i will work on this in one way or another, but please don't expect it to
be committed or even working soon. i guess that you know helge wagner at
GE? he may be able to help you (in hacking something together) too.

if you test the method outlined above i would really like to hear if it
works. please note though that it may also brick your setup... dont
blame me then please :)

if you want to help us and have a method to recover bricked boards
(i.e. if you have an external programmer that works with your boards),
you could also try to play with the FREG1 values in the descriptor with
fit.exe (or fitw.exe).

that said, i just read an interesting paragraph in the ibex peak SPI
programming guide:

"Flash Space Allocation
FIT/Ftoolc allocates SPI flash space allocation for each region as follows:
1. 2. If after allocation for all regions there is still space left in flash, then the ME region
     expands to fill the remaining space.
3. If there is leftover space and the ME region is not implemented, then the BIOS
  region is expands to use the remaining space.
4. If there is leftover space and the BIOS region is not implemented, then the GbE
  region is expands to contain the remaining space."

not sure if that still applies to cougar point, but i would guess so.
in this case i am wondering if your hardware engineering team has
created the image correctly (or if they have set up the total size
incorrectly to 4MB instead of 8).

> P.S.: Bist Du etwa ein Student an der TU Wien - sprichst Du also Deutsch?

yes i am, but since this is public and some of us do not speak german,
we use english exclusively on the mailing list. you can mail me
directly though, if it is important.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner