BrainMaster Serial Port Installation, Configuration, and Operation. Start an MS-DOS prompt window, using the menu found under the “Start” menu, or using an icon on the main Windows screen. In the MS-DOS window, use the following procedure. BrainMaster Serial Port Configuration. It can access Com ports 1-8, including USB serial devices. MS-DOS: Use Simp Term from our Website to check motherboard or ISA based serial ports under DOS. Same settings for input and output, so any setting works with the same port.
Serial HOWTO: Locating the Serial Port: IO address, IRQs If you need to find a serial port it often helps if you know what bus it's on. If the serial port is on a card, you may know what bus the card inserts into such as a PCI slot. But if the serial port is built into the motherboard it may not be clear what bus it's on. For old motherboards that have ISA bus slots, it's likely on the ISA bus and may not even be Plug-and-Play.
But even if all your slots are PCI, the serial port is likely to be on either an ISA bus or LPC bus (also called a 'LPC interface'). LPC is common on laptop computers. Type 'lspci' to see if it shows 'LPC'. Unfortunately, the LPC bus has no standard Plug-and-Play method for low-level configuring devices on it. But according to the specs, the BIOS is supposed to do such configuring (using ACPI??).
![Ms-dos Serial Port Configuration Ms-dos Serial Port Configuration](/uploads/1/2/5/6/125641734/398856484.png)
To see if you have a LPC bus, type 'lspci' and look for a LPC bridge or the like. For a serial port to work properly it first must be given both an IO address and an IRQ. For old hardware (of mid 1990s), jumpers on a card or a saved BIOS setting does it. For newer hardware the BIOS or Linux must set them at boot-time, and the new hardware doesn't remember how it was set once it's powered down. Enabling the hardware (by using software) gives it both an IRQ and an IO address. Without an IO address, it can't be used. Without an IRQ it will need to use inefficient polling methods for which one must set the IRQ to 0 in the serial driver.
Using digital signals sent to the hardware by the BIOS or Linux, it all should get configured automatically (provided the BIOS has not been previously set up to disable it). So you only need to read this if you're having problems or if you want to understand how it works. The driver must of course know both the IO address and IRQ so that it can talk to the serial port chip. Modern serial port drivers (kernel 2.4) try to determine this by PnP methods so one doesn't normally need to tell the driver (by using 'setserial').
A driver may also set an IO address or IRQ in the hardware. But unfortunately, there is some PCI serial port hardware that the driver doesn't recognize so you might need to enable the port yourself. See For the old ISA bus, the driver also probes likely serial port addresses to see if there are any serial ports there. This works for the case of jumpers and sometimes works for a ISA PnP port when the driver doesn't do ISA PnP (prior to kernel 2.4). Locating the serial port by giving it an IRQ and IO address is low-level configuring. It's often automatically done by the serial driver but sometimes you have to do it yourself. What follows repeats what was said above but in more detail.
The low-level configuring consists of assigning an IO address, IRQ, and names (such as ttyS2). This IO-IRQ pair must be set in both the hardware and told to the serial driver. And the driver needs to call this pair a name (such as ttyS2). We could call this 'io-irq' configuring for short. The modern way to do this is for the driver to use PnP methods to detect/set the IO/IRQ and then remember what it did. An easy way for a driver to do this is for the driver to ask the kernel to enable the device and then the kernel tells the driver what IO/IRQ it has used. The old way is using the 'setserial' program to tell the driver.
For jumpers, there is no PnP but the driver might detect the port if the jumpers are set to the usual IO/IRQ. If you need to configure but don't understand certain details it's easy to get into trouble. When Linux starts, an effort is made to detect and configure (low-level) the serial ports.
Exactly what happens depends on your BIOS, hardware, Linux distribution, kernel version, etc. If the serial ports work OK, there may be no need for you to do any more low-level configuring.
If you're having problems with the serial ports, then you may need to do low-level configuring. If you have kernel 2.2 or lower, then you need to do it if you:. Plan to use more than 2 ISA serial ports. Are installing a new serial port (such as an internal modem).
One or more of your serial ports have non-standard IRQs or IO addresses Starting with kernel 2.2 you may be able to use more than 2 serial ports without doing any low-level configuring by sharing interrupts. All PCI ports should support this but for ISA it only works for some hardware. It may be just as easy to give each port a unique interrupt if they are available. See The low-level configuring (setting the IRQ and IO address) seems to cause people more trouble than the high-level stuff, although for many it's fully automatic and there is no configuring to be done. Until the port is enabled and the serial driver knows the correct IRQ and IO address, the port will not usually not work at all.
A port may be disabled, either by the BIOS or by failure of Linux to find and enable the port. For modern ports (provided the BIOS hasn't disabled them) manual PnP tools such as lspci should be able to find them. Applications, and utilities such as 'setserial' and 'scanport' (Debian only??) only probe IO addresses, don't use PnP tools, and thus can't detect disabled ports. Even if an ISA port can be found by the probing done by the serial driver it may work extremely slow if the IRQ is wrong. PCI ports are less likely to get the IRQ wrong.
IO address, IRQs, etc. Are called 'resources' and we are thus configuring certain resources. But there are many other types of 'resources' so the term has many other meanings. In summary, the low-level configuring consists of enabling the device, giving it a name (ttyS2 for example) and putting two values (an IRQ number and IO address) into two places:. The device driver (done by PnP or ' setserial'). Configuration registers of the serial port hardware itself, done by PnP software (or jumpers on legacy hardware).
You may watch the start-up (= boot-time) messages. They are usually correct. But if you're having problems, your serial port may not show up at all or if you do see a message from 'setserial' it may not show the true configuration of the hardware (and it is not necessarily supposed to). Introduction If you have kernel 2.4 or better, then there should be support for PnP for both the PCI and ISA buses (either built-in or by modules). Some PCI serial ports can be automatically detected and low-level configured by the serial driver. Others may not be.
While kernel 2.2 supported PCI in general, it had no support for PCI serial ports (although some people got them working anyway). Starting with kernel 2.4, the serial driver will read the id number digitally stored in the serial hardware to determine how to support it (if it knows how). It should assign an I/O address to it, determine its IRQ, etc. So you don't need to use 'setserial' for it. There is a possible problem if you don't use the device filesystem. The driver may assign the port to say tt/ttyS4 per a boot-time message (use dmesg to see it). But if you don't have a 'file' /dev/ttyS4 then the port will not work.
So you will then need to create it, using cd /dev;./MAKEDEV ttyS4 More info on PCI PCI ports are not well standardized. Some use main memory for communication with the PC. Some require special enabling of the IRQ. The output of 'lspci -vv' can help determine if one can be supported. If you see a 4-digit IO port, the port might work by just telling 'setserial' the IO port and the IRQ. For example, if lspci shows IRQ 10, I/O at 0xecb8 and you decide to name it ttyS2 then the command is: setserial /dev/ttyS2 irq 10 port 0xecb8 autoconfig Note that the boot-time message 'Probing PCI hardware' means reading the PnP configuration registers in the PCI devices which detects info about all PCI cards and on-board PCI devices. This is different than the probing of IO addresses by the serial driver which means reading certain IO addresses to see if what's read looks like there's a serial port at that address.
Here are some common mistakes people make:. setserial command: They run it (without the 'autoconfig' and autoirq options) and think it has checked the hardware to see if what it shows is correct (it hasn't).
setserial messages: They see them displayed on the screen at boot-time (or by giving the setserial command) and erroneously think that the result always shows how their hardware is actually configured. /proc/interrupts: When their serial device isn't in use they don't see its interrupt there, and erroneously conclude that their serial port can't be found (or doesn't have an interrupt set). /proc/ioports and /proc/tty/driver/serial: People think this shows the actual hardware configuration when it only shows about the same info (possibly erroneous) as setserial. There are really two answers to the question 'What is my IO and IRQ?' What the device driver thinks has been set (This is what setserial usually sets and shows.). What is actually set in the hardware. Above should be the same.
If they're not it spells trouble since the driver has incorrect info on the physical serial port. In some cases the hardware is disabled so it has no IO address or IRQ. If the driver has the wrong IO address it will try to send data to a non-existing serial port -or even worse, to some other device. If it has the wrong IRQ the driver will not get interrupt service requests from the serial port, resulting in a very slow or no response. If it has the wrong model of UART there is also apt to be trouble. To determine if both IO-IRQ pairs are identical you must find out how they are set in both the driver and the hardware.
Introduction What the driver thinks is not necessarily how the hardware is actually set. If everything works OK then what the driver thinks is likely correct (set in the hardware) and you don't need to investigate (unless you're curious or want to become a guru). Ways to determine what the driver thinks include: boot-time messages, the /proc directory 'files', and the 'setserial' command.
I/O Address & IRQ: Boot-time messages In many cases your ports will automatically get low-level configured at boot-time (but not always correctly). To see what is happening, look at the start-up messages on the screen.
Don't neglect to check the messages from the BIOS before Linux is loaded (no examples shown here). These BIOS messages may be frozen by pressing the Pause key (while holding down shift). It's often tricky to freeze them and you may need to hit Ctrl-Alt-Del while Linux is booting to start rebooting and try again.
What these messages display may change as booting progresses and it's often tricky to freeze it at exactly the right words. Use Shift-PageUp to scroll back to the messages after they have flashed. Shift-PageDown will scroll in the opposite direction. The dmesg command (or looking at logs in /var/log) will show only the first of these two messages. Here's an example of the start-up messages (as of 2004, almost the same as for 1999). Note that in older versions ttyS1 was displayed in these messages as ttyS01, etc.
At first you see what was detected (but the irq is only a wild guess): Serial driver version 4.27 with no serial options enabled ttyS0 at 0x03f8 (irq = 4) is a 16550A ttyS1 at 0x02f8 (irq = 3) is a 16550A ttyS2 at 0x03e8 (irq = 4) is a 16550A ttyS4 at port 0xeff0 (irq = 10) is a 16550A Note that ttyS0-ttyS2 were detected by probing the standard addresses while ttyS4 is a PCI port detected by probing the PCI configuration. Later setserial shows you what was saved in a configuration file (which you may edit), but it's not necessarily correct either: Loading the saved-state of the serial devices. /dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A /dev/ttyS2 at 0x03e8 (irq = 5) is a 16550A Note that the configuration file only had ttyS1-2 in it so that ttyS0 and ttyS4 were not affected by it. There is also a slight discrepancy: The first message shows ttyS2 at irq=4 while the second shows it at irq=5. In most cases the second message is the correct one. But if you're having trouble, it may be misleading.
Before reading the explanation of all of this complexity in the rest of this section, you might just try using your serial port and see if it works OK. If so it may not be essential to read further. The second message is from the setserial program being run at boot-time from a script in the /etc directory tree. It shows what the device driver thinks is the correct configuration.
But this too could be wrong. For example, the irq could actually be set to irq=8 in the hardware (both messages wrong).
The irq=5 could be there because the configuration file is incorrect. With old jumper-set serial ports Linux sometimes gets IRQs wrong because it doesn't by default probe for IRQs. It just assumes the 'standard' ones (first message) or accepts what is in a configuration file (second message).
Neither of these is necessarily correct. If the serial driver has the wrong IRQ, the serial port is very slow or doesn't seem to work at all.
The first message is a result of Linux probing the ISA serial port addresses but it doesn't probe for IRQs. If a port shows up here it exists but the IRQ may be wrong.
Linux doesn't check IRQs because doing so is not foolproof. It just assumes the IRQs are as shown because they are the 'standard' values. You may check them manually with setserial using the autoconfig and autoirq options but this isn't guaranteed to be correct either. The data shown by the BIOS messages (which you see at first before Linux is booted) are what is initially set in the hardware. If your serial port is Plug-and-Play (PnP) then it's possible that 'isapnp' or 'setpci' will run and change these settings. Look for messages about this after Linux starts.
The last serial port message shown in the example above should agree with the BIOS messages (as possibly modified by isapnp or setpci). If they don't agree then you either need to change the setting in the port hardware or use setserial to tell the driver what is actually set in the hardware. Also, if you have Plug-and-Play (PnP) serial ports, they can only be found by PnP software unless the IRQ and IO has been set inside the hardware by Plug-and-Play software. Prior to kernel 2.4 this was a common reason why the start-up messages did not show a serial port that physically exists. A PnP BIOS may automatically low-level configure them.
PnP configuring will be explained later. The /proc directory and setserial Type 'setserial -g /dev/ttyS.'
. There are some other ways to find this info by looking at 'files' in the /proc directory. Be warned that there is no guarantee that the same is set in the hardware. /proc/ioports will show the IO addresses that the drivers are using. /proc/interrupts shows the IRQs that are used by drivers of currently running processes (that have devices open). It shows how many interrupts have actually be issued. /proc/tty/driver/serial shows much of the above, plus the number of bytes that have been received and sent (even if the device is not now open).
Note that for the IO addresses and IRQ assignments, you are only seeing what the driver thinks and not necessarily what is actually set in the hardware. The data on the actual number of interrupts issued and bytes processed is real however. If you see a large number of interrupts and/or bytes then it probably means that the device is (or was) working. But the interrupts might be from another device. If there are no bytes received (rx:0) but bytes were transmitted (tx:3749 for example), then only one direction of flow is working (or being utilized). Sometimes a showing of just a few interrupts doesn't mean that the interrupt is actually being physically generated by any serial port.
Thus if you see almost no interrupts for a port that you're trying to use, that interrupt might not be set in the hardware. To view /proc/interrupts to check on a program that you're currently running (such as 'minicom') you need to keep the program running while you view it. Introduction If it's PCI or ISA PnP then what's set in the hardware has been done by PnP methods. Even if nothing has been set or the port disabled, PnP ports may still be found by using 'lspci -v' or 'isapnp -dumpregs'. Ports disabled by jumpers (or hardware failures) are completely lost.
See, PnP ports don't store their configuration in the hardware when the power is turned off. This is in contrast to Jumpers (non-PnP) which remain the same with the power off.
That's why a PnP port is more likely to be found in a disabled state than an old non-PnP one. PCI: What IOs and IRQs have been set? For PCI, the BIOS almost always sets the IRQ and may set the IO address as well. To see how it's set use 'lspci -vv' (best) or look in /proc/bus/pci (or for kernels.