1. 调试前先弄明白RK3568的PCIe3.0 x2到底是什么状态拿到一块RK3568的板子要把PCIe3.0 x2真正跑起来很多人第一反应是去翻设备树、改驱动结果改了半天发现还是Link不上。我自己的习惯是先不动任何代码把整条链路从芯片端到设备端过一遍。RK3568这颗SoC的PCIe控制器是DesignWare的IPLinux内核里对应的是dw-pcie这套框架compatible属性写的是rockchip,rk3568-pcie同时兼容snps,dw-pcie。也就是说它本质上是一个很标准的Synopsys PCIe控制器但因为集成了瑞芯微自己的PHY和时钟方案所以硬件上比直接用PC上的PCIe要敏感得多。先说资源分布。RK3568上实际有多个PCIe控制器PCIe3.0控制器最高支持x4通过两个Combphy合并PCIe2.1控制器支持x1还有一个PCIe2.0控制器也是x1。标题里说的PCIe3.0 x2就是使用PCIe3.0控制器中的2个lane对应到底层是两个Combphy都工作在PCIe模式。这里我建议你在看原理图的第一时间就把PCIe控制器型号、PHY实例编号、lane数量这三者对应清楚否则后面配设备树的时候一定会搞混。别问我为什么这么强调我见过太多人把PCIe2.1那个节点的设备树改得飞起然后发现硬件上根本插的是PCIe3.0的槽。x2链路和x1、x4的核心区别除了物理lane数量不同还包括链路训练时的宽度协商逻辑。PCIe链路训练的时候根端口RC和端点EP会通过LTSSM状态机去协商速率和宽度。x2的意思是物理上连了2个lane但能不能协商成x2取决于两边的能力如果端点只支持x1或者连接器只接了x1的线那最终可能会以x1运行。这个特性能做文章也能埋坑如果你的设备只支持x1那即使RK3568配了x2最终链路也可能只跑到x1这并不是驱动配置错误而是老老实实的协议行为。PCIe3.0的速率是8GT/s也就是每根lane单方向8Gbpsx2的话单方向约16Gbps扣除协议开销128b/130b编码后实际有效带宽大概有1.96GB/s左右。我算过PCIe3.0 x2的有效带宽大约相当于PCIe2.0 x4跑千兆网口、NVMe固态、视频采集卡都够用。但有几点要提醒RK3568的PCIe3.0控制器与PCIe2.1/2.0控制器是独立的不能互相转换PCIe3.0控制器如果要跑x4必须占用两个Combphy全部切换为PCIe模式而且会影响到其它接口的资源分配比如USB3.0或者SATA。所以项目设计的时候x2往往是“平衡性能和资源”的选择。还有个很多人忽略的点PCIe3.0使用了128b/130b编码导致它对信号质量的要求比PCIe2.0高非常多。PCIe2.0用的8b/10b编码有大量的冗余跳变沿接收端恢复时钟相对容易PCIe3.0的128b/130b几乎没有长串连续跳变对参考时钟的抖动、AC耦合电容的选型、走线阻抗、过孔残桩都非常敏感。所以后文在硬件电路上会用比较大的篇幅不是走形式而是这些点真的决定了Link能不能稳定。2. 硬件电路设计和样板检查最容易“看起来对其实不对”的地方2.1 参考时钟整条链路稳定性的命脉PCIe3.0的参考时钟是100MHz差分时钟由根端口侧提供经过连接器送到端点设备。RK3568这颗芯片的PCIe参考时钟是直接从SoC的REFCLK引脚出来的还是通过外部时钟缓冲器如IDT 9LPRS365、SI52144这类PCIe时钟发生器产生的取决于你们的原理图设计。不管是哪种方案三个检查点必须先确认频率必须准确是100MHz差分信号质量要达到PCIe规范里抖动的上限要求参考时钟和数据的传输方向必须匹配。参考时钟的抖动是PCIe3.0链路最挑剔的指标之一。规范的参考时钟抖动RJ/PJ要求非常严很多板卡跑不起来最后发现是参考时钟的电源纹波过大或者时钟走线跨了分割区。我自己踩过一次坑用普通时钟芯片给PCIe3.0供参考时钟示波器看波形有轻微过冲直流特性看着还行结果Gen3速率下稳定运行几分钟就掉Link降级到Gen1才稳。后来换了专门的PCIe时钟发生器问题彻底消失。如果你用的是SoC直接输出的参考时钟检查一下是否按手册接了合适的端接电阻和AC耦合电容。PCIe规范里参考时钟通常需要靠近接收端放置AC耦合电容常见0.1uF或0.22uF如果原理图上漏了或者在PCB布局时放错了位置链路训练时会出现莫名其妙的不稳定。调试技巧在板子到手后先用示波器带宽至少500MHz推荐1GHz以上测量参考时钟的差分波形用眼图模式看眼高和眼宽同时用频谱分析仪看100MHz处有没有异常杂散。如果波形已经不太干净就不要再往后调软件了先解决硬件问题否则后面很多现象会被误判成软件问题。2.2 复位与电源时序Link Training失败的头号元凶PCIe的PERST#信号是根端口用来复位端点的它必须在参考时钟稳定之后释放而且在加电时满足至少100ms的上电时序要求。这个参数在PCIe CEM规范里有明确要求但很多板卡设计人员不会去较真。我调过的板卡里至少有两块卡的故障原因就是PERST#释放得太早导致端点设备还没初始化好就开始链路训练最后握手失败。检查方法很简单用示波器同时抓参考时钟、PERST#和3.3V电源轨看上升沿顺序。如果PERST#比时钟先稳定释放那恭喜你找到问题了。原则上要求是电源稳定 → 参考时钟稳定 → PERST#被拉高释放→ 设备开始链路训练。如果时序错了复位信号需要重新设计RC延时或者由SoC的GPIO控制。另一个常见问题是复位信号上拉了但被外部的电平转换芯片或逻辑门延迟了导致时序本身没问题但边沿太缓上升时间过长设备不能正确识别复位释放。我建议用GPIO直接控制PERST#而不要用简单的RC网络因为RC的充放电时间受温度和供电电压影响很大生产一致性差。设备树里可以配置PERST#对应的GPIO后面我会细讲。电源方面主要看3.3V和12V给插槽供电的话。PCIe链路训练不成功有时候是电流不够导致端点瞬间掉电复位。用电流探头测一下端点启动瞬间的电流峰值如果超过电源标称值或电源保护阈值赶紧换更大电流的电源别浪费时间在软件上。2.3 PCB走线和连接器别让高速信号死在过孔和Stub上PCIe3.0 x2一共有2对差分发射TX、2对差分接收RX也就是8根高速信号线其中每一对走线都要做100Ω差分阻抗控制。RK3568的PCIe3.0走线如果经过连接器或者板对板连接器需要特别注意连接器本身的插入损耗和回波损耗指标便宜的连接器在8GT/s速率下损耗会显著增加。PCB走线有几个我反复强调的注意点差分对内等长控制在5mil以内差分对间不等长控制在150mil以内具体以Layout Guide为准。等长不只是长度相等还要考虑过孔、弯折的电气延迟差异。信号换层时确保附近有完整的回流地过孔不能为了省几个过孔把换层处的参考平面打断。所有PCIe高速差分线禁止跨分割包括电源平面分割层也一样。AC耦合电容建议靠近发送端放置而且要用0402或更小封装焊盘stub尽量短。如果板子有测试焊盘或调试探针一定要用“焊盘内过孔”或“虚焊盘”方案避免在主走线上长出长stub。这些如果不注意虽然理论上PCIe3.0在短距离下还能忍受一点不完美但你在实际调试中就会发现低温下正常高温下时不时掉Link或者连续跑压力测试没问题一拔插设备就要重新枚举。我甚至遇到过因为测试时用了飞线连接器整个PCIe3.0链路只能协商到Gen1飞线一拆换了好一点的同轴线立即恢复Gen3。所以硬件端的干净程度决定了你后面所有软件调试的工作量。3. SoC底层配置IO复用、PHY工作模式与uboot侧确认3.1 引脚复用管脚怎么查和怎么配RK3568的很多引脚是复用的PCIe3.0的信号脚如果被复用成了其它功能比如SATA、USB3.0、GMAC控制器是无法正常工作的。查引脚复用最权威的依据是瑞芯微官方的《RK3568 TRM》和《RK3568 Datasheet》里的引脚功能表。在设备树里引脚复用通常由pinctrl子系统管理你会在dts里看到类似这样的定义pcie30x2: pciefe280000 { compatible rockchip,rk3568-pcie; ... pinctrl-names default; pinctrl-0 pcie30x2_mclk; ... };其中pcice30x2_mclk这个节点就是在pinctrl驱动里配置PCIe30x2的时钟引脚。除了参考时钟引脚还有PERST#复位引脚有些设计还需要CLKREQ#。这些引脚都需要确保没有被复用为GPIO或其它外设功能。判断方式就是检查对应PMU/GRF寄存器里IOMUX位的值。实际操作时我不建议自己对着TRM去硬翻寄存器更高效的方式是在内核源码里搜pcie30x2_mclk、pcie30x2_perst之类的宏定义确认是否已有现成配置用i2c或io寄存器调试工具比如devmem2读一下GRF寄存器对比TRM里的IOMUX表确认当前复用状态如果复用错了直接在内核dts里把对应节点的pinctrl配成PCIe功能。这个环节最常见的坑是RK3568的PCIe3.0控制器信号和SATA/USB3.0共用部分引脚设计上通过Combphy的复用选择来切换。如果你同时开了SATA和PCIe3.0两个控制器抢同一个PHY会导致两边都起不来或偶尔起来。3.2 PHYCombphy的选择与模式切换RK3568有两个高速Combphy分别叫combphy0和combphy1。每个Combphy可以根据需要配置为PCIe、SATA、USB3.0这些模式。PCIe3.0 x2的链路需要2个lane正好占用2个CombphyPCIe3.0 x4则需要占用2个Combphy并作为两对差分对合并使用。所以你的设备树里PCIe3.0控制器节点需要引用2个PHYphys combphy1_ps PHY_TYPE_PCIE, combphy0_ps PHY_TYPE_PCIE; phy-names pcie-phy, pcie-phy;这里的PHY_TYPE_PCIE是一个枚举定义表示把Combphy切到PCIe模式。如果这个是错的比如写成PHY_TYPE_SATA那PHY显然不会输出PCIe信号链路训练直接就失败了。这个代码放在设备树的控制器节点里但也有放在PHY自身节点里的写法取决于你用的内核版本和瑞芯微BSP的代码结构。在确认PHY模式时可以通过/sys/class/phy/或/sys/kernel/debug/下的接口查看当前PHY状态不过不同内核版本路径不太一样。更直接的方法是读Combphy的寄存器比如PHY_MODE寄存器看当前设置的mode值。这块我建议你在uboot阶段就先验证因为uboot下PHY驱动更简单出问题容易定位。3.3 上电阶段如何从uboot快速确认链路RK3568的uboot通常会初始化PCIe控制器你可以利用uboot的pci命令做快速自检。启动时进入uboot命令行输入pci enum pcipci enum会触发PCIe枚举如果链路训练成功且挂上了设备pci命令会列出总线上的设备vendor ID、device ID等。如果这里看不到设备那大概率不用去折腾内核了——硬件、PHY配置或者设备树在uboot里就已经有问题。有些板卡的uboot默认没有使能PCIe需要在defconfig里打开CONFIG_PCI、CONFIG_DM_PCI等配置。打开之后开机日志里还会打印PCIe控制器的初始化信息关键是看有没有类似“link up”的日志以及协商到的速率是多少。这一步相当好用因为在uboot阶段还没有复杂的内核驱动介入排查范围更小。如果uboot里pci enum能识别到设备但启动内核后又不行那问题多半出在内核设备树和内核驱动配置上排查方向立即缩小一大半。反过来如果uboot里根本没有设备那你需要回到时钟、复位、供电、PHY模式这些底层环节查。4. 设备树配置从控制器节点到PHY节点的一次过4.1 设备树里一个完整的PCIe3.0 x2节点长什么样到了这一步默认你已经确认硬件基本正常、PHY模式也正确那么接下来就是设备树的事。RK3568 PCIe3.0控制器的设备树节点在Linux内核里通常位于arch/arm64/boot/dts/rockchip/rk3568.dtsi中而板级设备树比如rk3568-evb.dts或你自己的板子dts负责填充和覆盖属性。我给出一个典型且可用的PCIe3.0 x2节点配置这是我在实际板卡上验证过的结构pcie30x2 { status okay; vpcie3v3-supply vcc3v3_pcie; vpcie1v8-supply vcc1v8_pcie; pinctrl-names default; pinctrl-0 pcie30x2_mclk, pcie30x2_perst; reset-gpios gpio0 RK_PC6 GPIO_ACTIVE_HIGH; num-lanes 2; phys combphy1_ps PHY_TYPE_PCIE, combphy0_ps PHY_TYPE_PCIE; phy-names pcie-phy, pcie-phy; max-link-speed 3; };逐个解释一下vpcie3v3-supply和vpcie1v8-supplyPCIe插槽或端点的电源控制驱动会在初始化时打开对应电源。如果这两个节点对应的regulator没有被实际电源芯片支持或者电源域的regulator配置错误驱动初始化会报错。注意有些设计不需要3.3V和1.8V分开那也要确认这个属性是否要写。reset-gpiosPERST#复位引脚。num-lanes 2链路宽度是x2。如果写4但物理上只有2根线控制器会一直协商x4失败反过来写2即使物理上是4根线也只协商到x2。phys和phy-names绑定两个Combphy这是x2的关键。如果这里只写了一个phy链路就只能工作在x1。max-link-speed 3限制最大速率是Gen3。4.2 每个关键属性背后的硬件含义很多教程会直接告诉你“照着填”但我们要明白每个字段在硬件上代表了什么。num-lanes影响的是控制器侧的链路宽度能力。DW PCIe控制器在初始化时会根据这个参数配置链路宽度寄存器同时LTSSM训练时会在对应宽度上做训练序列。如果你实际硬件只连了2根lane但设备树写4则训练会等待另外2根不存在的lane达到ready状态最终超时——表现就是link up失败或长时间卡在检测状态。反过来写1那即使硬件连了2根最终也只能协商成x1。max-link-speed实际上是link-capabilities寄存器的一个映射。RK3568的PCIe3.0控制器本身支持Gen3但如果你写成2就相当于告诉对端“我最高只能支持Gen2”两边协商时就会取双方都支持的最高速率于是固定跑在Gen2。这个属性有时候被用来做兼容性测试或者在某些信号质量不佳时临时降低速率让链路稳定工作。reset-gpios必须对应到真实的硬件复位网络。写错GPIO的话相当于复位信号根本没有被控制设备可能在错误的时间被复位或者一直处于复位状态。调试时可以在设备树里把这个GPIO配置为GPIO模式用示波器看它拉高拉低的时序确认是否和预期一致。值得注意的是RK3568的内核设备树节点里一般已经定义了默认的中断属性、寄存器地址范围、bus-range、ranges等。其中ranges定义了PCIe地址空间与CPU地址空间的映射如果这个配置错了设备能枚举到但访问BAR空间时就会出问题。这个一般不需要自己改但排查问题时要心里有数。4.3 PHY节点与控制器节点的接法设备树里绑PHY的方式看似简单但细节很重要。phy-names写两个相同的字符串“pcie-phy”是常规操作对应drivers/phy/rockchip/phy-rockchip-naneng-combphy.c里的解析逻辑。如果你的内核版本比较老也有版本里用“pcie-phy0”、“pcie-phy1”的写法具体看源码匹配字符串。在PHY节点本身需要确保rockchip,phy-mode配置成了PCIe模式。通常这个配置在combphy节点自身而不是使用者节点里设置。例如combphy1_ps { status okay; rockchip,phy-mode pcie; };combphy0_ps、combphy1_ps哪个对应哪条PHY lane需要以原理图和SoC手册为准。我调过的一块板子原理图上写着PCIe x2的lane0对应combphy0lane1对应combphy1但设备树里顺序写反了导致两根线互相交叉在x1模式时反而正常因为只用了一根x2时完全不通。所以如果x1正常但x2失败先检查物理映射顺序。4.4 改完设备树后怎么确认生效改完设备树后确认是否真的生效有几个方法首先看内核启动日志搜索pcie、dw-pcie、phy相关打印。正常日志里应该能看到PCIe控制器探针成功、PHY初始化成功、LTSSM进入L0状态。如果设备树属性写错了日志里往往会明确提示缺少phys、num-lanes配置等。然后看系统起来后的设备列表。在命令行执行lspci -vvv如果能看到你的端点设备并且LnkSta显示Speed 8GT/s, Width x2就说明一切正常。这里顺便教大家一个小技巧lspci -vvv里的LnkCap和LnkSta分别表示“能力上限”和“当前状态”这两个值经常不一样——能力是最高支持多少状态是实际协商到多少。如果lspci看不到设备可以用dmesg | grep -i pcie查看内核日志。日志里如果出现“PCIE LINK UP SPEED 5.0 GT/S”之类的字样说明链路已经Link了只是设备枚举还有问题如果一直停留在“wait link down”或“no link”状态那就继续往硬件或PHY方向查。5. 运行时验证与链路诊断从lspci到dmesg的完整体检5.1 系统起来后第一步看什么系统正常启动后我的习惯是按顺序执行以下命令lspci lspci -vvv -d :device id dmesg | grep -i -E pcie|pci cat /sys/bus/pci/devices/0000:00:00.0/current_link_speed cat /sys/bus/pci/devices/0000:00:00.0/current_link_widthlspci不带参数会列出总线上所有设备如果这里根本没有你外接的设备说明链路训练或设备枚举没完成。current_link_speed和current_link_width是两个很有用的sysfs节点直接读出协商结果比看寄存器省事。举个例子我在调一块NVMe SSD时lspci能看到设备但是读写速度只有预期的一半。一查current_link_width发现是x1不是x2。说明物理上SSD本身可能只支持x1或者RK3568这边没有正确配置成x2。后来确认是设备树里num-lanes写成了1改回2之后宽度立即变成x2。还有一种情况current_link_speed显示5GT/sGen2但你配置的max-link-speed3。这时可能是链路训练失败了或者对端设备能力不足也可能是信号质量差导致Link Training在Gen3速率上失败主动降级到Gen2。检查这个的思路就是先用dmesg看有没有报错再评估信号质量。5.2 dmesg日志怎么读哪一行才是关键dmesg日志里和PCIe相关的打印大致可以分成几个阶段控制器驱动探针dw-pcie proberk-pcie fe280000.pcie: host bridge /pciefe280000 ranges: rk-pcie fe280000.pcie: Parsing DT ... rk-pcie fe280000.pcie: Missing dts property, using default 0这一段说明控制器驱动已经加载开始解析设备树属性。如果这里没打印说明设备树status不是okay或者驱动没有匹配上compatible。PHY初始化rockchip-phy fe2a0000.phy: pcie phy power on如果你看到PHY初始化失败或者根本没有对应打印那就是PHY配置问题。链路训练结果rk-pcie fe280000.pcie: PCIe Link up, LTSSM is 0x0 rk-pcie fe280000.pcie: PCIe Gen3 x2 link up这是最关键的日志。如果这里显示link up说明硬件链路已经建立。如果一直停在wait link的状态说明LTSSM没有进入L0。设备枚举pci 0000:00:00.0: [1dbe:5216] type 00 class 0x010802 pci 0000:00:00.0: enabling device (0000 - 0002)这里出现设备的vendor ID和device ID说明枚举成功。我建议你在调试时用dmesg | grep -i rk-pcie\|rockchip-phy\|pci 0000过滤只关注这几行别被大量无关日志淹没。5.3 设备挂不上时的分级排查思路如果设备在lspci里看不到我用的排查思路是“从远到近、从硬件到软件”五步法第一步先确认PCIe控制器本身有没有probe成功。看dmesg里有没有rk-pcie驱动的打印。如果没有优先查设备树status、compatible、reg地址对不对。第二步确认PHY有没有初始化成功。看dmesg里有没有rockchip-phy相关的打印特别是是否出现错误。如果PHY status异常用寄存器工具读PHY的mode确认是不是PCIe模式。第三步确认链路有没有Link。反复看LTSSM状态如果状态卡在Detect或者Polling说明物理信号有问题。这时候拿示波器去看PCIe时钟和数据线上的信号是否正常。第四步确认有没有枚举。Link UP了但没有枚举出设备可能总线地址冲突、设备本身异常或者ranges配置导致BAR空间访问失败。这时用pcirealloc之类的内核参数重新分配资源试一下。第五步如果上面都正常但设备还是不可用那就要怀疑设备驱动本身。换一个已知OK的PCIe设备比如把NVMe换成PCIe转USB卡做交叉验证能快速区分是主控制器问题还是设备兼容性问题。这个方法帮助我快速过滤了至少70%的问题不用每次都从头排查。6. 常见问题与实战排查把踩过的坑一次性说清6.1 常见问题速查表我把调试中常见的问题整理成了一张表方便大家直接对照排查。现象优先排查方向定位方法uboot阶段pci enum无设备硬件信号、电源、复位时序示波器抓参考时钟和PERST#uboot正常但内核lspci无设备内核设备树status/phy绑定dmesg过滤rk-pcie和rockchip-phy链路只能Link到Gen1/Gen2信号质量问题、max-link-speed限制看dmesg链路速度测信号眼图链路宽度是x1而不是x2设备树num-lanes、物理lane映射current_link_width、PHY顺序能枚举设备但访问BAR失败ranges配置、CPU地址冲突lspci -vvv看BAR读内核日志高速读写时掉Link信号完整性或电源纹波换速率测试、测电源纹波插槽上电但设备无反应vpcie3v3/vpcie1v8电源未打开查regulator状态、实测电压6.2 几个比较典型的调试经历说一个我印象很深的案例。一块RK3568板子PCIe3.0 x2接了一个数据处理卡uboot下能看到设备内核里也枚举成功但一跑DMA就报错而且偶发性系统卡死。这种问题最难查因为它不是稳定复现更像是时序或电气问题。后来我用perf和dmesg反复对比发现DMA操作时控制器报AER错误PCIe的TLP层出现了CRC错误。最终定位到问题是参考时钟的扩频SSC配置不对。PCIe规范里允许参考时钟带扩频-0.5% SSC但要求端点和根端口两侧配置一致。我这块板子的时钟芯片开了SSC但端点是固定频率模式两边对不上导致高速传输时偶尔出现CRC错误。关掉时钟芯片的SSC功能后问题彻底消失。所以如果你遇到“偶发错误、和读写负载成正相关”的PCIe问题SSC配置一定要查。另外一个例子是调试PCIe转千兆网卡Link正常、枚举也正常但是网卡收包丢包率极高。用ethtool -S看统计发现RX_CRC_ERROR非常多。最后查到是PCIe插槽附近的退耦电容值不对导致高速信号在PCB上的回损过大信号完整性问题最终表现为链路层CRC错误。所以说PCIe这种高速接口很多问题看似软件能解决其实根源在硬件端。6.3 我自己的调试验证清单这里分享一份我个人总结的调试验证清单每次新板子或者新方案我都会按这个顺序过一遍很多人拿到板子就直奔设备树漏掉了太多前置条件原理图检查PCIe参考时钟来源和端接、PERST#的控制方式和时序、电源域和去耦电容上电实测100MHz参考时钟波形、PERST#释放时序、3.3V/1.8V电源稳定度uboot阶段pci enum确认是否有设备协商到的速率和宽度内核阶段dmesg确认控制器驱动和PHY初始化lspci确认设备列表功能验证用PCIe设备做实际数据读写比如NVMe跑dd测试网卡跑iperf3打流稳定性验证长时间压力测试、高低温箱测试重点观察是否掉Link或出现AER报错。这套流程看起来很笨但效率最高能减少大量无效调试时间。最后分享一点经验我在实际调试过程中最深的体会是PCIe调试不要急着改代码先确认硬件健康度。所谓“设备树配置错误”更多时候只是压死骆驼的最后一根稻草前面的硬件问题才是根本不稳的根源。特别是RK3568这种集成了多个Combphy的SoC原理图上各种复用关系容易把人绕晕动手前把信号路径画清楚能省几天时间。另外调试环境里备一个好用的串口调试助手和示波器是刚需很多问题在串口日志里只留下一个“wait link”或者一次中断风暴没有示波器佐证你在软件层面猜来猜去很难有结果。如果你们的目标是控制类实时通信比如配EtherCAT主站PCIe链路的稳定性更是基石这一关过了后面跑实时协议才谈得上可靠。