home | help
DIGI(4) 		     Kernel Interfaces Manual			 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 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 in-
     telligent 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  con-
     figuration  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  in-
     stalled  (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  out-
     side  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 de-
     vice.  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 de-
     vice for each of the callin and the callout "data" devices.  The minor num-
     ber 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  de-
     vice  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  al-
     most  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  de-
		     vices

     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, prob-
     ably 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 con-
     fig file.

     dgbX: BIOS start failed  Problems with starting the on-board BIOS.   Proba-
     bly 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 over-
     lap with some other device or with RAM.

     dgbX: FEP/OS start failed	Problems with starting of the Front-End  Proces-
     sor'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 spec-
     ified 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.

FreeBSD 11.1			  July 8, 2017				 DIGI(4)

home | help