| Netra CP2160 CompactPCI Board Installation and Technical Reference Manual |    
|
| Netra CP2160 CompactPCI Board Installation and Technical Reference Manual |
|
| C H A P T E R 4 |
|
Firmware |
The Netra CP2160 board platform comprises a modular firmware architecture that gives the user latitude in controlling boot initialization. The user can customize initialization and test firmware, even enabling 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 CompactPCI interface, System Management and Hot Swap control, and some board hardware. The SMC configuration is controlled by separate firmware.
This chapter contains the following sections:
Control flow at board startup is shown in FIGURE 4-1. Execution begins in Firmware Common Operations andReset 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.
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.
|
Initializes EBus and UPA/PCI and PCI/PCI bridges in path between CPU and EBus devices |
|
|
Perform basic diagnostics on caches & MMUs[1] |
|
|
Perform partial memory test[2] |
|
|
Setup I/D MMUs with valid mappings; enable MMUs and I/D caches |
|
|
Copy Firmware CORE into memory and transfer control to the RAM copy |
|
|
Execute POST dropin| |
|
|
Locate the client in PROM. If found, copy into memory and transfer control to it |
|
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:
EPOST is used for additional POST code dropins that are provided by the user.
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 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 typing show-devs at the ok prompt. An example of a device tree appears below.
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:
This section provides some information on the CORE SRAM variables and the configuration variables. For a battery-less system, such as the Netra CP2160 board, the NVRAM functions as an SRAM. That is, the SRAM stores configuration variables while the system is powered-on, but when the system goes through a power cycle, the system flash retains the variable information and reloads the SRAM at boot-up.
At start up, Firmware CORE defines a set of variables in the SRAM. These provide for controlling initialization and selecting the amount of testing required. These variables determine the following functions. At the CORE interface, type
print-nvram and the fixed offset SRAM variables similar to the following will be displayed on the screen (see TABLE 4-3):
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 at Power-on.
The Netra CP2160 board supports the USB keyboard.
Configuration variables are used by the OpenBoot PROM code and are stored in the system flash. The following is a sample of the output when the printenv command is entered at the ok prompt. The setenv command is used 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).
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 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.
|
diag-switch?[3] set: |
diag-level* set: |
||
|---|---|---|---|
The satellite host board boots from the 1MB 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 may be upgraded by running a program out of OpenBoot PROM--see Section 4.7, SMC Firmware. It is not otherwise accessible by the user.
TABLE 4-5 lists the firmware CORE Commands that are run from the monitor. At the key sequence Control-U mode (see TABLE 4-2), you may type help to get all the supported commands such as in the example shown below.
The Netra CP2160 board supports USB keyboard only.
Advanced System Monitoring (ASM) is an intelligent fault detection system to increase uptime and manageability at OpenBoot PROM. The SMC module on the Netra CP2160 board, supports the temperature monitoring functions of ASM. ASM monitors the following at regular intervals at the ok prompt:
At the OpenBoot PROM level, when an over-temperature condition occurs, corresponding messages are displayed on the console. 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. The warning-temperature and shutdown-temperature are maintained in the SRAM for the Netra CP2160 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 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.
The ASM also provides PCI-RESET# polling. ASM checks the status of the PCI_RESET# on the system board and enables the satellite board to respond accordingly. For example, a hot-swap cPCI chassis containing a system host board and a few Netra CP2160 satellite boards that are all at the ok prompt: If the PCI_RESET# is reasserted by the system board, then the assertion is polled by the SMC on the satellite boards. The satellite board then does an automatic reset-all on itself.
The field upgradeable SMC firmware supports features such as Netra CP2160 board resources, temperature monitoring, control of the power module, IPMI communication with other boards, PCI reset modes of operation, 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 WS833, the memory chip. Inside WS833, there are the main flash and the boot flash and SRAM for data storage. The host CPU sends commands and data to SMC via the EBus. For more details on the SMC subsystem please 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/new features, or providing special code for a specific OEM customer.
The SMC is capable of performing a flash update on both, main and boot flash. The main flash can flash update the boot flash, and the boot flash can flash update the main flash. The boot code contains the bare minimum code to be able to let the system boot to ok prompt in the event of the main flash failure, and be able to switch from boot flash to main flash for execution. Therefore any attempt to perform flash update to the boot flash is considered risky and should not be done too often.
The CORE/OpenBoot PROM code has support for recovery in case of SMC flash update failure. When it detects that SMC is running from boot code, it automatically goes to the ok prompt, and the user can do a flash update. Any other commands sent to SMC will not be allowed at this time.
For full details on SMC firmware and detailed commands, please refer to the Netra CP2160 board web site:
http://www.sun.com/products-n-solutions/nep/hardware/boards/cp2160/
This section provides information on the various modes of reset available on the Netra CP2160 board when used in the different roles and CompactPCI slots. TABLE 4-6 describes the available modes of operation in response to a reset request on the CompactPCI backplane. Determination of system or peripheral/satellite operation is made from the state of the cPCI backplane SYSEN# signal as per the PICMG 2.0 R3.0 Specification. The RESET# signal affects only the PCI component of the cPCI bus. Please refer to the Netra CP2160 board web site for detailed information on reset modes:
http://www.sun.com/products-n-solutions/nep/hardware/boards/cp2160/
|
Standard system slot operation -- the board generates normal RESET# and PCI signalling for the backplane in its role as system controller |
Backplane reset is propagated to the UltraSPARC-IIi 21555 NTB and other reset table components on the board. This results in a complete reset of the UltraSPARC section of the board. |
|
|
Standalone mode - The board asserts a constant RESET# but no PCI clocking for the cPCI bus, and does not respond to any PCI signalling on the backplane |
Standalone mode - The local cPCI bridge is held in reset, isolated from the cPCI bus. the board does not respond to any PCI signalling on the cPCI bus. |
|
|
66[4] |
Standard system slot operation -- the board generates normal RESET# and PCI signalling for the backplane in its role as system controller |
Standalone mode - The local cPCI bridge is held in reset, isolated from the cPCI bus. The board does not respond to any PCI signalling on the cPCI bus. |
Users may reprogram the operating mode from the OpenBoot PROM prompt, then reboot (power cycle) the entire system in order for the new reset modes to take effect.
|
Caution - Some of these modes may be incompatible with various PICMG specifications, and customers may use these modes at their own risk. |
The SMC power-on behavior and other attributes are stored in an 16-byte configuration block. This configuration block is stored in an accessible Serial I2C EEPROM. In the absence of this configuration block, SMC boots up in a default mode. For this purpose, at the OpenBoot PROM level there are two commands: setsmcenv and printsmcenv in the SMC node. The setsmcenv command is used to set paramters in the configuration block of SMC. The printsmcenv command prints the value of the parameters in the SMC configuration block.
To change 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 below:
During OpenBoot PROM start up sequence, and before the PCI probe, OpenBoot PROM checks for a valid SMC configuration block. If it does not find a valid configuration block (i.e configuration version is not equal to 1), then OpenBoot PROM instructs the SMC to program the configuration block with the following default settings:
Config version: 1 Backplane info: 0 Reset mode: 66 SIR & XIR: 2 Health control: 0 Health status: 0 byte 7: 0 byte 8: 0 |
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.7.2, Downloading and Installing SunVTS.
The firmware diagnostic modules are:
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. See the reference to the OpenBoot 4.x Command Reference Manual listed in Appendix D.
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 4-4.
CPOST and Extended POST are clients of Firmware CORE.
BPOST is integrated into Firmware CORE. It can provide on-demand diagnostic services in response to IPMI requests from the System Management Bus.
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:
The second part of BPOST is performed after Firmware CORE is copied into main RAM. This part of BASIC POST executed from RAM includes:
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
After CPOST it 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).
The OpenBoot PROM on-board diagnostics reside in the OpenBoot PROM dropin. These diagnostics are described fully in the OpenBoot 3.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 comprise:
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 that is started from the ok prompt by typing obdiag.
When OpenBoot Diagnostics is started, the following menu is displayed:
When at the obdiag prompt, typing test-all would display a printout similar to the following:
| Netra CP2160 CompactPCI Board Installation and Technical Reference Manual | 816-5772-11 |
|
Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.
