[参考译文] AM6442：eMMC 引导满足复位问题

尊敬的 Kevin：

DFU 刷写 eMMC 后、您是热复位还是对电路板进行下电上电？ 对电路板进行下电上电后、eMMC 引导问题是否仍然出现？

该电路板是否具有 JTAG 连接以便可以使用 CCS 检查寄存器？

您好、Bin、

DFU 刷写 eMMC 后、客户已尝试多次对电路板进行下电上电、但仍会在以下位置触发。

打印"重置"后、将不会继续。 我可以知道这可能是什么原因吗？

非常感谢、

Kevin

您好、Bin、

此外、此时电路板卡住时、客户已尝试连接到 CCS VIS JTAG、但 JTAG 无法连接。

Kevin

尊敬的 Kevin：

打印"重置"后、将不继续。 我可以知道这个原因是什么吗？

这是我第一次听到这样的问题,不知道什么可能导致问题。

此外、当它卡滞时、客户尝试连接至 CCS VIS JTAG、但无法连接 JTAG。

什么是连接故障？ 请注意、在此阶段、A53_0尚未运行、您无法连接到 A53_0、但应能够连接到 DAP 内核。

您好、Bin、

谢谢、客户明天会尝试连接到 DAP 内核。

顺便说一下、您认为这可能是由某些硬件问题导致的吗？ 上面附有相应的原理图、该 EVM 应该与 EVM 相同。

谢谢！

Kevin

尊敬的 Kevin：

顺便说一句、您认为这可能是由于某些硬件问题？

我现在还不能告诉你。

客户明天将尝试连接到 DAP 内核。

如果能够连接到 DAP、请读取寄存器0x43018178。

尊敬的 Kevin：

还请要求客户使用 SDK9.2 U-Boot 进行测试、以查看是否也发生相同的问题。

0x43018178为0x0。  

您的电路板有 PMIC 吗？ 如果是、当 U-Boot SPL 复位时、PMIC 是否会先关断电源再重新导通？

请与 SDK9.2 U-Boot 进行测试、以查看是否也发生相同的问题。

大家好！

我读出外部 CSD 并确认外部 CSD 162 RST_n_FUNCTION 被设置为1。

这不是 eMMC ext CSD 问题。 当 U-Boot SPL 热复位时、SoC 电源似乎已关闭。

您好、Bin、

   但我们的电路板使用 DCDC 和 LDO、该电源无法由 CPU 控制。

您好、Bin、

为了更清楚地说明、客户只尝试删除 Uboot 中 ErrataID i2331的权变措施代码、现在他们可以成功地热复位。

但是、 MMC 报告在内核启动后超时、无法启动 systemd、客户已提供上述相应的日志、请帮助查看。

非常感谢、

Kevin

您好、Bin、

我在 u-boot 中注释掉了权变措施勘误代码、现在电路板可以无停顿地热复位。

我不清楚根本原因是什么。 我会验证。

e2e.ti.com/.../20241101_5F00_102811.mp4

尊敬的 Wangbin：

不应删除勘误代码。 要继续找出根本原因、请

-使用勘误代码,当 SPL 触发热复位时,请探测所有电源轨,查看复位期间是否仍在有效范围内;

-使用 SDK9.2 U-boot 进行测试,查看复位环路问题是否也发生。

Kevin

但是、 MMC 报告在内核启动后超时、无法获得 systemd 启动

这应该是一个单独的问题、与热复位环路问题无关。 请帮助为 eMMC 超时问题创建一个单独的 e2e 线程、并将该线程分配给我、我将帮助您了解该问题。 在这个单线程中处理两个不相关的问题不是一个好主意。

尊敬的 Wangbin：

移除勘误码、并且您在 U-Boot 提示符下手动重置命令后、系统重新启动并再次运行 U-Boot。

此时、请在 U-Boot 提示符处停止、运行以下命令转储寄存器0x43018178并让我知道其值：

=> md.l 0x43018178 1.

您好、Bin、

感谢您的建议、我创建了一个单独的 E2E 来讨论超时问题、非常感谢！

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1432664/am6442-emmc-timeout-in-booting-kernel

Kevin

您好、Bin、

当勘误代码被移除时、热复位后、0x43018178读出0x10000。

但是、重新添加勘误代码后、软复位将再次卡住。

您好、Bin、

