[参考译文] AM625：引导停止和崩溃

你好  

与几个月前的请求类似、我们将需要您的帮助、进一步剥离洋葱、看看您是否可以通过更简单的测试并定位到特定模块(CAN？)来证明这一点 是对故障等敏感的东西等

1) 1)我想再次确认您使用的是最新的 SDK、特别是列出了修复程序的 SYSFW  2.1.版本说明—Processor SDK AM62x 文档 (SYSFW-7056)  

2) 2)您已经消除了之前由 DDR 和 eMMC 故障/不稳定导致的问题  

3) 3)您采取了哪些措施来进一步缩小问题范围？ 每个电路板、每个型号都失败。 是否进行了研究以了解故障是来自于器件、电路板还是二者的混合？ ABA 交换？

4) 4)故障与通过电路板的比例是多少

5) 5)您已确认 OPP 正确、并且您未在0.75V 下运行1.4GHz 等  

6) 6)温室温度与芯片传感器报告的芯片温度之间存在何种相关性

7) 7)故障是否仅在负温度下发生-高温下一切正常？  

8) 8)该故障对给定温度敏感、还是在您在不同温度下初始化但在不同温度下进行压力测试或温度室测试时发生？

1) 1)我想再次确认您使用的是最新的 SDK、特别是列出了修复程序的 SYSFW  2.1.版本说明—Processor SDK AM62x 文档 (SYSFW-7056)  

好的、我们在这里似乎犯了一个错误。 上一轮测试使用手动构建的映像执行、以添加 U-Boot eMMC 错误的补丁(https://lore.kernel.org/u-boot/20240418190100.1289150-1-jm@ti.com/)、而错误地将旧的 SYSFW 集成到其中。

我们将重新执行测试、并在几天后向您更新。

谢谢、它会很有帮助  

eateng xu 说：

1)我想再次确认您使用的是最新的 SDK、特别是列出了修复程序的 SYSFW  2.1.版本说明—Processor SDK AM62x 文档 (SYSFW-7056) [/报价]

纠正错误后、我们使用最新的 SYSFW 重新运行所有测试。 我们看不到任何改进。

请参阅更新的日志。

e2e.ti.com/.../24_2D00_04_2D00_30_5F00_17_2D00_01_2D00_57_2D00_Fail.txt

e2e.ti.com/.../24_2D00_04_2D00_30_5F00_20_2D00_19_2D00_09_2D00_Fail.txt

[报价 userid="5798" url="~/support/processors-group/processors/f/processors-forum/1354528/am625-boot-stall-and-crashes/5169374 #5169374"]

2) 2)您已经消除了之前由 DDR 和 eMMC 故障/不稳定导致的问题  

[报价]

正确。 我们集成了 eMMC 缺失调优算法的最新 WIP。  

除此之外、我还要指出、DDR 和 eMMC 问题仅影响我们模块的特定变体、而此处描述的问题会影响我们的所有变体。

[报价 userid="5798" url="~/support/processors-group/processors/f/processors-forum/1354528/am625-boot-stall-and-crashes/5169374 #5169374"]

3) 3)您采取了哪些措施来进一步缩小问题范围？ 每个电路板、每个型号都失败。 是否进行了研究以了解故障是来自于器件、电路板还是二者的混合？ ABA 交换？

[报价]

我们在禁用了 CAN 接口(`module_blacklist=m_can、m_can_platform` kernel 命令行参数)的情况下运行了测试、但是此次更改后、我们无法重现此问题。 这是我们昨天刚刚执行的测试(这是新信息)。

[报价 userid="5798" url="~/support/processors-group/processors/f/processors-forum/1354528/am625-boot-stall-and-crashes/5169374 #5169374"]

4) 4)故障与通过电路板的比例是多少

[报价]

 在我们最新的测试中、所有电路板都发生故障、低于-30°C 故障率为~30%。 请参见随附的图。

[报价 userid="5798" url="~/support/processors-group/processors/f/processors-forum/1354528/am625-boot-stall-and-crashes/5169374 #5169374"]

5) 5)您已确认 OPP 正确、并且您未在0.75V 下运行1.4GHz 等  

[报价]

是的、我可以再次确认。 我还可以确认我们的电路板具有0.85V VDD 内核故障。

[报价 userid="5798" url="~/support/processors-group/processors/f/processors-forum/1354528/am625-boot-stall-and-crashes/5169374 #5169374"]

6) 6)温室温度与芯片传感器报告的芯片温度之间存在何种相关性

[报价]

我们没有直接测量此值、而是通过 在人工气候室的-40°C T AIR 处进行一些间接测量、SOC 温度传感器在启动后报告-32°C 周围的温度

[报价 userid="5798" url="~/support/processors-group/processors/f/processors-forum/1354528/am625-boot-stall-and-crashes/5169374 #5169374"]

7) 7)故障是否仅在负温度下发生-高温下一切正常？  

[报价]

正确、-20°C 以上的一切都很好。

