How to Perform System Boot and Shutdown Procedures for Solaris 10, Part A

Introduction

System startup requires an understanding of the hardware and the operating system functions that are required to bring the system to a running state. This chapter discusses the operations that the system must perform from the time you power on the system until you receive a system logon prompt. In addition, it covers the steps required to properly shut down a system. After reading this chapter, you’ll understand how to boot the system from the OpenBoot programmable read-only memory (PROM) and what operations must take place to start up the kernel and Unix system processes.

Booting a System

Bootstrapping is the process a computer follows to load and execute the bootable operating system. The term comes from the phrase "pulling yourself up by your bootstraps." The instructions for the bootstrap procedure are stored in the boot PROM.

The boot process goes through the following phases:

1. Boot PROM phase—After you turn on power to the system, the PROM displays system identification information and runs self-test diagnostics to verify the system's hardware and memory. It then loads the primary boot program, called bootblk from its location on the boot device into memory.
2. Boot programs phase—The bootblk program finds and executes the secondary boot program (called ufsboot) from the Unix file system (UFS) and loads it into memory. After the ufsboot program is loaded, the ufsboot program loads the two-part kernel.
3. Kernel initialization phase—The kernel initializes itself and begins loading modules, using ufsboot to read the files. When the kernel has loaded enough modules to mount the root file system, it unmaps the ufsboot program and continues, using its own resources.
4. init phase—The kernel creates a user process and starts the /sbin/init process. The /sbin/init process reads the /etc/inittab file for instructions on starting other processes, one of which is the svc.startd daemon (/lib/svc/bin/svc.startd).
5. svc.startd phase—The svc.startd daemon starts the system services and boots the system to the appropriate milestone. Specifically, svc.startd starts the following system services:
• Checks and mounts file systems
• Configures the network and devices
• Initiates various startup processes and performs system maintenance tasks
• In addition, svc.startd executes the legacy run control (rc) scripts for compatibility.

Powering On the System

Before you power on the system, you need to make sure everything is plugged in properly. Check the small computer system interface (SCSI) cables that connect any external devices to the system (such as disk drives and tape drives) to make sure they are properly connected. Check your network connection. Also make sure that the keyboard and monitor are connected properly. Loose cables can cause your system to fail during the startup process.

Connecting Cables with the Power Turned Off

Always connect your cables before turning on the hardware; otherwise, you could damage your system.

The correct sequence for powering on your equipment is to first turn on any peripherals (that is, external disk drives or tape drives) and then turn on power to the system.

The Boot PROM and Program Phases

The bootstrap process begins after power-up, when the startup routines located in the hardware’s PROM chip are executed. Sun calls this the OpenBoot firmware, and it is executed immediately after you turn on the system.

The primary task of the OpenBoot firmware is to test the hardware and to boot the operating system either from a mass storage device or from the network. OpenBoot contains a program called the monitor that controls the operation of the system before the kernel is available and before the operating system has been booted. When a system is turned on, the monitor runs a power-on self-test (POST) that checks such things as the hardware and memory on the system.

If no errors are found, the automatic boot process begins. OpenBoot contains a set of instructions that locate and start up the system’s boot program and eventually start up the Unix operating system.

Automatic System Recovery

Sun server class systems can recognize failed components and disable the board that contains the failed component. If the server is configured with multiple central processing unit (CPU)/memory and input/output (I/O) boards, the system can boot in a degraded yet stable condition, even with failed components. See your server’s System Reference Manual for details on automatic system recovery.

The boot program is stored in a predictable area (sectors 1–15) on the system hard drive, CD-ROM, or other bootable device and is referred to as the bootblock (bootblk). The bootblock is responsible for loading the secondary boot program (ufsboot) into memory, which is located in the UFS file system on the boot device. The path to ufsboot is recorded in the bootblock, which is installed by the Solaris installboot utility.

ufsboot locates and loads the two-part kernel. The kernel (which is covered in detail later in this chapter) is the part of the operating system that remains running at all times until the system is shut down. It is the core and the most important part of the operating system. The kernel consists of a two-piece static core called genunix and unix. genunix is the platform-independent generic kernel file, and unix is the platform-specific kernel file. When the system boots, ufsboot combines these two files into memory to form the running kernel.

The OpenBoot Environment

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 

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 basic input/output system (BIOS), the firmware interface on a PC. Therefore, many features provided by OpenBoot are not available on Intel systems.

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.

Alternative Methods for Stopping a System

An alternative 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 alternative sequence, you must first modify the /etc/default/kbd file by removing the # from the entry:

#KEYBOARD_ABORT=alternate

To disable the abort key sequence, make the following entry to the /etc/default/kbd file:

KEYBOARD_ABORT=disable

Remember to uncomment the line by removing the "#".

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

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. When you access the ok prompt from a running system, you are suspending the operating environment software and placing the system under firmware control. Any processes that were running under the operating environment software are also suspended, and the state of such software may not be recoverable.

The diagnostics and commands that you run from the ok prompt have the potential to affect the state of the system. Don’t assume that you will be able to resume execution of the operating environment software from the point at which it was suspended. Although the go command will resume execution in most circumstances, as a rule, each time you drop the system down to the ok prompt, you should expect to have to reboot it to get back to the normal operating state.

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:

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—power-on self test.
2. 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.
3. OpenBoot will check parameters stored in NVRAM to determine how to boot the operating system.
4. OpenBoot loads the primary startup program, bootblk, from the default startup device.
5. The bootblk program finds and executes the secondary startup program, ufsboot, and loads it into memory. The ufsboot program loads the operating system kernel.

The OpenBoot Architecture

The OpenBoot Device Tree

In this section, pay close attention to the OpenBoot device tree. You’re likely to see this topic on the exam.

The OpenBoot architecture provides an increase in functionality and portability compared to the proprietary systems of some other hardware vendors. Although this architecture was first implemented by Sun Microsystems as OpenBoot on SPARC (Scaleable Processor Architecture) systems, its design is processor independent. The following are some notable features of OpenBoot firmware:

