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