[coreboot] flashrom issues found??

[Carl-Daniel Hailfinger]

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.

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?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/