由于它位于客户板上并且经过了一些修改、因此客户不容易直接在 SDK9.2上测试、因此它们需要一些移植工作。

谢谢！

Kevin

尊敬的 Wangbin：

请进行以下测试。

1.对 SDK10.0应用以下 U-Boot 补丁。 它在复位前后打印 rst_src 寄存器值。

diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index 80c3cb3479f7..e539885ef9ec 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -231,6 +231,7 @@ void board_init_f(ulong dummy)
                printf("\n%s:uclass device error [%d]\n",__func__,ret);
 
        rst_src = readl(CTRLMMR_MCU_RST_SRC);
+       printf("rst_src: 0x%x\n", rst_src);
        if (rst_src == COLD_BOOT || rst_src & (SW_POR_MCU | SW_POR_MAIN)) {
                printf("Resetting on cold boot to workaround ErrataID:i2331\n");
                printf("Please resend tiboot3.bin in case of UART/DFU boot\n");

2.如果复位后寄存器值始终为"0"、请探测所有电源轨、查看复位期间是否仍在有效范围内。

由于该文件位于客户电路板上并且进行了一些修改、因此客户不容易直接在 SDK9.2上进行测试、因此需要进行一些移植工作。

3.您不必移植整个 SDK9.2。 请仅将 SYSFW 二进制文件从 SDK9.2复制到 SDK10.0、并重新编译 SDK10.0 U-Boot。 下面的显示了我完成的过程。

dev@ula:~$ cd sdk/am64x-plsdk-10074/board-support/prebuilt-images/am64xx-evm/
dev@ula:am64xx-evm$ mv ti-sysfw ti-sysfw.orig
dev@ula:am64xx-evm$ cp -r ~/sdk/am64x-plsdk-9.2.1.a/board-support/prebuilt-images/am64xx-evm/ti-sysfw ti-sysfw.sdk92
dev@ula:am64xx-evm$ ln -s ti-sysfw.sdk92 ti-sysfw
dev@ula:am64xx-evm$ ls -ld ti-sysfw*
lrwxrwxrwx 1 lb lb   13 Nov  1 10:29 ti-sysfw -> ti-sysfw.sdk92
drwxr-xr-x 2 lb lb 4096 Aug  5 05:41 ti-sysfw.orig
drwxr-xr-x 2 lb lb 4096 Nov  1 10:20 ti-sysfw.sdk92
dev@ula:am64xx-evm$ cd ../..
dev@ula:board-support$ rm -rf u-boot-build/
dev@ula:board-support$ cd ..
dev@ula:am64x-plsdk-10074$ make u-boot

尊敬的 Bin & Kevin：

    我按照您的建议操作、但在 tiboot3期间热复位仍然卡住。

我使用9.02 sysfw 进行测试、结果是相同的。

它只是输出 rst_src：0、因为它卡在这里。

我用示波器测量 RESETSTATz 信号。

在勘误处理 DO_RESET 代码期间、无法触发此热复位信号。

但是、如果移除代码并在 A53 u-boot 中发出复位命令、则可以触发 RESETSTATz 信号。

因此、 rst_src 保持0的原因不是功率下降、而是 CPU 不执行热复位。

可以将 围绕热复位代码的勘误表工作从 R5 tiboot3中移到 A53 u-boot 中？

尊敬的 Wangbin：

它只是打印出 rst_src：0、因为它卡在那里。

这是奇怪的。 我在具有 SDK10.0 u-boot 的 AM64x EVM 测试中看到0x10000。 编译 U-Boot 时是否修改了 U-Boot defconfig？

可以将 围绕热复位代码的勘误表从 R5 tiboot3中移到 A53 u-boot？

如果删除了此勘误表权变措施、当您以后要在 Linux 中使用以太网时、系统可能会锁定。

您可以尝试用以下行替换 U-Boot 中的 DO_RESET 代码吗？

writel (6、CTRLMMR_MCU_RST_CTRL)；

有。 我修改了 defconfig、并对源代码进行了一点修改。

EVM 与我们客户电路板之间的主要区别是：

1) DDR：我们使用512MB DDR4、DDR 目前在该 AM6442项目中可以正常运行。

2) 2)无 EEPROM。 我们删除了 EEPROM 芯片。 但 EVM 具有用于表示电路板 ID 的 EEPROM。 因此我删除了 uboot 中的一些代码。

