The CH1 comes from the factory pre-configured with two ethernet ports, one 10/100/1000 Base-T connection and one 1000 Base-X connection. Both ports will provide the same capabilities. The interfaces have static IP addresses of 192.168.1.19 for the Base-T connection and 192.168.1.20 for the 1000Base-X connection. The user can change these IP addresses to fit their network requirements.

The USB UART can be used to connect to either the operator’s console or the ChMC console. The UART exposes four USB interfaces- the operator’s console can be accessed by connecting to “Silicon Labs Quad CP2108 USB to UART Bridge: Interface 1”. The ChMC console can be accessed by connecting to “Silicon Labs Quad CP2108 USB to UART Bridge: Interface 2”. Interface 0 is for debug purposes and can be ignored. Interface 3 is not populated. This connection uses Silicon Labs CP210x USB to UART Bridge Virtual COM Port (VCP) drivers. Contact the factory if assistance is required in finding and installing these drivers.

Connect to the Operator’s Console using the “CHM CONSOLE RX” and “CHM CONSOLE TX” lines and connect to a remote computer running a terminal program like TeraTerm or Putty.

The System Management Interface (SMI) operates over an Ethernet connection using Remote Management Console Protocol (RMCP) as defined in the Intelligent Platform Management Interface Specification v1.5. For an Out-of-Band Chassis Management system, the Base-T Ethernet connection on the CH1 can be routed outside the chassis/card to an external Local Area Network (LAN). This allows System Management Software (SMS) to access the CH1 from a remote computer. In an In-Band system, the 1000 Base-X connection is located on the 68G6 host card and can be routed across the backplane to an SBC running system management software.

Please contact the factory if the intention is to align with SOSA objectives. REST APIs must be used when interfacing with the SMI in this case and NAI can include the required software running on the chassis manager.

Operator’s Console The operator’s console can be accessed through a linux shell being run on the module. From the factory, the default Linux username for the CH1 is: “root” with no password. Once logged in, the operator’s console is communicated with through a virtual terminal that can be launched with command “sudo conspy 10”. For human interaction, the console size can be adjusted with command “sudo stty -F /dev/tty10 columns x rows y”

Refer to the Operator’s Console section of this manual for more details about the various commands that are available.

The CH1 also provides a command line interface to the controller that runs the chassis manager, primarily for debug purposes. Refer to Appendix B: Command Line Interface for more details. The terminal should be set to 115,200 Baud, with local echo enabled, a transmit delay of 150 ms/line, with flow control set to Xon/Xoff.

First is the 'physical' view of the chassis. This data set is typically created by the chassis/backplane vendor and stored in a physical Chassis FRU Information site/device within the chassis.

Often, this is an I2C-based Serial EEPROM located on the backplane and wired to a private I2C bus on the ChMC. In some cases, the Chassis FRU Information may be stored on the CH1; either as a file (chassis_fru_info_253.hex) in the ChM cache (/etc/ChM), or/and in non-volatile memory within the ChMC.

If no physical Chassis FRU Information is stored in the chassis when you first powered on, the CH1 will post an Error message to the operator’s console during its initialization process and default to an ‘unknown chassis’ data set. This data set populates the identification field with 'unknown' values and assumes that the backplane implements redundant, bussed IPMB topology with maximum operating frequency of 100 kHz. It assumes, un-managed or no cooling control and no chassis LED or special control signals. The address table is fully populated, (during discovery, all possible IPMB addresses are scanned); this will dramatically increase the time needed to complete the power-on discovery process. Once this initial discovery is completed, the user will have the option to edit and save Chassis FRU Information either in the ChM cache or any previously discovered physical storage locations. This will dramatically reduce start-up time.

A physical storage location for Chassis FRU Information is often identified with its own FRU ID number within the FRU Inventory and is associated with a 'FRU Info Site'. The ChM service on the CH1 keeps track of these locations and will automatically use them to store updates to the Chassis FRU Information for the physical view of the chassis/backplane.

The ChM service mirrors the physical view of the chassis/backplane at logical FRU ID 253 within the FRU Inventory. An operator, or SMS Software can read and write the FRU information at FRU ID 253 and then choose to discard it or commit that information either to the ChM cache (chassis_fru_info_253.hex), or one or more physical storage locations identified in the FRU Inventory. For details on writing Chassis FRU information, refer to [VITA] section 8.2 and Chassis Discovery section of this document.

The second data set is the 'product' view for your application. The product view is an 'overlay' of the physical view that represents 'how the chassis is being used'. This data set uses the same records/format as the physical view but resides in the ChM cache as a file (chassis_fru_info_254.hex).

The first time you power-up the CH1, it will populate this data set with a 'copy' of the physical Chassis FRU Information. If you do not commit (save) this view, it will be re-populated with the physical view each time the ChM service runs its discovery process. The product FRU Information is mirrored at FRU ID 254 within the FRU Inventory and can be read/written just the same as the physical view at FRU 253.

