Software is steadily increasing its complexity and this raises the size of a whole Update. SWUpdate allows incremental updates based on filesystem, and single file updates are possible. A good update concept will still allow lightweight updates without losing on reliability, but more care must be taken to handle all use cases. A well known way for reliable updates is to replace the whole filesystem as a single binary, but of course the size can be in term of several hundreds of megabytes or even gigabytes.

But what about to update just the part of the giant blob that was changed between two updates ? This is more complex than replacing a single file, but it guarantees the maximum reliability and the installed software will be exactly the same as the one built on your host. This is more important in case you sign the software, and in all case secure boot is required on your device.

The “Delta Handler” in SWUpdate addresses these topics. Thanks to the “rolling hash” theory, SWUpdate is able to compute on the device itself which part of the binary blobs are different and to download only the changed parts, strongly reducing the size of the downloaded data. And this maintaining all features present in SWUpdate. Do not trust to fairy tale: not any frog will turn into a prince !

And of course: still everything Open Source !

Features:

The file sw-description is the central place to configure a release and to provide how a new sofware must be installed. Apart very simple cases, an update consists oft of several parts, some of them  are not always active, and a release can be installed on devices with different hardware revisions. This leads to have several sections inside sw-description. It is possible to factorize some parts of them using SWUpdate’s links. A link is a reference for one of the major sections (images, files, partitions, scripts and bootenv) and the whole section can be referenced by a link.  Let’s start having a device in field, but several hardware revisions are now running and the software is not exactly the same for all of them. For example, older hardware revisions are not supported by newer Linux kernels, or new application’s features are just added to later releases due to hardware limitations. SWUpdate has always supported this case, and sw-description is omething like the following:

    software =
     {
             version = "0.1.0";

             myboard = {
                 stable = {

                     hardware-compatibility: ["1.0", "1.2", "2.0", "3.0", "3.1"];
                     rev-1.0: {
                             images: (
                                     ...
                             );
                             scripts: (
                                     ...
                             );
                     }
                     rev-1.2: {
                             hardware-compatibility: ["1.2"];
                             images: (
                                     ...
                             );
                             scripts: (
                                     ...
                             );
                     }
                     rev-2.0: {
                             hardware-compatibility: ["2.0"];
                             images: (
                                     ...
                             );
                             scripts: (
                                ...
                             );
                     }

The device should recognize which hardware revision is running, and SWUpdate is started via “selection” to parse just the relevant part of the file. A lot of entries must be duplicated, for example if most releases share the same kernel or rootfs. Using links, the example above can be written as:

     software =
     {
             version = "0.1.0";

             myboard = {
                 stable = {

                     hardware-compatibility: ["1.0", "1.2", "2.0", "1.3, "3.0", "3.1"];
                     rev-1x: {
                             images: (
                                ...
                             );
                             scripts: (
                                 ...
                             );
                     }
                     rev1.0 = {
                             ref = "#./rev-1x";
                     }
                     rev1.2 = {
                             ref = "#./rev-1x";
                     }
                     rev1.3 = {
                             ref = "#./rev-1x";
                     }
                     rev-2x: {
                             images: (
                                  ...
                             );
                             scripts: (
                                  ...
                             );
                     }
                     rev2.0 = {
                             ref = "#./rev-2x";
                     }

This factorizes big blocks, that is some blocks are common between the revisions.

Links has the following syntax:

 

Anyway, it was not possible until now to split one of the sections to share a common block and some specific extensions. For example, if the application consists of more entries (image and files), but depending on hardware revision or on the mode the device is started there are some entries that differ.

 

somecommon: {
      images: (
              {
                  .............
              },
              {
                  .......
              }
      )
}
somespecific: {
      images: (
              {
                  .............
              },
              {
                  .......
              }
      )

}      
selection : {
       images: (
                {
                    ref = "#./../../somecommon/images";
                },
                {
                    ref = "#./../../somespecific/images";
                },
                {
                    filename = "somefilename";
                    device = "/dev/somedevice";
                    type = "raw";
                }
            )

Links are now available in whole sw-description and this simplify the readability and maintainability. This feature is now commited.

Proud to announce a new release for SWUpdate with exciting new features !

Siemens exposed how to combine secure boot and SWUpdate in this interesting talk (https://static.sched.com/hosted_files/ossna2020/17/Secure-OTA-Updates_elc-na-2020.pdf).