system(4) system(4) NAME system - 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, 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. 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) ] [ 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. 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 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 ALSO lboot(1M), master(4), mtune(4), stune(4). Page 6