From: "Bills, Jason M" <jason.m.bills@linux.intel.com>
To: openbmc@lists.ozlabs.org
Subject: Re: Modifications in PLDM T5 flow to support SPI staged update
Date: Wed, 27 Aug 2025 12:03:59 -0600 [thread overview]
Message-ID: <0f0550bd-34b7-4f47-b472-160007bb8683@linux.intel.com> (raw)
In-Reply-To: <DC3C6C29-2ABB-4E27-834A-02EBE322B82D@stwcx.xyz>
On 8/15/2025 7:25 AM, Patrick Williams wrote:
> Are there Redfish methods of initiating this now? I recall a workgroup
> at OCP was trying to get this done there.
>
> — Patrick Williams
>
>> On Aug 15, 2025, at 8:15 AM, Tom Joseph <rushtotom@gmail.com> wrote:
>>
>>
>>
>> Hello All,
>>
>> SPI Staged Update enables pre-downloading firmware component images
>> for supported devices, significantly reducing downtime during firmware
>> updates and activation. This requires devices to support at least two
>> slots — one for the running firmware and another for staging the new
>> image.
>>
>> The update process occurs in two iterations:
>>
>> 1.
>>
>> First Iteration:
>>
>> *
>>
>> The PLDM UA initiates the PLDM T5 flow with the PLDM FD
>> supporting staged updates.
>>
>> *
>>
>> All stages (Transfer, Verify, Apply) are completed
>> except activation. This is achieved by PLDM UA skipping the
>> PLDM T5 ActivateFirmware command.
>>
>> *
>>
>> Upon state machine timeout, the PLDM FD marks the new image
>> as /staged/ (not failed update). Since it’s staged, it remains
>> inactive until explicitly activated later.
>>
>> 2.
>>
>> Second Iteration:
>>
>> *
>>
>> The same PLDM package is used. Since the image is already
>> staged, the PLDM FD skips most of the Transfer stage, reducing
>> downtime.
>>
>> *
>>
>> This iteration is typically scheduled during a maintenance window.
>>
>> *
>>
>> Devices that do not support SPI staging are updated in this
>> iteration.
>>
>> *
>>
>> All firmware is activated after this iteration.
>>
>> To enable this, we propose introducing a new OEM parameter in the
>> MultiPart API to instruct the PLDM UA to skip sending the |
>> ActivateFirmware|command, along with necessary PLDM UA modifications
>> to support the SPI staged flow.
>>
>> If there is interest within the OpenBMC community to adopt and
>> collaborate on this feature, please feel free to reach out.
>>
Intel has interest in being part of an OpenBMC community collaboration
on this feature.
>> [1] https://docs.nvidia.com/multi-node-nvlink-systems/nvfupd-guide/
>> appendix/spi-staged.html <https://docs.nvidia.com/multi-node-nvlink-
>> systems/nvfupd-guide/appendix/spi-staged.html>
>>
>> Regards,
>> Tom
prev parent reply other threads:[~2025-08-27 18:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 12:14 Modifications in PLDM T5 flow to support SPI staged update Tom Joseph
2025-08-15 13:25 ` Patrick Williams
2025-08-27 18:03 ` Bills, Jason M [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0f0550bd-34b7-4f47-b472-160007bb8683@linux.intel.com \
--to=jason.m.bills@linux.intel.com \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox