[参考译文] AM625：AM625引导 ATF 错误跟随情况

PLZ 允许这里的跳线监控/帮助这个问题。

您好！

如果出现故障、客户是否在 WKUP_UART0端口上观察到 DM 固件日志？

这是为了确认故障是否是由于 DM 固件未启动和运行所致。

此致、

Prashant

Prashant,  

我不确定客户电路板上是否保留了 WKUP_UART0。  

DM 固件启动时、EVM 上是否会有控制台日志？

您是否希望日志上有任何特定消息、或者预期日志会在某处停止？  

此外、当发生 ATF 时、客户使用 CCS 连接故障器件、发现 A53和 R5上的 PC 始终停止在同一地址、这意味着原因应该相同、但不是随机的。  

BR、丰富  

您好！

如果 DM 固件已启动并正在运行、则 WKUP_UART0控制台的日志应如下所示：

我是否可以知道 DM 固件客户正在此处使用？ 是 PSDK 附带的预编译版本还是通过 MCU+ SDK 手动编译的版本？

此致、

Prashant

Prashant,  

谢谢、我们会在客户电路板上检查 WKUP_UART0。  

客户仅使用 Linux SDK、他们从不使用 MCU+ SDK、因此我假设这是预先构建的 SDK。  

BR、丰富

Eric Ding 说：

客户仅使用 Linux SDK、他们从不使用 MCU+ SDK、因此我假设这是预先构建的 SDK。  [报价]

假设他们仅使用预构建固件、您能否让客户下载以下 DM 固件

e2e.ti.com/.../dm_5F00_firmwares.zip

然后、通过替换$psdk/board-support/prebuilt-images/am62xx-evm/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f 中提供的预编译脚、逐一测试这些脚本。

cp ~/Downloads/ipc_rpmsg_echo_linux.wkup-r5f0_0.release.strip.out ~/ti/psdk/am62x/09.01.00.08/board-support/prebuilt-images/am62xx-evm/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f
cp ~/Downloads/ipc_rpmsg_echo_linux.wkup-r5f0_0.debug.strip.out ~/ti/psdk/am62x/09.01.00.08/board-support/prebuilt-images/am62xx-evm/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f

请告诉我、问题是否仍然与两者有关、还是仅与其中一个有关。

谢谢！

Prashant

Prashant,  

客户尝试了您为调试版和发布版提供的新 DM 固件。  

AM62x 侧的端点13和14是什么？  

正在启动 Sciserver..... 通过
[IPC RPMSG ECHO]版本：Rel.MCUSDK.09.01.00.39+(2024年12月26日15：47：53)：
[IPC RPMSG ECHO]远程核心在端点13等待消息...!!!
[IPC RPMSG ECHO]远程核心在端点14等待消息...!!!

A53和 DM 的日志已附加。  

调试版本：

e2e.ti.com/.../uart0_2D00_debugimage_2D00_log.txte2e.ti.com/.../4011.errorlog.txt

发布版本：

e2e.ti.com/.../1230_2D00_release_2D00_test.txte2e.ti.com/.../uart0_2D00_release_2D00_log.txt

BR、丰富

Prashant,  

我们已检查旧固件、发现 A53和 DM 日志与新 DM 版本相同。  

它看起来 DM 正在运行且未卡住。  

因此、我们需要检查回到 A53侧卡住的 PC。  

在 A53引导日志中、0x9E788200位于早期内存节点范围、我标记为黄色。  

我们试图检查 tee.map、但它从0x9E800000开始。

您知道这个范围上的函数是什么吗？  

正在启动内核...

