[Buildroot] Autotest infrastructure (a bit of off-topic: git repo URL)

[Peter Korsgaard <jacmet@uclibc.org>]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> On a related topic (firmware upgrade), I have:
 Thomas> https://gitorious.org/embedded-linux-firmware-upgrade-tool/embedded-linux-firmware-upgrade-tool

 Thomas> It has a:

 Thomas>  * A host utility to prepare firmware images composed of multiple parts
 Thomas>    (usually a kernel image + root filesystem image, but there could be
 Thomas>    more)

 Thomas>  * A target utility that can run either on the command line or as a CGI
 Thomas>    script. This utility does the firmware upgrade itself by fiddling
 Thomas>    with the U-Boot environment.

 Thomas> The tool assumes that the flash has two partitions for each component
 Thomas> been upgraded (one active partition, one to upgrade).

 Thomas> The documentation at
 Thomas> https://gitorious.org/embedded-linux-firmware-upgrade-tool/embedded-linux-firmware-upgrade-tool/blobs/master/fwupgrade-doc.txt
 Thomas> has a few details.

This is getting pretty offtopic, but from a quick look at it, it seems
nice, but:

- hardcoded for nand (E.G. uses nandwrite)
- non-atomic (E.G. uboot environment is handled per-part, so you can end
  up with a halfway upgraded system if something goes wrong)
- fairly inflexible (hardcoded upgrade procedure, hw id handling, cgi)

I've solved it in the past by wrapping firmware upgrades in .deb files,
and used the depends on / conflicts stuff for hw id/version handling,
and the pre/post scripts to define the upgrade handling in the upgrade
itself. To ensure an atomic change between current and upgraded system I
key off the choice of kernel/rootfs from a single u-boot variable
(typically called boot=high|low) which is only changed at the very end.

Maybe we should do some more firmware upgrade talks at an upcoming
conference ;)

-- 
Bye, Peter Korsgaard