• Plug-in device drivers—A device driver can be loaded from a plug-in device such as an SBus 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 software device drivers. This feature lets the input and output devices evolve without changing the system PROM.
• The FCode interpreter—Plug-in drivers are written in a machine-independent interpreted language called FCode. Each OpenBoot system PROM contains an FCode interpreter. This enables the same device and driver to be used on machines with different CPU instruction sets.
• The device tree—Devices called nodes are attached to a host computer through a hierarchy of interconnected buses on the device tree. A node representing the host computer’s main physical address bus forms the tree’s root node. Both the user and the operating system can determine the system’s hardware configuration by viewing 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 that is 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.

• The programmable user interface—The OpenBoot user interface is based on the programming language Forth, which provides an interactive programming environment. It can be quickly expanded and adapted to special needs and different hardware systems. Forth is used not only by Sun but also utilized in the OpenFirmware boot ROMs provided by IBM, Apple, and Hewlett-Packard.

Forth

If you’re interested in more information on Forth, refer to American National Standards Institute (ANSI) Standard X3.215-1994 (see http://www.ansi.org).

The OpenBoot Interface

The OpenBoot firmware provides a command-line interface for the user at the system console called the Forth Monitor.

The Forth Monitor is an interactive command interpreter that gives you access to an extensive set of functions for hardware and software diagnosis. Sometimes you’ll also see the Forth Monitor referred to as new command mode. These functions are available to anyone who has access to the system console.

The Forth Monitor prompt is ok. When you enter the Forth Monitor mode, the following line displays:

Type help for more information 

ok

Getting Help in OpenBoot

At any time, you can obtain help on the various Forth commands supported in OpenBoot by using the help command. The help commands from the ok prompt are listed in Table 3.2.

Table 3.2 OpenBoot help Commands

Command

Description

help

Displays instructions for using the help system and lists the available help categories.

help <category>

Shows help for all commands in the category. You use only the first word of the category description.

help <command>

Shows help for an individual command.

Because of the large number of commands, help is available only for commands that are used frequently.

The following example shows the help command with no arguments:

ok help

The system responds with the following:

Enter ‘help command-name’ or ‘help category-name’ for more help

(Use ONLY the first word of a category description) 

Examples: help system -or- help nvramrc

Categories:

boot (Load and execute a program)

nvramrc (Store user defined commands)

system configuration variables (NVRAM variables)

command line editing

editor (nvramrc editor)

resume execution

devaliases (Device Aliases)

diag (Diagnostic commands)

ioredirect (I/O redirection commands)

misc (Miscellaneous commands)

ok

If you want to see the help messages for all commands in the category diag, for example, you type the following:

ok help diag

The system responds with this:

test <device> Run the selftest method for specified device

test-all  Execute test for all devices with selftest method

watch-net  Monitor network connection

probe-scsi  Show attached SCSI devices

ok

ok help misc

The system responds with this:

reset-all  Reset system (similar to a power-cycle)

power-off  Power off system

sync   Reenter operating system to sync the disks

eject-floppy Eject floppy from drive

ok

ok help boot

The system responds with this:

boot [<device-specifier>:<device-arguments>] [boot-arguments]

Examples:

boot             Default boot (values specified in NVRAM variables)

boot disk1:h     Boot from disk1 partition h

boot myunix -as  Boot from default device. Pass boot program "myunix -as"

Booting from network

boot <network-device>:[dhcp,][server-ip],[boot-filename],[client-ip],

[router-ip],[boot-retries],[tftp-retries],[subnet-mask] [boot-arguments]

ok

PROM Device Tree (Full Device Pathnames)

• Identify the system’s boot device.

The Device Tree Versus Device Pathname

The terms device tree and device pathname are often interchanged, and you’ll see both used. They both mean the same thing.

OpenBoot deals directly with the hardware devices in the system. Each device has a unique name that represents both the type of device and the location of that device in the device tree. The OpenBoot firmware builds a device tree for all devices from information gathered at the POST. Sun uses the device tree to organize devices that are attached to the system. The device tree is loaded into memory, to be used by the kernel during boot to identify all configured devices. The paths built in the device tree by OpenBoot vary, depending on the type of system and its device configuration. The following example shows a full device pathname for an internal disk on a peripheral component interconnect (PCI) bus system such as an Ultra 5:

/pci@1f,0/pci@1,1/ide@3/disk@0,0

Typically, the OBP uses disk and cdrom for the boot disk and CD-ROM drive.

The following example shows the disk device on an Ultra system with a PCI-SCSI bus and a SCSI target address of 3:

/pci@1f,0/pci@1/scsi@1,1/sd@3,0

A device tree is a series of node names separated by slashes (/). The top of the device tree is the root device node. Following the root device node, and separated by a leading slash /, is a list of bus devices and controllers. Each device pathname has this form:

driver-name@unit-address:device-arguments

The components of the device pathname are described in Table 3.3.

Table 3.3 Device Pathname Parameters

Parameter

Description

driver-name

This is the root device node, which is a human-readable string that consists of 1 to 31 letters, digits, and the following punctuation characters:

 

, (comma)

 

. (period)

 

_ (underscore)

 

+ (plus sign)

 

- (minus sign)

 

Uppercase and lowercase characters are distinct from one another. In some cases, the driver name includes the name of the device's manufacturer and the device's model name, separated by a comma. Typically, the manufacturer's uppercase, publicly listed stock symbol is used as the manufacturer's name (for example, SUNW,hme0). For built-in devices, the manufacturer's name is usually omitted (for example, scsi or pci).

 

@ must precede the address parameter; it serves as a separator between the driver name and unit address.

unit-address

A text string that represents the physical address of the device in its parent's address space. The exact meaning of a particular address depends on the bus to which the device is attached. In this example,

 

/sbus@3,0/SUNW,fas@3,0/sd@0,0

 

sbus@3,0 represents the I/O board in slot 1, located on the back of the system, and SUNW,fas@3,0 is the onboard fast/wide SCSI controller of the same board.

 

The following are common device driver names:

 

fas—Fast/wide SCSI controller.

 

hme—Fast (10/100Mbps) Ethernet.

 

isp—Differential SCSI controllers and the SunSwift card.

 

ge—Sun Gigabit Ethernet.

 

eri—FastEthernet.

 

ce—Gigaswift Ethernet.

 

qfe—Quad FastEthernet.

 

dmfe—Davicom FastEthernet.

 

glm—UltraSCSI controllers.

 

scsi—SCSI devices.

 

sf—SCSI-compliant nexus driver that supports the Fibre Channel Protocol for SCSI on Private Fibre Channel Arbitrated Loops (FC-ALs).

 

soc—Serial optical controller (SOC) device driver.

 

socal—The Fibre Channel host bus adapter, which is an SBus card that implements two full-duplex Fibre Channel interfaces. Each Fibre Channel interface can connect to an FC-AL.

 

iprb—An Intel network interface found on x86/x64 based systems. The network interface driver will change depending on which one of many possible third party network interfaces you have installed on your x86/x64 platform. Others are dnet (Sohoware), elxl (3COM), spwr (SMC), and nei (Linksys).

 

sd@0,0 is the SCSI disk (sd) set to target id 0. (In this case, it is an internal disk because only internal disks should be controlled by the onboard SCSI controller of the I/O board in slot 1.)

device-arguments

A text string whose format depends on the particular device. device-arguments can be used to pass additional information to the device's software. In this example:

/pci@1f,0/pci@1,1/ide@3/atapicd@2,0:f

the argument for the disk device is f. The software driver for this device interprets its argument as a disk partition, so the device pathname refers to partition f on a CD-ROM.

You use the OpenBoot command show-devs to obtain information about the device tree and to display device pathnames. This command displays all the devices known to the system directly beneath a given device in the device hierarchy. show-devs used by itself shows the entire device tree. The syntax is as follows:

ok show-devs

The system outputs the entire device tree, as follows:

/SUNW,UltraSPARC-IIi@0,0

/pci@1f,0

/virtual-memory

/memory@0,10000000

/aliases

/options

/openprom

/chosen

/packages

/pci@1f,0/pci@1

/pci@1f,0/pci@1,1

/pci@1f,0/pci@1/scsi@1,1

/pci@1f,0/pci@1/scsi@1

/pci@1f,0/pci@1/scsi@1,1/tape

/pci@1f,0/pci@1/scsi@1,1/disk

/pci@1f,0/pci@1/scsi@1/tape

/pci@1f,0/pci@1/scsi@1/disk

/pci@1f,0/pci@1,1/ide@3

/pci@1f,0/pci@1,1/SUNW,m64B@2

/pci@1f,0/pci@1,1/network@1,1

/pci@1f,0/pci@1,1/ebus@1

/pci@1f,0/pci@1,1/ide@3/cdrom

/pci@1f,0/pci@1,1/ide@3/disk

/pci@1f,0/pci@1,1/ebus@1/SUNW,CS4231@14,200000

/pci@1f,0/pci@1,1/ebus@1/flashprom@10,0

/pci@1f,0/pci@1,1/ebus@1/eeprom@14,0

/pci@1f,0/pci@1,1/ebus@1/fdthree@14,3023f0

/pci@1f,0/pci@1,1/ebus@1/ecpp@14,3043bc

/pci@1f,0/pci@1,1/ebus@1/su@14,3062f8

/pci@1f,0/pci@1,1/ebus@1/su@14,3083f8

/pci@1f,0/pci@1,1/ebus@1/se@14,400000

/pci@1f,0/pci@1,1/ebus@1/SUNW,pll@14,504000

/pci@1f,0/pci@1,1/ebus@1/power@14,724000

/pci@1f,0/pci@1,1/ebus@1/auxio@14,726000

/openprom/client-services

/packages/ufs-file-system

/packages/sun-keyboard

/packages/SUNW,builtin-drivers

/packages/disk-label

/packages/obp-tftp

/packages/deblocker

/packages/terminal-emulator

ok 

Commands that are used to examine the device tree are listed in Table 3.4.

Table 3.4 Commands for Browsing the Device Tree

Command

Description

.properties

Displays the names and values of the current node’s properties.

dev <device-path>

Chooses the specified device node and makes it the current node.

dev <node-name>

Searches for a node with the specified name in the subtree below the current node and chooses the first such node found.

dev ..

Chooses the device node that is the parent of the current node.

dev /

Chooses the root machine node.

cd /

Same as dev /

device-end

Leaves the device tree.

<device-path> find-device

Chooses the specified device node, similar to dev.

ls

Displays the names of the current node’s children.

pwd

Displays the device pathname that names the current node.

see <wordname>

Decompiles the specified word.

show-devs <device-path>

Displays all the devices known to the system directly beneath a given device in the device hierarchy. show-devs used by itself shows the entire device tree.

show-disks

Displays only the disk devices currently connected to the system.

show-nets

Displays only the network interface devices currently connected to the system.

words

Displays the names of the current node’s methods.

<device-path>" select-dev

Selects the specified device and makes it the active node.

You can examine the device path from a Unix shell prompt by typing the following:

prtconf -p

The system displays the following information:

System Configuration: Sun Microsystems sun4u

Memory size: 128 Megabytes

System Peripherals (PROM Nodes):

Node 'SUNW,Ultra-5_10'

   Node 'packages'

      Node 'terminal-emulator'

      Node 'deblocker'

      Node 'obp-tftp'

      Node 'disk-label'

      Node 'SUNW,builtin-drivers'

      Node 'sun-keyboard'

      Node 'ufs-file-system'

   Node 'chosen'

   Node 'openprom'

        Node 'client-services'

   Node 'options'

   Node 'aliases'

   Node 'memory'

   Node 'virtual-memory'

   Node 'pci'

        Node 'pci'

               Node 'ebus'

            Node 'auxio'

            Node 'power'

               Node 'SUNW,pll'

               Node 'se'

            Node 'su'

               Node 'su'

               Node 'ecpp'

               Node 'fdthree'

               Node 'eeprom'

               Node 'flashprom'

               Node 'SUNW,CS4231'

        Node 'network'

        Node 'SUNW,m64B'

        Node 'ide'

               Node 'disk'

               Node 'cdrom'

   Node 'pci'

        Node 'scsi'

               Node 'disk'

               Node 'tape'

        Node 'scsi'

               Node 'disk'

               Node 'tape'

 Node 'SUNW,UltraSPARC-IIi'

OpenBoot Device Aliases

Objective: Create and remove custom device aliases.

Device pathnames can be long and complex. Device aliases, like Unix file system aliases, allow you to substitute a short name for a long name. An alias represents an entire device pathname, not a component of it. For example, the alias disk0 might represent the following device pathname:

/pci@1f,0/pci@1,1/ide@3/disk@0,0

OpenBoot provides the predefined device aliases listed in Table 3.5 for commonly used devices, so you rarely need to type a full device pathname. Be aware, however, that device aliases and pathnames can vary on each platform. The device aliases shown in Table 3.5 are from a Sun Ultra 5 system.

Table 3.5 Predefined Device Aliases

Alias

Device Pathname

disk

/pci@1f,0/pci@1,1/ide@3/disk@0,0

disk0

/pci@1f,0/pci@1,1/ide@3/disk@0,0

disk1

/pci@1f,0/pci@1,1/ide@3/disk@1,0

disk2

/pci@1f,0/pci@1,1/ide@3/disk@2,0

disk3

/pci@1f,0/pci@1,1/ide@3/disk@3,0

cdrom

/pci@1f,0/pci@1,1/ide@3/cdrom@2,0:f

net

/pci@1f,0/pci@1,1/network@1,1

If you add disk drives or change the target of the startup drive, you might need to modify these device aliases. Table 3.6 describes the devalias commands, which are used to examine, create, and change OpenBoot aliases.

Table 3.6 The devalias Commands

Command

Description

devalias

Displays all current device aliases

devalias_<alias>

Displays the device pathname that corresponds to alias

devalias_<alias> <device-path>

Defines an alias that represents device-path

Don’t Use Existing devalias Names

If an alias with the same name already exists, you’ll see two aliases defined: a devalias with the old value and a devalias with the new value. It gets confusing as to which devalias is the current devalias. Therefore, it is recommended that you do not reuse the name of an existing devalias, but choose a new name.

The following example creates a device alias named bootdisk, which represents an Integrated Drive Electronics (IDE) disk with a target ID of 3 on an Ultra 5 system:

devalias bootdisk /pci@1f,0/pci@1,1/ide@3/disk@3,0

To confirm the alias, you type devalias, as follows:

ok devalias

The system responds by printing all the aliases, like this:

bootdisk     /pci@1f,0/pci@1,1/ide@3/disk@3,0

screen       /pci@1f,0/pci@1,1/SUNW,m64B@2

net               /pci@1f,0/pci@1,1/network@1,1

cdrom        /pci@1f,0/pci@1,1/ide@3/cdrom@2,0:f

disk         /pci@1f,0/pci@1,1/ide@3/disk@0,0

disk3        /pci@1f,0/pci@1,1/ide@3/disk@3,0

disk2        /pci@1f,0/pci@1,1/ide@3/disk@2,0

disk1        /pci@1f,0/pci@1,1/ide@3/disk@1,0

disk0        /pci@1f,0/pci@1,1/ide@3/disk@0,0

ide               /pci@1f,0/pci@1,1/ide@3

floppy       /pci@1f,0/pci@1,1/ebus@1/fdthree

ttyb              /pci@1f,0/pci@1,1/ebus@1/se:b

ttya              /pci@1f,0/pci@1,1/ebus@1/se:a

keyboard!    /pci@1f,0/pci@1,1/ebus@1/su@14,3083f8:forcemode

keyboard     /pci@1f,0/pci@1,1/ebus@1/su@14,3083f8

mouse        /pci@1f,0/pci@1,1/ebus@1/su@14,3062f8

name         aliases

You can also view device aliases from a shell prompt by using the prtconf -vp command.

User-defined aliases are lost after a system reset or power cycle unless you create a permanent alias. If you want to create permanent aliases, you can either manually store the devalias command in a portion of NVRAM called NVRAMRC or you can use the nvalias and nvunalias commands. The following section describes how to configure permanent settings in the NVRAM on a Sun system.

OpenBoot NVRAM

• View and change NVRAM parameters from the shell.

System configuration variables are stored in system NVRAM. These OpenBoot variables determine the startup machine configuration and related communication characteristics. If you modify the values of the configuration variables, any changes you make remain in effect even after a power cycle. Configuration variables should be adjusted cautiously, however, because incorrect settings can prevent a system from booting.

Table 3.7 describes OpenBoot’s NVRAM configuration variables, their default values, and their functions.

Table 3.7 NVRAM Variables

Variable

Default

Description

auto-boot?

true

The system starts up automatically after power-on or reset if auto-boot? is true. If it is set to false, the system stops at the OpenBoot prompt (ok) after power-on or reset.

boot-command

boot

The command that is executed if auto-boot? is true.

boot-device

disk or net

The device from which to start up.

boot-file

Empty string

Arguments passed to the started program.

diag-device

net

The diagnostic startup source device.

diag-file

Empty string

Arguments passed to the startup program in diagnostic mode.

diag-switch?

false

Whether to run in diagnostic mode.

fcode-debug?

false

Whether name fields are included for plug-in device FCodes.

input-device

keyboard

A console input device (usually keyboard, ttya, or ttyb).

nvramrc

Empty

The contents of NVRAMRC.

oem-banner

Empty string

A custom original equipment manufacturer (OEM) banner (enabled with oem-banner? true).

oem-banner?

false

If true, use custom OEM banner.

oem-logo

No default

A byte array custom OEM logo (enabled with oem-logo? true). Displayed in hexadecimal.

oem-logo?

false

If true, use custom OEM logo; otherwise, use the Sun logo.

output-device

screen

A console output device (usually screen, ttya, or ttyb).

sbus-probe-list

0123

Which SBus slots to probe and in what order.

screen-#columns

80

The number of onscreen columns (characters/line).

screen-#rows

34

The number of onscreen rows (lines).

security-#badlogins

No default

The number of incorrect security password attempts.

security-mode

none

The firmware security level (options: none, command, or full).

security-password

No default

The firmware security password (which is never displayed).

use-nvramrc?

false

If true, execute commands in NVRAMRC during system startup.

OpenBoot Versions

Because older SPARC systems use older versions of OpenBoot, they might use different defaults or different configuration variables from those shown in Table 3.7. This text describes OpenBoot version 4.

You can view and change the NVRAM configuration variables by using the commands listed in Table 3.8.

Table 3.8 Commands for Viewing and Modifying Configuration Variables

Command

Description

password

Sets the security password.

printenv

Displays the current value and the default value for each variable. To show the current value of a named variable, you type the following:

 

printenv <parameter-name>

setenv <variable> <value>

Sets <variable> to the given decimal or text <value>. Changes are permanent, but they often take effect only after a reset.

set-default <variable>

Resets the value of a specified <variable> to the factory default.

set-defaults

Resets ALL OpenBoot variable values to the factory defaults.

The following examples illustrate the use of the commands described in Table 3.8. All commands are entered at the ok OpenBoot prompt.

You use the printenv command, with no argument, to display the current value and the default value for each variable:

ok printenv

The system responds with this:

Variable Name           Value                  Default Value

tpe-link-test?          true                   true

scsi-initiator-id  7                           7

keyboard-click?         false                  false

keymap

ttyb-rts-dtr-off    false                      false

ttyb-ignore-cd           true                  true

ttya-rts-dtr-off    false                      false

ttya-ignore-cd           true                  true

ttyb-mode                9600,8,n,1,-          9600,8,n,1,-

ttya-mode                9600,8,n,1,-          9600,8,n,1,-

pcia-probe-list          1,2,3,4                1,2,3,4

pcib-probe-list          1,2,3                 1,2,3

mfg-mode                 off                   off

diag-level               max                   max

#power-cycles            89

system-board-serial#

system-board-date

fcode-debug?      false                 false

output-device            screen                screen

input-device      keyboard              keyboard

load-base                16384                 16384

boot-command      boot                  boot

auto-boot?               false                 true

watchdog-reboot?    false              false

diag-file

diag-device              net               net

boot-file

boot-device      disk:a disk net    disk net

local-mac-address?  false                      false

ansi-terminal?           true                  true

screen-#columns          80                    80

screen-#rows      34                    34

silent-mode?      false                 false

use-nvramrc?      false                 false

nvramrc

security-mode            none

security-password

security-#badlogins 0

oem-logo

oem-logo?                false                 false

oem-banner

oem-banner?              false                 false

hardware-revision

last-hardware-update

diag-switch?        false                      false

The printenv Command

Depending on the version of OpenBoot that you have on your system, the printenv command might show slightly different results. This example uses a system running OpenBoot version 3.31.

To set the auto-boot? variable to false, you type the following:

ok setenv auto-boot? false

The system responds with this:

auto-boot? = false

You can verify the setting by typing the following:

ok printenv auto-boot?

The system responds with this:

auto-boot? =  false

To reset the variable to its default setting, you type the following:

ok set-default auto-boot?

The system does not respond with a message—only another OpenBoot prompt. You can verify the setting by typing the following:

ok printenv auto-boot?

The system responds with this:

auto-boot? =  true

To reset all variables to their default settings, you type the following:

ok set-defaults

The system responds with this:

Setting NVRAM parameters to default values.

It’s possible to set variables from the Unix command line by issuing the eeprom command. You must be logged in as root to issue this command, and although anyone can view a parameter, only root can change the value of a parameter. For example, to set the auto-boot? variable to true, you type the following at the Unix prompt (note the use of quotes to escape the ? from expansion by the shell):

eeprom ‘auto-boot?=true’

Any non-root user can view the OpenBoot configuration variables from a Unix prompt by typing the following:

/usr/sbin/eeprom

For example, to change the OpenBoot parameter security-password from the command line, you must be logged in as root and issue the following command:

example# eeprom security-password=

Changing PROM password:

New password:

Retype new password:

Setting the OpenBoot Security Mode

Setting the security mode and password can be dangerous: If you forget the password, the system is unable to boot. It is nearly impossible to break in without sending the CPU to Sun to have the PROM reset. OpenBoot security is discussed more in the section "OpenBoot Security," later in this chapter.

The security mode password you assign must be between zero and eight characters. Any characters after the eighth are ignored. You do not have to reset the system after you set a password; the security feature takes effect as soon as you type the command.

With no parameters, the eeprom command displays all the OpenBoot configuration settings, similar to the OpenBoot printenv command.

Use the prtconf command with the -vp options to view OpenBoot parameters from the shell prompt as follows:

prtconf -vp

The system responds with a great deal of output, but you'll see the following OpenBoot information embedded in the output:

. . . . <output truncated>

ansi-terminal?: 'true'

  screen-#columns: '80'

  screen-#rows: '34'

  silent-mode?: 'false'

  use-nvramrc?: 'false'

  nvramrc:

  security-mode: 'none'

  security-password:

  security-#badlogins: '0'

  oem-logo:

  oem-logo?: 'false'

  oem-banner:

  oem-banner?: 'false'

  hardware-revision:

  last-hardware-update:

  diag-switch?: 'false'

  name: 'options'

 Node 0xf002ce38

  screen: '/pci@1f,0/pci@1,1/SUNW,m64B@2'

  net: '/pci@1f,0/pci@1,1/network@1,1'

  cdrom: '/pci@1f,0/pci@1,1/ide@3/cdrom@2,0:f'

  disk: '/pci@1f,0/pci@1,1/ide@3/disk@0,0'

  disk3: '/pci@1f,0/pci@1,1/ide@3/disk@3,0'

  disk2: '/pci@1f,0/pci@1,1/ide@3/disk@2,0'

  disk1: '/pci@1f,0/pci@1,1/ide@3/disk@1,0'

  disk0: '/pci@1f,0/pci@1,1/ide@3/disk@0,0'

  ide: '/pci@1f,0/pci@1,1/ide@3'

. . . <output truncated>

Resetting NVRAM Variables

On non-USB style keyboards, not USB keyboards, if you change an NVRAM setting on a SPARC system and the system no longer starts up, you can reset the NVRAM variables to their default settings by holding down Stop+N while the machine is powering up. When you issue the Stop+N key sequence, you hold down Stop+N immediately after turning on the power to the SPARC system; you then keep these keys pressed for a few seconds or until you see the banner (if the display is available).

These are both good techniques for forcing a system’s NVRAM variables to a known condition.

You can use the NVRAM commands listed in Table 3.9 to modify device aliases so that they remain permanent, even after a restart.

Table 3.9 NVRAM Commands

Command

Description

nvalias <alias> <device-path>

Stores the command devalias <alias> <device-path> in NVRAMRC. (The alias persists until the nvunalias or set-defaults command is executed.) This command turns on use-nvramrc?.

nvunalias <alias>

Deletes the corresponding alias from NVRAMRC.

For example, to permanently create a device alias named bootdisk that represents a SCSI disk with a target ID of 3 on an Ultra 5 system, you type the following:

nvalias bootdisk /pci@1f,0/pci@1,1/ide@3/disk@3,0

Because disk device pathnames can be long and complex, the show-disks command is provided to assist you in creating device aliases. Type the show-disks command and a list of disk devices is shown as follows:

ok show-disks

a) /pci@1f,0/pci@1,1/ide@3/cdrom

