>On 2019-06-05 = 22:31, Lei YU wrote:

=0A

>> On Wed, Jun 5, 2019 at 1= 0:25 PM Matt Spinler <mspinler@linux.ibm.com>

=0A

>>= wrote:

=0A

>>>

=0A

>>>

=0A>>> On 6/5/2019 1:18 AM, Lei YU wrote:=0A

>>>= >>> The PSU firmware code update will re-use the current interfa= ces to upload,

=0A

>>> >>> verify, and activate= the image.

=0A

>>> >> We would like the option to= be able to ship the PSU firmware as part of

=0A

>>> >= ;> the BMC image (in the root filesystem). This means that it is alread= y

=0A

>>> >> present and authenticated when the BM= C boots. In this way, we know that

=0A

>>> >> the = current BMC firmware plays well with the PSU firmware and have fewer

= =0A

>>> >> variables to test for when making a release.=

=0A

>>> > Because the PSU firmware is part of BMC im= age, this seems a completely

=0A

>>> > different appr= oach, and more like part of BMC image update, is it?

=0A

>>= > > I would expect this should not be part of this design, what do y= ou think?

=0A

>>>

=0A

>>> FYI, I am 9= 9% sure this is how IBM needs its systems to work as well.

=0A

&g= t;>> That being the case,

=0A

>>>

=0A

&g= t;>> will you also be handling this design?

=0A

>> =0A

>> Good to know.

=0A

>= ;> Then a question comes up:

=0A

>> In which cases PSU f= irmware update shall be done?

=0A

>> 1. It is updated toget= her with BMC firmware update as described by

=0A

>> Vernon=

=0A

>> Mauery;

=0A

>> 2. = It is updated independently with APIs, as described in this design

= =0A

>> doc.

=0A

>> Will 1 = and 2 both be valid, or only 1 is the real case and we do not

=0A>> need to

=0A

>> support 2?

=0A

>> =

=0A

> I see it as having a single tar= ball file that has the required files to

=0A

> update the=0A

> BMC and the PSU. When this tarball is uploaded, then a new = Version with

=0A

> a Purpose

=0A

> of System or s= ome other name is created. When this Version is activated,

=0A

&= gt; this

=0A

> triggers the BMC updater (existing) and the PSU= updater (new) to check

=0A

> if all

=0A

> the ne= cessary files to perform the update of their component exist. If

=0A=

> yes, each

=0A

> updater updates their piece and if a= ny one fails it'd mark the Version

=0A

> as Failed

=0A> (TBD on synchronizing the updaters to mark the Version as Active o= r

=0A

> Failed).

=0A

> So the PSU would be update= d at the same time as the BMC, but done by its

=0A

> own=0A

> updater application.

=0A

&= gt; Thoughts?

=0A

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 sign= ed. PSU

firmware is a part of the root filesystem (as a file). I= n this case the whole update

flow would look like:

1. Upload and update the BMC firmware itsel= f.

2. Boot to new version of BMC firmware.

3. BMC to r= ead 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 i= s that PSU firmware update process is transparent to end user.

<= br>

How do you think?

Yuan Li

=0A

>> The reason I ask is because if we could get cl= ear requirements, it is

=0A

>> possible

=0A

>&= gt; to simplify the design.

=0A

=0A=0A ------=_001_NextPart624106210581_=------