[coreboot] flashrom issues found??

joe at smittys.pointclark.net joe at smittys.pointclark.net
Wed Mar 12 20:19:26 CET 2008


Quoting Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>:

> On 12.03.2008 16:39, joe at smittys.pointclark.net wrote:
>> Quoting Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>:
>>> 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,  <joe at smittys.pointclark.net> 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




More information about the coreboot mailing list