C H A P T E R  6


This chapter describes the structure and function of initialization firmware. The Netra CP2140 board platform comprises a modular firmware architecture that enables the user to customize initialization and test firmware, even enabling the installation of a custom operating environment.

The SPARC firmware consists of two components: Common Operations and Reset Environment (CORE) and OpenBoot PROM. The CORE in its expanded form is Common Operations and Reset Environment. CORE handles the early initialization of the board before the SPARC control is transferred to OpenBoot PROM. It also provides a trap-based interface for the OpenBoot PROM and user firmware.

This platform also employs the System Management Controller (SMC). The SMC controls the CompactPCI interface, System Management and hot-swap control, and some board hardware. The SMC configuration is controlled by separate firmware.

6.1 Initialization Firmware

The control flow at board startup is shown in FIGURE 6-1. Execution begins in Firmware CORE, which includes Basic POST (BPOST). Then it passes to Comprehensive POST (CPOST) and Extended POST (EPOST), if these are present, before returning to Firmware CORE and on to OpenBoot PROM.

 FIGURE 6-1 Control Flow from Power On for Firmware CORE and Client Modules--Solaris Case

This diagram shows the control flow for firmware CORE and client modules from power on.

6.1.1 Firmware CORE and BPOST

Firmware CORE:

See Section 6.10, Firmware Diagnostics for detailed information.

BPOST is integrated into Firmware CORE. Its tests are interleaved with the initialization activities of Firmware CORE to present a foundation of validated and initialized hardware to run subsequent code such as that in CPOST or OpenBoot PROM. The tests listed in TABLE 6-1 are examples of CORE and BPOST flow of execution.

Note - Not all of the hardware listed in this table is present on this platform. If a hardware item is not detected by the firmware, the firmware makes no attempt to test or initialize it.

Because BPOST runs from PROM, the extent of testing is limited to that needed by modules that are loaded later. Such a module, for example CPOST, can perform comprehensive testing more quickly because it executes from DRAM.

TABLE 6-1 Firmware CORE and BPOST Flow of Execution

Firmware CORE Service


Initialize Processor

Set processor in stable state

Initialize NVRAM

Set up state variables

Initialize EBus and bridges

Initialize EBus and bridges in path between CPU and EBus devices

Initialize Super I/O, TTY

For keyboard/mouse, message display, floppy

Set memory timings


Verify NVRAM

Check magic number. Set defaults if invalid

Check keyboard

Probe and initialize keyboard, set TTYA otherwise

Check I/P device for key pressed

Set state variables in NVRAM accordingly

Cache, MMU test

Perform basic diagnostics on caches and MMUs[1]

Initialize caches, MMUs

Set up I and D caches and MMUs

Memory test

Perform partial memory test[2]

Memory probe

Probe memory and clear top memory region

MMU and cache setup

Set up I/D MMUs with valid mappings; enable MMUs and I/D caches

Copy Firmware CORE

Copy Firmware CORE into memory and transfer control to the RAM copy

Set up trap table

Set up trap table in memory

Initialize interrupts

Set up hardware interrupts

Probe flash PROMs

Probe for type and size of flash PROMs in the system

Initialize TOD


Set up CPU counter

Calibrate CPU counter to determine module speed

Probe PCI bus

Probe for Primary PCI system bus

Execute POST dropin|


Locate the client

Locate the client in PROM. If found, copy into memory and transfer control to it

Enter user interface

OpenBoot PROM for Solaris software, else RTOS or custom OS

6.1.2 CPOST and EPOST

CPOST contains tests for higher level board functions. By placing these tests in a separate module, the user has the option of performing them and the developer can substitute them with other tests. Examples of CPOST tests are:

  • PBM, IOMMU, APB, tests
  • PCI Tests
  • PCIO-2 Tests
  • SCSI controller tests
  • SMC diagnostic tests
  • Memory stress tests

EPOST is used for additional POST code dropins that are provided by the user.

6.1.3 OpenBootPROM

Note - Always upgrade board OpenBoot PROM before upgrading SMC (System Management Controller) firmware.

OpenBoot PROM exists in the form of a dropin in the System Flash memory area. OpenBoot PROM probes for devices and builds the device tree, a table that contains entries for how drivers communicate with connected hardware. Each line, or entry, of the device tree is a reference for the node entry for the peripheral in the /dev directory in the / directory. The device tree is inherited by Solaris software as it is booted.

To display the device tree, type show-devs at the ok prompt. An example of a device tree follows.

6.1.4 Example of a show-devs Device Tree


CODE EXAMPLE 6-1 show-devs Command Output
ok  show-devs

OpenBoot PROM also contains aliases for some of the devices shown in the device tree. These aliases can simplify hardware access at the ok prompt, for example:

ok boot disk1

The devalias command lists the device tree aliases. An example of the devalias command follows.

6.1.5 Example of devalias Command


