|Skip Navigation Links|
|Exit Print View|
|man pages section 7: Device and Network Interfaces Oracle Solaris 11 Information Library|
- Siemens 82532 ESCC serial communications driver
The se module is a loadable STREAMS driver that provides basic support for the 82532 ESCC hardware and basic asynchronous and synchronous communication support. This manual page describes the asynchronous protocol interface; for information on the synchronous interface, please see the se_hdlc(7D) manual page.
This module is affected by the setting of specific eeprom variables. For information on parameters that are persistent across reboots, see the eeprom(1M) man page.
The platform specific device bus address for the se module is bus_address. The se module's port_name is a single letter (a-z).
Note - During boot up, ttya/b characteristics are read from the /kernel/drv/options.conf file and changed from the PROM defaults to reflect Solaris defaults. Messages displayed on the console after this point are based on settings in that file. If you switch a characteristic, (for example, the baud rate of the console terminal), you must revise the /kernel/drv/options.conf or the console will be configured to an unusable configuration and console messages will be garbled by the mismatched serial port settings.
The Siemens 82532 provides two serial input/output channels capable of supporting a variety of communication protocols. A typical system will use one of these devices to implement two serial ports (port_name), usually configured for RS-423 (which also supports most RS-232 equipment). The Siemens 82532 uses 64 character input and output FIFOs to reduce system overhead. When receiving characters, the CPU is notified when 32 characters have arrived (one-half of receive buffer is full) or no character has arrived in the time it would take to receive four characters at the current baud rate.
When sending characters, the Siemens 82532 places the first 64 characters to be sent into its output FIFO and then notifies the CPU when it is half empty (32 characters left). Because the se module waits for the Siemens 82532 to transmit the remaining characters within its output FIFO before making requested changes, delays may occur when the port's attributes are being modified.
The se module implements CTS/RTS flow control in hardware. To prevent data overruns, remove CTS/RTS flow control responsibility from the CPU during periods of high system load.
In async mode (obtained by opening /dev/cua/[a-z], /dev/term/[a-z] or /dev/tty[a-z]), the driver supports the termio(7I) device control functions specified by flags in the c_cflag word of the termios structure, and by the IGNBRK, IGNPAR, PARMRK, or INPCK flags in the c_iflag word. All other termio(7I) functions must be performed by STREAMS modules pushed atop the driver. When a device is opened, the ldterm(7M) and ttcompat(7M) STREAMS modules are automatically pushed on top of the stream, providing the standard termio interface.
You can connect a single tty line to a modem for incoming and outgoing calls using a special feature controlled by the minor device number. By accessing character-special devices with names of the form /dev/cua/[a-z], it is possible to open a port without the Carrier Detect signal being asserted, either through hardware or an equivalent software mechanism. These devices are commonly known as dial-out lines.
After a /dev/cua/[a-z] line is opened, the corresponding tty line cannot be opened until the /dev/cua/[a-z] line is closed. A blocking open will wait until the /dev/cua/[a-z] line is closed (which will drop Data Terminal Ready and Carrier Detect) and carrier is detected again. A non-blocking open will return an error. If the tty line has been opened successfully (usually only when carrier is recognized on the modem), the corresponding /dev/cua/[a-z] line cannot be opened. This allows a modem to be attached to a device, (for example, /dev/term/ [a-z] renamed from /dev/tty[a-z]) and used for dial-in (by enabling the line for login in /etc/inittab) and dial-out (by tip(1) or uucp(1C)) as /dev/cua/[a-z] when no one is logged in on the line.
The se driver can be configured to support mice as well as applications requiring no buffering on the receive fifo. You can do this in one of two ways:
Using the se configuration file — To configure the se device to support mice using this approach, create an se.conf under /kernel/drv, then add keywords of the form: disable-rfifo-port<a/b><instance number>. For example, if your system has two se devices and you want port b on the device (associated with instance 0) and port a (associated with instance 1) to have their receive fifo disabled, the se.conf file must contain the following entries:
Programmatically — You can also configure the se device to support mice programatically by using the SERVICEIMM stream call to turn buffering off on the receive fifo, and/or SERVICEDEF to turn it back on again.
The se module supports the standard set of termio ioctl( ) calls.
Breaks can be generated by the TCSBRK, TIOCSBRK, and TIOCCBRK ioctl() calls.
The state of the DCD, CTS, RTS, and DTR interface signals can be queried through the use of the TIOCM_CAR, TIOCM_CTS, TIOCM_RTS, and TIOCM_DTR arguments to the TIOCMGET ioctl command, respectively. Due to hardware limitations, only the RTS and DTR signals may be set through their respective arguments to the TIOCMSET, TIOCMBIS, and TIOCMBIC ioctl commands.
The input and output line speeds may be set to all baud rates supported by termio. Input and output line speeds cannot be set independently; when you set the output speed, the input speed is automatically set to the same speed.
When using baud rates over 100,000 baud, the software changes the line driver configuration to handle the higher data rates. This action decreases the theoretical maximum cable length from 70 meters to 30 meters.
When the se module is used to service the serial console port, it supports a BREAK condition that allows the system to enter the debugger or the monitor. The BREAK condition is generated by hardware and it is usually enabled by default. A BREAK condition originating from erroneous electrical signals cannot be distinguished from one deliberately sent by remote DCE. Due to a risk of incorrect sequence interpretation, SLIP and certain other binary protocols should not be run over the serial console port when Alternate Break sequence is in effect. Although PPP is a binary protocol, it is able to avoid these sequences using the ACCM feature in RFC 1662. For Solaris PPP 4.0, you do this by adding the following line to the /etc/ppp/options file (or other configuration files used for the connection; see pppd(1M) for details):
By default, the Alternate Break sequence is a three character sequence: carriage return, tilde and control-B (CR ~ CTRL-B), but may be changed by the driver. For information on breaking (entering the debugger or monitor), see kmdb(1) and kb(7M).
An open() will fail under the following conditions:
The unit being opened does not exist.
The dial-out device is being opened and the dial-in device is already open, or the dial-in device is being opened with a no-delay open and the dial-out device is already open.
The port is in use by another serial protocol.
The unit has been marked as exclusive-use by another process with a TIOCEXCL ioctl( ) call.
The open was interrupted by the delivery of a signal.
dial-out tty lines
dial-in tty lines
binary compatibility package device names
synchronous devices - see se_hdlc(7D).
synchronous control clone device
System wide default device driver properties
See attributes(5) for descriptions of the following attributes:
The Siemens 82532 internal FIFO received more data than it could handle. This indicates that Solaris was not servicing data interrupts fast enough and suggests a system with too many interrupts or a data line with a data rate that is too high.
The se module was unable to store data it removed from the Siemens 82532 FIFO. The user process is not reading data fast enough, and suggests an overloaded system. If possible, the application should enable flow control (either CTSRTS or XONXOFF) to allow the driver to backpressure the remote system when the local buffers fill up.