From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Autotest infrastructure (a bit of off-topic: git repo URL)
Date: Fri, 9 Nov 2012 14:18:15 +0100 [thread overview]
Message-ID: <20121109141815.1630955a@skate> (raw)
In-Reply-To: <87bof76kkn.fsf@dell.be.48ers.dk>
On Fri, 09 Nov 2012 13:13:12 +0100, Peter Korsgaard wrote:
> 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.
> 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).
> Maybe we should do some more firmware upgrade talks at an upcoming
> conference ;)
Eeh, why not :-)
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
prev parent reply other threads:[~2012-11-09 13:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-08 15:00 [Buildroot] Autotest infrastructure Arnout Vandecappelle
2012-11-08 16:21 ` [Buildroot] Autotest infrastructure (a bit of off-topic: git repo URL) Javier Viguera
2012-11-08 21:21 ` Arnout Vandecappelle
2012-11-09 10:47 ` Thomas Petazzoni
2012-11-09 12:13 ` Peter Korsgaard
2012-11-09 13:18 ` Thomas Petazzoni [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121109141815.1630955a@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox