ATCA FIRMWARE AND SOFTWARE UPDATE INSTRUCTIONS USING THE RADISYS SOFTWARE MANAGEMENT FRAMEWORK April 2012 007-03428-0003
Revision history Version -0000 -0001 -0002 Date March 2011 June 2011 January 2012 -0003 April 2012 Description First edition. Second edition. Updated to state that ATCA-7220 data flow mode selection is not preserved automatically. Third edition. Added information about the update bundle format. Added instructions for updating IPMI firmware and FRU data for an AMC or RTM. Noted that the sample hpiapp should not be used in deployed systems. Fourth edition.
Table of Contents Preface ................................................................................................................................................ 5 About these update instructions ..................................................................................................................5 What’s new in this manual...........................................................................................................................5 Where to get more product information ...
Table of Contents Appendix C: Updating IPMI FW and FRU Data for an AMC or RTM ............................................. 56 Determining the IPMI firmware version......................................................................................................56 Updating the IPMI firmware .......................................................................................................................57 Reverting to backup firmware..................................................................
Preface About these update instructions This document describes the rsys_swm utility, which is the upgrade utility provided with the Radisys Software Management Framework (SMF). The rsys_swm utility and the SMF were introduced in the 4.0.0 release as the new tools for making software and firmware updates in the ATCA® system. The rsys_swm utility can perform the update on a single module, a fully‐populated shelf, or simultaneously on multiple shelves–all from the same update host.
Preface See the following documents for additional firmware and software update information: • ATCA 3.x to 4.x Firmware and Software Upgrade/Downgrade Instructions • ATCA Firmware and Software Update Instructions For information about the PCI Industrial Computer Manufacturers Group (PICMG®) and the AdvancedTCA standard, consult the PICMG Web site at this URL: http://www.picmg.org. Notational conventions This manual uses the following conventions BoldText A keyword.
Chapter 1 Introduction Supported modules and components Table 1 lists the ATCA modules and components that can be updated automatically by the Radisys Software Management Framework (SMF). ATCA modules typically have a number of firmware and software components that can be updated. These components are programmed into flash devices or logic devices like FPGAs and CPLDs. Some of the devices act as redundant active‐standby pairs that are updated one‐at‐a‐time. Other devices are single, non‐redundant units.
1 Introduction a b c For the ATCA‐7220 PPM, the data flow mode selection is not preserved automatically. See the ATCA‐7220 Packet Processing Module Reference. The CPMs must be running a Radisys supported operating system and any support modules like the AMCs must be installed. Use the rsysbflash utility for the ATCA‐45xx series and the ATCA‐46xx series CPMs to save and restore the configuration.
1 Introduction Overview of the Software Management Framework The sections that follow give a brief description of each SMF component as they pertain to the rsys_swm utility and the update process described in this document. For detailed information on the SMF components, see the ATCA Software Guide.
1 Introduction System manager A system manager is a high‐level management application that may manage entities ranging from a single shelf to multiple systems. While the Radisys ATCA software does not currently include a system manager, its shelf management software does provide capabilities and interfaces that a system manager can use to manage ATCA shelves.
1 Introduction Firmware tools Radisys provides firmware tools that interact directly with the hardware to perform software management operations. The firmware tools are Linux‐based and include a set of commands for performing low level operations such as checking for the versions of installed firmware, updating the flash banks, and verifying the images. These tools typically run locally on the local management processor, but some of the tools may be able to perform their operations remotely.
Chapter 2 Performing Updates Using rsys_swm Procedures for update process The procedures for updating one or more Radisys shelves is as follows: 1. Plan the update by reading this document and identify which products will be included in the update. See page 7 for a list of the modules and components that can be updated using the rsys_swm utility. 2. Prepare the update host. See page 17. 3. Determine the required IP interfaces.
Performing Updates Using rsys_swm 2 If you intend to include Shelf Manager modules like the ATCA‐2210 in the upgrade, some further planning and preparation is required. For redundant Shelf Manager modules, you must first upgrade the standby Shelf Manager module, perform a switchover between the two Shelf Manager modules, and then upgrade the other Shelf Manager module. If you have only one Shelf Manager module (i.e., non‐redundant) in the shelf, you must perform some additional configuration procedures.
Performing Updates Using rsys_swm 2 Determine when to perform the update Your planning should take into account the time needed to perform the update and the downtime involved. Table 3 shows the estimated time it takes for one update pass on a fully‐populated platform. Table 3.
Performing Updates Using rsys_swm • • 2 the directories /rsys/onboot.d and /rsys/onboot.data are removed and repopulated by the new release, and the configuration saved in the temporary location is restored to its proper location. Files preserved by default File preservation includes various configurations—Ethernet (Fastpath), module management, shelf management, and others. The system automatically preserves the following files in a default preservation list stored in the /etc/configmgmt.
Performing Updates Using rsys_swm 2 Create a custom preservation list You may want to preserve other files that are not preserved automatically. For example, if you have an ATCA‐2210 SCM running a DHCP server, you may want to preserve its DHCP configuration files. To preserve additional configuration files, add them to the /etc/rsys‐user‐file‐list.cfg file. If this file is not available on your system, you may need to create it. When adding the configuration file names to the rsys‐user‐file‐list.
Performing Updates Using rsys_swm 2 Step 2: Prepare the update host The update host must be a Linux host with LAN access to the modules in the shelf. All update targets must be accessible via the Base Ethernet interface from the update host running rsys_swm. The update repository must be local to the update host. Currently, the rsys_swm utility only supports “file://” type uniform resource identifiers (URIs) for its repository location parameter (“releaseuri” tag in the configuration file).
Performing Updates Using rsys_swm 2 Step 3: Determine and configure the required IP interfaces Updates to multiple modules When updating an entire shelf or multiple modules within a shelf, you will need to provide the Shelf Manager server’s (ShMS) IP address to the rsys_swm utility for the update server’s IP address.
Performing Updates Using rsys_swm 2 If a particular FRU is missing from the version report, then its Blade HSD is not registered with the Shelf Manager and you will need to edit its configuration file and set up IP interfaces. See Configure an IP interface for the Blade HSD below for information. Configure an IP interface for the Blade HSD You must configure an IP interface for the Blade HSD when performing the following types of updates: • Updating modules on a third‐party shelf (i.e.
2 Performing Updates Using rsys_swm Sample rsyshsd.conf file The three IP interface parameters appear near the bottom of the configuration file. An example of a configuration file for a CPM module is shown below. #!/bin/sh ######################################################################## ## RadiSys Confidential ## ## RadiSys Promentum(TM) ATCA Blade HPI Management ## ## (C) Copyright RadiSys Corporation 2004‐2005. All Rights Reserved.
Performing Updates Using rsys_swm 2 CPM-specific recommendations On CPM modules, the interfaces are set to the following by default: • RSYSHSD_BASE_INTERFACE: eth0 • RSYSHSD_FABRIC_INTERFACE: eth1 • RSYSHSD_SHMS_INTERFACE: eth0 If the CPMs in your system use bonded interfaces to communicate with the Shelf Manager over the Base Ethernet, you will need to edit the default parameters and name the bonded interfaces. for the RSYSHSD_BASE_INTERFACE and the RSYSHSD_SHMS_INTERFACE parameters.
Performing Updates Using rsys_swm 2 Updates to the Shelf Manager modules If you execute the upgrade using the Shelf Manager’s IP address against a shelf with redundant Shelf Manager modules (e.g., the ATCA‐2210s), the active Shelf Manager module will be automatically skipped. Only the standby Shelf Manger module will be updated. To update the active Shelf Manager module, you can perform a switchover on the Shelf Manager modules and change their active/standby status.
Performing Updates Using rsys_swm 2 Step 4: Obtain the release ISO image from Radisys An ATCA Software image is available at www.radisys.com/downloads. Browse to the downloads page for the AdvancedTCA platform system (for example, the SYS‐6010 platform). From the Software downloads section, download the .zip file (or files) that contain the ISO image. Once the ISO image has been extracted, perform the procedures described in the following sections.
Performing Updates Using rsys_swm 2 If the export was successful, you will see the folder listed. 4. Log on to the module (for example, an ATCA‐2210) that will run the rsys_swm utility and create a directory with the same path: mkdir /mnt/release The repository path must be the same on both the remote host and the module. 5. Mount repository from the remote host using nfs: mount ‐t nfs :/mnt/release /mnt/release You may receive some warning messages at this point.
Performing Updates Using rsys_swm 2 Step 5: Install the software packages Locate the following packages and install them on the update host in the order shown here: 1. The HPI client library package: libhcl‐1.6.4 (or higher) 2. The YAML library software packages: libyaml‐0.1.3 3. The RPC support package: rsys‐rpc‐support‐1.0.53‐1 (or higher) 4. The SML package: libsml‐0.1.
2 Performing Updates Using rsys_swm Step 6: Define the upgrade campaign configuration file Before you can run the update process, you must create and define an upgrade campaign configuration file. This configuration file is used by the rsys_swm utility in determining which modules and components are updated and in what order the updates take place. You can generate an upgrade configuration from the sample text file “config.cfg” that is available in /usr/share/rsys_swm/ folder.
2 Performing Updates Using rsys_swm Required configuration releaseuri tag This tag specifies the URI of the update repository on the update host. This is the mount location of the release CD ISO image or the root of the update repository where the ISO is mounted. The software bundles must be accessible from the update targets (i.e., modules and components) using the URI specified for the update repository. The IP connections are shown in the following diagram: Figure 3.
Performing Updates Using rsys_swm 2 The possible SDKs supported for the ATCA‐7220s are listed below: Table 5. SDKs for the ATCA-7220s Parameter SDK1.7 SDK1.9 SDK 2.1 Description Software development kit, version 1.7 Software development kit, version 1.9 Software development kit, version 2.1 If no SDK is specified for the ATCA‐7220, the SDK1.7 bundle is used for the update. Optional configuration and actions phase tag This tag specifies the phases.
Performing Updates Using rsys_swm 2 module tag This tag identifies modules to be updated. See Supported modules and components on page 7 for the list of the modules supported by this configuration file. The modules are identified in the configuration file using this format: ‐module: . Use either a type or a name tag for the FRU type parameter. Currently, the only allowed type is “board,” but future versions of rsys_swm may support other types.
Performing Updates Using rsys_swm 2 exclude tag This tag specifies the components to exclude from the upgrade for all modules. The possible exclude tags are listed below: Table 6. Exclude tags Tag system-os system-boot bios ipmcipmc-app ipmc-boot ipmc-fpga fru-data boot-block legacy-fpga commux-cpld base-nic fabric-nic front-nic Description LMP, Linux kernel filesystem. U-Boot. BIOS. IPMC for the application block, the boot block, and the FPGA. IPMC for the application block only.
Performing Updates Using rsys_swm 2 Configuration file syntax The upgrade campaign configuration file used by the rsys_swm utility must conform to the YAML file format. See http://pyyaml.org/wiki/LibYAML to download the library (libyaml). Additional information on the YAML format can be found at http://yaml.org/spec/1.1. Formatting guidelines The configuration file must conform to these YAML 1.1 specifications: • Indentations must be inserted with spaces.
Performing Updates Using rsys_swm 2 Step 7: Running the rsys_swm utility The rsys_swm utility can perform the following operations: • Checks and verifies the user provided configuration file and provides advance summary of the update configuration. • Retrieves active and backup versions for all assets in the shelf. No campaign configuration or update repository is needed for this operation. • Performs the upgrade by installing and activating the SMF‐supported software components.
Performing Updates Using rsys_swm ‐c 2 Species the path of the YAML formatted upgrade campaign configuration file. ‐s Specifies the URI of the update server host. The URI is used by modules to download update bundles from the repository on the update host. This parameter, along with the information provided for the “releaseuri” in the campaign configuration file are used by modules to determine the bundle download path.
Performing Updates Using rsys_swm 2 Using rsys_swm to perform upgrades The default behavior of the rsys_swm utility is to upgrade all entities under the default root entity path when no phases are specified in the configuration file. However, additional control over the order and phasing of the upgrades can be controlled through the upgrade campaign file. For information on configuring an upgrade campaign file, see page 26. Sample configuration files are also provided on page 41.
2 Performing Updates Using rsys_swm Usage examples To perform a dry run of the upgrade campaign, enter: rsys_swm ‐i 192.168.16.17 \ ‐c ./config.cfg \ ‐s tftp://10.100.110.45 \ ‐‐upgrade ‐‐check 192.168.6.17 is the IP address of the Shelf Manager and 10.100.110.45 is the IP address of the update host. The dry run checks the integrity of images and displays the modules and software entities that will be upgraded. To retrieve the versions of all the entities in the shelf: rsys_swm ‐i 192.168.16.
2 Performing Updates Using rsys_swm To perform an upgrade campaign on the software entities on a specific module: rsys_swm ‐i 10.100.18.22 \ ‐c ./config.cfg \ ‐s ftp://johndoe:password@10.100.18.252 \ ‐e board.8 \ ‐‐upgrade The module specified for this example is the module installed in slot 8 of the shelf. Using the ‐ e option can significantly speed up the update process, as it directs the upgrade at a specific board (for example, at the ATCA‐2210 acting as the standby Shelf Manager).
Performing Updates Using rsys_swm 2 Correlation between the “-s” parameter and the “releaseuri” tag The “s” parameter, which identifies the update server URI for rsys_swm, and the “releaseuri” tag in the upgrade campaign file correlate with each other. The SML combines these two parameters to create a URI, which the Blade HSDs running on the modules use for downloading the update bundles from the update host. For example, if you have the following: • The update host is accessible via IP address 10.100.19.
Performing Updates Using rsys_swm 2 Callback function The rsys_swm utility implements a sample callback function in its code that adheres to the callback API prototype published in the SML header file rsys_swm_api.h and defined in the API documentation (rsys_sml_api_reference.doc) generated by the SML library code. By default, the sample callback only tracks the upgrade campaign’s progress and displays it on screen in verbose mode.
Performing Updates Using rsys_swm 2 Step 8: Verify the update was successful Review the upgrade report file “report.yml” after the upgrade process runs. The upgrade report lists which modules and components were upgraded and whether the upgrade was successful. By default, the upgrade report is located in the current working directory. However, you can specify other locations to output the report using the ‐r/‐‐report option. The report.yml file is formatted in YAML 1.
Performing Updates Using rsys_swm 2 Rear Transitional Modules (RTMs) • • • • ATCA‐1200 RTM (optional RTM for the ATCA‐1200 Quad AMC Carrier). ATCA‐5200 RTM (optional RTM for the ATCA‐7220 PPM). ATCA‐5400 and ATCA‐5401 RTMs (optional RTMs for the ATCA‐45xx series and ATCA‐46xx CPMs). ATCA‐5402 RTM (optional RTM for the ATCA‐46xx series CPMs) Shelf Peripheral Modules (SPMs) • ATCA‐5010 and ATCA‐5014 SPMs (optional SPMs for the ATCA‐2210 SCM).
Appendix A Sample Configuration Files This appendix includes four sample rsys_swm upgrade campaign configuration files that can be used as guidelines for creating your own upgrade campaign file. You can copy any of the configuration file samples shown in these sections into a text file. Edit the text file as necessary and save it with a name that clearly identifies its purpose. For example: upgrade‐campaign.yml See Configuration file syntax on page 31 for details on YAML formatting.
A Sample Configuration Files Example 1: Generic configuration file The following example is generic and contains the tag information and descriptions. # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # Upgrade campaign example This file is used for specifying the upgrade order. The upgrade order is grouped into phases. Each phase executes a complete upgrade of a subset of modules.
A Sample Configuration Files ‐‐‐ campaign: ‐ releaseuri: file:///mnt/release‐4.0.0 ‐ exclude: system‐boot, boot‐block, legacy‐fpga ‐ phase: ‐ step: ‐ module: board.8 ‐ exclude: fru‐data ‐ step: ‐ module: ATCA‐4500.[2,5] ‐ os: wr1_32 ‐ exclude: ipmc‐, fru‐data # skip UBoot and BIOS boot‐block # Phase 1 # SCM in slot 8 # skip IPMI fru data # CPMs in slots 2 and 5 # WR1.4 32 bit OS # skip ipmc components & fru‐data ‐ phase: ‐ step: ‐ module: ATCA‐7220 ‐ step: ‐ module: board.[10‐16] ‐ exclude: ‐nic ...
A Sample Configuration Files Example 2: Two phase update In this example, phase 1 updates all the ATCA‐7220 modules and ATCA‐4500 modules together. Phase 2 updates the ATCA‐2210 acting as the standby Shelf Manager. Please note that with this configuration, the shelf will go off‐line during the activation stage of the upgrade process, since all the node modules are being updated in parallel during phase 1.
A Sample Configuration Files Example 3: Three phase update In this example, the update is completed in three phases. • Phase 1–all ATCA‐1200 modules are upgraded. • Phase 2–all the ATCA‐4500 modules are upgraded. • Phase 3–the ATCA‐2210 acting as the standby Shelf Manager is upgraded. # Upgrade campaign example # Note: The tag description section has been removed from this example. # ‐‐‐ campaign: ‐ releaseuri: file:///mnt/release‐4.x.
A Sample Configuration Files Example 4: Three phase redundant update In this example, a shelf upgrade is performed in three phases and is configured in such a way that the redundant modules continue to run, which keeps the shelf from going offline: • Phase 1–upgrades the left side of the shelf. The ATCA‐1200 modules in slots 1‐6 and the ATCA‐4500 module in slot 7 are upgraded, while services continue to run on the right side of the shelf. • Phase 2–upgrades the right side of the shelf.
A Sample Configuration Files Other configuration file variations You can create a configuration file that only has the “releaseuri” tag specified. If you use such a configuration file, be aware that all SMF‐supported modules and components on the shelf will be updated by default. # Upgrade campaign example # Note: The tag description section has been removed from this example. # ‐‐‐ campaign: ‐ releaseuri: file:///mnt/release‐4.x.
Appendix B Updating and Customizing FRU Data Use the procedures in this appendix to update or customize FRU data for a FRU or shelf. Radisys occasionally updates the functional aspects of FRU data, including PICMG point‐to‐point connectivity records, with corrections or enhancements. The update procedures preserve the FRU‐specific information such as the serial number. Another procedure allows you to customize certain fields while preserving the functional aspects of the FRU data.
Updating and Customizing FRU Data B Updating FRU data The fru_update shell script can be used for two purposes: • Update the portions of the functional FRU data that changed to a new version from Radisys while preserving FRU‐specific information. • Modify the fields that can be customized in the FRU data while preserving the functional FRU data.
Updating and Customizing FRU Data B Procedure: From a Linux host with LAN access to the Shelf Manager, update the FRU data by entering: fru_update "‐I lan ‐H ‐A NONE ‐t " The IP address of the active Shelf Manager. The IPMB address of the FRU to update. The IPMB information is available in each shelf’s reference manual and is also described in the ATCA Command Line Interface Reference.
Updating and Customizing FRU Data B Customizing FRU-specific data The frugen.pl Perl script prompts for new values for the user‐definable fields in an existing FRU data image. The script creates a new binary image containing the functional FRU data and any custom values. Specify in a configuration file which of the user‐definable fields to overwrite in the FRU device. Use the configuration file and the image created to write the custom values to the FRU device as described in Updating FRU data on page 49.
B Updating and Customizing FRU Data 3. Respond to the prompts by entering custom data or leaving fields blank to keep the existing value. Pressing enter without entering anything uses the data already in the .sf file, which are typically blank spaces, or the data on the FRU device (depending on the choices made in Step 5). The data entered must match the default length of the field (usually 20 characters). Otherwise frugen.pl will prompt again for the same field.
B Updating and Customizing FRU Data Updating FRU data on the ATCA-6006 5U 6-slot shelf Important: For the ATCA‐6006 shelf to run 3.3.0 and later, the shelf FRU data update is mandatory. First, update the shelf FRU data to version 3.3.0 as described in this section. Next, customize the ATCA‐6006 FRU data using Customizing FRU‐specific data on page 51. Finally, use Updating FRU data on page 49 to apply the changes to the customized fields and perform any further updates.
Updating and Customizing FRU Data B c. Locate and modify the Chassis Serial Number line: • Chassis Serial Number is just below the part number. • Replace the 'X' characters with the Chassis Serial value (13 characters total). d. Locate and modify the Chassis Manufacturer Name: • Chassis Manufacturer Name is just below the serial number. • Replace the characters with Radisys Corp. (13 characters total). e. Search for the string BOARD. f.
Updating and Customizing FRU Data B 6. Generate a shelf FRU data file based on the changed template file. a. Run frugen.pl on the ATCA‐2210 to generate a shelf FRU data file with the newly added serial numbers and asset tag information. frugen.pl ‐f .sf ‐o .bin b. When prompted for Serial Numbers and Asset Tag information, make sure it is correct and press the Enter key. c. If the value is not correct, edit the file and run frugen.pl again.
Appendix C Updating IPMI FW and FRU Data for an AMC or RTM This chapter describes updating the AMC or RTM IPMI firmware using rsys‐ipmitool and updating the FRU data for an AMC or RTM using the rmcpta utility.
Updating IPMI FW and FRU Data for an AMC or RTM C Updating the IPMI firmware The IPMI firmware for an RTM or AMC is updated using rsys‐ipmitool. Update the AMC or RTM IPMI firmware by following these steps: 1. Access the Linux or Windows command prompt. 2. Change directory to the location of the extracted AMC or RTM firmware images and tools. 3.
Updating IPMI FW and FRU Data for an AMC or RTM C Reviewing the output The output from the IPMI firmware update commands should resemble the following example: PICMG HPM.1 Upgrade Agent 1.0: Validating firmware image integrity...OK Performing preparation stage... Services may be affected during upgrade.
Updating IPMI FW and FRU Data for an AMC or RTM C Reverting to backup firmware Use this procedure only if you need to revert to the backup firmware version stored on the MMC. After performing the procedure, you will not be able to run the new version again until a full upgrade is completed.
Updating IPMI FW and FRU Data for an AMC or RTM C IPMB and IPMB-L address mapping Table 7 provides the IPMB addresses of ATCA front modules, Power Entry Modules (PEMs), fan modules, and Shelf Peripheral Modules (SPMs) in Radisys ATCA shelves. The hexadecimal addresses in these tables may not be correct for shelves made by other manufacturers. If you are using a third‐party shelf, refer to the shelf's documentation for its IPMB addresses. Table 7.
Updating IPMI FW and FRU Data for an AMC or RTM C Table 8 provides the local IPMB addresses (IPMB‐L) for AMC and RTM devices, which is the IPMB from the carrier manager to the module. Each AMC and RTM connects to IPMB‐L through a module management controller (MMC). The hexadecimal addresses in this table may not be correct for shelves made by other manufacturers. If you are using a third‐party shelf, refer to the shelf's documentation for its IPMB‐L addresses. To comply with the AMC.
Appendix D Updating the BIOS on the CPMs This chapter describes the BIOS flash update methods for the ATCA‐45xx series and ATCA‐46xx series CPMs. The updates are performed from the Linux command line or from the EFI shell of the CPMs. Prepare the CPMs for the update To prepare the ATCA‐45xx series and the ATCA‐46xx series CPMs for the BIOS update, perform the following procedures. 1. Locate the latest *tgz file for the appropriate CPM product. For example, ATCA‐4500‐.tgz is a *.
Updating the BIOS on the CPMs D Building the flash update driver If the amifldrv‐.rpm is not in the software release, you will need to build it using the rsysbflash utility. 1. From the ATCA software release, install biosver.rpm and rsysbflash.rpm for your operating system. This step is not necessary if these required RPMs are already installed (see Prepare the CPMs for the update on page 62 for instructions). 2. If the CPM uses a cross‐compiled version of Wind River 2.
Updating the BIOS on the CPMs D For ATCA-4500, ATCA-4550, and ATCA-4555 CPMs Updating the main BIOS from the Linux command line 1. Verify the rsysbflash utility and the amifldrv_mod.o kernel driver are installed. See Prepare the CPMs for the update on page 62 for installation instructions 2. Copy the BIOS.ROM file from the firmware/bios folder of the operating system update bundle to a location that is accessible to the rsysbflash utility. 3.
Updating the BIOS on the CPMs D Updating the BIOS from EFI shell 1. Copy AFUEFIx64.efi, ME_BIOS.bin, update.nsh, and updateme.nsh to a USB flash drive and boot into the EFI shell. The files are located in the firmware/bios folder of the operating system update bundle. 2. Switch to the file system on the USB flash drive (usually fs0:). fs0: 3. Run the update.nsh batch file or execute the following command to update the BIOS on one bank: AFUEFIx64.efi ME_BIOS.bin /p /b /x 4. Reboot the CPM. 5.
Appendix E Restoring Older Firmware or Software If firmware image corruption or incompatibilities occur that cannot be corrected, it may be necessary to downgrade the modules in the system to an earlier ATCA version. If you are downgrading from release ATCA‐4.1.1 or later to an earlier version of 4.x.x, use the rsys_swm utility to perform the downgrade. The same procedures are used for the downgrade as the upgrade.
Appendix F Troubleshooting If an update fails, first check to make sure the specified URI and all command line arguments are correct. For other failures, retry the update at least once more before contacting Radisys Support. WARNING! Do not reset the board until the update failure has been corrected.
F Troubleshooting RSYS_E_SML_INVALID_URI Decimal code: 12582918 Hexadecimal code: 0xC00006 Description: A specified URI was in an invalid format. Action to take: Verify that the URI specified on the command line for the SML report file and the URI specified for the releaseuri tag in the upgrade campaign file are formatted correctly.
F Troubleshooting RSYS_E_SML_UPGRADE_TOOL_NOT_FOUND Decimal code: 12582921 Hexadecimal code: 0xC00009 Description: The specified upgrade tool could not be found on the target FRU. Action to take: For most of the Radisys modules, the update bundle contains all the tools necessary to perform the upgrade on the target FRU. A few module types, like the CPMs, do require certain tools to be pre‐installed. For example, all necessary board support packages must be installed on the file system for CPMs.
F Troubleshooting RSYS_E_SML_TARGET_ACTIVATION_FAILED Decimal code: 12582924 Hexadecimal code: 0xC0000C Description: The newly installed image failed to activate on the target software entity. Action to take: This indicates either a hardware error in the component being updated or a corrupt bundle. Please send the information from the log messages and SML log files to Radisys Support. See Appendix G, Log File Information, on page 75 for details.
F Troubleshooting RSYS_E_SML_INFO_GET_FAILED Decimal code: 201326612 Hexadecimal code: 0xC000014 Description: The SML failed to retrieve information from the software entity or the bundle. Action to take: This indicates a loss of communication between the FRU and the Shelf Manager over the Base interface. This can also mean that the associated software component on the module is not responding. Reboot the module and try the upgrade again. If the problem persists, contact Radisys Support.
F Troubleshooting RSYS_E_SML_OPERATION_INIT_FAILED Decimal code: 201326616 Hexadecimal code: 0xC000018 Description: The SML operation failed to set the upgrade source or to construct the update bundle for a module. Action to take: This indicates the SML lost its HPI connectivity with the update server that was identified to the rsys_swm utility by the “‐i” parameter. • • • Verify the update server that was specified for “‐i” is accessible.
F Troubleshooting RSYS_E_SML_OPERATION_INCOMPLETE Decimal code: 201326617 Hexadecimal code: 0xC000019 Description: The SML failed to complete the post‐update cleanup operation on the software entity or bundle. Action to take: This error typically indicates that following activation of a FRU, the FRU has either gotten stuck in its reset process or taken too long to reboot. This error occurs more frequently with upgrades of LMP‐based modules where the FRU needs to be reset.
F Troubleshooting RSYS_E_SML_HPI_BUSY Decimal code: 201326652 Hexadecimal code: 0xC00003C Description: The HPI server is busy. Action to take: The update server is busy with other operations. Please wait a few minutes and then perform the upgrade again. If the problem persists, switch over to the redundant Shelf Manager and then restart the update procedure. If a redundant Shelf Manager is not available, restart the Shelf Manager.
Appendix G Log File Information Table 9 describes the log files that contain information about the upgrade process. The files can be helpful in troubleshooting any upgrade issues that may occur during the upgrade. Table 9. Log file information Log file rsys_swm.log updateLog_.log SML report file Description The log kept by the rsys_swm utility. This tracks the verification of the configuration file and the command line arguments, and contains the SML return codes.
