Gigabyte GA-H77-D3H test

[Alexander Gordeev]

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? :)

[Stefan Tauner]

On Tue, 14 Aug 2012 02:51:39 +0400
Alexander Gordeev  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.