3) EMMC：我们使用4GB MX52LM04A11XSI 、它与 eMMC 5.1兼容。 但它具有默认的4MB 引导分区。 因此、我更改了 defconfig 和 MMC DFU 地址以重新定义 tiboot3、spl、uboot 分区偏移量和大小。

您好、Bin、

writel (6、CTRLMMR_MCU_RST_CTRL)；

这也不起作用。

您好、Bin、

客户只是尝试了一个有用的实验。 他们将相同的 tiboot3.bin 文件放在开发板上的 EVM 板上、并发现此 tiboot3.bin 文件可以在 EVM 上的 Uboot 中正常引导。 因此、我们怀疑这可能是由硬件差异造成的。 对于需要热复位正常工作的外设、是否有任何特定要求？

例如、EVM 上有一个 I2C 的 GPIO 扩展器芯片、eMMC 复位具有与 GPIO 扩展器具有与门关系的逻辑器件。 客户电路板没有此器件。 K3和 ROM 是否会读取/写入 I2C 的 GPIO 扩展器？

谢谢！

Kevin

尊敬的 Wengbin：

是的。 我修改了 defconfig、并对源代码进行了少量修改。

请附上修改的补丁。

writel (6、CTRLMMR_MCU_RST_CTRL)；

这也不起作用。

复位后、您是说 tiboot3.bin 仍然会打印 rst_src 寄存器仍为"0"吗？

请在您的所有描述中描述 rst_src 寄存器值。 "不起作用"或"卡住"之类的东西并不能真正帮助我理解这种行为。

Kevin

因此、我们怀疑这可能是硬件差异造成的。 对于需要热复位正常工作的外设是否有任何特定要求？[/QUOT]

我还不知道。 tiboot3.bin 中的热复位全部与 AM64x 器件有关、除了电源轨外、不应依赖任何其他外部组件。 (顺便说一下、我要求客户在热复位期间探测所有电源轨、以确保它们处于有效电压范围内、但客户没有清楚地回答这个问题。)

请向我发送电子邮件、告诉我定制电路板原理图、我想确认一下是否能提供任何提示。

[报价 userid="546457" url="~/support/processors-group/processors/f/processors-forum/1432304/am6442-emmc-boot-meet-resetting-problem/5494974 #54974"]但是、如果他们删除了勘误表权变措施代码并在输入 A53后使用 reset 命令、则该操作将不再卡滞。 因此、客户想知道他们是否可以这样做(在输入 A53后使用 reset 命令)？[/QUOT]

是的、只要在 U-Boot 中未使用以太网并且在 U-Boot 器件中禁用了 CPSW、在 A53 U-Boot 中执行复位是可以的、它只会在引导时间中增加几秒钟。

尊敬的 Kevin：

启用勘误权变措施代码后、客户测量了示波器、他们发现 RESETSTATz 上有热复位信号、这意味着它在接收到热复位信号之后卡滞。 但是、如果他们删除了勘误表权变措施代码、并在输入 A53后使用 RESET 命令、则它不会再次卡住。 因此、客户想知道他们是否可以这样做(在进入 A53后使用 RESET 命令)？

如果没有、我们可能需要弄清热复位为什么会卡住、是否有任何要求外设一起工作？

我再次阅读了您的消息、与原始报告相比、行为现在有了变化？

现在您说存在 RESETSTATz 信号、但 Wangbin 前面说、在 tiboot3.bin 中复位 i2331后不会触发该信号。

现在、tiboot3.bin 中的 i2331复位后似乎 ROM 卡住了、但最初的问题是 ROM 和 tiboot3.bin 之间的无限循环。

我的理解是否正确？ 导致这种不同行为的原因是什么？

尊敬的 Bin&Kevin：

     今天我要把原理图和 uboot 补丁邮寄给 Kevin。 凯文,请你把我交给斌。

下面我总结一下：

1) 1)它会在 tiboot3勘误表中卡住、处理定制电路板上的热复位问题。 由于它卡住、 CTRLMMR_MCU_RST_SRC 值仅打印一次0x0。

2) 2)我测量了 RESETSTATz 热复位信号。 它具有低电平有效脉冲、与 EVM 相同。

3) 3) JTAG 显示在 K3代理发送复位请求之后、R5 CPU PC 跳转至0x418019F0。 CPU 似乎在 0x418019F0处循环。 0x43018178读取0x0。

4) 4)如果直接在 EVM 上运行相同的 BINAY、则不会卡住。 热复位正常。

