Understanding the OpenBoot PROM | Solaris 9 Sun Certified System Administrator Study Guide

On Scalable Processor Architecture (SPARC) computers, the initial booting of the computer is controlled by the OpenBoot PROM (OBP). The OBP acts as an intermediary between the hardware and the Solaris operating system, preparing the computer for the loading of an operating system during boot.

The OBP is stored in two chips on your motherboard and controls the entire boot process of your Sun computer. The two parts of the OBP are the boot PROM itself, which contains startup information regarding your system, and the Non-Volatile Random Access Memory (NVRAM). The NVRAM contains built-in hardware diagnostics, device information, device aliases, the host ID, Ethernet address, and system Time of Day (TOD) clock. The most current version of OpenBoot is version 4.x, and the examples listed in this chapter reflect this version.

OBP is often referred to as firmware, because it's not quite classified as software or hardware but acts as a liaison between the two. Without OBP, the system would not know how to boot, and Solaris would never load.

The OBP is directly responsible for the following tasks:

Determining the system's hardware configuration
Testing and initializing the system's hardware
Loading the operating system from a local storage device or the network
Providing an interface for modification of system startup configuration parameters and NVRAM parameters
Interpreting programs written in the Forth programming language

The boot process on a SPARC computer has four distinct phases: the boot PROM, boot programs, kernel initialization, and init. The boot process on a SPARC machine follows this order:

In the boot PROM phase, the boot PROM displays system information and runs the Power-On Self-Test (POST), which checks the integrity of the system's hardware and memory. The hardware check is fairly superficial and will detect only serious problems. After the POST, the boot PROM loads bootblk (boot block), the primary startup program. The sole purpose of bootblk is to find and execute the secondary boot program, ufsboot, and load it into memory.
During the boot programs phase, bootblk finds and executes the secondary boot program, ufsboot, and loads it into memory. Then ufsboot loads the operating system's kernel.
During the kernel initialization phase, the kernel initializes and begins loading modules. After enough modules are loaded, the kernel mounts the root (/) file system. The kernel then starts the /sbin/init process, which reads the /etc/inittab file to start other processes.
The last phase is the init phase. Here the /sbin/init process loads run control (rc) scripts, which in turn execute other scripts to complete the operating system initialization.

Tip

Know the order of boot phases for a SPARC computer: boot PROM, boot programs, kernel initialization, and init.

The /sbin/init process and /etc/inittab files will be discussed in more depth later in this chapter. Knowing the order of the boot process can help you determine where to start troubleshooting if there is a boot problem on your computer.

OpenBoot Features

Although OpenBoot was originally designed to work on SPARC systems, it features a processor-independent design. Because of this, it is not proprietary, and its considerable functionality can be used on many platform types. Here are some notable features of OpenBoot:

Plug-in device drivers A plug-in driver is a driver loaded from an expansion bus card located within your machine. Plug-in drivers can be used to boot the operating system, thereby avoiding the boot PROM. This feature is useful if you have devices that are not supported by your existing firmware; you can operate your system without changing your boot PROM.

FCode interpreter Plug-in drivers are written in a language called FCode, which is machine independent. Each OBP contains an FCode interpreter. This enables the same devices and drivers to be used on machines that have differing CPU types.

Device tree All hardware devices installed in a Sun computer are part of a hierarchical classification system called a device tree. The position within the device tree identifies the physical location of the device (also known as a node) within the system.

A node with children is typically a system bus (such as an IDE or SCSI bus). Child devices (physical disks, expansion cards) are identified by a unique hardware address, with their address being based on their parent node. The hardware address (also called the physical address) is based upon the unique physical location of the device in the system, such as a particular controller or slot.

Programmable user interface The OBP is based on the Forth programming language. Users can create programs in this language to perform various tasks, including modifying some boot processes, and debugging hardware and software problems.

Accessing OpenBoot

OpenBoot is accessed through a user interface based on the Forth programming language. Consequently, you will often hear the OBP prompt referred to as a Forth Monitor or Forth prompt. When you are in the OBP, you will be given an ok prompt.

Tip

Some older versions of OpenBoot used a > as their prompt. This was known as the Restricted Monitor. If your machine gives you this prompt, type n and press Enter to switch to an ok prompt.

There are four ways to enter the OBP:

If you are in Solaris, use the init 0 or shutdown commands to halt the operating system.
Press the Stop and A keys at the same time (Stop+A).
Reboot the machine. If your computer is not configured to boot automatically, it will stop at the OBP prompt. If your system is configured to boot automatically, you can stop it by pressing Stop+A on the keyboard after the display banner appears but before the operating system loads.
When the system detects an unrecoverable hardware error (called a Watchdog Reset).

