Design Feature: May 9, 1996
When CardBus cards interface to a PCI bus via a PCI-to-CardBus bridge 
(Figure 1), the system-configuration process includes configuring the bridge as well as the cards themselves. Configuration software detects and configures the CardBus cards during power-up, and this software depends on the revision levels of the system firmware, the operating system, and the PCMCIA Card Services (CS) and Socket Services (SS) software. If the software in a system has not been upgraded to support CardBus, it won't configure either the CardBus bridge or the PC Cards.
The first configuration step, that of configuring the PCI-to-CardBus bridge, occurs in essentially the same way as the configuration of any other device on the PCI bus. PCI configuration software scans the PCI bus, detecting the devices that are present and configuring them. The software configures the bridge, preparing it for recognition of PC Card installation and for notifying the PCMCIA software that a user has inserted a PC Card into a socket. This first step involves the typical plug-and-play configuration that applies to any PCI device, except that a PCI-to-CardBus bridge has a unique configuration-register layout.
The second step, that of configuring CardBus cards, involves the same PCMCIA software used for 16-bit cards. This software, which comprises the CardBus client driver, CS, and SS, applies power to the card and configures the PC Card and the bridge's socket interface. It also handles hot-insertion capability; when you insert a PC Card into a socket, the CardBus bridge detects the card's presence and generates an interrupt to notify the software.
For CardBus cards, as with 16-bit PC Cards, a client driver, or an enabler, must exist for each card function. Without an enabler, the software does not configure the card functions, and the functions remain disabled. The same software elements and flow apply to 16-bit PC Cards and CardBus cards The software elements (enablers, CS, and SS) function in the same manner in a CardBus environment as they do in a 16-bit PC Card environment. They include a few additional and modified services to support CardBus implementations, but the fundamental processes remain the same.
All CardBus cards and PCI devices must implement a base set of configuration registers, which the PCI and CardBus specifications define. In addition, the specifications set aside additional configuration locations for implementing device-specific configuration registers. Configuration software accesses these registers to determine the configuration requirements of a given device and to allocate selected system resources. Use of the configuration address space differs between PCI and CardBus devices, however.
In a PCI device, configuration registers contain encoded configuration information that defines the resource requirements of the device. For example, PCI configuration software knows how to probe the PCI base-address registers (BARs) to determine address-space requirements. These same registers configure the device's address decoders, so that the device responds to the specified address range or ranges.
CardBus devices use PCMCIA's card-information structure (CIS), which specifies the PC Card's resource requirements. PCMCIA configuration software must first access a PC configuration register (the CardBus CIS pointer register) to obtain the start address of the CIS. The software then scans the CIS to determine the device's resource requirements. For example, the BAR tuples within the CIS define the device's address-space requirements. As with PCI devices, the BARs, which are located within the configuration-address space, configure the address decoders.
The differences between CardBus and PCI configuration stem from the hot-insertion ability of the CardBus cards. CardBus configuration software must always be able to detect the insertion of a CardBus card and to properly configure it. To complicate matters, the CardBus software must also be able to detect card removal and to release the socket-interface configuration.
Each CardBus card and PCI device can internally implement from one to eight functions, or logical devices. For example, a multifunction CardBus card could incorporate an Ethernet LAN controller, a SCSI interface, and a fax/modem. Each of these functions requires its own set of configuration registers. The PCI and CardBus specifications allocate each function 256 bytes (64 32-bit "doublewords") of configuration address space into which its configuration registers are mapped. Note that CardBus bridges have one specific configuration register layout, and CardBus cards have another layout.
Accessing configuration space
Intel x86 and PowerPC 60x processors possess the ability to address two distinct address spaces: I/O and memory. CardBus and PCI-bus masters use I/O and memory addressing to access CardBus and PCI devices. A third address space, configuration, allows access of a PCI device's configuration registers. To configure a PCI device for proper operation in a host system, the device's configuration registers must be accessed at startup time. In the case of CardBus cards, however, configuration may occur after the system has started. This ability allows the insertion of a CardBus card into a socket at any time.
CardBus-memory space, I/O space, and configuration-address space are mapped within the respective PCI address space. PCI configuration space comprises separate configuration address spaces for each function in a physical device, such as a chip or card. The PCI specification defines the format and use of the configuration header. The specification currently defines two header formats: header-type zero for all devices except PCI-to-PCI bridges and header-type one for PCI-to-PCI bridges. A third format, header type two, has informal status for CardBus bridges (see Reference 1); it has not been officially adopted by the PCI Special Interest Group (SIG).
The system designer must provide some mechanism for converting host-processor-initiated predefined memory or I/O accesses into configuration accesses on the PCI bus and CardBus. Access to configuration address space occurs via configuration read and write commands.
The configuration sequence
To enable access to PC Cards, a system must configure both the cards themselves and the CardBus bridge. The configuration process involves several major steps:
The first step, socket-interface initialization, entails configuring and en-abling the socket interface for card insertion. PCI configuration software configures the socket-status registers, which reflect the status of the socket interface. The software also sets up the socket's status-change interrupt, which notifies PCMCIA software of socket-interface changes, such as card insertion. The socket-status registers reflect the cause of the interrupt, such as a PC Card that the user has inserted into a socket. The software must map these registers into the PCI address space so that PCMCIA software can access them.
The second configuration step, PC Card detection, occurs when a user inserts a PC Card into a socket, and the bridge generates a status-change interrupt. This interrupt invokes the PCMCIA software that performs reads from the socket-status registers to determine the cause of the interruptÑin this case, card insertion.
In the third configuration step, PCMCIA software configures a PC Card after reading the card's configuration registers to determine what resources the card needs. PCMCIA software must program the PC Card's configuration registers to assign the address space and function-specific interrupt that the PC Card requires. Because PC Cards are hot-pluggable, and because PCI configuration software configures devices only during a power-up sequence, PCI configuration software cannot be responsible for this portion of the configuration.
The fourth step configures the bridge to filter transactions and to steer PC Card interrupts. PCMCIA configuration software configures the bridge's socket interface so that it forwards transactions to and from a CardBus card or a PC Card when the bridge detects transactions in the PC Card's address range or when a CardBus card initiates a transaction. The software must also configure the bridge to steer the function-specific interrupt pin to the selected IRQ line. This bridge configuration is implementation-specific.
Socket interface initialization
When the system powers up, all PCI devices (including the CardBus bridges) are disabled and cannot be accessed except for their configuration address space. The PCI-configuration software is responsible for scanning the PCI bus to detect the presence of all PCI devices and configure them. The software accomplishes this function by accessing the configuration registers in the devices on the PCI bus. For the software to access the registers, the system must provide some mechanism for generating access to PCI configuration address space.
A CardBus bridge provides the interface between a PC Card socket and the PCI bus. Each socket that a CardBus bridge supports requires a separate interface, because each socket uses point-to-point signaling (that is, there is no direct busing between sockets). Consequently, each socket interface is treated as a separate function within the CardBus bridge. When PCI configuration software scans the PCI bus, it detects a separate function for each socket that a given CardBus bridge supports.
When the PCI configuration software detects a CardBus bridge, it determines the amount of memory and/or I/O space that the bridge requires and determines if the bridge uses interrupts to report socket-status changes, such as card insertion or removal. The program then configures the bridge by programming its address decoders to respond to memory or I/O address ranges that are guaranteed not to conflict with those ranges assigned to other system devices. The program also specifies to which IRQ line the system routes the bridge's PCI interrupt request.
The CardBus bridge is partially configured by PCI configuration software to enable its PC Card socket interfaces. This configuration entails mapping and enabling the bridge's socket-status registers and routing the CardBus bridge socket-status interrupt. PCI configuration software may also allocate a CardBus number, which can provide later access to the CardBus configuration registers. At this point, the software can't completely configure the CardBus card and its socket interface, because a PC Card may not be present during power-up. Later, when the PCMCIA software detects that a user has inserted a PC Card into the socket, it completes bridge configuration and configures and enables the card.
PC Card detection
Once the socket interface is initialized, the bridge's socket-status registers reflect whether a card is inserted into a socket. If a PC Card is present when the system powers up, PCMCIA software can read the socket-status registers to detect the card's presence. If, however, no PC Card is present during the power-up process, then PCMCIA software awaits notification of card insertion via a status-change interrupt that the CardBus bridge generates.
PCMCIA-configuration software configures a PC Card and sets up the bridge's socket interface. When PCMCIA software installs, it checks for the presence of a CardBus bridge. If the bridge is present, the software then checks the bridge's socket-status registers, which the PCI configuration software previously configured, to determine if a PC Card is present in any of the sockets. If a PC Card is present, the software proceeds to interrogate the card to determine its resource requirements and then performs the card configuration. If no PC Cards are present, PCMCIA software remains resident in memory and awaits the insertion of a PC Card.
Configuring a CardBus card involves four steps:
PCMCIA software consists of the CardBus card's client driver, CS, and SS. The detection of a PC Card via CS and SS results in the notification of the PC Card's client driver. The client driver is ultimately responsible for configuring the card.
A client driver parses a PC Card's CIS to determine whether it should attempt to configure the card. When a client driver requests access to the CIS, CS must first access the CardBus card's configuration address space to obtain the location of the CIS within the card. The client driver then traverses the card's tuple list to determine if it should attempt to configure the card and, if so, must determine the resources required by the card.
Upon determining the required resources, the client driver requests that each resource be allocated to its card via CS. If CS determines that the requested resources are available, it allocates the resources to the client driver. The client driver, after obtaining the resources that the card needs, requests that CS perform the configuration based on the resources previously acquired. In response, CS and SS write to the CardBus card's configuration registers to configure the address decoders. CardBus cards contain PCI-like configuration registers that are accessible via PCI configuration read and write transactions.
In addition to configuring the CardBus card, CS and SS must also configure the CardBus bridge so that it can correctly forward transactions to and from the card. Note that a CardBus card may contain as many as eight individual functions. As a result, the configuration process repeats for each function in the card.
The final stage in configuring the CardBus bridge involves setting up the bridge so that it can properly forward transactions between the CardBus card and the PCI bus. The CardBus bridge contains memory and I/O address registers that the software must configure so that the bridge knows the range of addresses that have been mapped to the CardBus card functions. The software must also configure the bridge so that it steers interrupts from the CardBus functions to the assigned system IRQ line.
Author's biography
Tom Shanley is the president of MindShare Inc. He is the coauthor of the PCI System Architecture from MindShare's PC System Architecture book series.
Reference
(Figure 2).
Figure 3 illustrates the basic format of a PCI or CardBus function's configuration space. The first 16 doublewords of a device's space are referred to as the device's "configuration header space."
| design features | out in front | design ideas | columnist | departments | products |