PCI IRQ Routing Table Specification
Microsoft Corporation, Version 1.0, February 27, 1996
Important: This information applies only to legacy PCs running the Microsoft Windows 95 OSR 2 and Windows 98 operating systems. ACPI-based systems must follow the implementation defined in the ACPI specification. For information, see the OnNow home page.
On This Page
|
Purpose
One drawback of Microsoft Windows 95 is its inability to dynamically route PCI interrupts to interrupt requests (IRQs). The BIOS must assign IRQs to all PCI devices during power-on self-test (POST), and once chosen, the interrupts cannot be moved.
In order to support assignment and reassignment of PCI IRQs, Windows 98 will need to know how the system board has wired each PCI slot's interrupt pins to the PCI Interrupt Router's interrupt pins. This information cannot be detected without special-purpose hardware, so Windows must obtain it from another source. This document describes how Windows 98 will use the BIOS to determine this information.
Assumptions
Each PCI system board consists of one or more slots and a PCI Interrupt Router. Each slot has four interrupt pins, known as INTA#, INTB#, INTC#, and INTD#. The PCI Interrupt Router has several interrupt pins, known as PIRQ1#, PIRQ2#, PIRQ3#, ... PIRQn#. There is no PIRQ0#. The INTn# pins for each slot may be wire OR'd with other INTn# pins from the same or other slots, and these groups of pins may also be connected to a PIRQn# pin on the Interrupt Router.
The actual PIRQ value assigned to each interrupt pin on each Interrupt Router is assigned by the chip-set vendor. Microsoft will work closely with chip-set vendors to assign appropriate PIRQ values for existing and future PCI chip sets.
Overview
The PCI IRQ routing information will be stored in a table in BIOS ROM. The table will be stored on a 16-byte boundary and will contain a signature and checksum for detection and validation purposes. The table will:
| • | Identify the location of the PCI Interrupt Router. |
| • | Identify a compatible PCI Interrupt Router. |
| • | Identify the IRQs devoted exclusively to PCI usage. |
| • | Show how each slot's interrupt pins are wire OR'd together into links. |
| • | Indicate which link is connected to each of the Interrupt Router's interrupt pins. |
This data is similar to the data available via the PCI BIOS 2.1 function GetIRQRoutingTable, but it contains the following additional features:
| • | The link numbers are standardized on a per chip set basis |
| • | The PCI Interrupt Router is identified by Bus and DevFunc |
| • | There is a field for a compatible Interrupt Router |
| • | The table is in ROM and does not rely on the BIOS for tricky 32-bit memory copying code |
Detection
The PCI IRQ Routing Table can be detected by searching the system memory from F0000h to FFFFFh at every 16-byte boundary for the PCI IRQ routing signature ("$PIR"). Once the signature is found, the following items need to be validated:
| • | Version. Must be 1.0. |
| • | Table size. Must be larger than 32 and must be a multiple of 16. |
| • | Checksum. The entire structure's checksum must be 0. |
Description
The PCI IRQ Routing Table has the following structure:
| Byte Offset | Size in Bytes | Name |
0 | 4 | Signature |
4 | 2 | Version |
6 | 2 | Table Size |
8 | 1 | PCI Interrupt Router's Bus |
9 | 1 | PCI Interrupt Router's DevFunc |
10 | 2 | PCI Exclusive IRQs |
12 | 4 | Compatible PCI Interrupt Router |
16 | 4 | Miniport Data |
20 | 11 | Reserved (Zero) |
31 | 1 | Checksum |
32 | 16 | First Slot Entry |
48 | 16 | Second Slot Entry |
(N + 1) * 16 | 16 | Nth Slot Entry |
Signature: The signature for this table is the ASCII string "$PIR". Byte 0 is a 24h, byte 1 a 50h, byte 2 is a 49h, and byte 3 is 52h.
Version: The version consists of a Minor version byte followed by a Major version byte. Since this specification describes the Version 1.0 table format, byte 4 of the table is a 00h and byte 5 is a 01h.
Table Size:This is a 16-bit value that holds the size of the PCI IRQ Routing Table in bytes. If there were five slot entries in the table, this value would be 32 + (5 * 16) = 112.
PCI Interrupt Router's Bus This contains the bus number of the PCI Interrupt Router device.
PCI Interrupt Router's DevFunc This contains the Device and Function number of the PCI Interrupt Router device. The Device is in the upper five bits, the Function in the lower three.
PCI Exclusive IRQs: This is an IRQ bitmap that indicates which IRQs are devoted exclusively for PCI usage. For example, if IRQ11 is devoted exclusively to PCI and cannot be assigned to an ISA device, then bit 11 of this 16-bit field should be set to 1. If there are no IRQs devoted exclusively to PCI, then this value should be 0.
Compatible PCI Interrupt Router: This field contains the Vendor ID (bytes 10 and 11) and Device ID (byes 12 and 13) of a compatible PCI Interrupt Router, or zero (0) if there is none. A compatible PCI Interrupt Router is one that uses the same method for mapping PIRQn# links to IRQs, and uses the same method for controlling the edge/level triggering of IRQs. This field allows an operating system to load an existing IRQ driver on a new PCI chip set without updating any drivers and without any user interaction.
Miniport Data: This DWORD is passed directly to the IRQ Miniport's Initialize() function. If an IRQ Miniport does not need any additional information, this field should be set to zero (0).
Reserved: These bytes are reserved for future use and must be set to zero (0).
Checksum:This byte should be set such that the sum of all of the bytes in the PCI IRQ Routing Table, including the checksum, and all of the slot entries, modulo 256, is zero.
Slot Entry:
Each slot entry is 16-bytes long and describes how a slot's PCI
interrupt pins are wire OR'd to other slot interrupt pins and
to the chip set's IRQ pins. Each entry has the following format:
| Byte Offset | Size in Bytes | Name |
0 | Byte | PCI Bus Number |
1 | Byte | PCI Device Number (in upper five bits) |
2 | Byte | Link Value for INTA# |
3 | Word | IRQ Bitmap for INTA# |
5 | Byte | Link Value for INTB# |
6 | Word | IRQ Bitmap for INTB# |
8 | Byte | Link Value for INTC# |
9 | Word | IRQ Bitmap for INTC# |
11 | Byte | Link Value for INTD# |
12 | Word | IRQ Bitmap for INTD# |
14 | Byte | Slot Number |
15 | Byte | Reserved |
PCI Bus Number: The bus number of the slot.
PCI Device Number:The device number of the slot.
Link Value for INTn#:A value of zero means this interrupt pin is not connected to any other interrupt pins and is not connected to any of the Interrupt Router's interrupt pins.
The non-zero link values are specific to a chip set and decided by the chip-set vendor. Here is a suggested implementation:
A value of 1 through the number of interrupt pins on the Interrupt Router means the pin is connected to that PIRQn# pin of the Interrupt Router.
| • | A value larger than the number of interrupt pins on the Interrupt Router means the pin is wire OR'd together with other slot interrupt pins, but the group is not connected to any PIRQn# pin on the Interrupt Router. |
| • | Other interpretations of the link values are possible. For instance, the link value may indicate which byte of Configuration Space to access for this link, or which I/O Port to access for the link. The specific interpretation of the link value is decided by the manufacturer of the Interrupt Router and is supported by the driver for that router. |
IRQ Bitmap for INTn#: This value shows which of the standard AT IRQs this PCI's interrupts can be routed to. This provides the routing options for one particular PCI interrupt pin. In this bitmap, bit 0 corresponds to IRQ0, bit 1 to IRQ1, and so on. A 1 bit in this bitmap indicates that routing is possible; a 0 bit indicates that no routing is possible.
This bitmap must be the same for all pins that have the same link number.
Slot Number:This value is used to communicate whether the table entry is for a system-board device or an add-in slot. For system-board devices, the slot number should be set to zero. For add-in slots, the slot number should be set to a value that corresponds with the physical placement of the slot on the system board. This provides a way to correlate physical slots with PCI device numbers.
Values (with the exception of zero) are OEM-specific. For end-user ease-of-use, slots in the system should be clearly labeled (such as solder mask, back panel, and so on).
It should be noted that the slot entries of the PCI IRQ Routing Table are compatible with the PCI IRQ Routing Options Table of the PCI BIOS Specification, Revision 2.1. This makes it possible to support both the PCI IRQ Routing Table and the PCI BIOS specification with only one table in ROM.
Notes
Moving the Interrupt Routing Table from a PCI BIOS call into a ROM table has a couple of side effects. Since the table is in ROM, it is no longer dynamic. There are a couple of scenarios related to bridges and docking where a dynamic table is a disadvantage.
Every time a PCI device, slot, or Interrupt Router is described by location in the IRQ Routing Table, it includes the device's bus. Unfortunately, the PCI bus number of a device behind a PCI-to-PCI bridge can change without even calling the PCI BIOS. Since the IRQ Routing Table is in ROM, the table cannot be updated on the fly to reflect new bus numbers.
PCI dockable portables have the ability to add new PCI devices and slots while the system is running. Since the IRQ Routing Table is in ROM, the table cannot be updated on the fly to describe new devices.
How each of these problems gets addressed depends to a large extent on the design of the PCI bus architecture of the computer. Here are some examples:
Single PCI Bus Desktop System with PCI-to-PCI Bridge Add-in Card
The routing table for a single bus desktop systemwith a PCI-to-PCI bridge add-in card does not need to include the IRQ routing for devices behind the add-in card. The PCI-to-PCI bridge specification already describes how to route the INTn# lines from the bridge's children to the bridge's INTn# lines. The IRQ Routing Table in the BIOS only needs to describe the routing of the bridge's INTn# lines to the system's PCI Interrupt Router. There is no problem supporting such systems with an IRQ Routing Table in ROM.
Dockable Portable Docking Through a TransparentPCI-to-PCI Bridge
Transparent PCI-to-PCI bridges do not support primary, secondary, or subordinate bus numbers. The devices behind the bridge have the same PCI bus number as the transparent bridge itself. This architecture is commonly seen on dockable PCI portables, where the docking station devices appear behind the transparent bridge.
Since the bridge is invisible to the PCI bus hierarchy, the operating system does not have any idea how the IRQs should be routed through the bridge. In this case, the IRQ Routing Table must report the IRQ routing for all devices behind the PCI-to-PCI bridge, even when the dock is not currently present.
However, this could prove to be a problem if the portable can dock to multiple docking stations, each with different routings. Manufacturers who make such docking hardware will have to ensure that the IRQ Routing Table in ROM is the union of all known and planned docks for the portable, and that two docks do not use different routing for the same Dev.
For example, if one dock routes Dev 9 Pin A to Link 2, and another dock routes Dev 9 Pin A to Link 3, then that system cannot be supported by this specification.
Dockable Portable Docking Through a PCI-to-PCI Bridgeto Separate PCI Bus
Other portables support docking via a PCI-to-PCI bridge (either positive or subtractive decode) that supports the primary/secondary/subordinate bus numbers. Devices behind the PCI-to-PCI bridge have their own PCI bus number. The simplest approach to supporting these systems is to follow the PCI-to-PCI bridge specification for routing the bridge's secondary bus INTn# pins to the bridge's primary bus INTn# pins.
If a vendor implements IRQ routing through a non-standard routing mechanism, the best solution is for the PCI BIOS to configure the PCI-to-PCI bridge to the same bus number on each boot, and then to put the bus's devices and slots into the IRQ Routing Table. An application or the operating system could change the bus numbers at a later time, but at least the ROM table was accurate on bootup.
This problem is much more difficult to solve when the portable boots up undocked and then later warm or hot docks. The BIOS should not assign any bus numbers when warm or hot docking (that is the responsibility of the operating system). Yet, the BIOS has no idea what bus numbers the operating system will use when it docks, so it has no idea what bus numbers to use in the IRQ Routing Table.
IRQ routing support for such PCI systems will likely be poor or non-existent. It is strongly recommended that vendors follow the standard PCI-to-PCI bridge IRQ routing on internal or proprietary PCI-to-PCI bridges.
Dual PCI ("Peer") Bus System
Some systems have two PCI buses hanging off the CPU. Since one bus is not sitting behind a PCI-to-PCI bridge, there is no standard routing mechanism for devices behind the non-zero PCI bus. Devices on both buses must appear in the IRQ Routing Table. Since the top level PCI bus numbers rarely change (and are often built directly into the hardware), it should be easy to support such systems with an IRQ Routing Table in ROM.
See also PIIXA and IRQ Routing for OSR 2, which describes how to get PCI IRQ routing to work with the PIIXA chip set.