[参考译文] 66AK2H06：QMSS 有问题

admin

Guru**** 2619895 points

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/659342/66ak2h06-problem-with-qmss

器件型号：66AK2H06

大家好、团队、

您能帮我们解答客户的问题吗？

他们无法在 Linux 上启动 qmss。

Linux 使用 keystone-uio.dtsi、其中：

uio_qmss：qmss｛

兼容="ti、uio-module-drv"；

MEM =<0x02a00000 0x00100000

0x23a00000 0x00200000>；

}；

在 k2hk uio.dtsi 文件中、不会重新定义此段

在文档中： documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt

qmss：qmss@2a40000｛

兼容="ti、keystone-qms"；

DMA 相干；

此部分通过 keystone-k2hk)-netcp.dtsi 进行拉取

在 Keystone 2中 QMSS 模块的文档中、基址 0x02a00000 更改为 0x02a40000

问题：
如上所述、出现以下消息的原因(尝试打开 QMSS 传输时)：

TransportQmss 版本：0x02000001

版本字符串：Linux IPC transports Revision：2.0.0.01：2018年1月23日：19：13：09

进程1：已初始化的 RM_Client0

流程1：打开 RM 客户端套接字/var/run/rm/rm_client0

FW_memMap：找不到用于映射0x02a00000的 FD。

过程1：创建 TransportQmss 实例

FW_memMap：找不到用于映射0x02a00000的 FD。

TransportQmss_create：mpm_transport_open 失败

名称="arm-qmss-generic"、msg_size=4096、rm_service_h=0x830f68

错误进程1：创建 TransportQmss 句柄失败

编辑：即使在对地址进行手动更改后，/dev/qmss 仍然不会显示。
问题2：
/dev/qmss 何时出现？应加载哪个驱动程序？

“rmServer.out /usr/bin/device/k2h/global-resource-list.dtb /usr/bin/device/k2h/policy_dsp_arm.dtb”-启动时没有出现错误。

提前感谢您！

Ilya。

8 年多前

0 admin 8 年多前

TI__Guru**** 2619895 points

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

您好、Ilya、

地址差异是指寄存器的不同位置。请参阅数据表中的器件存储器映射以及多核导航器用户指南的第5.3节"存储器映射"。

您是否能够运行任何 QMSS_LLD ARM 示例、qmInfraDmaMC_K2H.out、qmInfraDmaSC_K2H.out 或 qmQAllocTest_K2H.out？它们位于 tisdk-server-ext-rootfs-image-k2hk-evm.tar.xz 文件系统中。我使用了 procSDK 4.1版本中的映像、而不是下载最新的4.2。我能够在 ARM 上运行多核 DMA 示例。

root@k2hk EVM：/usr/include/ti/drv/rm/device/k2h rmServer.out global_resource-list.dTB policy_dsm_arm.dtb
正在启动 rmServer.out
守护程序返回0作为返回值。
root@k2hk EVM：/usr/include/ti/drv/rm/device/k2h qmInfraDmaMC_K2H.out
未提供命令行。放弃4个任务
coreNum：1；pid=926
coreNum：0；pid=925
coreNum：2；pid=927
coreNum：3；pid=928

已初始化 RM_Client0

已初始化 RM_Client1

已初始化 RM_Client2

已初始化 RM_Client3

内核0：获取 CMEM CMA physy 0x87cc00000；virt bbb6d16000
内核0：映射0x02a00000处来自/dev/qmss 的1048576字节
内核0：映射0x23a00000处来自/dev/qmss 的1048576字节
线程优先级设置为99
内核1：获得 CMEM CMA physy 0x87cc00000；virt bbb6d16000
内核1：映射0x02a00000处来自/dev/qmss 的1048576字节
内核1：映射0x23a00000处来自/dev/qmss 的1048576字节
线程优先级设置为99
内核2：获得 CMEM CMA physy 0x87cc00000；virt bbb6d16000
内核2：映射0x02a00000处来自/dev/qmss 的1048576字节
内核2：映射0x23a00000处来自/dev/qmss 的1048576字节
线程优先级设置为99
内核3：获得 CMEM CMA physy 0x87cc00000；virt bbb6d16000
内核3：映射0x02a00000处来自/dev/qmss 的1048576字节
内核3：映射0x23a00000处来自/dev/qmss 的1048576字节
线程优先级设置为99
已成功打开 RX QPEND 队列665
已成功打开 UIO DEV /dev/uio3
内核0：我的 Rx 队列：665

