*_Functional Specification of SAB8253X ASLX Driver for Linux_*
The SAB8253X serial interface chip is very flexible. It supports most
of the standard asynchronous serial transmission modes as well as
synchronous Bit Oriented Protocols (BOPs) and character oriented
protocols. The Linux ASLX Driver system provides an extremely flexible
Linux interface to the SAB8253X serial interface chips that are used on
the Aurora <http://www.auroratech.com/> XX20 adapter cards and
Multichannel server units whether they are inserted directly into a host
bus or whether they are connected via a PCI extension system such as the
Aurora XP7.
Supported Hardware
The Linux ASLX Driver supports Aurora SAB8253X communications adapter
cards and systems for PCI bus systems. Possible adapter card
configurations are identified as MN20 where M is 1, 2, 4, 8 and N is 0
or 5. M is the number of ports. N = 0 means that the adapter card does
not support synchronous modes. N = 5 means the adapter card modes are
unrestricted. The multichannel server system consists of an host
adapter card that attaches to an expansion box via the G-Link connection
cable. The expansion box can host 2000, 2500 and 3500 type Expansion
Boards (EBs). The 2000 EB provides 15 asynchronous-only RS-232 ports
and 1 unrestricted RS-232 port. The 2500 EB provides 16 unrestricted
RS-232 ports. The 3500 EB provides 16 unrestricted serial ports, whose
physical signaling is under software control. The XP7 is a PCI
expansion chassis.
The ASLX correctly identifies the Aurora adapter card or Multichannel
server and EBs, determines capabilities and provides a software
interface to configurable capabilities (e.g., a choice of RS-232 [= the
default], RS 422/423, RS 449, EIA 530, V.35, X.21, RS-485 and none
[=off] signaling for 3500 EBs). The use of an XP7 should be transparent
to the driver. The ASLX driver will automatically correct incorrectly
programmed adapter card or Multichannel server serial EEPROMs.
Moreover, in addition to the primary serial communications interface,
the ASLX driver provides a ^Ómaintenance^Ô interface to the serial EEPROMs
so that user intervention can correct an incorrectly programmed EEPROM.
Serial Communications Interface
The ASLX driver conforms to the standard Linux driver formalism for TTY
devices, network devices and character devices.
The ASLX Linux driver can like all standard Linux drivers either be
linked into the kernel or be built as a downloadable module that can
also be cleanly deloaded.
The ASLX Linux driver functionality provides more than the usual serial
device driver functionality because it provides the TTY device, network
device and character device functionality in one package. Moreover, the
ASLX Linux driver TTY functionality supports asynchronous TTY devices,
asynchronous CUA devices and synchronous TTY devices. The CUA devices
can also be used in conjunction with the network device and synchronous
character device functionalities for the purpose of dynamically setting
up a dialed link via a modem device.
The ASLX Linux driver has been developed for Linux on i386 hardware, but
it has no specific i386 dependence and after recompilation should be
able to run with Linux that has been compiled for other hardware.
The driver is structured to minimize Linux 2.4.*-isms. While it has not
been built as a Linux 2.2.* driver, rebuilding it to work under Linux
2.2.* should not be too difficult.
Driver Initialization
Drivers for physical devices usually must provide device detection and
device initialization.
The initialization or probe routines of the driver detect all the Aurora
SAB8253X devices in the system (i.e., these routines look for PCI
devices that have Aurora device and manufacturer IDs) and carry out any
necessary low-level PCI initialization of the PLX9050 (XX20 adapter
cards) or AMCC5920 bridge device (Multichannel server host card).
The initialization routines of the ASLX driver dynamically allocate all
structures. The number of Aurora adapter cards in a given system is
solely limited by the amount of dynamically allocatable kernel memory.
Note that the performance of a system will be dependent on the number of
active SAB8253X ports, port modes and speeds, the speed of the CPU, the
number of CPUs, memory design and similar hardware related considerations.
This driver currently does not initialize serial adapter cards of
similar design but with different device or manufacturer IDs, but users
will be able to access all the functionality described in this document
for serial ports on SAB8253X based Aurora adapter cards.
Extending the initialization to the intrinsic SAB8253X ports of SPARC
hardware or to similar adapter cards of other manufacturers would not be
difficult.
Note that the intrinsic SAB8253X ports of the SPARC hardware can serve
as boot serial consoles because they do not depend on PCI initialization
as the Aurora adapter cards and multichannel units do. Currently, the
Aurora ASLX driver does not support boot console or serial console
functionality, but extending the driver to provide such functionality
would not be difficult.
Note further the ASLX driver is designed (viz the Design Specification
of SAB8253X ASLX Driver for Linux) for hardware that utilizes none of
the DMA capabilities of SAB8253X extended serial interface controllers.
Because the ASLX driver transmits data from sk_buffs and receives data
into sk_buffs extending the driver to support SAB8253X based adapter
cards that support DMA would not be particularly difficult..
In addition, the Zilog 85X30, Intel 8X530 and the AMD 85X30 serial
communication controllers are character oriented devices that could
easily be supported within the logic of the ASLX driver. These devices
do not have the same sort of visible FIFO that the SAB8253X devices
have, but a FIFO operation looks like a sequence of operations to an
output or an input register on a device that does not have a visible FIFO.
The Communications Port
From the standpoint of the Linux operating system, after initialization,
the device that the operating system accesses is neither the Aurora
adapter card or Multichannel server nor the SAB8253X chip but is the
individual communications port of a SAB8253X chip. Thus a SAB82532 is
logically two devices, a SAB82538 is logically 8 devices, an Aurora 4520
logically provides 4 devices, and an Aurora Multichannel server can
logically provide up to 64 serial communications devices.
Each communications port according to board capabilities and device
configuration can provide asynchronous communications or synchronous
communications as well as access to modem signal status. On a given
port synchronous communications can either be bit-oriented or
character-oriented. Currently, the driver only supports bit-oriented
HDLC flag-framing and bit-stuffing, but the driver source can be easily
modified to support BSC character-oriented synchronous communications.
There are two obvious possible ways to extend the driver to support BSC
communications. Either a configuration flag could be added to indicate
that the synchronous TTY, network and character devices were running in
BSC mode and not in BOP mode, or new BSC specific TTY, network and
character devices could be created. The latter approach would probably
minimize potential user confusion and errors of connecting BSC ports to
BOP configured lines and vice-versa.
/Asynchronous Serial Communications Initialization for a Specific Port/
After probing for the hardware, the driver registers the asynchronous
device dependent routines, whose addresses are values of elements of
/struct tty_driver/ variables with the device independent TTY driver by
means of the /tty_register_driver()/ function.
These functions handle the device dependent aspects of opening a TTY
port (i.e., completing initialization in asynchronous mode), closing a
physical TTY port, writing an array of characters to a physical TTY
port, putting a single character to a physical TTY port, flushing the
characters in the process of being written to a single TTY port,
determining how much buffer space is currently available to a single
physical TTY port, determining how many characters are in the buffer
space associated with a single physical TTY port, carrying out the
device dependent aspects of IOCTLs invoked by a user application,
carrying out flow control at the physical port, carrying out the device
dependent aspects of setting TERMIOs, handling asynchronous break, and
waiting for a physical TTY port to transmit all characters associated
with the port. Other elements of the /struct_tty_driver/ are
initialized with information used for proc files and other TTY driver
functionality.
/Asynchronous Serial Communications Functionality/
The driver supports the standard Linux asynchronous TTY and call out
functionality, which includes all standard STTY and TERMIO IOCTLs, all
the standard speeds, all the standard flow control formalisms, etc.,
that can be found in the Linux STTY and TERMIO manual pages.
Note that custom IOCTLs have been added to support the configuration of
signaling on the WAN multichannel server 3500 cards.
In addition, customized IOCTLs have been added to support reading and
programming the serial EEPROM associated with the various Aurora adapter
cards and units. These are of limited use for users but are helpful in
debugging cards. Changing the manufacturer or device IDs can render an
adapter card or unit unusable.
The asynchronous TTY and call out functionality obey the standard Linux
block_til_ready logic than enforces arbitration between call out and
asynchronous TTY access. Current Linux design documents deprecate the
separate asynchronous call out functionality, but it is not particularly
obvious how to provide asynchronous call out functionality to set up
synchronous point-to-point links dynamically without the separate call
out devices.
To wit, ckermit does not use the cua devices. The ckermit user sets a
tty line, turns off carrier watch, executes the connect command, dials
out and then continues with his terminal session using the same tty
device on which he dialed out after the modems connect. This procedure
would not work if the point-to-point connection were to be synchronous
(or in fact if the point-to-point session were to carry X.25 traffic for
a PAD session). The cua devices are useful to deal with such /mixed
mode/ dynamically connected sessions.
Note that in the past Linux has required that TTY devices be named
/dev/ttyS* and that call out devices be named /dev/cua*. The devices
can still be so named, but this naming convention is not obligatory.
The asynchronous TTY devices use major device 4 and the call out device
uses major device 5. This assignment is a convention and can be changed
if necessary.
Ports are selected by the minor device number. Port minor device
numbers increase strictly monotonically in accord with the numbering
convention of the adapter card or adapter unit.[1] <#_ftn1>
The file /proc/tty/driver/auraserial that is created by the ASLX driver
helps in mapping port to minor device number. The call out device and
TTY device of a single port have the same minor device number. To
calculate the port number of an asynchronous TTY device or of a call out
device, subtract the minor device number of the first ASLX port from the
minor device number of the TTY or CUA device of interest.
/Synchronous Serial TTY Communications Initialization for a Specific Port/
After probing for the hardware, the driver registers the synchronous
device dependent routines, whose addresses are values of elements of
/struct_tty_driver/ variables with the device independent TTY driver by
means of the /tty_register_driver()/ function.
Just as in the case of asynchronous TTYs, these functions handle the
device dependent aspects of opening a TTY port (i.e., completing
initialization in synchronous mode), closing a physical TTY port,
writing an array of characters to a physical TTY port, putting a single
character to a physical TTY port, flushing the characters in the process
of being written to a single TTY port, determining how much buffer space
is currently available to a single physical TTY port, determining how
many characters are in the buffer space associated with a single
physical TTY port, carrying out the device dependent aspects of IOCTLs
invoked by a user application, carrying out flow control at the physical
port, carrying out the device dependent aspects of setting TERMIOs, and
waiting for a physical TTY port to transmit all characters associated
with the port. Other elements of the /struct tty_driver/ are
initialized with information used for proc files and other TTY driver
functionality.
Synchronous Serial TTY Communications Functionality
By default synchronous serial TTY communications takes place on devices
named /dev/sttyS*, but such names are not required. The major device
number associated with these ports is dynamically allocated and can be
found in the /proc/tty/driver/auraserial file.
Synchronous TTYs act just like asynchronous TTYs (e.g., getty^Òs may be
associated with them, and a user may invoke cu on them) in so far as
possible (to wit, break processing is not possible on a synchronous TTY).
As one cannot generally purchase synchronous TTY hardware, synchronous
TTYs are probably most useful in porting a synchronous TTY application
from another type of Unix that made use of line disciplines in some
legacy application.
Note that the synchronous TTY driver logic obeys the block_til_ready
arbitration logic so that asynchronous call out devices can be used to
set up point-to-point synchronous TTY links.
The synchronous TTY devices support all the standard STTY and TERMIO
IOCTLs as well as the custom IOCTLs that are described in the previous
section. Because these IOCTLs do not deal with the issue of synchronous
clock mode, IOCTLs for setting custom bit rates as well as for
programming and reading synchronous clock modes are provided. These
IOCTLs are also accessible through the asynchronous TTY and call out
devices. Configuring a port to provide clock only affects the port when
it is used as a synchronous device.
The minor device number associated with a specific port is the same
whether it is used as a synchronous TTY, an asynchronous TTY or a call
out device. To calculate the port number of a synchronous TTY device,
subtract the minor device number of the first ASLX port from the minor
device number of the TTY device of interest.
Synchronous Serial Network Device Initialization
The synchronous network device functionality is to some extent an
extension of the synchronous TTY functionality.
After probing for the SAB8253X hardware, the software in addition to
invoking /tty_register_driver()/ also invokes /register_netdev()/ for
each SAB8253X port. This registration makes it possible to connect
SAB8253X ports into the Linux network layer via ifconfig commands like
the following, which opens the device.
*ifconfig 8253x001 */{network address or host name}/
*ifconfig 8253x001* *hw ether* /{MAC address}/
Note that by default the number part of the network device name
corresponds to the serial port number (i.e., the minor device number of
the associated serial port minus the value of an internal kernel
variable called sab8253x_minor_start [equal to the minor device number
of the first TTY device listed in the /proc/tty/driver/auraserial
file]). The module parameter, sab8253x_minor_start, identifies the
minor device number at which Aurora asynchronous TTY, synchronous TTY
and call out devices start.
The network driver dynamically allocates memory specifically for its use
as needed on network device open and frees up network device driver
memory on network device close.
Synchronous Serial Network Devices
The network devices like all standard Linux network devices are not
visible in the /dev directory.
If an 8 port adapter card is installed in a Linux system that has an
Ethernet port, the new SAB8253X Linux driver makes it possible to use
the system as an 8 WAN x 1 LAN port router.
The SAB8253X network device functionality emulates an Ethernet device.
The network device functionality requires the implementation of the
following functions. As a consequence, the network portion of the ASLX
driver implements the standard Ethernet functionality as far as
possible. In addition, the network driver requires a special IOCTL to
set a pseudomac address.
In addition, the network driver needs some functionality that goes
beyond the standard Ethernet functionality, for it must be possible
dynamically to establish or reestablish synchronous links by means of
the asynchronous call out device logic.
Using the call out device logic in conjunction with the network device
requires an extension of the call out device arbitration logic.
The standard call out device arbitration logic requires that the call
out device start first and be invoked from the same process or process
group that opens the TTY device while the TTY device blocks until the
call out succeeds. Such logic is inapplicable to the network device.
The call out device must be opened while the corresponding network
device is open. The corresponding network device never blocks but
informs the network layer of outgoing network congestion.
Synchronous Serial Character Device Initialization
The synchronous character device functionality is to some extent an
extension of the synchronous network functionality.
After probing for the SAB8253X hardware, the software besides invoking
/tty_register_driver()/ also invokes /register_chardev()/ in addition to
/register_netdev()/ for each SAB8253X port. This registration makes it
possible to access SAB8253X port packet functionality independently of
the Linux network layer via function calls associated with a standard
character device.
The major device number of the synchronous serial character device can
be found in the /proc/devices file. Note that by default the minor
device number of each synchronous serial character device file (e.g.,
/dev/sab8253xC* if mknod is invoked as below) corresponds to the minor
device number of the associated serial port minus the value of an
internal kernel variable/module parameter called sab8253x_minor_start
(equal to the minor device number of the first TTY device indentified in
the /proc/tty/driver/auraserial file). The variable
sab8253x_minor_start identifies the minor device number at which Aurora
asynchronous TTY, synchronous TTY and call out devices start.
*mknod /dev/sab8253xC*{number} *c* {major dev number} {minor dev number}
The character driver dynamically allocates memory specifically for its
use as needed on network device open and frees up network device driver
memory on network device close.
/Synchronous Serial Character Device/
/
/
/ /
The SAB8253X synchronous character device functionality implements
essentially the same functions as the SAB8253X synchronous network
device functionality with the addition of a read/receive function that
will pass received data packets to a user application and with the
addition of an fasync helper function if the driver is to support
asynchronous notification to the user application. This functionality
is provided so that users that wish to implement their own bit oriented
synchronous protocols may directly access the serial data stream without
having to work around the TTY driver or the Linux network layer.
Note that while the network device is only opened once by the Linux
network layer, the character device may be opened multiple times by a
process or defined process group just like the TTY driver.
In a sense, the synchronous character device implements an emulation of
Solaris putmsg/getmsg functionality for Aurora^Òs synchronous serial
device. The availability of such emulation should help the portation of
applications from Solaris to a Linux platform that uses Aurora hardware
and software.
The asynchronous functionality is useful for those protocols like LAPB,
which do not work well if the physical driver buffers up low priority
packets while other packets are being transmitted. The asynchronous
notification can provide notification that there are no packets of any
sort in the process of being transmitted and that there are no high
priority packets buffered within the driver. On receiving this
notification, the user application could transmit the next low priority
packet.
Note that the synchronous serial character device interacts with the
call out device almost exactly like the TTY devices.
In the interest of keeping the interfaces simple and not introducing
extra foci for bugs, there are no IOCTLs implemented for this device.
If it is necessary to set a clocking mode or baud rate etc., the IOCTL
call is made via the STTY, TERMIO or extended IOCTLs associated with the
TTY driver functionalities.
Common Interrupt Handling Functionality
All the above functionality shares a common interrupt handler that
invokes indirectly functionality-specific receive_chars, transmit_chars
and check_status functions to receive character data, to transmit
character data and to check signal status.
In other words, the interrupt handler must support all possible
functionalities simultaneously on a group of ports associated with a
single interrupt simultaneously.
Linux is not capable of registering an interrupt handler for each port
separately (when there are many ports ^Ö the specialty of Aurora
hardware), and such an approach would have lower performance than having
a single interrupt handler that polled the ports. In any case,
interrupt status registers associated with the Aurora hardware often
indicate interrupt status on several ports simultaneous. It is
preferable to read such registers once especially with the Multichannel
server hardware.
Proc Files
The following traces show how the driver interacts with (or creates)
various /proc status files.
martillo@ylith:~ > cat /proc/tty/driver/auraserial
serinfo:2.01N driver:1.22
TTY MAJOR = 4, CUA MAJOR = 5, STTY MAJOR = 254.
128: port 0: sab82538: v3: chip 0: ATI 8520P: bus 2: slot 10: NR: close:
NOPRG
129: port 1: sab82538: v3: chip 0: ATI 8520P: bus 2: slot 10: NR: openA:
NOPRG
130: port 2: sab82538: v3: chip 0: ATI 8520P: bus 2: slot 10: NR: openA:
NOPRG
131: port 3: sab82538: v3: chip 0: ATI 8520P: bus 2: slot 10: NR: close:
NOPRG
132: port 4: sab82538: v3: chip 0: ATI 8520P: bus 2: slot 10: NR: close:
NOPRG
133: port 5: sab82538: v3: chip 0: ATI 8520P: bus 2: slot 10: NR: openS:
NOPRG
134: port 6: sab82538: v3: chip 0: ATI 8520P: bus 2: slot 10: NR: close:
NOPRG
135: port 7: sab82538: v3: chip 0: ATI 8520P: bus 2: slot 10: NR: close:
NOPRG
136: port 0: sab82538: v2: chip 0: ATI WANMS: bus 2: slot 11: NR: openA:
RS232
137: port 1: sab82538: v2: chip 0: ATI WANMS: bus 2: slot 11: NR: openA:
RS232
138: port 2: sab82538: v2: chip 0: ATI WANMS: bus 2: slot 11: NR: openA:
RS232
139: port 3: sab82538: v2: chip 0: ATI WANMS: bus 2: slot 11: NR: close:
RS232
140: port 4: sab82538: v2: chip 0: ATI WANMS: bus 2: slot 11: NR: close:
RS232
141: port 5: sab82538: v2: chip 0: ATI WANMS: bus 2: slot 11: NR: close:
RS232
142: port 6: sab82538: v2: chip 0: ATI WANMS: bus 2: slot 11: NR: close:
RS232
143: port 7: sab82538: v2: chip 0: ATI WANMS: bus 2: slot 11: NR: close:
RS232
144: port 0: sab82538: v2: chip 1: ATI WANMS: bus 2: slot 11: NR: openA:
RS232
145: port 1: sab82538: v2: chip 1: ATI WANMS: bus 2: slot 11: NR: close:
RS232
146: port 2: sab82538: v2: chip 1: ATI WANMS: bus 2: slot 11: NR: close:
RS232
147: port 3: sab82538: v2: chip 1: ATI WANMS: bus 2: slot 11: NR: close:
RS232
148: port 4: sab82538: v2: chip 1: ATI WANMS: bus 2: slot 11: NR: close:
RS530
149: port 5: sab82538: v2: chip 1: ATI WANMS: bus 2: slot 11: NR: close:
RS232
150: port 6: sab82538: v2: chip 1: ATI WANMS: bus 2: slot 11: NR: close:
RS232
151: port 7: sab82538: v2: chip 1: ATI WANMS: bus 2: slot 11: NR: openA:
RS232
152: port 0: sab82538: v2: chip 2: ATI WANMS: bus 2: slot 11: NR: openA:
RS232
153: port 1: sab82538: v2: chip 2: ATI WANMS: bus 2: slot 11: NR: close:
RS232
154: port 2: sab82538: v2: chip 2: ATI WANMS: bus 2: slot 11: NR: close:
RS232
155: port 3: sab82538: v2: chip 2: ATI WANMS: bus 2: slot 11: NR: close:
RS232
156: port 4: sab82538: v2: chip 2: ATI WANMS: bus 2: slot 11: NR: close:
RS232
157: port 5: sab82538: v2: chip 2: ATI WANMS: bus 2: slot 11: NR: close:
RS232
158: port 6: sab82538: v2: chip 2: ATI WANMS: bus 2: slot 11: NR: close:
RS232
159: port 7: sab82538: v2: chip 2: ATI WANMS: bus 2: slot 11: NR: openA:
RS232
160: port 0: sab82538: v2: chip 3: ATI WANMS: bus 2: slot 11: NR: close:
RS232
161: port 1: sab82538: v2: chip 3: ATI WANMS: bus 2: slot 11: NR: close:
RS232
162: port 2: sab82538: v2: chip 3: ATI WANMS: bus 2: slot 11: NR: close:
RS232
163: port 3: sab82538: v2: chip 3: ATI WANMS: bus 2: slot 11: NR: close:
RS232
164: port 4: sab82538: v2: chip 3: ATI WANMS: bus 2: slot 11: NR: close:
RS232
165: port 5: sab82538: v2: chip 3: ATI WANMS: bus 2: slot 11: NR: close:
RS232
166: port 6: sab82538: v2: chip 3: ATI WANMS: bus 2: slot 11: NR: close:
RS232
167: port 7: sab82538: v2: chip 3: ATI WANMS: bus 2: slot 11: NR: close:
RS232
168: port 0: sab82538: v2: chip 4: ATI WANMS: bus 2: slot 11: NR: openA:
RS232
169: port 1: sab82538: v2: chip 4: ATI WANMS: bus 2: slot 11: NR: close:
RS232
170: port 2: sab82538: v2: chip 4: ATI WANMS: bus 2: slot 11: NR: close:
RS232
171: port 3: sab82538: v2: chip 4: ATI WANMS: bus 2: slot 11: NR: close:
RS232
172: port 4: sab82538: v2: chip 4: ATI WANMS: bus 2: slot 11: NR: close:
RS232
173: port 5: sab82538: v2: chip 4: ATI WANMS: bus 2: slot 11: NR: close:
RS232
174: port 6: sab82538: v2: chip 4: ATI WANMS: bus 2: slot 11: NR: close:
RS232
175: port 7: sab82538: v2: chip 4: ATI WANMS: bus 2: slot 11: NR: close:
RS232
176: port 0: sab82538: v2: chip 5: ATI WANMS: bus 2: slot 11: NR: close:
RS232
177: port 1: sab82538: v2: chip 5: ATI WANMS: bus 2: slot 11: NR: close:
RS232
178: port 2: sab82538: v2: chip 5: ATI WANMS: bus 2: slot 11: NR: close:
RS232
179: port 3: sab82538: v2: chip 5: ATI WANMS: bus 2: slot 11: NR: close:
RS232
180: port 4: sab82538: v2: chip 5: ATI WANMS: bus 2: slot 11: NR: close:
RS232
181: port 5: sab82538: v2: chip 5: ATI WANMS: bus 2: slot 11: NR: close:
RS232
182: port 6: sab82538: v2: chip 5: ATI WANMS: bus 2: slot 11: NR: close:
RS232
183: port 7: sab82538: v2: chip 5: ATI WANMS: bus 2: slot 11: NR: close:
RS232
184: port 0: sab82538: v2: chip 6: ATI WANMS: bus 2: slot 11: NR: openA:
RS232
185: port 1: sab82538: v2: chip 6: ATI WANMS: bus 2: slot 11: NR: close:
RS232
186: port 2: sab82538: v2: chip 6: ATI WANMS: bus 2: slot 11: NR: close:
RS232
187: port 3: sab82538: v2: chip 6: ATI WANMS: bus 2: slot 11: NR: close:
RS232
188: port 4: sab82538: v2: chip 6: ATI WANMS: bus 2: slot 11: NR: close:
RS232
189: port 5: sab82538: v2: chip 6: ATI WANMS: bus 2: slot 11: NR: close:
RS232
190: port 6: sab82538: v2: chip 6: ATI WANMS: bus 2: slot 11: NR: close:
RS232
191: port 7: sab82538: v2: chip 6: ATI WANMS: bus 2: slot 11: NR: close:
RS232
192: port 0: sab82538: v2: chip 7: ATI WANMS: bus 2: slot 11: NR: close:
RS232
193: port 1: sab82538: v2: chip 7: ATI WANMS: bus 2: slot 11: NR: close:
RS232
194: port 2: sab82538: v2: chip 7: ATI WANMS: bus 2: slot 11: NR: close:
RS232
195: port 3: sab82538: v2: chip 7: ATI WANMS: bus 2: slot 11: NR: close:
RS232
196: port 4: sab82538: v2: chip 7: ATI WANMS: bus 2: slot 11: NR: close:
RS232
197: port 5: sab82538: v2: chip 7: ATI WANMS: bus 2: slot 11: NR: close:
RS232
198: port 6: sab82538: v2: chip 7: ATI WANMS: bus 2: slot 11: NR: close:
RS232
199: port 7: sab82538: v2: chip 7: ATI WANMS: bus 2: slot 11: NR: openA:
RS232
The above file indicates the minor device number, port number relative
to chip, chip type, chip version number, chip number (meaningful for
4X20 and multichannel servers), interface type, bus number, slot number,
port availability (AO = asynchronous only, NR = No Restrictions, or NA =
Not Available), status (closed, open Synchronous, open Asynchronous,
open Character, or open Network), and signaling type (NOPRG = not
selectable programmatically; other possibilities inclue OFF, RS232,
RS442, RS449, RS530 and V.35).
martillo@ylith:/proc > cat /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel Corporation 82820 820 (Camino) Chipset Host
Bridge (MCH) (rev 4).
Prefetchable 32 bit memory at 0xf8000000 [0xfbffffff].
Bus 0, device 1, function 0:
PCI bridge: Intel Corporation 82820 820 (Camino) Chipset PCI to AGP
Bridge (rev 4).
Master Capable. Latency=64. Min Gnt=8.
Bus 0, device 30, function 0:
PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 2).
Master Capable. No bursts. Min Gnt=2.
Bus 0, device 31, function 0:
ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 2).
Bus 0, device 31, function 1:
IDE interface: Intel Corporation 82801AA IDE (rev 2).
I/O at 0xffa0 [0xffaf].
Bus 0, device 31, function 2:
USB Controller: Intel Corporation 82801AA USB (rev 2).
IRQ 10.
I/O at 0xef80 [0xef9f].
Bus 0, device 31, function 3:
SMBus: Intel Corporation 82801AA SMBus (rev 2).
IRQ 9.
I/O at 0xefa0 [0xefaf].
Bus 1, device 0, function 0:
VGA compatible controller: nVidia Corporation NV15 (Geforce2 GTS)
(rev 164).
IRQ 11.
Master Capable. Latency=64. Min Gnt=5.Max Lat=1.
Non-prefetchable 32 bit memory at 0xfd000000 [0xfdffffff].
Prefetchable 32 bit memory at 0xe8000000 [0xefffffff].
Bus 2, device 8, function 0:
Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink]
(rev 120).
IRQ 11.
Master Capable. Latency=64. Min Gnt=10.Max Lat=10.
I/O at 0xdc00 [0xdc7f].
Non-prefetchable 32 bit memory at 0xfeacfc00 [0xfeacfc7f].
Bus 2, device 9, function 0:
Unknown mass storage controller: Promise Technology, Inc. 20267 (rev 2).
IRQ 9.
Master Capable. Latency=64.
I/O at 0xdff0 [0xdff7].
I/O at 0xdfe4 [0xdfe7].
I/O at 0xdfa8 [0xdfaf].
I/O at 0xdfe0 [0xdfe3].
I/O at 0xdf00 [0xdf3f].
Non-prefetchable 32 bit memory at 0xfeae0000 [0xfeafffff].
Bus 2, device 10, function 0:
Communication controller: PCI device 125c:0101 (Aurora Technologies,
Inc.) (rev 1).
IRQ 3.
Non-prefetchable 32 bit memory at 0xfeacf800 [0xfeacf87f].
Non-prefetchable 32 bit memory at 0xfeacf400 [0xfeacf5ff].
Non-prefetchable 32 bit memory at 0xfeacf000 [0xfeacf1ff].
Bus 2, device 11, function 0:
Communication controller: PCI device 125c:0101 (Aurora Technologies,
Inc.) (rev 1).
IRQ 10.
Non-prefetchable 32 bit memory at 0xfeacec00 [0xfeacec7f].
Non-prefetchable 32 bit memory at 0xfeace000 [0xfeace7ff].
Non-prefetchable 32 bit memory at 0xfeacd800 [0xfeacdfff].
The above file indications PCI resources that the Aurora adapter card or
unit uses.
martillo@ylith:/proc > cat /proc/devices
Character devices:
1 mem
2 pty
3 ttyp
4 ttyS
5 cua
7 vcs
10 misc
14 sound
128 ptm
136 pts
162 raw
180 usb
253 sab8253xc
254 sttyS
Block devices:
2 fd
22 ide1
33 ide2
The above file provides the major device number associated with the
synchronous serial character device.
martillo@ylith:/proc > cat /proc/modules
ASLX 84336 5 (autoclean)
The above file indicates that the ASLX module has been dynamically
linked into the kernel. If the ASLX is statically linked into the
kernel, it will not appear in this file.
martillo@ylith:/proc > cat /proc/interrupts
CPU0
0: 25311 XT-PIC timer
1: 401 XT-PIC keyboard
2: 0 XT-PIC cascade
3: 22 XT-PIC sab8253x
9: 20055 XT-PIC ide2
10: 27 XT-PIC usb-uhci, sab8253x
11: 38 XT-PIC eth0
12: 2720 XT-PIC PS/2 Mouse
15: 7 XT-PIC ide1
NMI: 0
LOC: 0
ERR: 0
MIS: 0
The above file indicates the interrupts that are being used by Aurora
adapter cards.
martillo@ylith:/proc/net > cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed
multicast|bytes packets errs drop fifo colls carrier compressed
lo: 1080 16 0 0 0 0 0 0
1080 16 0 0 0 0 0 0
eth0: 2316 19 0 0 0 0 0 0
1836 19 0 0 0 1 0 0
8253x000: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
8253x001: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
8253x002: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
8253x003: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
8253x004: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
8253x005: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
8253x006: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
8253x007: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
8253x008: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
8253x009: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
8253x010: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
8253x011: 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
The above file provides statistics on ASLX network interfaces.
martillo@ylith:/proc > cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000cc000-000cdfff : Extension ROM
000ce000-000ce7ff : Extension ROM
000f0000-000fffff : System ROM
00100000-0ffbffff : System RAM
00100000-00260dfe : Kernel code
00260dff-002f325f : Kernel data
0ffc0000-0fff7fff : ACPI Tables
0fff8000-0fffffff : ACPI Non-volatile Storage
e4600000-f46fffff : PCI Bus #01
e8000000-efffffff : nVidia Corporation NV15 (Geforce2 GTS)
f4700000-f47fffff : PCI Bus #02
f8000000-fbffffff : Intel Corporation 82820 820 (Camino) Chipset Host
Bridge (MCH)
fc900000-fe9fffff : PCI Bus #01
fd000000-fdffffff : nVidia Corporation NV15 (Geforce2 GTS)
fea00000-feafffff : PCI Bus #02
feacd800-feacdfff : PCI device 125c:0101 (Aurora Technologies, Inc.)
feace000-feace7ff : PCI device 125c:0101 (Aurora Technologies, Inc.)
feacec00-feacec7f : PCI device 125c:0101 (Aurora Technologies, Inc.)
feacf000-feacf1ff : PCI device 125c:0101 (Aurora Technologies, Inc.)
feacf400-feacf5ff : PCI device 125c:0101 (Aurora Technologies, Inc.)
feacf800-feacf87f : PCI device 125c:0101 (Aurora Technologies, Inc.)
feacfc00-feacfc7f : 3Com Corporation 3c905C-TX [Fast Etherlink]
feae0000-feafffff : Promise Technology, Inc. 20267
ffb80000-ffbfffff : reserved
fff00000-ffffffff : reserved
The above file indicate the I/O memory mapping of the Aurora devices.
ASLX IOCTL Summary
The ASLX driver supports the standard TTY and Ethernet driver IOCTLs.
In addition, the following TTY driver IOCTLs are supported (on
asynchronous/synchronous TTY devices and on asynchronous CUA devices):
/1. /set custom baud rate,//
/2. /get baud rate,//
/3. /read EEPROM,//
/4. /set EEPROM,//
/5. /get clocking mode,//
/6. /set clocking mode//
/7. /get WAN MCS signaling configuration,//
/8. /set WAN MCS signaling configuration,//
/9. /clear network driver statistics.//
In addition, the ASLX driver supports a network IOCTL to clear interface
statistics.
/Source Code Functionality/
To facilitate user modification and extension of the ASLX driver, the
code has been written as clearly as possible, and the various
functionalities (asynchronous TTY, synchronous TTY, network device and
character devices, initialization, interrupt, bridge initialization,
etc) have their own files to discourage massive unsupportable changes to
driver logic.
/Summary/
The driver attempts to provide as much as possible of the functionality
of the SAB8253X communication controller and the Aurora hardware in a
form that is both useful and friendly to the Linux user with as much
self-configuration as possible and by means of the standard Linux
interfaces. The custom portion of the interface has been minimized as
much as possible, and duplication of this interface across the TTY,
network, and synchronous serial character interface has been eschewed.
In this version of the driver for each type of custom configuration,
there is only one IOCTL, and this custom configuration is shared among
all the functionalities that share a given physical port.
In most applications of this driver, the user will generally not have to
use any of the custom IOCTLs unless he is using a serial port as a
synchronous device that is providing clock, in which case he would have
to use an IOCTL to make the port provide clock and he might have to use
another IOCTL to set a custom baud rate. In all cases, if the network
driver is used on a given port, that port would have to be assigned a
pseudomac address by means of the standard ifconfig command.
Altogether the driver provides the functionality needed for massive
asynchronous and synchronous TTY connectivity, for shake-and-bake WAN
networking and for synchronous legacy interconnect by means of a custom
application. Linux systems that host Aurora communications cards that
interface to the OS via the ASLX driver can replace a massive
point-of-sales servers, expensive WAN networking systems or custom
synchronous legacy protocol-to-standard protocol interconnect hardware.
------------------------------------------------------------------------
[1] <#_ftnref1> In the ASLX driver internal device lists, adapter cards
and adapter units are ordered in reverse order to the ordering on the
kernel PCI device list by type. Multiport adapter cards are ordered
last. Compact multiport adapter cards are ordered next. And
Multichannel units are ordered next, i.e., first. The ordering of
adapter cards and interface chips on internal driver lists currently
does not affect external functionality with one possible exception.
Adapter cards are also listed on per type per interrupt lists. If
there are many cards associated with a given interrupt, it is possible
that list order might cause maximum delay in loading and emptying port
FIFOs to be exceeded. As every card on the interrupt list must be
interrogated when an interrupt is received, avoiding the problem might
require moving to a faster processor based system. Multi-CPU hardware
would not help.
Download Driver Pack
After your driver has been downloaded, follow these simple steps to install it.
Expand the archive file (if the download file is in zip or rar format).
If the expanded file has an .exe extension, double click it and follow the installation instructions.
Otherwise, open Device Manager by right-clicking the Start menu and selecting Device Manager.
Find the device and model you want to update in the device list.
Double-click on it to open the Properties dialog box.
From the Properties dialog box, select the Driver tab.
Click the Update Driver button, then follow the instructions.
Very important: You must reboot your system to ensure that any driver updates have taken effect.
For more help, visit our Driver Support section for step-by-step videos on how to install drivers for every file type.