b) /pci@1f,0/pci@1,1/ide@3/disk

c) /pci@1f,0/pci@1,1/ebus@1/fdthree@14,3023f0

q) NO SELECTION

Enter Selection, q to quit:

Type b to select an IDE disk and the system responds with the following message:

/pci@1f,0/pci@1,1/ide@3/disk has been selected.

Type ^Y ( Control-Y ) to insert it in the command line.

e.g. ok nvalias mydev ^Y for creating devalias mydev for

/pci@1f,0/pci@1,1/ide@3/disk

Now create a device alias named mydisk followed by ctrl+y as follows:

nvalias mydisk ^Y 

The system pastes the selected device path as follows:

ok nvalias mydisk /pci@1f,0/pci@1,1/ide@3/disk

Now all you need to do is add the target number and logical unit number (for example, sd@0,0 or disk@0,0) to the end of the device name as follows:

ok nvalias mydisk /pci@1f,0/pci@1,1/ide@3/disk@0,0

Specifying the Disk Slice

If the boot slice of the disk device that you wish to boot to is not slice 0, you will need to add the disk slice letter to the end of the device name as follows:

ok nvalias mydisk /pci@1f,0/pci@1,1/ide@3/disk@0,0:b

In the example, I used the letter "b," which corresponds to disk slice 1. This is one area where you’ll find disk slices identified by an alpha character and not a number. The letter "a" corresponds to slice 0, "b" is slice 1, etc. If no letter is specified, "a" for slice 0 is assumed. For example, /pci@1f,0/pci@1,1/ide@3/disk@0,0 is the same as specifying /pci@1f,0/pci@1,1/ide@3/disk@0,0:a.

