[参考译文] AM623：RTI 看门狗支持非窗口(100%开放)运行

你好、亚伦、

这是驱动程序的限制、而不是我知道的硬件限制。

在之前的讨论中、当我们不能允许看门狗时、我们检查了50%、25%、12.5%、6.5%和3.125%窗口：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1338070/am625-how-to-control-the-watchdog/5185069#5185069

我不确定是否已对100%窗口进行测试-我将与开发人员核实。

此致、

Nick

你好、亚伦、

我再次与开发人员核实、由于驱动程序当前不支持100%打开窗口、因此我们没有尝试100%窗口。

您能给我们详细介绍一下50%窗口不能满足设计需求的用例吗？

此致、

Nick

您好、Nick。

我目前遇到由 systemd 提供服务时看门狗复位电路板的问题。  引用/sys/class/watchdog/watchdog0/timeleft.时、通常会在30秒标记附近进行复位  我已 使用设置`RuntimeWatchdogSec=45`配置了 systemd、并且我还测试了其他值。  此处应用了 V3补丁、因为我们仍然在 SDK 9.01上。

有趣的是、当我禁用 systemd 看门狗 功能并使用用户空间应用程序来宠物时、看门狗的行为符合预期。  我通过脚本设置对看门狗进行了测试、并在应用中使用看门狗 IOCTL API 对看门狗进行了测试。  都按预期工作。

如果我将 驱动器中的 MAX_HW_ERROR 定义从250增加到2000 (随机选择)、我可以使系统跟上系统对看门狗的维护需求。  默认超时时间为60秒、看门狗模块使用外部32kHz 时钟源计时。

一些有趣的发现是、systemd 配置参数`RuntimeWatchdogSec`不使用该值。  检查 systemd 看门狗源代码后、当检测到设置 超时是不受支持的功能时、似乎会回退到使用驱动程序默认值(60s)。  systemd 将尝试以一半超时间隔的速率宠物看门狗。  这意味着 systemd 将尝试宠物看门狗在30秒标记,虽然我已经看到它宠物更快。  这可能会使该事件正好在关闭窗口的边缘对看门狗进行维护。

在我看来、与用户空间应用程序相比、我在关闭/打开窗口的边缘遇到了 systemd 对看门狗进行服务的时序问题。

谢谢！
亚伦

哎呀、我忘了跟进我的用例。  出于上述原因、我曾经尝试更新安全装置驱动程序、这样它可运行为一个传统安全装置、在整个超时内具有100%开放窗口。  缓解何时访问看门狗以及仅在超时到期前处理看门狗的不确定性。

如上所述、它无法在超时后将电路板复位。  WDSTATUS 寄存器指示在结束时间的时序违例。  /sys/class/watchdog/watchdog0/timeleft 停止计数并报告0。  我曾尝试将 WWDRXNCTRL (看门狗反应控制)从 NMI (驱动程序默认值)更改为复位、但它没有改变行为。

你好、亚伦、

有意思。 我能否让您分享您应用以设置100%窗口的补丁程序？

MAX_HW_ERROR 的作用是什么？

我们已意识到看门狗超时值的13个最低有效位已在看门狗的硬件中进行了舍入。 这意味着软件编程的超时和硬件编程的超时之间可能存在长达0.25秒的差异。 如果我们仅允许对整秒进行编程、则硬件倒计时值与软件倒计时值之间始终存在0.25秒的差值。

根据窗口的大小、这意味着软件驱动程序将允许软件在硬件窗口实际打开之前0.125至0.25秒宠物看门狗。 因此、我们添加了 MAX_HW_ERROR 作为0.25秒的缓冲区、以确保软件驱动程序在硬件窗口打开之前不会允许看门狗宠物。

下面是一幅混乱的图形,我绘制了一幅,显示了发生了什么:

要确认：系统正在通过系统设置看门狗进行复位、除非您将 MAX_HW_ERROR 增加到更大的值？  

