[参考译文] AM6442：通过 A53运行 Linux 的从 SRAM 运行 R5

您好、Tony、

存储器映射布局中的该图像显示了默认的存储器分配、但这并非所需的存储器分配。

AM64x Academy 多核模块将在下周左右的某个时间上线。 在 AM62x Academy 多核模块变为可用状态之前、您可以让客户参考 AM62x Academy 多核模块的"如何分配存储器"页
https://dev.ti.com/tirex/explore/node?node=A__AZgEw2fWxmvPzpRgXlGAMQ__AM62-ACADEMY__uiYMDcq__LATEST

您应该能够将定义的 SRAM 存储器区域传递到 Linux devicetree 文件节点中、就像定义的 DDR 存储器区域一样。

此致、

尼克

Nick、

感谢您的回复。

是否也可以在运行 Linux 的 A53时在 SRAM 上分配 IPC 存储器？ 我猜是的。

您好、Tony、

这是一个包含复杂答案的简单问题。

您能否在此处提供有关用例的更多详细信息？ 例如、

1)您说的是用于 Linux <-->远程核心通信的 RPMSg IPC VRingS?
2) 2)您是否在谈论远程内核之间的 IPC？ (即不使用 Linux)？
3) 3)或者我们是否在讨论其他类型的 IPC？
4) 4)是否有特定的时序注意事项？
等等

如果您谈论的是 RPMsg IPC VRINGS：  

请记住这一点：

1) AM64x SRAM 仅为2MB、Linux 与1个远程内核之间的 RPMsg IPC VRINGS 默认占用1MB (因为总共512个缓冲区、每个方向256个缓冲区)。  也许有 一种方法可以通过减少缓冲器数量来减小尺寸,但上次我尝试减少 Virtio 缓冲器的数量时,它不起作用。 这将需要额外的开发工作。

2)我们只测试了进入 DDR 的 RPMSg IPC VRNG。 可能是一个问题、导致我们无法将这些缓冲器放置在 SRAM 中、但我无法准确地告诉您相关信息。

此致、

尼克

此处 可能 是一种通过减少缓冲区数量来减小大小的方法，但我上次尝试减少 Virtio 缓冲区的数量却没有成功。 这将需要额外的开发工作。

展望未来、它将起作用、我的客户案例仅需要512字节缓冲器。

附加问题、默认情况下、IPC 共享存储器不可缓存。 如果在 MCU 端代码中启用缓存至 IPC 共享存储器、是否需要在 A53 Linux 端进行额外配置？

您好、Tony、

只是为了澄清一下：如果您要求在 SRAM 中的 Linux 和远程内核之间设置 RPMsg IPC VRING、那么这种做法不受支持、而且无论我们是否能够减少 Virtio 缓冲区的数量、这种做法甚至都不可能实现。

通常、您不希望将共享内存设置为可高速缓存。 每当 R5F 检查其他人是否已写入存储器时、您都希望 R5F 实际外出读取存储器区域、而不是仅 读取其缓存并假设数据尚未更新。

此致、

尼克

每当 R5F 检查是否有人写入内存时，您希望 R5F 实际输出并读取内存区域，而不是仅 读取其缓存并假定数据尚未更新时。

在 R5F 端、在读取之前添加缓存失效以确保读取物理存储器、情况如何？

您好、Tony、

我认为这应该可行、但我需要将您的问题转给另一位员工进行验证。

在我介绍您的主题之前、您能帮助我理解将 IPC 内存区域设置为可缓存的用例吗？ 这种存储器访问优化是否是某种存储器访问优化、在短期内您会尝试通过将传入的 IPC 数据存储在缓存中而不是复制到本地存储器来节省存储器？

此致、

尼克

Nick、

背面接地是这个岗位：

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1300848/am6442-throughput-between-ipc-memory-and-sram

如果可以利用可缓存 IPC 存储器、那么将 IPC 共享存储器放置在何处无关紧要、因为即使将其放置在 DDR 上、吞吐量也足够快。

您好、Tony、

啊，还可以。  Anil 是我会问的缓存操作是如何工作的、所以我让他来评论另一个线程。

