C H A P T E R  4

 


Firmware

The Netra CP2300 board contains a modular firmware architecture that gives you latitude in controlling boot initialization. You can customize the initialization, test the firmware, and even enable the installation of a custom operating system.

This platform also employs the System Management Controller (SMC)--described in Section 5.6, System Management Controller--which controls the system management and hot-swap control, and some board hardware. The SMC configuration is controlled by separate firmware.

This chapter contains the following sections:


4.1 Firmware Initialization

Control flow at board startup is shown in FIGURE 4-1. Execution begins in Firmware Common Operations and Reset Environment (CORE)--which includes Basic POST (BPOST). It passes to Comprehensive POST (CPOST) and Extended POST (EPOST), if these are present, before returning to firmware CORE and on to OpenBoot PROM. The test execution path is determined by environment variables.

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

Figure showing the Solaris software control flow of the board.

4.1.1 Firmware CORE and BPOST

Firmware CORE provides the following functionality:

BPOST is integrated into firmware CORE. BPOST 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 4-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. When a hardware item is not detected by the firmware, this firmware makes no attempt to test or initialize it.



Because BPOST runs from PROM, its 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 4-1 Firmware CORE and BPOST Flow of Execution

Firmware CORE Service

Description

Initialize processor

Sets processor in stable state.

Initialize NVRAM

Sets up state variables.

Initialize XBus and bridges

Initializes XBus and UPA/PCI and PCI/PCI bridges in path between CPU and XBus devices.

Initialize TTY

For message display.

Set memory timings

 

Verify NVRAM

Check magic number. Set defaults if bad.

Check keyboard

Probe & initialize keyboard, set TTYA otherwise.

Check I/O device for key pressed

Set state variables in NVRAM accordingly.

Cache, MMU test

Perform basic diagnostics on caches & MMUs[1].

Initialize caches, MMUs

Setup I and D caches and MMUs.

Memory probe

Probe memory and clear top memory region.

Memory test

Perform partial memory test[2].

MMU and cache setup

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

Initialize TOD

Initialize the time of day.

Set up CPU counter

Calibrate CPU counter to determine module speed.

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.


4.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:

4.1.3 EPOST

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

4.1.4 OpenBoot PROM

Rather than executing the initialization code that formerly existed in OpenBoot PROM for prior Sun board platforms, OpenBoot PROM now makes calls to the traps laid down by firmware CORE. 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, which is 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. The device tree is inherited by Solaris software as it is booted. An example of a device tree is shown below. The device tree can be seen by directory in the / directory. The device tree can be seen by typing show-devs at the ok prompt. An example of a device tree appears below.

CODE EXAMPLE 4-1 OpenBoot PROM show-devs Command Output

ok show-devs
/SUNW,UltraSPARC-IIe@0,0
/pci@1f,0
/ssp-serial
/multiplexer@0,0
/virtual-memory
/memory@0,0
/aliases
/options
/openprom
/chosen
/packages
/pci@1f,0/pci@1
/pci@1f,0/pci@1,1
/pci@1f,0/pci@1,1/usb@a
/pci@1f,0/pci@1,1/ide@d
/pci@1f,0/pci@1,1/ethernet@2
/pci@1f,0/pci@1,1/ethernet@1
/pci@1f,0/pci@1,1/pmu@3
/pci@1f,0/pci@1,1/isa@7
/pci@1f,0/pci@1,1/ide@d/cdrom
/pci@1f,0/pci@1,1/ide@d/disk
/pci@1f,0/pci@1,1/pmu@3/gpio@80000000,8a
/pci@1f,0/pci@1,1/pmu@3/i2c@0,0
/pci@1f,0/pci@1,1/pmu@3/i2c@0,0/i2c-nvram@0,8e
/pci@1f,0/pci@1,1/pmu@3/i2c@0,0/i2ctod@0,b0
/pci@1f,0/pci@1,1/pmu@3/i2c@0,0/dimm@0,70
/pci@1f,0/pci@1,1/pmu@3/i2c@0,0/dimm@0,80
/pci@1f,0/pci@1,1/pmu@3/i2c@0,0/dimm@0,88
/pci@1f,0/pci@1,1/pmu@3/i2c@0,0/i2c-nvram@0,8e/idprom@1fd8
/pci@1f,0/pci@1,1/isa@7/sysmgmt@0,8010
/pci@1f,0/pci@1,1/isa@7/flashprom@1f,100000
/pci@1f,0/pci@1,1/isa@7/flashprom@1f,0
/pci@1f,0/pci@1,1/isa@7/serial@0,2e8
/pci@1f,0/pci@1,1/isa@7/serial@0,3f8
/pci@1f,0/pci@1,1/isa@7/power@0,2000
/pci@1f,0/pci@1,1/isa@7/dma@0,0
/openprom/client-services
/packages/kbd-translator
/packages/console-pkg
/packages/dropins
/packages/SUNW,builtin-drivers
/packages/cdfs
/packages/ufs-file-system
/packages/disk-label
/packages/obp-tftp
/packages/deblocker
/packages/terminal-emulator
ok
 

