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

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>

show more ...

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

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>

show more ...

Set ExtendedVersion property on Activations

Activation objects are created by this application in three scenarios:
1. When an InterfacesAdded event notifies the application about a new
PSU image

Set ExtendedVersion property on Activations

Activation objects are created by this application in three scenarios:
1. When an InterfacesAdded event notifies the application about a new
PSU image that was uploaded to IMG_DIR (/tmp/images).
2. When getting the firmware version that is already running on a PSU
in the system.
3. When a firmware version is found in the file system (IMG_DIR_BUILTIN
or IMG_DIR_PERSIST).

In scenario #2, there are two Activation properties that are not set:
1. Path: the file system path to the image directory.
2. ExtendedVersion: contains the manufacturer and model.

In scenario #3, a firmware version may be found in the file system that
is the same as the version running on a PSU. In this case, the
Activation object has already been created. The Path property on the
existing Activation is set to the file system path.

However, the ExtendedVersion property of the existing Activation is not
set. Due to this, the Activation has no manufacturer or model
information. This means it cannot be used to update other PSUs.

Solve this problem by setting the ExtendedVersion property of the
existing Activation when a matching version is found in the file system.
This will enable the Activation to obtain the manufacturer and model
information. This in turn will allow the Activation to be used to update
other PSUs that are not running the latest version.

Tested:
* Verified that extendedVersion, manufacturer, and model data members
are set when the Activation constructor is called.
* Verified that extendedVersion, manufacturer, and model data members
are set when the new, overridden extendedVersion() method is called.
* Verified that the ExtendedVersion property is set by scanDirectory()
if an Activation already exists.
* For the complete test plan see:
https://gist.github.com/smccarney/2a3bf72c6faa436199a70968cd99e30e

Change-Id: I7107b8c1d631ada5cd55648f92cf2c1e5cd90778
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>

show more ...

Verify PSU is present before code update

When an Activation is set to the Activating state, it checks all the
PSUs in the system to see which ones are compatible. Compatibility is
determined based o

Verify PSU is present before code update

When an Activation is set to the Activating state, it checks all the
PSUs in the system to see which ones are compatible. Compatibility is
determined based on the Model and Manufacturer properties. It performs a
code update only on compatible PSUs.

Update the Activation class to also check whether a PSU is present. A
code update should not be attempted on a missing PSU. The attempt will
fail, and that will cause the remaining PSUs to be skipped.

Tested:
* Activation::startActivation()
* Test where PSU is not present
* Verify it is skipped
* Test where PSU is present
* Verify the compatibility is checked
* Test where PSU is not compatible
* Verify it is skipped
* Test where PSU is compatible
* Verify it is code updated
* Activation::isPresent()
* Test where PSU is present
* Test where PSU is not present
* Test where a D-Bus error occurs
* Verify error is written to the journal
* Verify false is returned

Change-Id: I5647e51177d84d22f6ae5a38afa970243fe9ecdd
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>

show more ...

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() statemen

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>

show more ...

Rename getPSUInventoryPath to getPSUInventoryPaths

Rename the utils method/function getPSUInventoryPath() to
getPSUInventoryPaths(). The method/function returns multiple paths in a
vector, so the n

Rename getPSUInventoryPath to getPSUInventoryPaths

Rename the utils method/function getPSUInventoryPath() to
getPSUInventoryPaths(). The method/function returns multiple paths in a
vector, so the name should be plural. This will make the return type
more clear. Currently the name implies only one path will be returned.

Tested:
* Verified all automated tests build and run successfully
* Verified getPSUInventoryPaths() returns correct data

Change-Id: I7e215c37e3ce1eb27313bc51348c7f7335c8f67a
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>

show more ...

Convert from log() to lg2()

Convert from the old log() API to the new lg2() API for logging journal
messages. The new API is simpler to use, and the old API may be
deprecated in the future.

Tested:

Convert from log() to lg2()

Convert from the old log() API to the new lg2() API for logging journal
messages. The new API is simpler to use, and the old API may be
deprecated in the future.

Tested:
* Tested all lg2() calls to verify the resulting journal message was
correct.
* For the complete test plan, see
https://gist.github.com/smccarney/f4ed140bf7a46773b31c76b488e739dc

