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.

[参考译文] PROCESSOR-SDK-AM64X:在运行时启动 R5f remoteproc

Guru**** 2457540 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1482330/processor-sdk-am64x-starting-r5f-remoteproc-at-runtime

器件型号:PROCESSOR-SDK-AM64X

工具与软件:

尊敬的 TI 团队:

我目前正在研究在 AM64x 上启动 R5f 内核的不同方式。

根据我们要在早期启动(U-Boot) R5f 内核以使其尽快启动并运行的用例、但我们可能还想在 Linux 已经运行时(尤其是在开发过程中)稍后启动 R5f 内核。

直到 Processor SDK 10.00之前、我曾能够删除/lib/firmware 中的链接以使 R5f 内核"离线"。 此时我可以修改/sys/class/remoteproc/remoteprocX 中的 Remoteproc "固件"和"状态"条目来引导 R5f 内核。 该方法的唯一问题是群集中的第二个内核不会有 Remoteproc 条目。

使用 Processor SDK 10.01时、如果 Linux 在引导过程中无法找到固件、则 R5f 内核的 Remoteproc 条目将完全丢失。

  • 什么是"预期"行为? 我是否能够在运行时启动 R5f 内核? 或者这是否仅在启动期间受支持?
  • 是否存在从10.00到10.01的已知/有意回归?

此致、

Dominic

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

    脚注 Dominic: 请记住、AM64x Linux SDK 正在从 Linux 6.6迁移到6.12、因此预计会有一些影响。

    供参考

    吉姆

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

    您好、Dominic:

    问得好。 在运行时而不是在启动时期间引导内核绝对是一个有效的用例。 我尚未对 SDK 10.1进行测试、但我们没有有意更改从 SDK 10.0到 SDK 10.1延迟远程内核初始化的行为。

    我唯一能想到的就是在 SDK 10.0中引入了一个错误、其中正常关机被破坏了。 该错误已在 SDK 10.1中修复。 但我不确定引入错误的补丁是否可能改变了 R5F 初始化的工作方式...

    我能否让您发布可正常工作但无法正常工作的案例的终端输出?

    目前修复 SDK 11.0为时太晚、但如果有问题需要修复、我们可以开始针对 SDK 11.1进行修复。

    此致、

    Nick

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

    这是一个好主意,

    我使用最新的 CI/CD 快照运行了另一个测试:

    https://software-dl.ti.com/cicd-report/linux/index.html?section=snapshot&platform=am64xx&snapshot=cicd.scarthgap.202502261418

    似乎这可以解决所有问题。 即使在 Linux 启动过程中未加载固件、我也可以看到全部四个 R5f 内核。

    -> 当 SDK 11.00将被发布用于 AM64x 时,您有什么估计吗?

    此致、

    Dominic

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

    您好、Dominic:

    再次感谢您报告和提供日志。

    在不与开发人员核实的情况下、您报告的 SDK 11.0行为正是我希望看到的(并且预计基于我在过去几年中对 PRU 内核进行的测试)。 如果定义了 devicetree 节点、我会希望分配 remoteprocX、以便在运行时加载固件。

    我预计 AM64x Linux SDK 11.0将于3月底或4月推出。 我们将在本周结束开发工作、因此从现在到发布、它将进行测试和错误修复。

    让我来运行开发团队的观察结果。 如果在下一个版本中已经修复了该行为、那很好、但务必记录您的观察结果、以便将来有人在 SDK 10.x 上遇到相同问题时可以参考。 理想情况下、我希望我们了解为什么会观察到该行为、这样我们就不会在将来的版本中意外地再次将其分解。

    此致、

    Nick

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

    您好、Nick。

    让我来运行开发团队对您的观察。 如果在下一个版本中已经修复了该行为、那很好、但务必记录您的观察结果、以便将来有人在 SDK 10.x 上遇到相同问题时可以参考。 理想情况下、我希望我们了解为什么会观察到该行为、这样我们就不会在将来的版本中意外地再次将其分解。

    是的、非常好。 我们可以随时解决问题、但确保这在未来的版本中始终有效将大有裨益。 如果你能够找出这个问题的所在/是什么修复了它,那将是很棒的,因为我们可以确保这不会击中我们的定制版本,例如在客户项目中的主线内核。

    此致、

    Dominic

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

    您好、Dominic:

    好的、据我所知、这种行为是在 SDK 9.2/10.0左右添加的(我目前没有时间跟踪确切的补丁)。 我们向 R5F rproc 驱动程序添加了一些额外代码、用于在该时间范围内为某些非 AM64x 处理器处理内核开启/关闭操作、而该代码打破了一些障碍:

    R5F 内核正常关闭在 AM64x SDK 10.0中中断、但修复了从 SDK 10.1开始的问题。 未来的读者、可以在 AM64x Academy 的 SDK 10.0版本中找到相关文档: https://dev.ti.com/tirex/explore/node?a=WI1KRXP__10.00.00.01&node=A__AdAyuKWUWVV5j4wBc7C6XA__AM64-ACADEMY__WI1KRXP__10.00.00.01

    看起来您发现了另一个损坏的功能-如果 Linux 没有找到固件、它将在 Remoteproc 驱动程序中终止、而从未完成对内核的注册。 我被告知预计 SDK 9.2 - SDK 10.1会出现错误行为。

    SDK 11.0的修复方法如下所示:
    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/remoteproc?h=ti-linux-6.12.y-cicd&id=141dc8410ea2828f00a851e557f1f903293a44c1 

    此致、

    Nick