commit | ddf525f2df00fbe12f592416f9ea2a6ffdd54fbc | [log] [tgz] |
---|---|---|
author | Shawn McCarney <shawnmm@us.ibm.com> | Fri Sep 27 09:27:06 2024 -0500 |
committer | Shawn McCarney <shawnmm@us.ibm.com> | Fri Sep 27 09:46:56 2024 -0500 |
tree | 90dfd15676844f22115ead424425ee90f1b9aa93 | |
parent | 799f5149d7164723da65d27db39ec8ed851be325 [diff] |
Only store images from IMG_DIR New PSU images are uploaded/downloaded to IMG_DIR (normally /tmp/images). After all PSUs have been updated with the new image, the image is copied to IMG_DIR_PERSIST (normally /var/lib/obmc/psu). This stores the image in a persistent location that will exist beyond a BMC reboot. If a PSU is replaced in the future, and the new PSU has old code, the PSU image from IMG_DIR_PERSIST is used to update it. The application currently also copies PSU images from IMG_DIR_BUILTIN (normally /usr/share/obmc/psu) to IMG_DIR_PERSIST. This is undesirable for two reasons: * Wastes flash space since IMG_DIR_BUILTIN is already persistent. * IMG_DIR_PERSIST is located in a directory that is shared between both BMC images ("A" side and "B" side). This means the PSU image will be found by both BMC images. This may be undesirable behavior, such as if the other BMC image has not been tested with this PSU image. Modify the storing logic so that only PSU images from IMG_DIR are copied to IMG_DIR_PERSIST. Tested: * Verified that a PSU image in IMG_DIR is copied to IMG_DIR_PERSIST * Verified that a PSU image in IMG_DIR_PERSIST is not copied to IMG_DIR_PERSIST * Verified that a PSU image in IMG_DIR_BUILTIN is not copied to IMG_DIR_PERSIST Change-Id: I69fbbefffb08374cffcb86b9037780b7a312c459 Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>
phosphor-psu-code-mgmt is a service to provide management for PSU code, including:
meson build/ && ninja -C build
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
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:
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: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.
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" },
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
To update the PSU firmware, follow the same steps as described in code-update.md:
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.
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.