eateng xu 说：

8)故障是对给定温度敏感还是在不同温度下初始化但在不同温度下进行应力测试或温箱测试时发生？

这些故障仅在启动期间发生、然后才能执行任何压力测试。 发生故障时的温度与启动时出现的温度几乎相同(原因相同)。

我还要求您看一看我 在 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1309832/am625-crash-internal-error-synchronous-external-abort-in-mcan-driver-at-low-temperatures-20-degrees-celsius/4978691中的分析 

此处引用的是相关器件：

""

此类问题会在`m _can_get_berr_counter ()`调用`_m_can_get_berr_counter ()`m 时发生、而不调用`_can_clk_start ()`、IOW 而不启用时钟。 我确实查看了代码、但未能 发现 m_can 驱动程序中能够证明此类行为合理的任何错误。

...

在系统在室温下正确引导后、我们无法重现运行 Continuous `ip -Det link show CAN0`的问题。

我唯一能想到的问题可能是`m _can_runtime_resume ()`在启用时钟之前返回、这可能与在 cortex R5上运行的 DM 固件出现某种竞态条件有关？  

""

[/quote]

你(们)好  

这感谢您提供详细的响应和额外的测试电池。 非常感谢

以下是我的快速评估(请查看您是否同意)

1) 1)温度灵敏度似乎仅围绕 CAN 功能？

2) 2)故障率为30%、因此不清楚是电路板、SOC 还是软件驱动程序中的任何边缘性(我目前怀疑这一点)  

3) 3)您是否做了足够的工作来确保 DDR 的功能不存在边缘性(即使看起来像是 CAN 问题)。 您在这些电路板上使用什么存储器？

是否还有方法可以考虑执行 ABA 交换以查看故障是否出在器件或主板上？

我还将向 MCAN 驱动程序所有者指出该主题、以了解他们是否对您在日志和之前的帖子中提供的其他信息有任何疑问。  

1) 1)温度灵敏度似乎仅围绕 CAN 功能？

有。 我们在禁用 CAN 的情况下进行了压力测试、一切都运行稳定

2) 2)故障率为30%、因此不清楚是电路板、SOC 还是软件驱动程序中的任何边缘性(我目前怀疑这一点)  

我 在原始 e2e 线程中已经同意的建议/假设 是、从驱动器启用时钟到启用/稳定时钟需要一段时间。

3) 3)您是否做了足够的工作来确保 DDR 的功能不存在边缘性(即使看起来像是 CAN 问题)。 您在这些电路板上使用什么存储器？

是的、到目前为止我们执行的所有扩展内存测试都通过了。 我们使用了多个存储器(Micron、南亚各有不同尺寸和温度范围的器件)。

是否还有方法可以考虑执行 ABA 交换以查看故障是否出在器件或主板上？

无论我们使用哪种存储器、eMMC、VDD_Core 或 SOC 型号、我们的所有电路板都受到影响。 我们有很多组合、它们都失败了。

eateng xu 说：

此外、是否有办法查看引脚上的 CAN 总线活动、无论如何、您都可以证明数据传输/波特率在工作与非工作场景中均完好无损？

崩溃发生在探测时间。 此时 CAN 引脚上没有任何情况。 这是配置任何波特率之前的方法。

我误点击了"This resolved my issue"按钮、但情况并非如此。  Mukul Bhatnagarmaybe你可以纠正这一点,并再次标记为未解决。

eateng xu 说：

我还将此主题指向 MCAN 驱动程序所有者、以查看他们是否对您在日志和之前的帖子中提供的附加信息有任何建议。  [报价]

与实际的 MCAN 驱动程序相比、CAN 时钟似乎更像是一个问题、至少这是由于我们正在经历的崩溃类型。  

是的、我想问您是否还可以查看您的 CAN 收发器温度 规格等 我同意这是倾向于一个硬件一样的问题,我也会提请硬件专家的注意。  

(99+)如何重新打开标记为已解决错误的问题-接口论坛-接口- TI E2E 支持论坛

不用担心、我们期待您的回应。  

eateng xu 说：

是的、我想问您是否还可以查看您的 CAN 收发器温度 规格等。

是的、即使没有收发器、问题也是一样的、您根本不需要使用收发器来解决此问题。

我想知道是否可以通过在 TI AM62 SK 板上启用主 CAN0和 MCU CAN0来重现此问题。  但是、我不知道 SK 板在-30摄氏度下是否性能良好。

您是否尝试过环回测试来排除外部组件依赖性？ 我们的 EVM 额定工作温度为-30°C、用于软件功能评估、 而非-40°C 至125°C 温度范围内的参考设计。  

我们需要你的帮助,进一步剥洋葱。 ABA 测试是否计划进行？

eateng xu 说：

您是否已尝试过环回测试以排除外部组件依赖关系？ [报价]

你在这里具体是什么意思？ 我们使用的所有组件的额定温度均低至-40°C。如果您对某些组件有任何具体问题、我们可以尝试对其进行一些具体检查。

