[参考译文] AM623：SDK 中不提供复位原因

您好、Leonardo、

对此处延迟的回复表示歉意。 我将在星期四上留出一些时间来研究这一点。

此致、

Nick

您好、Nick。 没问题！ 此外、如果您能为我提供一个已启用此功能的 Processor Linux SDK (RT) 映像、以便我可以使用开发套件进行测试、我将不胜感激。

您好、Leonardo、

看门狗驱动程序 代码  

我假设您参考的是 RTI_WDT_PROBE 函数的这一部分：

        node = of_parse_phandle(pdev->dev.of_node, "memory-region", 0);
        if (node) {
...
                /*
                 * If reserved memory is defined for watchdog reset cause.
                 * Readout the Power-on(PON) reason and pass to bootstatus.
                 */
                paddr = res.start;
                reserved_mem_size = resource_size(&res);
...
                vaddr = memremap(paddr, reserved_mem_size, MEMREMAP_WB);
                if (!vaddr) {
                        dev_err(dev, "Failed to map memory-region.\n");
                        ret = -ENOMEM;
                        goto err_iomap;
                }

                if (vaddr[0] == PON_REASON_SOF_NUM &&
                    vaddr[1] == PON_REASON_MAGIC_NUM &&
                    vaddr[2] == PON_REASON_EOF_NUM) {
                        wdd->bootstatus |= WDIOF_CARDRESET;
                }
                memset(vaddr, 0, reserved_mem_size);
                memunmap(vaddr);

和绑定文档中定义的存储器区域：
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml?h=ti-linux-6.12.y#n37

南... 这将需要一点时间进行研究。 一目了然、我实际上没有看到 DDR 中这种任意内存分配的效果。

首先、在探测函数中、我们可以看到驱动程序仅查找 12 个特定字节、这些字节应该指示看门狗复位。 如果存储器区域中有任何其他值、则不会更新 BOOTSTATUS。 因此、它只能判断是否发生了看门狗复位、而不是任何其他复位源。

但其他一些驱动程序代码需要知道、用户分配了该特定的 DDR 区域以保存复位值、然后在看门狗复位事件期间将 12 个魔术字节写入 DDR 区域。 我没有看到内存区域在任何地方使用、因此我不知道这 12 个字节最初是如何写入 DDR 的。

我可能会遗漏一些东西。 我正在与其他团队成员联系、征求他们的意见。

查看复位原因的其他选项

TRM 的这一部分是否描述了您要寻找的功能？

“复位源状态寄存器“
寄存器 CTRLMMR_MCU_RST_SRC

此致、

Nick

您好、Nick、

关于  CTRLMMR_MCU_RST_SRC 寄存器、我在一些 AM62x 文档中阅读了该寄存器、但我无法清除其配置。 您能解释一下如何在自定义 u-boot 和内核环境中配置它来指示看门狗复位吗？

您好、Leonardo、

我将首先发布相关寄存器的屏幕截图、因为在 TRM 中的不同位置、这些寄存器具有不同的名称、并且不容易找到。 我已经针对 TRM 提交了一个错误、看看是否有办法改进此结构。

您好、Leonardo、

无需配置寄存器即可使寄存器记录重新启动原因。 但是、每次发生热复位时、新的复位源都会添加到寄存器中（而不是擦除之前的复位原因，然后将新的复位原因放入寄存器中）。 因此、建议在读取寄存器后手动将其清零。

测试 1：2 个寄存器中的位是否匹配？

是的

测试 2：这些位是否在热复位后更新？ 第二次热复位后会发生什么情况？

是、这些位在热复位后更新。 如果有第二次热复位、则第二个复位源只需添加到前一个复位源（即，寄存器不会“清除“，然后每次热复位重新设置）。

root@am62xx-evm:~# uname -a
Linux am62xx-evm 6.6.58-rt45-ti-rt-01780-gc79d7ef3a56f-dirty #1 SMP PREEMPT_RT Wed Nov 27 14:15:26 UTC 2024 aarch64 GNU/Linux

// Let's check the register value after a cold boot (should be 0)
root@am62xx-evm:~# devmem2 0x4518178
/dev/mem opened.
Memory mapped at address 0xffffa1fe9000.
Read at address  0x04518178 (0xffffa1fe9178): 0x00000000

// now let's do a software reboot and see what happens
root@am62xx-evm:~# reboot
...
root@am62xx-evm:~# devmem2 0x4518178
/dev/mem opened.
Memory mapped at address 0xffffa3b2c000.
Read at address  0x04518178 (0xffffa3b2c178): 0x00010000
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffffb0bf1000.
Read at address  0x43018178 (0xffffb0bf1178): 0x00010000

// now let's do a watchdog reset
root@am62xx-evm:~# echo 1 > /dev/watchdog
[  482.720093] watchdog: watchdog0: nowayout prevents watchdog being stopped!
[  482.720138] watchdog: watchdog0: watchdog did not stop!
root@am62xx-evm:~#
U-Boot SPL 2024.04-ti-g29d0c23d67ee (Nov 29 2024 - 11:41:54 +0000)
...
root@am62xx-evm:~# devmem2 0x4518178
/dev/mem opened.
Memory mapped at address 0xffffad4c5000.
Read at address  0x04518178 (0xffffad4c5178): 0xC0010000
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffff82422000.
Read at address  0x43018178 (0xffff82422178): 0xC0010000

测试 3：我们可以 在运行时清除这些位吗？  

是的。 TRM 寄存器定义 告诉我们这一点

CTRLMMR_RST_SRC 为只读、而
如果您向该位写入 1、CTRLMMR_MCU_RST_SRC 将清除一个位。

我们可以在这里看到：

// writing to CTRLMMR_RST_SRC does not change the bits
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffff9fe7d000.
Read at address  0x43018178 (0xffff9fe7d178): 0xC0010000
root@am62xx-evm:~# devmem2 0x43018178 w 0x00000000
/dev/mem opened.
Memory mapped at address 0xffff8cb4b000.
Read at address  0x43018178 (0xffff8cb4b178): 0xC0010000
Write at address 0x43018178 (0xffff8cb4b178): 0x00000000, readback 0x00000000
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffffa0ac5000.
Read at address  0x43018178 (0xffffa0ac5178): 0xC0010000
root@am62xx-evm:~# devmem2 0x43018178 w 0xFFFFFFFF
/dev/mem opened.
Memory mapped at address 0xffffab81a000.
Read at address  0x43018178 (0xffffab81a178): 0xC0010000
Write at address 0x43018178 (0xffffab81a178): 0xFFFFFFFF, readback 0xFFFFFFFF
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffffabb8b000.
Read at address  0x43018178 (0xffffabb8b178): 0xC0010000

// writing 1s to CTRLMMR_MCU_RST_SRC will clear the bits
root@am62xx-evm:~# devmem2 0x4518178
/dev/mem opened.
Memory mapped at address 0xffff81fdb000.
Read at address  0x04518178 (0xffff81fdb178): 0xC0010000
root@am62xx-evm:~# devmem2 0x4518178 w 0xFFFFFFFF
/dev/mem opened.
Memory mapped at address 0xffffb356a000.
Read at address  0x04518178 (0xffffb356a178): 0xC0010000
Write at address 0x04518178 (0xffffb356a178): 0xFFFFFFFF, readback 0xFFFFFFFF
root@am62xx-evm:~# devmem2 0x4518178
/dev/mem opened.
Memory mapped at address 0xffff8e00f000.
Read at address  0x04518178 (0xffff8e00f178): 0x00000000
root@am62xx-evm:~# devmem2 0x43018178
/dev/mem opened.
Memory mapped at address 0xffffafeb0000.
Read at address  0x43018178 (0xffffafeb0178): 0x00000000

此致、

Nick

下面是一些您可能感兴趣的其他信息：

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1507829/am62a7-q1-is-the-am62a-sdk-set-up-to-use-the-power-on-memory-region-referenced-in-the-watchdog-driver/5827256#5827256 

您好、Nick、

感谢您的研究。 我可以在开发套件中重现这种行为。 我还在基于 AM623 处理器的定制电路板中对其进行了测试、并且 即使在软件复位和看门狗复位后、0x4518178 寄存器也保持不变。 该主板运行 u-boot 版本 2023.10 和 Linux 内核版本 6.1.69-rt21。 可能存在未正确设置的配置或驱动程序？

此致

您好、Leonardo、

您能给我说明一下“ 即使在软件复位和看门狗复位后、0x4518178 寄存器也保持不变“的意思吗？

此致、

Nick

您好、Nick

对不起,如果我不清楚。 我的意思是、位于地址 0x04518178 的 MCU_MMR0_RST_SRC 寄存器在执行与您相同的测试（软件复位和看门狗复位）时不会更新其值、但在具有上述固件的定制电路板中更新。

此致

您好、Leonardo、

如果你可以告诉我你运行的确切测试,以及读取地址时的确切终端输出,这比口头描述更有帮助。 我已经看到很多这些问题持续了几个星期比他们应该有的更长,因为 有人 不只是分享终端输出。

显然无需显示整个引导日志、但请至少共享您的终端输入、并且特定寄存器在前后读取和写入。

谢谢、

Nick

您好、Nick

当然。 我测试的唯一区别是我使用 devmem 运行它,而不是 devmem2。 但它们的行为应该完全相同。 这些测试如下所示：

// After a cold boot:
device:~# uname -a
Linux device 6.1.69-rt21 #3 SMP PREEMPT_RT Tue May 20 08:56:29 -03 2025 aarch64 GNU/Linux

device:~# devmem 0x4518178
0x00000000

device:~# reboot
...

// After a warm reset:
device:~# devmem 0x4518178
0x00000000

device:~# devmem 0x43018178
0x00000000

device:~# echo 1 > /dev/watchdog
device:~# [   53.989131] watchdog: watchdog0: watchdog did not stop!

U-Boot SPL 2023.101.0.2.0 (May 13 2025 - 07:55:00 -0300)
...

// After a watchdog reset:
device:~# devmem 0x4518178
0x00000000

device:~# devmem 0x43018178
0x00000000

此致

您好、Nick

再次回复、只是要知道您是否在这种情况下取得了任何进展

此致

您好 Leanardo

我们对迟迟未能对此作出反应感到遗憾。 Nick 本周正在进行国际旅行、下周将回到办公室。  

我们可能会在回复中看到一些额外的延迟、但我们会优先考虑下周初回复您。

此致

Mukul  

您好、Mukul

好的、没问题。 我将等待下一个答复。 谢谢你。

此致、

Leonardo

您好 Leanardo、
当 Nick 不在办公室时、我要补充一下我的意见。
我将在 AM62-SK 电路板上附加我之前使用 Linux SDK 8.6 捕获的示例日志。
我们是否可以在您的电路板上运行类似的测试@u-boot？
1/。 CMDS @u-boot、用于触发 RTI_WDT RTI0 以进行计数（~1s 超时）
=> mw.l 0xe0000a4 0xA 1
=> mw.l 0xe000090 0xA98559DA 1
2/。 主域和 MCU 域的 RST_CTRL/RST_STAT/RST_SRC 上的 CTRLMMR 寄存器被捕获在附加的日志=>中、其中显示“RTI_WDT TIMEOUT => MCU ESM ERROR => WarmReset“工作@u-boot 级别。

此致、
- Hong

e2e.ti.com/.../am62_5F00_8.6_5F00_rti_5F00_wdt_5F00_1s_5F00_FS.log

您好 Leanardo、

WDT SOC 复位可通过 ESM 模块来完成。

如果是通过 ESM 进行复位、则将在 MCU_ESM_err_rst 或 MAIN_ESM_err_rst 中指示该复位。

如果您控制主域 ESM 位 来重置 SOC、则监视主 ESM 错误位（第 30 位位置）、如果您控制 MCU 域 ESM 位 来重置 SOC、则监视 MCU MMR 错误位（第 31 位位置） 。

此致、

Anil.

Hong Hong：

我将在运行  Processor SDK Linux RT 版本 11.00.09.04（首次附加）的开发套件和运行 U-boot 2023.10 和 Linux 内核 6.1.69 RT 21（上次附加）的定制电路板中附加日志捕获

U-Boot SPL 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
Changed A53 CPU frequency to 1250000000Hz (T grade) in DT
SPL initial stack usage: 13424 bytes
Trying to boot from MMC2
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.12.0(release):11.00.08-1-gb11beb2b6-dirty
NOTICE:  BL31: Built : 12:35:58, Mar 24 2025

U-Boot SPL 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
SPL initial stack usage: 1952 bytes
Trying to boot from MMC2
Skipping authentication on GP device
Skipping authentication on GP device


U-Boot 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)