Change-Id: Ieb46c5d1481ceb51e5b0d51392b1c32596d8eac8
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>

show more ...

Get model using command line tool

Get the PSU model using a command line tool specified in the meson
options. The default tool is 'psutils --get-model'. The tool should
get the model data directly

Get model using command line tool

Get the PSU model using a command line tool specified in the meson
options. The default tool is 'psutils --get-model'. The tool should
get the model data directly from the PSU.

This is more accurate than getting the Model property of the Asset
interface on D-Bus. Inventory Manager saves its state to files. When
the BMC is booted, Inventory Manager initializes itself using the saved
state. This is necessary to handle the scenario where the BMC is
rebooted while the rest of the system is powered on (such as a
concurrent BMC code update).

However, if all power was removed from the system, a PSU may have been
added/removed/replaced while the BMC was offline. When the BMC boots,
the Inventory Manager saved state is not correct.

Eventually the PSU monitoring application will update the model on
D-Bus, but this can take a non-trivial amount of time. This is
especially true if EntityManager is used to provide the PSU bus and
address information to the PSU monitoring application.

Tested:
* Verified all automated tests build and run successfully
* Verified application uses command line tool to obtain model
* Verified command line tool was returning the correct model
* Test where command line tool fails with non-zero exit code
* Tested where all PSU information available when application starts
* Tested where PSU information is obtained after application starts
using the InterfacesAdded handler
* Tested where PSU presence changes and is obtained by the
PropertiesChanged handler
* Full test plan is available at
https://gist.github.com/smccarney/87bd821a6d317ec0915d1f162028ff01

Change-Id: Ia9d35850aa6ac27dd006679991272232d67390ff
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>

show more ...

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

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>

show more ...

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda forma

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda formatting also changed, so we have made changes to the
organization default style format to better handle lambda formatting.

See I5e08687e696dd240402a2780158664b7113def0e for updated style.
See Iea0776aaa7edd483fa395e23de25ebf5a6288f71 for clang-18 enablement.

Change-Id: I08efc0671773edfae814ebcda5c01389155e2cac
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

Fix spelling mistakes using codespell

This commit corrects various spelling mistakes throughout the
repository. The corrections were made automatically using `codespell`[1]
tool.

[1]: https://githu

Fix spelling mistakes using codespell

This commit corrects various spelling mistakes throughout the
repository. The corrections were made automatically using `codespell`[1]
tool.

[1]: https://github.com/codespell-project/codespell

Change-Id: Icafafe827d67c9b6cc5c3f6bfb204fe425e91a32
Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>

show more ...

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest .clang-format from the docs repository and reformat the
repository.

Change-Id: Idb72665dbadfa8afd569a2e0e254d84f0a2108d3
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

sdbusplus: use shorter type aliases

The sdbusplus headers provide shortened aliases for many types.
Switch to using them to provide better code clarity and shorter
lines. Possible replacements are

sdbusplus: use shorter type aliases

The sdbusplus headers provide shortened aliases for many types.
Switch to using them to provide better code clarity and shorter
lines. Possible replacements are for:
* bus_t
* exception_t
* manager_t
* match_t
* message_t
* object_t
* slot_t

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Ie530f2c63000bbfac7c5fbbc74ebe6bc8c07fb1a

show more ...

exception: switch to public sdbus exception

SdBusError was intended to be a private error type inside sdbusplus.
Switch all catch locations to use the general sdbusplus::exception type.

Signed-off-

exception: switch to public sdbus exception

SdBusError was intended to be a private error type inside sdbusplus.
Switch all catch locations to use the general sdbusplus::exception type.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I3f173e46d23ab9a21f37356df848f5226ccf7962

show more ...

Add updateable association

Add 'updateable' association to the functional PSU firmware.
This 'updateable' association can be used to mark all the
firmware components which can be programmable from B

Add updateable association

Add 'updateable' association to the functional PSU firmware.
This 'updateable' association can be used to mark all the
firmware components which can be programmable from BMC
interfaces like Redfish.

Resolves openbmc/phosphor-psu-code-mgmt#2

Tested: Verify unit tests success;
Verify the updateable associations are created for PSU firmware
objects on Witherspoon, and the Redfish has "Updateable": true
for the PSU images.