CODE EXAMPLE 6-2 devalias Command Output
ok devalias
userprom2                /pci@1f,0/pci@1,1/ebus@1/flashprom@10,800000
userprom1                /pci@1f,0/pci@1,1/ebus@1/flashprom@10,400000
systemprom               /pci@1f,0/pci@1,1/ebus@1/flashprom@10,0
output-mux               /multiplexer:output
input-mux                /multiplexer:input
dload                    /pci@1f,0/pci@1,1/network@1,1:,
hsc                      /pci@1f,0/pci@1,1/ebus@3/sysmgmt@14,600000
pcic                     /pci@1f,0/pci@1/pci@1
pcib                     /pci@1f,0/pci@1,1
pcia                     /pci@1f,0/pci@1
ebus2                    /pci@1f,0/pci@1,1/ebus@3
ebus                     /pci@1f,0/pci@1,1/ebus@1
net2                     /pci@1f,0/pci@1,1/network@3,1
net                      /pci@1f,0/pci@1,1/network@1,1
floppy                   /pci@1f,0/pci@1,1/ebus@1/fdthree
diskx                    /pci@1f,0/pci@1,1/scsi@2,1/disk@0,0
cdromx                   /pci@1f,0/pci@1,1/scsi@2,1/disk@6,0:f
tapex                    /pci@1f,0/pci@1,1/scsi@2,1/tape@4,0
tapex1                   /pci@1f,0/pci@1,1/scsi@2,1/tape@5,0
tapex0                   /pci@1f,0/pci@1,1/scsi@2,1/tape@4,0
diskxf                   /pci@1f,0/pci@1,1/scsi@2,1/disk@f,0
diskxe                   /pci@1f,0/pci@1,1/scsi@2,1/disk@e,0
diskxd                   /pci@1f,0/pci@1,1/scsi@2,1/disk@d,0
diskxc                   /pci@1f,0/pci@1,1/scsi@2,1/disk@c,0
diskxb                   /pci@1f,0/pci@1,1/scsi@2,1/disk@b,0
diskxa                   /pci@1f,0/pci@1,1/scsi@2,1/disk@a,0
diskx9                   /pci@1f,0/pci@1,1/scsi@2,1/disk@9,0
diskx8                   /pci@1f,0/pci@1,1/scsi@2,1/disk@8,0
diskx7                   /pci@1f,0/pci@1,1/scsi@2,1/disk@7,0
diskx6                   /pci@1f,0/pci@1,1/scsi@2,1/disk@6,0
diskx5                   /pci@1f,0/pci@1,1/scsi@2,1/disk@5,0
diskx4                   /pci@1f,0/pci@1,1/scsi@2,1/disk@4,0
diskx3                   /pci@1f,0/pci@1,1/scsi@2,1/disk@3,0
diskx2                   /pci@1f,0/pci@1,1/scsi@2,1/disk@2,0
diskx1                   /pci@1f,0/pci@1,1/scsi@2,1/disk@1,0
diskx0                   /pci@1f,0/pci@1,1/scsi@2,1/disk@0,0
scsix                    /pci@1f,0/pci@1,1/scsi@2,1
disk                     /pci@1f,0/pci@1,1/scsi@2/disk@0,0
cdrom                    /pci@1f,0/pci@1,1/scsi@2/disk@6,0:f
tape                     /pci@1f,0/pci@1,1/scsi@2/tape@4,0
tape1                    /pci@1f,0/pci@1,1/scsi@2/tape@5,0
tape0                    /pci@1f,0/pci@1,1/scsi@2/tape@4,0
diskf                    /pci@1f,0/pci@1,1/scsi@2/disk@f,0
diske                    /pci@1f,0/pci@1,1/scsi@2/disk@e,0
diskd                    /pci@1f,0/pci@1,1/scsi@2/disk@d,0
diskc                    /pci@1f,0/pci@1,1/scsi@2/disk@c,0
diskb                    /pci@1f,0/pci@1,1/scsi@2/disk@b,0
diska                    /pci@1f,0/pci@1,1/scsi@2/disk@a,0
disk9                    /pci@1f,0/pci@1,1/scsi@2/disk@9,0
disk8                    /pci@1f,0/pci@1,1/scsi@2/disk@8,0
disk7                    /pci@1f,0/pci@1,1/scsi@2/disk@7,0
disk6                    /pci@1f,0/pci@1,1/scsi@2/disk@6,0
disk5                    /pci@1f,0/pci@1,1/scsi@2/disk@5,0
disk4                    /pci@1f,0/pci@1,1/scsi@2/disk@4,0
disk3                    /pci@1f,0/pci@1,1/scsi@2/disk@3,0
disk2                    /pci@1f,0/pci@1,1/scsi@2/disk@2,0
disk1                    /pci@1f,0/pci@1,1/scsi@2/disk@1,0
disk0                    /pci@1f,0/pci@1,1/scsi@2/disk@0,0
scsi                     /pci@1f,0/pci@1,1/scsi@2
ttyb                     /pci@1f,0/pci@1,1/ebus@1/su@14,3602f8
ttya                     /pci@1f,0/pci@1,1/ebus@1/su@14,3803f8

6.2 Firmware NVRAM Variables

This section provides some information on the CORE NVRAM variables and the NVRAM configuration variables.

6.2.1 Firmware CORE NVRAM Variables

At startup, Firmware CORE defines a set of variables in the NVRAM for controlling initialization and selecting the amount of testing required. These variables determine the following functions:

  • run-post: If true, POST is executed depending upon the value of post-level variable. If false, POST is skipped.
  • post-level: Defines the level of diagnostics to be executed
  • msg-verbosity: If run-post is nonzero, msg-verbosity defines the level of messages displayed on TTY interface
  • user-interface: CORE falls into the user-interface without invoking the client
  • kernel: Name of the client to be loaded and executed by Firmware CORE
  • trap-state: Defines the behavior of an error trap

6.2.2 Firmware CORE Execution Control

Use the key combinations listed in TABLE 6-2 to control the flow of execution at system boot. These key combinations must be pressed at power-on.

TABLE 6-2 Firmware Execution Control Key Sequences

Key combination





Enter CORE user interface


Set default NVRAM variables


Turn on power on messages

6.2.3 OpenBoot PROM Configuration Variables

The configuration variables are used by the OpenBoot PROM code and are stored in NVRAM. TABLE 6-3 shows a sample output when the printenv command is typed at the ok prompt. Use the setenv command to modify the environment variables. The boot process is controlled by several variables.

TABLE 6-3 NVRAM Configuration Variables

Variable Name


Default Value











ttya ttye

ttya ttye


ttya ttye

ttya ttye








































No default



No default



No default



















































































disk net

disk net



























No default


No default




No default


No default






No default






No default



No default








Note - All numbers are hex numbers.