SoC:   AM62X SR1.0 GP
Model: Texas Instruments AM625 SK
DRAM:  2 GiB
Core:  83 devices, 32 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@8000000port@1

Hit any key to stop autoboot:  0
=> md.l 0x43018170 3
43018170: 000200ff 00000000 00000000           ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 00000000           ..@.........
=> mw.l 0xe0000a4 0xa 1
=> mw.l 0xe000090 0xA98559DA 1
=>
U-Boot SPL 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
Changed A53 CPU frequency to 1250000000Hz (T grade) in DT
SPL initial stack usage: 13424 bytes
Trying to boot from MMC2
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Skipping authentication on GP device
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.12.0(release):11.00.08-1-gb11beb2b6-dirty
NOTICE:  BL31: Built : 12:35:58, Mar 24 2025

U-Boot SPL 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
SPL initial stack usage: 1952 bytes
Trying to boot from MMC2
Skipping authentication on GP device
Skipping authentication on GP device


U-Boot 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)

SoC:   AM62X SR1.0 GP
Model: Texas Instruments AM625 SK
DRAM:  2 GiB
Core:  83 devices, 32 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@8000000port@1

Hit any key to stop autoboot:  0
=> md.l 0x43018170 3
43018170: 000200ff 00000000 c0000000           ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 c0000000           ..@.........
=>