前面讲过、在探测 MCAN 驱动程序时会发生问题、因此在测试失败的情况下我们不会使用 CAN。

eateng xu 说：

我们需要您的帮助来进一步剥离洋葱。 ABA 测试是否计划进行？[/QUOT]

我不理解你到底在问什么,但我们在这里是为了帮助达成一个共同的解决方案。 您希望确切测试什么内容？

[/quote]

抱歉、我快速阅读、我想 ABA 交换没有意义、因为您说100%的电路板故障、但每块电路板的故障率是30%。  

我们可能还需要关注您所指的  在启用时钟之前`m can_runtime_resume ()`返回的内容,这可能与 SYSFW 时钟启用/禁用时的某种竞态条件有关? 您是否尝试过在任何位置添加任何等待状态以查看这是否有用？   

是的、在向您提到这一点后、我们决定准备一项测试、并添加一些延迟、我们将在一两天内获得测试结果。

一些更新

Unknown 说：

是的、在向您提及此事后、我们决定准备一项测试并添加一些延迟、我们将在一到两天内得到测试结果。

在启用 CAN 时钟后添加10ms 延迟似乎有积极的影响、发生率从30%降低到12%。 我们将增加延迟并重新执行测试。 这些试验结果虽然有希望、但尚未得出结论。

 `m、我们还针对一组不同的板(具有不同的硬件配置)再运行了一个测试、另外、在禁用 CAN 接口(Δ t odule_blacklist=m_can、m_can_platform`)后、板在整个温度范围内均可稳定运行。  

如果您有任何缩小问题范围的建议、请告诉我。

Hi-FD、

您是否能够测试以下内容、尝试禁用 MAIN_mcan0并仅启用 MCU_mcan0。 然后进行测试、查看这是否仍然导致启动失败。 然后禁用 MCU_mcan0并仅启用 MAIN_mcan0并比较结果。

~ Judith

尊敬的 Judith Mendez：

Unknown 说：

您能否测试以下内容、请尝试禁用 main_mcan0并仅启用 mcu_mcan0。 然后进行测试、查看这是否仍然导致启动失败。 然后禁用 MCU_mcan0并仅启用 MAIN_mcan0并比较结果。[/QUOT]

不过、我们明天将进行测试、我对提供有用反馈的期望不高。  这里的问题 早已存在、在实际的 Linux m_CAN 驱动程序被扩展以根据 TI AM62 SOC 中的 MCU_MCAN[01]上的要求启用无中断 MCAN 器件之前。

Hi-FD、

好的、那么此处不太可能是由计时器轮询支持导致的问题、仍请进行一次测试。

谢谢！

~ Judith

Unknown 说：

启用 CAN 时钟后增加10ms 延迟似乎有积极影响、发生率从30%降低到12%。 我们将增加延迟并重新执行测试。 这些测试结果虽然有希望,但还不是最终结果。[/报价]

按照这些思路,我也会尝试更严厉的措施,因为这,删除暂停/恢复 PM ..

