Over the air update for embedded Linux systems
The ability to update embedded systems remotely has become an important part of modern product development. Products that were previously supplied with fixed software for their entire lifetime now often need to be able to receive security updates, functional improvements and fixes after they have been put into service. For companies developing electronic products with Linux-based software, (F)OTA – or Firmware over the air update – is therefore more than just a technical feature. It is a way of maintaining, securing and further developing the product throughout its entire life cycle.
In this article, we’ll go through the basics of OTA updates for embedded Linux, how different architectures such as A/B partitions work in practice, and how to manage security risks (CVEs) and avoid the most common pitfalls during implementation.
What is an OTA update?
An OTA update is a method of updating firmware or software remotely via a network, such as the internet or a mobile network. This means that new versions can be distributed without the device needing to be sent in for servicing, connected via a cable or replaced. In English, terms such as ‘over-the-air update’, ‘firmware over-the-air update’, ‘OTA software update’, ‘FOTA update’ and ‘embedded Linux OTA’ are often used.
In practice, this involves creating a secure and controlled process for updating products that are already with customers or in the field. For products in sectors such as medtech, automotive systems, advanced cameras and industrial equipment, OTA can be crucial. It makes it possible to manage security, functionality and regulatory requirements even after launch.
An OTA solution usually consists of three parts:
- A controlled way of packaging firmware and software
- A channel for distribution to the devices
- Mechanisms within the device for receiving, verifying, installing and rolling back the update if necessary
OTA is therefore not a single tool. It is a combination of infrastructure, processes and code within the embedded system.
FOTA update and OTA software update
OTA can be used for various types of updates. An important distinction is whether the update concerns firmware or software running on top of the operating system.
FOTA update
A FOTA update, or firmware over-the-air update, affects the more fundamental parts of the system. These may include, for example, the bootloader, kernel, root filesystem, BSP and other hardware-related components.
This type of update requires particularly careful planning. If anything goes wrong, in the worst-case scenario the system may fail to start up. Robust start-up logic, clear verification and the ability to roll back are therefore essential.
In embedded Linux systems, a firmware update often involves replacing all or part of the system image. For companies that build products based on Linux, embedded Linux OTA therefore becomes an integral part of the system architecture, rather than something that is added as an afterthought.
OTA software update
An OTA software update applies to applications and services running on top of the operating system. These may include, for example, user interfaces, backend services, AI models or product-specific algorithms.
The focus here is often on dependencies, data migration and compatibility between different versions. The risk is usually lower than with firmware updates, but the update still needs to be thoroughly tested.
In many modern products, the OTA system needs to be able to handle both types. Sometimes only applications are updated. Sometimes both firmware and software need to be included in the same release.
Embedded Linux OTA updates in practice
An embedded Linux OTA update needs to be tailored to the product’s hardware, storage capacity, connectivity and security requirements. Unlike standard Linux servers or computers, embedded Linux systems often operate in more constrained environments, where power cuts, poor connectivity or limited memory can affect the update.
The OTA solution needs to be able to handle, for example:
- interrupted download
- verification of update packages
- failed installation
- power cut during installation
- rollback to a previous version
- version control
- Safe start-up after an update
This is particularly important for products with a long lifecycle. A robust embedded Linux OTA update makes it possible to keep the system secure, compatible and up to date without the need for manual intervention on each device.
Security in OTA solutions
The OTA channel provides direct access to the system. Security must therefore be built in from the outset, both in the architecture and in the workflow.
Signing and verification
Firmware images and software packages are cryptographically signed and encrypted. The device then verifies the signature before the update is installed. This reduces the risk of tampered or unauthorised updates being installed on the system. Communication should also be protected using secure protocols, such as TLS. This ensures that data cannot be tampered with during transmission and that the device can verify that the update comes from the correct source.
Common OTA architectures in embedded Linux systems
The structure of the OTA solution depends on the product’s requirements, hardware and risk level. Common architectures include A/B partitions, single partitions with rollback, and package-based updates.
A/B partitions
A/B partitions, also known as dual bank, are a common solution for FOTA updates in embedded Linux.
The system then has two sets of firmware, A and B. The update is written to the inactive partition. Only once the new version has been verified and has booted correctly does the device switch to the new version.
If the start-up fails, the system can automatically revert to the previous version that was working. This makes the solution particularly suitable for products where operational reliability is important.
Single partition with rollback
In simpler systems, a single system partition is sometimes used in conjunction with snapshot or backup mechanisms.
This may be an option when storage space is limited, but the model requires clear procedures for recovery. If something goes wrong, the system must still be able to return to a working state. In Linux systems, this is often achieved using a minimal fallback system – for example, one based on an initramfs – which exists solely to enable the installation of the full system.
The choice between A/B partitions and a single partition is influenced, amongst other things, by available storage, boot time and how critical the product is within its environment.
Package-based updates
In some cases, package-based updates are used. In such cases, applications and services are updated via a package manager, whilst the firmware is updated less frequently.
This can result in smaller and more flexible updates for the application layer. At the same time, it requires effective management of dependencies, versions and compatibility.
For more complex products, package-based application deployment is often combined with image-based firmware updates.
CVE management throughout the product lifecycle
Linux systems are based on FOSS, i.e. free and open-source software. This offers great opportunities, but also means that new vulnerabilities, CVEs, may be published on an ongoing basis for libraries, the Linux kernel and other parts of the system.
A clear process is needed to:
- monitor relevant CVEs
- assess the impact on their own platform
- produce updated images or packages
- distribute the updates via the OTA solution
In this way, OTA becomes a practical tool for actually implementing safety measures in the field, rather than simply identifying risks in a report.
Codiax has extensive experience of embedded Linux and CVE management, and can assist with update strategy, implementation and ongoing maintenance.
Common pitfalls when implementing OTA
Many problems arise when OTA is introduced too late in the development process. The ability to update the system should ideally be incorporated right from the design stage.
-
The system lacks an update strategy
-
Inadequate version control
-
Insufficient testing
When is an OTA solution appropriate?
An OTA solution involves an initial investment, but can deliver significant benefits over the product’s life cycle, not least during the early development phase when systems in a laboratory environment are updated frequently. OTA is particularly relevant when:
- many units are geographically dispersed
- Field updates are costly or difficult to carry out manually
- The requirements for security updates and compliance are high
- the product should have a long lifespan and be capable of incorporating new features over time
- customers or public authorities require the option to carry out updates
For simpler, short-lived or entirely offline products, manual update strategies may sometimes suffice. However, for connected products, OTA is an integral part of the system architecture.
Codiax helps you find the right solution right from the start
An effective OTA solution is not just about choosing the right tools. It needs to be suited to the product’s hardware, security requirements, development workflow and maintenance. Codiax has extensive experience in developing embedded Linux systems for various types of products. Get in touch and we’ll help you get it right from the start!