Thanks for getting back to me.<div><br></div><div>I restarted my computer -- while holding my breath -- and it booted without issue.</div><div><br></div><div>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.</div>
<div><br></div><div>Thanks again for all the help...</div><div><br>Bill-<br><br><div class="gmail_quote">On Wed, Jul 18, 2012 at 9:23 PM, Carl-Daniel Hailfinger <span dir="ltr"><<a href="mailto:c-d.hailfinger.devel.2006@gmx.net" target="_blank">c-d.hailfinger.devel.2006@gmx.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bill,<br>
<br>
glad to hear you could restore by writing the backup.<br>
Analysis follows.<br>
<br>
<br>
Am 18.07.2012 01:39 schrieb William Speirs:<br>
<div class="im">> $ flashrom -w M2N_0902.ROM<br>
> flashrom v0.9.5.2-r1517 on Linux<br>
</div>> Calibrating delay loop... OK.<br>
> Found chipset "NVIDIA MCP61". Enabling flash write... OK.<br>
<div class="im">> Found Winbond flash chip "W39V040C" (512 kB, LPC) at physical address<br>
> 0xfff80000.<br>
<br>
</div>A notoriously troublesome chip. It behaves in a weird way (IMHO not<br>
really JEDEC-compliant) with the JEDEC Toggle Bit algorithm (minimum 50<br>
ms time between reads). You may be hitting that problem although we<br>
tried to add workarounds for it.<br>
<div class="im"><br>
<br>
> Reading old flash chip contents... done.<br>
> Erasing and writing flash chip... ERASE FAILED at 0x00000000!<br>
> Expected=0xff, Read=0x4f, failed byte count from 0x00000000-0x0000ffff:<br>
> 0x10000<br>
> ERASE FAILED!<br>
<br>
</div>This is actually not a failed erase, but a misdetected end-of-erase due<br>
to the JEDEC Toggle Bit weirdness. The erase succeeds eventually,<br>
roughly half a second after flashrom complains about erase failure.<br>
<div class="im"><br>
<br>
> Reading current flash chip contents... done. ERASE FAILED at 0x00010000!<br>
> Expected=0xff, Read=0xdf, failed byte count from 0x00000000-0x0007ffff:<br>
> 0x652aa<br>
> ERASE FAILED!<br>
<br>
</div>This is actually a failed erase due to a flashrom bug in the chip<br>
definition. Whole-chip erase is not supported by this chip at all, and<br>
flashrom should not attempt to use that. The successful erase of the<br>
first 0x10000 bytes is the longterm (admittedly long-term means roughly<br>
one second here) effect of the first erase attempt.<br>
<div class="im"><br>
> FAILED!<br>
> Uh oh. Erase/write failed. Checking if anything changed.<br>
> Your flash chip is in an unknown state.<br>
><br>
><br>
</div><div class="im">> I tried a flashrom -r and compared it to the backup I made and it's<br>
> different. It is also different from the ROM I tried to install.<br>
><br>
> Any thoughts?<br>
<br>
</div>Yes. Please download latest flashrom from svn, edit file jedec.c<br>
function toggle_ready_jedec_slow() and replace<br>
toggle_ready_jedec_common(flash, dst, 8 * 1000);<br>
with<br>
toggle_ready_jedec_common(flash, dst, 100 * 1000);<br>
<br>
In theory, that change should work around the hardware bug you're<br>
hitting, but to be honest I expect more weirdness to show up instead.<br>
Still, it would be very helpful if you could test that.<br>
<br>
Do you have a way to recover (i.e. another board with a LPC flash chip<br>
in a socket)? I'm asking because I want to keep the risk low, and while<br>
the test above should be harmless in itself, more tests might be<br>
necessary later.<br>
<br>
Regards,<br>
Carl-Daniel<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<a href="http://www.hailfinger.org/" target="_blank">http://www.hailfinger.org/</a><br>
<br>
</font></span></blockquote></div><br></div>