5) 5)删除  勘误内容处理热复位代码并在我们的定制电路板上运行、 在 A53 u-boot 中发出复位命令后即可正常工作。 CPU 可以成功进行热复位、然后获取 CTRLMMR_MCU_RST_SRC 值 打印0x10000。

Wangbin

Kevin 在上周发表的第一篇文章中、问题在于 tiboot3复位以无限循环方式运行、不是转到 tispl.bin。 但是、您现在说 tiboot3复位会导致它卡在 ROM 中。 这是两种完全不同的行为。 您是否进行了导致行为发生变化的任何更改？ 是否进行了任何软件更改、硬件更改或电路板不同？

您好、Bin、

     抱歉、Kevin 的第一篇文章中的问题描述可能不是很准确。

此图显示了 由手动冷复位引起的几个重复日志。 由于 CPU 在显示"Reseting..."后卡住、因此我执行冷复位。

实际上、它卡在 ROM 中。

您好、Bin、

    我将围绕热复位代码的勘误表移至 A53 u-boot、并且可以正常工作。

它可以成功进行热复位。

但我不清楚为什么 SPL 无法热复位。

哇、我完全误解了问题...

好的,谢谢澄清。

使用 DFU 刷写 eMMC 时、由于 i2331复位、您必须传输 tiboot3.bin 两次、而这种复位在 DFU 引导中可以正常工作。

因此、该问题似乎与 eMMC 重置有关。

请使用示波器在 eMMC 引导和 DFU 引导中捕获靠近 eMMC 器件的 RESETSTATz 信号、以查看波形是否相似？

您好、Bin、

有。 对于 DFU、、EVM 和定制电路板都需要传输两次 tiboot3、此复位很有效。

我 昨天 在正常的 eMMC 引导模式而不是 DFU 模式下测量了 RESETSTATz 信号。 客户电路板和 EVM 上的热复位脉冲时序几乎相同。

但 EMMC 芯片并不相同。

我稍后检查数据表上的复位时序。  

尊敬的 Wangbin：

我在 AM64x EVM 上的 RESETSTATz 信号上没有看到任何电阻器、因此您也可以尝试移除 RESETSTATz 线路上的 R513、看看它是否有任何区别。

嗨、Bin、

我已移除 R513。 没有帮助。

DS 显示 tRSCA 需要200us、 在使用参数0xFFFFFFFA 发出 CMD1或 CMD0之前、需要74个周期的时钟信号。

我不知道 ROM 代码或硬件是否可以满足此要求。

但在 A53 uboot 中、热复位可成功工作。 热复位引导是否有区别？

您能否在 tiboot3和 u-boot 中测量 RESETSTATz 以查看是否有任何差异？

是的、我稍后再进行测量。

嗨、Bin、

我已经测量了信号波形。 并且存在差异。

此波形是 A53 u-boot 调用的热复位波形。 可以成功地对其进行热复位。

一旦 RESETSTATz 置为有效、它会遵循大量突发时钟。

以下波形是针对 tiboot3中热复位的勘误操作。 冷复位后有突发时钟、但热复位后无突发时钟。

它会卡在 ROM 上。

尊敬的 Wangbin：

您能不能调节波形的刻度？ 我真的无法在两个捕获中详细说明 RESETSTATz 信号。

顺便说一下、我们的硬件专家已经就您的电路板设计中与复位相关的内容向 Kevin 提供了注释。 您是否根据评论修改了电路板？ 这些波形是在修改之后捕获的、还是不修改之后捕获的？

第二个波形似乎显示 eMMC 器件没有复位。 因此、请放大 RESETSTATz 信号、看看它在两种情况下是否有任何差异、以及其信号质量是否符合 AM64x 数据表中的要求。

您好、Bin、

我将让客户调整波形的标度。

至于硬件修改、请参阅我最新的电子邮件回复、客户已尝试修改所有这些、但结果是相同的、可能我们需要检查是否还有其他需要修改的内容。

非常感谢、

Kevin

感谢 Kevin 为客户提供的支持。 现在的问题更多的是与硬件设计相关。 获得清晰的波形后、我会将此问题交给我们的硬件专家来提供支持、因为我只支持软件。

您好、Bin、

我已经根据 Kevin 的反馈更改了硬件。 但它没有帮助。

我忘记了  是否在修改后捕获了波形。 我想我稍后可以再次捕获它。

