Bill-

On Wed, Jul 18, 2012 at 9:23 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:

Hi Bill,

glad to hear you could restore by writing the backup.
Analysis follows.

Am 18.07.2012 01:39 schrieb William Speirs:

> $ flashrom -w M2N_0902.ROM
> flashrom v0.9.5.2-r1517 on Linux

> Calibrating delay loop... OK.
> Found chipset "NVIDIA MCP61". Enabling flash write... OK.

> Found Winbond flash chip "W39V040C" (512 kB, LPC) at physical address
> 0xfff80000.

A notoriously troublesome chip. It behaves in a weird way (IMHO not
really JEDEC-compliant) with the JEDEC Toggle Bit algorithm (minimum 50
ms time between reads). You may be hitting that problem although we
tried to add workarounds for it.

> Reading old flash chip contents... done.
> Erasing and writing flash chip... ERASE FAILED at 0x00000000!
> Expected=0xff, Read=0x4f, failed byte count from 0x00000000-0x0000ffff:
> 0x10000
> ERASE FAILED!

This is actually not a failed erase, but a misdetected end-of-erase due
to the JEDEC Toggle Bit weirdness. The erase succeeds eventually,
roughly half a second after flashrom complains about erase failure.

> Reading current flash chip contents... done. ERASE FAILED at 0x00010000!
> Expected=0xff, Read=0xdf, failed byte count from 0x00000000-0x0007ffff:
> 0x652aa
> ERASE FAILED!

This is actually a failed erase due to a flashrom bug in the chip
definition. Whole-chip erase is not supported by this chip at all, and
flashrom should not attempt to use that. The successful erase of the
first 0x10000 bytes is the longterm (admittedly long-term means roughly
one second here) effect of the first erase attempt.

> FAILED!
> Uh oh. Erase/write failed. Checking if anything changed.
> Your flash chip is in an unknown state.
>
>

> I tried a flashrom -r and compared it to the backup I made and it's
> different. It is also different from the ROM I tried to install.
>
> Any thoughts?

Yes. Please download latest flashrom from svn, edit file jedec.c
function toggle_ready_jedec_slow() and replace
toggle_ready_jedec_common(flash, dst, 8 * 1000);
with
toggle_ready_jedec_common(flash, dst, 100 * 1000);

In theory, that change should work around the hardware bug you're
hitting, but to be honest I expect more weirdness to show up instead.
Still, it would be very helpful if you could test that.

Do you have a way to recover (i.e. another board with a LPC flash chip
in a socket)? I'm asking because I want to keep the risk low, and while
the test above should be harmless in itself, more tests might be
necessary later.

Regards,
Carl-Daniel

--
http://www.hailfinger.org/