Sun Netra CT900 Server Administration and Reference Manual

You administer your system using the shelf management card command-line interface (CLI) or via Ethernet using the RMCP interface.

This chapter contains the following sections:

• IPMI LAN Interface
• Shelf Manager Command-Line Interface
• Monitoring Your System
• Re-initializing the Shelf Manager
• Reprogramming the Shelf Management Card
• Connecting to a Node Board Console
• Manual Graceful Shutdown of Node Boards

---

IPMI LAN Interface

The IPMI LAN interface is required by the ATCA specification and supports IPMI messaging with the Shelf Manager through the Remote Management Control Protocol (RMCP). A system administrator that uses RMCP to communicate with shelves is able to interact with any ATCA-compliant Shelf Manager. This low-level interface provides access to the IPMI aspects of a shelf, including the ability for the system administrator to issue IPMI commands to IPM controllers in the shelf, using the Shelf Manager as a proxy.

Supported IPMI Commands

The standard IPMI commands are documented in the PICMG 3.0, ATCA specification. TABLE 3-1 shows the IPMI commands implemented by the Shelf Manager. Due to security considerations, the treatment of a given command may be different, depending on whether it is received over the RMCP interface or on IPMB-0.

Get Self Test Results IPMI Command

The Get Self Test Results command returns the results of the POST tests performed by the U-Boot utility when the ShMM is powered up. If all tests are passed, the status code 0x55 is returned. If any tests fail, the device-specific failure code 0x59 is returned and the third byte contains the following bit mask:

IPMI OEM Extension Commands

In addition to the specification-defined IPMI commands listed in TABLE 3-1, the Shelf Manager implements several OEM-defined IPMI commands for the convenience of the System Manager. The Shelf Manager IPMI extension commands are listed in TABLE 3-2 and described in Appendix B.

---

Shelf Manager Command-Line Interface

The Shelf Manager command-line interface (CLI) can be used to communicate with the intelligent management controllers of the shelf, with boards, and with the Shelf Manager itself, through text commands. The CLI is an IPMI-based set of commands that can be accessed directly or through a higher-level management application or a script. Administrators can access the CLI through a Telnet connection or the shelf management card serial port. Using the CLI, operators can access information about the current state of the shelf including current FRU population, current sensor values, threshold settings, recent events, and overall shelf health.

Starting the Command-Line Interface

To use the CLI, first log on to the Linux operation system on the shelf management card. Once logged in, run the executable clia from the command line with specific parameters. The first parameter is the command verb. The clia executable is located on the virtual root file system maintained by Linux running on the shelf management card. The clia executable connects to the main Shelf Manager software process, passes the command information to it, and retrieves the results. The Shelf Manager must be running prior to starting the CLI.

For example:

# clia ipmc 20
 
Pigeon Point Shelf Manager Command Line Interpreter
 
20: Entity: (d0, 0) Maximum FRU device ID: 20
    PICMG Version 2.0
    Hot Swap State: M4, Previous: M3, Last State Change Cause: Normal State Change (0)
#

If started without parameters, clia enters an interactive mode. In that mode, the program repeatedly issues a prompt to the terminal, accepts user input as the next command with parameters, executes that command, and shows the results on the terminal, until the user types the command exit or quit. For example:

# clia
 
Pigeon Point Shelf Manager Command Line Interpreter
 
CLI> ipmc 20
 
20: Entity: (d0, 0) Maximum FRU device ID: 20
    PICMG Version 2.0
    Hot Swap State: M4, Previous: M3, Last State Change Cause: Normal State Change (0)
 
CLI> exit
#

Shelf Manager CLI Commands

The Shelf Manager CLI implements the following commands. They are described in detail in Appendix A, Shelf Manager CLI Commands with a subsection for each command, in alphabetical order of the command names.

Most informational commands support brief and verbose modes of execution, differing in the amount of information provided. Brief mode is the default (standard); verbose mode is selected by using the option -v in the command line, directly after the command and before the positional arguments. Commands that are executed on the backup Shelf Manager can only access objects (such as sensors, FRUs, IPM controllers) that are local to the backup Shelf Manager.

To help the user to determine whether a specific command is being executed on the active or on the backup Shelf Manager, the following message is issued when a CLI command is executed on the backup Shelf Manager: Running on the Backup Shelf Manager, with limited functionality.

---

Monitoring Your System

The Shelf Manager CLI provides many commands to monitor your system and display system status. This section describes various ways to monitor your system. See Shelf Manager CLI Commands or Appendix A, Shelf Manager CLI Commands for more information.

Displaying Board and IPMC Information

Board information includes information about each IPM controller in the range of IPMB addresses allocated to ATCA slots, and about each additional FRU controlled by these controllers. The range of IPMB addresses is 82h-A0h for PICMG 3.0 systems, where boards have IPM controllers on them.

Examples for the following tasks are provided showing the commands used and their outputs.

• To Display Standard Information About All Boards in the Server
• To Display Detailed Information About a Board
• To List the Sensors on a Board
• To Display Data from a Sensor on a Board
• To List All IPMCs in the Server
• To Display Information About a Specific IPM Controller
• To Display Detailed Information About the IPM Controller

  To Display Standard Information About All Boards in the Server

In the example, only the boards in physical slots 3, 4, 5, 7, and 8 are present.

# clia board
Pigeon Point Shelf Manager Command Line Interpreter
 
Physical Slot # 3
92: Entity: (0xa0, 0x60) Maximum FRU device ID: 0x01
    PICMG Version 2.2
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
 
