PCI Configuration Space
From Wikipedia, the free encyclopedia
One of the major improvements Peripheral Component Interconnect (PCI) had over other I/O architectures was its configuration mechanism. In addition to the normal memory-mapped and port spaces, each device on the bus has a configuration space. This is 256 bytes that are addressable by knowing the 8-bit PCI bus, 5-bit device, and 3-bit function numbers for the device (commonly referred to as the BDF). This allows up to 256 buses, each with up to 32 devices, each supporting 8 functions. A single PCI expansion card can respond as a device and must implement at least function number zero. The first 64 bytes of configuration space are standardised; the remainder are available for vendor-defined purposes.
In order to allow more parts of configuration space to be standardised without conflicting with existing uses, there is a list of capabilities. Each capability has one byte that describes which capability it is, and one byte to point to the next capability. The number of additional bytes depends on the capability ID.
PCI-X 2.0 and PCI Express introduced an extended configuration space, up to 4096 bytes. The only standardised part of extended configuration space is the first 4 bytes at 0x100 which are the start of an extended capability list. Extended capabilities are very much like normal capabilities except that they can refer to any byte in the extended configuration space (by using 12 bits instead of 8), have a 4-bit version number and a 16-bit capability ID. Extended capability IDs overlap with normal capability IDs, but there is no chance of confusion as they are in separate lists.
Contents |
[edit] Standardised registers
The Vendor ID and Device ID registers identify the device, and are commonly called the PCI ID. The 16-bit vendor ID is allocated by the PCI SIG. The 16-bit device ID is then assigned by the vendor. There is an ongoing project to collect all known Vendor and Device IDs. (See external links (below).)
The Subsystem Vendor ID and the Subsystem Device ID further identify the device. The Vendor ID is that of the chip manufacturer, and the Subsystem Vendor ID is that of the card manufacturer. The Subsystem Device ID is assigned by the subsystem vendor, but is assigned from the same number space as the Device ID.
The Command register contains a bitmask of features that can be individually enabled and disabled.
The Status register is used to report which features are supported and whether certain kinds of error have occurred.
The Cache Line Size register must be programmed before the device is told it can use the memory-write-and-invalidate transaction. This should normally match the CPU's cache line size, but the correct setting is system dependent.
[edit] Bus enumeration
In order to address a device through port space or memory space, system firmware or the OS will program the Base Address Registers (commonly called BARs) by writing configuration commands to the PCI controller. Since on system boot, all PCI devices are in an inactive state, they do not have any addresses assigned to them by which the operating system or device drivers can communicate with them. Either the BIOS or the operating system itself geographically addresses the PCI slots (e.g. the first PCI slot, or the second PCI slot or the third PCI slot on the motherboard etc.) through the PCI controller. Since there is no direct method for the BIOS or OS to determine which PCI slots have devices and which functions they implement, the PCI bus must be enumerated. Bus enumeration is performed by attempting to read the VID/DID for each combination of bus, device, and function. If there is no device that implements the specified function, the bus master performs an abort and returns all 1's in binary (F's in hexadecimal). This is an invalid VID/DID so the BIOS or OS know the specified device does not exist. If a read to function zero of a specified bus/device master aborts, then it is assumed that no such device exists on the bus since devices are required to implement function number zero. In this case reads to the remaining functions are not necessary.
When a read to a specified BDF succeeds, the BIOS or OS programs the memory and port addresses into the PCI devices' on-chip memory. These addresses stay valid as long as the system remains turned on. On power off, all these settings are lost and on the next system boot, the configuration procedure is repeated all over again. Since this entire process is fully automated, the computer user is spared the difficult task of configuring any newly added hardware manually by modifying settings of dip switches on the cards themselves. This is how plug and play is implemented.
Each non-bridge device can implement up to 6 BARs, each of which can respond to certain areas of port or memory space. A device can have a ROM.
[edit] See also
[edit] External links
- The Linux PCI ID Repository, a project to collect all known IDs
- PCI and PCI32 utilities, Craig Hart's freeware PCI Software suites and ID Database
- RapidDriver - PCI interfacing from Win32.
