Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   


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
probe-scsi Identifies devices attached to a SCSI bus.
probe-ide Identifies IDE devices attached to the PCI bus.
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    SEAGATE ST1120N 833400093849
              Copyright  1992 Seagate
              All rights reserved 0000
Target 3
    Unit 0  Disk    MAXTOR LXT-213S SUN2074.20

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

NOTE

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.

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), Keyboard Present 
OpenBoot 3.15, 128 MB 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.15 Version 2 created 1998/11/10 10:35
OBP 3.15.2 1998/11/10 10:35
POST 2.3.1 1998/08/07 16:33

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

NOTE

Checking the OpenBoot Version from a Shell Prompt You can display the OpenBoot version from a shell prompt by typing this:

/usr/platform/´uname –m´/\sbin/prtdiag –v

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)


Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: February 28, 2008