Name Date Size #Lines LOC

..--

inc/H--205173

service_files/H--2418

src/H--493401

subprojects/H--2720

.clang-formatH A D01-Feb-20253.7 KiB137135

LICENSEH A D05-Sep-201811.1 KiB202169

OWNERSH A D27-Jun-20251.8 KiB5348

README.mdH A D29-May-20252.9 KiB8367

meson.buildH A D09-Jul-20252.4 KiB9482

meson.optionsH A D01-Feb-2025601 2827

post-code-handlers.jsonH A D29-May-20253 21

README.md

1# phosphor-post-code-manager
2
3This phosphor-post-code-manager repository provides an infrastructure to persist
4the POST codes in BMC filesystem & it also owns the systemd services that are
5responsible for exposing the BIOS Post Codes to rest of the world via redfish.
6
7## To Build
8
9To build phosphor-post-code-manager package , do the following steps:
10
11```bash
12meson <build directory>
13ninja -C <build directory>
14```
15
16## Hosted Services
17
18This repository ships `xyz.openbmc_project.State.Boot.PostCode.service` systemd
19service along with its
20[template version](https://github.com/openbmc/docs/blob/master/designs/multi-host-postcode.md)
21and a tiny binary that exposes the necessary
22[dbus interfaces & methods](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/State/Boot/PostCode.interface.yaml)
23to extract the POST codes per boot cycle.
24
25## Architecture
26
27This repository is tightly coupled with
28[phosphor-host-postd](https://github.com/openbmc/phosphor-host-postd) OpenBMC
29repository which is responsible for emitting the dbus signals for every new POST
30Code.
31
32phosphor-post-code-manager is architected to look for the property changed
33signals which are being emitted from the service that hosts
34[Value](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/State/Boot/Raw.interface.yaml)
35property on `xyz.openbmc_project.State.Boot.Raw` interface & archive them per
36boot on the filesystem, so that those can be exposed over
37[redfish](https://github.com/openbmc/docs/blob/master/designs/redfish-postcodes.md)
38
39## Special Post code handling/eventing
40
41Platforms can provide custom configuration to allow for special handling of
42specific postcodes. Special handling include starting user configured systemd
43unit files and/or creating a structured event as defined by the user. The JSON
44configuration file can be passed in using the `--config PATH` or `-c PATH`
45options.
46
47Configuration format:
48
49```json
50[
51  {
52    "primary": [123],
53    "secondary": [234, 123],
54    "targets": ["my_special.service"]
55  },
56  {
57    "primary": [999],
58    "targets": ["power_failure.service"],
59    "event": {
60      "name": "xyz.openbmc_project.State.Power.PowerRailFault",
61      "arguments": {
62        "POWER_RAIL": "MyDevice",
63        "FAILURE_DATA": ""
64      }
65    }
66  }
67]
68```
69
70Each entry in the array describes a special handler for a specific post code.
71
72- `primary` - [required] The primary post code to match.
73- `secondary` - [optional] The secondary post code to match. If not present, the
74  match will be for all post codes which match just the primary
75- `targets` - [optional] List of systemd targets to start when the matching post
76  code is received.
77- `event` - [optional] The descriptor of the event to create with
78  phosphor-logging.
79  - `event::name` - Name of the event log. See `log-create --list` for a list of
80    possible events which can be created
81  - `event::arguments` - The named argument list which will be used to create
82    the event.
83