From owner-freebsd-hackers Thu Aug 27 19:06:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA24854 for freebsd-hackers-outgoing; Thu, 27 Aug 1998 19:06:17 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA24797 for ; Thu, 27 Aug 1998 19:05:52 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id TAA00722; Thu, 27 Aug 1998 19:04:56 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd000656; Thu Aug 27 19:04:49 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id TAA07846; Thu, 27 Aug 1998 19:04:37 -0700 (MST) From: Terry Lambert Message-Id: <199808280204.TAA07846@usr07.primenet.com> Subject: Re: PCI devices To: mike@smith.net.au (Mike Smith) Date: Fri, 28 Aug 1998 02:04:36 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, tony@dell.com, wpaul@skynet.ctr.columbia.edu, chuckr@glue.umd.edu, hackers@FreeBSD.ORG In-Reply-To: <199808271758.RAA01530@dingo.cdrom.com> from "Mike Smith" at Aug 27, 98 05:58:22 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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