Article by : Mohamed BELOUARGA

Adding a feature, fixing a bug, or correcting a security breach are all part of the life cycle of software, a library, or a firmware. However, for architects and developers, performing these tasks still comes with its technical drawbacks and its load of possible unwanted outcomes (more bugs, rollbacks etc.)

Until now, the industry, and particularly the embedded systems industry, continues to send their technicians on-site to perform updates on their products. These procedures are time-consuming, require heavy-duty logistics, are expensive and are therefore often overlooked, causing a great deal of contempt for clients and users.   

Remote updates, also called Over The Air (OTA) updates, are more suitable to the future needs of most industrials, manufacturers and their future products.    

In embedded Linux, OTA updates are available

This article discusses remote updates for embedded Linux systems.

OTA updates allow software modifications to be made to a system without making physical contact with the system. These updates can be performed using several open-source solutions, but their implementation is not always straightforward.

As manufacturers look at update options, the first solution they consider is to update by packet. This solution is the least suitable for embedded systems for several reasons:

• If the update doesn’t go as planned, you cannot perform a rollback operation.
• Each component must be managed according to its dependencies
• Version conflicts: In a desktop system, we can afford to have two versions of the same library, but that is not the case in a memory-constrained system.
• The validation of an update is a very challenging task. More so, that the more updates are made, the more complicated and expensive updating becomes. It is necessary to plan the passage from V1 to V2, from V2 to V3, but also from V1 to V3 etc.

👉 Examples include Mender, Ostree, RAUC…

Nevertheless, there are other solutions that can avoid all these drawbacks, such as SWUpdate, Mender, OsTree, RAUC, etc.

Each solution has its own way of dealing with updates, we will only discuss Stefano Babic’s SWUpdate in this article.

#Swupdate is more of a framework than other end-to-end solutions

Unlike the end-to-end solution Mender, which comes with its requirements, its constraints and limitations, SWUpdate can create a custom version of Mender, of adding or removing features. Creating an update solution that will perfectly match the client’s needs.

The disadvantage is that the update file can be considerable, which will raise network prices. However, this issue can also be avoided by using compressed rootfs when updating, or by using delta update. We will develop this later on.

Determining an update strategy

Before implementing an update solution, an update strategy needs to be defined. This strategy is abiding to a product’s lifespan and is very difficult to modify.

Some examples of updates strategy include: 

Double copy mode

• Double copy mode consists of duplicating elements which implies having: two rootfs, two kernels, two DT (device tree), two bootloader environments etc.

The update procedure goes as follows. While the product is working with rootfs1 and kernel1, swupdate updates rootfs2 or kernel2 and then reboots on rootfs2 and kernel2.

If the update is successful, the product remains as is. But if that is not the case (rootfs2 is corrupted or kernel2 panics) the u-boot executes a rollback operation back to rootfs1 and kernel1.

Single rescue strategy

• Single rescue Strategy uses less space than double copy mode by working with a rescue rootfs and kernel.

The rescue kernel is limited to the necessary drivers, and the rescue rootfs is limited to the necessary libraries and swupdate. The other rootfs and kernel are the production firmware.

When an update is ready, the image reboots on the rescue image and from the rescue image the rootfs and kernel are updated. Once updated, the image reboots on the production kernel and rootfs.

In any case, if the update fails, the rescue kernel and rootfs serve as backups.

As discussed before, SWUpdate being a framework, with it anything is possible. Its only limitations are the imagination of its users.

Bootloader interface

SWUpdate must work with the bootloader, meaning that when the device or product needs to change the rootfs, the bootloader will change the command line that the kernel receives. Making this conjunction vital to the update system.

Now that we saw update strategies, and bootloader interface, let’s see the different tools that SWUpdate provides to send an actual update. 

Mangoose mode

The interface could look like this:

SWUpdate in Mangoose mode includes an embedded web server that allows us to send the update file through a web interface.

Once SWUpdate is configured correctly, this interface allows the user to send an update file (.swu) to the target. The interface also shows insights such as update status and logs.

Surricata mode

SWUpdate in Surricata mode asks a remote server for updates, pulls them, and installs them, then reports the results.

Mostly used for large amounts of cards, Surricata mode centralizes and monitors the controls of the update system. From the server side, we can use Eclipse hawkBit to monitor the status of a park of cards.

Currently, only Eclipse hawkBit is supported but, thanks to the open-source nature of these solutions, a customized server can be added and serve as a work-around.

Making SWupdate an integral part of your business processes

SWUpdate acting like a framework provides users with many more features and tools. For exemple, in the situation where a user would like to input a .swu update using another application. The file can be sent to the SWUpdate deamon using the tool SWUpdate-client. Furthermore, with SWUpdate-progress, that same application can retrieve the update progress data, making external monitoring possible.

There are many other features available, and all are very well documented. 

Handlers

If you have a specific need, such as how to install a certain update or update a microcontroller linked to the target, SWUpdate allows you to add your own handler.

Signed Updates

Security remains important for SWUpdate. The capacity to use HTTPS with the surricata mode already showcases this but we also can sign .swu files. SWUpdate will then be in capacity to verify that the received updates come from an authorized source (private key/public key).  

Solving the issue of size and bandwidth

👉 Compressed updates

The most expensive part of an update procedure is in most cases the cost of bandwidth. Updating a rootfs for large amounts of targets also requires large amounts of bandwidth. To solve and reduce costs, SWUpdate permits you to use compressed rootfs.

👉 Delta updates

The price of bandwidth remains high even after compression, which is why SWUpdate proposes another solution based on deltas.

This solution will be discussed in a future article.

In conclusion, SWUpdate is a massive framework able to solve many specific situations. When well configured, SWUpdate can reduce your update costs while making updating Linux based systems much simpler for all.

If you want to find out more about SWUpdate and how it can help your company, you can contact : 

Fabien LAHOUDERE, T&S Linux Practice Leader
Martin COUSSERANS, Business manager

Contact us