The diag-switch and diag-level variables listed in TABLE 6-3 affect the path through the various embedded tests. TABLE 6-4 shows the effect of setting these variables.

BPOST is embedded within Firmware CORE and is executed when the OpenBoot PROM environment variable, diag-switch is set to true and diag- level set to min. Similarly CPOST (and EPOST if it is present) is executed when diag-level is set to max. The permutations are shown in TABLE 6-4.

TABLE 6-4 OpenBoot PROM Environment Variable Settings for Executing the POST Modules


diag-switch[3] set:

diag-level* set:





No messages are output to TTY


min (0x20)



off (0x0)

Messages are output to TTY




No messages are output to TTY


max (0x40)

Runs after BPOST


off (0x0)

Messages are output to TTY




No messages are output to TTY


max (0x40)

Runs automatically after CPOST (if EPOST module is present)


off (0x0)

Messages are output to TTY

6.3 Firmware Memory Map

The host board boots from the 1 Mbyte system flash PROM device, which contains the firmware CORE, Basic POST code, Comprehensive POST, and OpenBoot PROM. The contents map of this PROM is shown in FIGURE 6-2. User-developed code can also be programmed into the user flash memory space in the form of dropins. The system flash can be upgraded by running a program out of OpenBoot PROM--see OpenBoot PROM Flash Update. It is not otherwise accessible to the user.

 FIGURE 6-2 System Flash PROM Map

This is a diagram of a system flash PROM map.

6.4 Firmware CORE Features

TABLE 6-5 lists the firmware CORE commands that are run from the monitor.


TABLE 6-5 Firmware CORE Monitor Commands

Description of Task

CORE Monitor Command

To get this help


To allocate memory buffer

malloc <size>

To free memory buffer

free <addr>

To block copy memory

bcopy <src> <dest> <#bytes>

To dump memory

dump <addr> <#bytes> [asi]

To read an address

[safe-]peek <addr> <1|2|4|8> [asi]

To write to an address

poke <addr> <1|2|4|8> <data> [asi]

To update Flash PROM

flash-update <dev> <file-path>

To load a file

load <device> <file-path> <addr>

Jump to an address

go <addr>

Execute client

execute [client-name]

Print NVRAM data


Write to NVRAM variable

set-nvram <variable-name|ID> <data>

Read an NVRAM variable

get-nvram <variable-name|ID>

Delete an NVRAM variable

delete-nvram <ID>

Set NVRAM variables to default


Call a trap function

trap <trap#> <par0> ... <par5>

Soft Reset


To change input device

input-device <tty|kbd>

To initialize PCI


To show all pci devices


To show pci config space

show-pci-space <bus#> <device#> <function#> <offset>

To show pci nexus nodes


To remove a pci device

rm-pci-dev <device#>

To add a pci device

add-pci-dev <device#>

To remove all pci devices


To add all pci devices


To execute UI cmd in loop

loop <count> <command>

Note - All numbers are hex numbers.

6.5 ASM Support

ASM support is added at the OpenBoot PROM level. The ASM monitors the CPU temperature. The CPU warning, critical and shutdown temperature default limits are set at 60° C, 65° C and 70° C, respectively. For more information on ASM Warning, Critical and Shutdown temperature parameter settings, refer to the Netra CP2000 and CP2100 Series CompactPCI Boards Programming Guide for Solaris Operating Environment (816-0854-xx).

The following NVRAM variables are added in OpenBoot PROM for ASM:

1) NVRAM variable name: env-monitor?
Function  :enables or disables environment monitoring at OBP.
Data type  :string 
Valid values  :disabled or enable
Default value  :disable
OBP Usage  :OK setenv env-monitor? enable
2) NVRAM variable name  :warning-temperature
Function  :sets the cpu warning temperature threshold
Data type  :byte
Unit  :Decimal
Default value  :60
OBP Usage  :ok setenv warning-temperature <temperature-value>
3) NVRAM variable name  :shutdown-temperature
Function  :sets the cpu shutdown temperature threshold
Data type  :byte
Unit  :Decimal
Default value  :70
OBP Usage  :ok setenv shutdown-temperature <temperature-value>
CAUTION: User should exercise caution while setting the above two parameters.
Setting these values too high leaves the system un-protected against system
WARNING: Temperature response at OBP When cpu temperature reaches
"warning-temperature", the following message is spit out at ok prompt
at a regular interval:
Temperature sensor #2 has threshold event of
<<< WARNING!!! Crossing Warning temperature threshold >>>
The current threshold setting is: 18
The current temperature is      : 28
Critical Temperature response at OBP
Sensor in IPMB Addr 20 has event === 
  Temperature sensor #2 has threshold event of 
   <<< !!! ALERT!!! Crossing Critical temperature threshold >>> 
  The current threshold setting is: 20  degreeC
  The current temperature is      : 28  degreeC
Shutdown Temperature response at OBP
When cpu temperature reaches "warning-temperature", the following message is displayed at ok prompt at a regular interval,
Temperature sensor #2 has threshold event of
<<< !!! ALERT!!! Upper Critical - going high >>>
The current threshold setting is: 65
The current temperature is      : 66
show-sensor command at OBP
The "show-sensor" command at OBP displays the readings of all the temperature sensors on the board.

6.6 Determining Firmware Version

If the installed version is not current, update the OpenBoot PROM before continuing. The third character group (X) in OpenBoot PROM is the revision number.

6.6.1 From OpenBoot PROM

To determine the installed OpenBoot PROM version, type the .version command at the ok prompt. For an example, the firmware version in the output below is the OpenBoot PROM version:

6.6.2 If Running Solaris Software

Type the prtconf command at the machine_name prompt:

6.7 OpenBoot PROM Flash Update

To update the binary image for both system flash and user flash, OpenBoot PROM is always stored in system flash. User flashes are provided for you to store your own application code or a backup copy of OpenBoot PROM.

