[coreboot] flashrom issues found??

joe at smittys.pointclark.net joe at smittys.pointclark.net
Sun Mar 9 20:20:11 CET 2008

Quoting Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>:

> On 09.03.2008 08:50, joe at smittys.pointclark.net wrote:
>> Quoting ron minnich <rminnich at gmail.com>:
>>> On Sat, Mar 8, 2008 at 11:24 PM,  <joe at smittys.pointclark.net> wrote:
>>>> Ok,
>>>>  I think I know what is going on here after looking at the uniflash
>>>>  source code. I found this comment in the Intel programming code "Do
>>>>  not program FF, erase will result in all FF's so it's not necessary.
>>>>  Besides, 2*FF means reset ..."
>>>>  So, I removed this function from jedec.c and rebuilt flashrom.
>>>>  // dumb check if erase was successful.
>>>>  for (i = 0; i < total_size; i++) {
>>>>         if (bios[i] != (uint8_t) 0xff) {
>>>>                 printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]);
>>>>                 return -1;
>>>>         }
>>>>  }
>>>>  It seems to work fine now. Is this a bug for Intel ICH series???
>>> if it is we should not modify jedec.c -- that seems to work many
>>> places. Rather, we need to make a special function -- ich only -- and
>>> use that on ich.
>> Maybe we can add an ich.c to flashrom then??
> What are you trying to do? The code you quoted does not write to the
> chip at all.
If you look at jedec.c at the bottom you would see what I mean. It is  
part of the write_jedec function. I can do everything else except  
write (-w) to the flash chip. I get a:

Vendor ID: rca, part ID: rm4100
Found chipset "ICH4/ICH4-L", enabling flash write... OK.
NOT FOUND rca:rm4100
M50FW080 found at physical address 0xfff00000.
Flash part is M50FW080 (1024 KB).
ERASE FAILED @0, val 92!

If I remove the above function from write_jedec flashrom writes to the  
chip just fine.
> By the way, there is a bug in erase_chip_jedec() at the end. We use the
> simple toggle_ready_jedec() to check for end of erase operation and
> toggle_ready_jedec() spins in a tight loop without delays. Some chips
> (e.g. W39V040B) are documented to hang/crash/whatever if you try JEDEC
> toogle bit requests to check for the end of an erase operation in
> shorter intervals than 50 ms, right now we run the loop 1000000 times
> faster than allowed.
> write_jedec already makes sure not to write 0xff to the chip by calling
> write_page_write_jedec() which has the check for 0xff inside.
> So can we please find the real problem and fix it?
So maybe there is an issue with erase_chip_jedec than??

Thanks - Joe

More information about the coreboot mailing list