Партнёры:
Хостинг:
If you don't understand this section, read the next section How a Computer Finds Devices (and conversely)
Oversimplified, Plug-and-Play automatically tells 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 physical device and its driver. In order to achieve this, PnP allocates the following "bus-resources" to both drivers and hardware: I/O addresses, memory regions, IRQs, DMA channels (ISA bus only). These 4 things are sometimes called "1st order resources" or just "resources". If you don't understand what these 4 bus-resources are, read the following subsections of this HOWTO: I/O Addresses, IRQs, DMA Channels, Memory Regions. An article in Linux Gazette regarding 3 of these bus-resources is Introduction to IRQs, DMAs and Base Addresses. Once these bus-resources have been assigned (and if the correct driver is installed), the "files" for such devices in the /dev directory are ready to use.
This PnP assignment of bus-resources is sometimes called "configuring" but it is only a low level type of configuring. The /etc directory has many configuration files but most of them are not for PnP configuring. So most of the configuring of hardware devices has nothing to do with PnP or bus-resources. For, example the initializing of a modem by an "init string" or setting it's speed is not PnP. Thus when talking about PnP, "configuring" means only a certain type of configuring. While other documentation (such a for MS Windows) simply calls bus-resources "resources", I have used the term "bus-resources" so as to distinguish it from the multitude of other kinds of resources.
A computer consists of a CPU/processor to do the computing and RAM memory to store programs and data (for fast access). 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, the USB bus, serial and parallel ports, etc. There is also a power supply to provide electric energy, various buses on a motherboard to connect the devices to the CPU, 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 the "motherboard". Furthermore, 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". This is software which is a part of the operating system (perhaps loaded as a module) and 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 hda3 (third partition on hard drive a), ttyS1 (the second serial port), eth0 (the first ethernet card), etc.
To make matters more complicated, the particular device driver selected, say for example eth0, may depend on the type of ethernet card you have. Thus eth0 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. If the driver is a module, some of these assignments might be found in /etc/modules.conf (called "alias") while others may reside in an internal kernel table. For example, if you have an ethernet card that uses the "tulip" chip put "alias eth0 tulip" into /etc/modules.conf so that when your computer asks for eth0 it finds the tulip driver. Other device names may have a standard driver associated with them so the above isn't always required.
To control a device, the CPU (under the control of the device driver) sends commands and data to, and reads status and data from the various devices. In order to do this each device driver must know the address of the device it controls. 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.
This communication channel is actually a little more complex than described above. An "address" is actually a range of addresses so that sometimes the word "range" is used instead of "address". There could even be more that one range (with no overlapping) for a single device. Also, there is a reverse part of the channel (known as interrupts) which allows devices to send an urgent "help" request to their device driver.
PCs have 3 address spaces: I/O, main memory (IO memory), and configuration (except that the old ISA bus lacks a genuine "configuration" address space). All of these 3 types of addresses share the same bus inside the PC. But the presence or absence of voltage on certain dedicated wires on the PC's bus tells which "space" an address is in: I/O, main memory, (see Memory Ranges), or configuration. See Address Details for more details. Only two of these 3 address spaces are used for device I/O: I/0 and main memory. I/O stands for Input-Output.
Devices were originally located in I/O address space but today they may use space in main memory. An I/0 address is sometimes just called "I/O", "IO", "i/o" or "io". The terms "I/O port" or "I/O range" are also used. Don't confuse these IO ports with "IO memory" located in main memory. There are two main steps to allocate the I/O addresses (or some other bus-resources such as interrupts on the ISA bus):
Often, the device driver does both of these. The two step process above is something like the two part problem of finding someone's house number on a street. Someone must install a number on the front of the house so that it may be found and then you must obtain (and write down) this house number so that you can find the house. In computers the device hardware must first get the address it will use set a special register and then the device driver must obtain this address. Both of these must be done, either automatically by software or by entering the data manually into files. Problems may occur when only one of them gets done (or is attempted).
For manual PnP configuration 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 may use "setserial" to assign an address to a serial port without realizing that this only tells the driver an address. It doesn't set the address in the serial port hardware itself. If the serial port hardware doesn't have the address you told setserial (or doesn't have any address set in it) then you're in trouble.
An obvious requirement is that before the device driver can use an address it must be first set in the physical device (such as a card). Since device drivers often start up soon after you start the computer, they sometimes try to access a card (to see if it's there, etc.) before the address has been set in the card by a PnP configuration program. Then you see an error message that they can't find the card even though it's there (but doesn't yet have an address).
What was said in the last few paragraphs regarding I/O addresses applies with equal force to most other bus-resources: Memory Ranges, IRQs --Overview and DMA Channels. What these are will be explained in the next 3 sections. The exception is that IRQs on the PCI bus are not set by a card register but are set by a special routing chip on the motherboard.
Many devices are assigned address space in main memory. It's sometimes called "shared memory" or "memory-mapped IO" or "IO memory". This memory is physically located in the device. When discussing bus-resources it's often just called "memory", "mem", or "iomem". In addition to using such "memory", such a device might also use conventional IO address space. To see what mem is in use on your computer, look at /proc/iomem. This "file" includes the memory range used by your ordinary RAM memory chips but this really not strictly a part of iomem.
When you insert a card that uses iomem, you are in effect also inserting a memory module for main memory. A high address is selected for it by PnP so that it doesn't conflict with main memory chips. This memory can either be ROM (Read Only Memory) or shared memory. Shared memory is shared between the device and the CPU (running the device driver) just as IO address space is shared between the device and the CPU. This shared memory serves as a means of data "transfer" between the device and main memory. It's IO but it's not done in IO space. Both the card and the device driver need to know where it is.
ROM is different. It is likely a program (perhaps a device driver) which will be used with the device. It could be initialization code so that a device driver is still required. Hopefully, it will work with Linux and not just MS Windows. It may need to be shadowed which means that it is copied to your main memory chips in order to run faster. Once it's shadowed it's no longer "read only".
After reading this you may read Interrupts --Details for many more details. The following is intentionally oversimplified: Besides the address, there is also an interrupt number to deal with (such as IRQ 5). It's called an IRQ (Interrupt ReQuest) number or just an "irq" for short. 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 device needs to tell its device driver something immediately? For example, the device may have just received a lot of bytes destined for main memory and the device needs to tell its driver to fetch these bytes at once and transfer them from the device's nearly full buffer into main memory. Another example is to signal the driver that the device has finished sending out a bunch of bytes and is now waiting for some more bytes from the driver so it can send them too.
How should the device rapidly signal its driver? It may not be able to use the main data bus since it's likely already in use. Instead it puts a voltage on a dedicated interrupt wire (part of the bus) which is often reserved for that device alone. This voltage signal is called an Interrupt ReQuest (IRQ) or just an "interrupt" for short. There are the equivalent of 16 such wires in a PC 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 the device sends help requests 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 on.
Once the device driver gets the interrupt from the device it must find out why the interrupt was issued and take appropriate action to service the interrupt. On the ISA bus each device usually needs its own unique IRQ number. For the PCI bus and other special cases the sharing of IRQs is allowed and the IRQ assignment is determined by a programmable routing chip. See Interrupts --Details for how this works.
DMA channels are only for the ISA bus. 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:
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 resource 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-requests 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 special register on the physical device.
Thus device drivers must be "attached" in some way to the hardware they control. This is done by allocating bus-resources (I/O, Memory, IRQ's, DMA's) to both the physical device and the device driver software. For example, a serial port uses 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 also given a name in the /dev directory (such as ttyS1). The address and IRQ number is stored by the physical device in configuration registers on its card (or in a chip on the motherboard). For the case of jumpers, it's the location of the jumpers themselves that store the bus-resource configuration in the device hardware (on the card, etc.). For the case of PnP, the configuration register data is usually lost when the PC is powered down (turned off) so that the bus-resource data must be supplied to each device anew each time the PC is powered on.
The architecture of the PC provides only a limited number of IRQ's, DMA channels, I/O address, and memory regions. If there were only several devices and they all had standardized bus-resource data (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 addresses, there would be no IRQ conflicts, etc. Each driver would be programmed with the unique addresses, 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 frequent, 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 network cards, 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 bus-resources, there is a problem of making a mistake in telling the device driver what the bus-resources are for the case of manual configuration. 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 bus-resource allocation error.
The allocation of bus-resources, if done correctly, 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 other info to the device. It's actually a little more than one-way since the driver may get information from the device by reading its registers. But the device can't initiate any communication this way. To initiate communication the device needs an IRQ so it can send interrupts to its driver. This creates a two-way communication channel where both the driver and the physical device can initiate communication.
External devices that connect to the serial port via a cable (such as external modems) can also be called Plug-and-Play. Since only the serial port itself needs bus-resources (an IRQ and I/O address) there are no bus-resources to allocate to such plug-in devices. In this case, PnP is used only to identify the modem (read it's model code number). This could be important if the modem is a software modem (linmodem) and requires a special driver. There is a special PnP specification for such external serial devices (something connected to the serial port).
Linux doesn't support this yet ?? For a hardware modem, the ordinary serial driver will work OK so there's little need for using the special serial PnP to find a driver. You still need to tell the communications program what port (such as /dev/ttyS1) the modem is on. With PnP you wouldn't need to even do this. With the advent of software modems that have Linux drivers (linmodems), it would be nice to have the appropriate driver install itself automatically via PnP.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |