PCI: Difference between revisions

The following code segment illustrates the use of configuration mechanism #1 to read 16-bit fields from configuration space. Note that this segment, the outl(port, value) and inl(port) functions refer to the OUTL and INL Pentium assembly language instructions.

 

uint16_t pciConfigReadWord(uint8_t bus, uint8_t slot, uint8_t func, uint8_t offset) {

uint32_t address;

return tmp;

}

 

When a configuration access attempts to select a device that does not exist, the host bridge will complete the access without error, dropping all data on writes and returning all ones on reads. The following code segment illustrates the read of a non-existent device.

 

uint16_t pciCheckVendor(uint8_t bus, uint8_t slot) {

uint16_t vendor, device;

} return (vendor);

}

 

=== Configuration Space Access Mechanism #2 ===

 

The following field descriptions are common to all Header Types:

 

* ''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.

* ''Class Code:'' A read-only register that specifies the type of function the device performs.

* ''Subclass:'' A read-only register that specifies the specific function the device performs.

* ''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).

* ''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.

 

==== Header Type 0x0 ====

| colspan="4" | 16-bit PC Card legacy mode base address

|}

 

=== Base Address Registers ===

 

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>.

 

To determine the amount of address space needed by a PCI device, you must save the original value of the BAR, write a value of all 1's to the register, then read it back. The amount of memory can then be determined by masking the information bits, performing a bitwise NOT ('~' in C), and incrementing the value by 1. The original value of the BAR should then be restored. The BAR register is naturally aligned and as such you can only modify the bits that are set. For example, if a device utilizes 16 MB it will have BAR0 filled with 0xFF000000 (0x1000000 after decoding) and you can only modify the upper 8-bits. [https://web.archive.org/web/20150101180929/https://www.pcisig.com/reflector/msg05233.html]

For all 3 methods, you need to be able to check if a specific device on a specific bus is present and if it is multi-function or not. Pseudo-code might look like this:

 

void checkDevice(uint8_t bus, uint8_t device) {

uint8_t function = 0;

void checkFunction(uint8_t bus, uint8_t device, uint8_t function) {

}

 

Please note that if you don't check bit 7 of the header type and scan all functions, then some single-function devices will report details for "function 0" for every function.

For the brute force method, the remaining code is relatively simple. Pseudo-code might look like this:

 

void checkAllBuses(void) {

uint16_t bus;

}

}

 

For this method, there are 32 devices per bus and 256 buses, so you call "checkDevice()" 8192 times.

The first step for the recursive scan is to implement a function that scans one bus. Pseudo-code might look like this:

 

void checkBus(uint8_t bus) {

uint8_t device;

}

}

 

The next step is to add code in "checkFunction()" that detects if the function is a PCI to PCI bridge. If the device is a PCI to PCI bridge then you want to extract the "secondary bus number" from the bridge's configuration space and call "checkBus()" with the number of the bus on the other side of the bridge.

Pseudo-code might look like this:

 

void checkFunction(uint8_t bus, uint8_t device, uint8_t function) {

uint8_t baseClass;

}

}

 

The final step is to handle systems with multiple PCI host controllers correctly. Start by checking if the device at bus 0, device 0 is a multi-function device. If it's not a multi-function device, then there is only one PCI host controller and bus 0, device 0, function 0 will be the PCI host controller responsible for bus 0. If it's a multi-function device, then bus 0, device 0, function 0 will be the PCI host controller responsible for bus 0; bus 0, device 0, function 1 will be the PCI host controller responsible for bus 1, etc (up to the number of functions supported).

Pseudo-code might look like this:

 

void checkAllBuses(void) {

uint8_t function;

}

}

 

=== Recursive Scan With Bus Configuration ===

If you're using the old [[PIC]], your life is really easy. You have the ''Interrupt Line'' field of the header, which is read/write (you can change it's value!) and it says which interrupt will the PCI device fire when it needs attention.

 

 

The only problem is that the PCI pins correspond to an arbitrary I/O APIC pin. It's up to the programmer to find the mapping. How is that done? You must parse the [[MP]] Tables or the [[ACPI]] tables. The MP tables are easy, only they aren't supported on newer hardware. The ACPI tables, however, involve parsing AML, which is not an easy task. If one wants to take a shortcut, you can use [[ACPICA]].

=== Enabling MSI ===

First, check that the device has a pointer to the capabilities list (status register bit 4 set to 1).

 

The MSI capability is as follows:

 

The message address/data is architecture specific. On x86(-64), it is as follows:

uint64_t arch_msi_address(uint64_t *data, size_t vector, uint32_t processor, uint8_t edgetrigger, uint8_t deassert) {

*data = (vector & 0xFF) | (edgetrigger == 1 ? 0 : (1 << 15)) | (deassert == 1 ? 0 : (1 << 14));

return (0xFEE00000 | (processor << 12));

}

MSI interrupts seem to be invariably edge triggered high.

 

[[Category:Buses]]

[[Category:PCI]]

[[de:Peripheral_Component_Interconnect]]