CardBus Controllers and Windows
Updated: December 4, 2001
.gif)
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
.gif)
Introduction
BIOS Support for Windows Compatibility
Supporting CardBus Controllers under ACPI
How CardBus Controllers Are Configured when a Windows 2000 or Windows XP System is Started
BIOS Report for Plug and Play Enumeration
PCI Configuration Space Considerations for CardBus Controllers
Special Hardware Design Considerations for CardBus Host Controllers
Call to Action
Introduction
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:
Initialize the CardBus controller in Intel 82365-compatible mode and report it as device pnp0e03, Intel 82365-compatible CardBus controller.
Set the Command register (offset 0x04) to 0x07 (IOSpaceEnable, MemSpaceEnable, BusMasterEnable).
Set all memory and I/O windows (offset 0x1C 0x38)as required to allow child devices behind the controller to receiverequired resources, or rely on the operating system to set default memory and I/O windows.
See the resources listed at the end of this article for information about configuring memory and I/O windows.
Set LegacyBaseAddress (offset 0x44) to a legacy mode I/O base address (such as 0x3E0).
Set the RegisterBaseAddress (offset 0x10) to 0. If support is needed for other environments such as Windows 3.1 or MS-DOS, the BIOS should configure it to an available 4K memory window.
Set the Interrupt Line register (offset 0x3C) to 0xFF (no IRQ assigned). If support is needed for other environments such as Windows 3.1 or MS-DOS, an assigned IRQ line can be set.
Note: The Interrupt Line register must be set to 0xFF when the device is disabled by the operating system and set into CardBus mode, as described in "BIOS Report for Plug and Play Enumeration" later in this article.
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.)
The $PIR table must return the necessary PCI IRQ routing information, including the routing information for the CardBus controller.
In general, if the CardBus controller is built in to the system board, the $PIR table must contain a slot routing entry for the controller. If the CardBus controller is a PCI add-in card, the $PIR table must also contain routing information entries for each PCI slot in the system.
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:
Disable LegacyBaseAddress (0x44) to disable decoding of legacy mode I/O base address 0x3E0.
Do not change any Base Address Registers or any other registers below offset 0x3C.
Perform any proprietary initialization (offsets above 0x3C) required to put the device in CardBus mode.
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:
The BIOS was not designed to configure more than one level of PCI-to-PCI bridge and CardBus controller, or an error occurred during configuration.
The controller was not present in the system while the BIOS code was running (that is, the controller was hot-plugged after the BIOS transferred control to the operating system).
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:
If an ISA interrupt is detected, the R2 card receives a dedicated ISA-style interrupt and the operating system avoids the risk of assigning a shared PCI interrupt to an R2 device that may not support PCI interrupts. If an R2 card that requires ISA-style interrupts is inserted in the slot, the operating system can assign the correct interrupt to that card.
If no interrupt is wired to the CardBus controller and an ISA interrupt is not detected during the scan, the operating system assigns a PCI interrupt to the card, so R2 cards that require ISA interrupts might not work.
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:
The PCI bus driver scans a bus and finds a controller.
The PCI bus driver determines whether the controller has been configured by the BIOS by checking if the I/O Enable, Memory Enable, and Bus Master bits are set in the controller's command register.
If the controller was configured by the _INI method, the PCI bus driver does not change the controller configuration.
If the controller was not configured, either because of an error or because the controller was not present when the BIOS code was running, the PCI bus driver assigns the following default resources. These allocations are the same on both 32-bit and 64-bit systems.
Windows 2000 default resources:
One 4K memory window
One 2 MB memory window
Two 256-byte I/O windows
Windows XP default resources:
Because one memory window of 4K and one window of 2 MB are not sufficient for CardBus controllers in many configurations, Windows XP allocates larger memory windows to CardBus controllers where possible. However, resource windows are static (that is, the operating system does not dynamically allocate larger memory windows if new devices appear.) Under Windows XP, CardBus controllers will be assigned the following resources:
One 4K memory window, as in Windows 2000
64 MB memory, if that amount of memory is available. If 64 MB is not available the controller will receive 32 MB; if 32 MB is not available, the controller will receive 16 MB; if 16 MB is not available, the bridge will receive 8 MB; and so on down to a minimum assignment of 1 MB in configurations where memory is too constrained for the operating system to provide a larger window.
Two 256-byte I/O windows
The PCI bus driver starts the controller and scans the bus behind the bridge.
If there are CardBus devices behind the controller, the PCI bus driver assigns resources to those devices.
If the PCI resources allocated to the controller are sufficient for the devices behind the controller, the driver assigns resources to all devices from the controller resource allocation. All devices can start and operate correctly.
If the resources allocated to the controller are not sufficient for the devices behind the controller, the driver assigns resources to devices from the controller resource allocation until the allocation is used up. Devices that do not receive resources from this allocation cannot be started because controller windows are static. The PCI bus driver will not attempt to allocate more resources to the controller to meet the needs of child devices.
If there are R2 devices behind the controller, Pcmcia.sys loads and assigns resources to those devices.
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:
If the CardBus controller is already in CardBus mode, (that is, if LegacyBaseAddress register offset 0x44 is cleared), the BIOS returns SUCCESS and does no other processing.
If the CardBus controller is still in legacy PCIC mode as described in "PCI Configuration Space for CardBus" later in this article, the BIOS does the following to put the controller into CardBus mode:
Set Command register (offset 0x04) to 0
Set RegisterBaseAddress (offset 0x10) to 0
Set Interrupt Line register (offset 0x3C) set to 0xFF
Set LegacyBaseAddress (offset 0x44) to 0
Perform any other controller-specific initialization to put the controller in CardBus mode
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:
CardBus controllers are multifunction PCI devices, and Windows treats each function as an independent device. As such, there can be no sharing between functions of writable PCI Configuration Space bits, such as the Command register.
Notice that the 16-bit PC Card interface legacy-mode Base Address Register (BAR; offset 44h in the Type 2 PCI header) is the only exception to this requirement. This BAR must be shared between the two functions in order to be compatible with the ExCA programming model.
For more information about design requirements for CardBus, see Microsoft Windows Logo Program System and Device Requirements, Version 2.0, available at http://www.microsoft.com/whdc/winlogo/default.mspx.
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.
Interrupt Control:
CSC Interrupt in PCI mode (the hardware must allow CSC interrupt generation in PCI mode).
CardBus Card interrupt generation in PCI mode.
R2 Card interrupt generation in ISA mode. Can be dynamically switched to PCI mode (sharing interrupt with CSC), if necessary.
CardBus Socket Event and Socket Mask registers used to handle CSC interrupt regardless of card type (for both CardBus cards and R2 cards).
Many CardBus controller implementations allow several ISA interrupt request (IRQ) modes, such as serial ISA IRQ mode. These modes must be transparent to software. The controller driver will not perform any initialization to set up and enable these modes.
Power Control:
CardBus Socket Control register used to control power for both CardBus cards and R2 cards, because there is no ExCA register standard on 3.3-volt support.
3.3-volt or lower support for CardBus card; 5-volt or 3.3-volt support for R2 cards.
Other Special Considerations:
R2 Memory Window Control. The ExCA standard states that an ExCA memory window can only be within 0M to 16M, which is an ISA bus limitation. Because a CardBus controller is by definition a PCI device, this limitation no longer applies. The Yenta specification specifies optional extended R2 memory window base/limit registers at offset 0x840-0x844. For Windows compatibility, these registers are required. Windows depends on these registers in order to map memory beyond 16M for R2 cards if the CardBus controller is behind a positive decode PCI bridge (that is, in a docking station).
Configuration Space Registers. The Yenta specification is incorrect in stating that some bits in the Command registers can be shared between the two functions (that is, the two sockets), in particular, the IOSpaceEnable and MemSpaceEnable bits. For compatibility with Windows, the bits in these registers must not be shared between the two sockets. Windows relies on these bits to disable a CardBus socket. If the bits are shared, the sockets can not be disabled independently of each other.
The same issue applies to the Bridge Control register. For compatibility with Windows, the bits in these registers must not be shared between the two sockets. For more information, see "PCI Configuration Space Considerations for CardBus Controllers" earlier in this article.
Call to Action
Understand common issues for PCI-to-PCI bridges and CardBus controllers, such as configuring memory and I/O windows and implications of static windows, as described in PCI-to-PCI Bridges and CardBus Controllers on Windows Operating Systems at http://www.microsoft.com/whdc/hwdev/bus/pci/pcibridge-cardbus.mspx
Design CardBus controllers, CardBus cards, and PC Cards according to the requirements defined in Microsoft Windows Logo Program System and Device Requirements, Version 2.0, at http://www.microsoft.com/winlogo/hardware/default.mspx
Implement _PRT and _INI for CardBus controllers as described in the Advanced Configuration and Power Interface Specification, version 1.0b or later, available at
http://www.acpi.info/ .gif)
Develop R2 card drivers that share PCI interrupts. R2 cards that support PCI shared interrupts are much more likely to work properly because they do not rely on system manufacturers to wire an ISA interrupt to the CardBus controller.
Ensure that BIOS code sets CardBus controllers to PCIC mode for compatibility with Windows 95/98/Me operating systems, Windows 2000 and Windows XP.
Ensure that functions in multifunction devices do not share configuration space. Functions in a multifunction device must be completely independent.
.gif){kind=icon}
