Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
DIGI(4)		       FreeBSD 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

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 com-
     puter 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.	Pro-
     cesses 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 han-
     dling 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	set-
     tings of a	data device are	copied from those of the corresponding ini-
     tial-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 ben-
     efit 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 num-
     ber (a decimal number between 0 and 65535 inclusive).  The	second ques-
     tion 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 out-
     side 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 mem-
     ory of the	card, probably the wrong iomem value is	specified in the ker-
     nel config	file.

     dgbX: BIOS	start failed  Problems with starting the on-board BIOS.	 Prob-
     ably 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	Pro-
     cessor's micro-OS.	 Probably the memory addresses of the DigiBoard	over-
     lap 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 Digi-
     Board 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.

FreeBSD	10.1		       December	7, 2003			  FreeBSD 10.1

NAME | SYNOPSIS | DESCRIPTION | FILES | DIAGNOSTICS | SEE ALSO | HISTORY | BUGS

Want to link to this manual page? Use this URL:
<http://www.freebsd.org/cgi/man.cgi?query=digi&sektion=4&manpath=FreeBSD+10.1-RELEASE>

home | help