Date: Thu, 27 Aug 1998 14:57:26 +0000 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: mike@smith.net.au (Mike Smith), tony@dell.com, wpaul@skynet.ctr.columbia.edu, chuckr@glue.umd.edu, hackers@FreeBSD.ORG Subject: Re: PCI devices Message-ID: <199808271457.OAA00519@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 27 Aug 1998 18:57:27 GMT." <199808271857.LAA26413@usr01.primenet.com>
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. Or perhaps it's just designed only to run on PnP systems. > 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". It may not support ISA PnP. Please don't call them "PnP cards"; PCI cards are PnP cards, PCCARD cards are PnP cards. > > 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. Which is exactly what I said. > > > 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. Yes. Read that again: "Yes". The OS may do a good job of guessing, but that's all it can do. > 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. This is almost irrelevant. > 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. So? You are again abusing "PnP" to mean "ISA PnP". > 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). Your phrasing is ambiguous here. The ISA PnP spec requires devices which *may* form part of the boot path to be enabled following reset, with "default" configurations. "Turning off PnP on the card" will make a non-boot-path device visible, yes. > 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. It's arguably erroneous to perform this at this stage. It would be more correct to attempt to locate *resources* claimed by such devices. > 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. Only if the operating system is capable of locating the device, and only if the user has not correctly informed the BIOS of the resources consumed by said device. If the user has behaved appropriately, the information is available both to the BIOS and the operating system via the ESCD data. > 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. The number of ISA PnP adapters with onboard BIOS code is so low that such emulation is virtually pointless. There is one specific case (video adapters) which is already well covered on at least some platforms (eg. the alpha console ROM contains an x86 emulator). > In any case, there should be no more reason for an OS to guess than > there would be for a BIOS to guess. In the absence of ESCD information, the OS must guess as to the location of system peripherals. It can only detect those peripherals that it already knows about, ie. it must guess. In the presence of (correct) ESCD information, the BIOS and the operating system both have the same data, and modulo bugs in the BIOS implementation both can do the same work. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199808271457.OAA00519>