[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash????

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash????

[Eisenhut, Daniel]

> Has anyone ever implemented duel U-boot images in flash as a
> fail safe mechanism? A primary U-boot image, and a backup U-boot
> image incase the primary image is invalid.
>
> I understand there needs to be a single boot point with
> verification to determine which image to boot from. Is there a
> mechanism already in U-boot that can do this?

We're looking at doing something similar on an MPC860 with a
first-stage U-Boot that just checksums and jumps to one of two
second-stage U-Boot images that are stored in flash.  This would
allow us to update U-Boot in the field without risk of losing our
bootloader and being left with a dead system.  Of course, this
assumes we keep the initial U-Boot very simple so that we can get
away with never updating it. We haven't started working on it yet,
just discussing at a high level.  Might have some issues with
vectors.

Dan

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash????

[Wolfgang Denk]

In message <65E50D2CD54E9649B6CAA522C3EF659105E34667@MKEMLVEM08.e2k.ad.ge.com> you wrote:
>
> We're looking at doing something similar on an MPC860 with a
> first-stage U-Boot that just checksums and jumps to one of two
> second-stage U-Boot images that are stored in flash.  This would

A checksum does not help anything. It is no guarantee that  an  image
is actually working. Also, many systems have an embedded environment,
so the first "saveenv" will kill your checksum.

> allow us to update U-Boot in the field without risk of losing our
> bootloader and being left with a dead system.  Of course, this

Installing a new image and just relying on the checksum is  something
you can already do today.

> assumes we keep the initial U-Boot very simple so that we can get

Please don't call this "init code "U-Boot", then. And  note  that  it
will  not  be  as  simple as you like. You said checksum? So you must
have at least the checksum functions; you must determine which of the
available images to select; you may have  to  trigger  the  watchdog;
etc. etc.

> away with never updating it. We haven't started working on it yet,
> just discussing at a high level.  Might have some issues with
> vectors.

It is far from trivial, and if you look cloder into it, you will find
that you cannot fix all of the things that potentially can go  wrong.
In  the  end  you  might  decide that it's either saver to not update
U-Boot, or to use it just as the core and implement any higher  level
functions  as  loadable standalone programs, or just to risk that one
out of N (N being some really big number) updates might  actually  go
wrong.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What the gods would destroy they first submit to  an  IEEE  standards
committee.

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash??? ?

[Frank]

--- "Eisenhut, Daniel (GE Healthcare)"
<Daniel.Eisenhut@med.ge.com> wrote:

> > > The code at the entry point needs to be small, reliable
> and never require an
> > > upgrade in the field. This code would run a CRC on the
> primary U-boot image
> >
> > THe code at the  entry  point  that  is  small,  reliable 
> and  never
> > requires  an upgrade in the field is U-Boot. Just don't
> touch it. You
> > don't have to.
> 
> ...insert bullet, spin cylinder, point at foot, pull
> trigger...
> 
> Hopefully, we will never need to update.  But if we do, it'd
> be nice
> to be able to reduce the risk of updating as much as possible.
> 
> > What you typically do (assuming the hardware supports it) is
> to  have
> > two  banks  of  flash memory that can be swapped using some
> jumper or
> > switch or so.
> 
> When it costs a grand just to have a service tech walk in the
> door, this
> becomes an unacceptable option.

What you guys are trying to do, I've done many times before. You
should at least have a bit mask in nonvolatile memory somewhere
that tells you the result of your operation. One bit tells the
the "miniboot'" loader That this is the first time the image has
beeen booted. Another bit is set when the new image comes up
telling the miniboot loader that it came up ok. If the new image
nerver get's to the point where it can set that bit and the
"first time bit" is reset then the miniboot loader won't try and
boot that image the second time around. I may have left some
details out but basically it works for me...
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your
> very own
> Sony(tm)PSP.  Click here to play:
> http://sourceforge.net/geronimo.php
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash??? ?

[Frank]

--- "Eisenhut, Daniel (GE Healthcare)"
<Daniel.Eisenhut@med.ge.com> wrote:

> > > 
> > > > So what happens if the CRC is correct, but the new image
> has
> > > a
> > > > bug (functional ?) in it....
> > > 
> > > Then you should of tested your code before you released
> it. 
> > > If the
> > > CRC passes, then it is the same as what you tested.
> > > 
> > Famous last words. Sometimes corner cases are missed. I
> don't
> > know about you, but I realized a long time ago I am not
> perfect
> > and make mistakes. So what do you do when the hardware
> reboots
> > because of some unforseen proble? Just sit in a loop and
> reboot
> > forever?
> 
> No, no one is perfect.  But to imply that we should forgo
> implementing
> fail safes to protect against the power failing right as we
> are
> programming flash or flash becoming corrupt just because we
> might
> still have a bug in our code, is just plain foolish.

I didn't say that. The point I was trying to make is if for
whatever reason the image doesn't boot, you should have a fall
back method. if you don't, you will continually reboot forever..
> 



	
		
______________________________________________________ 
Yahoo! for Good 
Donate to the Hurricane Katrina relief effort. 
http://store.yahoo.com/redcross-donate3/ 

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash??? ?

[Eisenhut, Daniel]

> > The code at the entry point needs to be small, reliable and never require an
> > upgrade in the field. This code would run a CRC on the primary U-boot image
>
> THe code at the  entry  point  that  is  small,  reliable  and  never
> requires  an upgrade in the field is U-Boot. Just don't touch it. You
> don't have to.

...insert bullet, spin cylinder, point at foot, pull trigger...

Hopefully, we will never need to update.  But if we do, it'd be nice
to be able to reduce the risk of updating as much as possible.

> What you typically do (assuming the hardware supports it) is to  have
> two  banks  of  flash memory that can be swapped using some jumper or
> switch or so.

When it costs a grand just to have a service tech walk in the door, this
becomes an unacceptable option.

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash??? ?

[Eisenhut, Daniel]

> > 
> > > So what happens if the CRC is correct, but the new image has
> > a
> > > bug (functional ?) in it....
> > 
> > Then you should of tested your code before you released it. 
> > If the
> > CRC passes, then it is the same as what you tested.
> > 
> Famous last words. Sometimes corner cases are missed. I don't
> know about you, but I realized a long time ago I am not perfect
> and make mistakes. So what do you do when the hardware reboots
> because of some unforseen proble? Just sit in a loop and reboot
> forever?

No, no one is perfect.  But to imply that we should forgo implementing
fail safes to protect against the power failing right as we are
programming flash or flash becoming corrupt just because we might
still have a bug in our code, is just plain foolish.

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash??? ?

[Frank]

--- "Eisenhut, Daniel (GE Healthcare)"
<Daniel.Eisenhut@med.ge.com> wrote:

> 
> > So what happens if the CRC is correct, but the new image has
> a
> > bug (functional ?) in it....
> 
> Then you should of tested your code before you released it. 
> If the
> CRC passes, then it is the same as what you tested.
> 
> 
I hope "med.ge.com" doesn't mean you guys are making pacemakers
or something. if so, I hope I won't need one from "GE MED" in
the future. S...t happens and if you don't allow for it, it
_will_ happen. Ever heard of Murphy?


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash??? ?

[Frank]

--- "Eisenhut, Daniel (GE Healthcare)"
<Daniel.Eisenhut@med.ge.com> wrote:

> 
> > So what happens if the CRC is correct, but the new image has
> a
> > bug (functional ?) in it....
> 
> Then you should of tested your code before you released it. 
> If the
> CRC passes, then it is the same as what you tested.
> 
Famous last words. Sometimes corner cases are missed. I don't
know about you, but I realized a long time ago I am not perfect
and make mistakes. So what do you do when the hardware reboots
because of some unforseen proble? Just sit in a loop and reboot
forever?


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash??? ?

[Eisenhut, Daniel]

> So what happens if the CRC is correct, but the new image has a
> bug (functional ?) in it....

Then you should of tested your code before you released it.  If the
CRC passes, then it is the same as what you tested.

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash??? ?

[Wolfgang Denk]

In message <5F98E47AD7B1C349895ED4E2EDF3918B01F291FF@stca209a> you wrote:
>  
> The code at the entry point needs to be small, reliable and never require an
> upgrade in the field. This code would run a CRC on the primary U-boot image

THe code at the  entry  point  that  is  small,  reliable  and  never
requires  an upgrade in the field is U-Boot. Just don't touch it. You
don't have to.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
No man knows what true happiness is until he gets married.  By  then,
of course, its too late.

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash????

[Thomas Lange]

Roberts, John wrote:

>The code at the entry point needs to be small, reliable and never require an
>upgrade in the field. This code would run a CRC on the primary U-boot image
>to determine if it's safe to boot, upon CRC failure verify then run the
>backup image.
>
>For remote systems we need to resolve the issue of upgrade failure without
>human intervention - or perhaps remote human intervention.
>  
>
We have done this on our board "gth".
We use a pre-loader called miniboot:
http://opensource.se/projects/miniboot/index.html

Miniboot choose which of two u-boot images to boot by checking CRC.

Regards,
/Thomas

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash??? ?

[Frank]

--- "Roberts, John" <john.e.roberts@siemens.com> wrote:

>  
> 
> >It is impossible - there is only one reset entry point.
> >How would you determine which image to boot?
> 
> >What you typically do (assuming the hardware supports it) is
> to  have
> >two  banks  of  flash memory that can be swapped using some
> jumper or
> >switch or so.
> 
> The code at the entry point needs to be small, reliable and
> never require an
> upgrade in the field. This code would run a CRC on the primary
> U-boot image
> to determine if it's safe to boot, upon CRC failure verify
> then run the
> backup image.
> 
> For remote systems we need to resolve the issue of upgrade
> failure without
> human intervention - or perhaps remote human intervention. 
> 
> -John Roberts  (Engineer, not Judge)

So what happens if the CRC is correct, but the new image has a
bug (functional ?) in it....
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your
> very own
> Sony(tm)PSP.  Click here to play:
> http://sourceforge.net/geronimo.php
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash??? ?

[Roberts, John]

 

>It is impossible - there is only one reset entry point.
>How would you determine which image to boot?

>What you typically do (assuming the hardware supports it) is to  have
>two  banks  of  flash memory that can be swapped using some jumper or
>switch or so.

The code at the entry point needs to be small, reliable and never require an
upgrade in the field. This code would run a CRC on the primary U-boot image
to determine if it's safe to boot, upon CRC failure verify then run the
backup image.

For remote systems we need to resolve the issue of upgrade failure without
human intervention - or perhaps remote human intervention. 

-John Roberts  (Engineer, not Judge)

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash????

[Dan Malek]

On Sep 23, 2005, at 2:56 PM, Wolfgang Denk wrote:

> What you typically do (assuming the hardware supports it) is to  have
> two  banks  of  flash memory that can be swapped using some jumper or
> switch or so.

What I have done in the past is evaluate what you really want to
be updating, and found I didn't really need to update U-Boot itself.
I will write some U-Boot applications, as a second stage loader
that you can then select, and is usually the code that needs to
change over the life of the product.  This way, you always have a
working, never changing, U-Boot that can always be used to
recover from other mistakes ;-)

