| OpenBoot 4.x Command Reference Manual |
|
| OpenBoot 4.x Command Reference Manual |
|
| C H A P T E R 2 |
Booting and Testing Your System |
This chapter describes the most common tasks that you perform using OpenBoot:
The most important function of OpenBoot firmware is to boot the system. Booting is the process of loading and executing a stand-alone program such as an operating system. Booting can either be initiated automatically or by typing a command at the user interface.
The boot process is controlled by a number of configuration variables . Configuration variables are discussed in detail in Chapter 3 . The configuration variables that affect the boot process are:
auto-boot?
This variable controls whether or not the system automatically boots after a system reset or when the power is turned on. This variable is typically true .
boot-command
This variable specifies the command to be executed when auto-boot? is true . The default value of boot-command is boot with no command-line arguments.
boot-device
This variable contains the name of the default boot device that is used when OpenBoot is not in diagnostic mode.
boot-file
This variable contains the default boot arguments that are used when OpenBoot is not in diagnostic mode.
Based on the values of the above configuration variables, the boot process can proceed in a number of different ways. For example:
If auto-boot? is true , the system will boot from either the default boot device or from the diagnostic boot device depending on whether OpenBoot is in diagnostic mode.
If auto-boot? is false , the system may stop at the OpenBoot user interface without booting the system. To boot the system, you can do one of the following:
Type the boot command without any arguments. The system boots from the default boot device using the default boot arguments.
Type the boot command with an explicit boot device. The system boots from the specified boot device using the default boot arguments.
Typically, auto-boot? is true , boot-command is boot , and OpenBoot is not in diagnostic mode. Consequently, the system automatically loads and executes the program and arguments described by boot-file from the device described by boot-device when the system is first turned on or following a system reset.
If you want to boot the default program when auto-boot? is false , simply type boot at the ok prompt.
OpenBoot normally loads and executes an operating system or an operating system's loader program, but boot can also be used to load and execute other kinds of programs, such as diagnostics. For further details about loading programs other than the operating system, see Chapter 5 .
Booting usually happens automatically based on the values contained in the configuration variables described above. However, the user can also initiate booting from the user interface.
OpenBoot performs the following steps during the boot process:
The firmware may reset the system 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 may 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.
The loaded program is executed. The behavior of the program may 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 program , whose purpose is to load yet another program. This secondary boot program may use a protocol different from that used by OpenBoot to load the secondary boot program. For example, OpenBoot might use the Trivial File Transfer Protocol (TFTP) to load the secondary boot program while the secondary boot program might then use the Network File System (NFS) protocol to load the operating system.
Typical secondary boot programs accept arguments of the form:
Where
filename
is the name of the file containing the operating system and where
-flags
is a list of options controlling the details of the start-up phase of either the secondary boot program, the operating system 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.
The boot command has the following format:
The optional parameters for the boot command are described in TABLE 2-1 .
Since a device alias cannot be syntactically distinguished from the arguments , OpenBoot resolves this ambiguity as follows:
If the space-delimited word following boot on the command line begins with / , the word is a device-path and, thus, a device-specifier . Any text to the right of this device-specifier is included in arguments .
If the space-delimited word matches an existing device alias, the word is a device-specifier . Any text to the right of this device-specifier is included in arguments .
Otherwise, the appropriate default boot device is used, and any text to the right of boot is included in arguments .
Consequently, boot command lines have the following possible forms.
With this form, boot loads and executes the program specified by the default boot arguments from the default boot device.
If boot has a single argument that either begins with the character / or is the name of a defined devalias , boot uses the argument as a device specifier. boot loads and executes the program specified by the default boot arguments from the specified device.
For example, to explicitly boot from the primary disk, type:
To explicitly boot from the primary network device, type:
If boot has a single argument that neither begins with the character / nor is the name of a defined devalias , boot uses all of the remaining text as its arguments.
boot loads and executes the program specified by the arguments from the default boot device.
If there are at least two space-delimited arguments, and if the first such argument begins with the character / or if it is the name of a defined devalias , boot uses the first argument as a device specifier and uses all of the remaining text as its arguments. boot loads and executes the program specified by the arguments from the specified device.
For all of the above cases, boot records the device that it uses in the bootpath property of the /chosen node. boot also records the arguments that it uses in the bootargs property of the /chosen node.
Device alias definitions vary from system to system. Use the devalias command, described in Chapter 1 , to obtain the definitions of your system's aliases.
The network boot process involves:
Obtaining the IP address of the booting client
The client knows its Ethernet address and system type, but needs its IP address to transfer the files it needs.
Downloading the standalone boot program and executing it
The client uses TFTP (Trivial File Transfer Protocol) to download the standalone boot program and executes it.
A client booting over a network can use RARP (Reverse Address Resolution Protocol) to obtain its IP address. When booting Solaris software, the loaded standalone program is 'inetboot' which uses the RPC protocol 'bootparams' to obtain boot parameters, and loads the kernel and executes it. To boot with RARP and bootparams, use the command:
Clients that are DHCP (Dynamic Host Configuration Protocol) aware can use DHCP to obtain the IP address, boot parameters, and network configuration information with more efficiency and flexibility than the combination of the RARP and bootparams services. In addition, using DHCP removes the requirement for a boot server on every subnet. To boot with DHCP, use the command:
DHCP aware PROM clients support inter operability with BOOTP (Bootstrap Protocol) servers. The client prefers DHCP configurations over BOOTP, but accepts BOOTP configurations if no DHCP configuration is offered.
The default protocol used (that is, RARP or DHCP) when the command boot net is executed depends on how the 'net' device alias is specified. If the net devalias specifies only the path to the network device, RARP is used as the default address discovery protocol. If the device alias includes dhcp as an argument, DHCP is used. The following examples show how the 'net' device alias must be defined to select RARP or DHCP booting on a Sun Blade 100 (The default is RARP boot):
You can set the desired device alias by using the nvalias command.
The network boot support package ( obp-tftp ) enables a wide range of system knowledge to be used in the boot process. At one extreme, the client knows nothing except its Ethernet address and system type. At the other end, the client can know the server's IP address, its own IP address, router addresses necessary, and so on. The following syntax is supported for network boot:
boot <network-device>:[dhcp|bootp,][server-ip], [boot-filename],[client-ip],[router-ip],[boot-retries], [tftp-retries],[subnet-mask][boot-arguments] |
All arguments are optional. Commas are required for missing positional parameters unless they are at the end of the list.
server-ip , client-ip , router-ip, and subnet-mask are specified in Internet standard "dotted-decimal" notation.If any of server-ip , boot-filename , client-ip , router-ip , and subnet-mask are specified, the PROM client uses these values instead of any values which are (or may be) obtained by the normal configuration process.
dhcp specifies the use of DHCP as the address discovery protocol to be used. bootp is treated as a synonym of DHCP (that is, the client still uses DHCP format messages). The client accepts a BOOTP configuration only if no DHCP configurations are offered.
server-ip is the IP address of the TFTP server from which the standalone boot program is to be downloaded.
boot-filename is the name of the standalone program to be loaded by TFTP from the server. The default file name is constructed from the IP address if the boot protocol is RARP, or from the client class identifier if using DHCP/BOOTP.
client-ip is the IP address of the client (i.e., the system being booted).
router-ip is the IP address of router to be used.
boot-retries is the maximum number of retries attempted before the boot process is determined to have failed.
tftp-retries is the maximum number of retries attempted before the TFTP process is determined to have failed.
subnet-mask is the subnet mask on the local network.
Several diagnostic commands are available from the user interface. These commands let you check devices such as the network controller, the diskette system, memory, installed SBus cards and SCSI devices, and the system clock.
The value returned by diagnostic-mode? controls:
The selection of the device and file that are used by the boot and load commands (if the device and file are not explicitly specified as arguments to those commands).
OpenBoot is in diagnostic mode and the diagnostic-mode? command returns true if at least one of the following conditions is met:
When OpenBoot is in diagnostic mode, the value of diag-device is used as the default boot device and the value of diag-file is used as the default boot arguments for the boot command.
When OpenBoot is not in diagnostic mode, the value of boot-device is used as the default boot device and the value of boot-file is used as the default boot arguments for the boot command.
TABLE 2-2 lists diagnostic test commands. Not all of these tests are available in all OpenBoot implementations.
|
Note Note - Running any diagnostic test command may cause the system to reset before booting. |
The extent of diagnostic coverage performed by self-test methods may depend on the setting of the diag-level configuration variable as well as on the test arguments and on whether or not the system is in diagnostic mode.
|
Note Note - To assure maximum coverage of testing make sure your system is in diagnostic mode and diag-level is set to max. |
The extent of diagnostics coverage performed by self-test methods may depend on the setting of the diag-level configuration variable as well as on the test arguments and on whether or not the system is in diagnostic mode.
To assure maximum coverage of testing make sure your system is in diagnostic mode and diag-level is set to max .
To check a SCSI bus for connected devices, type:
The actual response depends on the devices on the SCSI bus.
To test a single installed device, type:
In general, if no message is displayed, the test succeeded.
|
Note Note - Many devices require the system's diag-switch? parameter to be true in order to run this test. |
The removable media drive test determines whether or not the removable media drive being tested is functioning properly. For some implementations, a formatted, high-density (HD) disk, a CD-ROM or a tape must be in the appropriate removable media drive for this test to succeed.
To test the diskette drive, type:
ok test floppy Testing floppy disk system. A formatted disk should be in the drive. Test succeeded. ok |
|
Note Note - Not all OpenBoot systems include this test word. |
To eject the diskette from the diskette drive of a system capable of software-controlled ejection, type:
To test the CD-ROM drive, type:
|
Note Note - Not all OpenBoot systems include this test word. |
To eject the CD-ROM from the CD-ROM drive of a system capable of software-controlled ejection, type:
|
Note Note - Not all OpenBoot systems include this test word. |
To eject the tape from the tape drive of a system capable of software-controlled ejection, type:
In the preceding example, the first number (4000000) is the base address of the testing, and the following number (11) is the number of megabytes to go.
|
Note Note - Not all OpenBoot systems include this test word. |
To test the clock function, type:
ok watch-clock Watching the 'seconds' register of the real time clock chip. It should be ticking once a second. Type any key to stop. 1 ok |
The system responds by incrementing a number once a second. Press any key to stop the test.
|
Note Note - Not all OpenBoot systems include this test word. |
To test the primary network controller, type:
The system responds with a message indicating the result of the test.
To monitor a network connection, type:
The system monitors network traffic, displaying " . " each time it receives an error-free packet and "X " each time it receives a packet with an error that can be detected by the network hardware interface.
|
Note Note - Not all OpenBoot systems include this test word. |
The user interface provides one or more commands to display system information. banner is provided by all OpenBoot implementations; the remaining commands represent extensions provided by some implementations. These commands, listed in TABLE 2-3 , let you display the system banner, the Ethernet address for the Ethernet controller, the contents of the ID PROM, and the version number of OpenBoot. The ID PROM contains information specific to each individual system, including the serial number, date of manufacture, and Ethernet address assigned to the system.
Also see the device tree browsing commands in TABLE 1-3 .
Occasionally, you may need to reset your system. The reset-all command resets the entire system and is similar to performing a power cycle.
If your system is set up to run the power-on self-test (POST) and initialization procedures on reset, these procedures begin executing once you initiate this command. (On some systems, POST is only executed after power-on.) Once POST completes, the system either boots automatically or enters the user interface, just as it would have done after a power cycle.
| OpenBoot 4.x Command Reference Manual | 816-1177-10 |
|
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.