[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