public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] uboot redundancy.
Date: Wed, 21 Jul 2010 21:37:45 +0200	[thread overview]
Message-ID: <20100721193745.CD3AA153780@gemini.denx.de> (raw)
In-Reply-To: <AANLkTilwlzwHniDQAl1VDQascJzJkzmBnoSwMyw2BjGF@mail.gmail.com>

Dear Sagar Heroorkar,

In message <AANLkTilwlzwHniDQAl1VDQascJzJkzmBnoSwMyw2BjGF@mail.gmail.com> you wrote:
>
> Is there any other way to make the u-boot redundant  other than what i have
> sent in the email earliar.

I still fail to understand where your requirements are coming from,
resp. which exact goal you are trying to achieve.

If it's all about reliability, you should consider never updating /
replacing U-Boot at all, and then a single copy is all you need in
most cases.

If you have really paranoid reliability requirements, you cannot do
without adequate support from the hardware design. Tyically such
systems come with two separate, identical banks of NOR flash that are
attached through some switch logic to two different chip select
signals. In addition, they need a hardware watchdog (I mean a real
one, that starts automatically and that cannot be stopped by
software), and logic that allows to detect the a watchdog reset.


Assume in "normal" position the switch connects flash bank 1 as boot
device (say, chip select CS0), and flash bank 2 to another device
(say, chip select 1).

You would then install the same copy of U-Boot into both flash banks 1
and 2.

Upon power-on, the watchdog starts running, and the system will boot
from the image in flash bank 1. If it's working fine, it will trigger
the watchdog, and everything is fine.

In case of errors (image corrupt, flash broken, ...) the watchdog will
time out and cause a watchdog reset, which gets detected by the board
logic. After a predetermined number of such watchdog resets (N=1 is of
course also an option) the board logic will flip the switch, so the
next reset will see flach bank 2 connected to CS0 and thus being the
boot device, i. e. the alternative image will be booted.

This is simple, reliable, and doe snot require any special measures in
the software, which is completly agnostic to such toggeling.

You may even locate several copies of the environment in both flash
banks, so that you have a fully redundant system.

Whether the switch can also be controlled by software or not etc. are
details that allow for fine tuning, but I think you get the idea.

But you need a certain level of hardware support - all attempts of
nested first and second and third stage loaders and toggeling in
software is error prone, because you can be pretty sure that the
first problem that will bite you once the systems have been shipped
to customers all over the world is not in one of the redundant
images, but in the "golden" master copy...


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You got to learn three things. What's  real,  what's  not  real,  and
what's the difference."           - Terry Pratchett, _Witches Abroad_

  reply	other threads:[~2010-07-21 19:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-09 14:03 [U-Boot] uboot redundancy Sagar Heroorkar
2010-07-10 11:11 ` Graeme Russ
2010-07-16 19:12   ` Sagar Heroorkar
2010-07-18 15:55     ` Sagar Heroorkar
2010-07-19 13:26       ` Sagar Heroorkar
2010-07-19 20:36         ` Joakim Tjernlund
2010-07-21 15:21           ` Sagar Heroorkar
2010-07-21 16:27             ` Joakim Tjernlund
2010-07-21 17:09               ` Sagar Heroorkar
2010-07-21 17:21                 ` Joakim Tjernlund
2010-07-21 18:25             ` Wolfgang Denk
2010-07-21 18:45               ` Sagar Heroorkar
2010-07-21 19:37                 ` Wolfgang Denk [this message]
2010-07-21 19:59                   ` Sagar Heroorkar

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=20100721193745.CD3AA153780@gemini.denx.de \
    --to=wd@denx.de \
    --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