[参考译文] AM62A7-Q1：具有自定义构建固件的 SDK 11.01.07.05 — 缺少 rpmsg 端点

尊敬的 Bas：

一些启动问题、以便我更好地了解情况（是的，我以前见过这样的问题，但在我的 11.1 中我不知道）：

1. 在这里失败的始终是相同的 rpmsg 端点吗？
2. 问题是否始终是同一个核心？
3. 您能否确认使用的是更新的固件、以及 SDK 中提供的固件？  
   1. 我想在库存 SDK 上自行重现此问题。 脚本是在 u-boot 还是 Linux 终端中运行？ 该 IP 地址是发送到台式 PC 还是 EVM？ 我需要更多的信息来尝试这个自己
4. 您的引导分区中 uEnv.txt 的内容是什么？
5. 您能否从发生此问题的场景中共享 u-boot / linux-boot 日志？

我估计在启动/连接 Remoteproc 内核时、此问题从引导流程中的某个位置开始

BR、
Reese

尊敬的 Reese：

1. 在这里失败的始终是相同的 rpmsg 端点：是的、始终  缺少 virtio1.rpmsg_crdev.–1.13 和 virtio1.ti.ipc4.ping-pong.–1.21。
2. 问题是否始终是同一个内核：是的、它始终是 virtio1、即容纳 VPAC 组件的 DM-R5。
3. 您能否确认您使用的是更新的固件与 SDK 中包含的固件：我为 DDR_SHARED_MEMORY (252MB、而不是默认固件使用的 172MB) 构建了一个具有扩展内存区域的自定义固件。 我可以提供固件构建器的补丁（以及用于构建所有内容的脚本）。
   a.我在引导期间在电路板上运行了一个脚本、用于检查所有 12 个 rpmgs 端点是否存在、如果其中一个或多个端点缺失、则会触发看门狗重新启动。 在 u-boot 中、我向引导序列添加了一条（自定义）命令、用于检查看门狗复位状态并将其记录在变量中。 该变量由我的 boot 命令用作内核命令行参数（0 =冷启动、1 =热启动、2 =看门狗复位）。
   上面的命令会检查内核命令行以查看我们是否进行了看门狗复位、然后重新启动电路板、并一直这样做。
4. 您的引导分区中 uEnv.txt 的内容是什么：我们不使用 uEnv.txt、但 edgeai dtso 和摄像头 dtso 包含在我们的器件树中。
5. 可以从发生此问题的场景中共享 u-boot /linux 引导日志吗：
   e2e.ti.com/.../7271.boot.log

希望这对您有所帮助。 我还没有尝试在 EVM 上重现问题。

此致、

Bas Vermeulen

我刚才在 EVM 上重现问题、并能使用 11.1：

我用于检查 rpmsg 端点的脚本存在于 EVM 上（另存为/usr/bin/check-multiscaler.sh）

e2e.ti.com/.../check_2D00_multiscaler.txt

然后、在连接到与 EVM 相同网络的计算机上使用以下命令行：

errors=0；count=0；true 时；执行 ssh root@172.16.40.136 /usr/bin/check-multiscaler.sh；if [$? -eq 1 ];然后让 errors=$errors+1 ; break; fi; ssh root@172.16.40.136 reboot ; let count=$count+1; sleep 20;回显“Cycle $count, Errors $errors“; 已完成

我使用使用使用固件构建器构建的映像、这会触发每两次重新启动。

此致、

Bas Vermeulen

尊敬的 Reese：

使用上述脚本和命令行、我在具有 11.1.7.5 版本的 EVM 上重现了问题。

此致、

Bas Vermeulen

你好 BAS ,这是非常有帮助,包括,非常感谢。  