Tip

If you are at the ok prompt and need assistance, type help.

Devices and Device Aliases

OpenBoot deals directly with all hardware devices in the system. Each device is identified by a unique device name, which categorizes the device based on its type and location within the system. All system devices are then organized into a device tree, which is built with information gathered during system POST. The following are two examples of device names:

 /pci@1f,0/ide@d/disk@0,0 /pci@1f,0/usb@c,3/keyboard@4

The full device path names shown in the examples are a series of node names separated by slashes. The slash at the beginning indicates the machine node. The machine node is the root of the device tree and does not receive an explicit name. The first device name in the example shows the first internal IDE hard disk, disk0. The second device in the example is an external Universal Serial Bus (USB) device, the keyboard. Each device listed will have the following form:

 driver-name@unit-address:device-arguments

To gain a better understanding of what all this means, analyze the earlier example. First, the hard disk. The first part of the device name (/pci@1f,0) indicates that this system has a PCI architecture. The 1f,0 portion represents an address on the main PCI system bus. Another common architecture to see with Sun systems is the SBus architecture, which will generally read as /sbus@1f,0. The ide@d portion indicates that this is an IDE controller, at address d. The last portion of the first example shows the device name of the disk, which is at address 0,0. This generally refers to the first disk on that particular IDE controller.

Now on to the second example, this time without extra commentary. The keyboard is attached to the same motherboard as the hard disk, identified as /pci@1f,0. There is a USB controller at address c,3 (usb@c,3), and the keyboard itself is at address 4 on the USB controller. The more you deal with full device names, the more sense they tend to make. To display the list of configured devices in your system, use the following command:

 ok show-devs

A lot of the devices that you will see will make some sense. Names such as serial, parallel, floppy, and cdrom are somewhat intuitive. Others might not make any sense at all, for example, /pci@1f,0/pmu@3/ppm@0,b3. Unless you know what ppm stands for, this name might not do much for you.

None of the earlier examples had any device arguments, so here's one more example for good measure:

 /sbus@1f,0/scsi@1,2/sd@2,0:a

This example is from a system with SBus architecture, and 1f,0 represents an address on the main board. The SCSI controller is at address 1,2. The SCSI disk (sd) is attached to the SCSI bus at target 2, with a logical unit number of 0. Device arguments differ in format based on the device they are attached to, but they always follow a colon (such as :a, seen in the code line above). In this case, the driver for the SCSI disk interprets the argument as a partition value. So, this particular example refers to partition a of this SCSI disk.

It might be a necessary evil to have long device names to keep track of all unique devices on a computer. However, always having to type in the long name when referring to a device can get a bit cumbersome. There has to be an easier way, doesn't there? There is: device aliases.

Device Aliases

The sad fact is, computers are smarter than humans. Just ask a computer. They can look at a device name such as /sbus@1f,0/scsi@1,2/sd@2,0:a and immediately know everything they need to about the device. Humans on the other hand prefer simplicity. We'd rather call the device something easy to remember, such as "disk1." Disk1 is easier to say, type, and remember.

Device aliases are for human ease. A device alias is an ordinary name for a configured device on a Solaris-based computer. You can also think of a device alias as a shorthand notation for a full device path. Not all devices have device aliases, but some common ones are set up during installation. You can see the device aliases and their associated devices by typing the following:

 ok devalias

Devices that are commonly referred to, such as the floppy, hard disks, CD-ROM drives, network card, keyboard, and mouse are among the devices that have default aliases. For devices that do not have an alias, you can manually create one by using the devalias command. Options for devalias are shown in Table 3.1.

Table 3.1: *devalias* Usage
Command	Description
devalias	Displays all current device aliases and their associated devices.
devalias alias	Displays the full path name to the specified device alias.
devalias alias devicepath	Defines an alias for the device path provided. If the alias provided already exists, the new value overwrites the old value.

If the system is reset or loses power, all user-defined device aliases are lost. To avoid this, you have two choices. One is to save the devalias command used to create the device in a portion of NVRAM called NVRAMRC (Non-Volatile Random Access Memory Run Control). The other is to use the nvalias command to create your aliases.

Booting from the Boot PROM

By default, most systems boot to a user login screen. This is because of two NVRAM variables: auto-boot? (set to true) and boot-command (set to boot). These two variables tell the system to auto-boot and to use the boot command, respectively. These NVRAM parameters will be discussed in more detail shortly.

