Difference between revisions of "Generic upgrade infrastructure for embedded systems"

From eLinux.org
Jump to: navigation, search
(add page)
 
(Add not selected status info)
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
Generic upgrade infrastructure for embedded systems.
 
 
 
; Summary: Generic upgrade infrastructure for embedded systems.
 
; Summary: Generic upgrade infrastructure for embedded systems.
 
 
; Proposer: Atilla Filiz, Arnout Vandecappelle
 
; Proposer: Atilla Filiz, Arnout Vandecappelle
 +
; Status: Not selected in 2013 to be sponsored by the CE Workgroup
  
 
== Description ==
 
== Description ==
Line 19: Line 17:
 
The infrastructure will allow an embedded system to have one backup
 
The infrastructure will allow an embedded system to have one backup
 
firmware, and one or two main firmware partitions. When a new firmware
 
firmware, and one or two main firmware partitions. When a new firmware
is downloaded and written as a main firmware, the upgrade system makes
+
is downloaded and written as a main firmware, the upgrade system makes sure
sure
+
the device can boot. If the upgrade fails due to power, file corruption or
the device can boot. If the upgrade fails due to power, file corruption
+
other factors, the system recovers by booting the previous firmware or a
or
 
other factors, the system recovers by booting the previous firmware or
 
a
 
 
failsafe firmware to retry upgrading.
 
failsafe firmware to retry upgrading.
  
Line 37: Line 32:
 
* CGI based project repository:
 
* CGI based project repository:
 
https://gitorious.org/embedded-linux-firmware-upgrade-tool
 
https://gitorious.org/embedded-linux-firmware-upgrade-tool
 +
 +
* Linupdate + barebox
 +
** Jean-Christophe PLAGNIOL-VILLARD says that he and others are currently working on a similar project with a full c application under GPLv2 called linupdate + barebox.  It is intended to will support secure boot platforms such as STB
  
 
== Scope ==
 
== Scope ==
Line 53: Line 51:
  
 
== Comments ==
 
== Comments ==
 +
Thomas Petazzoni, of Free Electrons, writes:
 +
 +
<pre>
 +
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.
 +
</pre>
  
 +
=== Reasons for CEWG not selecting this project ===
  
 +
Most AG members thought that companies already had existing upgrade
 +
solutions (e.g. Android already has well-established upgrade mechanisms)
 +
Also, most members didn't think a one-size-fits-all approach would be
 +
useful. The proposal seems to be based on a particular file system
 +
layout, and doesn't handle special use cases like read-only partitions.
  
 
[[Category:Project proposals 2013]]
 
[[Category:Project proposals 2013]]

Latest revision as of 13:16, 30 December 2013

Summary
Generic upgrade infrastructure for embedded systems.
Proposer
Atilla Filiz, Arnout Vandecappelle
Status
Not selected in 2013 to be sponsored by the CE Workgroup

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

  • Linupdate + barebox
    • Jean-Christophe PLAGNIOL-VILLARD says that he and others are currently working on a similar project with a full c application under GPLv2 called linupdate + barebox. It is intended to will support secure boot platforms such as STB

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

Thomas Petazzoni, of Free Electrons, writes:

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.

Reasons for CEWG not selecting this project

Most AG members thought that companies already had existing upgrade solutions (e.g. Android already has well-established upgrade mechanisms) Also, most members didn't think a one-size-fits-all approach would be useful. The proposal seems to be based on a particular file system layout, and doesn't handle special use cases like read-only partitions.