Note - The Netra CP2140 board does not support booting the Solaris operating environment from a user flash EPROM device. Accessing SMC Config Block

Use SMC Config block to select booting mode, either from system flash or from user flash.

The following example shows how to select OpenBoot PROM booting mode using the setting in the SMC config block:

ok printsmcenv
config-version      : 3 
backplane-type      : 1 
reset-mode          : 11 
sir-xir-enable      : 2 
byte5               : 0 
chassis-type        : 0 
flash-device        : 8  (userflash mode ) 
byte8               : 0 
ha-signal-handler   : 0 
poweron-vector      : 0 
ipmi-checksum-ctlr  : 0 
byteC               : 0 
byteD               : 0 
byteE               : 0 
byteF               : 0 
byte10              : 0 
ok setsmcenv flash-device h# c
ok printsmcenv
config-version      : 3 
backplane-type      : 1 
reset-mode          : 11 
sir-xir-enable      : 2 
byte5               : 0 
chassis-type        : 0 
flash-device        : c  (userflash mode c is equivalent
                          to sysflash mode) 
byte8               : 0 
ha-signal-handler   : 0 
poweron-vector      : 0 
ipmi-checksum-ctlr  : 0 
byteC               : 0 
byteD               : 0 
byteE               : 0 
byteF               : 0 
byte10              : 0 
ok Using Flash Update Commands

The command format is flash-update file-path flashtype.

ok flash-update file-path systemprom    <---- to update system flash
ok flash-update file-path userprom1     <---- to update user flash1
ok flash-update file-path userprom2     <---- to update user flash2

In the absence of flashtype, the OpenBoot PROM updates OpenBoot PROM in whatever flash has the address:


For example, in sysflash mode, the system flash is updated. In the user flash mode, the user flash #1 is updated.

If a combined SPARC and SMC binary file is provided to the flash-update command then it updates SMC as well as the SPARC firmware. Use the regular flash-update command to update the combined binary and follow the syntax of the flash-update command with the full file path of the combined binary. Field CORE/OpenBoot PROM Firmware Upgrade

This firmware can only be upgraded when operating at the OpenBoot PROM level, that is, at the ok prompt. The following procedure gives the steps to update firmware on the target system.

1. Download the latest Netra CP2140 board host firmware binaries.

Download the latest CP2140 host firmware (OpenBoot PROM) and SMC firmware to your server. Contact your Field Application Engineer for help on how to download it.

2. Bring the system down to OpenBoot PROM level.

If your Netra CP2140 host is currently running Solaris software, become superuser and type the following command to halt the system:

$ shutdown -i0 -g0 -y


$ init 0

3. Check the firmware revision.

Check the current firmware revision on the target system by typing:

ok .version

See Section 6.6.1, From OpenBoot PROM for an example of the output of this command.

The Platform ID identifies the board ID. For example, if ID = 10 indicates the CP2140.

For each release, there must be compatible revision numbers for other components. To get the correct combination, refer to the latest release notes.

4. Disable autoboot; then reset.

Disable autoboot and reset the system using the following commands:

ok setenv auto-boot? false
ok reset-all

The system is now reset.

5. Flash update your firmware.

ok flash-update obp-file-path/obp-latest-binary
ok smc-flash-update smc-file-path/smc-latest-binary 
If you have the combined SPARC and SMC binary file then use the following command:
ok flash-update obp-smc-file-path/obp-smc-combined-latest-binary

The system should automatically reset. If it does not, power cycle it.

6. Check the firmware revision.

Check the firmware revision by typing:

ok .version

The output appears as in the example in Step 3. Ensure that the version information shows up as expected. If not, repeat Step 1 through Step 6.

7. Enable autobooting and reset the system.

Enable autobooting by typing:

ok setenv auto-boot? true

and reset the system to boot the Solaris software:

ok reset-all

Contact your service personnel if you have any problems.

Note - Solaris scripts are also available to upgrade core OpenBoot PROM firmware. Sequence to Boot Up the Correct OpenBoot PROM Image

The following sequence enables you to boot up the correct OpenBoot PROM image.

1. You are logged in UserFlash Mode 8 with OpenBoot PROM image from User Flash #1, which has the following setup in SMC config block:

ok printsmcenv
config-version      : 3 
backplane-type      : 1 
reset-mode          : 11 
sir-xir-enable      : 2 
byte5               : 0 
chassis-type        : 0 
flash-device        : 8  
byte8               : 0 
ha-signal-handler   : 0 
poweron-vector      : 0 
ipmi-checksum-ctlr  : 0 
byteC               : 0 
byteD               : 0 
byteE               : 0 
byteF               : 0 
byte10              : 0 

2. Flash updates new OpenBoot PROM to system flash:

ok flash-update file-path systemprom

3. Change to system flash to boot up if you want to boot from it:

ok setsmcenv flash-device c

4. Power cycle the CP2140 system.

The new OpenBoot PROM boots up from the system flash.

6.7.1 SMC Firmware Update

SMC firmware is updated only from the OpenBoot PROM level. Follow these steps to update the SMC firmware:

1. Check with your Field Application Engineer.

2. Type the following command:

smc-flash-update filename

Note - The filename must be a valid binary or else the file cannot be read to complete the flash update.

3. If a power failure occurs, or an error message displays, or you notice that the second binary is an F, then the flash update has failed.

The following example shows the binary breakdown:

First binary

Secondary binary

Third binary

SMCFw version = xx

Revision = 0xF

Build = xx

4. You must now perform a code recovery of the SMC flash update in order for the code to work.

6.7.2 IPMI Packet

This section describes how to send and receive packets from one board to another board using the IPMI protocol. First, you must know how to set the IPMB address of each board.

The following steps show you how to calculate the Geographical Address bits:

1. Read Geographical Address bits.

