Date: Wed, 30 Jul 1997 15:30:44 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: hasty@rah.star-gate.com, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: Advice sought on PnP configuration Message-ID: <199707300600.PAA19038@genesis.atrad.adelaide.edu.au> In-Reply-To: <199707300404.GAA03229@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 30, 97 06:04:33 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo stands accused of saying: > > I am revising the PnP configuration stuff. I have got to a point > where it behaves very similarly to the PCI configuration stuff, > i.e. it relies on the BIOS to set addresses and IRQs correctly, > and then fetches the parameters from the board and passes them to > the driver. No manual configuration required (of course, the OS > must recognize your card, but that's another problem and is common > with PCI stuff -- within some time, a reasonable database of card > IDs can be compiled to have things working for a wide range of > boards). This information is also available from the ECSD, which can also only be fetched from the BIOS. > 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. > 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.) - 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. 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. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707300600.PAA19038>