Date: Thu, 27 Aug 1998 18:57:27 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: tlambert@primenet.com, tony@dell.com, wpaul@skynet.ctr.columbia.edu, chuckr@glue.umd.edu, hackers@FreeBSD.ORG Subject: Re: PCI devices Message-ID: <199808271857.LAA26413@usr01.primenet.com> In-Reply-To: <199808262207.WAA00827@word.smith.net.au> from "Mike Smith" at Aug 26, 98 10:07:56 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > A PnP OS follows the PnP specification, available from the Intel > > and Microsoft sites, for free download (use "site search" and > > look for "PnP specification"). > > > > A PnP OS is superior, since it will work on machines without a PnP > > BIOS. > > This is a fallacious conclusion. An OS which meets the criteria for > "PnP OS" in the preceeding discussion need not (and may not) work on a > system without a PnP BIOS. Then the OS sucks. An OS that does not know how to do card isolation will be unable, in the absence of a PnP BIOS, to utilize cards other than those whose POST's enable them as being potential boot devices. A nominally "PnP OS" that can't talk to "PnP cards", isn't very "PnP". This was a major flaw in the initial "PnP Windows 95" release. > As Tony pointed out, all the "PnP OS" setting does is determine whether > the BIOS or the OS will perform resource allocation for devices that > are not marked as being a potential boot path. Actually, According to "Plug and Play System Architecture", page 190, item 6: If the software must boot a non-PnP OS, it must enable (i.e., activate) every device in the system so that they are available for use by the OS and application programs. > > By default, PnP devices are required to be "disabled until enabled"; > > the bsearch mechanism can be implemented once in the OS; after that, > > it is no longer necessary to rely on the BIOS vendor "doing the right > > thing". > > This is also not correct, as a PnP OS can only operate properly in a > situation where resource availibility can be determined. In the PnP > BIOS case, this can be obtained from the BIOS. Without a PnP (actually > ESCD) BIOS, the OS must guess. No. 1) All legacy ISA device ROMs are required to begin on a 2K boundary in the range 0x000C0000 through 0x000EFFFF. The first and second bytes must be 0x55AA. The third byte is the number of 512 byte blocks in the ROM. The fourth is the actual entry point to the code. 2) All PnP device ROMS have the same requirements. But as of the fourth byte, there are 4 bytes of jump instruction to the actual initialization entrypoint. One can differentiate PnP devices from legacy ISA devices using this information. 3) On a non-PnP-BIOS machine, devices in the boot path will be enabled. Devices which are not boot devices are supposed to be disabled by default (the infamous "turn off PnP on the card" soloution to missing hardware). 4) The PnP OS can then: A) issues the key sequence to put all PnP devices to sleep. B) identify all EISA, MCA, PCI, and PCMCIA hardware, for the purpose of excluding it from ISA identification. C) Identify all remaining (legacy) ISA hardware. D) Perform PnP card isolation for configuration, and identify all possible locations for the cards. E) Perform closure over all possible configuration combinations for all cards. F) Configure the cards, as necessary. This is, in fact, the basis for the Microsoft claim that Windows 98 is better at autoconfiguration that most PnP BIOS's. In the presence of legacy cards unknown to the BIOS, Microsoft will not assign a resource used by a legacy card to a PnP card. This is what FreeBSD should be doing, as well. Note that this will be necessary for the OS to do on non-Intel hardware in most cases, since the OS must run an x86 interpreter to implement the card POST and other BIOS execution functions for Intel cards in these systems. In any case, there should be no more reason for an OS to guess than there would be for a BIOS to guess. Yes, this may mean allocating legacy cards PnP resources in the OS data store/Registry. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808271857.LAA26413>