Editing PCI configuration space (section)

== Bus enumeration <span class="anchor" id="BUS-ENUM"></span><span class="anchor" id="IDSEL"></span>==
To address a PCI device, it must be enabled by being mapped into the system's I/O port address space or [[Memory-mapped I/O and port-mapped I/O|memory-mapped address space]]. The system's firmware (e.g. [[BIOS]]) or the [[operating system]] program the ''Base Address Registers'' (commonly called BARs) to inform the device of its [[system resource|resource]]s configuration by writing configuration commands to the PCI controller. Because all PCI devices are in an ''inactive'' state upon system reset, they will have no addresses assigned to them by which the operating system or [[device driver]]s can communicate with them. Either the [[BIOS]] or the operating system geographically addresses the PCI devices (for example, the first PCI slot, the second PCI slot, the third PCI slot, or the integrated PCI devices, etc., on the [[motherboard]]) through the PCI controller using the per slot or per device IDSEL (Initialization Device Select) signals.

{| class="wikitable floatright" style="margin-left: 1.5em; margin-right: 0;"
|+ PCI BAR Bits
|-
! Bits !! Description !! Values
|-
| colspan="3" style="text-align: center;" | ''For all PCI BARs''
|- style="vertical-align: top"
| style="text-align: right; padding: 0em 0.5em;" | 0 || style="padding: 0em 0.5em;" | Region Type || style="padding: 0em 0.5em;" | 0 = Memory<br>1 = I/O
|-
| colspan="3" style="text-align: center;" | ''For Memory BARs''
|- style="vertical-align: top"
| style="text-align: right; padding: 0em 0.5em;" | 2-1 || style="padding: 0em 0.5em;" | Locatable || style="padding: 0em 0.5em;" | 0 = any 32-bit<br>1 = &lt; 1&nbsp;[[megabyte|MB]]<br>2 = any 64-bit
|- style="vertical-align: top"
| style="text-align: right; padding: 0em 0.5em;" | 3 || style="padding: 0em 0.5em;" | Prefetchable || style="padding: 0em 0.5em;" | 0 = no<br>1 = yes
|- style="vertical-align: top"
| style="text-align: right; padding: 0em 0.5em;" | 31-4 || style="padding: 0em 0.5em;" | Base Address || style="padding: 0em 0.5em;" | naturally 16-byte aligned
|-
| colspan="3" style="text-align: center;" | ''For I/O BARs''
|- style="vertical-align: top"
| style="text-align: right; padding: 0em 0.5em;" | 1 || style="padding: 0em 0.5em;" | Reserved || style="padding: 0em 0.5em;" |
|- style="vertical-align: top"
| style="text-align: right; padding: 0em 0.5em;" | 31-2 || style="padding: 0em 0.5em;" | Base Address || style="padding: 0em 0.5em;" | naturally 4-byte aligned
|}

When the computer is powered on, the PCI bus(es) and device(s) must be ''enumerated'' by BIOS or operating system. Bus enumeration is performed by attempting to access the PCI configuration space registers for each buses, devices and functions. Note that device number, different from VID and DID, is merely a device's sequential number on that bus. Moreover, after a new bridge is detected, a new bus number is defined, and device enumeration restarts at device number zero.

If no response is received from the device's function #0, the [[Bus mastering|bus master]] performs an abort and returns an all-bits-on value ({{mono|FFFFFFFF}} in hexadecimal), which is an invalid VID/DID value, thus the BIOS or operating system can tell that the specified combination bus/device_number/function (B/D/F) is not present. So, when a read to a function ID of zero for a given bus/device causes the master (initiator) to abort, it must then be presumed that no working device exists on that bus because devices are required to implement function number zero. In this case, reads to the remaining functions numbers (1&ndash;7) are not necessary as they also will not exist.

When a read to a specified B/D/F combination for the vendor ID register succeeds, the system firmware or operating system knows that it exists; it writes all ones to its BARs and reads back the device's requested memory size in an encoded form. The design implies that all address space sizes are a power of two and are naturally aligned.<ref name="pci-bars" />

At this point, the BIOS or operating system will program the memory-mapped addresses and I/O port addresses into the device's BAR configuration registers. These addresses stay valid as long as the system remains turned on. Upon power-off, these settings are lost and the procedure is repeated next time the system is powered back on. The BIOS or operating system will also program some other registers of the PCI configuration space for each PCI device, e.g. [[interrupt request]]. Since this entire process is fully automated, the user is spared the task of configuring any newly added hardware manually by changing [[DIP switch]]es on the cards themselves. This automatic device discovery and address space assignment is how [[plug and play]] is implemented.

If a PCI-to-PCI bridge is found, the system must assign the secondary PCI bus beyond the bridge a bus number other than zero, and then enumerate the devices on that secondary bus. If more PCI bridges are found, the discovery continues recursively until all possible domain/bus/device combinations are scanned.

Each non-bridge PCI device function can implement up to 6 BARs, each of which can respond to different addresses in I/O port and memory-mapped address space. Each BAR describes a region <ref>{{Cite web
 | url = http://www.read.seas.harvard.edu/~kohler/class/04f-aos/ref/hardware/vgadoc/PCI.TXT
 | title = PCI configuration methods
 | date = 2011-11-22
 | accessdate = 2021-09-27
 | publisher = read.seas.harvard.edu
}}</ref><ref name="pci-bars">{{Cite web
 | url = http://wiki.osdev.org/PCI#Base_Address_Registers
 | title = Base Address Registers | work = PCI
 | date = 2013-12-24
 | accessdate = 2014-04-17
 | publisher = osdev.org
}}</ref> that is between 16 bytes and 2 gigabytes in size, located below the 4 gigabyte address space limit. If a platform supports the "Above 4G" option in system firmware, 64 bit BARs can be used. '''Resizable BAR''' (also known as ''Re-Size BAR'', [[AMD]] ''Smart Access Memory'' (SAM),<ref name="rps-rebar">{{cite news |first=James |last=Archer |date=2021-12-07 |title=What is Resizable BAR, and should you use it? |url=https://www.rockpapershotgun.com/what-is-resizable-bar-and-should-you-use-it |work=[[Rock Paper Shotgun]] |access-date=2024-03-26}}</ref> or [[ASRock]] ''Clever Access Memory'' (CAM))<ref>{{cite web |url=https://www.techpowerup.com/275578/asrock-implements-cam-clever-access-memory-on-intel-z490-taichi-motherboard |title=ASRock Implements CAM (Clever Access Memory) on Intel Z490 Taichi Motherboard |author=Raevenlord |date=2020-12-04 |website=TechPowerUp  |access-date=2024-03-26}}</ref> is a capability which a PCIe device can use to negotiate a larger BAR size.<ref name="intel-rebar">{{cite web |url=https://www.intel.com/content/www/us/en/support/articles/000090831/graphics.html |title=What Is Resizable BAR and How Do I Enable It? |date=2023-04-18 |website=intel.com |publisher=Intel Corporation |access-date=2024-03-26 }}</ref> Classically, BARs were limited to a size of 256MB, but modern [[graphics card]]s have [[framebuffer]]s much larger than that.<ref name="rps-rebar"/> This mismatch led to inefficiencies when the CPU accessed the framebuffer.<ref name="rps-rebar"/> Resizable BAR lets a CPU access the whole framebuffer at once, thus improving performance.<ref name="rps-rebar"/>

A PCI device may also have an ''[[option ROM]]''.