[参考译文] PROCESSOR-SDK-AM437X：Remoteproc 在启动期间启动非常晚

您好 Eduardo、

您能给我们详细介绍一下 PRU 在您的用例中正在做什么吗？ 例如 PRU 以太网？ 您是否正在运行自定义固件？ 您的定制固件是否与引脚多路复用等交互？

TI 仅在 Linux 引导期间验证了使用 Remoteproc 来初始化 PRU。

您可能会想到以下几种方案：

1)缩短总体启动时间(这不是我的专业知识,但我可以根据需要重新分配您的线程)

2)在内核引导流程中较早地探测 PRU Remoteproc 驱动程序(我尚未尝试这样做、不确定我们对时序控制的程度)

3)在 uboot 期间初始化 PRU。 TI 不支持这一点、但我知道一些 AM335x 客户当时能够破解 uboot 来初始化其 PRU 内核。 我在我可以提供的帮助中会受到限制、但如果您想尝试一下、我可以四处探索并尝试给您一些建议。

此致、

Nick

您好、Nick、

感谢您的意见。

我们使用定制的 PRU 固件、该固件与通过 DTS 文件(pinctrl-single、pins)中的 AM4372_IOPAD 配置的引脚进行交互(我不是 DTS 文件方面的专家)。 我们的主应用程序当前通过 用户空间中的"/sys/class/remoteproc/remoteproc1管理 PRU (固件加载和启动)。 当前实现有效、但仅在 Remoteproc 启动并运行后运行、这种情况发生得非常晚。 我们的电路板使用 AM4376ZDN。

我一直在从 TI 学习以下文档：

• RemoteProc 和 RPMsg

基于此、我想知道我们可以更早地使用自定义固件初始化 PRU。

1)同意,这是我一直在努力,我已经得到了一些 systemd 改进,不幸的是, remoteproc 似乎是最后初始化的模块之一。 这是接下来要查看的内容、并查看哪个 systemd 服务正在启动   Remoteproc。

2)好主意,我还没有做那神秘的,但我会试一下;我想这是受到 systemd 的影响。

3)有趣的想法,我会记住这一点。

此致、

Eduardo

您好 Eduardo、

以下是一些可能有用的附加线程：

启用 PRU 内核的自动引导、因此在探测到 Linux Remoteproc 驱动程序时就会加载固件、而不是等待用户空间应用  

这可能是最快的尝试方法、修改 Linux 驱动程序并重新编译内核/内核模块：

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/943886/re-am4376-linux-5-4-how-to-auto-load-pru-firmware/3490293#3490293 

看起来内核5.10使用与5.4相同的基本驱动程序结构、因此您可以对进行相同的更改
board-support/linux-5.10.100+gitAUTOINC+7a7a3af903-g7a7a3af903/drivers/remoteproc/PRU_rproc.c

        /*
         * rproc_add will auto-boot the processor normally, but this is not
         * desired with PRU client driven boot-flow methodology. A PRU
         * application/client driver will boot the corresponding PRU
         * remote-processor as part of its state machine either through the
         * remoteproc sysfs interface or through the equivalent kernel API.
         */
        /*rproc->auto_boot = false; */
        rproc->auto_boot = true;

其他可能有用的链接

在 uboot 期间引导 PRU  

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1254407/am3358-prevent-pru-from-stopping-during-kernel-boot

自动引导 PRU 内核的选项-自定义 Linux 驱动程序  

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/634904/linux-am3358-running-pru-remoteproc-at-boot-time

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/909445/tmdsidk574-pru-not-started-when-linux-boots

您好、Nick、

谢谢、您的建议看起来非常有前景！

我找到了您在 board-support/linux-5.10.100+gitAUTOINC+7a7a3af903-g7a7a3af903/drivers/remoteproc 中提到的代码、并添加了相同的更改以及调试 消息：

	 * remoteproc sysfs interface or through the equivalent kernel API.
	 */
	/* rproc->auto_boot = false; */
	rproc->auto_boot = true;
	dev_info(dev, "auto_boot = true - pdev->name %s fw_name %s\n", pdev->name, fw_name);

我运行了一个完全干净的 Yocto 构建、以确保将内核中的这些更改包含在最终图像中、但我没有看到 dmesg 消息、并且 Remoteproc 仍然没有尽快启动。 我肯定是在 做一些错误的事情、明天我会继续调查。 我仍然希望这是正确的解决方案。

感谢您发送所有这些有用的链接。

此致、

Eduardo

您好、Nick、

我终于能够测试这种变化。 PRU 自动引导会正常运行、但遗憾的是、Remoteproc 初始化仍 发生延迟、例如：

[   26.650399] pru-rproc 54434000.pru: auto_boot = true - pdev->name 54434000.pru fw_name am437x-pru1_0-fw
[   26.650670] remoteproc remoteproc1: 54434000.pru is available
[   26.650957] remoteproc remoteproc1: Direct firmware load for am437x-pru1_0-fw failed with error -2
[   26.650982] remoteproc remoteproc1: powering up 54434000.pru
[   26.651032] remoteproc remoteproc1: Direct firmware load for am437x-pru1_0-fw failed with error -2
[   26.651045] remoteproc remoteproc1: request_firmware failed: -2

