From owner-freebsd-multimedia Tue Jul 29 23:57:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA14065 for multimedia-outgoing; Tue, 29 Jul 1997 23:57:21 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA14055; Tue, 29 Jul 1997 23:57:09 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA03429; Wed, 30 Jul 1997 07:52:59 +0200 From: Luigi Rizzo Message-Id: <199707300552.HAA03429@labinfo.iet.unipi.it> Subject: Re: Advice sought on PnP configuration To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 30 Jul 1997 07:52:58 +0200 (MET DST) Cc: hasty@rah.star-gate.com, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG In-Reply-To: <199707300600.PAA19038@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 30, 97 03:30:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Luigi Rizzo stands accused of saying: > > the driver. No manual configuration required (of course, the OS > > must recognize your card, but that's another problem and is common ... > This information is also available from the ECSD, which can also only > be fetched from the BIOS. wrong wording... I should have said "the OS must _know_ your card, or how can it know that pnp_id 0x12345678 corresponds to the board "foo" and must use driver "bar"... > > In order to configure cards correctly, the bios should know which > > IRQs and which I/O address ranges are used by plain isa devices. > > The former can be told to some bioses, the latter I have never seen > > how to do on my systems. > > The former is available from the ECSD, the latter is specifically > covered in the PnP specification. how ? I am talking about non-pnp devices... > > Since we cannot trust the BIOS (because it does not have enough > > info) the only way to do autoconfiguration reliably in FreeBSD is > > the following: > > We should only not trust the BIOS if it is broken. The bottom line > here is actually easy to determine; how do Microsoft do it? Do they > trust the BIOS if present, or do they start from scratch. > > Given that we have to work on systems with no BIOS PnP support, I'd be > inclined to look for means for locating IRQ availability information > (ECSD, perhaps reading back the IRQ routing data from known chipsets), > and then use the PnP technique to handle I/O conflicts. > > > 1 probe & attach pci devices > > 2 disable all pnp devices, so that they are not recognized by isa probes; > > 3 probe & attach plain isa devices; > > 4 configure PnP devices, using info derived from the isa configuration > > process to determine which address ranges and irqs are busy; > > 5 activate PnP devices; > > 6 finally, probe and attach PnP devices. > > > > Any comments on the above ? Right now I am doing steps in the order 1, > > 5, 6, 3 (2 and 4 are not necessary if the bios works), but it can > > fail in some cases for the reasons stated above. > > My personal preference : > > - gather all the information : > PCI probe > PnP probe > get ISA config (compiled in, datafile, etc.) > get PCI/PnP identifier tables (compiled in, bootloader, etc.) unfortunately, in the current code, a device is probed and attached right after the probe succeeds (otherwise, I guess one should store information on which devices have been probed successfully and where... etc) > - attach PCI devices > I/O ports and IRQs are assigned by the PCI rules. > - attach PnP devices > IRQs are taken from the free pool left after PCI assignment and > those marked for 'legacy' use. I/O ports are probed as per the > PnP spec. > - walk ISA config data, probe possible devices > We know which IRQ and I/O resources are still available, > we can hunt for devices that match the gaps. but this is a problem: you cannot (generally) reprogram isa device, so it would be better to probe them first and then relocate the programmable ones at a later time. As I said, for PCI devices it is not much of a problem: io addresses are generally taken from a different range, DMA does not use the ISA dma controller, and interrupts can be shared. But for PnP... > I think it's important to leave the 'legacy' devices until _last_, as > this prevents a PnP device being accidentally recognised as a 'legacy' > device. same goal that I have, but in a slightly different manner: step 2 _disables_ all pnp devices so they cannot be recognised as legacy devices. so the non-pnp isa attach cannot find PnP devices. As for getting isa config info: the only way we can do it is by looking at what devices have been successfully attached; compiled-in information are not helpful when a kernel such as GENERIC is built, with a ton of different devices compiled in. Thanks Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________