1. 为什么Link Startup决定了UFS设备能否被“看见”做UFS驱动和底层固件的人都有一个共识链路启动Link Startup是整条初始化的第一道坎也是排查起来最费劲的一道坎。很多同事第一次接触UFS时习惯性地拿eMMC那套思维去套——上电、等复位完成、读CID、识别设备完事。但UFS完全不是这个逻辑。UFS在真正进入命令传输之前Host和Device之间要先建立一条完整的物理链路和协议层链路这套过程就是UFS Link Startup。UFS的协议栈分三层应用层UPU/UPC、传输协议层UTP、互联层UIC。其中UIC层又包含M-PHY物理层和UniPro数据链路层。Link Startup主要发生在UIC层确切地说是UniPro和M-PHY协同完成的。它要解决的核心问题是在Host和Device都上电之后如何把两条物理线缆从“电气沉默”状态拉起来让双方在低速模式下先能互相听懂然后再通过能力交换确认各自支持的最高速率和线数最后切换到高速模式工作。为什么说它决定设备能否被“看见”因为如果Link Startup失败host上连最基础的设备描述符都读不到。UFS不像eMMC那样有固定的CMD线上电时序UFS的设备识别完全建立在UniPro链路建立成功的基础上。换句话说你在内核日志里看到类似“ufs-hisi: link startup failed”的报错说明UFS设备一开始就没进入可通信状态后续所有操作都无从谈起。从实际项目经验来看Link Startup涉及的细节非常多物理层唤醒时序、DME属性读写、Gear与速率映射、线数协商、HS-Gear切换时机……任何一个环节不对表现出的现象可能都是“枚举失败”但根因却千差万别。这篇东西我把整个流程拆开讲一遍从底层原理到实际调试经验都覆盖到希望对正在调UFS的朋友有帮助。1.1 从eMMC到UFS多了一整层“通信协议”先花点篇幅讲清楚UFS和eMMC的本质区别理解了这个才能理解Link Startup存在的意义。eMMC本质上是把NAND Flash和一个简单的控制器封装在一起通过并行或串行的存储接口与Host相连。Host对它做的事情很简单发命令、收数据。读写时序由Host直接控制硬件上不需要“协商”什么东西。UFS走的是另一条路线。它借鉴了PC领域SATA/NVMe的思路把存储设备做成一个“协议端点”。Host和Device之间不是简单的命令/响应关系而是一条双向、支持多命令并发、具备重传机制的串行链路。这条链路的通信模型基于MIPI的M-PHY和UniPro协议整个通信过程更像两个网络设备在对话而不是一个CPU在操作外设。这就需要一套完整的“握手”流程来建立通信基础先确认物理连接是否正常再在低速状态下交换双方的基础能力然后根据能力协商出最优的工作参数最后切换到高速模式。这套流程就是UFS Link Startup。很多只做过eMMC的工程师第一次看UFS初始化流程时会觉得非常繁琐但其实这套机制的容错性是远超eMMC的。M-PHY支持多种Gear和线数配置UniPro支持重传和流控只要Link Startup能把链路拉起来后续的数据传输可靠性比eMMC高很多。代价就是初始化的复杂度上来了。1.2 一次完整的UFS初始化链路为了给后文铺路这里先把UFS从上电到可用的完整流程列出来让大家有一个全局视角。整个流程大概分四个阶段供电与复位阶段Host给UFS设备供上电源释放复位信号。此时设备内部的ROM Code开始执行完成基础时钟和电源管理初始化。Link Startup阶段这是本文的核心。Host的UniPro协议栈主动发起链路启动过程通过M-PHY物理层与Device交换唤醒序列建立低速链路PWM-G1然后双方通过DME接口读取对方属性完成能力交换最后协商并切入高速模式HS-Gear。UTP层初始化阶段链路建立后Host通过UTP层发送NOP_OUT命令确认设备命令通道正常然后读取设备描述符、配置描述符获取设备的制造商信息、支持的命令集等。功能配置阶段Host根据设备能力配置相关参数如电源模式、命令队列深度等然后发送START_STOP命令或进入正常工作状态等待上层文件系统发I/O请求。这里面最复杂的、也是最容易出问题的就是第2阶段。阶段3和阶段4虽然也有各种坑但只要链路起来了大多数问题都能通过协议分析仪或日志定位到具体命令。而Link Startup阶段出了问题提示信息往往非常有限可能是硬件时序问题、可能是PHY配置问题、也可能是UniPro状态机卡住了。1.3 Link Startup的边界到哪里算结束判断Link Startup是否成功其实有一个明确的分界点当Host通过DME_GET命令成功读取到Device的PeerDeviceID属性并且本地属性LocalDeviceID也已经被Device识别时基础链路建立就算完成了。之后的能力交换和高速切换可以看成是在这个基础上做“性能挖潜”。这里有个常见误区很多人把Link Startup和“进入HS-Gear”画等号认为必须跑到HS-G4才算初始化完成。实际上Link Startup的目标只是建立一条可用的链路最初跑在PWM-G1这种极低速模式下也是合法的。如果能跑低速链路但是无法切换到高速模式问题通常出在PHY配置或信号完整性上而不应该归类为Link Startup失败。明确了这个边界调试时就不会被带偏。当日志显示Link Startup成功后却无法进入HS模式你应该去查M-PHY的寄存器配置和信号质量而不是反复怀疑UniPro状态机。反过来说如果你连DME属性都读不到那问题大概率在物理层或者链路启动状态机排查方向要押在前面。2. Link Startup的三段式执行过程详解Link Startup虽然代码实现各有不同但协议层面的执行过程是固定的可以分为三个阶段低速训练与唤醒、本地与远程属性配置、高速模式切换。下面按这个顺序拆开讲每一段我都会解释底层的行为逻辑以及实际调试中对应的观察点。2.1 第一段低速训练与唤醒序列Link Startup的物理基础是M-PHY的“唤醒”机制。M-PHY有两种工作模式PWM模式低速和HS模式高速。在链路启动阶段双方只能使用PWM-G1速率进行通信——这是M-PHY协议规定的最低速率档位普通GPIO都能拉出这个频率范围容错性最高。具体过程是Host侧UniPro通过DME接口下发DME_RESET请求将本地UniPro模块复位到初始状态。随后Host发起唤醒序列在TX方向上向Device发送一段特定的信号翻转序列。这个唤醒序列的作用是把Device从“沉睡”或者“未知”状态拉起来让Device的M-PHY RX能够检测到Host的存在。Device收到唤醒序列后会回复一组自己的唤醒序列。至此物理层的“握手”完成两侧的M-PHY都进入活跃状态。随后UniPro层开始传输初始化帧双方交换一些最基本的协议版本信息。此时你会看到UFS驱动日志里类似这样的输出[ 2.312345] ufshcd: ufshcd_link_startup: Entering link startup [ 2.318901] ufshcd: ufshcd_link_startup: link startup completed, ret 0link startup completed出现在日志里的前提就是唤醒序列和低速帧交换都成功了。这一阶段最容易出的问题是什么呢我见过最多的就是唤醒序列的时序不满足。M-PHY对唤醒信号的脉冲宽度、间隔时间都有明确要求如果Host侧PHY配置的PWM-G1频率偏离标准值太多Device侧可能检测不到有效唤醒信号整个Link Startup就卡死在第一步。2.2 第二段本地属性配置与远程DME访问物理链路建立起来之后UniPro层进入正常工作状态。此时Host和Device各自维护一组DME属性Device Management Entity Attributes这些属性描述了设备自身的能力和状态。Host需要通过DME_GET命令去读取Device侧的属性也需要通过DME_SET命令配置Device侧的一些行为。在UniPro协议栈里DME属性的访问是通过DME_GET、DME_SET这两个请求/响应原语实现的。Host的通用接口层Generic Interface Layer负责发起这些请求经由本地UniPro模块发送到对端设备。这一阶段的动作大致包括设置本地LocalDeviceID用于唯一标识本端设备。读取远程PeerDeviceID确认对端设备已经被分配了有效ID。读取PeerTxDataLanes和PeerRxDataLanes了解对端支持的线数配置。配置PA_HighSpeed、PA_TxGear等属性为后续高速切换做准备。从协议栈实现看这一阶段也是UniPro状态机最活跃的时期。状态机会依次经历LocalDBI配置、RemoteDBI读取、链路能力交换等子状态任何一个状态超时都会导致Link Startup中断。调试这个阶段建议在代码里打开UFS的调试日志级别把DME请求和响应都打印出来。正常的初始化过程会看到一系列dme_get和dme_set调用。如果卡在某个请求上重点检查对应属性的访问权限和值范围。2.3 第三段从PWM到HS的高速模式切换能力交换完成后Host已经掌握了Device支持的Gear和线数接下来就是真正“跑高速”的环节。高速模式切换的过程在协议里叫做PA_HighSpeed切换。Host通过DME_SET将本端的PA_HighSpeed属性置为1随后双方开始协商使用哪个Gear档位。M-PHY的Gear档位从G1到G4最新规范已经到G5每档速率翻倍具体速率还取决于线数——1条线还是2条线速率会差一倍。切换过程不是瞬时的M-PHY协议规定了一个TATurnaround时间和Slew Rate补偿过程。实际表现就是先切到HS-G1稳定运行一段时间让PHY的PLL锁定然后再继续升档到HS-G2、HS-G3等目标Gear。这阶段常见的失败现象是链路能建立DME属性也能正常交换但一切换HS模式Device就失去响应。这种问题十有八九是信号完整性导致的——PCB走线过长、阻抗不连续、端接电阻配置不对都会让高速信号在Device端无法被正确采样。还有一个经常被忽略的点切换HS模式时双方对Gear的理解必须完全一致。Host认为自己切到了HS-G3但Device侧的某个属性没有配到位实际只运行在HS-G1两边速率不匹配导致的后果就是链路直接崩溃。排查这个问题的方法就是对比Host和Device两端关于PA_TxGear、PA_RxGear的配置值是否一致。3. 能力交换的核心DME属性表与关键参数很多人把能力交换理解为“读一下寄存器”其实能力交换的本质是Host通过DME属性访问获取Device在物理层和链路层的所有可选能力然后根据这些能力决定实际的链路配置。3.1 关键DME属性一览在Link Startup过程中实际起决定性作用的属性不多我列了一个表格方便对照属性名访问方向含义典型值LocalDeviceID本地写本端设备ID由Host分配给自身0x01PeerDeviceID远端读对端设备ID用于确认对端身份0x02PA_TxGear本地读写本端发送Gear档位G1-G4PA_RxGear本地读写本端接收Gear档位G1-G4PA_HighSpeed本地读写是否启用高速模式0/1PA_TxLanes本地读写发送方向线数1或2PA_RxLanes本地读写接收方向线数1或2PeerTxLanes远端读对端发送线数能力1或2PeerRxLanes远端读对端接收线数能力1或2PA_ActiveTxDataLanes本地读当前激活的发送线数1或2PA_ActiveRxDataLanes本地读当前激活的接收线数1或2这张表值得存下来调试UFS时你会频繁和这些属性打交道。3.2 能力协商的判定逻辑有了上面的属性Host完成能力协商时会执行一套类似下面的逻辑读取PeerTxLanes和PeerRxLanes得到Device端支持的收发线数。比如Device报告PeerRxLanes2说明Device的RX方向支持2线接收。Host结合自己的PHY能力决定最终使用的线数。如果Host只支持1线即使Device支持2线最终也只能跑1线。读取Device支持的Gear档位。通过PA_TxGear和PA_RxGear的读写或者通过DME_GET读取对端的Gear能力确定双方共同支持的最高Gear。综合线数和Gear确定最终的吞吐能力。比如2线HS-G3的吞吐大约是1线HS-G3的两倍。这套逻辑看起来简单但实际代码里容易出问题的点是Host和Device对“能力”的定义不对齐。有的设备固件实现时把PA_TxGear和PA_RxGear的定义搞反了导致Host读取到错误的能力值协商出错误的速率最终表现为链路不稳定或者无法进入高速。3.3 协商结果如何影响后续工作能力协商的最终结果会写入UFS驱动里的uic_link_state和max_gear等变量这些变量直接决定了后续命令传输能跑多快。内核里/sys/devices/platform/soc/.../ufshcd对应的sysfs节点可以读到类似这样的信息$ cat /sys/devices/platform/soc/15570000.ufs/ufshcd/gear HS-G3 $ cat /sys/devices/platform/soc/15570000.ufs/ufshcd/lanes 2这里显示的HS-G3和2就是能力协商的最终结果。如果你发现实际跑起来的速率远低于预期优先检查的就是这个节点。另外一个容易被忽视的点能力协商结果不是一成不变的。UFS支持运行时的链路重启和重新协商当遇到温度过高、电压不稳等情况Host可以主动降低Gear档位来保证链路稳定。这属于链路调优的内容但在调试时如果发现速率“忽高忽低”首先要联想到是不是触发了降档机制。4. 实战排查Link Startup失败的根因定位与案例复盘前面把原理讲了不少现在聊点实在的——实际调试中怎么定位问题。以下内容全部来自真实项目经验你可以直接拿来当排查手册用。4.1 案例一Link Startup超时日志停留在pwr seq现象设备在冷启动时内核日志反复打印ufshcd_link_startup: Failed to bring up link代码trace停在pwr seq相关逻辑上。排查过程第一步先确认UFS的供电和时钟。用示波器抓VCC、VCCQ的波形确认上电时序是否满足规格要求。UFS对上电顺序比较敏感如果VCC先于VCCQ到达指定电压设备侧的状态机可能会异常。第二步检查复位信号。UFS的复位电平要求有明确的建立时间复位释放过早或者过晚都会导致Link Startup无法启动。我们用逻辑分析仪对比了Host释放复位到Device发出唤醒序列的时间间隔发现Device的唤醒序列始终没有出现。第三步排查PHY配置。对比了正常批次和异常批次设备的M-PHY寄存器配置发现异常设备的PWM_G1时钟频率配置偏差超过了5%。M-PHY协议对PWM-G1的时钟容差要求是±5%超出这个范围后Device侧面无法正确采样唤醒信号。根因某个批次的晶振精度不达标导致PWM-G1频率超标Device收不到有效唤醒。解决替换晶振并在驱动里增加对PWM-G1频率的校准逻辑在PHY配置时检查频率偏差超出阈值时报错提醒。4.2 案例二能力交换正常但HS-G3切换后链路丢失现象Link Startup成功低速模式下能够正常读写DME属性但切到HS-G3后Host与Device失联日志中没有任何报错只是超时。排查过程拿到这个问题我先怀疑信号完整性。用示波器在Device端测HS-G3的PCIe-like差分信号发现眼图质量很差信号的上升沿有严重过冲。进一步检查PCB走线发现这条UFS走线在中间换层处有一段较长的stub形成了阻抗不连续点。M-PHY的HS模式工作在Gbps级别对走线阻抗的要求非常苛刻。任何阻抗突变都会反射信号导致眼图塌陷。低速PWM模式对信号质量不敏感所以低速时一切正常一切到高速问题立刻暴露。根因PCB走线stub导致阻抗不连续高速信号反射严重。解决修改PCB设计去掉stub同时在PHY端调整均衡器设置补偿部分信号损耗。改版后HS-G3链路稳定运行两天未再掉链。从这个案例可以总结一条经验如果Link Startup低速正常但高速不工作优先怀疑物理层信号完整性而不是UniPro协议栈配置。4.3 排查工具与调试手段UFS调试不同于普通外设它的协议栈层次多光靠内核日志很难定位深层问题。我在实际工作中使用最多的工具按优先级排列如下内核动态调试开启UFS驱动的dynamic_debug可以打印出完整的DME属性访问记录和状态机切换过程这是最基础也是最先要做的。协议分析仪如果条件允许接上UFS协议分析仪能直接看到物理层的信号波形和UniPro帧交换过程是定位底层问题的终极工具。示波器/逻辑分析仪用来测量上电时序、唤醒信号时序以及初步评估信号质量。高通/联发科的专用调试工具各家SoC厂商都有自己的UFS调试工具比如高通的QFIL和QXDM能看到底层PHY寄存器状态。内核日志里几个典型的报错以及对应排查方向日志关键词对应阶段优先排查方向pwr seq timeout唤醒/低速训练供电、时钟、复位时序DME_GET failed属性访问UniPro状态机、Device固件HS gear switch timeout高速切换信号完整性、PHY配置Device not found枚举链路未建立回到第一阶段排查4.4 我踩过的坑总结最后总结几个自己踩过、也帮别人擦过屁股的坑都是常规文档里不容易看到的经验坑一复位信号的毛刺。有的PMIC在供电瞬间会产生毛刺信号如果这个毛刺恰好落在UFS复位引脚上设备可能进入一种半复位状态——既没有完全复位也没法正常唤醒。处理办法是在驱动里增加复位引脚的延时释放逻辑等待电源稳定后再释放复位。坑二DME属性缓存导致的问题。某些UFS Device固件在软复位后会保留上次的DME属性值如果Host没有主动清除缓存下一次Link Startup时读到的是上次的残留值导致协商出错误的速率。排查时如果发现“第一次启动正常第二次启动异常”优先考虑这个原因。坑三多设备共用参考时钟的干扰。UFS参考时钟如果和WiFi/BT芯片共用一颗晶振高速信号切换时容易产生串扰导致Link Startup间歇性失败。这个问题在原型验证阶段最容易遇到量产后反而少见。坑四不要迷信“高速一定好”。我遇到过一个项目为了追求标称性能把UFS硬生生配到HS-G4结果因为PCB走线质量有限链路在高温下频繁掉链。后来把Gear降到HS-G3实际性能几乎没有下降但稳定性大幅提升。性能指标固然重要但稳定压倒一切。5. 如何验证Link Startup的最终效果调试完成后总要有一些量化的指标来确认Link Startup和后续链路状态是健康的。这里分享几个我在项目中常用的验证手段。5.1 通过内核sysfs节点检查链路状态UFS驱动在/sys/devices/platform/.../ufshcd/目录下暴露了不少有用的节点。除了前面提到的gear和lanes以下几个也值得关注# 查看当前链路状态是否为ACTIVE $ cat /sys/devices/platform/soc/15570000.ufs/ufshcd/link_state ACTIVE # 查看设备支持的Gear列表 $ cat /sys/devices/platform/soc/15570000.ufs/ufshcd/supported_gear HS-G1 HS-G2 HS-G3 HS-G4 # 查看是否有链路错误计数 $ cat /sys/devices/platform/soc/15570000.ufs/ufshcd/err_stats pa_err: 0 dl_err: 0 dme_err: 0其中err_stats是最直观的健康指标。如果pa_err或dl_err持续非零说明链路上存在不稳定因素要么是信号质量下降要么是协议层流控异常。5.2 压力测试与长稳验证链路稳定性的最终检验是压力和长稳测试。我通常会在做完Link Startup优化后跑以下几类测试长时间连续读写用fio做4K随机读写和1M顺序读写混合测试跑24小时以上观察是否有命令超时。UFS对命令超时很敏感一次严重的链路抖动就可能导致上层文件系统报错。温度循环测试在-20°C到70°C范围内循环变化温度同时持续读写。高速模式下信号质量对温度变化尤为敏感高温下PLL可能失锁低温下晶振频率偏移可能导致功耗和时序问题。热插拔/休眠唤醒测试反复执行系统suspend/resumeUFS在休眠时会进入低功耗模式唤醒时可能触发链路重启流程。每轮suspend/resume都应该观察到Link Startup被正确执行且不会因为竞态条件卡死。测试过程中如果出现命令超时重点看超时时Host的链路状态机在哪一步再结合dmesg里的ufshcd日志和sata_link相关的错误计数来定位。5.3 性能数据确认链路参数协商好之后性能数据是最直接的验证。用fio或者其他存储测试工具实测的顺序读速度应该能接近UFS的理论峰值。比如2线HS-G3的理论带宽大约在11.6Gbps转换到实际吞吐大概在1.1GB/s到1.2GB/s左右顺序读跑到900MB/s以上说明链路配置基本合理。如果实测性能明显低于预期回到能力协商那一步——确认协商出来的Gear和Lanes是不是目标值。很多“性能不达标”的问题最后查出来都是能力协商时某个属性没配到位实际只跑在了HS-G1而不是HS-G3。6. 一些额外想说的话UFS Link Startup这块内容真正调过的人会觉得很清晰没调过的人看代码会觉得一头雾水。这几年新加入嵌入式存储领域的工程师越来越多大家普遍反映UFS调试门槛比eMMC高不少我觉得主要原因不是协议有多复杂而是坑都藏在不显眼的地方——一处上电时序、一个DME属性值、一段PCB走线都可能导致整个链路起不来或者不稳定。如果只能记住一句话我会说不要轻视低速阶段。很多问题表面上看是高速模式下的链路丢失实际在低速阶段的时序、频率容差上就已经埋下了隐患。把link startup的前两步做扎实了后面高速模式反而很少出问题。写这篇东西的时候我把之前项目里的调试记录翻了一遍挑了几个有代表性的案例重新整理了出来希望能帮你少走一些弯路。以后如果遇到其他UFS相关的疑难问题也欢迎一起交流讨论存储这块儿的坑我一个人踩不完大家一起踩才能踩得更有价值。