[coreboot] flashrom issues found??

[Carl-Daniel Hailfinger]

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/