Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
This chapter is from the book

The OpenBoot Environment

  • Identify the system's boot PROM version.

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 socketed startup PROM. The OpenBoot PROM consists of two 8KB chips on the system board: the startup PROM itself, which contains extensive firmware that allows access to user-written startup drivers and extended diagnostics, and a nonvolatile random-access memory (NVRAM) chip.

The NVRAM chip has user-definable system parameters and writable 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. A single lithium battery backup provides backup for the NVRAM and clock. 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. Depending on the age of your system, you could have PROM version 1, 2, 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. Version 5 is available on the Sun Enterprise 3500, 4500, 5500, and 6500 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.

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 ROM basic input/output system (BIOS), the firmware interface on a PC.

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. The following are examples of systems that are capable of using only one system board:

  • SPARCstation 4, 5, 10, and 20

  • Sun Blade 100 and 1000

  • Ultra 1, 2, 5, 10, 30, 60, 80, 220, 250, 240, 420, and 450

  • Netra X1, T1, T1400, and T1405

  • Sun Fire V120, V480, and V880

Sun's midrange, midframe, and high-end servers can be configured with multiple CPU/memory and I/O boards. The following are examples of these systems:

  • Midrange—Enterprise 3000, 3500, 4000, 4500, 5000, 5500, 6000, and 6500

  • Midframe—Sun Fire 3800, 4800, 4810, and 6800

  • High-end—Enterprise 10000, Sun Fire 12000, and Sun Fire 15000

All other systems can be configured with multiple system boards and have special boot PROM and NVRAM arrangements. 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.

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.

  • When the system is initially powered on. If your system is not configured to start up automatically, it stops at the user interface. 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.)

NOTE

Alternate Methods for Stopping a System An alternate 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 alternate sequence, you must first modify the /etc/default/kbd file by removing the # from the entry:

#KEYBOARD_ABORT=alternate

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

OpenBoot Firmware Tasks

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 testing hardware and software.

  • Allow modification and management of system startup configuration, such as NVRAM parameters.

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

  1. 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 POST.

  2. OpenBoot loads the primary startup program, bootblk, from the default startup device.

  3. The bootblk program finds and executes the secondary startup program, ufsboot, and loads it into memory. The ufsboot program loads the operating system kernel.

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.

  • + Share This
  • 🔖 Save To Your Account