Standard FW update package structure - use PLDM?
Deepak Kodihalli
deepak.kodihalli.83 at gmail.com
Wed Jun 2 14:18:18 AEST 2021
Hi,
The PLDM FW update spec [1] defines a structure to package firmware
images - primarily to identify target devices and to associate them
with software versions. This is done via metadata in the package, and
the metadata itself is defined in terms of generic concepts (like
UUIDs, PCI vendor IDs, version strings etc). For devices that do
support PLDM, the 'UpdateAgent' (typically the BMC) uses this package
structure plus a set of standard PLDM commands to talk to the devices
to perform FW update.
For platforms that enable FW update of multiple entities through the
BMC (this could be a mix of the BMC itself and other PLDM/non-PLDM
devices), I think the current OpenBMC mechanism involves the use of a
VersionPurpose [2] interface in order to map FW images to devices. A
couple of problems with this approach:
- Can this enumeration cover all possible device types?
- How does this fit with PLDM?
Instead of the VersionPurpose based approach, how about using the PLDM
FW update package structure as the standard to target devices and to
associate devices with versions, even for non-PLDM devices? This means
FW images uploaded to the BMC will be packaged in the PLDM FW update
format. I don't think this is a violation of the PLDM FW update spec
(also checking with PMCI WG). For non-PLDM devices, this means using
just the package structure, not PLDM commands.
[1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0267_1.1.0.pdf
[2] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software/Version.interface.yaml#L19
Thanks,
Deepak
More information about the openbmc
mailing list