The product view typically has different manufacturer, part number, and serial number fields than the physical view. Often, it has a different IP Address record and an address table that contains a sub-set of the one in the physical view. The Fan Geography and IPMB records are usually identical across the two views.

Each time the CH1 starts-up, it first checks for physical Chassis FRU Information in the ChM cache. If it does not find chassis_fru_info_253.hex, it checks for physical Chassis FRU Information at the last known location. If it does not find physical Chassis FRU Information, it populates FRU ID 253 with the 'unknown chassis' data set as described previously.

If chassis_fru_info_253.hex is found, the ChM then checks for matching data at the last known physical storage location. If no previous location is cached, or the stored information matches the cached information, then the cached information is loaded into FRU ID 253. If the previous location is missing, or the cached information does not match the information stored externally, the ChM must conclude that the data has been moved to a new chassis. If the previous location is missing, the ChM will default to the 'unknown chassis' data set. If the storage location contains valid Chassis FRU Information, it will invalidate chassis_fru_info_253.hex and load the latest information into FRU ID 253 from the external storage location.

Then the ChM service checks to see if chassis_fru_info_254.hex is present in the cache. If it is, then the cached product data set is compared to the data set at FRU ID 253 to make sure that the product view is 'compatible' with the current physical view. If they are compatible, then the cached data is loaded into FRU ID 254; otherwise chassis_fru_info_254.hex is invalidated and FRU ID 254 gets a copy of the data in FRU ID 253.

Once the chassis discovery process is complete, an operator or SMS software can modify the physical Chassis FRU Information Records at FRU ID 253. A commit of FRU ID 253 will update the chassis_fru_info_253.hex file in the ChM cache, and, if present, any physical storage devices that have previously been associated with physical FRU Information. An operator may also copy the contents of FRU ID 253 to FRU ID 254, or explicitly save the physical view to any external FRU storage device that is present in the current FRU inventory.

An operator or SMS software can modify the product Chassis FRU Information Records at FRU ID 254. A commit (save) of FRU ID 254 will update the chassis_fru_info_254.hex file in the ChM cache. They may also copy the contents of FRU ID 254 to FRU ID 253 or explicitly save the product view to any external FRU storage device that is present in the current FRU inventory.

Refer to [VITA] section 8.2 and the associated IPMI command definitions and Appendix B: Command Line Interface for details on how to use these commands to modify, save, or remove Chassis FRU Information through the CH1.

This command displays identification, current state, and sensor readings of the ‘chassis’ (entity 0x17:00).

The identification fields (name, p/n, s/n) are from the product view Chassis FRU Information accessed at FRU 254 (refer to the FRU Information section). The ChM (20h) sensors are associated with the 'chassis' entity (0x17:00) and provide an 'aggregate view' of states within the Chassis Manager itself and the underlying FRUs throughout the chassis. Please refer to the Sensors sub-section under Chassis Control Signals.

This command displays identification, capabilities, and state of each physical site in the chassis based on the physical view Chassis FRU Information Records accessed at FRU 253 (refer to the FRU Information section). This view displays the default settings of a 'bare chassis' which will be used if no changes are made to them by the product view. It provides an overview of the basic configuration of the chassis, which can serve as a reference point for modifications.

This command displays identification, capabilities, and state of each physical site in the chassis based on the physical view Chassis FRU Information Records accessed at FRU 254 (refer to the FRU Information section).

Sites that contain active FRUs have an assigned FRU number, display the FRU name from its Management Controller Locator Record, and show the IPMB STATUS and FRU STATE for that FRU. Sites that are empty/not-managed display '---' for the FRU number as seen in Figure 6.

This command returns a summary of all active FRUs currently under management by the ChM.

This command displays System IPMB connectivity and supported capabilities for Chassis and each active FRU.

If the user does not add 'settings', this command returns the current state of the specified sensor (by number) within the target FRU. Instead of 'fru x', you can also specify the target FRU by address as described for the 'get fru x' command.

If the user does include 'settings', this command returns the sensor/event enables, and for threshold-based sensors the threshold and hysteresis settings as shown in Figure 7. This command operates in conjunction with the 'set fru x sensor settings' commands (refer to the Chassis Setup sub-section).

Threshold appear in the following order: low fault, critically low, low, high, critically high, high fault; and hysteresis is listed in order: going-low and going-high.

Displays a list of discovered Fan Trays, and for Active Fan Trays, each subsidiary fan, and its' current state: local, co-operative, override and both 'local' and 'remote' commanded speed (0-100%) and the resulting control setting.

