[参考译文] PROCESSOR-SDK-DRA8X-TDA4X：[无效：布局错误]&quot；PHY 链路从未出现&quot；对于基于 J7X 通用处理器板的设计中的 PCIe

Josh、

您能否在 PCIe 连接器附近提供重置线路的捕获信息。

此外、请提供 D3使用的100MHz 时钟范围图、以查看是否有合适的100MHz 时钟。

尝试降低速度(例如、从第1代开始、然后从此处开始)。 您将需要更改设备树文件。

同样、从1通道开始(更改器件树)。 这些步骤应该有助于缩小问题的范围、并为我们提供可能存在问题的线索。

另一个实验是尝试从时钟发生 器到本地 SERDES 和器件的通用时钟。

此外、请注意 、您已指出、与 EVM 相比、您的设计中的时钟请求线是浮动的。  它现在是 pu (与 EVM 中相同)、也将进行检查。

让我们首先尝试这些实验、然后可能执行寄存器转储(PCIe 块)以比较 TI EVM 寄存器和电路板。

John

仍然不幸运...

M.2连接器的引脚55处的 SSD_CLK_P 捕捉似乎可以接受100MHz：

将通道数更改为1、将最大链路速度更改为1：

root@j7-evm：/proc/device-tree hexdump ./interconnect@100000/wiz@5020000/serDes@5020000/link@0/cdn、num-liges
0000000 0000 0100
0000004
root@J7-EVM：/proc/device-tree。# hexdump。/互连@100000/PCIe@2920000/通道数
0000000 0000 0100
0000004
root@J7-EVM：/proc/device-tree hexdump ./interconnect@100000/PCIe@2920000/最大链路速度
0000000 0000 0100
0000004

将很快跟进从负载开关和 SSD_RSTN 脉冲中捕获的3V3。  

这里是3V3与 SSD_RSTN：

默认情况下、SDD_RSTN 在 GPIO 扩展器上启动为低电平、否则在尝试初始化之前将驱动为低电平100至200us。 在内核日志中进行其他调试时确认了时序：

[1.155430] CDNS-PCIe-host e000000.pcie：缺少"mem"
[1.160683] CDNS-PCIe-host e000000.pcie：复位低电平
[1.165911] CDNS-PCIe-host e000000.PCIe：以使用者身份链接到 phy-5020000.serdes.2
[1.175223] CDNS-PCIe-host e000000.PCIe：复位高电平
[2.180268] CDNS-PCIe-host e000000.PCIe：PHY 链路从未出现
[2.186321] CDNS-PCIe-host e000000.PCIe：主机桥/互连@100000/PCIe@292000/PCIe@e000000范围：
[2.196290] CDNS-PCIe-host e000000.PCIe：IO 0x4400001000..0x4400010fff -> 0x00001000
[2.204476] CDNS-PCIe-host e000000.PCIe：MEM 0x4400011000.0x4407ffff -> 0x00011000
[2.21271] CDNS-PCIe-host e000000.pcie：PCI 主机桥至总线0000：00

  PCIe_USER_LINKSTATUS 寄存器(0292 7014h)的值是多少？  您是否在 PCIe2_TX/PCIe2_RX 线路中看到任何活动？

root@J7-EVM：~# devmem2 0x02927014、
/dev/mem 已打开。
映射到地址0xff98950000的存储器。
在地址0x02927014 (0xff98957014)：0x00000004处读取 

看起来没有检测到任何内容、但在驾驶员放弃等待客户端后、我正在读取这段时间... 我将介绍报告"PHY link never 上来"的代码、因为我希望它看到的是同一个寄存器。

我们对电路板做了另一项更改。 我已经用0欧姆短路替换了 RX0和 RX1通道的去耦电容器：

深入了解该驱动程序后、我可以在  j721e_pcie_is_link_up ()中看到它正在查看同一个寄存器、并且未看到 LINK_STATUS 位更改为 LINK_UP_DL_Completed (0x3)。 我修改了驱动程序、以便在值变为非零时立即额外输出、但似乎没有发生。

这里是 PCIe_USER_CFG #2的完全转储：

