[U-Boot-Users] [PATCH] 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.
Signed-off-by: Wilson Callan wcallan@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
participants (2)
-
Jerry Van Baren
-
Wilson Callan