NAME¶
digi —
DigiBoard intelligent serial
cards driver
SYNOPSIS¶
device digi
This man page was originally written for the dgb driver, and should likely be
gone over with a fine tooth comb to reflect differences with the digi driver.
When not defined the number is computed:
default
NDGBPORTS
= number_of_described_DigiBoard_cards *
16
If it is less than the actual number of ports the system will be able to use
only the first
NDGBPORTS
ports. If it is greater then
all ports will be usable but some memory will be wasted.
Meaning of
flags:
- 0x0001
- use alternate pinout (exchange DCD and DSR lines)
- 0x0002
- do not use 8K window mode of PC/Xe
Device numbering:
0b CCmmmmmmmmOLIPPPPP
CCard number
mmmmmmmmajor number
callOut
Lock
Initial
PPPPPort number
DESCRIPTION¶
The
digi driver provides support for DigiBoard PC/Xe and PC/Xi
series intelligent serial multiport cards with asynchronous interfaces based
on the EIA RS-232C (CCITT V.24) standard.
Input and output for each line may set to one of following baud rates; 50, 75,
110, 134.5, 150, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600,
or for newer versions of cards 115200.
The driver does not use any interrupts, it is “polling-based”. This
means that it uses clock interrupts instead of interrupts generated by
DigiBoard cards and checks the state of cards 25 times per second. This is
practical because the DigiBoard cards have large input and output buffers
(more than 1Kbyte per port) and hardware that allows efficiently finding the
port that needs attention. The only problem seen with this policy is slower
SLIP and PPP response.
Each line in the kernel configuration file describes one card, not one port as
in the
sio(4) driver.
The
flags keyword may be used on each
“
device dgb
” line in the kernel
configuration file to change the pinout of the interface or to use new PC/Xe
cards which can work with an 8K memory window in compatibility mode (with a
64K memory window). Note that using 8K memory window does not mean shorter
input/output buffers, it means only that all buffers will be mapped to the
same memory address and switched as needed.
The
port value must be the same as the port set on the card by
jumpers. For PC/Xi cards the same rule is applicable to the
iomem value. It must be the same as the memory address set
on the card by jumpers. For PC/Xe cards there is no need to use jumpers for
this purpose. In fact there are no jumpers to do it. Just write the address
you want as the
iomem value in kernel config file and the
card will be programmed to use this address.
The same range of memory addresses may be used for all the DigiBoards installed
(but not for any other card or real memory). DigiBoards with a large amount of
memory (256K or 512K and perhaps even 128K) must be mapped to memory addresses
outside of the first megabyte. If the computer has more than 15 megabytes of
memory then there is no free address space outside of the first megabyte where
such DigiBoards can be mapped. In this case you may need to reduce the amount
of memory in the computer. But many machines provide a better solution. They
have the ability to “turn off” the memory in the 16th megabyte
(addresses 0xF00000 - 0xFFFFFF) using the BIOS setup. Then the DigiBoard's
address space can be set to this “hole”.
Serial ports controlled by the
digi driver can be used for
both “callin” and “callout”. For each port there is a
callin device and a callout device. The minor number of the callout device is
128 higher than that of the corresponding callin port. The callin device is
general purpose. Processes opening it normally wait for carrier and for the
callout device to become inactive. The callout device is used to steal the
port from processes waiting for carrier on the callin device. Processes
opening it do not wait for carrier and put any processes waiting for carrier
on the callin device into a deeper sleep so that they do not conflict with the
callout session. The callout device is abused for handling programs that are
supposed to work on general ports and need to open the port without waiting
but are too stupid to do so.
The
digi driver also supports an initial-state and a
lock-state control device for each of the callin and the callout
“data” devices. The minor number of the initial-state device is 32
higher than that of the corresponding data device. The minor number of the
lock-state device is 64 higher than that of the corresponding data device. The
termios settings of a data device are copied from those of the corresponding
initial-state device on first opens and are not inherited from previous opens.
Use
stty(1) in the normal way on the initial-state devices
to program initial termios states suitable for your setup.
The lock termios state acts as flags to disable changing the termios state.
E.g., to lock a flag variable such as
CRTSCTS
, use
“
stty crtscts
” on the lock-state device.
Speeds and special characters may be locked by setting the corresponding value
in the lock-state device to any nonzero value.
Correct programs talking to correctly wired external devices work with almost
arbitrary initial states and no locking, but other setups may benefit from
changing some of the default initial state and locking the state. In
particular, the initial states for non (POSIX) standard flags should be set to
suit the devices attached and may need to be locked to prevent buggy programs
from changing them. E.g.,
CRTSCTS
should be locked on
for devices that support RTS/CTS handshaking at all times and off for devices
that do not support it at all.
CLOCAL
should be locked
on for devices that do not support carrier.
HUPCL
may
be locked off if you do not want to hang up for some reason. In general, very
bad things happen if something is locked to the wrong state, and things should
not be locked for devices that support more than one setting. The
CLOCAL
flag on callin ports should be locked off for
logins to avoid certain security holes, but this needs to be done by getty if
the callin port is used for anything else.
FILES¶
- /dev/ttyD??
- for callin ports
- /dev/ttyiD??
-
- /dev/ttylD??
- corresponding callin initial-state and lock-state devices
- /dev/cuaD??
- for callout ports
- /dev/cuaiD??
-
- /dev/cualD??
- corresponding callout initial-state and lock-state
devices
- /etc/rc.serial
- examples of setting the initial-state and lock-state
devices
The first question mark in these device names is short for the card number (a
decimal number between 0 and 65535 inclusive). The second question mark is
short for the port number (a letter in the range [0-9a-v]).
DIAGNOSTICS¶
You may enable extended diagnostics by defining DEBUG at the start of the source
file
dgb.c.
- dgbX: warning: address N
truncated to M
- The memory address for the PC/Xe's 8K window is misaligned
(it should be on an 8K boundary) or outside of the first megabyte.
- dgbX: 1st reset failed
- Problems with accessing I/O port of the card, probably the
wrong port value is specified in the kernel config
file.
- dgbX: 2nd reset failed
- Problems with hardware.
- dgbX: N[st,nd,rd,th]
memory test failed
- Problems with accessing the memory of the card, probably
the wrong iomem value is specified in the kernel config
file.
- dgbX: BIOS start failed
- Problems with starting the on-board BIOS. Probably the
memory addresses of the DigiBoard overlap with some other device or with
RAM.
- dgbX: BIOS download
failed
- Problems with the on-board BIOS. Probably the memory
addresses of the DigiBoard overlap with some other device or with
RAM.
- dgbX: FEP code download
failed
- Problems with downloading of the Front-End Processor's
micro-OS. Probably the memory addresses of the DigiBoard overlap with some
other device or with RAM.
- dgbX: FEP/OS start
failed
- Problems with starting of the Front-End Processor's
micro-OS. Probably the memory addresses of the DigiBoard overlap with some
other device or with RAM.
- dgbX: too many ports
- This DigiBoard reports that it has more than 32 ports.
Perhaps a hardware problem or the memory addresses of the DigiBoard
overlap with some other device or with RAM.
- dgbX: only N ports are
usable
- The
NDGBPORTS
parameter is too
small and there is only enough space allocated for N
ports on this card.
- dgbX: port Y is
broken
- The on-board diagnostic has reported that the specified
port has hardware problems.
- dgbX: polling of disabled board
stopped
- Internal problems in the polling logic of driver.
- dgbX: event queue's head or tail
is wrong!
- Internal problems in the driver or hardware.
- dgbX: port Y: got event
on nonexisting port
- Some status changed on a port that is physically present
but is unusable due to misconfiguration.
- dgbX: port Y: event
N mstat M lstat K
- The driver got a strange event from card. Probably this
means that you have a newer card with an extended list of events or some
other hardware problem.
- dgbX: port Y:
overrun
- Input buffer has filled up. Problems in polling logic of
driver.
- dgbX: port Y: FEP command
on disabled port
- Internal problems in driver.
- dgbX: port Y: timeout on
FEP command
- Problems in hardware.
SEE ALSO¶
stty(1),
termios(4),
tty(4),
comcontrol(8)
HISTORY¶
The
digi driver is derived from the
sio(4)
driver and the DigiBoard driver from Linux and is currently under development.
BUGS¶
The implementation of sending
BREAK
is broken.
BREAK
of fixed length of 1/4 s is sent anyway.
There was a bug in implementation of
select(2). It is fixed
now but not widely tested yet.
There is no ditty command. Most of its functions (alternate pinout, speed up to
115200 baud, etc.) are implemented in the driver itself. Some other functions
are missing.