This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] Linux/PROCESSOR-SDK-AM335X:计时器中断会定期停止且系统无响应

Guru**** 2562120 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/623397/linux-processor-sdk-am335x-timer-interrupts-stop-and-system-becomes-unresponsive-periodically

器件型号:PROCESSOR-SDK-AM335X

工具/软件:Linux

大家好、

我们有一个使用 AM335x SoC 的定制板。 系统会不时地(很难重现)进入 gp_timer 中断完全停止的状态、因此如果我发出命令 cat /proc/interrupts、gp_timer 上的中断数量将保持不变。

进入此状态后、相关器件进入一种状态、在特定时间内无响应、然后再次响应。 它没有响应的时间几乎恒定、大约为1分钟55秒。 当系统再次响应时、系统时间跳回62秒、恰好62秒后系统再次冻结。

一旦处于此状态、串行控制台根本不响应-我连接到设备 vi ssh、在这种状态下、我会遇到冻结、然后可靠地跳回日期。

我在描述此问题的论坛上找到了一个主题、但未发布解决方案。 该主题是 e2e.ti.com/.../2108951

还有人注意到这种行为了吗?

提前感谢

Hamish

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    这是哪个内核? 您能总结一下将 TISDK 移植到定制板所做的更改吗?

    此致、
    Yordan
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Yordan、您好!

    我们看到的内核问题是4.1.13。 我们使用 Yocto 构建我们的系统。 我们使用 的是标准/BeagleBone 分支上的 git://git.yoctoproject.org/linux-yocto-4.1.git 内核 repo。 遗憾的是、我没有完整的平台移植流程历史、因为我仅在一年前加入了该团队、但该项目在2013年启动。

    此致、
    Hamish

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Yordan、您好!

    我已设法深入了解移植过程的更多历史。 项目启动时、在 BeagleBone 器件上评估了 AM335x、并在该点使用了 Yocto Denzil。 我们开发了定制硬件、并且在第一个原型到达后、便开始了移植。 此时、内核为3.2.23 - linux-ti33x-PSP。 我们的定制硬件主要基于 AM335x-EVM、但我们添加了 Altera Cyclone FPGA 以及支持 PTP 的 PHY、此外、我们还添加了 Modbus 支持和其他一些令我难以忘怀的项目、 但正如我说过的、它主要基于 EVM。 FPGA 连接到 GPMC 总线、因此引脚多路复用与 EVM 不同、NAND 引脚多路复用与 EVM 也稍有不同。

    原始端口在本地存储库中完成、并直接修改了 am335xevm 代码库。 随着端口的发展、开发人员不断更新 Yocto、并像 Yocto 发布的那样凸点内核版本。 随着端口的成熟、开发人员越来越难以将更改集成到较新的内核版本中、在该阶段、SVN 正用于项目。 然后决定切换到 git、并为定制板创建了新的 Yocto 层、并根据当时的 TI 内核创建了补丁、这些补丁存储在层元数据中。

    2014年的某个时候、决定使用 Yocto 内核恢复、而不是 Linux-ti33x-PSP。 开发工作继续进行、内核更新频率相对较高、但保守。

    我们在市场上拥有的两款产品基于去年秋季发布的平台版本、其中包含4.1.13内核。 这两种产品都出现了所描述的问题、但正如我所说、这并不常见、我们想尝试了解问题的原因、我们能够通过将设备的时钟同步到 PTP 时钟、立即恢复处于此状态的设备、 这只是在 clock_realtime 上执行 clock_settime 调用。 我想我们可以使用任何对 clock_settime 的调用、但是、我们知道、这种情况很少发生、以至于我没有太多机会尝试其他机制来恢复它们。

    我现在已经使用实时时钟编写了代码来生成中断、以便我可以检查 gp_timer 中断是否已锁定、 如果有、我可以远程通知发生了这种情况、因此我将使用4.1.13内核将多个器件置于长期运行的测试中。

    我们还有2个开发分支、一个位于4.1.35内核上、另一个位于4.8.13内核上(我们将很快更新到4.9.x)。 我还对我们的补丁进行了彻底修改、以便对现有 EVM 代码库进行补丁、包括电路板检测代码、以便我们实际上能够针对电路板以及 BeagleBone 和 EVM 运行 u-boot 和内核二进制文件。 这意味着、如果 AM335x 代码库中有任何更改、我们会在补丁无法应用时立即看到它们、并且能够根据更新的内核版本重新构建我们的补丁。

    我们在这两个较新的分支机构都没有看到这种现象,但我必须很快补充,我们在这两个分支机构中都没有长期的测试,所以我不能排除这些分支机构也会出现这种问题。 我正在设置基础架构、以便我将在4.1.35和4.8.13内核版本上运行一些器件、并运行长期测试、同时准备好故障检测代码。

    我非常好奇、此主题中确切地报告了此问题:

    e2e.ti.com/.../2108951

    但从未有任何关于解决这一问题的结论性报告。

    我再次感谢您对这个问题的关注。

    Hamish

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    很抱歉耽误你的回答。 让我进一步检查一下。

    此致、
    Yordan
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Yordan、您好!

    我渴望获得任何其他信息。

    此致

    Hamish