RE: Subsystem IDs, again

["Kevin D. Davis" <kevind@ti.com>]

The problem with:
	<BIOS loading subsystem IDs>
* the system BIOS would have to load devices based upon devsels. 
 Otherwise, it might load into devices that are in expansion slots.
* subsystem BIOSs couldn't load device ids, because subsystem BIOSs will 
not always get control after runtime power off events (coming in WinNT with

ACPI).  The system BIOS is probably only sort of promised to get some 
amount of control after some runtime power events.   Notice all of the 
"some"s and "sort of"s.  I'd hate to design my system based upon the 
current ACPI specs.

	<Extra chips to implement subsystem IDs>
* Many system designs don't have any room to add more chips.  Just rip open

a notebook and see how little available space is there.  (Heck, go buy 
several and compare the difference :).
* Now if someone could come up with a neat idea about doing it with only 1 
more chip....


Kevin D. Davis
TI Notebook, Software


----------
From:  Peter N. Glaskowsky[SMTP:png@woof.net]
Sent:  Tuesday, July 30, 1996 2:30 PM
To:  Mailing List Recipients
Subject:  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
one...

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

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




µp]