Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / phosphor-psu-code-mgmt / 799f5149d7164723da65d27db39ec8ed851be325
commit799f5149d7164723da65d27db39ec8ed851be325[log] [tgz]
authorShawn McCarney <shawnmm@us.ibm.com>Thu Sep 26 14:50:25 2024 -0500
committerShawn McCarney <shawnmm@us.ibm.com>Thu Sep 26 19:17:13 2024 -0500
tree30592b19b706f441ec2085da9fa8e00117b9ff31
parentfb86e7947e455a33ffd04a8653f520c1b3ac2352 [diff]
Support ALWAYS_USE_BUILTIN_IMG_DIR in IA handler

Support the new ALWAYS_USE_BUILTIN_IMG_DIR meson option in the
InterfacesAdded handler for software versions.

This handler notifies the application when a new software version is
created on D-Bus.  When a new PSU image is uploaded to the IMG_DIR
(/tmp/images) directory, the xyz.openbmc_project.Software.Version
service creates a new D-Bus object with the Version interface.

If the ALWAYS_USE_BUILTIN_IMG_DIR option is specified, the new PSU image
in IMG_DIR should be ignored.  Only PSU images stored in IMG_DIR_BUILTIN
(/usr/share/obmc/psu) are used to update PSUs.

Tested:
* Built with ALWAYS_USE_BUILTIN_IMG_DIR set to false (the default)
  * Verified that a new PSU image uploaded to /tmp/images is installed
    on all PSUs.
  * Verified new PSU image is copied to /var/lib/obmc/psu
  * Verified new PSU image is removed from /tmp/images
  * Verified that after BMC is rebooted new PSU image still exists in
    /var/lib/obmc/psu
* Built with ALWAYS_USE_BUILTIN_IMG_DIR set to true
  * Verified that a new PSU image uploaded to /tmp/images is ignored and
    no PSUs are updated.
  * Verified new PSU image is not copied to /var/lib/obmc/psu
  * Verified new PSU image is not removed from /tmp/images
  * Verified that after BMC is rebooted new PSU image no longer exists
    in /tmp/images

Change-Id: I2f71593f786eac86bdf6f484cc0220e0e6b0f4b7
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>
1 file changed
tree: 30592b19b706f441ec2085da9fa8e00117b9ff31
  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
  • 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_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_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 and compare the 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-bin 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, the stored image (after PSU update), and the existing PSUs, if there is any PSU that has an older firmware, it will be updated to the newest one.