Robust Software Updates for Embedded Linux: SWUpdate in our Yocto BSPs

Date : 3. August 2026

OTA and offline updates for embedded Linux devices – project-oriented, security-focused and Yocto-integrated.

An embedded device that runs in the field for many years needs an update path that lasts just as long. With the Cyber Resilience Act, maintainability turns from a nice-to-have into a requirement: security updates have to reach devices in a planned and traceable way – even years after delivery. This is exactly where SWUpdate comes in, and in our Yocto BSPs the framework is already integrated. This article shows how we use SWUpdate in customer projects and what matters for a dependable update concept.

Robust software updates for embedded Linux with SWUpdate in our Yocto projects

Embedded devices today have to stay maintainable over many years: security updates, bug fixes, new features or customer-specific changes need to reach the field reliably – without recalling devices and without rebuilding the update concept every time.

That is precisely why we rely on SWUpdate in our Yocto projects, an established open-source framework for software updates on embedded Linux systems. For our computer modules, we can provide customers with project-specific Yocto meta-layers that they build along and integrate into their systems. This approach has already been used in customer projects based on STM32MP13, STM32MP15, i.MX6ULL and i.MX8.

Why SWUpdate?

SWUpdate is not a rigid "one-size-fits-all" updater, but a flexible framework. That is decisive in the embedded space in particular: memory layout, bootloader, flash technology, update source and security requirements differ from project to project. SWUpdate can be configured accordingly – instead of artificially forcing the target system into a fixed update scheme.

One update package – many components

With SWUpdate, several parts of a system can be combined into a single .swu update package, for example root filesystem, kernel, device tree, application, configurations or further artifacts. The central sw-description file describes which components are installed and how they should be processed.

For Yocto-based projects this is especially interesting: with the meta-swupdate layer, SWU packages can be generated directly from the build process. This makes the update artifact reproducible and matches exactly the images that are built in the Yocto project anyway.

More security through signatures and hash verification

A professional update mechanism has to ensure that only authorized and unmodified software is installed. SWUpdate supports signed update descriptions and hash checks of the individual artifacts. In practice this means: the target system can verify whether an update comes from a trusted source and whether the included components match the released release description.

Depending on project requirements, signature methods such as RSA, CMS certificates or GPG can be used. In addition, artifacts can be encrypted if update content is to be transported or stored in a protected way.

Robust against power loss and faulty updates

In the field, what counts is not only that an update can be installed – but that a device reliably boots again afterwards. SWUpdate is designed to work together with the bootloader. Through persistent status information, the bootloader can detect whether an update was interrupted or whether a new software version still needs to start successfully and confirm itself. This makes A/B or dual-copy concepts possible, where the previous software is kept as a fallback. If the new version fails to start, the system can roll back to the previous version. This mechanism is an important building block to keep devices updatable in the field and to reduce service visits.

Suitable for resource-constrained embedded systems

Many embedded systems have limited RAM and flash memory. SWUpdate takes this into account through a modular architecture and supports streaming and zero-copy mechanisms. Update data can be processed directly, without having to store complete temporary copies in RAM or the file system. This is relevant especially for larger images or smaller memory configurations.

Flexible update paths: local, via web interface or OTA

Not every product needs a full cloud fleet management right away. Some devices are updated via USB stick during service, others through a local web interface, and still others via an OTA backend process. SWUpdate supports these different scenarios: local media such as USB or SD, an integrated web server, HTTP/HTTPS downloads as well as connection to backend systems like Eclipse hawkBit. This way a project can start with a simple update path and later extend to a fleet or OTA concept.

The benefit for our customers

Thanks to our Yocto meta-layers, customers don't have to reinvent the wheel for SWUpdate every time. Instead, they get a field-proven basis that can be embedded into the respective BSP and the specific hardware design.

This reduces integration effort and technical risk – especially for questions such as:

• Which components should be updated?
• How is the SWU package generated in the Yocto build?
• How is the bootloader tied into the update concept?
• How are signatures, hashes and hardware compatibility checks implemented?

• Which update path fits the product: USB, web interface, downloader or OTA backend?

   

Our conclusion

For embedded Linux products, SWUpdate is a technical building block that brings together security, maintainability and project specifics. For customers of our computer modules this means: a dependable update concept can be considered at BSP level from the start – and does not have to be retrofitted at the end of the product project.