------------ 正在初始化---
已成功打开 RX QPEND 队列663
已成功打开 UIO DEV /dev/uio1
内核1：我的 Rx 队列：663
内核0：插入内存区域0
已成功打开 RX QPEND 队列664
已成功打开 UIO DEV /dev/uio2
酷睿2：我的 RX 队列：664
已成功打开 RX QPEND 队列662
已成功打开 UIO DEV /dev/uio0
内核3：我的 Rx 队列：662
内核0：插入内存区域1
核心0：Tx 完成队列编号：9025已打开
核心0：请求的 Tx 描述符数：32。分配的描述符数：32
核心0：请求的 Rx 描述符数：32。分配的描述符数：32
核心0：请求的同步自由描述符数：32。分配的描述符数：32
核心0：同步队列编号：9026已打开
核心0：同步配置队列编号 :898已打开
核心0：同步可用队列编号：８９７打开
核心0：接收空闲队列号：8928已打开
核心0：传输空闲队列号：７３６个已开放
核心0：系统初始化完成：736
核心0：发布共享队列的 RM 名称服务器名称
内核0：获取其他内核的接收队列
核心1：RX 可用队列编号：8928已打开
酷睿2：RX 空闲队列号：8928已打开
Core 3：RX Free Queue Number ：8928已打开
核心1：Tx 可用队列编号：７３６个已开放
核心2：Tx 可用队列编号：７３６个已开放
核心3：Tx 可用队列编号：７３６个已开放
核心1：Tx 完成队列编号：9025已打开
核心2：Tx 完成队列编号：9025已打开
核心3：Tx 完成队列编号：9025已打开
核心1：同步队列编号：9026已打开
Core 2：同步队列编号：9026已打开
Core 3：同步队列编号：9026已打开
Core 1：同步可用队列编号：８９７打开
Core 2：同步可用队列编号：８９７打开
Core 3：同步可用队列编号：８９７打开
核心1：同步配置队列编号 :898已打开
核心2：同步配置队列编号 :898已打开
核心3：同步配置队列编号 :898已打开
内核1：在663上等待数据包
内核2：等待664上的数据包
内核3：等待662上的数据包
内核0：内核1的 RX QID：663
内核0：内核2的 RX QID：664
内核0：内核3的 RX QID：662

---------- 队列状态核心0-----------------
初始化之后

TX 空闲队列736条目计数 :32.
RX 空闲队列8928条目计数 :32.
TX 完成队列9025条目计数：0
同步队列9026条目计数：0
同步空闲队列897条目计数 :29.
同步配置队列898条目计数：3.
----------------------------------------

核心0：打开的 Tx 通道 :16.
核心0：打开的 Rx 通道 :16.
内核0：发送队列编号：816
核心0：接收队列编号：665
核心0：打开的 Rx 流 :16.

核心0：传输8个数据包.........

