The OpenBoot Environment

Objective:

Execute basic boot PROM commands for a SPARC system.

Explain boot PROM fundamentals, including OpenBoot Architecture Standard, boot PROM, NVRAM, POST, Abort Sequence, and displaying POST to serial port on SPARC systems.

The hardware-level user interface that you see before the operating system starts is called the OpenBoot PROM (OBP). OpenBoot is based on an interactive command interpreter that gives you access to an extensive set of functions for hardware and software development, fault isolation, and debugging. The OBP firmware is stored in the system's PROM chip.

Sun UltraSPARC systems use a programmable boot PROM that allows new boot program data to be loaded into the PROM by "flashing" the PROM with software. This type of PROM is called a flash PROM (FPROM).

The NVRAM chip stores user-definable system parameters, also referred to as NVRAM variables or EEPROM parameters. The parameters allow administrators to control variables such as the default boot device and boot command. The NVRAM also contains writeable areas for user-controlled diagnostics, macros, and device aliases. NVRAM is where the system identification information is stored, such as the host ID, Ethernet address, and time-of-day (TOD) clock. On older systems, a single lithium battery backup provides backup for the NVRAM and clock. Newer systems contain a non-removable Serial Electronically Erasable Programmable Read-Only Memory (SEEPROM) chip that does not require a battery. Other newer systems may contain a removable system configuration card to hold the system configuration information. Many software packages use the host ID for licensing purposes; therefore, it is important that the NVRAM chip can be removed and placed into any replacement system board. Because NVRAM contains unique identification information for the machine, Sun sometimes refers to it as the identification programmable read-only memory (ID PROM).

OpenBoot is currently at version 5 but is available only on high-end Sun servers (SunFire and higher). Depending on the age of your system, you could have PROM version 3, 4, or 5 installed. The original boot PROM firmware, version 1, was first introduced on the Sun SPARCstation 1. The first version of the OpenBoot PROM was version 2, and it first appeared on the SPARCstation 2 system. OpenBoot versions 3 and 4 are the versions that are currently available on the Ultra series systems and Enterprise servers. Versions 3, 4 and 5 of the OpenBoot architecture provide a significant increase in functionality over the boot PROMs in earlier Sun systems. One notable feature of the OpenBoot firmware is a programmable user interface based on the interactive programming language Forth. In Forth, sequences of user commands can be combined to form complete programs. This capability provides a powerful tool for debugging hardware and software. Another benefit of versions 3, 4, and 5 is the Flash update feature. You can update the version 3, 4, and 5 firmware without replacing the PROM chip, but you will not be tested on updating the firmware on the exam .

To determine the version of the OpenBoot PROM, type

/usr/bin/prtdiag -v

prtconf -v .

Note

No OpenBoot Environment on the Intel Platform The Intel environment has no OpenBoot PROM or NVRAM. On Intel systems, before the kernel is started, the system is controlled by the basic input/output system (BIOS), the firmware interface on a PC. Therefore, many features provided by OpenBoot are not available on Intel systems.

Entry-Level to High-End Systems

Every Sun workstation and server except the midrange, midframe, and high-end servers has only one system board and holds only one boot PROM and NVRAM chip.

Sun's midrange, midframe, and high-end servers, such as the Enterprise and Sun Fire, can be configured with multiple CPU/memory and I/O boards.

The following are some things you should be aware of on multiple-CPU systems:

A multiple-CPU system has a clock board to oversee the backplane communications.
The host ID and Ethernet address are on the clock board and are automatically downloaded to the NVRAM on all CPU boards when the POST is complete.
PROM contents on each CPU are compared and verified via checksums.
The CPU that is located in the lowermost card cage slot is the master CPU board.
Each CPU runs its own individual POST.
If these systems are configured with redundant CPU/memory and I/O boards, they can run in a degraded yet stable mode, even when some components have failed. Such systems are usually described as fault-tolerant or fault-resilient .

Accessing the OpenBoot Environment

You can get to the OpenBoot environment by using any of the following methods:

Halting the operating system.
Pressing the Stop and A keys simultaneously (Stop+A). On terminals that are connected to the serial port and do not have a Stop key, you press the Break key. This will stop the operating system and transfer control to the OpenBoot monitor. In some cases, this may lead to data loss or corruption, and therefore should be used with caution.
When the system is initially powered on. If your system is not configured to start up automatically, it stops at the user interface (the monitor prompt). If automatic startup is configured, you can make the system stop at the user interface by pressing Stop+A after the display console banner is displayed but before the system begins starting the operating system.
When the system hardware detects an error from which it cannot recover. (This is known as a watchdog reset .)

System Control Switch

On those servers with a power button and system control switch located on the system's front panel, the ability to turn the system on or off is controlled by the key position on the system control switch.

The four-position system control switch (key) located on the system's front panel controls the power-on modes of the system and prevents unauthorized users from powering off the system or reprogramming system firmware. Table 3.1 describes the function of each system control switch setting:

Table 3.1. Function of Each System Control Switch Setting
Position
Description
Normal
This key position allows the system Power button to power the system on or off. If the operating system is running, pressing and releasing the Power button initiates a graceful software system shutdown. Pressing and holding the Power button in for five seconds causes an immediate hardware power off. which could cause disk corruption and loss of datathis should be used only as last resort.
Locked
This key position disables the system Power button to prevent unauthorized users from powering the system on or off. It also disables the keyboard L1-A (Stop-A) command, terminal Break key command, and ~# tip window command, preventing users from suspending system operation to access the system ok prompt. The Locked setting, used for normal day-to-day operations, also prevents unauthorized programming of the system boot PROM.
Diagnostics
This key position forces the power-on self-test (POST) and OpenBoot Diagnostics software to run during system startup and system resets. The Power button functions the same as when the system control switch is in the Normal position.
Forced Off
This key position forces the system to power off immediately and to enter 5-volt standby mode. It also disables the system Power button. Use this setting when AC power is interrupted and you do not want the system to restart automatically when power is restored. With the system control switch in any other position, if the system were running prior to losing power, it restarts automatically once power is restored.

The Forced Off setting also prevents a Remote System Control (RSC) session from restarting the system. However, the RSC card continues to operate using the system's 5-volt standby power.

Note

Alternative Methods for Stopping a System An alternative sequence that can be used to stop the system is Enter+~+Ctrl+B, which is equivalent to Stop+A. There must be an interval of more than 0.5 seconds between characters, and the entire string must be entered in less than 5 seconds. You can use this method only with serial devices acting as consoles and not for systems with keyboards of their own. To enable this alternative sequence, you must first modify the /etc/default/kbd file by removing the # from the entry:

#KEYBOARD_ABORT=alternate

To disable the abort key sequence, make the following entry to the /etc/default/kbd file:

KEYBOARD_ABORT=disable

Remember to uncomment the line by removing the "#".

Then you save the changes and, as root, type

kbd -i

to put the changes into effect.

On a server with a physical keyswitch, the alternative BREAK does not work when the key is set to the Secure position.

If your console is connected to the serial port via a modem, you can send a break (Stop+A or L1+A) through the tip window by typing ~# (tilde and then the pound sign).

Caution

Using Stop+A Sparingly Forcing a system into the OpenBoot PROM by using Stop+A or Break abruptly breaks execution of the operating system. You should use these methods only as a last resort to restart the system. When you access the ok prompt from a running system, you are suspending the operating environment software and placing the system under firmware control. Any processes that were running under the operating environment software are also suspended, and the state of such software may not be recoverable.

The diagnostics and commands that you run from the ok prompt have the potential to affect the state of the system. Don't assume that you will be able to resume execution of the operating environment software from the point at which it was suspended. Although the go command will resume execution in most circumstances, as a rule, each time you drop the system down to the ok prompt, you should expect to have to reboot it to get back to the normal operating state.

OpenBoot Firmware Tasks

The IEEE Standard 1275 defines the OpenBoot architecture and the primary tasks of the OpenBoot firmware are as follows:

Test and initialize the system hardware.
Determine the hardware configuration.
Start the operating system from either a mass storage device or a network.
Provide interactive debugging facilities for configuring, testing, and debugging.
Allow modification and management of system startup configuration, such as NVRAM parameters.
Servers such as the Sun Fire provide environmental monitoring and control capabilities at both the operating system level and the OpenBoot firmware level to monitor the state of the system power supplies, fans, and temperature sensors. If it detects any voltage, current, fan speed, or temperature irregularities, the monitor generates a warning message to the system console and ultimately it will initiate an automatic system shutdown sequence.

Specifically, the following tasks are necessary to initialize the operating system kernel:

OpenBoot displays system identification information and then runs self-test diagnostics to verify the system's hardware and memory. These checks are known as a POSTpower-on self test.
OpenBoot will then probe system bus devices, interpret their drivers, build a device tree, and then install the console. After initializing the system, OpenBoot displays a banner on the console.
OpenBoot will check parameters stored in NVRAM to determine how to boot the operating system.
OpenBoot loads the primary startup program, bootblk, from the default startup device.
The bootblk program finds and executes the secondary startup program, ufsboot, and loads it into memory. The ufsboot program loads the operating system kernel.