| commit | 7103f039fa45ea5907d810d713c75fbf05439a44 | [log] [tgz] |
|---|---|---|
| author | Amithash Prasad <amithash@meta.com> | Wed Jul 09 18:52:44 2025 -0700 |
| committer | Kuiying Wang <wangkuiying.wky@alibaba-inc.com> | Thu Aug 21 05:19:05 2025 +0000 |
| tree | 899c8536dce482a4395952b77bf4ad100078e575 | |
| parent | 0cbdb6e74472c0461a465bb2ceb8242e6343c578 [diff] |
Switch to hex string for post code representation in handler config As title, using list of integers only make parsing the JSON easier but would be really hard for developers to interpret or confirm if the correct post code is being used (Especially since most CPU vendors tend to document post codes as HEX strings). This also adds a name and description field to each handler configuration to allow for ease of documentation. Change-Id: I0215e98483aa6c5c3bae4f20d918118fdda9fa90 Signed-off-by: Amithash Prasad <amithash@meta.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.