Firmware update

[derick-montague]

No description provided.

[mmagdzix]

What are the requirements for this issue? Can you explain us what should be done here?

[derick-montague]

@ParishrutB will be updating this story soon.

[ParishrutB]

Use Case

As a system admin, I need to be able to update the firmware or run a backup copy, so that the system is performing as per expectations.

Design Review Workflow

1. Each design iteration will have a comment section
2. The section will include:
   • A title with the iteration number
   • Any description or specific feedback the designer is requesting
   • Screenshots of the workflow
3. Based on community and user feedback, we create a comment for the new iteration and repeat these steps

[ParishrutB]

Firmware Update - Version 1 - Single file update

---

In the single file update, BMC and Host files are uploaded together as a .tar file. Since they are linked in the system and will always be the same, we decided to show the versions for BMC and Host as one in the GUI.

Main screen

---

Update access key

The update access key information sits on the top of the page. If it has expired, then the warning is shown prominently.

---

Firmware update

The new process has the following changes:

1. A single .tar file containing both the BMC and Host images needs to be uploaded.
2. Once uploaded & then activated (loaded to system memory), the application (to make it as running image) and BMC reboot follows immediately. In other words, once the user clicks on the upload button, the process goes through all the steps of a firmware update in one shot.

To communicate the above process and make it easier to follow, we have added a process section. A successful update looks like the following flow:

---

Firmware update - error

In case there is an error, we tried to communicate it through the process section. In the following example, there was an error after the upload, at the activation stage.

[ParishrutB]

Upcoming updates

---

Based on discussions in the workgroup, we are working on the following updates:

1. Different community members may support different upload locations. E.g. Intel does not support TFTP FW uploads.
2. Use case for powering off the host may not be the same for all community members.
3. In the single file version, what if the uploaded file contained only a BMC image? Will the host need to be powered off? Is it possible to update a single target (only BMC in this case) in this version? - Needs to be checked, in discussion.
4. A design for the 2 file version supported by phosphor-webui.

---

The design shown above (Single file version - update 1) has been tested with a few users. We are now in the process of making a new iteration.

[ParishrutB]

Questions

Host Shutdown
In this prototype, the host shutdown is required because:

1. The ApplyTime='Immediate' property being used while uploading the file. This forces the new firmware to be applied as soon as the upload is completed, followed by a BMC reboot.
2. The host is required to be shut down so that both the BMC and host are running the same firmware level, as phyp is expecting a 'single image' behaviour.
3. Also concurrent updates (updating the host while it is running) are not possible.

**Question: With respect to which of the above points is the update process different for you?

[williamspatrick]

• What is an "update access key"? This sounds like you're charging your customers for the privilege of being able to update? Is there an easy method to disable this feature? I don't think it should be enabled by default in the opensource version.

• The language implies to me that the server is limited to 2 images: "current" and "backup". This might be a limitation in your implementation but it isn't a fundamental limit.

• A "single tar containing BMC and Host" is very specific to your design and generally not applicable. Most systems support independent update of the BMC and Host firmware. Many systems support updating various firmwares which are not those two: VRs, GPUs, TPMs, CPLDs; just to name a few.

[derick-montague]

Thanks for the feedback @williamspatrick!
A couple of clarifications.

1. We are not looking to extend beyond what phosphor-webui supported other than the single file image
2. There is a two-file image page that is the same as phosphor-webui

What is an "update access key"? This sounds like you're charging your customers for the privilege of being able to update? Is there an easy method to disable this feature? I don't think it should be enabled by default in the opensource version.

Yes, this is proprietary and will not be enabled by default. The design will accommodate this.

A "single tar containing BMC and Host" is very specific to your design and generally not applicable. Most systems support independent update of the BMC and Host firmware. Many systems support updating various firmwares which are not those two: VRs, GPUs, TPMs, CPLDs; just to name a few.

Agreed, this is proprietary and will need to be toggled in some way for the build

The language implies to me that the server is limited to 2 images: "current" and "backup". This might be a limitation in your implementation but it isn't a fundamental limit.

We are also moving to Redfish and I expect much of this conversation is also taking place with the community. Phosphor-webui only supported two images as well, functional and active. Intel is also moving to the single image model. However, we know that not everyone has, which is why we still have the two file upload model that is used on phosphor-webui.

[williamspatrick]

By “single image model” you mean the tarfile, right? This model might work for commercial vendors, but it won’t work for data center vendors (like FB); not that we really use the webui for deploying updates. We have different teams managing different sets of firmware and work directly with vendors to get them. The rate we receive and deploy updates for BMC vs BIOS vs VR is quite different.

[derick-montague]

By “single image model” you mean the tarfile, right?

Even in two file upload where the BMC and Host FW were separate, we were still using tar files. In this case, single file means BMC and Host are both included in the update with one uploaded file. Opposed to having to upload two different files to update the host and BMC.

This model might work for commercial vendors, but it won’t work for data center vendors (like FB); not that we really use the webui for deploying updates. We have different teams managing different sets of firmware and work directly with vendors to get them. The rate we receive and deploy updates for BMC vs BIOS vs VR is quite different.

