The following things should be installed on your system before you start installing PCMCIA:
The latest version requires a kernel version 1.2.8 or higher, or a development kernel 1.3.30 or higher. 1.3.38 is definitely broken, and 1.3.31 to 1.3.36 are untested. It also requires a relatively recent set of module utilities. There are no kernel patches specifically for PCMCIA.
You need to have a complete linux source tree for your kernel, not just an up-to-date kernel image, to compile the PCMCIA package. The PCMCIA modules contain some references to kernel source files. While you may want to build a new kernel to remove unnecessary drivers, installing PCMCIA does not require you to do so.
Current ``stable'' kernel sources and patches are available from
sunsite.unc.edu in /pub/Linux/kernel/v1.2, or from
tsx-11.mit.edu in /pub/linux/sources/system/v1.2.
Current module utilities can be found in the same place, in
modules-1.2.8.tgz. Development kernels can be found in the
corresponding v1.3 subdirectories. Some recent development
kernels and compiler releases interact badly with older sets of module
tools. The latest versions of the module utilities can be found at
<http://www.pi.se/blox/modules>.
When configuring your kernel, if you plan on using a PCMCIA ethernet card, you should turn on networking support but turn off the normal Linux network card drivers, including the ``pocket and portable adapters''. The PCMCIA network card drivers are all implemented as loadable modules. Any drivers compiled into your kernel will only waste space.
If you want to use SLIP, PPP, or PLIP, you do need to either configure your kernel with these enabled, or use the loadable module versions of these drivers. There is an unfortunate deficiency in the kernel config process in 1.2.X kernels, in that it is not possible to set configuration options (like SLIP compression) for a loadable module, so it is probably better to just link SLIP into the kernel if you need it.
If you want to use a PCMCIA token ring adapter, your kernel needs to
be configured with ``Token Ring driver support'' (CONFIG_TR)
enabled, though you should leave CONFIG_IBMTR off.
If you will be using a PCMCIA SCSI adapter, you should enable
CONFIG_SCSI when configuring your kernel. Also, enable any top
level drivers (SCSI disk, tape, cdrom, generic) that you expect to
use. All low-level drivers for particular host adapters should be
disabled, as they will just take up space.
If you want to modularize a driver that is needed for a PCMCIA device,
you must modify /etc/pcmcia/config to specify what modules
need to be loaded for what card types. For example, if the serial
driver is modularized, then you could change the serial device
definition to:
device "serial_cs"
class "serial" module "serial", "serial_cs"
If your kernel is compiled with CONFIG_MODVERSIONS enabled, for
kernel symbol version checking, the configure script will check for
the existence of /usr/include/linux/modversions.h, the symbol
version database. This is created by running ``make dep'' in the
kernel source tree.
This package includes an X-based card status utility called
cardinfo. This utility is based on a public domain user
interface toolkit called the Forms Library, which you will need to
install before building cardinfo. A binary distribution is on
hyper.stanford.edu in /pub/pcmcia/extras: there are both
a.out and ELF versions of the library.
Here is a synopsis of the installation process:
make config'' in the new pcmcia-cs-2.8.? directory.make all'', then ``make install''./etc/rc.d/rc.pcmcia and the option files in
/etc/pcmcia for your site.Running ``make config'' prompts for a few configuration options,
and checks out your system to verify that it satisfies all
prerequisites for installing PCMCIA support. In most cases, you'll be
able to just accept all the default configuration options. Be sure to
carefully check the output of this command in case there are problems.
If you are compiling the PCMCIA stuff for installation on another
machine, specify an alternate target directory when prompted by the
configure script. This should be an absolute path. All the PCMCIA
tools will be installed relative to this directory. You will then be
able to tar this directory tree and copy to your target machine,
and unpack relative to its root directory to install everything in the
proper places.
If you are cross compiling on another machine, you may want to specify alternate names for the compiler and linker. This may also be helpful on mixed a.out and ELF systems. The script will also prompt for additional compiler flags for debugging.
There are a few kernel configuration options that affect the PCMCIA tools. The configuration script can deduce these from the running kernel (the most common case). Alternatively, if you are compiling for installation on another machine, it can read the configuration from a kernel source tree, or each option can be set interactively.
Running ``make all'' followed by ``make install'' will build
and then install the kernel modules and utility programs. Kernel
modules are installed under /lib/modules/<version>/pcmcia.
The cardmgr and cardctl programs are installed in
/sbin. If cardinfo is built, it is installed in
/usr/bin/X11.
Configuration files will be installed in the /etc/pcmcia
directory. If you are installing over an older version, your old
config scripts will be backed up before being replaced. The saved
scripts will be given extensions like *.~1~, *.~2~, and so
on.
If you don't know what kind of PCMCIA controller chip you have, you
can use the probe utility in the cardmgr/ subdirectory to
determine this. There are two major types: the Databook TCIC-2 type
and the Intel i82365SL-compatible type.
A user-level daemon processes card insertion and removal events. This
is called cardmgr. It is similar in function to Barry Jaspan's
pcmciad in earlier PCMCIA releases. Cardmgr reads a
configuration file describing known PCMCIA cards from
/etc/pcmcia/config. This file also specifies what resources
can be allocated for use by PCMCIA devices, and may need to be
customized for your system. See the pcmcia man page for more
information about this file.
The script rc.pcmcia, installed in /etc/rc.d, controls
starting up and shutting down the PCMCIA system.
``make install'' will use the probe command to determine
your controller type and modify rc.pcmcia appropriately. You
should add a line to your system startup file /etc/rc.d/rc.M
to invoke this:
/etc/rc.d/rc.pcmcia start
In a few cases, the probe command will be unable to determine
your controller type automatically. The Tadpole P1000 and some other
PCI-based laptops have a special Cirrus PCI-to-PCMCIA bridge chip that
can't be detected by probe. If you have one of these systems,
you'll need to edit rc.pcmcia by hand to load the i82365
module. If you have a Halikan NBD 486 system, it has a TCIC-2
controller at an unusual location: you'll need to edit rc.pcmcia
to load the tcic module, as well as setting the PCIC_OPTS
parameter to ``tcic_base=0x02c0''.
Card Services should automatically avoid allocating IO ports and
interrupts already in use by other standard devices. It will also
attempt to detect conflicts with unknown devices, but this is not
completely reliable. In some cases, you may need to explicitly
exclude resources for a device in /etc/pcmcia/config.opts.
Here are some resource settings for specific laptop types.
Some PCMCIA controllers have optional features that may or may not be implemented in a particular system. It is generally impossible for a socket driver to detect if these features are implemented. Check the man page for your driver to see what optional features may be enabled.
The low level socket drivers, tcic and i82365, have numerous
bus timing parameters that may need to be adjusted for systems with
particularly fast processors. Symptoms of timing problems include
card recognition problems, lock-ups under heavy loads, high error
rates, or poor device performance. Check the corresponding man pages
for more details, but here is a brief summary:
freq_bypass flag which changes the
multiplier for the PCMCIA bus clock to slow down all operations.fast_pci flag, which
should be set if the PCI bus speed is greater than 25 MHz.async_clock flag changes the relative clocking of PCMCIA bus and
host bus cycles. Setting this flag adds extra wait states to some
operations. However, I have yet to hear of a laptop that needs this.pcmcia_core module has the cis_speed parameter for
changing the memory speed used for accessing a card's Card Information
Structure (CIS). On some systems with fast bus clocks, increasing
this parameter (i.e., slowing down card accesses) may be beneficial.i82365 module should be loaded
with the extra_sockets parameter set to 1.All these options should be configured by modifying the top of
/etc/rc.d/rc.pcmcia. For example:
# Should be either i82365 or tcic
PCIC=i82365
# Put socket driver timing parameters here
PCIC_OPTS="cmd_time=12"
# Put pcmcia_core options here
CORE_OPTS="cis_speed=500"
Here are some timing settings for specific systems:
freq_bypass=1 cmd_time=8''.cmd_time=12''.cmd_time=16''.On some systems using Cirrus controllers, including the NEC Versa M,
the BIOS puts the controller in a special suspended state at system
startup time. On these systems, the probe command will fail to
find any known PCMCIA controller. If this happens, edit
/etc/rc.d/rc.pcmcia by hand as follows:
# Should be either i82365 or tcic
PCIC=i82365
# Put socket driver timing parameters here
PCIC_OPTS="wakeup=1"
The configure script will normally ensure that the PCMCIA modules are
compatible with your kernel. So, module loading problems generally
indicate that the user has interfered with the normal installation
process in some way. Some module loading errors are sent directly to
the Linux console. Other errors are recorded in the system log file,
normally /usr/adm/messages or /var/log/messages. To
track down a problem, be sure to check both locations, to pin down
which module is actually causing trouble.
Some of the PCMCIA modules require kernel services that may or may not
be present, depending on kernel configuration. For instance, the SCSI
card drivers require that the kernel be configured with SCSI support,
and the network drivers require a networking kernel. If a kernel
lacks a necessary feature, insmod may report undefined symbols
and refuse to load a module.
If insmod reports ``wrong version'' errors, it means that the
module was compiled for a different kernel version than your system is
actually running. This might occur if modules compiled on one machine
are copied to another machine with a different configuration, or if
the kernel is reconfigured after PCMCIA is installed.
Another source of module loading errors is when the modules and kernel
were compiled with different settings of CONFIG_MODVERSIONS. If
a module with version checking is loaded against a kernel without
version checking, insmod will complain about undefined symbols.
Finally, relatively recent binutils releases are incompatible with
older versions of the module utilities, and can cause module version
incompatibilities to be reported. The most common symptom is
complaints about ``gcc_compiled'' being undefined. If you get
these errors, upgrade to the latest module utilities, available from
<http://www.pi.se/blox/modules>.
In most cases, the socket driver (i82365 or tcic) will
automatically probe and select an appropriate interrupt to signal card
status changes. The automatic interrupt probe doesn't work on some
Intel-compatible controllers, including Cirrus chips and the chips
used in some IBM ThinkPads. If a device is inactive at probe time,
its interrupt may also appear to be available. In these cases, the
socket driver may pick an interrupt that is used by another device.
With the i82365 and tcic drivers, the irq_mask option
can be used to limit the interrupts that will be tested. This mask
limits the set of interrupts that can be used by PCMCIA cards as well
as for monitoring card status changes. The cs_irq option can
also be used to explicitly set the interrupt to be used for monitoring
card status changes.
If you can't find an interrupt number that works, there is also a
polled status mode: both i82365 and tcic will accept a
poll_interval=100 option, to poll for card status changes once
per second. This option should also be used if your system has a
shortage of interrupts available for use by PCMCIA cards. Especially
for systems with more than one PCMCIA controller, there is little
point in dedicating interrupts for monitoring card status changes.
All these options should be set in the PCIC_OPTS= line in either
/etc/rc.d/rc.pcmcia or /etc/sysconfig/pcmcia,
depending on your site setup.
The most common problem of this type seems to be a conflict with a
PS/2 pointer device on interrupt 12. In this case, edit
rc.pcmcia so the PCIC_OPTS= line reads:
PCIC_OPTS="irq_mask=0xefff"
By default, the PCMCIA drivers use the address region 0xd0000-0xdffff
to access PCMCIA devices. This memory window is specified in
/etc/pcmcia/config.opts. If this address region is used by
other devices in your system, cards may not be identified correctly.
With chipsets that support it, conflicts can also result from memory
shadowing in this region. If you find that all your cards are always
misidentified as memory cards, verify that shadowing is disabled in
your system's hardware setup. As there is no reliable way to
automatically identify memory window conflicts, finding a good window
may require some experimentation. Some alternative windows to try are
0xd8000-0xdffff, 0xc0000-0xcffff, and 0xc8000-0xcffff.
If you have DOS PCMCIA drivers, you may be able to deduce what memory
region those drivers use. Note that DOS memory addresses are often
specified in ``segment'' form, which leaves off the final hex digit
(so an absolute address of 0xd0000 would be given as 0xd000). Be sure
to add the extra digit back when making changes to
/etc/pcmcia/config.opts.
Red Hat and Caldera have a System V-ish arrangement for system startup
files. The PCMCIA installation scripts will automatically detect this
and adjust accordingly. The rc.pcmcia script will be installed as
/etc/rc.d/init.d/pcmcia. There is no need to edit any of the
Caldera startup scripts to enable PCMCIA: it will happen
automatically.
A separate configuration file, /etc/sysconfig/pcmcia, will
be created for startup options. If you need to change any module
options (like the PCIC= or PCIC_OPTS= settings), edit this config
file rather than the actual PCMCIA startup script. This file will not
be overwritten by subsequent installs.
Previous releases used the /etc/sysconfig/pcmcia-scripts
directory in place of /etc/pcmcia on these platforms. The
current release instead uses /etc/pcmcia for all systems, and
will move an existing /etc/sysconfig/pcmcia-scripts to
/etc/pcmcia.
For me, distributing binaries is a significant hassle. It is complicated because some features can only be selected at compile time, and because the PCMCIA modules are somewhat dependent on having the ``right'' kernel configuration. So, I would probably need to distribute precompiled modules along with matching kernels. Beyond this, the greatest need for precompiled modules is when installing Linux on a clean system. This typically requires setting up PCMCIA so that it can be used in the installation process for a particular Linux distribution. Each Linux distribution has its own procedures, and it is not feasible for me to provide boot and root disks for even just the common combinations of drivers and distributions.
PCMCIA is now a part of many of the major Linux distributions, including Red Hat, Caldera, Slackware, Yggdrasil, Craftworks, and Nascent Technology.
Well, first of all, it isn't actually that large. All the driver modules together take up about 200K of disk space. The utility programs add up to about 70K, and the stuff in /etc/pcmcia is about 30K. When running, the core PCMCIA modules take up 48K of system memory. The cardmgr daemon will generally be swapped out except when cards are inserted or removed. The total package size is not much different from DOS Card Services implementations.
Compared to DOS ``point enablers'', this may still seem like a lot of overhead, especially for people that don't plan on using many of the features of PCMCIA, such as power management or hot swapping. Point enablers can be tiny because they generally support only one or a small set of cards, and also generally support a restricted set of PCMCIA controllers. If someone were to write a genuinely ``generic'' modem enabler, it would end up incorporating much of the functionality of Card Services, to handle cards from different vendors and the full range of PCMCIA controller variants.