Where to store downloaded update packages?

We have a own server for software rollouts, due this we don’t want to use the airvantage stuff. My question is, where is the best way to store the downloaded update packages before installing them on the target. Is their a specific partition which is reserved for the downloads ? Our update sequence should follow the following sequence.

  1. Download update artifact
  2. Store update package (Where ?)
  3. check checksum
  4. Run My-Application without any change. The My-Application should only be updated on startup.
  5. On system startup a installer application should check the signature and install the update package.
  6. Start My-Application

We want to us this sequence for complete firmware updates and also for application updates.

Where can we store the update packages without using the space which is reserved for the applications ?
I there a specific partition that is reserved for downloaded update packages ?
How can we access the partition ?
What is the best way to realize our update sequence ?

Hi, @ABCBurns,

There is a “FOTA partition” reserved for this purpose. It is used by the AirVantage FOTA update, but you can use it directly if you want to implement your own FOTA system. It is accessed via the Firmware Update API or indirectly via the higher-level Update API.

You can pass a file descriptor to le_fwupdate_Download() or le_update_Start(), which will read the update image from that fd and write it into the FOTA partition. You trigger the installation of the update by calling le_fwupdate_Install() or le_update_Install().

The benefit of using a file descriptor is that you can stream your download directly to the update system without having to save it anywhere else beforehand (thereby reducing the amount of flash space you need). The update systems include integrity checks, so you don’t need to do your own checksum.

If you want to do your own digital signing, with a check just before you install the update, you may wish to still save your own signed copy to flash. Depending on your non-volatile storage requirements (like how big your application is), you may be able to find the space you need under /mnt/flash. Be sure not to mess with the directories that already exist under there, but you can add your own directory under /mnt/flash, if you need to.

The main benefit of the le_fwupdate API over the le_update API is that le_fwupdate supports resuming interrupted update downloads part way through (See le_fwupdate_GetResumePosition()). But, to use this mechanism, you’ll need to generate .spk or .cwe files for your updates, because this API only accepts those types of files. This can be done using the systoimg and swicwe tools (at build time). But, if you’re saving your own copy to flash and doing a signature check at install time, then you won’t need the resume feature (you can implement your own).

The advantage of using the le_update API is that it accepts .update files as well as .spk and .cwe files and, when using .update files it can roll-back to a previous version of software if the system fails to boot up properly after an update. Rollback is not supported for updates to the root filesystem, linux kernel, bootloaders, or modem firmware, though. Only Legato “systems” including the Legato framework, apps, and loadable kernel modules can be rolled-back. See here for more information.

NOTE: When reading the API docs, keep in mind that (as of today) the WP modules are all “single image” systems. The “dual image” configuration is only supported on some of the AR (automotive) modules.

I hope this helps!


1 Like

Thank you very much. It helps a lot.

1 Like