To get the Geographical Address (GA) bits, type the following command:

2. If (GA != 0) then:

if (GA <= 9) then

ipmb_addr = 0xB0 + (GA - 1) * 2

else if (GA <= 30)

ipmb_addr = 0xC4 + (GA - 10) * 2


ipmb_addr = 0


ipmb_addr = 0

3. For SBC, IPMB address is always 0x20.

Note - Upon power up, the SMC sets up the IPMB address of the board automatically, but you need to provide the sender's and receiver's IPMB addresses properly within the IPMI packet in order to get the communication to work.

Before sending the IPMI packet to the other board, you must set a bit in the global enable register inside SMC.

Note - All examples shown in this section are performed at the CORE level.

To do this, send cmd 0x2F to the SMC (get_smc_global_enable).

It returns three bytes of data: The first byte is completion code, the other 2 bytes are global enable bits.

After you get the data, send the following packet to the SMC:
command 0x2E (set_smc_global_enables):

All values are in hex:

07 : Byte count
XX : Checksum
XX : Sequence number
18 : NetFN/LUN
2e : set_smc_global_enables 
YY : Put back the first byte that you read earlier.
ZZ : Put back the 2nd byte that you read earlier, but modify bit 4 to 0.

Now you can send the IPMI packet through the send_message command. You must append this IPMI packet to the EBus packet header, plus the channel number, where 0 is IPMI channel, 1 is the interhost channel.

Here is the format:

LL: Byte count
CS: Checksum
SN: Sequence number
18: NetFN/LUN
34: send_message command


00: Channel number, IPMI channel is 0, Interhost is 1.

Append the following IPMI packet to the header:

RA: Responder address, in this case this is the destination IPMB address.
NF: IPMI net function for the command that you want to send.

This MUST be shifted left by 2 bits, and ORed it with LUN, in this case we set it to 1.

CS: Checksum for the IPMI packet.
QA: Requester address. This is the IPMB address of the requester.
SN: Sequence number
CM: IPMI command

Here is the diagram:

After this command is sent to the SMC, you will receive a response packet from the SMC.

Note - This is not the IPMI response packet; this is the SMC response packet indicating that it received the command.

If the packet is received, the SMC responds with:

06: Byte count.
CS: Checksum.
SN: Sequence number
1C: Response NetFN number
34: send_message command.
00: OK. 

After you retrieve that packet, you can send command 0x33 (get_message) in the following format

05: Byte count.
CS: Checksum.
SN: Sequence number
18: NetFN/LUN
33: get_message command

If the packet is received, the other board which is appended to the EBus packet header, responds with:

LL: Byte count
CS: Checksum
SN: Sequence number
1C: Response NetFN number
33: get message command
00: OK. 

The IPMI response packet is appended to the packet header listed above. Source and destination IPMB addresses are exchanged in the response packet.

Note - In order to get the response packet from the other board properly with the get_message command, the sequence number expected must match the sequence number sent.

Here is an example of the get_device_id command:

The packet looks like:

Send packet to read global enable bits
5 0 0 18 2f

You get the following response packet from the SMC:

8 0 0 1c 2f 0 0 14
Send packet to set global enable bits:
7 0 0 18 2e 0 4

Now you can send the IPMI packet to the other board so that it can read its device ID.

c 0 22 18 34 0 b6 19 0 20 22 1 bd

The sequence number in this case is set to 22 (this number is picked arbitrarily).

Net function for get_device_id command is 6, and we shift it 2 bits to the left, and ORed it with logical unit number 1. Therefore it becomes 19. The b6 is the address of the board from which the device ID is requested.

Since this packet is being sent from the SBC, 20 is put as the requester IPMB address and 1 is the get_device_id command for Netfunction 6 (Application).

If everything goes well, SMC sends the following response packet first:

6 0 22 1c 34 0 

You can read the device ID packet of the other board, by issuing a get_message command, the packet looks like this:

5 0 22 18 33

If the data is not available, the following response packet is received from the SMC:

6 0 22 1c 33 80

Completion code 80 indicates that data is not available.

Otherwise, you will get the following response packet from the SMC:

1d 0 22 1c 33 0 ......

followed by the IPMI response packet from the other board, with the requester and responder addresses swapped from the original IPMI packet header.

TABLE 6-6 shows an example of a chassis configuration.


TABLE 6-6 Chassis Configuration Example










Geographical Address









IPMB Address









Note - On the first slot, the SBC is assigned an IPMB address of 0x20, not 0xB0. If the second slot becomes SBC, then the IPMB address becomes 0x20, not 0xB2.

To send an IPMI packet to other boards, make sure that you include the correct checksum data in the IPMI packet.

TABLE 6-7 shows what an IPMI packet looks like.

TABLE 6-7 IPMI Packet








Check 1




reSeq / rqLUN









NN - 1



Check 2

Check 1: This is the 2's complement check sum of rsSA and netFn.Check 2: This is the 2's complement check sum of data starting from rqSA all the way to NN - 1 data.

To calculate the checksum, add all the data involved for that particular checksum entry, then use this formula:

checksum = - checksum

The checksum arithmetic that is done is module 256 since only one byte is allocated for each checksum. By performing this calculation, once all the data entries for the checksum have been added and the result is added to that checksum, you get a result of 0.

The examples below show how to send a packet at the OpenBoot PROM interface at the ok prompt. At the OpenBoot PROM level, you do not have to include all EBus packet header data, making the process simple.

Type the following commands at the ok prompt as shown below:

ok dev hsc
ok showstack
ok words

The showstack command enables you to see the value of the returned data. The words command lists all the commands that are supported.

Now you are ready to send the packets.

The generic format is as follows:

ok ipmi_packet CH BC 34 execute-smc-cmd

Reviewers: Is ipmi_packet CH BC supposed to be variables and 34 execute-smc-cmd the literal command?

