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-Users] intended behavior of bootm
Date: Tue, 22 Apr 2008 22:49:23 +0200	[thread overview]
Message-ID: <20080422204923.D4AF124AB5@gemini.denx.de> (raw)
In-Reply-To: Your message of "Mon, 21 Apr 2008 23:02:30 +0200." <200804212302.30762.matthias.fuchs@esd-electronics.com>

In message <200804212302.30762.matthias.fuchs@esd-electronics.com> you wrote:
> 
> Now I have to find a (simple) solution to solve my problem:
> 
> Typically the 405 board boots from onboard flash. Because of historic
> reason there is a kernel and a ramdisk image (not a multi image and nothing
> that is aware of any new image format). These images cannot be changed.
> When one of these images either one of them or both is corrupted, U-Boot
> should try to load both of them from a usb mass storage. So what's the best
> way to do so?

The key question here is your definition of "corrupted".

If reliability is an issue, you want to implement (1) support  for  a
hardware  watchdog combined with (2) support for a boot counter. Then
you set "bootlimit" to a reasonable value  and  "altbootcmd"  to  the
command required to load and boot from USB.

Such a setup will be very robust and handle even situations when  the
images  look  good  (checksums  are  OK  etc.)  but fail to work (for
example, because of buggy binaries or libraries were included, config
files got corrupted, etc.).

> 1) Make bootm fail when any image has a CRC error?

This is trivial to do. Remember that you can always use "imi" to check
images; something like

=> imi $kernel_addr && imi $ramdisk_addr && bootm $kernel_addr $ramdisk_addr

would do what you want.

The new image format allows for even fancier methods.

Or implement a boot counter and let the board reset on corrupt images
and then use "altbootcmd".

> 2) Add a new command to check images and decide on the result

Not needed. "iminfo" already does that.

> Any idea? I think the idea behind this is clear. When images A are not ok boot
> images B.

As mentioned above, the trick question is  how  you  define  when  an
image is OK.



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
What kind of love is that?  Not to be loved; never to have shown love.
	-- Commissioner Nancy Hedford, "Metamorphosis",
	   stardate 3219.8

  reply	other threads:[~2008-04-22 20:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-21 13:09 [U-Boot-Users] intended behavior of bootm Matthias Fuchs
2008-04-21 14:58 ` Matthias Fuchs
2008-04-21 15:16   ` Jerry Van Baren
2008-04-21 15:43     ` Matthias Fuchs
2008-04-21 16:28       ` Jerry Van Baren
2008-04-21 19:19 ` Wolfgang Denk
2008-04-21 21:02   ` Matthias Fuchs
2008-04-22 20:49     ` Wolfgang Denk [this message]
2008-04-23  8:43       ` Matthias Fuchs

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=20080422204923.D4AF124AB5@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