[参考译文] DRA829V：DRA829和 PCIe SW (PI7C9X3G1632GP)之间的连接[再次]

您好。 H、

对延迟回复深表歉意。 我从上一个主题中看到、怀疑所看到的问题与以下内容有关： https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1215795/processor-sdk-j721e-pcie-bridge-linux-kernel-panic

您能否指定是否代表您发布 Takumi 或 Paulo？ 我想知道哪些日志与您特别面临的问题相关、因为始终存在类似行为的可能性、但问题的根本原因是不同的。

关于 Q1和 Q2、我个人不知道是否对连接为 EP 的 PCIe 开关器件进行了内部测试。 本质上 Foundational_Components、将 DRA829V 连接到 Kernel_Drivers Ie_Backplane 背板、与此处记录的示例类似、不同的器件是 DRA829V 充当 PCIe 背板：https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/08_06_01_02/exports/docs/linux/pci/kernel/pcie。 我可以查看这一点、并最迟在接下来的两天内与您联系、了解我们过去是否使用 PCIe 开关器件进行过内部测试。

此致、

大沼市

尊敬的 Takuma-San：

感谢您的支持。

对延迟回复深表歉意。 我从上一个主题中看到、怀疑所看到的问题与以下内容有关： https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1215795/processor-sdk-j721e-pcie-bridge-linux-kernel-panic

您能否指定是否代表您发布 Takumi 或 Paulo？ 我想知道哪些日志与您特别面临的问题相关、因为始终存在类似行为的可能性、但问题的根本原因是不同的。

我代表 Takumi 发布。

为了准确调查 Takumi 的案例,我可以请 Takumi 在此主题中解释最新的情况和问题。
以上情况如何？

如果上述情况没问题、请您提供所需的任何其他信息、我将不胜感激。
(例如、"完整的内核崩溃日志、包括导致内核崩溃的所有日志")

我明白了。  如果您能尽快告诉我们结果、将会有所帮助。

此致、
o h

您好。 H、

知道了、所以我会将 Paulo 在单独 E2E 中的日志视为类似但"可能"不同的问题。 我发现 Takumi-San 提到在另一个 E2E 主题中发帖： https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1209929/dra829v-pcie-rescan-fails

根据 Takumi-San 之前的文章、我认为该电路板能够在启动期间初始化 PCIe 链路、并在 Linux 内核完全启动后重新扫描导致错误-但这一理解是否正确？

是的、完整的内核崩溃日志、包括导致内核崩溃的日志会很好、此外、如果您可以通过"dmesg"命令发布引导日志、 这将有助于确定问题是否与其他线程中的 Paulo 或 Johnson 存在相同的行为。

此致、

大沼市

您好。 H、

在崩溃日志和引导日志的顶部、如果可能、您还可以发布来自"lspci"的输出吗？ 我假定 Linux 能够初始化、所以所有 Linux 命令行工具都可用。

此致、

大沼市

尊敬的 Takumi-San：

我有几个问题来阐明我的理解。 在上一个 E2E 主题中、您曾提到：

"DRA829评估板使用具有如下所述 RC 端设置的固件。
software-dl.ti.com/.../PCIe_End_Point html"

指向的文档是当 DRA829配置为 EP 时的情况、但从您的语句中来看、DRA829似乎是配置为 RC。 我假设 DRA829配置为 RC、但您可以确认吗？ 这将缩小相关代码的范围、以检查 PCIe 驱动程序中的内容。

根据共享的日志、我的理解是、使用该定制板时、该板能够引导至 Linux 并执行重新扫描会导致内核崩溃、而使用 TI DRA829 EVM 时、内核在启动期间崩溃。 2个 PCIe 通道连接到 PCIe 软件、然后该软件连接到2个 PCIe 通道的2个实例、总共4个 PCIe 通道。

收集这些日志时、连接到 PCIe 交换机的器件是什么？ 是两个 NVMe SSD 卡、还是两个其他 DRA829V？ 主要问题、因为上一主题提到连接了其他两个 DRA829V、而在 lspci 日志中、似乎连接了两个 SSD 卡。

在没有连接到 PCIe 交换机的设备的情况下进行重新扫描是否会导致崩溃？ 如果崩溃、我们可以将问题隔离为 DRA829V 和 PCIe 交换机之间的连接。

最后、我们是否可以购买可轻松连接到 TI DRA829 EVM 板的推荐独立 PCIe 开关卡？ 在在线搜索主题中提到的器件型号的过程中、我不确定提到的 PCIe 开关是不是可以轻松插入到我们的 EVM 板中的 PCIe 卡、或者只是芯片并需要设计到定制板中。 如果是卡片而不是芯片、我想与经理核实、看看我们是否可以采购一个开关、看看我们是否可以重现问题。

