[U-Boot-Users] Fail Safe: Redundant U-boot Images in Flash????
Wolfgang Denk
wd at denx.de
Fri Sep 23 21:06:40 CEST 2005
In message <65E50D2CD54E9649B6CAA522C3EF659105E34667 at 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.
More information about the U-Boot
mailing list