[参考译文] AM5748：系统挂起时看门狗计时器不触发

您好：

客户是否有 E2E 账户？

我将对此进行研究、并且可能在下周之前没有答案。

-Josue

Field Apps 已确认客户可以访问此主题。  

两个 AM5748 内核都在运行自己的看门狗进程、以处理不同的看门狗计时器、以防其中一个内核在运行进程/内核线程时挂起。

你能详细说明一下这句话吗？ 这是指单独的 A15 内核还是 SoC 中的另一个处理器？

能否分享正在使用的 SDK 版本？  

如何启用看门狗？

-Josue

Linux 内核中有 3 个看门狗计时器：/dev/watchdog、/dev/watchdog0、/dev/watchdog1. 不知道为什么我无法真正使用/dev/watchdog0.做任何事情 因此、我们运行以下 2 个进程：

/bin/watchdog /dev/watchdog - A15 core0
/bin/watchdog /dev/watchdog1 - A15 内核 1

我们未使用您的 SDK。 但我们确实从这个 SDK ti-processor-sdk-linux-am57xx-hs-evm-08_02_01_00 开始。

如上所述、可以启用看门狗。

Maynard Cabiente ,

您的内核基于 Linux 内核 5.10 吗？

看门狗映射到什么地址？ 其中一个不可访问、因为它是为安全目的而保留的。 因此、只有一个可用的是 TRM 中所述的 WD_TIMER2。

如何在 DTS 中进行设置？

下面是一个线程、它提供了一些实现方法的线索：

 问题：AM5728：U-boot 中启用 WDT 时出现问题 

-Josue

我们的 Linux 内核为 6.12.34。

这是看门狗器件及其身份的列表。

# ls -lt /dev/watchdog
很糟糕 1 根根 248、1 Dec 31 1969 /dev/watchdog1
很糟糕 1 根根 10,130 Dec 31 1969 /dev/watchdog
很糟糕 1 根根 248、0 Dec 31 1969 /dev/watchdog0

# cat /sys/class/watchdog/watchdog0/identity
软件看门狗
# cat /sys/class/watchdog/watchdog1/identity
OMAP 看门狗

我必须检查/dev/watchdog 是否以某种方式连接到/dev/watchdog0 上、这只是一个软件看门狗。

就内核 dts 而言、这是我发现的关于“dra74-ipu-dsp-common.dtsi"中“中包含在电路板 dts 中的看门狗条目的唯一信息。

&dsp2｛
mboxes =<&mailbox6 &mbox_dsp2_ipc3x>；
TI、timers =<&timer6>；
TI、watchdog-timers =<&timer13>；
}；

感谢链接。 我已经在 U-Boot 中配置了看门狗并正常工作。 我们的问题发生在内核中、当发出软件重新启动命令后、系统将永久挂起。

对于 AM5748 中的其他看门狗计时器、TRM 中指出、每个 MPU 内核都有一个计时器和看门狗计时器。 什么是 MPU 内核？ 是 A15 core0 和 core1 吗？ 如果是、如何访问两个看门狗计时器？

还有一个安全看门狗计时器（如您所述）。 我们确实使用 AM5748 芯片的安全启动选项。 我们是否有办法在我们的应用中使用此计时器、以便实际上有 2 个硬件看门狗计时器、而不依赖于 1 个软件看门狗计时器？

-梅纳德

Maynard Cabiente ,

安全看门狗未打开以进行修改。 我认为、安全文档只会介绍如何通过 ISW 配置旋钮修改其响应。

在 Linux 中、我没有现成的示例、这需要一些时间。

我目前没有带宽可提供帮助。 ILL 试图在下周前做出回应。

同时请参阅以下线程：  Linux/AM5718：WDTimer 在内核启动时停止 

-Josue

我们在 Linux 中设置了看门狗计时器。 除非您实际必须为 MPU 看门狗计时器做些什么、否则 Linux 中已支持看门狗计时器。

