This section summarizes PC 98 requirements and standards for socket controllers.
3. Controller supports industry-standard ExCA register set
Required
The built-in software supporting PC Card 16 cards in Windows includes drivers for the industry-standard Exchangeable Card Architecture-compatible (ExCA-compatible) socket controllers. To be compatible with these drivers, socket-controller implementations must support the industry-standard ExCA base register set.
Notice that some controllers do not fully implement the register set and therefore are incompatible. Also, some controllers implement extended registers or enhancements. The built-in Windows drivers do not exploit these features, even though the controller might be compatible.
4. System maintains mapping of IRQ Routing Register bits to system interrupt vectors
Required
The system design must maintain the mapping of the PC Card controller’s IRQ Routing Register bits to system interrupt vectors. This means that when an interrupt is programmed in the controller to occur on the IRQx pin, the system’s IRQ routing causes the interrupt controller to generate the interrupt vector for IRQx and no other IRQ.
5. IRQ connections can be determined by using the 0805 register
Required
Windows uses the 0805 register on both PC Card 16-only controllers and on CardBus controllers to determine which ISA IRQs are connected to the controller. This register must engage (that is, drive low) the corresponding ISA IRQ when programmed with a value. It must disengage the IRQ (that is, float high) when programmed at zero (0).
6. CardBus controllers support both ISA and PCI interrupts
Required
PC Card software dynamically configures the bridge to use ISA interrupts for PC Card 16 cards and to use PCI interrupts for CardBus cards. As defined in the “IRQ connections can be determined by using the 0805 register” and “System maintains mapping of IRQ Routing Register bits to system interrupt vectors” requirements earlier in this section, CardBus controllers must maintain mapping of IRQ routing. Also, notice that systems implementing CardBus controllers must fully support PCI 2.1 as well as additional PCI requirements for IRQ routing as described in the “PCI” chapter in Part 3 of this guide.
7. System supports industry-standard definition for CardBus bridges
Required
If the system supports CardBus, it must support the definition in PCI to PCMCIA CardBus Bridge Register Description (Yenta specification) for CardBus controllers (PCI-to-CardBus bridges). This definition includes a common PCI Configuration Space header assigned the Header Type field value of 82h.
Although this requirement is not yet incorporated into the PCI standard, Windows supports it. Any controller features that are not part of the Yenta specification will not be used in standard drivers. The BIOS is responsible for any hardware initialization or setup required to make the controller comply with the Yenta specification or other requirements listed in this chapter.
Because CardBus host controllers are PCI bus bridges, they will be supported (enumerated and configured) by the PCI software in Windows in the same manner as other PCI bus bridges. For more information, see the “PCI” chapter in Part 3 of this guide.
8. BIOS initializes CardBus controller in 82365-compatible mode and supports backward compatibility
Recommended
CardBus controllers are enumerated and configured in Windows in the same way as other PCI bus bridges. The PCI bus bridge support in Windows 98 is based on new requirements for PCI interrupt routing and bridge-window configuration. Because of this, full compliance with the latest PCI specifications is a requirement for CardBus support.
There are steps the BIOS can take to achieve backward compatibility with Windows. Specifically, the BIOS can initialize the CardBus controller in Intel 82365-compatible mode and report it as device “PNP0E03, Intel 82365-compatible CardBus controller.” The requirements are as follows for BIOS POST time (CardBus controller ConfigSpace initialization):
This puts the CardBus controller into legacy mode where the Windows Socket Services driver can access it as an Intel PC Card I/O card–compatible (PCIC-compatible) controller at an I/O address (for example, 0x3e0).
Notice that the BIOS must be at least PCI 2.1-compliant and must support the $PIR Interrupt Routing Table. 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 on the system board, there must be a slot routing entry for it in the table. If the CardBus controller is a PCI add-on card, there must be routing information entries for each PCI slot in the system.
During Plug and Play BIOS enumeration, 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).
For more information, see the white paper on CardBus host controllers and Windows compatibility at http://www.microsoft.com/hwdev/busbios/.
9. CardBus controllers do not share writable PCI Configuration Space bits
Required |
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 PC Card 16-bit interface legacy-mode 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, since they must share the same BARs in order to be compatible with the ExCA programming model.
10. Each PC Card 16 memory window in CardBus controller has it own page register
Required
For complete flexibility and support of typical configurations, CardBus controllers must support the independent location of R2 memory windows anywhere in the full system address space as recommended in the Yenta specification.
Controllers that share a single page register among all PC Card 16 memory windows require that all PC Card 16 memory windows must be located within the same 16-MB block. Often, this is not possible with typical (16 MB) DRAM and bridge (positive-decode) configurations. The result is disabled cards.