92: FRU # 0
    Entity: (0xa0, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “NetraCP-3010”
 
Physical Slot # 4
8e: Entity: (0xa0, 0x60) Maximum FRU device ID: 0x01
    PICMG Version 2.1
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
 
8e: FRU # 0
    Entity: (0xa0, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “NetraCP-3060”
 
8e: FRU # 1
    Entity: (0xc1, 0x61)
    Hot Swap State: M4 (Active), Previous: M7 (Communication Lost), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “SB AMC-HD-A-80X”
 
Physical Slot # 5
8a: Entity: (0xa0, 0x60) Maximum FRU device ID: 0x00
    PICMG Version 2.1
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
 
8a: FRU # 0
    Entity: (0xa0, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “NetraCP-3020”
 
Physical Slot # 7
82: Entity: (0xa0, 0x60) Maximum FRU device ID: 0x01
    PICMG Version 2.1
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
 
82: FRU # 0
    Entity: (0xa0, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “ATS1160”
 
82: FRU # 1
    Entity: (0xc0, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “TM1460A RTM”
 
Physical Slot # 8
84: Entity: (0xa0, 0x60) Maximum FRU device ID: 0x01
    PICMG Version 2.1
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
 
84: FRU # 0
    Entity: (0xa0, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “CP3140H-BEG”
 
84: FRU # 1
    Entity: (0xc0, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “XCP3040H-RTC”
#

  To Display Detailed Information About a Board

This example shows detailed information about the board in physical slot 14.

# clia board -v 4
Pigeon Point Shelf Manager Command Line Interpreter
 
Physical Slot # 4
8e: Entity: (0xa0, 0x60) Maximum FRU device ID: 0x01
    PICMG Version 2.1
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID: 0x00, Revision: 0, Firmware: 0.210, IPMI ver 1.5
    Manufacturer ID: 00006F or 2A (Sun legacy), Product ID: 0bf4, Auxiliary Rev: 00000000
    Device ID String: "NetraCP-3060"
    Global Initialization: 0xc, Power State Notification: 0xc, Device Capabilities: 0x29
    Controller provides Device SDRs
    Supported features: 0x29
        "Sensor Device" "FRU Inventory Device" "IPMB Event Generator"
    8e: Base Interface (0x00), Channel: 1
        Link: Enabled Ports: 1
        Peer Addr: 0x82, Link Type: PICMG 3.0 Base Interface 10/100/1000 BASE-T, Ext: 0 (10/100/1000 BASE-T)
    8e: Base Interface (0x00), Channel: 2
        Link: Enabled Ports: 1
        Peer Addr: 0x84, Link Type: PICMG 3.0 Base Interface 10/100/1000 BASE-T, Ext: 0 (10/100/1000 BASE-T)
    8e: Fabric Interface (0x01), Channel: 1
        Link: Enabled Ports: 1
        Peer Addr: 0x82, Link Type: PICMG 3.1 Ethernet Fabric Interface, Ext: 0
    8e: Fabric Interface (0x01), Channel: 2
        Link: Enabled Ports: 1
        Peer Addr: 0x84, Link Type: PICMG 3.1 Ethernet Fabric Interface, Ext: 0
 
8e: FRU # 0
    Entity: (0xa0, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: "NetraCP-3060"
    Site Type: 0x00, Site Number: 04
    Current Power Level: 0x01, Maximum Power Level: 0x01, Current Power Allocation: 174.0 Watts
 
8e: FRU # 1
    Entity: (0xc1, 0x61)
    Hot Swap State: M4 (Active), Previous: M7 (Communication Lost), Last State Change Cause: Normal State Change (0x0)
    Device Type: "FRU Inventory Device behind management controller" (0x10), Modifier 0x0
    Device ID String: "SB AMC-HD-A-80X"
    Current Power Level: 0x01, Maximum Power Level: 0x01, Current Power Allocation: 21.1 Watts
#

  To List the Sensors on a Board

In this example, a list of sensors on the board at IPMB address 92 is displayed.

# clia sensor 92
Pigeon Point Shelf Manager Command Line Interpreter
 
92: LUN: 0, Sensor # 0 ("FRU 0 Hot Swap")
    Type: Discrete (0x6f), "Hot Swap" (0xf0)
    Belongs to entity: (0xa0, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 2 ("IPMB Physical")
    Type: Discrete (0x6f), "IPMB Link" (0xf1)
    Belongs to entity: (0xa0, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 4 ("CPU1 Temp")
    Type: Threshold (0x01), "Temperature" (0x01)
    Belongs to entity: (0x3, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 5 ("CPU2 Temp")
    Type: Threshold (0x01), "Temperature" (0x01)
    Belongs to entity: (0x3, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 6 ("Inlet Temp")
    Type: Threshold (0x01), "Temperature" (0x01)
    Belongs to entity: (0x3, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 7 ("+12.0V")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 8 ("-12.0V")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 9 ("+5.0V VCC")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 10 ("+3.3V Main")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 11 ("+3.3V StandBy")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 12 ("VBAT")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 13 ("VDD Core0")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 14 ("VDD Core1")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 15 ("VTT 1.25V")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 16 ("VDD 1.2V")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 17 ("VCC TM 2.5V")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 18 ("VDD +2.5V")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 19 ("VDD +1.5V")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 20 ("System Event")
    Type: Discrete (0x6f), "System Event" (0x12)
    Belongs to entity: (0xa0, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 3 ("BMC Watchdog")
    Type: Discrete (0x6f), "Watchdog 2" (0x23)
    Belongs to entity: (0x3, 96) [FRU # 0]
 
92: LUN: 0, Sensor # 21 ("RTM Presence")
    Type: Discrete (0x6f), "Entity Presence" (0x25)
    Belongs to entity: (0xa0, 96) [FRU # 0]
#

  To Display Data from a Sensor on a Board

In the example, information about sensor number 3 (CPU2 Temp) on the board at IPMB address 92 is displayed.

# clia sensor 92 9
Pigeon Point Shelf Manager Command Line Interpreter
 
92: LUN: 0, Sensor # 9 ("+5.0V VCC")
    Type: Threshold (0x01), "Voltage" (0x02)
    Belongs to entity: (0x14, 96) [FRU # 0]
 

  To List All IPMCs in the Server

This example shows the typical output for the ipmc command.

# clia ipmc
Pigeon Point Shelf Manager Command Line Interpreter
 
10: Entity: (0xf0, 0x60) Maximum FRU device ID: 0x08
    PICMG Version 2.1
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
 
20: Entity: (0xf0, 0x1) Maximum FRU device ID: 0x08
    PICMG Version 2.1
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
 
82: Entity: (0xa0, 0x60) Maximum FRU device ID: 0x00
    PICMG Version 2.1
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
 
88: Entity: (0xa0, 0x60) Maximum FRU device ID: 0x00
    Hot Swap State: M7 (Communication Lost), Previous: M4 (Active), Last State Change Cause: Communication Lost (0x4)
 
92: Entity: (0xa0, 0x60) Maximum FRU device ID: 0x00
    PICMG Version 2.1
    Hot Swap State: M4 (Active), Previous: M7 (Communication Lost), Last State Change Cause: Communication Lost (0x4)
 
96: Entity: (0xa0, 0x60) Maximum FRU device ID: 0x00
    Hot Swap State: M7 (Communication Lost), Previous: M6 (Deactivation In Progress), Last State Change Cause: Communication Lost (0x4)
20: Entity: (0xf0, 0x1) Maximum FRU device ID: 0x08
    PICMG Version 2.1
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)

  To Display Information About a Specific IPM Controller

In the example, basic information about the IPM controller at address 9C is displayed.

# clia ipmc 9c
Pigeon Point Shelf Manager Command Line Interpreter
 
9c: Entity: (0xd0, 0x0) Maximum FRU device ID: 0x08
    PICMG Version 2.0
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
#

  To Display Detailed Information About the IPM Controller

In the example, detailed information about the IPM controller at address 9C is displayed.

# clia ipmc -v 9c
Pigeon Point Shelf Manager Command Line Interpreter
 
9c: Entity: (0xd0, 0x0) Maximum FRU device ID: 0x08
    PICMG Version 2.0
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID: 0x00, Revision: 0, Firmware: 1.01, IPMI ver 1.5
    Manufacturer ID: 00315a (PICMG), Product ID: 0000, Auxiliary Rev: 01ac10ac
    Device ID String: "PPS Sentry 6"
    Global Initialization: 0x0, Power State Notification: 0x0, Device Capabilities: 0x29
    Controller provides Device SDRs
    Supported features: 0x29
        "Sensor Device" "FRU Inventory Device" "IPMB Event Generator" 
#

Displaying FRU Information

You can display information about all the FRUs in the system by issuing the clia fru command without any parameters, or you can display information for specific FRU by supplying the FRU’s address, and optionally the FRU ID. See Physical Address to Logical Slot Mapping for a mapping of chassis slot number to physical address to IMPB address.

In the following example, in the line “20: FRU # 1“, 20 is the midplane’s IPMB address and 1 is the FRU device ID.

# clia fru
Pigeon Point Shelf Manager Command Line Interpreter
 
20: FRU # 1
 Entity: (0xf2, 0x60)
Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
 Device ID String: "Shelf EEPROM 1"
 

IPMI FRU Information Layout

FIGURE 3-1 shows how the IPMI FRU information is organized. Each partition provides specific types of data.

• The Common Header contains area offsets.
• The Internal Use area is used to store proprietary data.
• The Chassis Information area contains chassis type, part number, serial number.
• The Board Information area contains manufacturer timestamp, manufacturer, product name, part/serial number.
• The Product Information area contains manufacturer, product name, part/serial number, version.
• The MultiRecord area contains dynamic data.

FIGURE 3-1 IPMI FRU Information Layout

Environment FRUs

Environment FRUs include midplane, shelf management cards, fans, power entry modules (PEMs), and the shelf alarm panel (SAP). All the environment FRUs have IPMI FRU information only, which are provided and programmed by third-party vendors.

The midplane FRU information includes the Sun part number as well as the third-party part number. Sun also adds additional system information such as slot, vlan, vtag, and other data, in the multirecord area of the midplane FRU information. The midplane FRU information is stored in two identical EEPROMs. Any change in one EEPROM is automatically made in the other EEPROM.

Blade FRUs

The Sun Netra CT900 server switch boards (located in slots 7 and 8) have IPMI FRU information only. The Sun node boards have two separate EEPROMS; one contains IPMI FRU information and the other contains Sun FRU information.

Examples

Examples for the following tasks are provided showing the commands used and their outputs.

• To Display Standard Information About All FRUs in the Shelf
• To Display Standard Information About All FRUs at Address 9C
• To Display Detailed Information About FRU #1 in the Shelf, Address 20
• To Display Detailed Information About FRU #0 on a Node Board at Address 8e.
• To Display FRU Information in Raw Form
• To Display FRU Information in User-Friendly Format

  To Display Standard Information About All FRUs in the Shelf

This example shows the standard FRU information displayed by the fru command with no arguments.

# clia fru
Pigeon Point Shelf Manager Command Line Interpreter
 
10: FRU # 0
    Entity: (0xf0, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “ShMM-500”
 
12: FRU # 0
    Entity: (0xf0, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “ShMM-500”
 
20: FRU # 0
    Entity: (0xf0, 0x1)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “PPS BMC”
 
20: FRU # 1
    Entity: (0xf2, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “Shelf EEPROM 1”
 
20: FRU # 2
    Entity: (0xf2, 0x61)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “Shelf EEPROM 2”
 
20: FRU # 3
    Entity: (0x1e, 0x0)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “Fan Tray 0”
 
20: FRU # 4
    Entity: (0x1e, 0x1)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “Fan Tray 1”
 
20: FRU # 5
    Entity: (0x1e, 0x2)
    Device ID String: “Fan Tray 1” Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “Fan Tray 2”
                                
20: FRU # 6                 
    Entity: (0xa, 0x60)     
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “PEM A”
                            
20: FRU # 7                 
    Entity: (0xa, 0x61)     
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “PEM B”
                            
20: FRU # 8                 
    Entity: (0x7, 0x6f)     
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “SAP Board”
                            
82: FRU # 0                 
    Entity: (0xa0, 0x60)    
    Hot Swap State: M4 (Active), Previous: M4 (Active, Last State Change Cause: Normal State (0x0)
    Device ID String: “NetraCP-3140”
 
84: FRU # 0 
    Entity: (0xa0, 0x60)
    Hot Swap State: M4 (Active), Previous: M4 (Active, Last State Change Cause: Normal State Change (0x0)
  Device ID String: "NetraCP-3140"
 
8e: FRU # 0
    Entity: (0xa0, 0x60)
 Hot Swap State: M4 (Active), Previous: M4 (Active), Last State Change Cause: Normal State Change (0x0)
    Device ID String: "NetraCP-3010
 
9a: FRU # 0                 
    Entity: (0xa0, 0x60)    
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: “NetraCP-3020”
 
 

  To Display Standard Information About All FRUs at Address 9C

In this example, only FRU information is displayed for all FRUs at physical address 9C.

# clia fru 9a 
Pigeon Point Shelf Manager Command Line Interpreter
 
9a: FRU # 0
    Entity: (0ad0, 0x60)
    Hot Swap State: M4 (Active), Previous: M3 (Activation In Process), Last State Change Cause: Normal State Change (0x0)
    Device ID String: "NetraCP-3020"
#

  To Display Detailed Information About FRU #1 in the Shelf, Address 20

In this example, detailed FRU information is displayed for FRU device ID 1 on the chassis, physical address 20.

# clia fruinfo 20 1
Pigeon Point Shelf Manager Command Line Interpreter
 
20: FRU # 1, FRU Info
Common Header:    Format Version = 1
 
Internal Use Area:
    Version = 1
Chassis Info Area:
    Version   = 1
    Chassis Type             = (23)
    Chassis Part Number      = 11592-450   
    Chassis Serial Number    = 
 
Board Info Area:
    Version     = 1
    Language Code            = 25
    Mfg Date/Time            = Jun 16 00:00:00 2005 (4973760 minutes since 1996)
    Board Manufacturer       = Schroff
    Board Product Name       = ShMM-ACB-III Shelf Manager (Radial IPMB)
    Board Serial Number      = 0000001 
    Board Part Number        = 21593-251   
    FRU Programmer File ID   = Schroff_11592450_AA.inf
         
Product Info Area:
    Version     = 1
    Language Code            = 25
    Manufacturer Name        = Schroff
    Product Name             = 12U 14-Slot ATCA Chassis
    Product Part / Model#    = 11592-450   
    Product Version          = Dual Star (Radial IPMB)
    Product Serial Number    = 0000001 
    Asset Tag                = 
    FRU Programmer File ID   = Schroff_11592450_AA.inf
         
Multi Record Area:
    PICMG Shelf Manager IP Connection Record (ID=0x13)
        Version = 1
         
    Record Type              = Management Access Record
        Version = 2
    Sub-Record Type: Component Name (0x05)
         
    PICMG Address Table Record (ID=0x10)
        Version = 0
         
    PICMG Backplane Point-to-Point Connectivity Record (ID=0x04)
        Version = 0
         
    PICMG Backplane Point-to-Point Connectivity Record (ID=0x04)
        Version = 0
         
    PICMG Shelf Activation And Power Management Record (ID=0x12)
        Version = 0
         
    PICMG Shelf Power Distribution Record (ID=0x11)
        Version = 0
         
    PICMG Radial IPMB-0 Link Mapping Record (ID=0x15)
        Version = 0
          
    Record Type              = 0xf0 OEM Defined Record
        Version = 2
    Manufacturer ID = 0x303833

  To Display Detailed Information About FRU #0 on a Node Board at Address 8e.

In this example, detailed FRU information is displayed for FRU device ID 0 on a node board installed at physical address 8e.

# clia fruinfo 8e 0
Pigeon Point Shelf Manager Command Line Interpreter
 
8e: FRU # 0, FRU Info
Common Header:    Format Version = 1
 
Board Info Area:
    Version     = 1
    Language Code            = 25
    Mfg Date/Time            = Mar 20 00:00:00 2006 (5372640 minutes since 1996)
    Board Manufacturer       = Sun Microsystems, Inc.
    Board Product Name       = NetraCP-3060
    Board Serial Number      = 00000000000000000001
    Board Part Number        = 00000000000005017313
    FRU Programmer File ID   = fru-info.inf
 
Product Info Area:
    Version     = 1
    Language Code            = 25
    Manufacturer Name        = Sun Microsystems, Inc.
    Product Name             = NetraCP-3060
    Product Part / Model#    = 00000000000005017313
    Product Version          = Rev 1.00TEST
    Product Serial Number    = 00000000000000000001
    Asset Tag                = 
    FRU Programmer File ID   = fru-info.inf
 
Multi Record Area:
    PICMG Board Point-to-Point Connectivity Record (ID=0x14)
        Version = 0
 
    AMC Carrier Information Table Record (ID=0x1a)
        Version = 0
 
    AMC Carrier Activation and Current Management Record (ID=0x17)
        Version = 0
 
    AMC Carrier Point-to-Point Connectivity Record (ID=0x18)
        Version = 0
 
    AMC Carrier Point-to-Point Connectivity Record (ID=0x19)
        Version = 0
 
    AMC Carrier Point-to-Point Connectivity Record (ID=0x19)
        Version = 0
 

  To Display FRU Information in Raw Form

In this example, FRU information is displayed in raw form for all FRUs and for a specific FRU.

# clia frudata
Pigeon Point Shelf Manager Command Line Interpreter
 
10: FRU # 0 Raw FRU Info Data
    FRU Info size: 435
12: FRU # 0 Raw FRU Info Data
    FRU Info size: 435
20: FRU # 0 Raw FRU Info Data
    FRU Info size: 152
20: FRU # 1 Raw FRU Info Data
    FRU Info size: 8192
20: FRU # 2 Raw FRU Info Data
    FRU Info size: 8192
20: FRU # 3 Raw FRU Info Data
    FRU Info size: 2048
20: FRU # 4 Raw FRU Info Data
    FRU Info size: 2048
20: FRU # 5 Raw FRU Info Data
    FRU Info size: 2048
20: FRU # 6 Raw FRU Info Data
    FRU Info size: 2048
20: FRU # 7 Raw FRU Info Data
    FRU Info size: 2048
20: FRU # 8 Raw FRU Info Data
    FRU Info size: 2048
20: FRU # 254 Raw FRU Info Data
    FRU Info size: 3068
9a: FRU # 0 Raw FRU Info Data
    FRU Info size: 512
# 
# clia frudata 20 1 0
Pigeon Point Shelf Manager Command Line Interpreter
 
20: FRU # 1 Block # 0 Raw FRU Info Data
    FRU Info size: 8192
 01 01 22 24  31 3E 00 49  01 A0 A1 A2  A3 A4 A5 A6 
 A7 A8 A9 AA  AB AC AD E0  E1 E2 E3 E4  E5 E6 D0 D1 

  To Display FRU Information in User-Friendly Format

This example shows a user-friendly version of the FRU information.

# clia fruinfo 20 1
Pigeon Point Shelf Manager Command Line Interpreter
 
20: FRU # 1, FRU Info
Common Header:    Format Version = 1
 
Internal Use Area:
    Version = 1
Chassis Info Area:
    Version   = 1
    Chassis Type             = (23)
    Chassis Part Number      = 11592-450   
    Chassis Serial Number    = 
 
Board Info Area:
    Version     = 1
    Language Code            = 25
    Mfg Date/Time            = Jun 16 00:00:00 2005 (4973760 minutes since 1996)
    Board Manufacturer       = Schroff
    Board Product Name       = ShMM-ACB-III Shelf Manager (Radial IPMB)
    Board Serial Number      = 0000001 
    Board Part Number        = 21593-251   
    FRU Programmer File ID   = Schroff_11592450_AA.inf
         
Product Info Area:
    Version     = 1
    Language Code            = 25
    Manufacturer Name        = Schroff
    Product Name             = 12U 14-Slot ATCA Chassis
    Product Part / Model#    = 11592-450   
    Product Version          = Dual Star (Radial IPMB)
    Product Serial Number    = 0000001 
    Asset Tag                = 
    FRU Programmer File ID   = Schroff_11592450_AA.inf
         
Multi Record Area:
    PICMG Shelf Manager IP Connection Record (ID=0x13)
        Version = 1
         
    Record Type              = Management Access Record
        Version = 2
    Sub-Record Type: Component Name (0x05)
         
    PICMG Address Table Record (ID=0x10)
        Version = 0
         
    PICMG Backplane Point-to-Point Connectivity Record (ID=0x04)
        Version = 0
         
    PICMG Backplane Point-to-Point Connectivity Record (ID=0x04)
        Version = 0
         
    PICMG Shelf Activation And Power Management Record (ID=0x12)
        Version = 0
         
    PICMG Shelf Power Distribution Record (ID=0x11)
        Version = 0
         
    PICMG Radial IPMB-0 Link Mapping Record (ID=0x15)
        Version = 0
          
    Record Type              = 0xf0 OEM Record
        Version = 2
    UNKNOWN Manufacturer ID = 0x303833
 

Displaying Shelf Information

You can use the clia shelf command with one of its valid parameters to display FRU information for key shelf FRUs. You can also get current operating data for the shelf and modify some fields in the Shelf FRU information. The valid shelf parameters are:

• cooling_state or cs
• fans_state or fs
• address_table or at
• power_distribution or pd
• power_management or pm
• pci_connectivity or pcic
• ha_connectivity or ha
• h110_connectivity or h1110c
• point-to-point_connectivity or ppc

See Display Shelf FRU Information for more information.

Examples

Examples for the following tasks are provided showing the commands used and their outputs.

• To Display Shelf Cooling Status
• To Display Shelf Fan Status
• To Display Address Table
• To Display Power Management Information
• To Display Power Distribution Information

  To Display Shelf Cooling Status

This example shows the commands and outputs for displaying the shelf’s cooling status.

# clia shelf cooling_state
Pigeon Point Shelf Manager Command Line Interpreter
 
    Cooling state: "Normal"
 
# clia shelf -v cooling_state
Pigeon Point Shelf Manager Command Line Interpreter
 
    Cooling state: "Normal"
    Sensor(s) at this state: (0x9a,4,0) (0x9a,5,0) (0x10,2,0) (0x9a,3,0) 
                             (0x20,120,0) (0x20,121,0) (0x20,122,0) (0x20,123,0) 
                             (0x20,200,0) (0x20,201,0) (0x20,240,0) (0x20,241,0) 
                             (0x20,242,0) 

  To Display Shelf Fan Status

The commands to display the fan status and the outputs are in this example.

# clia shelf fans_state
Pigeon Point Shelf Manager Command Line Interpreter
 
    Fans state: "Normal"
 
# clia shelf -v fans_state
Pigeon Point Shelf Manager Command Line Interpreter
 
    Fans state: "Normal"
    Sensor(s) at this state: (0x10,7,0) (0x10,8,0) (0x10,9,0) (0x10,10,0) 
                             (0x10,11,0) (0x10,12,0) 
# 

  To Display Address Table

This example shows the command and output for displaying the shelf address table.

# clia shelf address_table
Pigeon Point Shelf Manager Command Line Interpreter
 
    PICMG Address Table Record (ID=0x10)
        Version = 0
    Shelf Address            = 1 
    Address Table Entries#   = 16
        Hw Addr: 41, Site # 7, Type: "AdvancedTCA Board" 00
        Hw Addr: 42, Site # 8, Type: "AdvancedTCA Board" 00
        Hw Addr: 43, Site # 6, Type: "AdvancedTCA Board" 00
        Hw Addr: 44, Site # 9, Type: "AdvancedTCA Board" 00
        Hw Addr: 45, Site # 5, Type: "AdvancedTCA Board" 00
        Hw Addr: 46, Site # 10, Type: "AdvancedTCA Board" 00
        Hw Addr: 47, Site # 4, Type: "AdvancedTCA Board" 00
        Hw Addr: 48, Site # 11, Type: "AdvancedTCA Board" 00
        Hw Addr: 49, Site # 3, Type: "AdvancedTCA Board" 00
        Hw Addr: 4a, Site # 12, Type: "AdvancedTCA Board" 00
        Hw Addr: 4b, Site # 2, Type: "AdvancedTCA Board" 00
        Hw Addr: 4c, Site # 13, Type: "AdvancedTCA Board" 00
        Hw Addr: 4d, Site # 1, Type: "AdvancedTCA Board" 00
        Hw Addr: 4e, Site # 14, Type: "AdvancedTCA Board" 00
        Hw Addr: 08, Site # 1, Type: "Dedicated ShMC" 03
        Hw Addr: 09, Site # 2, Type: "Dedicated ShMC" 03

  To Display Power Management Information

An example of the command and its output are shown in this example.

# clia shelf pm
Pigeon Point Shelf Manager Command Line Interpreter
 
PICMG Shelf Activation And Power Management Record (ID=0x12)
        Version = 0
    Allowance for FRU Activation Readiness: 20 seconds
    FRU Activation and Power Description Count: 19
    Hw Address: 41, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
 
    Hw Address: 42, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
 
    Hw Address: 43, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
 
    Hw Address: 44, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
 
    Hw Address: 45, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 46, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 47, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 48, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 49, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 4a, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 4b, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 4c, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 4d, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 4e, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 44, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 45, FRU ID: 0xfe, Maximum FRU Power Capabilities: 200 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 08, FRU ID: 0xfe, Maximum FRU Power Capabilities: 24 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 09, FRU ID: 0xfe, Maximum FRU Power Capabilities: 24 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
    Hw Address: 20, FRU ID: 0xfe, Maximum FRU Power Capabilities: 100 Watts
        Shelf Manager Controlled Activation: Enabled
        Delay Before Next Power On: 0.0 seconds
         
# 

  To Display Power Distribution Information

The example shows the command and output for getting the shelf’s power distribution information.

# clia shelf pd
Pigeon Point Shelf Manager Command Line Interpreter
 
PICMG Shelf Power Distribution Record (ID=0x11)
        Version = 0
    Feed count: 8
    Feed 00:
        Maximum External Available Current: 25.0 Amps
        Maximum Internal Current: 25.0 Amps
        Minimum Expected Operating Voltage: -40.5 Volts
        Actual Power Available: 1012.500 Watts
        Currently Used Power: 30.000 Watts
        Feed-to-FRU Mapping entries count: 3
           FRU Addr: 49, FRU ID: 0xfe
           FRU Addr: 4b, FRU ID: 0xfe
           FRU Addr: 4d, FRU ID: 0xfe
    Feed 01:
        Maximum External Available Current: 25.0 Amps
        Maximum Internal Current: 25.0 Amps
        Minimum Expected Operating Voltage: -40.5 Volts
        Actual Power Available: 1012.500 Watts
        Currently Used Power: 30.000 Watts
        Feed-to-FRU Mapping entries count: 3
           FRU Addr: 49, FRU ID: 0xfee
           FRU Addr: 4b, FRU ID: 0xfe
           FRU Addr: 4d, FRU ID: 0xfe
    Feed 02:
        Maximum External Available Current: 25.0 Amps
        Maximum Internal Current: 25.0 Amps
        Minimum Expected Operating Voltage: -40.5 Volts
        Actual Power Available: 1012.500 Watts
        Currently Used Power: 40.000 Watts
        Feed-to-FRU Mapping entries count: 4
           FRU Addr: 41, FRU ID: 0xfe
           FRU Addr: 43, FRU ID: 0xfe
           FRU Addr: 45, FRU ID: 0xfe
           FRU Addr: 47, FRU ID: 0xfe
    Feed 03:
        Maximum External Available Current: 25.0 Amps
        Maximum Internal Current: 25.0 Amps
        Minimum Expected Operating Voltage: -40.5 Volts
        Actual Power Available: 1012.500 Watts
        Currently Used Power: 40.000 Watts
        Feed-to-FRU Mapping entries count: 4
           FRU Addr: 41, FRU ID: 0xfe
           FRU Addr: 43, FRU ID: 0xfe
           FRU Addr: 45, FRU ID: 0xfe
           FRU Addr: 47, FRU ID: 0xfe
        Maximum External Available Current: 25.0 Amps
        Maximum Internal Current: 25.0 Amps
        Minimum Expected Operating Voltage: -40.5 Volts
        Actual Power Available: 1012.500 Watts
        Currently Used Power: 40.000 Watts
        Feed-to-FRU Mapping entries count: 4
           FRU Addr: 42, FRU ID: 0xfe
           FRU Addr: 44, FRU ID: 0xfe
           FRU Addr: 46, FRU ID: 0xfe
           FRU Addr: 48, FRU ID: 0xfe
    Feed 05:
        Maximum External Available Current: 25.0 Amps
        Maximum Internal Current: 25.0 Amps
        Minimum Expected Operating Voltage: -40.5 Volts
        Actual Power Available: 1012.500 Watts
        Currently Used Power: 40.000 Watts
        Feed-to-FRU Mapping entries count: 4
           FRU Addr: 42, FRU ID: 0xfe
           FRU Addr: 44, FRU ID: 0xfe
           FRU Addr: 46, FRU ID: 0xfe
           FRU Addr: 48, FRU ID: 0xfe
    Feed 06:
        Maximum External Available Current: 25.0 Amps
        Maximum Internal Current: 25.0 Amps
        Minimum Expected Operating Voltage: -40.5 Volts
        Actual Power Available: 1012.500 Watts
        Currently Used Power: 100.000 Watts
        Feed-to-FRU Mapping entries count: 6
           FRU Addr: 08, FRU ID: 0xfe
           FRU Addr: 09, FRU ID: 0xfe
           FRU Addr: 20, FRU ID: 0xfe
           FRU Addr: 4a, FRU ID: 0xfe
           FRU Addr: 4c, FRU ID: 0xfe
           FRU Addr: 4e, FRU ID: 0xfe
    Feed 07:
        Maximum External Available Current: 25.0 Amps
        Maximum Internal Current: 25.0 Amps
        Minimum Expected Operating Voltage: -40.5 Volts
        Actual Power Available: 1012.500 Watts
        Currently Used Power: 100.000 Watts
        Feed-to-FRU Mapping entries count: 6
           FRU Addr: 08, FRU ID: 0xfe
           FRU Addr: 09, FRU ID: 0xfe
           FRU Addr: 20, FRU ID: 0xfe
           FRU Addr: 4a, FRU ID: 0xfe
           FRU Addr: 4c, FRU ID: 0xfe
           FRU Addr: 4e, FRU ID: 0xfe
# 

---

Re-initializing the Shelf Manager

This section describes how to re-initialize the U-Boot environment variables, the file system in Flash memory, and the login password on the shelf management card.

Re-initialize the U-Boot Environment

The U-Boot environment variables are stored in the shelf management card EEPROM. To restore the factory defaults for the U-Boot environment variables, you must first erase the environment variables stored in EEPROM and reset (or power cycle) the shelf management card.

Caution - U-boot re-initialization can cause the backup ShMM to continually reboot because some critical variables are being reset. To prevent this, make a copy of existing variables before re-initialization and apply them after re-initialization. For lists of variables that need to be restored, see the list the variables that should only be changed for debugging by advanced users and the list variables should not be changed list in Recommendations for Changing U-Boot Variables.

1. Erase the EEPROM by entering the following command from the U-Boot prompt:

shmm500 eeprom write 80400000 0 1000
 
EEPROM @0x50 write: addr 80400000  off 0000  count 4096 ... done

2. Reset the shelf management card as follows:

shmm500 reset
U-Boot 1.1.2 (Nov 27 2005 - 19:17:09)
 
CPU: Au1550 324 MHz, id: 0x02, rev: 0x00
Board: ShMM-500
S/N: 8000041
DRAM:  128 MB
Flash: 64 MB
*** Warning - bad CRC, using default environment
 
In:    serial
Out:   serial
Err:   serial
Net:   Au1X00 ETHERNET
Hit any key to stop autoboot:  0 
 
YOU MUST HIT ANY KEY NOW TO BREAK THE BOOT PROCESS

3. Set default for the Sun environment

shmm500 setenv rc2 /etc/rc.acb3

4. Save these environment settings using the following commands:

The saveenv command must be issued twice as shown.

shmm500 saveenv
shmm500 saveenv

5. Reboot the shelf manager card using the following command:

shmm500 boot

Re-initializing the File System

The file system is stored within the Flash memory and can be reset to factory defaults quite easily. U-Boot has an environment variable called flash_reset. Setting this variable to y and then booting the system will re-initialized the file system to the factory defaults.

# setenv flash_reset y
# boot

The flash_reset variable is automatically set to n at system startup after the Flash memory is re-initialized. The bootcmd command will begin booting the Linux kernel. It is during this process that the file system is re-initialized. The following output will be shown on the console.

/etc/rc: Mounted /dev/pts
/etc/rc: Flash erase requested via U-BOOT var
/etc/rc: erasing mtdchar1 -> /etc
Erased 1024 Kibyte @ 0 -- 100% complete.
/etc/rc: erasing mtdchar0 -> /var
Erased 1536 Kibyte @ 0 -- 100% complete.
/etc/rc: Mounted /dev/mtdblock3 to /var
/etc/rc: /var/log mounted as FLASH disk
/etc/rc: Started syslogd and klogd
/etc/rc: /var/tmp mounted as RAM disk
/etc/rc: hostname demo
/etc/rc: /dev/mtdblock2 appears to be empty ... restoring from factory /etc...
 

Resetting the Login Password

The factory default login for the shelf management card is userid root and password sunct900. Users are encouraged to change the password when configuring the Shelf Manager. In the event that the new password is forgotten, the password can be reset to its factory default via the password_reset U-Boot variable. Setting this variable to y and then booting the system will remove the root password.

# setenv password_reset y
# boot

The following output will be displayed on the console, during boot.

/etc/rc: hostname demo

---

Reprogramming the Shelf Management Card

Reprogramming the shelf management card involves reprogramming several firmware images stored on it. The set of images can be conceptually divided into two groups, depending on the method of reprogramming them. These groups are:

• U-Boot, Linux kernel, and Linux root file system (RFS) images

These images are normally reprogrammed using the reliable upgrade procedure. Alternatively, the kernel and RFS can be reprogrammed from the U-Boot prompt by loading them from a TFTP server.

• Complex Programmable Logic Device (CPLD) image

This image is reprogrammed from the shelf management card command line, using a special command-line utility cpldtool.

Detailed instructions for reprogramming these images are given below

Firmware Reliable Upgrade Procedure

The Monterey Linux operating system provides a reliable upgrade procedure for the firmware images on a running and functioning shelf management card. The procedure supports upgrade of the U-Boot firmware, the Linux kernel, and the Linux RFS (or an arbitrary combination of these three images). If a software upgrade attempt fails (for instance, due to installation of a faulty U-Boot firmware image, incapable of booting the shelf management card or a Shelf Manager that can’t start) the reliable upgrade procedure automatically falls back to the previous version of the firmware in persistent Flash memory.

The shelf management card Flash memory is divided into two areas. When a stable set of firmware is established in one of these areas, it is designated the persistent area. When new firmware is installed, it goes in the other area, which is initially designated provisional. Once a new set of firmware in the provisional area is validated, that area is designated the persistent area and continues in use until a future upgrade cycle starts the process over.

The reliable upgrade hardware mechanisms ensure that no matter what is installed to the provisional Flash, the shelf management card always manages to boot from a software copy that is either fully functional or sufficiently sane to determine that there has been a failure in the upgrade session and consequently take appropriate corrective actions to revert to the safe software copy in persistent Flash.

At a higher level, the reliable upgrade hardware mechanisms are assisted by a software protocol based on logging of the status of the upgrade session to a non-volatile file in /var/upgrade/status (see Reliable Upgrade Procedure Status File). The software protocol ensures that the reliable upgrade does not finish until all the required actions, including those defined by custom hook scripts that might be needed for a specific application, have completed successfully.

The reliable upgrade procedure implemented in Monterey Linux is neutral to the embedded application running on the shelf management card. The procedure provides a sufficient set of “hooks” allowing a specific application running on the shelf management card to ensure that custom actions are carried out at appropriate points of the reliable upgrade. The remainder of this section focuses on provisions for reliable upgrade of the Pigeon Point Shelf Manager firmware that have been implemented using these hooks.

Flash Partitioning

The shelf management card provides a hardware mechanism that allows swapping of the lower and upper halves of the Flash in the system memory map under control of software running on the MIPS processor. This capability is implemented in support of the reliable upgrade procedure for software images in Flash. The reliable software upgrade procedure assumes that the Flash device contains two copies of the software, located in the lower and upper halves of Flash. All shelf management cards are shipped with the partitioning, where the Flash device is divided onto two equal parts, each dedicated to holding one copy of the Shelf Manager software.

The U-Boot environment variable reliable_upgrade (see U-Boot Environment Variables) is used by the Linux layers to determine whether or not the reliable upgrade procedure is enabled. This variable must be set to y and is passed to the Linux kernel in the bootargs kernel parameters string. The Linux Flash MTD layer checks the reliable_upgrade parameter at Flash partitions initialization time and, depending on the parameter value (as well as the size of the Flash device installed on the shelf management card), partitions the Flash device in an appropriate way.

This section assumes that the shelf management card is configured to support the reliable upgrade, including the two separate Flash regions. TABLE 3-4 provides a summary of the Flash partitions maintained on the shelf management card in this configuration (reliable_upgrade=y):

TABLE 3-5 provides a summary of the Flash partitions maintained on the shelf management card for the 64MB Flash devices:

The /var/upgrade File System

As documented in Firmware Reliable Upgrade Procedure, if reliable_upgrade is y, Monterey Linux mounts a 1-MByte partition as a JFFS2 file system at /var/upgrade. This file system is used to host the reliable upgrade procedure status file (see Reliable Upgrade Procedure Status File).

It is important to note that the /var/upgrade JFFS2 partition is composed of two non-contiguous Flash blocks (0.5 MByte each), one residing in the lower half and one in upper half of the Flash device. Monterey Linux takes advantage of the ability of the Linux MTD and JFFS2 layers to support a file system in non-contiguous Flash sectors in order to implement /var/upgrade this way.

Another feature of the JFFS2 file system that makes /var/upgrade work for the purposes of the reliable upgrade procedure is that the JFFS2 internal structures do not create any dependencies (such as linked lists) based on Flash sector numbers or absolute offsets in Flash. Instead, when mounting a file system on a partition, the JFFS2 scans all the Flash sectors making up the partition and recreates the logical content of a file system in an internal in-RAM representation. This feature ensures that regardless of which half of the Flash the ShMM has booted from, Linux is able to mount /var/upgrade as a JFFS2 file system and make use of the previous content of the file system.

Reliable Upgrade Procedure Status File

The software reliable upgrade procedure maintains the status of the most recent upgrade procedure session in the file /var/upgrade/status residing in a dedicated file system (/var/upgrade), which is mounted by Linux regardless of which Flash the ShMM has booted from. If the file exists, it contains the status of an upgrade procedure session that either is in progress presently or has recently completed.

/var/upgrade/status is an ASCII-format file that contains one or more new line-terminated records, each describing the status of a particular step in the upgrade procedure. The format of a record line is as follows:

<step>: <status>

where step is an integer ranging from 1 to 14 (with Step 14 corresponding to a completed upgrade session) and status is a human-readable string describing status of the current step of the upgrade procedure session.

The status file is used by the reliable upgrade utility (see Reliable Upgrade Utility) to maintain a software protocol atop the reliable upgrade procedure hardware mechanisms to reliably determine the status of the upgrade procedure and proceed as appropriate.

Reliable Upgrade Utility

A special user-space, reliable upgrade utility is provided for carrying out the reliable upgrade procedure as well as checking the status of the most recent upgrade.

The utility can be called only from the superuser (root) account. Any attempt to run the utility from a non-superuser account is rejected.

As a first step in its execution, the utility checks that the reliable_upgrade U-Boot environment variable (see Flash Partitioning), as passed by U-Boot to the Linux kernel in the kernel parameters string, is set to y. If this check fails, the utility immediately terminates and exits with an appropriate error code.

If called with any of the -s, -c, or -f options, the utility is being used to carry out the reliable upgrade procedure. While in the upgrade procedure, the utility logs to /var/upgrade/status the status of each action it performs as it proceeds through the steps of the upgrade procedure. If the utility detects a failure, the reliable upgrade procedure is terminated by adding to /var/upgrade/status a record indicating an unsuccessful completion of the upgrade procedure and exiting with an appropriate error code.

The utility prints any informational messages to stdout. Providing -v specifier to any option that supports it increases the verbosity of the informational messages. The utility prints any error messages to stderr.

The utility has the following syntax:

• rupgrade_tool -s {--dst=src}... [--proto=protocol] [-d] [--hook=args] [-v]
• rupgrade_tool -c [-v]
• rupgrade_tool -f [--hook=args] [-v]
• rupgrade_tool -w [-f]
• rupgrade_tool -S [-v]
• rupgrade_tool -u
• rupgrade_tool -h

where the parameters are defined as follows:

-s {--dst=src}... [--proto=protocol] [--hook=args] [-v]

Initiate the reliable upgrade procedure. As delivered with Shelf Manager support, this step includes the following actions:

• Obtaining the images to copy, locally or via the network
• Copying the images to the provisional Flash
• Terminating the Shelf Manager instance running on the ShMM, if any
• Copying non-volatile data to the provisional Flash
• Resetting the shelf management card and instructing it to boot from the provisional Flash

Because of the last step, an invocation of rupgrade_tool -s typically does not return and instead resets the shelf management card. If rupgrade_tool -s does return, it indicates that the reliable upgrade procedure has failed and was terminated before proceeding to reset the shelf management card in order to boot from the provisional Flash.

Before the first step of the upgrade procedure is initiated by the utility, it removes the /var/upgrade/status file (see Reliable Upgrade Procedure Status File). In other words, the status of the previous upgrade procedure session (if any) is lost and overwritten by the status of the new upgrade procedure session as soon as rupgrade_tool -s is called.

There can be one or more --dst=src specifiers in a call to rupgrade_tool -s. Each such specifier defines the name of a to-be-installed upgrade image file and where the file is to be installed in the Flash of the shelf management card.

dst defines the destination of a newly installed upgrade image and can be any of the following:

• u - Upgrade the U-Boot image in the provisional U-Boot firmware image partition (/dev/mtdchar3).
• k - Upgrade the Linux kernel image in the provisional Linux kernel image partition (/dev/mtdchar2).
• r - Upgrade the root file system image in the provisional root file system image partition (/dev/mtdchar4).

src specifies an upgrade image file to be copied to the provisional Flash partition specified by dst.

The image upgrade works as follows. For each of the specified src images, the image is copied to the shelf management card using the specified copy protocol. If no -d specifier is supplied, the image is first copied to the RAM file system of the shelf management card (specifically, the copy is to the /tmp directory) and then moved to Flash (that is, copied to the destination partition in Flash and then removed from the RAM file system). If a -d specifier is supplied in the call to rupgrade_tool -s, the intermediate copy to the /tmp directory is skipped and the image is copied directly to its destination in the Flash. Use of this specifier is intended for a scenario where there is insufficient runtime memory on the shelf management card for an intermediate copy to the RAM file system.

If no -d specifier is supplied, the reliable upgrade procedure invokes a special script, the main purpose of which is to validate images after they are copied to the /tmp directory. If -d specifier is present, no such validation is performed.

Currently, the script /etc/upgrade/step4vshm supplied with the Shelf Manager does not perform specific image validation steps, but does take responsibility for filling in the Flash partitions for which no images are provided in the current call to rupgrade_tool (as would happen in a partial upgrade scenario). These partitions are copied from the current persistent Flash to the provisional Flash. For example, if the current partial upgrade provides only a new RFS image, the script copies the U-Boot and kernel partitions from the persistent Flash to the provisional Flash.

As soon as the first image has been installed to its destination, the utility proceeds to the second image (if there is one), and so on, until all the supplied image files have been successfully installed to Flash. A failure to successfully install an image immediately terminates the upgrade procedure (vs. skipping a failing image and proceeding to the next one).

This approach enables the user to separately upgrade the three parts of shelf management card firmware (U-Boot, kernel, and RFS image). However, bear in mind that the parts that are not explicitly updated will be copied from persistent Flash.

It is recommended that you use of one of the following upgrade approaches:

• Explicitly upgrade all three partitions.
• When fewer than three partitions are explicitly upgraded, omit the -d specifier; in that case, the special script mentioned above will automatically ensure that every upgrade is effectively a full upgrade covering all three partitions.

protocol specifies a file copy protocol used to pull each of the specified src files to the Shelf Manager and can be any of the following:

• no - No copy is performed. This protocol assumes that all of the specified src files were pushed to the /tmp directory prior to start of the reliable upgrade procedure. This protocol choice cannot be used in conjunction with the -d option.
• cp:dir - Simple copy. This protocol assumes that all of the specified src files are to be copied from the specified directory in the Shelf Manager local file system by the cp command. This protocol can be useful, for instance, for installation of upgrade images from an NFS-mounted file system or even from a JFFS2 file system.
• ftp:server:dir:user[:pwd] - Copy from a remote FTP server. This protocol assumes that all of the specified src files are to be copied to the shelf management card from the FTP server host specified as the host name or the IP address by server. All the images must reside in the directory specified by dir on the remote FTP server. The FTP connection is made using the account specified by the user parameter, with the password specified by the optional pwd parameter. If no pwd is supplied, the utility will prompt for a password.

A failure in copying an image to the Shelf Manager causes the utility to terminate the upgrade procedure (vs. skipping a failing image and proceeding to the next one).

For each provisional Flash partition upgraded by the -s option, the partition to be upgraded is given write permissions after the validity of the image has been checked and immediately before the src image is moved to the Flash. Write permissions are removed from the partition immediately after the full image has been moved to Flash. Combined with the fact that all the partitions containing the U-Boot, Linux kernel, and root file system images are read-only on boot of the Shelf Manager, this ensures that applications cannot accidentally erase the critical boot images.

After all the specified images have been installed to their respective destinations in Flash memory, the utility invokes a hook script that enables custom actions required by an application at the point where the upgrade images have been already installed in Flash but the upgrade procedure has not yet initiated the hardware mechanisms of the reliable upgrade procedure by enabling the ShMM’s upgrade watchdog timer (WDT).

The hook script, /etc/upgrade/step4hshm, is supplied with the Shelf Manager. It performs the following actions:

• Terminates the Shelf Manager, performing a switchover to the backup ShMM without restarting the shelf; the ATCA watchdog timer is stopped.
• Mounts the provisional /etc and /var Flash partitions and erases all files on them.
• Optionally copies the current contents of the /etc directory to the provisional /etc Flash partition.
• Optionally copies the current non-volatile Shelf Manager information from the directory /var/nvdata to the provisional /var file system; or optionally copies the whole /var directory to the provisional /var Flash partition.
• Temporarily (until next boot) sets the boot delay to 0; this is done to minimize the time of the next boot and prevent the reliable upgrade watchdog timer from premature expiration.

This script is invoked as a sub-shell and given a single parameter, which is either the string specified by args or no args (an empty string). The given parameter defines the script’s operational mode which determines operations like the copying of non-volatile information from the persistent Flash partitions to the provisional Flash partitions. The script takes the following args values, and perform the corresponding actions:

• No parameter supplied - the script erases both the provisional /etc and provisional /var directories, then copies Shelf Manager non-volatile information from the directory /var/nvdata to the provisional /var partition. This is the default mode of operation; in this case, the non-volatile data will be preserved but the Shelf Manager configuration file will be taken from the new RFS image.
• erase - the script erases both the provisional /etc and provisional /var directories; they will be restored from the RFS default values during the next boot; the current Shelf Manager non-volatile data and configurations are not preserved.
• etc_copy - the script erases both the provisional /etc and provisional /var directories, then it copies the contents of /etc and the non-volatile information from the directory /var/nvdata to the provisional Flash partitions. In this case, both the non-volatile data and the Shelf Manager configuration file are preserved.
• copy - the script erases both the provisional /etc and provisional /var directories, then copies the full contents of the /etc and /var directories onto the provisional partition. In this case, not only the configuration, but also the executable files placed to /var/bin will be copied and will override executable files with the same name from the RFS image. This mode of operation is useful if the directory /var/bin contains some special executable files (for example, a special version of the Shelf Manager or other utilities) that must be preserved across the upgrade.

The script returns 0 on success and a non-zero value for failure. If a non-zero value is returned, the upgrade procedure is terminated.

The utility starts the upgrade WDT with a 12.8-second time-out period. This time-out period is considered sufficient for any software that will boot after the reset to proceed to the point where it is able to call rupgrade_tool -c (which strobes the upgrade WDT in case it is active) without having to strobe the upgrade WDT in the interim. The utility performs a strobe of the upgrade WDT just before resetting the ShMM.

• -c [-v]

Proceed with the reliable upgrade procedure after the ShMM is booted from the provisional Flash. The invocation of rupgrade_tool -c is done from the /etc/rc script. As described below, certain situations discovered by rupgrade_tool -c imply a failure in the upgrade procedure and require corrective actions, including those resulting in the need to soft reset the ShMM. This means that an invocation of rupgrade_tool -c may not return and instead may result in reset of the ShMM. If a reset takes place, it reverts the ShMM to the software installed in the persistent Flash.

If the upgrade WDT is active and has fired at any step prior to invocation of rupgrade -c, this means that the ShMM already reverted to the software in the persistent Flash. In this scenario, the utility disables the upgrade WDT and returns to the use of persistent Flash and terminates the upgrade procedure.

If the upgrade WDT is active but has not fired, this means that the ShMM successfully booted (up to this point) from the provisional Flash. The utility strobes the upgrade WDT and exits with the return code of 0, indicating that there is an upgrade procedure session in progress.

If the upgrade WDT is not active but the content of the /var/upgrade/status file indicates that the upgrade procedure is still in progress, this means that the ShMM rebooted due to a power-cycle at one of the steps of the upgrade procedure. In this scenario the utility performs the same corrective actions as for the situation when the upgrade WDT is active and has fired.

Finally, if the upgrade WDT is not active and /var/upgrade/status is either not present or indicates that the upgrade procedure has finished (either successfully or unsuccessfully), the utility exits with the return value of 1, indicating that there is no upgrade procedure in progress.

• -f [--hook=args] [-v]

Complete the upgrade procedure. The invocation of rupgrade_tool -f is done from inside the Shelf Manager after the Shelf Manager successfully completes its initialization. If the Shelf Manager is not started automatically, that invocation is done at the end of the /etc/rc script.

As soon as it is invoked, rupgrade_tool -f strobes the upgrade WDT and proceeds with establishing the new persistent Flash and disabling the upgrade WDT.

Before completion, the utility updates /var/upgrade/status with a record indicating a successful completion of the upgrade procedure then exits with a value of 0.

• -w [-f]

Print the current status of the most recent upgrade procedure. Essentially, this option dumps the content of the /var/upgrade/status file to stdout.

rupgrade_tool -w returns a value of 0 if the upgrade procedure has completed successfully, 1 if the upgrade procedure was unsuccessful, and an error code if there is no /var/upgrade/status.

If the -f specifier is supplied, rupgrade_tool -w removes the /var/upgrade/status file before exiting.

• -S [-v]

Strobe the upgrade WDT. rupgrade_tool -S is intended as a shell-level interface for use by newly installed software that is validating its sanity.

rupgrade_tool -S returns a value of 0.

• -u

Undo a successful upgrade session, reverting to the previous persistent Flash device.

rupgrade_tool -u causes the ShMM to reboot.

• -h

Print help to stdout.

Reliable Upgrade Utility Use Scenarios

It is intended that the reliable upgrade utility will be used in the following sequence to carry out an upgrade of the ShMM:

1. The user makes a call to rupgrade_tool -s to initiate the upgrade procedure. The call can be made either locally from the ShMM serial console or remotely over the network via telnet, rsh, ssh, or any equivalent utility.

2. The user waits for rupgrade_tool -s to reboot the ShMM. If the user is connected to the serial console locally, the status of the reboot is obvious from the messages printed by the U-Boot firmware and Linux to the serial console. If the connection to the ShMM is remote, the status of the reboot is less obvious. For instance, a Telnet connection will time out on the reboot of the shelf management card. The user can either assume that the upgrade procedure has been carried out successfully or wait for a certain amount of time required for the upgrade session to complete and then make a call to rupgrade_tool -w (again, remotely, over any of the remote shell tools mentioned above) to find out the status of the upgrade session. The amount of time to wait depends on the size of the upgrade images and the copy protocol used to pull the images to the shelf management card as well as actions performed by the image validation script.

3. On the shelf management card, the startup script /etc/rc unconditionally makes a call to rupgrade_tool -c. If the call returns a value of 1, indicating that there is no upgrade in progress or an error code value indicating that the upgrade session has failed, the startup scripts proceed with the normal mode boot sequence. However, if a value of 0 is returned, indicating that there is an upgrade session in progress, the startup scripts proceed with validation of the sanity of the newly installed software, calling rupgrade_tool -S in the middle of the operation to strobe the upgrade WDT in case the validation takes longer than the upgrade WDT timeout period, and finally start the Shelf Manager to perform final validation. The watchdog timer interval is set to 12.8 seconds, so the processing times in the /etc/rc script between the call to rupgrade_tool -c and strobing the WDT and between strobing the WDT and starting the Shelf Manager must not exceed 12.8 seconds each.

4. During initialization, the Shelf Manager strobes the upgrade WDT once again, before trying to establish a network connection with the peer Shelf Manager. Establishing a network connection may take up to six seconds. After that, and after successfully finishing the initialization (which indicates validity of the new configuration), the Shelf Manager makes a call to rupgrade_tool -f, which completes the upgrade procedure.

5. The user optionally calls rupgrade_tool -w to find out the status of the upgrade session. As explained above, this option may be especially useful for a remote upgrade session where the progress of the upgrade cannot be observed directly from the messages printed to the serial console, as is the case for a local upgrade.

After the completion of the reliable upgrade, the user can revert to the original images if the new images are not acceptable for any reason. To do this, the user calls rupgrade_tool -u.

If necessary, the above sequence can be easily automated by developing a simple script designed to run on a remote network host. Alternatively, an operator can carry out the reliable upgrade manually, either locally from the serial console or remotely over the network.

Reliable Upgrade Examples

Example 1:

This example shows a reliable upgrade of all three components (U-Boot, kernel, and RFS image), copying /etc and /var/nvdata non-volatile directories to the provisional Flash. All images are taken from the local /tmp (which implies that they have already been copied there in some unspecified way). The U-boot image is taken from /tmp/u-boot.bin, the kernel image is taken from /tmp/sentry.kernel, and the RFS image is taken from /tmp/sentry.rfs. The upgrade procedure is started from the serial console. Comments are interspersed in the console log to provide additional background on the steps of the upgrade procedure.

First, rupgrade_tool is started from the command prompt. The parameters show that all three Flash images are to be updated, with the Shelf Manager non-volatile data and configuration file preserved as well.

# rupgrade_tool -s --k=sentry.kernel --r=sentry.rfs--u=u-boot.bin --hook=etc_copy -v
rupgrade_tool: PLB is 5
rupgrade_tool: EEPROM page saved
rupgrade_tool: persistent flash is 0
rupgrade_tool: provisional flash is 1
rupgrade_tool: copying image(s)

The upgrade utility attempts to invoke a validation script to check the images in /tmp currently supplied. If any of the specified file designators is not found in /tmp, the utility stops and a message like the following is produced.

rupgrade_tool: cannot open /tmp/u-boot.bin for reading.
rupgrade_tool: failed to copy images to flash

The utility proceeds to copy the images to the specified destinations in provisional Flash.

rupgrade_tool: invoking scripts (step4v*) [--u=u-boot.bin --k=sentry.kernel --r=sentry.rfs --hook=etc_copy]
rupgrade_tool: copying u-boot.bin from /tmp to /dev/mtdchar8 using 'cp' protocol
rupgrade_tool: copying sentry.kernel from /tmp to /dev/mtdchar7 using 'cp' protocol
rupgrade_tool: copying sentry.rfs from /tmp to /dev/mtdchar9 using 'cp' protocol
rupgrade_tool: invoking scripts (step4h*) [etc_copy]

At this point, the step4hshm hook script is invoked; it stops the Shelf Manager and copies non-volatile information to the provisional Flash.

/etc/upgrade/step4hshm: Stopping Shelf Manager...
/etc/upgrade/step4hshm: Erasing /var and /etc, copying /var/nvdata...
/etc/upgrade/step4hshm: Operation: copy /etc and /var/nvdata.
/etc/upgrade/step4hshm: Copying completed.
rupgrade_tool: image(s) copy OK
rupgrade_tool: watchdog started
rupgrade_tool: selected provisional flash
rupgrade_tool: reboot
Restarting system.

Here, the reliable upgrade procedure resets the ShMM. This causes U-boot to start from the provisional Flash.

* Resetting Integrated Peripherals
 
U-Boot 1.1.2 (May 12 2005 - 21:27:13)
 
CPU: Au1550 324 MHz, id: 0x02, rev: 0x00
Board: ShMM-500
S/N: 8000044
DRAM:  128 MB
Flash: 64 MB
In:    serial
Out:   serial
Err:   serial
Net:   Au1X00 ETHERNET
Hit any key to stop autoboot:  0 
## Booting image at bfb00000 ...
   Image Name:   MIPS Linux-2.4.26
   Created:      2005-06-24  13:29:50 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    844843 Bytes = 825 kB
   Load Address: 80100000
   Entry Point:  802bc040
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading Ramdisk Image at bfc40000 ...
   Image Name:   sentry RFS Ramdisk Image
   Created:      2005-04-22   9:10:41 UTC
   Image Type:   MIPS Linux RAMDisk Image (gzip compressed)
   Data Size:    2465924 Bytes =  2.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
 
Starting kernel ...
 
init started:  BusyBox v0.60.5 (2005.06.15-14:45+0000) multi-call binary
/etc/rc: Mounted /proc
/etc/rc: Mounting filesystems...
/etc/rc: Mounted /dev/pts
/etc/rc: Mounted /dev/mtdblock0 to /var
/etc/rc: Mounted /dev/mtdblock10 to /var/upgrade

At this point, the rc script invokes rupgrade_tool -c to check if a reliable upgrade is in progress. The tool returns 0, confirming that an upgrade is in progress. Given that result, the rc script continues with the startup process.

/etc/rc: Checking the reliable upgrade watchdog timer
/etc/rc: Mounted ram disk to /var/log
/etc/rc: Started syslogd and klogd
/etc/rc: Mounted ram disk to /var/tmp
/etc/rc: Setting hostname shmm+193

Since a reliable upgrade is in progress, the watchdog timer is strobed once more in the rc script.

/etc/rc: Strobing the reliable upgrade watchdog timer
/etc/rc: Mounted /dev/mtdblock1 to /etc
/etc/rc: Calling /etc/rc.carrier3
Board Hardware Address: 0xFE
/etc/netconfig: /etc/hosts has valid  192.168.1.193 entry
/etc/netconfig: Updating /etc/profile.sentry with IP settings
/etc/netconfig: ifconfig eth0 192.168.1.193
/etc/netconfig: ifconfig eth1 192.168.0.193
/etc/netconfig: route add default gw 192.168.1.253
/etc/netconfig: Starting inetd...
/etc/rc.carrier3: Starting up IPMBs ...
/etc/rc.carrier3: Updating /etc/profile.sentry with specific settings
/etc/rc.carrier3: Starting snmpd...
/etc/rc.carrier3: Starting httpd...
/etc/rc.carrier3: Starting Shelf Manager ...
<I> 02:48:08.463   [171] Pigeon Point Shelf Manager ver. 2.0.0. Built on Jun 27 2005 14:48:57
<*> 02:48:08.469   [171] Limits: code=(400000:506f0), end_data=10062000, start_stack=7fff7e30, esp=7fff78a0, eip=6F or 2A (Sun legacy)b0d2e4
<*> 02:48:08.469   [171] Stack limits: curr=1ff000, max=7fffffff
<*> 02:48:08.470   [171] Data limits: curr=7fffffff, max=7fffffff
<*> 02:48:08.900   [171] *** Lock log print buffer at 1003b7f0 ***
<*> 02:48:08.900   [171] *** Pthread lock log print buffer at 1003f820 ***

The Shelf Manager starts and finalizes the reliable upgrade by executing rupgrade_tool -f.

eth0: link up
eth1: link up
eth1: going to full duplex
 
shmm+193 login:root
 
BusyBox v0.60.5 (2005.05.12-22:46+0000) Built-in shell (msh)

The user then checks the status of the reliable upgrade by issuing the rupgrade_tool -w command.

# rupgrade_tool -w
Recent upgrade status:
1:PLB is 5
1:EEPROM page saved
2:persistent flash is 1
3:provisional flash is 0
4:copying image(s)
4:invoking scripts (step4v*) [--u=u-boot.bin --k=sentry.kernel --r=sentry.rfs  --hook=etc_copy]
4:copying u-boot.bin from /tmp to /dev/mtdchar8 using 'cp' protocol
4:copying sentry.kernel from /tmp to /dev/mtdchar7 using 'cp' protocol
4:copying sentry.rfs from /tmp to /dev/mtdchar9 using 'cp' protocol
4:invoking scripts (step4h*) [etc_copy]
4:image(s) copy OK
5:watchdog started
6:selected provisional flash
7:reboot
9:WDT not fired, upgrade in progress.
11:provisional flash 0, updating EEPROM
12:EEPROM updated
13:upgrade WDT disabled
13:invoking scripts (step13h*) []
14:upgrade completed successfully
#

Example 2:

This example shows a reliable upgrade of the RFS image only, copying /etc and /var/nvdata non-volatile directories to provisional Flash. The RFS image is taken from an FTP server at the IP address 192.168.1.253. The path to the RFS image on the FTP server is /tftpboot/ru-mips/sentry.mips.rfs. The upgrade procedure is started from a Telnet session.

The local system must have access to the FTP server over the network (that is, its network adapter must be up and configured and a route must exist from the ShMM to the FTP server). In the example, the ShMM is configured with the network address 192.168.1.174 (which is in the same network with the FTP server):

# telnet 192.168.1.174
Trying 192.168.1.174...
Connected to 192.168.1.174.
Escape character is '^]'.
 
BusyBox on shmm+174 login: root
 
 
BusyBox v0.60.5 (2005.05.07-17:27+0000) Built-in shell (msh)

The parameters to rupgrade_tool -s indicate that only the RFS is being upgraded and that the copy protocol is FTP, accessing a specified IP address and file, with user admin and no password supplied.

# rupgrade_tool -s --r=sentry.mips.rfs 
--proto=ftp:192.168.1.253:/tftpboot/ru-mips:admin --hook=etc_copy -v
rupgrade_tool: PLB is 5
rupgrade_tool: EEPROM page saved
rupgrade_tool: persistent flash is 1
rupgrade_tool: provisional flash is 0
rupgrade_tool: copying image(s)
rupgrade_tool: copying sentry.rfs from 192.168.1.253:/tftpboot/ru-mips:admin to /tmp using 'ftp' protocol
220 hydra FTP server (Version wu-2.4.2-academ[BETA-17](1) Tue Jun 9 10:43:14 EDT 1998) ready.
USER admin

The user is asked for a password to the FTP site; that password is entered manually.

331 Password required for admin.
Password:xxxx
PASS *****
230 User admin logged in.
TYPE I
200 Type set to I.
PASV
227 Entering Passive Mode (192,168,1,253,9,20)
RETR /tftpboot/ru-mips/sentry.mips.rfs
150 Opening BINARY mode data connection for /tftpboot/ru-mips/sentry.mips.rfs (2465988 bytes).
226 Transfer complete.
QUIT
221 Goodbye.

In the next step, a special script step4vshm is invoked, that copies the U-Boot and kernel images from the persistent Flash to the provisional Flash, After that, the upgrade utility proceeds to copy the RFS image to its designated position in provisional Flash.

rupgrade_tool: invoking scripts (step4v*) [--r=sentry.mips.rfs --proto=ftp:192.168.1.253:/tftpboot/ru-mips:admin --hook=etc_copy]
/etc/upgrade/step4vshm: Erasing /dev/mtdchar7...Done
etc/upgrade/step4vshm: Copying Kernel from /dev/mtdchar2 to /dev/mtdchar7...Done
/etc/upgrade/step4vshm: Erasing /dev/mtdchar8...Done
/etc/upgrade/step4vshm: Copying U-Boot from /dev/mtdchar3 to /dev/mtdchar8...Done
rupgrade_tool: copying sentry.mips.rfs from /tmp to /dev/mtdchar9 using ’cp’ protocol

The step4hshm hook script is invoked, which stops the Shelf Manager and preserves the non-volatile data. The utility then starts the upgrade WDT and reboots.

rupgrade_tool: invoking scripts (step4h*) [etc_copy]
/etc/upgrade/step4hshm: Stopping Shelf Manager...
/etc/upgrade/step4hshm: Erasing /var and /etc, copying /var/nvdata..
/etc/upgrade/step4hshm: Operation: copy /etc and /var/nvdata.
/etc/upgrade/step4hshm: Copying completed.
rupgrade_tool: image(s) copy OK
rupgrade_tool: watchdog started
rupgrade_tool: selected provisional flash
rupgrade_tool: reboot
Restarting system.
Connection closed by foreign host.

At this point, the Telnet session is closed after a certain inactivity period; after several seconds, it is possible to reconnect to the target again and check the status of the reliable upgrade, by invoking rupgrade_tool -w.

# telnet 192.168.1.174
Trying 192.168.1.174...
Connected to 192.168.1.174.
Escape character is '^]'.
 
BusyBox on shmm+174 login: root
 
BusyBox v0.60.5 (2005.05.07-17:27+0000) Built-in shell (msh)
# 
# rupgrade_tool -w
Recent upgrade status:
1:PLB is 5
1:EEPROM page saved
2:persistent flash is 1
3:provisional flash is 0
4:copying image(s)
4:copying sentry.mips.rfs from 192.168.1.253:/tftpboot/ru-mips:admin to /tmp using 'ftp' protocol
4:invoking scripts (step4v*) [--r=sentry. rfs --hook=etc_copy]
4:copying sentry.mips.rfs from /tmp to /dev/mtdchar9 using 'cp' protocol
4:invoking scripts (step4h*) [etc_copy]
4:image(s) copy OK
5:watchdog started
6:selected provisional flash
7:reboot
9:WDT not fired, upgrade in progress.
11:provisional flash 0, updating EEPROM
12:EEPROM updated
13:upgrade WDT disabled
13:invoking scripts (step13h*) []
14:upgrade completed successfully
#

Example 3:

This example shows an unsuccessful reliable upgrade. Power is turned off after the boot from the provisional Flash, but before the reliable upgrade is finalized. After turning the power back on, the rollback to the persistent Flash occurs. This reliable upgrade is initiated from the serial console. All three images are assumed to be already in /tmp.

# rupgrade_tool -s --k=sentry.kernel --r=sentry.rfs --u=u-boot.bin --hook=etc_copy -v
rupgrade_tool: PLB is 5
rupgrade_tool: EEPROM page saved
rupgrade_tool: persistent flash is 0
rupgrade_tool: provisional flash is 1
rupgrade_tool: copying image(s)
rupgrade_tool: invoking scripts (step4v*) [--u=u-boot.bin --k=sentry.kernel --r=sentry.rfs --hook=etc_copy]
rupgrade_tool: copying u-boot.bin from /tmp to /dev/mtdchar8 using 'cp' protocol
rupgrade_tool: copying sentry.kernel from /tmp to /dev/mtdchar7 using 'cp' protocol
rupgrade_tool: copying sentry.rfs from /tmp to /dev/mtdchar9 using 'cp' protocol
rupgrade_tool: invoking scripts (step4h*) [etc_copy]
Stopping Shelf Manager...
 
Pigeon Point Shelf Manager Command Line Interpreter
 
Terminating the 
Erasing /var and /etc, copying /var/nvdata...
Operation: copy /etc and /var/nvdata.
Copying completed.
rupgrade_tool: image(s) copy OK
rupgrade_tool: watchdog started
rupgrade_tool: selected provisional flash
rupgrade_tool: reboot
Restarting system.

The reliable upgrade procedure resets the ShMM here and starts U-boot from the provisional Flash.

** Resetting Integrated Peripherals
 
 
U-Boot 1.1.2 (Nov 11 2005 - 15:16:25)
 
CPU: Au1550 324 MHz, id: 0x02, rev: 0x00
Board: ShMM-500
S/N: 8000044
DRAM:  128 MB
Flash: 64 MB
In:    serial
Out:   serial
Err:   serial
Net:   Au1X00 ETHERNET
Hit any key to stop autoboot:  0 
## Booting image at bfb00000 ...
   Image Name:   MIPS Linux-2.4.26
   Created:      2005-04-11  10:35:08 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    843129 Bytes = 823.4 kB
   Load Address: 80100000
   Entry Point:  802bc040
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading Ramdisk Image at bfc40000 ...
   Image Name:   sentry RFS Ramdisk Image
   Created:      2005-04-22   9:10:41 UTC
   Image Type:   MIPS Linux RAMDisk Image (gzip compressed)
   Data Size:    2400736 Bytes =  2.3 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

Power is turned off here. After some time, power is turned back on. Assignment of provisional Flash has been lost because of the power loss, so the system reverts back to the persistent Flash.

U-Boot 1.1.2 (Nov 11 2005 - 15:16:25)
 
CPU: Au1550 324 MHz, id: 0x02, rev: 0x00
Board: ShMM-500
S/N: 8000048
DRAM:  128 MB
Flash: 64 MB
In:    serial
Out:   serial
Err:   serial
Net:   Au1X00 ETHERNET
Hit any key to stop autoboot:  0 
## Booting image at bfb00000 ...
   Image Name:   MIPS Linux-2.4.26
   Created:      2005-04-11  10:35:08 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    843129 Bytes = 823.4 kB
   Load Address: 80100000
   Entry Point:  802bc040
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading Ramdisk Image at bfc40000 ...
   Image Name:   sentry RFS Ramdisk Image
   Created:      2005-04-11  18:27:17 UTC
   Image Type:   MIPS Linux RAMDisk Image (gzip compressed)
   Data Size:    2372311 Bytes =  2.3 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
 
Starting kernel ...
 
init started:  BusyBox v0.60.5 (2005.02.07-16:45+0000) multi-call binary
hub.c: new USB device AU1550-1, assigned address 2
usb0: ? speed config #1: Ethernet Gadget
usb1: register usbnet usb-AU1550-1, Linux Device
serial#=8000048: not found
/etc/rc: Mounted /proc
/etc/rc: Mounting filesystems...
/etc/rc: Mounted /dev/pts
/etc/rc: Mounted /dev/mtdblock0 to /var
/etc/rc: Mounted /dev/mtdblock10 to /var/upgrade
 

The next step in the rc script is to call rupgrade_tool -c to check whether a reliable upgrade is in progress. The check determines that an attempted reliable upgrade failed. The message restoring ADM1060 EEPROM to RAM refers to the ShMM system supervisory device (an ADM1060), which supervises the ShMM boot process and implements some of the hardware aspects of the reliable upgrade support. This message indicates that key variables affecting the boot process are being restored to their state before the reliable upgrade was attempted.

/etc/rc: Checking the reliable upgrade watchdog timer
rupgrade_tool: Watchdog not active.
rupgrade_tool: restoring ADM1060 EEPROM to RAM
rupgrade_tool: upgrade failed
/etc/rc: Rupgrade -c Ret: 255
/etc/rc: Mounted ram disk to /var/log
/etc/rc: Started syslogd and klogd
/etc/rc: Mounted ram disk to /var/tmp
/etc/rc: Setting hostname shmm+173
/etc/rc: Mounted /dev/mtdblock1 to /etc
/etc/rc: Calling /etc/rc.carrier3
Board Hardware Address: 0xFE
/etc/netconfig: /etc/hosts has valid  192.168.1.173 entry
/etc/netconfig: Updating /etc/profile.sentry with IP settings
/etc/netconfig: Starting inetd...
/etc/rc.carrier3: Starting up IPMBs ...
/etc/rc.carrier3: Updating /etc/profile.sentry with specific settings
/etc/rc.carrier3: RC2 daemons not started by request

---

Connecting to a Node Board Console

The Shelf Manager provides the capability to connect to node boards and open console sessions from the active shelf management card (ShMM). This feature is often referred to as NetConsole. You begin by logging in to the active ShMM through the Ethernet port. Use of the ShMM’s serial port is not recommended for this function.

Once a console session with a node board is established, you can run system administration commands, such as passwd, read status and error messages, or halt the board in that particular slot.

Establishing Console Sessions Between the Shelf Manager and Node Boards

Once you have configured your system for console use, you can log in to the active ShMM and open a console for a slot. The Sun Netra CT system allows one console session per node board slot. TABLE 3-6 shows the Shelf Manager CLI console-related commands that can be executed from the current login session on the shelf management card.

1. Log in to the ShMM.

You can log in to the ShMM through a terminal attached to either the serial port connection on the SAP or the Ethernet port connection.

2. Check to see if the ShMM is the active ShMM.

Once you are logged in, use the clia shmstatus command to verify that you are logged onto the active ShMM before continuing. If you are logged onto the standby ShMM, either connect to the other serial port on the SAP or use the clia switchover command to change the ShMM to Active. (See shmstatus and switchover in Shelf Manager CLI Commands for more information.)

3. Open a console session to a node board.

 # clia console slot-number

where slot-number is 1 -6 and 9 -14. For example, to open a console to the board in slot 4, enter the following:

# clia console 4

You now have access to the node board in slot 4. Depending on the state of the board in that particular slot, and whether the previous user logged out of the shell, you see one of several prompts:

• console login% (Oracle Solaris level)
• # (Oracle Solaris level, previous user logged in as superuser, and did not log out before disconnecting from the console)
• ok (OpenBoot PROM level)
• # (Monta Vista Linux)

1. (Optional) Log out of the OS shell.

2. At the prompt, disconnect from the console by entering the escape sequence ~q or ~. (tilde period):

prompt ~q

Disconnecting from the console does not automatically log you out from the remote host. Unless you log out from the remote host, the next console user who connects to that board sees the shell prompt of your previous session.

Changing Console Escape Character

Normally the ~. or ~q escape sequences are used to disconnect a console session. The tilda (~) is the default console escape character. The escape character can be modified by changing the value of the Escape_Char variable in the /etc/netconsole.conf file. For example, Escape_Char=”#” changes the escape character to the pound sign (#) and the console disconnect escape sequences to #. or #q. All active console sessions must be restarted to implement the change.

The escape character will default to ~ if the Escape_Char variable is missing or undefined.

Displaying Board’s User Label During Console Session

Administrators can assign names (or user labels) to the shelf and to slots using the ShMM CLI setuserlabel command (see setuserlabel and userlabel). User labels are displayed as shelf-name:slot-name.

During a console session, the user can display the user label for the session by typing the escape character and ? or L. Using the default escape character ~ (tilde), the escape sequence would be ~? or ~L.

For example:

# clia console 6
console login
. . . . . . . . . . . . . .
# ~?
Connected to "ATCA02:CP3020-06" console.
#

---

Manual Graceful Shutdown of Node Boards

For Sun Netra CP3010, CP3020, and CP3060 node boards, a manual graceful shutdown procedure is provided to prevent the accidental removal of a node boards or FRUs. Graceful shutdown means to quiesce (shut down) all the applications and OS running on the node board’s payload, and the payload itself in a non-abrupt manner.

Before hot-swapping or removing a one of these Sun Netra node boards, the applications and operating system running on the node board should be gracefully shut down. Using the Shelf Manager’s NetConsole feature, the system administrator can start a console session on the node board and perform a graceful shutdown according to the site’s shutdown procedures.

Once the shutdown is complete, the system administrator enables deactivation of the FRU (or node board) and opens the hot-swap latch on the board. After the node board is replaced or reinstalled, the administrator disables deactivation of the FRU (or node board) to prevent an ungraceful shutdown when the hot-swap latch is open.

The steps involved in this process are detailed in the following procedures.

This procedure requires that the hot-swap latch on the node board be closed.

1. Log in to the active ShMM.

2. Start a console session to the node board.

See To Start a Console Session From the Shelf Manager.

3. Shut down the application and operating system on the node board.

Follow the graceful shutdown procedures for your site. When the shutdown is complete, close the console session (see To End the Console Session).

4. Enable the shelf manager controlled deactivation on the node board using the following Shelf Manager CLI command.

# clia shelf deactivation hardware-addr fru-id 0

For example:

# clia shelf deactivation 0x41 0xfe 0
Pigeon Point Shelf Manager Command Line Interpreter
 
Updating Shelf FRU Info, address: 0x41, FRU ID # 254
    Cached information updated
    Wrote Information to the Shelf FRU
# 

5. Verify that the shelf manager controlled deactivation is enabled using the following Shelf Manager CLI command.

# clia shelf pm

Look for the Shelf Manager Controlled Deactivation: Enabled message.

For example:

# clia shelf pm
Pigeon Point Shelf Manager Command Line Interpreter
 
PICMG Shelf Activation And Power Management Record (ID=0x12)
        Version = 1
    Allowance for FRU Activation Readiness: 10 seconds
    FRU Activation and Power Description Count: 16
    Hw Address: 41, FRU ID: 0xfe, Maximum FRU Power Capabilities: 150 Watts
        Shelf Manager Controlled Activation: Enabled
        Shelf Manager Controlled Deactivation: Enabled
        Delay Before Next Power On: 0.0 seconds

6. Open the hot-swap latch on the node board.

7. When the node board blue hot-swap LED is on steady, remove or replace the node board.

Caution - Always wear a grounded antistatic wrist strap when handling modules.

8. When the node board is replaced or reinstalled, disable the shelf manager controlled deactivation on the node board using the following Shelf Manager CLI command.

# clia shelf deactivation hardware-addr fru-id 1

For example:

# clia shelf deactivation 0x41 0xfe 1
Pigeon Point Shelf Manager Command Line Interpreter
 
Updating Shelf FRU Info, address: 0x41, FRU ID # 254
    Cached information updated
    Wrote Information to the Shelf FRU
# 

Sun Netra CT900 Server Administration and Reference Manual

819-1177-18

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.