To remove an alias, type nvunalias <aliasname>. For example, to remove the devalias named mydisk, type

ok nvunalias mydisk

The alias named mydisk will no longer be listed after the next OpenBoot reset.

The nvedit Line Editor

Optionally, you can use nvedit to create your device aliases. On systems with a PROM version of 1.x or 2.x, the nvalias command might not be available and you must use nvedit to create custom device aliases. nvedit is an OpenBoot line editor that edits the NVRAMRC directly, has a set of editing commands, and operates in a temporary buffer. The following is a sample nvedit session:

ok setenv use-nvramrc? true

Learning nvedit

This section is included for information purposes, to show an additional method for modifying the NVRAM. The nvedit line editor will not be covered on the certification exam.

The system responds with the following:

use-nvramrc? =  true

ok nvedit

 0: devalias bootdisk /pci@1f,0/pci@1,1/ide@3/disk@0,0

1: <Control-C>

ok nvstore

ok reset-all

 Resetting ......

ok boot bootdisk

The preceding example uses nvedit to create a permanent device alias named bootdisk. The example uses Ctrl+C to exit the editor. It also uses the nvstore command to make the change permanent in the NVRAMRC. Then, it issues the reset-all command to reset the system and then boots the system from bootdisk by using the boot bootdisk command.

