[Design] PSU firmware update
Neeraj Ladkani
neladk at microsoft.com
Tue Jun 4 03:23:52 AEST 2019
1. Why host power off is a pre-condition? We should add this a PSU pre-requisite to support Live upgrade and activation.
2. How should PSU update impact PSU and battery monitoring ? should there be coordination between sensor monitoring task during update ?
3. PSU may have multiple regions like bootloader, active region and inactive region. We should design to support multiple region update.
4. Can you propose required SEL logs and telemetry requirements as well ?
Thanks
Neeraj
-----Original Message-----
From: openbmc <openbmc-bounces+neladk=microsoft.com at lists.ozlabs.org> On Behalf Of Andrew Geissler
Sent: Monday, June 3, 2019 6:32 AM
To: Lei YU <mine260309 at gmail.com>
Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>
Subject: Re: [Design] PSU firmware update
On Mon, Jun 3, 2019 at 3:54 AM Lei YU <mine260309 at gmail.com> wrote:
>
> Hi All,
>
> This is a proposed design of PSU firmware update.
> It will be posted to gerrit for review after we have resolved comments
> in the mailing list.
>
> # PSU firmware update
>
> Author:
> Lei YU <mine260309 at gmail.com> <LeiYU>
> Primary assignee:
> None
> Other contributors:
> Su Xiao <suxiao at inspur.com>
> Derek Howard <derekh at us.ibm.com>
> Created:
> 2019-06-03
>
>
> ## Problem Description
>
> There is no support in OpenBMC to update the firmware for PSUs.
>
>
> ## Background and References
>
> In OpenBMC, there is an existing interface for [software update][1].
>
> The update process consists of:
> 1. Uploading an image to BMC;
> 2. Processing the image to check the version and purpose of the image;
> 3. Verifying and activating the image.
>
> Currently, BMC and PNOR firmware update are supported:
> * [phosphor-bmc-code-mgmt][2] implements BMC code update, and it supports all
> the above 3 processes.
> * [openpower-pnor-code-mgmt][3] implements PNOR code update, and it only
> implements "verifying and activating" the image. It shares the function of
> the above 1 & 2 processes.
>
> For PSU firmware code update, it is preferred to re-use the same function for
> the above 1 & 2.
>
>
> ## Requirements
>
> To mitigate the risk of power loss, the PSU firmware code update shall meet
> pre-conditions:
> 1. The host is powered off;
> 2. The redundant PSUs are all connected;
> 3. The AC input and DC standby output shall be OK on all the PSUs;
>
> And during updating:
> 4. After the update is done on a PSU, the AC input and DC standby output shall
> be checked.
What happens if this fail? Auto roll back or just an error log?
>
>
> ## Proposed Design
>
> The PSU firmware code update will re-use the current interfaces to upload,
> verify, and activate the image.
Yes, this ensures the existing Redfish firmware update API's implemented
within bmcweb will also work for this without any changes required.
>
> 1. The "Version" interface needs to be extended:
> * Add a new [VersionPurpose][4] for PSU;
> * Re-use the existing ExtendedVersion as an additional string for
> vendor-specific purpose, e.g. to indicate the PSU model.
> 2. Re-use the existing functions implemented by [phosphor-bmc-code-mgmt][2] for
> uploading and processing the image.
> * The PSU update image shall be a tarball consists of a MANIFEST, images,
> and signatures
> 3. There will be a new service that implements the [Activation][5] interface to
> update the PSU firmware.
> * It shall run all the checks described in [Requirements] before performing
> the code update;
> * It shall run the checks after each PSU code update is done.
> * The service will verify the signature of the image;
> * The service shall check the ExtendedVersion to make sure the image matches
> the PSU model.
> * The service will call a configurable and vendor-specific tool to perform
> the code update.
> * When each check fails, or the vendor-specific tool returns errors, the PSU
> code update will be aborted and an error event log shall be created.
> * When the PSU code update is completed, an informational event log shall be
> created.
Is this a normal requirement when it comes to PSU's? We don't do this for BMC
or PNOR.
>
>
<snip>
More information about the openbmc
mailing list