root@J7-EVM：~/PCIe#./dump_pcie2.sh
base：02927000h
00h：68128100h
04h：00000001h
08h：00000000h
0Ch：01C41FFDh
10h：000000014h
：00000004h
... 其余通过 C0h 的所有值均为0h

将其与 TI EVM 原理图进行比较、TX 线路中有电容器、我在 D3的电路板中似乎找不到这些电容器

不确定这是否导致了问题。 是否可以使其与 TI EVM 相同？

Nevemind、我再次检查了它、它与 TI EVM 相同。

我刚刚准备了一个补丁来使用外部时钟(从 clkgen)到本地串行器/解串器。 通过这种方式、我们为本地串行器/解串器和 PCIe 器件都提供通用时钟。 您能否添加补丁以查看它是否有用。

仍然不幸运:-(

我是否正确地理解了这些 I/O 通道的引脚由于其高速特性而不能进行多路复用？ (因此、多路复用有望不是我们的问题？)

在 Linux 之前是否发生过与 PCIe 相关的任何初始化？

这是正确的 Josh。 PCIe 线路不进行多路复用。

在 Linux 中进行完整的 PCIe 初始化(尽管它向 SYSFW 发送用于启用电源、时钟等的请求)。

您是否在 TX 或 RX 线路中看到任何活动、或者它是否完全死机？

Josh、设备树文件中是否有任何其他更改？  

 CTRLMMR_SERDES2_LN0_CTRL (0x1040a0)、  CTRLMMR_SERDES2_LN1_CTRL (0x1040a4)的寄存器值是多少？

我只使用500MHz 示波 器、我很清楚、在2.5GT/s 的速度下我无法解码任何内容、但希望我能看到活动迹象。 在这种设置下、我在 RX 通道上没有看到任何东西、我还没有找到探测 TX 通道的安全方法。 我的另一位同事的 工作范围是1GHz、目前也在尝试确认这一点。

以下是 CTRLMMR_SERDES2_lnn_CTRL 的值：

root@J7-EVM：~# devmem2 0x1040a0
/dev/mem 已打开。
映射到地址0xff95370000的存储器。
在地址0x001040A0 (0xff953740a0)处读取：0x00000001
root@J7-EVM：~ devmem2 0x1040a4
/dev/mem 已打开。
映射到地址0xff7fd60000的内存。
读取地址0x001040A4 (0xff7fd640a4)：0x00000001

似乎两个都已正确配置 PCIe2

我们的器件树应与 EVM 几乎相同、尤其是在 PCIe 区域、因为存在风险因素。 今天下午、我将回顾并重新评估所有差异、并将告诉您是否有任何突出的地方。

下面是 PSDK 6.2到目前为止的完整差异：

e2e.ti.com/.../tda4_5F00_bb_5F00_dts.diff

附件是 SERDES_16G2： e2e.ti.com/.../serdes2.txt 的转储

通过我们的电子邮件主题：

好消息：我刚刚在 TI 的 EVM 基板和旧版 SD 卡构建(PSDK 6.1？)上试用了 D3的 SOM PCIe 在那里工作、因此我们对 SOM 本身的工作充满信心。 今天下午晚些时候、我将尝试在 TI SOM+EVM 上构建并加载 PSDK 6.2、并再次检查 PCIe 是否仍然正常工作。

至于 TX 通道、我已要求我的同事查看他的板。

当我们的 SOM 连接到 EVM 或 BB 时、似乎无法到达 TX 线：交流耦合电容器位于 SOM 的底部。 尽管如此、我认为我们对 SOM 的物理布局感到满意、因为它刚刚被证明可用于 TI EVM。 这将使我们的 BB 和 SW 成为可能的故障点。

(看起来我的最后一篇帖子没有通过、这里又是这样)

问题最终是我们基板上的旋转连接器：PCIe2和 USB 的多个信号都位于连接器的错误一侧。

如上所述、我们确认 PCIe 可与我们的 SOM 在 TI EVM 上配合使用、因此我们有信心在 BB 的修订版2中解决这一问题。