Exposing BIOS attributes to a remote management console
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
b) The BMC uses phosphor-settingsd  as the backend to store BIOS
attributes on D-Bus.
c) Bmcweb implements the Redfish BIOS schema  to enable remote
reads/writes on the BIOS attributes.
However, c) is a problem because one needs to write YAML files  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.
More information about the openbmc