Updating an embedded system

SWUpdate is a Linux update agent that provides an efficient and safe way to update an embedded Linux system in the field. SWUpdate supports both local and OTA updates, as well as multiple update strategies, and is designed with security in mind.

Main Features

Update Everything
• SWUpdate can update all components of your device, including:
• Bootloader
• Linux Kernel
• Root filesystem
• Applications
• FPGAs
• Firmware on a separate microcontroller

Hardware compatibility

SWUpdate verifies that the delivered software is compatible with the target device. This is done by checking each release against a hardware compatibility map.

Rescue System

SWUpdate’s small footprint allows for the creation of a rescue system that runs automatically if your device fails to boot.

Extensible

SWUpdate integrates a Lua interpreter. Projects can extend SWUpdate's functionality by adding custom installers.

Atomic Update

Atomic updates prevent power cuts and network losses from bricking your device. The new software is either fully installed, or the update is interrupted, leaving the device in its previous running state. There are no partial software updates, as can happen with package-based updaters.

Zero copy

When configured for a small footprint, SWUpdate does not create temporary copies; incoming packets are installed directly to the storage medium. The entire process (decompression, decryption) is done on chunks in memory, making it more difficult for an attacker to access.

Update Authenticity

Update packages are signed and verified by SWUpdate to ensure an authorized and trusted update. SWUpdate supports signing with RSA keys and with certificates using its own PKI infrastructure.

Embedded Media Support

SWUpdate is suitable for all embedded storage types. It natively supports NOR, NAND, eMMC, SPI Flash, and UBI volumes. There are no constraints on your memory layout, giving you full control over where your software is installed.

Rollback

SWUpdate, in conjunction with the bootloader, detects if the installed software is running correctly. In case of failure, it automatically rolls back to the previously installed version.

Multiple interfaces

SWUpdate supports both offline (USB, SD, etc.) and remote (OTA) updates. It has an integrated web server for upgrading devices like SOHO routers and can also connect to a backend like Hawkbit for fleet deployments. The modular design allows for adding more backends or interfaces in the future.
SWUpdate also provides a library that can be linked to your application if you have a custom method for receiving the update package. The library is licensed under the more permissive LGPLv2.1 and can be used with closed-source applications.

Reliable

Atomic updates prevent power cuts and network losses from bricking your device.

Update Procedure

To perform an OTA update, follow these steps:

1. Create a base image and an update image.
2. Boot the kernel with the base image and enter OTA mode.
3. Download the update image to the target partition.
4. Reboot the system and synchronize the update status.
5. Perform recovery if the update fails.

The demo procedure uses the Mongoose web server.

Single copy – running as a standalone image

• A standalone image consists of the kernel, device tree (DT), and an initrd.
• It is smaller than the entire system.
• The bootloader is responsible for loading the standalone image.
• The system must reboot to enter the update process.

Double copy with fall-back

• A double-copy setup requires twice the storage space of a single-copy setup.
• It guarantees that there is always a working copy of the system.
• The bootloader is responsible for booting the correct image.

[NOTE]

The meta-tn-imx-bsp has not yet implemented the double-copy feature.

Base Image Layout

The double-copy layout does not have a ramdisk, and the single-copy layout does not have the second copy of the kernel, DTB, and rootfs.

Bootloader Upgrade

The bootloader is used to check the update result, switch the boot system, and perform recovery. Generally, there is no second copy of the bootloader, so it is not recommended to upgrade it. The device could be bricked if a power loss occurs during the bootloader update. Some SoCs allow for multiple copies of the bootloader, but there is no general solution for this, as it is hardware-dependent. While i.MX series chips may support a secondary boot image for a two-copy bootloader setup, a bootloader upgrade is still not recommended.
Note:
It is not guaranteed that all i.MX chips support a secondary boot image.

Power Failure Recovery

When a power loss occurs, the system must be guaranteed to remain functional. This means it must either restart SWUpdate to retry the update or restore the old copy of the software.
The behavior differs based on the chosen scenario:

• Single copy: If SWUpdate is interrupted, the update transaction will not complete. The bootloader can then restart SWUpdate to attempt the update again.

• Double copy: If the update is interrupted, SWUpdate will not switch between the standby and active copies. The version of the software untouched by the update is simply restarted.

For safety purposes, SWUpdate and the bootloader must exchange information. The bootloader must detect if an update was interrupted by a power loss and restart SWUpdate until the update is successful. U-Boot has a power-safe environment that SWUpdate can read from and write to in order to communicate with it. SWUpdate sets a flag when it starts an update and resets the same flag upon completion. The bootloader can read this flag to check if an update was in progress before the device powered off.

For detailed information, please refer to Embedded Software Update Documentation