top of page

Updating an Embedded Linux Systems

Embedded Linux systems consist of code from many open-source projects and proprietary software. By nature, software always keeps evolving with new features, fixes, and critical security patches.



Embedded Linux systems are everywhere, indoors and outdoors, and in many cases has limited physical access to it. This makes software update for embedded systems so critical.


The main updatable elements at almost any embedded Linux device are:

• Bootloader.

• Kernel image and Device Tree files.

• Root file system.



Package Manager Update

Package managers (dpkg, rpm, etc...) are commonly used in desktop environments.

When the embedded device runs a desktop distribution such as Debian, a package manager is built-in and can be used to update the vendor’s software as well as the packages of the Linux distribution.

In general, desktop Linux distributions and their package managers are not designed for embedded devices, this might cause many problems down the road. The main concern is that desktop package managers do not perform atomic updates required for an embedded system. A power-loss in an update sequence can break the device without any option to revive it other than sending it back to the factory.

Another disadvantage of using package managers is that it creates many combinations of software combinations running on many systems, this is hard to manage and validate.

Package managers are not reliable enough to accomplish the critical software update requirement on embedded devices and it is recommended to avoid using them.


Double Copy Image Update

The double image copy strategy saves two copies of the whole software (Kernel, DTB and ROMDISK), an active image and a standby image. At boot time, the bootloader will load the active image from storage and runs it. The active image must be able to update the standby image copy, this way the system can be safely upgraded with a guarantee that there is always a valid copy even if the software update is interrupted or a power cut occurs.

This strategy requires a mechanism to identify which copy is active and should be started at boot time, for example, a dedicated file can be saved at a user data partition, this file should point to the active copy.

The double copy image update strategy requires more storage to save two full images, yet this is a very reliable and robust strategy for software updates on any embedded system.


Single Copy Image Update

In some cases when storage size is limited and cannot store two full images, a single copy image update can be used.

With this strategy, a small recovery image with minimal software is responsible to update the single full image. The recovery image is preinstalled by the factory and in general should not be upgraded. The update process starts by rebooting the device into recovery mode. The bootloader will load the recovery image and start the recovery process.

In case of failure, the main image will be corrupted and will not able to fully function. The bootloader should validate the main image at every boot and if it is corrupted the bootloader should start the recovery image again.


Conclusion

Releasing a new embedded system to the market requires a reliable and robust software update strategy to avoid broken devices in the field. Software update consideration must be taken right from the early stage of the product design.

bottom of page