If ChM supports control of the INHIBIT* signal, initiating this command will immediately assert the INHIBIT* signal. This action should cause the power supply unit to disable power to the payload voltages in the backplane to force an emergency shutdown of all payload cards. This is equivalent to receiving a Chassis Control[0] command over the SMI interface.

The payload command, when used without specifying an underlying FRU, is the same as receiving a Chassis Control command from SMS Software.

You can determine which of these commands a FRU will accept using the 'get fru x -d' command and looking at the FRU Control capabilities listed for the FRU.

This variant of the payload command can send an IPMI cold_reset (re-boot), or warm_reset (clear buffers and interfaces) to the IPMC on the targeted FRU.

In general, the internal files should not be accessed by the user. If these files are erased (using 'rm all') they will be automatically re-generated when the ChM service is re-started; however, any previous POH hours, changes to settings, and user added SDRs will be lost. The one exception is ChM_FRU_info.hex. If this file is deleted, it must be re-loaded using the 'upload' command (see below) or you will get a discovery time warning that the ChM FRU information is missing, and the FRU Info AREA for FRU 0 will be null.

External files include:

The user may choose to remove previous log files using the 'rm logs' command. This command removes all the log files (including the active log). The SEL receiving its next event initiates the creation of a new log.

This command allows the user to remove cached FRU information for a specific FRU or Site, or to flush all of the stored FRU information from the cache.

This command will remove the chassis_fru_info_253.hex file from the cache. This will cause the ChM to search for physical Chassis FRU Information device(s) during discovery. The ChM will issue an error message and defer to the chassis_fru_info_254.hex (see below) if no device is found. As an alternative to storing the physical Chassis FRU Information in the ChMC or an EEPROM on the backplane or Chassis Info Site, the user can upload a backplane.hex file into the cache (see upload command) or enter basic Chassis FRU Information using console commands and save it to chassis_fru_info_253.hex (see Chassis Setup section).

The command will remove the chassis_fru_info_254.hex file from the cache. This will cause the ChM to issue a warning message and defer to the chassis_fru_info_253.hex (see Chassis Discovery section). To create/update a chassis_fru_info_254.hex file, the user can create the file externally and upload it into the cache or enter basic Chassis FRU Information using console commands and save it to chassis_fru_info_254.hex (see below).

The first step is to manually update the physical (backplane) Chassis FRU Information to reflect the true capabilities of the chassis using the commands described below:

>set ( backplane | generic ) type N

Generally, the correct type code for a desktop development chassis is 3. For other options refer to Table 16 in the System Management BIOS (SMBIOS) Reference Specification Version 2.7.1.

>set ( backplane | generic ) name <string>

Provides a descriptive name.

>set ( backplane | generic ) part <string>

Provide an ASCII string up to thirty-two (32) characters in length with the orderable part number for the generic chassis.

>set ( backplane | generic ) snum <string>

Provide an ASCII string up to thirty-two (32) characters in length with the serial number for this chassis.

>set ( backplane | generic ) ipmb { a | r } { 100 | 400 }

The current CH1 release supports only 'bussed' System IPMB topologies. This command allows the user to tell the CH1 if the System IPMB implementation in the chassis is singular or redundant and whether the bus must operate at or below 100 kHz (default) or it can operate at up to 400 kHz.

>set ( backplane | generic ) { ip | net | gateway } n.n.n.n

The default IPv4 address, Network mask, or default Gateway addresses for the generic chassis (no chassis_fru_info_253.hex file present) can be set using this command where 'n' is a decimal value between 0 and 255 inclusive.

Using this command and saving the backplane info without a chassis_fru_info_253.hex file in the cache, will cause the CH1, during its next power-up sequence, to update these 'static' settings and restart its IP service within Linux. The System Management Interface (SMI) will then respond accordingly going forward.

>set ( chassis | app ) type N

Generally, the correct type code for a desktop development chassis is 3. For other options refer to Table 16 in the System Management BIOS (SMBIOS) Reference Specification Version 2.7.1.

>set ( chassis | app ) name <string>

Provides a descriptive name.

>set ( chassis | app ) part <string>

Provide an ASCII string up to thirty-two (32) characters in length with the orderable part number for the generic chassis.

>set ( chassis | app ) snum <string>

Provide an ASCII string up to thirty-two (32) characters in length with the serial number for this chassis.

>set ( chassis | app ) ipmb { a | r } { 100 | 400 }

The current CH1 release supports only ‘bussed’ System IPMB topologies. This command allows the user to tell the CH1 if the System IPMB implementation in the chassis is singular or redundant and whether the bus must operate at or below 100 kHz (default) or it can operate at up to 400 kHz.

>set ( chassis | app ) { ip | net | gateway } n.n.n.n

The default IPv4 address, Network mask, or default Gateway addresses for the generic chassis (no chassis_fru_info_253.hex file present) can be set using this command where 'n' is a decimal value between 0 and 255 inclusive.

