Please note that User Registration has been temporarily disabled due to a recent increase in automated registrations. If anyone needs an account, please request one here: RequestAccount. Thanks for your patience!--Wmat (talk)
Please email User:Wmat if you experience any issues with the Request Account form.

Generic upgrade infrastructure for embedded systems

From eLinux.org
Revision as of 20:41, 17 September 2013 by Tim Bird (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.

Related work

  • FOSDEM/ELC-E Presentation:

http://mind.be/content/Presentation_Upgrade-without-Bricking.pdf

  • Generic project repository with detailed documentation:

https://gitorious.org/gupies

  • CGI based project repository:

https://gitorious.org/embedded-linux-firmware-upgrade-tool

Scope

A basic system can be implemented and unit tested in six person-weeks. This includes support for a single bootloader (U-Boot), for overwriting an MTD partition and a UBI volume. This also includes a wire format for the upgrade image and documentation for the platform-specific part, needed per project. Additional partition types (e.g. mbr) or bootloaders (e.g. barebox) require additional effort.

Contractor Candidates

Arnout Vandecappelle (Essensium/Mind)

Comments