Designing peripheral microcontroller firmware update strategy

[Shakta Exe]

I have been reviewing swupdate src and docs to get a better understanding of how it handles updating peripheral micocontroller firmware. I see that after the pre-install scripts are ran, each images found in the swupdate config are installed by calling their respective handler. I have not quite tracked down where the list of images gets populated.

Let's suppose I have a linux SOM attached to a microcontroller via UART. In my swu, I have a file node with rootfs in it as a tarball. I also have a pre/post shell script to assist with the update. I think I will need to add another node to the swu for the microcontrollers firmware image and then either use the built in ucfw handler or build a custom one.

When I am installing multiple images, are the images installed serially? It appears to me that the answer is yes. If so, can their order be controlled such that swupdate will abort if the microntroller firmware update fails? This is not clear to me.

- Shakta -

[Shakta Exe]

In a project I contributed to in the past, the approach for peripheral MCU firmware update strategy was to handle it outside of swupdate. The MCUs firmware blob was packaged into the rootfs. After updating & device reboot, on system startup a set of scripts/apps would handle updating the MCU if needed.

This approach has issues (not to mention having firmware blob on rootfs feels...wrong) and I think a better approach could be realized by leveraging swupdate framework and adding custom handler. I need to convince myself that is the case but have to learn a little more about swupdate internals first to weigh pros/cons.

- Shakta -

[Stefano Babic]

Hi Shakta,

On 06.09.23 22:07, Shakta Exe wrote:
> In a project I contributed to in the past, the approach for peripheral
> MCU firmware update strategy was to handle it outside of swupdate. The
> MCUs firmware blob was packaged into the rootfs. After updating & device
> reboot, on system startup a set of scripts/apps would handle updating
> the MCU if needed.
>
> This approach has issues (not to mention having firmware blob on rootfs
> feels...wrong) and I think a better approach could be realized by
> leveraging swupdate framework and adding custom handler.

Yes, but it depends on the implementation. It should be verified if
updating the microcontroller could be a single point of failure, and
what should be done in case of failure. Most approaches on
Microcontroller puts the microcontroller in bootloader mode, and then
the application is loaded. If the microcontroller has not dual-copy of
application software, it is a single point of failure.

> I need to
> convince myself that is the case but have to learn a little more about
> swupdate internals first to weigh pros/cons.

Best regards,
Stefano Babic

>
> - Shakta -
>
> On Wednesday, September 6, 2023 at 1:21:05 PM UTC-5 Shakta Exe wrote:
>
> I have been reviewing swupdate src and docs to get a better
> understanding of how it handles updating peripheral micocontroller
> firmware. I see that after the pre-install scripts are ran, each
> images found in the swupdate config are installed by calling their
> respective handler. I have not quite tracked down where the list of
> images gets populated.
>
> Let's suppose I have a linux SOM attached to a microcontroller via
> UART. In my swu, I have a file node with rootfs in it as a tarball.
> I also have a pre/post shell script to assist with the update. I
> think I will need to add another node to the swu for the
> microcontrollers firmware image and then either use the built in
> ucfw handler or build a custom one.
>
> When I am installing multiple images, are the images installed
> serially? It appears to me that the answer is yes. If so, can their
> order be controlled such that swupdate will abort if the
> microntroller firmware update fails? This is not clear to me.
>
> - Shakta -
>

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/e6d62652-a8f8-4977-b1c9-7c9df0d07180n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/e6d62652-a8f8-4977-b1c9-7c9df0d07180n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Shakta Exe]

Let's suppose my description file declares 2 images, one is an ext4.gz for the SOM and the other is a firmware binary for the peripheral MCU. Both components support double-copy, so MCU is not a single point of failure. And u-boot is bootloader.

I am curious what happens if the update is successful for the SOM image but not the MCU image. If I had to guess...

• The update for the SOM would still be written to the standby copy
• But swupdate would not update the boot partition in uboot env since one of the handlers resulted in failure
  

Is my guess correct?

- Shakta -

[Stefano Babic]

On 11.09.23 03:35, Shakta Exe wrote:
> Let's suppose my description file declares 2 images, one is an ext4.gz
> for the SOM and the other is a firmware binary for the peripheral MCU.
> Both components support double-copy, so MCU is not a single point of
> failure. And u-boot is bootloader.
>
> I am curious what happens if the update is successful for the SOM image
> but not the MCU image. If I had to guess...
>

> * The update for the SOM would still be written to the standby copy
> * But swupdate would not update the boot partition in uboot env since

> one of the handlers resulted in failure
>
> Is my guess correct?
>

Correct.

> https://groups.google.com/d/msgid/swupdate/e6d62652-a8f8-4977-b1c9-7c9df0d07180n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/e6d62652-a8f8-4977-b1c9-7c9df0d07180n%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/e6d62652-a8f8-4977-b1c9-7c9df0d07180n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/e6d62652-a8f8-4977-b1c9-7c9df0d07180n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> =====================================================================
> DENX Software Engineering GmbH, Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany

> Phone: +49-8142-66989-53 <tel:+49%208142%206698953> Fax:
> +49-8142-66989-80 <tel:+49%208142%206698980> Email: sba...@denx.de
> =====================================================================

>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/3f415cca-d0e7-44ad-bfa5-145d1a8506f1n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/3f415cca-d0e7-44ad-bfa5-145d1a8506f1n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Shakta Exe]

Are the handlers for the images executed serially, in the order they are found in the description file?

- Shakta -