Table 3.10 lists some of the basic commands you can use while in the nvedit line editor.

Table 3.10 nvedit Commands

Command

Meaning

Ctrl+A

Moves backward to beginning of the line.

Ctrl+B

Moves backward one character.

Esc+B

Moves backward one word.

Ctrl+C

Exits the script editor, returning to the OpenBoot command interpreter. The temporary buffer is preserved but is not written back to the script. You use nvstore afterward to write it back.

Ctrl+D

Erases the next character.

Esc+D

Erases from the cursor to the end of the word, storing the erased characters in a save buffer.

Ctrl+E

Moves forward to the end of the line.

Ctrl+F

Moves forward one character.

Esc+F

Moves forward one word.

Ctrl+H

Erases the previous character.

Esc+H

Erases from the beginning of the word to just before the cursor, storing erased characters in a save buffer.

Ctrl+K

Erases from the cursor position to the end of the line, storing the erased characters in a save buffer. If at the end of a line, it joins the next line to the current line (that is, deletes the new line).

Ctrl+L

Displays the entire contents of the editing buffer.

Ctrl+N

Moves to the next line of the script-editing buffer.

Ctrl+O

Inserts a new line at the cursor position and stays on the current line.

Ctrl+P

Moves to the previous line of the script-editing buffer.

