An issue about the architecture of pldmd when implementing Set/Get Boot Order for YV4 platform

[Delphine_CC_Chiu/WYHQ/Wiwynn]

Hi Patrick,

In previous projects, e.g., YV35, BICs bridge the IPMI command of Set/Get Boot Order sent from BIOS directly to the BMC, but in YV4, IPMI command is replaced by PLDM.
As a result, we plan to translate the OEM IPMI command: Set (NetFn=0x30, Cmd=0x52) and Get (NetFn=0x30, Cmd=0x53) Boot Order sent from BIOS into standard command "SetBIOSAttributeCurrentValue" and "GetBIOSAttributeCurrentValueByHandle" in PLDM for BIOS Control and Configuration (DSP0247).

Currently, the handlers for the 2 commands above have been implemented in pldmd to set/get the current value of a BIOSAttribute. (libpldmresponder/bios.cpp<https://github.com/openbmc/pldm/blob/9e6631e201cf71895491987d93e8a343e05783b5/libpldmresponder/bios.cpp#L104>)
Each BIOSAttribute can be different AttributeTypes, BIOSEnumeration, BIOSString, and BIOSInteger have been implemented. We want to add a new type "BIOSBootConfigSetting". (Can refer to Table 14: PLDM Representation of BIOSAttributeValueTableData in DSP0247<https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf>)

When Set/Get command comes in, it will find specific BIOSAttribute by searching the BIOSTable (i.e., BIOSTableObj at libpldmresponder/bios_config.hpp<https://github.com/openbmc/pldm/blob/9e6631e201cf71895491987d93e8a343e05783b5/libpldmresponder/bios_config.hpp#L53>), there are CurrentValue and DefaultValue and OptionValue to represent the attribute's value (a few lines above to BIOSTableObj), but the type is restricted to int64_t and string, which has only 1 element.
BootConfigSetting is a series of BootSources, which should be a string array. We want to add string array to let BootConfigSetting can store multiple elements and add into BIOSTableObj. Since change the type of data type might need a good amount of work, we wonder know if there is any concern to do it?

Thanks,
Delphine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20240129/17ec3976/attachment.htm>