However, there might be cases when you don't want your system to auto-boot, or maybe you have rebooted the system into the boot PROM and want to get back to Solaris. To boot your system manually from the ok prompt, you use (ironically) the boot command. Here is the syntax for the boot command:

 ok boot device filename arguments flags

The boot command offers many options and gives the user great flexibility when controlling the boot process. The various parameters of the boot command are as follows:

device enables the user to specify the device that the system will boot from. The default is generally the hard disk. Some choices for this parameter are disk, net, cdrom, tape, and floppy. Full device paths and device aliases can also be specified.

Note

Booting from the network requires a boot server on the network and one of two protocols: Dynamic Host Configuration Protocol (DHCP) or Reverse Address Resolution Protocol (RARP). RARP is the default network boot protocol in Solaris 9.

If you want to specify an alternate kernel as opposed to the default, you could use the filename option as the full path to the alternate kernel's file name. This could be handy if you are testing new products.
The boot command supports various arguments. They include: -a, which boots into interactive mode, requiring the user to specify boot details (such as kernel, system file, root file system type, and physical name of the root device); -r, which is used after the system is reconfigured; and -s, which forces Solaris into the S run level.

Tip
To boot your Solaris computer into kernel debugging mode, type boot kadb at the ok prompt.
All flags are passed on to the file specified in the filename parameter and are dependent upon how the file itself interprets them.

Running Diagnostics and Displaying System Information

One of the helpful features of OpenBoot is the built-in set of diagnostic tools. Diagnostic tools incorporated into OpenBoot enable you to test various system devices, including the system clock, floppy disk drive, network interface card, SCSI devices, and memory. A list of common diagnostic commands is displayed in Table 3.2.

Table 3.2: OpenBoot Diagnostic Commands
Command	Description
test floppy	Tests the floppy disk drive
test net	Tests the network adapter
test scsi	Tests SCSI adapters (if applicable)
test /memory	Tests the system's memory
probe-scsi	Displays attached SCSI devices in the system (if applicable)
watch-clock	Displays the computer's real-time clock
watch-net	Monitors the network for broadcast packets

Unfortunately, not all the tests listed in Table 3.2 are available in all versions of OpenBoot. To see which tests are valid on your computer, type help test or help diag at the ok prompt.

OpenBoot also comes with a set of commands designed to display system information. We have already looked at two such commands: show-devs to display system devices and devailas to show device aliases. Table 3.3 lists more commands used to display system information.

Table 3.3: OpenBoot System Information Commands
Command	Description
banner	Displays the system's power-on banner
show-sbus	Shows a list of installed and probed SBus devices (if your computer has this architecture)
.enet-addr	Displays the current Ethernet address
.id-prom or .idprom	Displays ID PROM contents
.traps	Displays a list of processor trap types
.version	Shows detailed information about the OpenBoot PROM
.speed	Displays processor and system bus speeds

As with the diagnostic commands, not all of these informational commands are available in all OpenBoot versions. As an example, .speed does not work in OpenBoot release 4.5.

The most versatile of the information commands is banner. The banner command displays the same power-on banner you see at the beginning of the boot process and contains a great deal of information, including the OpenBoot version, amount of memory installed, serial number, Ethernet address, and host ID number. Here is an example.

 ok banner Sun Blade 100 (UltraSPARC-IIe), Keyboard Present Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.5, 256 MB memory installed, Serial #8675309. Ethernet address 0:3:ba:15:d:18, Host ID: 84107d19.

Both the banner and .version commands display information about the OpenBoot version. However, banner displays more-general system information, whereas .version displays detailed information about just the OpenBoot PROM.

Modifying NVRAM

Most user-definable OpenBoot variables are stored in an area of the OpenBoot PROM called Non-Volatile Random Access Memory (NVRAM). With these variables, you can control everything from the boot process to system output to OpenBoot security parameters. The exact variables offered depend on the version of OpenBoot you are using. Table 3.4 lists some of the more common variables, their default values, and a brief description. These values are listed in alphabetical order and might not be listed in this exact order on your computer.