由于您将使用  ipc_rpmsg_echo 示例、我假设您在两个 MCU+内核之间讨论 IPC。

在查看这些测试时、我们会想到几个问题：

1) 1)内核如何通知内核共享存储器数据已就绪？ 我假设 IPC_Notify 最大程度地减少通知延迟？

2) 2)这里的延迟注意事项是什么？

例如、您是否正在尝试尽可能缩短 从发送内核发送 IPC Notify 通知数据已就绪到接收内核实际读取数据之间的延迟？

您是否关心延迟、只是想尽量减少 R5F 用于读取数据的时钟周期？

如果延迟无关紧要、您只是想最小化 R5F 进行读取或写入的时钟周期、那么高速缓存失效/读取高速缓存操作可能是个好主意(具体取决于 CacheP_inv / CacheP_wbInv 实际工作方式)。 但是、如果延迟需要关注、您实际上可能会也可能没有看到使用高速缓存带来的好处。

此致、

尼克

Nick、

我们提供了详细信息、其中延迟和吞吐量对于实时用例都很重要。 客户将对其进行评估和比较。

现在我们可以在 R5F 内核上使用 RTOS 的缓存 API、如何 在 A53 Linux 到 IPC 存储器上启用缓存并实现缓存一致性？

您好、Tony、

这听起来不错。

我并不十分熟悉 Linux 与缓存的具体交互方式。 高级用户空间应用代码在发送和接收常规的 RPMsg 消息时无需担心缓存管理。

但是、它看起来就像我们使用零占空比示例进行一些缓存一致性管理：
https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/

来自 https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/tree/linux/README.md

We're doing a very basic cache coherency management with the help of
*DMA_BUF_IOCTL_SYNC* ioctl before and after accessing the mmapped area.

它引用的行在此处：
https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/tree/linux/src / rpmsg_char_zerocopy.c#n226

这是否意味着 DDR 存储器区域 实际上已 移至本地缓存、对 DDR 存储器区域的任何读取操作都将实际从本地缓存而不是 DDR 进行读取？ 这些同步是否就是为了超级安全？ 我不确定的那部分。

此致、

尼克

您好、Tony、

我在度假直到明天、因此我现在提供快速响应、我将有更多时间在星期五查看此内容。 如果我在星期一之前未再次回复、请 Ping 该主题。

AM64x Academy

首先、请注意 AM64x Academy 多核模块现已在线！ 客户使用以下工具可能会更容易：
https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AbwqjEswy38Z6lZWYQC-5g__AM64-ACADEMY__WI1KRXP__LATEST 

回答问题

这里有几个潜在的问题。 我没有发布的 SRAM 示例、我现在可以为您指出、因此我们必须一起完成。

首先、如果我回忆正确、在客户的器件树中修改的保留存储器部分专门用于 DDR。 您可以在 am64-main.dtsi 文件中找到 SRAM 分配。 因此、如果客户要添加 SRAM 分配、则需要将其添加到 SRAM 节点而不是 DDR 节点。

其次、请注意、我们仅测试了1MB Virtio 部分在 DDR 中工作、而不是在 SRAM 中工作。 我不确定资源表是否也需要位于 DDR 中、或者它是否可以进入 SRAM 中。 但这是另一项要测试的内容。

第三、 除非进行修改以添加资源表、否则 Linux Remoteproc 将无法加载 GPIO_LED_BLINK。 请参阅 AM64x Academy、多核模块页面"远程内核上的应用开发"
https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AeMVTHckwFDmFoNkRHpRPw__AM64-ACADEMY__WI1KRXP__LATEST 

此致、

尼克

再需注意的一点是、对于 GPIO_LED_BLINK 示例、应在 Linux devicetree 中禁用远程内核正在使用的 GPIO 模块。 请参阅 https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/09_01_00_41/exports/docs/api_guide_am64x/EXAMPLES_DRIVERS_GPIO_INPUT_INTERRUPT.html 上的注释

此致、

尼克

在此处继续与客户进行讨论：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1312501/am6442-how-to-implement-a-linux-system-boot-r5f-cpu-project-running-on-msram

此致、

尼克