FreeBSD 7.0 manual page repository

FreeBSD is a free computer operating system based on BSD UNIX originally. Many IT companies, like DeployIS is using it to provide an up-to-date, stable operating system.

digi - DigiBoard intelligent serial cards driver

 

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.  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 corre‐
      sponding 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 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.
      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.
 

Sections

Based on BSD UNIX
FreeBSD is an advanced operating system for x86 compatible (including Pentium and Athlon), amd64 compatible (including Opteron, Athlon64, and EM64T), UltraSPARC, IA-64, PC-98 and ARM architectures. It is derived from BSD, the version of UNIX developed at the University of California, Berkeley. It is developed and maintained by a large team of individuals. Additional platforms are in various stages of development.