The 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. CODE EXAMPLE 4-2 shows how the OpenBoot devalias command lists the available device tree aliases.

CODE EXAMPLE 4-2 OpenBoot PROM devalias Command Output

ok devalias
output-mux        /multiplexer:output
input-mux         /multiplexer:input
ssp-serial        /ssp-serial
hsc               /pci@1f,0/pci@1,1/isa@7/sysmgmt@0,8010
pmc1              /pci@1f,0/pci@1/@2
pmc0              /pci@1f,0/pci@1/@1
rtc               /pci@1f,0/pci@1,1/pmu@3/i2c@0,0/i2ctod@0,b0
usb               /pci@1f,0/pci@1,1/usb@a
uflash            /pci@1f,0/pci@1,1/isa@7/flashprom@1f,100000
flash             /pci@1f,0/pci@1,1/isa@7/flashprom@1f,0
systemprom        /pci@1f,0/pci@1,1/isa@7/flashprom@1f,0
i2c-nvram         /pci@1f,0/pci@1,1/pmu@3/i2c@0,0/i2c-nvram@0,8e
dload2            /pci@1f,0/pci@1,1/ethernet@2:,
net2              /pci@1f,0/pci@1,1/ethernet@2
dload             /pci@1f,0/pci@1,1/ethernet@1:,
net               /pci@1f,0/pci@1,1/ethernet@1
cdrom             /pci@1f,0/pci@1,1/ide@d/cdrom@2,0:f
disk              /pci@1f,0/pci@1,1/ide@d/disk@0,0
disk3             /pci@1f,0/pci@1,1/ide@d/disk@3,0
disk2             /pci@1f,0/pci@1,1/ide@d/disk@2,0
disk1             /pci@1f,0/pci@1,1/ide@d/disk@1,0
disk0             /pci@1f,0/pci@1,1/ide@d/disk@0,0
ide               /pci@1f,0/pci@1,1/ide@d
floppy            /pci@1f,0/pci@1,1/isa@7/dma/floppy
ttyb              /pci@1f,0/pci@1,1/isa@7/serial@0,2e8
ttya              /pci@1f,0/pci@1,1/isa@7/serial@0,3f8
ok 
 


4.2 Firmware Configuration Variables

This section provides some information on the CORE SRAM variables and the configuration variables. Firmware configuration variables are saved in the 8 Kbyte I2C serial EEPROM. The EEPROM's contents are preserved across board power-cycles.

4.2.1 Firmware CORE Execution Control

The key combinations listed in TABLE 4-2 can be used to control the flow of execution at system boot. These key combinations must be pressed when you turn the power on.

TABLE 4-2 Key Sequences

Key combination

Result

Control-P

Skip POST

Control-N

Set default SRAM configuration variables

Control-M

Turn on power on messages


The Netra CP2300 boards support USB keyboards.

4.2.2 OpenBoot PROM Configuration Variables

TABLE 4-3 describes the OpenBoot PROM configuration variables stored in the NVRAM and displayed by the OpenBoot PROM printenv command. Use the setenv OpenBoot command to modify the environment variables. The boot process is controlled by several variables (see TABLE 4-4). For values of each variable, refer to the OpenBoot 4.x Command Reference Manual (see Appendix D).

TABLE 4-3 OpenBoot PROM SRAM Configuration Variables

Variable Name

Default Value

Description

multiplexer-output-devices

ttya ttye

Specify multiple output devices.

