[参考译文] AM623：通过 systemd 进行 WDT_RTI 控制

Michael、您好！
下面是 AM64x Linux SDK 中 RTI_WDT 上最近的一篇 e2e 文章、供您参考。
e2e.ti.com/.../am6442-watchdog-timer-issue-on-sr2-0-silicon
此致！
-洪

您好、Hong：

是的、我已经看到过有关 RTI_WDT 的这个问题和其他讨论。 但这并不适用于我的问题、因为驾驶员在一般情况下可以正常工作。 我能够运行

./runltp -P am62xx-sk -f DDT/WDT_test -s WDT_S_FUNC_getStatus

然后在60秒内成功完成对板的重新启动。  

客户和我所面临的难题是使用 systemd 框架操作 WD。 报价从 说明(https://www.freedesktop.org/software/systemd/man/latest/systemd-system.conf.html):)

如果 RuntimeWatchdogSec= 设置为非零值，/dev/watchdog0  WatchdogDevice=  systemd.watchdog-device=则看门狗硬件(或使用或内核选项指定的路径)将编程为在指定的超时时间间隔内没有联系到系统时自动重新引导系统。 系统管理人员将确保至少在指定超时时间间隔的一半时间内与它联系一次。 此功能需要具备硬件看门狗器件、因为嵌入式系统和服务器系统中通常会出现这种情况。 并非所有硬件看门狗都允许配置所有可能的重新启动超时值、在这种情况下会选择最接近的可用超时。

不会发生上述情况。 而电路板则在每个 RuntimeWatchdogSec 间隔内不断重新启动。 我们确实在默认 SDK 映像上运行了 systemd、但其对 RTI_WDT 的控制似乎已损坏。 您能与司机确认一下可能会出现什么问题吗？

谢谢！

迈克尔

Michael、您好！
感谢您对用户案例的说明。 我会将其传递给我的同事以进行跟进...
此致！
-洪

Michael、您好！

对于此处的延迟响应、我们深表歉意。 我想在我结束时重复你的观察,但我本周耗尽了时间。 星期一是一个假期。 请保持诚实,并 ping 的线,如果我没有回应星期三。

此致、

尼克

Nick、

看起来 /etc/systemd/system.conf 仅在启动时被检查。 仅限 I 更改  

RuntimeWatchdogSec=40

然后重新启动电路板、它开始持续进行复位。 不要短接超过40秒、否则您将没有足够的时间在复位之间将其更改回

如果您看到这种情况、请告诉我、

谢谢！

迈克尔

Michael、您好！

我前面提到的几个人不熟悉看门狗计时器。 我一直在问、但目前我们可能没有任何有关看门狗的本地专业知识。

啊、我明白自己错了-我没有在 /etc/systemd/system.conf 文件中取消看门狗设置的注释。 现在我已经删除#我可以复制你的观察.

与这说,首先,我得到一个超时,实际上是60秒,现在我得到一个超时30秒后(即使设置仍然是 RuntimeWatchdogSec=60 -不知道什么改变)。

我今天没有时间进行更多测试、因此我会通过在线考察添加一些可能有用(但未经测试)的注释：

/sys/class/watchdog/watchdogN 更改内核参数后可能会显示状态和超时  
CONFIG_WATCHDOG_SYSFS=y

systemctl 状态看门狗  
无论是否已在 systemd 文件中启用看门狗、我都会得到相同的输出：

root@am62xx-evm:~# systemctl status watchdog


* watchdog.service - watchdog daemon

     Loaded: loaded (8;;file://am62xx-evm/lib/systemd/system/watchdog.service/lib/systemd/system/watchdog.service8;;; disabled; vendor preset: disabled)8;;

     Active: inactive (dead)

我在这里看到了 https://unix.stackexchange.com/questions/684671/how-to-check-systemd-hardware-watchdog-state 关于系统如何在某些时候获得本机硬件看门狗支持的评论。 这可能是我们需要深入研究的问题？

此致、

尼克

Nick、

CONFIG_WATCHDOG_SYSFS=y 的确暴露了不同的参数数量：

root@am62xx-evm：~ ls /sys/class/watchdog/watchdog0
引导状态设备标识 max_timeout min_timeout nowaoute 电源状态子系统 timeleft timeout uevent

我可以通过将"active"写入"status"或通过"systemctl start watchdog"或通过"wdctl /dev/watchdog0 "激活 WD、但在所有情况下、WD 都只是启动并在过期时重新启动系统。

但超时情况不同：systemctl 或状态导致30秒后重新启动。 60秒后为 wdctl。  

通过 wdctl 激活 WD 时：

root@am62xx-EVM：~#
root@am62xx-EVM：~# wdctl
[ 198.408194]看门狗: watchdog0: nowaouting 阻止看门狗停止!
[ 198.415116]看门狗: watchdog0:看门狗没有停止!
设备：/dev/watchdog0
标识：K3 RTI 看门狗[版本0]
超时：60秒
预超时：0秒
TimeLeft：60秒
标志说明状态 boot-status
KEEPALIVEPING 保持活动 ping 回复1 0

通过 systemd 激活时：

root@am62xx-evm:~# systemctl start watchdog
root@am62xx-evm:~# systemctl status watchdog
* watchdog.service -看门狗后台程序
已加载：已加载(/lib/systemd/system/watchdog.service；禁用；供应商预设：禁用)
活动：活动(运行)、自世界时(1970年01月01日) 00：01：59 (UTC)起；8秒前
过程：1613 ExecStartPre=/bin/sh -c [-z "$｛watchdog_module｝"||["$｛watchdog_module｝"="none"]||/sbin/modprobe $watchdog_module (代码=已退出、状态= 0/Success)
过程：1615 ExecStart=/bin/sh -c [x$run_watchdog != x1 ]|exec /usr/sbin/watchdog $watchdog_options (code=exported, status=0/success)
主 PID：1617 (安全装置)
任务数：1 (数量：2154)
内存：684.0K
cgroup：/system.slice/watchdog.service
`í- 1617 /usr/sbin/watchdog

JAN 01 00：01：59 am62xx-evm watchdog[1617]：接口：没有要检查的接口
JAN 01 00：01：59 am62xx-evm watchdog[1617]：温度：没有要检查的传感器
JAN 01 00：01：59 am62xx-evmwatchdog[1617]：无测试二进制文件
JAN 01 00：01：59 am62xx-evm watchdog[1617]：不修复二进制文件
JAN 01 00：01：59 am62xx-EVM 看门狗[1617]：错误重试超时= 60秒
JAN 01 00：01：59 am62xx-EVM 看门狗[1617]：修复尝试= 1
Jan 01 00：01：59 am62xx-evm watchdog[1617]：alive=/dev/watchdog heartbeat=[none] to=root no_act=no force=no
JAN 01 00：01：59 am62xx-EVM 看门狗[1617]：无法设置超时60 (errno = 95 ="不支持操作")
JAN 01 00：01：59 am62xx-EVM 看门狗[1617]：硬件看门狗标识：K3 RTI 看门狗
Jan 01 00:01:59 am62xx-evm systemd[1]：启动看门狗守护程序。

看起来 systemd 看门狗服务已激活并运行,但未能激活超时并宠物的狗。  我认为此时我们需要驾驶员的维护人员的支持。  

谢谢！

迈克尔

Michael、您好！

有关解释 systemctl 状态看门狗输出的一些指导：
https://trstringer.com/systemctl-status-output-explained/

我们正在慢慢取得进展...

当我在 systemd 中启用看门狗时,我在启动日志中看到与您的日志输出相匹配的以下内容:

root@am62xx-evm:~# dmesg | grep watchdog
[    2.325550] systemd[1]: Using hardware watchdog 'K3 RTI Watchdog', version 0, device /dev/watchdog0
[    2.334741] systemd[1]: Modifying watchdog timeout is not supported, reusing the programmed timeout.

这就解释了为什么无论我在 systemd 文件中输入了多少值、主板从启动时间到主板重置之前只能给我大约35秒的时间。  

另外有趣的是，如果通过 system.conf 文件而不是 systemctl 启动 watchdog，则 watchdemon 的状态为"inactive"。 我不确定是否有一个单独的地方需要在引导过程中显式调用看门狗守护程序？

root@am62xx-evm:~# systemctl status watchdog

* watchdog.service - watchdog daemon
     Loaded: loaded (8;;file://am62xx-evm/lib/systemd/system/watchdog.service/lib/systemd/system/watchdog.servi
ce8;;; disabled; vendor preset: disabled)8;;
     Active: inactive (dead)

我会继续将您的观察结果传递给更广泛的团队。 我在星期五得到的唯一反馈是"你需要一个守护程序来宠物看门狗",但显然你的输出"启动的看门狗守护程序"表明,事情没有预期的工作。

此致、

尼克

Michael、您好！

我很抱歉 这里的反应很慢-我还没有时间在我身边做更多的测试。

到目前为止，我还没有找到在这一领域具有专门知识的人。 我得到的唯一附加反馈如下：

JAN 01 00：01：59 am62xx-EVM 看门狗[1617]：无法设置超时60 (errno = 95 ="不支持操作")

也许我们的超时是固定的(不可配置)、这样我们就不需要试图将其设置为60、或者_将其设置为完全支持的值。 我会深入研究这一点。

看门狗超时设置一次后、我的理解是在处理器重启之前无法更改超时值。 但我不确定这是否会阻止系统代码的"设置"功能工作。 从我之前的响应启动期间的终端输出似乎表明 systemd 足够灵活、能够重复使用当前编程的超时值。 (尽管它仍然在我身上超时)

我有一个本地的人,我可以尝试与他们交谈,我将尝试寻找他们本周。

此致、

尼克

晚上好、我一直在努力解决同一个问题、并且至少还有一个数据点可以添加到本次讨论中。 根据 Nishanth Menon 在 Beagleplay Discord Channel 上的建议、我交叉编译并运行内核自己的 watchdog-test.c 实用程序。 在 eMMC Debian 发行版上(从一个镜像下载,但仍然是官方的)。

BTW，我可以确认 Michael Shklyarman 在这里报告的所有同样的行为(w.r.t` wdctl `s和` ystem d `)。

以下是我调用这个非常简单的测试实用程序得到的输出：

root@BeaglePlay:/home/debian# ./watchdog-test -p 5
Watchdog ping rate set to 5 seconds.
Watchdog Ticking Away!
......
U-Boot SPL 2023.04-g43791d94 (Dec 28 2023 - 17:37:03 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
...

大约30秒后，系统将忠实地重新启动。

在另一个窗口中、我在看门狗测试过程的 pid 上调用了`strace`、结果如下所示：

root@BeaglePlay:/home/debian# strace -p 1305
strace: Process 1305 attached
restart_syscall(<... resuming interrupted io_setup ...>) = 0
ioctl(3, WDIOC_KEEPALIVE)               = 0
write(1, ".", 1)                        = 1
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=5, tv_nsec=0}, 0xffffec52a3b0) = 0
ioctl(3, WDIOC_KEEPALIVE)               = 0
write(1, ".", 1)                        = 1
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=5, tv_nsec=0}, 0xffffec52a3b0) = 0
ioctl(3, WDIOC_KEEPALIVE)               = 0
write(1, ".", 1)                        = 1
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=5, tv_nsec=0}, 0xffffec52a3b0) = 0
ioctl(3, WDIOC_KEEPALIVE)               = 0
write(1, ".", 1)                        = 1
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=5, tv_nsec=0},

很明显、每5秒"设置"IOCTL 调用就会成功(值为0时见证)、这将表明硬件看门狗驱动器 IMO 的部分出现静默故障。

此致、

锡德

我在 SDK 9.0 (内核6.1)上测试了看门狗简单应用程序 。今天我也在 Samples/watchdog-simple.c 下测试了看门狗简单应用程序，它还导致重新启动而不是永久运行。 所以在这一点上,它看起来像一个驱动程序问题,而不是一个专门的问题与 systemd。

我还没有在 SDK 8.x 上进行测试、看看内核5.10上是否也存在该行为。 这将是我接下来要测试的内容。

此致、

尼克

部分更新：开发团队表示、他们将在不久的将来查看一下。 此时、他们尚未承诺特定的固定时间范围。 请随时告诉我一周内的最新动态。

此致、

尼克

Michael、您好！

我已经看过这个问题、并将 wdctl (工作案例)与 watchdog_simple (故障案例)进行了比较。 似乎 wdctl 工作的原因和 watchdog_simple 不是因为 wdctl 重复使用 open()和 close()，而 watchdog_simple 仅使用 write()。

这仍在调试中,但这是 WATCHDOG_SIMPLE 应用程序的快速破解,因此您可以在末端验证 open()实际上正在设置看门狗。

e2e.ti.com/.../test_2D00_wdgsimple

如果可以、请让我知道您的发现。

~朱迪斯

Judith、您好！

不确定应该发生什么情况、以下是控制台输出。 您能说明一下该示例的用途吗？ 我们知道 WD 可以手动修补(如果这是你在这个例子中所做的)。 问题是我们的 systemd 没有做到这一点。

谢谢！

迈克尔

root 用户@am62xx-evm：~#./test-wdgSimple
调试、开放式通道
[1226353.699953]看门狗: watchdog0: nowaouting 阻止看门狗停止!
[1226353.707103]看门狗: watchdog0:看门狗没有停止!
调试、开放式通道
[1226365.713129]看门狗: watchdog0: nowaouting 阻止看门狗停止!
[1226365.720241]看门狗: watchdog0:看门狗没有停止!
调试、开放式通道
[1226377.726470]看门狗: watchdog0: nowaouting 阻止看门狗停止!
[1226377.733689]看门狗: watchdog0:看门狗没有停止!
调试、开放式通道
[1

Michael、您好！

我们将在周一休息、但在本周晚些时候再次休息。 我不确定 Judith 是否花了更多时间休息。

我们仍在精确地调试正在发生的事情。 我无法访问 Judith 的源代码、但如果我回忆起我们的口头讨论、她向您提供的是经过修改的示例/看门狗/看门狗简单易用版。 她在看门狗驱动程序中添加了 print 语句,然后在 while 循环中移动了 open()和 close()命令。 (今天没有实际测试代码)、我认为代码如下所示：

int main(void)
{
//        int fd = open("/dev/watchdog", O_WRONLY);
//        int ret = 0;
//        if (fd == -1) {
//                perror("watchdog");
//                exit(EXIT_FAILURE);
//        }
        while (1) {
        
                int fd = open("/dev/watchdog", O_WRONLY);
                int ret = 0;
                if (fd == -1) {
                        perror("watchdog");
                        exit(EXIT_FAILURE);
                }
                ret = write(fd, "\0", 1);
                if (ret != 1) {
                        ret = -1;
                        break;
                }
                close(fd);
                
                sleep(10);
        }
//        close(fd);
        return ret;
}

因此,如果你试图遵循她张贴的打印声明的逻辑,我认为它应该像这样:

Debug, open pass
//countdown at 60 sec (fails to reset watchdog counter)
// not sure if the close() command is triggering these print statements?
[1226353.699953] watchdog: watchdog0: nowayout prevents watchdog being stopped!
[1226353.707103] watchdog: watchdog0: watchdog did not stop!
Debug, open pass
//countdown at 48 sec (fails to reset watchdog counter)
[1226365.713129] watchdog: watchdog0: nowayout prevents watchdog being stopped!
[1226365.720241] watchdog: watchdog0: watchdog did not stop!
Debug, open pass
//countdown at 36 sec (fails to reset watchdog counter)
[1226377.726470] watchdog: watchdog0: nowayout prevents watchdog being stopped!
[1226377.733689] watchdog: watchdog0: watchdog did not stop!
Debug, open pass
// after another sleep(10), countdown should be <30 sec
// At this point I would expect to see the watchdog get reset
// the processor should not force a reboot

我不想在这里说太多,只是因为我们还没有完全理解行为。 但它看起来像
1) 1)看门狗可以宠物、但是
2) 2)我们期望用于控制看门狗的 API 似乎未按预期运行

设定期望值：如果我们发现需要修改看门狗驱动程序、该补丁不会将其放入 SDK 9.2版本中。 我们将继续致力于此、在 取得进一步进展后、我们可以进一步讨论代码分发的最佳方法。

感谢 你的耐心,并让我们负责迈克尔。 如果我们在几个工作日内没有为您提供其他更新、请随时 ping 该主题。

此致、

尼克

Michael、您好！

添加到 Nick 的评论中。

我还没有使用 systemd 进行测试、

使用 wdctl、Linux 内核源码中的 watchdog-simple.c 以及一些其他调试工具、我发现了一些事情。

WATCHDOG_SIMPLE 使用一个 SYSCALL WRITE ()调用、看门狗子系统使用该调用来访问看门狗。 此示例程序可以在 AM64x 上工作、但不能在 AM62x 上工作。 软件执行的路径是相同的。  在 watchdog_dev.c 中、我们介绍了各个函数、最后在 RTI_WDG.c 中调用 RTI_WDT_ping、这是 K3器件上看门狗的驱动程序。 对于 AM64x、我们成功写入了使看门狗电容器放电的两步键序列、基本上会重新加载 DWD 递减计数器、这是使看门狗接收数据的操作。 对于 AM62x 平台、第二次写入似乎失败。

然而,当您重复调用 syscalls open ()和 close ()函数时,我们确实会在 AM62x 的一个特定情况下"宠物看门狗"。 这就是我发送一个实现该目标的示例程序的原因。 使用 open ()和 close ()看门狗子系统使用不同的路径、但我们最终也在 RTI_WDG.c 中调用 RTI_WDT_ping、两个写入都通过、重新加载 DWD 递减计数器。

所以我现在正在研究为什么我们不能执行两次写入来使用 write ()调用重新加载 AM62x 的 DWD 递减计数器。

~朱迪斯

大家好！

有人可以尝试在 Linux 内核中进行以下更改、并告诉我这是否改变了看门狗的行为：

diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index a9ccf7bb2ecc..06460243cdcd 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -891,7 +891,7 @@ main_rti0: watchdog@e000000 {
                clocks = <&k3_clks 125 0>;
                power-domains = <&k3_pds 125 TI_SCI_PD_EXCLUSIVE>;
                assigned-clocks = <&k3_clks 125 0>;
-               assigned-clock-parents = <&k3_clks 125 2>;
+               assigned-clock-parents = <&k3_clks 125 4>;
        };
 
        main_rti1: watchdog@e010000 {

~朱迪斯

大家好！

此处是另一个更新。

RTI WWDT 的父时钟(DEV_RTI0_RTI_CLK_PARTAL_CLK_32K_RC_SEL_OUT0)似乎未按预期工作。 如果我们更改为：

DEV_RTI0_RTI_CLK_PARTNER_MAIN_WWDTCLKN_SEL_OUT0_DIV_CLKOUT 然后看门狗按预期工作、但这不是真正的32K 信号。

上面发送的补丁应该允许宠物看门狗、很高兴看到它现在是否可以使用 systemd 工作。

正在等待、以检查 LFXOSC0不工作的原因。

~朱迪斯

上述补丁 Judith 在两者之间  
DEV_RTI0_RTI_CLK_PARTAL_CLK_32K_RC_SEL_OUT0 (时钟 ID 2)
和
DEV_RTI0_RTI_CLK_PARTAL_MAIN_WWDTCLKN_SEL_OUT0_DIV_CLKOUT (时钟 ID 4)

依据
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/clocks.html#clocks-for-rti0-device 

此致、

尼克

你好,我能够重现这个问题在这个线程上的 systemd ,设置我的 RuntimeWatchdogSec 到45。

然后我应用了上述补丁(根时钟 ID 2到根时钟 ID 4)、现在系统不再重新启动。

这一改变是否被认为是解决这个问题的办法，还是其他暗示可能会出现什么问题？

此致、

拉斐尔

大家好、我在更新 k3-am62-main.dtsi 文件后(重新)构建了系统、并重新运行了几周前的`watchdog-test`实验。

不幸的是，*未*阻止重新启动系统。

root@2b6e5b7:/tmp# ./watchdog-test -p 5  
Watchdog ping rate set to 5 seconds.
Watchdog Ticking Away!
......SSH session disconnected
SSH reconnecting...

明天我将尝试将 systemd 看门狗 runtimewatchdogsec 值设置为0以外的值。。。 但这是其他人感兴趣的另一个数据点。

您好 Rafael & Sidd：

感谢你们双方在你们身边进行测试！

我们仍在深入探究正在发生的事情。 我们目前假设的行为是由驱动程序文件中的这些代码行引起的。
驱动程序/看门狗/RTI_WDT.c

        /*
         * If watchdog is running at 32k clock, it is not accurate.
         * Adjust frequency down in this case so that we don't pet
         * the watchdog too often.
         */
        if (wdt->freq < 32768)
                wdt->freq = wdt->freq * 9 / 10;

它看起来像是使用默认时钟， WDT->freq = 32768，因此驱动程序不输入 if 语句， WDT->freq 保持在32768，看门狗不能正常工作。 但是、在另一个时钟 WDT->freq < 32768下、驱动程序输入 if 语句 WDT->freq 减小10%、看门狗正常工作。

假设是这种情况、我们仍在研究降低 WDT->FREQ 会改变行为的确切原因、以及为何首先添加这行代码的逻辑。 一旦我们了解了最初的意图、我们就可以进行其他评估(例如、如果"正确的修复"是删除 if 语句并 始终设置  WDT->freq = WDT->freq * 0.9、如果这覆盖了需要在代码中其他位置更改的某些逻辑、等等)。

此致、

尼克

尊敬的 Sidd：

以下命令会为您显示什么？

root@am62pxx-evm:~# k3conf dump parent_clock 125 0
|------------------------------------------------------------------------------|
| VERSION INFO                                                                 |
|------------------------------------------------------------------------------|
| K3CONF | (version 0.3-nogit built Tue Feb 13 15:54:05 UTC 2024)              |
| SoC    | AM62Px SR1.0                                                        |
| SYSFW  | ABI: 3.1 (firmware version 0x0009 '9.2.5--v09.02.05 (Kool Koala))') |
|------------------------------------------------------------------------------|

|-----------------------------------------------------------------------------|
| Clock information                                                           |
|-----------------------------------------------------------------------------|
| Device ID | Clock ID | Clock Name       | Status          | Clock Frequency |
|-----------------------------------------------------------------------------|
|   125     |     0    | DEV_RTI0_RTI_CLK | CLK_STATE_READY | 32768           |
|-----------------------------------------------------------------------------|

|--------------------------------------------------------------------------------------------------------------------|
| Clock Parent information                                                                                           |
|--------------------------------------------------------------------------------------------------------------------|
| Selected | Clock ID | Clock Name                                               | Status          | Clock Frequency |
|--------------------------------------------------------------------------------------------------------------------|
|          |     1    | DEV_RTI0_RTI_CLK_PARENT_GLUELOGIC_HFOSC0_CLKOUT          | CLK_STATE_READY | 25000000        |
|   ==>    |     2    | DEV_RTI0_RTI_CLK_PARENT_CLK_32K_RC_SEL_OUT0              | CLK_STATE_READY | 32768           |
|          |     3    | DEV_RTI0_RTI_CLK_PARENT_GLUELOGIC_RCOSC_CLKOUT           | CLK_STATE_READY | 12500000        |
|          |     4    | DEV_RTI0_RTI_CLK_PARENT_GLUELOGIC_RCOSC_CLK_1P0V_97P65K3 | CLK_STATE_READY | 32552           |
|--------------------------------------------------------------------------------------------------------------------|

root@am62pxx-evm:~# 

既然我举了一个使用 AM62p 的例子、那么在结束时就忽略这一结果、但我很好奇 k3conf 会为您显示什么。

~朱迪斯

Rafael、您好！

该补丁会更改 RTI_clk 的父时钟、因为驱动器中的频率已更改、这会影响计时器裕量、并会影响我们启用看门狗时。 在 AM62x 上、我们似乎违反了有效时间窗口来控制看门狗、我们似乎设置得太早。 我们可以通过扩展驱动程序中当前的 Hack 来解决问题、但长期修复仍在等待中。 如果这是真正的32K 时钟信号、我们需要了解为什么32K 时钟会让我们过早地检测看门狗。

~朱迪斯

尊敬的朱迪思：

我按照您的要求构建并运行了 k3conf 命令、这里是它生成的输出：

root@2b6e5b7:/opt/install# ./k3conf dump parent_clock 125 0
|------------------------------------------------------------------------------|
| VERSION INFO                                                                 |
|------------------------------------------------------------------------------|
| K3CONF | (version v0.2-53-g81581af built Thu Mar 7 11:09:21 PM UTC 2024)     |
| SoC    | AM62X SR1.0                                                         |
| SYSFW  | ABI: 3.1 (firmware version 0x0009 '9.1.8--v09.01.08 (Kool Koala))') |
|------------------------------------------------------------------------------|

|-----------------------------------------------------------------------------|
| Clock information                                                           |
|-----------------------------------------------------------------------------|
| Device ID | Clock ID | Clock Name       | Status          | Clock Frequency |
|-----------------------------------------------------------------------------|
|   125     |     0    | DEV_RTI0_RTI_CLK | CLK_STATE_READY | 32552           |
|-----------------------------------------------------------------------------|

|---------------------------------------------------------------------------------------------------------------------|
| Clock Parent information                                                                                            |
|---------------------------------------------------------------------------------------------------------------------|
| Selected | Clock ID | Clock Name                                                | Status          | Clock Frequency |
|---------------------------------------------------------------------------------------------------------------------|
|          |     1    | DEV_RTI0_RTI_CLK_PARENT_GLUELOGIC_HFOSC0_CLKOUT           | CLK_STATE_READY | 25000000        |
|          |     2    | DEV_RTI0_RTI_CLK_PARENT_CLK_32K_RC_SEL_OUT0               | CLK_STATE_READY | 32768           |
|          |     3    | DEV_RTI0_RTI_CLK_PARENT_GLUELOGIC_RCOSC_CLKOUT            | CLK_STATE_READY | 12500000        |
|   ==>    |     4    | DEV_RTI0_RTI_CLK_PARENT_MAIN_WWDTCLKN_SEL_OUT0_DIV_CLKOUT | CLK_STATE_READY | 32552           |
|---------------------------------------------------------------------------------------------------------------------|

(希望这对您有所帮助)

此致、

锡德

尊敬的 Sid：

感谢您的更新。 父时钟正确。 您在使用什么电路板？ 是 TI EVM 吗？ 另外,您使用 systemd 的测试结果是什么?

~朱迪斯

大家好、 Judith MendezandTI 专家：

为解决此问题、您有何计划和期望？

高 FD、

到目前为止，我们已经完成了初步调查。 希望能在10.0版本中及时修复此问题。

~朱迪斯

大家好！

我们现在准备了一个补丁来修复此问题。 在 AM62x 上、在有效计时窗口打开之前看门狗似乎处于宠物状态、请尝试以下补丁、并告知我们这是否会最终解决您的问题。

e2e.ti.com/.../0002_2D00_watchdog_2D00_rti_5F00_wdt_2D00_Fix_2D00_min_5F00_hw_5F00_heartbeat_5F00_ms.patch

~朱迪斯

谢谢 Judith Mendez。 为了清楚起见，我是否可以回复您在应用此更改之前提出的以下更改？ 我假设不再需要这一点。

此致、

锡德

diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
索引 f1494e0e9816..33d7ba16da9a 100644
-- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@-834,7 +834,7 @@ main_rti0：看门狗@e000000
               时钟=<&K3_CLKS 125 0>；
               电源域=<&K3_PDS 125 TI_SCI_PD_Excluse>；
               分配的时钟=<&K3_CLKS 125 0>；
-              Assigned-Clock-Parents =<&K3_CLKS 125 2>；
+              Assigned-Clock-Parents =<&K3_CLKS 125 4>；
       }；
 
       main_rti1：看门狗@e010000｛

尊敬的 Sidd：

不再需要您引用的补丁。 唯一需要的补丁是： 0002-WATCHDOG-RTT-Fix-min_hw_heartbeat_ms.patch。

~朱迪斯

尊敬的 Sidd：

根据检查注释、在有效窗口打开后、一个更安全的宠物进入看门狗超时值的+5%、所以下面是相应的补丁：

e2e.ti.com/.../v2_2D00_0001_2D00_watchdog_2D00_rti_5F00_wdt_2D00_Set_2D00_min_5F00_hw_5F00_heartbeat_5F00_ms_2D00_to_2D00_55_2D00_of.patch

让我们知道此修复是否有用。

此致、

朱迪斯

你好 Judith Mendez

您发送至 LKML https://lore.kernel.org/all/20240403212426.582727-1-jm@ti.com/的补丁 似乎有所不同。 您能解释一下原因吗？  

高 FD、

是的、我可以解释。

1.我省略了驱动程序引入中包含的黑客程序,因为在本例中,我们不会在 AM62x 上默认接触该特定的代码片段,因此,有人可以说这种变化是不相关的。

2.如果在 Linux 内核启动看门狗之前启动了看门狗，则 RTI_WDT_setup_HW_HB 函数将起作用，我们必须在此处更新 MIN_HW_HEARTBEATH_ms，以适应5%的安全裕度。

~朱迪斯

可能是尚未测试的解决方案 https://patches.linaro.org/project/linux-watchdog/patch/4d82b8ce-bc34-e4b2-c5fe-9e883b0db59d@siemens.com/

大家好！

更新

我们已经测试了补丁集的 v3、它暂时看起来很好：
https://lore.kernel.org/lkml/20240417205700.3947408-1-jm@ti.com/

我要离开一个整晚运行的测试、窗口= 50%、超时为1秒、宠物间隔为5ms。 如果到明天仍未重新启动、我想说 Linux 驱动程序补丁就能提供我们所需要的功能。

到目前为止已测试的内容

我到目前为止所有的测试都是针对该主题：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1338070/am625-how-to-control-the-watchdog

以下是指向特定测试的链接：

您可以通过传入内核模块参数来设置看门狗超时值

不能通过在 Linux devicetree 中设置 timeout-sec 来设置看门狗超时值。

您可以使用 systemd 来控制看门狗。 不需要 systemd 修补程序

您可以使用 Samples/watchdog/watchdog-simple.c 来控制看门狗

V2和 v2.5 (未发布)对于较小的超时值不起作用

在"默认"环境中、V3似乎可以在超时值低至1秒时工作。 取决于您的环境和设置、请参阅此处的数学知识

此致、

尼克