[参考译文] AM5728：DSP 固件交换

软件团队已收到通知。 他们将在这里作出回应。

是否有更新？

此外、当我切换固件映像时、从 Remoteproc 内核日志记录的角度来看、所有内容都是相同的、无论我是从固件"A"到固件"B"、还是从固件"A"到固件"A"。 问题是当我开始使用 IPC/MessageQ 时-它就好像在内部 Remoteproc 内核处于错误状态、在~15秒后修复了自身。

Gerard、

这是一种奇怪的行为。 我已经联系过内核开发人员、并将让您了解他们返回的内容。

您能否在代码中提供'A'和'B'固件之间的任何增量、从而导致首次使用 IPC/MessageQ？

Jason Reeder

Gerard、

其中一个开发人员认为 根本原因是用户空间在重新建立用于查询名称服务器请求的套接字时重复尝试，特别是在存在打开的应用程序时。 以前在错误恢复中也出现过类似的行为。

在解除绑定和绑定操作期间，您是否在用户空间中有任何尝试使用通信通道主机端的开放应用程序/进程？

Jason Reeder

关于固件"A"和"B"的差异：

固件"A"和"B"软件在我们在本主题中讨论的时间段内本质上具有等效的功能-这两个过程都要经过一些硬件设置过程、然后空闲、等待 IPC/MessageQ 通信。 两个固件映像都在执行这方面的通用代码。 固件映像会发生变化并开始执行自定义功能、直到稍后(一旦 IPC/MessageQ 启动并运行)。

关于在解除绑定/绑定期间可能尝试使用通信通道主机端的任何其他进程：

否、现在对于此受控测试、我们仅运行与 IPC/MessageQ 交互的单个应用程序。 长期来看、我们将有2个此应用的实例-每个 DSP 1个-但现在它只是单个实例。

 

其他信息：

下面是该过程中添加的更多详细信息：

1. 新加电
2. Shell 脚本在启动时执行
   1. 将 DSP1固件 symlink 设置为固件"A"
   2. 加载 rproc/rpmsg 内核模块、使用固件"A"自动加载 DSP1 (注意：DSP1、IPU1和 IPU2固件不存在、因此它们超时)
   3. 休眠10秒钟
   4. 通过取消绑定节点关闭 DSP1 (为了节省功耗-我们可能在几分钟后不再需要它)
   5. 启动 IPC 守护程序

3. 自定义应用程序启动(仅与远程处理器/IPC/MessageQ/ETC 进行交互的项目)
   1. 将 DSP1固件 symlink 设置为固件"B"
   2. 通过绑定节点为 DSP1加电
   3. 等待 /sys/bus/platform/drivers/omap-rproc/40800000.dsp 显示在文件系统上(我尝试知道 DSP1何时准备就绪)
   4. 休眠1500ms (我发现无法信任上面的节点是 DSP1准备就绪的指示-将其更改为15000ms "修复"固件开关问题)
   5. 启动 IPC/MessageQ (如示例应用)
      1. IPC_START()
      2. 创建主机队列(MessageQ_create())
      3. 开放从队列(MessageQ_open()-这是最终失败的结果-软件会以 MessageQ_open()尝试 DSP1从队列的方式无延迟循环)
      4. 将初始 MessageQ 消息发送到 DSP1
      5. (笑声)

希望这将会使您的工作更加轻松。

谢谢

内核日志提供了切换固件映像时我看到的额外延迟：

 

案例1 - DSP1加载了固件"A"、停止并重新加载了固件"A"：

[222.564962]  remoteproc2：已停止远程处理器40800000.dsp

[222.571247]  remoteproc2：发布了40800000.dsp

[223.593908]  remoteproc2：提供40800000.DSP

[223.598903]  remoteproc2：注意：remoteproc 仍在开发中并被视为实验。

[223.607932]  remoteproc 2：二进制格式尚未最终确定、并且尚不能保证向后兼容性。

[223.653173]  remoteproc2：为40800000.DSP 加电

[223.658121]  remoteproc2：引导 FW 映像 dra7-dsp1-fw.xe66，大小为15366040

[223.672422] omap_hwmod：mu0_dsp1：_wait_target_disable 失败

[223.678325] OMAP-iommu 40d01000.MMU：40d01000.MMU：版本3.0

[223.684267] OMAP-iommu 40d020.MMU：40d020.MMU：版本3.0

[223.804556]  remoteproc2：远程处理器40800000.DSP 现已启动

[223.811750] virtio_rpmsg_bus virtio0：rpmsg 主机处于联机状态

[223.817296]  remoteproc2：registered virtio0 (type 7)

[223.869634] virtio_rpmsg_bus virtio0：创建通道 rpmsg-proto addr 0x3D

案例2 - DSP1加载了固件"A"、停止并重新加载了固件"B"：

[116.642082]  remoteproc2：已停止远程处理器40800000.dsp

[116.648215]  remoteproc2：发布了40800000.dsp

[117.667211]  remoteproc2：提供40800000.DSP

[117.672227]  remoteproc2：注意：remoteproc 仍在开发中并被视为实验。

[117.681253]  remoteproc 2：二进制格式尚未最终确定、并且尚不能保证向后兼容性。

[123.636295]  remoteproc2：为40800000.DSP 加电

[123.641146]  remoteproc2：引导 FW 映像 dra7-dsp1-fw.xe66、大小为17317496

[123.655324] OMAP-hwmod：mu0_dsp1：_wait_target_disable 失败

