[fwutil.md] Fwutil Auto-update support #648

sujinmkang · 2020-07-14T07:23:21Z

Update fwutil to support for the automatic fw update with boot/action option based on platform_components.json

instead of having a separate utility to perform similar job

nazariig · 2020-08-02T16:21:30Z

doc/fwutil/fwutil.md

+                    "script": "/usr/share/sonic/<platform_name>/<onie_platform>/fw_update/bios_fw_update",
+                    "version": "0ACLH003_02.02.010"
+                    "required_reboot": "None"
+                    "immediate_action": "No"


@sujinmkang IMHO, this should be fetched automatically by Platform API if needed.
The config file should be simple and clear.

Use case: the same firmware package may have a different behaviour based on device vendor/model.
Example: SSD with/without on-the-fly update mode

nazariig · 2020-08-02T16:23:00Z

doc/fwutil/fwutil.md

@@ -340,7 +340,7 @@ The purpose of the update commands group is to provide an interface
 for automatic FW installation of various platform components.

 Automatic FW installation requires platform_components.json to be created and placed at:  
-_sonic-buildimage/device/<platform_name>/<onie_platform>/platform_components.json_
+_sonic-buildimage/device/<platform_name>/<onie_platform>/platform_fw_updatecomponents.json_


@sujinmkang Typo? Maybe it's better to have something like platform_fw_updates?

nazariig · 2020-08-02T16:26:19Z

