[Design] PSU firmware update

[Andrew Geissler]

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>