[参考译文] AM625：软件看门狗在 HS-SE 器件上无法正常工作

admin

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1581574/am625-software-watchdog-not-working-on-hs-se-devices

器件型号： AM625

尊敬的 TI 支持团队：

我们遇到了一个问题。

客户想要使用看门狗。只要 SoC 是 HS-AM625、这种方法 FS 就可以正常工作。

当系统是安全 (HS-SE) 器件时、看门狗不再触发复位。

我们使用以下命令触发复位：

root@am62x-var-som：~# echo 0 >/dev/watchdog
[37.915089] 看门狗：watchdog0：nowayout 阻止看门狗停止！
[37.922007] watchdog0: watchdog没有停止！
root@am62x-var-som：~#

（33 秒后（计算我头部的秒数）)
U-Boot SPL 2025.01-g0a9e882bb85f (2025 年 10 月 6 日 — 10：36：20 +0000)

我们在 U-Boot 邮件列表中找到了一个补丁。补丁工作正常、让看门狗复位机器：

https://lists.denx.de/pipermail/u-boot/2025-August/596717.html

然而、该补丁会引发一些问题：它会恢复看门狗功能、但它会使对某些寄存器的访问保持打开状态、而这些寄存器可能不应该处于打开状态。

您能评论一下这个补丁吗？

最佳情况：您能否在下一个版本中提供修复？

我们目前仍在 11.00.09.04 版本中、但我在的发行说明中未看到此问题的修复

https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/11_01_05_03/exports/docs/devices/AM62X/linux/Release_Specific_Release_Notes．html

感谢您的支持。

Matthias

4 个月前

0 admin 4 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Matthias、

让我和我的一些团队成员一起询问。如果星期一未回复、请 ping 通该线程。

此致、

Nick

0 admin 4 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Nick、

这是星期一;-)

Matthias

0 admin 4 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Matthias、

感谢您的 ping。

修补程序看起来像一个很好的解决方法、但我怀疑它不能解决行为的实际来源。

从查看 am625_init.c函数可以看出 board_init_f () 使用解锁所有控制 MMR Ctrl_MMR_UNLOCK () 。我在_init 文件中看不到任何显式锁定控件 MMR 的代码、因此看起来目的是在函数时仍应解锁控件 MMR board_init_f () 调用 ENABLE_MCU_ESM_RESET () 。如果您的观察结果正确、则 HS-SE 处理器会在两者之间执行不同的代码 Ctrl_MMR_UNLOCK () 和 ENABLE_MCU_ESM_RESET () 而且不同的代码会重新锁定控制 FS。我不确定 HS-SE 的这种行为是否有意。

这在中的某个时刻 Board_init_f 函数、打印语句成为可能（不确定确切位置，但我们看到 printf 语句开始弹出）。因此、您可以使用它来缩小 MMR 在哪个点被重新锁定的范围。

我不确定我们是否正在跟踪这种行为。我可以根据您的输入（尚未归档）提交错误。我无法保证我们会在 12 月的 SDK 版本之前更新代码、但您也可以向上游或 ti-u-boot 存储库提交补丁（我想？）。

此致、

Nick

0 admin 4 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Nick、

我得出了同样的结论 — 或者更具体地说，编写修补程序的人得出了同样的结论。

如果您能跟踪此信息、我将很乐意为您提供帮助。

虽然我尚未验证、但我假设此重新锁定是在 https://github.com/TexasInstruments/ti-u-boot/blob/ti-u-boot-2025.01/arch/arm/mach-k3/am62x/am625_init.c#L247 上启动外部固件时完成的

因此、我想这是为了执行某些操作而启动或触发的 ARM 可信固件。

我们还没有触及 ARM Trusted Firmware、如果它保持这种状态、我会欢迎您的到来。

0 admin 4 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Nick、

我刚刚意识到我之前的评论是不正确的：

由于配置文件中未设置 CONFIG_K3_LOAD_SYSFW、因此该器件无法负责锁定寄存器...

0 admin 4 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

我需要做一些进一步的分析。

我有一些 U-Boot 配置、这些配置稍后将允许 Linux 内核使看门狗复位系统、但不再需要再次解锁这些寄存器。

是否有明确的方法来确定这些寄存器是否仍然被锁定？

我假设如果写入访问有效、这些寄存器未锁定、但对其的早期访问会使系统崩溃。

以后的访问只需简单的工作...现在。

当我从写入解锁访问的 KICK 寄存器中读回值时、我始终读回适当的解锁数据...

上次写入这些寄存器是有效的、因此我当前配置的“问题“可能只是突然我的寄存器不再被锁定、我不知道为什么...

0 admin 4 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Mattias、

有意思。

根据 TRM、我们似乎应该能够读取 LOCKI_KICK0 寄存器的未锁定位、以便查看某个段是否已锁定：

LOCKI_KICK0 和 LOCKI_KICK1 寄存器用于此目的。需要首先写入 LOCKI_KICK0[31-1]键字段、然后写入带有确切数据值的 LOCKI_KICK1[31-0]键字段以解锁保护机制。释放后、可以写入分区“I"中“中具有写入权限的所有寄存器。只读寄存器仍为只读寄存器。当 LOCKI_KICK0[0]未锁定位设置为 1h 时、表示解锁分区“i"。“。当保护机制被锁定时（通过 LOCKI_KICK0[0]未锁定= 0h 指示）、不能写入分区“i"中“中的任何寄存器。