Using this command and saving the backplane info without a chassis_fru_info_253.hex file in the cache, will cause the CH1, during its next power-up sequence, to update these 'static' settings and restart its IP service within Linux. The System Management Interface (SMI) will then respond accordingly going forward.

The last step is to update the physical Chassis Address Table to match the actual capabilities of the chassis. The default address table for an 'unknown chassis' contains every possible hardware address with mostly 'unknown' site type/number except ChMM, PSM, and PIC address ranges which are defined by VITA. During discovery, the polling of non-existent sites for potential FRUs can result in a lengthy delay. It also adversely effects the periodic FRU health polling routine with non-existent sites dramatically increasing the latency of the polling loop. It is necessary to optimize the address table in the backplane view so that it only contains sites that are physically present and 'may' have a card with an IPMC to represent it plugged in at some point.

>rm ( backplane | generic ) site all

This command allows the user to easily remove all the address table entries from the backplane view of the Chassis FRU Information.

>add ( backplane | generic ) site <hw_addr> <type> <number>

Use this command to add back only the hardware addresses that you want the ChMC to actively poll during its initial discovery and then within the health polling loop. For the backplane view, you should include all sites that are physically present.

The Hardware Address should take the form 0xAA where AA is the 7-bit I2C slave address that is associated with the physical site.

There are three methods for entering the Site Type: as a decimal number (0-99), as a HEX number in either NNh or 0xNN form, or as a string chosen from Table 6.

There are two methods for entering the Site Number: as a decimal number (0-99), or as a HEX number in either NNh or 0xNN form. Site numbers may be 'system relative' (0 - 191) or 'chassis relative' (192-255). Site numbers are assigned consecutively (starting with 1) for each site type. For example, a chassis with 6 PIC slots, with hardware addresses ranging from 0x41 to 0x47, the chassis relative site numbers assigned to them should be 0xC1-0xC7 (In this case relative to the Active Chassis Manager).

While it is not necessary to include 'subsidiary sites' in the Chassis Address Table, you may choose to do so. Especially in the chassis (logical) view, where it may be known that the PIC in a specific slot supports a subsidiary FMC site that is required to have an FMC card present, and you therefore want to include that subsidiary site in the health polling process. The Chassis Address Table must have consecutive entries representing the primary FRU site and its subsidiary site(s). The hardware address for both sites is the same. The first entry gets the primary site type (VPX front-loading card slot) while the second entry get the subsidiary site type (VPX FMC site). The subsidiary site(s) typically receive a 'device relative' site number starting with '0xC1' (in this case relative to the IPMC on the card in the primary site).

>rm ( backplane | generic ) site <hw_addr>

This command allows the user to remove all entries for a specific hardware address if any input errors have been made.

>set ( backplane | generic ) capability N

This command tells the ChM whether the implementation supports the extended capabilities listed in accompanying table. The setting is a single byte in HEX format (NNh or 0xNN). Each bit indicates support for a specific capability as indicated in the table.

>save ( backplane | generic ) { to cache (default) | to chassis | to eeprom | to [dev] }

Once all changes have been made, the Chassis FRU Information at FRU 253 can be saved as chassis_fru_info_253.hex in the ChM cache, copied into FRU 254 (to chassis), written into the FRU Information storage device(s) that has previously discovered to contain the physical Chassis FRU Information, and/or written into a specific FRU Information storage device (to [dev]).

Saving changes to FRU 253 does not immediately affect the current operating state of the ChM, but it may have an impact during the next time the ChM powers up (E.g., changes to the IPMB settings or Address Table may cause changes to the ChM behavior).

rm ( chassis | app ) site all

This command allows the user to easily remove all the address table entries from the chassis view of the Chassis FRU Information.

>add ( chassis | app ) site <hw_addr> <type> <number>

Use this command to add back only the hardware address that you want the ChMC to actively poll during its initial discovery and then within the health polling loop. See add ( backplane | generic } site for more details.

>rm ( chassis | app ) site <hw_addr>

This command allows the user to remove all entries for a specific hardware address if any input errors have been made.

>set ( chassis | app ) capability N

This command tells the ChM whether the implementation supports the extended capabilities listed in Table 7. The setting is a single byte in HEX format (NNh or 0xNN). Each bit indicates support for a specific capability as indicated in the table.

>set { chassis | app } { to cache (default) | to generic }

Once all changes have been made, the Chassis FRU Information at FRU 254 can be saved as chassis_fru_info_254.hex in the ChM cache, or copied into FRU 253 (to backplane).

Saving changes to FRU 254 does not immediately affect the current operating state of the ChM, but it may have an impact during the next time the ChM powers up (E.g., changes to the IPMB settings or Address Table may cause changes to the ChM behavior).

Manually updating the logical (chassis) Chassis FRU Information to reflect the capabilities of the chassis as it is being used is the next step.

