Provided by: freebsd-manpages_11.1-3_all bug

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:
     0bCCmmmmmmmmOLIPPPPP
       CCard number
         mmmmmmmmajor number
                 callOut
                  Lock
                   Initial
                    PPPPPort number

DEPRECATION NOTICE

     The digi driver will be removed in FreeBSD 12.0.

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.