multiplexer-input-devices

ttya ttye

Specify multiple input devices.

dhcp-clientid

 

Specifies the client information needed for a DHCP boot.

shutdown-temperature

70

Sets the CPU shutdown temperature.

critical-temperature

65

Sets the CPU critical temperature.

warning-temperature

60

Sets the CPU warning temperature.

env-monitor

disabled

Enable or disable environment monitoring at the OpenBoot PROM.

ntp-server-addr

255.255.255.255

Network time protocol (NTP) internet address.

ntp-enable?

false

Enable NTP synchronization.

diag-passes

1

Repeats each diagnostic test the number of times specified.

diag-continue?

0

When false, the diagnostic testing will stop within a test routine and prints a message as soon as an error is detected. After printing the message, the testing will then skip to the next test routine in the sequence.

When true, the diagnostic testing will run all subtests within a test, even if an error is detected.

diag-targets

0

Specify the target of the diagnostic testing.

diag-verbosity

0

Sets the level of diagnostic messages:

  • 0 = Prints one line that indicates the device being tested and its pass/fail status.
  • 1 = Prints more detailed test status, which varies in content from test to test.
  • 2 = Prints subtest names.
  • 4 = Prints debug messages.
  • 8 = Prints back trace of callers on error.

post-on-sir?

false

If variable is set to true, execute POST on soft reset.

keyboard-click?

false

If variable is set to true, enable keyboard click sound.

keymap

 

Use key map for custom keyboard.

scsi-initiator-id

7

Sets the SCSI bus address of host adapter, with a range of 0-7.

#power-cycles

No default

Initialized by manufacturer.

system-board-serial#

No default

Initialized by manufacturer.

system-board-date

No default

Initialized by manufacturer.

ttyb-rts-dtr-off

false

If variable is set to true, the operating system does not assert DTR and runs on TTYB.

ttyb-ignore-cd

true

If variable is set to true, the operating system ignores TTYB carrier-detect.

ttya-rts-dtr-off

false

If variable is set to true, the operating system does not assert DTR and runs on TTYA.

ttya-ignore-cd

true

If variable is set to true, the operating system ignores TTYA carrier-detect.

ttyb-mode

9600,8,n,1,-