U-Boot SPL 2023.101.0.2.0 (May 13 2025 - 07:55:00 -0300)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 1792 bytes
Trying to boot from MMC1
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted


U-Boot 2023.101.0.2.0 (May 13 2025 - 07:55:00 -0300)

SoC:   AM62X SR1.0 GP
Model: XF325
DRAM:  2 GiB
Core:  78 devices, 24 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from MMC... OK
In:    serial@2830000
Out:   serial@2830000
Err:   serial@2830000
Net:   eth0: ethernet@8000000port@1, eth1: ethernet@8000000port@2
Hit any key to stop autoboot:  0
=> md.l 0x43018170 3
43018170: 000200ff 00000000 00000000           ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 00000000           ..@.........
=> mw.l 0xe0000a4 0xa 1
=> mw.l 0xe000090 0xA98559DA 1
=>
U-Boot SPL 2023.101.0.2.0 (May 13 2025 - 07:55:00 -0300)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 1792 bytes
Trying to boot from MMC1
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted
Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted


U-Boot 2023.101.0.2.0 (May 13 2025 - 07:55:00 -0300)

SoC:   AM62X SR1.0 GP
Model: XF325
DRAM:  2 GiB
Core:  78 devices, 24 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from MMC... OK
In:    serial@2830000
Out:   serial@2830000
Err:   serial@2830000
Net:   eth0: ethernet@8000000port@1, eth1: ethernet@8000000port@2
Hit any key to stop autoboot:  0
=> md.l 0x43018170 3
43018170: 000200ff 00000000 00000000           ............
=> md.l 0x04518170 3
04518170: 00400fff 00000001 00000000           ..@.........
=>