以下是昨天的 RESTATz 波形。

复位脉冲宽度约为172us。 在 tiboot3和 A53热复位时、其宽度相同。

对于 tiboot3热复位、我无法在波形中看到 clk 频繁开关。 但在 A53 WAM 复位或冷复位时会有突发时钟切换。 ROM 热复位行为似乎不一致。

我注意到 MXIC eMMC 数据表中有 thers 的复位时序。 在发出 cmd 之前需要200us 74clks。 我已经在上一篇文章中发布了计时。

因此、我不确定 eMMC 复位是否成功、但复位脉冲宽度是否可以满足要求。

尊敬的 Wangbin：

现在波形放大的似乎太多、我没有看到 RESETSTATz 信号切换以显示复位。

无论如何、这超出了我的支持范围、我会将您的查询路由给我们的硬件专家。 我在这里总结这个问题、这样他就不必学习整个线程。

这是关于 eMMC 引导/复位问题。 当自定义 AM64x 电路板上电时、由于 i2331、在第二个引导加载程序(R5 SPL)热复位开始时、似乎出现了 ROM 卡住、因为 eMMC 器件未正确复位、ROM 无法读取第二个引导加载程序。

但是、如果将第二个引导加载程序修改为在引导 Linux 内核之前将 warmreset 断言从 R5 SPL 级移至末尾(A53 U-Boot)、则 eMMC 器件将正确复位、引导过程正常。

尊敬的 Sreenivasa / Bin：

请帮助查看我的电子邮件中 EMMC 复位器件的硬件原理图、并查看是否需要进行任何修改、谢谢！

客户还提到 EMMC 客户使用了74个时钟要求、如果我们的 ROM 可以支持、您还能帮忙吗？因为客户怀疑这是否也与问题有某种关系。

非常感谢、

Kevin

尊敬的 Kevin：

我向 ROM 团队咨询过、为 eMMC 器件设置的唯一 eMMC 命令是 CMD0、它使用0xFFFFFFFA 读取 tiboot3.bin 映像、因此您在 JEDEC 标准中提到的要求不适用。

请要求客户执行测试、移除 R513以使 eMMC RSTN 引脚与 AM64x RESETSTATz 引脚断开连接、并移除 U-Boot SPL 中的 DO_RESET ()。 电路板上电并引导至 U-Boot 提示符后、请执行"reset"命令以触发 warmreset、然后查看 warmreset 是否仍然卡在 ROM 中、或者是否可以从 eMMC 引导 U-boot。

您好、Bin、

我已经再次捕获了波形。 成功的热重置和切换的热重置没有明显的区别。

CH1 (黄色)是 RESETSTATz

CH2 (蓝色)为 MMC_CLK

CH3 (粉色)为 MMC_CMD

成功的热复位波形：

残留的热复位波形：

您好、Bin、  

 移除 R513后、在键入 RESET 命令后、热复位将卡在 A53 u-boot 中。

 第215.

谢谢你。

R513将热复位输出状态输出 RESETSTATz 连接到 eMMC 复位。

我希望将该引脚连接到 eMMC 复位输入、以执行冷复位或热复位。

此致、

Sreenivasa

移除 R513只是一个测试。 这种情况不太可能发生、但想知道工作案例中的 eMMC 复位是否与 RESETSTATz 信号有关。

Wangbin

您能否应用下面的 U-Boot 补丁以查看是否修复热复位卡滞问题？ 它将 warmreset 断言从 tiboot3移至 tispl (仍早于 U-Boot)。

diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index 80c3cb3479f7..1cf52d2f272a 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -167,10 +167,10 @@ static void enable_mcu_esm_reset(void)
 void board_init_f(ulong dummy)
 {
 #if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM64_DDRSS) || defined(CONFIG_ESM_K3)
+#endif
        struct udevice *dev;
        int ret;
        int rst_src;
-#endif
 
 #if defined(CONFIG_CPU_V7R)
        setup_k3_mpu_regions();
@@ -212,7 +212,7 @@ void board_init_f(ulong dummy)
                        k3_mmc_restart_clock);
 #endif
 
-#if defined(CONFIG_CPU_V7R)
+#if !defined(CONFIG_CPU_V7R)
        /*
         * Errata ID i2331 CPSW: A device lockup can occur during the second
         * read of any CPSW subsystem register after any MAIN domain power on