<div dir="ltr"><div><span style="font-family:arial,sans-serif;letter-spacing:0.08px">Hello all,</span></div><div><p class="gmail-my-2 gmail-[&+p]:mt-4 gmail-[&_strong:has(+br)]:inline-block gmail-[&_strong:has(+br)]:pb-2" style="box-sizing:border-box;border-width:0px;border-style:solid;margin:1rem 0px 0.5rem;letter-spacing:0.08px"><font face="arial, sans-serif">Devices such as GPUs, CPUs, and  NICs support firmware update using standard protocols like MCTP and PLDM T5. They also support recovery protocols, providing out-of-band mechanisms to detect when a device enters a fault state where firmware update is not possible and to securely restore it to a known good condition.</font></p><p class="gmail-my-2 gmail-[&+p]:mt-4 gmail-[&_strong:has(+br)]:inline-block gmail-[&_strong:has(+br)]:pb-2" style="box-sizing:border-box;border-width:0px;border-style:solid;margin:1rem 0px 0.5rem;letter-spacing:0.08px"><font face="arial, sans-serif">The Open Compute Project (OCP) offers a secure firmware protocol [1] to determine if a device is in recovery mode and to facilitate recovery through the transfer of recovery images, typically over SMBus. Firmware recovery generally follows a two-stage process: OCP recovery is first used to deliver the Stage 1 (initial) firmware to the device, which then enables further updates through MCTP/PLDM T5. Stage 2 involves transferring complete device firmware using MCTP/PLDM T5, which is already supported by the OpenBMC stack. There are also similar custom protocols for device recovery, some of which support two stage updates while others recover with a single-stage update. </font></p><p class="gmail-my-2 gmail-[&+p]:mt-4 gmail-[&_strong:has(+br)]:inline-block gmail-[&_strong:has(+br)]:pb-2" style="box-sizing:border-box;border-width:0px;border-style:solid;margin:1rem 0px 0.5rem;letter-spacing:0.08px"><font face="arial, sans-serif">To bring these capabilities into the OpenBMC ecosystem, the proposal is to leverage the standard Redfish API for code updates and utilize PLDM packaging for recovery images. Recovery protocols like OCP would be implemented as Non-PLDM code updaters, which handle the specific recovery protocol and parse PLDM packages to extract the appropriate recovery images for each device. This approach builds on the current efforts to update non-PLDM devices, such as VRs and CPLDs, with PLDM image packaging.</font></p><p class="gmail-my-2 gmail-[&+p]:mt-4 gmail-[&_strong:has(+br)]:inline-block gmail-[&_strong:has(+br)]:pb-2" style="box-sizing:border-box;border-width:0px;border-style:solid;margin:1rem 0px 0.5rem;letter-spacing:0.08px"><font face="arial, sans-serif" style="">I welcome feedback from the community on the approach and invite any alternative suggestions.</font></p><p class="gmail-my-2 gmail-[&+p]:mt-4 gmail-[&_strong:has(+br)]:inline-block gmail-[&_strong:has(+br)]:pb-2" style="box-sizing:border-box;border-width:0px;border-style:solid;margin:1rem 0px 0.5rem;letter-spacing:0.08px"><font face="arial, sans-serif">[1] <a rel="nofollow noopener" class="gmail-break-word gmail-hover:text-super gmail-hover:decoration-super gmail-underline gmail-decoration-from-font gmail-underline-offset-1 gmail-transition-all gmail-duration-300" target="_blank" href="https://www.opencompute.org/documents/ocp-recovery-document-1p0-final-1-pdf" style="box-sizing:border-box;border-width:0px;border-style:solid">https://www.opencompute.org/documents/ocp-recovery-document-1p0-final-1-pdf</a><br style="box-sizing:border-box;border-width:0px;border-style:solid">[2] <a rel="nofollow noopener" class="gmail-break-word gmail-hover:text-super gmail-hover:decoration-super gmail-underline gmail-decoration-from-font gmail-underline-offset-1 gmail-transition-all gmail-duration-300" target="_blank" href="https://gerrit.openbmc.org/c/openbmc/docs/+/76645" style="box-sizing:border-box;border-width:0px;border-style:solid">https://gerrit.openbmc.org/c/openbmc/docs/+/76645</a></font></p></div><div>Regards,</div><div>Tom</div></div>