boot(1M) — ADMINISTRATOR COMMANDS

NAME

boot − bootstrap procedures

DESCRIPTION

Bootstrapping is the process of loading and executing a standalone program. The term bootstrapping is used to describe the process of loading and executing the bootable operating system, but any standalone program can be booted instead. The diagnostic monitor for a machine is a good example of a standalone program other than the operating system that can be booted.

The bootstrap procedure on most machines consists of the following basic phases.

First, the machine is either turned on, or brought down to firmware mode in any of a number of ways (hardware reset button, a shutdown or init command, and so on). On powerup, the boot process is generally begun automatically: a small firmware program is loaded and executed, and the process moves into the second phase.

From firmware mode, however, the boot process is not automatic and the user can request the running of a firmware command, a standalone program (such as the bootable operating system), or the reconfiguration of the operating system.

Assume that an operating system boot is requested from firmware. The firmware boot code loads and executes a disk (or other storage media) based boot program.

Next, the boot program loads and executes the bootable operating system. It is at this point that the UNIX system is started, necessary file systems are mounted [see vfstab(4)], and init is run to bring the system to the initdefault state specified in /etc/inittab [see inittab(4)].

For the Motorola reference platform, the disk-based boot program is called boot and the tape-based boot program is called tapeboot. These programs are taken from the boot slice on disk or the first file on tape, and loaded and executed at boot time. Copies of these programs exist in the directory /usr/lib, for the purpose of copying to another hard disk using the dinit command or to another tape using the igf command.

The default bootable operating system file is /stand/unix for disks and COREunix for tapes. The /stand slice is defined in the disk’s VTOC table.

BOOT COMMANDS AND OPTIONS

For more information about what commands and options the boot supports, issue a boot command from the BUG but specify a file name of ;help. This help message will produce output which looks something like that shown below.

188-Bug>bo 6 0;help
Booting from: VME328, Controller 6, Drive 0
Loading: ;help
Volume: $00000000
IPL loaded at: $0F00000
  SVR4 Boot Loader 921013
Boot commands: "bo x y ;command"
make-kernel     force a new unix to be built
help            obtain these helpful messages
ls              list the files in the V_STAND slice
l               an alias for ls
?               an alias for help
Boot options: "bo x y file;option[;option] ..."
lockon          force MP locking on
lockoff         force MP locking off
root-slice      specify root FS slice; keyword=hex
boot-slice      specify V_STAND slice; keyword=hex
noprobe         do not run the device probes
one-cpu         use only the boot mpu
kdb             stop in kernel debugger on boot (if possible)
diagdiagnostic control; keyword=hex
probe           specify the probe output; keyword=hex
debug           specify the boot debugging; keyword=hex
halt            return to the BUG after loading kernel
h               an alias for halt
188-Bug>

The make-kernel command is used to force the system through the auto-configuration process. It is useful when you change a configurable parameter, forget to touch /stand/system, and shut the system down.

The help command lists the help message shown above.

The ls and l commands are used to view the contents of the V_STAND slice to determine what kernels are available.

The lockon option specifies that multiprocessor locking is to be forced on regardless of the number of CPUs on the platform.

The lockoff option specifies that multiprocessor locking is to be forced off regardless of the number of CPUs on the platform. No additional CPUs beyond the boot processor may be started if locking is off. If lockon and lockoff are specified together, lockon overrides lockoff.

The root-slice option specifies the slice on the boot device which is to be used as the root filesystem (this command is used only in special configurations). Slices are designated using a single hexadecimal digit [0-9a-fA-F].

The boot-slice option is used to select from the available V_STAND slices on a disk to locate the probes and the kernel (this command is used only in special configurations). Slices are designated using a single hexadecimal digit [0-9a-fA-F].

The noprobe option is used to avoid the time spent probing for new devices and subsequently checking whether the system needs to be reconfigured. No reconfiguration will occur if noprobe is specified even if one is needed.

On multiprocessor systems, one of the CPUs is used to initialize the majority of the system and then the remainder of the CPUs are started. Using the one-cpu option inhibits the starting of the remainder of the CPUs in the system. This option is useful for eliminating multiprocessor affects on the system (e.g., during driver debugging).

The kdb option causes the system to halt in the kernel debugger after the system has been initialized but before any additional CPUs are started and before the devices are initialized. If the kernel debugger is not installed, this option has no effect. See the kdb(1M) manpage for further details about the kernel debugger.

