Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

      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