[coreboot] flashrom issues found??

[Carl-Daniel Hailfinger]

On 12.03.2008 20:19, joe at smittys.pointclark.net wrote:
> 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?
>   

In theory, it should be possible to fix this in v2 as well.


>> 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.
>   

Good to know.

>> 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.
>>     

Please reread the line above.


> 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?

No. The modified erase_block_jedec could perhaps work by accident, but
this is rather unlikely.


> How can we fix this?
>   

As I wrote in my last mail: "erase_sector_39sf020() is the erase routine
you need to use in a loop." It is the (mostly) correct routine to use.
Simply call it for every block to be erased. There is an equivalent
routine for the 20sf040.

However, if you want instant gratification, replace erase_jedec() with
erase_lhf00l04() or erase_82802ab(). Those two functions are even closer
to the datasheet recommended values. In fact, with them everything
should work out of the box, including sector protection.

Regards,
Carl-Daniel

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