|C H A P T E R 1|
Test and initialize the system hardware
Determine the hardware configuration
Boot the operating system from either a mass storage device or from a network
Provide interactive debugging facilities for testing hardware and software
The OpenBoot architecture provides a significant increase in functionality and portability when compared to proprietary systems of the past. Although this architecture was first implemented by Sun Microsystems as OpenBoot on SPARC systems, its design is processor-independent.
A plug-in device driver is usually loaded from a plug-in device such as an SBus or a PCI card. The plug-in device driver can be used to boot the operating system from that device or to display text on the device before the operating system has activated its own drivers. This feature enables the input and output devices supported by a particular system to evolve without changing the system PROM.
Plug-in drivers are written in a machine-independent interpreted language called FCode . Each OpenBoot system PROM contains an FCode interpreter. Thus, the same device and driver can be used on systems with different CPU instruction sets.
The device tree is a data structure describing the devices (permanently installed and plug-in) attached to a system. Both the user and the operating system can determine the hardware configuration of the system by inspecting the device tree.
The OpenBoot user interface is based on the interactive programming language Forth . By combining sequences of commands to form complete programs, this provides a powerful capability for debugging hardware and software.
The user interface 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. Any level of user can use these functions.
If automatic booting is configured, you can make the system stop at the user interface by pressing the Stop-A keys from the keyboard after the display console banner is displayed but before the system starts booting the operating system.
See A Caution About Using Some OpenBoot Commands for information on using commands after entering OpenBoot from the operating system.
Devices are attached to a host computer through a hierarchy of interconnected buses. OpenBoot represents the interconnected buses and their attached devices as a tree of nodes, called the device tree . A node representing the host computer's main physical address bus forms the tree's root node.
Children, which are other device nodes "attached" to a given node and that lie directly below it in the device tree
Nodes with children usually represent buses and their associated controllers, if any. Each such node defines a physical address space that distinguishes the devices connected to the node from one another. Each child of that node is assigned a physical address in the parent's address space.
The physical address generally represents a physical characteristic unique to the device (such as the bus address or the slot number where the device is installed). The use of physical addresses to identify devices prevents device addresses from changing when other devices are installed or removed.
OpenBoot deals directly with hardware devices in the system. Each device has a unique name representing the type of device and where that device is located in the system addressing structure. The following example shows a full device path name:
A full device path name is a series of node names separated by slashes ( / ). The root of the tree is the machine node, which is not named explicitly but is indicated by a leading slash ( / ). Each node name has the form:
TABLE 1-1 describes each of these parameters.
A human-readable string consisting of one to 31 letters, digits and punctuation characters from the set " , . _ + - " that, ideally, has some mnemonic value. Uppercase and lowercase characters are distinct. In some cases, this name includes the name of the device's manufacturer and the device's model name, separated by a comma. Typically, the manufacturer's upper-case, publicly-listed stock symbol is used as the manufacturer's name (for example, SUNW,sd ). For built-in devices, the manufacturer's name is usually omitted (for example, sbus ).
In general, the unit-address part of a node name represents an address in the physical address space of its parent. The exact meaning of a particular address depends on the bus to which the device is attached. Consider this example:
1f,0 represents an address on the main system bus, because the SBus is directly attached to the main system bus in this example.
0,40000 is an SBus slot number (in this case, 0 ) and an offset (in this case, 40000 ), because the esp device is at offset 40000 on the card in SBus slot 0.
3,0 is a SCSI target and logical unit number, because the disk device is attached to a SCSI bus at target 3, logical unit 0.
When specifying a path name, either the @ unit-address or device-name part of a node name is optional, in which case the firmware tries to pick the device that best matches the given name. If there are several matching nodes, the firmware chooses one (but it may not be the one you want).
For example, using /sbus/esp@0,40000/sd@3,0 assumes that the system in question has exactly one SBus on the main system bus, making sbus as unambiguous an address as sbus@1f,0 . On the same system, however, /sbus/esp/sd@3,0 might or might not be ambiguous. Since SBus accepts plug-in cards, there could be more than one esp device on the same SBus bus. If there were more than one on the system, using esp alone would not specify which one, and the firmware might not choose the one you intended.
As another example, /sbus/@2,1/sd@3,0 would normally be unambiguous, while /sbus/scsi@2,1/@3,0 usually would not, since both a SCSI disk device driver and a SCSI tape device driver can use the SCSI target, logical unit address 3,0 .
Some implementations also enable you to omit path name components. So long as the omission does not create any ambiguity, those implementations select the device that you intended. For example, if our example system had only one
/sd:a would identify the same device as the much longer preceding expression.
TABLE 1-2 describes the devalias command, which is used to examine, create, and change aliases.
User-defined aliases are lost after a system reset or power cycle. If you want to create permanent aliases, you can either manually store the devalias command in a portion of non-volatile RAM (NVRAM) called nvramrc , or use the nvalias and nvunalias commands. (See Chapter 3 for further details.)
You can browse the device tree to examine individual device tree nodes. The device tree browsing commands are similar to the Solaris commands for changing, displaying and listing the current directory in the Solaris directory tree. Selecting a device node makes it the current node.
The user interface commands for browsing the device tree are shown in TABLE 1-3 .
Note Note - After choosing a device node with dev or find-device, you can't execute that node's methods because dev does not establish the current instance. For a detailed explanation of this issue, refer to Writing FCode 3.x Programs.
Whenever you see the ok prompt on the display, you can ask the system for help by typing one of the help commands shown in TABLE 1-4 .
help , without any specifier, displays instructions on how to use the help system and lists the available help categories. Because of the large number of commands, help is available only for commands that are used frequently.
OpenBoot might not operate correctly after the operating system has begun execution (for example, after Stop-A or halt). This occurs when the operating system can modify the system state in ways that are inconsistent with continued OpenBoot operation. In this case, you might have to power cycle the system to restore normal operation. Not all OpenBoot commands referenced in this document are available on all systems. The behavior of some of the commands may vary from one system to another.
For example, suppose you boot the operating system, exit to OpenBoot, then execute the probe-scsi command (described in Chapter 2). You may find that probe-scsi fails, and you may not be able to resume the operating system, or you may have to power cycle the systems.