Question about OpenBMC Remote BIOS configuration proposal

[Chang, Abner (HPS SW/FW Technologist)]

Hi Sekar,
This is Abner Chang from HPE Server BIOS team, our team is also working on UEFI/EDK2 Redfish open source solution (just FYI the POC code is almost done).

I read through the Remote BIOS configuration proposal and would like to see if we still have chance to make some changes on it to reduce the efforts on both BMC and BIOS. Also get rid of using PLDM BIOS control/Configuration methodology because we can find the equivalent method if use Redfish service.
I understand that this proposal is focus on the early system firmware POST, and the firmware solution could be EDK2 + Linux boot. That means this firmware solution may not have the network driver stack to communicate with Redfish service through vNIC. So some ideas proposed here are understandable such as the special format of BIOS resource and the IPMI channel to BMC. However, some of the designs proposed here would be the additional effort to current system firmware (e.g. EDK2 PEI/ or early DXE phase) implementation and BMC as well.
The proprietary format of BIOS resource (Type 0/1) is one issue. We think it would be better to just leverage JSON format (which follows BIOS/AttributeRegistry data model) and carried by HTTP. The payload could be compressed by Redfish supported compress algorithm (gzip) and delivered over whatever non network stack based channel (e.g. IPMI proposed here) in the early POST.
With this, we may leverage system firmware drivers for building up the payload between BIOS and BMC. This could reduce system firmware effort and get rid of proprietary format of BIOS resource in XML. Furthermore, the architecture of OpenBMC Remote BIOS configuration would be more closer to the current Redfish service implementation. BMC can leverage the implementation of Redfish service if the payload is carried by HTTP message with JSON format which follow Redfish BIOS data model
We don't have much concerns of the transport layer between BMC<->BIOS because it is used in the early system POST, stay with IPMI looks fine for now.

Thanks
Abner


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200723/3ef2ac36/attachment.htm>