Ctrl+Q

Quotes the next character (that is, allows you to insert control characters).

Ctrl+R

Retypes the line.

Ctrl+U

Erases the entire line, storing the erased characters in a save buffer.

Ctrl+W

Erases from the beginning of the word to just before the cursor, storing erased characters in a save buffer.

Ctrl+Y

Inserts the contents of the save buffer before the cursor.

Return (Enter)

Inserts a new line at the cursor position and advances to the next line.

Delete

Erases the previous character.

Backspace

Erases the previous character.

OpenBoot Security

Anyone who has access to a computer keyboard can access OpenBoot and modify parameters unless you set up the security variables. These variables are listed in Table 3.11.

Table 3.11 OpenBoot Security Variables

Variable

Description

security-mode

Restricts the set of operations that users are allowed to perform at the OpenBoot prompt.

security-password

Specifies the firmware security password. (It is never displayed.) You should not set this variable directly; you set it by using password.

security-#badlogins

Specifies the number of incorrect security password attempts.

Setting the OpenBoot Security Mode

It is important to remember your security password and to set it before setting the security mode. If you later forget this password, you cannot use your system; you must call your vendor’s customer support service to make your machine bootable again.

If you are able to get to a Unix prompt as root, you can use the eeprom command to either change the security-mode parameter to none or reset the security password.