TTYB settings (baud, #bits, parity, #stop, handshake).

ttya-mode

9600,8,n,1,-

TTYA settings (baud, #bits, parity, #stop, handshake).

pcia-probe-list

1,2

Probe list of devices present on internal PCI bus A.

pcib-probe-list

7,3,1,2,d,a

Probe list of devices present on internal PCI bus B.

mfg-mode

off

Manufacturing test mode (leave off).

diag-level

max

Sets the level of diagnostics to run (max or min).

watchdog-timeout

65535

Watchdog timeout value (in 1/10 sec.)

watchdog-enable?

false

Enable programming of watchdog

fcode-debug?

false

OpenBoot PROM dedub variable.

output-device

ttya

Console output device (usually a screen, TTYA, or TTYB).

input-device

ttya

Input device used at power-on (usually keyboard, TTYA, or TTYB).

load-base

16384

Base address where the client image is loaded by the OpenBoot PROM.

auto-boot-retry?

false

Attempt to reboot if initial boot fails.

boot-command

boot

Command that is executed if auto-boot? is set to true.

auto-boot?

true

If variable is set to true, the board boots automatically after a power-on reset.

watchdog-reboot?

false

If variable is set to true, the board boots automatically after a watchdog reset.

diag-file

 

File from which to boot in diagnostic mode.

diag-device

net

Device from which to boot.

boot-file

 

File from which to boot (an empty strings lets the secondary boot choose the default).

boot-device

disk net

Device from which to boot.

net-timeout

0

Specify the retry time to boot from the network. After timeout, the boot will abort. The default setting is 0 (retry infinite times).

ansi-terminal?

true

This variable is not applicable.

screen-#columns

80

Screen width in columns.

screen-#rows

34

Screen height in rows.

local-mac-address?

false

If variable is set to true, network drivers use the board's MAC address, and not the system's address.

silent-mode?

false

If variable is set to true, suppress messages related to clearing memory.

use-nvramrc?

false

If variable is set to true, execute commands in NVRAMRC during the board start-up.

nvramrc

 

Contents of the NVRAMRC.

security-mode

No default

Firmware security level (none, command, or full).

  • none: no password required.
  • command: all commands except for boot and go require password.
  • full: all commands except for go require password.

security-password

No default

Set the firmware security password (never displayed).

security-#badlogins

No default

OpenBoot PROM internal use.

oem-logo

No default

Byte array custom OEM logo (enabled by oem logo? true); displayed in hex.

oem-logo?

false

If true, use custom OEM logo, else use Sun logo.

oem-banner

No default

Custom OEM banner (enabled by oem-logo? true).

oem-banner?

false

If variable is set to true, use custom OEM banner.

hardware-revision

No default

Initialized in manufacture.

last-hardware-update

No default

Initialized in manufacture.

diag-switch?

false

If variable is set to true, POST is executed when system is next powered.


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

BPOST is embedded within the 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 4-4.

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

Module

diag-switch? Setting

diag-level Setting

Description

BPOST

false

X

No messages are output to TTY.

true

max (0x40)

Runs BPOST.

true

min (0x20)

Runs BPOST.

true

off (0x0)

No POST executed; messages displayed on TTYa.

CPOST

false

X

No messages are output to TTY.

true

max (0x40)

Runs after BPOST.

true

min (0x20)

CPOST is not run.

true

off (0x0)

No POST executed; messages displayed on TTYa.

EPOST

false

X

No messages are output to TTY.

true

max (0x4x)

Runs automatically after CPOST (if EPOST module is present).

true

off (0x0)

No POST executed; messages displayed on TTYa.



4.3 System Flash PROM Memory Map

The node 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 4-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 Section 4.6, SMC Firmware. It is not otherwise accessible by the user.

 FIGURE 4-2 System Flash PROM Map

Figure showing the system flash PROM memory map.


4.4 USB Keyboard Support

The Netra CP2300 supports USB keyboards only.


4.5 ASM Support at OpenBoot PROM

Advanced System Monitoring (ASM) is an intelligent fault detection system to increase uptime and manageability at OpenBoot PROM. The SMC module on the Netra CP2300 board, supports the temperature monitoring functions of ASM. ASM monitors the following at regular intervals at the ok prompt:



Note - Refer to the Netra CP2300 cPSB Board Programming Guide (817-1331-xx) for additional information about the ASM features of the Netra CP2300 board.



4.5.1 CPU Thermal Sensor

At the OpenBoot PROM level, when an over-temperature condition occurs, corresponding messages are displayed on the console. The OpenBoot PROM displays the warning messages as soon as the board temperature reaches the warning temperature and is still below the shutdown temperature. The shutdown messages are displayed as soon as the board temperature reaches the shutdown temperature. Finally, the critical messages are displayed when the board temperature reaches the critical temperature.

The warning-temperature, shutdown-temperature, and
critical-temperature are maintained in the SRAM for the Netra CP2300 board (for warning and shutdown temperature values, see TABLE 4-3). Also, the show-sensor command at OpenBoot PROM displays the readings of all the temperature sensors on the board.

When the CPU temperature reaches the set warning temperature limit, the following message is displayed at the ok prompt at regular intervals:

<<< !!! ALERT!!! Upper Non-critical - going high >>> 
     The current threshold setting is:  < >
     The current temperature is      : < >

When the CPU temperature reaches the set shutdown temperature limit, the following message is displayed at the ok prompt at regular intervals:

<<< !!! ALERT!!! Upper Critical - going high >>> 
     The current threshold setting is:  < >
     The current temperature is      : < >

The warning and shutdown temperature values provided are the OpenBoot PROM default values. A user can change these values by changing the corresponding SRAM variable values and resetting the system hardware or software.

ok setenv env-monitor enabled
ok setenv warning-temperature  <new_value>ok setenv shutdown-temperature <new_value>
ok setenv critical-temperature <new_value>ok reset-all

The <new_value> is a decimal value for a new temperature limit. The OpenBoot PROM then uses the new temperature limits after the system reset.



caution icon

Caution - Be careful when setting the temperature parameters. Setting the warning-temperature and shutdown-temperature values too high will leave the system unprotected against overheating. Setting the temperature too low may cause the Netra CP2300 board to send error messages continuously.




4.6 SMC Firmware

The field upgradeable SMC firmware supports features such as Netra CP2300 resources, temperature monitoring, control of the power subsystem, IPMI communication with other boards, configurable reset handling, hot-swap capability, and watchdog timer heartbeat mechanism. The SMC firmware also has its own built-in self-test at power up. The SMC consists of DS80CH11, which is an 8051 compatible chip and the PSD833F2 memory chip. Inside the PSD833F2 chip, there are the main flash and the boot flash and SRAM for data storage. The host CPU sends commands and data to SMC by way of the SBus. For more details on the SMC subsystem see Section 5.6, System Management Controller.

The SMC architecture allows the update of the SMC firmware. SMC firmware is only updated from the OpenBoot PROM. This feature is used to modify SMC firmware during a field upgrade, for fixing bugs, adding enhancements or new features, or providing special code for a specific OEM customer.

The SMC is capable of performing a flash update on the main and boot flash memory. The main flash can flash update the boot flash, and the boot flash can flash update the main flash. The boot code contains the minimum code to enable the system to boot to the ok prompt if the main flash fails, and to switch from boot flash to main flash for execution. Therefore, any attempt to perform a flash update of the boot flash would be considered risky and should not be done often.

The CORE/OpenBoot PROM code has support for recovery if the SMC flash update fails. When it detects that SMC is running from boot code, the code automatically goes to the ok prompt, enabling you to perform a flash update. Commands other than flash-update and get-version are not supported while running from the boot code.



Note - Due to interdependency between OpenBoot PROM CORE, SMC and hardware, you must take into account compatibility between various parts of the system among different version numbers when performing flash update.



4.6.1 SMC Configuration Block

The SMC power-on behavior and other attributes are stored in a 16-byte configuration block. This configuration block is stored in an accessible serial I2C SEEPROM. In the absence of this configuration block, SMC boots up in a default mode. At the OpenBoot PROM level, the setsmcenv and printsmcenv commands in the SMC node are used to set parameters in the configuration block of SMC. The printsmcenv command prints the value of the parameters in the SMC configuration block.

4.6.1.1 Setting the SMC Configuration Block

To view the settings on the configuration block, read the block using the printsmcenv command. If you want to change the settings, use the setsmcenv command to change the SEEPROM configuration block. Some examples are given in the code example below.

ok printsmcenv
config-version         : 1 
backplane-type         : 0 
reset-action           : 66 
sir-xir-enable         : 2 
back-end-power-option  : 0 
chassis-type           : 0 
flash-device           : 0 
set-role-option        : 0 
ipmi-checksum-ctlr     : 1 
healthy-option         : 0 
byteB                  : 0 
byteC                  : 0 
byteD                  : 0 
byteE                  : 0 
byteF                  : 0 
byte10                 : 0 
ok setsmcenv flash-device 4
ok



Note - Each setting on the configuration block can change the behavior of the board significantly. For example, an invalid value in config-version would cause the OpenBoot PROM to reset the configuration block to the default values. Ask your Sun field application engineer for further details on the configuration block settings.




4.7 Updating Flash PROMs

On the Netra CP2300 board, both the system (boot) flash and the user flash memory reside on the same physical device. By default the system flash uses 1 MByte of flash memory while the user flash uses 7 MBytes of flash memory (TABLE 4-4). For more information about system flash and user flash memory, see Section 5.3.4, Memory Components.

 FIGURE 4-3 System Flash and User Flash Logical Devices on Same Physical Device

Figure showing that the logical system flash and user flash devices exist on the same physical device.

4.7.1 Exchanging the System and User Flash Memory Devices

By default, the system flash is allocated 1 MByte of memory and user flash is allocated 7 MBytes of memory. If your application environment requires it, you can exchange these logical memory devices and make the system flash use 7 MBytes of memory and the user flash 1 MByte of memory.

To exchange these memory allocations, you must first change the SW3 DIP switch setting and set the flash-device setting in the configuration block. (See Section 4.6.1, SMC Configuration Block for more information about the configuration block.)

To Exchange the Flash Memory Devices:

1. At the ok prompt, use the printsmcenv command to display the configuration block.

ok printsmcenv
config-version         : 1 
backplane-type         : 0 
reset-action           : 66 
sir-xir-enable         : 2 
back-end-power-option  : 0 
chassis-type           : 0 
flash-device           : 0 
set-role-option        : 0 
ipmi-checksum-ctlr     : 1 
healthy-option         : 0 
byteB                  : 0 
byteC                  : 0 
byteD                  : 0 
byteE                  : 0 
byteF                  : 0 
byte10                 : 0 

If flash-device is set to any other value besides 4, you will need to set it to 4 in order to exchange the system flash and user flash memory allocations.

2. If the flash-device value is not equal to 4, use the setsmcenv command to set it to 4.

ok setsmcenv flash-device 4

3. Gracefully power-down the board and remove it from the chassis.

4. Locate the SW3 DIP Switch on the component side of the board.

The SW3 DIP switch is located slightly under the heat-sink on the board. FIGURE 4-4 shows the location and default setting of the SW3 DIP switch.

 FIGURE 4-4 SW3 DIP Switch Location

Figure showing SW3 DIP switch location and setting that controls the memory flash location.

SW3 DIP switch position 6 controls the flash memory selection. When position 6 is set to on (default), system flash will be assigned 1 MByte of memory and user flash will be assigned 7 MBytes of memory.

When SW3 DIP switch position 6 is set to off, and the flash-device setting of the configuration block is set to 4, user flash will be assigned 1 MByte of memory and system flash will be assigned 7 MBytes of memory.



caution icon

Caution - Do modify the settings on position 1 through 5 on the SW3 DIP switch. These positions are not user-selectable and any change to these positions' settings could critically damage the Netra CP2300 board.



5. To set the flash memory selection, set the SW3 DIP switch position 6 to off.

See FIGURE 4-4 for the location of the SW3 DIP switch.

6. Re-install the Netra CP2300 board into the chassis or system.

See Chapter 2 for installation instructions.

7. Power on the Netra CP2300 board and display the OpenBoot PROM ok prompt.

After setting the DIP switch and the flash-device setting, the system flash will be assigned 7 MBytes of memory and the user flash will be assigned 1 MByte of memory (see FIGURE 4-5).

 FIGURE 4-5 Exchanged System Flash and User Flash Logical Devices

Figure showing the logical system flash and user flash devices exchanged on the same physical device.

4.7.2 Determining the Flash Memory Settings

If you are unsure if system flash is allocated the default 1 MByte of memory or 7 MBytes of memory, you can use the OpenBoot devalias command to see where user flash logical device begins.

Using the devalias command at the ok prompt, you can see where the user flash device path begins. By default, the system flash will use 1 MByte of space, so the user flash will begin at 100000 bytes (0 to 99999 will be used by the system flash):

ok devalias uflash
uflash     /pci@1f,0/pci@1,1/isa@7/flashprom@1f,100000

If the SW3 DIP switch position 6 is set to off, and the flash-device is set to 4, the system flash uses 7 MBytes of space and the user flash device path will begin at 700000 (0 to 699999 will be used by the system flash):

ok devalias uflash
uflash     /pci@1f,0/pci@1,1/isa@7/flashprom@1f,700000

In both situations, the system flash device path will start at 0, so you should not use it to determine the flash memory sizes:

ok devalias flash
flash     /pci@1f,0/pci@1,1/isa@7/flashprom@1f,0

4.7.3 Updating Flash Memory

Use the flash-update and flat-update OpenBoot PROM commands to update the flash memory on the Netra CP2300 board. Use the flash-update command to update the Netra CP2300 board's OpenBoot PROM or add OpenBoot PROM drop-in packages, and use the flat-update command to add any raw device to flash memory.

The command formats are:

flash-update file-path flashtype
flat-update file-path flashtype

Where file-path is the path to the flash update image, and flashtype can be:

  • systemprom--updates the system flash
  • uflash--updates the user flash

4.7.4 SMC Firmware Update

You can only update the SMC firmware at the OpenBoot PROM ok prompt.

To update the SMC firmware:

1. Contact your Field Application Engineer to acquire the updated SMC firmware image.

2. Save the firmware to a directory on the system.

3. Use the smc-flash-update command to update the SMC firmware:

ok smc-flash-update filename

Replace filename with the filename and full path to the SMC firmware image.



Note - filename must point to a valid SMC firmware binary image or the file cannot be read to complete the flash update.




4.8 Firmware Diagnostics

The firmware contains a comprehensive set of hardware diagnostic modules that provide tests for most situations. FIGURE 4-1 shows the control-flow relationship of the diagnostic modules with the system firmware. SunVTS can be executed from within the Solaris software if more tests are required. For more information, see Section 3.3, Downloading and Installing SunVTS.

The firmware diagnostic modules are:

  • Basic POST (BPOST)
  • Comprehensive POST (CPOST) - optional
  • Extended POST (EPOST) - OEM supplied drop-in
  • 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 drop-ins that can be placed by the user. See the reference to the OpenBoot 4.x Command Reference Manual listed in Appendix D.

4.8.1 Setting Diagnostic Levels

The user interface for 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 is 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 4-4.

CPOST and Extended POST are clients of firmware CORE.

4.8.2 Basic POST (BPOST)

BPOST is integrated into firmware CORE. 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. BPOST runs when the diag-switch? is set to true (see TABLE 4-4).

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

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

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

  • Memory address line test - 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.

4.8.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 4-4). CPOST runs after BPOST. To run CPOST, set the environment variables diag-switch? to true and diag-level set to max

CPOST tests include:

  • Memory stress test; advanced main memory test
  • Basic PBM, IOMMU test
  • Basic Advanced PCI Bridge APB test
  • Davicom Ethernet 1, 2
  • South Bridge ISA, PMC, IDE, USB tests
  • System Management Controller test

After CPOST the system 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).

