【85】退出fundamental reset后20ms无法进入detect是否可以再次linkup

一、背景

    PCIe协议规定，在退出fundamental reset后，component必须在20ms进入LTSSM detect状态。

    那么如果EP在20ms以内没有进入detect状态，CPU或者Switch和EP的link状态能否正常到Linkup，或者说LTSSM能够到L0？

二、测试设备

    Intel 11th Gen Intel(R) Core(TM) i7-11700K、Broadcom Switch PEX87xx、PLDA inspector、Xilinx V13P开发板。

三、测试思路

1. Intel CPU通过PCIe slot连接V13P开发板。拉低V13P开发板的reset信号，然后系统上电，查看CPU和V13P的link状态，拉高V13P开发板的reset信号，查看CPU和V13P的link状态。
2. Intel CPU通过PCIe slot连接PLDA inspector，inspector连接V13P开发板。拉低V13P开发板的reset信号，然后系统上电，通过inspector查看inspector和V13P的link状态和LTSSM。拉高V13P开发板的reset信号，查看inspector和V13P的link状态和LTSSM。
3. Intel CPU通过PCIe slot连接PEX87xx接口卡。拉低PEX87xx芯片的reset信号，然后系统上电，查看CPU和PEX87xx的link状态，拉低PEX87xx芯片的reset信号，查看CPU和PEX87xx的link状态。
4. Intel CPU通过PCIe slot连接PLDA inspector，inspector连接PEX87xx接口卡。拉低PEX87xx芯片的reset信号，然后系统上电，通过inspector查看inspector和PEX87xx的link状态和LTSSM。拉高PEX87xx芯片的reset信号，查看inspector和PEX87xx的link状态和LTSSM。

四、测试结果

    1、Intel CPU通过PCIe slot连接V13P开发板。拉低V13P开发板的reset信号，然后系统上电，查看CPU和V13P的link状态（restv13pslot2.txt）。

----->由于V13P开发板被reset住，CPU和V13P的link是linkdown的，BIOS/OS没有枚举到V13P。

    拉高V13P开发板的reset信号，查看CPU和V13P的link状态。

----->CPU和V13P之间的link是linkup的（unrsetv13pslot2.txt）。

    我们通过sys文件系统手动rescan PCIe设备，可以把V13P扫描进入系统，并且V13P可以正常访问（unresetscanv13pslot2.txt）。

    2、Intel CPU通过PCIe slot连接PLDA inspector，inspector连接V13P开发板。拉低V13P开发板的reset信号，然后系统上电，通过inspector查看inspector和V13P的link状态和LTSSM。

----->由于V13P被reset住，inspector显示inspector连接V13P的downstream port的LTSSM是polling.compliance状态。

    因为没有协议分析仪，无法看到inspector和V13P发送的TS序列，从LTSSM的状态跳转情况推测V13P的reset仅仅是reset的controller，但是phy没有被reset住，也就说phy对地是50欧姆的而不是200K欧姆的高阻状态。

    这样inspector的downstream port发起detect是可以detect到V13P。从而让inspector从detec状态进入polling状态，但是V13P的PCIe controller被reset住，导致inspector无法收到V13P发过来的TS序列，按照协议inspector就进入了polling.compliance。我们可以通过试验（4）来反推上面的推测是合理的。

注意detect是个DC common mode的电压

    拉高V13P开发板的reset信号，查看inspector和V13P的link状态和LTSSM。

----->由于V13P的reset被拉高，inspector的downstream port和V13P之间的LTSSM从polling.compliance跳转到L0，也就是说inspector的downstream port和V13P之间的link是linkup的。

    3、Intel CPU通过PCIe slot连接PEX87xx接口卡。拉低PEX87xx芯片的reset信号，然后系统上电，查看CPU和PEX87xx的link状态，拉低PEX87xx芯片的reset信号，查看CPU和PEX87xx的link状态。

----->由于PEX87xx芯片被reset住，CPU和PEX87xx芯片的link是linkdown的，BIOS/OS没有枚举到PEX87xx芯片（resetPEX87xxslot1Realtekslot2.txt）。

    拉高PEX87xx芯片的reset信号，查看CPU和PEX87xx芯片的link状态。

----->CPU和V13P之间的link是linkup的，这里因为不支持热插拔，所以0:1.0的桥后bus资源没有预留够，PEX87xx芯片加入系统后，导致PCIe tree乱了，PCIe tree不是本次测试的重点（unresetPEX87xxslot1Realtekslot2.txt）。

    4、Intel CPU通过PCIe slot连接PLDA inspector，inspector连接PEX87xx接口卡。拉低PEX87xx芯片的reset信号，然后系统上电，通过inspector查看inspector和PEX87xx的link状态和LTSSM。

----->由于PEX87xx芯片被reset住，inspector的downstream port和PEX87xx芯片的link是linkdown的，PEX87xx芯片的reset会把phy拉住，即PEX87xx的phy在高阻状态。所以，inspector的downstream port的LTSSM在detect.quiet状态。

    这也从侧面证实了我们在试验（2）中的推论，V13P的reset只是拉低了PCIe controller而没有拉低phy。

    拉高PEX87xx芯片的reset信号，查看inspector和PEX87xx的link状态和LTSSM。

----->PEX87xx芯片的reset信号被拉高，inspector和PEX87xx的link状态变成DL_active，LTSSM变成L0。

   

    2.5GT/s L0到8GT/s L0的跳转如下：

    2.5GT/s L0-->2.5GT/s Recovery.Rcvrlock-->2.5GT/s Recovery.RcvCfg-->2.5GT/s Recovery.Speed-->8GT/s Recovery.Speed-->8GT/s Recovery.Rcvrlock-->8GT/s Recovery.Equalization Phase 1-
->8GT/s Recovery.Equalization Phase 2-->8GT/s Recovery.Equalization Phase 3-->8GT/s Recovery.Rcvrlock-->8GT/s Recovery.RcvCfg-->8GT/s Recovery.Idle-->8GT/s L0

5、结论

    链路一端的设备从fundamental reset退出进入detect状态，链路另外一端的设备如果没有同时进入detect，intel 11代CPU可以正常和对端设备linkup。也就说如果EP设备初始化比较慢，不能和CPU同时进入detect状态（释放reset 20ms内），链路也可以正常linkup。

    风险点：如果CPU对应的RootPort不支持热插拔，RootPort的桥后PCIe相关资源（bus资源、memory资源、prefetchable memory资源）没有预留够，即使linkup成功，由于资源限制，EP设备一样无法正常扫描进入系统。也就是说这种情况下，物理层可以正常linkup，但是EP设备仍然无法使用。如果想临时规避，可以从root port端口（00:01.0）把所有设备都remove掉，然后再rescan回来，不过这样做后，root port后的memory地址（Memory behind bridge和Prefetchable memory behind bridge）可能变的比实际使用的要大，这个是linux资源预留算法的问题。
echo 1 >/sys/bus/pci/devices/0000\:00\:01.0/remove
echo 1 >/sys/bus/pci/rescan