[参考译文] DRA821：DRA821 QNX 执行&quot；ifconfig&quot；将卡在 QNX 站点上

客户将共享以下驱动程序代码和复制的步骤。

要包含的目录为：

psdkqa/qnx/devnp

REMOTE_DEVICE/CLIENT-RTOS/框架

ethfw/ethremotecfg/client

e2e.ti.com/.../3125.code.zip 请参阅代码附件。 定期津贴如下：
我们使用脚本打开 TI 的 IPC_ Test 程序、
当我们意外发现可以稳定地重现此问题的操作时、就会出现这种现象。  

该脚本如下：

BOOT_IS_A=`BOOT -s`
while ["$｛boot_is_c｝"!="c"]
正确
IPC_TEST 和
睡眠1
完成

Unknown 说：

MCU2_0可以通过 QNX 发送和接收 IPC 消息

对于上述关于使用 QNX 发送和接收 IPC 消息的声明、您能告诉我们正在加载什么固件映像吗？ 是 IPC_ECHO_TEST 固件映像吗？

Unknown 说：

MCU2_0将在 插入和拔下网络电缆时打印链路断开和链路接通消息[/报价]

对于这种说法、MCU2_0内核上运行的是什么？ EthFW 映像 是否已加载？  您能否共享显示链路断开和链路建立消息的日志？

Unknown 说：

QNX 启动新进程将失败，如果该进程与" QNX 设备 "[/报价]

这里提到的新流程是什么？ 请分享完整的"sing2info -w"。

Unknown 说：

ifconfig 命令将卡在 QNX

[/quote]

上

您能否分享有关如何启动网络驱动程序的详细信息？

Unknown 说：

该脚本如下：

BOOT_IS_A=`BOOT -s`
while ["$｛boot_is_c｝"!="c"]
正确
IPC_TEST 和
睡眠1
完成

[/报价]

这里使用的 IPC_TEST 是什么。 它是 TI 在处理器 SDK QNX 交付过程中提供的默认 IPC_TEST。 如果是、我不确定运行的是有效的测试应用程序、除非您已加载本测试进行通信所需的 IPC_ECHO_TEST 固件映像。 您能解释一下吗。

谢谢。

[/quote][/quote]

e2e.ti.com/.../slog2info.txt

附件是 slog2info 的日志，但 slog2info 不承诺有关 IPC 的一些信息。

IPC_测试是针对 TI 提供的 IPC 通信的测试程序

顺便说一下、MCU2_0上的所有测试基地都是 ETHFW 固件。   

您能否解释一下为什么在 MCU2_0内核运行 EthFW 固件时运行 IPC_TEST 程序？ 请注意、当 MCU2_0和其他内核加载 IPC_ECHO_TEST 固件映像时、需要运行 IPC_TEST。 所以我认为您的测试场景有一个基本的缺陷,或者您是否可以解释其他。 此外、请阐明上面发布的其他问题、以帮助了解所报告的问题？

谢谢。

您好 Praveen：
IPC_TEST 由客户修改 t 海瑟尔夫  以便与 MCU2_0通信。 同时、MCU2_0运行 ETHFW 固件、并且存在 IPC 任务接收和发送 IPC 消息。 这是客户项目需求。  对于需要进一步澄清的其他事项、如下所示：

对于上述关于使用 QNX 发送和接收 IPC 消息的声明、您能告诉我们正在加载什么固件映像吗？ 是 IPC_ECHO_TEST 固件映像吗？

MCU2_0已加载 ETHFW 固件。

对于这种说法、MCU2_0内核上运行的是什么？ EthFW 映像 是否已加载？  您能否共享显示链路断开和链路建立消息的日志？

是的、所有这些测试都已加载 ETHFW 固件。 稍后将共享该日志。

这里提到的新流程是什么？ 请分享完整的"sing2info -w"。

此日志在之前已附加

您能否分享有关如何启动网络驱动程序的详细信息？

您能解释一下启动网络驱动程序意味着什么吗？ 据我了解、MCU2_0加载了 ETHFW、它将配置 CPSW5G、然后在 QNX 正常引导时应说明网络驱动程序。  

这里使用的 IPC_TEST 是什么。 它是 TI 在处理器 SDK QNX 交付过程中提供的默认 IPC_TEST。 如果是、我不确定运行的是有效的测试应用程序、除非您已加载本测试进行通信所需的 IPC_ECHO_TEST 固件映像。

