CardBus Controllers and Windows
Updated: December 4, 2001
This article describes compatibility issues related to CardBus controllers for Microsoft Windows operating systems, including ACPI and BIOS support issues for CardBus, how CardBus controllers are configured by Windows 2000 and Windows XP, and hardware design issues that should be considered by manufacturers.
The information in this article applies to Windows 95, Windows 98, Windows Millennium Edition (Windows Me), Windows 2000, and Windows XP.
On This Page
CardBus host controllers are a type of PCI-to-PCI bridge. A PCI-to-PCI bridge connects two PCI buses, increasing expansion capability beyond the limitations of a single bus. PCI-to-PCI bridges are defined as header type 1 in the PCI Local Bus Specification.
A CardBus controller extends a PCI bus with a CardBus slot for insertion of a 32-bit CardBus card or a legacy 16-bit PCMCIA Revision 2 card, sometimes called an "R2 card." CardBus controllers are defined as header type 2 in the PCI Local Bus Specification.
Because CardBus host controllers are a type of PCI-to-PCI bridge, they are enumerated and configured by the PCI driver in Windows, as with other PCI bus bridges. However, unlike PCI bridges, when an R2 card is inserted in a CardBus slot, Pcmcia.sys is responsible for enumeration and configuration.
This article describes ACPI and BIOS support issues for CardBus, how Windows 2000 and Windows XP configure CardBus controllers, and hardware design issues that should be considered by CardBus controller manufacturers, CardBus card manufacturers, and vendors who build systems that include CardBus.
See the resources listed at the end of this article for information about common issues related to PCI-to-PCI bridges and CardBus controllers.
BIOS Support for Windows Compatibility
This section describes the BIOS support required for Windows compatibility in systems that include CardBus controllers.
Setting Up a CardBus Controller. The BIOS must set up the CardBus controller as follows:
Interrupt Routing. The BIOS must be at least PCI 2.1 compliant and must support the $PIR Interrupt Routing table for PNP BIOS machines. (If the BIOS does not support the $PIR Interrupt Routing table, the operating system can be configured explicitly to utilize the BIOS function GetIRQRouting to set the AX register to 0xB10E, but this might not work on some machines.)
For ACPI machines, the BIOS must support interrupt routing by way of the _PRT object as described in "Supporting CardBus Controllers Under ACPI" later in this article.
Supporting CardBus Controllers under ACPI
For ACPI-aware versions of Windows, each CardBus controller must have an entry that describes the controllers PCI interrupt in the _PRT object in the ACPI namespace.
Each CardBus controller must also have an _INI control method. Windows calls the _INI control method to configure the CardBus controller in CardBus mode.
Assuming that the controller is initialized as described in "BIOS Support for Windows Compatibility" later in this article, the _INI control method should perform the following steps:
For information about _PRT and _INI, see the Advanced Configuration and Power Interface Specification, version 1.0b or later.
How CardBus Controllers Are Configured when a Windows 2000 or Windows XP System is Started
This section outlines the process of starting a Windows 2000 or Windows XP system and allocating resources to CardBus controllers.
The BIOS detects and configures bridges. After the system is powered on, the BIOS detects devices in the system and allocates I/O and memory windows as determined by the BIOS developer. The BIOS will detect and configure more than one level of bridge and controller. If configuration code in the BIOS is implemented correctly, all bridges, controllers, and child devices receive the resources required to start.
CardBus controllers are set to PC Card I/O Card (PCIC) mode by default in the hardware. The system BIOS must leave CardBus controllers in PCIC mode before the BIOS transfers control to the operating system so that the operating system will be able to determine which ISA interrupts are attached to the CardBus controller.
When the BIOS code completes, all controllers in the system should still be in PCIC mode and should have sufficient memory and I/O windows assigned. However, a controller might be unconfigured for one of the following reasons:
NTDetect scans for ISA interrupts. After the BIOS code completes, NTDetect loads and runs a scan to determine which ISA interrupts are attached to the CardBus controller. The ISA interrupt scan can be run only on CardBus controllers that are in PCIC mode. Mobile PC users will have the best experience with the widest variety of R2 cards if mobile PC vendors set CardBus controllers to PCIC mode so the ISA interrupt scan can succeed.
The ISA interrupt scan is necessary to prevent interrupt storms that can be caused by R2 cards that do not support PCI interrupts, or that support PCI interrupts incorrectly. In a given system, a CardBus controller might not be wired to an ISA interrupt, or it might be wired to an ISA interrupt in an unexpected way, or it might be wired incorrectly. Simply routing interrupts to PCI do not solve these problems.
NTDetect scans interrupts wired to the CardBus controller in an attempt to identify an ISA interrupt that can be used to support R2 cards inserted in the CardBus slot:
The operating system calls the _INI method associated with each CardBus controller. After the NTDetect ISA interrupt scan completes, the ACPI driver loads. The CardBus controller no longer needs to be in PCIC mode, so the operating system calls the controllers _INI method, which places the CardBus controller in CardBus mode and performs the additional steps described in "Supporting CardBus Controllers under ACPI"> earlier in this article.
The operating system enumerates devices and assigns default resources to unconfigured controllers. The operating system enumerates devices on PCI buses that include bridges as follows:
See the resources listed at the end of this article for information about the implications of static memory and I/O windows for PCI-to-PCI bridges and CardBus controllers.
BIOS Report for Plug and Play Enumeration
The BIOS enumeration information in this section applies only to legacy (non-ACPI) systems. ACPI defines the _INI method for switching a CardBus controller from PCIC mode, which is not supported in ACPI-aware operating systems, to CardBus mode, which is supported in ACPI-aware operating systems.
During Plug and Play BIOS enumeration on legacy (non-ACPI) systems, the BIOS should report the CardBus controller as *pnp0e03 with a compatible ID of *pnp0e00 and the I/O resource of two ports (for example, 0x3E0 0x3E1).
Windows 95. In response to the compatible ID of *pnp0e00, Windows 95 will load Socketsv.vxd (for generic Intel PCIC-compatible controllers) and everything will work with the BIOS initialization. The Windows 95 PCI enumerator (Pci.vxd) does not recognize the CardBus controller's PCI header (type 2), so it would not report the CardBus controller.
Windows 95 OSR 2, Windows 98, and Windows Me. When the BIOS enumerator detects *pnp0e03, it hides the device and calls the BIOS to disable it. When the BIOS receives the disable call for *pnp0e03, it does one of the following:
Windows 95 OSR 2 and Windows 98 can call the BIOS more than once to disable *pnp0e03 (for example, whenever the operating system re-enumerates the hardware). The BIOS should perform the steps described in this section only if the controller is still in legacy PCIC mode.
PCI Configuration Space Considerations for CardBus Controllers
CardBus designers must not share writable PCI Configuration Space bits in a multifunction PCI device. This is a requirement for the "Designed for Microsoft Windows" logo program:
For more information about design requirements for CardBus, see Microsoft Windows Logo Program System and Device Requirements, Version 2.0, available at the Windows Logo Program site.
Special Hardware Design Considerations for CardBus Host Controllers
This section describes special hardware design considerations for CardBus host controllers.
ExCA and CardBus Socket registers. For backward compatibility with 16-bit Exchangeable Card Architecture (ExCA) standard, the CardBus (Yenta) specification introduces ambiguity in that there are two interfaces through which to program the controller: ExCA registers and CardBus Socket registers. To resolve this ambiguity and to support both legacy 16-bit software and CardBus software, these two interfaces must be linked so that the controllers state and the cards state are kept consistent, regardless of which interface is used.
For Windows compatibility, the controller must allow programming from either interface, and the programming from one side should be reflected automatically to the other side (for example, the ExCA Registers offset 0x801 0x805). This includes client-side caching (CSC) interrupt control, power control, controller status, and card status.
Power protection. Another special consideration for CardBus controllers is the power protection feature. The Yenta specification requires the controller to do power-protection checking before applying voltages to an inserted card. This feature must be implemented flexibly in order to maintain backward compatibility. Specifically, power protection should be applied only to protect the card from a higher voltage than its VS1/VS2 pins specify; applying a lower voltage should be allowed.
In addition, for R2 cards only, there should be a way to override power protection, because some R2 cards specify higher voltages in their configuration tuples than is reported on their VS1/VS2 pins.
Compatibility with standard Windows drivers. CardBus Host Controller initialization also has special considerations for compatibility with standard Windows drivers. Specifically, CardBus drivers for Windows expect the hardware to provide the following.
Other Special Considerations:
Call to Action