One possibility is simply to 'save' the physical Chassis FRU Information (FRU 253) to the logical view using the 'save backplane to chassis' command, and then 'save chassis' to create the chassis_fru_info_254.hex file in the ChM cache. At this point, chassis_fru_info_253.hex and chassis_fru_info_254.hex are identical.

Often, however, the logical view (chassis) is updated using 'set chassis' with all of the same command options described previously for the backplane info to differentiate the 'integrated product' from the 'bare chassis'. SMS software will see the 'logical' view (FRU 254) of the Chassis FRU Information, while the physical Chassis Information (FRU 253) is preserved and can be used to detect when the CH1 is moved to a different chassis, or 'fall back' if the chassis is to be re-purposed for a new application.

>save population { to chassis (default) | to backplane }

Use this command to add entries to a blank Chassis Address Table (either view) for all physical sites currently containing active FRUs. The primary objective of this command is to update the logical Chassis Address Table with only currently used sites, thereby optimizing the ChM’s discovery and health polling for maximum performance. However, in case a new card is added to an unused slot, the logical chassis address table needs to be updated, or else the ChM may fail to discover the card. If the newly added card generates an event after the ChM has enabled its Event Receiver, then the ChM will detect it and add it to the health polling loop, regardless of the Chassis Address Table entries, but this can result in an unpredictable situation.

>add [dev] confirmation

This command functions to add an FRU Confirmation Record for a specific device into the chassisSDRs.hex file. Adding the record to the SDRs will cause the ChM, during chassis initialization, to verify key responses from the device against the information stored during record creation. An event message generates when any change occurs. The Platform Event Filter (PEF) can be set-up to take actions or send alert messages to the SMS software as needed.

>rm [dev] confirmation

This command allows the user to remove an FRU Confirmation Record for the specified device from the chassisSDRs.hex file. This will not immediately remove the record from the SDR Repository; but the record will no longer be loaded into the Repository once the ChM is reset or power-cycled.

The following commands enable the user to assert direct control of an individual fan (or all fans in a tray) for troubleshooting purposes.

>set fan speed [ L | N | H | M ]

The Cooling Management routines determine the fan speed setting (0-100%) for fans associated with a given FRU site based on thresholds asserted by the FRU_TEMPERATURE sensor for each FRU. One of four speed settings are applicable: low (L), nominal (N), high (H), max (M). Settings entered using this command are saved in non-volatile memory and apply to all fans in all fan trays.

This command sets the depth of the ChM’s SEL table (as a decimal value from 100 to 65534).

By using this command, the user can configure how the System Event Log (SEL) will be handled in the ChM. You can set the SEL to be cached or volatile and choose the action to take when the SEL table becomes full.

This command determines whether the SEL will honor or ignore the NVMRO control input.

This command sets the 'logging threshold' for the SEL. In most instances an application will log 'all' events; however, there may be times (especially while troubleshooting) it may be desirable to limit what goes into the log.

This command enables the creation a 'white list' (space-delineated string of device identifiers) that determines which origin(s) will be logged.

Ex: to log only events from three specific PICs, enter 'set SEL from 0x41 0x43 0x48'

This command enables the creation of a 'white list' (space-delineated string of device identifiers) that determines which sensor types will be logged.

Ex: to log only events from temperature sensors, enter 'set SEL type 1'

This command posts a flag to have the ChM erase the current SEL table (and file if cached). It does not remove timestamped log files from the cache (see >rm logs command).

This command enables or disables PEF operation.

This command enables or disables PEF events.

This command sets the ACTION-CTL parameters. Each parameter consists of one ASCII-HEX coded 'byte' with bit assignments as described in Table 8.

This command serves to disable delayed start-up of the PEF or set the delay time as a decimal integer from 0 to 255 in seconds (default 60 seconds). Enabling this function will cause the ChM to delay startup of the PEF for the specified period after a ChM Initialization. This mechanism allows time for SMS software or an operator to disable or re-configure the PEF after start-up of the ChM so that it is possible to recover if a fault or error in an EFT entry causes the ChM to continually power down or reset the chassis.

This command erases all the Event Filter Table entries so that a new set of Filters may be entered.

This command functions to update Event Filter #N (0-63). The Event Filter entry must be a 20-byte (40 characters) ASCII-HEX string. No error checking or validation is performed. For details on the Event Filter format and how it is used by the PEF, refer to [IPMI] section 17.

This command writes the current PEF settings and EFT entries to pef_settings.bin in the cache. During the initial power-up of the CH1, loading this file initializes the PEF settings.

When the ChMC initiates discovery on the System IPMB, it defaults to a transmission rate of 100 kHz in Standard Mode and performs its initial discovery on IPMB-A only. After discovery is complete and all IPMCs report support for Fast Mode and redundant IPMB, the ChMC enables IPMB-B and switches to Fast Mode (400 kHz).

