这么多年搞嵌入式显示最怕的就是“概率性”三个字。RK3568 这颗片子本身不算难调但一旦碰上 eDP 屏开机偶尔不亮、重启又好了、换一块屏又复现的问题那真是能把人耗到怀疑人生。今天就把我这次处理 RK3568 eDP 概率性不显示的完整排查过程、踩坑记录和最终定位的思路分享出来。这个案例来自一块自研的 RK3568 核心板加定制载板搭配 1920x1080 的 eDP 屏故障率大概在 3% 到 5% 之间不算高但产线只要碰到一台就够你忙活半天。这类问题最麻烦的地方在于它没有固定规律同一批板子有的冷启动不亮有的按复位键能亮有的在 Linux 内核启动阶段概率性训练失败而 U-Boot 里又一切正常。要定位这种偶发问题光靠看代码是不够的必须结合硬件时序、启动日志、寄存器状态一起分析。下面我按自己的排查顺序把整个过程逐步拆开讲。1. 问题现象与复现路径1.1 故障现场哪些“不显示”才是真的异常先说现象。这块板子使用的是 RK3568 的 eDP 控制器外接一颗带 eDP 接口的 15.6 寸屏分辨率 1920x1080内部信号源来自 Rockchip 的 Video Port 2。故障表现为三种形态整机冷启动时背光亮但屏幕无画面一直保持黑屏。系统启动过程中dmesg 日志里能看到 eDP 链路训练失败的报错但 U-Boot 阶段显示正常。少数板子按复位键重启后恢复正常但下一次冷启动可能再次不显示。这三种情况其实对应了不同的故障阶段。背光亮说明背光供电和背光控制信号是正常的问题出在 eDP 主链路的数据传输上U-Boot 正常但内核失败说明硬件本身大概率没问题而是软件初始化时序和链路训练参数在两个阶段不一致复位后恢复又说明现象和电容充放电、电源时序这种瞬态过程强相关。如果你也遇到类似情况第一步不是改代码而是先把“不显示”的具体表现记录清楚。屏幕有没有背光、U-Boot logo 能不能出来、内核启动到哪一步黑屏、HDMI 是否正常这几个信息能帮你快速缩小排查范围。我见过不少人在这一步直接把问题归咎于屏参配置结果改了几天发现根本不是那回事。1.2 复现条件和概率分布为了把“概率性”变成“可复现”我做了几轮统计实验。用同一批 20 台样机反复冷启动 50 次统计不显示次数再单独测试热重启、待机唤醒、断电间隔不同时间后的冷启动。结果有点意思测试条件不显示概率备注断电后立即重启偏低约 1%断电后静置 30 秒以上较高约 5%系统内热重启几乎为零U-Boot 已初始化过连接器重新插拔后冷启动最高约 8%断电静置越久、连接器重新插拔过之后概率越高。这说明问题极可能和 eDP 连接器接触电阻、面板电源电容的泄放状态有关。加上 eDP 是高速差分信号任何一端接触不良或者参考地平面不连续都会在链路训练时表现为偶发失败。这个阶段我的结论是硬件接触与电源时序是首要怀疑对象软件配置是次要怀疑对象。带着这个方向我开始深入 RK3568 的 eDP 初始化流程。2. eDP 从复位到点亮RK3568 内部发生了什么2.1 RK3568 eDP 控制器的基本架构RK3568 的 eDP 控制器在芯片内部叫 MIPI DSI/eDP 组合控制器实际上是一套可以切换协议的显示接口模块。它和 VP2 绑定最大支持 2560x160060Hz内部集成了 PHY支持 1/2/4 lane最高速率 5.4Gbps。对于 1080p 屏幕来说通常使用 2 lane 就够了带宽余量充足。从软件角度看eDP 的初始化链路是这样的U-Boot 或内核里的 DisplayManager 先配置 VP2 的时序参数然后通过 MIPI/DP PHY 驱动做 PHY 初始化再通过 eDP 控制器发送 AUX 命令去读屏幕的 EDID最后进行链路训练确认 lane 数和速率后开始传输图像数据。这里有个关键概念链路训练。eDP 是像 PCIe 那样的高速串行协议发送端和接收端要先“握手”通过 AUX 通道协商电压摆幅、预加重、lane 数和速率。屏幕作为接收端如果训练参数不合适比如电压太低或者时钟恢复环路不稳定它就会拒绝锁定表现为黑屏。这就能解释为什么“概率性”故障往往和链路训练强相关。2.2 一条完整的启动时间线我把一次从按下电源键到屏幕点亮的过程拆成了时间线PMIC 按时序输出各路电源包括 VCC3V3、VCC1V8、VCC0V9 等。RK3568 复位释放U-Boot 开始执行初始化 DDR、时钟、存储。U-Boot 初始化显示部分配置 VP2 时序、启动 PHY、读取 EDID。U-Boot 通过 AUX 做链路训练成功后显示 U-Boot logo。内核接管设备树eDP 驱动 probe重新初始化 VP、PHY、DP 控制器。内核再次做链路训练成功后投图。用户态显示服务接管 framebuffer显示桌面。这里至少要经历两次完全独立的链路训练一次在 U-Boot一次在内核。如果两次训练的参数不一致比如 U-Boot 用 2 lane 训练成功内核却因为时序原因在 PHY 还没稳定时就开始训练就会失败。另一个很多人忽略的点是内核 eDP 驱动 probe 之前屏幕的供电可能已经被 U-Boot 切断过。如果你的载板上 eDP 面板电源不是常供电而是通过 GPIO 控制的那 U-Boot 和内核之间可能有一段“电源空白期”。在这段期间屏幕内部的电容会放电EDID 和训练参数可能会丢失。等到内核再给屏供电时如果上电时序不够严谨屏幕就可能处于一个半初始化状态。2.3 U-Boot 和内核各管一段最容易出不一致RK3568 的显示初始化在 U-Boot 和内核里是两套独立代码。U-Boot 里用的是 Rockchip 自己的显示框架内核里用的是 DRM 框架。两者共用一个设备树但解析方式和初始化顺序并不完全一致。最常见的坑有三个U-Boot 里设置了edp_phy_power相关的时序但内核设备树里的power-supply属性没配对导致内核把面板电源当成未知设备重新初始化。U-Boot 通过panel-timing节点拿参数内核却需要display-timings节点里的另一套字段两边计算的像素时钟或 blanking 时间不一致。内核的 PHY 驱动在 probe 时会对寄存器做复位操作如果此时 PHY 电源不稳复位后的默认状态就不是预期的训练直接失败。这台板子最后定位出来的问题恰恰就落在第二个坑上但表现更隐蔽。细节留到第 4 节说这里想强调的是排查 eDP 概率性不显示一定要先确认 U-Boot 和内核两套时序参数完全一致否则你会在源代码里找到一个永远修不好的“软件 Bug”。3. 常规手段排了个遍问题到底在哪一环3.1 日志先说话内核打印了什么我习惯做法是先抓日志。把内核drm、rockchip-dp、edp相关模块的打印等级调高然后把 dmesg 完整保存下来。对比正常板和不显示板差异很快就出来了。正常板的关键日志是这样[ 3.843204] rockchip-dp cd3f0000.edp: AUX HPD status: 0x0 - 0x1 [ 3.849372] rockchip-dp cd3f0000.edp: Model: LTM156HL02 [ 3.854510] rockchip-dp cd3f0000.edp: HDR support: 0 [ 3.859332] rockchip-dp cd3f0000.edp: Link Training succeeded! [ 3.865471] rockchip-dp cd3f0000.edp: Link rate: 0x0a, lane count: 2故障板的关键日志则是这样[ 3.842905] rockchip-dp cd3f0000.edp: AUX HPD status: 0x0 [ 3.948821] rockchip-dp cd3f0000.edp: Failed to get HPD status [ 3.955943] rockchip-dp cd3f0000.edp: Unable to read EDID看到这个日志第一个反应是 HPD 信号有问题。HPD 是 Hot Plug Detect屏幕通过这个引脚告诉 SoC“我准备好了”。如果内核 probe 时 HPD 还是低电平驱动会认为没有接屏直接放弃后续的 EDID 读取和链路训练。但有意思的是U-Boot 阶段这个屏是正常点亮的说明 HPD 硬件链路没问题。那为什么内核阶段 HPD 会变成 0只有两种可能一是 HPD 引脚被复用了二是屏幕在内核 probe 时还没完成内部上电HPD 根本没拉起来。3.2 搬出示波器量 HPD 和电源的时序软件日志能告诉你“哪一步失败了”但不会告诉你“为什么失败”。这时候必须上示波器看时序。我同时抓了四路信号面板电源 VCC 3V3、HPD、AUX 差分对、背光使能。触发条件设在 VCC 3V3 上升沿观察从面板供电到 HPD 拉高之间的时间差。量完发现正常板从 VCC 3V3 上升到 HPD 拉高大约需要 180ms故障板有时候 300ms 都等不来 HPD。也就是说屏幕内部的上电速度比 SoC 驱动预期慢HPD 来得太晚。翻内核代码发现rockchip-dp.c里 HPD 检测逻辑会先等待一段时间但那个等待是基于panel_delay的。如果设备树里没给 panel 配置足够的上电延时驱动在 PHY 初始化后立刻去读 HPD自然就会读到低电平。而 U-Boot 那边因为没有同样的时序约束反而等得起所以 U-Boot 永远正常。3.3 排除法屏参、线材、连接器都查了一遍既然怀疑是接触和时序问题我把能换的都换了。原装屏蔽线材换了两根结果不显示概率没变化把连接器重新焊接一遍概率略有下降但从 5% 降到 3%并没有根治换另一家品牌的 eDP 屏故障率直接从 5% 变成 0.5%这让我意识到屏内部的上电逻辑差异非常关键。这个过程最大的心得是eDP 屏不是一个“即插即用”的被动设备。每款屏的内部时序、EDID 持有时间、HPD 上拉能力都不一样。RK3568 的驱动提供了panel-timing和panel_delay这些可调参数但你得针对具体屏型号去测不能直接抄参考板的配置。我还专门测试了屏厂提供的“最小 HPD 时间”参数。A 屏标称 200ms实际稳定时有余量B 屏标称 150ms但低温环境下能拖到 280ms。这里就埋了个雷如果你的产品要过低温测试时序余量不够概率性不显示就会更严重。4. 真正的问题一个掩藏在设备树里的电源时序漏洞4.1 三路电源谁先谁后决定了成败绕了一大圈最后定位到的问题不在 HPD也不在链路训练参数而在设备树里 eDP 面板电源和 SoC 内部 eDP PHY 电源的上电顺序。RK3568 的 eDP PHY 需要一路 0.9V 的数字电源面板需要一路 3.3V 的电源。规范要求面板电源应该在 PHY 准备之前稳定下来并且 HPD 要等面板电源稳定后才拉高。但实际硬件设计中PHY 的 0.9V 是 PMIC 直接输出的面板的 3.3V 却是 GPIO 控制一个负载开关给出的。问题出在 GPIO 控制时序上。设备树里我写的 panel 节点是这样的edp_panel { enable-gpios gpio4 12 GPIO_ACTIVE_HIGH; power-supply vcc3v3_lcd; panel_delay 100; ... };看起来没问题但内核的 DRM panel 驱动在 probe 时会做一件事先把 GPIO 拉到无效电平再拉到有效电平用于重置屏幕状态。这个动作发生在驱动 probe 的阶段而此时 PHY 的 0.9V 已经起来了。日志里看到的现象就是U-Boot 点亮屏幕内核接管后先把面板电源 GPIO 拉低再拉高中间给了个 100ms 的 delay理论上够。但实际量出来这个拉低再拉高导致面板电源出现了一个约 80ms 的缺口。4.2 为什么一个“80ms 缺口”就能让概率性不显示生效如果你看过 eDP 屏内部框图就知道了。面板里有一颗控制芯片它负责管理 T-CON、EDID、HPD 这些逻辑。外部电源一旦掉电哪怕只有几十毫秒这颗芯片的内部状态机就会复位。复位之后它需要重新完成内部初始化然后才能拉高 HPD、响应 AUX 命令。而内核的panel_simple驱动在prepare()阶段里按设备树的panel_delay等了 100ms。这个 100ms 是给“电源从 0 到稳定”的时间不是给“电源断开再重新上电后屏幕内部控制芯片重启”的时间。屏幕内部芯片重启耗时多少完全取决于屏厂的设计有的快有的慢快的 200ms 完成慢的 500ms 还在重启。一旦超过了驱动等待时间HPD 就晚到链路训练就失败。说白了这个问题的本质是内核驱动中少做了一次“电源已经断开”的判断。它不知道自己面对的是一块已经初始化过的面板更不知道 GPIO 拉低之后面板电源已经掉电屏幕状态已经丢失。它以为屏还在原来的状态所以只给了很少的重启时间。4.3 定位过程复盘如何从日志走到这个结论复盘的逻辑链是这样的第一步发现故障板的 HPD 状态为 0。第二步示波器确认 HPD 确实晚到时间随机。第三步对比正常板和故障板的 GPIO 波形发现 GPIO 在 U-Boot 阶段保持高电平但内核 probe 时有一个明显的“拉低-拉高”脉冲。第四步单独写一个小测试驱动让内核一开始不操作 GPIO直接保留 U-Boot 的输出状态故障率降到 0%。第五步确认是内核重复初始化 GPIO 导致面板电源出现电源毛刺。到这里问题根因就非常清晰了不是硬件设计错误不是 RK3568 本身的问题而是设备树和内核驱动没有配合好对面板电源做了重复上下电。这种问题在量产前的小批量测试中很难发现因为大多数时候 100ms delay 足够用只有碰上内部重启比较慢的屏才会触发。5. 修复方案软件优先硬件加固兜底5.1 设备树修补让内核不再重置面板电源最简单的软件修复是在enable-gpios上加GPIO_ACTIVE_HIGH的同时给 panel 节点增加一个prepare-delay属性并确保驱动在 probe 时不主动把 GPIO 拉低。比如这样edp_panel { enable-gpios gpio4 12 GPIO_ACTIVE_HIGH; power-supply vcc3v3_lcd; prepare-delay 250; enable-delay 250; disable-delay 20; panel_delay 250; status okay; };但只改这一个还不行。问题在于内核的panel_simple_probe里GPIO 被请求后会用gpiod_set_value_cansleep(panel-enable_gpio, 0)强制拉低一次用于“确保初始状态”。这个动作对一块由 U-Boot 点亮的屏来说是致命的。要完全绕开它有两个方案在 U-Boot 启动内核前不把 GPIO 的控制权交给内核而是在 U-Boot 的 DTS 中把该 GPIO 设为disabled或直接不给内核留enable-gpios属性仅保留power-supply。修改内核驱动在 probe 时判断 U-Boot 是否已经初始化过该 panel。判断方法可以是通过regmap读 eDP 控制器的某个状态位或者直接看内核启动中是否出现过 logo。方案一最简单但我个人不建议长期用一旦脱离 U-Boot 直接冷启内核调试屏幕又会出现同样的问题。方案二更符合工程习惯。我给内核打了个小补丁思路是请求 GPIO 时先读当前电平如果已经是高电平就不再拉低直接进入高电平状态。/* panel-simple.c custom hack */ if (panel-enable_gpio) { int val gpiod_get_value(panel-enable_gpio); if (val 0) { /* already enabled, skip disable pulse */ panel-enabled true; gpiod_direction_output(panel-enable_gpio, 1); } }实际测试下来这个 patch 让 20 台样机冷启动 200 次一次失败都没有。产线连续跑了三天故障率降到 0。5.2 硬件排查与加固HPD 上拉和电源滤波软件修复能解决绝大部分问题但硬件侧的余量也得留好。eDP 的信号完整性本来就容易受连接器影响HPD 作为低速信号反而更值得注意。我检查了载板原理图发现 HPD 引脚没有外加上拉电阻。虽然 SoC 内部有弱上拉但弱上拉能力有限加上排线走线长干扰环境下 HPD 上升沿会变缓。RK3568 的 eDP 控制器在检测 HPD 时有一个电压阈值如果上升太慢可能造成阈值穿越期间电平不确定驱动要么读 0 要么读 1概率性就来了。后续在 HPD 到地之间加了 1k 欧姆上拉到 3.3V再串一个 0 欧姆电阻方便调试。这个改动不算大但对低温和电缆插拔场景有实质帮助。另外面板供电引脚旁边原本只有一个 10uF 电容我在连接器座子附近额外补了一颗 100nF 和一颗 47uF 的电解电容用来缓解 GPIO 拉低瞬间带来的电压跌落。虽然软件修复后 GPIO 不会再拉低但多一层冗余总是好的。5.3 量产验证什么样的测试才叫“真测过”修完之后我做了一轮量产级验证测试矩阵是这么设计的40 台整机冷启动/热启动各 100 次。断电静置时间分别设为 5 秒、30 秒、5 分钟、1 小时。环境温度覆盖常温、40 度高温、-10 度低温。插拔 eDP 排线各 20 次模拟运输震动后的连接器状态。测试结果全部通过。这个矩阵看着简单但强调一点低温测试一定要做。很多概率性时序问题在常温下完全隐形一到低温就放大。我之前在另一块板子上遇到的 eDP 黑屏就是低温下 HPD 电平不够稳加个上拉就好了。如果你们项目还在研发阶段我建议在试产前做一次全温区的 eDP 启动压力测试别等量产了再发现。这类问题一旦到了客户手里很难用软件手段热修复因为它有时候只是偶发一次用户不会给你完整的复现步骤。6. 排查 RK3568 eDP 问题值得记住的几条经验先说结论这次 eDP 概率性不显示的根因是内核驱动在 probe 时对面板电源 GPIO 做了重复初始化导致面板电源产生了一次短暂跌落屏内部控制芯片重启延后HPD 晚到链路训练失败。再往深看一步这类概率性显示问题通常逃不出三个维度电源时序裕量不足、HPD 信号完整性差、U-Boot 与内核初始化流程不一致。三者之间不是孤立关系往往互相叠加最麻烦的就是“单看哪一项都正常”。我个人在这次排查中用到的工具组合是dmesg 日志 示波器四通道同步抓时序 设备树参数二分法。其中二分法最推荐先把 U-Boot 里的 logo 显示关掉让内核从零初始化 eDP验证纯内核路径。再把 U-Boot 显示打开但保留内核初始化对比两次行为差异。最后用一个小测试内核模块模拟不同 GPIO 时序组合锁定最终触发点。这个方法不挑平台换到全志、NXP 或者高通平台都能复用。做嵌入式显示调试尤其是 RK3568 这种带独立 PHY 的 SoC最忌讳一上来就怀疑屏参和连接器。它们可能是背锅的但大概率不是根源。先把软件初始化路径理清楚再动硬件效率会高很多。最后分享一个没那么好听但很真实的经验如果一块板子在量产前就暴露出概率性显示问题别嫌它麻烦这其实是给你省钱。把每一次黑屏都当成一次完整的时序课把硬件和软件两边都吃透了后面不管你换 DSI 屏还是换更高分辨率的 eDP 屏都能少踩很多坑。