Where the ipmi_packet is the data in the IPMI packet, CH is the channel number and BC is the byte count.

Note - The IPMI packet data is entered backwards at the ok prompt.

In this example, the get_device_id_command is used. B6 is the destination address or the responder, and 20 is the source address, or the requester. The command for get_device_id is 1 and the NetFn data field in this case is 19 (after it has been adjusted/shifted 2 bits to the left and ORed with 1). The sequence number is set to 22 in this case.

The IMPI packet looks like this:

b6 19 0 20 22 1 > byte count = 6

The channel number is 0 indicating that this is an IPMI channel.

The total byte count is 6 + 1 (the channel number) = 7.

Type the command as follows:

ok 1 22 20 0 19 b6 0 7 34 execute-smc-cmd

if everything works as planned, you get the following message:

0 ok

At this point, you can issue a clear command to clear the stack.

You see the following message:

0 ok clear

Now you are ready to issue command 33 to retrieve the response packet from the other board.

Type the following command:

ok 0 33 execute-smc-cmd

If everything works as planned, you receive the following message:


You also receive the EBus response data appended to the ipmi_response_packet. In this case, it is 0.

6.8 Host-to-Host Communication

An event is a packet of information in a fixed format which is sent by the SMC on one board to another board through IPMI. The events are usually generated by the SMC and they go to another board's SMC, which sends it to the local SPARC.

But the event can also be generated by the SPARC wherein it sends the event packet to its SMC which sends the packet to another board. FIGURE 6-3 shows the host-to-host communication.

 FIGURE 6-3 Host-to-Host Communication

This is a diagram of the host-to-host communication between boards.

6.8.1 Packet

There is a fixed packet for any event to be sent. That packet is as follows:

evm_rev         // Revision number
event_type_dir  // dir => assertion/deasserion event..

The packet formation depends on the sensor class and value. For example, if there is a temperature sensor, where the monitor task detects the temperature value higher than the threshold value, the packet might look like the following:

evm_rev = 0x03;  // for current specs it is 0x03
sensor_type = TEMPERATURE_SENSOR;  // sensor 0x01,Table 30.3
sensor_number = 0xe;  // Sensor # assigned to a sensor.
event_type_dir = 0x01;  // implies Threshold based sensor,Table 30.1
event_data1 = 0x59;  // Implies that in event_data2 we have
// current temp value and in event_data3 we
// have threhold value which triggered the
// event. see table 17.5 IPMI specs
event_data2 = temp_sensor_ds1721.temp;  // current temp value.
event_data3 = temp_sensor_ds1721.high_temp;  // threshold value.

Thus, the values specified in the variables change depending upon the event type.

For detailed explanation of these variables, refer to IPMI Intelligent Platform Management Interface Specification (A00328-xxx).

6.8.2 Event Receiver

All events are sent to the current event receiver. An event receiver is the address of the board which is bound to receive the events. By default, the event receiver is the BMC address 20 for all the SAT boards. However, any board can set itself or any other board as event receiver for other boards.

For example, a board at address 0xb6 can send IPMI command set_event_receiver to a board at address 0xba asking it to set address 0xb2 as its event receiver, so that now all the events from satellite at address 0xba goes to address b2. Similarly, the board at address 0xb6 could have asked 0xba to set 0xb6 itself as event receiver (which usually is the case).

The SMC sends the event to the currently set event receiver, without verifying whether that address is set correctly or not.

6.8.3 Protocol

The event generation follows a particular protocol as described in the following test. As soon as an event condition is detected, the SMC creates the packet to be sent and sends an event packet to the event receiver. It then waits for the response from the event receiver to come until it times out. If the response does not come within that time, it sends the event packet again, with a different sequence number and again waits for the time out. This continues until retry count is exhausted.

During all this time, the state system is held in a state which indicates that the event is transmitted and no response has been received. So, if during this period, another event condition is generated, the event shall not be sent until the response to previously sent event has timed out.

The state changes to normal idle state if either it times out or a response to the event is received.

Refer to the IPMI Intelligent Platform Management Interface Specification (A00328-xxx) for more details.

When an event receiver gets an event packet, it does two things: First, it updates its mini system event log where it keeps the latest event from the SAT which is sending the event; second, it sends the event packet to the local SPARC as an asynchronous message through command 0x88.

6.8.4 Generating an Event From SPARC to Send to Another SPARC

This is a special case of event generation. Here the event is not sent to the current event receiver but to the address where the SPARC wants the event to be sent.

To send an event packet to another SPARC, the SPARC sends the packet through EBus command send event (command f6) to the local SMC. Also it sends the address where the event is to be sent. SMC extracts the packet and sends the event to this address.

The protocol to send the event to the receiver address remains the same. When the receiver gets the event packet, it sends the packet to local SPARC through command 0x88.

The EBus packet for command 0xf6 looks similar to CODE EXAMPLE 6-3:

CODE EXAMPLE 6-3 EBus Packet for Command 0xf6
LEN           D
CHK           0
SEQ           Sequence Number 
CMD           0XF6

The response packet for this EBus command is as shown in CODE EXAMPLE 6-4:

CODE EXAMPLE 6-4 Response Packet for EBus Command 0xf6
LEN           5
CHK           0
SEQ           Sequence number 
CMD           0XF6
CC            Completion Code

If the completion code is 0xC0, the SMC is waiting for the response to the previously sent event packet. If the completion code is 0, the event packet has been sent.

6.9 SMC Implementation Note

This document lists the features supported by this release (Release 3.8.9). A brief description is included for each command.

The list is sorted by the opcode number:

1. Cmd. 0x22, reset watchdog timer.

This is used to start and restart local watchdog.

2. Cmd. 0x24, set watchdog timer.

This is used to initialize and configure local watchdog timer.

3. Cmd. 0x25, get watchdog timer.

