U-Boot提示超时

Question

我通过串行连接访问U-boot 的控制台，当u-boot提示我输入时commands，似乎我的时间有限。我想参加几个commands，但我需要更多时间。

有人遇到过这样的问题吗？我怎样才能增加时间（如果这是问题所在）？

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 选项，而是#define必须放入代码本身的 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 或类似功能启动主板的能力。在紧要关头，如果您将 SPI 闪存保持在复位状态，某些 SoC 将释放这些线路，从而允许您使用外部编程器 - 但其他 SoC 不会释放这些线路，这意味着您必须拆焊闪存芯片。将错误的 U-Boot 加载到板上，除了通过 U-Boot 本身注入代码之外没有其他方法，可能会导致变砖！。