From: David Lynch Jr. <dhlii@dlasys.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] Updating a system
Date: Tue, 28 Dec 2010 13:45:22 -0500 [thread overview]
Message-ID: <1293561922.3652.1286.camel@t-dhlii> (raw)
In-Reply-To: <4D19A86B.9050300@free.fr>
Sorry;
Your sugestions are appreciated. I had not yet looked at some of the
u-boot capabilities you described.
But I am trying to find out if there is something approaching a
standard scheme for handling this - rather than going off and doing
something myself that is non-standard.
I have a fairly good grasp of what needs to and can be done if there is
no common solution already.
On Tue, 2010-12-28 at 10:05 +0100, Albert ARIBAUD wrote:
> Hi David,
>
> Le 28/12/2010 08:54, David Lynch Jr. a ?crit :
> > I need to setup a system so that it can boot a user web updateable
> > kernel/rootfs or a failsafe version. The process has to be manageable by
> > completely non-technical users and work from a single flash media - no
> > plugging in an SD card or USB stick to recover.
> > Before I re-invent the wheel is there an existing scheme to manage
> > multiple boot choices with an automatic fallback to a failsafe ?
>
> Depends what you mean by "fail-safe".
>
> There is no way for a bootloader to detect "failures" in the OS and set
> of applications that it helps launching, at least no general,
> already-defined and 100%... fail-safe... way. You'll have to devise your
> own scheme for the bootloader to find out it should start the backup
> system instead of the main one. What U-boot can do for you here is
> provide tools to build this method.
>
> One tool is support for OS and root Flash images which can be checked
> for integrity (e.g. images made with make uImage). When told to run such
> images, u-boot will check their integrity and run them only if
> unaltered; otherwise it'll go on executing whatever instruction follows.
> This allows you to at least not run a main system if corrupt; it even
> allows you to not run a corrput backup system, however what you would do
> next is you own lookout.
>
> Another tool is the ability to store and retrieve a flag value which
> will persist across reboots and resets, both in u-boot and in linux, for
> instance you'd use some bytes of eeprom or a scratch register on a
> backed-up I2C RTC (mind the total power losses though!)
>
> As a (very bad and incomplete) example, initially the flag value would
> be set to "PASS" and the main system would use a watchdog scheme which,
> in case of "failures", would set the flag value to "FAIL" and reset.
> Then in u-boot, commands executed from boootcmd would check the flag
> value and boot either the main (if PASS) or backup (if FAIL) system.
>
> But as I said, these are only generic tools which can help making a
> system fail-safe.
>
> Amicalement,
prev parent reply other threads:[~2010-12-28 18:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-28 7:54 [U-Boot] Updating a system David Lynch Jr.
2010-12-28 9:05 ` Albert ARIBAUD
2010-12-28 18:45 ` David Lynch Jr. [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=1293561922.3652.1286.camel@t-dhlii \
--to=dhlii@dlasys.net \
--cc=u-boot@lists.denx.de \
/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