<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Deepak,</p>
<p>OOB BIOS high level config design doc is in progress. I will send
for review soon. <br>
</p>
<p>Yes, we need to support all interface -IPMI/ MCTP/ Redfish Host
interface. <br>
</p>
<p>If BIOS is not booted at all. BMC wont have any attribute info.
It will be empty in BMC side.</p>
<p>BIOS must provide BIOS OOB capability via KCS interface in early
boot stage.<br>
Like supported proprietary BIOS attribute file format or PLDM
support via MCTP or <br>
Redfish BIOS attribute registry format to the BMC.</p>
<p>BIOS must send the master BIOS attributes file(Intel properitary
- XML type 0)<br>
via KCS interface or all attributes details via Bios configuration
PLDM via MCTP or<br>
Redfish host interface during first boot.</p>
BIOS must collect the new attribute values from BMC and update the
same in BIOS<br>
<p>BIOS must send the updated master attributes file to the BMC and
once its updated in BIOS</p>
<p>and reset the system to reflect the BIOS configuration.<br>
</p>
<p>OOB daemon in BMC must maintain and collect the attribute
registry file from MCTP/ IPMI/ Redfish interface.<br>
</p>
<p>Convert the proprietary XML format/ PLDM data into BIOS
attribute Registry format &<br>
must support the below following dbus method.</p>
<p><a class="moz-txt-link-freetext" href="https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/18242">https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/18242</a></p>
<p>Validate the BIOS input data or User attribute value.</p>
<p>MCTP / Redfish host interface / IPMI must communicate with OOB
daemon in BMC via D bus</p>
<p>Thanks</p>
<p>Suryakanth.S<br>
</p>
<p><br>
</p>
<br>
<blockquote type="cite"
cite="mid:1504A9E7C77EF44697F386AD61B16260152FEBA5@BGSMSX105.gar.corp.intel.com">
<div class="WordSection1">
<div>
<div>
<p class="MsoNormal">---------- Forwarded message ----------<br>
From: Deepak Kodihalli <<a
href="mailto:dkodihal@linux.vnet.ibm.com"
moz-do-not-send="true">dkodihal@linux.vnet.ibm.com</a>><br>
Date: Feb 8, 2020 1:59 PM<br>
Subject: Exposing BIOS attributes to a remote management
console<br>
To: <a href="mailto:openbmc@lists.ozlabs.org"
moz-do-not-send="true">openbmc@lists.ozlabs.org</a><br>
Cc: <br>
<br>
<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:10.0pt">Hi,<br>
<br>
To enable remote updates (via a remote management console
that talks to <br>
the BMC) to the host firmware's BIOS settings table on IBM
systems, <br>
we're thinking of the following flow:<br>
<br>
a) The host firmware sends down a BIOS settings table to
the BMC using <br>
PLDM [1].<br>
b) The BMC uses phosphor-settingsd [2] as the backend to
store BIOS <br>
attributes on D-Bus.<br>
c) Bmcweb implements the Redfish BIOS schema [3] to enable
remote <br>
reads/writes on the BIOS attributes.<br>
<br>
However, c) is a problem because one needs to write YAML
files [4] for <br>
the BMC to determine what D-Bus objects to make
corresponding to the <br>
BIOS attributes. This requires a unique D-Bus interface
*per* BIOS <br>
attribute. This means the BMC must have prior knowledge
about the BIOS <br>
attributes.<br>
<br>
I don't think that's the right way to go about this for
two reasons. One <br>
- this creates a lockstep dependency on the host firmware
when the BIOS <br>
settings table needs to be updated, and two - I think the
OpenBMC <br>
implementation of this must be able to receive (via
PLDM/IPMI/other <br>
standard in-band means) a set of BIOS attributes from
different BIOS <br>
firmware stacks dynamically and expose them for out of
band updates, <br>
without having prior/build-time knowledge of those
attributes. So I <br>
think this calls for a different kind of D-Bus
interface/infrastructure <br>
than what the phosphor-settingsd app relies on. Something
that enables <br>
the BMC to add to D-Bus a BIOS attribute dynamically,
knowing it's name, <br>
type and default value.<br>
<br>
Any thoughts on this flow? I'm also curious to know if the
Redfish BIOS <br>
schema/attribute registry model requires the BMC to have
prior knowledge <br>
about the system BIOS attributes to update the registry.
This wasn't <br>
obvious to me from a quick read of the schema.<br>
<br>
Thanks,<br>
Deepak<br>
<br>
[1] <br>
<a
href="https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf"
moz-do-not-send="true">https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf</a><br>
[2] <a
href="https://github.com/openbmc/phosphor-settingsd"
moz-do-not-send="true">https://github.com/openbmc/phosphor-settingsd</a><br>
[3] <a
href="https://redfish.dmtf.org/schemas/v1/Bios.v1_1_0.json"
moz-do-not-send="true">https://redfish.dmtf.org/schemas/v1/Bios.v1_1_0.json</a><br>
[4] <br>
<a
href="https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/settings/phosphor-settings-defaults/defaults.yaml"
moz-do-not-send="true">https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/settings/phosphor-settings-defaults/defaults.yaml</a><o:p></o:p></span></p>
</div>
</div>
</blockquote>
</body>
</html>