PCMCIA Support on Linux

Initially, most wireless networking adapters were add-on cards that were based on the PC Card specification.[] PC Cards attach to the system bus through a 16-bit controller interface that operates at 8 MHz. Even though performance was limited by the bus to be roughly comparable to the 16-bit ISA bus, it was more than capable of supporting relatively slow 802.11b wireless LANs. Higher-performance 802.11a and 802.11g cards require the performance of the next-generation CardBus interface, which drives a 32-bit bus at 33 MHz. CardBus provides the dramatically improved performance required by higher-bandwidth network interfaces. CardBus cards look nearly identical to PC Cards, and are used in the same slots. Both CardBus and PC Cards are, not surprisingly, configured and managed through the Linux PCMCIA utilities.

] The Personal Computer Memory Card International Association (PCMCIA) is the industry group that came up with the PC Card specification. Initially, the cards were known as "PCMCIA cards," but the name was later shortened to "PC Card." I use both interchangeably, especially since Linux support for these cards still goes by the longer PCMCIA. (In reference to the unwieldy nature of the acronym, one common joke expands it as "People who Cant Manage Computer Industry Acronyms.")

Using external interfaces with antennas that protrude from the case of the laptop is not always desirable. Laptop vendors have adopted a different form factor for "built-in" wireless devices called Mini-PCI. Mini-PCI is a small version of the PCI interface that is only a few inches long. There no limit on what could be made into a Mini-PCI card, but by far the most popular use of the slot is to add wireless networking capabilties to laptops. Most Mini-PCI wireless cards consist of a PCI-to-Cardbus bridge combined with a CardBus wireless LAN interface, and are therefore configured and managed through the Linux PCMCIA system.

PCMCIA Card Services Overview

Card Services grew out of an attempt to simplify system configuration. Rather than dedicating system resources to individual devices, the host system maintained a pool of resources for PC Cards and allocated resources as necessary. Figure 19-1 shows the procedure by which cards are configured on Linux.

When a card is inserted, the cardmgr process orchestrates the configuration of the device, as shown in Figure 19-1. The orchestration pulls together system resources, kernel components, and kernel driver modules through the configuration files stored in /etc/pcmcia. Roughly speaking, the host takes the following steps:

1. A card is inserted into an empty PC Card socket, and cardmgr is notified of this event. In addition to any hardware operations (such as supplying power to the socket), cardmgr queries the card information structure (CIS) to determine the type of card inserted and the resources it needs. For more information on the CIS, see the sidebar "Card Information Structure" later in this chapter.
2. cardmgr attempts to identify the card and load the appropriate kernel modules for support. The PCMCIA card database stored in /etc/pcmcia/config is used to map the CIS database to drivers. Drivers can also be loaded automatically through a hardware identification list that is part of the module and stored in a module map (/lib/modules/(kernel version)/module.*map). The main task of the identification is to associate cards with a class. For the purposes of configuring network cards, the important point to note is that items in the network class have additional network configuration operations performed on them later. The card is identified by the CIS data from step 1, and the class setting is set in the main system configuration file. At this point, cardmgr beeps once. Successful identification results in a high-pitched beep; unsuccessful identifications are indicated by a beep of lower pitch.

   Figure 19-1. Linux PCMCIA configuration system

    
3. cardmgr determines which resources are available to allocate to the card. Blocks of system resources are reserved for PCMCIA card use in the main configuration file, and cardmgr doles out resources as needed to cards. The number of I/O ports needed and the size of the required memory window are obtained from the CIS.
4. Resources allocated by cardmgr are programmed into the PCMCIA controller, which is depicted in Figure 19-1 as interaction with the PCMCIA device driver. The Intel i82365SL PCMCIA controller is the most common chip on the market, which is why the kernel module is shown as "i82365." The new kernel-based PCMCIA system uses the yenta_socket driver instead of a chipset-specific driver. PCMCIA controllers implement resource steering to map resources required by the card onto available system resources. A card may ask for an interrupt, but the actual assigned interrupt is irrelevant. In operation, the card simply asks the PCMCIA controller to raise an interrupt, and the controller is responsible for looking up the interrupt assigned to the socket and firing the correct interrupt line.
5. Part of the configuration information obtained from the lookup in step 2 is the name of the device driver that should be loaded to use the newly inserted card. Drivers for PCMCIA cards are implemented as kernel modules. As part of the insertion process, the driver is informed of resources allocated in step 4. With proper module dependencies, module stacking can be used to load multiple modules.
6. Further user-space configuration is performed based on the class of the device. Network cards, for example, have further configuration done by the /etc/pcmcia/network script, which is configured by editing /etc/pcmcia/network.opts. Successful configuration in this step generates a second high beep, and failure is reported with a low beep. Additional configuration may also be performed by the Linux hotplug system.