同样、我们的问题是、当 AM5748 在软件重新启动后挂起时、看门狗计时器不会复位 AM5748。 我们需要知道是否有硬件修复、或者是否需要在软件中执行某些操作、以便看门狗计时器将 RSTOUTn 引脚置为有效以使系统复位。

此致、
Maynard

遗憾的是、发出 reboot 命令后没有日志、如下所示。

#重启
【此处挂起且无输出】

在启动期间、这是与看门狗计时器相关的日志：

[1.105987] softdog: initialized. SOFT_NOBOOT=0 SOFT_MARGIN=60 秒 SOFT_MANAGE=0 (nowayout=1)
[1.114685] softdog：soft_reboot_cmd= SOFT_ACTIVE_ON_BOOT=0

[1.711364] OMAP GPIO 硬件版本 0.1
[ 1.718841] OMAP-LWDT：OMAP 看门狗计时器修订版 0x01：初始超时 60 秒

-梅纳德

这不是要去的很多

从我能够收集的可能原因是一个“深度“内核恐慌,因为可能的未处理的内存故障,可能会扰乱 WD。  

您是否尝试在命令行参数中增加了详细程度 (verbosity=7)？ 可能会产生一些有用的内核消息  

有些人建议添加“ panic=60“添加到命令行参数、以在超时（60 秒）时强制执行硬复位。

 为了确定该问题、您可以做的最佳 (IMO) 操作是在挂起状态下连接 JTAG 并读取 WD 寄存器（以及在运行状态下进行快速比较）。 如果 WD 配置在这两种情况下均为“正常“、则问题更有可能与硬件相关。 否则、这表明进行的任何内核冻结也会使 WD 配置混乱。  我想重申的是、审查原理图对于排除可能的硬件问题非常有用。  

此致、

Michael

Maynard Cabiente ,

我将在下周重温这一主题。

感谢您的耐心！

-Josue

 Maynard Cabiente ,

从我共享的线程中、有 SoM 的证据表明、出于开发目的、WDT 在 Linux 引导的过程中被禁用。 您是否对 u-boot 或 Linux 进行了任何更改以使看门狗可用？

您是否尝试过以下操作： https://unix.stackexchange.com/questions/21335/how-do-i-cause-a-watchdog-reset-of-my-embedded-linux-device
   

您好 Josue、

在我们的 Linux 系统中设置看门狗（硬件和软件）没有问题。 我已经测试了看门狗计时器实际触发的两个位置、例如在内核驱动程序中放置 while (1) 循环或使用 sysrq 触发器。

同样、问题是当发生以下情况时、如果系统或内核挂起、看门狗计时器应将系统复位：

“我们有一个 FPGA 连接到 PCIe、它将 DMA 连接到 CPU 存储器、用于传输视频数据。 每当 FPGA 正在运行且可能发生数据传输时、我们只调用 Linux reboot 命令、系统就会挂起、永远不会重新启动。“

在这种情况下、看门狗计时器应该可以为我们节省空间、但不会触发复位。

此致、
Maynard

Maynard、

我想我终于明白了、所以 Linux 中的看门狗实际上正常工作、  

我已经测试了看门狗计时器实际触发的两个位置、例如在内核驱动程序中放置一个 while (1) 循环或使用 sysrq 触发器。

它只是在这个特定的场景中

"我们“我们有一个连接到 PCIe 的 FPGA、该 FPGA 连接到 CPU 存储器并用于传输视频数据。 每当 FPGA 正在运行且可能发生数据传输时、我们只调用 Linux reboot 命令、系统将挂起、永远不会重新启动

您进入挂起状态并且 WDT 实际上没有按预期触发重新引导。

很抱歉、我的理解滞后。 这对我来说是不清楚的。

在这一点上, 从 迈克尔 ·什克利亚曼的建议是走的方式。

-Josue