Re: [coreboot] flashrom issues found??

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) {
> > > >                 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.
> 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??

Thanks - Joe