System Firmware states on D-Bus

Thomaiyar, Richard Marian richard.marian.thomaiyar at
Wed Feb 26 01:17:42 AEDT 2020

Prefer D-Bus conveying details in finer / better manner, rather than 
tying it towards any user facing application like Redfish / IPMI.

i.e. We can define all possible values in D-Bus interface, so that any 
application (common / oem), can try to use the value, rather than value 
not being available in D-Bus. Redfish / IPMI can have conversion logic 
to group the values as per the need.



On 2/24/2020 10:57 PM, Andrew Geissler wrote:
> I sent an email[1] out a while ago about mapping Redfish Host states to
> PLDM Boot values.
> Now that we have that design moving, the next question is whether we want
> to try and map these to our current IPMI-based state sensors[2]
> (OperatingSystemState and BootProgress)? These are currently displayed when
> a user does a "obmcutil state" and I see a few other repositories reference
> them for boot status. The openbmc-test suite also uses them fairly extensively
> to verify different boot tests.
> If we want to maintain backwards compatibility then we should map the new PLDM
> based boot progress to these two. Mapping them does not seem too difficult.
> I could have phosphor-host-state-manager (which hosts these D-Bus properties)
> listen for changes to the PLDM property and update the two properties
> appropriately. This assumes a system where the system firmware is only
> IPMI or PLDM (not both) since they would not play all that well together.
>  From a Redfish API perspective, it will just directly look at the PLDM
> property.
> Thoughts?
> [1]:
> [2]:

More information about the openbmc mailing list