The most important function of OpenBoot firmware is to boot the virtual machine. Booting is the process of loading and executing a stand-alone program such as an OS.
Booting can either be initiated automatically after the start-up sequence, or by typing a boot command at the OpenBoot CLI. The boot process is controlled by a number of configuration variables. For information on how to set the variables, see Setting Configuration Variables.
These are the boot related configuration variables:
auto-boot? – As described in Start-up Sequence, if true, attempt to boot according to OpenBoot parameters. If false, stop and invoke the OpenBoot CLI.
boot-command – The command specified for this variable is executed if auto-boot? is true. The default is boot with no arguments.
diag-switch? – false by default, when set to true, it sets OpenBoot to diagnostic mode which provides additional displayed messages.
boot-device –Specifies the device from which to boot. The value can be a device alias or a device path. The default is usually disk net, which attempts to boot from the device specified for the disk alias. If that fails, OpenBoot then attempts to boot from the device specified for the net alias.
boot-file – Specifies the default arguments for boot, if diagnostic-mode? is false.
The behavior of that program can be controlled by an argument string that is made available to the program. Often, this program is a secondary boot-loader, whose purpose is to load yet another program. The secondary boot-loader might be capable of using additional protocols other than the protocol that OpenBoot used to load the first program. For example, OpenBoot can use the Trivial File Transfer Protocol (TFTP) to load the secondary boot-loader, which then uses the Network File System (NFS) protocol to load the OS from another file.
For disk booting, OpenBoot might load the secondary boot loader by reading the first few sectors from the disk, and that secondary boot loader might understand the OS's native file system structure, loading the OS from such a file.
Typical secondary boot loaders accept arguments in this form:
filename -flags ...
Where filename is the name of a file containing the OS, and -flags is a list of options controlling the details of the start-up phase of either the secondary boot loader, the OS, or both. However, from OpenBoot's point of view, the boot arguments are an opaque string that is passed uninterpreted to the boot program.
The device path of the boot device is also available to client programs, so they can determine the device from which they were booted.
The boot command parses the command line as follows:
If the word following boot begins with a “/”, the word is a device path and, thus, a device specifier.
Otherwise, if there is a device alias matching that word, the word is a device specifier.
If that word is neither a device path nor a known alias, the default boot device is used, and the word is included in arguments.
Assuming that disk0 is predefined as a device alias for a valid device path, these are examples of valid boot commands:
ok boot (performs a default boot using values specified in configuration variables) ok boot disk0 (boots from disk0 and uses boot program default arguments) ok boot disk0 vmunix -asw (boots from disk0 and passes boot program vmunix -asw) ok boot vmunix -asw (boots from default device and passes boot program vmunix -asw)
The boot command might restart the virtual machine in certain conditions and continue with the boot process when the virtual machine is restarted.
Booting usually happens automatically based on the values contained in the configuration variables described above. However, you can also initiate booting from the OpenBoot CLI. For specific booting instructions, refer to these procedures:
OpenBoot performs the following steps during the boot process:
The firmware might reset the virtual machine if a client program has been executed since the last reset. (The execution of a reset is implementation dependent.)
A device is selected by parsing the boot command line to determine the boot device and the boot arguments to use. Depending on the form of the boot command, the boot device and argument values might be taken from configuration variables.
The bootpath and bootargs properties in the /chosen node of the device tree are set with the selected values.
The selected program is loaded into memory using a protocol that depends on the type of the selected device. For example, a disk boot might read a fixed number of blocks from the beginning of the disk, while a tape boot might read a particular tape file.
If Verified Boot is enabled, then signatures on the selected program are verified before the program is executed. If signature verification fails, the virtual machine continues to boot with warning messages displayed if verified boot policy is set to warning, or the virtual machine halts with FATAL messages if the policy is set to enforce. Details on how to set up Verified Boot and other related settings are available at: https://docs.oracle.com/cd/E53394_01/html/E54828/sysauth-vb.html.
The loaded program is executed. The behavior of the program might be further controlled by any argument string that was either contained in the selected configuration variable or was passed to the boot command on the command line.
The program loaded and executed by the boot process can be a secondary boot loader, whose purpose is to load yet another program. This secondary boot loader might use a protocol different from that used by OpenBoot. For example, OpenBoot might use the TFTP to load the secondary boot loader while the secondary boot loader might then use the NFS protocol to load the OS.
Typical secondary boot loaders accept arguments of the form:
filename -flags
Where filename is the name of the file containing the OS and where -flags is a list of options controlling the details of the start-up phase of either the secondary boot loader, the OS or both. As shown in the boot command template, OpenBoot treats all such text as a single, opaque arguments string that has no special meaning to OpenBoot itself. The arguments string is passed unaltered to the specified program.