但没关系、至少现在我知道  Remoteproc 源代码在内核中的位置。 我认为问题与 systemd 有关,我将继续调查更多.

您好 Eduardo、

很高兴听到您正在取得进展。 对于自动引导、Linux 错误2表示 Remoteproc 驱动程序未在其查找位置找到要下载的固件。

Remoteproc 根据 Linux 器件树中的固件名称在/lib/firmware 下的文件系统中查找固件：
arch/arm/boot/dts/am4372.dtsi

                                pru1_0: pru@34000 {
                                        compatible = "ti,am4376-pru";
                                        reg = <0x34000 0x3000>,
                                              <0x22000 0x400>,
                                              <0x22400 0x100>;
                                        reg-names = "iram", "control", "debug";
                                        firmware-name = "am437x-pru1_0-fw";
...
                                };

                                pru1_1: pru@38000 {
                                        compatible = "ti,am4376-pru";
...
                                        firmware-name = "am437x-pru1_1-fw";
etc

我通常喜欢单独保留固件名称、只需 将一个名为 AM437X-pru1_0-FW 等的符号链接添加到指向我的实际固件的/lib/firmware 上。 例如：

$ cd /lib/firmware
$//假设您将固件放在/lib/firmware/pru 中
$ ln -sf /lib/firmware/pru/my_pru_firmware_1_0.out  AM437X-pru1_0-FW

祝你好运 systemd。

此致、

Nick

您好、Nick、

感谢您的解释和建议。

感谢您指出有关 am4372.dtsi 的详细信息。  符号链接是一个伟大的想法。

快速更新：

目前、我禁用了 PRU auto_boot 并实现了一个 systemd 服务、该服务 更早地启动 Remoteproc 内核模块、但我仍在尝试：

[Service]
Type=oneshot
StandardOutput=tty
ExecStart=insmod /lib/modules/5.10.100-g7a7a3af903/kernel/drivers/soc/ti/pruss.ko
ExecStart=insmod /lib/modules/5.10.100-g7a7a3af903/kernel/drivers/remoteproc/pru_rproc.ko

它似乎正在正确初始化：

[    4.912645] systemd[1]: Mounted Kernel Configuration File System.
[    5.378262] pru-rproc 54434000.pru: pru_rproc_probe: auto_boot = 0 - pdev->name 54434000.pru fw_name am437x-pru1_0-fw
[    5.378534] remoteproc remoteproc0: 54434000.pru is available
[    5.381422] pru-rproc 54438000.pru: pru_rproc_probe: auto_boot = 0 - pdev->name 54438000.pru fw_name am437x-pru1_1-fw
[    5.381641] remoteproc remoteproc1: 54438000.pru is available
[    5.386933] pru-rproc 54474000.pru: pru_rproc_probe: auto_boot = 0 - pdev->name 54474000.pru fw_name am437x-pru0_0-fw
[    5.387176] remoteproc remoteproc2: 54474000.pru is available
[    5.391009] pru-rproc 54478000.pru: pru_rproc_probe: auto_boot = 0 - pdev->name 54478000.pru fw_name am437x-pru0_1-fw
[    5.393881] remoteproc remoteproc3: 54478000.pru is available
[    5.403963] systemd[1]: start-pru.service: Succeeded.
[    5.427885] systemd[1]: Started PRU modules startup service.

这仍然是一个正在进行的工作,但我只是想给你一个快速的更新。

此致、

Eduardo

您好 Eduardo、

很高兴听到事情正在为您前进! 我对 systemd 没有太多的经验,所以我不能在那里提供帮助,但我感谢更新。

如果弹出了有关 PRU 或硬件行为的其他问题、请告诉我。

此外,只是供参考:团队和我 正在工作的一个 PRU 学院全年。 目标是让 PRU 入门实验深入探讨 PRU 子系统以及如何编写 PRU 代码(例如、读取/写入、GPI/GPO、INTC、宽边加速器、 Linux + PRU 等)：
https://software-dl.ti.com/processor-sdk-linux/esd/AM437X/09_03_05_02/exports/docs/common/PRU-ICSS/PRU-Getting-Started-Labs.html

如果您对现有 PRU 体验有任何反馈、欢迎您收看。 我将重点介绍 AM243x/AM64x、AM263x 和 AM62x 等最新器件、但 AM62x 上的大多数概念也适用于 AM335x/AM437x/AM57x。

此致、

Nick

您好、Nick、

谢谢！

我现在面临的一个问题是、在用户空间中尝试通过 sysfs 加载固件时出现这个错误：

[   11.825878] pru-rproc 54438000.pru: can't change firmware while running

在 systemd 上进行更改之前、相同的代码运行良好、在  引导期间、我提前很多时间启动 pruss.ko 和 PRU_rproc.ko 模块。 似乎另一个 PRU 固件已在运行。 我会继续调查更多。

好的、我将开始查看该链接、因为它与我现在正在处理的内容有关。

非常好、PRU 学院一定会 对所有开发人员非常有帮助。  非常感谢您和参与 PRU Academy 的 TI 团队、非常感谢！

此致、

Eduardo

您好 Eduardo、

嗯、是的、这似乎表明固件已在 PRU 内核上运行。 我当前没有 AM437x 运行、因此我将展示 AM62x 的一些终端输出。

首先、我假设您在启动过程中仍然启用了打印功能？ 如果 PRU Remoteproc 驱动程序实际上正在将固件加载到 PRU 内核中、我希望您看到 Remoteproc 驱动程序输出。

以下是一些在调试时可能会有所帮助的 Linux 命令：

root@am62xx-evm:~# dmesg | grep remoteproc
...
[    8.259308] remoteproc remoteproc2: 30074000.pru is available
[    8.270489] remoteproc remoteproc3: 30078000.pru is available

root@am62xx-evm:~# head /sys/class/remoteproc/remoteproc*/name
...
==> /sys/class/remoteproc/remoteproc2/name <==
30074000.pru

==> /sys/class/remoteproc/remoteproc3/name <==
30078000.pru

root@am62xx-evm:~# cat /sys/class/remoteproc/remoteproc2/state
offline
root@am62xx-evm:~# cat /sys/class/remoteproc/remoteproc2/firmware
am62x-pru0-fw
root@am62xx-evm:~# ls -al /lib/firmware/
total 25496
...
lrwxrwxrwx  1 root root      51 Mar  9  2018 am62x-pru0-fw -> /usr/lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0.out
lrwxrwxrwx  1 root root      51 Mar  9  2018 am62x-pru1-fw -> /usr/lib/firmware/pru/PRU_RPMsg_Echo_Interrupt1.out

此致、

Nick

您好 Eduardo、

很高兴听到事情正在为您工作!

我将此线程标记为已解决、因为好像您在引导过程的早期就已成功初始化 PRU。 如果我们需要对该主题进行更多讨论、请随时在此处继续讨论。

如果您对 PRU 入门实验室有任何反馈意见或问题、请创建新的 e2e 主题并在那里咨询。

此致、

Nick

您好、Nick、

非常感谢您的帮助、Nick！ 我可能仍在此处提供有关 PRU 调查的更多更新信息。

此致、

Eduardo

您好、Nick、

由于此问题与 之前启动 Remoteproc 有关、我想在此发帖。  如果您愿意、我可以创建新对话。

之前、我一直在进行 A/B 测试、但没有启动 Remoteproc。

早期：

[   66.377976] virtio_rpmsg_bus virtio0: rpmsg host is online
[   66.378154]  remoteproc1#vdev0buffer: registered virtio0 (type 7)
[   66.378170] remoteproc remoteproc1: remote processor 54438000.pru is now up

延迟：

[  135.989416]  remoteproc1#vdev0buffer: registered virtio0 (type 7)
[  135.989444] remoteproc remoteproc1: remote processor 54434000.pru is now up
[  136.007425] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x20
[  136.008337] virtio_rpmsg_bus virtio0: rpmsg host is online
[  136.071744] rpmsg_pru virtio0.rpmsg-pru.-1.32: new rpmsg_pru device: /dev/rpmsg_pru32

我正在尝试弄清为什么使用早期的 Remoteproc 启动时、 在 PRU 成功启动后没有看到新的 rpmsg_PRU 器件：/dev/rpmsg_pru32。

4月4日更新 :现在似乎很明显,但问题在于对 sys 类 remoteproc 处理程序的 PRU 内核分配。 由于某种原因,在早期的开始, remoteproc1被分配到 54438000.pru,但在后期开始时, remoteproc1被分配到54434000.pru。 我们的用户空间代码依靠该路径 /sys/class/remoteproc/remoteproc1来加载和启动 PRU、但实际的 PRU 内核在这两种情况下都不同。 我还没有机会验证为什么只能使用 54434000.PRU 内核来处理 rpmsg_PRU 器件、但一旦我将路径更改为 /sys/class/remoteproc/remoteproc0、rpmsg_PRU virtio0.rpmsg-PRU 就开始处理早期的 remoteproc start。

最后要做的改进是 更快地启动 rpmsg_PRU virtio0.rpmsg-PRU、截至目前、用户空间代码在 创建 rpmsg_PRU virtio0.rpmsg-pru-1.32之前进行很少的 sys 尝试：

[   48.735769] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x20
[   48.736029] virtio_rpmsg_bus virtio0: rpmsg host is online
[   48.736149]  remoteproc0#vdev0buffer: registered virtio0 (type 7)
[   48.736167] remoteproc remoteproc0: remote processor 54434000.pru is now up
[   48.810940] rpmsg_pru virtio0.rpmsg-pru.-1.32: new rpmsg_pru device: /dev/rpmsg_pru32

此致、

Eduardo