3

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.

jacks
  • 181
  • 1
  • 2
  • 6

1 Answers1

1

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.

David Schwartz
  • 61,528
  • 7
  • 100
  • 149
  • 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 06: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 06: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 07: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 07: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 07:15
  • If the BIOS does not support PnP, then it will not be able to boot from devices that require PnP for configuration. Setting the PnP OS to "yes" causes some additional devices to be allocated resources, but not all of them. In particular, devices that can only be used with a driver anyway do not need to be allocated resources because the driver can do that. – David Schwartz Jul 29 '12 at 07:24
  • Suppose I developed a PCI device and installed it on a PCI expansion slot in a PC. Of course I need to write a device driver to use my device. Now to use my device from a non-PnP OS say DOS, this means that I myself need to allocate I/O or memory address to my pci device by reading it's BARs. Till this point it is ok. But *how do I ensure that the I/O or memory and irq assignmnets that I made doesn't conflict with any other device already present on that PC.* See, the task ... – jacks Jul 29 '12 at 07:43
  • @jacks: You have to check, and you may need to unmap other resources if there's an unresovable conflict. That's why you really want a PnP OS to deal with PnP devices. It's not a trivial problem and the BIOS can't do it all by itself because it doesn't know what devices and device features the system will need to use. – David Schwartz Jul 29 '12 at 07:44
  • ...of a device driver is to manage its associated device and *not* to manage resource allocation of *all* devices present on a system. If I would have a PnP BIOS I could relieve the task of resource allocation to BIOS, and I simply need to write a driver to access my device via I/O instructions. So it seems to me that a PnP BIOS is required to do *resource allocation* (not configuration - that is a different thing will be taken are of by device driver for a particular OS). Isn't PnP means automatic non-conflicting resource allocation? – jacks Jul 29 '12 at 07:46
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/4293/discussion-between-david-schwartz-and-jacks) – David Schwartz Jul 29 '12 at 07:46