Author: Andrew Geissler (geissonator)
Other contributors: None
Created: May 27, 2020
The boot progress of an OpenBMC managed system is complex. There are a mix of phosphor D-Bus properties, IPMI sensors, PLDM sensors, and Redfish properties to represent it. The goal of this design document is to highlight these different entities and provide a base for system implementors on what to implement.
phosphor-state-manager implements D-Bus properties which track the state of the BMC, Chassis, and Host. This design is primarily focused on the status of the Host since it is the most complex. Specifically the goal is to provide detailed information on what the host is doing during a boot.
HostState provides basic Off/Running type information along with an error state (Quiesced) and debug state (DiagnosticMode). The focus of this document is the Running state. This simply indicates whether something is running on the host processors.
phosphor-state-manager implements some other D-Bus properties that represent the host boot progress:
These two D-Bus properties are very IPMI-centric. They were defined based on two IPMI sensors which are set by the host firmware as it boots the system.
PLDM also has a boot progress sensor. Search for "Boot Progress" in this doc. A subset of this maps fairly well to the IPMI sensors above. This PLDM sensor is not implemented yet in OpenBMC code.
Redfish represents system state in a variety of ways. The BMC, Chassis, and System all implement a Status object. This provides a list of generic State options which are applicable to Redfish objects. OpenBMC has the following mapping for phosphor-state-manager to the Redfish System [Status][state]:
xyz.openbmc_project.State.Host.HostState.Running : Enabledxyz.openbmc_project.State.Host.HostState.Quiesced : Quiescedxyz.openbmc_project.State.Host.HostState.DiagnosticMode : InTestAs of ComputerSystem.v1_13_0, the BootProgress object is officially in the Redfish ComputerSystem schema.
To summarize, the LastState property under this new BootProgress object tracks the following boot states of the system:
There is also a LastStateTime associated with this new BootProgress object which should be updated with the date and time the LastState was last updated.
In the end, the goal is to be able to map either the IPMI or PLDM boot sensors into all or some of the values in this new Redfish property.
Note that this design does not include multi-host computer system concepts but it also does not preclude them. The BootProgress D-Bus property is associated with a /xyz/openbmc_project/state/host<X> instance where is the host instance. Similarly, the Redfish system object is also an instance based object.
BootProgressLastUpdate D-Bus property that will hold the date and time of the last update to BootProgressBootProgress and BootProgressLastUpdate properties are updated appropriately in both IPMI and PLDM based stacksBootProgress property on D-BusBootProgressLastUpdate property on D-Bus when it sees BootProgress updatedLastState and LastStateTime properties have the appropriate mappings to the BootProgress and `BootProgressLastUpdate D-Bus propertiesDifferent OpenBMC systems could support different boot progress codes, and support them in different orders. This document does not try to set any requirements on this other than that they must all be defined within the BootProgress D-Bus property and the ones which have a mapping to the Redfish BootProgress object will be shown via the Redfish interface.
BootProgress will be enhanced to support a superset of what is provided by IPMI and PLDM.
IPMI code already sets the BootProgress D-Bus property based on a config file. Look for fw_boot_sensor in this file for an example of how a particular IPMI sensor is mapped to this D-Bus property.
PLDM software will do something similar.
bmcweb will then use this BootProgress D-Bus interface to respond appropriately to Redfish requests.
A lot of system BIOS's provided some form of a detailed boot progress codes. UEFI has POST codes, POWER has istep progress codes. If more fine grained details were needed, we could look into using these. Currently though the need is just high level boot progress. Note that these POST/istep codes could be mapped to the appropriate BootProgress value if desired (or for cases where the host does not support an IPMI or PLDM stack that has BootProgress in it).
Each system will need to document which BootProgress codes they support and the expected order of them when a system is booting.
Ensure an IPMI and PLDM based system boot and update the BootProgress D-Bus property as expected.