[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Subsystem IDs, again

mek@sco.com wrote:
> Motherboard ID? Where does that live? Maybe you can intuit it
> from, say, Host Bridge vendor and device id or some such, but
> all you'd be doing is providing a 'convention,' not a standard.

Since I stuck my nose in earlier and "helped" get this thing going, let me
go back and explain how things _could_ work.

This is a long message but I hope it'll help clear up the confusion. And
there's a quiz at the end. No, really. :-)

The goal, I think, is to allow Windows 95 to re-enumerate the whole PCI bus
and figure out for itself how to initialize everything. It would be nicer
if Microsoft could trust every PC vendor to ship usable BIOS code that
would leave everything in the right condition for Windows 95, but, just in
fact, it can't.

So... Microsoft wants to be able to use device IDs to figure out what kind
of device is on the bus, and subsystem IDs to figure out what's attached to
the other side of these devices. This, I think, is a good plan...

Except that subsystem IDs are inconsistently implemented. They can't be
permanently programmed into the PCI device; that would defeat the whole
point of it. They have to be set by the subsystem vendor. Some PCI devices
don't allow this at all, and some subsystem vendors don't want to spend the
money to add the necessary EPROM, or whatever other device is necessary.

So what I suggested was that anyone designing a new PCI device for
expansion cards should support the use of some ultra-cheap serial ROM or
PROM, just to load subsystem ID data into the device's registers at
powerup. I don't really know if Dallas Semiconductor sells custom versions
of their DS2401 "Silicon Serial Number", but that would be ideal. If the
designer wants to load other proprietary registers, something like the
DS2430a or DS2501-UNW with EEPROM would be good, too.

I also pointed out that a motherboard doesn't really need separate SROMs
for each hardwired PCI device; the motherboard BIOS, which certainly gets
control of the machine before anything else, could program the subsystem
IDs and then lock in those values before allowing anything else to
communicate with PCI.

So this shows how we can ensure that every PCI device gets a valid
subsystem ID before Windows 95, or even the PCI BIOS, goes looking for

At least if we're talking about new devices. For old devices on expansion
cards, well, I don't think there's ANY good answer to this. Many old
devices (heck, many new devices) don't know anything about subsystem IDs.
Windows 95 has to be able to handle these as legacy devices. If it
recognizes the device and has some way to figure out whose card it's on,
that's good. If not? Today, this just causes grief. I think it always will.
There's not always going to be a way to tell if that PCI Ethernet chip is
on a Brand X card or a Brand Y card.

For old devices on the motherboard, however, we _can_ help. Once again, the
motherboard BIOS can be programmed to know what devices are there, and
what's on the other side of them-- the same info we'd use to generate
subsystem IDs if we had someplace to put them. In this case, we need a
mechanism to allow the motherboard BIOS to communicate this info to Windows

What I don't know, and hopefully someone can just answer this without
creating any new confusion, is, is there such a mechanism? Does Windows 95
look at the results of the PCI BIOS scan at all? Or only if it trusts the
motherboard and BIOS vendor? Or what?

..                 png