Re: [coreboot] flashrom issues found??

Quoting Carl-Daniel Hailfinger :
> On 12.03.2008 16:39, [e-mail] wrote:
> > Quoting Carl-Daniel Hailfinger :
> > > On 12.03.2008 13:46, Carl-Daniel Hailfinger wrote:
> > > > On 12.03.2008 04:47, ron minnich wrote:
> > > > > On Tue, Mar 11, 2008 at 5:03 PM,   wrote:
> > > > > > 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?
> > > > >
> > > > > strace won't show you memory references. That's the only issue.
> > > >
> > > > Dumping the ICH GPIO settings and PCI config space (once) before and
> > > > (repeatedly) during a flash operation with the Intel SDK flash utility
> > > > may help you solve the mystery. If you can't find any differences, you
> > > > may have to resort to renouveau and revenge (reverse engineering tools
> > > > of nouveau and radeon developers, respectively).
> > >
> > > A PCI config space dump under factory BIOS and coreboot would be
> > > appreciated. As I wrote in another mail, knowing the MTRRs would help as
> > > well.
> >
> > here you go.
>
> Thanks. The enabled set of legacy devices (superio, keyboard,
> gameport...) differs quite a bit between factory and coreboot. However,
> even with the additional information I found, the LPC configuration
> seems to be OK.
>
> I dislike the MTRR settings, though. I would very much like to
> explicitly disable caching for the top 128 MB.

Yeh Corey didn't like it much eithor, I think he was talking about an  
improvment for v3?
> Have you already tried to set the ICH+SuperIO GPIO settings to the same
> values as the factory BIOS? If you do that and the issue still happens,
> we should investigate caching.

Yes, this I setup this in gpio.c in the mainboard directory.
> AARGH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> This is a M50FW080 chip, right? The M50FW080 data sheet explicitly
> states you can NOT issue the chip erase command in FWH mode.
> erase_sector_39sf020() is the erase routine you need to use in a loop.

A guy on my site suggested this:

i don't believe that m50fw080 supports chip erase in fwh mode .
you would have to do a sector erase after looking at the data sheet
http://www.st.com/stonline/books/pdf/docs/7764.pdf

after looking at flashrom jdec.c file you would also have to change  
the commands then just loop thru all the blocks to erase
look at sst_fwhub.c erase_sst_fwhub()

int erase_block_jedec(volatile uint8_t *bios, unsigned int block)
{
/* Issue the Sector Erase command */
*(volatile uint8_t *)(bios + 0x5555) = 0xAA;
myusec_delay(10);
*(volatile uint8_t *)(bios + 0x2AAA) = 0x55;
myusec_delay(10);
*(volatile uint8_t *)(bios + 0x5555) = 0x80; <-- change to 0x20
myusec_delay(10);

*(volatile uint8_t *)(bios + 0x5555) = 0xAA;
myusec_delay(10);
*(volatile uint8_t *)(bios + 0x2AAA) = 0x55;
myusec_delay(10);
*(volatile uint8_t *)(bios + block) = 0x50; <-- change to 0xd0
myusec_delay(10);

/* wait for Toggle bit ready */
toggle_ready_jedec(bios);

return 0;
}

Does that make sense? How can we fix this?

Thanks - Joe