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. These tasks enable you to:


Booting Your System

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:

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 .

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.

If the value is true , run in the Diagnostic mode. This variable is false by default.

This variable contains the name of the default boot device that is used when OpenBoot is not in diagnostic mode.

This variable contains the default boot arguments that are used when OpenBoot is not in diagnostic mode.

This variable contains the name of the default diagnostic mode boot device.

This variable contains the default diagnostic mode boot arguments.

Based on the values of the above configuration variables, the boot process can proceed in a number of different ways. For instance:

Booting for the Casual User

Typically, auto-boot? will be true , boot-command will be boot , and OpenBoot will not be in diagnostic mode. Consequently, the system will automatically load and execute 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.

Booting for the Expert User

Booting is the process of loading and executing a client program. The client program is normally 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 more 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:

Often, the program loaded and executed by the boot process is 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:

filename -flags

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. Please note that, as shown in the boot command template immediately below, 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:

ok boot [device-specifier] [arguments]

The optional parameters for the boot command are described in .

TABLE 2-1 Optional boot Command Parameters

Parameter

Description

[ device-specifier ]

The name (full path name or devalias ) of the boot device. Typical values include:

cdrom (CD-ROM drive)

disk (hard disk)

floppy (3-1/2" diskette drive)

net (Ethernet)

tape (SCSI tape)

If device-specifier is not specified and if diagnostic-mode? returns false , boot uses the device specified by the boot-device configuration variable.

If device-specifier is not specified and if diagnostic-mode? returns true , boot uses the device specified by the diag-device configuration variable.

[ arguments ]

The name of the program to be booted (e.g. stand/diag ) and any program arguments.

If arguments is not specified and if diagnostic-mode? returns false , boot uses the file specified by the boot-file configuration variable.

If arguments is not specified and if diagnostic-mode? returns true , boot uses the file specified by the diag-file configuration variable.




Note - Most commands (such as boot and test) that require a device name accept either a full device path name or a device alias. In this manual, the term device-specifier indicates that either an appropriate device path name or a device alias is acceptable for such commands.


Since a device alias cannot be syntactically distinguished from the arguments , OpenBoot resolves this ambiguity as follows:

Consequently, boot command lines have the following possible forms.

ok boot

With this form, boot loads and executes the program specified by the default boot arguments from the default boot device.

ok boot device-specifier

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:

ok boot disk

To explicitly boot from the primary network device, type:

ok boot net

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.

ok boot arguments

boot loads and executes the program specified by the arguments from the default boot device.

ok boot device-specifier arguments

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.


Running Diagnostics

Several diagnostic routines are available from the User Interface. These on-board tests let you check devices such as the network controller, the floppy disk system, memory, installed SBus cards and SCSI devices, and the system clock.

The value returned by diagnostic-mode? controls:

OpenBoot will be in diagnostic mode and the diagnostic-mode? command will return true if at least one of the following conditions is met:

When OpenBoot is in the 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 the 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.

lists diagnostic test commands. Not all of these tests are available in all OpenBoot implementations.

TABLE 2-2 Diagnostic Test Commands

Command

Description

probe-scsi

Identify devices attached to a SCSI bus.

test device-specifier

Execute the specified device's selftest method. For example:

test net - test the network connection

watch-clock

Test a clock function.

watch-net

Monitor a network connection.


Testing the SCSI Bus

To check a SCSI bus for connected devices, type:

ok probe-scsi
Target 1
Unit 0 Disk SEAGATE ST1480 SUN04246266 Copyright (C) 1991 Seagate All rights reserved
Target 3
Unit 0 Disk SEAGATE ST1480 SUN04245826 Copyright (C) 1991 Seagate All rights reserved
ok

The actual response depends on the devices on the SCSI bus.

Testing Installed Devices

To test a single installed device, type:

ok test device-specifier

In general, if no message is displayed, the test succeeded.



Note - Many devices require the system's diag-switch? parameter to be true in order to run this test.


Testing the Diskette Drive

The diskette drive test determines whether or not the diskette drive is functioning properly. For some implementations, a formatted, high-density (HD) disk must be in the diskette 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 - 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:

ok eject-floppy
ok

Testing Memory

To test memory, type:

ok test /memory
Testing 16 megs of memory at addr 4000000 11
ok



Note - Not all OpenBoot systems include this test word.


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.

Testing the Clock

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.
ok

The system responds by incrementing a number once a second. Press any key to stop the test.



Note - Not all OpenBoot systems include this test word.


Testing the Network Controller

To test the primary network controller, type:

ok test net
Internal Loopback test - (result)
External Loopback test - (result)
ok

The system responds with a message indicating the result of the test.



Note - Depending on the particular network controller and the type of network to which your system is attached, various levels of testing are possible. Some such tests may require that the network interface be connected to the network.


Monitoring the Network

To monitor a network connection, type:

ok watch-net
Internal Loopback test - succeeded
External Loopback test - succeeded
Looking for Ethernet packets.
'.' is a good packet. 'X' is a bad packet.
Type any key to stop
....................X.....X...............
ok

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 - Not all OpenBoot systems include this test word.



Displaying System Information

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 , 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 machine, including the serial number, date of manufacture, and Ethernet address assigned to the machine.)

TABLE 2-3 System Information Commands

Command

Description

banner

Display power-on banner.

show-sbus

Display list of installed and probed SBus devices.

.enet-addr

Display current Ethernet address.

.idprom

Display ID PROM contents, formatted.

.traps

Display a list of processor-dependent trap types.

.version

Display version and date of the boot PROM.

. speed

Display processor and bus speeds.


Also see the device tree browsing commands in .


Resetting the System

Occasionally, you may need to reset your system. The reset-all command resets the entire system and is similar to performing a power cycle.

To reset the system, type:

ok reset-all

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.

Copyright © 2001, Sun Microsystems, Inc. All rights reserved.