4 ms·
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.
by 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 agoyou 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 agoIt 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.