The diag option is used to specify the diagnostic control that the kernel is to run with. A level of zero (the default) specifies that no additional diagnostics or diagnostic output is requested. Other values specify more stringent testing and/or verbose output.

The probe option controls how much output is sent to the console terminal by the probe routines. The hex value must be between 0 and 7 inclusive and consists of three bits in which 0 indicates off and 1 indicates on. Bit 0 controls diagnostics for successful probe operations. Bit 1 controls diagnostics for failed probe operations. Bit 2 controls diagnostics for probe operations which are skipped (e.g., the ignore option in the EDT data file causes the entry to be skipped).

The debug option controls how much output is sent to the console terminal by the bootstrap. The hex value specifies bits which 0 indicates off and 1 indicates on. Bit 0 controls diagnostics for loading program sections. Bit 1 controls diagnostics for handling EDT. Bit 2 controls diagnostics for zeroing memory.

The halt and h options return to the ROM debugger after the image is loaded (this option requires intimate knowledge of how the image operates and should be used carefully). See the note below when using this option.

DIAGNOSTICS

The following table describes the diagnostics which may be seen when the system is booted.

equal sign is missing
The option being executed requires an equal sign to separate the keyword from the value and no equal sign was found.

invalid hex value
The option being executed requires a valid hexadecimal value. These valid

probe value must be <= 7
The probe value must be between 0 and 7 inclusive.

unknown option <option>
An unknown option was specified.

file name too long
Due to limitations of the BFS file system, all files have names containing less than 14 characters. The file specified contains more than 14 characters.

Unable to open <name>
The file name specified doesn’t exist or can’t be opened.

file <filename>: bad magic
The file specified is not a COFF or ELF executable and thus can not be loaded.

no compiled in configuration information found
Standard kernels have default configuration information compiled into the ELF file itself to allow the system to be booted without any probes. The file specified contained no such information.

cannot open file system
The file /stand/system either doesn’t exist or can’t be opened.

system file more recent than unix
The file /stand/system has been modified more recently than the kernel being booted and thus a reconfiguration of the kernel is required.

cannot open file edt_data
The file /stand/edt_data either doesn’t exist or can’t be opened.

edt_data file more recent than unix
The file /stand/edt_data has been modified more recently than the kernel being booted and thus a reconfiguration of the kernel is required.

help may used only with list
The help command was attempted with a command which is not one of the list commands.

slice <slice> isn’t tagged V_STAND
An attempt was made to boot from a slice which isn’t tagged as a V_STAND file system.

No /stand slice on device
There are no slices on this device which contain any bootable files.

noprobe and debug may not be used together
The commands noprobe and debug may not be used together.

must not specify a file name
A command or option was specified which does not take a file name but a file name was given.

must specify a file name
A command which requires a file was executed without any file specified.

Name = <kernel_name>, start address = <start_address>
This diagnostic message shows which object is booted and what the address in the object where execution will begin.

EDT table overflow
The number of devices specified in the EDT data file or found by the probes exceeds the boot program’s internal table size.

Using In-core EDT built by probe programs
This diagnostic message is issued when the information gathered by the probes is used (as opposed to the EDT information in the kernel itself).

Program load point <addr> is too near the boot loader
The program, when loaded, would cause the boot loader to be overwritten.

Incore and probed EDT entries differ for <name>, board <num>
A difference between the probe and the previously configuration information was found. The kernel should be reconfigured.

Adding required device <device> to EDT
This diagnostic is printed when a required device is added to the configuration information regardless of whether the device is actually present in the system.

No probe programs!: using builtin devices
No probe programs were found so the previously configuration information will be used by the kernel.

Boot: unable to run this kernel on this CPU
The kernel is not configured to run on the CPU it was booted on.

Boot: kernel configuration information missing
One or more the compiled in configuration sections of the kernel file were missing from the kernel.

Boot: inappropriate kernel CPU support
The kernel if either configured for a different CPU than the one it was booted on or it has support for more CPUs than are necessary. The kernel should be reconfigured.

NOTES

The boot program is not smart enough to differentiate between a bootable kernel or stand-alone program and a UNIX executable. Booting a UNIX executable will result in unpredictable results.

When booting an m88k UNIX kernel using the ;halt option, register 9 must be manually set to the value of 0xF00D before directly jumping to the start address of the kernel by using the GO command with an address parameter. Register 9 will be correctly set if the user just continues from the BUG by using the GO command without an address parameter.

Museum