Hardware Platform Management IPM Controller Firmware Upgrade Specification PICMG HPM.1 R1.0 May 4, 2007

Transcription

1 HPM.1 Hardware Platform Management IPM Controller Firmware Upgrade Specification PICMG HPM.1 R1.0 May 4, 2007

2 Copyright 2007, PCI Industrial Computer Manufacturers Group. The attention of adopters is directed to the possibility that compliance with or adoption of PICMG specifications may require use of an invention covered by patent rights. PICMG shall not be responsible for identifying patents for which a license may be required by any PICMG specification or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. PICMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. NOTICE: The information contained in this document is subject to change without notice. The material in this document details a PICMG specification in accordance with the license and notices set forth on this page. This document does not represent a commitment to implement any portion of this specification in any company's products. WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, PICMG MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL INCLUDING, BUT NOT LIMITED TO, ANY WARANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR PARTICULAR PURPOSE OR USE. In no event shall PICMG be liable for errors contained herein or for indirect, incidental, special, consequential, reliance or cover damages, including loss of profits, revenue, data or use, incurred by any user or any third party. Compliance with this specification does not absolve manufacturers of equipment from the requirements of safety and regulatory agencies (UL, CSA, FCC, IEC, etc.). PICMG, CompactPCI, AdvancedTCA, AdvancedTCA 300, ATCA, ATCA 300, CompactPCI Express and the PICMG, CompactPCI, AdvancedTCA and ATCA logos are registered trademarks, and COM Express, MicroTCA, µtca, CompactTCA, AdvancedMC and SHB Express are trademarks of the PCI Industrial Computer Manufacturers Group. All other brand or product names may be trademarks or registered trademarks of their respective holders. ii PICMG HPM.1 R1.0, May 4, 2007

3 Contents 1 Introduction Special word usage Conformance Reference specifications HPM.1 Specification contributors Name and logo usage Intellectual property Necessary claims Unnecessary claims Third party disclosures Glossary Overview Firmware redundancy Assisted Rollback Boot Loader Steps of sample Firmware Upgrade Multi-component IPM Controllers Deferred firmware activation Procedure Handling long-duration commands Preparation stage Upgrade stage Comparison of the Active Copy Activation stage Aborting Firmware Upgrade Firmware Upgrade error handling Upgrade Image Other aspects Guidelines on implementing loadable Boot Loaders Guidelines on implementing dependent components Handling of duplicated requests Firmware Upgrade over one bus of IPMB Commands...55 A Scenarios...57 A.1 Non-preemptive, multiple symmetric banks (detailed description)...57 A.1.1 Scenario overview...57 A.1.2 Upgrade Image example...58 A.1.3 Upgrade procedure example...60 A.2 Preemptive, single bank with Boot Loader (overview)...63 A.2.1 Scenario overview...63 A.2.2 Upgrade procedure example...63 A.3 Preemptive, multiple asymmetric banks - approach 1 (overview)...64 A.3.1 Scenario overview...64 PICMG HPM.1 R1.0, May 4, 2007 iii

4 A.3.2 Upgrade procedure example A.4 Non-preemptive, multiple asymmetric banks - approach 2 (overview) A.4.1 Scenario overview A.4.2 Upgrade procedure example iv PICMG HPM.1 R1.0, May 4, 2007

5 Figures 3-1 Preparation stage of Firmware Upgrade procedure Upgrade stage of Firmware Upgrade procedure Activation stage of Firmware Upgrade procedure Upgrade Image format...48 A-1 Sample IPM Controller components...57 A-2 Upgrade Image example...59 PICMG HPM.1 R1.0, May 4, 2007 v

6 vi PICMG HPM.1 R1.0, May 4, 2007

7 Tables 1-1 Special terms Long-duration commands Get upgrade status command Get target upgrade capabilities command Component bit mask Get component properties command Component properties data Version field Initiate upgrade action command Upload firmware block command Finish firmware upload command Activate firmware command Query self-test results command Query Rollback status command Initiate Manual Rollback command Abort Firmware Upgrade command Upgrade Image header record OEM data descriptor Upgrade action record Image checksum record Command number assignments and requirements Command privilege levels...56 PICMG HPM.1 R1.0, May 4, 2007 vii

8 viii PICMG HPM.1 R1.0, May 4, 2007

