new CONFIG_RETURN_FROM_BOOTM

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CONFIG_RETURN_FROM_BOOTM.patch
Type: application/octet-stream
Size: 2926 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070720/a7909ce9/attachment.obj

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