This is used to get the current setting and present countdown value.

4. Cmd. 0x2e, set SMC global enables.

This is used to set the global enable bits.

5. Cmd. 0x2f, get SMC global enables.

This is used to read the global enable bits settings.

6. Cmd. 0x33, get message.

This is used to retrieve data in the Receive Message Queue (RMQ). The data in RMQ is typically from IPMI channel.

7. Cmd. 0x34, send message.

This is used to send IPMI packet to the other board. The packet is appended to the EBus packet, with the channel number.

8. Cmd. 0x52, master write-read I2C

This is used to communicate with devices via I2C channel. It is normally used for raw data communication, not like IPMI packet.

9. Cmd. 0x55, get geographical address.

This reads 5 bits of geographical address of the slot from the backplane.

10. Cmd. 0x60, select memory device.

This command is reserved for SMC flash update operations, therefore it can't be used for other purposes. It selects the device type and segment number.

11. Cmd. 0x63, write selected memory device.

This command is reserved for SMC flash update operations. It writes multiple bytes of data into the selected device.

12. Cmd. 0x65, erase selected memory device.

This command is also reserved for SMC flash update operations. It erases one segment of the selected device.

13. Cmd. 0x6f, get firmware version.

This command returns multiple bytes of data, which includes version number, and if the code is running from main flash or boot flash. It also tells if the code is for actual production or testing.

14. Cmd. 0x70, reset device.

This command is used to reset device, and to control the level of reset (max or min. reset).

15. Cmd. 0x71, get role information.

This is used to find out if the board is SBC, SSBC or SAT.

16. Cmd. 0x83, notify SMC of host health.

This is used by SPARC to notify SMC of its health status.It updates the SMC the execution state of the host. Useful for power up sequence.

17. Cmd. 0x84, turn blue, or red LED on/off.

This is used to control the blue LED on the front panel of the board.

18. Cmd. 0x87, enum notification.

This is an asynchronous message sent by the SMC to the host. It is used to notify the host of a pending ENUM condition.

Note - The host does not send this command. This is an asynchronous command which means it comes only from the SMC.

19. Cmd. 0x88, IPMI response message notification.

This command is used by SMC to send unsolicited data to the host.

Note - The host does not send this command. This is an asynchronous command which means it comes only from the SMC.

20. Cmd. 0x8b, SMC local event.

This is used by the SMC to update the host of the action taken by the SMC. It is normally used during power up/reset.

Note - This is also an asynchronous command, only sent by the SMC.

21. Cmd. 0x8c, get device table data.

This is used by the host to read device table information. The device table contains data of which slots are occupied, etc. Only the board that support IPMI is listed.

22. Cmd. 0xa0, get SMC self test results.

This is used to read the SMC self test results. The self tests are done at power up only.

23. Cmd. 0xc3, EEPROM write.

This command is used to write data into I2C EEPROM devices using I2C channel (Channel 2). Multiple data can be written in one pass.

24. Cmd. 0xc4, EEPROM read.

This command is used to read data from EEPROM devices, using I2C channel (Channel 2). Multiple data can be read in one pass.

25. Cmd. 0xf4, get sensor event enable. This command is used to get the sensor event enable setting.

26. Cmd. 0xf5, set sensor event enable.

This is used to enable or disable sensor event generator. Each sensor event generator can be enabled or disabled

27. Cmd. 0xf6, send event.

This is used by one host to communicate with the other host on another board in different slot.

28. Cmd. 0xf8, get configuration block.

This is used to read the configuration data in the I2C EEPROM device.

29. Cmd. 0xf9, set configuration block.

This command is used to set the configuration data in the I2C EEPROM device.

The data is used for power up sequence.

Note - In order to take effect, after the new data is written, the board must be power cycled.

30. Cmd. 0xfb, set voltage.

This is used to set voltage level in the power module. Please consult the hardware team before using this command for testing.

31. Cmd. 0xfc, get sensor reading.

This is used to read the data of selected sensor. The data read includes the current status with respect to the threshold value, or state value.

32. Cmd. 0xfd, get sensor threshold

This command is used to get the current sensor threshold settings.

33. Cmd. 0xfe, set sensor threshold.

This command is used to set the sensor threshold settings.

6.10 Firmware Diagnostics

The firmware contains a comprehensive set of hardware diagnostic modules that provide tests for most situations. FIGURE 6-1, shows the control-flow relationship of the diagnostic modules with the system firmware. The Sun Validation Test Suite (SunVTStrademark) package can be executed from within the Solaris software if more tests are required.

The Firmware diagnostic modules are:

  • Basic POST (BPOST)
  • Comprehensive POST (CPOST)
  • Extended POST (EPOST) (currently not available on this board)
  • OBDiag

The firmware diagnostics cover address and data bits on all system buses and exercise the function of the major hardware resources on the board.

Diagnostics can be performed at OpenBoot PROM level by using the obdiag command, or by typing individual test commands at the ok prompt. These test suites are similar to those in earlier OpenBoot PROM versions but they are comprised of dropins that can be placed by the user.

6.10.1 Setting Diagnostic Levels

The user interface in terms of running POST at minimum or maximum remains the same. BPOST is embedded within Firmware CORE and is executed when the OpenBoot PROM environment variable, diag-switch? is set to true and
diag-level set to min. Similarly CPOST (and EPOST if it is present) is executed when diag-level is set to max. The permutations are shown in TABLE 6-4.

CPOST, and Extended POST are clients of Firmware CORE.

6.10.2 Basic POST (BPOST)

BPOST is integrated into Firmware CORE. It can provide on-demand diagnostic services in response to:

  • IPMI requests from the System Management Bus
  • Requests from the network
  • Requests from CompactPCI using the packet-based communication protocol

 FIGURE 6-4 Basic POST Services

This diagram shows the basic POST services such as on-demand diagnostics request..

