Other Parts Discussed in Thread: AM6422
器件型号： AM6422
TI 团队大家好、
参考票证
这是对上一个 TT 的跟进：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1604262/am6422-am6442-pcie-boot-issue-ep-fails-to-boot-no-logs-after-writing-tiboot3-bin-to-bar1/6238997
注意：在当前设置中、我们不会尝试 PCIe 引导。 我们仅在 R5 SPL 中执行 PCIe 链路训练、然后在 Linux 内核中使用 PCIe EP。
目标
我们的目标是使用 AM6422 作为 PCIe 端点、并运行 am64 SDK 中提供的 PCIe 端点测试应用程序。
由于 x86 主机具有枚举时序限制、因此我们不能等到 Linux 内核引导以启用 PCIe。 因此：
PCIe 链路训练在 R5 SPL 中完成
然后、Linux 内核中再次使用 PCIe EP
主机在内核引导后重新扫描 PCIe
消息
端点 (EP)
SoC：AM642 (AM64 EVM)
PCIe 模式：端点
在以下通道中启用 PCIe：
R5 SPL
Linux 内核
根复合体 (RC)
主机：运行 Linux 的 x86 PC
我们使用提供的相同 pcie-endpint-test 驱动程序来测试 am64 EVK 中的 PCIe RC。
我们做了什么
在 R5 SPL 中启用 PCIe EP
PCIe EP 在 R5 SPL 中进行初始化、链路训练完成。
结果：
在 x86 主机上检测到 PCIe 设备。 （用于检查检测的 lspci 命令）
2. PCIe EP 在 Linux 内核中再次启用
内核启动后、使用端点框架再次启用 PCIe EP。
我们使用 TI 文档中提供的 PCIe 端点测试驱动程序程序程序来配置 BAR。
https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/11_01_05_03/exports/docs/linux/Foundational_Components、Kernel/PCIe/PC Kernel_Drivers Ie_End_Point
重新扫描 PCIe 后、在主机上可以看到 BAR 配置更改。
主机示例：
回波 1 >/sys/bus/pci/devices/0000：01\：00.0/remove
回波 1 >/sys/bus/pci/devices/0000：00\：00.0/rescan
重新扫描后：
来自内核的 BAR 配置已正确反映在主机上。
在 x86 上、我们能够加载 PCIe-Endpoint-test 驱动程序、并且 PCIe 的设备节点也可作为/dev/pci-endpoint-test.0 进行测试
发现的问题：
从主机运行 PCIe 端点测试操作时、系统会冻结。
使用 PCI-ENDPOINT 测试驱动程序执行读/写。
结果：
命令提示符冻结
操作未完成
即使出现以下情况、该过程也无法终止：
KILL –9.
在执行 PCIe BAR 读取/写入操作期间、系统出现卡滞。
重要观察
我们观察到不同的行为、具体取决于 RC 和 EP 的引导顺序。
场景 1（出现问题）
端点首先引导
在 SPL 中训练的 PCIe 链路
Linux 引导
主机重新扫描 PCIe
条形正确反射
运行端点测试→系统冻结
场景 2（工作正常）
端点首先完全引导 Linux 内核
x86 主机随后打开电源
SPL 设置默认 BAR、内核重新配置它们
主机正常枚举器件
在这种情况下：
PCIe 端点测试读/写正常工作
不会发生冻结
我们希望澄清以下问题：
是否支持在 SPL 中执行 PCIe 链路训练、然后在 Linux 内核中将控制器重复用于 EP 操作？
此问题是否与 SPL 中已发生链路训练后的 PCIe BAR 重新配置相关？
当 PCIe 已在 SPL 中初始化时、内核中是否需要任何额外的 PCIe 控制器复位或重新初始化步骤？
对于 AM6422、是否有跨 SPL 和内核进行 PCIe EP 初始化的建议流程？
谢谢、
Charan