Before discovery starts, you can use this command to set up the ChMC’s IPMB configuration. If you know that all devices support Fast Mode and redundant IPMB, you can configure the ChMC to perform discovery at the higher speed using both interfaces. Then, the ChMC enables these capabilities in each IPMC as they are discovered, rather than waiting until after the initial discovery process is complete.

The 'start-up delay' command allows the ChM to be configured with a delay before beginning the discovery process. This delay, specified by N as a decimal integer in seconds, is useful to ensure that all underlying IPMCs have completed booting and are ready for enumeration.

This command sets the interval that the ChM is observed between power-down and power-up when performing a 'power-cycle' of the chassis, with N representing the decimal integer in seconds.

This command allows the user to set the period for the health polling routine where N is a decimal integer in seconds. The ChM service utilizes a polling algorithm to collect information from multiple devices. The interval between polling cycles is determined by dividing the total polling time by the number of devices to poll, resulting in the sleep interval for each device in the loop.

The ChM supports several 'standard' signals that may be assigned to GPIO in the ChMC (see Table 9). This command allows you to tell the ChM which GPIO these signals are associated with so that the ChM can monitor and control them as needed. These settings are non-volatile.

This command overwrites the 16-bit device name in the ChM’s local cache of the Management Controller Locator Record (a device SDR) for the specified device. This will cause the ChM and SMS software to display this name in the FRU inventory rather that the underlying name found in the actual SDR read from the device. This setting persists until a change in the underlying device causes the ChM to refresh its cache for the affected device.

This command sends a command to the specified device to enable or disable its default FRU activation policy bit (non-volatile setting).

This command sends a command to the specified device to set its commanded deactivation policy bit (non-volatile setting).

This command displays the current settings (read from the device) for the specified sensor N as shown in Figure 8. For an example of settings for a threshold-based sensor, see Figure 7.

