From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] new CONFIG_RETURN_FROM_BOOTM
Date: Fri, 20 Jul 2007 10:22:52 -0400 [thread overview]
Message-ID: <46A0C53C.2070006@smiths-aerospace.com> (raw)
In-Reply-To: <6588BF2C-AD54-42AB-9673-CA5D60013AB0@savantav.com>
Wilson Callan wrote:
> Hi,
>
> I've added an option similar to the netretry=no environment option
> which allows a script to control the retry operation for networking.
> This option controls a retry operation for bootm. Here is the README
> entry:
>
> +- CONFIG_RETURN_FROM_BOOTM
> +
> + Return from the bootm command instead of rebooting. This
> + is useful for setting up multiple boot image options in a
> + script. It allows the script to control the retry
> + operation. For example, these scripts setup a system that
> + will attempt a primary flash image, then a backup image
> + location, then resort to TFTP:
> + "boot_tftp=dhcp 3c0;bootm 3c0;reset\0" /* if fails, reset */ \
> + "boot_flash=bootm ff050000 3c0;bootm ffc00000 3c0;run
> boot_tftp;reset\0"
>
>
> CHANGELOG:
>
> Added CONFIG_RETURN_FROM_BOOTM to control retry operation of bootm command.
>
> Signed-off-by: Wilson Callan <wcallan@savantav.com>
NAK
This is a *BAD* idea as is. See the comment in cmd_bootm.c line 298:
<http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=common/cmd_bootm.c;h=ba286f1e636c1f6d36ea41b0366b6e192ef03d0f;hb=HEAD#l298>
298 /*
299 * We have reached the point of no return: we are going to
300 * overwrite all exception vector code, so we cannot easily
301 * recover from any failures any more...
302 */
If you return, one of four things will happen:
a) U-boot will continue to work.
b) It may work by pure luck.
c) It may work for a while and then go goofy and crash.
d) It may simply crash.
Unless you can guarantee (a), this is not an acceptable patch. Note
that the current code does *NOT* guarantee (a). My experience is that
it is (c) or (b), in that order (DAMHIKT).
Trivia: I have some pending reorganization and other improvements in my
u-boot-fdt repo that fix some erroneous returns. One Of These Days they
will be pulled into the mainline repo.
<http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=blob;f=common/cmd_bootm.c;h=ba286f1e636c1f6d36ea41b0366b6e192ef03d0f;hb=HEAD>
One thought is to copy the interrupt vectors to a set-aside area so
that, if something fails after line 298, you can restore the interrupt
vectors and _then_ return. Note that you have to guarantee your u-boot
(static) variables are not overwritten by the aborted bootm command as
well. This /shouldn't/ be an issue, but it could be since stupid^W
ignorant users can load in poorly chosen memory locations.
Good luck,
gvb
prev parent reply other threads:[~2007-07-20 14:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-20 13:57 [U-Boot-Users] [PATCH] new CONFIG_RETURN_FROM_BOOTM Wilson Callan
2007-07-20 14:22 ` Jerry Van Baren [this message]
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=46A0C53C.2070006@smiths-aerospace.com \
--to=gerald.vanbaren@smiths-aerospace.com \
--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