[U-Boot] uboot redundancy.

[Sagar Heroorkar]

Dear Wolfgang,

Thanks you for the reply.

-Sagar

On Wed, Jul 21, 2010 at 3:37 PM, Wolfgang Denk <wd at denx.de> wrote:

> Dear Sagar Heroorkar,
>
> In message <AANLkTilwlzwHniDQAl1VDQascJzJkzmBnoSwMyw2BjGF at 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_
>