In my experience, all of the "fail safe" systems only had that
concept in common.  The implementation and update procedures
were always different.  The other thing in common is we never
planned to update the original U-Boot, since that was never necessary
with a mult-stage boot process.

Thanks.

	-- Dan

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash????

[Wolfgang Denk]

In message <5F98E47AD7B1C349895ED4E2EDF3918B01F291FB@stca209a> you wrote:
> 
> Has anyone ever implemented duel U-boot images in flash as a fail safe
> mechanism? A primary U-boot image, and a backup U-boot image incase the
> primary image is invalid.

It is impossible - there is only one reset entry point.

> I understand there needs to be a single boot point with verification to
> determine which image to boot from. Is there a mechanism already in U-boot
> that can do this?

How would you determine which image to boot?

What you typically do (assuming the hardware supports it) is to  have
two  banks  of  flash memory that can be swapped using some jumper or
switch or so.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"One lawyer can steal more than a hundred men with guns."
- The Godfather

[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash????

[Roberts, John]

Has anyone ever implemented duel U-boot images in flash as a fail safe
mechanism? A primary U-boot image, and a backup U-boot image incase the
primary image is invalid.

I understand there needs to be a single boot point with verification to
determine which image to boot from. Is there a mechanism already in U-boot
that can do this?

Any information is appreciated.

(440gx)
> -John Roberts
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20050923/41222c67/attachment.htm