PCI: Difference between revisions

584 bytes added ,  2 years ago
m
Add code tag for most hexadecimal values
[unchecked revision][unchecked revision]
(Clean up whole page)
m (Add code tag for most hexadecimal values)
Line 11:
PCI devices are inherently little-endian, meaning all multiple byte fields have the least significant values at the lower addresses. This requires a big-endian processor, such as a Power PC, to perform the proper byte-swapping of data read from or written to the PCI device, including any accesses to the Configuration Address Space.
 
Systems must provide a mechanism that allows access to the PCI configuration space, as most CPUs do not have any such mechanism. This task is usually performed by the Host to PCI Bridge (Host Bridge). Two distinct mechanisms are defined to allow the software to generate the required configuration accesses. Configuration mechanism #1 is the preferred method, while mechanism #2 is provided for backwardbackwards compatibility. Only configuration mechanism #1 will be described here, as it is the only access mechanism that will be used in the future.
 
=== Configuration Space Access Mechanism #1 ===
 
Two 32-bit I/O locations are used, the first location (<code>0xCF8</code>) is named CONFIG_ADDRESS, and the second (<code>0xCFC</code>) is called CONFIG_DATA. CONFIG_ADDRESS specifies the configuration address that is required to be accesses, while accesses to CONFIG_DATA will actually generate the configuration access and will transfer the data to or from the CONFIG_DATA register.
 
