做嵌入式这几年凡是涉及高速接口的新板卡uboot阶段最让人精神紧绷的往往就是PCIe。这个子系统横在硬件和软件之间硬件上一根根的lane、参考时钟、复位时序稍有不对链路就训练不起来软件上uboot的PCIe驱动模型、枚举流程、DTS绑定又自成一套体系跟内核里那套还不太一样。这篇是我梳理uboot PCIe子系统时整理的路线图从硬件基础到驱动代码从枚举原理到调试命令尽量一次讲透。适合正在调uboot、想搞懂PCIe枚举过程、或者被掉卡、降速问题折磨的工程师参考。1. 为什么要在uboot阶段死磕PCIe1.1 引导阶段PCIe的现实需求很多人会问uboot里把PCIe调试通到底图什么最直接的原因是引导设备。NVMe SSD挂在PCIe上如果想从NVMe启动系统uboot就必须在引导阶段完成PCIe控制器初始化、链路训练、枚举设备、找到NVMe的BAR空间再通过NVMe协议读写块设备。这个链路任何一个环节断了系统就起不来。除了NVMe常见的PCIe引导设备还有SAS/RAID卡、PCIe网卡PXE启动、GPU不少ARM板子要借独显输出console。可以说uboot阶段对PCIe的需求本质上就是“尽早拿到能用的高速I/O”。另外一个不那么显眼但同样重要的原因是诊断。高速链路的问题往往在uboot阶段比内核阶段更容易定位因为uboot环境简单、没有操作系统调度干扰pci命令一敲就能看到枚举结果。很多内核态花了几天排查的降速问题在uboot里读一下链接状态寄存器就真相大白。所以uboot里的PCIe子系统不光是引导工具更是整块板子高速链路健康状况的“第一道体检”。1.2 uboot的PCIe子系统与内核的差异uboot的PCIe子系统和Linux内核相比体量小得多但骨架是相似的。内核里有PCI核心层、总线驱动、port驱动、各级子系统uboot在引入Driver ModelDM之后把PCIe抽象成UCLASS_PCI控制器、UCLASS_PCI_GENERIC设备等逻辑上一样有枚举、配置访问、BAR分配、地址资源映射这一整套流程。区别在于uboot是单线程的没有完整的中断处理框架没有电源管理也没有标准热插拔状态机甚至错误处理都很简陋。好处是代码简单直接适合从整体上理解PCIe的运行机制坏处是很多问题在uboot阶段容易被忽略等到内核起来才爆发。我见过不少项目uboot枚举一切正常进内核后却AER报错或者链路掉到Gen1。原因往往是uboot里只做了“能跑起来”级别的初始化PHY均衡、供电时序没处理好。所以现在很多原厂BSP在uboot里把PCIe初始化做得越来越完整像RK3399、i.MX8平台uboot阶段就能看到完整拓扑、可调的链路参数。这也是我写这篇梳理的动力uboot里这套东西值得系统过一遍。2. 先搞懂PCIe硬件基础再读代码2.1 拓扑结构RC、Switch与Endpointuboot代码里你会反复看到几个名词RCRoot Complex、Switch、Endpoint。RC是整个PCIe域的根相当于CPU侧的“主人”负责发起配置访问、管理内存映射、转发IO。Endpoint是被管理的设备比如NVMe SSD、网卡、GPU。Switch则像交换机把一个PCIe端口扩展成多个端口让一颗RC芯片能带很多设备。理解拓扑结构是读代码的前提因为你会在DTS里看到bus-range会在pci命令输出里看到总线号实际上这些都是在描述这棵拓扑树。拓扑上有个重要概念总线号bus number。RC默认对应bus 0每经过一个PCIe桥包括Switch内部的虚拟桥总线号就往下递增一个。uboot枚举时按bus号一层层扫描正是靠这种树形结构组织的。你拿pci命令看到的输出里那个xx:xx.x前一个数就是bus号中间的数是device号最后是function号。遇到复杂拓扑我一般手动画一遍树把每个桥的总线号标出来再回看代码思路会清晰很多。2.2 引脚、时钟与链路协商PCIe物理层是一条条差分对每条lane由发送差分对PETp/PETn和接收差分对PERp/PERn组成。x1就是一对收发x4就是四对。除数据线外还有REFCLK参考时钟通常100MHz、PERST#复位信号、以及用于热插拔检测的PRSNT#。很多新人在layout阶段忽略参考时钟走线质量结果链路训练不稳定。这里热词里问到的“pcie时钟需要对地电容吗”至少要分清两类一是参考时钟线上的AC耦合电容用于隔离直流分量这是标准设计二是电源引脚附近的去耦电容用于稳定供电这些不是可选项缺了直接表现为握手失败或间歇性掉卡。链路训练可以理解成两个设备“握手”先检测对端存在Detect再交换训练序列TS1/TS2协商速率和宽度最后进入L0正常工作状态。这个过程由硬件状态机LTSSM完成uboot做的主要是发起链路训练、等待状态稳定、读回协商结果。每代速率对应一个速率等级Gen1是2.5GT/sGen2是5GT/sGen3是8GT/sGen4是16GT/s。如果双方最大支持速率不一致或信号质量不达标就会协商到低等级——这就是平时说的“降速”。做Gen3以上PCB时信号完整性仿真pcie仿真几乎是必须环节否则等到uboot去训练链路才发现眼图不满足返工成本就大了。2.3 配置空间与BAR分配理解PCIe配置空间几乎是uboot调试的必修课。每个PCIe设备都有配置空间前256字节兼容传统PCIPCIe在此基础上把扩展空间延伸到4KB偏移0x100开始的部分用于存放AER、热插拔、链路状态等能力集。配置空间里最基础的是vendor ID、device ID、class code以及BAR基地址寄存器。BAR是设备向软件申报地址空间需求的窗口软件往BAR写全1再读回就能算出设备需要多大内存空间然后给它分配一个合适地址。uboot枚举时干的活本质上就是“认出设备、给它编总线号、再给它分地址空间”。对于Endpoint配置头是Type0对于桥设备是Type1。理解这两种头结构你才能看懂枚举递归的逻辑。uboot里对配置空间的访问有两种路径一种是传统的IO端口方式另一种是基于ECAM的内存映射方式。现在主流SoC基本都用ECAM比如DesignWare核通过iATU把配置空间映射到CPU地址段。如果枚举时读到的ID全是0xFF或者超时优先怀疑配置访问路径根本就没建立起来。3. uboot PCIe驱动架构与代码路线3.1 驱动模型DM下的PCIe框架从U-Boot 2017年前后开始新PCIe驱动基本都基于DM模型。DM把设备、驱动、uclass三者分开设备来自DTS驱动实现uclass规定的操作接口uclass则提供对外通用API。对于PCIe控制器驱动会注册到UCLASS_PCI同时它的ops结构体里包含map_bus、read_config、write_config等回调。上层代码pci-uclass.c调用这些回调完成配置读写。这个设计与内核的struct pci_ops思路很像如果你熟悉内核PCI驱动上手会非常快。看代码的时候有个小技巧先打开include/dm/pci.h把struct pci_controller、struct pci_child_platdata这些核心结构体理清再去看drivers/pci/pci-uclass.c。你会看到一条清晰的流程pci_init()进入uclass扫描根总线为每个发现的设备创建子节点读取ID和class如果发现桥就递归扫描。把这条主线的函数调用关系写下来整个PCIe驱动的框架就掌握了。别一上来就扎进某个特定CODEC控制器驱动那样容易被寄存器细节带偏。3.2 常见控制器驱动适配方式不同SoC的PCIe控制器实现差异很大uboot里的驱动也因此分多种。最常见的是Synopsys DesignWare核Rockchip、NXP部分平台、全志等都用它。对应驱动是pcie_dw.c和pcie_dw_common.c主要工作包括配置控制器核心寄存器、拉起LTSSM、配置iATU地址转换单元。iATU是个关键模块它把配置空间、内存、IO分别映射到CPU地址空间相当于软件看到的地址和PCIe总线地址之间的翻译器。如果没有iATU映射配置空间根本访问不了。以RK3399为例DTS里ranges 0x82000000 ... 0xfa000000 ... 0x600000定义了非桥接的PCIe内存窗口配置空间则通过reg属性里的一段地址映射到ECAM协议。调这种平台如果pci命令枚举不到设备第一步先查iATU映射是否正确第二步查PERST#复位释放时序第三步查参考时钟和供电。这三个问题占了新板子PCIe问题的大头。还有一种情况是控制器本身初始化成功但PHY没起来表现是寄存器能读写但LTSSM一直卡在Detect这时候就要往时钟/供电方向深挖。3.3 DTS绑定与属性解析uboot的PCIe节点和内核的PCIe节点基本复用同一份DTS但uboot只关心它需要的属性。重点属性有这么几个bus-range定义该控制器管理的总线范围num-lanes和max-link-speed影响链路协商配置ranges定义CPU地址到PCIe总线地址的映射包括32位内存空间0x82000000、IO空间0x81000000、64位内存空间0xc2000000等。compatible字符串决定了驱动绑定。调新平台时DTS里compatible必须和驱动匹配上否则设备节点probe都会失败。我踩过的坑里一个典型是bus-range 0x0 0xff和ranges里的窗口大小不匹配枚举时uboot给下游设备分配总线号没问题但BAR分配时可用内存窗口太小多个设备地址重叠。这种问题在uboot里通常表现成“第一个设备正常第二个设备读写异常”进了内核后用lspci -vvv能明显看到BAR地址重叠。另外有些平台的多控制器设计需要在DTS里显式错开bus-range否则两个控制器从bus 0开始枚举结果相互串扰。4. 枚举过程精读从扫描到BAR分配4.1 枚举主流程uboot的PCIe枚举要解决的核心问题就一句话“这条总线上挂着谁它们需要多大资源我怎么分配地址不打架。”处理流程大致如下控制器初始化完成使能LTSSM、等待链路训练到L0从根总线bus 0开始按devfn从0到255遍历所有设备/功能每个节点读vendor ID和device ID判断是否有设备存在没设备跳过有设备则创建子节点记录devfn、vendor、device、class如果读到的header type显示是桥说明下面还挂着次级总线就分配新的bus number并递归扫描全部扫描完后统一做BAR分配和资源映射。这个流程写起来简单实际代码里牵扯到pci_scan_bus()系列函数、pci_add_child()、pci_bus_order()等不少细节。拿drivers/pci/pci-uclass.c看时重点盯dm_pci_scan_bus()和pci_uclass_child_post_probe()前者负责扫描发现设备后者在子设备probe完成后做一些地址/资源处理。我建议你第一次读的时候在纸上连续画出三层设备RC→桥→Endpoint的枚举轨迹把每个阶段的变量变化记下来比反复看代码更有效。4.2 桥设备与总线号分配桥设备是枚举中最容易出错的地方。配置空间Type1 header里primary bus number、secondary bus number、subordinate bus number三个字段分别记录了桥上游、下游、最深可达的总线号。uboot扫描到桥后要先把这些字段设置好再递归扫描下游。如果这里设置错误下游设备要么枚举不到要么被赋予错误的总线号导致配置访问寻址不到。这类问题在log里往往表现为“设备读到了但是后续访问挂死”或“某些function随机消失”。多控制器系统是另一个重灾区。比如一个SoC有两路PCIe控制器DTS里bus-range必须错开否则两个控制器都从bus 0开始配置空间会串。原厂BSP通常会在DTS里把控制器0定义为bus-range 0x00 0x1f、控制器1定义为0x20 0x3f。我见过有人图省事把bus-range都留默认结果两个控制器枚举出的设备ID混在一起排查起来极其痛苦。所以拿到新板子第一件事就是把DTS里所有PCIe节点的bus-range画出来确认没有范围重叠。4.3 BAR分配与地址映射枚举完设备下一步是给每个设备的BAR分配地址。uboot的操作方式对一个BAR先写0xFFFFFFFF读回掩码算出所需大小和对齐然后按优先顺序分配地址最后把分配到的地址写回BAR并在桥的存储器窗口里加上相应范围。对应代码主要是pci_size_bars()、pci_assign_bars()。这里的“大小”必须是2的幂次且按设备要求对齐写全1读回掩码这个技巧本质上是利用PCI规范设计的“可编程基址”机制。这里有个容易忽略的点如果DTS里ranges窗口比设备BAR需求小分配就会失败或重叠。另一个经典问题在64位BAR设备上64位BAR需要两个连续的BAR寄存器配合前一个寄存器和后一个组合成64位地址分配时必须作为一个整体处理不能只分配其中一个。很多uboot的BAR分配bug都出在64位BAR处理上尤其是设备有多个64位BAR时。另外有的网络设备例如Realtek的PCIe千兆网卡在32位系统上常因BAR落在4GB之上而不可达uboot阶段如果能通过pci bar确认并把BAR控制在低32位地址空间能减少很多兼容性烦恼。5. 实操uboot下的PCIe调试命令与手段5.1 常用命令实战uboot提供的PCIe调试命令在工程里非常实用。pci enum强制重新枚举整个PCIe域pci不带参数列出所有设备pci header查看指定设备的配置头pci bar查看和修改BARpci display直接dump一段配置空间。另外别忘了DM系的命令dm tree可以查看设备驱动模型树dm uclass可以查看PCIe uclass下的设备实例。新手上路时最容易忽视这些信息类命令其实他们把设备从DTS绑定到驱动再到实例化的全过程都暴露出来了定位问题时特别有用。调试我一般按这个顺序来先pci enum看能不能枚举到设备列表空就排查控制器初始化链路再pci header看vendor/device ID和class code确认读到的不是垃圾值设备出来了但BAR读写异常用pci bar核对BAR地址再用md命令读对应地址验证进内核前确认链路协商结果读到PCIe能力集里的link status寄存器看speed和width是否符合预期。这套顺序我称之为“加电—枚举—资源—链路”四步走基本覆盖了新板卡PCIe首轮调试的绝大多数场景。5.2 枚举不上、掉卡、降速的排查思路新板子最常遇到的就是枚举不上。处理优先级我一般是供电检查3.3V辅助电和主供电有没有按时序拉起来→ 时钟检查100MHz参考时钟是否干净、AC耦合电容是否遗漏→ 复位时序PERST#释放是否晚于供电和时钟稳定→ 链路训练用示波器抓TS序列或读LTSSM状态寄存器。这里再补充一句时钟问题PCIe参考时钟走线要求很严格不是“能出波形就行”对抖动和共模电平都有要求满足不了轻则开机链路慢重则直接跑不起来。掉卡问题分两种部分板子跑着跑着设备消失这是硬件链路不稳定供电波动、连接器氧化、时钟抖动过大还有一种是从uboot跳内核时“掉”往往是uboot和内核的复位时序不一致或者uboot阶段重新枚举导致链路训练失败。内核里看dmesg会有pcieport的link down消息再用lspci -vvv看Link Status。降速也一样如果协商结果总是Gen1而不是Gen2/Gen3先确认两端最大支持速率再看PCB走线长度、过孔数、端接电阻和PHY均衡配置。5.3 热插拔与信号完整性的几个坑uboot阶段的PCIe热插拔并不是标配能力。常规做法还是开机枚举时保证设备在位热插拔更多交给OS处理。但这不代表uboot可以完全不管如果整机设计支持热插拔的盘位或扩展槽uboot的枚举代码需要处理PRSNT#状态避免设备不在位时误报错误或尝试访问不存在的设备导致挂死。这块在各平台BSP里支持程度不一实测下来还是先把冷启动链路做稳更重要。信号完整性是另一个大坑Gen3以后尤其明显。链路训练加入了均衡equalization过程发送端和接收端要互相协商信号补偿参数。uboot层面的工作通常是配置PHY的预加重/去加重系数或者选择Gen3均衡握手的开关状态。很多平台在uboot里默认关闭Gen3均衡结果链路在Gen3边缘反复重训最终掉到Gen2。遇到这种情况可以先用max-link-speed 2在uboot里锁定Gen2验证功能正常再回头从PCB走线和PHY配置方向去解决Gen3问题这样至少能把“链路有没有物理连通”和“高速信号质量够不够”两个问题拆开。6. 兼容性与稳定性的工程经验6.1 经典问题速查表我把自己在uboot PCIe调试中遇到的典型问题整理成表方便对照排查现象最常见原因排查手段枚举不到设备PERST#释放时序不对或POE供电异常示波器抓复位时序读LTSSM寄存器枚举到设备但读BAR全是0xFFiATU映射未配置或配置空间基址错误检查ranges和reg核对配置空间映射进内核后AER报错uboot与内核PCIe初始化参数不一致对比DTS关闭ASPM做A/B测试协商掉到Gen1参考时钟质量差、走线过长抓REFCLK眼图先锁定Gen2验证第二个设备BAR重叠ranges窗口不足或bus-range冲突增大窗口调整多控制器bus-range热插拔后设备不复位缺PRSNT#处理或电源时序不完整检查插槽PRSNT#接法核对电源开关时序32位系统访问枚举设备失败BAR被分配到4GB以上uboot阶段用pci bar固定低端地址除了表格里的问题还有一个常被问的兼容性问题是“mini PCIe能不能插在PCIe x1上”。物理上mini PCIemPCIe就是x1的电气接口但尺寸和固定方式不同需要用转接卡才能插到标准x1插槽反过来x1设备插到mPCIe插槽同样需要转接。uboot代码层面这类设备没有区别只要链路是x1就能正常枚举。真正影响枚举的是设备自身对配置访问的响应速度少数Endpoint设备配置空间读取比较“慢”uboot枚举轮询太快时会误判设备不存在此时需要在驱动里加适当的访问延时限速或重试机制。6.2 关于稳定性的一点体会说句实在话uboot里的PCIe子系统这套东西光看代码远不如“带着问题看代码”效率高。我在调一款用DesignWare核的平台时一开始也是对着pci-uclass硬读完全抓不住重点。后来反复看一张实际启动log、对照pci enum输出和DTS里的ranges才把枚举、总线号、BAR这些概念串起来。对新手我的建议是先掌握一句话主线——“把每个设备的配置空间读出来、给它总线号、再分地址”——其余都是这条主线上的细节。从uboot到内核的稳定性还是一个容易被忽视的分水岭。uboot里初始化OK并不代表进内核就万事大吉。我有一次调一块带Switch的板子uboot枚举和NVMe读写全都正常一进内核就周期性AER报错。最后定位到是uboot在启动内核前重新复位了PCIe链路而这个时序让Switch没有足够时间完成内部初始化。解决方案不是改内核而是在uboot的启动流程里增加一个延迟或二次枚举逻辑。这类跨阶段问题只有在uboot侧有了整套清晰的PCIe子系统认识才可能快速定位。最后再分享一个实操技巧uboot阶段想快速验证PCIe链路有没有通不需要急着进系统。pci enum后直接用pci bar确认设备BAR然后找一段地址用md读读看能不能读到设备数据。对于NVMe可以再挂上nvme驱动试试能不能ls到盘。链路是不是真的稳定、数据通路通不通这一步比任何log都直观。PCIe子系统看着大但只要把硬件基础、驱动模型、枚举流程、调试手段这几块吃透新平台上手就能快不少。至少我手里的下一块板子合入uboot时PCIe相关的修改量已经从最初的两周缩到了两天这套梳理方法确实管用。