Date: Thu, 27 Aug 1998 17:58:22 +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: <199808271758.RAA01530@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 28 Aug 1998 00:44:21 GMT." <199808280044.RAA03553@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. > > Huh? How can it do this without locating the devices to which the > resources are assigned? By using a variety of non- and semi- intrusive techniques. For example the ISA PnP architecture supports using a PnP device as a test pattern generator for I/O port ranges, which are the most critical. > > 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). > > The resource records are in the ROM, so the ROM has to be there. The resource records are not necessarily in a ROM, and such a ROM is not necessarily mapped into any accessible address space. Even if such a ROM were mapped, it might not contain any initialisation code, so the point about detecting the ROM type based on initialisation layout is unuseful. Alternative designs include serial EEPROM or serial ROM, and a hardcoded shift register preload (effectively a serial ROM) embedded in the interface ASIC. > > > 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. > > Unless the BIOS is not a PnP BIOS, in which case the OS has a much better > shot. You get a kick out of restating things? The point being that under these circumstances the OS is the *only* player, but it's _still_guessing_. > But since the OS can detect legacy hardware resource usage via probe, > and the BIOS does not, the OS has an advantage, even in the PnP BIOS > case. The OS has no advantage over a PnP BIOS unless the system is misconfigured. Even then it only has an advantage when it can detect everything. This is problematic. -- \\ 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?199808271758.RAA01530>