4 ms·

> (e.g. OTA update and the like). What's linux FOTA like? It's dirt simple for most M-class devices, and most use MCUboot with two banks. I've not used it on L

> (e.g. OTA update and the like). What's linux FOTA like? It's dirt simple for most M-class devices, and most use MCUboot with two banks. I've not used it on Linux, but I can't imaging updating the kernal/distro OTA since it is so big, but I'm guessing just the application gets updated???

Rochus 4y ago
Have a look at e.g. https://sbabic.github.io/swupdate https://sbabic.github.io/swupdate, which is also available in Buildroot; kernels and rootfs can be configured to be rather small.
saidinesh5 4y ago
rauc, swupdate, even docker/balena are all tools that handle the FOTA problem really well. We used rauc and swupdate in my last job as they came with yocto/buildroot (our build system for generating custom distro images). It is always these 3 basic partitions + a boot script to check if the boot is successful and if it isn't roll back the update or boot from a recovery partition: root A (usually around 500GB), root B (500GB), common application data (usually mounted as /home/app and is around 500 MB). The distro + application usually takes up about 50-100MB. We usually left at least 10X that free space to not worry about the future..
- FatActor 4y ago
  Are we talking about the same thing? An OTA firmware update of 100MB seems about 100X what I'm used to in the Cortex-M space.
  - froh 4y ago
    you should use a differential binary updater. SUSE introduced differential rpm updates quite a while back and others have it too these days. the really tricky part is making the update robust against power outage or, much more probable, manual power off "ThE UpDaTe TaKeS So LonG"
  - saidinesh5 4y ago
    It depends on what you are trying to build/update and how you are trying to deliver the OTA. Typically the rootfs (kernel + libs + applications) of a similar app (think lvgl + some kind of gui) of a linux system is around 5-10MB higher than using a microcontroller (kernel - 5-6MB, uboot, busybox, libc etc.. another 1-2MB). But nothing is preventing you from static linking everything and just running your single app as init on top of the kernel. Except licensing. (Statically linked qt = you need to be open source or have a commercial license). For typical wireless router kind of use case (read: Openwrt), the whole firmware is around 2-4MB squashfs, and used to fit in a 4MB flash chip. (These days they recommend 16MB or higher iirc..) For automotive infotainment systems which have to play a dozen audio/video formats, have to show various engine information, have to have smooth animated menu and high quality icons/images, the firmware was around 50-60MB. We typically didn't bother with delta updates because these updates only happen when connected to wifi or in some cases via. a USB drive with firmware in it. So I can't give you the exact numbers on how big the delta updates usually can be. In android world, delta updates let us update a 1.4GB system partition with an OTA blob of 20-30MB I think. The economics are also different. It is cheaper to buy a 4GB emmc instead of 2GB emmc which you need.

Rochus 4y ago

Have a look at e.g. https://sbabic.github.io/swupdate https://sbabic.github.io/swupdate, which is also available in Buildroot; kernels and rootfs can be configured to be rather small.

saidinesh5 4y ago

rauc, swupdate, even docker/balena are all tools that handle the FOTA problem really well. We used rauc and swupdate in my last job as they came with yocto/buildroot (our build system for generating custom distro images). It is always these 3 basic partitions + a boot script to check if the boot is successful and if it isn't roll back the update or boot from a recovery partition: root A (usually around 500GB), root B (500GB), common application data (usually mounted as /home/app and is around 500 MB). The distro + application usually takes up about 50-100MB. We usually left at least 10X that free space to not worry about the future..

FatActor 4y ago
Are we talking about the same thing? An OTA firmware update of 100MB seems about 100X what I'm used to in the Cortex-M space.
- froh 4y ago
  you should use a differential binary updater. SUSE introduced differential rpm updates quite a while back and others have it too these days. the really tricky part is making the update robust against power outage or, much more probable, manual power off "ThE UpDaTe TaKeS So LonG"
- saidinesh5 4y ago
  It depends on what you are trying to build/update and how you are trying to deliver the OTA. Typically the rootfs (kernel + libs + applications) of a similar app (think lvgl + some kind of gui) of a linux system is around 5-10MB higher than using a microcontroller (kernel - 5-6MB, uboot, busybox, libc etc.. another 1-2MB). But nothing is preventing you from static linking everything and just running your single app as init on top of the kernel. Except licensing. (Statically linked qt = you need to be open source or have a commercial license). For typical wireless router kind of use case (read: Openwrt), the whole firmware is around 2-4MB squashfs, and used to fit in a 4MB flash chip. (These days they recommend 16MB or higher iirc..) For automotive infotainment systems which have to play a dozen audio/video formats, have to show various engine information, have to have smooth animated menu and high quality icons/images, the firmware was around 50-60MB. We typically didn't bother with delta updates because these updates only happen when connected to wifi or in some cases via. a USB drive with firmware in it. So I can't give you the exact numbers on how big the delta updates usually can be. In android world, delta updates let us update a 1.4GB system partition with an OTA blob of 20-30MB I think. The economics are also different. It is cheaper to buy a 4GB emmc instead of 2GB emmc which you need.