$ git diff
diff --git a/drivers/net/can/m_can/m_can_platform.c b/drivers/net/can/m_can/m_can_platform.c
index 01c363d20d3f..28a4d5107f39 100644
--- a/drivers/net/can/m_can/m_can_platform.c
+++ b/drivers/net/can/m_can/m_can_platform.c
@@ -220,7 +220,6 @@ static int __maybe_unused m_can_runtime_resume(struct device *dev)
 static const struct dev_pm_ops m_can_pmops = {
        SET_RUNTIME_PM_OPS(m_can_runtime_suspend,
                           m_can_runtime_resume, NULL)
-       SET_SYSTEM_SLEEP_PM_OPS(m_can_suspend, m_can_resume)
 };

 static const struct of_device_id m_can_of_table[] = {

...如果这不能帮助更激烈的这样,删除所有的 PM ...

$ git diff
diff --git a/drivers/net/can/m_can/m_can_platform.c b/drivers/net/can/m_can/m_can_platform.c
index 01c363d20d3f..622c90c1218f 100644
--- a/drivers/net/can/m_can/m_can_platform.c
+++ b/drivers/net/can/m_can/m_can_platform.c
@@ -233,7 +232,6 @@ static struct platform_driver m_can_plat_driver = {
        .driver = {
                .name = KBUILD_MODNAME,
                .of_match_table = m_can_of_table,
-               .pm     = &m_can_pmops,
        },
        .probe = m_can_plat_probe,
        .remove = m_can_plat_remove,

此致、Andreas

按照这些思路,我也会尝试更严厉的措施,因为这,删除暂停/恢复 PM ..

我认为这不会有任何不同。 该问题发生在驱动器探测器()期间、并且该探测器比 任何实际暂停/恢复发生的时间都早。

或者我缺少什么吗？

Mukul Bhatnagar JudithMendezAndreasDannenberg

启用 CAN 时钟后、我们确实运行了一个延迟为50ms 的测试、进行了这种更改、系统运行稳定而没有出现故障。

--- a/drivers/net/can/m_can/m_can_platform.c
+++ b/drivers/net/can/m_can/m_can_platform.c
@@ -5,6 +5,7 @@
 //
 // Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
 
+#include <linux/delay.h>
 #include <linux/hrtimer.h>
 #include <linux/platform_device.h>
 #include <linux/phy/phy.h>
@@ -213,7 +214,9 @@ static int __maybe_unused m_can_runtime_resume(struct device *dev)
        err = clk_prepare_enable(mcan_class->cclk);
        if (err)
                clk_disable_unprepare(mcan_class->hclk);
-
+       printk("delay 50ms....");
+       mdelay(50);
+       printk("end delay....");
        return err;
 }

Hi-FD、

Unknown 说：

我们在启用 CAN 时钟后执行了一项测试、延迟为50ms、发生此类更改后、系统运行稳定、没有出现故障。

太好了、感谢确认。 这也意味着、完全删除部分 PM 代码(之前建议的实验)很可能也可以解决该问题、但使用的方法可能更清晰、直到我们了解根本原因并验证延迟是否确实是有效的修复方法(如果是、则需要多长时间)。

现在我们需要在结尾处弄清导致这个问题的真正原因。 我认为时钟启用等。调用将是同步的、并且仅在时钟启用并稳定后返回、需要确认这一点以查看是否起作用。 之类的设置。

此致、Andreas

Xiange Tian 说：

我认为时钟启用等呼叫将同步

是的、我可以确认 Linux 时钟 API 应该是同步的。

Xiange Tian 说：

现在我们需要在结尾处找出真正导致此问题的原因

在这里、请告诉我我们是否以及如何能够提供帮助。

至少、我们仍计划 运行 Judith Mendez 建议的测试、可能问题特定于两个(MAIN/MCU)域之一。

Unknown 说：

是的、我可以确认 Linux 时钟 API 应该是同步的。

这些调用应一直传播到器件管理器(DM)固件、该固件控制时钟树/多路复用器/PLL 等 最终取决于固件的功能、我来看看这些器件。 我不认为有任何意外真的,例如 PLL 代码总是等待"锁定",然后再继续,但它不会伤害再次检查。 当然、这也可能是另外一种情况、可能也是由于您的特定设置中的特定时钟比率(CAN 速度/时钟与系统时钟等)导致其自身发生的时序依赖性。 它需要一些检测工作。

此致、Andreas

(很抱歉、我不小心将上面的帖子标记为"回答"、这不是我可以撤销的内容)

Unknown 说：

也许我们应该保持打开选项、让其他东西还没有准备好(电源？)。

如果您尚未尝试此功能(这里没有所有的历史记录)、您能否在运行时加载 CAN 内核模块(使用 modprobe)来查看其功能？

此致、Andreas

如果您尚未尝试此功能(这里没有所有的历史记录)、您能否在运行时加载 CAN 内核模块(使用 modprobe)来查看其功能？

我更关注电源域、例如对于 MAIN_mcan0 `电源域=<&K3_PDS 98 TI_SCI_PD_Exclusive>`。 可能时钟就绪、但域尚未通电。 如果有这个延迟、我们 可能会隐式解决这个问题。 稍后加载模块不会改变这一点。

尽管如此、我们还没有尝试过您提到的特定测试、但是进行此设置并不是很简单、因为内核只是自动加载模块。

从计时的角度来看、 模块加载已经在引导阶段相对较晚的时间进行、此时用户空间 systemd init 序列正在进行、引导时间超过5秒。

如果您仍然认为这是要做的重要测试、我们可以尝试找到一些方法来测试它。

确认这一怪异假设的一种方法是添加延迟之前启用时钟、而不是之后。 我们将尝试对此进行测试。

所有这一切都可能是由实际时钟和电源域本身启用之外的一些通用竞态情况引起的。 从异常日志中可以看到、netlink 驱动程序似乎正在尝试访问尚未准备好的 CAN 寄存器、这通常是由于时钟或电源域问题而导致的。

在这种背景下、一个实验将限制系统仅使用一个 CPU、这样事情就以更"有序"的方式发生。 您可以执行以下操作：

# In U-Boot, populate an extra Kernel command line parameter
=> env set optargs maxcpus=1
=> env print optargs
optargs=maxcpus=1
=> boot

<...snip...>

# Check to make sure that parameter made it to the Kernel...
# (yes, it did)
[    0.000000] Kernel command line: console=ttyS2,115200n8 maxcpus=1 earlycon=ns16550a,mmio32,0x02800000 mtdparts=spi-nand0:512k(ospi_nand.tiboot3),2m(ospi_nand.tispl),4m(ospi_nand.u-boot),256k(ospi_nand.env),25
6k(ospi_nand.env.backup),98048k@32m(ospi_nand.rootfs),256k@130816k(ospi_nand.phypattern) root=PARTUUID=eb24392b-02 rw rootfstype=ext4 rootwait

<...snip...>

# Finally, also double-check at Linux prompt...
root@am62pxx-evm:~# nproc
1

此致、Andreas

Xiange Tian 说：

在这种情况下、一个实验将系统限制为仅使用一个 CPU、

我们已经在单核 AM6231 SOC 中重现了此问题、因此我认为不需要此测试。

Andreas Dannenberg

在 执行更多测试后更新一些信息。

Unknown 说：

您能否测试以下内容、请尝试禁用 main_mcan0并仅启用 mcu_mcan0。 然后进行测试、查看这是否仍然导致启动失败。 然后禁用 MCU_mcan0并仅启用 MAIN_mcan0并比较结果。[/QUOT]

Judith Mendez：我们测试了这一点、行为和以前一样。 只要启用了任何 CAN 接口(主域或 MCU 域)、就会出现问题。

Unknown 说：

确认这一奇怪假设的一种方法是添加延迟之前启用时钟、而不是之后启用时钟。 我们将尝试对此进行测试。

我们对此进行了测试、启用 CAN 时钟之前增加50ms 延迟可解决该问题。 因此、似乎需要一些延迟、但这不是时钟。 CAN 接口的电源域是一个选项、但也许您还需要探究其他想法。

只是提醒一下,这个问题只发生在零下20摄氏度以下(或者至少,我们无法在任何其他条件下重现它),所以我们应该关注一些与时间相关的东西, 当温度"低"时可能会更慢。

CC: Franz Schnyder

[/quote]

Hi-FD、

感谢您的确认。

~ Judith

高 FD
是不是可以让我们得到一个寄存器转储为 PLL (主 PLL0将时钟源到 CAN ), CAN 和 PSC 寄存器一个失败与通过用例。  

此致

Mukul  

你好 Mukul Bhatnagar

eateng xu 说：

您是否可以向我们提供 PLL (主 PLL0将时钟源发送给 CAN)的寄存器转储、CAN 和 PSC 寄存器(对于失败与通过的用例)。  [报价]

我不确定如何实现这一点。 当它失败时、系统会崩溃、因此之后没有太多方法可以执行任何操作。

有了这句话,如果我是误会你的请求, 共享 一个代码片段/修补程序,它将打印此信息在控制台上使用 printk(),我们可以应用修补程序,并在我们的测试台上运行它。  如果您考虑 使用调试器、则无法轻松获得此设置(我们需要研究一些选项、但我看不到任何简单的解决方案)。

Hi-FD、

我将准备一个内核补丁来转储必要的寄存器。 我目前正在并行处理其他客户问题、因此进度可能会有点慢。

FD

很抱歉再向一个专注于 LPM 的软件开发人员提出一些建议

我们可以尝试将不活动超时设置为-1吗？ 这将禁用运行时 PM

或者、 尝试将不活动超时时间增加到50ms、而不是延迟。 它可以确保驱动器在最后一次活动50ms 后才会暂停。

再次这些只是实验,如果你更容易快速尝试,这可能会继续帮助我们缩小问题。

我还在评估,看看我们是否可以做一个快速测试我们的 EVM 下的热流在 负温度,但可能需要几天。  

Andreas Dannenberg

还有上次测试执行后的更新、我们确实运行了 Linux 内核 v6.9.0测试、但问题仍然存在。

Unknown 说：

上次测试执行后再进行一次更新、我们使用 Linux 内核 v6.9.0运行了测试、该问题仍然存在。

太好了、感谢您进行该测试。

我这边可以快速介绍一下。 上周结束时、我试图通过对驾驶员进行一些修改来重新创建问题、希望使其更有可能出现故障(至少我认为这样)、但未能取得很大进展。 本周我正在出差、因此我无法进一步调试、但 从下周一开始、我将能够再次优先处理这一问题。

此致、Andreas

Hi-FD、

在转储 PLL 寄存器之前、您能否在 DTS 中更改 MCAN REFCLK 父级、以查看崩溃是否仍然发生而没有50ms 延迟？

以下是针对 MCAN REFCLK 的 DTS 更改的参考：

diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
index 90657f5f532c..fd7b2fc4401a 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -614,3 +614,9 @@ &mcu_gpio0 {
 &mcu_gpio_intr {
        status = "reserved";
 };
+
+&main_mcan0 {
+       assigned-clocks = <&k3_clks 98 1>;
+       assigned-clock-parents = <&k3_clks 98 5>;
+       status = "okay";
+};

MCAN REFCLK 父频率5是25MHz (默认父频率为80MHz)、因此我不确定 MCAN0控制器是否仍然可以与总线上的 CAN 器件通信、但我只想查看在使用不同 REFCLK 父频率的 MCAN 初始化期间是否发生了崩溃。

额外更新、我们对单个 EVM 进行了快速测试、在 DUT 上以-40C 的温度运行热流、 10输出10引导/重启未显示 CAN 的任何故障。 在接下来的几天内、我们可能会再次进行一些自动化和片上传感器的运行、以报告温度、但初始结果与30%的故障不匹配。  

您是否比较过 EVM 与您的电路板/软件上可能有所不同的电路板/软件差异？

您好、Mukul、

eateng xu 说：

如需进行额外更新、我们对单个 EVM 进行了快速测试、在 DUT 上以-40C 运行热流、 10选10引导/reboot 未显示 CAN

通常情况下、我们在7块并行电路板的情况下运行测试至少1小时。 可能30%的重现性率分布不均匀、仅10次重新启动可能不够。 Franz Schnyder 您能在这里添加更多详细信息吗?

我意识到在驱动程序探测过程中不会发生这种问题、但这可能是 systemd 第一次在网络设备上进行某种枚举。 我假设这在您的软件上是相同的、但我可能是错的(当然、您需要在 DT 中启用 MCAN 器件、但您知道、只需编写它、因为问题很棘手、最好是确保我们不会在一些愚蠢的细节上迷路)。

eateng xu 说：

您是否对 EVM 与您的主板可能不同的电路板/软件差异进行了比较和对比？

在 Linux 内核源代码方面,没有真正显著的区别,这个问题是通过普通的 Linux 6.9.0重新出现的,而没有任何软件更改。 当然、dts 文件是不同的、并且内核配置也略有不同(启用了某些驱动程序)并且 userspace init 也不同。 总的来说、我不想详述任何具体内容。

我们对电路板的时钟和电源进行了大量验证、但我们未在其中发现任何异常。 如果有任何特定信号(功率、时钟等)可能专门对 CAN 器件产生影响、请告诉我、我们将对其进行仔细检查。 我想写一次,一旦我们禁用 CAN 一切都运行坚如磐石。

我们很快就会对您和 Bin 建议的测试进行一些更新。

Unknown 说：

通常我们在7块并行电路板上运行至少1小时的测试。 可能30%的重现性率分布不均匀、仅10次重新启动可能不够。 Franz Schnyder 您能在这里添加更多详细信息吗?[/报价]

30%是7个电路板组合在一起的平均故障率。 它并不是均匀分布。 一些模块显示的问题较少、其他模块则更常见。 测试通常运行+18h、以便具有足够的启动周期(~1000)来获得代表性结果。 仅在最新的测试中(仅启用了 MCU_mcan 或 MAIN_mcan)、或者在 Linux 6.9.0中、测试时间较短、因为问题从一开始就存在、所以没有必要再运行它。

最晚在今天或明天期待 Bin 提出的测试结果。

您是否能够启用片上温度传感器、以查看相对于温度室的相应 SOC 温度

您的较旧帖子具有以下内容  

气候室: KWP 120
启动温度：-40.3 C
结束温度：-39.8°C
测量温度：-40.3 C
货架温度：-39.5 C
货架名称：shifle_19.
模块序列号：15313474
模块位置：货架1、载板5
测试持续时间：127.82s

问题是否可以通过热复位重现、或者您是否对电路板进行下电上电？

我们运行了另一个测试、进行了大约50次重新启动、但没有出现故障、当然是单个 EVM。 冰在板上形成,所以没有计划运行长时间的测试。  

您好、Bin、

我已在 DTS 中完成所需的更改、并在/sys/kernel/debug/clk/clk_summary.中验证了更改

 clk:98:5                             0        0        0    25000000          0     0  50000         Y
    clk:98:1                          0        0        0    25000000          0     0  50000         Y

为清楚起见、我还从 DTS 中删除了 mcu_mcan0、重点关注 main_mcan0、因为您仅针对 main_mcan 发送更改。

问题仍然存在、并在同一位置发生。 故障率较低是因为问题仅在该测试中的七个模块之一发生。 我认为、两个 CAN 接口中只有一个可用、这一事实也会对故障率产生影响。

您是否能够启用片上温度传感器、以查看相对于温度室的相应 SOC 温度

您的较旧帖子具有以下内容  

气候室: KWP 120
启动温度：-40.3 C
结束温度：-39.8°C
测量温度：-40.3 C
货架温度：-39.5 C
货架名称：shifle_19.
模块序列号：15313474
模块位置：货架1、载板5
测试持续时间：127.82s

出现问题时、只有在成功启动后、我们才会读取温度。 从碰撞前后的周期来看、SoC 温度传感器报告-26°C 和-32°C 之间的温度(因模块而异、也取决于我们让模块在一个周期后冷却多长时间)。 您所显示的温度都是我们气候室中的参考温度。

eateng xu 说：

此问题是否可以通过热复位重现、或者是否对电路板进行下电上电？

执行下电上电。

eateng xu 说：

我们可以尝试将不活动超时设置为-1。 这将禁用运行时 PM

只是仔细检查一下这个。 因此、根据我在这里读取的内容、需要将 autosuspend_delay_ms 设置为-1。 是这样吗？ 只是为了检查我是否测试了正确的设置。

diff --git a/drivers/net/can/m_can/m_can_platform.c b/drivers/net/can/m_can/m_can_platform.c
index 01c363d20d3f..91a20eb3d9c2 100644
--- a/drivers/net/can/m_can/m_can_platform.c
+++ b/drivers/net/can/m_can/m_can_platform.c
@@ -154,6 +154,9 @@ static int m_can_plat_probe(struct platform_device *pdev)
        platform_set_drvdata(pdev, mcan_class);
 
        pm_runtime_enable(mcan_class->dev);
+       printk("Disabling PM Runtime");
+       pm_runtime_set_autosuspend_delay(mcan_class->dev, -1);
+       pm_runtime_use_autosuspend(mcan_class->dev);
        ret = m_can_class_register(mcan_class);
        if (ret)
                goto out_runtime_disable;

root@verdin-am62-15355727:~# cat /sys/devices/platform/bus\@f0000/20701000.can/power/*
-1
auto
351651
active
0

谢谢！

弗朗茨

我在上次测试的日志中找到了此 RCU_PREMPT 调用跟踪(如果有任何帮助)。 它设法恢复和启动、而不是像往常一样崩溃(这在过去已经出现过、但它很难恢复)。

[    5.419275] CAN device driver interface
[[0;32m  OK  [0m] Found device [0;1;39m/dev/ttyS2[0m.
[    5.518926] m_can_platform 20701000.can: m_can device registered (irq=490, version=32)
[    5.675688] Bluetooth: Core ver 2.22
[    5.706332] NET: Registered PF_BLUETOOTH protocol family
[    5.724814] Bluetooth: HCI device and connection manager initialized
[    5.780995] k3-m4-rproc 5000000.m4fss: device does not reserved memory regions, ret = -22
[    5.839607] Bluetooth: HCI socket layer initialized
[    5.846090] systemd-journald[166]: Oldest entry in /run/log/journal/d00310a14e344f619c21685c1baa4fef/system.journal is older than the configured file retention duration (1month), suggesting rotation.
[    5.851086] k3-m4-rproc 5000000.m4fss: reserved memory init failed, ret = -22
[    5.865163] Bluetooth: L2CAP socket layer initialized
[[0;32m  OK  [0m] Started [0;1;39mNetwork Time Synchronizatio[    5.880191] systemd-journald[166]: /run/log/journal/d00310a14e344f619c21685c1baa4fef/system.journal: Journal header limits reached or header out-of-date, rotating.
n[0m.
[[0;32m  OK  [0m] Reached target [0;1;39mSystem Time Set[0m.
[    5.928415] systemd-journald[166]: Oldest entry in /run/log/journal/d00310a14e344f619c21685c1baa4fef/system.journal is older than the configured file retention duration (1month), suggesting rotation.
[    5.955110] Bluetooth: SCO socket layer initialized
[    5.967373] systemd-journald[166]: /run/log/journal/d00310a14e344f619c21685c1baa4fef/system.journal: Journal header limits reached or header out-of-date, rotating.
[    5.982222] remoteproc remoteproc0: releasing 5000000.m4fss
[    5.982264] k3-m4-rproc: probe of 5000000.m4fss failed with error -22
[    6.132507] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    6.142535] rtc-ti-k3 2b1f0000.rtc: registered as rtc1
[    6.152875] platform 78000000.r5f: R5F core may have been powered on by a different host, programmed state (0) != actual state (1)
[    6.190091] platform 78000000.r5f: configured R5F for IPC-only mode
[    6.197583] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    6.204401] platform 78000000.r5f: device does not have reserved memory regions, ret = -22
[    6.213720] cfg80211: Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[    6.222416] k3_r5_rproc bus@f0000:bus@b00000:r5fss@78000000: reserved memory init failed, ret = -22
[    6.232111] remoteproc remoteproc0: releasing 78000000.r5f
[    6.238979] k3_r5_rproc bus@f0000:bus@b00000:r5fss@78000000: k3_r5_cluster_rproc_init failed, ret = -22
[    6.249375] k3_r5_rproc: probe of bus@f0000:bus@b00000:r5fss@78000000 failed with error -22
[    6.283486] pvrsrvkm: loading out-of-tree module taints kernel.
[    6.342544] lt8912 1-0048: supply vdd not found, using dummy regulator
[    6.351699] lt8912 1-0048: supply vccmipirx not found, using dummy regulator
[    6.361915] lt8912 1-0048: supply vccsysclk not found, using dummy regulator
[    6.373716] lt8912 1-0048: supply vcclvdstx not found, using dummy regulator
[    6.385568] PVR_K:  188: Device: fd00000.gpu
[    6.390439] lt8912 1-0048: supply vcchdmitx not found, using dummy regulator
[    6.398947] lt8912 1-0048: supply vcclvdspll not found, using dummy regulator
[    6.415096] PVR_K:  188: Read BVNC 33.15.11.3 from HW device registers
[    6.422348] lt8912 1-0048: supply vcchdmipll not found, using dummy regulator
[    6.436695] PVR_K:  188: RGX Device registered with BVNC 33.15.11.3
[    6.475119] [drm] Initialized tidss 1.0.0 20180215 for 30200000.dss on minor 1
[    6.482969] [drm] Initialized pvr 23.3.6512818 20170530 for fd00000.gpu on minor 0
[    6.484460] tidss 30200000.dss: [drm] Cannot find any crtc or sizes
[    6.500017] tidss 30200000.dss: [drm] Cannot find any crtc or sizes
[    6.786402] mwifiex_sdio mmc2:0001:1: info: FW download over, size 570976 bytes
[    8.199307] mwifiex_sdio mmc2:0001:1: WLAN FW is active
[    8.240413] mwifiex_sdio mmc2:0001:1: Unknown api_id: 5
[[0m[0;31m*     [0m] A start job is running for Wait for…ice Initialization (2s / 2min 58s)
M
[K[[0;32m  OK  [0m] Listening on [0;1;39mLoad/Save RF …itch Status /dev/rfkill Watch[0m.
[K[    8.281250] mwifiex_sdio mmc2:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (16.92.21.p84) 
[    8.293371] mwifiex_sdio mmc2:0001:1: driver_version = mwifiex 1.0 (16.92.21.p84) 
         Starting [0;1;39mLoad/Save RF Kill Switch Status[0m...
[   29.339185] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[   58.650207] remoteproc remoteproc0: 30074000.pru is available
[   58.653103] rcu: 	Tasks blocked on level-0 rcu_node (CPUs 0-1): P184/1:b..l
[   58.653124] 	(detected by 0, t=12581 jiffies, g=1753, q=434 ncpus=2)
[   58.653134] task:systemd-udevd   state:R  running task     stack:0     pid:184   ppid:1      flags:0x00000a04
[   58.653147] Call trace:
[   58.653151]  __switch_to+0xd4/0x130
[   58.653172]  __schedule+0x230/0x664
[   58.691519]  preempt_schedule+0x4c/0x70
[   58.691526]  _raw_spin_unlock_irqrestore+0x30/0x50
[   58.691536]  __wake_up_common_lock+0x90/0xd4
[   58.691546]  __wake_up_sync_key+0x20/0x30
[   58.691553]  sock_def_readable+0x40/0x80
[   58.691565]  __netlink_sendskb+0x6c/0xa0
[   58.691576]  netlink_unicast+0x138/0x360
[   58.691582]  netlink_sendmsg+0x1b0/0x420
[   58.691589]  ____sys_sendmsg+0x228/0x290
[   58.691596]  ___sys_sendmsg+0x84/0xe4
[   58.691603]  __sys_sendmsg+0x6c/0xd0
[   58.691609]  __arm64_sys_sendmsg+0x24/0x30
[   58.691617]  invoke_syscall+0x48/0x114
[   58.691627]  el0_svc_common.constprop.0+0xd4/0xfc
[   58.691634]  do_el0_svc+0x20/0x30
[   58.691640]  el0_svc+0x28/0xa0
[   58.691650]  el0t_64_sync_handler+0xbc/0x140
[   58.691658]  el0t_64_sync+0x18c/0x190
[[0;1;31m*[0m[0;31m*    [0m] (1 of 2) A start job is running for… RF Kill Switch Status (50s / 30s)
[   58.778725] remoteproc remoteproc1: 30078000.pru is available
M
[K[[0;1;31mFAILED[0m] Failed to start [0;1;39mLoad/Save R[   58.797733] platform sound: deferred probe pending
F Kill Switch Status[0m.
[KSee 'systemctl status systemd-rfkill.service' for details.
         Starting [0;1;39mLoad/Save RF Kill Switch Status[0m...
[[0;32m  OK  [0m] Started [0;1;39mLoad/Save RF Kill Switch Status[0m.
[[0;32m  OK  [0m] Created slice [0;1;39mSlice /system/systemd-fsck[0m.
[[0;32m  OK  [0m] Found device [0;1;39m/dev/mmcblk0p1[0m.
[[0;32m  OK  [0m] Finished [0;1;39mWait for udev To Complete Device Initialization[0m.

Unknown 说：

仅供再次查看。 因此、根据我在这里读取的内容、需要将 autosuspend_delay_ms 设置为-1。 是这样吗？ 只是为了检查我是否测试了正确的设置[/报价]

是、这是正确的设置。  

您的最后一个帖子是您能够从崩溃中恢复,完成了 Bin 的更改还是运行时暂停禁用?

eateng xu 说：

是您的最后一篇帖子、您可以通过 Bin 的更改或运行时暂停禁用功能从崩溃中恢复吗？

我上一篇文章中的日志仅与 Bin 的更改。

同时、我已经在禁用运行时暂停的情况下进行了测试、当然这两个 CAN 接口都在 DTS 中再次启用、但尚未发现任何问题。