On Wed, 17 Aug 2011 09:16:05 +0200 "Frei, Thomas (GE Germany)" Thomas.Frei@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.
-
Stefan Tauner