system(4)system(4)NAMEsystem - system configuration information directory
DESCRIPTION
This directory contains files (with the .sm suffix) that are used by the
lboot 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 rootdev, as well as instructions for manually
overriding the drivers selected by the self-configuring boot process.
Each major subsystem can have its own configuration file, for example:
irix.sm (base operating system configuration file), gfx.sm (graphics
subsystem configuration file), and so forth. lboot logically
concatenates all files in the system directory with the .sm suffix and
processes the results.
The syntax of the system files is given below. The parser for the
/var/sysgen/system/*.sm file is case sensitive. All uppercase strings in
the syntax below should be uppercase in the /var/sysgen/system/*.sm file
as well. Nonterminal symbols are enclosed in angle brackets, , while
optional arguments are enclosed in square brackets, []. Ellipses, ...,
indicate optional repetition of the argument for that line.
fname ::= master filename from /master.d directory
func ::= interrupt function name
devicefile :: = special device name
major ::= number
minor ::= number
proc ::= processor # as interpreted by runon(1)
number ::= decimal, octal or hex literal
lboot 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:
probe_cmd ::= probe=number
[ probe_size=number ] | extended_probe
extended_probe ::= exprobe=probe_sequence
| exprobe=(probe_sequence,probe_sequence,...)
probe_sequence ::= (seq,address,size,value,mask)
seq ::= a sequence of 1 or more r's, rn's, or w's, indicating a
read from address or a write to address
address ::= number
size ::= number
value ::= number
mask ::= number
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 probe_size bytes (default 4) to
determine if the hardware exists for the module. If the read succeeds,
Page 1
system(4)system(4)
the hardware is assumed to exist, and the module is included.
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).
probe_cmd ::= probe_space=(bus_space,number
[ probe_size=number ] | extended_probe)
extended_probe ::= exprobe_space=probe_sequence
| exprobe_space=(probe_sequence,probe_sequence, ...)
probe_sequence ::= (seq,bus_space,address,size,
value,mask)
seq ::= a sequence of 1 or more r's, rn's, or w's, indicating a
read from address, or a write to address.
bus_space ::= A16NP | A16S | A24NP | A24S | A32NP | A32S
address ::= number
size ::= number
value ::= number
mask ::= number
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 sequence, an address to read or write, a size of up to four
bytes, a value, and a mask. Then, for each five-tuple, the following is
performed:
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
The third probe command format is required to detect XIO and PCI
peripherals on platforms such as Octane and Origin.
probe_cmd ::= probe_path=pathname
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.
Page 2
system(4)system(4)
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.
VECTOR: module=fname [ intr=func ]
[ vector=number ipl=number unit=number ] [ base=number ]
[ base2=number ] [ base3=number ]
[ probe_cmd ]
[ intrcpu=number ] [ syscallcpu=number ]
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.
If a probe sequence is not specified, the hardware is assumed to
exist. The intr 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 master(4)) is concatenated with the
string intr, and, if a routine with that name is found in the
module's object (which resides in the directory /var/sysgen/boot),
it is used as the interrupt routine.
If the triplet (vector, ipl, unit, base) is specified, a VME
interrupt structure is assigned, using the corresponding VME address
vector, priority level ipl, unit unit.
If the modules' object contains a routine whose name is the
concatenation of the master file prefix and edtinit, 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.
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.
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.
VECTOR: bustype=bustype module=fname adapter=number ipl=number
[ intr=func ] [ vector=number ] [ ctlr=number ]
[ iospace=(address-space,address,size) ]
[ iospace2=(address-space,address,size) ]
[ iospace3=(address-space,address,size) ]
Page 3
system(4)system(4)
[ probe_cmd ]
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.
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.
The adapter specifies to which bus of type bustype the device is
connected. If adapter is set to *, the system looks at each bus of
type bustype to find the device.
The intr 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 master(4)) is concatenated with the string intr and
if a routine with that name is found in the module's object (which
resides in the directory /var/sysgen/boot), it is used as the
interrupt routine.
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.
If the modules' object contains a routine whose name is the
concatenation of the master file prefix and edtinit, 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.
VECTOR: module=fname probe_path=pathname
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
/hw/.id/{pci,xio}/[vendorid][deviceid]. For example, a PCI token
ring card might be described by /hw/.id/pci/10B60002 (note the id is
specified in hexadecimal with capital letters). When lboot
configures the system, if pathname exists then the driver specified
by fname will be loaded.
EXCLUDE: [ string ] ...
Specifies drivers to exclude from the load even if the device is
found via VECTOR information.
Page 4
system(4)system(4)
INCLUDE: [ string[(number)] ] ...
Specifies software drivers or loadable modules to be included in the
load. This is necessary to include the drivers for software
devices. The optional number (parenthesis required) specifies the
number of devices to be controlled by the driver (defaults to 1).
This number corresponds to the builtin variable ##c which can be
referred to by expressions in part two of the /var/sysgen/master
file.
ROOTDEV: devicefile
Identifies the device containing the root filesystem.
SWAPDEV: devicefile number number
Identifies the device to be used as swap space, the block number the
swap space starts at, and the number of swap blocks available.
DUMPDEV: devicefile
Identifies the device to be used for kernel dumps.
IPL: IRQ level proc
Send VME interrupt at IRQ level to proc. If proc does not exist at
run time, the kernel defaults to use processor 0.
USE: [ string[(number)] [ extended_probe ] ] ...
If the driver is present, it is the same as INCLUDE. Behaves like
EXCLUDE if the module or driver is not present in /var/sysgen/boot.
KERNEL: [ string ] ...
Specifies the module containing the heart of the operating system.
It must be present in the system file.
NOINTR: proc ...
In Origin series, Onyx series, Tezro, OCTANE, and CHALLENGE sytems,
NOINTR provides a way to prevent processor(s) from receiving any
interrupt other than the VME IRQ levels defined using IPL directive
or PCI(-X) interrupts sent there with interrupt targetting. 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.
LINKMODULES: 1|0
Page 5
system(4)system(4)
If set to 1, this option causes lboot to ignore the d option in all
master files and link all necessary modules into the kernel.
CC
LD
The names of the compiler and linker used to build the kernel. If
absent, they default to cc and ld, respectively.
CCOPTS
LDOPTS
Option strings given to cc(1) and ld(1) respectively, to compile the
master.c file and link the operating system.
TUNE-TAG: string ...
Sets a set of tags to be used to qualify the various tunable
parameters for inclusion. If a tunable parameter has no tag (see
mtune(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 -O option to lboot. Tags can be used to
permit a single set of mtune and stune files to represent many
different configurations.
DEVICE_ADMIN: hwgraph-device-name variable-name=value
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.
DRIVER_ADMIN: device-driver-name variable-name=value
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.
FILES
/var/sysgen/system/*.sm
/usr/include/sys/edt.h
SEE ALSOlboot(1M), master(4), mtune(4), stune(4).
Page 6
