1
0
Files
irix-657m-src/irix/man/man4/system.4
2022-09-29 17:59:04 +03:00

407 lines
13 KiB
Groff

.nr X
.if \nX=0 .ds x} system 4 "" "\&"
.TH \*(x}
.SH NAME
system \- system configuration information directory
.SH DESCRIPTION
This directory contains files (with the
\f4\&.sm\f1
suffix) that are used by the
\f4lboot\f1
program to obtain configuration information.
These files generally contain
information used to determine if specified hardware exists,
a list of software drivers to include in the load, and
the assignment of system devices such as \f2rootdev\f1,
as well as instructions for manually overriding the drivers selected by the
self-configuring boot process.
.PP
Each major subsystem can have its own
configuration file, for example:
\f4irix.sm\f1
(base operating system configuration file),
\f4gfx.sm\f1
(graphics subsystem configuration file),
and so forth.
\f4lboot\f1
logically concatenates all files in the \f2system\fP directory with the
\f4\&.sm\f1
suffix and processes the results.
.PP
The syntax of the system files is given below.
The parser for the \f4/var/sysgen/system/*.sm\f1 file is case sensitive.
All uppercase strings in the syntax below should be uppercase in the
\f4/var/sysgen/system/*.sm\f1 file as well.
Nonterminal symbols are enclosed in angle brackets, \f2\f1, while
optional arguments are enclosed in square brackets, [].
Ellipses, ..., indicate optional repetition of the argument
for that line.
.PP
.PD 0
.RS
.TP
\f2fname\f1 ::= master filename from \f4/master.d\f1 directory
.TP
\f2func\f1 ::= interrupt function name
.TP
\f2devicefile\f1 :: = special device name
.TP
\f2major\f1 ::= \f2number\f1
.TP
\f2minor\f1 ::= \f2number\f1
.TP
\f2proc\f1 ::= processor # as interpreted by \f4runon\f1(1)
.TP
\f2number\f1 ::= decimal, octal or hex literal
.RE
.PD
.PP
\f4lboot\fP can determine if hardware exists for a given module by use of
probe commands. There are three distinct probe command formats.
The syntax for the first type of probe command is:
.PP
.RS
.PD 0
.TP
\f2probe_cmd\f1 ::= probe=\f2number\f1
[ probe_size=\f2number\f1 ] | \f2extended_probe\f1
.TP
\f2extended_probe\f1 ::= exprobe=\f2probe_sequence\f1
| exprobe=(\f2probe_sequence\f1,\f2probe_sequence\f1,...)
.TP
\f2probe_sequence\f1 ::= (\f2seq\f1,\f2address\f1,\f2size\f1,\f2value\f1,\f2mask\f1)
.TP
\f2seq\f1 ::= a sequence of 1 or more r's, rn's, or w's, indicating a
.br
read from \f2address\f1 or a write to \f2address\f1
.TP
\f2address\f1 ::= \f2number\f1
.TP
\f2size\f1 ::= \f2number\f1
.TP
\f2value\f1 ::= \f2number\f1
.TP
\f2mask\f1 ::= \f2number\f1
.RE
.PD
.PP
This probe command format allows the specification of an address, and
optionally, a number of bytes, to read.
If a probe address is specified, the boot program
attempts to read \f2probe_size\fP bytes (default 4) to determine
if the hardware
exists for the module.
If the read succeeds, the hardware is assumed
to exist, and the module is included.
.PP
The second probe command format provides the only means with
which to detect peripherals on the CHALLENGE and Onyx systems
(note that this format is supported on all Silicon Graphics platforms
however).
.PP
.RS
.PD 0
.TP
\f2probe_cmd\f1 ::= probe_space=(\f2bus_space\f1,\f2number\f1
[ probe_size=\f2number\f1 ] | \f2extended_probe\f1)
.TP
\f2extended_probe\f1 ::= exprobe_space=\f2probe_sequence\f1
| exprobe_space=(\f2probe_sequence\f1,\f2probe_sequence\f1, ...)
.TP
\f2probe_sequence\f1 ::= (\f2seq\f1,\f2bus_space\f1,\f2address\f1,\f2size\f1,
\f2value\f1,\f2mask\f1)
.TP
\f2seq\f1 ::= a sequence of 1 or more r's, rn's, or w's, indicating a
read from \f2address\f1, or a write to \f2address\f1.
.TP
\f2bus_space\f1 ::= A16NP | A16S | A24NP | A24S | A32NP | A32S
.TP
\f2address\f1 ::= \f2number\f1
.TP
\f2size\f1 ::= \f2number\f1
.TP
\f2value\f1 ::= \f2number\f1
.TP
\f2mask\f1 ::= \f2number\f1
.RE
.PD
.PP
.PP
This extended format specifies a sequence of one or more five-tuples used
to determine if the hardware exists.
Each five-tuple specifies a
read/write \f2sequence\fP, an \f2address\fP
to read or write, a \f2size\fP of up to four bytes, a \f2value\fP, and
a \f2mask\fP.
Then, for each five-tuple, the following is performed:
.Ex
for each element in command do
if element == 'w' then
if write(address, value & mask, size) != size then
failure
if element == 'r' then
if read(address, temp, size) != size then
failure
if suffix == 'n' then
if temp & mask == value & mask then
failure
else
if temp & mask != value & mask then
failure
.Ee
.PP
The third probe command format is required to detect XIO and
PCI peripherals on platforms such as Octane and Origin.
.PP
.RS
.PD 0
.TP
\f2probe_cmd\f1 ::= probe_path=\f2pathname\f1
.RE
.PD
.PP
.PP
The lines listed below can appear in any order.
Blank lines can be inserted at any point.
Comment lines must begin with an asterisk.
Entries for VECTOR, EXCLUDE, and INCLUDE are cumulative.
For all other entries, the last line to appear
in the file is used -- any earlier entries are ignored.
.PP
There are three styles of VECTOR line.
The first version is
the historical version and does not work on platforms such as
the CHALLENGE and Onyx series.
The second VECTOR command
supports the CHALLENGE and Onyx series along
with bus types such as EISA.
The second version is the preferred method for non XIO/PCI devices
since it works across all Silicon Graphics platforms.
The third version should be used for Origin, Octane, and O2 devices
that use the XIO or PCI bus.
.PP
VECTOR: module=\f2fname\f1 [ intr=\f2func\f1 ]
.br
[ vector=\f2number\f1 ipl=\f2number\f1 unit=\f2number\f1 ] [ base=\f2number\f1 ]
.br
[ base2=\f2number\f1 ] [ base3=\f2number\f1 ]
.br
[ \f2probe_cmd\f1 ]
.br
[ intrcpu=\f2number\f1 ] [ syscallcpu=\f2number\f1 ]
.IP
Specifies hardware to conditionally load.
(Note that this must be a single line.)
If a probe command is specified, the boot program performs the
probe sequence, as discussed above.
If the sequence succeeds, the
module is included.
.IP
If a probe sequence is not specified, the hardware is assumed to exist.
The \f4intr\f1 function specifies the name of the module's interrupt handler.
If it is not specified, the prefix defined in the module's master file
(see \f4master\fP(4)) is concatenated with the string \f4intr\f1, and,
if a routine with that name is found in the module's object (which
resides in the directory
\f4/var/sysgen/boot\f1),
it is used as the interrupt routine.
.IP
If the triplet (vector, ipl, unit, base) is specified, a VME interrupt
structure is assigned, using the corresponding VME address
\f2vector\f1, priority
level \f2ipl\f1, unit \f2unit\f1.
.IP
If the modules' object contains
a routine whose name is the concatenation of the master file
prefix and \f4edtinit\f1, that routine is involved once at startup
and passed a pointer to an edt structure that contains the values
for base, base2, base3, and a pointer to the VME interrupt structure.
.IP
If intrcpu is specified, it hints to the driver the desired CPU to
take interrupts on.
This is only a hint and may not be honored in all
cases.
.IP
If syscallcpu is specified, it indicates the CPU to run non-MP
driver syscalls on.
This directive is always honored for non-MP
drivers, and is silently ignored by MP drivers.
This option should be
used with caution because non-MP drivers may expect their syscalls and
interrupts to run on the same CPU.
.PP
VECTOR: bustype=\f2bustype\f1 module=\f2fname\f1 adapter=\f2number\f1 ipl=\f2number\f1
.br
[ intr=\f2func\f1 ] [ vector=\f2number\f1 ] [ ctlr=\f2number\f1 ]
.br
[ iospace=(\f2address-space\f1,\f2address\f1,\f2size\f1) ]
.br
[ iospace2=(\f2address-space\f1,\f2address\f1,\f2size\f1) ]
.br
[ iospace3=(\f2address-space\f1,\f2address\f1,\f2size\f1) ]
.br
[ \f2probe_cmd\f1 ]
.IP
Specifies hardware to conditionally load.
(Note that this must be a single line.)
If a probe command is specified, the boot program performs the
probe sequence, as discussed above.
If the sequence succeeds, the
module is included.
.IP
If a probe sequence is not specified, the hardware is assumed to exist.
The bustype specifies the type of bus on which the device is connected.
This is VME for a VME bus.
.IP
The adapter specifies to which bus of type bustype the device is connected.
If adapter is set to \f4*\f1, the system looks at each bus of type bustype
to find the device.
.IP
The \f4intr\f1 function specifies the name of the module's interrupt handler.
If it is not specified, the prefix defined in the module's master file
(see \f4master\fP(4)) is concatenated with the string \f4intr\f1 and
if a routine with that name is found in the module's object (which
resides in the directory
\f4/var/sysgen/boot\f1),
it is used as the interrupt routine.
.IP
If the vector is not specified, it is assumed to be programmable.
The ctlr field is used to pass a value into the driver that is specific
to the device.
This can be used to identify which device is present when
there are multiple VECTOR lines for a particular device.
.IP
If the modules' object contains
a routine whose name is the concatenation of the master file
prefix and \f4edtinit\f1, that routine is involved once at startup
and passed a pointer to an edt structure that contains the values
for iospace, iospace2, iospace3, and a pointer to the bus info structure.
.PP
VECTOR: module=\f2fname\f1 probe_path=\f2pathname\f1
.IP
Specifies hardware to conditionally load (note that this
must be a single line). When a device with a vendor ID and
device ID is found on the system, the XIO/PCI infrastructure
will add a node in the hardware graph, accessible via the format
\f2/hw/.id/{pci,xio}/[vendorid][deviceid]\f1. For example, a PCI token ring
card might be described by \f4/hw/.id/pci/10B60002\f1 (note the id is
specified in hexadecimal with capital letters).
When \f4lboot\f1 configures the system, if \f2pathname\f1 exists then
the driver specified
by \f2fname\f1 will be loaded.
.PP
EXCLUDE: [ \f2string\f1 ] ...
.IP
Specifies drivers to exclude from the load even if the device is found
via VECTOR information.
.PP
INCLUDE: [ \f2string\f1[(\f2number\f1)] ] ...
.IP
Specifies software drivers or loadable modules to be included in the load.
This is necessary to include the drivers for software devices.
The optional \f2number\f1 (parenthesis required)
specifies the number of devices to be controlled by the driver
(defaults to 1).
This number corresponds to the builtin variable
.I ##c
which can be referred to by expressions in part two of the
\f4/var/sysgen/master\f1
file.
.PP
ROOTDEV: \f2devicefile\f1
.IP
Identifies the device containing the root filesystem.
.PP
SWAPDEV: \f2devicefile\f1 \f2number\f1 \f2number\f1
.IP
Identifies the device to be used as swap space, the block number the swap
space starts at, and the number of swap blocks available.
.PP
DUMPDEV: \f2devicefile\f1
.IP
Identifies the device to be used for kernel dumps.
.PP
IPL: \f2IRQ level\f1 \f2proc\f1
.IP
Send VME interrupt at \f2IRQ level\f1 to \f2proc\f1.
If \f2proc\f1 does not exist at run time, the kernel defaults to use processor 0.
.PP
USE: [ \f2string\f1[(\f2number\f1)] [ \f2extended_probe\f1 ] ] ...
.IP
If the driver is present, it is the same as INCLUDE.
Behaves like EXCLUDE if the module or driver is not present in
\f4/var/sysgen/boot\f1.
.PP
KERNEL: [ \f2string\f1 ] ...
.IP
Specifies the module containing the heart of the operating system.
It must be present in the system file.
.PP
NOINTR: \f2proc\f1 ...
.IP
In Origin, Onyx2, OCTANE, CHALLENGE and Onyx systems, NOINTR provides a
way to prevent processor(s) from receiving any interrupt other than the
VME IRQ levels defined using IPL directive. This can be used for marking
a processor for real time purpose. CPU 0 although should not be
restricted from receiving interrupts. This directive is ignored on all
other platforms.
.PP
LINKMODULES: \f21|0\f1
.IP
If set to 1, this option causes \f4lboot\f1 to ignore the \f4d\f1 option
in all master files and link all necessary modules into the kernel.
.PP
CC
.br
LD
.IP
The names of the compiler and linker used to build the kernel.
If absent, they default to \f4cc\f1 and \f4ld\f1, respectively.
.PP
CCOPTS
.br
LDOPTS
.IP
Option strings given to
\f4cc\f1(1)
and
\f4ld\f1(1)
respectively, to compile the \f4master.c\f1 file and link the operating
system.
.PP
TUNE-TAG: \f2string\f1 ...
.IP
Sets a set of tags to be used to qualify the various tunable parameters
for inclusion.
If a tunable parameter has no tag (see \f4mtune\fP(4)), it is always
included.
If a tunable parameter has a tag, it is included only if the tag matches
one of the tags specified by this parameter or via the \f4\-O\fP option to
\f4lboot\fP.
Tags can be used to permit a single set of \f4mtune\fP and \f4stune\fP
files to represent many different configurations.
.PP
DEVICE_ADMIN: \f2hwgraph-device-name variable-name=value\f1
.IP
Associates information (value) with the specified device and variable name
for later interpretation by a device driver or other system software. This
allows for a single mechanism that device drivers may use to establish
arbitrary "contracts" with the administrator. The particular variable names
used by a driver and the interpretation of their values are described in that
device driver's documentation.
.PP
DRIVER_ADMIN: \f2device-driver-name variable-name=value\f1
.IP
Works just like DEVICE_ADMIN, but for device drivers rather than for instances
of devices. Interpretation of variable names and values is defined by the
driver and described in device driver documentation.
.SH FILES
/var/sysgen/system/*.sm
.br
/usr/include/sys/edt.h
.SH SEE ALSO
lboot(1M),
master(4),
mtune(4),
stune(4).