NAME

mvme337 − MVME337 communication controller STREAMS driver

DESCRIPTION

mvme337 is a STREAMS-based driver that provides a general interface to the MVME337 VMEbus communication controller module.  The MVME337 controller supports up to sixty-four asynchronous serial communication ports.  The MVME741 EVSB module will support sixteen ports per module.  Each MVME337 can support up to four MVME741 modules.  The mvme337 driver supports up to four MVME337 controllers per system when the mvme337 package has been installed. 

Each peripheral device connected to the MVME337 has the same major device number.  The MVME337 firmware presents a generic serial device interface to the driver.  Device numbers 0-63 are allocated for the sixty-four serial devices.  The least significant 4 bits in the minor device field are interpreted as the port number.  The next 2 bits are interpreted as the EVSB slot number of the 741.  And the next 2 bits are interpreted as the MVME337 controller number.  Therefore, a maximum of 64 minor device numbers can be  made per MVME337 controller.  The maximum number of controllers supported by the system is four. 

When the mvme337 driver is used with the STREAMS line discipline module ­ldterm(7), behavior on all communications ports is as described in UNIX System V/68 or V/88 Release 4 ­termio(7).  This is the default condition for sessions begun by ttymon(1M). 

If BSD/XENIX/V7 compatibility is required for a port, then the user must push the ­ttcompat(7) module onto the stream containing the MVME337 driver.  This can be done either interactively by using the command strchg(1), or by modifying the autopush(1M) files for the MVME337 controllers.  Each controller has an autopush file called /etc/m337.x.ap, where x is the controller number.  The autopush file(s) by default apply to all ports on a controller.  This can be changed by editing the autopush file(s). 

MVME337 IOCTLS

In addition to supporting the standard ioctl(2) commands as specified by termio(7), mvme337 supports hardware flow control and the downloading of object code and data to the MVME337 via MVME337-specific ioctl system calls.  The optional ioctl system calls specified by termiox(7) are not supported. 

The following MVME337-specific ioctl system calls have the form:

ioctl(fildes, command, arg)
int fildes, command;
struct dl_info ∗arg;

The dl_info structure is defined in /usr/include/sys/mvme337.h and has the following format:

TCDLOAD
Download object code or data to the MVME337. arg is a pointer to a user buffer containing a dl_info structure.  The hostaddr field points to a user buffer containing the object code or data to be downloaded.  The ipcaddr field points to the base address of the downloadable area in MVME337 local RAM.  The count field specifies the number of bytes to be downloaded. 

TCLINE
Load line discipline table, previously downloaded by TCDLOAD, into the MVME337’s internal table.  arg points to a user buffer containing a dl_info structure.  The ipcaddr field points to a user buffer containing the linesw table.  The count field specifies the number of lines in the linesw table.  The MVME337 linesw table is defined as follows:

TCEXEC
Execute a user function that has been downloaded by a previous TCDLOAD command.  arg points to a user buffer containing a dl_info structure.  The ipcaddr field specifies the execution function address. 

The following MVME337-specific ioctl system call has the form:

ioctl(fildes, command, arg)
int fildes, command;
int arg;

TCSETHW
Set hardware flow control option. If arg is 1, enable hardware flow control using the RTS/CTS signal pairs; if arg is 0, disable hardware flow control. 

The following MVME337-specific ioctl system calls have the form:

ioctl(fildes, command, arg)
int fildes, command;
int ∗arg;

TCGETHW
Return hardware flow control status. If the specified serial port has hardware flow control enabled, 1 is returned to the arg integer location; otherwise, 0 is returned. 

TCGETVR
Return MVME337 firmware and driver version and revision numbers in the integer pointed to by arg.  The driver version number is returned in the most significant byte, the driver revision number is in the second most significant byte, the firmware revision number is in the third byte, and the firmware revision number is in the least significant byte. 

TCGETDS
Return the current status of a device’s hardware signals, such as DCD, CTS, DSR, PR_FAULT, PR_POUT and PR_SELECT, in the integer pointed to by arg.  The following status values are defined in /usr/include/sys/mvme337.h:

E_DCD, E_LOST_DCD
E_DSR, E_LOST_DSR
E_CTS, E_LOST_CTS
E_PR_FAULT, E_PR_POUT, E_PR_SELECT

The following MVME337-specific ioctl system calls have the form:

ioctl(fildes, command, arg)
int fildes, command;
struct termios ∗arg;

TCSETDF
Set the default termios parameters.  arg is a pointer to a user-supplied termios structure. 

TCGETDF
Get the default termios parameters.  arg is a pointer to a user buffer large enough to contain a termios structure. 

CONFIGURATION ISSUES

Currently, the MVME337 operates in a canonical state handling only the most basic of features (breaks, interrupts, xon/xoff).  The default master file setting for xon/xoff processing is to let the controller do it.  However, to pass portions of compliance suites the master file must be changed so that the ldterm(7) module handles xon/xoff processing.  The ldterm(7) module may be pushed on the stream via autopush(1M) or when beginning a ttymon(1M) directly from the /etc/inittab file.  [See init(1M)]. 

The master.d file, /etc/master.d/mvme337, contains tunable parameters for board xon/xoff processing, scan rate of the MVME337 status channels, default board line discipline, and vmin/vtime parameters. 

BOOT TIME DIAGNOSTICS

The Software Discernible Field Replaceable Unit (SDFRU) consists of a MVME337 board and a MVSB741 board. 

Normal, Quick and Comprehensive diagnostic boot modes are the same. 

Diagnostic output verbosity mode of DV_OFF produces no output. 

Diagnostic output verbosity mode of DV_LEVEL1 produces the following phase messages for each SDFRU:

1. performing probe operation
2. testing mvsb741 boards
3. copying download to board
4. testing execution of download
5. test of bpp initialization

Each of these phases will pass or fail depending on the results of the tests ran within the phase.  A failed status of the MVSB741 SDFRU means that the MVSB741 may need replacement.  A failed status of the MVME337 SDFRU means that MVME337 may need replacement but that the MVSB741 status is unknown. 

Diagnostic output verbosity mode of DV_LEVEL2 produces printing of information of individual tests within the above phases. 

Diagnostic output verbosity mode of DV_LEVEL3 produces no additional information. 

D_FRU_STATUS

A D_FRU_STATUS call to driverinfo(D2DK) will return information about the SDFRU.  Along with the standard information, see driverinfo(D2DK), additional information about the MVSB741 SDFRU board revision and serial number is returned. 

FILES

/usr/include/sys/mvme337.h
/dev/term/??, /dev/port/m337_c?d??
/dev/edt/mvme332xt_c?
/etc/m337.?.ap
/etc/master.d/mvme337

ERRORS

The mvme337 driver generates error messages which are displayed on the console in order to help the operator diagnose problems. 

Error numbers returned in errno are standard except for the ENOSPC error which may be returned on an open if no free Buffered Pipe Protocol envelopes can be gotten to send an OPEN command to the MVME337 controller. 

SEE ALSO

autopush(1M), m337ctl(1M), mvme337(1M), ttymon(1M), termio(7), ldterm(7), ttcompat(7), driverinfo(D2DK).