Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Jul 1997 07:52:58 +0200 (MET DST)
From:      Luigi Rizzo <luigi@labinfo.iet.unipi.it>
To:        msmith@atrad.adelaide.edu.au (Michael Smith)
Cc:        hasty@rah.star-gate.com, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG
Subject:   Re: Advice sought on PnP configuration
Message-ID:  <199707300552.HAA03429@labinfo.iet.unipi.it>
In-Reply-To: <199707300600.PAA19038@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 30, 97 03:30:25 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 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/
_____________________________|______________________________________



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707300552.HAA03429>