Signed-off-by: Lei YU <mine260309@gmail.com>
Change-Id: I579121587b0d2c14f08beceaa68e380eaf1eefd9

show more ...

Activation: add BMC reboot guard

BMC shall not reboot during PSU update, otherwise it has the risk of
putting the PSU in a bad state.
So add BMC reboot guard in ActivationBlocksTransition to enable

Activation: add BMC reboot guard

BMC shall not reboot during PSU update, otherwise it has the risk of
putting the PSU in a bad state.
So add BMC reboot guard in ActivationBlocksTransition to enable reboot
guard when PSU update is started, and disable it when it's finished or
failed.

During test, it's found that the ActivationBlocksTransition is created
too early before checking the PSU compatibility, it is fixed by
constructing ActivationBlocksTransition after the check.

Tested: Verify the BMC guard is enabled and disabled during PSU update.

Signed-off-by: Lei YU <mine260309@gmail.com>
Change-Id: I405fe640929aa91ecbcb3d48e19309d38b6849e5

show more ...

Check and sync PSU image when PSU is plugged in

When a PSU is plugged out and in, the service shall check the version
and do update if it is with an old software.
When the PSU is plugged in, the mod

Check and sync PSU image when PSU is plugged in

When a PSU is plugged out and in, the service shall check the version
and do update if it is with an old software.
When the PSU is plugged in, the model is not available for a while, so
the service subscribe the model property as well, and only create the
software object when both present and model properties are set.

Tested: With dummy update service, verify on Witherspoon that when PSU
is plugged out (by setting "Present" property in inventory), the
software object is removed, and when it's pluggd int (by setting
"Present" property), the software object is created after the
model is got, and is upgraded by a newer image stored in BMC
filesystem.

Signed-off-by: Lei YU <mine260309@gmail.com>
Change-Id: Ia7516e5bc9c642158b216036bcddf404157f9204

show more ...

Activation: remove old objects after update done

The update on PSUs is one-by-one, after each PSU is updated, notify
ItemUpdater by onUpdateDone() so that the old object for the PSU is
removed.

Tes

Activation: remove old objects after update done

The update on PSUs is one-by-one, after each PSU is updated, notify
ItemUpdater by onUpdateDone() so that the old object for the PSU is
removed.

Tested: With dummy PSU image and update service, verify the old
objects are removed on Witherspoon.

Change-Id: I212b8cba9570ad96083d362bf57691fdabb4e42f

show more ...

Sync PSU images on service startup

On service startup, it shall check the PSU images, find a latest
version, and update to the PSUs that are not with this version.

Tested: With dummy image and serv

Sync PSU images on service startup

On service startup, it shall check the PSU images, find a latest
version, and update to the PSUs that are not with this version.

Tested: With dummy image and service, test on Witherspoon with 2
different running PSU software:
* When startup without stored image, the serive tries to update an older
PSU but it does not have PSU image, so it's skipped with below journal
log:
Automatically update PSU
No image for the activation, skipped
* When startup with an older image stored in BMC, it behaves the same as
above.
* When startup with a new image stored in BMC, it updates the PSUs, with
below example journal log:
Automatically update PSU
Starting Update PSU
/xyz/openbmc_project/inventory/system/chassis/motherboard/powersupply0
/var/lib/obmc/psu/2B1D...
Started Update PSU
/xyz/openbmc_project/inventory/system/chassis/motherboard/powersupply0
/var/lib/obmc/psu/2B1D.
Starting Update PSU
/xyz/openbmc_project/inventory/system/chassis/motherboard/powersupply1
/var/lib/obmc/psu/2B1D...
Started Update PSU
/xyz/openbmc_project/inventory/system/chassis/motherboard/powersupply1
/var/lib/obmc/psu/2B1D.

Signed-off-by: Lei YU <mine260309@gmail.com>
Change-Id: I6d676c5a4441685fb2b5920455f439c00f6097af

show more ...

Activation: support updating PSU from stored image

The previous code assume the image to update is from IMG_DIR.
Now it needs to update PSU from pre-built or stored images.

This commit adds the sup

Activation: support updating PSU from stored image

The previous code assume the image to update is from IMG_DIR.
Now it needs to update PSU from pre-built or stored images.

This commit adds the support, by constructing the systemd unit based on
Activation's Path property instead of IMG_DIR.

Tested: Verify on Witherspoon that it is able to activate a stored
image.

Signed-off-by: Lei YU <mine260309@gmail.com>
Change-Id: I0936bb921b22c7f67aee9689e3695e6b21703a29

show more ...

Scan directories that store PSU images on start

When the service starts, scan the directories that store PSU images,
including the built-in images, and the saved images during PSU update.

When the

Scan directories that store PSU images on start

When the service starts, scan the directories that store PSU images,
including the built-in images, and the saved images during PSU update.

When the scanned image is different than the running images, create
activation/version object;
When the scanned image is the same as the running images, update the
version object's path to indicate the PSU image path, so it could be
used for future update in case a PSU is replaced with a different
software.

Tested: On Witherspoon, fake create a dummy PSU image with a different
version than running PSU, verify a new object is created on
restart;
fake creating a dummy PSU image with a same version as a running
PSU, verify no new object is created, but the "Path" property is
set to the PSU image directory.

Signed-off-by: Lei YU <mine260309@gmail.com>
Change-Id: I860b978250a718eb82d948a1c88bd8f41bb2b2e3

show more ...

Activation: store PSU image in persistent storage

When an activation succeeds, store the PSU image into persistent
storage, which will be used in future in case a PSU is replaced, and the
BMC will n

Activation: store PSU image in persistent storage

When an activation succeeds, store the PSU image into persistent
storage, which will be used in future in case a PSU is replaced, and the
BMC will need to update the replaced PSU's firmware.
Only the latest image is saved, and old ones are removed for each model.

Tested: On witherspoon, verify the PSU image is saved in persistent
storage after a successful activation with dummy service, and
the FilePath inteface is updated with the stored path.
And after another successful activation, the new image is saved
and the old one is removed in persistent storage.

Signed-off-by: Lei YU <mine260309@gmail.com>
Change-Id: I11f3d4a91d045d2316242d8eef968f05250d862e

show more ...

Refactor: Make Activation inherit FilePath interface

Previously Version inherits FilePath interface to provide the
information of the file path property of a software, and Activation was
using pre-d

Refactor: Make Activation inherit FilePath interface

Previously Version inherits FilePath interface to provide the
information of the file path property of a software, and Activation was
using pre-defined location to find the image path (IMG_DIR / versionId).

Now the code is going to support pre-built image and stored image during
update, the Activation class needs to know the file path to perform the
update.

So this commit "moves" the FilePath from Version to Activation.

Tested: Verify the "Path" property on FilePath still exists on the DBus
object after uploading a tarball.

Signed-off-by: Lei YU <mine260309@gmail.com>
Change-Id: I37b41eaa93cd239ab7732f6fac9400410995ca71

show more ...

Activation: check compatiblity of uploaded software

Before activation, check if the PSU inventory's manufacturer and model
matches the uploaded software, to make sure the software is not updated
to

Activation: check compatiblity of uploaded software

Before activation, check if the PSU inventory's manufacturer and model
matches the uploaded software, to make sure the software is not updated
to a incompatible PSU.

The model check is mandatory, and if the PSU manufacturer is empty,
ignore the manufacturer check.

Tested: Upload a dummy tarball with incompatible model, verify the
activation fails;
Upload a dummy tarball with compatible model, verify the
activation succeeds with a dummy update service.
Also added unit tests for several cases:
* Update on a PSU that model is incompatible;
* Update on a PSU that the manufacture is incompatible;
* Update on a PSU that the menufacture is empty;
* Update on 4 PSUs that the second one is incompatible.

Signed-off-by: Lei YU <mine260309@gmail.com>
Change-Id: Ia1b6a3fa6c98cdea1ea93c917c0938d4a60f0911

show more ...

Activation: create associations

Create activation, functional, activate associations during PSU update.

Tested: With dummy psu update service, verify the assocations are
created when the PS

Activation: create associations

Create activation, functional, activate associations during PSU update.

Tested: With dummy psu update service, verify the assocations are
created when the PSU update is completed, and not created
when PSU update fails.

Signed-off-by: Lei YU <mine260309@gmail.com>
Change-Id: I3d457e65b55066b93f7fc9a3311093dcec05d020

show more ...