Table 3.4: NVRAM Configuration Variables
Variable	Default	Description
auto-boot?	true	If true, the system boots automatically after power on or reset.
boot-command	boot	Command to execute if auto-boot? is true.
boot-device	disk	Default device from which to boot.
boot-file	empty	Optional arguments for the boot program.
diag-device	net	Boot source device for diagnostic testing.
diag-file	empty	Optional arguments for the boot program in diagnostic mode.
diag-switch?	false	If set to true, the system boots into diagnostic mode.
error-reset-recovery	boot	Recovery action to take after an error reset CPU trap. Options are none, sync, or boot.
fcode-debug?	false	If true, include name fields for plug-in device FCodes.
input-device	keyboard	Console input device. Usually keyboard, ttya, or ttyb.
nvramrc	empty	Contents of NVRAMRC.
oem-banner	empty	If oem-banner? is true, the custom banner to use.
oem-banner?	false	If true, use a custom OEM banner.
oem-logo	empty	Byte array of the custom OEM banner, displayed in hexadecimal.
oem-logo?	false	If true, use the custom OEM logo instead of the Sun logo.
output-device	screen	Console output device. Usually screen, ttya, or ttyb.
screen-#columns	80	Number of characters per line on-screen.
screen-#rows	34	Number of on-screen rows or lines.
security-#badlogins	empty	Number of incorrect firmware security password attempts.
security-mode	none	Firmware security level. Options are none, command, or full.
security-password	empty	Firmware security password. Not displayed for obvious security reasons.
use-nvramrc?	false	If true, executes the command located in NVRAMRC during system boot.

As you can see in Table 3.4, quite a few parameters can be set in NVRAM. Some of them, such as the boot options, can be critical to system operation. Others, such as the OEM series of parameters, don't exactly affect critical system functions. However, by using oem-banner and oem-logo, you can create your own custom boot banner and logo to be displayed when the system is powered on. They might not be critical settings, but they can be fun.

With so many possible NVRAM parameters, you can't be expected to memorize them all. Besides, Solaris 9 can be installed on a variety of systems. Therefore, you won't have to know all options for OpenBoot 4.5 (or any other version) by heart. That being the case, it's still a good idea to know some of the more common options, for example, the boot series and the security series. You don't need to commit Table 3.4's contents to memory, but be able to recognize NVRAM configuration options when presented with them.

Tip

Configuration options that end in a ? always require true or false values. If the values are set to true, then another parameter needs to be configured as well.

NVRAM parameters are displayed with the printenv command and set by using the setenv command. The syntax of setenv is as follows:

 ok setenv variable value

To make your system halt at the Forth Monitor instead of booting to a Solaris login prompt, you could type this:

 ok setenv auto-boot? false

What if you've changed a variable, and for some reason it messes up your system? Or what if someone has changed a lot of variables (primitive hacking), trying to mess up your computer? Is there a way to fix problems like these? Yes. The set-default variable command will reset a specific variable to factory defaults. The set-defaults command resets all variables back to their default settings, as does pressing Stop+N (the Stop and N keys simultaneously) during boot.

Note

Solaris 9 provides the eeprom command for managing NVRAM variables from within the operating environment. The eeprom command offers the functionality of the OpenBoot printenv and setenv commands.

NVRAMRC

The NVRAMRC is a customizable configuration area of NVRAM. If you use NVRAMRC, its contents (called a script) will run during the boot process. The most common use of NVRAMRC is to store permanent device aliases, although other startup options (defining startup variables, patching device drivers) are possible.

Earlier in this chapter, you learned about device aliases. If you use the devalias command to set up an alias, the alias will be lost when the system loses power or is rebooted. Another command, nvalias, creates the alias and writes the necessary information to re-create the alias upon reboot into the NVRAMRC. If you use the nvalias command to create an alias, the use-nvramrc? variable is automatically set to true.

The syntax for creating an alias with nvalias is identical to devalias:

 ok nvalias alias devicepath

Aliases created with nvalias are essentially permanent. They can be deleted by using the nvunalias command. Just type nvunalias alias at the ok prompt to delete the alias.

To edit the NVRAMRC directly, you can use a script editor named nvedit. Using nvedit is beyond the scope of this book and beyond the scope of the Solaris 9 System Administrator exams.

Firmware Security

The OpenBoot firmware can be protected from would-be hackers through password security. The three NVRAM variables that control security are security-mode, security-password, and security-#badlogins. By default, security-mode is set to none, so security-password and security-#badlogins are not used either.

There are three options for the level of security: none, command, and full. With no security set, any user can access OpenBoot and make any changes they want. With command security enabled, the boot and go commands don't require a password, but all other commands do. If you enable full security, all commands except the go command require a password.

Note

When using command security, the boot command by itself does not require a password. However, the boot command with any arguments does need a password to execute.

The setenv command is used to configure the vast majority of NVRAM parameters. One exception is security-password. To set the security password, use the password command. Here's what setting your password will most likely look like:

 ok password ok New Password (only first 8 chars are used): ok Retype new password: ok

The password will not be displayed for security reasons.

Warning

Enable your security password before you set the security mode. Also, if you enable full security mode and forget your password, you will render your computer useless. To fix your machine, you will have to contact your vendor or Sun's technical support.