9 Introduction 1 1 This hardware platform management specification defines a Firmware Upgrade facility for PICMG IPM Controllers, as specified in the AdvancedTCA, AdvancedMC, and MicroTCA specifications. References to IPM Controller in this specification are intended to cover the following: PICMG 3.0 IPM Controller AMC.0 Carrier IPM Controller AMC.0 Module Management Controller (MMC) MTCA.0 MicroTCA Carrier Management Controller (MCMC) MTCA.0 Enhanced Module Management Controller (EMMC) 2 During the life cycle of an AdvancedTCA or MicroTCA Shelf, the software and firmware running on Intelligent FRUs probably will require upgrades. The major part of such upgrades is performed via FRU-specific mechanisms provided by the FRU vendor. This is justified by the potentially substantial differences among such Intelligent FRUs in their hardware/ software designs and features. 3 However, all PICMG-compliant Intelligent FRUs have one common feature, the IPM Controller. Under certain conditions, it will be necessary to upgrade the IPM Controller firmware. One example of when this is needed is to fix a bug in the IPM Controller firmware. Another example is adoption of specification changes and need for compliance with them. Due to this, one of the popular requirements for Intelligent FRUs is support for IPM Controller firmware upgrades. Since the AdvancedTCA and MicroTCA architectures are designed to provide high availability, this requirement usually implies in-field IPM Controller firmware upgrades, which means that it is possible to upgrade the IPM Controller without extracting the FRU from the Shelf. 4 The most universal way to upgrade IPM Controllers is over IPMB, because all IPM Controllers are required to support it. Moreover, the IPM Controllers of some Intelligent FRUs are so simple that they do not provide any external interfaces except for IPMB. One of the advantages of Firmware Upgrade over IPMB is that it allows upgrading of all Intelligent FRUs from a single location (for example, the Shelf or System Manager). Other approaches, such as upgrade over the Payload Interface, do not support a centralized upgrade. This advantage of upgrade over IPMB makes it very convenient for system integrators, who would prefer to have a single upgrade mechanism for the entire system. This specification uses IPMB to refer to IPMB-0 or IPMB-L as defined in the AdvancedTCA Base specification and the AdvancedMC Base specification, respectively. 5 To further facilitate integration of Intelligent FRUs produced by different vendors, this specification defines an upgrade facility for IPM Controller firmware referred to in this specification as Firmware Upgrade. Firmware Upgrade allows the system integrators to have a single set of tools for upgrading IPM Controllers in the entire system. In addition, Firmware Upgrade ensures that all new FRUs will be automatically supported by the upgrade tools compliant with this specification, and vice versa. Another advantage of Firmware Upgrade is that it allows vendors to focus on either IPM Controller implementations or upgrade tools. This fragmentation is deemed to improve the quality of each of these parts. This specification defines an Upgrade Agent as the tool used to perform the Firmware Upgrade. PICMG HPM.1 R1.0, May 4,

10 6 Although the PICMG 3.0 Shelf Management Controller (ShMC) is not listed among the IPM Controllers covered by this specification, such controllers can also support Firmware Upgrade. However, in the ShMC case, Firmware Upgrade covers only the IPM Controller functionality of the ShMC, not the Shelf Manager functionality. Shelf Manager vendors are expected to provide proprietary mechanisms for upgrading the Shelf Manager on their Shelf Management Controllers. Also, if an ShMC supports Firmware Upgrade, it uses the System Manager Interface as a primary Firmware Upgrade interface, instead of IPMB-0. 7 In addition to the PICMG 3.0 System Manager, the MicroTCA Carrier Manager and Shelf Manager functions are not required to support Firmware Upgrade by this specification. If supported, the MicroTCA Shelf Manager or Carrier Manager support Firmware Upgrade over the System Manager Interface or Shelf-Carrier Manager Interface, respectively. 8 Upgrade Agent access to an IPM Controller connected to IPMB-0 or IPMB-L is provided by the Shelf Manager, the AMC Carrier AdvancedTCA Board, and the MicroTCA Carrier Hub with message bridging as defined in the AdvancedTCA Base specification, AdvancedMC Base specification and MicroTCA specification, respectively. The System Manager Interface is used by the Upgrade Agent to send Firmware Upgrade messages to an IPM Controller via the Shelf Manager. IPM Controller implementations located with a Shelf Manager or a Carrier Manager can support Firmware Upgrade over the System Manager Interface or the Shelf-Carrier Manager Interface as defined in the AdvancedTCA and the MicroTCA specifications, respectively. 1.1 Special word usage 9 In this specification, the following key words (in bold text) will be used: may should shall indicates flexibility of choice with no implied preference. indicates flexibility of choice with a strongly preferred implementation. The use of should not (in bold text) indicates flexibility of choice with a strong preference that the choice or implementation be avoided. indicates a mandatory requirement. Designers shall implement such mandatory requirements to ensure interchangeability and to claim conformance with this specification. The use of shall not (in bold text) indicates an action or implementation that is prohibited. Note: When not in bold text, the words may, should, and shall are being used in the traditional sense; that is, they do not adhere to the strict meanings described above. 10 This document uses requirements numbering as a way to find and reference HPM.1 requirements. Each requirement is numbered using the format REQ X.YY where X is the section where the requirement is located, YY denotes the requirement number and is a running sequence for each section. 1.2 Conformance 11 Statements of compliance with this specification take the form specified in the PICMG Policies and Procedures for Specification Development: This product complies with PICMG HPM.1 Revision PICMG HPM.1 R1.0, May 4, 2007

