fw_update: add pre-post update conditions Description: This commit introduces the concept of pre and post update conditions in the firmware update process to meet the code-update design[1]. Allow platform specific systemd units to run before an update starts and after an update has finished successfully. A pre-update condition is executed before the firmware update flow starts, and a failing one aborts the update. A post-update condition is executed only after the update has succeeded, as defined by the design; no condition is executed once the update itself has failed. [1]: https://github.com/openbmc/docs/blob/master/designs/code-update.md#pre-and-post-update-conditions - Added a new JSON schema for defining pre and post update conditions - A condition service that needs arguments is configured as a systemd template unit and receives all supported named arguments as its escaped instance name Motivation: The firmware update process may require certain conditions to be met before and after the update. This feature allows for greater flexibility and control over the update process, ensuring that the system is in a valid state before and after the update. Tested: Platform: Yosemite 4, Sentinel Dome T2 in slot 1, BIC firmware update over PLDM (EID 10, ast1030 v2023SD). - Parameterized post update condition: pldm resolved yv4-bic-post-update@.service into the escaped instance boardName=Yosemite_4_Sentinel_Dome_T2_Slot_1,applyTime=OnReset, systemd job 34591 returned "done" and the update completed. - Non parameterized pre update condition: pldm started yv4-bic-pre-update.service without an instance name, dropping the arguments as expected, job 21105 returned "done" and the update proceeded into the transfer. - No condition configured: with both targets omitted for the component, both conditions were skipped and the update still completed, so the base update flow is unaffected. - Unit tests pass in the OpenBMC unit test container, with the format and cppcheck stages clean. Not covered on hardware: a condition that fails, a condition unit that hits its start timeout, and a manager erased while its condition is still running. Change-Id: Ie862c8ec6aa41db3239a6e7438953326e99a7bc3 Signed-off-by: Unive Tien <unive.tien.wiwynn@gmail.com>
PLDM (Platform Level Data Model) is a key component of the OpenBMC project, providing a standardized data model and message formats for various platform management functionalities. It defines a method to manage, monitor, and control the firmware and hardware of a system.
The OpenBMC PLDM project aims to implement the specifications defined by the Distributed Management Task Force (DMTF), allowing for interoperable management interfaces across different hardware and firmware components.
To build and run PLDM, you need the following dependencies:
MesonNinjaAlternatively, source an OpenBMC ARM/x86 SDK.
To build the PLDM project, follow these steps:
meson setup build && meson compile -C build
The simplest way of running the tests is as described by the meson man page:
meson test -C build
Alternatively, tests can be run in the OpenBMC CI docker container using these steps.
pldm daemon accepts a command line argument --verbose or --v or -v to enable the daemon to run in verbose mode. It can be done via adding this option to the environment file that pldm service consumes.
echo 'PLDMD_ARGS="--verbose"' > /etc/default/pldmd systemctl restart pldmd
rm /etc/default/pldmd systemctl restart pldmd
For complete documentation on the functionality and usage of this repository, please refer to the docs folder.