As highlighted in Figure 8, the sensor (#0 of type F0h = FRU State sensor) has scanning enabled (which allows it to be periodically updated), and event generation is enabled for the sensor. The sensor is set to generate an assertion event whenever it enters one of the six (6) enabled states (0,1,4,5,6,7).

This command sends an IPMI request to the target device to set the scan enable bit for the specified sensor. If a specific sensor number is not indicated, the command is applied to all sensors within the target device. This action is volatile.

This command sends an IPMI request to the target device to set the sensor event enable bit for the specified sensor. If a specific sensor number is not indicated, the command is sent to all sensors within the target device. This command does not change the event assertion/de-assertion masks, it affects a single control bit that controls event generation at the 'sensor' level. This action is volatile.

This command displays login credentials for all current user entries.

This command removes the specified login credentials from the user table.

This command adds the specified login credentials to the user table. Usernames and passwords may be up to sixteen (16) characters in length.

This command updates the password and optionally, the maximum privilege level, associated with the specified username.

This command will update the IPMB State settings for the target device. This action is 'volatile'; it only persists until the device is reset or power-cycled.

When this command is directed to the ChMC, it has a direct impact on the usage of the System IPMB for all IPMCs that are connected to it.

This command displays SDRs for the specified device from the ChM’s SDR Repository (cache). If the command does not indicate a specific device, ALL the SDRs are displayed.

This command enables debug messages associated with one of the 'level' described in Table 10. Setting debug levels is cumulative (multiple levels can be active at the same time). These settings are non-volatile.

This command sends the 'ctl-i' character (09h) on the serial IPMB-0 interface to signal an external device to put its interface into Basic Mode so that you can send IPMB messages to the device.

This command allows you to send a raw (hex) command to the target device. The NetFn code can be entered as a decimal or hex (0xNN or NNh) value, or using one of the abbreviations listed in Table 11. The CC byte is the 'command code' (hex) and DD bytes are the request data bytes as needed (hex).

Use this command to change the operational state of the ChM, either by emulating a 'fault condition' or causing the ChM to swap roles with a redundant ChM. When a redundant ChM is present, forcing a ChM into the stand-by role will cause them to re-negotiate for the active role.

Use this command to toggle the ChM’s health polling functionality on/off. This can be useful when testing messages on the System IPMB and monitoring responses without interruptions caused by the polling process.

Utilize this command to put the console into 'upload' mode so that you can send an ASCII coded file over the terminal that the ChM will write into its cache using the specified file name.

The command will timeout if it does not receive any file within thirty (30) seconds of initialization.

This command will gracefully terminate the ChM service. Linux will then automatically re-start the ChM service. In effect, this serves as a 'cold reset' or 're-boot' of the ChM software without having to login to the Linux terminal to stop/start the service or power-cycle the CH1 and re-boot Linux.

This displays a list of commands with a short description of each command (shown in Figure 9 above).

This command clears the terminal screen.

This command displays the operational state of FRU0 and any subsidiary FRUs and their sensors as shown in Figure 10. The information is updated once per second until the user begins to type another command, or any event message is printed to the console.

The first line of status information shows the software and firmware (FPGA fabric) versions that are currently loaded into the device followed by the time of day HH:MM:SS.

The second line of status information indicates whether Event Forwarding is enabled or disabled. The next group of lines identify the ChMC itself and an NVM that holds backplane information. The main output from the 'status' command is information on all of the included sensors. Sensors 00-08 are defined in VITA 46.11-2022 with Sensor 07 (Payload Mode) having different modes defined between SOSA and VITA. The CH1 is configured for SOSA. If a different configuration is desired, please contact the factory. Sensor 08 is not required by SOSA or VITA though is recommended. Detailed definitions of the sensors can be found in the VITA 46.11-2022 and the SOSA specifications.

The show FRUx command shows board and/or product FRU information for the card that is represented by the ChMC (the X may be omitted for FRU0). When FRU0 is a carrier that includes subsidiary FRU devices (FMC, XMC, etc…) the X determines which subsidiary device is accessed.

The payload on and payload off commands are equivalent in effect to sending a [VITA] FRU_activation command to activate or de-activate the payload connected to the ChMC. See previous sections for details on the power-up and power-down sequences related to FRU activation. The CH1 is configured to assert INHIBIT*_O to a payload off command.

The payload rst c and payload rst w commands are equivalent in effect to sending a [VITA] FRU_control cold reset or warm reset command respectively. The CH1 is configured to assert SYSRESET*_O in response to a payload rst command.

The payload test command is equivalent in effect to sending a [VITA] FRU_control diagnostic irq command. This command does not effect the CH1.

Similar to the payload commands above, the FRUx on, FRUx off, and FRUx rst allow you to activate, deactivate, or assert cold-reset to the specified subsidiary FRU independently of the base FRU (FRU0). The only FRU for the CH1 is the chassis itself.

The get_ipmb command displays the current state and statistics for each of the IPMB interfaces of the ChMC to help with troubleshooting IPMB communication issues. The display shows which I²C interfaces and address(es) are associated with each IPMB channel, and the rate at which it is operating. Figure 12 is an example output if no arguments are provided. If arguments are provided, then 'get ipmb c' returns the Chassis IPMB_0. The arguments 'p' and 'l' return Payload (IPMB_2) and Local (IPMB_3), respectively.

The states command displays the current logic states of various flags and signals within the ChMC as shown in Figure 13. This display may be useful for in-system troubleshooting.

For signals, a=asserted, d=de-asserted, z=high-impedance. If a signal is configured as active low (INV=L), then asserted means that this signal is low. If a signal is configured as active high (INV=H), then asserted means that the signal is high. For GPIO, the INV register shows whether the I/O pad is configured active- high or active-low.

The IPMCf register contains Self-Test results and stays valid for later evaluation. The IPMIf register contains the internal state of the ChMC. Both the IPMCf and IPMIf registers are defined in Appendix A.

The lower 8 bits of the hFLAGS register duplicate the lower bits of the IPMCf register. Additional faults may be mapped into the upper bits of this register, which then affect the FRU_HEALTH_SENSOR. Check the vendor documentation for your card to see if additional faults have been included.

The vFLAGS register may have up to 24 pGood inputs mapped into various bits. When the pGood input is asserted, the corresponding bit is cleared (i.e. '1' = fault). Check the vendor documentation for your card to see if/how the various pGood signals have been mapped.

The tFLAGS register shows the threshold states for up to 4 temperature sensors that may be mapped into the FRU_TEMPERATURE sensor. There are six thresholds associated with each sensor. They are mapped into the register as 6 consecutive bits with High_Fault, High_Critical, High, Low_Fault, Low_Critical, and Low from left to right. The thresholds for sensor 1 are mapped to bits[5:0], while the thresholds for sensor 4 are in bits [23:18].

This command displays the current number of entries and provides a HEX dump of the last N entries. Some interpretation of the results is also provided for some known sensor types.

The get uart command displays the UART baud rate settings.

The admin command starts the transition to admin mode, which is described in the next section.

The set password [password] command can be used to set a 16-character password to deter casual access to the admin commands. This password is stored in non-volatile memory and cannot be altered except by entering admin mode and then using the set password command, or complete erasure and re-programming of the SmartFusion2 device through JTAG (which requires both the Flash-Lock key and a 256-bit AES key).

Once a password is set, it must be included on the admin <password> command line in order to log-in to admin mode.

This command is used to set up the information shown in Figure 15 (above).

set (gpio, time, auto, dci, uart, db, nvmro, sysrst, led1, led2, pavail, gap, por_en_ipmbb, ga, )

get (time, uart)

clr (auto, wp, dci, nvmro, sysrst, led1, led2, pavail, gap, por_en_ipmbb, ga)

In Admin Mode the erase option is added to the SEL command. The option erases all the entries in the System Event Log.

This command can erase all of the SDRs, count them, or write them all to the screen in a HEX format.

This command is used to load or modify the results of IPMCgen to the ChMC.

The upload command is used to load configuration or FRU information files into the ChMC. These files may be generated from the [IPMCgen] tool. This command supports uploads to several partitions within the ChMC’s non-volatile memory. NVMRO must be de-asserted to use this command. Refer to 'How to Upload Configuration Files' in IPMCgen User Guide.

This command is equivalent to the [IPMI] warm_reset request. This action flushes all of the interface buffers and re-initialized the IPMB, I2C, SPI and serial interfaces. It will also clear FRU_VOLTAGE faults associated with attempting to activate the payload while payload power is not available (pAVAIL de- asserted) and reset the sensor event status of all sensors (cause them to re-send their current event state).

This command is equivalent to the [IPMI] cold_reset request or asserting the soft-reset input to the ChMC. It causes the software to completely re-start as if from power-up - EXCEPT that the time and test register values are not reset.

This command enables or disables additional diagnostic messages to the console output.

This command enables or disables the debug commands defined in the next section. Disabling them is useful because they can modify low level things that are often not desired.

This command exits Admin Mode. To renter a password may be required.

By default, the ChMC will power-up in run mode. If a card is on the bench or in a test fixture without valid VPX backplane inputs (SYSRESET*, NVMRO, GAP, GA…), the test mode can be used to give a user control of various control inputs using the set and clr commands. Test mode causes the ChMC software to look at a 'test register' instead of the actual input pads for some signals (see set/clr command). Once test mode is activated settings will persist even through 'reboot' until you power-cycle or use DEVRSTn to hard reset the ChMC. So, the typical use model is to put the ChMC into test mode, set/clr control signals to the desired states, and then REBOOT the ChMC so that it boots into test mode with the desired states present during the initialization process.

The peek/poke commands allow you to directly read and write 32-bit data from and to internal registers in the ChMC for testing and troubleshooting. For detailed information about the low-level registers within the ChMC please contact the factory.

The no_poll command is used to temporarily turn-off device descriptor and sensor polling so that you can read/write on the I2C interfaces and get/set GPIO states without battling the ChMC of the interfaces or having the ChMC over-write the 'state' that you are trying to induce.

This command performs a simple I2C write on the selected bus (N = 0-7) targeting the device specified by the 7-bit Slave Address (SA). The specified HEX bytes (there must be an even number of characters) are written from left to right.

This command performs an I2C read on the selected bus (N = 0-7) targeting the device specified by the 7- bit Slave Address (SA). It will read and display the specified number of bytes (NB = 01 - FF).

This command performs an SMBus/PMBus write on the selected bus (N = 0-7) targeting the device specified by the 7-bit Slave Address (SA). The specified command code (CC) is written first followed by the HEX bytes (there must to an even number of characters) are written from left to right.

This command performs an SMBus/PMBus write on the selected bus (N = 0-7) targeting the device specified by the 7-bit Slave Address (SA). The specified command code (CC) is written first followed by a 'restart' that reads the specified number of bytes (NB = 01 - FF).

This command is used to set GP Output state (a = assert, d = de-assert, z = hi-z).

When the ChMC is in test mode, the set and clr commands will assert or de-assert the specified ChMC inputs (read from an internal register) as listed in Table 12.

The set/clr commands can also be used to set the state of various outputs listed in Table 13.

The read/write commands allow you to directly read and write memory contents within various partitions of the ChMCs non-volatile memory (NVM). NVMRO must be de-asserted to use the write command. For detailed information about the configuration memory spaces within the ChMC please contact the factory.

This command displays a HEX dump of the device descriptor storage space.

This command displays a HEX dump of the POR and Activation initialization scripts.

This command reads all messages from the SMS queue and displays them as HEX strings on the console before deleting them.

This command is used to send an IPMI message on the specified IPMB interface. The message is entered as a HEX string. You do not need to include the final checksum byte as the ChMC will calculate that for you. The target interface is specified as c=chassis (IPMB-0), p=SCL/SDA[2], or 'l'=SCL/SDA[3].

When sending messages from the command-line, you will want 'debug ipmb' on and specify the rqSA:00b as the IPMB address of this ChMC so that the response comes back to this ChMC and is displayed on the console. You may also choose to use rqSA:10b as the requestor address so that the response will be routed into the SMS Queue for later retrieval.

Ex: 'get device ID' request to device at 82h from 80h: ipmb_send c 821866800401<enter>

when snoop is enabled, the ChMC will display every message detected on its IPMI interface regardless of whether that message is addressed to this ChMC or not.