11 12 Products making this simple claim of compliance must provide, at a minimum, all features defined in numbered requirements (REQ X.YY) listed in this specification as being mandatory by using the keyword shall in the body of the requirement. Such products must not include any feature prohibited by the use of the keyword shall not in the numbered requirements contained in the specification. Such products may also provide recommended features associated with the keyword should, preferentially not provide the features associated with the keywords should not, and permitted features associated with the keyword may contained within the numbered requirements. 13 A simple claim of compliance with a subsidiary specification indicates the presence of all features defined as being mandatory by the use of the keyword shall, and absence of any features defined as being prohibited by the keywords shall not in the body of that specification. Because subsidiary specifications could also provide for recommended and permitted features beyond the mandatory minimum set and a range of performance capabilities, more complete descriptions of product compliance are encouraged. 1.3 Reference specifications 14 The following publications are used in conjunction with this specification. All documents can be obtained from their respective organizations. AdvancedTCA Base Specification document (PICMG 3.0 R2.0, as amended by ECN and ECN ). Referred to as AdvancedTCA Specification in the rest of this document, Advanced Mezzanine Card base specification document (AMC.0 R2.0), MicroTCA base specification document (MTCA.0 R1.0), IPMI Intelligent Platform Management Bus Communications Protocol Specification V1.0 Document Revision 1.0, November 15, 1999 Intel Corporation, Hewlett-Packard Company, NEC Corporation, Dell Computer Corporation. IPMI Intelligent Platform Management Interface Specification, v1.5. Document Revision 1.1, February 20, Intel Corporation, Hewlett-Packard Company, NEC Corporation, Dell Computer Corporation. PICMG Policies and Procedures for Specification Development, Revision 2.0, September 14, 2004, PCI Industrial Computer Manufacturers Group (PICMG ), 401 Edgewater Place, Suite 500, Wakefield, MA USA, Tel: , Fax: , SAF: Service Availability Forum Hardware Platform Interface, version B (SAI- HPI-B.02.01); January 2007; SAF: Service Availability Forum HPI-to-AdvancedTCA Mapping Specification, version B (SAIM-HPI-B ATCA); March 2006; PICMG HPM.1 R1.0, May 4,

