- Introduction
- Booting a System
- The OpenBoot Environment
- The OpenBoot Architecture
- The OpenBoot Interface
- Getting Help in OpenBoot
- PROM Device Tree (Full Device Pathnames)
- OpenBoot NVRAM
- OpenBoot Security
- OpenBoot Diagnostics
- OpenBoot PROM Versions
- Booting a System
- The Kernel
- The init Phase
- System Shutdown
- Summary
- Suggested Readings and Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
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
or
prtconf -v
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 data—this 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. |
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 POST—power-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.