[ 0.000000]在物理 CPU 上引导 Linux 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 6.1.46-rt13-bsp_12.5.1 --g2ff8ed6046 (OE-user@OE-host)(AArch64-OE-LINUX-gcc (GCC) 11.4.0、GNU ld (GNU binutils) 2.38.20220708)#1 UTC preempt_RT Wed 7月3 08：48：50 UTC 2024
[ 0.000000]机器模型：德州仪器(TI) AM625 SK
[ 0.000000] earlycon：ns16550a0 at MMIO32 0x0000000002800000 (选项"")
[ 0.000000] printk：启动控制台[ns16550a0]已启用
[ 0.000000] EFI：找不到 UEFI。
[ 0.000000]保留内存：在0x00000000f7600000处创建了 CMA 内存池、大小为128 MIB
[ 0.000000] of：reserved mem：initialized node linux、cma、compatible id shared-dma-pool
[ 0.000000]保留内存：在0x000000009c800000处创建了 DMA 内存池、大小为3MiB
[ 0.000000] of：reserved mem：initialized node ipc-memorys@9c800000、compatible id shared-dma-pool
[ 0.000000]保留内存：在0x000000009cb00000创建了 DMA 内存池、大小为1MiB
[ 0.000000] of：reserved mem：initialized node M4F-DMA-memory@9cb00000、compatible id shared-dma-pool
[ 0.000000]保留内存：在0x000000009cc00000创建 DMA 内存池、大小为14 MiB
[ 0.000000] of：reserved mem：initialized node m4f-memory@9cc00000、compatible id shared-dma-pool
[ 0.000000]保留内存：在0x000000009da00000创建了 DMA 内存池、大小为1MiB
[ 0.000000] of：reserved mem：initialized node r5f-dma-memory@9da00000、compatible id shared-dma-pool
[ 0.000000]保留内存：在0x000000009db00000创建 DMA 内存池、大小为12MiB
[ 0.000000] of：reserved mem：initialized node r5f-memory@9db00000、compatible id shared-dma-pool
[ 0.000000]区域范围：
[ 0.000000] DMA [存储器0x0000000080000000-0x00000000ffff]
[ 0.000000] dma32空
[ 0.000000]正常为空
[ 0.000000]每个节点的可移动区域开始
[ 0.000000]早期内存节点范围
[ 0.000000]节点0：[MEM 0x0000000080000000-0x000000009c7fff]
[ 0.000000]节点0：[MEM 0x000000009c800000-0x000000009e6fff]
[ 0.000000]节点0：[MEM 0x000000009e700000-0x000000009e77ffffffffff]
[ 0.000000]节点0：[MEM 0x000000009e780000-0x000000009fffff]
[ 0.000000]节点0：[MEM 0x00000000a0000000-0x00000000ff6fffff]
[ 0.000000]节点0：[MEM 0x00000000ff700000-0x00000000fffc9fff]
[ 0.000000]节点0：[MEM 0x00000000fffca000-0x00000000ffffff]
[ 0.000000] Initmem 设置节点0 [mem 0x0000000080000000-0x00000000ffff]

BR、丰富

Prashant,

我是否可以确认获取 WKUP_UART0 DM 日志控制台的目的是判断 DM 固件是否已运行？  

从当前的 DM 日志中、所有日志都是相同的、我们可以告诉 DM 固件可能不会卡在某处或出现错误日志。  

DM 固件是否可能在 ATF 故障情况下无法运行？ 这是您想要检查的吗？ (DM 固件是否运行)

BR、丰富    

Eric Ding 说：

请确认获取 WKUP_UART0 DM 日志控制台的意图是判断 DM 固件是否运行？  [报价]

有。

Eric Ding 说：

在 ATF 失败的情况下 DM 固件是否可能无法运行？ 这是您想要检查的吗？ (DM 固件运行或未运行)[/QUOT]

是的、完全正确。 我想查看 DM 固件在 ATF 故障情况下是否已启动并运行。

[/quote]

Prashant：

抱歉、DM FW SDK 在哪里？

Dm 是 M4F？

BR Rio

PLZ 忽略我的上一篇文章。

根据此 pic、客户是否已传递 DMSC 负载？ 请参阅客户日志的第一个帖子。

xing fang 说：

根据此 pic、客户已通过 DMSC 加载？ 请参阅客户日志的第一个帖子。

这仅意味着 DM 固件已正确加载、但不一定意味着它在 R5 SPL 之后成功运行。

客户需要确认是否在引导故障案例中看到 DM 固件日志。

Prashant,  

客户在 UART0 (A53)和 WKUP_UART0 (DM)上的调试日志上添加时间戳、并确认在发生 ATF 故障时未打印 DM 固件日志。  

这意味着 DM 固件可能无法完全加载或无法完全运行。

此处附加了调试日志。  

e2e.ti.com/.../console_2D00_rel.txte2e.ti.com/.../uart0_2D00_rel.txt

DM 固件可能无法 打印的可能性是什么？

如何进行进一步调试？  

是否会提供调试版 DM 固件？  

BR、丰富  

假设他们仅使用预构建固件、您能否让客户下载以下 DM 固件

dm_firmwares.zip

他们是否也会看到此 ZIP 中提供的 DM 固件的问题？

Prashant,  

这与您之前在本主题中提供的 DM_firmwares.zip 是否相同？

如果答案是肯定的、则此 DM 固件上的问题仍然存在、客户已尝试过此固件、结果与预编译固件相同。  

BR、丰富

您好！

Eric Ding 说：

这是否与您之前在本主题中提供的 DM_firmwares.zip 相同？

有。 为调试和发布配置文件构建了两个 DM 固件。

他们是否看到两个 DM 固件的问题？

如果需要、您能否让他们使用 CCS 加载符号以识别 DM 卡住的位置？

程序如下：

• 连接到 WKUP R5F 内核。
• 加载符号： Run -> Load -> Load Symbols... ->浏览-> DM 固件可执行文件的路径。

此致、

Prashant

Prashant,  

是的、我们看到两个 DM 固件都存在问题。  

并且客户构建了 Debug 和 Release 版本、并看到相同的结果。  

您更喜欢检查哪种 DM 固件版本？ 您提供的新版本？ 构建版本？

BR、丰富   

Eric Ding 说：

您更喜欢查看哪个 DM 固件版本？ 您提供的新版本？ 构建版本？[/QUOT]

请随调试一提供结果。