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/ -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
