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.

[参考译文] PRU-SWPKG:PRU 对主机存储器的访问

Guru**** 2595805 points
Other Parts Discussed in Thread: PRU-SWPKG, PROCESSOR-SDK-AM437X

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/642081/pru-swpkg-pru-access-to-host-memory

器件型号:PRU-SWPKG
主题中讨论的其他器件: PROCESSOR-SDK-AM437X

您好!


基于 此线程 、我将通过向 RAM 上的已知地址写入值来调试在 PRU 上运行的代码。 我正在使用 devmem2实用程序读取值。

介绍 PRU

#define debug *(volatile unsigned int *) 0x54440FD0
debug = 0xDEADBEEF; 

在 ARM 上

devmem2 0x54440FD0 


这适用于测试。 但我有几个问题:

1.在生产中、PRU 和 ARM 之间的数据通信可以使用相同的方法吗?


2.我们直接访问内存而不是恐吓内核,这是一件安全的事情吗? 如果内核将此内存分配给另一个应用程序、该怎么办?


 技术参考手册的30.3.1.2节"本地数据存储器映射  "说明 PRU 可以从0x0008_0000地址访问外部主机存储器、但是我无法从0x0008_0000访问外部主机存储器。 但我可以在0x54440FD0处访问它。 如何找到地址映射 b/w ARM 和 PRU (以便可以在应用中使用)?

谢谢

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

    PRU-SWPKG 已停产。 此功能现已集成到 TI 处理器 SDK 中。 请参阅 processors.wiki.ti.com/.../PRU-ICSS_Getting_Started_Guide ARM 和 PRU 之间的通信基于 Remoteproc/RPMsg 框架、请参阅 processors.wiki.ti.com/.../PRU-ICSS_Remoteproc_and_RPMsg
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    你(们)好
    感谢您的回复。

    我应该将此查询放入 PROCESSOR-SDK-AM437X 器件中吗?
    我们使用了 Remoteproc/RPMsg 框架,它运行正常。 但是、通过此框架发送的消息比 ARM 和 PRU 通过 RAM 地址进行直接通信占用更多的时钟周期。 由于 PRU 正在处理一项时间关键的任务、我们希望它尽可能地向前发展。 此外、处理 RPMsgs 所占用的空间(占用约1.5KB)为应用其余部分留下的空间更小。
    那么、我们想知道是否有方法来确定原始问题中提到的映射? 我们是否会遇到损坏另一个应用程序的风险?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我已要求 PRU 专家发表意见。 他们将在这里作出回应。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Puneeth、

    很抱歉耽误了我的时间,我在过去两周离开了我的办公桌。

    [引述]1. 我是否可以在生产中对 PRU 和 ARM 之间的数据通信使用相同的方法?

    在生产环境中使用此通信的决定由您决定。 许多生产系统会从文件系统中删除/dev/mem 器件、因为它可以读取/写入器件的完整存储器映射、这会带来安全风险。 但是、/dev/mem 仅在以 root 身份运行时可用、因此如果有人对您的现场系统具有 root 访问权限、那么您很可能会担心更大的安全问题。

    [引述]2. 我们直接访问存储器而不是恐吓内核、这是一件安全的事情吗? 如果内核将此内存分配给另一个应用程序、该怎么办?

    如下面的存储器映射响应中所示、在这种情况下使用的存储器位于 PRU-ICSS0中 PRU0的数据 RAM 中。 除非您使用的是 TI 提供的 PRU 以太网 Linux 驱动程序(我不认为您是)、否则 Linux 不应使用 PRU-ICSS 内的任何存储器。

    如果您选择在 DDR 存储器中共享地址(0x8000_0000或更高版本)、那么是的、您需要让 Linux 知道不要将该存储器部分用于任何其他内容。 如有必要、可通过简单的器件树节点来实现这一点、但在您当前的用例中不需要这样做。

    [引述]3.  技术参考手册的30.3.1.2节"本地数据存储器映射  "说明 PRU 可以从0x0008_0000地址访问外部主机存储器、但是我无法从0x0008_0000访问外部主机存储器。 但我可以在0x54440FD0处访问它。 如何找到地址映射 b/w ARM 和 PRU (以便可以在应用中使用)?

    在 AM437x 器件中、PRU-ICSS 的全局启动存储器位置为0x5440_0000 (如 TRM 开头部分2.1.1中的 L3存储器映射中所示)。 表30-6中显示的偏移量是 PRU-ICSS 的存储器出现在全局存储器映射中的位置。 以您的0x54440FD0地址为例:

      0x5440_0000 (PRU-ICSS 外设启动的全局存储器位置、来自 TRM 中的表2-1)

    + 0x0004_0000 (从 TRM 中的表30-6中删除了 PRU-ICSS0 DRAM 0的全局存储器映射启动偏移量)

    + 0x0000_0FD0 (PRU-ICSS0 DRAM 0末尾的地址偏移量0xFD0)

    ----------------------------------------------------

    0x5444_0FD0 (PRU-ICSS0 DRAM 0地址0xFD0的全局存储器映射位置)

    ARM 内核只能使用全局存储器映射来访问存储器。 因此、0x5444_0FD0地址是 ARM 内核唯一读取或写入该位置的方法。

    但是、PRU 内核可以使用全局地址或本地地址(您和我在 https://e2e.ti.com/support/arm/sitara_arm/f/791/p/619957/2287114#2287114之前简要讨论过)。 同一 PRU-ICSS 中的内核使用偏移0x0000_2000到达另一个内核的 DRAM。 不同 PRU-ICSS 中的内核使用偏移0x0004_0000到达其他 PRU-ICSS 的基址(在 TRM 中的表30-5中提到)。

    以下是每个内核可用于访问完全相同存储器位置(位于 PRU-ICSS0 DRAM 0中)的地址细分:

    ARM 内核-> 0x5444_0FD0 (全局存储器映射位置)

    PRU-ICSS0 PRU0 -> 0x5444_0FD0 (全局存储器映射位置*)

    PRU-ICSS0 PRU0 -> 0x0000_0FD0 (本地数据存储器映射位置(相同 ICSS、相同内核的 DRAM)

    PRU-ICSS0 PRU1 -> 0x5444_0FD0 (全局存储器映射位置*)

    PRU-ICSS0 PRU1 -> 0x0000_2FD0 (本地数据存储器映射位置(相同的 ICSS、不同内核的 DRAM)

    PRU-ICSS1 PRU0 -> 0x5444_0FD0 (全局存储器映射位置*)

    PRU-ICSS1 PRU0 -> 0x0004_0FD0 (本地数据存储器映射位置**(其他 ICSS))

    PRU-ICSS1 PRU1 -> 0x5444_0FD0 (全局存储器映射位置*)

    PRU-ICSS1 PRU1 -> 0x0004_0FD0 (本地数据存储器映射位置**(其他 ICSS))

    *从 PRU 的角度来看、这些全局访问将退出 PRU-ICSS 并在共享存储器总线上路由回 PRU-ICSS。 因此、这些访问比本地访问花费的时间更长、并且确定性更低。

    **在 AM437x 器件上使用两个 PRU-ICSS 之间的存储器桥时发现一个芯片错误。 桥上的4字节读取和写入将正常工作、但超过4字节的突发读取和写入将无法正确完成。 此 e2e 帖子解释了更多内容: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/624669/2303523#2303523

    希望这能解答您的映射问题。

    Jason Reeder

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

    感谢您的回复、它消除了我对 PRU 地址映射的所有疑虑。