On Tue, 14 Aug 2012 02:51:39 +0400 Alexander Gordeev lasaine@lvk.cs.msu.su wrote:
Hi!
I've got the attached output after running flashrom -V. Is it ok to try to write to flash? Particularly this line concerns me:
enable_flash_ich_dc_spi: unknown ICH generation. Please report!
Anyway, Gigabyte DualBIOS should save it if write corrupts BIOS... Right? :)
Alexander joined IRC later after flashrom failed to erase. Everything turned out well, but since it is an interesting case that flashrom can't handle yet on its own i'll explain it below.
first, the failed erase: http://paste.flashrom.org/view.php?id=1323 You can ignore the "unknown ICH generation"-related stuff. This is just because that flashrom version was too old and has nothing to do with the actual problems.
As you can see in the log above it failed to erase exactly after 4kB. The reason turned out to be that the actual chip was an evil twin of the MX25L6405 that has a 4kB sector size instead of 64kB. There has been some effort in the past to fix this by trying to distinguish the chips and there exists a patch that does that http://patchwork.coreboot.org/patch/3709/ It uses the REMS2 identification method because that seems to be a way to distinguish those chips.
So i have rebased the patch so that it applies to the current code and everything should be great. This is the result: http://paste.flashrom.org/view.php?id=1331 If you paid attention you have already noticed in the first log that all but the first erase function immediately failed; and also the REMS2 command in the latter log fails. This is due to ICH SPI lockdown... so we are stuck with the opcodes programmed by the vendor... and there is just RDID no REMS2. One bold way to circumvent the problem would be to try to erase in the probing method and check how much is erased. Not a very good idea :) Apart from that i had no idea to "improve" the patch above. Anyone?
The problem of writing to that mainboard was eventually fixed by using hardware sequencing. The descriptor had the correct erase sector size of 4kB set so everything went well. Now the question is... do we dare to make hwseq the default if it is available? Is there a good reason besides reliability concerns not to?
I'll mark the board as supported in our list with an appropriate note to use hwseq. Alexander was a great user/tester (thanks again!) and is also willing to test patches in case we can come up with another method to distinguish those evil twins.