[引述 userid=“590891" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1630014/am62a7-q1-sdk-11-01-07-05-with-custom-built-firmware---missing-rpmsg-endpoints/6285258

使用上述脚本和命令行、我在具有 11.1.7.5 版本的 EVM 上重现了问题。

[/报价]

您说的是 11.1.7.5、指的是该版本的库存 TI SDK、对吗？ 不存在更新的固件？ 这是否发生频率相似、或者这里需要明显更多的迭代才能重现？  

应该知道、这是一个误差（它本身随机显示）相对于显示问题的核心和端点具有确定性。 有趣的是、virtio1（DM R5 内核）的一些端点确实已填充。 我看到`发现: virtio1.rpmsg_chrdev.–1.14`,然而,  

我来尝试使用库存 SDK`复制这一个

我注意到您的日志与默认情况下看到的内容：  

[ 6.098001] virtio_rpmsg_bus virtio1: creating channel ti.ipc4.ping-pong addr 0xd
...
[ 6.111720] virtio_rpmsg_bus virtio1: creating channel rpmsg_chrdev addr 0xe 
### Missing one additional rpmsg_chrdev channel creation

# In my stock SDK , default shows

[    7.162291] virtio_rpmsg_bus virtio1: creating channel rpmsg_chrdev addr 0xd
...
[    7.169565] virtio_rpmsg_bus virtio1: creating channel rpmsg_chrdev addr 0xe
[    7.183379] virtio_rpmsg_bus virtio1: creating channel ti.ipc4.ping-pong addr 0x15

这里需要更多的分析,但我越来越怀疑 DM R5 上存在某种程度的竞争条件,因此 PingPong 端点实际上是首先设置的。 也许这只是抓取第一个地址打开并阻止另一个 rpmsg_chrdev 0xd（因此–1.13）被创建。  

尊敬的 Reese：

您说的是 11.1.7.5、表示该版本的 TI SDK 库存、对吗？ 不存在更新的固件？ 这是否发生频率相似、或者这里需要明显更多的迭代才能重现？  [/报价]

是的、这是现货 11.1.7.5 TI SDK、现已下载、不存在更新的固件。 我很幸运、在这方面、它在一次重新启动后触发、  

重试几次、通常会在一次或两次重新引导后触发。

尊敬的 Bas：

我已经能够触发类似的,虽然不是完全相同的问题（至少在第一次发生时,你的脚本注意到了一个问题  

Found: virtio0.rpmsg_ctrl.0.0
Found: virtio0.rpmsg_ns.53.53
Found: virtio0.rpmsg_chrdev.-1.14
Found: virtio1.rpmsg_ctrl.0.0
Found: virtio1.rpmsg_chrdev.-1.13
Found: virtio1.rpmsg_chrdev.-1.14
Found: virtio1.rpmsg_ns.53.53
Found: virtio1.ti.ipc4.ping-pong.-1.21
Found: virtio2.rpmsg_chrdev.-1.14
Found: virtio2.rpmsg_ctrl.0.0
Found: virtio2.rpmsg_ns.53.53

Summary: Found 11 of 14 required files
Missing required rpmsg devices:
  - virtio0.ti.ipc4.ping-pong.-1.13
  - virtio2.rpmsg_chrdev.-1.13
  - virtio2.ti.ipc4.ping-pong.-1.21

System needs reboot

所以我已经看到 virtio 数字与核心/远程处理器是不确定的。 在这种情况下、C7x DSP 是 virtio0、我更常在其中查看是否为 virtio2。 同样, MCU R5 的 virtio 也 发生了变化（对于这个框架不是那么重要,但仍然值得注意）。  

我看到的是、乒乓端点有时会接管端点 ID（例如，有时在–1.21（即地址 0x15）、有时在–1.13（即地址 0xd）。  

我在此处看到的场景中、TIOVX / GStreamer /TIDL 应用仍按预期运行、因此没有看到功能错误。 `  ` rpmsg_char_simply -r 8 -n 10 k Ω 测试未为我完成、这可能与乒乓端点有关

在您的情况下、您是否看到缺少的 DM R5 端点会导致应用级故障？ 我可以使用该脚本运行更多测试、看看是否可以重现相同的失败端点

尊敬的 Reese：

它用于导致应用程序级别失败、这就是我们设置脚本以检查所有端点是否具有正确名称的原因。

我将尝试禁用它、并检查应用程序是否失败。

Bas

我修改了我的测试脚本,以检查不同的端点是否独立于 virtio。 这似乎正常工作。 如果端点略有不同、VPAC 仍能正常工作、因此这样很好。 很抱歉混淆。

此致、

Bas Vermeulen