Exposing BIOS attributes to a remote management console

Deepak Kodihalli dkodihal at linux.vnet.ibm.com
Sat Feb 8 19:28:04 AEDT 2020


To enable remote updates (via a remote management console that talks to 
the BMC) to the host firmware's BIOS settings table on IBM systems, 
we're thinking of the following flow:

a) The host firmware sends down a BIOS settings table to the BMC using 
PLDM [1].
b) The BMC uses phosphor-settingsd [2] as the backend to store BIOS 
attributes on D-Bus.
c) Bmcweb implements the Redfish BIOS schema [3] to enable remote 
reads/writes on the BIOS attributes.

However, c) is a problem because one needs to write YAML files [4] for 
the BMC to determine what D-Bus objects to make corresponding to the 
BIOS attributes. This requires a unique D-Bus interface *per* BIOS 
attribute. This means the BMC must have prior knowledge about the BIOS 

I don't think that's the right way to go about this for two reasons. One 
- this creates a lockstep dependency on the host firmware when the BIOS 
settings table needs to be updated, and two - I think the OpenBMC 
implementation of this must be able to receive (via PLDM/IPMI/other 
standard in-band means) a set of BIOS attributes from different BIOS 
firmware stacks dynamically and expose them for out of band updates, 
without having prior/build-time knowledge of those attributes. So I 
think this calls for a different kind of D-Bus interface/infrastructure 
than what the phosphor-settingsd app relies on. Something that enables 
the BMC to add to D-Bus a BIOS attribute dynamically, knowing it's name, 
type and default value.

Any thoughts on this flow? I'm also curious to know if the Redfish BIOS 
schema/attribute registry model requires the BMC to have prior knowledge 
about the system BIOS attributes to update the registry. This wasn't 
obvious to me from a quick read of the schema.


[2] https://github.com/openbmc/phosphor-settingsd
[3] https://redfish.dmtf.org/schemas/v1/Bios.v1_1_0.json

More information about the openbmc mailing list