IPC_TEST 是客户的 可执行程序、用于与 MCU2_0进行通信、MCU2_0将创建一项用于接收和发送 IPC 消息的任务。  

尊敬的 Kangija：

Unknown 说：

IPC_test 是客户修改 t 海瑟尔夫  以便与 MCU2_0通信。

回归可能是由于这种原因而引入的,那么 我们是否知道它们的修改是否正确?  

Unknown 说：

此日志在前已附加

所附的日志不正确。 建议从操作系统开始共享完整的日志、包括网络驱动程序初始化

。

Unknown 说：

您能解释启动网络驱动程序意味着什么吗？ 据我了解、MCU2_0加载了 ETHFW、它将配置 CPSW5G、然后在 QNX 正常引导时应说明网络驱动程序。  [/报价]

是的、在 A72端、当 QNX 正常引导时、我们将启动与 EthFW 交互的 CPSW5G 虚拟瘦客户端 DEVNP 驱动程序。 这是此处引用的网络驱动程序。 我们需要有关在启动驱动程序时传递的参数的详细信息。 从一开始就生成的日志。

要进一步操作、我们建议您是否可以在 TI EVM 上重现此问题、并向我们分享重现此问题的步骤。 或者、我们也可以召开会议讨论客户设置、因为我们无法清楚地了解他们的设置。

谢谢

尊敬的 Kangija：

感谢您的反馈。 这表明停止不是由于 网络驱动程序(devnp cpsw5g 虚拟驱动程序),而是更多的是 IPC 回波测试支持集成到 EthFW 中的方式。

我们将查看共享的代码、看看我们是否能提供一些反馈。

谢谢。

尊敬的 Kewei：
  我们的研发团队提出了一些问题。 请帮助检查~

我看了看分享的日志,并有一些问题:

1. qnx_log.txt、slog.txt 和 r5f_log.txt 似乎与运行的 IPC_tests 一致。 看起来测试运行了16次。 脚本是否在这之后中止了？ 日志中不清楚这一点。 在您开始看到 rx_queue 已满错误(从 slog.txt 中的第261行开始)后、测试是否中止？
2. 在 slog.txt 中、我看到 cpsw5g 驱动程序在开始测试之前已启动。 是这样吗？ 最后一条注释指出、问题在不启动驱动程序的情况下重现。

我会对分享的代码进行更深入的研究。 似乎在 QNX 端添加了 IPC 诊断服务。 是这样吗？ 我在 slog.txt 日志中没有看到该内容

1.在问题再次出现后手动退出脚本。
2.上传的日志正常启动 CPSW
3.IPC_Diag 用于我们的诊断、并且在测试期间未激活

尊敬的 Kewei：
 您能否获得您的电路板的以下信息？

slog2info > /tmp/log.txt
pidin syspage=asinfo 

并且他们的 evm-ti.build 文件内容。 具体来说、以[+keeplinked] startup–dra821-evm 开头的行
问题所在的电路板可能不同、但我要查找用于构建 QNX IFS 的构建文件的内容
这是我们的 EVM 的 J721s2构建文件的屏幕截图。 它们应该具有与第22行类似的编号、

e2e.ti.com/.../5850.log.zip

您好！

感谢您分享这些信息。

我查看了您共享的文件、这里是我可以收集的信息。

1.  只有以太网固件是加载的远程技术器。
2. 在 ethw 固件二进制文件中、只有以太网服务器用例。
3. 使用 SBL 引导流程。 (基于 U-boot 的引导流程将一些 DDR 用于 DMSC、起始地址为0xA0000000。 这已经在他们的板级配置文件中进行了处理、但为了清晰起见、我在此提及它)
4. 根据构建文件,分割值为 96MB 的 DDR ,地址为0xA0000000(直到0xA6000000 )。 注意：TI 参考构建文件具有0x60000000 (1536MB -因为我们的参考具有更大的分割空间)。
5. MCU2_0的 IPC 回声测试样本集成到以太网固件包中。

后续步骤：

