[coreboot] flashrom issues found??

joe at smittys.pointclark.net joe at smittys.pointclark.net
Wed Mar 12 00:59:35 CET 2008

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

> On 09.03.2008 20:20, joe at smittys.pointclark.net wrote:
>> 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) {
> It reads from the flash and compares the result to 0xff. No write to
> flash happens.
>>>>>>                 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.
> It seems erase_chip_jedec() leaves the chip in a bad state. And
> according to the chip documentation, the value you read means
> "program/erase finished, programming failed some time since last
> reset/status register clearing, failed attempt to write to a protected
> block some time since last reset/status register clearing". However,
> both spec and real life are unclear whether my interpretation is correct.
>>> 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??
> Indeed. Have you tried to erase only, then read back the result
> immediately? That would be very interesting. If the readback is all
> 0xff, try commenting out erase_chip_jedec(flash) in write_jedec() and
> leave the "dumb check if erase successful" in place, erase the memory
> with flashrom -E, wait 30 seconds, write to the memory with the flashrom
> version which does not call erase_chip_jedec(flash) in write_jedec(). I
> would be very interested in the result.
> Regards,
> Carl-Daniel
> --
> http://www.hailfinger.org/

Thanks - Joe

More information about the coreboot mailing list