  Plug-and-Play-HOWTO (for Linux)
  David S.Lawyer    <mailto:bf347@lafn.org>
  v0.01, March 1999

  Help with understanding and dealing with Plug-and-Play devices.  How
  to get your Linux system to support Plug-and-Play.  This early version
  is incomplete but should be of some help.

  ______________________________________________________________________

  Table of Contents


  1. Introduction

     1.1 Copyright, Trademarks, Disclaimer, & Credits
        1.1.1 Copyright
        1.1.2 Trademarks
        1.1.3 Disclaimer
     1.2 Future Plans: You Can Help
     1.3 New Versions of this HOWTO

  2. What PnP Should Do: Allocate "Resources"

     2.1 What is Plug-and-Play (PnP)?
     2.2 How a Computer Finds Devices (and conversely)
     2.3 I/O Addresses, etc.
     2.4 IRQ's --Overview
     2.5 DMA Channels
     2.6 Memory Regions
     2.7 "Resources" in Two Places
     2.8 The Problem
     2.9 PnP Finds Devices Plugged Into Serial Ports

  3. The Plug-and-Play (PnP) Solution

     3.1 Introduction
     3.2 Linux Needs PnP
     3.3 Buses
     3.4 Configuring a PnP BIOS
        3.4.1 Do you have a PnP operating system?
        3.4.2 How are resources to be controlled?
        3.4.3 Reset the configuration?

  4. How To Deal With PnP Cards

     4.1 Introduction
     4.2 Disable PnP ?
     4.3 BIOS Configures PnP
     4.4 Isapnp
     4.5 Patch the Kernel to Make Linux PnP
     4.6 PnP Software and Documents

  5. Appendix

     5.1 Addresses
        5.1.1 ISA Bus Configuration Address (Read-Port etc.)
        5.1.2 Address ranges
        5.1.3 Address space
        5.1.4 Communicating Directly via Memory
     5.2 Interrupts --Details
     5.3 PCI Interrupts
     5.4 Isolation



  ______________________________________________________________________

  1.  Introduction

  1.1.  Copyright, Trademarks, Disclaimer, & Credits

  1.1.1.  Copyright

  Copyright (c) 1998 by David S. Lawyer. Please freely copy and
  distribute (sell or give away) this document.  For corrections and
  minor changes contact the maintainer.  Otherwise you may create
  derivative works and distribute them provided you:

  1. Discuss it with the maintainer (if there is one).  2. Put the
  derivative work at the mirrored LDP Internet site for free
  downloading.  3. License the work in the spirit of this license or use
  GPL.  4. Give due credit to previous authors and major contributors.


  1.1.2.  Trademarks

  If certain words are trademarks, the context should make it clear to
  whom they belong.  For example "MS Windows" (or just "Windows")
  implies that "Windows" belongs to Microsoft (Micro$oft).


  1.1.3.  Disclaimer

  Much of the info in this HOWTO was obtained from Serial-HOWTO, the
  Internet, etc. and may be unreliable.  While I haven't intentionally
  tried to mislead you, there are likely a number of errors in this
  document.  Please let me know about them.  Since this is free
  documentation, it should be obvious that neither I nor previous
  authors can be held legally responsible for any errors.


  1.2.  Future Plans: You Can Help

  Please let me know of any errors in facts, opinions, logic, spelling,
  grammar, clarity, links, etc.  But first, if the date is over a months
  old, check to see that you have the latest version.  Please send me
  any info that you think belongs in this document.

  I haven't studied in detail either isapnptools nor David Howells
  patches to the kernel.  Nor do I fully understand how PnP is
  configured by the BIOS.  Thus this HOWTO is incomplete and may be
  inaccurate (let me know where I'm wrong).  In this HOWTO I've used ??
  to indicate that I don't really know the answer.  Would you like to
  improve on (rewrite) and maintain this HOWTO?  I'm looking for someone
  to turn it over to.


  1.3.  New Versions of this HOWTO

  New versions of the Plug-and-Play-HOWTO will be available to browse
  and/or download at LDP mirror sites.  For a list of mirror sites see:
  <http://sunsite.unc.edu/LDP/mirrors.html>.  Various formats are
  available.  If you only want to quickly check the date of the latest
  version look at:  <http://sunsite.unc.edu/LDP/HOWTO/Plug-and-Play-
  HOWTO.html>.


  2.  What PnP Should Do: Allocate "Resources"



  2.1.  What is Plug-and-Play (PnP)?

  Oversimplified, Plug-and-Play is a way to automatically tell the
  software (device drivers) where to find various pieces of hardware
  (devices) such as modems, network cards, sound cards, etc.  Plug-and-
  Play's task is to match up physical devices with the software (device
  drivers) that operates them and to establish channels of communication
  between each device and its driver.  More precisely, PnP allocates the
  following "resources" to both drivers and hardware: I/O addresses,
  IRQ's, DMA channels (ISA bus only), and memory regions.  If you don't
  understand what these 4 items are read the following subsections.
  Once these resources have been assigned, the names for such devices in
  the /dev directory are ready to use.

  This PnP assignment of certain resources is sometimes called
  "configuring" but it is only a low level type of configuring.  Even
  with PnP fully utilized, much configuring of devices is done by other
  than PnP.  For modem configuration, an "init string" is sent to the
  modem over the I/0 address "channel".  This "init string" has nothing
  to do with PnP although the "channel" used to send it to the modem was
  allocated by PnP.  Setting the speed (and many other parameters) of a
  serial port is done by sending messages to the device driver from
  programs run by the user (often automatically boot-time).  This
  configuring also has nothing to do with PnP.  Thus when talking about
  PnP, "resources" means only a limited subset of resources and
  "configuring" means only a certain type of configuring.


  2.2.  How a Computer Finds Devices (and conversely)

  A computer consists of a CPU/processor to do the computing and memory
  to store programs and data.  In addition, there are a number of
  devices such as various kinds of disk-drives, a video card, a
  keyboard, network cards, modem cards, sound cards, serial and parallel
  ports, etc.  There is also a power supply to provide electric energy,
  various buses on a motherboard to connect the devices and the CPU
  together, and a case to put all this into.

  In olden days most all devices had their own plug-in cards (printed
  circuit boards).  Today, in addition to plug-in cards, many "devices"
  are small chips permanently mounted on a single board called the
  "motherboard".  Cards which plug into the motherboard may contain more
  than one device.  Memory chips are also sometimes considered to be
  devices but are not plug-and-play in the sense used in this HOWTO.

  For the computer system to work right, each device must be under the
  control of its "device driver" (software which is a part of the
  operating system and which runs on the CPU).  Device drivers are
  associated with "special files" in the /dev directory although they
  are not really files.  They have names such as hda1 (first partition
  on hard drive a), ttyS0 (the first serial port), eth1 (the second
  ethernet card), etc.  To make matters more complicated, the particular
  device driver selected, say for eth1, will depend on the type of
  ethernet card you have.  Thus eth1 can't just be assigned to any
  ethernet driver.  It must be assigned to a certain driver that will
  work for the type of ethernet card you have installed.  To control a
  device, the CPU (under the control of the device driver) sends
  commands (and data) to and reads info from the various devices.  In
  order to do this each device driver must know the address used for
  such communication.  Knowing such an address is equivalent to setting
  up a communication channel, even though the physical "channel" is
  actually the data bus inside the PC which is shared with almost
  everything else.

  The communication channel is actually a little more complex than
  described above.  An "address" is actually a range of addresses and
  there is a reverse part of the channel (known as interrupts) which
  allows devices to send an urgent "help" request to their device
  driver.


  2.3.  I/O Addresses, etc.

  PC's have 3 address spaces: I/O, main memory, and configuration (only
  on the PCI bus).  Only the first two (memory and I/O) are configured
  by PnP.  All of these 3 types of addresses share the same bus inside
  the PC.  But the voltage on certain dedicated wires tells all devices
  which "space" an address is in: I/O, main memory, or configuration.
  Devices are normally located in I/O address space (although in some
  cases they are also allocated space in main memory).  An I/0 address
  is sometimes just called "I/O", "IO", "i/o" or "io".  The term "I/O
  port" also used.  There are two main steps to allocate the I/O
  addresses (or other resources such as interrupts).:


  1. Set the I/O address, etc. on the card (in one of its registers)

  2. Let its device driver know what this I/O address, etc. is


  The two step process above is something like the two part problem of
  finding someone's house number on a street.  You must obtain (and
  write down) the house number and and someone must install a number on
  the front of the house so that it may be found.  In computers, the
  device driver must obtain the address and the device hardware must
  install the same address in one of its registers.  Both of these must
  be done, but some people make the mistake of doing only one of these
  and then wonder why the computer can't find the device.  For example,
  they will use "setserial" to assign an address to a serial port
  without realizing that this only tells the driver that this is the
  address.  It doesn't set the address in the serial port hardware
  itself and if you told the driver the wrong address you're in trouble.
  Now to explain (in the next 3 sections) some other "resources" which
  may be assigned:  ``IRQ's'', ``DMA Channels'', and ``Memory Regions''.


  2.4.  IRQ's --Overview

  After reading this you may read ``Interrupts --Details'' for some more
  details.  The following is intentionally oversimplified:  Besides the
  address, there is also an interrupt number to deal with (such as
  IRQ5).  It's called an IRQ (Interrupt ReQuest) number.  We already
  mentioned above that the device driver must know the address of a card
  in order to be able to communicate with it.  But what about
  communication in the opposite direction?  Suppose the the device needs
  to tell its device driver something immediately?  Thus the device
  needs to know the address (or the like) of it's device driver so that
  it can call it for help.  For example, the device may have just
  received a lot of bytes destined for main memory and the device needs
  to call its driver to fetch these bytes at once and transfer them from
  the device's nearly full buffer into main memory.

  The device calls for such help by putting a voltage on an interrupt
  wire (part of the bus).  There are the equivalent of 16 wires and each
  wire leads (indirectly) to a certain device driver.  Each wire has a
  unique IRQ (Interrupt ReQuest) number.  The device must put its
  interrupt on the correct wire and the device driver must listen for
  the interrupt on the correct wire.  Which wire it's put on is
  determined by the IRQ number stored in the device.  This same IRQ
  number must be known to the device driver so that the device driver
  knows which IRQ line to listen to.

  On the ISA bus each device needs its own unique IRQ number (except
  that two or more serial ports may share IRQs starting with kernel
  2.2).  For the PCI bus, sharing of IRQs is allowed.


  2.5.  DMA Channels

  This is not used much since true DMA is only for the ISA bus and the
  equivalent of DMA on the PCI bus is both much faster and doesn't
  require a "DMA channel".  DMA stands for "Direct Memory Access".  This
  is where a device is allowed to take over the main computer bus from
  the CPU and transfer bytes directly to main memory.  Normally the CPU
  would make such a transfer in a two step process: 1. reading from the
  I/O memory space of the device, putting these bytes into the CPU
  itself  2. writing these byte from the CPU to main memory.  With DMA
  it's usually a one step process of sending the bytes directly from the
  device to memory.  The device must have such capabilities built into
  its hardware and thus not all devices can do DMA.  While DMA is going
  on the CPU can't do much since the main bus is being used by The DMA
  transfer.

  The PCI bus doesn't really have any DMA but instead it has something
  even better: bus mastering.  It works something like DMA and is
  sometimes called DMA (for example, hard disk drives that call
  themselves "UltraDMA").  It allows devices to temporarily become bus
  masters and to transfer bytes almost like the bus master was the CPU.
  It doesn't use any channel numbers since the organization of the PCI
  bus is such that the PCI hardware knows which device is currently the
  bus master and which device is requesting to become a bus master.
  Thus there is no allocation of DMA channels for the PCI bus.

  When a device on the ISA bus wants to do DMA it issues a DMA-request
  using dedicated DMA request wires much like an interrupt request.  DMA
  actually could have been handled by using interrupts but this would
  introduce some delays so it's faster to do it by having a special type
  of interrupt known as a DMA-request.  Like interrupts, DMA-request are
  numbered so as to identify which device is making the request.  This
  number is called a DMA-channel.  Since DMA transfers all use the main
  bus (and only one can run at a time) they all actually use the same
  channel but the "DMA channel" number serves to identify who is using
  the "channel".  Hardware registers exist on the motherboard which
  store the current status of each "channel".  Thus in order to issue a
  DMA-request, the device must know its DMA-channel number which must be
  stored in a register on the physical device.


  2.6.  Memory Regions

  Some devices are assigned address space in main memory as well as in
  I/O address space.  When you plug in such a card, you are in effect
  also plugging in a memory module (for main memory, not just I/O
  memory).  This memory is shared between the device and the CPU
  (running the device driver).  This memory can serve as a means of
  direct data "transfer" between the device and main memory.  It's not
  really a transfer since the device puts data into its own memory which
  also happens to be main memory.  Both the card and the device driver
  need to know where it is.  The memory address are likely to be very
  high so that they do not conflict with the lower addresses of the
  memory chips in your computer.


  2.7.  "Resources" in Two Places

  Thus device drivers must be "attached" in some way to the hardware
  they control.  This is done by supplying "resources" (I/O, Memory,
  IRQ's, DMA's) to both the physical device and the device driver
  software.  For example, in the case of a serial port there are only 2
  (out of 4 possible) resources: an IRQ and an I/O address.  Both of
  these values must be supplied to the device driver and the physical
  device.  The driver (and its device) is then given a name in the /dev
  directory (such as ttyS1).  The address and IRQ number is stored by
  the physical device in a register on the card (or in a chip on the
  motherboard).


  2.8.  The Problem

  The architecture of the PC provides only a limited number of IRQ's,
  DMA channels, I/O address, etc.  If there were only several devices
  and they all had standardized resource (such as unique I/O addresses
  and IRQ numbers) there would be no problem of attaching device drivers
  to devices.  Each device would have a fixed resources which would not
  conflict with any other device on your computer.  No two devices would
  have the same I/O address, there would be no IRQ conflicts, etc.  Each
  driver would be programmed with the I/O address, IRQ, etc. hard-coded
  into the program.  Life would be simple.

  But it's not.  Not only are there so many different devices today that
  conflicts are likely, but but one sometimes needs to have more than
  one of the same type of device.  For example one may want to have a
  few different disk-drives, a few serial ports, etc.  For these reasons
  devices need to have some flexibility so that they can be set to
  whatever address, IRQ, etc. is needed to avoid conflicts.  But some
  IRQ's and addresses are pretty standard such as the ones for the clock
  and keyboard.  These don't need such flexibility.

  Besides the problem of conflicting allocation of resources, there is a
  problem of making a mistake in telling the device driver what the
  resources are.  For example, suppose that you enter IRQ 4 in a
  configuration file when the device is actually set at IRQ 5.  This is
  another type of resource allocation error.

  The allocation of resources, if done correctly, also establishes
  channels of communication between physical hardware and their device
  drivers.  For example, if a certain I/O address range (resource) is
  allocated to both a device driver and a piece of hardware, then this
  has established a one-way communication channel between them.  The
  driver may send commands and info to the device.  It's actually a
  little more than one-way since the driver may get information from the
  device by reading it's registers.  But the device can't initiate any
  communication this way.  Allocating an IRQ makes it a two-way
  communication channel where both the driver and the device can
  initiate communication.


  2.9.  PnP Finds Devices Plugged Into Serial Ports

  Devices that plug into the serial port can also be Plug-and-Play.
  Since only the serial port itself needs resources (an IRQ and I/O
  address) there are no resources to allocate to such plug-in devices.
  Thus PnP is not really needed for them.

  However, a PnP operating system will find them and know what model of
  device is there.  Then it may be able to find a device driver for it
  so that you don't have to tell an application program that you are
  using say /dev/ttyS1.  Since you should be able to manually tell your
  computer (via a configuration file, etc.) what serial port the device
  is on (and possibly what model number it is) you should not really
  need this "serial" feature of PnP.



  3.  The Plug-and-Play (PnP) Solution

  3.1.  Introduction

  Plug-and_Play (PnP) is a way to automate the assignment of PnP
  resources to hardware and the corresponding software.  That is, to
  match up devices and their device drivers and specify their
  communication channels.  Before Plug-and-Play the resources were set
  on hardware devices by jumpers and software drivers were assigned
  resources by configuration files (or the like) or by probing the for
  the device (which didn't always work right).

  With full PnP (which doesn't always work right either), both a PnP
  BIOS and the operating system participate.  When the computer is first
  turned on the BIOS chip runs its program to get the computer started.
  If the operating system is stored on the hard-drive (as it normally
  is) then the BIOS must know about the hard-drive.  If the hard-drive
  is PnP then the BIOS may use PnP methods to find it.  Also, in order
  to configure the BIOS when the computer starts up, a screen (video
  card) and keyboard is required so the BIOS must PnP-configure these
  devices if needed.

  Once the BIOS has identified the hard-drive, the video card, and the
  keyboard it is ready to "boot" (load the operating system from the
  hard-disk).  If you've told the BIOS that you have a PnP operating
  system, it should do this and let the operating system finish the PnP
  configuring.  Otherwise, a PnP-BIOS will likely try to do the rest of
  the PnP configuring itself.


  3.2.  Linux Needs PnP

  PnP was invented by Wintel (Microsoft and Intel).  Partly for this
  reason, and partly due to dislike of the way it was implemented there
  has been some justified prejudice against PnP in the Linux community.
  But like it or not, most all hardware today is PnP and Linux has no
  choice but to deal effectively with PnP.

  Linux users should not need to delve into the details of PnP to
  configure devices as they now need to.  The solution would be a
  standardized version of Linux that supports Plug-and-Play.  A patch to
  the kernel has been written although most drivers don't support it.
  It's not part of standard Linux.  See ``Patch Kernel''.


  3.3.  Buses

  PnP is intended to work on any bus such as ISA and PCI.  ISA is the
  old bus of the old IBM PC's while PCI is a newer and faster bus from
  Intel.  Eventually, the ISA bus should become extinct.  The PCI bus
  reserved many configuration addresses on the bus for configuring (by
  PnP or otherwise).  Linux uses some of these addresses to find out
  what PCI devices you have and puts information about them in the
  /proc/pci "file".

  For the ISA bus there is a real problem with implementing PnP since
  unlike the PCI bus which was designed for PnP, no one had PnP in mind
  when the ISA bus was designed and there are almost no I/O addresses
  available for PnP to use.  As a result, the way PnP is handled on the
  ISA bus is complicated and requires that each PnP device be assigned a
  temporary "handle" by the PnP program so that one may address it for
  PnP configuring.  Assigning these "handles" is call "isolation".  See
  ``Isolation'' in the Appendix for the complex details.



  3.4.  Configuring a PnP BIOS

  When the computer is first turned on, the BIOS runs before the
  operating system is loaded.  Newer BIOSs are PnP and will configure
  some or all of the PnP devices.  For most PnP BIOSs there is no way to
  disable PnP so you have to live with it.  Here are some of the choices
  which may exist in your BIOS (sometimes called CMOS) menu:


    ``Do you have a PnP operating  system?''

    ``How are resources to be controlled?''

    ``Reset the configuration?''


  3.4.1.  Do you have a PnP operating system?

  If you say yes, then the PnP BIOS will start to PnP-configure the
  hard-drive, video card, and keyboard to make the system bootable.  But
  it will leave it up to the operating system to finish the
  configuration job.  It may do an ``Isolation'' on the ISA bus leaving
  the devices disabled but ready to be configured by the operating
  system.  If your operating system doesn't do configuring (some Linux
  patched versions do), you probably should not say yes since the BIOS
  might leave the ISA devices it hasn't configured in a disabled state
  ??

  If you say no, then the BIOS will do the configuring itself.  Unless
  you have added new PnP devices, it should use the previous
  configuration which it has stored in non-volatile memory.  If the last
  session on your computer was with Linux, then there should be no
  change in configuration.  But if the last session was with Windows 95
  or 98 (which are PnP) then Windows may have set up the configuration
  differently than what you want under Linux.  You may check on how it's
  configured when running Windows and then assume that under Linux it
  remains the same.  This is one way to deal with PnP: Just accept
  whatever configuration Windows 9x gives it.  When you are first
  configuring under Windows9x, you may tell the BIOS that you have a PnP
  OS and then later on change the answer to no.  When you add a new
  device, the BIOS alone may be able to configure it too without help
  from Windows but it might not do the configuring as well ??

  You can always have isapnp run at the startup of Linux to change the
  ISA configuration to what you want under Linux.  This is of no help
  for PCI cards but you can always check how they are configured by
  looking at /proc/pci.  Then you need to make sure that this matches
  your Linux configuration files ("setserial", lilo.conf, etc.) for the
  driver being used.  See ``BIOS Configures PnP'' for more info.


  3.4.2.  How are resources to be controlled?

  This may involve just deciding how to allocate IRQ's and DMA's.  It
  set to "auto", the bios will do the allocation.  If set to manual, you
  enter another menu and are able to reserve some IRQ's for use on
  "legacy" (non-pnp) cards.  Now the BIOS may or may not know about your
  legacy cards.  If it knows about them, then try using "auto".  If it
  doesn't know about them then manually reserve the IRQ's needed for the
  legacy ISA cards and let the rest be for the BIOS PnP to allocate.
  The BIOS will only know about your legacy cards if you ran ICU (or the
  like) under Windows to tell the BIOS about them.  The BIOS will then
  store this information in its non-volatile data-base.



  3.4.3.  Reset the configuration?

  This will erase the BIOSs data-base of how your PnP devices should be
  configured as well as the list of how legacy (non-PnP) devices are
  configured.  Never do this unless you are convinced that this data-
  base is wrong and needs to be remade.  It was stated somewhere that
  you should do this only if you can't get your computer to boot.  If
  the BIOS loses the data on legacy devices, then you'll need to run ICA
  again under windows to reestablish this data.


  4.  How To Deal With PnP Cards

  4.1.  Introduction

  Today most all new internal boards (cards) are Plug-and-Play (PnP).
  Some of these have jumpers (or this like) which may be changed to
  disable PnP.  Since software exists in Linux (and Dos/Windows) to
  handle PnP, it is sometimes best to keep PnP enabled even when you
  have the option of disabling it.  If you patch the kernel for Plug-
  and-Play it not only configures the hardware by putting resource
  information into its registers but it also tries to provides this
  information to the driver software so that you may not need to
  configure it.  For example, for a serial port you may not need to use
  "setserial".  Unfortunately, most drivers don't yet support it.

  If you have a PnP card, then your have one or more of the following
  options for configuring it:


    ``Disable PnP''  by jumpers (but many cards can't do this) or
     special software

    ``BIOS Configures PnP'' (only if you have a PnP BIOS)

    ``Isapnp''(is a program you can always use to configure PnP devices
     on the ISA bus (not for PCI devices)

    ``Patch Kernel'' to transform it Linux into a PnP operating system


  4.2.  Disable PnP ?

  Many devices are PnP only with no option for disabling it.  If
  possible, it may be a lot simpler to just disable PnP but don't forget
  to tell the BIOS the resources that it uses.  There are also some
  reasons why you might not want to disable PnP:


  1. If you have MS Windows on the same machine, then you may want to
     allow PnP under MS Windows to configure your devices differently.

  2. The range of selection for IRQ numbers (or port addresses) etc.
     may be quite limited unless you use PnP.

  3. If it requires the use of Dos/Windows software to configure a non-
     PnP configuration, then someday you might not have Dos/Windows
     around anymore and will thus have difficulty changing the
     configuration.

  4. You have (or will have) other PnP devices that need configuring so
     that you'll need to provide for PnP anyway.

     Once configured as non-PnP devices, they can't be configured by PnP
     software or the BIOS (until you move jumpers and/or use the
     Dos/Windows configuration software again to enable PnP).
  4.3.  BIOS Configures PnP

  Your BIOS must obviously support PnP to do this.  To find out more
  about your BIOS, look on the Web.  Some BIOS may have minimal PnP
  capabilities and try to turn over the difficult parts of the
  configuration task to Window utilities (which can't happen under
  Linux).  In this case if the BIOS does maintain a configuration data
  base (in non-volatile memory), you might try to help set up this data
  base by using the ICU under DOS/Windows or if you have Windows9x
  (which are PnP OS's) you could just let Windows do it without using
  ICU.

  Before you run Linux you set up the BIOS for "Not a PnP Operating
  System" (or the like).  See ``Configuring a PnP BIOS'' This will make
  the BIOS do the configuring instead of leaving it to the operating
  system.

  The BIOS's non-volatile data-base is called the ESCD (Extended System
  Configuration Data).  The ESCD not only stores the configuration of
  PnP devices but stores configuration information of non-PnP devices so
  as to avoid conflicts.  When you install a new non-PnP device you are
  supposed to tell the BIOS's ESCD about it by running the Dos/Windows
  ICU (Intel Configuration Utility) program prior to installation.  You
  will also need to run this to tell the ESCD about the existing non-PnP
  devices on the PC (unless someone else has already done so).

  The non-volatile ESCD configuration is usually saved on a chip and
  remains intact when the power is off, but sometimes it's put on a
  hard-drive??  Each time the BIOS starts up under Linux it should
  configure things this way.  You may want to take notes on how ICU (and
  the BIOS) has configured things (or print them out).  However, if you
  add a new non-PnP device you need to run the ICU program again to let
  the BIOS put that info into it's data base.  If it's PnP then the BIOS
  will automatically configure it and hopefully not change the
  configuration on any of the other existing devices on your PC.  But it
  might have to reconfigure some of the existing devices in order to
  allocate the required resources to the new device.

  How has the BIOS configured it?  To determine this under Linux may not
  be easy.  But it is easy for the PCI bus: just look at /proc/pci.  For
  the ISA bus it's not so easy.  Using pnpdump one may find PnP cards on
  the ISA bus and also how they would like to be configured but there is
  no guarantee that they have been actually configured like this.  One
  may run some isapnp commands using the PEEK keyword to find out what
  the I/O address and IRQ is but this is complicated.  Don't confuse the
  read-port address which pnpdump "trys" (and finds something there)
  with the I/O address of the found device.  They are not the same.

  Note that under Dos/Windows the configuration used is also put in a
  Windows file on the hard disk so the the operating system knows where
  everything is.  This doesn't happen in Linux which usually auto-
  detects devices.


  4.4.  Isapnp

  Unfortunately, the documentation for isapnp was difficult to
  understand unless you knew the basics of PnP.  This HOWTO should help
  you understand it.  isapnp is only for PnP devices on the ISA bus
  (non-PCI).  Running the Linux program "isapnp" at boot-time will
  configure such devices to the resource values you set in
  /etc/isapnp.conf.  You need the package isapnptools, available in many
  distributions of Linux.  Type "locate pnp" to see what you may already
  have available for isapnp.  If your Linux distribution automatically
  installed isapnptools, isapnp may already be running at startup.  In
  this case, all you need to do is to edit /etc/isapnp.conf per "man
  isapnp.conf".  Note that this is like manually configuring PnP since
  you make the decisions as to how to configure as you edit the
  configuration file.  You can use the program "pnpdump" to help create
  the configuration file.  If you use "isapnp" like this and have a PnP
  BIOS, should you tell the BIOS (when you set it up) that you have a
  PnP operating system ??

  If you only ran isapnp once to configure ISA-PnP devices but failed to
  run isapnp each time the computer starts up then if you have Windows
  9x on the same PC the following problem might occur: When you use
  Windows 9x, Windows may configure your PnP cards differently in such a
  way that it doesn't work right (if at all) when you go back to use
  Linux.


  4.5.  Patch the Kernel to Make Linux PnP

  David Howells has created a patch to do this called "Linux Kernel
  Configuration/Resource Manager.  The resulting kernel is is claimed to
  be stable but bugs have been reported.  It includes documentation:
  serial.txt to show how to deal with the serial port.  It provides
  "files" in the /proc tree so that you can see what is going on and can
  echo commands into one of these files for custom configuration.  One
  problem is that most device drivers don't know about it so that you
  still may have to use the traditional configuration files, etc. for
  configuration.  See  <http://lucifer.hemmet.s-hem.chalmers.se/~dwh>


  4.6.  PnP Software and Documents


    See  <http://www.microsoft.com/hwdev/respec/pnpspecs.htm> for
     pointers to specifications of PnP

    Book: PCI System Architecture, 3rd ed. by Tom Shanley +, MindShare
     1995.  Covers inherent PnP on the PCI bus.

    Book: Plug and Play System Architecture, by Tom Shanley, Mind Share
     1995.  Details of PnP on the ISA bus.  Only a brief overview of PnP
     on the PCI bus.


  5.  Appendix

  5.1.  Addresses

  There are three types of addresses: main memory addresses, I/O
  addresses and configuration addresses.  On the PCI bus configuration
  addresses constitute a separate address space just like I/O addresses
  do.  Except for the case of ISA configuration addresses, whether or
  not an address on the address bus (or shared address-data bus for PCI)
  is a memory address, I/O address, or configuration address depends
  only on the voltage on other wires (traces) of the bus.


  5.1.1.  ISA Bus Configuration Address (Read-Port etc.)

  For the ISA bus, there is technically no configuration address space,
  but there is a special way for the CPU to access PnP configuration
  registers on the PnP cards.  For this purpose 3 @ I/O addresses are
  allocated.  This is not 3 addresses for each card but 3 addresses
  shared by all cards.  Each card listens at the same address called a
  write-port

  The 3 addresses are named read-port, write-port, and address-port.
  The ports are one byte in size.  Each PnP card has a number of
  registers so that just 3 addresses are not even sufficient for a
  single card.  To communicate with a certain card, the card number
  (handle) is sent to all cards at the write-port address.  After that
  only that one card is listening.  Then the address of the register
  which is to be dealt with is sent to the address-port (of all cards
  --but only one is listening).  Next either a read is made on the read-
  port or a write is made on the write-port.

  The write-port is always A79 and the address-port is always 279.  But
  the read-port is not fixed but is set by the configuration software at
  some address that will supposedly not conflict with any other ISA
  card.  If there is a conflict, it will change the address.  All PnP
  cards get "programmed" with this address.  Thus if you use say isapnp
  to set or check configuration data you need to know the read-port
  address.


  5.1.2.  Address ranges

  The term "address" is sometimes used in this document to mean a
  contiguous range of addresses.  Since addresses are given in bytes, a
  single address only contains one byte but I/O (and main memory)
  addresses need more than this.  So a range of say 8 bytes is often
  used for I/O address while the range for main memory addresses
  allocated to a device is much larger.  For a serial port (an I/O
  device) it's sufficient to give the starting I/O address of the device
  (such as 3F8) since it's well known that the range of addresses for
  this device is only 8 bytes.  The starting address is known as the
  "base address".


  5.1.3.  Address space

  For ISA, to access both I/O and (main) memory address "spaces" the
  same address bus is used (the wires used for the address are shared).
  How does the device know whether or not an address which appears on
  the address bus is a memory address or I/O address?  Well, there are 4
  dedicated wires on the bus that convey this information and more.  If
  a certain one of these 4 wires is asserted, it says that the CPU wants
  to read from an I/O address, and the main memory ignores the address
  on the bus.  The other 3 wires serve similar purposes.  In summary:
  Read and write wires exist for both main memory and I/O addresses (4
  wires in all).

  For the PCI bus it's the same basic idea also using 4 wires but it's
  done a little differently.  Instead of only one or the four wires
  being asserted, a binary number is put on the wires (16 different
  possibilities).  Thus more info may be conveyed.   Four of these 16
  numbers serve the I/O and memory spaces as in the above paragraph.  In
  addition there is also configuration address space which uses up two
  more numbers.  Ten extra numbers are left over for other purposes.


  5.1.4.  Communicating Directly via Memory

  Traditionally, most I/O devices used only I/O memory to communicate
  with the CPU.  For example, the serial port does this.  The device
  driver, running on the CPU would read and write data to/from the I/O
  address space and main memory.  A faster way would be for the device
  itself to put the data directly into main memory.  One way to do this
  is by using ``DMA Channels''.  Another way is to allocate some space
  in main memory to the device.  This way the device reads and writes
  directly to main memory without having to bother with DMA.  Such
  device normally have both an I/O address and a main memory address.


  5.2.  Interrupts --Details

  Interrupts convey a lot of information but only indirectly.  The
  interrupt signal (a voltage on a wire) just tells a chip called the
  interrupt controller that a certain device needs attention.  The
  interrupt controller then signals the CPU.  The CPU find the driver
  for this device and runs a part of it known as an "interrupt service
  routine" (or "interrupt handler").  This "routine" tries to find out
  what has happened and then deals with the problem such a transferring
  bytes from (or to) the device.   This program (routine) can easily
  find out what has happened since the device has registers at addresses
  known to the the driver software (provided the IRQ number and the I/O
  address of the device has been set correctly).  These registers
  contain status information about the device .  The software reads the
  contents of these registers and by inspecting the contents, finds out
  what happened, and takes appropriate action..

  Thus each device driver needs to know what interrupt number (IRQ) to
  listen to.  On the PCI bus (and for the serial ports on the ISA bus
  starting with Kernel 2.2) it's possible for two (or more) devices to
  share the same IRQ number.  This is done by the CPU running all
  interrupt service routines for all devices using that interrupt.  The
  first thing the first service routine does is to check to see if an
  interrupt actually happened for its device.  If there was no interrupt
  (false alarm) it likely will exit and the next service routine starts,
  etc.


  5.3.  PCI Interrupts

  PCI interrupts are different but since they are normally mapped to
  IRQ's they behave in about the same way.  A major difference is that
  PCI interrupts may be shared.  For example IRQ5 may be shared between
  two PCI devices.  This sharing ability is automatic: you don't need
  special hardware or software.  There have been some reports of
  situations where such sharing didn't work, but it's likely due to a
  defect in the device driver software.  All device drivers for PCI
  devices are supposed to provide for interrupt sharing.  Note that you
  can't share the same interrupt between the PCI and ISA bus.  However,
  illegal sharing will work provided the devices which are in conflict
  are not in use at the same time.  "In use" here means that a program
  is running which "opened" the device in it's C programming code.

  You may need to know some of the details of the PCI interrupt system
  in order to set up the BIOS's CMOS or to set jumpers on old PCI cards.
  The PCI bus has INTA# thru INTD# (A, B, C, and D) which are 4
  interrupts.  The specs provide for these 4 interrupts for each card so
  that for a 7-slot system there could be 7 x 4 = 28  different
  interrupt lines.  But the specs permit a fewer number of interrupt
  lines.  This is not too restrictive since interrupts may be shared.
  Many PCI buses seem to be made with only 4 interrupt lines.  Call
  these lines (wires or traces) W, X, Y, Z.  Suppose we designate the B
  interrupt from slot 3 as interrupt 3B.  Then wire W could be used to
  share interrupts 1A, 2B, 3C, 4D, 5A, 6B, 7C.  This is done by
  physically connecting wire W to wires 1A, 2B, etc.  Likewise wire X
  could be connected to wires 1B, 2C, 3D, 4A, 5B, 6C, 7D.  Then on
  startup, the BIOS maps the X, W, Y, Z to IRQ's.  After that it writes
  the IRQ that each device is mapped to into a hardware register in each
  device, so that the device (and anything interrogating the device)
  will know what IRQ it uses.

  The above mentioned wires X, W, Y, Z  are labeled per PCI specs as
  INTA#, INTB#, INTC# and INTD#.  This official PCI notation is
  confusing since now INTA# has 2 possible meanings depending on whether
  we are talking about a slot or the PCI bus.  For example, if 3C is
  mapped to X then we say that INTC# of slot 3 is cabled to INTA# (X) of
  the PCI bus.  Confusing notation.

  There's another requirement also.  A PCI slot must use the lower
  interrupt letters first.  Thus if a slot only uses one interrupt, it
  must be INTA#.  If it uses 2 interrupts they must be INTA# and INTB#,
  etc.  A card in a slot may have up to 8 devices on it but there are
  only 4 PCI interrupts for it.  This is OK since interrupts may be
  shared so that each of the 8 devices (if they exist) can have an
  interrupt.  The PCI interrupt letter of a device is often fixed and
  hardwired into the device.  Since the BIOS maps this to an IRQ, how it
  does this mapping determines the IRQ it uses.

  You might reason that using IRQ's is something from the ISA bus and
  might be slow, etc.  Not really.  The ISA Interrupt Controller Chip(s)
  has a direct interrupt wire going to the CPU so it can get immediate
  attention.  While signals on the ISA address and data buses need to go
  thru the PCI bus to get to the CPU, the IRQ interrupt signals go there
  almost directly.


  5.4.  Isolation

  This is only for the ISA bus.  Isolation is a complex method of
  assigning a temporary handle (id number or Card Select Number = CSN)
  to each PnP device on the ISA bus.  Since there are more efficient
  (but more complex) ways to do this, some might claim that it's a
  simple method.  Only one write address is used for PnP writes to all
  PnP devices so that writing to this address goes to all PnP device
  that are listening.  This write address is used to send (assign) a
  unique handle to each PnP device.  To assign this handle requires that
  only one device be listening when the handle is sent (written) to this
  common address.  All PnP devices have a unique serial number which
  they use for the process of isolation.  Doing isolation is something
  like a game.  It's done using the equivalent of just one common bus
  wire connecting all PnP devices and the isolation program.

  For the first round of the "game" all PnP devices listen on this wire
  and send out simultaneously a sequence of bits to the wire.  The
  allowed bits are either a 1 (positive voltage) or an "open 0" of no
  voltage (open circuit or tri-state).  Each PnP device just starts to
  sequentially send out its serial number, bit-by-bit, starting with the
  high-order bit, on this wire.  If any device sends a 1, a 1 will be
  heard on the wire by all other devices.  If all devices send an "open
  0" nothing will be heard on the wire.  The object is to eliminate (by
  the end of this first round) all but highest serial number device.
  "Eliminate" means to cease to listen anymore to the write address that
  all devices still in the game are still listening to.  This is also
  called "dropping out".  (Note that all serial numbers are of the same
  length.)

  First consider only the high order bit of the serial number which is
  put on the wire first by all devices which have no handle yet.  If any
  PnP device sends out a 0 (open 0) but hears a 1, this means that some
  other PnP device has a higher serial number, so it temporarily drops
  out of this round and doesn't listen anymore until the round is
  finished (when a handle is assigned to the winner: the highest serial
  number).  Now the devices still in the game all have the same leading
  digit (a 1) so we may strip off this digit and consider only the
  resulting "stripped serial number" for future participation in this
  round.  Then go to the start of this paragraph and repeat until the
  entire serial number has been examined for each device (see below for
  the all-0 case).

  Thus it's clear that the highest serial number will not be eliminated
  from the game.  But what happens if the leading digits (of the
  possibly stripped serial numbers) are all 0?  In this case an "open 0"
  is sent on the line and all participants stay in the game.  If they
  all have a leading 0 then this is a tie and the 0's are stripped off
  just like the 1's were in the above paragraph.  The game then
  continues as the next digit (of the serial number) is sent out.

  At the end of the round (after the low-order bit of the serial number
  has been sent out by whatever participants remain) only one PnP device
  with the highest serial number remains.  It then gets assigned a
  handle and drops out of the game permanently.  Then all the dropouts
  from the last round (that don't have a handle yet) reenter the game
  and a new round begins with one less participant.  Eventually, all PnP
  devices are assigned handles.  It's easy to prove that this algorithm
  works.

  Once all handles are assigned, they are used to address each PnP
  device and send it a configuration as well as to read configuration
  info from the PnP device.  Note that these handles are only used for
  PnP configuration and are not used for normal communication with the
  PnP device.  When the computer starts up, all of the handles are lost
  so that a PnP BIOS usually does the isolation process again each time
  you start your PC.

  END OF Plug-and-Play-HOWTO











































