ourtechnology-2.jpg

Software Update on Embedded Linux Systems

Embedded Linux systems consist of code from many open-source projects as well as the vendor's 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.

In most cases, it is not recommended to update the bootloader since is very risky and it can break your device!

There are a few different strategies to update the software on embedded devices.


Package Manager Update

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

In some cases 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 can 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 your 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 releases running on many systems which 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 start the active image.

The active image is responsible for updating 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 should be started at boot time, for example, a dedicated file can be saved at a user data partition, this file should store the name of the active copy.

A double copy image update requires more storage to save two full images, but this is the most reliable and robust strategy to perform 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 and starting the recovery image. Then the recovery image can update the main image safely.

In case of failure, the main image will be corrupted and will not able to fully function. At boot time, the bootloader should validate the main image and if the main image 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.

We at EMBEDOX have vast experience with software updated strategies for embedded devices and we here to assist you to integrate the best solution for your product.


Copyright EMBEDOX  2020  |  All Rights Reserved 

LOGOONLY.png