BPOST consists of two parts:

The first part of BPOST executes from flash memory. It is designed to validate enough of the system resources to be able to run Firmware CORE in main memory (System RAM). If this test phase is passed, BPOST is also copied into system RAM.

The part of BPOST executed from flash includes basic tests for the items:

  • I-cache and D-cache
  • MMU
  • FPU
  • L2-cache tag and RAM
  • Data lines
  • CORE memory

The second part is performed after Firmware CORE is copied into main RAM. This part of BASIC POST executed from RAM includes:

  • Memory address line test--this test assumes that the CPU, MMU, and FPU are functional.
  • ECC block memory test--verifies main memory with block write and ECC checking. This test assumes that the CPU, MMU, and FPU are functional.

6.10.3 Comprehensive POST (CPOST)

Comprehensive POST (CPOST) is a client of Firmware CORE. It is a dropin module invoked by Firmware CORE and contains enhanced diagnostics for the CPU and on-board devices.

The execution of CPOST is optional and can be selectively controlled by an environment variable--see TABLE 6-4. CPOST runs after BPOST. To run CPOST, set the environment variables diag-switch to true and diag-level set to max.

CPOST tests comprise:

  • DMA logic test; advanced test of APB
  • Memory stress test; advanced main memory test
  • Basic PBM, IOMMU test
  • Basic Advanced PCI Bridge APB test
  • Basic PCI-PCI bridge test: verify the NTB
  • PCI/EBus/Ethernet/SuperI/O tests
  • System timers test
  • SuperI/O test; verify SuperI/O
  • Basic SCSI test; verify PCI configuration registers of Symbios 875 SCSI controller
  • System Management Controller test
  • Advanced 21555 diagnostics

Execution passes to EPOST (if it exists) or undergoes a software reset which sends it back to Firmware CORE. From this point, execution enters OpenBoot PROM (since diagnostics are only executed at power on reset).

6.10.4 Extended POST

Extended POST enables OEMs to provide additional firmware diagnostics for their hardware within a CP2140-based system. Extended POST is a dropin module invoked by CPOST and is also a client of Firmware CORE from which it uses trap- based services.

 FIGURE 6-5 POST Enables OEMs to add Diagnostics

In this diagram it shows how extended POST enables the addition of diagnostic support for the hardware in a CP2140 system.

The conditions for execution of EPOST are:

  • After CPOST completes, if there is any error, execution returns to the OpenBoot PROM with its standard interface. If BPOST tests are passed and diag-level is not set to max, execution passes to OpenBoot PROM.
  • If the diag-level is max, the CPOST code checks if there is an EPOST dropin in flash or user PROM area. If it does not find one, it displays a message:
There is no extended POST in this system
  • If CPOST finds an EPOST dropin, it loads it into memory and runs it.

Before passing control to EPOST, CPOST creates a list of pointers of vital functions and passes these to EPOST.

6.10.5 OpenBoot PROM Onboard Diagnostics

The OpenBoot PROM onboard diagnostics reside in the OpenBoot PROM dropin.

To execute the OpenBoot PROM onboard diagnostics, the system must be at the ok prompt. The OpenBoot PROM onboard diagnostics comprise:

  • Watch-clock
  • Watch-net and watch-net-all
  • Probe-scsi
  • Test alias name, device path, -all
  • Probe-scsi-all

6.10.6 OpenBoot Diagnostics

The OpenBoot Diagnostics are an enhancement of the traditional system tests. They reside in Forth script in a dropin and are invoked with an interactive tool started from the ok prompt.

When OpenBoot Diagnostics is started, the OpenBoot Diagnostics menu shown below is displayed.

1 ebus@1

4 flashprom@10,0

7 network@1,1

10 scsi@2,1

2 ebus@3

5 flashprom@10,400000

8 network@3,1

11 usb@1,3

3 fdthree@14,3203f0

6 flashprom@10,800000

9 scsi@2

12 usb@3,3

Commands: test test-all except help what printenvs setenv versions exit

An example of the test-all OpenBoot Diagnostics command follows:

ok obdiagobdiag> test-allHit the spacebar to interrupt testingTesting /pci@1f,0/pci@1,1/ebus@1 .....................................passed
Testing /pci@1f,0/pci@1,1/ebus@3 .....................................passed
Testing /pci@1f,0/pci@1,1/ebus@1/fdthree@14,3203f0 Testing 
floppy disk system.  A formatted disk should be in the drive.
Recalibrate failed.  The floppy drive is either missing,improperly 
connected, or defective.
Selftest at /pci@1f,0/pci@1,1/ebus@1/fdthree@14,3203f0 (return:-1) ...failed
Testing /pci@1f,0/pci@1,1/ebus@1/flashprom@10,0 ......................passed
Testing /pci@1f,0/pci@1,1/ebus@1/flashprom@10,400000 .................passed
Testing /pci@1f,0/pci@1,1/ebus@1/flashprom@10,800000 .................passed
Testing /pci@1f,0/pci@1,1/network@1,1 ................................passed
Testing /pci@1f,0/pci@1,1/network@3,1 ................................passed
Testing /pci@1f,0/pci@1,1/scsi@2 .....................................passed
Testing /pci@1f,0/pci@1,1/scsi@2,1 ...................................passed
Testing /pci@1f,0/pci@1,1/usb@1,3 ....................................passed
Testing /pci@1f,0/pci@1,1/usb@3,3 ....................................passed
Hit any key to return to the main menu  

1 (TableFootnote) Execute if hardware power-on, run-post set to true, post-level set to min/max, and key to skip post not pressed.
2 (TableFootnote) Execute if hardware power-on, run-post set to true, post-level set to max, and key to skip post not pressed.
3 (TableFootnote) Firmware CORE variables run-post and post-level are equivalent to enviromnment variables diag-switch and diag-level respectively.