12 1.4 HPM.1 Specification contributors 15 The following companies met the criteria as active members of the HPM.1 working group at the time of this writing: GE Fanuc Embedded Systems Intel JBlade LLC Kontron Motorola Nortel Performance Technologies Pigeon Point Systems RadiSys 1.5 Name and logo usage 16 The PCI Industrial Computer Manufacturers Group policies regarding the use of its logos and trademarks are as follows: 17 Permission to use the PICMG organization logo is automatically granted to designated PICMG members only as stipulated on the most recent Membership Privileges document (available at during the period of time for which their membership dues are paid. Non-members must not use the PICMG organization logo. 18 The PICMG organization logo must be printed in black or color, as shown in the files available for download from the members side of the Web site. The center bar of the logo containing the phrase PICMG is set horizontally and the aspect ratio of the entire logo must be maintained, but the size may be varied. Nothing may be added or deleted from the PICMG logo. 19 Manufacturers distributors and sales representatives may use PICMG trademarked and registered logos and trademarks (but not the PICMG organization logo) in promoting products sold under the name of the manufacturer. The use of these logos and trademarks is a privilege granted by the PICMG organization to companies who have purchased the relevant specifications (or acquired them as a member benefit), and who believe their products comply with these specifications. Use of the logos and trademarks by either members or nonmembers implies such compliance. PICMG may revoke permission to use logos if they are misused. All trademarked and registered logos and trademarks must carry the or symbols as appropriate and must be attributed to PICMG. The logos may be found on the members side of the website Non-members may fill out the logo request form therein. 20 The PICMG name and logo are registered trademarks of PICMG. Registered trademarks must be followed by the symbol, and the following statement must appear in all published literature and advertising material in which the logo appears: The PICMG name and logo are registered trademarks of the PCI Industrial Computer Manufacturers Group. 1.6 Intellectual property 21 The Consortium draws attention to the fact that it is claimed that compliance with this specification might involve the use of a patent claim(s) (Intellectual Property - IPR ). The Consortium takes no position concerning the evidence, validity, or scope of this IPR. 4 PICMG HPM.1 R1.0, May 4, 2007

13 22 Under the PICMG Intellectual Property Rights Policy adopted by the Executive Membership September 14, 2004, the license grants of Necessary Claims made in connection with this specification apply only to the Compliant Portion of an implementation. As a result they apply only to the required (as designated by the keyword shall ) or recommended (as designated by the keyword should ) elements of a specification that are within the bounds of the Statement of Work under which the Specification was developed. 23 The holder of this IPR has assured the Consortium that it is willing to license or sublicense all such IPR to those licensees (Members and non-members alike) desiring to implement this specification. The statement of the holder of this IPR to such effect has been filed with the Consortium. 24 Attention is also drawn to the possibility that some of the elements of this specification might be the subject of IPR other than those identified below. The Consortium is not responsible for identifying any or all such IPR. 25 No representation is made as to the availability of any license rights for use of any IPR inherent in this specification for any purpose other than to implement this specification. 26 This specification conforms to the current PICMG Intellectual Property Rights Policy and the Policies and Procedures for Specification Development and does not contain any known intellectual property that is not available for licensing under Reasonable and Non-discriminatory terms. In the course of Membership Review the following disclosures were made: Necessary claims 27 (referring to mandatory or recommended features) 28 No disclosures in this category have been made. 29 In addition, this specification requires implementations of the Intelligent Platform Management Interface and Intelligent Platform Management Bus specifications. The IPMI Promoters (Dell, HP, Intel Corporation and NEC Corporation) require that implementers of either of these specifications sign the IPMI Adopters Agreement. Please refer to for details Unnecessary claims 30 (referring to optional features or non-normative elements) 31 No disclosures in this category have been made Third party disclosures 32 (Note that third party IPR submissions do not contain any claim of willingness to license the IPR.) 33 No disclosures in this category were made during subcommittee review. 34 Refer to PICMG IPR Policies and Procedures and the company owner of the patent for terms and conditions of usage. PICMG HPM.1 R1.0, May 4,

14 35 PICMG makes no judgment as to the validity of these claims or the licensing terms offered by the claimants. 36 THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NON- INFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFI- CATION IS MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION. 37 Compliance with this specification does not absolve manufacturers of equipment from the requirements of safety and regulatory agencies (UL, CSA, FCC, IEC, etc.). 1.7 Glossary 38 The special terms in Table 1-1 are used throughout this specification. Table 1-1 Special terms Term Active Copy Backup Copy Boot Loader Firmware Upgrade Rollback Automatic Rollback Manual Rollback Assisted Rollback Upgrade Agent Upgrade Image Definition The current running copy of IPM Controller firmware An alternate, presumably stable, copy of IPM Controller firmware An optional small part of the IPM Controller firmware that is responsible for Firmware Upgrade The IPM Controller firmware upgrade facility as specified in this specification To switch to a Backup Copy of IPM Controller firmware Rollback initiated and performed autonomously by the IPM Controller upon detection of a serious error Rollback initiated externally by an action of either an Upgrade Agent or higher level management software and performed directly by the IPM Controller Rollback initiated and performed externally by an Upgrade Agent via a repeat of the Firmware Upgrade process An application responsible for managing upgrade of IPM Controller firmware Upgrade data, usually provided by the IPM Controller manufacturer, that is used by an Upgrade Agent to direct the Firmware Upgrade process. 6 PICMG HPM.1 R1.0, May 4, 2007

15 Overview 2 39 Firmware Upgrade consists of the following items: Firmware Upgrade procedure defining a sequence of actions to be performed when upgrading the IPM Controller of an Intelligent FRU. Explicitly defined IPMI-message-based Firmware Upgrade protocol that is used to prepare an IPM Controller for upgrade, transfer firmware and activate it. Common format for an Upgrade Image containing IPM Controller firmware upgrades. 40 The Firmware Upgrade procedure defines how an Upgrade Agent initiates a Firmware Upgrade, matches an Upgrade Image to a target IPM Controller, prepares an IPM Controller for Firmware Upgrade, uploads new firmware to an IPM Controller and activates it there. The main purpose of the Firmware Upgrade procedure is to define an explicit program flow for both an Upgrade Agent and an IPM Controller. See Section 3, Procedure, of this specification for details on the Firmware Upgrade procedure and protocol. 41 It is the intent of this specification that a single Upgrade Agent performs the Firmware Upgrade procedure with respect to a particular Shelf at any given time. Therefore, the rest of this specification assumes that there is only one Upgrade Agent operating at a time. This specification does not try to address the issues that might arise if there are multiple concurrently active Upgrade Agents for a given Shelf. 42 The Firmware Upgrade protocol defines the format of requests and responses used for communication between an Upgrade Agent and an IPM Controller. The communication between an Upgrade Agent and an IPM Controller is performed in the form of IPMI messages. Although this specification focuses mainly on IPMB, the communication can be performed through any interface supported by an IPM Controller and capable of transmitting IPMI messages. As an example, Firmware Upgrade could be supported through the Payload Interface if it is implemented. 43 Section 4, Upgrade Image, of this specification defines a common format for an Upgrade Image. These Upgrade Images are generated by FRU or IPM Controller vendors and provided to the system integrator. The system integrator uses an Upgrade Agent, that could be developed by another vendor, to process an Upgrade Image. The Upgrade Agent reads the Upgrade Image properties, matches them with its own capabilities and the capabilities of the target IPM Controller, performs actions specified in the Upgrade Image, extracts the new firmware from the image and transmits it to the target IPM Controller using the upgrade protocol. The mechanisms by which Upgrade Images are collected and accessed are outside the scope of this specification. 44 The Service Availability Forum (SAF) provides a Hardware Platform Interface (HPI) specification that defines an application programming interface for monitoring and controlling highly available systems and a complementary HPI-to-AdvancedTCA Mapping specification covering the application of HPI to the AdvancedTCA context. The HPI specification defines Firmware Upgrade Management Instruments (FUMIs) that could provide an interface to an HPM.1 Upgrade Agent from a System Manager function based on HPI. However, the current HPI-to-AdvancedTCA Mapping specification does not address FUMIs and the details of mapping HPI FUMIs to the facilities of HPM.1 are outside the scope of this specification. PICMG HPM.1 R1.0, May 4,

16 IPM Controller Requirements REQ 2.1 REQ 2.2 REQ 2.3 All IPM Controllers including PICMG 3.0 IPM Controllers, AMC.0 Carrier IPM Controllers, MMCs, EMMCs, MCMCs and IPM Controllers located with Shelf Managers shall support Firmware Upgrade described in this specification. IPM Controllers may support proprietary firmware upgrade mechanisms in addition to the firmware upgrade mechanism defined in this specification. IPM Controllers shall support Firmware Upgrade over IPMB-0 or IPMB-L unless the IPM Controller is part of a Shelf Manager or a Carrier Manager. REQ 2.4 IPM Controllers shall support Firmware Upgrade over LUN 0. REQ 2.5 REQ 2.6 REQ 2.7 IPM Controllers may support Firmware Upgrade over non-zero LUNs in addition to LUN 0. IPM Controllers shall return the Completion Codes as described in the Completion Codes section of the IPMI specification or the relevant PICMG specifications unless otherwise defined in this specification. The vendors of FRUs shall provide firmware upgrades in the Upgrade Image format as defined in Section 4, Upgrade Image. 2.1 Firmware redundancy 45 For better reliability and fault tolerance, IPM Controllers can contain multiple copies of the firmware. One of these copies is used as the Active Copy, while the others are provided as Backup Copies. A Backup Copy could be used during Firmware Upgrade to backup the previous version of the firmware. If the Firmware Upgrade fails (e.g. due to a power or communication failure) or self-test of the newly programmed firmware does not pass, the IPM Controller could then perform Automatic Rollback. 46 If both self-test and Rollback are implemented, self-test failures cause Automatic Rollback (versus, for example, performing Automatic Rollback only upon a self-test failure occurring on the very first startup of the new firmware). Implementations can avoid effects of an Automatic Rollback by ensuring the Backup Copy contains the same firmware as the Active Copy. An operator or higher-level management software decides when to upgrade the Backup Copy or upload the Active Copy to the Backup Copy, considering the Active Copy functions as expected. This can be done to avoid situations when the previous version of the firmware is so outdated that its execution might not be safe for some reason (for example, the old firmware has a severe bug that compromises the reliability of the entire Shelf). 47 Alternatively, Rollback can be initiated manually by an operator or higher-level management. This feature is intended for situations when it is desirable to revert to a previous version of the IPM Controller firmware that is known to be good and stored on the IPM Controller. Manual Rollback is initiated by an explicit request from an Upgrade Agent or higher-level management software and performed by the IPM Controller similarly to Automatic Rollback. 48 There are multiple approaches to implementing redundant firmware images in the IPM Controller. Some implementations could divide Flash memory into two parts, one of which is bootable and the other is not, and copy the contents of the first part to the second part before upgrade. Other implementations could have two independent Flash chips and provide chip 8 PICMG HPM.1 R1.0, May 4, 2007

17 select logic to avoid the need to copy firmware from one Flash chip to another. This specification abstracts these implementation details and intentionally leaves them outside the scope of this specification. IPM Controller Requirements REQ 2.8 REQ 2.9 REQ 2.10 IPM Controllers should provide redundant firmware images and support Automatic Rollback to increase the reliability of the Firmware Upgrade. IPM Controllers supporting redundant firmware images shall reestablish the previous version of the firmware when a Firmware Upgrade is interrupted or the IPM Controller detects that it is unable to continue the upgrade. IPM Controllers that do not support redundant firmware images shall return to a mode allowing further upgrades when a Firmware Upgrade is interrupted or the IPM Controller detects that it is unable to continue the upgrade. 2.2 Assisted Rollback 49 Although IPM Controller firmware redundancy is a desirable feature, some low-end IPM Controllers might be unable to support it. To provide an acceptable level of Firmware Upgrade reliability for such IPM Controllers, an Upgrade Agent can implement Assisted Rollback for these IPM Controllers. For example, an Upgrade Agent could save the last version of the firmware for these IPM Controllers and use the following procedure: 1. Obtain the current IPM Controller firmware from, for instance, an archive of old Upgrade Images and save it for future use (see steps 3 and 5). 2. Upgrade the IPM Controller with the new firmware. 3. If the upgrade is cancelled or interrupted, the Upgrade Agent uploads the previously saved version of the firmware to the IPM Controller at its earliest convenience. 4. If the upgrade passes successfully, the Upgrade Agent initiates self-test on the IPM Controller and checks its result. 5. If self-test fails, the Upgrade Agent uploads the saved (i.e. previous) version of the firmware to the IPM Controller. IPM Controller Requirement REQ 2.11 When an IPM Controller, that does not support redundant firmware images, detects that its firmware is not operational, it shall attempt to operate in a state in which its IPM Controller firmware can be upgraded. Upgrade Agent Requirement REQ 2.12 An Upgrade Agent may implement Assisted Rollback. 2.3 Boot Loader 50 In many implementations, the IPM Controller firmware contains a small independent section responsible for erasing and programming of the non-volatile memory containing the IPM Controller firmware. This firmware section is referred to as the Boot Loader. Some imple- PICMG HPM.1 R1.0, May 4,

18 mentations have Boot Loaders that are not stored in the IPM Controller on a permanent basis, but rather loaded to their RAM and executed from there at the beginning of Firmware Upgrade. 51 The Boot Loader either directly communicates with the Upgrade Agent over its IPM Controller interfaces and downloads the new firmware itself, or uses firmware downloaded by the main part of the IPM Controller firmware beforehand. In the first case, the Boot Loader could either program the firmware on-the-fly or cache the entire firmware and program it in one step. In the later case, the Boot Loader supports programming only and does not have to acquire the new firmware as it has already been downloaded. 52 Advanced IPM Controller implementations might not use any Boot Loader at all and might have the Firmware Upgrade capability fully incorporated into the IPM Controller firmware. In this case, the IPM Controller must support redundant firmware copies and each copy must be able to reprogram other copies. In addition, there needs to be a mechanism for switching between these copies. This mechanism can be a hardware-based one, e.g. some logic that preserves its state across resets and blackouts, or a software-based one, e.g. a small piece of software reading the last state from non-volatile memory and jumping to one of the images. 53 The main disadvantage of implementations with a Boot Loader is that it might be impossible to reliably upgrade the Boot Loader itself. For example, if the Boot Loader resides in a bootable part of Flash memory and its upgrade fails prior to completion, the Boot Loader and the entire IPM Controller might become non-operational. For this reason, IPM Controller implementations with a Boot Loader are not required (though they are encouraged) to provide upgrade capabilities for the Boot Loader by this specification. IPM Controller Requirement REQ 2.13 An IPM Controller using a Boot Loader that permanently resides on it should make its Boot Loader upgradeable via Firmware Upgrade. 2.4 Steps of sample Firmware Upgrade 54 For an example IPM Controller, a sample implementation of Firmware Upgrade consists of the following steps: 1. Reading, parsing and validating the Upgrade Image, retrieving capabilities and properties of the IPM Controller, matching the Upgrade Image to the IPM Controller. 2. Optionally uploading of the Boot Loader to the IPM Controller. 3. Creating a Backup Copy of the active firmware in the IPM Controller. 4. Erasing the Active Copy of the IPM Controller firmware. 5. Uploading new firmware to the IPM Controller and programming it to non-volatile memory. 6. Activating the newly programmed firmware. 7. Self-testing the new firmware and restoring the previous version of the firmware if the test fails. 55 Depending on implementation, the sequence of steps described in the above example can be different. Some of the steps, such as uploading of the Boot Loader, can be skipped altogether. The creation of a Backup Copy and erasing the Active Copy steps are not required for IPM 10 PICMG HPM.1 R1.0, May 4, 2007

19 Controllers having two symmetrical redundant images. The creation of a Backup Copy and erasing the Active Copy steps might be performed between uploading of new firmware and storing it in non-volatile memory. 56 The list of steps provided in the above example intentionally does not cover switching from the IPM Controller firmware to the Boot Loader in implementations supporting the latter. For better flexibility, IPM Controller implementers are allowed to perform this switching at any moment that makes sense for them. 2.5 Multi-component IPM Controllers 57 IPM Controllers can consist of more than one component. A component is a logical part of an IPM Controller, or related element, that can be upgraded. For example, an IPM Controller might contain or interface with an FPGA implementing some peripheral function. In this case, it is desirable to provide a method to upgrade the FPGA code on a running board. 58 Another example of a multi-component IPM Controller is an IPM Controller consisting of several microcontrollers. For example, one microcontroller could be responsible for IPMI and AdvancedTCA functionality, while another microcontroller could be responsible for controlling and monitoring FRU fans or managing other on-board devices. It is not necessary that there be a one-to-one relationship of hardware parts to components. 59 In order to support complex IPM Controllers that involve several upgradeable components, the Firmware Upgrade procedure makes special provisions for these configurations. Specifically, the IPM Controller is responsible for indicating to the Upgrade Agent the population and properties of the upgradeable components it includes. In addition, the Upgrade Image can include upgrades for several components. These parts of the Upgrade Image are referred to as firmware images. The Upgrade Agent is responsible for extracting these firmware images and transferring them to the target IPM Controller. IPM Controller Requirement REQ 2.14 IPM Controllers may support more than one upgradeable component. 2.6 Deferred firmware activation 60 In some cases, it is desirable to synchronously upgrade several FRUs in the system. One example of such a situation is an IPM Controller upgrade that affects the Payload. In this case, each IPM Controller Firmware Upgrade reduces the overall availability of the system. To reduce the impact of an IPM Controller Firmware Upgrade, system integrators can combine IPM Controller Firmware Upgrades for two or more FRUs. 61 To support such synchronized upgrades, this specification defines a feature called deferred firmware activation. This feature decouples uploading of new firmware to an IPM Controller and its activation. An Upgrade Agent supporting this feature first uploads new IPM Controller firmware to all FRUs that have to be upgraded and then initiates switching to the new IPM Controller firmware on all these FRUs at roughly the same time by sending the Activate firmware command defined in Table This feature requires certain support on the IPM Controller side. Specifically, the IPM Controller must be able to store new firmware without activating it. PICMG HPM.1 R1.0, May 4,

20 Requirement REQ 2.15 IPM Controllers and Upgrade Agents may support deferred firmware activation. IPM Controller Requirements REQ 2.16 REQ 2.17 REQ 2.18 IPM Controllers supporting deferred firmware activation shall indicate this feature to the higher-level management and an Upgrade Agent in response to Get target upgrade capabilities and Get component properties commands as defined in Table 3-3 and Table 3-5. IPM Controllers supporting deferred firmware activation shall be able to store new firmware without activating it. IPM Controllers supporting deferred firmware activation shall preserve newly uploaded firmware across IPM Controller resets and power cycles until activated with the Activate firmware command as defined in Table Upgrade Agent Requirements REQ 2.19 REQ 2.20 An Upgrade Agent should refuse to perform deferred firmware activation if any of the components affected by the provided Upgrade Image do not support deferred activation. An Upgrade Agent may provide the operator or higher-level management with a means of overriding the behavior recommended in REQ PICMG HPM.1 R1.0, May 4, 2007

21 Procedure 3 63 The Firmware Upgrade procedure consists of the following stages: Identification of the target IPM Controller and validation of its compatibility with the Upgrade Agent and the Upgrade Image (preparation stage). Creation of a Backup Copy of the active IPM Controller firmware and uploading of new firmware to the target IPM Controller (upgrade stage). Activation and self-testing of the new firmware (activation stage). 64 The preparation stage includes step 1, the upgrade stage includes steps 2 through 5 and the activation stage include steps 6 and 7 listed in Section 2.4, Steps of sample Firmware Upgrade. 65 Normally, a Firmware Upgrade includes all three of these stages. However, for deferred firmware activation the upgrade procedure is performed in two phases. At the first phase, only the preparation and upgrade stages are performed. After these stages have been performed for all IPM Controllers requiring Firmware Upgrade, the Upgrade Agent proceeds to the second phase. The Upgrade Agent ensures each IPM Controller contains the appropriate firmware from the Upgrade Image by performing the preparation stage before activating the previously downloaded firmware, therefore the second phase includes the preparation and activation stages. 66 The Firmware Upgrade procedure is orchestrated by the Upgrade Agent based on an Upgrade Image built for a specific IPM Controller. Specifically, the actions performed by the Upgrade Agent during Firmware Upgrade and their order are defined in the Upgrade Image. Refer to Section 4, Upgrade Image, for additional information on Upgrade Image format. 67 Firmware Upgrade commands are issued sequentially to the IPM Controller in order to support simple IPM Controller implementations that are not able to handle commands in parallel. The Upgrade Agent does not send another Firmware Upgrade command until it makes sure that the action requested by the previous commands have completed. 3.1 Handling long-duration commands 68 Many of the commands defined in the following sections can require considerable time to complete. An IPM Controller that receives one of these commands might be unable to fully complete it in time to meet IPMB response timing requirements. To avoid violation of the timing requirements, the IPM Controller responds with the Command in progress (80h) Completion Code to such a command before starting its actual processing. For most of these commands, when receiving this Completion Code, the Upgrade Agent polls the IPM Controller using the Get upgrade status command defined in Table 3-2 to monitor progress of the IPM Controller. For some of the commands however, the command is re-issued to PICMG HPM.1 R1.0, May 4,

22 monitor progress. Table 3-1 lists the long-duration Firmware Upgrade commands and the commands that are used to check status when the Command in progress (80h) Completion Code is returned. Table 3-1 Long-duration commands Command HPM.1 Table Long-duration command Command used to check status Get target upgrade capabilities 3-3 No NA Get component properties 3-5 No NA Abort Firmware Upgrade 3-15 No NA Initiate upgrade action 3-8 Yes Get upgrade status Upload firmware block 3-9 Yes Get upgrade status Finish firmware upload 3-10 Yes Get upgrade status Get upgrade status 3-2 No Get upgrade status Activate firmware 3-11 Yes Get upgrade status Query self-test results 3-12 No Query self-test results Query Rollback status 3-13 No Query Rollback status Initiate Manual Rollback 3-14 Yes Query Rollback status 69 All the commands identified as long-duration commands return the Command in progress (80h) Completion Code when a long-duration command is in progress. The Get upgrade status, Query self-test results and Query Rollback status commands are not longduration commands. These commands are called to check for the status of a long-duration command. The Get upgrade status command can return the value 80h in the Last Command Completion Code field to indicate that a long-duration command is still in progress. The Query self-test results and Query Rollback status commands can return the Command in progress (80h) Completion Code to indicate that the respective command is still in progress. 70 Table 3-2 defines the format of the Get upgrade status command. Table 3-2 Get upgrade status command Byte Request data 1 Data field PICMG Identifier. Indicates that this is a PICMG-defined group extension command. A value of 00h must be used. Response data 1 Completion Code (5) PICMG Identifier. Indicates that this is a PICMG-defined group extension command. A value of 00h must be used. Command in process. This field indicates the command code of the currently executing or the last long-duration command the IPM Controller has processed. Last Command Completion Code. This field contains the Completion Code of the last completed long-duration command. 80h = The current long-duration command is still in progress. Completion estimate. This optional field provides an estimation of the completion for the current long-duration command in progress when present. [7] - Reserved, write as 0b. [6:0] - Estimated percentage complete. This field might not be present if no estimate for completion is provided. 14 PICMG HPM.1 R1.0, May 4, 2007

23 IPM Controller Requirements REQ 3.1 REQ 3.2 REQ 3.3 REQ 3.4 REQ 3.5 REQ 3.6 REQ 3.7 IPM Controllers returning the Command in progress (80h) Completion Code for any of the long-duration commands defined in Table 3-1 as monitored via the Get upgrade status command shall support the Get upgrade status command as defined in Table 3-2. Each IPM Controller shall return the Command in progress (80h) Completion Code if the requested operation takes longer to respond than the maximum request-to-response time defined by the IPMB specification. Each IPM Controller shall indicate the command code of the currently executing or the last long-duration command in the Command in process field of its Get upgrade status response. Each IPM Controller shall return the command code for the Get upgrade status command in the Command in process field of its Get upgrade status response if no long-duration command has previously been issued. Each IPM Controller shall return Command in progress (80h) in the Last Command Completion Code field of its Get upgrade status response when the current longduration command is still in progress. Each IPM Controller shall indicate the Completion Code of the last long-duration command in the Last Command Completion Code field of its Get upgrade status response when there is no long-duration command in progress. Each IPM Controller should return a Completion estimate in percentage complete of the current command in progress in its Get upgrade status response when the Last Command Completion Code field value is 80h. Upgrade Agent Requirements REQ 3.8 REQ 3.9 REQ 3.10 When receiving the Command in progress (80h) Completion Code, an Upgrade Agent shall poll the IPM Controller for the status of the last command sent using the respective monitor command (refer to Table 3-1), and wait for the command completion before attempting to send another Firmware Upgrade command. An Upgrade Agent should wait at least 100 milliseconds between requests for status with a Get upgrade status command. An Upgrade Agent shall continue to poll the IPM Controller for upgrade status until either the long-duration command has completed or the upgrade timeout period, as defined by the Upgrade timeout value returned in the Get target upgrade capabilities response, has expired. PICMG HPM.1 R1.0, May 4,

24 3.2 Preparation stage 71 The purpose of the preparation stage of the Firmware Upgrade procedure is to compare the Firmware Upgrade capabilities of the target IPM Controller with the capabilities of the Upgrade Agent, and to verify whether an Upgrade Image is suitable for the target IPM Controller. These checks are necessary for reliable upgrade of the IPM Controller and are designed to avoid situations when an IPM Controller gets programmed with wrong firmware and becomes non-operational. 72 Some implementations of the Upgrade Agent provide a capability for an automatic search for compatible IPM Controllers and automatic upgrade of such IPM Controllers. In this case, the maintenance personnel just make new firmware available to the Upgrade Agent, which takes care of the rest of the upgrade process. Such implementations are outside the scope of this specification. 73 Figure 3-1 illustrates the preparation stage of IPM Controller Firmware Upgrade. Figure 3-1 Preparation stage of Firmware Upgrade procedure Get Device ID Match Device ID, Manufacturer ID, etc with the Upgrade Image no match Compare Current Revision with Upgrade Image Earliest Compatible Revision incompatible revisions Get target upgrade capabilities Match IPM Controller capabilities with Upgrade Image capabilities no match upgrade failure Get component properties all components queried query the next component Check firmware image sizes, flags, etc. check failed Command requests handled by the IPM Controller Command requests likely to be handled by the Boot Loader Logical actions performed by the Upgrade Agent 16 PICMG HPM.1 R1.0, May 4, 2007

25 74 Figure 3-1 intentionally does not define a particular moment when control is passed from the firmware to the Boot Loader (if there is any switching at all). It is up to implementer to choose when it could be done. For example, switching to the Boot Loader can be done upon receiving the first Get component properties request. 75 The preparation stage starts with reading the Device ID, Manufacturer ID and Product ID of the IPM Controller via the IPMI-defined Get Device ID command and comparing these IDs with the IDs provided in the Upgrade Image defined in Table 4-1. Then, the Upgrade Agent compares the revision of the current IPM Controller firmware and the Earliest Compatible Revision provided in the Upgrade Image to validate that the IPM Controller can be upgraded with the given Upgrade Image. 76 After this, the Upgrade Agent reads the upgrade capabilities of the target IPM Controller using the Get target upgrade capabilities command. If the IPM Controller does not support Firmware Upgrade over the interface used to send the Get target upgrade capabilities command defined in Table 3-3, the Completion Code 81h or C1h is returned. These Completion Codes indicate to the Upgrade Agent that Firmware Upgrade is not supported over that interface. In this way, an Upgrade Agent that supports an interface that is not required by this specification, such as the Payload Interface, can determine whether an IPM Controller supports that interface for the purpose of Firmware Upgrade. 77 When Firmware Upgrade is not supported over a specific IPM Controller interface, the IPM Controller can return the Completion Code 81h to the Get target upgrade capabilities, Get component properties, and Query self-test results commands, and still provide valid response data. This is useful for getting firmware version and other IPM Controller information over an interface that is not supported for Firmware Upgrade. This behavior is optional and an IPM Controller can not respond or respond with the Invalid Command (C1h) Completion Code to Firmware Upgrade commands received over an interface that is not supported for the purposes of Firmware Upgrade. 78 The IPM Controller always returns the Invalid Command (C1h) Completion Code over an unsupported interface for other Firmware Upgrade commands including the Initiate Upgrade Action, Upload firmware block, Finish firmware upload, Get upgrade status, Activate firmware, Query Rollback status, and Initiate Manual Rollback commands. 79 The upgrade capabilities indicate which optional features of Firmware Upgrade are supported by the IPM Controller. In addition, the upgrade capabilities indicate timeout values for various responses from the IPM Controller. This information is necessary for establishing reliable communication with the IPM Controller during an upgrade. 80 Some Firmware Upgrade commands may cause an IPM Controller to be inaccessible for a period of time. During this period of inaccessibility, a Shelf Manager, Carrier Manager, or other high-level management software might attempt to access the IPM Controller. For example, a Shelf Manager will periodically poll the IPM Controllers in the Shelf to verify that it can still communicate with the IPM Controller. During any periods of inaccessibility, failure to respond can result in the Shelf Manager, Carrier Manager, or other high-level management software taking actions, potentially including transition the IPM Controller to the M7 state, sending alerts or traps, triggering alarms, etc. While this specification recognizes these consequences of an IPM Controller being inaccessible, it does not specify how to deal with them and leaves it up to a system integrator to decide what to do about them. PICMG HPM.1 R1.0, May 4,