此致、

大沼市

你好,大熊山

获取日志的 DRA829配置为 RC。
对于主机(RC)设置、请使用以下主机器件设置中发布的设置。

https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-rt-jacinto7/08_02_00_01/exports/docs/linux/Foundational_Components /内核/ Kernel_Drivers PCIe/550.html Ie_End_Point

自定义板(RC)连接了一个 PI7C9X3G1632GP 和两个 NVMeSSD。
八个 DRA829V 连接到 PI7C9X3G1632GP。

即使没有任何器件连接到 PCIe 交换机、
我在运行重新扫描时收到错误消息。

建议不要购买 PCIe 交换机卡。
PI7C9X3G1632GP 仅用于芯片销售。 我借用了 EVM、
关于 PCIe 交换机、我遇到了与 PEX 8648相同的问题。

此致、
Takumi

您好、Takumi：

Unknown 说：

即使没有设备连接到 PCIe 交换机
我在运行重新扫描时收到错误。

看起来问题已与 RC 和 PCIe 交换机之间的连接隔离。 当没有设备连接到 PCIe 交换机时、您是否可以共享此特定配置的 RC 端的日志？

Unknown 说：

没有建议购买 PCIe 交换机卡。

我懂了。 我将看看我能否在线获得随机的 PCIe 开关、看看我是否能在最后重现问题。 我正在购买一张标题为"具有 PCIe 分叉功能的双 M.2 PCIe NVMe X4适配器"的卡、它应该允许我将2个 SSD 卡插入 TI EVM 上的4通道 PCIe 端口。 计划于6月20日发货、因此 TI-Side 的动手实验最早将于下周开始。

此致、

大沼市

您好、Takumi：

作为更新、我今天收到了 PCIe 交换卡、并将进行一些初始实验。

此致、

大沼市

您好、Takumi：

我们发现 PCIe 开关有一些有趣的行为。 使用 DRA829V TI EVM 时、我们也能够重现您看到的问题。

但是、在使用类似的处理器 DRA821 TI EVM 时、电路板能够枚举 PCIe 开关。 DRA829V EVM 明显特定于该问题。 我们将对此进行研究、如果我们发现任何其他有趣的结果/实验/修复、我会随时向您更新。 如果您没有收到我的反馈、并且需要更新、请通过在此 E2E 中发帖让我知道、我会让您了解最新的。

此致、

大沼市

大家好、Takuma-San、

感谢您的答复。

我们还能够在使用其他处理器的 AM69A EVM 时枚举外部 PCIeSW。 我认为这是 DRA829特有的问题。

此致、
Takumi

您好、Takumi：

感谢您提供的信息。 我们仍在努力找出问题的根源，但我确实有一些想法。 AM69A 和 DRA821都具有与 DRA829不同的 PCIe PHY。

因此、目前最可疑的代码片段是 PHY 专用代码、它们是 phy-cadence-Sierra。c 和 phy-cadence-torrent.c。 代码的差异非常大(虽然流程相似)、因此需要几天时间来列出差异并进行一些实验以获得有关该问题的更多信息。

与此同时、您可以在定制电路板上发布来自/usr/sbin/lspci -vvvv 的输出吗？ 这样应该会获得有关 PCIe 交换机器件的详细信息。 如果开关根据 lspci 的日志支持 ARI、那么我们可以尝试进行实验、看看启用 ARI 是否可以解决我们遇到的问题。

此致、

大沼市

尊敬的 Takumi-San：

从日志来看、似乎没有 ARI (备用路由 ID 解释)功能、因此我们可能无法采取变通办法。 我们将继续调试该问题。

感谢您的耐心。

此致、

大沼市

大家好、Takuma-San、

您说 PHY 专用代码可疑、但此后确认的状态是什么？

此致、
Takumi

您好、Takumi：

遗憾的是、我无法确认这是 PHY 特定代码的问题、还是 PCIe 驱动程序本身的问题、这种问题只会由于所使用的特定 PHY 的组合而出现。

就当前情况而言、根据日志并浏览代码、日志似乎是从 probe.c 中的 pci_scan_bridge_extend 生成的。 具体而言、此代码用于扫描设备两次。 一次扫描 BIOS 配置的设备，然后再次扫描剩余的总线。 这第二次失败了。

现在、我们仍在探讨为什么第二次测试仅在 DRA829V 上失败、并需要更多的时间来解决此问题。

此致、

大沼市

尊敬的 Takumi-San：

对迟交的答复表示歉意。 我可以与您分享的好消息是、我们认为我们已经找到了根本原因、并且有一种权变措施似乎适用于我的 PCIe 开关设置。

您能否尝试应用此补丁、看看它是否适合您？

