Date: Fri, 28 Aug 1998 02:04:36 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: tlambert@primenet.com, mike@smith.net.au, tony@dell.com, wpaul@skynet.ctr.columbia.edu, chuckr@glue.umd.edu, hackers@FreeBSD.ORG Subject: Re: PCI devices Message-ID: <199808280204.TAA07846@usr07.primenet.com> In-Reply-To: <199808271758.RAA01530@dingo.cdrom.com> from "Mike Smith" at Aug 27, 98 05:58:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. After a bit of re-reading, I can see where I went wrong. A card *MAY* have a ROM; if it doesn't, you have to use the I/O ports to get the config data. What it may *NOT* omit is the existance of config data. > > > 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_. I think a PnP FreeBSD should work with PnP cards in a machine that does not have a PnP BIOS. I think it's misleading to say you have a PnP OS, and then when a user plugs in a PnP card, the card is not reported. I think any PnP OS that fails to do the work of the PnP BIOS in the absence of a PnP BIOS doesn't deserve to be called a PnP OS. I'm attempting to make this point, not restate things. If this is a restatement (again), then I think you are trying to gloss over the point. > > 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. In "detect", I loosely include the ability to mark resources used by legacy cards as "taken", without specifying "by what". In other words, cards for which there is not a driver, but for which resources must be accounted to avoid a conflict. I also like the Microsoft idea that you tell the PnP BIOS that you aren't a PnP OS; this avoids things like the Adaptec 2940 and Bus Mouse IRQ 12 conflicts caused by the ALR motherboard having a BIOS that didn't know that there was a bus mouse on the motherboard, since the OS is capable of, best case, proactively detecting the hardware, or, worst case, allowing configuration of a "conflict map" for the hardware so that it doesn't break PnP devices by mapping them into this "unused" space. 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?199808280204.TAA07846>