On 20.07.2008 13:55, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 20.07.2008 02:55, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
flashrom -c MX25L8005 -w g33ds3r.f7h
That's interesting. This command does write to the chip without erasing first, so the image you now have in ROM is supposed to be a mixture of the old and new BIOS.
The ichspi driver erases a block prior to writing it, as all the non-spi drivers do. The only behavior that would possibly make sense from a user perspective.
Ah yes. I forgot about the silent data corruption bug in the ICH SPI driver. It works most of the time, but there are quite a few chips listed in flashchips.c which will act weird or require a separate erase call.
In fact, my experience was the other way around. The seperate erase command does not work for most of the chips in the list on ICH7.
That's expected. I looked at spi.c and it seems that only one chip erase command has a corresponding function. The other one is missing completely. IIRC I had it once in my code, but it may have disappeared either during initial checkin or later. Basically, the chip erase function for some families of SPI chips in flashchips.c is wrong, it should be spi_chip_erase_60 instead of spi_chip_erase_c7.
What ICH did you make this experience on?
That is purely from reading the datasheets.
Besides that, the block erase code does not belong in the chipset driver, it belongs in the flash chip driver.
I guess you are right. Patches, someone?
ich_spi_erase_block should be a generic SPI routine and choose the correct block erase command per chip. JEDEC_BE_D8 is not supported by all SPI chips.
I can try to prepare patches over the next week. What do you think about changing the generic erase and write function prototypes to accept ranges and move the call to autoerase functions into the main flashrom.c function?
Regards, Carl-Daniel