[参考译文] DRA821U：DRA821：在 SDK 11.02 上的连续软件重新引导测试期间观察到 U-Boot 挂起

尊敬的 Ashwini：

您能否确认在其他引导介质上是否也出现此问题。

BES 此致

Gokul Praveen

尊敬的 Gokul Praveen：

也从 SD 卡引导时会出现同样的问题。

此致、

Ashwini  

Ho Ashwini,

感谢您的更新。 您还能帮助我们解决以下问题吗？

1.这一问题是否出现在所有样本上。

2.您是否能连接到 CCS 调试器并检查它是否始终卡在同一位置。

3.从哪里执行重新引导命令：是从 Uboot 还是从 linuxn Linux。

此致

Gokul Praveen

尊敬的 Gokul Praveen：

[quote userid=“567772“ url=“~/support/processors-group/processors/f/processors-forum/1653905/dra821u-dra821-u-boot-hang-observed-during-continuous-software-reboot-test-on-sdk-11-02/6377322 是否所有样本都存在此问题。

是的

[quote userid=“567772“ url=“~/support/processors-group/processors/f/processors-forum/1653905/dra821u-dra821-u-boot-hang-observed-during-continuous-software-reboot-test-on-sdk-11-02/6377322 您能否连接到 CCS 调试器并检查它是否始终停留在同一位置。

我不熟悉如何使用 CCS 调试器。 您能否提供有关如何使用 CCS 来调试此问题的过程或任何参考文档？ 如果您可以分享在电路板卡住时捕获相关信息所需的步骤、那将会很有帮助。

[quote userid=“567772“ url=“~/support/processors-group/processors/f/processors-forum/1653905/dra821u-dra821-u-boot-hang-observed-during-continuous-software-reboot-test-on-sdk-11-02/6377322 从执行重新引导的位置：UBoot/Linux。

这些工作

此致、

A·阿什维尼

尊敬的 Ashwini：

[引用 userid=“684563“ url=“~/support/processors-group/processors/f/processors-forum/1653905/dra821u-dra821-u-boot-hang-observed-during-continuous-software-reboot-test-on-sdk-11-02 ]U-Boot SPL 2025.01-g01603b10a7f9 (6 月 03 2026 - 04：31：21 +0000)
SYSFW ABI：4.0（固件版本 0x000b'11.2.8--v11.02.08 (Fancy Rat)')
尝试从 MMC0 启动
从无处加载环境... 好的
不支持器件 17 的 init_env！
在 ARM64 内核上启动 ATF……

注意： BL31：v2.13.0（发行版）：e0c4d3903-dirty
注意:BL31: 建造时间:07:01:36, Jul 1 2025

U-Boot SPL 2025.01-g01603b10a7f9 (6 月 03 2026 - 04：31：21 +0000)
SYSFW ABI：4.0（固件版本 0x000b'11.2.8--v11.02.08 (Fancy Rat)')
DM ABI：3.0（固件版本 0x000b 'PSDK.11.02.00.07--v11.02.07' patch_ver：7）
尝试从 MMC0引导

在重新启动失败时、代码是否始终停留在与上面相同的位置/打印位置。

我不熟悉使用 CCS 调试器。 您能否提供有关如何使用 CCS 来调试此问题的过程或任何参考文档？ 如果您能分享在电路板卡住时捕获相关信息所需的步骤、将会很有帮助。

对于 CCS、我建议执行以下步骤：

• 第 1 步:遵循第 7.2 节 。
  • https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j7200/11_02_00_02/exports/docs/psdk_rtos/docs/user_guide/ccs_setup_j7200.html
• 第 2 步：
  • 
  • 点击“SVE configuration“
    • 
  • 将 JTAG 从 PC 连接到 EVM。

当重新启动失败时、请执行以下步骤：

• 第 3 步：
  
  • 按照以下步骤打开 CCS 并启动 j7200.ccxml。  
  • 
• 第 4 步：
  • 启动 EVM。
• 第 5 步：
  • 理想情况下、您现在应该会在 CCS 调试器屏幕的左侧看到以下内容。  
  • 右键点击 A72_0_0 内核、然后选择 Connect Target。
  • 
• 第 6 步：
  • 完成后、您将看到类似这样的内容、它指向代码卡住的 DDR 地址。
  • 
• 第 7 步：
  • 现在、终止会话并关闭 EVM。  
  • 
• 第 8 步：
  • 当重新启动失败时重复步骤 3-Step7、并 按照步骤 6 捕获代码卡住的 DDR 地址

此致

Gokul Praveen

尊敬的 Gokul Praveen：

在重新启动失败时、代码是否始终停留在同一位置/打印位置。

是的。

使用 CCS 调试器时、我们的定制电路板中需要一个连接设备、来调试支持的 UART (MAIN_UART0)、TypeC USB 和数据 UART (MCU_UART0)。 可用作连接。

谢谢您、

此致、

Ashwini

尊敬的 Ashwini：

对延迟深表歉意。 我们必须 连接 XDS110 连接器[ 下面所附映像上的编号 6]、如果您要将 CCS 用作 MCU UART/MAIN UART/TYPEC 接口无法正常工作、该连接器使用 JTAG 调试接口。

此致

Gokul Praveen

尊敬的 Gokul Praveen：

我们的定制板不支持 JTAG 连接器。  

尊敬的 Ashwini：

如果没有 JTAG 调试接口、则无法实际调试该问题、因为我们需要 CCS 来了解此问题的根本原因。

此致

Gokul Praveen

尊敬的 Gokul Praveen：

感谢您的答复。

您能否 通过运行 12 小时的连续软件重新启动测试来验证 J7200 EVM 板上是否观察到了相同的问题？

以下是我用于执行软件重新启动测试的过程：

CD /etc/systemd/system

CAT > reboot.service << EOF

【单位】

Description=MyApp 服务

after=network.target

【服务】

ExecStart=/sbin/reboot

RESTART=始终

RestartSec=5

【安装】

WantedBy= multi-user.target

EOF

chmod 777 reboot.service

systemctl enable reboot.service

systemctl start reboot.service

按照上述步骤、让我知道是否可以在 J7200 EVM 上重现问题。

谢谢您、

A·阿什维尼

尊敬的 Ashwini：

当然、我可以尝试一下。

此致

Gokul Praveen

尊敬的 Gokul Praveen：

您对 J7200 EVM 上的 SW 重新启动测试有任何更新吗？

我还尝试通过向 defconfig 添加以下配置来提高 U-Boot 日志级别：

CONFIG_LOG=y
CONFIG_LOG_CONSOLE=y
CONFIG_LOG_MAX_LEVEL=7
CONFIG_LOG_DEFAULT_LEVEL=7
CONFIG_SPL_LOG=y
CONFIG_SPL_LOG_CONSOLE=y
CONFIG_SPL_LOG_MAX_LEVEL=7
CONFIG_SPL_LOG_DEFAULT_LEVEL=7

通过这些更改、大约需要 2 分钟 才能到达 “Hit any key to stop autoboot“ （点击任意键以停止自动引导）消息、而如果没有其他日志、则只需要大约 3 秒钟。

有趣的是、在提高日志级别后、即使连续运行系统超过 24 小时、我也没有观察到挂起问题。

这让我想知道这个问题是否与 SPL 加载 和 U-Boot 映像加载之间的时序有关。  

请告诉我：

1. 这种与时间有关的问题是否可能？
2. 是否有任何补丁或推荐方法可以在加载 u-boot.img 映像之前特意添加延迟、以便我们可以验证问题是否与延迟相关？

期待您的反馈。

此致、

A·阿什维尼

尊敬的 Ashwini：

对延迟深表歉意。 我已运行重启压力测试 24 小时、但在 TI EVM 上找不到任何故障。

[引述 userid=“684563“ url=“~/support/processors-group/processors/f/processors-forum/1653905/dra821u-dra821-u-boot-hang-observed-during-continuous-software-reboot-test-on-sdk-11-02/6387433

有趣的是、在提高日志级别后、即使连续运行系统超过 24 小时、我也没有观察到挂起问题。

这让我想知道这个问题是否与 SPL 加载 和 U-Boot 映像加载之间的时序有关。  

请告诉我：

1. 这种与时间有关的问题是否可能？
2. 是否有任何补丁或推荐方法可以在加载 u-boot.img 映像之前特意添加延迟、以便我们可以验证问题是否与延迟相关？

[/报价]

理想情况下、这不应该是因为我们在 TI EVM 上的重启压力测试没有遇到任何问题。 尝试在定制电路板上进行更多小时的测试、看看是否会出现故障。 可能只是定制电路板现在需要更多的应力测试才能到达故障案例。

此致

Gokul Praveen

感谢您的答复。

我们当前正在在定制电路板上调试同一问题。您能分享一些调试技巧或建议的方法来缩小此问题的根本原因吗？ 对需要关注的具体领域或隔离问题的方法提出任何建议都将是非常有帮助的。

谢谢你。

此致、
A·阿什维尼

HII Gokul Praveen,

这里我附加了我们的定制主板所做的更改、 您能否检查更改并告诉我们、如果您注意到任何可能导致系统在重新启动期间挂起的问题？

e2e.ti.com/.../U_2D00_boot.txt

谢谢你

此致、

A·阿什维尼

HII Gokul Praveen,

上述查询的任何更新。

尊敬的 Gokul Praveen：

我已运行重启压力测试 24 小时、但在 TI EVM 上找不到任何故障。

您能否从 EVM 共享完整的引导和重新启动日志？

谢谢您、

此致、

A·阿什维尼

尊敬的 Gokul Praveen：

我们添加了在从 spl 跳转到 uboot 正确地址之前清除缓存的更改

文件名：common/spl/spl.c
__weak void __noreep jump_to_image_no_args (struct spl_image_info *spl_image)  
｛

debug（“图像入口点：0x%lx\n“、spl_image->entry_point)；

+#ifdef CONFIG_ARM64
+       cleanup_Before_linux ();
+#endif
+       flush()；
       image_entry()；

 通过此更改、重新启动测试运行超过 15 小时。
请核实并指导我们继续。

此致、

A·阿什维尼

尊敬的 Ashwini：

如果在做了更深层次的压力测试后这是良好和良好的,那么你可以继续这样做,因为它将确保内存在跳前处于一个适当的状态。

此致

Gokul Praveen