[coreboot] r3393 - trunk/util/flashrom

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sat Jun 28 23:29:10 CEST 2008


On 28.06.2008 23:14, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>   
>>> I don't think it makes much sense to differentiate between 29* types,
>>> lpc and fwh:
>>> The physical bus looks exactly the same from a software perspective;
>>> until after you scanned the bus and know which category the chip you
>>> found belongs to. And then the data is not exactly interesting anymore.
>>>   
>>>     
>>>       
>> Differentiating between LPC/FWH is important for the unlock procedure of
>> some chips.
>> Keeping the 29* parallel flash chips in a separate category fixes the
>> AMIC chip confusion by 29EE probing.
>>   
>>     
> Ok, so make a suggestion how to determine the difference without probing
> for the chips themselfes and we can discuss that.
>   

Determine the info from the chipset? If a chipset doesn't support
old-style parallel flash, there is no point probing for it.


>> I meant bus/address pairs where appropriate. There can be only one chip
>> per bus/address pair.
>>   
>>     
> There can even only be one chip per address, as those are physical cpu
> addresses. The bus is not relevant here for any known design of flash
> device.
>   

You can have chips with no address, though. SPI ID accesses are
inherently address-free. (If someone invents a SPI multiplexer, we can
still think about that.)


>>> But, I suggest we consider multiple flash busses once we see that happen
>>> in the real world. At least the ICH is always strapped to either FWH
>>> _or_ SPI.
>>>     
>>>       
>> Except if you have a Kontron board (for which multiple flash chip
>> support was written in the first place).
>>   
>>     
>
> Ok, I just checked the mail traffic on that one.  How do the bios straps
> look on those systems?
>
> Is there any method of finding out whether there is something on the SPI
> bus physically?
>   

In theory every command which returns something should return a stream
of 0xff if the bus is unpopulated.


> Some systems seem to hang when probing the spi bus without devices
> attached to it. Which is the origin of this discussion.
>   

Where exactly do these systems hang? If they hang while programming the
opcodes, the probing itself is not the cause of the hang.


Regards,
Carl-Daniel

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





More information about the coreboot mailing list