To set the security password, you type the password at the ok prompt, as shown in the following:

New password (only first 8 chars are used): <enter password>

Retype new password: <enter password>

Earlier in this chapter you learned how to change the OpenBoot parameter security-password from the command line.

After you assign a password, you can set the security variables that best fit your environment.

You use security-mode to restrict the use of OpenBoot commands. When you assign one of the three values shown in Table 3.12, access to commands is protected by a password. The syntax for setting security-mode is as follows:

setenv security-mode <value>

Table 3.12 OpenBoot Security Values

Value

Description

full

Specifies that all OpenBoot commands except go require a password. This security mode is the most restrictive.

command

Specifies that all OpenBoot commands except boot and go require a password.

none

Specifies that no password is required. This is the default.

The following example sets the OpenBoot environment so that all commands except boot and go require a password:

setenv security-mode command

With security-mode set to command, a password is not required if you enter the boot command by itself or if you enter the go command. Any other command requires a password, including the boot command with an argument.

The following are examples of when a password might be required when security-mode is set to command:

Example

Description

ok boot

No password is required.

ok go

No password is required.

ok reset-all

You are prompted to enter a password.

Note that with Password, the password is not echoed as it is typed.

If you enter an incorrect security password, there is a delay of about 10 seconds before the next startup prompt appears. The number of times that an incorrect security password can be typed is stored in the security-#badlogins variable, but you should not change this variable.

OpenBoot Diagnostics

You can run various hardware diagnostics in OpenBoot to troubleshoot hardware and network problems. The diagnostic commands are listed in Table 3.13.

Table 3.13 OpenBoot Diagnostic Commands

Command

Description

.env

On servers, this command is used to obtain status information about the system’s power supplies, fans, and temperature sensors.

probe-scsi

Identifies devices attached to the internal SCSI bus.

probe-scsi-all

Identifies devices attached to any SCSI bus.

probe-ide

Identifies IDE devices attached to the PCI bus.

probe-fcal-all

Identifies devices on all fibre channel loops.

reset-all

Resets the entire system, similar to a power cycle.

test <device-specifier>

Executes the specified device’s self-test method. For example, test floppy tests the floppy drive (if installed), and test net tests the network connection.

test-all <device-specifier>

Tests all devices that have built-in self-test methods below the specified device tree node. If <device-specifier> is absent, all devices beginning from the root node are tested.

watch-clock

Tests the clock function.

watch-net

Monitors the network connection.

The following examples use some of the diagnostic features of OpenBoot.

To identify peripheral devices currently connected to the system, such as disks, tape drives, or CD-ROMs, you use OpenBoot probe commands. To identify the various probe commands and their syntax, you use the OpenBoot sifting command, as follows:

sifting probe

The system responds with this:

(f006c444) probe-all

(f006bf14) probe-pci-slot

(f006baa4) probe-scsi-all

(f0060de8) probe-pci

. . . <output has been truncated>

The OpenBoot sifting command, also called a sifting dump, searches OpenBoot commands to find every command name that contains the specified string.

This first example uses the OpenBoot probe command, probe-scsi, to identify all the SCSI devices attached to a particular SCSI bus:

ok probe-scsi

This command is useful for identifying SCSI target IDs that are already in use or to make sure that all devices are connected and identified by the system. The system responds with this:

Target 1

 Unit 0 Disk  IBM  DDRS34560SUN4.2GS98E

Target 3

 Unit 0 Disk  IBM  DDRS34560SUN4.2GS98E

OpenBoot probe Commands

The most common OpenBoot probe commands are probe-scsi and probe-scsi-all, which are used to obtain a free open SCSI target ID number before adding a tape unit, a CD-ROM drive, a disk drive, or any other SCSI peripheral. Only devices that are powered on will be located, so you need to make sure everything is turned on. You can use this command after installing a SCSI device to ensure that it has been connected properly and that the system can see it. You can also use this command if you suspect a faulty cable or connection. If you have more than one SCSI bus, you use the probe-scsi-all command, but only after a reset-all has been issued; otherwise the system is likely to lock up.

This example uses the probe-ide command to identify all IDE devices connected to the PCI bus:

ok probe-ide

 Device 0 ( Primary Master )

   ATA Model: ST34321A

 Device 1 ( Primary Slave )

   Not Present

 Device 2 ( Secondary Master )

   Removable ATAPI Model: CRD-8322B

 Device 3 ( Secondary Slave )

   Not Present

This example tests many of the system components, such as video, the network interface, and the floppy disk:

ok test all

To test the disk drive to determine whether it is functioning properly, you put a formatted, high-density disk into the drive and type the following:

ok test floppy

The system responds with this:

Testing floppy disk system. A formatted disk should be in the drive.

Test succeeded.

You type eject-floppy to remove the disk.

Table 3.14 describes other OpenBoot commands you can use to gather information about the system.

Table 3.14 System Information Commands

Command

Description

banner

Displays the power-on banner

show-sbus

Displays a list of installed and probed SBus devices

.enet-addr

Displays the current Ethernet address

.idprom

Displays ID PROM contents, formatted

.traps

Displays a list of SPARC trap types

.version

Displays the version and date of the startup PROM

.speed

Displays CPU and bus speeds

show-devs

Displays all installed and probed devices

The following example uses the banner command to display the CPU type, the installed RAM, the Ethernet address, the host ID, and the version and date of the startup PROM:

ok banner

The system responds with this:

Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz), No Keyboard

OpenBoot 3.31, 128 MB (60 ns) memory installed, Serial #10642306.

Ethernet address 8:0:20:a2:63:82, Host ID: 80a26382.

This example uses the .version command to display the OpenBoot version and the date of the startup PROM:

ok .version

The system responds with this:

Release 3.31 Version 0 created 2001/07/25 20:36

OBP 3.31.0 2001/07/25 20:36

POST 3.1.0 2000/06/27 13:56

Checking the OpenBoot Version from a Shell Prompt

You can display the OpenBoot version from a shell prompt by typing this:

/usr/sbin/prtdiag -v

The system displays the following system diagnostic information and the OpenBoot version is displayed at the end of the output:

System Configuration: Sun Microsystems sun4u Sun Ultra 5/10 UPA/PCI

 (UltraSPARC-IIi 270MHz)

System clock frequency: 90 MHz

Memory size: 128 Megabytes

========================= CPUs =========================

                         Run  Ecache   CPU   CPU

Brd CPU Module  MHz    MB    Impl.  Mask

--- --- ------- ----- ------ ------ ----

 0    0  0       270    0.2    12      1.3

========================= IO Cards =========================

    Bus# Freq

Brd Type MHz  Slot Name                                                 Model

--- ---- ---- ---- -------------------------------- ----------------------

 0  PCI-1 33    1  ebus

 0  PCI-1 33    1  network-SUNW,hme

 0  PCI-1 33    2  SUNW,m64B                                         ATY,GT-C

 0  PCI-1 33    3  ide-pci1095,646.1095.646.3

 0  PCI-2 33    1  pci-pci1011,25.4

No failures found in System

===========================

========================= HW Revisions =========================

ASIC Revisions:

---------------

Cheerio: ebus Rev 1

System PROM revisions:

----------------------

 OBP 3.31.0 2001/07/25 20:36 POST 3.1.0 2000/06/27 13:56

This example shows how to use the .enet-addr command to display the Ethernet address:

ok .enet-addr

The system responds with this:

8:0:20:1a:c7:e3

To display the CPU information, type the following:

.speed

The system responds with this:

CPU Speed : 270.00MHz

UPA Speed : 090.00MHz

PCI Bus A : 33MHz

PCI Bus B : 33MHz

Input and Output Control

The console is used as the primary means of communication between OpenBoot and the user. The console consists of an input device that is used for receiving information supplied by the user and an output device that is used for sending information to the user. Typically, the console is either the combination of a text/graphics display device and a keyboard, or an ASCII terminal connected to a serial port.

The configuration variables that are related to the control of the console are listed in Table 3.15.

Table 3.15 Console Configuration Variables

Variable

Description

input-device

Specifies the console input device (usually keyboard, ttya, or ttyb).

output-device

Specifies the console output device (usually screen, ttya, or ttyb).

screen-#columns

Specifies the number of onscreen columns. The default is 80 characters per line.

screen-#rows

Specifies the number of onscreen rows. The default is 34 lines.

You can use the variables in Table 3.15 to assign the console’s power-on defaults. These values do not take effect until after the next power cycle or system reset.

If you select keyboard for input-device and the device is not plugged in, input is accepted from the ttya port as a fallback device. If the system is powered on and the keyboard is not detected, the system looks to ttya—the serial port—for the system console and uses that port for all input and output.

You can define the communication parameters on the serial port by setting the configuration variables for that port. These variables are shown in Table 3.16.

Table 3.16 Port Configuration Variables

Variable

Default Value

ttyb-rts-dtr-off

false

ttyb-ignore-cd

true

ttya-rts-dtr-off

false

ttya-ignore-cd

true

ttyb-mode

9600,8,n,1,-

ttya-mode

9600,8,n,1,-

The value for each field of the ttya-mode variable is formatted as follows:

<baud-rate>,<data-bits>,<parity>,<stop-bits>,<handshake>

The values for these fields are shown in Table 3.17.

Table 3.17 Fields for the ttya-mode Variable

Field

Values

<baud-rate>

110, 300, 1200, 4800, 9600, 19200

<data-bits>

5, 6, 7, 8

<parity>

n (none), e (even), o (odd), m (mark), s (space)

<stop-bits>

1, 1.5, 2

<handshake>

- (none), h (hardware: rts/cts), s (software: xon/xoff)

OpenBoot PROM Versions

Before you can run Solaris 10, your version of OpenBoot must meet the minimum firmware level for your system.

Sun Ultra systems must have PROM version 3.25.xx or later to use the Dynamic Host Configuration Protocol (DHCP) network boot, and must be aware of milestones that are used by the Service Management Facility in Solaris 10 and described later in this chapter. For examples in this book, I’m using OpenBoot version 3.31.

On Sun Ultra systems, you can install an updated version of the PROM’s firmware to keep your PROM (and your version of OpenBoot) up-to-date. Updating your PROM is not covered on the exam, but if you would like more information on performing this procedure, visit http://sunsolve.sun.com and search the Sunsolve knowledgebase using the keywords flash prom.