Filter
Top Products
Chapter 6 Diagnostic Tools 85
Stage Two: OpenBoot Diagnostics Tests
Once POST diagnostics have finished running, POST reports back to the OpenBoot
firmware the status of each test it has run. Control then reverts back to the OpenBoot
firmware code.
OpenBoot firmware code compiles a hierarchical “census” of all devices in the
system. This census is called a device tree. Though different for every system
configuration, the device tree generally includes both built-in system components
and optional PCI bus devices.
Following the successful execution of POST diagnostics, the OpenBoot firmware
proceeds to run OpenBoot Diagnostics tests. Like the POST diagnostics, OpenBoot
Diagnostics code is firmware-based and resides in the Boot PROM.
What Are OpenBoot Diagnostics Tests For?
OpenBoot Diagnostics tests focus on system I/O and peripheral devices. Any device
in the device tree, regardless of manufacturer, that includes an IEEE 1275-compatible
self-test is included in the suite of OpenBoot Diagnostics tests. On a Sun Fire V490
server, OpenBoot Diagnostics test the following system components:
■ I/O interfaces; including USB and serial ports
■ System controller
■ Keyboard, mouse, and video (when present)
■ On-board boot devices (Ethernet, disk controller)
■ Any PCI option card with an IEEE 1275-compatible built-in self-test
By default, the OpenBoot Diagnostics tests run automatically via a script when you
start up the system. However, you can also run OpenBoot Diagnostics tests
manually, as explained in the next section.
Controlling OpenBoot Diagnostics Tests
When you restart the system, you can run OpenBoot Diagnostics tests either
interactively from a test menu, or by entering commands directly from the ok
prompt.
Most of the same OpenBoot configuration variables you use to control POST (see
TABLE 6-2) also affect OpenBoot Diagnostics tests. Notably, you can determine
OpenBoot Diagnostics testing level—or suppress testing entirely—by appropriately
setting the diag-level variable.