如果 systemd 只会对系统执行一次宠物操作、恰好是超时值的50%、那么我希望看门狗驱动程序会阻止宠物。

看门狗的硬件计数器和软件驱动程序计数器之间的另一个误差源将是时钟频率的差异。 看门狗驱动程序增加了2%的缓冲、但如果32kHz 硬件时钟递增时与软件驱动程序的 PLL 时钟的差异超过2%、那么驱动程序仍然可以在硬件窗口打开之前允许宠物看门狗。

此致、

Nick

您好、Nick。

我已经将相关的修补程序发送给 Michael、您希望很快就能收到它们。

感谢您提供 MAX_HW_ERROR 说明。  它确实澄清了对这个额外填充的要求。  您可能还记得其他讨论过的内容、我开发的定制电路板使用外部 RTC (MCP7940)来提供32KHz 时钟、这需要通过 I2C 进行初始化。  我将初始化移到了 U-Boot 中、以确保在 Linux 启动之前提供稳定的时钟源。  我不确定这是否会对 RTI 模块产生任何影响、因为我认为 AM62 EVM 始终会通过专用晶体提供32kHz 时钟。

我有一个问题与 AM62的看门狗及其如何监控引导加载程序过程相关。 你想让我打开一个单独的帖子吗?

你好、亚伦、

100%打开窗口

我已收到补丁。 这个周末时间不多了、所以我要看一下周一。 我不能对100%开放代码的运行做出任何承诺、但我将至少仔细检查您的更改、看看所有内容是否合理。

50%打开窗口

我仍在想我们为什么会看到您所描述的行为(增加 MAX_HW_ERROR 时会阻止系统在30秒后自行重新启动)：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1411019/am623-rti-watchdog-support-for-non-windowed-100-open-operation/5407264#5407264

我可能想到的最可能的情况是这些补丁没有应用于正在运行的代码、或者硬件时钟源运行的速度比软件时钟预期的慢2%以上。

我不确定 systemd 的超时是否可以独立于硬件看门狗设置,但如果这样,也许将 systemd 超时设置得更长也会导致更好的行为? (例如、systemd 超时为60秒、驱动程序超时为50秒、然后50%硬件窗口在25秒打开、在 systemd 尝试宠物之前有5秒的缓冲区)

此致、

Nick

你好、亚伦、

一般而言、您的代码更改对我来说合理。

看门狗到期时的行为

在检查代码时弹出一条消息、即默认情况下、驱动程序将看门狗配置为在看门狗过期时生成不可屏蔽中断(NMI)、而不是直接将处理器复位：

        /* Generate NMI when wdt expires */
        writel_relaxed(RTIWWDRX_NMI, wdt->base + RTIWWDRXCTRL);

我不确定代码是这样编写的、是否有特殊原因？ 但这是您可以转动的另一个旋钮、将其设置为0x5 (默认位域值)、而不是0xA、然后查看处理器是否按预期开始复位。

仔细检查 MIN_HW_HEARTBEAT_ms 中的零值  

至少在查看 SDK 10.0代码时,看起来这个值仅用于 watchdog_dev.c >_watchdog_ping ()。

这是 add 函数的一部分、因此不会期望零值引起与数学相关的问题(例如、没有被零除或诸如此类的问题)：