1. 如果不需要假内存分配器、可以安全地将其卸下。 从构建文件中、carveout 不会指向0xbc000000、因此我认为 sharedmemoryallocator 用处不大。 请澄清/删除相应内容。
2. 请确认您已按照 https://software-dl.ti.com/jacinto7/esd/processor-sdk-qnx-j7200/08_06_00_07/exports/docs/qnx_sdk_components_j7200.html#ti-modifications-to-the-bsp 到达从0xA0000000开始的96MB 车门。  
3. 请确认除 DM 和远程内核 MCU2_0之外，您的设置中没有加载其他内核。 如果是、则可能需要设置其他分割。
4. 若要识别分割大小和位置、必须使用链接器命令文件或生成的.map 文件。 对于以太网固件、生成的.map 文件应位于该位置、  
   /ethfw/out/J721E/R5Ft/FREERTOS/release/app_remoteswitchcfg_server_ccs.xer5f.map。 对于您的集成固件、请标识相应的映射文件。
   
5. 请分享此 TT 中的地图文件以供审核。

1.我尝试删除 shawedmemory 没有异常或错误。 似乎没有使用 sharedmemory。

将存储器地址修改为0xA0000000~0xA600000、不报告任何异常。

3.我们使用了 MCU1_0。

4.请参阅地图的附件 file.e2e.ti.com/.../app_5F00_remoteswitchcfg_5F00_server_5F00_ccs.xer5f.zip

感谢您分享这些信息。 我确实查看了映射文件、结果看起来很合理。 您是否还可以尝试从0xa0000000开始将分割量增加到512M？

Br
苏布

您好！

似乎问题在于脚本的运行方式、具体在于 A72侧运行的示例 IPC_TEST 代码。  examples/IPC/IPC_TEST_QNX/IPC src 文件夹中的 IPC_testsetup.c 文件中的测试结束时有1段时间。 在编写脚本的方式中、样本会启动多个 IPC_TEST 样本。 在发送和接收回波消息后、样本会命中 while 循环、并坐在那里。 这将开始占用 CPU、一旦您在后台运行足够的这些测试、A72将耗尽 CPU 周期、所有进程都不会运行(因此、一个非功能性 cpsw 驱动程序)。

我将随附一个 ipc_testsetup.c 文件的熟食版本、一旦测试成功、该文件便会正常退出。 请注意、与初始版本类似的版本仅为示例测试代码、供参考。

我已附加了脚本的修改版本、该版本可能也会很方便。

还随附了 J7200电路板上的日志、其中包含此测试用例在8.0版本顶部运行1500次以上。

如果您需要更多信息、请告诉我。

谢谢。此

大家好！

更新最新补丁 e2e.ti.com/.../Patch_5F00_for_5F00_ethfw.zipe2e.ti.com/.../ipc_5F00_trace_5F00_logger.zipe2e.ti.com/.../Patch_5F00_for_5F00_psdkqa.zip

-1- Patch_for_psdkqa.zip

请注意、我之前提到过提供一个增补程序来转储更多日志、但经过仔细分析后、现在工作量过大、无法增加任何价值。 相反，我提供了一个 DEVNP 驱动程序的修补程序，该驱动程序禁用了调用"Enabis If_Check will linkUP()"。 请注意、该函数对于 CPSW5G 驱动程序的功能很重要。 此外、这是将周期性 ioctl 发送到 EthFW 的函数、如果 EthFW 停止或不响应、那么该函数会保持 IO-pkt 网络栈线程、从而导致"ifconfig"命令停止。 通过禁用该调用、当 出现 EthFW 特定问题时、不会出现任何失速。

补丁更新是 J7_cpsw.c 文件、完成的更改如下：

Patch_for_ethfw.zip

该补丁适用于 EthFW。 该补丁有助于将 tracebuf 地址添加到 EthFW 服务器映射文件。 此次更新后、新生成的映射文件将具有任何地址、可用于使用实用程序(IPC_TRACE_LOGGER)从 A72 QNX 端检索跟踪消息。

补丁更新为 ipc_trace.c 文件、所做的更改如下：

若要从 EthFW 服务器映像获取跟踪缓冲器基址、请在 EthFW 映像上运行 readelf 工具、如下所示：

readelf -S app_remoteswitchcfg_server.xer5f | grep tracebuf

示例的映像、我们在其中将基于 tracebuf 的地址视为0x2936000。 请注意、该地址值可能会在客户的图像上发生变化。

-3- ipc_trace_logger.zip

此 zip 文件包含 IPC_TRACE_LOGGER QNX 二进制文件、该二进制文件可直接添加到客户的 QNX 映像中。

该工具需要按如下方式调用。 调用该函数后、EthFw 跟踪将被重定向到 slogger。 tracebuer_base 值需要从 EthFW 服务器映像的映射文件中获得。

