[参考译文] AM4378：L4-wkup-clkctrl：0118：0：启用失败

您好 Daniel、

支持预期

为了设定期望、SDK 8.2 现在已经过时、我们无法在论坛上提供支持。 我仍然会尽力帮助您、但我不会在硬件上运行任何测试。

这不是我  熟悉的终端输出、

请详细说明您正在观察的内容  

您多久看到一次此输出？

看到输出后、看门狗是否仍按预期工作？ 例如、

1) 您仍然可以读取和写入看门狗寄存器（例如,使用 devmem2）吗?

2) 是否仍然可以配置看门狗,并看到它重新启动系统,如果它没有宠物

其他想法

该时钟由多个外设使用。 如果您使用任何由时钟源提供的其他外设、可以进行快速完整性检查、通过测试以下外设来确保时钟本身仍然存在：

linux-5.10.100+gitAUTOINC+7a7a3af903-g7a7a3af903/arch/arm/boot/dts$ grep -r --include=am43* l4_wkup_clkctrl
am43xx-clocks.dtsi:             l4_wkup_clkctrl: l4-wkup-clkctrl@220 {
am437x-l4.dtsi:                 clocks = <&l4_wkup_clkctrl AM4_L4_WKUP_GPIO1_CLKCTRL 0>,
am437x-l4.dtsi:                          <&l4_wkup_clkctrl AM4_L4_WKUP_GPIO1_CLKCTRL 8>;
am437x-l4.dtsi:                 clocks = <&l4_wkup_clkctrl AM4_L4_WKUP_UART1_CLKCTRL 0>;
am437x-l4.dtsi:                 clocks = <&l4_wkup_clkctrl AM4_L4_WKUP_I2C1_CLKCTRL 0>;
am437x-l4.dtsi:                 clocks = <&l4_wkup_clkctrl AM4_L4_WKUP_TIMER1_CLKCTRL 0>;
am437x-l4.dtsi:                 clocks = <&l4_wkup_clkctrl AM4_L4_WKUP_WD_TIMER2_CLKCTRL 0>;

Where AM4_L4_WKUP_WD_TIMER2_CLKCTRL is the watchdog timer

此致、

Nick

你好、Nick

感谢您的回答。

-这种情况很少发生,大约 5 倍的过去几个月在我有日志的两个系统。
-我仍然可以配置看门狗,如果不是宠物,它会重新启动系统。
-我检查了一个 GPIO 引脚（在组 GPIO1 上）,它仍然按预期工作,例如,我可以切换引脚。

此致、Daniel

您好 Daniel、

为了进行确认、您能够配置看门狗、并且看门狗会在您看到该警告输出的引导程序中工作？ 或者您是否只能在“正常“引导上进行测试？

有一些驱动程序打印“启用失败“，但实际上，这种驱动程序很少是整个输出 — 大多数输出会告诉您更多关于启用失败的内容。 您看到的图片可能来自 clkctrl 驱动器：

drivers/clk/ti/clkctrl.c

static int _omap4_clkctrl_clk_enable(struct clk_hw *hw)
{
    ...
        /* Wait until module is enabled */
        while (!_omap4_is_ready(ti_clk_ll_ops->clk_readl(&clk->enable_reg))) {
                if (_omap4_is_timeout(&timeout, OMAP4_MAX_MODULE_READY_TIME)) {
                        pr_err("%s: failed to enable\n", clk_hw_get_name(hw));
                        return -EBUSY;
                }
        }

下一步是验证这是否是打印的实际来源

假设这是打印语句的原因：

这是超时错误。 如果计时器未在 2ms (2000us) 内就绪、似乎就会发生错误。

根据引导期间的其他情况、我已经看到像 I2C 这样的非 RT Linux 驱动程序在较新的器件 (AM62x) 上暂停几十至几百毫秒。 我不确定您在启动期间有多少控制权来提高此驱动程序的相对优先级、但我希望 RT Linux 有助于限制最坏情况下的时序。

如果不考虑潜在的后续影响、最简单的“修复“可能就是增加超时值。 只要整个引导没有冻结或崩溃、我希望 ARM 内核最终会完成它正在执行的其他任务、然后返回到 clkctrl 驱动程序完成时钟设置。

此致、

Nick

你好、Nick

是、显示警告消息后、看门狗和 GPIO 仍按预期运行。

我可以确认错误来自您指出的位置、我还添加了一条有关成功的消息（见下文）。

我设法重现它：我反复启用和禁用看门狗（通过将 V 写入、然后将 abc 写入/dev/watchdog）。
然后我通过繁忙的循环在 CPU 上引入重负载。 最终、它将失败。

[  210.382703] l4-wkup-clkctrl:0118:0: enabled successfully
[  210.431105] watchdog: watchdog0: watchdog did not stop!
[  211.013113] l4-wkup-clkctrl:0118:0: enabled successfully
[  211.089211] watchdog: watchdog0: watchdog did not stop!
[  211.620067] l4-wkup-clkctrl:0118:0: enabled successfully
[  211.668160] watchdog: watchdog0: watchdog did not stop!
[  212.247453] l4-wkup-clkctrl:0118:0: enabled successfully
[  212.289189] watchdog: watchdog0: watchdog did not stop!
[  212.918972] l4-wkup-clkctrl:0118:0: enabled successfully
[  213.001608] watchdog: watchdog0: watchdog did not stop!
[  213.541859] l4-wkup-clkctrl:0118:0: failed to enable       <- failure
[  213.597160] watchdog: watchdog0: watchdog did not stop!
[  214.193884] watchdog: watchdog0: watchdog did not stop!
[  214.757848] watchdog: watchdog0: watchdog did not stop!
[  215.312557] watchdog: watchdog0: watchdog did not stop!

现在还可以清楚地看到、至少对于该计时器、它与系统引导无关、因为当看门狗本身被启用/禁用时、计时器会被启用/禁用。

在我`、μ V_OMAP4_clkctrl_clk_enable`返回的错误条件没有得到评估并执行。

此致、Daniel