[coreboot] flashrom issues found??

[Carl-Daniel Hailfinger]

On 12.03.2008 01:03, joe at smittys.pointclark.net wrote:
> 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.
>>     

Can you find out whether ROM shadowing is enabled? That might explain
some of the effects.
Please try "flashrom --chip M50FW080" for easing and writing and reading
as well. I think the probing for other chips may cause some of the
strange readbacks.


>>>> 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.
>>     
>
> Well, I did just want you said above and the readback is not 0xff it
> looks like a coreboot image. Then I commented out
> erase_chip_jedec(flash) in write_jedec() and did this:
>
> [root at localhost flashrom]# flashrom -E
> Calibrating delay loop... OK.
> Found coreboot table at 0x00000530.
> Vendor ID: RCA, part ID: RM4100
> Found chipset "ICH4/ICH4-L", enabling flash write... OK.
> NOT FOUND RCA:RM4100
> Flash part is M50FW080 (1024 KB).
> Erasing flash chip
> [root at localhost flashrom]# flashrom -wv test.rom
> Calibrating delay loop... OK.
> Found coreboot table at 0x00000530.
> 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 55!
> Verifying flash... VERIFIED.
> [root at localhost flashrom]#
>
> There is definatly something funky going on with
> erase_chip_jedec(flash) here. I don't think it is a GPIO or anything, I
> have them setup just like the original bios and uniflash is able to
> write to it just fine with the original bios.........please help:-(
>   

Did you check ICH GPIOs and SuperIO GPIOs?
Maybe there is some ROM shadowing/caching involved as well. Comparing
the MTRRs between proprietary BIOS and coreboot may shed some light on
caching.


> One difference I did notice this time compared to last is the error:
> First write with no flashrom modifications:
> ERASE FAILED @0, val 92!
> and now with erase_chip_jedec(flash) commented out:
> ERASE FAILED @0, val 55!
>   

This is very interesting and supports my suspicion about
shadowing/caching. Maybe you will see even more changes if you use the
--chip parameter for flashrom.

> What does this mean? Also Intel has a development SDK for a
> development i830 board very close to this one that has a linux flash
> utility (pre-built binary, no source) with it. I am thinking of trying
> it with an ?strace? to see what it does? Would that help to find out
> what is going on here?
>   

See Ron's mail and my other mail.

Regards,
Carl-Daniel

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