The CONFIG_ADDRESS is a 32-bit register with the format shown in following figure. Bit 31 is an enable flag for determining when accesses to CONFIG_DATA should be translated to configuration cycles. Bits 23 through 16 allow the configuration software to choose a specific PCI bus in the system. Bits 15 through 11 select the specific device on the PCI Bus. Bits 10 through 8 choose a specific function in a device (if the device supports multiple functions).
Line 23:
{| {{wikitable}}
|-
! Bit 31
! Bits 30 - 24
! Bits 23 - 16
! Bits 15 - 11
! Bits 10 - 8
! Bits 7 - 0
|-
| Enable Bit
Line 51:
// Create configuration address as per Figure 1
address = (uint32_t)((lbus << 16) | (lslot << 11) |
(lfunc << 8) | (offset & 0xfc0xFC) | ((uint32_t)0x80000000));
// Write out the address
Line 80:
This configuration space access mechanism was deprecated in PCI version 2.0. This means it's only likely to exist on hardware from around 1992 (when PCI 1.0 was introduced) to 1993 (when PCI 2.0 was introduced), which limits it to 80486 and early Pentium motherboards.
 
For access mechanism #2, the IO port at <code>0xCF8</code> is an 8-bit port and is used to enable/disable the access mechanism and set the function number. It has the following format:
 
{| {{wikitable}}
|-
! Bits 7 - 4
! Bits 3 - 1
! Bit 0
|-
| Key (0 = access mechanism disabled, non-zero = access mechanism enabled)
Line 93:
|}
 
The IO port at <code>0xCFA</code> (the "Forwarding Register") is also an 8-bit port, and is used to set the bus number for subsequent PCI configuration space accesses.
 
Once the access mechanism has been enabled; accesses to IO ports <code>0xC000</code> to <code>0xCFFF</code> are used to access PCI configuration space. The IO port number has the following format:
 
{| {{wikitable}}
|-
! Bits 15 - 12
! Bits 11 - 8
! Bits 7 - 2
! Bits 1 - 0
|-
| Must be 1100b
Line 126:
* Computer supports both mechanism #1 and the memory mapped access mechanism
 
For BIOS systems, "<code>int 0x1A, AX=0xB101 (PCI BIOS presence check)"</code> will tell you if the system uses mechanism #1 or mechanism #2. If this function doesn't exist you can't be sure if the computer supports PCI or not. If it says mechanism #1 is supported you won't know if the memory mapped access mechanism is also supported or not.
 
For UEFI systems, it's extremely safe to assume that mechanism #2 is not supported; and you can test to see if the computer supports PCI or not by checking to see if the "PCI bus support" protocol exists. If PCI is supported, there's no easy way to determine if (e.g.) the computer supports mechanism #1 or not.
Line 132:
For both BIOS and UEFI systems, you can check the ACPI tables to determine if the memory mapped access mechanism is supported.
 
This leaves a few cases uncovered (e.g. where you don't know if whether mechanism #1 or #2 are supported despite trying all of the above). For these cases the only option left is manual probing. This means 2 specific tests - whether mechanism #1 is supported, and if not whether mechanism #2 is supported. Please note that manual probing has risks; in that if there is no PCI (e.g. the system only has ISA) the IO port accesses might cause undefined behaviour (especially on systems where the ISA bus ignores highest 6 bits of the IO port address, where accessing IO port 0x0CF8<code>0xCF8</code> is the same as accessing IO port <code>0xF8</code>).
 
=== PCI Device Structure ===
Line 143:
 
* ''Device ID:'' Identifies the particular device. Where valid IDs are allocated by the vendor.
* ''Vendor ID:'' Identifies the manufacturer of the device. Where valid IDs are allocated by PCI-SIG (the list is [https://pcisig.com/membership/member-companies here]) to ensure uniqueness and <code>0xFFFF</code> is an invalid value that will be returned on read accesses to Configuration Space registers of non-existent devices.
* ''Status:'' A register used to record status information for PCI bus related events.
* ''Command:'' Provides control over a device's ability to generate and respond to PCI cycles. Where the only functionality guaranteed to be supported by all devices is, when a 0 is written to this register, the device is disconnected from the PCI bus for all accesses except Configuration Space access.
Line 151:
* ''Revision ID:'' Specifies a revision identifier for a particular device. Where valid IDs are allocated by the vendor.
* ''BIST:'' Represents that status and allows control of a devices BIST (built-in self test).
* ''Header Type:'' Identifies the layout of the rest of the header beginning at byte <code>0x10</code> of the header and also specifies whether or not the device has multiple functions. Where a value of <code>0x0</code> specifies a general device, a value of <code>0x1</code> specifies a PCI-to-PCI bridge, and a value of <code>0x2</code> specifies a CardBus bridge. If bit 7 of this register is set, the device has multiple functions; otherwise, it is a single function device.
* ''Latency Timer:'' Specifies the latency timer in units of PCI bus clocks.
* ''Cache Line Size:'' Specifies the system cache line size in 32-bit units. A device can limit the number of cacheline sizes it can support, if a unsupported value is written to this field, the device will behave as if a value of 0 was written.
Line 157:
==== Header Type 0x0 ====
 
This table is applicable if the Header Type is <code>0x0</code>. (Figure 2)
{| {{wikitable}}
|-
Line 234:
|}
 
The following field descriptions apply if the Header Type is <code>0x0</code>:
 
* ''CardBus CIS Pointer:'' Points to the Card Information Structure and is used by devices that share silicon between CardBus and PCI.
 
* ''Interrupt Line:'' Specifies which input of the system interrupt controllers the device's interrupt pin is connected to and is implemented by any device that makes use of an interrupt pin. For the x86 architecture this register corresponds to the PIC IRQ numbers 0-15 (and not I/O APIC IRQ numbers) and a value of <code>0xFF</code> defines no connection.
 
* ''Interrupt Pin:'' Specifies which interrupt pin the device uses. Where a value of <code>0x1</code> is INTA#, <code>0x2</code> is INTB#, <code>0x3</code> is INTC#, <code>0x4</code> is INTD#, and <code>0x0</code> means the device does not use an interrupt pin.
 
* ''Max Latency:'' A read-only register that specifies how often the device needs access to the PCI bus (in 1/4 microsecond units).
Line 250:
==== Header Type 0x1 (PCI-to-PCI bridge) ====
 
This table is applicable if the Header Type is <code>0x1</code> (PCI-to-PCI bridge) (Figure 3)
 
{| {{wikitable}}
Line 348:
 
* ''MF'' - If MF = 1 Then this device has multiple functions.
* ''Header Type'' - <code>0x0</code> Standard Header - <code>0x1</code> PCI-to-PCI Bridge - <code>0x2</code> CardBus Bridge
 
===== BIST Register =====
Line 367:
==== Header Type 0x2 (PCI-to-CardBus bridge) ====
 
This table is applicable if the Header Type is <code>0x2</code> (PCI-to-CardBus bridge)
 
{| {{wikitable}}
Line 523:
* ''Received Target Abort'' - This bit will be set to 1, by a master device, whenever its transaction is terminated with Target-Abort.
* ''Signalled Target Abort'' - This bit will be set to 1 whenever a target device terminates a transaction with Target-Abort.
* ''DEVSEL Timing'' - Read only bits that represent the slowest time that a device will assert DEVSEL# for any bus command except Configuration Space read and writes. Where a value of 0x00<code>0x0</code> represents fast timing, a value of 0x01<code>0x1</code> represents medium timing, and a value of 0x02<code>0x2</code> represents slow timing.
* ''Master Data Parity Error'' - This bit is only set when the following conditions are met. The bus agent asserted PERR# on a read or observed an assertion of PERR# on a write, the agent setting the bit acted as the bus master for the operation in which the error occurred, and bit 6 of the Command register (Parity Error Response bit) is set to 1.
* ''Fast Back-to-Back Capable'' - If set to 1 the device can accept fast back-to-back transactions that are not from the same agent; otherwise, transactions can only be accepted from the same agent.
* ''Bit 6'' - As of revision 3.0 of the PCI Local Bus specification this bit is reserved. In revision 2.1 of the specification this bit was used to indicate whether or not a device supported User Definable Features.
* ''66 MHz Capable'' - If set to 1 the device is capable of running at 66 MHz; otherwise, the device runs at 33 MHz.
* ''Capabilities List'' - If set to 1 the device implements the pointer for a New Capabilities Linked list at offset <code>0x34</code>; otherwise, the linked list is not available.
* ''Interrupt Status'' - Represents the state of the device's INTx# signal. If set to 1 and bit 10 of the Command register (Interrupt Disable bit) is set to 0 the signal will be asserted; otherwise, the signal will be ignored.
 
Line 540:
|+Memory Space BAR Layout
|-
! Bits 31 - 4
! Bit 3
! Bits 2 - 1
! Bit 0
|-
| 16-Byte Aligned Base Address
Line 554:
|+I/O Space BAR Layout
|-
!31 -Bits 31-2
! Bit 1
! Bit 0
|-
| 4-Byte Aligned Base Address
Line 563:
|}
 
The Type field of the Memory Space BAR Layout specifies the size of the base register and where in memory it can be mapped. If it has a value of <code>0x0</code> then the base register is 32-bits wide and can be mapped anywhere in the 32-bit Memory Space. A value of <code>0x2</code> means the base register is 64-bits wide and can be mapped anywhere in the 64-bit Memory Space (A 64-bit base address register consumes 2 of the base address registers available). A value of <code>0x1</code> is reserved as of revision 3.0 of the PCI Local Bus Specification. In earlier versions it was used to support memory space below 1MB (16-bit wide base register that can be mapped anywhere in the 16-bit Memory Space).
 
When you want to retrieve the actual base address of a BAR, be sure to mask the lower bits. For 16-bit Memory Space BARs, you calculate <code>(BAR[x] & 0xFFF0)</code>. For 32-bit Memory Space BARs, you calculate <code>(BAR[x] & 0xFFFFFFF0)</code>. For 64-bit Memory Space BARs, you calculate <code>((BAR[x] & 0xFFFFFFF0) + ((BAR[x + 1] & 0xFFFFFFFF) << 32))</code> For I/O Space BARs, you calculate <code>(BAR[x] & 0xFFFFFFFC)</code>.
Line 1,071:
And this is just the beginning: After allocating bus numbers, you need to allocate MMIO, it would be trivial if it wasn't for the fact that PCI has 3 areas the kernel manages: IO, Prefetch and Memory.
 
A bridge can manage multiple buses, but that means it spans all the memory of these buses, if device 1 is behind bridge 2, which is behind bridge 1, then bridge 2 will contain the memory area of device 1 + any other device's areas, supposing IO is 4M, Memory is 16M and Prefetch is 5MB (supposing there are 3 devices in bridge's 2 bus), bridge 2 would contain those, take in reference table for Header type <code>0x1</code>. However, bridge 1 will contain the areas of bridge 2 + any other devices in bridge's 1 bus.
 
Once all memory areas are allocated, the devices can be used. Note that PCI-to-PCI bridges also have BAR's.
Line 1,095:
=== Enabling MSI ===
First, check that the device has a pointer to the capabilities list (status register bit 4 set to 1).
Then, traverse the capabilities list. The low 8 bits of a capability register are the ID - <code>0x5</code> for MSI. The next 8 bits are the offset (in [[#Configuration Space|PCI Configuration Space]]) of the next capability.
 
The MSI capability is as follows:
Line 1,209:
Unlike MSI, MSI-X supports 2048 interrupts. This is achieved by maintaining a table of interrupts in the PCI device's address space. The wording of the PCI 3.0 specification indicates that this ''must'' be via a Memory BAR.
 
'''BIR''' specifies which BAR is used for the Message Table. This may be a 64-bit BAR, and is zero-indexed (so BIR=0, BAR0, offset <code>0x10</code> into the header).
 
'''Table Offset''' is an offset into that BAR where the Message Table lives. Note that it is 8-byte aligned - so simply mask BIR.
Line 1,266:
 
== Multi-function Devices ==
Multi-function devices behave in the same manner as normal PCI devices. The easiest way to detect a multi-function device is bit 7 of the header type field. If it is set (value = <code>0x80</code>), the device is multi-function -- else it is not. Make sure you mask this bit when you determine header type. To detect the number of functions you need to scan the PCI configuration space for every function - unused functions have vendor <code>0xFFFF</code>. Device IDs and Class codes vary between functions. Functions are not necessarily in order - you can have function <code>0x0</code>, <code>0x1</code> and <code>0x7</code> in use.
 
== Disclaimer ==
73

edits