FW: Exposing BIOS attributes to a remote management console
suryakanth.sekar at linux.intel.com
Mon Feb 10 21:49:04 AEDT 2020
OOB BIOS high level config design doc is in progress. I will send for
Yes, we need to support all interface -IPMI/ MCTP/ Redfish Host interface.
If BIOS is not booted at all. BMC wont have any attribute info. It will
be empty in BMC side.
BIOS must provide BIOS OOB capability via KCS interface in early boot stage.
Like supported proprietary BIOS attribute file format or PLDM support
via MCTP or
Redfish BIOS attribute registry format to the BMC.
BIOS must send the master BIOS attributes file(Intel properitary - XML
via KCS interface or all attributes details via Bios configuration PLDM
via MCTP or
Redfish host interface during first boot.
BIOS must collect the new attribute values from BMC and update the same
BIOS must send the updated master attributes file to the BMC and once
its updated in BIOS
and reset the system to reflect the BIOS configuration.
OOB daemon in BMC must maintain and collect the attribute registry
file from MCTP/ IPMI/ Redfish interface.
Convert the proprietary XML format/ PLDM data into BIOS attribute
Registry format &
must support the below following dbus method.
Validate the BIOS input data or User attribute value.
MCTP / Redfish host interface / IPMI must communicate with OOB daemon in
BMC via D bus
> ---------- Forwarded message ----------
> From: Deepak Kodihalli <dkodihal at linux.vnet.ibm.com
> <mailto:dkodihal at linux.vnet.ibm.com>>
> Date: Feb 8, 2020 1:59 PM
> Subject: Exposing BIOS attributes to a remote management console
> To: openbmc at lists.ozlabs.org <mailto:openbmc at lists.ozlabs.org>
> 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 .
> 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.
>  https://github.com/openbmc/phosphor-settingsd
>  https://redfish.dmtf.org/schemas/v1/Bios.v1_1_0.json
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openbmc