Add support for post code handling/eventing

Add support to consume a JSON configuration which
will let a platform configuration to dictate if
we need to do special handling or logging based
on specific post codes received.

Tested:

1. Created the following config and after restarting
`xyz.openbmc_project.State.Boot.PostCode@0.service`:
```
[
    {
        "primary": [1,2,5],
        "event": {
            "name": "xyz.openbmc_project.State.SMC.SMCFailed",
            "arguments": {
                "IDENTIFIER": "test",
                "FAILURE_TYPE": "world"
            }
        }
    }
]
```

Created the primary post code:
```
root@bmc:~# busctl set-property xyz.openbmc_project.State.Boot.Raw /xyz/openbmc_project/state/boot/raw0 xyz.openbmc_project.State.Boot.Raw Value '(ayay)' 3 0x1 0x2 0x5 0x0
```
Check that the log is created:
```
root@bmc:~# busctl introspect -l xyz.openbmc_project.Logging /xyz/openbmc_project/logging/entry/2 xyz.openbmc_project.Logging.Entry | grep "AdditionalData\|Message"
.AdditionalData property  a{ss}     6 "FAILURE_TYPE" "world" "IDENTIFIER" "test" <snip>
.Message property  s "xyz.openbmc_project.State.SMC.SMCFailed"
```
2. Replace the config with:
```
[
    {
        "primary": [1,2,6],
        "targets": ["testservice.service"]
    }
]
```
Create a test unit file:
testservice.service:
```
[Unit]
Description=A simple oneshot service

[Service]
Type=oneshot
ExecStart=/bin/bash -c "echo Hello world > /tmp/test.txt"
```
Issue a new post code with the new config.
```
systemctl daemon-reload
systemctl restart xyz.openbmc_project.State.Boot.PostCode@0.service
root@bmc:/usr/lib/systemd/system# busctl set-property xyz.openbmc_project.State.Boot.Raw /xyz/openbmc_project/state/boot/raw0 xyz.openbmc_project.State.Boot.Raw Value '(ayay)' 3 0x1 0x2 0x5 0x0
root@bmc:/usr/lib/systemd/system# cat /tmp/test.txt
Hello world
```

Change-Id: Ibaa09fb88190a344fd7c4fadd24dda4aa4ae0633
Signed-off-by: Amithash Prasad <amithash@meta.com>
8 files changed
tree: 46a7c33f2f644e1de83912ce244faea5d3ddc025
  1. inc/
  2. service_files/
  3. src/
  4. subprojects/
  5. .clang-format
  6. LICENSE
  7. meson.build
  8. meson.options
  9. OWNERS
  10. post-code-handlers.json
  11. README.md
README.md

phosphor-post-code-manager

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

To build phosphor-post-code-manager package , do the following steps:

meson <build directory>
ninja -C <build directory>

Hosted Services

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.

Architecture

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

Special Post code handling/eventing

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 primary
  • targets - [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 created
    • event::arguments - The named argument list which will be used to create the event.