如果您能帮助我 解释这些寄存器值以及可能出现的错误、我很感激。

此致、

Leonardo

您好、Swargam、

为了使 ESM 模块路由到 RTI_WDT、我是否必须在定制电路板中执行任何特定的配置？ 因为我已经监控了寄存器的位、并且看不到任何有关 ESM 已触发的指示。 也许应该调整一些 U-boot 配置或设备树？

此致、

Leonardo

您好、Leonardo、
根据电路板上的 u-boot 日志、RTI_WDT 超时 (~1s) 中的 WARMRESET、我的理解是否正确？

参考日志
=> MD.l 0x43018170 3.
43018170：000200ff 00000000 c0000000…
=> MD.l 0x04518170 3.
04518170: 00400fff 00000001 c0000000 ..@……

但是您电路板上的日志
=> MD.l 0x43018170 3.
43018170：000200ff 00000000…
=> MD.l 0x04518170 3.
04518170: 00400fff 00000001 00000000 ..@……

RST_SRC[31：30]@0x43018178 和@0x0x04518178 未以某种方式设置或清除？

这就是在 R5-SPL 中配置 ESM 的方式
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/arch/arm/mach-k3/am625_init.c?h=09.01.00.008&id=169582025adc8892ec0813f52f6d643055b3e9dc
我建议交叉检查您为电路板定制的 u-boot 移植。

