Software update

A common requirement for embedded systems is the possibility to update the device software in the field.

The Kontron BSP addresses this requirement with its yocto demo image image-ktn-swu. This image provides the SWUpdate embedded update framework (see https://sbabic.github.io/swupdate/) on top of a double copy AB boot scheme with fallback boot and power-cut safety. With this setup it is easy to explore the possibilities and different aproaches SWUpdate offers. It is also a good starting point for other update approaches.

Some features

  • Boot counter support to detect boot failures and switching to a fallback image if the boot counter limit exceets
  • Two copies of bootable software in root_A and root_B partition of the root device. One of it is used as 'active' partition, the other as 'standby', which is used for a fallback boot.
  • Interrupted updates end up in the same partition as the update was started. The interruption is reported as separate update state.
  • SWUpdate provides various approaches to detect and update new software. For the BSP demo image the web server interface for updates is activated.
  • No writable environment is required for the boot loader.

How to use

These are the steps to equip your board with the SWUpdate demo image

  • Build the image-ktn-swu for your board like the normal image-ktn (see Building an image)
  • Flash your SD card with this image (see Create image with yocto) and equip the desired root storage (NAND or eMMC) with this image with the help of mptool.
  • After this, reboot your system into the newly flashed software

SWUpdate web interface is started automatically on port 8080 of your device. Now you are able to update your system by web interface.

SWUpdate requres so called *.swu files which contain the new software and some scripts required for the update. The BSP provides recipes to build such a 'swu' package for the image-ktn-swu. The appropriate recipe to build the *.swu file for image-ktn-swu is swupdate-img. To build this package with yocto bitbake use this command:

bitbake swupdate-img

Afterwards you find the update package file in the images directory of the yocto build. This is the file required to update the device firmware with the new built software.

Requirements for SWUpdate functionality

The full feature for embedded update is divided into two main areas:

  1. Switching between 'active' and 'standby' boot slot based on boot counter and update state in a power-cut save manner
  2. Doing the update with transmission, validation and flashing

The first part requires a deep integration in the system architecture. This requires adaptions for the bootloader and storage partitioning. With image-ktn-swu this is already done in the Kontron BSP and u-boot bootloader. For the Linux userspace part abootctl is selected to implement the switching between the two root filesystems and for calculating the system boot and update state.

Also without SWUpdate, abootctl provides the software abstraction to implement a software update strategy.

For AB double copy systems with abootctl the following storage structure is required:

  • A boot partition whitch contains all required boot files for the two root partitions. Currently this is the Linux kernel and devicetree files. But it could also be a FIT image. The different files are stored in the root_A and root_B subdirectory. This partition has to be formatted with ext4 filesystem and mounted on /boot directory when the device boots.
  • Two partitions root_A and root_B for the appropriate root filesystem.

The names for these partitions are a fixed requirement. root_A and root_B for abootctl, boot for the u-boot bootloader. For SD or eMMC storage this must be the partition label, for UBIFS they are volume names. There may be more partitions or volumes on the root device, but they don't influence the AB boot logic and can be created as required.

Additionally the root file systems root_A and root_B are reqired to be also on the same storage device.