[123.661227] OMAP-iommu 40d01000.MMU：40d01000.MMU：版本3.0

[123.667164] OMAP-iommu 40d020.MMU：40d020.MMU：版本3.0

[123.782077]  remoteproc2：远程处理器40800000.DSP 现已启动

[123.789302] virtio_rpmsg_bus virtio0：rpmsg 主机处于联机状态

[123.794868]  remoteproc2：注册的 virtio0 (类型7)

[123.847911] virtio_rpmsg_bus virtio0：创建通道 rpmsg-proto addr 0x3D

您可以看到、在第二种情况下、DSP 可用与远程处理器框架启动上电序列之间的时间接近6秒。

同样、如果您对问题有任何意见、我们将不胜感激。

谢谢

Gerard、

如果您多次重新加载固件"A"、则未看到这6秒延迟、对吧？ 如果您多次解除绑定并绑定固件"B"、那么每次看到的延迟是否相同？

这两个固件的资源表之间是否有任何增量、或者它们是否相同？ 两者之间的代码大小差异如何？

我假设您的原始问题(nameserver_attach 连接失败和 MessageQ_open()循环) 是固件"B"加载并联机所需的时间超过6秒的症状。 你同意吗？

我正在询问开发人员、他们是否知道导致此类延迟的原因、我将在您发布时向他们转发您的回复。

Jason

[引用用户="Jason Reeder"]

如果您多次重新加载固件"A"、则未看到这6秒延迟、对吧？ 如果您多次解除绑定并绑定固件"B"、那么每次看到的延迟是否相同？

[/报价]

正确、我在反复重新加载相同固件时没有看到6秒延迟。

[引用用户="Jason Reeder"]

这两个固件的资源表之间是否有任何增量、或者它们是否相同？ 两者之间的代码大小差异如何？

[/报价]

资源表是相同的。 xe66文件大小为14.7 MB 与16.5 MB。

[引用用户="Jason Reeder"]

我假设您的原始问题(nameserver_attach 连接失败和 MessageQ_open()循环) 是固件"B"加载并联机所需的时间超过6秒的症状。 你同意吗？

[/报价]

是的、完全正确！

我想我看到现在发生了什么：第一次加载固件文件时、似乎会出现较大的延迟。 换言之、在从固件"A"初始转换到固件"B"后、后续转换很快-我想这是因为某种级别的缓存。

因此、这让我想知道应用软件是否有一种编程方法来知道何时可以安全地启动 IPC。 我不想再延迟6秒、以应对希望不常发生的情况。 应用软件是否可以最大限度地缩短从加电/加载给定 DSP 到开始 IPC/MessageQ 通信之间的时间？

谢谢  

Gerard、

开发人员同意文件的读取是在此花费时间的地方。 您的文件系统从何处访问？ NFS？ SD 卡？

我仍在等待一种编程方法的响应、以确保固件已加载并运行、并将在我获得固件时告知您。

Jason Reeder

[引用用户="Jason Reeder]Gerard、

开发人员同意文件的读取是在此花费时间的地方。 您的文件系统从何处访问？ NFS？ SD 卡？

[/报价]

正在从 eMMC 之上的 EXT4文件系统访问 DSP 固件。

感谢您的支持！

Gerard、

减小所加载固件的尺寸(希望缩短加载时间)的一个步骤是去除符号和调试信息、因为固件类将复制整个固件。 是否可以尝试使用-p 选项运行 strip6x 命令以减小构建的固件映像大小？

在可编程检查固件加载完成端、remoteproc 内核首先使用异步固件加载、因此您实际上不能使用绑定的器件来表示 remoteproc 已完成引导(如您所见)。 有一个 debugfs‘state’变量(在/sys/kernel/debug/remoteproc/remoteprocN/state 上)提供了 Remoteproc 的状态， 但是，即使在远程处理器从重置状态释放后，也会将其标记为已完成(不能准确地表示 remoteproc 启动本身已完成，但应比当前使用的绑定开始更近)。

在 userspace 中、MessageQ_open 上的任何重试都应使用延迟、否则您将持续触发一组名称服务器请求(我认为这是您已经看到的内容)。

rpmsg 设备本身在引导期间从远程处理器端发布，然后绑定到 rpmsg-proto 驱动程序。 带有特定处理器的 MessageQ 堆栈只有在相应的 rpmsg-proto 设备绑定到 rpmsg-proto 驱动程序后才会启动。 用户可以间接使用此绑定器件状态、但否则、没有更简单的方法来实现此目的。

Jason Reeder

[引用用户="Jason Reeder"]
减小所加载固件的尺寸(希望缩短加载时间)的一个步骤是去除符号和调试信息、因为固件类将复制整个固件。 是否可以尝试使用-p 选项运行 strip6x 命令以减小构建的固件映像大小？
[/报价]

很好的建议；我们将对此进行实验。 此外、我将首先将所有固件映像传输到 RAM (tmpfs)、以便它们从 RAM 传输到 RAM、而不是从 ext4 eMMC 传输到 RAM。 我将报告结果。

[引用用户="Jason Reeder"]

在 userspace 中、MessageQ_open 上的任何重试都应使用延迟、否则您将持续触发一组名称服务器请求(我认为这是您已经看到的内容)。

[/报价]

我在请求之间确实有延迟-我基本上从 IPC/MessageQ 演示中传递了 LOOP /延迟逻辑。 如果在 DSP 完全通电之前调用 IPC/MessageQ 函数、IPC/MessageQ 似乎永远不会恢复。

感谢这些建议，我将再次报告。

Gerard