slog2info -w 和
IPC_TRACE_LOGGER TRACEBUFFER_BASE=0xXXXXXXXX、TRACEBUFFER_SIZE=0x80000、PRINT TO_SLog=1、WAIT_MODE=1 &

您好 Praveen：
它也可以重现这一问题，但概率降低了。 我们已经转储了寄存器值和 slog。 请帮助您查看并发表评论。 谢谢~

e2e.ti.com/.../log_2800_1_2900_.zip

您好 Praveen：
客户 系统方框图如下所示

当问题在汽车上重现时、我们检查了以下方面：

1. QNX 可以执行其他程序、但与使用 MCU2_0和 ifconfig 命令的 IPC 相关的程序除外、 尤其是 与" QNX 设备 "。

2. MCU2_0可以正常运行，因为在插入前置摄像头设备时，MCU2_0可以输出"链路断开和链路接通"日志。

3、其他 SOC 可以 ping 前摄像头设备和环视设备。

4.我们转储了 QNX 日志、并附加了一些寄存器值。

e2e.ti.com/.../zm_5F00_log20230707.7z 

e2e.ti.com/.../DAR821_5F00_log.zip

您好：请查看所附的日志

e2e.ti.com/.../20230721.zip

您好：请查看所附的日志

尊敬的 Kewei：

这些日志是否包含最新的 UDMA HC 更改？
-谢谢

大家好、Michael、这些日志并未合并最新的  UDMA HC 更改。 我们正在测试昨天的最新 UDMA HC 更改。

e2e.ti.com/.../slog_5F00_udma-change20230727.txthiMichael ,此 日志 包含最新的 UDMA HC 更改。 是否有任何可以找到根本原因的信息？

您好、Michael、 此 附件是最新的 loge2e.ti.com/.../del-diag.zip

除了在 ifconfig 持续运行时运行"pidin mem"(作为后台进程运行时)、您还可以仅运行"pidin"、以便我们查看线程的状态。 至于内存使用、/bin/message_center 好像使用了大部分内存(1529M/2048M)。 您能详细说明一下这个程序正在做什么吗？ 如果不需要、可以在不运行此程序的情况下尝试运行网络测试吗？

message_center 用于与其他芯片通信。

今天有一个日志、您可以按以下方式查看日志吗？

e2e.ti.com/.../2030803log.zip

ifconfig 命令似乎滞留在 IO-pkt 进程上、符合预期。 接下来的步骤是调试 IO-pkt 驱动程序。 通常，这是通过 QNX Momentics IDE 连接到进程或对核心文件执行事后调试来实现的。 是否有人尝试过这种方法？ 如果不是这样、我会查看 QNX dumper 实用程序以转储 IO-pkt-v6-hc 过程。 https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.utilities/topic/d/dumper.html

嗨 Micheal，此附件中有一个核心文件。

e2e.ti.com/.../20230804.zip

添加更多调试文件。  io-pkt-v6-hc  devnp-cpsw5g.so  io-pkt-v6-hc.sym   

e2e.ti.com/.../cpsw5g_5F00_debug.7z

您好，Michael，还有如下所示的另一个核心文件和一些调试文件。 这是另一个版本。  devnp-cpsw5g.so 与 kangjia 提供给 you.e2e.ti.com/.../del_5F00_diag.zip 的不同

您好、Kewei、我已经尝试过调试核心文件、Momentics 报告"没有调试信息"可用。 项目是否使用调试配置文件构建？

Michael、您好！

以下信息由 QNX 站点提供。

从 GDB 的分析来看,一切似乎都是正常的。 如果出现问题、则很可能是 TI 驱动程序有问题、因为几乎所有线程都会在驱动程序处理程序中停止。 请多次抓取核心文件进行比较分析。

e2e.ti.com/.../20230810debug-log.ziphiMichael、此日志来自调试版本。

您好，Kewei，devnp-cpsw5g.so 文件是否有新版本？  我拥有的早期版本与 ifconfig 核心文件前后 IO-pkt 中的版本不匹配。 所有其他库似乎都正确加载。

从日志和先前的核心文件和日志中可以看出、IPC 看起来是正常工作的。 我正在研究9.0发行说明中提到的 uDMA 错误修复是否与此相关。

Michael、

以下调试文件我已在上进行了验证。 它现在应该可以工作了。

e2e.ti.com/.../cpsw_5F00_debug_5F00_version.7z