此致、
- Hong

Hong Hong：

正确的是、电路板在启用看门狗后会重新启动、这表明确实发生了一些复位或中断反应。  但是、与参考用例 (0xC0000000) 不同、0x43018178 和 0x04518178 处的 RST_SRC[31：30]值保持为 0x00000000。

此外、我已确认电路板上的 R5 SPL 未 启用 CONFIG_ESM_K3。 但是、您附加的提交和代码本身提到了用于启用 ESM 模块的预期设备树节点、我的源代码中似乎缺少该节点。 此节点中应定义的内容是什么？ 是否有任何可以用作参考的文档或示例？

此致、

Leonardo

您好、Leonardo、
以下是 AM62x-SK 电路板的*defconfig 和 dts 上的 ESM 参考
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/configs/am62x_evm_r5_defconfig?h=09.01.00.008&id=25c7b65d176715d911ebb4b2029606b678d6d56a
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/arch/arm/dts/k3-am625-r5-sk.dts?h=09.01.00.008&id=3128c890f2715f5e73300d67edff2bd26865740d
此致、
- Hong

Hong Hong：

感谢您的支持。 很抱歉晚回复。 我应用了这些配置来启用 ESM 模块、但我意识到由于 tiboot3.bin 的最新编译、我的定制电路板不再引导。 显然、我的 u-boot 存储库中没有任何问题、但电路板拒绝引导、并且在加载新的 tiboot3.bin 时不会将任何内容打印到 UART 控制台。 我可以访问此二进制文件的旧版本,它可以正常工作,但不能访问其源代码。 您能指出我应该采取哪些步骤来调试这种情况吗？ 您是否可以为我提供一个已编译并应用了正确 ESM 配置的 R5F 引导加载程序 (tiboot3.bin)？

此外、我已经遵循了 本页中介绍的指南

此致、

Leonardo

您好、Leonardo、
电路板上的引导日志看起来表明您的电路板上是 AM62x GP。
请参阅此链接、了解如何对器件类型型号 (tiboot3/bin“ FS) 使用匹配的“tiboot3.bin"（“(GP)/HS-EMA/HS-SE)
https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/latest/exports/docs/linux/Foundational_Components_Migration_Guide．html
此致、
- Hong

Hong Hong：

我找到了 tiboot3.bin 的问题所在、并能够修复它以再次启动定制电路板。 但是、正如您发送给我的提交中所述、我再次使用 defconfig 和器件树中的正确配置在 u-boot 环境中执行了测试、这种操作无效。 结果与之前相同。

此致、

Leonardo

您好、Hong、

实际上、我将 SDK 11.00.09.04 用于开发套件上运行的测试、但 ESM 模块无法正常工作的定制电路板使用自定义固件。 所使用的引导加载程序为 ti-u-boot-2023.10、内核为 Linux 6.1.69、固件映像是使用 buildroot-2023.08 构建的。 引导加载程序和内核是从 TI 开源 Git 存储库下载的。

此致、

Leonardo

您好、Leonardo、
是否可以从 Linux SDK 而不是 buildroot 构建 u-boot、并在硬件上运行它？
此致、
- Hong