[flashrom] [PATCH] Updated vt823x "set all writes to lpc".

[Carl-Daniel Hailfinger]

On 22.12.2009 18:41, Luc Verhaegen wrote:
> On Tue, Dec 22, 2009 at 02:25:41PM +0100, Carl-Daniel Hailfinger wrote:
>   
>> On 22.12.2009 13:52, Luc Verhaegen wrote:
>>     
>>> On Tue, Dec 22, 2009 at 03:48:38AM +0100, Carl-Daniel Hailfinger wrote:
>>>   
>>>       
>>>> On 16.12.2009 12:14, Luc Verhaegen wrote:
>>>>     
>>>>         
>>>>> Chipset/Board: vt8237: Set All mem cycles to LPC in chipset enable.
>>>>>   
>>>>>       
>>>>>           
>>>> I don't have the datasheet, so I can't cross-check. I'm very interested
>>>> why this would be needed, though. If mem cycles don't go to LPC and we
>>>> have flash on LPC, the board won't boot anyway. If we force mem cycles
>>>> to LPC although we have parallel ROM, this will break. Does VT8237R
>>>> support parallel ROMs?
>>>>     
>>>>         
>>> We need this, otherwise we wouldn't be changing this many board enables 
>>> now.
>>>   
>>>       
>> Ah hm. I thought most board enables were created by imitating the
>> behaviour of the in-memory board enable code, not by checking for the
>> necessity of each step in there.
>> If there are VT8237R straps which select the ROM type, we should check
>> them and warn very loudly if a board strapped to parallel gets all
>> memory accesses redirected to LPC. That will make sure users know WTF
>> went wrong (if something went wrong).
>>
>>
>>     
>>> About parallel roms, no idea, but if we apply this patch, we should soon 
>>> find out.
>>>   
>>>   
>>>       
>>>> Side note: Should we read the ROMCS# strap on VT8235 to check whether
>>>> the ROM is LPC or Parallel? Does this strap exist for other VT823x as well?
>>>>     
>>>>         
>> The strap reading is IMHO very desirable because it can reduce the
>> number of probed chips roughly by half.
>>     
>
> The bit we are setting is the following:
>
> ROM Memory Cycles Go To LPC
> 0 Disable (all memory cycles go to LPC). default.
> 1 Enable (only ROM memory cycles go to LPC).
>
> What we do is set this bit to 0.
>
> This bit is present in 8235 too, but there it seems to be not necessary.
>
> It seems like a bug in vt8237R, and in 8237R only, as we only need to 
> set it there.
>   

Thanks for the explanation.

A slightly modified patch was committed in r815.

Regards,
Carl-Daniel

-- 
Developer quote of the month: 
"We are juggling too many chainsaws and flaming arrows and tigers."