Dear Atilla Filiz, On Tue, 17 Sep 2013 17:08:11 +0200, Atilla Filiz wrote: > Generic upgrade infrastructure for embedded systems. > > ; Summary: Generic upgrade infrastructure for embedded systems. > > ; Proposer: Atilla Filiz, Arnout Vandecappelle > > == Description == > > Experience as an embedded software contractor shows that most clients > need a means to upgrade their devices in the field. Often these > solutions are ad-hoc, and need to be redone for each project, > although requirements are similar. > > A collection of scripts and permissively licensed source code will help > device manufacturers to rapidly and safely implement a secure, > fail-safe, > atomic upgrade system for their devices. > > The infrastructure will allow an embedded system to have one backup > firmware, and one or two main firmware partitions. When a new firmware > is downloaded and written as a main firmware, the upgrade system makes > sure > the device can boot. If the upgrade fails due to power, file corruption > or > other factors, the system recovers by booting the previous firmware or > a > failsafe firmware to retry upgrading. > > Having this feature will prevent reinventing the wheel for each new > product when it comes to upgrading.
Interesting, thanks. I was also pondering proposing a project around system upgrade for embedded systems, but I was thinking of a different approach. Rather than implementing yet another tool/infrastructure, I wanted to propose a project that consists in writing a document/white-paper that details the different system upgrades solutions that one can use (for example: dual kernel+rootfs partitions, or minimal kernel+initramfs, updating from the bootloader or from Linux, full system update vs. package based updates), with details on their respective advantages/drawbacks, and how to implement them. I believe the problem in this space is not the much the solutions themselves, but rather the lack of a central document to help people make their mind between the different available solutions, and to help them find the relevant existing tools / bits of code. I don't think it's a problem that can be solved in a one-solution-fits-all way, depending on the context (size of flash, type of embedded system, origin of the firmware upgrades, etc.) there will necessarily be different solutions. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com _______________________________________________ Celinux-dev mailing list Celinux-dev@lists.celinuxforum.org https://lists.celinuxforum.org/mailman/listinfo/celinux-dev