doc/fwutil/fwutil.md

                    "version": "10"
                },
                "FPGA": {
-                    "firmware": "/etc/<platform_name>/fw/<onie_platform>/chassis1/fpga.bin",
+                    "firmware": "/usr/share/sonic/<platform_name>/<onie_platform>/fw_update/fpga.bin",


@sujinmkang Not sure whether this is the right place for fw binaries. Also this may overlap with the sonic_device_data package contents.

nazariig · 2020-08-02T16:35:44Z

doc/fwutil/fwutil.md

+...
+FW update in progress ...
+...
+root@sonic:~# fwutil --yes --image=next --boot=any --immediate=yes --component=ssd


@sujinmkang What about modular platforms? AFAIK, there is no clear restrictions on component names, which means that different modules can share the same component name. And what should be the expected behaviour in that case?

nazariig · 2020-08-02T16:51:38Z

doc/fwutil/fwutil.md

@@ -454,6 +486,24 @@ Warning: <firmware_update_notification>
 New FW will be installed, continue? [y/N]: N
 Aborted!
 ```
+3. Non modular chassis platform
+```bash
+root@sonic:~# fwutil --yes --image=next --boot=cold --immediate=yes


@sujinmkang I suggest to use something like:
fwutil update components fw --yes --image=next --boot=fast

nazariig · 2020-08-02T17:19:47Z

doc/fwutil/fwutil.md

+1. Find the available firmware based on boot type and immediate action type from platform specific fw update configuration file. 
+   Exit if no configuration file exists.
+2. Update the firmware using the script if it's specified in the configuration. Otherwise, fwutil will use the platform api to update the firmware.
+   Exit if the update fails in any step.


@sujinmkang Some thoughts:

In case platform API is not implemented (plugin mode) the fwutil CLI won't be fully available - only automatic installation mode. That's something which need to be highlighted in this design

Platform API should be extended with the new boot argument

How to handle version and script fields in case Platform API is not implemented

Need to extend the design with some output examples for automatic installation mode

rkdevi27 · 2020-08-19T09:46:53Z

doc/fwutil/fwutil.md

+    ...
+    if [[ -x ${PLATFORM_FW_UPDATE} ]]; then
+        debug "updating platform fw for ${REBOOT_TYPE}"
+        ${PLATFORM_FW_UPDATE} auto-update --yes --image={NEXT_BOOT_IMAGE} --boot=${REBOOT_TYPE}


Hi Sujin,

In what scenarios the fwutil command will include a reboot/powercycle? only in cases of immediate_(fast/warm/cold/powercycle)?

Also in few cases the upgrade may require unmount of filesystems and better to include them in the flow of reboot after unmounting filesystems. In that case fwutil can do just the placing of files in correct location and the actual upgrade will be done only as part of the reboot script. In those scenarios if this command just places the file, in what ways the actual upgrade can be included in these scripts?

Do you know the answer about your first question? I also have this question.
####In what scenarios the fwutil command will include a reboot/powercycle? only in cases of immediate_(fast/warm/cold/powercycle)?####

padmanarayana · 2020-09-29T17:35:50Z

doc/fwutil/fwutil.md

+    "component": {
+        "BIOS": {
+            "firmware": "bios.bin",
+            "version": "0ACLH003_02.02.010",


boot option needs to be added

padmanarayana · 2020-09-29T17:38:44Z

doc/fwutil/fwutil.md

+...
+CPLD firmware update is in progress with version 5 (current version 4)
+...
+CPLD firmware update is completed with version 5 (current version 4)


So, in the CPLD example above, the fwutil auto-update will be functionally equivalent to the existing "fwutil install" command, please mention this in the description.

padmanarayana · 2020-09-29T17:39:58Z

doc/fwutil/fwutil.md

+1.	Firmware
+2.	Boot action following after the firmware auto-update process
+3.	Fwutil action : -a(--autoupdate)
+**Utility can be supported for other platform api substitues like `compoenent_update` and `compoenent_install` with |-u(--update)|-i(--install)**


rkdevi27 · 2020-09-29T17:54:31Z

doc/fwutil/fwutil.md

+"True" : "completed"
+"True" : "scheduled"
+"False" : Error
+```


The "fwutil show auto-update" command has status as "updated but need a power-cycle". Please explain how these status will be derived from these utility return strings described above.

nazariig · 2020-11-18T20:39:27Z

doc/fwutil/fwutil.md

+|
+|--- auto_update
+     |--- fw -i|--image=<current|next> --b|--boot=<any|none|fast|warm|cold|powercycle>
+     |--- fw -z|--fw-image=<fw_package.tar.gz> --b|--boot=<any|none|fast|warm|cold|powercycle>


@sujinmkang How do you expect to handle power cycle scenario? SONiC can only distinguish between cold/fast/warm reboots in scope of firmware upgrade framework.

that is good question. I think we should limit this boot option to non/fast/warm/cold.

@sujinmkang Looks good. Please update the design

nazariig · 2020-11-18T20:41:28Z

doc/fwutil/fwutil.md

@@ -184,6 +201,8 @@ fwutil
 |    |--- version
 |    |--- status
 |    |--- updates -i|--image=<current|next>
+|    |--- updates -z|--fw-image=<fw_package.tar.gz>


@sujinmkang what is the expected behaviour when --image=next and --fw-image=<fw_package.tar.gz> are provided simultaneously?

We should take only one option. my current implementation takes the --fw-image option over --image option. Should we return error when user gives both option for one fwutil call?

nazariig · 2020-11-18T22:40:23Z

doc/fwutil/fwutil.md

+From the above `platform_components.json` example, if the platform needs the SSD firmware update, then the auto-update can be triggered with following command.
+`$PWD/ssd_fw_update -a $PWD/SSD.bin fast` 
+
+##### 2.2.2.4.3.2 Platform Firmware Update Reboot Handle Plugin


@sujinmkang please elaborate a bit more for a different flows (cold/warm/fast): at which point do you expect to call this plugin?

nazariig · 2020-11-18T22:48:01Z

doc/fwutil/fwutil.md

@@ -462,6 +519,321 @@ Aborted!

 **Note:** the default option is _--image=current_

+#### 2.2.2.4 Auto-update commands
+
+##### 2.2.2.4.1 Overview


@sujinmkang in case of boot_action=any what should be the expected behaviour if platform component supports both cold and fast reboot? Do we expect platform API will add this item to both cold_* and fast_* task lists?

As I replied in your previous question, we need to limit the boot action by none/fast/warm/cold. And in the previous comments, we don't support multiple firmware auto update for the same or other boot type.

nazariig · 2020-11-18T22:50:44Z

doc/fwutil/fwutil.md

+The Utility should support the minimum requirements to perform the fwutil auto-update interface. 
+The minimum requirement is that the component api's get_frimware_version, get_firmware_update_notification(), and auto_update_firmware() needs to be supported by the utility.
+Here are the interface requirements to support them.
+1. {utility} -s(--status) : able to retrieve the current firmware version:


@sujinmkang how do we expect to use this info in FW tools when we don't have a way to read the original (before the update) firmware version?

This api should retrieve the original version from the platform device. not the update firmware version.

nazariig · 2020-11-18T22:53:04Z

doc/fwutil/fwutil.md

+2. {utility} -n(--notification) : able to provide the update complete action :
+    - equivalent to the component api's get_firmware_update_notification(image_path) 
+    - response : the required action to complete the component installation
+3. {utility} -a(--autoupdate) : able to perform the auto-update action :


@sujinmkang why not to use a set of separate options: e.g. --fw and --boot

this utility will replace the platform api so I was expecting to pass the firmware path and boot type without any separate option. I will clarify this part.

@sujinmkang From the code changes, the utility -a interface alone has been used. So is it required for the utility to have the other interfaces implemented?

nazariig · 2020-11-18T22:54:54Z

doc/fwutil/fwutil.md

+
+
+if [[ -x ${PLATFORM_FW_UPDATE} ]]; then
+    ${PLATFORM_FW_UPDATE} auto-update fw --yes --image=next --boot=${REBOOT_TYPE}


@sujinmkang is it ok for you that firmware update may not happen if there is no platform components which support this boot action?

Yes. if there is no platform component firmware update available for the boot action, no firmware update is expected. The fwutil will return a message saying "no update is available for the specific boot type"

nazariig · 2020-11-18T23:00:53Z

doc/fwutil/fwutil.md

+
+SONiC device can have a component firmware updated without interrupting the data plan if the component firmware update doesn't need any boot action.
+```bash
+root@sonic:~# fwutil auto-update fw --fw-image=aboot-fw-update.tar.gz --boot=none


@sujinmkang What if the cold/fast/warm boot was specified as the desired action but some of the platform components do support firmware upgrade without dataplane interruption? Do we expect the update will take place implicitly or we still do want to do only with --boot=none?

That is good question. Without boot option, the update which can be done without data plane interruption, should be performed implicitly. I will add the default setting for boot type.

sujinmkang · 2020-11-24T18:08:30Z

@nazariig Can you please review this again?

nazariig · 2020-11-29T21:20:50Z

doc/fwutil/fwutil.md

+|
+|--- auto_update
+     |--- fw -i|--image=<current|next> --b|--boot=<any|none|fast|warm|cold|powercycle>
+     |--- fw -z|--fw-image=<fw_package.tar.gz> --b|--boot=<any|none|fast|warm|cold|powercycle>


@sujinmkang Looks good. Please update the design

nazariig · 2020-11-29T21:36:42Z

doc/fwutil/fwutil.md

@@ -257,6 +280,7 @@ Chassis   Module   Component   Firmware               Version (current/available
 Chassis1  N/A      BIOS        <image_path>/bios.bin  0ACLH004_02.02.007 / 0ACLH004_02.02.010  update is required
                   CPLD        <image_path>/cpld.bin  5 / 10                                   update is required
                   FPGA        <image_path>/fpga.bin  5 / 5                                    up-to-date
+                   SSD         <image_path>/ssd.bin   4 / 5                                    update is required


@sujinmkang We need a way to inform user about what components do support automatic firmware upgrade (e.g, if i do auto-update, the framework will definitely try to upgrade firmware of that components). Without this the behaviour will be non deterministic, since the decision will be taken at field by platform API/plugin. Taken this into consideration, i would expect to see some Auto Update column here with values Yes/No

@nazariig All components need to support the automatic firmware update but only any component firmware update won't happen during this boot time if the auto-update cannot be done for the boot type. And user will notify the components firmware update cannot be done for the boot-type. I don't think it's necessary.

nazariig · 2020-11-29T22:25:26Z

doc/fwutil/fwutil.md

+#### 2.2.2.4 Auto-update commands
+
+##### 2.2.2.4.1 Overview
+The purpose of the auto-update commands group is to provide and interface for automatic fw updates of various platform components based on the boot option and the platform firmwareupdate configuration file - "platform_components.json".


@sujinmkang please fix a typo firmware update

nazariig · 2020-11-29T23:03:43Z

doc/fwutil/fwutil.md

+{
+    "<boot_type>": [
+        {
+            "status": <true/false>,


@sujinmkang please update the design with status codes

@nazariig This is how fwutil save the status of auto-update in the fw_au_status file. I'm proposing that fwutil needs to process the return code of platform component api and save the process data as this format.

nazariig · 2020-11-29T23:05:23Z

doc/fwutil/fwutil.md

+_sonic-buildimage/device/<platform_name>/<onie_platform>/platform_components.json_
+Recommended image path is "/lib/firmware/<vendor>".
+
+Auto-update command can support the standalone custom firmware image package with --fw-image option.


@sujinmkang can we have a schema of this custom firmware package and some examples in design document?

nazariig · 2020-11-30T00:02:35Z

doc/fwutil/fwutil.md

+
+Auto-update command can support the standalone custom firmware image package with --fw-image option.
+The package can be any format between ".tar" or ".tar.gz" and should have the "platform_components.json", the firmware image(s).
+The package can have the auto-update plugin if the platform doesn't support platform api or if plugin needs to be updatedplugin.


@sujinmkang IMHO, the original idea of FW package was to provide an ability to do the upgrades on platforms which don't support platform API. Do we really want to use it for upgrades which involves platform API, when fwutil is already provides an infrastructure for that (e.g, this can be achived with FW deb packages)?

@nazariig I think it's good point. I understand we use the FW deb package to installed firmware which is missing from the current package. We can support both for the new firmware update based on the current image. But when we use a deb package to perform auto-update, we need 3 steps, push the firmware deb package, install the deb package and fwutil auto-update while this FW package approach needs 2 steps for auto update, push the FW package and fwutil aut-update with the FW package.

sujinmkang · 2020-11-30T08:26:00Z

@padmanarayana @nazariig @rkdevi27 can you please review this again? I want to close this by tomorrow. Thanks!

…turn code: installed

nazariig · 2020-12-18T12:01:17Z

doc/fwutil/fwutil.md

+|         |--- component <component_name>
+|              |--- fw -y|--yes -f|--force -i|--image=<current|next>
+|
+|--- auto-update


@sujinmkang Please update CLI tree to use new update all format

nazariig · 2020-12-18T12:02:18Z

doc/fwutil/fwutil.md

 ```
 fwutil
 |--- show
 |    |--- version
 |    |--- status
 |    |--- updates -i|--image=<current|next>
+|    |--- updates -z|--fw-image=<fw_package.tar.gz>
+|    |--- auto_update_status


@sujinmkang we need to refactor this part too since moving from auto-update to update all

I think this can be changed to update_status but I hope this doesn't mislead people to think that they could check the each component update done by fwutil update {chassis|module <module_name>} component <component_name> fw ....
But I agree to change the command.

nazariig · 2021-01-26T11:20:52Z

@sujinmkang Can we also have original documents (visio) as part of this PR? Just in case of further modification will be needed?

) To support the component firmware automatic update, add auto_update_firmware() to platform component api This is to support fwutil auto_update command to update the platform component firmware automatically. Fwutil HLD to support auto_update interfaces/commands. sonic-net/SONiC#648

…mponent fw updates (#1242) - What I did Add the support for the automatic platform component fw updates - How I did it Add fwutil auto_update interfaces - How to verify it Work with dell to verify the auto_update interfaces with ssd firmware update. - Previous command output (if the output of a command-line utility has changed) - New command output (if the output of a command-line utility has changed) New added command outputs are available in the following HLD: sonic-net/SONiC#648

sujinmkang added 2 commits July 14, 2020 00:21

initial version of platform-fw-update hld

19325ff

Update fwutil to support the automatic fw update

fc6ea86

instead of having a separate utility to perform similar job

sujinmkang changed the title ~~initial version of platform-fw-update hld~~ Update fwutil to support for the automatic fw update with boot/action option Jul 26, 2020

Auto fw update

16ed6f2

sujinmkang requested a review from nazariig July 27, 2020 21:31

nazariig reviewed Aug 2, 2020

View reviewed changes

sujinmkang added 3 commits August 3, 2020 16:23

update

e7cf636

add auto-update command to support automatic firmware update

15b74f0

fix some command options

a16ee43

sujinmkang changed the title ~~Update fwutil to support for the automatic fw update with boot/action option~~ FwUtil Auto-update support Aug 12, 2020

sujinmkang marked this pull request as ready for review August 12, 2020 06:01

platform_componenets.json

04cc424

rkdevi27 reviewed Aug 19, 2020

View reviewed changes

sujinmkang added 7 commits August 21, 2020 00:06

add more custom scripts details and fw_update_reboot_plugin

e8c8a15

Update

503c3e8

typo

4a7454f

review comment

72a0845

more auto-update utility requirement

ff5441b

add utility commandline example

ac2bc84

utility response

4b14a26

padmanarayana reviewed Sep 29, 2020

View reviewed changes

rkdevi27 reviewed Sep 29, 2020

View reviewed changes

address review comments

c4aed03

nazariig reviewed Nov 18, 2020

View reviewed changes

sujinmkang added 3 commits November 20, 2020 01:43

review comments

44afb41

review comments

289263e

review comments

8700f97

padmanarayana approved these changes Nov 24, 2020

View reviewed changes

rkdevi27 approved these changes Nov 24, 2020

View reviewed changes

nazariig suggested changes Nov 30, 2020

View reviewed changes

add more detail about FW package

efca3bf

sujinmkang added 2 commits December 2, 2020 15:27

Add more information about firmware image package and platform api re…

8cbf627

…turn code: installed

update with review comments

93416e5

nazariig reviewed Dec 18, 2020

View reviewed changes

sujinmkang added 2 commits December 18, 2020 14:27

additional review comments

4c76c14

Add more requirements for auto-update

3574859

nazariig approved these changes Jan 26, 2021

View reviewed changes

sujinmkang changed the title ~~FwUtil Auto-update support~~ [fwutil.md] Fwutil Auto-update support Jan 26, 2021

sujinmkang merged commit b72d76b into sonic-net:master Jan 26, 2021



		if [[ -x ${PLATFORM_FW_UPDATE} ]]; then
		${PLATFORM_FW_UPDATE} auto-update fw --yes --image=next --boot=${REBOOT_TYPE}

[fwutil.md] Fwutil Auto-update support #648

[fwutil.md] Fwutil Auto-update support #648

Conversation

sujinmkang commented Jul 14, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nazariig Aug 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nazariig Aug 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nazariig Nov 18, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nazariig Nov 18, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nazariig Nov 18, 2020 • edited Loading

Choose a reason for hiding this comment

nazariig Nov 18, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nazariig Nov 18, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nazariig Nov 18, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sujinmkang commented Nov 24, 2020

Choose a reason for hiding this comment

nazariig Nov 29, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sujinmkang commented Nov 30, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nazariig commented Jan 26, 2021

sujinmkang commented Jul 14, 2020 •

edited

Loading

nazariig Aug 2, 2020 •

edited

Loading

nazariig Aug 2, 2020 •

edited

Loading

nazariig Nov 18, 2020 •

edited

Loading

nazariig Nov 18, 2020 •

edited

Loading

nazariig Nov 18, 2020 •

edited

Loading

nazariig Nov 18, 2020 •

edited

Loading

nazariig Nov 18, 2020 •

edited

Loading

nazariig Nov 18, 2020 •

edited

Loading

nazariig Nov 29, 2020 •

edited

Loading