Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / phosphor-psu-code-mgmt / 56760ee2d42710153a9d8d9d73f537a326cb0e7c
commit56760ee2d42710153a9d8d9d73f537a326cb0e7c[log] [tgz]
authorShawn McCarney <shawnmm@us.ibm.com>Tue Feb 04 14:11:54 2025 -0600
committerMatt Spinler <spinler@us.ibm.com>Thu Feb 06 19:56:44 2025 +0000
treec89af9994d1ac2b7b4a2f0626a68c8374f3f8a20
parent638b84ae544defb76091053652042e19adfd2f53 [diff]
Set RequestedActivation to None in all cases

The Activation D-Bus object represents the activation state for an
associated Version object.

The Activation property of the Activation object indicates the current
activation state.  It has possible values like Ready, Activating,
Active, and Failed.

The RequestedActivation property of the Activation object indicates the
desired activation state.  It has possible values of Active and None.

When the PSU code update application wants to install firmware on one or
more PSUs, it sets the RequestedActivation property to Active.

If the code update is successful, the Activation property is set to
Active, and the RequestedActivation property is set to None.

However, if the code update fails, the RequestedActivation property is
not changed.  It continues to have the value Active.

There are many ways in which a code update can fail, such as:
* Unable to get PSU information from D-Bus
* No compatible PSUs found that need an update (happens during certain
  race conditions)
* Unable to find or start PSU code update service file
* PSU code update service fails

Since the RequestedActivation property has the value Active after a
failed code update, it prevents the PSU code update application from
performing another code update in the future.

It is desirable to allow PSU code updates to be attempted in the future.
For example, if a code update fails due to a bad PSU, and the customer
replaces the PSU with a good one that has downlevel code, the new PSU
should be code updated.

Modify the application so that the RequestedActivation property is
always set to None when an activation attempt ends, regardless of
whether it was successful.

Tested:
* Test where update succeeds
* Test where update fails on initial activation attempt
  * File path empty
  * Could not get list of PSU inventory paths
  * PSU queue is empty; no compatible PSUs needed update
  * Unable to get update service
  * Unable to start service
* Test where update fails after initial activation attempt
  * Test where fails to start service on second PSU
  * Test where second PSU update service fails
* Test where activation is restarted
  * Test where update succeeds
  * Test where fails on initial activation attempt
  * Test where update service fails

Change-Id: Ie124fdd399b1a9b02d8ad6b50040fa9ae6739ccd
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>
1 file changed
tree: c89af9994d1ac2b7b4a2f0626a68c8374f3f8a20
  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.