Interface names in Linux

When a driver creates the network interface, it is given a name consisting of a prefix and a number. Many drivers will create additional network interface with a name of the form ethX, where X is the next number in sequence. Most laptops now have built-in Ethernet interfaces that come up on boot as eth0, which makes many wireless interfaces start as eth1. Older versions of the WaveLAN driver created interfaces beginning with the prefix wvlan, but current versions use eth. Atheros-based cards come up using the prefix ath.

Hotplug system for automatic configuration

To perform automatic configuration, Linux depends on the work of the hotplug configuration project, whose web site is found at http://linux-hotplug.sourceforge.net/. When a device is inserted, the hotplug system will call any needed PCI configuration commands before configuring the interface. Hotplug scripts can help to automatically configure systems with large numbers of network interfaces, or perform arbitrary configuration tasks. Many wireless devices implementing new standards are under continued development after the product is released. New firmware updates to cards can make new protocol features possible, or fix bugs in the released version. Hotplug can also be configured to automatically update firmware when particular cards are plugged in.

PCMCIA Card Services Installation

As of kernel 2.4, PCMCIA support has been integrated into the kernel, and was probably installed with your distribution. It is not necessary to upgrade the kernel PCMCIA support. It may be necessary to fetch drivers for your interface, but it is almost certain that the PCMCIA support is up-to-date enough to handle any wireless interface you throw at it. (Older distributions can update PCMCIA software through a distribution maintainer's package, or by building from the source at http://pcmcia-cs.sourceforge.net/.)

Most configuration information is automatically detected from the environment without difficulty. Depending on the distribution and its installation, it may be necessary to inform the PCMCIA software which controller is running the PCMCIA slots by setting the PCIC variable in the system configuration file. Kernel PCMCIA software sets the value to yenta_socket. Systems that use the standalone PCMCIA support will set the variable to either tcic for Databook TCIC-2 chipsets, or i82365 for the Intel i82365SL chipset. Slackware features a "probe" option to load modules until one successfully loads.

Monitoring the Cards

The main tool used to control the PCMCIA subsystem is the cardctl command. It has several subcommands that can be used to view information or configuration status. Each argument can also take a slot number. Many laptop computers have two PCMCIA slots, in which case the slots are numbered 0 and 1. An increasing number of notebooks designed for portability have only a single slot, and therefore only have slot 0.

In addition to the hardware-based eject system, cardctl can be used to remove drivers by sending the "card is removed" notification. Once the software has removed all the associated drivers and powered the slot down, the card can be restarted by sending a software notification of the card insertion. Having software control over the card allows the "reboot" of a card without having to physically remove and reinsert it.

[root@bloodhound]# cardctl eject 0 [root@bloodhound]# cardctl insert 0

Drivers are selected based on the CIS data. To see the contents of the card's CIS, insert it and wait for it to power up, then use the info or ident subcommands to cardctl to see the identification information. Here is the information from a Proxim 8480 Gold card. Like nearly all cards with 802.11a capabilities, it is based on the Atheros chipset. The card even reports itself as an Atheros reference design:

root@bloodhound:~# cardctl info 0 PRODID_1="Atheros Communications, Inc." PRODID_2="AR5001-0000-0000" PRODID_3="Wireless LAN Reference Card" PRODID_4="00" MANFID=0271,0012 FUNCID=6 root@bloodhound:~# cardctl ident 0 product info: "Atheros Communications, Inc.", "AR5001-0000-0000", "Wireless LAN Reference Card", "00" manfid: 0x0271, 0x0012 function: 6 (network)

In addition to extracting the CIS identification with cardctl, the complete structure can be printed out with cis_dump. In addition to identification information, the CIS includes information about the supported speeds. In the case of the Proxim 8480, it reports exclusively on the 802.11a speeds, even though it is capable of 802.11b-compatible operation:

root@bloodhound:~# dump_cis Socket 0: manfid 0x0271, 0x0012 config_cb base 0x0000 last_index 0x01 cftable_entry_cb 0x01 [default] [master] [parity] [serr] [fast back] Vcc Vnom 3300mV Istatic 25mA Iavg 450mA Ipeak 500mA irq mask 0xffff [level] mem_base 1 BAR 1 size 64kb [mem] vers_1 7.1, "Atheros Communications, Inc.", "AR5001-0000-0000", "Wireless LAN Reference Card", "00" funcid network_adapter [post] lan_speed 6 mb/sec lan_speed 9 mb/sec lan_speed 12 mb/sec lan_speed 18 mb/sec lan_speed 24 mb/sec lan_speed 36 mb/sec lan_speed 48 mb/sec lan_speed 54 mb/sec lan_speed 72 mb/sec lan_media 5.4_GHz lan_node_id 20 00 4d a6 d4 0a lan_connector Closed connector standard Socket 1: no CIS present

Once the card has been inserted into the system, use the status subcommand to check on it. The config subcommand will also report the system interrupt assigned by the system. In my case, the laptop uses a PCI-to-Cardbus bridge, so the card inherits the IRQ assigned to the PCI bus.

root@bloodhound:~# cardctl status 0 3.3V CardBus card function 0: [ready] root@bloodhound:~# cardctl config 0 Vcc 3.3V Vpp1 3.3V Vpp2 3.3V interface type is "cardbus" irq 11 [exclusive] [level] function 0:

The lights are not useful

Many drivers are intended to work with several different pieces of hardware, and each manufacturer may customize the number and purpose of the lights on the card. Usually, there is one light to indicate that the card is powered up, and a second light that will blink to indicate traffic from the card. It may or may not blink in response to traffic from other stations. A few cards may have a third light to indicate association status.

Linux drivers generally do not make an attempt to control the lights on each card in a vendor-specific way, and internal cards may not have any lights at all. If your card behaves differently, don't panic. Check at the access point for an association; if an association exists, then the card is functioning normally but uses the lights in a different manner.

Troubleshooting Resource Conflicts

One of the revolutionary developments hyped by PCMCIA card vendors was that users were no longer directly responsible for maintaining low-level hardware configurations on IBM-compatible hardware. In many respects, this hype was overblown because users are still responsible for maintaining the resource pools used by PCMCIA Card Services to draw from for automatic configuration, and therefore they must still be familiar with the hardware configuration. Three major resources are managed by Card Services for users: IRQ lines, I/O ports, and direct memory access (DMA) channels. DMA channels are not required by network cards, however, and are not discussed in this section.

IRQs

IRQs are used by devices that must use the CPU periodically. Interfaces use IRQs so that when a buffer fills, the system CPU can be notified and drain the buffer. One limitation of the PC architecture is that it has only 15 available IRQs, and many are occupied by standard hardware. Table 19-1 shows common IRQ usage, which may help you determine which IRQs are available for PCMCIA cards. Disabling any extra components frees the IRQ. Table 19-1 also shows common IRQ settings on PC hardware. As a rule of thumb, IRQs 3, 5, and 10 are readily available on most machines.

I/O ports

I/O addresses are used for bidirectional communication between the system and a peripheral device. They tend to be somewhat poorly organized, and many devices have overlapping defaults. Each I/O port can be used to transfer a byte between the peripheral device and the CPU. Most devices require the ability to transfer multiple bytes at a time, so a block of ports is assigned to the device. The lowest port number is also called the base I/O address. A second parameter describes the size of the I/O window. Table 19-2 lists some of the common port assignments. Refer to your hardware vendor's documentation for details on additional devices such as IR ports, USB controllers, the PCMCIA controller, and any resources that may be required by motherboard components.