此致、

Nick

0 admin 4 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Nick、

我回到了无法修改寄存器的状态。

我假设我 simpy 在“此代码在 R5 处理器上执行“和“此代码在 A53 处理器上执行“之间丢失了。

这也是真实的,对于我写的以下内容:

“由于配置文件中未设置 CONFIG_K3_LOAD_SYSFW、因此此器件无法负责锁定寄存器...“

在 A53 配置中未设置 K3_LOAD_SYSFW、但在 R5 配置中进行了设置。

我仍然有以下问题。我无法可靠地检测到寄存器访问何时再次锁定。

我编写了以下测试函数：

bool MMR_is_locked（uintptr_t base、u32 分区）｛
  u32 kick0；

  /*转换基地址*/
  uintptr_t part_base = base +分区* CTRL_MMR0_partition_size；

  Kick0 = readl (PART_BASE + CTRLMMR_LOCK_KICK0)；

  return！(kick0 & 0x1)；  //只有第一位确定是否锁定
}

当我在引导过程的后期调用它时工作正常、但随后寄存器再次被锁定。

当我提前调用它,最具体的是通过调用 ctrl_mr_unlock () 来解锁寄存器访问后,系统将直接锁定。这种情况特别奇怪、因为_unlock 和_is_locked 都会访问相同的寄存器、但 is_locked 会读取它、_unlock 会直接写入它。

我现在所做的是测试锁定状态：

static __May_unused void ENABLE_MCU_ESM_RESET (void)
｛
    Bool 已锁定；
    U32 状态；

    /*在 HS-SE 器件上再次锁定寄存器访问*/
    锁定= MMR_IS_LOCKED (MCU_CTRL_MMR0_BASE、6)；
    IF（锁定）
        MMR_UNLOCK (MCU_CTRL_MMR0_BASE、6)；

    /*将 CTRLMMR_MCU_RST_CTRL：MCU_ESM_ERROR_RST_EN_Z 设置为“0"（“（低（低电平有效）*/

    STAT = readl (CTRLMMR_MCU_RST_CTRL)；

    STAT 且= RST_CTRL_ESM_ERROR_RST_EN_Z_MASK；
    writel (stat、CTRLMMR_MCU_RST_CTRL)；

    /*恢复旧设置*/
    IF（锁定）
        MMR_LOCK (MCU_CTRL_MMR0_BASE、6)；
}

我还可以在此处附加完整的补丁文件。

Nick、您已经写过关于建议使用 ti-u-boot 存储库？是否有特定的邮件列表/联系方式？

除了潜在的竞态条件外、我假设 AM62px AM62Lx 和 AM62ax 上也会存在类似的问题、我无法访问所有这些 SOM、因此、TI 将在某个时候提供解决方案非常欢迎。

0 admin 3 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Nick Saulnier

您对我上一个回答中的建议补丁有何看法？

这是否可以/应该集成到 TI 的 U-Boot 交付中？你写了关于 ti-uboot-repo 的文章、但我不知道如何联系他们...

0 admin 3 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Matthias、

对此处延迟的回复表示歉意。今天的时间不够用、让我看看提交修补程序的首选方法。

此致、

Nick

0 admin 3 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您能否评论此修补程序？

是的,请在 https://lists.denx.de/pipermail/u-boot/2025-August/596717.html 的 u-boot 邮件列表 u-boot@lists.denx.de 中发表评论和反馈

最佳案例：您能在下一个版本中提供修复吗？

下一个版本将是 12.x baseline、它随 LTS 迁移和 u-boot 版本迁移一起提供、至少迁移到 2026.01 版本。

修复程序维护后、会将其相应地反向移植到 ti-u-boot-2026.0x 版本、并将其返回到 12.0 版本。

0 admin 3 个月前

TI__Guru**** 2694635 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

好的、所以有“只是“正常的 U-Boot 邮件列表...

（我希望听起来不会太消极，这不是我的意图）...

此处已发布类似的补丁：

https://lists.denx.de/pipermail/u-boot/2025-August/596717.html

答案是更加好奇：

-解锁实际发生在哪里?

-它是否应该为未来的操作保持解锁?

原来的作者似乎没有答案和线跑干.

我也不知道锁在哪里发生。我假设这来自 TIFS 固件。

这也意味着我的补丁可能会引入比赛条件。

这也是为什么我写了关于*修复*而不是*我的修复*,因为我认为更好的事情应该上游,但为了这,我要么需要更多的时间（对此我没有资源）,或关于在这里发生的事情的额外信息。

鉴于我会将这视为 TI 软件交付中的一个错误、并且可能会影响更多 AM62xxx 变量、我希望 TI 能够提供更多主动性。

处理器（参考译文帖）

处理器（参考译文帖）(Read Only)

[参考译文] AM625：软件看门狗在 HS-SE 器件上无法正常工作