Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / phosphor-psu-code-mgmt / 7cb5d05e5f27b4411e74748be85daaf2a708227a
commit7cb5d05e5f27b4411e74748be85daaf2a708227a[log] [tgz]
authorShawn McCarney <shawnmm@us.ibm.com>Fri Jan 03 18:27:45 2025 -0600
committerShawn McCarney <shawnmm@us.ibm.com>Tue Jan 14 20:30:29 2025 -0600
tree38ddd5c638b19fee5fb0ac9fd34b1d247bb4472e
parentb8590f56389a9dfd1af6ae4f722cc2fed46de918 [diff]
Handle repeated activation requests

PSU code versions are represented on D-Bus as a combination of Version
and Activation objects.

When this application determines that one or more PSUs need a code
update, it sets the RequestedActivation property to Active on the
Activation object. This triggers the code update.

The code is updated on each PSU in sequential order. This process can
take several minutes depending on the PSU type and number of PSUs.

During this long code update process, it is possible for one of the
following to occur:
* New PSU information is found on D-Bus
* A new PSU is plugged in (hot-plug)

If the new PSU requires a code update, the application will again set
the RequestedActivation property to Active on the Activation object. If
a code update is already occurring, the property change is currently
ignored. That means that the new PSU will not be code updated.

Enhance the application so that the second code update request is not
ignored. If it is requested while another code update is already in
progress, then restart the code update process once the current one
completes.

Tested:
* Tested a repeated code update request occurring due to new PSU
  information found on D-Bus.
* Tested a repeated code update request occurring due to a new PSU
  being plugged in.
* Verified that code update cycle was repeated if a request was deferred
  and the previous code update was successful.
* Verified that code update cycle was not repeated if a request was
  deferred and the previous code update failed.
* See the complete test plan at
  https://gist.github.com/smccarney/424f92af23fc25c6c2b6f67ee54d8919

Change-Id: Ie73e3f83c68945f6c85c2747003c36637791a24b
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>
2 files changed
tree: 38ddd5c638b19fee5fb0ac9fd34b1d247bb4472e
  1. services/
  2. src/
  3. test/
  4. tools/
  5. vendor-example/
  6. .clang-format
  7. .clang-tidy
  8. .gitignore
  9. LICENSE
  10. meson.build
  11. meson.options
  12. OWNERS
  13. README.md
README.md

phosphor-psu-code-mgmt

phosphor-psu-code-mgmt is a service to provide management for PSU code, including:

  • PSU code version
  • PSU code update

Building

meson build/ && ninja -C build

Unit test

  • Run it in OpenBMC CI, refer to local-ci-build.md

  • Run it in OE SDK, run below commands in a x86-64 SDK env:

    meson -Doe-sdk=enabled -Dtests=enabled build/
ninja -C build/ test  # Meson skips running the case due to it thinks it's cross compiling
# Manually run the tests
for t in `find build/test/ -maxdepth 1 -name "test_*"`; do ./$t || break ; done

Vendor-specific tools

This repo contains generic code to handle the PSU versions and updates. It depends on vendor-specific tools to provide the below functions on the real PSU hardware:

  • Get PSU firmware version
  • Get PSU model
  • Compare the firmware version
  • Update the PSU firmware

It provides configure options for vendor-specific tools for the above functions:

  • PSU_VERSION_UTIL: It shall be defined as a command-line tool that accepts the PSU inventory path as input, and outputs the PSU version string to stdout.
  • PSU_MODEL_UTIL: It shall be defined as a command-line tool that accepts the PSU inventory path as input, and outputs the PSU model string to stdout.
  • PSU_VERSION_COMPARE_UTIL: It shall be defined as a command-line tool that accepts one or more PSU version strings, and outputs the latest version string to stdout.
  • PSU_UPDATE_SERVICE: It shall be defined as a systemd service that accepts two arguments:
    • The PSU inventory DBus object;
    • The path of the PSU image(s).

For example:

meson -Dtests=disabled \
    '-DPSU_VERSION_UTIL=/usr/bin/psutils --raw --get-version' \
    '-DPSU_MODEL_UTIL=/usr/bin/psutils --raw --get-model' \
    '-DPSU_VERSION_COMPARE_UTIL=/usr/bin/psutils --raw --compare' \
    '-DPSU_UPDATE_SERVICE=psu-update@.service' \
    build

The above configures the vendor-specific tools to use psutils from phosphor-power to get the PSU version and model, compare PSU versions, and use psu-update@.service to perform the PSU firmware update, where internally it invokes psutils as well.

Usage

PSU version

When the service starts, it queries the inventory to get all the PSU inventory paths, invokes the vendor-specific tool to get the versions, and creates version objects under /xyz/openbmc_project/software that are associated with the PSU inventory path. If multiple PSUs are using the same version, multiple PSU inventory paths are associated.

E.g.

  • Example of system with two PSUs that have different versions:

     "/xyz/openbmc_project/software/02572429": {
   "Activation": "xyz.openbmc_project.Software.Activation.Activations.Active",
   "Associations": [
     [
       "inventory",
       "activation",
       "/xyz/openbmc_project/inventory/system/chassis/motherboard/powersupply1"
     ]
   ],
   "ExtendedVersion": "",
   "Path": "",
   "Purpose": "xyz.openbmc_project.Software.Version.VersionPurpose.PSU",
   "RequestedActivation": "xyz.openbmc_project.Software.Activation.RequestedActivations.None",
   "Version": "01120114"
 },
 "/xyz/openbmc_project/software/7094f612": {
   "Activation": "xyz.openbmc_project.Software.Activation.Activations.Active",
   "Associations": [
     [
       "inventory",
       "activation",
       "/xyz/openbmc_project/inventory/system/chassis/motherboard/powersupply0"
     ]
   ],
   "ExtendedVersion": "",
   "Path": "",
   "Purpose": "xyz.openbmc_project.Software.Version.VersionPurpose.PSU",
   "RequestedActivation": "xyz.openbmc_project.Software.Activation.RequestedActivations.None",
   "Version": "00000110"
 },

  • Example of system with two PSUs that have the same version:

     "/xyz/openbmc_project/software/9463c2ad": {
   "Activation": "xyz.openbmc_project.Software.Activation.Activations.Active",
   "Associations": [
     [
       "inventory",
       "activation",
       "/xyz/openbmc_project/inventory/system/chassis/motherboard/powersupply0"
     ],
     [
       "inventory",
       "activation",
       "/xyz/openbmc_project/inventory/system/chassis/motherboard/powersupply1"
     ]
   ],
   "ExtendedVersion": "",
   "Path": "",
   "Purpose": "xyz.openbmc_project.Software.Version.VersionPurpose.PSU",
   "RequestedActivation": "xyz.openbmc_project.Software.Activation.RequestedActivations.None",
   "Version": "01100110"
 },

PSU update

  1. Generate a tarball of PSU firmware image by generate-psu-tar tool.

    ./generate-psu-tar --image <psu-image> --version <version> --model <model> --manufacturer \
<manufacturer> --machineName <machineName> --outfile <psu.tar> --sign

  2. To update the PSU firmware, follow the same steps as described in code-update.md:

    • Upload a PSU image tarball and get the version ID;
    • Set the RequestedActivation state of the uploaded image's version ID.
    • Check the state and wait for the activation to be completed.

  3. After a successful update, the PSU image and the manifest is stored in BMC's persistent storage defined by IMG_DIR_PERSIST. When a PSU is replaced, the PSU's firmware version will be checked and updated if it's older than the one stored in BMC.

  4. It is possible to put a PSU image and MANIFEST in the built-in OpenBMC image in BMC's read-only filesystem defined by IMG_DIR_BUILTIN. When the service starts, it will compare the versions of the built-in image and the existing PSUs. If there is any PSU that has older firmware, it will be updated to the new firmware.