4.8.4 OpenBoot PROM On-Board Diagnostics

The OpenBoot PROM on-board diagnostics reside in the OpenBoot PROM drop-in. These diagnostics are described fully in the OpenBoot 4.x Command Reference Manual (see Appendix D).

To execute the OpenBoot PROM on-board diagnostics, the system must be at the ok prompt. The OpenBoot PROM on-board diagnostics include:

  • watch-clock
  • watch-net and watch-net-all
  • probe-scsi
  • test device path
  • test-all

4.8.5 OpenBoot Diagnostics

The OpenBoot Diagnostics are an enhancement of the traditional system tests. They reside in Forth script in a drop-in and are invoked with an interactive tool that is started from the ok prompt by typing obdiag.

When you start the OpenBoot Diagnostics, you should see the following menu:

ok obdiag
_____________________________________________________________________________
|                                 o b d i a g                                |
|_________________________ __________________________________________________|
|                         |                         |                        |
|  1 ethernet@1           |  2 ethernet@2           |  3 flashprom@1f,0      |
|  4 flashprom@1f,100000  |  5 i2c-nvram@0,8e       |  6 ide@d               |
|  7 pmu@3                |  8 serial@0,2e8         |  9 serial@0,3f8        |
| 10 usb@a                |                         |                        |
|_________________________|_________________________|________________________|
|   Commands: test test-all except help what printenvs setenv versions exit  |
|____________________________________________________________________________|