e2e.ti.com/.../0001_2D00_Temporary_2D00_workaround_2D00_to_2D00_disable_2D00_kernel_2D00_panic_2D00_for_2D00_pci.patch

关于这一问题的背景：

我们发现勘误表 i2086确实导致了这一问题。 然而、与其轮询单个器件上不存在的器件功能相关的问题、问题似乎在于 PCIe 开关的默认行为是探测其总线上可能存在的所有256个可能的器件 ID。 如勘误表中所述、探测不存在的器件会导致 UR 响应。 CPU 认为它是一个不可恢复的总线错误,即使在现实中它是可恢复的,导致内核恐慌。

警告：共享修补程序不是最干净的变通办法、因为它假定不可恢复的错误是可恢复的、并抑制此错误响应。 但是、只要 ID 为0xbf000000的其他错误不发生、那么对于在 DRA829上启用 PCIe 交换机的情况、应该不会出现问题。

此致、

大沼市

您好、Takumi：

太棒了！ 很高兴听到错误日志消失了。 我是否也可以确认 PCIe 开关器件使用此补丁后可以正常工作？

我在前面提到过、它不是最干净的补丁、因为我为 ATF 制作的快速补丁会影响所有错误。 我也会在我的终端尝试使用 Linux RT 8.2版本 SDK、看看我们是否可以制定更干净的权变措施并与您分享。 与此同时、我分享的补丁应该会帮助您从开发中解除阻止、因为只要没有遇到"真正的"关键错误、例如访问无效的存储器位置、实际的总线错误等、应该就没有问题。

此致、

大沼市

尊敬的 Takuma-San：

我将 SDK 更新至8.06.1.2并检查了补丁和 lspci、其中列出了 PCIeSW 后面的器件。 我还可以使用 RC 运行 pcitest.sh。
但是、我在内核启动日志中看到以下错误：
pcieport 0001：00：00.0：of_IRQ_parse_pci：failed with RC=-22

我想问大家一些问题。
1.您遇到的错误与中断有关。 有问题吗？
2.您是否有适用于 SDK 8.06.1.2的0001-ARM64-DTS-j721e-Enable-minimal-DT-configuration.patch？

表示2、
在8.02.0.1中、对定制电路板使用0001-ARM64-DTS-j721e-Enable-minimal-DT-configuration.patch。 使用上述带有8.06.1.2的补丁将导致生成错误。

此致、
Takumi

您好、Takumi：

我假设0001-ARM64-DTS-j721e-Enable-minimal-DT-configuration.patch 来自常见问题解答或另一个类似如下的 E2E： https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1201887/processor-sdk-j721e-custom-board-bring-up-with-8-05?tisearch=e2e-sitesearch&keymatch=0001-arm64-dts-j721e-Enable-Minimal-DT-configuration.patch#。 如果补丁提交 ID 不同、请与我分享您引用的正确 ID。

纵观我发现的 E2E 线程上的补丁、我看到所有 SerDes 和 PCIe 节点都已从 DTS 文件中删除、在这种情况下、PCIe 完全可能无法正常工作。 因此、我假设在重新启用 PCIe 时进行了一些自定义更改。 如果可能、您能否与您的更改共享一个可在默认8.6.1.2 SDK 上应用的.patch 文件、以便我可以在结束时重现问题？

此外、您能否说明1中的行为是什么？ 例如、开关和连接在开关上的器件是否正常工作、除了一行错误外、一切都正常工作？ 或者你正在得到一个内核恐慌像以前?

最后、您能否分享第1个问题的完整启动日志和第2个问题的构建日志？ 我假设生成日志与 DTS 相关、因为您刚才提到 DTS、但我想知道在 DTS 编译之前是否有错误、以及错误日志如何验证我是否能够重现最后看到的问题。

此致、

大沼市

您好、Takumi：

对于1、浏览到上游 Linux 内核的一些在线补丁、似乎这个 IRQ 调试消息是已知的。 要从提交消息中引用、

"

中断引脚寄存器是只读的且可选。 某些 PCI 设备可能使用
msi/ms6、但使 Interrupt Pin 的值非零。 在这种情况下，
驱动程序将打印如下信息：
PCI 0000：40：00.0：of_IRQ_parse_pci ()失败，RC=-22

"

消息似乎取决于所连接的 PCIe 器件、此外、如果所连接的器件没有中断引脚寄存器、则不一定是会使系统中断的错误。 如果 PCIe 设备按预期工作、我认为可以忽略日志。

2、是的、我认为制作一个单独的线程不稀释当前线程是合理的、因为它是一个单独的主题。 但是、请在此主题中发布指向新 E2E 的链接、以便更好地进行跟踪。

此致、

大沼市