[Design] PSU firmware update

[yuan.li at linux.intel.com]

>On 2019-06-05 22:31, Lei YU wrote:
>> On Wed, Jun 5, 2019 at 10:25 PM Matt Spinler <mspinler at linux.ibm.com> 
>> wrote:
>>> 
>>> 
>>> On 6/5/2019 1:18 AM, Lei YU wrote:
>>> >>> The PSU firmware code update will re-use the current interfaces to upload,
>>> >>> verify, and activate the image.
>>> >> We would like the option to be able to ship the PSU firmware as part of
>>> >> the BMC image (in the root filesystem). This means that it is already
>>> >> present and authenticated when the BMC boots. In this way, we know that
>>> >> the current BMC firmware plays well with the PSU firmware and have fewer
>>> >> variables to test for when making a release.
>>> > Because the PSU firmware is part of BMC image, this seems a completely
>>> > different approach, and more like part of BMC image update, is it?
>>> > I would expect this should not be part of this design, what do you think?
>>> 
>>> FYI, I am 99% sure this is how IBM needs its systems to work as well.
>>> That being the case,
>>> 
>>> will you also be handling this design?
>> 
>> Good to know.
>> 
>> Then a question comes up:
>> In which cases PSU firmware update shall be done?
>> 1. It is updated together with BMC firmware update as described by 
>> Vernon
>>    Mauery;
>> 2. It is updated independently with APIs, as described in this design 
>> doc.
>> 
>> Will 1 and 2 both be valid, or only 1 is the real case and we do not 
>> need to
>> support 2?
>> 
> 
> I see it as having a single tarball file that has the required files to 
> update the
> BMC and the PSU. When this tarball is uploaded, then a new Version with 
> a Purpose
> of System or some other name is created. When this Version is activated, 
> this
> triggers the BMC updater (existing) and the PSU updater (new) to check 
> if all
> the necessary files to perform the update of their component exist. If 
> yes, each
> updater updates their piece and if any one fails it'd mark the Version 
> as Failed
> (TBD on synchronizing the updaters to mark the Version as Active or 
> Failed).
> So the PSU would be updated at the same time as the BMC, but done by its 
> own
> updater application.
>  
> Thoughts?
>

I have different opinion about this. In current practice it's not a tarball which 
could be decompressed easily. The embedded BMC update image is signed. PSU
firmware is a part of the root filesystem (as a file). In this case the  whole update 
flow would look like:
1. Upload and update the BMC firmware itself.
2. Boot to new version of BMC firmware.
3. BMC to read PSU firmware version from PSU, and compare with the file shipped
    with this BMC firmware.
4. If update needed, update tool could be launched.

Benefit for this is that PSU firmware update process is transparent to end user.

How do you think?

Yuan Li

>> The reason I ask is because if we could get clear requirements, it is 
>> possible
>> to simplify the design.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190610/d6094fc3/attachment.htm>