| commit | 20297dfbd96709af18b6046db76c99c79c149d59 | [log] [tgz] |
|---|---|---|
| author | Manojkiran Eda <manojkiran.eda@gmail.com> | Fri Aug 08 08:22:22 2025 +0530 |
| committer | Kuiying Wang <wangkuiying.wky@alibaba-inc.com> | Thu Aug 21 05:24:58 2025 +0000 |
| tree | 1c293a5b199f50b918ec59a316054833f2908774 | |
| parent | 7103f039fa45ea5907d810d713c75fbf05439a44 [diff] |
Add PostCodeDataVersion to the persisted data Commit `06b1dbe9c768adf8921e4c1cb915538486b5a7ca` changed the serialized format of `PostCodeData` without providing backward or forward compatibility. Previously, persisted data was stored as a `uint64_t`, whereas the updated code now expects a `vector<uint8_t>`. When the new code attempts to deserialize old data, Cereal interprets the `uint64_t` value as the vector size, resulting in excessively large allocations and out-of-memory errors during BMC initialization. This commit introduces a `PostCodeDataVersion` field in the serialized file. On startup, `post-code-manager` checks this version before deserialization and discards outdated data if the version does not match, ensuring a clean start without triggering memory issues. Tested: Verified that legacy persisted data is detected and discarded, allowing `post-code-manager` to initialize with fresh data. No out-of-memory conditions observed. Change-Id: I698556a1b9781d7d869daf18348bdcf6ec82d6a7 Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>
This phosphor-post-code-manager repository provides an infrastructure to persist the POST codes in BMC filesystem & it also owns the systemd services that are responsible for exposing the BIOS Post Codes to rest of the world via redfish.
To build phosphor-post-code-manager package , do the following steps:
meson <build directory> ninja -C <build directory>
This repository ships xyz.openbmc_project.State.Boot.PostCode.service systemd service along with its template version and a tiny binary that exposes the necessary dbus interfaces & methods to extract the POST codes per boot cycle.
This repository is tightly coupled with phosphor-host-postd OpenBMC repository which is responsible for emitting the dbus signals for every new POST Code.
phosphor-post-code-manager is architected to look for the property changed signals which are being emitted from the service that hosts Value property on xyz.openbmc_project.State.Boot.Raw interface & archive them per boot on the filesystem, so that those can be exposed over redfish
Platforms can provide custom configuration to allow for special handling of specific postcodes. Special handling include starting user configured systemd unit files and/or creating a structured event as defined by the user. The JSON configuration file can be passed in using the --config PATH or -c PATH options.
Configuration format:
[ { "primary": [123], "secondary": [234, 123], "targets": ["my_special.service"] }, { "primary": [999], "targets": ["power_failure.service"], "event": { "name": "xyz.openbmc_project.State.Power.PowerRailFault", "arguments": { "POWER_RAIL": "MyDevice", "FAILURE_DATA": "" } } } ]
Each entry in the array describes a special handler for a specific post code.
primary - [required] The primary post code to match.secondary - [optional] The secondary post code to match. If not present, the match will be for all post codes which match just the primarytargets - [optional] List of systemd targets to start when the matching post code is received.event - [optional] The descriptor of the event to create with phosphor-logging.event::name - Name of the event log. See log-create --list for a list of possible events which can be createdevent::arguments - The named argument list which will be used to create the event.