mirror of https://github.com/tLDP/LDP
updated
This commit is contained in:
parent
0b8f02f9ba
commit
1e5bdebda2
|
@ -1984,7 +1984,7 @@ nfs server attached by a Null-Modem parallel cable. </Para>
|
|||
Plug-and-Play-HOWTO</ULink>,
|
||||
<CiteTitle>The Linux Plug-and-Play HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: August 2001</CiteTitle>.
|
||||
<CiteTitle>Updated: March 2002</CiteTitle>.
|
||||
How to get your Linux system to support Plug-and-Play. </Para>
|
||||
</ListItem>
|
||||
|
||||
|
@ -2314,7 +2314,7 @@ Addresses Linux localization issues specific to Serbian users
|
|||
Serial-HOWTO</ULink>,
|
||||
<CiteTitle>Serial HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: November 2001</CiteTitle>.
|
||||
<CiteTitle>Updated: March 2002</CiteTitle>.
|
||||
Describes serial port features other than those which should be
|
||||
covered by other HOWTOs. Lists information on multiport serial cards
|
||||
and contains detailed technical information about the serial port
|
||||
|
|
|
@ -999,7 +999,7 @@ SCSI-Generic-HOWTO</ULink> for more current information.</emphasis> </Para>
|
|||
Serial-HOWTO</ULink>,
|
||||
<CiteTitle>Serial HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: November 2001</CiteTitle>.
|
||||
<CiteTitle>Updated: March 2002</CiteTitle>.
|
||||
Describes serial port features other than those which should be
|
||||
covered by other HOWTOs. Lists information on multiport serial cards
|
||||
and contains detailed technical information about the serial port
|
||||
|
@ -1257,7 +1257,7 @@ How to install and use PCMCIA Card Services for Linux. </Para>
|
|||
Plug-and-Play-HOWTO</ULink>,
|
||||
<CiteTitle>The Linux Plug-and-Play HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: August 2001</CiteTitle>.
|
||||
<CiteTitle>Updated: March 2002</CiteTitle>.
|
||||
How to get your Linux system to support Plug-and-Play. </Para>
|
||||
</ListItem>
|
||||
|
||||
|
|
|
@ -3,13 +3,15 @@
|
|||
<title> Plug-and-Play-HOWTO </title>
|
||||
<author>David S.Lawyer
|
||||
<tt><url url="mailto:dave@lafn.org"></tt>
|
||||
<date> v1.03, August 2001
|
||||
<date> v1.04, March 2002
|
||||
|
||||
<!--
|
||||
Change log:
|
||||
Change log:
|
||||
v1.04 March 2002 finding a device driver, PCI serial ports,
|
||||
alias example in modules.conf, PnP needed for linmodems
|
||||
v1.03 August 2001: error messages, boot-prompt parameters
|
||||
v1.02 July 2001: PCI config regs.
|
||||
v1.01 April 2001: less shortage today of bus-resouces, clarity in sect. 2,
|
||||
v1.01 April 2001: less shortage today of bus-resources, clarity in sect. 2,
|
||||
Windows 2000 OK (even if "not a PnP OS" in CMOS)
|
||||
v1.00 November 2000: "skip file" workaround for reconfiguring under Windows.
|
||||
PCI interrupt details: X, W were transposed, rewrote, mentioned MSI,
|
||||
|
@ -32,13 +34,13 @@ v0.02 Apr. 1999 /proc/... doesn't show hdw config (except pci)
|
|||
v0.01 Mar. 1999 serial PnP spec, PCI interrupts, no DMA on PCI,
|
||||
dumpregs for pnpdump , Bus Mastering DMA, clarity rewrites, pciutils
|
||||
kernel 2.2 /proc tree, IO range check, Windows may not update ESCD
|
||||
v0.00 Nov. 1998
|
||||
v0.00 Nov. 1998
|
||||
-->
|
||||
<abstract>
|
||||
Help with understanding and dealing with the complex Plug-and-Play
|
||||
(PnP) issue. How to get PnP to work on your PC (if it doesn't already).
|
||||
It doesn't cover what's called "Universal Plug and Play"
|
||||
(UPnP). See <ref id="UPnP_" name="Universal Plug and Play (UPnP)"
|
||||
(UPnP). See <ref id="UPnP_" name="Universal Plug and Play (UPnP)"
|
||||
</abstract>
|
||||
<toc>
|
||||
|
||||
|
@ -57,18 +59,18 @@ provided that you:
|
|||
|
||||
<enum>
|
||||
<item> If it's not a translation: Email a copy of your derivative work
|
||||
(in a format LDP accepts) to the author(s) and maintainer (could be
|
||||
the same person). If you don't get a response then email the LDP
|
||||
(Linux Documentation Project): submit@linuxdoc.org.
|
||||
(in a format LDP accepts) to the author(s) and maintainer (could be
|
||||
the same person). If you don't get a response then email the LDP
|
||||
(Linux Documentation Project): submit@linuxdoc.org.
|
||||
<item>License the derivative work in the spirit of this license or use
|
||||
GPL. Include a copyright notice and at least a pointer to the
|
||||
GPL. Include a copyright notice and at least a pointer to the
|
||||
license used.
|
||||
<item>Give due credit to previous authors and major contributors.
|
||||
</enum>
|
||||
|
||||
If you're considering making a derived work other than a
|
||||
translation, it's requested that you discuss your plans with the
|
||||
current maintainer.
|
||||
current maintainer.
|
||||
|
||||
<sect2>Disclaimer
|
||||
<p> While I haven't intentionally tried to mislead you, there are
|
||||
|
@ -84,12 +86,12 @@ be a trademark). Such trademarks belong to their respective owners.
|
|||
|
||||
<sect2> Credits
|
||||
<p>
|
||||
<itemize>
|
||||
<item> Daniel Scott proofread this in March 2000 and found many
|
||||
<itemize>
|
||||
<item> Daniel Scott proofread this in March 2000 and found many
|
||||
typos, etc.
|
||||
<item> Pete Barrett gave a workaround to prevent Windows from zeroing
|
||||
PCI IRQs.
|
||||
</itemize>
|
||||
</itemize>
|
||||
|
||||
<sect1> Future Plans; You Can Help
|
||||
<p> Please let me know of any errors in facts, opinions, logic,
|
||||
|
@ -112,21 +114,23 @@ url="http://linuxdoc.org/mirrors.html">. Various formats are
|
|||
available. If you only want to quickly check the date of the latest
|
||||
version look at: <url
|
||||
url="http://linuxdoc.org/HOWTO/Plug-and-Play-HOWTO.html">. The
|
||||
version you are now reading is: v1.03, August 2001 .
|
||||
version you are now reading is: v1.04, March 2002 .
|
||||
|
||||
<sect1> New in Recent Versions
|
||||
<p>
|
||||
v1.04 March 2002 finding a device driver, PCI serial ports,
|
||||
alias example in modules.conf, PnP needed for linmodems
|
||||
v1.03 August 2001: error messages, boot-prompt parameters
|
||||
v1.02 July 2001: PCI config regs. v1.01 April 2001: less shortage
|
||||
today of bus-resources, clarity in sect. 2, Windows 2000 OK (even if
|
||||
"not a PnP OS" in CMOS)
|
||||
v1.01 April 2001: less shortage today of bus-resources, clarity in sect. 2,
|
||||
v1.01 April 2001: less shortage today of bus-resources, clarity in sect. 2,
|
||||
Windows 2000 OK (even if "not a PnP OS" in CMOS)
|
||||
|
||||
The version 1.0 (Nov. 2000) was long overdue and recognized that the
|
||||
kernel is doing more in helping device drivers set up PnP. Kernel 2.4
|
||||
is significantly improved in this respect. There's still a lot of
|
||||
improvements needed in both this HOWTO and the way that Linux does
|
||||
improvement needed in both this HOWTO and the way that Linux does
|
||||
PnP.
|
||||
|
||||
<sect1> General Introduction. Do you need this HOWTO?
|
||||
|
@ -135,7 +139,7 @@ devices such as disks, sound cards, ethernet cards, modems, etc. It
|
|||
also does some low-level configuring of them. To be detected by PnP, the
|
||||
device must be designed for PnP. Non-PnP devices (or PnP devices which
|
||||
have been correctly PnP-configured), can often be detected by
|
||||
non-PnP methods.
|
||||
non-PnP methods.
|
||||
|
||||
While the Linux kernel has no centralized plug-and-play system, it
|
||||
does provide programs which various device drivers can use to do their
|
||||
|
@ -148,12 +152,32 @@ they not discovered or configured correctly by PnP) then you may need
|
|||
to read some of this HOWTO. You'll learn not only about PnP but also
|
||||
something about how communication takes place inside the computer.
|
||||
|
||||
If you're having problems with a device, first check to see that you
|
||||
have the right driver for a device, and that the driver is being found
|
||||
and used. If the driver is a module, type "lsmod" (as the root user)
|
||||
to see it it's loaded (in use). If it's not a module then it should
|
||||
be built into the kernel. There should be a file somewhere that tells
|
||||
what drivers are built into the kernel: (such as: /boot/config-2.4-20
|
||||
in Debian). Sometimes a device name (such as /dev/eth0) doesn't get a
|
||||
driver assigned to it unless the assignment is found in the file:
|
||||
/etc/modules.conf: For example, to assign the "tulip" driver to eth0
|
||||
you add a line to this file:
|
||||
<newline> alias eth0 tulip
|
||||
|
||||
This HOWTO doesn't cover the problem of finding and installing device
|
||||
drivers. Perhaps it should. One problem is that a certain brand of a
|
||||
card (or other physical device) may not say what kind of chips are
|
||||
used in it. The driver name is often the same as the chip name and
|
||||
not the brand name. One way to start to check on a driver is to see
|
||||
if it is discussed in the kernel documentation, in another HOWTO, or
|
||||
on the Internet. Warning: Such documentation may be out of date.
|
||||
|
||||
In this document I mention so many things that can go wrong that one
|
||||
who believes in Murphy's Law (If something can go wrong it will) may
|
||||
become quite alarmed. But for PnP for most people: If something can
|
||||
go wrong it usually doesn't. Remember that sometimes problems which
|
||||
seem to be PnP related are actually due to defective hardware or to
|
||||
hardware that doesn't conform to PnP specs.
|
||||
hardware that doesn't fully conform to PnP specs.
|
||||
|
||||
<sect> What PnP Should Do: Allocate "Bus-Resources"
|
||||
<sect1> What is Plug-and-Play (PnP)?
|
||||
|
@ -198,7 +222,7 @@ 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.
|
||||
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"
|
||||
|
@ -212,15 +236,19 @@ 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
|
||||
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. For modules, some of these assignments might be found in
|
||||
/etc/modules.conf (called "alias") while others may reside in an
|
||||
internal kernel table.
|
||||
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, will 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.
|
||||
|
||||
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.
|
||||
|
@ -238,7 +266,7 @@ 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.
|
||||
|
||||
<sect1> Addresses
|
||||
<sect1> Addresses
|
||||
<p> PCs have 3 address spaces: I/O, main memory (IO memory), and
|
||||
configuration (except that the old ISA bus lacks a "configuration"
|
||||
address space). All of these 3 types of addresses share the same bus
|
||||
|
@ -257,10 +285,10 @@ 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 other bus-resources such as interrupts):
|
||||
|
||||
<enum>
|
||||
<item> Set the I/O address, etc. on the card (in one of its registers)
|
||||
<enum>
|
||||
<item> Set the I/O address, etc. on the card (in one of its registers)
|
||||
<item> Let its device driver know what this I/O address, etc. is
|
||||
</enum>
|
||||
</enum>
|
||||
|
||||
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
|
||||
|
@ -279,7 +307,7 @@ 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.
|
||||
trouble.
|
||||
|
||||
An obvious requirement is that before the device driver can use an
|
||||
address it must be first set on the physical device (such as a card).
|
||||
|
@ -311,7 +339,7 @@ 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.
|
||||
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
|
||||
|
@ -319,7 +347,7 @@ 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".
|
||||
<sect1> IRQs --Overview <label id="interrupt_over">
|
||||
<sect1> IRQs --Overview <label id="interrupt_over">
|
||||
<p> After reading this you may read <ref id="interrupt_detail" name=
|
||||
"Interrupts --Details"> for some more details. The following is
|
||||
intentionally oversimplified: Besides the address, there is also an
|
||||
|
@ -360,7 +388,7 @@ sharing of IRQs is allowed.
|
|||
<p> 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:
|
||||
Normally the CPU would make such a transfer in a two step process:
|
||||
<enum>
|
||||
<item>reading from the I/O memory space of the device and putting these
|
||||
bytes into the CPU itself
|
||||
|
@ -368,7 +396,7 @@ bytes into the CPU itself
|
|||
</enum>
|
||||
<enum>
|
||||
<item> With DMA it's usually a one step process of sending the bytes
|
||||
directly from the device to memory
|
||||
directly from the device to memory
|
||||
</enum>
|
||||
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
|
||||
|
@ -416,7 +444,7 @@ 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.
|
||||
|
||||
<sect1> The Problem
|
||||
<sect1> The Problem
|
||||
<p> 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 (such
|
||||
|
@ -460,18 +488,20 @@ can initiate communication.
|
|||
<p> 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. Thus PnP is not
|
||||
really needed for them. Even so, there is a PnP specification for
|
||||
such external serial devices.
|
||||
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).
|
||||
|
||||
A PnP operating system will find such an external device and read its
|
||||
model number, etc. 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 have a
|
||||
certain device on say /dev/ttyS1. Since you should be able to
|
||||
manually inform your application program (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 port" feature of
|
||||
PnP. I don't think Linux supports it ??
|
||||
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.
|
||||
|
||||
<sect> The Plug-and-Play (PnP) Solution
|
||||
<sect1> Introduction to PnP
|
||||
|
@ -509,7 +539,7 @@ possible). It then tells each physical device what bus-resources are
|
|||
assigned to it and the devices set themselves up to use only the
|
||||
assigned bus-resources. Then the device drivers somehow find out what
|
||||
bus-resources their devices use and are thus able to communicate
|
||||
effectively with the devices they control.
|
||||
effectively with the devices they control.
|
||||
|
||||
For example, suppose a card needs one interrupt (IRQ number) and 1 MB
|
||||
of shared memory. The PnP program reads this request from the card.
|
||||
|
@ -597,7 +627,7 @@ device drivers with devices and also a need to configure devices that
|
|||
are added when the PC is up and running. These needs would be better
|
||||
satisfied if Linux was a PnP operating system.
|
||||
|
||||
<sect1> How Linux Does PnP <label id="how_linux_pnps">
|
||||
<sect1> How Linux Does PnP <label id="how_linux_pnps">
|
||||
<p> Linux has had a serious problem dealing with PnP and still has a
|
||||
problem but it's not as severe as it once was. Linux still is not
|
||||
really a PnP operating system and seems to mainly rely on and device
|
||||
|
@ -642,11 +672,11 @@ use. For the ISA bus see isapnp.txt and possibly (for kernel 2.4)
|
|||
When the PC starts up you may note from the messages on the screen
|
||||
that some Linux device drivers often find their hardware devices (and
|
||||
the bus-resources the BIOS has assigned them). But there are a number
|
||||
of things that a real PnP operating system could handle better:
|
||||
of things that a real PnP operating system could handle better:
|
||||
|
||||
<itemize>
|
||||
<item>A Allocate bus-resources when they are in short supply
|
||||
<item>Deal with more than one driver for a physical device
|
||||
<item>A Allocate bus-resources when they are in short supply
|
||||
<item>Deal with more than one driver for a physical device
|
||||
<item>Find a driver for a detected device (instead of making
|
||||
drivers do the searching)
|
||||
<item>Save a lot of work for the programmers of device drivers
|
||||
|
@ -743,7 +773,7 @@ fully configured by the BIOS but it can't. But it's reported that
|
|||
Windows 2000 can cope with this. One might expect that even if
|
||||
Windows9x didn't realize that the hardware was already configured, it
|
||||
would set the configuration of the physical devices per it's registry
|
||||
and then then everything would work OK.
|
||||
and then then everything would work OK.
|
||||
|
||||
But it doesn't seem to happen this way. It seems that Windows9x may
|
||||
just tell its device drivers what has been stored in the Windows'
|
||||
|
@ -758,9 +788,7 @@ One way to try to get the Registry and the ESCD the same is to install
|
|||
should present Windows with hardware configured by the BIOS. If this
|
||||
configuration is without conflicts, Windows will hopefully leave it
|
||||
alone and save it in it's Registry. Then the ESCD and the registry
|
||||
are in sync. If this works for you (and this is the latest version of
|
||||
this HOWTO), let me know as I only have one report of this working out
|
||||
OK.
|
||||
are in sync.
|
||||
|
||||
Another method is to remove devices that are causing problems in
|
||||
Windows by clicking on "remove" in the Device Manager. Then reboot with
|
||||
|
@ -822,8 +850,8 @@ configures it, you hope that the driver can find out what the BIOS did
|
|||
<item> <ref id="bios_conf" name= "BIOS Configures PnP"> (For the PCI bus
|
||||
you only need a PCI BIOS, otherwise you need a PnP BIOS)
|
||||
<item> <ref id="disable_pnp" name="Disable PnP"> by jumpers or
|
||||
DOS/Windows software (but many cards can't do this)
|
||||
<item> <ref id="isapnp_" name="Isapnp"> is a program you can always
|
||||
DOS/Windows software (but many cards can't do this)
|
||||
<item> <ref id="isapnp_" name="Isapnp"> is a program you can always
|
||||
use to configure PnP devices on the ISA bus only
|
||||
<item> <ref id="pciutils_" name="PCI Utilities"> is for configuring the PCI
|
||||
bus but the device driver should handle it
|
||||
|
@ -908,7 +936,7 @@ optional but most PnP-BIOSs have it. The ESCD not only stores the
|
|||
resource-configuration of PnP devices but also stores configuration
|
||||
information of non-PnP devices (and marks them as such) so as to avoid
|
||||
conflicts. The ESCD data is usually saved on a chip and remains
|
||||
intact when the power is off, but sometimes it's kept on a hard-drive??
|
||||
intact when the power is off, but sometimes it's kept on a hard-drive??
|
||||
|
||||
The ESCD is intended to hold the last used configuration, but if you
|
||||
use a program such as Linux's isapnp or pci utilities (which doesn't
|
||||
|
@ -924,7 +952,7 @@ the Linux OS is loaded) it should configure things this way. If the
|
|||
BIOS detects a new PnP card which is not in the ESCD, then it must
|
||||
allocate bus-resources to the card and update the ESCD. It may even
|
||||
have to change the bus-resources assigned to existing PnP cards and
|
||||
modify the ESCD accordingly.
|
||||
modify the ESCD accordingly.
|
||||
|
||||
If each device saved its last configuration in its hardware, hardware
|
||||
configuring wouldn't be needed each time you start your PC. But it
|
||||
|
@ -951,7 +979,7 @@ Windows knows about them and what bus-resources they use, then Windows
|
|||
should put this info into the ESCD.
|
||||
|
||||
If PnP devices are configured automatically by Windows without the
|
||||
user "forcing" it to change settings, then such settings probably will
|
||||
user "forcing" it to change settings, then such settings probably will
|
||||
not make it into the ESCD. Of course Windows may well decide on its
|
||||
own to configure the same as what is set in the ESCD so they could
|
||||
wind up being the same by coincidence.
|
||||
|
@ -983,7 +1011,7 @@ hardware" list: Start --> Programs --> Accessories --> System Tools
|
|||
--> System Information --> Hardware Resources --> Forced Hardware.
|
||||
When you "force" a change of bus-resources in Windows, it should put
|
||||
your change into the ESCD (provided you exit Windows normally).
|
||||
From the "System Information" window you may also inspect how IRQs and
|
||||
>From the "System Information" window you may also inspect how IRQs and
|
||||
IO ports have been allocated under Windows.
|
||||
|
||||
Even if Windows shows no conflict of bus-resources, there may be a
|
||||
|
@ -1007,7 +1035,7 @@ conflict. Another method is to run ICU under DOS/Windows. Still
|
|||
another is to install it manually under Windows 9x/2k and then make
|
||||
sure its configuration is "forced" (see the previous section). If
|
||||
it's "forced" Windows should update the ESCD when you shut down the
|
||||
PC.
|
||||
PC.
|
||||
|
||||
<sect1> Disable PnP ? <label id="disable_pnp">
|
||||
<p> Many devices are PnP only with no option for disabling PnP. But
|
||||
|
@ -1037,7 +1065,7 @@ Once configured as non-PnP devices, they can't be configured by PnP
|
|||
software or a PnP-BIOS (until you move jumpers and/or use the
|
||||
Dos/Windows configuration software again).
|
||||
|
||||
<sect1> Isapnp (part of isapnptools) <label id="isapnp_">
|
||||
<sect1> Isapnp (part of isapnptools) <label id="isapnp_">
|
||||
<p> Unfortunately, much of the documentation for isapnp is still
|
||||
difficult to understand unless you know the basics of PnP. This HOWTO
|
||||
should help you understand it as well the FAQ that comes with it.
|
||||
|
@ -1045,7 +1073,7 @@ should help you understand it as well the FAQ that comes with it.
|
|||
the Linux program "isapnp" at boot-time will configure such devices to
|
||||
the resource values specified in /etc/isapnp.conf. Its possible to
|
||||
create this configuration file automatically but you then must edit it
|
||||
manually to choose between various options.
|
||||
manually to choose between various options.
|
||||
|
||||
With isapnp there's a danger that a device driver which is built into
|
||||
the kernel may run too early before isapnp has set the address, etc.
|
||||
|
@ -1062,7 +1090,7 @@ the program "pnpdump" to help create the configuration file. It
|
|||
almost creates a configuration file for you but you must skillfully
|
||||
edit it a little before using it. It contains some comments to help
|
||||
you edit it. If you use "isapnp" for configuring and have a PnP BIOS,
|
||||
you you may want to tell the BIOS (when you set it up) that you don't
|
||||
you may want to tell the BIOS (when you set it up) that you don't
|
||||
have a PnP OS since you may want the BIOS to configure the PCI
|
||||
devices. While the BIOS may also configure the ISA devices, isapnp
|
||||
will redo it.
|
||||
|
@ -1172,7 +1200,7 @@ device resides. It may then try to test various IRQs to see which one
|
|||
works. It may or may not automatically do this. In other cases the
|
||||
driver may use PnP methods to find the device and how the bus-resources
|
||||
have been set, but will not actually set them. It may also look in
|
||||
some of the files in the /proc directory.
|
||||
some of the "files" in the /proc directory.
|
||||
|
||||
One may need to "manually" tell a driver what bus-resources it should
|
||||
use. You give such bus-resources as a parameter to the kernel or to a
|
||||
|
@ -1183,8 +1211,10 @@ parameters. Once you know what parameters to give to the kernel, one
|
|||
may put them into lilo.conf file as append="...". Then the lilo
|
||||
program must be run to get this info into the kernel loader.
|
||||
|
||||
If the driver is loaded as a module, you may need to give
|
||||
bus-resources as parameters to the module. In some versions of Linux
|
||||
If the driver is loaded as a module, in many cases the module will
|
||||
find the bus-resources it needs and set them in the device. In other
|
||||
cases (mostly for older PCs) you may need to give bus-resources as
|
||||
parameters to the module. In some versions of Linux
|
||||
/usr/lib/modules_help/descr.gz shows a list of possible module
|
||||
parameters. Parameters to a module (including ones that automatically
|
||||
load) may be specified in /etc/modules.conf. There are usually tools
|
||||
|
@ -1199,14 +1229,21 @@ kernel documentation tree). Some brief info on a few drivers is
|
|||
presented in the following sections:
|
||||
|
||||
<sect1> Serial Port Driver: setserial
|
||||
<p> For the standard serial port driver (not for multiport cards) you
|
||||
use setserial to configure the driver. It is often run from a
|
||||
start-up file. In newer versions there is a /etc/serial.conf file
|
||||
that you "edit" by simply using the setserial command in the normal
|
||||
way and what you set using <tt/setserial/ is saved in the
|
||||
<tt>serial.conf</tt> configuration file. The <tt>serial.conf</tt>
|
||||
file should be consulted when the <tt/setserial/ command runs from a
|
||||
start-up file. Your distribution may or may not set this up for you.
|
||||
<p> For PCI serial ports (and for newer 2.4 kernels for ISA), the
|
||||
serial driver detects the type of serial port and PnP configures it.
|
||||
Unfortunately, there may be some PCI serial ports that are not
|
||||
supported yet.
|
||||
|
||||
For the standard ISA serial port with older versions of the kernel and
|
||||
serial driver (not for multiport cards) you use setserial to configure
|
||||
the driver. Using setserial is also a must for non-pnp serial ports.
|
||||
Setserial is often run from a start-up file. In newer versions there
|
||||
is a /etc/serial.conf file that you "edit" by simply using the
|
||||
setserial command in the normal way and what you set using
|
||||
<tt/setserial/ is saved in the <tt>serial.conf</tt> configuration
|
||||
file. The <tt>serial.conf</tt> file should be consulted when the
|
||||
<tt/setserial/ command runs from a start-up file. Your distribution
|
||||
may or may not set this up for you.
|
||||
|
||||
There are two different ways to use <tt/setserial/ depending on the
|
||||
options you give it. One way is used to manually tell the driver the
|
||||
|
@ -1220,7 +1257,7 @@ probe for the existence of a port. See Serial-HOWTO for more details.
|
|||
For PCI serial, the serial driver may detect certain modems and
|
||||
configure the bus-resources.
|
||||
|
||||
<sect1> Sound Card Drivers
|
||||
<sect1> Old ISA Sound Card Drivers
|
||||
|
||||
<sect2> OSS-Lite
|
||||
<p> You must give the IO, IRQ, and DMA as parameters to a module
|
||||
|
@ -1268,7 +1305,7 @@ information.
|
|||
But sometimes the driver has been provided incorrect resources by a
|
||||
script, by incorrect resource parameters given to a module, or perhaps
|
||||
just hasn't been told what the resources are and tries to use
|
||||
incorrect default resources. For example, one can uses "setserial"
|
||||
incorrect default resources. For example, one can uses "setserial"
|
||||
to tell the driver an incorrect resource configuration and the driver
|
||||
accepts it without question.
|
||||
|
||||
|
@ -1282,7 +1319,7 @@ time to the shell prompt will show only the Linux kernel messages and
|
|||
miss some of the most important ones (including ones from the BIOS).
|
||||
The messages from Linux may sometimes only show what the device driver
|
||||
thinks the configuration is, perhaps as told it via an incorrect
|
||||
configuration file.
|
||||
configuration file.
|
||||
|
||||
The BIOS messages will show the actual hardware configuration at that
|
||||
time, but isapnp, or pci utilities, or device drivers may change it
|
||||
|
@ -1292,7 +1329,7 @@ them, try freezing them by hitting the "Pause" key. Press any key to
|
|||
resume. But once the messages from Linux start to appear, it's too
|
||||
late to use "Pause" since it will not freeze the messages from Linux.
|
||||
|
||||
<sect1> How Are My Device Drivers Configured?
|
||||
<sect1> How Are My Device Drivers Configured?
|
||||
<p> There may be a programs you can run from the command line (such as
|
||||
"setserial" for serial ports) to determine this. The /proc directory
|
||||
tree is useful. It seems that there are many files buried deep in
|
||||
|
@ -1314,13 +1351,13 @@ they came from the device shown. It could be that some other device
|
|||
which is not currently in use has issued them. A device not in use (per
|
||||
the kernel) may still issue some interrupts for various reasons.
|
||||
|
||||
<sect1> How Are My Hardware Devices Configured?
|
||||
<sect1> How Are My Hardware Devices Configured?
|
||||
<p> It's easy to find out what bus-resources have been assigned to
|
||||
devices on the PCI bus with the "lspci" or "scanpci" commands. For
|
||||
for kernels < 2.2: see <tt>/proc/pci</tt> or <tt>/proc/bus/pci</tt>
|
||||
for later kernels. Note that IRQs for <tt>/proc/pci</tt> are in
|
||||
hexadecimal. Don't bother trying to decipher
|
||||
<tt>/proc/bus/pci/devices</tt> since "lspci" will do that for you.
|
||||
<tt>/proc/bus/pci/devices</tt> since "lspci" will do that for you.
|
||||
|
||||
In most cases for PCI you will only see how the hardware is now
|
||||
configured and not what resources are required. In some cases you
|
||||
|
@ -1358,7 +1395,7 @@ cases both Windows and Linux simply accept what the BIOS has set. But
|
|||
where Windows and/or Linux do the configuring, they may do it
|
||||
differently. So don't count on devices being configured the same.
|
||||
|
||||
<sect>Error Messages
|
||||
<sect>Error Messages
|
||||
<sect1> Unexpected Interrupt
|
||||
<p> This means that an interrupt happened that no driver expected.
|
||||
It's unlikely that the hardware issued an interrupt by mistake. It's
|
||||
|
@ -1420,7 +1457,7 @@ for serial port is only 8 bytes. The starting address is known as the
|
|||
"base address". Sometimes just the word "range" is used to mean
|
||||
"address range".
|
||||
|
||||
<sect2> Address space
|
||||
<sect2> Address space
|
||||
<p> 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
|
||||
|
@ -1430,7 +1467,7 @@ 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.
|
||||
Thus read and write wires exist for both main memory and I/O addresses
|
||||
(4 wires in all).
|
||||
(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
|
||||
|
@ -1487,7 +1524,7 @@ this problem, each card is assigned a card number (handle) using a
|
|||
technique called "isolation". See <ref id="isolation_" name="ISA
|
||||
Isolation"> for the complex details.
|
||||
|
||||
Then to configure a certain card, its card number (handle) is sent
|
||||
Then to configure a certain card, its card number (handle) is sent
|
||||
out via the write-port address to tell that card that it is to listen
|
||||
at its address port. All other cards note that this isn't their card
|
||||
number and thus don't listen. Then the address of a configuration
|
||||
|
@ -1562,7 +1599,7 @@ to support it. 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
|
||||
its C programming code.
|
||||
its C programming code.
|
||||
|
||||
Here are some of the details of the PCI interrupt system. Each PCI
|
||||
card (and device mounted on the motherboard) has 4 possible
|
||||
|
@ -1573,7 +1610,7 @@ interrupt lines for the cards. But the specs permit a fewer number of
|
|||
interrupt lines so many PCI buses seem to be made with only 4
|
||||
interrupt lines. This is not too restrictive since interrupts may be
|
||||
shared. Call these lines (wires or traces) W, X, Y, Z. Suppose we
|
||||
designate the B interrupt from slot 3 as interrupt 3B.
|
||||
designate the B interrupt from slot 3 as interrupt 3B.
|
||||
|
||||
One simple method of connecting these lines to the interrupts would be
|
||||
to connect all A interrupts (INTA#) to line W, all B's to X,
|
||||
|
@ -1612,7 +1649,7 @@ the CMOS BIOS menu one may allow one to assign IRQs to PCI cards.
|
|||
Also, a PnP operating system (for example MS Windows) could attempt to
|
||||
assign these IRQs after first finding out what the BIOS has done. The
|
||||
assignments are known as a "routing table". If MS Windows makes such
|
||||
IRQ assignment dynamically (such as a docking event) it's called
|
||||
IRQ assignment dynamically (such as a docking event) it's called
|
||||
"IRQ steering". The BIOS may support it's own IRQ steering (which
|
||||
Linux could use). If you use Linux after Windows without turning off
|
||||
your PC, the IRQs may be different than what the BIOS set.
|
||||
|
@ -1663,7 +1700,7 @@ round) 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).
|
||||
for each device (see below for the all-0 case).
|
||||
|
||||
Thus it's clear that only cards with the lower serial number get
|
||||
eliminated during a round. But what happens if all devices in the
|
||||
|
@ -1696,3 +1733,5 @@ must be done over again.
|
|||
END OF Plug-and-Play-HOWTO
|
||||
</article>
|
||||
|
||||
___________________________________
|
||||
thanks for submitting into linuxdoc
|
||||
|
|
|
@ -4,9 +4,10 @@
|
|||
<author>David S.Lawyer
|
||||
<tt><htmlurl url="mailto:dave@lafn.org" name="dave@lafn.org"></tt>
|
||||
original by Greg Hankins
|
||||
<date> v2.15 November 2001
|
||||
<date> v2.16 March 2002
|
||||
|
||||
<!-- Change log:
|
||||
v2.16 March 2002 fixed a few broken links.
|
||||
v2.15 November 2001: mention of MIDI ports, problems with lockfiles
|
||||
for devfs
|
||||
v2.14 August 2001: major revision of Configuring the Serial Port
|
||||
|
@ -39,8 +40,8 @@ v1.11 15 November 1997 by Greg Hankins
|
|||
some research to determine them)
|
||||
v1.8.1: 9 Oct. 1995
|
||||
v1.7: 29 Oct. 1994
|
||||
v1.0 6 Jan. 1994: first Serial-HOWTO by Greg Hankins
|
||||
v1.0 June 1993: was called Serial FAQ, by Greg Hankins
|
||||
v1.0: 6 Jan. 1994: first Serial-HOWTO by Greg Hankins
|
||||
v1.0: June 1993: was called Serial FAQ, by Greg Hankins
|
||||
-->
|
||||
<abstract>
|
||||
This document describes serial port features other than those which
|
||||
|
@ -127,11 +128,12 @@ half is by David Lawyer. Ted Ts'o has continued to be helpful.
|
|||
<sect1> New Versions of this Serial-HOWTO
|
||||
<p> New versions of the Serial-HOWTO will be available to
|
||||
browse and/or download at LDP mirror sites. For a list of mirror
|
||||
sites see: <url url="http://metalab.unc.edu/LDP/mirrors.html">.
|
||||
sites see: <url url="http://www.linuxdoc.org/mirrors.html">.
|
||||
Various formats are available. If you only want to quickly check the
|
||||
date of the latest version look at <url
|
||||
url="http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html"> and compare
|
||||
it to this version: v2.15 November 2001 . New in recent versions:<newline>
|
||||
it to this version: v2.16 March 2002 . New in recent versions:<newline>
|
||||
v2.16 March 2002 fixed a few broken links.
|
||||
v2.15 November 2001: mention of MIDI ports, problems with lockfiles
|
||||
for devfs
|
||||
v2.14 August 2001: major revision of Configuring the Serial Port
|
||||
|
@ -351,7 +353,8 @@ transmit buffer in the hardware.
|
|||
Nov. '99: 2 serial drivers concurrently NG
|
||||
Sept. '00: data flow diagram
|
||||
Dec. '00 flow control +
|
||||
July "01 done -> down
|
||||
July '01 done -> down
|
||||
Feb. '02 4k buffer -> 8k
|
||||
-->
|
||||
|
||||
|
||||
|
@ -662,7 +665,7 @@ code. Likewise for DC1.
|
|||
control, a pair of 16-byte FIFO buffers (in the UART), and a pair of
|
||||
larger buffers inside a device connected to the serial port (such as a
|
||||
modem. But there is still another pair of buffers. These are large
|
||||
buffers (perhaps 8k) in main memory also known as serial port buffers.
|
||||
buffers (perhaps 4k) in main memory also known as serial port buffers.
|
||||
When an application program sends bytes to the serial port
|
||||
|
||||
they first get stashed in the the transmit serial port buffer in main
|
||||
|
@ -673,7 +676,7 @@ Transmit data flow is left to right while receive flow is right to
|
|||
left.
|
||||
|
||||
<verb>
|
||||
application 8k-byte 16-byte 1k-byte tele-
|
||||
application 4k-byte 16-byte 1k-byte tele-
|
||||
BROWSER ------- MEMORY -------- UART --------- MODEM -------- phone
|
||||
program buffer buffer buffer line
|
||||
</verb>
|
||||
|
@ -689,7 +692,7 @@ the computer, what it actually stops is the flow of outgoing bytes
|
|||
from the large transmit buffer in main memory. Even after this has
|
||||
happened and the flow to the device
|
||||
connected to the serial port has stopped, an application program
|
||||
may keep sending bytes to the 8k transmit buffer until it becomes
|
||||
may keep sending bytes to the 4k transmit buffer until it becomes
|
||||
fill.
|
||||
|
||||
When it gets fill, the application program can't send any more bytes
|
||||
|
@ -727,15 +730,15 @@ a long file from the BBS which is being sent simultaneously to both my
|
|||
text-terminal and a to file on my hard-disk. The bytes are coming in
|
||||
faster than the terminal can handle them so it sends a "stop" out its
|
||||
serial port to the first serial port on my PC. The device driver
|
||||
detects it and stops sending bytes from the 8k serial buffer (in main
|
||||
detects it and stops sending bytes from the 4k serial buffer (in main
|
||||
memory) to the terminal. Now minicom still keeps sending out bytes for
|
||||
the terminal into this 8k buffer.
|
||||
the terminal into this 4k buffer.
|
||||
|
||||
When this 8k transmit buffer (on the first serial port) is full,
|
||||
When this 4k transmit buffer (on the first serial port) is full,
|
||||
minicom must stop writing to it. Minicom stops and waits. But this
|
||||
also causes minicom to stop reading from the 8k receive buffer on the
|
||||
also causes minicom to stop reading from the 4k receive buffer on the
|
||||
2nd serial port connected to the modem. Flow from the modem continues
|
||||
until this 8k buffer too fills up and sends a different "stop" to the
|
||||
until this 4k buffer too fills up and sends a different "stop" to the
|
||||
modem. Now the modem's buffer ceases to send to the serial port and
|
||||
also fills up. The modem (assuming error correction is enabled) sends
|
||||
a "stop signal" to the other modem at the BBS. This modem stops
|
||||
|
@ -748,7 +751,7 @@ Thus a stop signal from a text terminal has halted a programs on a BBS
|
|||
computer. What a complex sequence of events! Note that the stop
|
||||
signal passed thru 4 serial ports, 2 modems, and one application
|
||||
program (minicom). Each serial port has 2 buffers (in one direction
|
||||
of flow): the 8k one and the hardware 16-byte one. The application
|
||||
of flow): the 4k one and the hardware 16-byte one. The application
|
||||
program may have a buffer in its C_code. This adds up to 11 different
|
||||
buffers the data is passing thru. Note that the small serial hardware
|
||||
buffers do not participate directly in flow control.
|
||||
|
@ -787,7 +790,7 @@ happened there, bytes intended for the hard-disk were lost.
|
|||
<sect1> Serial Driver Module
|
||||
<p> The device driver for the serial port is the software that
|
||||
operates the serial port. It is now provided as a serial module.
|
||||
From kernel 2.2 on, this module will normally get loaded automatically
|
||||
>From kernel 2.2 on, this module will normally get loaded automatically
|
||||
if it's needed. In earlier kernels, you had to have <tt/kerneld/
|
||||
running in order to do auto-load modules on demand. Otherwise the
|
||||
serial module needed to be explicitly listed in /etc/modules. Before
|
||||
|
@ -814,22 +817,23 @@ See <ref id="set_serial" name="What is Setserial"> for more info on
|
|||
<sect1> Introduction
|
||||
<p> The answer is yes, but ... The serial port is somewhat obsolete
|
||||
but it's still needed, especially for Linux. The serial port has many
|
||||
shortcomings but almost all new PC's seem to come with them them.
|
||||
Linux supports ordinary telephone modems only if they work thru a
|
||||
serial port.
|
||||
shortcomings but almost all new PC's seem to come with them. Linux
|
||||
supports ordinary telephone modems only if they work thru a serial
|
||||
port (although the port may be built into the modem).
|
||||
|
||||
The serial port must pass data between the computer and the external
|
||||
cable. Thus it has two interfaces and both of these interfaces are
|
||||
slow. First we'll consider the interface via external cable to the
|
||||
outside world.
|
||||
cable. Thus it has two interfaces: the serial-port-to cable and the
|
||||
serial-port-to-computer-bus. Both of these interfaces are slow.
|
||||
First we'll consider the interface via external cable to the outside
|
||||
world.
|
||||
|
||||
<sect1> EIA-232 Cable Is Low Speed & Short Distance
|
||||
<p> The conventional EIA-232 serial port is inherently low speed and
|
||||
is severely limited in distance. Ads often read "high speed" but it
|
||||
can only work at "high speed" over very short distances such as to a
|
||||
modem located right next to the computer. Compared to a network card,
|
||||
even this "high speed" is low speed. All of the serial cable wires
|
||||
use a common ground return wire so that twisted-pair technology
|
||||
even this "high speed" is low speed. All of the EIA-232 serial cable
|
||||
wires use a common ground return wire so that twisted-pair technology
|
||||
(needed for high speeds) can't be used without additional hardware.
|
||||
More modern interfaces for serial ports exist but they are not
|
||||
standard on PC's like the EIA-232 is. See <ref id="non_232"
|
||||
|
@ -857,13 +861,13 @@ port). It's actually a range of addresses and the lower address in
|
|||
this range is the base address. If someone only says (or writes)
|
||||
"address" it likely really means "base address"
|
||||
|
||||
Instead of using I/O, addresses some I/O devices read and write
|
||||
Instead of using I/O addresses, some I/O devices read and write
|
||||
directly from/to main memory. This provides more bandwidth since the
|
||||
conventional serial I/O system only moves a byte at a time. There are
|
||||
various ways to read/write directly to main memory. One way is called
|
||||
shared memory I/O (where the shared memory is usually on the same card
|
||||
as the I/O device). Other methods are DMA (direct memory access) on
|
||||
the ISA bus and what is about the same as DMA (only much faster):
|
||||
the ISA bus and what is about the same as DMA (only much faster):
|
||||
"bus mastering" on the PCI bus. These methods are a lot faster than
|
||||
those used for the serial port. Thus the conventional serial port
|
||||
with its interrupt driven (every 14 bytes) interface and single bytes
|
||||
|
@ -880,10 +884,11 @@ serial ports. Today they are commonly used for the control of
|
|||
external devices (including automation for both industry and the
|
||||
home). They can connect to computer servers for the purpose of
|
||||
monitoring/controlling the server from a remote location. They were
|
||||
once mainly used for connecting up many terminals and/or modems to
|
||||
serial ports. They are still used this way but today most modems are
|
||||
internal digital modems (often called something else) and they don't
|
||||
usually use multiport serial cards.
|
||||
once mainly used for connecting up many dumb terminals and/or modems
|
||||
to serial ports. Today, use of dumb terminals has declined, and
|
||||
several modems (or digital modems) can now be built into
|
||||
an internal card. So multiport serial cards are not as significant as
|
||||
they once were.
|
||||
|
||||
Each multiport card has a number of external connecters (DB-25 or
|
||||
RJ45) so that one may connect up a number of devices (modems,
|
||||
|
@ -997,9 +1002,9 @@ linux# ./MAKEDEV ttyS17
|
|||
For the names and numbers of other types of serial ports other than
|
||||
ttyS.. see devices.txt in the kernel documentation. Besides the
|
||||
listing of various brands of multiports found in this HOWTO there is
|
||||
<url url="http://members.aa.net/~swear/pedia/serialcards.html"
|
||||
name="Gary's Encyclopedia - Serial Cards">. It's not as complete, but
|
||||
may have some different links.
|
||||
<url url="http://eupedia.org/serialcards.html" name="Gary's
|
||||
Encyclopedia - Serial Cards">. It's not as complete, but may have
|
||||
some different links.
|
||||
|
||||
<sect1>Standard PC Serial Cards
|
||||
|
||||
|
@ -1018,8 +1023,8 @@ Here's a list of a few popular brands:
|
|||
<itemize>
|
||||
<item>Byte Runner (may order directly, shows prices) <url
|
||||
url="http://www.byterunner.com">
|
||||
<item> SIIG <url url="http://www.siig.com/io">
|
||||
<item> Dolphin <url url="http://www.dolphinfast.com/sersol/">
|
||||
<item> SIIG <url url="http://www.siig.com/products/io/">
|
||||
<item> Dolphin <url url="http://www.dolphinfast.com/sersol.html">
|
||||
</itemize>
|
||||
<p>
|
||||
Note: due to address conflicts, you may not be able to use COM4 and
|
||||
|
@ -1124,37 +1129,37 @@ driver status: for 2.2 kernel. Supported by Chase.
|
|||
<item>Computone IntelliPort II (ISA, PCI and EISA busses up to 64
|
||||
ports)<newline>
|
||||
webpage: <url url="http://www.computone.com"><newline>
|
||||
driver location:
|
||||
<url url="ftp://ftp.computone.com/PUB/Products/IntelliPortII/Linux/">,
|
||||
patch at <url
|
||||
driver location: old patch at <url
|
||||
url="http://www.wittsend.com/computone/linux-2.2.10-ctone.patch.gz"><newline>
|
||||
mailing list: <url url="mailto:majordomo@lazuli.wittsend.com"> with
|
||||
"subscribe linux-computone" in body<newline>
|
||||
note: Old ATvantage and Intelliport cards are not supported by Computone
|
||||
|
||||
<item> Connecttech<newline>
|
||||
website: <tt><url url="http://www.connecttech.com/products/products.html"></tt><newline>
|
||||
website: <tt><url url="http://www.connecttech.com/"></tt><newline>
|
||||
driver location: <url url="ftp://ftp.connecttech.com/pub/linux/">
|
||||
|
||||
<item>Cyclades<newline>
|
||||
Cyclom-Y (Cirrus Logic CD1400 UARTs; 8 - 32 ports),<newline>
|
||||
Cyclom-Z (MIPS R3000; 8 - 64 ports)<newline>
|
||||
website: <tt><url url="http://www.cyclades.com/products.html"></tt><newline>
|
||||
website: <tt><url
|
||||
url="http://www.cyclades.com/products/svrbas/zseries.php"></tt><newline>
|
||||
driver status: supported by Cyclades<newline>
|
||||
driver location: <tt><htmlurl url="ftp://ftp.cyclades.com/pub/cyclades"
|
||||
name="ftp://ftp.cyclades.com/pub/cyclades"></tt> and included in Linux
|
||||
kernel since version 1.1.75: cyclades.o
|
||||
|
||||
<item>Decision PCCOM (2-8 ports; ISA and PCI; AKA PC COM)<newline>
|
||||
<item>Decision PCCOM (2-8 ports; ISA and PCI; aka PC COM)<newline>
|
||||
ISA:<newline>
|
||||
contact: <tt><url url="mailto:info@cendio.se"></tt><newline>
|
||||
driver location: <tt><htmlurl url="ftp://ftp.signum.se/pub/pccom8"
|
||||
driver location: (dead link) <tt><htmlurl url="ftp://ftp.signum.se/pub/pccom8"
|
||||
name="ftp://ftp.signum.se/pub/pccom8"></tt><newline>
|
||||
PCI:<newline>
|
||||
drivers: <url url="http://www.decision.com.tw"> Click "download"<newline>
|
||||
drivers: <url url="http://www.decision.com.tw"><newline>
|
||||
driver status: Support in serial driver 5.03. For an earlier driver,
|
||||
there exists a patch for kernel 2.2.16 at <url
|
||||
url="http://www.qualica.com/serial/">
|
||||
url="http://www.qualica.com/serial/"> and for kernels 2.2.14-2.2.17
|
||||
at<url url="htp://www.pccompci.com/mains/installing_pci_linux1.html">
|
||||
|
||||
<item>Digi PC/Xi (12.5MHz 80186; 4, 8, or 16 ports),<newline>
|
||||
PC/Xe (12.5/16MHz 80186; 2, 4, or 8 ports),<newline>
|
||||
|
@ -1306,7 +1311,7 @@ to view the current status if you're having problems.
|
|||
See the section <ref id="stty_" name="Stty">
|
||||
|
||||
<sect>Locating the Serial Port: IO address, IRQs <label id="locate_port">
|
||||
<!-- configure.H begin (in MM, SS)
|
||||
<!-- locate.H begin (in MM, SS)
|
||||
<sect>Configuring the Serial Port
|
||||
Change-log:
|
||||
Aug. 2001: removed mention of patch to convert Linux to a PnP OS;
|
||||
|
@ -1986,31 +1991,35 @@ new devfs). The serial port ttySx (x=0,1,2, etc.) has major number 4.
|
|||
You may see this (and the minor numbers too) by typing: "ls -l ttyS*"
|
||||
in the /dev directory.
|
||||
|
||||
There formerly was an alternate name for each serial port. For
|
||||
example, ttyS2 would have cua2 as an alternate name. You may still
|
||||
have the cua devices in your /dev directory but they are now
|
||||
deprecated. Their drivers behave slightly different than for the ttyS
|
||||
ones. Device Obsolete">."') See the Modem-HOWTO
|
||||
section: "cua Device Obsolete">.
|
||||
There formerly was a "cua" name for each serial port and it behaved
|
||||
just a little differently. For example, ttyS2 would correspond to
|
||||
cua2. The cua major number was 5 and minor numbers started at 64.
|
||||
You may still have the cua devices in your /dev directory but they are
|
||||
now deprecated. Their drivers behave slightly different than for the
|
||||
ttyS ones. name="cua Device Obsolete">."') See the Modem-HOWTO section: "cua Device
|
||||
Obsolete">.
|
||||
|
||||
Dos/Windows use the COM name while the <tt/setserial/ program uses
|
||||
tty00, tty01, etc. Don't confuse these with dev/tty0, dev/tty1, etc.
|
||||
which are used for the console (your PC monitor) but are not serial
|
||||
ports. The table below is for the "standard" case (but yours could be
|
||||
different).
|
||||
different). The major/minor numbers don't exist with the devfs.
|
||||
|
||||
<tscreen><verb>
|
||||
IO devfs
|
||||
dos major minor major minor address name
|
||||
COM1 /dev/ttyS0 4, 64; /dev/cua0 5, 64 3F8 /dev/tts/0
|
||||
COM2 /dev/ttyS1 4, 65; /dev/cua1 5, 65 2F8 /dev/tts/1
|
||||
COM3 /dev/ttyS2 4, 66; /dev/cua2 5, 66 3E8 /dev/tts/2
|
||||
COM4 /dev/ttyS3 4, 67; /dev/cua3 5, 67 2E8 /dev/tts/3
|
||||
ISA IO devfs usb
|
||||
dos major minor address devfs devfs usb acm modem
|
||||
COM1 /dev/ttyS0 4, 64; 3F8 /dev/tts/0 /dev/usb/tts/0 /dev/usb/acm/0
|
||||
COM2 /dev/ttyS1 4, 65; 2F8 /dev/tts/1 /dev/usb/tts/1 /dev/usb/acm/1
|
||||
COM3 /dev/ttyS2 4, 66; 3E8 /dev/tts/2 /dev/usb/tts/2 /dev/usb/acm/2
|
||||
COM4 /dev/ttyS3 4, 67; 2E8 /dev/tts/3 /dev/usb/tts/3 /dev/usb/acm/3
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1> Universal Serial Bus Ports
|
||||
<p> Although the USB is not covered in this HOWTO, the serial ports on
|
||||
the USB are: /dev/ttyUSB0 /dev/ttyUSB1, etc.
|
||||
<sect1> USB (Universal Serial Bus) Ports
|
||||
<p>The serial ports on the USB are: /dev/ttyUSB0, /dev/ttyUSB1, etc.
|
||||
The devfs names for these are: /dev/usb/tts/0, /dev/usb/tts/1, etc.
|
||||
For many modems they are /dev/usb/acm/0, etc. (in devfs notation).
|
||||
For more info see the usb subdirectory in the kernel documentation
|
||||
directory for files: acm and usb-serial.
|
||||
|
||||
<sect1> Link ttySN to /dev/modem
|
||||
<p> On some installations, two extra devices will be created,
|
||||
|
@ -2764,21 +2773,22 @@ section is unique to each HOWTO.
|
|||
<p> The top speed of 115.2k has been standard since the mid 1990's.
|
||||
But by the year 2000, most new serial ports supported higher speeds of
|
||||
230.4k and 460.8k. Some also support 921.6k. Unfortunately Linux
|
||||
seldom uses these speeds due to lack of drivers. These ports behave
|
||||
just like 115.2k ports unless the higher speeds are enabled by special
|
||||
software. To get these speeds you need to compile the kernel with
|
||||
special patches but it seems that the 2.4 kernels not yet supported
|
||||
seldom uses these speeds due to lack of drivers. Thus such ports
|
||||
behave just like 115.2k ports unless the higher speeds are enabled by
|
||||
special software. To get these speeds you need to compile the kernel
|
||||
with special patches but it seems that the 2.4 kernels are not yet
|
||||
supported
|
||||
|
||||
The patch software is fairly simple since it only needs to enable the
|
||||
higher speeds by dialog with the hardware. But it's not quite as
|
||||
simple as just putting an enable byte in a hardware register since the
|
||||
registers weren't designed for this. But unfortunately, there is no
|
||||
standard way to enable the higher speeds so the driver needs to
|
||||
standard way to enable the higher speeds so the serial driver needs to
|
||||
support a variety of hardware.
|
||||
|
||||
A patch to support high-speed is called shsmod (Super High Speed
|
||||
Mode). There are both Windows and Linux versions of this patch. See
|
||||
<url url="http://www.devdrv.com/shsmod">. For Linux (as of late
|
||||
<url url="http://www.devdrv.com/shsmod/">. For Linux (as of late
|
||||
2001), most of the documentation is only in Japanese and the patch is
|
||||
for the old kernel 2.2.x. There is also a module for the VIA
|
||||
VT82C686 chip <url url="http://www.kati.fi/viahss/">. Using it may
|
||||
|
@ -2790,18 +2800,27 @@ Does shsmod support these ??
|
|||
|
||||
<sect2> How speed is set in hardware: the divisor and baud_base <label
|
||||
id="divisor_">
|
||||
<p> Here's a list of commonly used divisors and their corresponding
|
||||
speeds (assuming a maximum speed of 115,200): 1 (115.2k), 2 (57.6k), 3
|
||||
(38.4k), 6 (19.2k), 12 (9.6k), 24 (4.8k), 48 (2.4k), 96 (1.2k), etc.
|
||||
The serial driver sets the speed in the hardware by sending the
|
||||
hardware only a "divisor" (a positive integer). This "divisor"
|
||||
divides the maximum speed of the hardware resulting in a slower speed
|
||||
(except a divisor of 1 obviously tells the hardware to run at maximum
|
||||
speed).
|
||||
<p> Speed is set by having the serial port's clock change frequency.
|
||||
But this change happens not by acutally changing the frequency of the
|
||||
oscillator driving the clock but by "dividing" the clock's frequency.
|
||||
For example, to divide by two, just ignore every other clock tick.
|
||||
This cuts the speed in half. Dividing by 3 makes the clock run at 1/3
|
||||
frequency, etc. So to slow the clock down (meaning set speed), we
|
||||
just send the clock a divisor. It's sent by the serial driver to a
|
||||
register in the port. Thus speed is set by a divisor.
|
||||
|
||||
If the clock runs at a top speed of 115,000 bps (common), then here
|
||||
are the divisors for various speeds (assuming a maximum speed of
|
||||
115,200): 1 (115.2k), 2 (57.6k), 3 (38.4k), 6 (19.2k), 12 (9.6k), 24
|
||||
(4.8k), 48 (2.4k), 96 (1.2k), etc. The serial driver sets the speed
|
||||
in the hardware by sending the hardware only a "divisor" (a positive
|
||||
integer). This "divisor" divides the "maximum speed" of the hardware
|
||||
resulting in a slower speed (except a divisor of 1 obviously tells the
|
||||
hardware to run at maximum speed).
|
||||
|
||||
There are exceptions to the above since for certain serial port
|
||||
hardware, speeds above 115.2k are set by using a very high divisor.
|
||||
Bear that exception in mind as you read the rest of this section.
|
||||
Keep that exception in mind as you read the rest of this section.
|
||||
Normally, if you specify a speed of 115.2k (in your communication
|
||||
program or by stty) then the serial driver sets the port hardware to
|
||||
divisor 1 which sets the highest speed.
|
||||
|
@ -3132,27 +3151,28 @@ signal (positive or negative voltage). Still others have jumpers so
|
|||
that you can connect any wire to any wire. Some have switches.
|
||||
|
||||
Radio Shack sells (in 2001) a "RS-232 Troubleshooter" (formerly called
|
||||
"RS-232 Line Tester") which checks TD, RD, CD, RTS, CTS, DTR, and DSR.
|
||||
A green light means on (+12 v) while red means off (-12 v). They also
|
||||
sell a "RS-232 Serial Jumper Box" which permits connecting the pins
|
||||
anyway you choose. You will likely need to order them from the catalog
|
||||
where you may find them by checking the Index under "Tools, D-Sub
|
||||
Connection Pin ...". The two items mentioned are not "tools" but
|
||||
they appear on a page with tools.
|
||||
"RS-232 Line Tester") Cat. #276-1401. It checks TD, RD, CD, RTS,
|
||||
CTS, DTR, and DSR. A green light means on (+12 v) while red means
|
||||
off (-12 v). They also sell a "RS-232 Serial Jumper Box" Cat.
|
||||
#276-1403. This permits connecting the pins anyway you choose. Both
|
||||
these items are under the heading of "Peripheral hookup helpers".
|
||||
Unfortunately, they are not listed in the index to the printed
|
||||
catalog. They are on the same page as the D type connecters so
|
||||
look in the index under "Wire & Cable, Connectors. Or look
|
||||
under "Tools, D-Sub Connection Pin ...". A store chain named "Active Component
|
||||
|
||||
<sect2> Measuring voltages
|
||||
<p> Any voltmeter or multimeter, even the cheapest that sells for
|
||||
about $10, should work fine. Trying to use other methods for
|
||||
checking voltage is tricky. Don't use a LED unless it has a series
|
||||
resistor to reduce the voltage across the LED. A 470 ohm resistor is
|
||||
used for a 20 ma LED (but not all LED's are 20 ma). The LED will
|
||||
only light for a certain polarity so you may test for + or - voltages.
|
||||
Does anyone make such a gadget for automotive circuit testing?? Logic
|
||||
probes may be damaged if you try to use them since the TTL voltages
|
||||
for which they are designed are only 5 volts. Trying to use a 12 V
|
||||
incandescent light bulb is not a good idea. It won't show polarity
|
||||
and due to limited output current of the UART it probably will not
|
||||
even light up.
|
||||
about $10, should work fine. Trying to use other methods for checking
|
||||
voltage is tricky. Don't use a LED unless it has a series resistor to
|
||||
reduce the voltage across the LED. A 470 ohm resistor is used for a
|
||||
20 ma LED (but not all LED's are 20 ma). The LED will only light for
|
||||
a certain polarity so you may test for + or - voltages. Does anyone
|
||||
make such a gadget for automotive circuit testing?? Logic probes may
|
||||
be damaged if you try to use them since the TTL voltages for which
|
||||
they are designed are only 5 volts. Trying to use a 12 V incandescent
|
||||
light bulb is not a good idea. It won't show polarity and due to
|
||||
limited output current of the UART it probably will not even light up.
|
||||
|
||||
To measure voltage on a female connector you may plug in a bent paper
|
||||
clip into the desired opening. The paper clip's diameter should be no
|
||||
|
@ -3365,7 +3385,7 @@ is supposedly being used by another device (the resource is "busy").
|
|||
This message is easy to understand if it only means that the device is
|
||||
busy (in use). But it often means that a resource is in use. What
|
||||
makes it even more confusing is that in some cases neither the device
|
||||
not the resources that it needs are actually "busy".
|
||||
nor the resources that it needs are actually "busy".
|
||||
|
||||
The ``resource busy'' part often means (example for <tt/ttyS2/) ``You
|
||||
can't use <tt/ttyS2/ since another device is using ttyS2's
|
||||
|
@ -3394,10 +3414,12 @@ There are two possible cases when you see this message:
|
|||
|
||||
What you need to do is to find the interrupt setserial thinks
|
||||
<tt/ttyS2/ is using. Look at /proc/tty/driver/serial (if you have
|
||||
it). You should also be able to find it with the "setserial" command
|
||||
for <tt/ttyS2/. But due to a bug (reported by me in Nov. 2000) you
|
||||
get the same "... busy" error message when you try this with
|
||||
"setserial".
|
||||
it). You should also be able to see it with the "setserial" command
|
||||
for <tt/ttyS2/.
|
||||
|
||||
Bug in old versions: Prior to 2001 there was a bug which wouldn't let
|
||||
you see it with "setserial". Trying to see it would give the same
|
||||
"... busy" error message.
|
||||
|
||||
To try to resolve this problem reboot or: exit or gracefully kill all
|
||||
likely conflicting processes. If you reboot: 1. Watch the boot-time
|
||||
|
@ -3413,8 +3435,7 @@ correct (the same as set in the hardware). A way to test whether or
|
|||
not it's a potential interrupt conflict is to set the IRQ to 0
|
||||
(polling) using "setserial". Then if the busy message goes away, it
|
||||
was likely a potential interrupt conflict. It's not a good idea to
|
||||
leave it permanently set at 0 since it will make the CPU work too
|
||||
hard.
|
||||
leave it permanently set at 0 since it will put more load on the CPU.
|
||||
|
||||
<sect1> "Input/output error" from setserial or stty
|
||||
<p> You may have typed "ttys" instead of "ttyS". You will see this
|
||||
|
@ -3426,7 +3447,10 @@ serial port at the IO address that setserial thinks your port is at.
|
|||
|
||||
<sect1> Overrun errors on serial port
|
||||
<p> This is an overrun of the hardware FIFO buffer and you can't
|
||||
increase its size. See
|
||||
increase its size. Bug note (reported in 2002): Due to a bug in some
|
||||
kernel 2.4 versions, the port number may be missing and you will only
|
||||
see "ttyS" (no port number). But if devfs notation such as "tts/2" is
|
||||
being used, there is no bug. See
|
||||
|
||||
|
||||
|
||||
|
@ -4423,3 +4447,6 @@ the Internet (few retail stores stock them today) or find a used one.
|
|||
<p> END OF Serial-HOWTO
|
||||
</article>
|
||||
|
||||
|
||||
___________________________________
|
||||
thanks for submitting into linuxdoc
|
||||
|
|
Loading…
Reference in New Issue