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
Thanks for getting back to me.
I restarted my computer -- while holding my breath -- and it booted without issue.
As for testing the modification to the code, I'd rather not. I'm all for helping open source, but I cannot risk it on this computer. If I had a board and another BIOS to play around with, then I'd give it a shot.
Thanks again for all the help...
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
-
Carl-Daniel Hailfinger -
William Speirs