[Design] PSU firmware update
Adriana Kobylak
anoo at linux.ibm.com
Fri Jun 7 06:31:13 AEST 2019
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?
> The reason I ask is because if we could get clear requirements, it is
> possible
> to simplify the design.
More information about the openbmc
mailing list