Resource allocation by Plug-and-Play BIOS

1
votes

Plug-and-Play BIOS spec says that if you have a PnP BIOS, it can configure the hardware.

This means that your BIOS reads the resource requirements of all devices and configures them (allocates bus-resources to them).

Does a PnP always allocate resources(ie assigns I/O or memory addresses and irqs) to the devices embedded/integrated on motherboard?

Will a PnP BIOS(ie $PnP structure is present), always assign resources(I/O and memory addresses) to all devices present on mobo(ie embedded/integrated on mobo) as well as on PCI expansion cards.

Although the BIOS may not know how to 'configure' the non-embedded devices(ie devices not embedded on mobo), and will only configure devices embedded/integrated on mobo itself, it 'should' assign addresses(I/O and memory) and irq to avoid conflicts in case a non-PnP OS like DOS is to be used.

My question is:

Does a PnP BIOS must assign the I/O, memory addresses and irq to PCI expansion card devices during POST, ie before loading and transferring control to OS bootlader ? Is it true for all PnP BIOSes ?

Assume [Plug-and-Play OS] option is set to No. ie We told the BIOS that we do not have a PnP OS, but a non-PnP OS like DOS.

Some BIOSes do not have this option. Do they always allocate resources to all devices(ie both embedded ones and those on expansion slots)?

Update on 2012-08-01 :

Section 2.1 titled 'System BIOS POST Requirements' of PnP BIOS spec v1a says:

(I mentioned only the 3 points that are relevant to this post. The (*) marked info is my interpretation of the standard's statements. )

In order to achieve the goals of Plug and Play, the system BIOS POST is responsible for achieving the requirements listed below:

  1. Configuration of all 'static' devices known to system BIOS:

    At a 'minimum', this includes system board devices. It 'can' also include 'Plug and Play ISA Cards' and devices located on EISA, ISA, PCI, or any of the other static bus architectures available.

    *In effect, the above statement says, devices 'embedded/integrated' on the system board on any static bus (e.g., PCI, ISA, or EISA).) 'must' be configured by the BIOS, becoz *BIOS knows about 'all' of the devices that are embedded on mobo, as a design part.* The system BIOS programmer must have incorporated the provisions to configure the devices embedded on mobo as a system design part.

    Does this also include, 'cards installed in PCI/ISA/EISA card slots' ?

  2. BIOS POST Resource arbitration: The system BIOS must now be aware of system resource usage. Using the information provided through runtime services (described in a later section), along with resource information known to the system BIOS, critical resource conflicts can be avoided. 'Loading the operating system with a conflicting device disabled is better than causing a resource conflict and a possible system failure.'

    *This seems for ISA/EISA devices embedded/integrated on mobo or on ISA/EISA expansion card slots. Since PCI devices' resources can't conflict in terms of both I/O( or memory) address allocation(becoz the addresses are not hardwired for PCI devices, and hence in the 'hands' of BIOS to allocate non-conflicting addresses.) and irq allocation(becoz PCI interrupts are shareable by design.), so this means that 'all' PCI devices(embedded or non-embedded)will be initialized/allocated memory or I/O addresses and irq assigmnments.

  3. Support for both Plug and Play and Non-Plug and Play Operating Systems: The Plug and Play system BIOS POST 'must' configure the system to operate with 'both' Plug and Play aware, 'as well as' non-Plug and Play operating system.* In non-Plug and Play environments, 'either' the system BIOS 'or' the appropriate system software (device drivers) 'must' configure 'all' devices (Plug and Play ISA Cards, PCI devices, etc.). This will allow all environments to 'load exactly as they would on a standard PC compatible systems'. However, in a Plug and Play environment, the system BIOS can now assist the operating system to perform features such as runtime configuration of system board devices and event recognition when system board devices have changed.

*All these 3 statements from the spec, seems to point that if a non-PnP OS is to be booted(e.g. DOS), then the system BIOS 'must' configure( or, allocate addresses and irqs, at least) 'all' PCI devices, whether embedded/integrated on motherboard(mobo) or not. For ISA and EISA devices, the BIOS 'must' not enable/allocate the resources for those ISA/EISA devices(whether embedded or non-embedded) which will result in conflicting resource assignments.

Am I right in concluding from above statements of the spec. that: "If the BIOS must boot a non-PnP OS, it must enable (i.e., enable ie allocate resources) 'every' PCI device(whether embedded on mobo or on PCI expansion card slot) in the system so that they are available for use by the OS and application programs"?

Update on 2012-08-04 :

Have a look at chapter 12 of Linux Device Drivers 3rd ed.. The author, at many places explicitly refers that I/O or memory addresses and IRQ assignments will already be done by bios at the time linux kernel begins executing, and linux kernel may tailor the assignment according to its needs.

Might be another reference that mentions what are we trying to reach.

2
dosbiospcipci-busplug-and-play
@JonathonReinhart- Why this question is not related to programming? Just becoz I didn't make reference to any development environment, doesn't make this question out of scope. I need to develop a driver to be used from DOS, that's why I'm asking this question here. If the BIOS doesn't assign I/O or memory addresses to PCI expansion cards during POST, then I must write a resource allocator to be used from DOS!. I do accept that this question may look like some hardware troubleshooting issue, but that's not the case. It is much more than that. :) – jacks
@JonathonReinhart It's a valid programming question. – Alexey Frunze
@jacks comment retracted :-) If I could retract my close vote, I would. But for some reason SO doesn't have that feature. – Jonathon Reinhart
@JonathonReinhart- It's okay. I can just say, always poke the matter before jumping to a conclusion. – jacks
From a software perspective, LPC and ISA are pretty much the same thing. LPC devices are mapped at a (semi) fixed I/O IRQ and you talk to them just like an ISA device. (We implement custom LPC devices in our systems.) LPC is mostly used for the Super I/O and BIOS flash chip. However, newer Intel chipsets use a SPI interface for the BIOS chip. – myron-semack

2 Answers

4
votes

The "PnP OS" option is only relevant for ISA PnP devices, which are pretty much non-existent these days. That's why you don't see the option much anymore. It's basically a don't care on motherboards without ISA slots. Might still have some relevance if you can set your serial port base addresses to "Auto".

The BIOS should always configure the PCI BARs and INTx-to-IRQ mappings. It should do this regardless of the PnP OS option. This includes both onboard PCI devices (e.g. integrated Ethernet), and PCI/PCIe slot boards. I have never seen a (working) BIOS where you could boot to DOS and have non-configured BARs.

When the BIOS is setting up PCI configuration space, it will take ISA PnP information into account. For example, if it knows an ISA PnP device is using IRQ 9, the PCI init routines should be smart enough to not map IRQ 9 to any PCI INTx lines.

Also, keep in mind that when your operating system loads, it is free to overwrite BARs and IRQ mappings. Windows typically re-does IRQ mappings when it activates APIC and ACPI. BARs are typically not changed, although there can be special cases like a PCIe Hotplug event which requires the OS to populate the BAR.

-1
votes

The "PnP OS" option is only relevant for ISA PnP devices, which are pretty much non-existent these days. - FALSE! This option has a great impact to the distribution of the interrupts in Windows OS! The experiment itself to disprove abovementioned statement is very simple!