At the obdiag prompt, type test-all to display a printout similar to the following:

obdiag> test-all
Hit the spacebar to interrupt testing
Testing /pci@1f,0/pci@1,1/ethernet@1 .................................. passed
Testing /pci@1f,0/pci@1,1/ethernet@2 .................................. passed
Testing /pci@1f,0/pci@1,1/isa@7/flashprom@1f,0 ........................ passed
Testing /pci@1f,0/pci@1,1/isa@7/flashprom@1f,100000 ................... passed
Testing /pci@1f,0/pci@1,1/pmu@3/i2c@0,0/i2c-nvram@0,8e ................ passed
Testing /pci@1f,0/pci@1,1/ide@d ....................................... passed
Testing /pci@1f,0/pci@1,1/pmu@3 ....................................... passed
Testing /pci@1f,0/pci@1,1/isa@7/serial@0,2e8 .......................... passed
Testing /pci@1f,0/pci@1,1/isa@7/serial@0,3f8 [Used as Console] ........ passed
Testing /pci@1f,0/pci@1,1/usb@a ....................................... passed
 
Hit any key to return to the main menu 

 


1 (TableFootnote) Execute if hardware power-on, diag-switch? set to true, diag-level set to min/max, and key to skip POST not pressed.
2 (TableFootnote) Execute if hardware power-on, diag-switch? set to true, diag-level set to max and key to skip POST not pressed.