[参考译文] 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 上重现此问题、并向我们分享重现此问题的步骤。 或者、我们也可以召开会议讨论客户设置、因为我们无法清楚地了解他们的设置。

谢谢

e2e.ti.com/.../8463.log.zipe2e.ti.com/.../ipc_5F00_code.zip 嗨,大家好:   问题可以重现而不启动 cpsw。 有关日志和代码、请参阅附件。

尊敬的 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、此日志来自调试版本。

Michael、

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

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