static int __watchdog_ping(struct watchdog_device *wdd)
{
        struct watchdog_core_data *wd_data = wdd->wd_data;
        ktime_t earliest_keepalive, now;
        int err;

        earliest_keepalive = ktime_add(wd_data->last_hw_keepalive,
                                       ms_to_ktime(wdd->min_hw_heartbeat_ms));
        now = ktime_get();

        if (ktime_after(earliest_keepalive, now)) {
                hrtimer_start(&wd_data->timer,
                              ktime_sub(earliest_keepalive, now),
                              HRTIMER_MODE_REL_HARD);
                return 0;
        }

此致、

Nick

您好、Nick。

抱歉、我已经连接了一些项目。  我已经尝试了建议的更改、以在发生看门狗时序违规时直接复位处理器、而不是生成 NMI、但结果是相同的。   WDSTATUS 寄存器指示在结束时间违反时序、但从不发生复位。

您能否看到您是否可以使用类似的补丁在 AM62x EVM 上重现此问题？

谢谢！
亚伦

你好、亚伦、

您需要的时间范围是多少？ 我可以肯定地看到我是否可以复制您的系统观察、但我现在正在处理大量升级、因此如果您希望在9月份进行测试、您需要让您的现场代表升级我的管理链。

此致、

Nick

你好、亚伦、

很抱歉这里出现延误。 我现在正在努力复制您的观察结果。 将在明天提供另一个更新。

这是我目前唯一跟踪的 AM62x 项目的看门狗线程。 请告诉我、我的雷达上是否应该有任何其他线程。

此致、

Nick

你好、亚伦、

SDK 10.0测试-我无法复制结果

我先来看一下我是否可以在 AM62x SDK 10.0/kernel 6.6上复制您的观察结果。 我先介绍一下、因为这是看门狗开箱即用的第一个官方 SDK 版本。 然后我将向后移动至内核6.1。

首先、 看门狗能够复位电路板 如果我启动它而不维护它：

root@am62xx-evm:~# uname -a
Linux am62xx-evm 6.6.32-g6de6e418c80e-dirty #1 SMP PREEMPT Thu Oct 24 17:56:25 CDT 2024 aarch64 GNU/Linux

// processor resets after about a minute
root@am62xx-evm:~# echo 1 > /dev/watchdog
[   65.047224] watchdog: watchdog0: nowayout prevents watchdog being stopped!
[   65.054138] watchdog: watchdog0: watchdog did not stop!
...
U-Boot SPL 2024.04-ti-gfda88f8bcea3 (Jul 26 2024 - 11:00:12 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
SPL initial stack usage: 13392 bytes
Trying to boot from MMC2
Authentication passed
Authentication passed

systemd 能够使系统保持运行 (测试了5分钟、不确定是否必须等待更长的时间才能观察行为)

root@am62xx-evm:~# uname -a
Linux am62xx-evm 6.6.32-g6de6e418c80e-dirty #1 SMP PREEMPT Thu Oct 24 17:56:25 CDT 2024 aarch64 GNU/Linux

// set up SystemD and reboot
root@am62xx-evm:~# vi /etc/systemd/system.conf

//file looks like this:
RuntimeWatchdogSec=45
#RuntimeWatchdogPreSec=off
#RuntimeWatchdogPreGovernor=
RebootWatchdogSec=60
#KExecWatchdogSec=off
#WatchdogDevice=

// reboot

// watchdog is in use
root@am62xx-evm:~# echo 1 > /dev/watchdog
-sh: /dev/watchdog: Device or resource busy

我忘记使用这个内核参数来启用看门狗的额外可见性、但我将在 SDK 9.x 上的测试中启用它：
/sys/class/watchdog/watchdogN 更改内核参数后可能会显示状态和超时  
CONFIG_WATCHDOG_SYSFS=y

其他注释  

它看起来是一个特定的服务负责设置看门狗吗？ 默认情况下、服务只会在倒计时结束后中途加入看门狗、但似乎可以修改该服务以更频繁地发送通知消息。 如果为真、也许处理看门狗设置的服务可以重写 e、g、每1/4超时值发送一条通知消息？

https://manpages.debian.org/testing/libelogind-dev-doc/sd_watchdog_enabled.3.en.html

此致、

Nick

你好、亚伦、

对这里的延迟答复深表歉意。 您是否仍遇到问题？ 在尝试在 SDK 9.x 上进行测试之前、我是否应该了解任何更新？

此致、

Nick

你好、亚伦、

我想你可以让事情在你身边工作。 如果情况不是这样、请告诉我、我们可以继续讨论。

此致、

Nick