[参考译文] UDMA 状态位文档和 PSI-L/UDMA 对等寄存器接口

您好、Arthur、

Unknown 说：

在哪里可以找到有关 uDMA 通道实时状态位寄存器(1和2)含义的文档？

您是否想了解 UDMA_｛RRT/TRT｝_Peer1和 peer_2寄存器？ uDMA 与什么配对、或者您想将 DMA 与什么外设配合使用？

Peer1和 Peer2分别对应于位于地址0x401和0x402的远程对等的 RT 寄存器。 它们对应于  PDMA PSI-L Rx 的 PDMA_PSILCFG_RX_STATIC_TR_Z (0x401)和 PDMA_PSILCFG_RX_DEBUG_1   (0x402)、PDMA PSIL-L Tx 的 PDMA_PSILCFG_TX_DEBUG_1 (0x402)。 0x401处没有用于 PDMA PSI-L Tx 的寄存器。

[报价 USERID="607901" URL="~/support/processors-group/processors/f/processors-forum/1432014/udma-status-bits-documentation-and-psi-l-udma-peer-registers-interface ]]当尝试写入任何 给定(并已配置) UDMA RX 或 TX 通道的 PEER8寄存器时收到数据中止、尽管我可以写入 CTL 实时寄存器的"Enable"字段、因为我已成功执行针对 PSI-L 线程配对和 UDMA 通道配置(TX 或 RX)向 TIFS 的 Sciclient 请求。 这种情况是如何发生的以及为什么发生的？

您尝试从哪个内核写入 PEER8寄存器、以及相关的 UDMA 通道是从该同一内核还是不同内核分配的？ UDMA RT 资源具有通道化防火墙、该防火墙将在 UDMA 通道设置功能期间进行设置、并仅为请求 UDMA 通道的处理器提供权限。

[报价 userid="607901" url="~/support/processors-group/processors/f/processors-forum/1432014/udma-status-bits-documentation-and-psi-l-udma-peer-registers-interface "]当前 Sciclient_rmPsilPsilPair 函数似乎不支持位于不同域中的 PSI-L 线程的配对、例如与 UDMAP0_STRM 目标线程(NAVSS0)配对的 MCU_UDMAP0_STRM 源线程(MCU_NAVSS0)。

您能具体指定用于此目的的 PSI-L 线程编号吗？ 相应的 uDMA 通道是否已针对主机处理器进行了分区？

[报价 userid="607901" url="~/support/processors-group/processors/f/processors-forum/1432014/udma-status-bits-documentation-and-psi-l-udma-peer-registers-interface "]存储在 NAVSS_UDMAP_0_UDMASS_UDMAP0_RCHAN_RCHAN_THREAD_j 的 thread_ID 字段中的 Thread ID 为0、即使该函数返回"SUCCESS"返回代码、也是0。 MCU_NAVSS_UDMAP_0_UDMASS_UDMAP0_RCHAN_RCHAN_THREAD_j 的 THREAD_ID 字段被置于正确的 THREAD_ID (0x6000 + ch_idx)。

我不确定你在这里要做什么? 您在查看这两个 uDMA Rx 通道时、我预计您只会使用其中一个的 uDMA Rx 通道。 我希望另一个 是 Tx。 您要尝试进行哪种类型的 uDMA 传输？

[quote userid="607901" url="~/support/processors-group/processors/f/processors-forum/1432014/udma-status-bits-documentation-and-psi-l-udma-peer-registers-interface 您能否确认最新版本的 TIFS 是否支持此功能(v10.00.08 (Fiery Fox))

根据 TISCI_MSG_RM_PSIL_PAIR 的 TIFS TI-SCI 文档、我没有看到任何这样的限制 。

但是、跨域 src 和目标的 SDK 用法非常少。 我必须仔细检查 PDK Sciclient 代码是否施加了任何限制。

此致

Suman

尊敬的 Suman：

感谢您的回答,让我来回答您的后续问题:

Eason Zhang 说：

您是想询问 UDMA_｛RRT/TRT｝_Peer1和 peer_2寄存器吗？ uDMA 与什么配对、或者您想将 DMA 与什么外设配合使用？[/QUOT]

很抱歉不够清楚、我正在查找以下未真正记录的寄存器的相关信息：

• NAVSS_UDMAP_0_UDMASS_UDMAP_TCHANRT_TCHANRT_STATUS0_j (也适用于 RX 侧)
• NAVSS_UDMAP_0_UDMASS_UDMAP_TCHANRT_TCHANRT_STATUS1_j (也适用于 RX 侧)
• NAVSS_UDMAP_0_UDMASS_UDMAP_TCHANRT_TCHANRT_stdata_j  (也用于 RX 侧)

Eason Zhang 说：

您尝试从哪个内核写入 PEER8寄存器、相关的 UDMA 通道是从该同一内核分配还是从另一个内核分配？ UDMA RT 资源具有通道化防火墙、该防火墙将在 UDMA 通道设置功能期间进行设置、并仅为请求 UDMA 通道的处理器提供权限。[/QUOT]

在成功完成来自该同一内核向 TIFS 的 Scliclient_rmUdmaTxCfg 请求后、我正在尝试通过 MCU1_0写入 MCU_UDMAP_0 TX 通道11的 RT 寄存器。 但给定我的(开发) RM 配置：

      .num_resource = 44、

      .type = TISCI_RESASG_UTYPE (TISCI_DEV_MCU_NAVSS0_UDMAP_0、TISCI_RESASG_SUBTYPE_UDMAP_TX_CHAN)、

      .start_resource = 2、

      .host_id = TISCI_host_ID_all、

信道化防火墙应在 TIFS 调用后为系统中的"all hosts" priv-id 打开、因此我认为问题不存在。 在您说过我不应该放置 TISCI_HOST_ID_ALL、因为从系统的角度来看、我知道它不安全、但它用于开发。  

Eason Zhang 说：

您能指定为此目的使用的确切 PSI-L 线程编号吗？ 相应的 uDMA 通道是否已针对主机处理器进行了分区？[/QUOT]

线程 ID 如下所示：

• 来源：CSL_PSILCFG_NAVSS_MCU_UDMAP0_TSTRM_THREAD_OFFSET + 11u (MCU TX 通道11)

  目标：CSL_PSILCFG_NAVSS_MAIN_UDMAP0_RSTRM_THREAD_OFFSET + 24U、(主 RX 通道24)

给定应用的分区、主机不应该是问题。 此外、 我可以写入位于 RT 组中的 NAVSS_UDMAP_0_UDMASS_UDMAP_TCHANRT_TCHANRT_ctl_j。

Eason Zhang 说：

我不确定您在这里要做什么？ 您在查看这两个 uDMA Rx 通道时、我预计您只会使用其中一个的 uDMA Rx 通道。 我希望另一个 是 Tx。 您要尝试进行哪种类型的 uDMA 传输？[/QUOT]

抱歉、复制粘贴操作不正确。 我想说的是、在从 MCU1_0调用 Sciclient_rmPsilPair (使用先前声明的线程 ID)后、我会在相关寄存器中获得以下结果：

• NAVSS_UDMAP_0_UDMASS_UDMAP0_RCHAN_RCHAN_THREAD_j->THREAD_ID = 0 (主 RX 通道24)、
• NAVSS_UDMAP_0_UDMASS_UDMAP0_TCHAN_TCHAN_THREAD_j->THREAD_ID = 0x600B (MCU TX 通道11

Eason Zhang 说：

然而、跨域 src 和目标的 SDK 用法却很少。 我必须仔细检查 PDK Sciclient 代码是否设置了任何限制。

[/quote]

[/quote][/quote]

[/quote][/quote][/quote]

我之所以提出这个问题、是因为在查看中 Sciclient_rmPsilPair 函数的实现时 sciclient_rm_CSL.c 文件(不是 sciclient_rm.c)、似乎不支持跨域 PSI-L 对。 但是、由于此实现从未在 PDK 中使用(我知道)、因此我真的不知道它是多最新以及它与 TIFS 的实现有多接近。

再次提前感谢您的参与和支持。

此致

[/quote][/quote][/quote][/quote]

您好、Arthur、

[报价 userid="607901" url="~/support/processors-group/processors/f/processors-forum/1432014/udma-status-bits-documentation-and-psi-l-udma-peer-registers-interface/5491205 #5491205"]

很抱歉不够清楚、我正在查找以下未真正记录的寄存器的相关信息：

• NAVSS_UDMAP_0_UDMASS_UDMAP_TCHANRT_TCHANRT_STATUS0_j (也适用于 RX 侧)
• NAVSS_UDMAP_0_UDMASS_UDMAP_TCHANRT_TCHANRT_STATUS1_j (也适用于 RX 侧)
• NAVSS_UDMAP_0_UDMASS_UDMAP_TCHANRT_TCHANRT_stdata_j  (也用于 RX 侧)

[报价]

我 在我们的 PDK UDMA 驱动程序中的任何位置都没有使用这些寄存器。 我确实浏览了一些内部文档、但也没有  在其中找到任何位字段定义。 我找到的最接近的数据是 bCDMA TCHANRT STATUS0和 STATUS1寄存器的数据、但在 STDATA 上不是任何数据。 CSL 头文件中的相应定义都是准确的并基于内部数据。

Unknown 说：

按照 TIFS 调用、系统中的"all hosts" priv-id 应打开信道化防火墙、因此我认为问题不存在。 在您说过我不应该放置 TISCI_HOST_ID_ALL、因为从系统的角度来看、我知道它不安全、但它用于开发目的[/报价]

TISCI_HOST_ID_ALL 是一个协议宏、允许从该范围中分配任何内核(如果空闲)、它通常是在查看分配给该内核的资源后的备份。 这并不意味着此类 uDMA 通道的信道化防火墙已配置所有主机的权限。 通道化防火墙仍将配置为已获取该通道的内核、因此您无法从 A72等其他内核读取这些寄存器。

是的、理想的分区应避免使用 与 TISCI_HOST_ID_ALL 相同的资源。

[报价 userid="607901" url="~/support/processors-group/processors/f/processors-forum/1432014/udma-status-bits-documentation-and-psi-l-udma-peer-registers-interface/5491205 #5491205"]

抱歉、复制粘贴操作不正确。 我想说的是、在从 MCU1_0调用 Sciclient_rmPsilPair (使用先前声明的线程 ID)后、我会在相关寄存器中获得以下结果：

• NAVSS_UDMAP_0_UDMASS_UDMAP0_RCHAN_RCHAN_THREAD_j->THREAD_ID = 0 (主 RX 通道24)、
• NAVSS_UDMAP_0_UDMASS_UDMAP0_TCHAN_TCHAN_THREAD_j->THREAD_ID = 0x600B (MCU TX 通道11

[报价]

这与预期结果相符。 目标线程 ID 仅编程到源线程(Tx Chan) thread_ID 中、目标线程用于读取能力、然后将源线程编程为匹配相应的目标线程数据。 数据从 Tx 传输到 Rx、因此 Tx 需要知道要向其发送数据包的 Rx 线程 ID。 如果希望使用未使用的 Tx 通道的线程 ID 对 Rchan_thread_j->thread_ID 进行编程。  

Unknown 说：

我之所以问这个问题、是因为在观察中 Sciclient_rmPsilPair 函数的实现方案 sciclient_rm_CSL.c 文件(不是 sciclient_rm.c)、似乎不支持跨域 PSI-L 对。 但是,由于此实现从未在 PDK 中使用(我知道),我真的不知道它是最新的,以及它与 TIFS 的实现有多接近。[/报价]

正确。 CSL 中的 Sciclient_rmPsilPair 仅作为通用参考提供、但不用于任何位置。 PSIL 配对过程只能在单个处理器(PSIL CFG 线程的所有者)上完成、这实际上是由 TIFS 固件管理的。 Sciclient RM 处理分为 DM 和 TIFS 内核、由 TIFS 内核负责 PSIL 配对和设置安全防火墙、由 DM 代码管理 RM 编程。  

此致

Suman

[/quote]

尊敬的 Suman：

再次感谢您的详尽回答。

我有一些后续问题,然后:

Eason Zhang 说：

TISCI_HOST_ID_ALL 是一个通用宏、它允许任何内核从此范围分配(如果可用)、通常在浏览分配给该内核的资源后作为备份。 这并不意味着此类 uDMA 通道的信道化防火墙已配置所有主机的权限。 通道化防火墙仍将配置为已获取该通道的内核、因此您将无法从 A72等其他内核读取这些寄存器。

我理解。 但是、我将尝试从原始 TIFS 配对和通道配置请求源自的同一内核(MCU1_0)写入该 PEER8寄存器。 你也说过:

Eason Zhang 说：

这与预期结果相符。 目标线程 ID 仅编程到源线程(Tx Chan) thread_ID 中、目标线程用于读取能力、然后将源线程编程为匹配相应的目标线程数据。 数据从 Tx 传输到 Rx、因此 Tx 需要知道要向其发送数据包的 Rx 线程 ID。 如果希望使用未使用的 Tx 通道的线程 ID 对 Rchan_thread_j->thread_ID 进行编程。  [报价]

联系回我的原始问题、

[报价 USERID="607901" URL="~/support/processors-group/processors/f/processors-forum/1432014/udma-status-bits-documentation-and-psi-l-udma-peer-registers-interface ]]当尝试写入任何 给定(并已配置) UDMA RX 或 TX 通道的 PEER8寄存器时、即使我可以写入 CTL 实时寄存器的"Enable"字段、因为我已成功执行针对 PSI-L 线程配对和 UDMA 通道配置(TX/RX)向 TIFS 发出的 Sciclient 请求、所以收到数据中止[或 RX]。

这是否意味着 RX 通道的 PEERx 寄存器本质上是不可禁用的/不具有任何用途、因为 RX 通道不需要在其寄存器中填充源线程 ID、因此解释了为什么我在尝试访问该寄存器时会收到数据中止？ 那么、当我对 TX 通道执行相同的操作时(请记住、我是从同一个内核 MCU1_0执行所有这些操作)、我会得到什么解释？

此外、您说：

Eason Zhang 说：

CSL 中的 Sciclient_rmPsilPair 仅作为通用参考提供、但不用于任何地方。 PSIL 配对过程只能在单个处理器(PSIL CFG 线程的所有者)上完成、这实际上是由 TIFS 固件管理的。[/QUOT]

以及：

Eason Zhang 说：

这与预期结果相符。 目标线程 ID 仅编程到源线程(Tx Chan) thread_ID 中、目标线程用于读取能力、然后将源线程编程为匹配相应的目标线程数据。 数据从 Tx 传输到 Rx、因此 Tx 需要知道要向其发送数据包的 Rx 线程 ID。 如果您希望使用未使用的 Tx 通道的线程 ID 对 Rchan_thread_j->thread_ID 进行编程。

[/quote]

感谢您清除所有这些信息。 在此 CSL 示例中、Sciclient_rmPsilPair 将使用其各自的预期值(RX 通道中的源线程 ID、TX 通道中的目标线程 ID)写入两个通道的 thread_ID 字段(tisci_msg_rm_psil_pair_req  结构中包含的目标线程 ID)。 只是为了确保,因为我认为你已经回答了这一点: RX 通道的 NAVSS_UDMAP_0_UDMASS_UDMAP0_RCHAN_RCHAN_THREAD_j 寄存器中的 THREAD_ID 字段是否会产生任何功能影响？ 是否需要将目标线程 ID 编程到 RX 通道的 TRHEAD_ID 字段中？

如果它确实没有任何影响、则应同时反映在 PDK 的文档/注释中、因为它应说明、例如、tisci_msg_rm_psil_pair_req 的 nav_id 成员是 TX 通道的 UDMA 实例、当前不适用。

此外,在 J784S4的寄存器电子表格中,UDMAP(MCU 和 MAIN )选项卡中也存在差异: NAVSS_UDMAP_0_UDMASS_UDMAP0_RCHAN_RCHAN_THREAD_j 寄存器说明似乎与 NAVSS_UDMAP_0_UDMASS_UDMAP0_TCHAN_TX_j 完全相同,区别被替换为 TX_THREAD_j。 这是正常的还是只是复制粘贴错误？

再次感谢您花时间和精力回答这些问题。

此致

[/quote][/quote]

您好、Arthur、

Unknown 说：

我明白。 但是、我将尝试从原始 TIFS 配对和通道配置请求源自的同一内核(MCU1_0)写入该 PEER8寄存器。 [报价]

这不应造成任何问题。 我在 udma_chEnable()中确实看到了这种用法、正如您之前所指出的。  

您尝试将此配置用于哪个渠道、并发现相关问题？ 是在 Tx 通道上还是在 Rx 通道上？ 您是否能够在代码中使用 uDMA_chEnable()？  

[报价 userid="607901" url="~/support/processors-group/processors/f/processors-forum/1432014/udma-status-bits-documentation-and-psi-l-udma-peer-registers-interface/5495275 #5495275"]这是否意味着 RX 通道的 PEERx 寄存器本质上是不可寻址/不起任何作用、因为 RX 通道不需要在其寄存器中填充源线程 ID、因此解释了为何我在尝试访问该寄存器时会收到数据中止？ 那么、当对 TX 通道执行相同操作时(请记住、我是从同一个内核 MCU1_0执行所有这些操作)、我会得到什么解释？

uDMA_chEnable()逻辑确实 使用 Rx 通道上的 PEER8寄存器。

我怀疑您在整个序列中缺少了之前的一些配置步骤。 您是否未使用 PDK UDMA 驱动程序？

Unknown 说：

RX 通道 NAVSS_UDMAP_0_UDMASS_UDMAP0_RCHAN_RCHAN_THREAD_j 寄存器中的 THREAD_ID 字段是否有任何功能影响？ 是否需要将目标线程 ID 编程到 RX 通道的 TRHEAD_ID 字段中？[/QUOT]

我认为您不需要手动设置。 当您调用 RM_PSIL_PAIR TI-SCI 消息时、TIFS 代码应自动考虑这一点。 我之前只看了 PSIL 线程配对逻辑、但我确实看到已针对 uDMA 通道进行了编程。

Unknown 说：

此外、在 J784S4的寄存器电子表格中、两个 UDMAP (MCU 和 MAIN)选项卡中都存在差异：NAVSS_UDMAP_0_UDMASS_UDMAP0_RCHAN_RCHAN_THREAD_j 寄存器说明似乎与 NAVSS_UDMAP_0_UDMASS_UDMASS_UDMASS_TX_0完全相同、差异被替换为0。 这是正常的还是只是复制粘贴错误？

RCHAN & TCHAN 寄存器(和 RCHANRT & TCHANRT)看起来非常相似、所以我怀疑说明已经被重复使用了。

此致

Suman  

[/quote]

您好、Arthur、

Unknown 说：

我的确没有使用 PDK 驱动程序、而是尝试编写轻量级驱动程序。

从头开始编写 UDMA 驱动程序是一项艰巨的任务。 请利用 PDK uDMA 驱动程序代码和示例作为参考。 我建议您阅读作为 PDK 文档一部分提供的有关 uDMA 编程典型高级步骤的 uDMA 概述培训材料。  

[报价 userid="607901" url="~/support/processors-group/processors/f/processors-forum/1432014/udma-status-bits-documentation-and-psi-l-udma-peer-registers-interface/5543355 #5543355"]当将指向 HPD 的指针推至 TX 空闲队列时、我没有在通道级别遇到任何错误(即 TCHANRT 中的错误位。 CTL 已清除)、但从不会将我的 HPD 传输到相应的 RX 通道队列[/QUOT]

HPD 将不会发送到 Rx 通道队列。 UDMA 通道分为 Tx 通道和 Rx 通道。 当推送到 TX 空闲队列时、主机数据包描述符由 UDMA 控制器 IP 进行处理、然后返回到 Tx 完成队列。  

对于 Rx 操作、同样需要将空的 HPD 描述符提交到 Rx 空闲队列、以便 UDMA 控制器接收传入的缓冲区。

如果您尝试进行存储器到存储器的 uDMA 操作、请浏览 uDMA 块复制示例代码。

我建议您通过在 TI EVM 上运行示例来浏览 UDMA 代码以了解。

BTW、您要处理的 SoC 是什么、因为 UDMA IP 有一些变体、如 BCDMA、PKTDMA 等、具体取决于 SoC。

此致

Suman