RTC Magazine

A recently adopted PICMG specification addresses an important gap that had existed in the PICMG hardware platform management (HPM) architecture: there was no spec-defined way to upgrade the firmware on management controllers. As a result, AdvancedTCA (ATCA) and MicroTCA systems built from a mix of components from different vendors could need a mix of incompatible firmware upgrade tools.

HPM.1, the Intelligent Platform Management Controller (IPMC) firmware upgrade specification, closes that gap for all the board and module level management controller types defined in the ATCA, MicroTCA and AdvancedMC (AMC) architectures. This specification is the first in what will likely be a series of PICMG specifications covering hardware platform management aspects of all three architectures. Even though this specification was developed in the PICMG 3.0 subcommittee, it is immediately applicable to the other two architectures as well.

Figure 1 shows the overall vision for HPM.1 firmware upgrades, which includes the board- and module-level controllers. Collectively referenced as IPM controllers in HPM.1, these also include AMC carrier IPMCs and module management controllers (MMCs), plus MicroTCA carrier management controllers (MCMCs) and enhanced MMCs (EMMCs). It also covers the ATCA and MicroTCA shelf managers that provide access to their respective types of shelves. HPM.1 was not engineered to cover upgrading of shelf manager firmware, which is usually substantially larger than board-level controller firmware. An upgrade agent applies HPM.1 upgrade images to the appropriate controllers by communicating with those controllers, often via the shelf managers and the intervening in-shelf buses, such as IPMB-0 and/or IPMB-L.

If all the IPM controllers in a shelf are HPM.1-compliant, a single HPM.1-compliant upgrade agent can upgrade the firmware in all the controllers, even if each element of the system is implemented by a different vendor, including the shelf managers and the upgrade agent, itself.

HPM.1 IPM controllers must support upgrades over IPMB-0 or IPMB-L, but can also support any other IPMI interface for this purpose. One popular option is the payload interface that links the IPM controller to the main processor(s) on a board. In this scenario, an upgrade agent could execute directly on a payload processor and communicate directly with an IPM controller over the payload interface. Figure 1 shows this option for the two MMCs, as an example.

Each upgrade image identifies the type (including the implementer and compatible version range) of IPM controllers it can be applied to. IPM controllers can identify themselves in these same dimensions. As a result, an independently implemented upgrade agent can apply firmware images of different types (for example, types A and B in Figure 1) to appropriate IPM controllers (for example, type A IPMCs and type B MMCs in Figure 1).

In addition to a descriptive header, each upgrade image includes a sequence of upgrade action records, some of which may include data, which is typically the new firmware to be uploaded. An upgrade agent communicates via HPM.1-defined IPMI commands with an IPM controller that is a candidate for upgrade and, for a compatible upgrade image and controller pair, proceeds to affect the upgrade actions on the controller.

Key Requirements

In addition to multi-vendor interoperability, the developers of HPM.1 in PICMG identified and achieved the following requirements for the firmware upgrades supported by this new facility:

• Reliable: an IPM controller can store redundant firmware images and automatically fall back to the prior image if it detects that a newly uploaded image has a serious error or loses connection to the upgrade agent. HPM.1 encourages and provides infrastructure for self-tests that the IPM controller can execute to validate a newly uploaded image.

• On-line: an IPM controller can accept a new firmware image while continuing to perform its normal management functions, executing a previously installed image.

• Deferrable: new firmware can be uploaded, but not activated until some later time, perhaps after all needed downloads are done and the system is in a low load period.

• Flagged payload effects: IPM controllers and upgrade images indicate whether an upgrade can affect the payload of the parent field replaceable unit; any such impact should be the rare exception, but may not be entirely avoidable. It may be critical for the upgrade agent and/or its operator to know whether an upgrade operation could require, for example, a reset of the payload.