Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / phosphor-psu-code-mgmt / 487e2e19bf667a668d67034d86548031ce2313d4
commit487e2e19bf667a668d67034d86548031ce2313d4[log] [tgz]
authorShawn McCarney <shawnmm@us.ibm.com>Mon Nov 25 17:19:46 2024 -0600
committerShawn McCarney <shawnmm@us.ibm.com>Mon Dec 09 17:03:41 2024 -0600
treee762437ab0e76700890e065750745c86597904a7
parentd57bd2f2b15738da1a38e3caaa193a7cc713adca [diff]
Improve error handling for exceptions and asserts

The phosphor-psu-code-manager application currently exits abnormally due
to the following conditions:
* Uncaught exception
* False assert() statement

An abnormal exit can result in a core dump and/or a BMC dump. It also
causes the service to be restarted. If the failure condition remains,
the restarts will fail repeatedly, and systemd will stop trying to start
the service.

Improve error handling for exceptions in the following ways:
* Add try/catch blocks to the following locations:
  * Code that calls functions that throw and needs to handle exceptions.
    * For example, code looping over PSU objects may need to handle an
      exception for one PSU and then continue to the remaining PSUs.
  * D-Bus PropertiesChanged and InterfacesAdded event handlers.
    * Do not allow exceptions to escape to the sdbusplus stack frames.
  * main()
    * Last line of defense; catching avoids a core dump.
* Write exception error message to the journal if appropriate

Replace assert statements with exceptions or error messages to the
journal.

Tested:
* Tested all modified functions/methods.
* Verified that all exceptions were caught and logged to the journal if
  appropriate.
* Verified that asserts were replaced by exceptions and logging.
* See complete test plan at
  https://gist.github.com/smccarney/b4bf568639fedd269c9737234fa2803d

Change-Id: I933386e94f43a915b301d6aef7d91691816a0548
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>
8 files changed
tree: e762437ab0e76700890e065750745c86597904a7
  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.