[Design] PSU firmware update

[Matt Spinler]

On 6/6/2019 3:31 PM, Adriana Kobylak wrote:
> 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?

3 more quick notes:

1) PSs can be hot pluggable, so when a new one is detected, the code
update should run then too if the new PS needs one, assuming all other
conditions are met.

2) A single system may support multiple models of PS (will definitely
happen for us), so this design should be able to store multiple PS
images and send the correct image to the correct model.

3) You mentioned the combined image stuff before.  We should just check
the timeline for that support aligns with this one.






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