U-Boot提示超时

Question

我正在通过串口连接访问 U-boot 控制台，当 u-boot 提示我输入 命令 时，似乎我有限的时间来完成操作。 我想输入几个 命令，但我需要更多时间。是否有人遇到过这样的问题，并且如何增加时间（如果这是问题的原因）？

- izhivkov

Answer 1

U-Boot的启动重试机制，也称防止永久挂起启动

让U-Boot命令提示超时实际上是一种可取的行为，因为如果没有这个功能，意外中断引导可能会使系统永久卡在U-Boot提示符下，直到下一次电源循环。

鉴于此，除了Tom Rini提到的硬件看门狗可能性之外，您的U-Boot构建还可以设置“启动重试”功能，并且不太可能有其他人（就像我一样）正在寻找一种方法来故意引起这种行为。

如果您看到以下内容，则很可能具有启动重试功能：

Timeout waiting for command
resetting ...

---

三个 构建时 配置选项和一个 运行时 变量控制启动重试:

• CONFIG_BOOT_RETRY_TIME 是没有有效命令的默认秒数，超过该时间后（仍可中断）自动启动序列将自动重新运行。

• bootretry 是包含当前生效延迟的 环境变量。负值表示不会发生启动重试。不幸的是，该值只在启动时取样 - 更改它 不会 防止当前会话中的启动重试。

• CONFIG_BOOT_RETRY_MIN 是上述环境变量的安全限制，但是 似乎负值或禁用值通过了检查。这使得更难推断出该设置的预期用途；如果未在配置文件中显式设置，则被赋予 CONFIG_BOOT_RETRY_TIME 的值。

• CONFIG_RESET_TO_RETRY 是一种选项，意味着处理器将重新启动，而不是直接恢复自动启动序列。实际上，这可能是使用启动重试的唯一支持方式；如果不设置该选项，则会导致构建错误。

重要提示：除了一些经过修补的分支外，这些不是您可以将其放在 board_defconfig 中的 KConfig 选项，而是必须放在代码本身的 C 头文件中，特别是适用于构建的系统配置。

---

禁用启动重试

如果您看到上面的超时消息并怀疑启动重试有问题，有几种可能的方法可以停止它。

首先，如果您的 U-Boot 支持持久保存环境变量，您可以

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

然后重新启动。一些系统可能仍具有古老的错误，导致无法解析负值，此时您可以使用一个大正值，例如3600秒（一小时）。

但不幸的是，在不保存环境变量的情况下无法这样做，因为它只在启动时读取。为了使环境变量作为维护的临时覆盖而启用，您可以像这样每次通过有效命令重置超时时重新评估它：

--- 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);
 }

这似乎可以工作，因为您可以将bootretry设置为-1以进行扩展的手动维护。此外，似乎您可以将bootretry设置为比默认值更长，但由于原因不明，尝试缩短它似乎无效。

至少有一部分是专门设计的机制，其中使用配置CONFIG_AUTOBOOT_STOP_STR ，然后输入它应该停止引导重试机制，但我无法使其工作，也找不到任何有用的信息。

---

完全删除引导重试功能

要完全删除引导重试功能，请在适用于您的板的代码中查找其定义位置（例如grep -r CONFIG_BOOT_RETRY *或类似方法），然后删除它，重新构建和刷新。

---

将引导重试作为期望的功能实现

首先，在适用于您特定板的标题中放置必要的# define，例如，如果您有一个Allwinner SoC，则可以执行以下操作：

--- 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

接下来重新构建u-boot，可能是这样的：

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- 

重新打包结果，并将其刷入您的开发板。警告：在覆盖现有U-Boot之前，始终确保具备备用引导或刷写手段！根据您的开发板，这可能是硬件本身从SD卡或USB设备引导的能力，通过USB工具推送代码的能力，或通过JTAG或类似方式启动板子的能力。在紧急情况下，如果将它们保持在复位状态，一些SoC将释放SPI闪存的线路，允许您使用外部编程器；但其他的不会释放线路，这意味着您必须对闪存芯片进行去焊操作。将错误的U-Boot加载到没有其他注入代码方式的板子中，可能会导致砖化！请注意。

- Chris Stratton

Answer 2

我不明白为什么这些CONFIG选项是Kconfig的一部分，以便可以使用“make menuconfig”进行配置，并在_defconfig文件中保存设置。

这比添加和自定义头文件更有意义。

现在已经是2021年了。我想知道是否值得提交一个补丁？

- BrendanSimon

Answer 3

没有更多细节（如平台、配置和版本），很难说。在正常情况下，你唯一的超时时间是停止自动引导。如果板子在开机N秒后可靠地重置，那么很可能是触发了看门狗，并且U-Boot没有配置知道并禁用或定期发送信号来避免系统重置。

- Tom Rini