OpenBoot PROM

On the domain, OpenBoot PROM (OBP) is not a hardware PROM; it is loaded from a file on the SSP. An SSP file also replaces the traditional OBP NVRAM and idprom (hostid).

The OBP file is located under a directory path that is specific to the SunOS release. SunOS 5.6 corresponds to the Solaris 2.6 operating environment, SunOS 5.7 corresponds to the Solaris 7 operating environment, and SunOS 5.8 corresponds to the Solaris 8 operating environment. You can determine your SunOS version with uname -r. For example, under SunOS 5.7, the OBP file is located in the following directory:

/opt/SUNWssp/release/Ultra-Enterprise-10000/5/7/hostobjs/obp

where the /5/7 portion of the path corresponds to the SunOS version number. If your release contains a different version of the operating system, that portion of the path will be different.

The primary task of OBP is to boot and configure the operating system from either a mass storage device or from a network. OBP also provides extensive features for testing hardware and software interactively. As part of the boot procedure, OBP probes all the SBus slots on all the system boards and builds a device tree. This device tree is passed on to the operating system. The device tree is ultimately visible using the command prtconf (for more information, see the SunOS prtconf(1M) man page).

OBP also interprets and runs FCode on SBus cards, which provides loadable, simple drivers for accomplishing boot. In addition, it provides a kernel debugger, which is always loaded.

The following sections describe how the obp_helper daemon and download_helper file control the OBP.

obp_helper Daemon

obp_helper(1M) is responsible for starting processors other than the boot processor. It communicates with OBP through bootbus SRAM(BBSRAM), responding to requests to supply the time-of-day, get or put the contents of the pseudo-EEPROM, and release slave processors when in multiprocessor mode. To release the slave processors, obp_helper(1M) must load download_helper into the BBSRAM of all the slave processors, place an indication in BBSRAM that it is a slave processor, then start the processor by releasing the bootbus controller reset.

The bringup(1M) command starts obp_helper(1M) in the background, which kills the previous obp_helper(1M), if one exists. obp_helper(1M) runs download_helper and subsequently downloads and runs OBP.

For more information, see the obp_helper(1M), and bringup(1M) man pages and "download_helper File".

download_helper File

download_helper enables programs to be downloaded to the memory used by a domain instead of BBSRAM. This provides an environment in which host programs can run without having to know how to relocate themselves to memory. These programs can be larger than BBSRAM.

download_helper works by running a protocol through a mailbox in BBSRAM. The protocol has commands for allocating and mapping physical to virtual memory, and for moving data between a buffer in BBSRAM and virtual memory. When complete, the thread of execution is usually passed to the new program at an entry point provided by the SSP. After this occurs, download_helper lives on in BBSRAM so it can provide reset handling services. Normally, you do not need to be concerned with the download helper; it is used only by the obp_helper(1M) daemon. See the obp_helper(1M) man page for more information.