Autotest infrastructure
Thomas, all,
If we want more features in the autobuilders, it may be worthwhile to reuse
existing infrastructure. At ELC-E, I attended a talk about autotest ( http://github.com/autotest ) and I wrote a small report about that talk ( http://wp.me/pNMCz-2t ). It sounds like it could be something that can be used for the autobuilders, though of course it won't work out of the box for us...
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout dot vandecappelle at essensium dot com Senior Embedded Software Architect . . +32-16-286540 . +32-478-010353 (mobile) Essensium, Mind division . . . . . . . . . . . . . . . . . http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium . . . . . . . . BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43
[Buildroot] Autotest infrastructure (a bit of off-topic: git repo URL)
Hi Arnout,
I attended the other day to your talk on "upgrading without bricking" (congrats for that, i learned a lot) and you mentioned a repo where you have started collecting some tools/scripts to do the job.
Could you remind me that repo URL? I shouldn't have trust i would remember it some days after.
Sorry the rest for the thread hijacking.
Signature · 3 lines
Javier Viguera Software Engineer Digi International? Spain S.A.U.
[Buildroot] Autotest infrastructure (a bit of off-topic: git repo URL)
Pretty off-topic indeed... but I don't mind :-)
Quoted 4 lines · Javier Viguera
I attended the other day to your talk on "upgrading without bricking" (congrats for that, i learned a lot) and you mentioned a repo where you have started collecting some
tools/scriptsto do the job.Could you remind me that repo URL? I shouldn't have trust i would remember it some days after.
But as I mentioned, it's still pretty empty... I expect to really start
committing something in a week or two.
I've also created a mailing list, but it's on google groups which sucks
somewhat: https://groups.google.com/group/gupies/subscribe
If you have a better idea, I'd welcome that.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
[Buildroot] Autotest infrastructure (a bit of off-topic: git repo URL)
Hello,
Quoted 8 lines · Arnout Vandecappelle
Pretty off-topic indeed... but I don't mind :-)
Quoted 4 lines · Javier Viguera
I attended the other day to your talk on "upgrading without bricking" (congrats for that, i learned a lot) and you mentioned a repo where you have started collecting some
tools/scriptsto do the job.Could you remind me that repo URL? I shouldn't have trust i would remember it some days after.
Quoted 8 lines
But as I mentioned, it's still pretty empty... I expect to really start
committing something in a week or two.I've also created a mailing list, but it's on google groups which sucks
somewhat: https://groups.google.com/group/gupies/subscribe
If you have a better idea, I'd welcome that.
On a related topic (firmware upgrade), I have:
https://gitorious.org/embedded-linux-firmware-upgrade-tool/embedded-linux-firmware-upgrade-tool
It has a:
* A host utility to prepare firmware images composed of multiple parts (usually a kernel image + root filesystem image, but there could be more)
* A target utility that can run either on the command line or as a CGI script. This utility does the firmware upgrade itself by fiddling with the U-Boot environment.
The tool assumes that the flash has two partitions for each component been upgraded (one active partition, one to upgrade).
The documentation at
https://gitorious.org/embedded-linux-firmware-upgrade-tool/embedded-linux-firmware-upgrade-tool/blobs/master/fwupgrade-doc.txt
has a few details.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
[Buildroot] Autotest infrastructure (a bit of off-topic: git repo URL)
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> 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 ;)
Signature · 1 line
Bye, Peter Korsgaard
[Buildroot] Autotest infrastructure (a bit of off-topic: git repo URL)
Quoted 7 lines · Peter Korsgaard
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)
Agreed. I've written this stuff for only one project at the moment, so it hasn't been made more generic than it was needed at the time.
Quoted 6 lines
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.
I also did an .ipk wrapping of firmware upgrade images for some other project, for the same reason (post-install script triggering the upgrade).
Quoted 2 lines
Maybe we should do some more firmware upgrade talks at an upcoming conference ;)
Eeh, why not :-)
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com