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



More information about the coreboot mailing list