U-Boot提示超时

Question

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

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

Answer 1

没有更多细节（例如平台、配置和版本），很难说。在正常情况下，您唯一的超时时间是停止自动引导。如果电路板在启动 N 秒后可靠地复位，则可能是触发了看门狗，并且 U-Boot 未配置为了解并禁用或定期抚摸看门狗以防止系统复位。

Answer 2

U-Boot 的引导重试机制，又名，防止永远挂起的引导

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

鉴于此，除了 Tom Rini 提到的硬件看门狗可能性之外，您的 U-Boot 构建也可能设置有“启动重试”功能 - 找到此页面的其他人（就像我一样）寻找一种方法 故意导致 此类行为并非不可能。

如果您看到以下内容，则可能是启动重试：

Timeout waiting for command
resetting ...

三个 build-time 配置选项和一个 run-time 变量管理引导重试：

CONFIG_BOOT_RETRY_TIME 是 默认值 没有有效命令的秒数，之后 (仍可中断）自动启动顺序将自动 re-run.
bootretry 是一个 环境变量 包含当前生效的延迟。负值意味着不会发生引导重试。不幸的是，此值仅在启动时采样 - 更改它不会阻止在当前 session.
中重试启动
CONFIG_BOOT_RETRY_MIN 是上述环境变量的安全限制，但是 负值或禁用值似乎得到了通过检查。这使得推断此设置的预期用途变得更加困难；如果未在配置中明确设置，则分配值 CONFIG_BOOT_RETRY_TIME.
CONFIG_RESET_TO_RETRY 是一个选项，表示处理器将重新启动，而不是直接恢复自动启动序列。这实际上可能是唯一受支持的使用引导重试的方式；如果您不这样做，似乎会出现构建错误，要求您设置它。

重要说明：除了一些补丁叉，这些不是您可以放入 board_defconfig 的 KConfig 选项，而是必须放入的 #define代码本身的一个 C header 文件，具体适用于您构建的系统配置。

禁用启动重试

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

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

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

然后重启。一些系统可能仍然存在 ancient 错误，该错误会阻止解析负值，在这种情况下，您可以使用较大的正值，例如 3600 秒（一小时）。

但不幸的是，如果不保存环境变量，您将无法执行此操作，因为它仅在启动时读取。要启用将环境变量用作临时覆盖以进行维护，您可以在每次通过有效命令重置超时时对 re-evaluate 执行类似的操作：

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

这似乎可行，因为您可以将引导重试设置为 -1 以进行更长时间的手动维护。您似乎还可以将引导重试设置为比默认值更长的时间，但是由于不明原因，尝试将其设置得更短似乎不起作用。

似乎至少 部分设计在 机制中使用配置 CONFIG_AUTOBOOT_STOP_STR 然后输入它应该停止引导重试机制，但我在搜索时无法正常工作或找不到任何有用的匹配项。

完全删除启动重试功能

要完全删除启动重试功能，请在适用于您的电路板的代码（grep -r CONFIG_BOOT_RETRY * 或类似代码）中找到它的定义位置，删除它，重建并重新刷写。

实现启动重试作为所需的功能

首先，将必要的#define 放在适用于您的特定板的 header 中，例如，如果您有 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-

适当地重新打包结果并将其闪存到您的开发板

警告：在 over-writing 现有的 U-Boot!

之前，始终确保您有启动或闪烁的备份方法

根据您的电路板，这可能类似于硬件本身从 SD 卡或 USB 记忆棒启动的能力，通过 USB 实用程序推送代码，或者通过 JTAG 启动电路板的能力或类似的。在紧要关头，如果您将某些 SoC 保持在复位状态，它们会释放到 SPI 闪存的线路，从而允许您使用外部编程器 - 但其他一些不会释放线路，这意味着您必须拆焊闪存芯片。将错误的 U-Boot 加载到您没有其他方式注入代码的电路板中，只能通过U-Boot 本身 可以导致变砖！.

Answer 3

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

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

现在是 2021 年。我想知道是否值得提交补丁？

U-Boot提示超时

U-Boot prompt timeout

u-boot