Is there a need from the UI for webui-vue that is different than what was supported on phosphor-webui? It sounds like any orgs not managing stand-alone systems that rely on the GUI are not impacted by this design. Is that reasonable?

[williamspatrick]

Is there a need from the UI for webui-vue that is different than what was supported on phosphor-webui? It sounds like any orgs not managing stand-alone systems that rely on the GUI are not impacted by this design. Is that reasonable?

I'll be honest that I don't know exactly what modes were supported in phosphor-webui.

I'm not necessarily expecting you to implement support for any of these concerns if they aren't relevant to IBM, but hopefully the GUI is designed in a way to be extensible for someone else to come around and add it. It would be unfortunate, to me, if adding support for updating Voltage Regulators would require a completely new interface / design.

[jmbills]

Intel is also moving to the single image model.

To clarify, Intel doesn't have a tar file with a combined BMC and Host firmware image included. The "single image" upload that I was thinking is that we can upload either a BMC or Host or other firmware in the same box and the back-end service will detect what type of image it is and handle it appropriately. We don't need two separate upload boxes, but the single upload box would be for any type of firmware supported by the BMC Redfish UpdateService. I'm not sure how best to represent this in the UI, though.

[derick-montague]

@jmbills: To clarify, Intel doesn't have a tar file

Good to know that .tar can not be a file type requirement. If we had an idea of what all the possible file types were, we could add those types to improve the user's experience. I know that this conversation is happening in the community with @anoo1. @ParishrutB and/or @priyanka-pillai97 will verify the expectation, but I do think that you can provide either BMC or Host, but also able to upload them together in a compressed file.

@williamspatrick: It would be unfortunate, to me, if adding support for updating Voltage Regulators would require a completely new interface / design.

If I understand correctly, you are thinking the firmware update could be extended to so that you could also show a voltage regulators version and it could be updated in the same way. Is that accurate? If so, that would not require a completely new interface, but it would require changes to show what version of voltage regulators the system was running.

[williamspatrick]

If I understand correctly, you are thinking the firmware update could be extended to so that you could also show a voltage regulators version and it could be updated in the same way. Is that accurate?

Yes. The dbus interface is designed in a way that it can support firmware update of arbitrary components. We just need to implement the VR version of the internals.

Good to know that .tar can not be a file type requirement.

I think you clipped jmbills' statement mid-sentence. I don't think anyone has said that .tar isn't a reasonable file type for firmware update containers. That is how they are currently defined internally to be is a tar-archive with special files in it.

To clarify, Intel doesn't have a tar file
... with a combined BMC and Host firmware image included

[derick-montague]

@jmbills

We don't need two separate upload boxes, but the single upload box would be for any type of firmware supported by the BMC Redfish UpdateService. I'm not sure how best to represent this in the UI, though.

That is how it works today in phosphor-webui. The difference in the UI will be what we were calling the two file upload, which is misleading. It is a UI that shows the host and the BMC individually and doesn't have anything do do with how the files are uploaded. We will have a UI for that also we aren't there yet.

[ParishrutB]

Firmware Update - Version 2

Improvements:

1. 2 file version added.
2. Minimum firmware required - Systems that are patched with a minimum code required property show this information on the GUI.
3. Simplified process updates.

---

Key screen - Single file version

Access key expired and server powered on.

Note:

• Access key is proprietary and will not be enabled by default.
• Minimum version required is only applicable if it has been applied to the system.

Access key updated and server powered off.

Key screen - Two file version

Access key expired and server powered on.

---

Flow

In the previous iteration, we had tried to show process updates through both the Firmware Update section and the toast messages, but seeing them in two places was confusing for users. So in this iteration, we focussed on showing most of the process updates only through the process section.

Once the server is shut down, the update section is enabled.

The user can select the upload location (workstation by default) and add a file. We have used a dropdown for the File Location so that different options required by the community can be accommodated without changes to the design.

After clicking Refresh in the above screen...

---

Firmware update - error

In the following example, there was an error after the upload, at the activation stage. While the update steps show where the error occurred, a toast notification is used to communicate more detail and the next step. Note that the backup image got deleted due in the activation process. This has not been highlighted as an error because we found that it distracted users from trying to update again - once the next update is successful, the running image becomes the backup image.

[ParishrutB]

Share your thoughts with us!

• What do you like or dislike about the design?
• Is there anything that you think is confusing?
• Any ideas about where and how we can improve it?

[derick-montague]

Some work in progress: https://gerrit.openbmc-project.xyz/c/openbmc/webui-vue/+/40317

[yoshiemuranaka]

We've stripped down a lot of what @ParishrutB initially proposed. screenshots below of updated designs

Default build

IBM build

Some of the enhancements to make the page dynamic:

• Disabled form and additional alerts depending on server status
  • By default the forms will not be disabled
• TFTP upload option
  • By default will not show TFTP unless it's listed as an allowable value from UpdateService
• Combined BMC and Host firmware 'cards'
  • Checks all firmware images, if includes BMC and Host images, the layout will display 4 cards

[derick-montague]

This has already been implemented. If there are bugs with the design, we can open new issues.