(小部分
核心0：打开的 Tx 通道 :16.
核心0：打开的 Rx 通道 :16.
内核0：发送队列编号：816
核心0：接收队列编号：663
核心0：打开的 Rx 流 :16.

核心0：传输8个数据包.........

(小部分
内核1：获取中断-进程8
内核1：有8个数据包
内核1：等待 SYNC 信号
核心0：打开的 Tx 通道 :16.
核心0：打开的 Rx 通道 :16.
内核0：发送队列编号：816
核心0：接收队列编号：664
核心0：打开的 Rx 流 :16.

核心0：传输8个数据包.........

(小部分
内核2：获取中断-进程8
内核2：有8个数据包
内核2：等待 SYNC 信号
核心0：打开的 Tx 通道 :16.
核心0：打开的 Rx 通道 :16.
内核0：发送队列编号：816
核心0：接收队列编号：662
核心0：打开的 Rx 流 :16.

核心0：传输8个数据包.........

(小部分
内核3：获取中断-进程8
内核3：有8个数据包
内核3：等待 SYNC 信号
内核0：等待665上的数据包
内核0：获得中断-进程8
内核0：有8个数据包
内核1：获得 SYNC 信号
内核3：获得 SYNC 信号
(小部分
(小部分

内核2：获得 SYNC 信号
(小部分

内核0：等待 SYNC 信号
内核0：获得 SYNC 信号
(小部分

---------- 队列状态核心0-----------------
数据包处理之后

TX 空闲队列736条目计数：0
RX 空闲队列8928条目计数 :32.
TX 完成队列9025条目计数 :32.
同步队列9026条目计数：4.
同步空闲队列897条目计数 :24.
同步配置队列898条目计数：4.
----------------------------------------

内核0：等待其他内核获取 SYNC 信号
内核0：找到插孔
核心1：接收空闲队列已成功关闭。参考计数：3.
核心3：接收空闲队列已成功关闭。参考计数：2.
核心2：接收空闲队列已成功关闭。参考计数：1.
核心0：接收空闲队列已成功关闭。参考计数：0
内核1：传输完成队列已成功关闭。参考计数：3.
内核3：传输完成队列已成功关闭。参考计数：2.
核心2：传输完成队列已成功关闭。参考计数：1.
核心0：传输完成队列已成功关闭。参考计数：0
核心1：传输空闲队列已成功关闭。参考计数：3.
核心3：传输空闲队列已成功关闭。参考计数：2.
核心2：传输空闲队列已成功关闭。参考计数：1.
核心0：传输空闲队列已成功关闭。参考计数：0
Core 1：同步队列已成功关闭。参考计数：3.
Core 3：同步队列已成功关闭。参考计数：2.
Core 2：同步队列已成功关闭。参考计数：1.
核心0：同步队列已成功关闭。参考计数：0
Core 1：同步空闲队列已成功关闭。参考计数：3.
Core 3：同步空闲队列已成功关闭。参考计数：2.
Core 2：同步空闲队列已成功关闭。参考计数：1.
核心0：同步空闲队列已成功关闭。参考计数：0
Core 1：同步队列已成功关闭。参考计数：3.
Core 3：同步队列已成功关闭。参考计数：2.
Core 2：同步队列已成功关闭。参考计数：1.
核心0：同步队列已成功关闭。参考计数：0
核心0：CPPI CPDMA 已成功关闭
核心0：CPPI 退出成功
磁芯0：清洁区域
内核1：CPPI CPDMA 已成功关闭
核心1：CPPI 退出成功
内核1：退出 QMSS
内核3：CPPI CPDMA 已成功关闭
核心3：CPPI 退出成功
内核3：退出 QMSS
内核2：CPPI CPDMA 已成功关闭
核心2：CPPI 退出成功
内核2：退出 QMSS
(三
***** QMSS 多核(1)示例完成(通过)*****
(三
(三
***** QMSS 多核(3)示例完成(通过)*****
(三
(三
***** QMSS 多核(2)示例完成(通过)*****
(三
内核0：退出 QMSS
核心0：删除共享队列的 RM 名称服务器名称
(三
***** QMSS 多核(0)示例完成(通过)*****
(三
等待孩子离开
所有儿童都通过了考试
root@k2hk EVM：/usr/include/ti/drv/rm/device/k2h

您可能需要检查与该示例不同的做法。

雷克斯

0 admin 8 年多前

TI__Guru**** 2619895 points

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

尊敬的 Rex：

非常感谢您的回复！

在您的帮助下、客户解决了注册问题。

但存在真正的问题：它们无法在 Linux 和 DSP 内核之间开始交互。

描述：

客户设法通过共享存储器运行 mpm-transort、但这种方法不是最好的、因为操作系统应不断轮询邮箱。看起来应该有一个用于正常运行的带有中断的 qmss 机制。

客户采用了 DSP_EP 和 ARM_EP 示例、并尝试针对自己的项目进行调整。

在 Linux 下、似乎可以正常工作、出现了"/ dev/qms"、但我们正在循环旋转：

执行｛

状态= MessageQ_open (rem_msg_q_name、&msg_q_id_arr[i])；

睡眠(1)；

} while ((status =MessageQ_E_NOTFOUND)||

(status =MessageQ_E_TIMEOUT)；

其中 rem_msg_q_name ="rm_Client_DSP_1 "，status = MessageQ_E_NOTFOUND。

将程序加载到 DSP0后、它还会进入循环：

*==== virtqueue_startup ===

void virtqueue_startup (uint16 ProcID、bool isHost)

｛

/*等待来自主机的第一次启动，这恰好与一致

*主机接收缓冲区的初始设置，表示主机已准备好发送。

*由于中断已清除、我们将丢弃这第一个脚踢、即

*好的、因为我们无论如何都不会在 ISR 中处理此问题。

log_print0 (Diags_User1、"virtqueue_startup：轮询主机 int...")；

while (！virtqueue_InterruptProxy_intClear (ProcID、NULL))；

它正在等待来自主机的东西。 DSP 还在等什么？

Linux 部件：

IPC_transportConfig (&TransportRpmsg_Factory)；

status = IPC_START()；

rm_msg_hub (MAX_REMOLE_DSP)；->环

堆栈顺序中的 DSP 部件：

/*为主机通信设置 TransportRpmsg */

IpcMgr_ipcStartup ()；->

Status = TransportRpmsgSetup_attach (ProcID、0)；->

Handle = TransportRpmsg_create (ProcID、&params、&EB)；

RPMessage_init (remoteProId)；->

/*插入振铃中断，并等待主机准备重新启动：*/

virtqueue_startup (remoteProId、isHost)；

此过程也会在“进程1：尝试打开 DSP 1队列：test_MSGQ_Proc_1”上停止。登录附件- Log1出现错误、log2在重新引导后使用内部 ARM 进行检查

e2e.ti.com/.../putty_5F00_2.loge2e.ti.com/.../putty_5F00_1.log

编辑1：他们通过连接必要的模块来收集自己的 Linux 映像：

arago_image_extra 安装?=""

image_install +="\

packagegroup-core-boot \

$｛Arago_image_extra _install｝\

image_install +="\

packagegroup-arago-base \

packagegroup-arago-console \

packagegroup-arago-base-tisdk \

packagegroup-arago-test

$｛virtual-Runtime_initramfs｝\

image_install +="openssh openssh-sftp openssh-sftp-server gdbserver multiprocmgr ip-translation_qmss ui-module-drv qmss-lld qmss-pdsp-fw rm-lld"

在附件中、有各种选项(logs.zip).e2e.ti.com/.../5707.logs.zip 的日志

编辑2：按照我的理解、我应该添加中描述的几乎类似的问题：

https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/541046/1983711

https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/544167

但我没有找到 TI 团队的任何完整答案。或者、我们可能错过了什么...

0 admin 8 年多前

TI__Guru**** 2619895 points

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

您好、Ilya、

从日志中、基准测试和多进程会重新读取、但由于 IPC_START 失败、armEP 测试失败。在您提供的链接中、客户自己解决了问题、发现"事实证明、定义共享区域的位置非常重要。如果放置在配置文件的中间(如示例中的原始 dsp_ep.cfg)、则 IPC 启动会阻止。如果共享区域是在配置文件的末尾定义的、它就会起作用！ "

您的客户能否将其配置与该主题中发布的配置进行比较、以查看问题是否出在哪里？

雷克斯

0 admin 8 年多前

TI__Guru**** 2619895 points

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

尊敬的 Rex：

感谢您的回复！

客户提出的附加问题：

1)由于«dsp_ep.c»文件中 prj«transportQmsDspEpK2HC66TestProject»的源代码、IPC 初始化为：

/*为主机通信设置 TransportRpmsg */

IpcMgr_ipcStartup ()；

/*为 DSP 到 DSP 的通信设置 IPC */

status = IPC_START()；

然后 IPC_START()变为无限循环。

但在文档中提到，Linux-DSP 模式下的 Keystone 2只能使用 IpcMgr_ipcStartup()。但是、当执行此操作时、未调用 ti_sdo_ipc_SharedRegion_attach（)和 SharedRegion_getHeap ()、并且 ti_sdo_ipc_GateMP_instance_init ()的初始化返回 NULL。

问题：

应在 ARM-Linux 中初始化 SharedRegion_module->regions[0]。heap 吗？

»、那么：为什么不由«armEpTest_K2H.out»从«IPC-transport qmss-test 初始化？

此外、客户还补充：

1)如果 IPC_START()留在 DSP 模块中，则它不会转至周期。然后、如果我们尝试将 IPC_Attach (2)设置为另一个 DSP、则在调用状态= IPC_procSyncStart (RemoteProId、IPC_MODULE->ipcSharedAddr)后、它返回状态=-11 (IPC_E_NotReady)。

从 DSP2登录：

2个位于0x810000的资源条目

核心1

内核1：SYS/BIOS DSP TransportQmss 异构测试(DSP EP)

核心1

内核1：设备名称： TMS320TCI6636

内核1：处理器名称：主机、CORE0、Core1

Core 1：IPC Core ID： 2.

内核1：DSP 的数量 2.

Core 1：测试迭代次数：100

内核1：以名称(“Core1”)启动 IPC 内核2

TransportRpmsg_instance_init：remoteProc：0

在61上使用主机注册 rpmsg-proto：rpmsg-proto 服务

[T=0x00052e1c] xdc.runtime.Main: NameMap_sendMessage：主机53、端口=61

2) 2)在示例项目(transportQmsDspEpK2HC66TestProject)中、有以下函数：

/*区域堆将进行对齐*/

区域堆= SharedRegion_getHeap (obj->RegionID)；

如果没有 IPC_START()，则返回 NULL (如果我们只留下 IpcMgr_ipcStartup())。

如果我们打开 IPC_START()，当 DSP2尝试连接到 DSP1时，进程会因重新初始化而崩溃(因为通过 RM 服务器，我们只能使用主机)。

但目前、我们不需要在 DSP 内核之间进行操作。

返回 NULL 时的调用栈：

initTsk >>>

GateMP_create >>>

TI_sdo_IPC_GateMP_create >>

TI_sdo_IPC_GateMP_Instance_init__E >>>

TI_sdo_IPC_GateMP_instance_init >>

SharedRegion_getHeap (0)返回 NULL！！！

IPC_START() CORE0中出现错误时的堆栈：

IPC_START >>>

状态= IPC_Attach (baseId = 2)；>>>

状态= ti_sdo IPC_MessageQ_SetupTransportProxy_attach (2、0)；返回-1；！！！

TransportRpmsgSetup_attach

TransportRpmsg_instance_init

/*目前，通过 RPMSG 传输的 MessageQ 只与“主机”对话：*/！！！

您能帮我们重新解决客户的问题吗？这是一个非常重要的项目。

客户希望在 PCIe 上进行数据接收并将数据分发到 DSP、然后使用 SPI 双向处理数据和数据传输。

0 admin 8 年多前

TI__Guru**** 2619895 points

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

您好、Ilya、

我将关闭 QMSS 的此主题。您能否提交此 IPC 问题的新主题？我将有一名 DSP 工程师在新的主题中提供帮助。

雷克斯

0 admin 7 年多前

TI__Guru**** 2619895 points

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

尊敬的 Rex：

我为上一篇帖子制作了新主题：
e2e.ti.com/.../662636

Ilya。

处理器（参考译文帖）

处理器（参考译文帖）(Read Only)

[参考译文] 66AK2H06：QMSS 有问题