Re: [coreboot] flashrom issues found??

Quoting Carl-Daniel Hailfinger :
> On 09.03.2008 20:20, [e-mail] wrote:
> > Quoting Carl-Daniel Hailfinger :
> > > On 09.03.2008 08:50, [e-mail] wrote:
> > > > Quoting ron minnich :
> > > > > On Sat, Mar 8, 2008 at 11:24 PM,   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.

To me it looks like if bios[i] does not equal 0xff than error......
I know nothing is writing to flash in this function but, this is right  
after the erase_chip_jedec() runs which writes to flash, correct?
> > > > > >             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.

This makes sense:-)
> > > 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.

I will try this and post my results.

Thanks - Joe