[Design] PSU firmware update

Derek Howard derekh at linux.vnet.ibm.com
Sat Jun 8 01:52:50 AEST 2019


On 6/7/2019 9:35 AM, Matt Spinler wrote:
>
> 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.
>
>
Good point Matt on the PS install.  It would probably be a good idea to 
get the newly installed PS to the same image as the rest of the PS's in 
the system.

We do support PS's that don't provide control supply (standby voltage) 
when reset at the end of the update, while other PS's do.  Therefore for 
the former case, if only 1 PS has AC attached, we cannot update/reset 
that PS, so please let that be selectable by the user (eg vendor 
specific tool).

Also, please provide a way to know that the updates have finished.  As 
we don't want to update the PS's when the power is on (this is vendor 
specific as well), we also do not want to power the system on in the 
middle of an update.  For example, if after a BMC update the PS's are 
being updated, we want to hold off the next system power on until the PS 
updates have finished. Thanks.

>
>
>>
>>> The reason I ask is because if we could get clear requirements, it 
>>> is possible
>>> to simplify the design.
>
Would it be possible to support both methods?  The general use case 
being done during/after BMC code update, but also support the more 
manual method that could be used perhaps in the lab to test new psu 
images or in the field if there are problems with an existing image? Thanks.




More information about the openbmc mailing list