digi(4)

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 dif
ferences 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:
0bCCmmmmmmmmOLIPPPPP
  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 inter
faces 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 com
patibility mode
(with a 64K memory window). Note that using 8K memory win
dow 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). Di
giBoards 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 ad
dress 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 de
vice 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 pro
cesses 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'' de
vices. 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 corre
sponding 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 ac
cessing 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 oth
er device or
with RAM.
dgbX: FEP code download failed Problems with downloading of
the FrontEnd 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 Di
giBoard 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 prob
lems 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 mis
configuration.
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 prob
lems 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.
BSD December 7, 2003
Copyright © 2010-2025 Platon Technologies, s.r.o.           Home | Man pages | tLDP | Documents | Utilities | About
Design by styleshout