U-Boot prompt timeout

Question

I'm accessing U-boot's console via serial connection and when u-boot prompt me to enter commands, it seems that I have limited time to do that. I want to enter several commands, but I need more time.

Does anyone experienced such an issue and how can I increase that time (if that is the problem)?

Answer 1

U-Boot's Boot Retry Mechanism, AKA, Preventing Eternally Hung Boot

Having the U-Boot command prompt timeout can actually be desirable behavior, as without this an inadvertent interruption of the boot could leave a system permanently stuck at the U-Boot prompt until the next power cycle.

Given this, in addition to the hardware watchdog possibility mentioned by Tom Rini, it is also possible that your U-Boot build could be set up with the "Boot Retry" feature - and not unlikely that others finding this page will (as I was) be seeking a way to intentionally cause such behavior.

If you see the following, you likely have boot retry:

Timeout waiting for command
resetting ...

---

Three build-time configuration options and one run-time variable govern boot retry:

• CONFIG_BOOT_RETRY_TIME is the default number of seconds without a valid command, after which the (still interruptible) auto boot sequence will be automatically re-run.

• bootretry is an environment variable containing the current delay in effect. Negative values mean boot retry will not occur. Unfortunately, this value is only sampled on startup - changing it will not prevent boot retry in the current session.

• CONFIG_BOOT_RETRY_MIN is a safety limit on the above environment variable, however it appears that negative or disabling values get a pass through the check. This makes it harder to deduce the intended usage of this setting; if not explicitly set in the config it is assigned the value of CONFIG_BOOT_RETRY_TIME.

• CONFIG_RESET_TO_RETRY is an option which means that instead of directly resuming the autoboot sequence, the processor will reboot. This may in fact be the only supported way of using boot retry; it seems that a build error asking you to set it results if you do not.

Critical note: Except in a few patched forks, these are not KConfig options which you can put in your board_defconfig, but rather #define's which must go in a C header file of the code itself, specifically one applicable to the system configuration which you build.

---

Disable Boot Retry

If you saw the above timeout message and suspect that boot retry is at fault, there are a few possible ways to stop it.

First, if your u-boot supports saving environment variables persistently, you could

u-boot> setenv bootretry -1
u-boot> saveenv

and then reboot. A few systems may still have an ancient bug which prevents parsing a negative value, in which case you could use a large positive one, such as 3600 seconds (one hour).

But unfortunately, you cannot do this without saving the environment variable, as it is only read on startup. To enable using the environment variable as a temporary override for maintenance, you could do something like this to re-evaluate it each time the timeout is reset by a valid command:

--- a/common/bootretry.c
+++ b/common/bootretry.c
@@ -39,6 +39,7 @@ void bootretry_init_cmd_timeout(void)
  */
 void bootretry_reset_cmd_timeout(void)
 {
+       bootretry_init_cmd_timeout(); //pickup any environment change
        endtime = endtick(retry_time);
 }

This seems to work, in that you can set the bootretry to -1 for extended manual maintenance. It also seems you can set the bootretry to longer than default, but for reasons not understood, trying to set it shorter does not seem to work.

There does appear to be at least part of designed in mechanism where using configuring CONFIG_AUTOBOOT_STOP_STR and then entering it is supposed to stop the boot retry mechanism, but I couldn't get that to work or find any useful hits when searching on it.

---

To remove boot retry feature entirely

To remove the boot retry feature entirely, find where it is being defined in code applicable to your board (grep -r CONFIG_BOOT_RETRY * or similar), remove that, rebuild and reflash.

---

To achieve boot retry as a desired feature

First, put the necessary #define in a header applicable to your specific board, for example, if you had an Allwinner SoC you might do:

--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -16,6 +16,8 @@
 #include <asm/arch/cpu.h>
 #include <linux/stringify.h>
 
+#define CONFIG_BOOT_RETRY_TIME 60 //command prompt will timeout
+#define CONFIG_RESET_TO_RETRY     //required for above on this chip
+
 #ifdef CONFIG_OLD_SUNXI_KERNEL_COMPAT
 /*
  * The U-Boot workarounds bugs in the outdated buggy sunxi-3.4 kernels at the

Then rebuild u-boot, probably something like this:

make CROSS_COMPILE=~/path/to/gcc-xxx-yyy-zzz-/bin/xxx-yyy-zzz- clean
make CROSS_COMPILE=~/path/to/gcc-xxx-yyy-zzz-/bin/xxx-yyy-zzz- your_board_defconfig
make CROSS_COMPILE=~/path/to/gcc-xxx-yyy-zzz-/bin/xxx-yyy-zzz- 

Repackage the result appropriately and flash it to your board

Warning: Always make sure you have a backup means of booting or flashing before over-writing the existing U-Boot!

Depending on your board, that might be something like the ability for the hardware itself to boot from an SD card or USB stick, to push code via a USB utility, or the or the ability to start the board via JTAG or similar. In a pinch some SoC's will release the lines to an SPI flash if you hold them in reset, allowing you to use an external programmer - but others will not release the lines, meaning you have to desolder the flash chip. Loading a bad U-Boot into a board where you have no other way of injecting code but through U-Boot itself can result in a brick!.

Answer 2

Without more details (such as platform, config and version), it's hard to say. Under normal circumstances the only timeout you have is to stop the automatic boot. If the board is resetting reliably after N seconds of being on it is likely that a watchdog is being triggered and U-Boot is not configured to know about and either disable or periodically pet the watchdog to keep the system from resettting.