Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 in PCI BARs) 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 bootloader ? 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' ? This is where I'm confused exactly.

  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 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"?

At least this must be the case when [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.

share|improve this question

If you set PnP OS to no in the BIOS, it will assign resources to all devices. If you set PnP OS to yes in the BIOS, it will only assign resources to those devices that might be needed to boot the OS or that the OS might need to access before its PnP engine is operational.

share|improve this answer
Do you mean to say that with PnP OS to No in BIOS setup, all devices(whether embedded on mobo or on pci expansion cards) will be assigned appropriate I/O or memory addresses while POST completes and control is transfered to OS bootloader? Is it guaranteed in a PC having PnP compliant BIOS - ie $PnP signature is present. If this is true, then it means that I can access any PCI device(embedded or non-embedded on mobo) in say DOS, by searching for it using its bus/device/function, and reading its BARs to get its I/O(or memory in case of MMIO) address and issue I/O instructions to it.Isn't it? – jacks Jul 29 '12 at 6:42
Yes, all devices. No, it's not guaranteed because the BIOS is not required to be able to configure complex devices. Generally, though, you can access any PnP PCI device from DOS if the BIOS supports configuring it. Note that the BIOS may do a terrible job. – David Schwartz Jul 29 '12 at 6:57
Actually from my perspective configuring is different from allocating resources. By 'allocating resources' I mean assigning I/O or memory addresses and irqs. A BIOS may have no knowledge of how to 'configure' a particular PCI device, but of course it can assign I/O or memory addresses and irqs to that PCI device w/o configuring it. It seems to me that 'allocating resources' (leave the configuring part) to all devices(embedded on mobo + on PCI expansion cards) should be guaranteed on a PC having PnP BIOS. Isn't it? – jacks Jul 29 '12 at 7:04
I do not believe it is formally guaranteed. You may find that devices like sound cards have not been assigned addresses. For one thing, it is common for some resources on some devices not to be used at all, and the BIOS may find it impossible (or very sub-optimal) to map all resources. You are only formally guaranteed that devices the BIOS knows how to boot, and simple keyboard and VGA-compatible video devices will be allocated. (And a few other things, such as enough sound hardware to beep.) – David Schwartz Jul 29 '12 at 7:09
Even if a PnP BIOS is not required to allocate resources to all devices present on the system, then what is the purpose of a PnP BIOS? If its only purpose is to provide boot support, then that is done even on a BIOS that do not support PnP = for e.g. if I set [PnP OS] option to YES, then also the system will boot normally as keyboard and VGA-compatible video devices will then also be initialized, otherwise we won't be able to view BIOS setup menu or chipset logo at startup. – jacks Jul 29 '12 at 7:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.