调屏这件事很多从其它 SoC 平台转过来的工程师第一反应就是去 U-Boot 源码里翻 DTS找 panel 节点、找 backlight 节点、找 reset 引脚。但真正在 RK 平台上做过几个项目之后你会发现一个反直觉的现象内核 DTS 里的屏参改了、背光节点改了U-Boot 的 DTS 往往根本不用碰重新编译内核后屏幕照样点亮有些场景下连 U-Boot 都不用重新编译boot logo 也正常出现。这个现象不是运气而是 RK 的显示链路设计和设备树组织方式决定的搞懂了它你调屏的效率会高很多。这篇文章就围绕这个现象展开。我会先讲清楚 RK 从 VOP 到屏幕的链路再说为什么 U-Boot 通常不需要单独维护一份显示 DTS然后以 MIPI DSI 屏为例把完整调屏流程过一遍最后聊聊哪些情况下你必须回头动 U-Boot以及常见的黑屏、花屏问题怎么查。无论你是刚入行调屏的嵌入式工程师还是被一块屏折腾过好几天的老手这篇内容都值得存一下。1. 先掰开 RK 显示链路图像从 VOP 到屏幕到底经过什么1.1 接口类型差异MIPI DSI、eDP、LVDS、RGB 在 DTS 里长啥样RK 的显示控制器叫 VOPVideo Output Processor你可以把它理解成一块“画布”所有要显示的画面最终都在这里合成然后通过片上集成的各种显示接口把数据送出去。调屏的第一步就是搞清楚你的屏幕是通过哪种接口接进来的因为这决定了你在 DTS 里要找哪些节点。常见的 RK 显示接口有这么几类。接口典型场景DTS 里常见节点U-Boot 是否参与MIPI DSI平板、车载、小尺寸消费屏dsi、mipi_dsi、route_dsi可选eDP笔记本、中大尺寸屏edp、route_edp可选LVDS工控、车载大屏lvds、route_lvds可选RGB/CPU低成本小屏、并口屏lcdc、route_rgb一般只看背光不管哪种接口屏幕本身的描述——分辨率、时序、供电、复位时序、初始化命令——都在 panel 节点里接口控制器的参数比如 DSI 的 lane 数、eDP 的 lane 数、时钟频率则在外设控制器节点里。也就是说调屏时你改的其实是一堆互相引用的节点而不是单纯改某一个值。这里有个很多新手容易混淆的点U-Boot 和 Linux 内核是两套完全不同的驱动代码但它们读取的设备树来源却可以是同一份。RK 平台的 U-Boot 并不是像某些老平台那样在 C 代码里写死一组屏幕参数而是同样走设备树解析的路子。这就为“不用单独改 U-Boot DTS”埋下了伏笔。1.2 route 节点谁在决定“哪条路送画面”RK 设备树里有一类特殊节点叫 route 节点比如 route_dsi、route_edp、route_lvds。它干的事情是把某个 VOP 和某个显示输出接口绑定起来决定“画布上的画面到底从哪条物理链路送出去”。看一个典型片段route_dsi { status okay; connect vopb; };意思很直白DSI 这条显示通路要启用并且画面由 vopb 这个显示控制器送出。RK 一般有 VOPB 和 VOPL能力不同VOPB 通常更强一些支持更高分辨率VOPL 是低功耗用途。connect 里面绑的如果不是实际接线的那个 VOP那就会黑屏。这个节点在排查问题时非常关键。如果你把 route_dsi 的状态改成 disabled哪怕 DSI 控制器节点本身是 okay系统也不会往这块屏上送画面。U-Boot 和内核的显示驱动都会读取 route 节点所以当你发现“接口也对了、panel 也对了、背光也亮了但就是没画面”的时候第一件事就该检查 route 节点的状态而不是一头扎进时序参数里。不同 SDK 对 route 节点的命名有一点差异有的叫 route_mipi有的叫 route_dsi老平台可能还有 route_lvds。遇到不清楚的直接在 SDK 自带的 dts 文件里搜 route 就能找到本平台的命名规范。调屏前把这条链路自己在 dts 里追一遍能省下大量在群里问“为什么黑屏”的时间。2. U-Boot 的显示体系和内核不在一个频道但吃的是同一锅饭2.1 U-Boot 显示 logo 的典型流程U-Boot 为什么要管显示主要就一个目的开机时显示 logo或者在 Android 方案的 recovery 模式、fastboot 模式下给用户一个交互画面。它的显示初始化流程和内核 DRM 驱动的流程很像但简化得多。大致是这样的U-Boot 启动后如果 defconfig 里打开了显示驱动相关驱动会去解析 DTS 里的 VOP 节点、route 节点、panel 节点和 backlight 节点然后初始化 VOP 的时钟和控制器再根据 panel 节点里的时序参数配置对应的显示接口比如 DSI 的 lane 数、时钟频率接着初始化 GPIO 完成屏幕复位上电打开背光最后往 framebuffer 里写入 logo 内容。注意一个细节U-Boot 的显示驱动功能上比内核精简很多尤其对 MIPI DSI 屏幕有些屏需要一长串厂商初始化命令U-Boot 的驱动可能只执行了其中一部分甚至有些 SDK 版本根本不执行而是依赖屏硬件上电后的默认状态。这就导致同样一块屏在内核里正常在 U-Boot 里却花屏或者不亮。遇到这种现象不要急着改 U-Boot DTS先确认 U-Boot 驱动到底有没有执行你屏需要的初始化序列。2.2 同一个 DTS 怎么同时服务两套驱动回到核心问题为什么调屏时不用改 U-Boot DTS真正的技术关键在于RK SDK 里 U-Boot 的板级 DTS 文件通常会 include 内核的板级 DTS 文件。举个例子SDK 的 u-boot/arch/arm/dts/ 目录下有一份 rk3568-evb.dts文件内容往往不是从零开始写的而是像这样#include rk3568-evb.dts把它自己需要的一些 U-Boot 专属属性追加进去比如 chosen 节点、u-boot,boot0 标识、bootph-all 属性等。这意味着你在内核 dts 里写的 panel 节点、backlight 节点、route 节点U-Boot 在编译时也能看到。两套驱动吃的是同一棵设备树只是站在不同角度去解析而已。所以更准确的说法是不是“不用改 U-Boot DTS”而是“U-Boot DTS 不需要单独维护一份屏参”。你在内核 DTS 里改的屏参本质上已经是 U-Boot 能看到的参数了。调屏时你真正要做的是修改共享的那份 DTS然后重新编译 U-Boot让新的设备树打包进 uboot.img。要是你的调试流程是单独加载内核 dtb、不走 U-Boot 显示那连重编 U-Boot 这一步都可以省掉。这就是网上很多教程说“不用改 U-Boot”的真相。2.3 defconfig 才是 U-Boot 显示的“总开关”很多时候你觉得自己“没改 U-Boot 就亮了”其实是因为 SDK 默认的 U-Boot defconfig 里已经打开了显示驱动。U-Boot 的显示能力不是靠 DTS 决定是否编译的而是靠 Kconfig 配置。在 U-Boot 的 defconfig 里通常会有类似这样的配置项CONFIG_ROCKCHIP_DRM_DISPLAYy CONFIG_ROCKCHIP_DRM_DSIy CONFIG_ROCKCHIP_DRM_EDPy CONFIG_ROCKCHIP_BACKLIGHTy不同 SDK 版本的宏名会有些区别但思路一致。这些配置决定了 U-Boot 会不会把显示相关驱动编译进固件。如果某个平台把显示驱动整体裁剪掉了那你把 DTS 改成花也没用U-Boot 根本不会去解析显示节点。反过来如果这些宏默认是打开的那么 U-Boot 只要能在 DTS 里找到合法节点就会尝试初始化。这里就出现了一个调屏时很常见的误区有人改了 DTS 里所有显示参数U-Boot 仍然不出 logo于是怀疑是 DTS 哪里写错了折腾半天。其实问题可能在 defconfig 的开关上或者在 U-Boot 的板级文件有没有正确 include 那颗内核 DTS。遇到 U-Boot 显示问题先查“开关”再查“参数”不要一上来就改屏参。2.4 内核接管后U-Boot 的显示工作就结束了还有一个容易让人困惑的点U-Boot 已经把屏点亮了为什么内核起来后又要重新初始化一遍因为 U-Boot 和内核是两套独立的驱动U-Boot 初始化完的寄存器状态在跳转到内核后并不会被完整继承。内核的 DRM 驱动会重新 probe 硬件重新配置 VOP、重新发 DSI 初始化序列、重新调背光。所以 U-Boot 阶段的点亮本质上只是“早班员工先开了灯”内核起来后会再开一次。只要两边读的 DTS 参数一致这个过程用户无感如果两边参数不一致就会出现 logo 正常但内核起来黑屏或者 logo 花屏但内核显示正常这类奇葩现象。RK 为了让这个交接更顺滑在 U-Boot 和内核之间还留了一些 framebuffer 交接机制本质上也是靠 DTS 里的 reserved-memory 配置来对齐地址。但不管机制多复杂源头都是同一份设备树。所以调屏时把内核 DTS 作为“唯一权威版本”让 U-Boot 跟着走是最不容易出错的姿势。3. 调屏实操以 MIPI DSI 屏为例主要工作量其实在内核 DTS3.1 开工前必须从屏厂拿到的参数清单调屏不是拿到一块屏就开写 DTS没参数就是盲人摸象。我一般开工前会找屏厂要一份屏规格书并且重点核对下面这些东西。分辨率hactive、vactive这个不用说。时序hback-porch、hfront-porch、hsync-len、vback-porch、vfront-porch、vsync-len以及 clock-frequency。DSI 配置几 lane数据格式是 RGB888 还是 RGB666DSI 时钟频率。供电屏需要的 VCC、IOVCC、VCI 这些电压值以及上电顺序。复位时序reset 脚是低有效还是高有效拉低多久然后再拉高等多久才能发起操作。初始化命令有些 MIPI 屏上电后需要主控通过 DSI 发一串初始化命令这些命令序列屏厂通常会提供十六进制数组。背光背光 PWM 频率、使能脚电平、默认亮度。特别强调一下复位时序。不同屏差距非常大有的只要 1ms有的要 10ms。曾经遇到一块屏reset 拉低时间不够导致屏偶尔白屏改长时序后问题消失。这种问题是 DTS 参数不好解决的往往要在驱动里加延时或者在上电时序里处理好。3.2 修改 Panel、背光、route 节点的步骤以 MIPI DSI 屏为例典型的内核 DTS 修改包含三个地方。首先是 DSI 控制器下的 panel 节点。dsi { status okay; panel0 { compatible panel-mipi-dsi; reg 0; backlight backlight; reset-gpios gpio3 RK_PB6 GPIO_ACTIVE_LOW; pinctrl-names default; pinctrl-0 lcd_panel_reset; dsi,lanes 4; dsi,format MIPI_DSI_FMT_RGB888; display-timings { timing0 { clock-frequency 140000000; hactive 1080; vactive 1920; hback-porch 40; hfront-porch 40; hsync-len 8; vback-porch 10; vfront-porch 28; vsync-len 4; }; }; }; };其次是背光节点。背光常见方案是 PWM 背光也有 GPIO 开关背光的。PWM 频率要注意一般屏厂会推荐 20k 到 200k 之间太低会有可闻噪声太高可能影响亮度调节线性度。下面是一个典型配置。backlight { status okay; pwms pwm1 0 20000 0; enable-gpios gpio1 RK_PA1 GPIO_ACTIVE_HIGH; pinctrl-names default; pinctrl-0 bl_en; brightness-levels 0 255; default-brightness-level 200; };最后是 route 节点决定 VOP 和 DSI 接口的绑定关系。route_dsi { status okay; connect vopb; };这里必须要注意compatible 字符串要以你 SDK 自带的面板驱动模板为准我示例里的 panel-mipi-dsi 并不一定适用于所有内核版本。另外如果屏需要发初始化命令序列不同 SDK 的写法差别很大有的放在 panel 节点的 init-sequence 里有的用 rockchip,cmd 这种自定义字段还有的直接在驱动里做 switch 分支。别光看网上教程抄去 SDK 里搜一个现成量产的屏幕节点照它的格式改最稳妥。3.3 U-Boot 侧真正要做的三件小事内核 DTS 改完后如果你希望 U-Boot 也能正常显示 logoU-Boot 侧真正要做的事情其实很少通常就三件。第一确认 U-Boot 的 defconfig 里对应显示接口的驱动宏已经打开。这个前面说过是总开关。第二确认 U-Boot 板级 DTS 包含了内核 DTS。如果你的项目是基于 SDK 默认板子改的一般已经 include 了如果是自己新做的板子要检查 u-boot/arch/arm/dts 下的文件是否引用了你正在改的那颗内核 dts 文件。这一步被很多人忽略结果内核侧怎么改都正常U-Boot 永远老样子。第三重新编译 U-Boot 并烧写 uboot.img。这里说的“重编 U-Boot”不是改代码而是让 U-Boot 拿到最新生成的 dtb。如果你是调试阶段通过 fastboot 单独加载内核 dtbU-Boot 自带 dtb 不参与显示流程那确实连这一步都不需要。这也是为什么很多帖子里说“调屏不用动 U-Boot”——人家是在单独的调试加载模式下说的量产烧一体的镜像时还是得把 U-Boot 同步编译一遍。3.4 如果你想让 U-Boot 阶段也能过 logo还要多做什么如果你想在 U-Boot 阶段就把 logo 打出来并且对显示效果有要求光靠 DTS 参数同步还不够。需要确认 U-Boot 的显示驱动执行了屏的初始化流程。有些 MIPI 屏的初始化序列很长U-Boot 的驱动可能没有执行全这种情况你就得去 U-Boot 的 panel 驱动里补充初始化命令或者调整驱动的执行逻辑。另外logo 的格式和位置也有讲究。RK U-Boot 的 logo 一般放在 resource.img 分区内核起来后如果 DTS 里配置了同样的 logo 资源可以做到从 U-Boot logo 平滑切换到内核 logo不闪黑屏。如果你发现 logo 显示后有短暂黑屏再亮多半是内核 drm 重新初始化的过程中清空了 framebuffer而新的 logo 资源没有及时加载。这时候别急着找 U-Boot 的麻烦先检查内核侧 logo 资源有没有配好。4. 什么情况必须动 U-Boot DTS四个典型场景4.1 开机 logo 本身就是产品需求有些产品要求一上电就要看到品牌 logo并且从按 power 键到出 logo 的时间被死死卡住比如必须 300ms 内。这时候 U-Boot 显示是必须工作的U-Boot DTS 里关于 VOP、DSI、panel、backlight 的配置就都必须正确。但这里要分清绝大多数情况下你需要的不是“改 U-Boot 专用屏参”而是“确保 U-Boot 能拿到内核 DTS 里已经改好的屏参”。如果你手头 SDK 的 U-Boot 板级 DTS 没有正确 include 内核 DTS那你确实需要改 U-Boot DTS 的 include 关系否则 U-Boot 看不到屏节点。4.2 有些屏必须由 U-Boot 完成上电复位某些对时序要求苛刻的屏幕如果 U-Boot 阶段不做 GPIO 上电和复位等内核启动到一半才拉屏电源和复位屏幕就会白屏或者花屏。典型的例子是带 MCU 的 DSI 屏主控和屏的握手必须在上电后的很短时间内完成晚了屏可能进入异常状态。这种屏通常要在 U-Boot 阶段就把电源、复位 GPIO 处理好甚至要在 U-Boot 的 board 初始化代码里加延时。DTS 层面能做的是把 panel 节点的 reset-gpios、enable-gpios、pinctrl 配齐让 U-Boot 驱动在初始化时执行。但如果 SDK 的 U-Boot 驱动本身不解析这些 GPIO那你就得改 U-Boot 驱动代码这就超出了“改 DTS”的范畴。遇到这种情况别死磕 DTS直接看驱动源码更实际。4.3 屏参版本分裂一个屏两套参数这个场景主要出现在比较老的 RK 平台比如 RK3288、RK3128 上。早期 SDK 的 U-Boot 里可能还保留着一套独立的 LCDC 面板参数数组它以结构体或者宏的形式写死在 C 文件里根本不读 DTS。内核侧则走设备树。两套参数一旦不一致就会出现 U-Boot logo 正常但内核黑屏或者反过来。这种情况下你不想动 U-Boot 都不行因为内核 DTS 参数根本传不到 U-Boot 的显示代码里。解决方案有两种一是把 U-Boot 里的面板参数改成与内核 DTS 一致二是把旧平台的 U-Boot 显示驱动升级成新平台那套基于 DTS 的 rockchip_display 驱动。具体怎么做取决于项目的改造成本。所以你看网上那些“RK 调屏不用改 U-Boot”的说法其实是针对新平台的老平台该改还得改。4.4 想裁剪 U-Boot 显示省启动时间还有一种反向操作产品压根不想要 U-Boot logo希望内核起来后直接出画面。这时候 U-Boot 显示初始化反而成了负担白白增加几十毫秒启动时间。你可以在 U-Boot DTS 里把 route 节点状态都置为 disabled或者干脆在 defconfig 里去掉显示驱动宏。这种“动 U-Boot”的本质是关闭显示不是调屏参。很多 Android 平板方案为了追求开机速度会做这步裁剪逻辑上也能明显缩短从上电到 kernel 首帧的时间。5. 调屏现场常见问题与排查思路5.1 改了内核 DTSU-Boot logo 反而不见了一个常见场景内核 DTS 改了屏参U-Boot 原本能显示 logo重编内核后发现 U-Boot logo 没了。原因通常是 U-Boot 的 dtb 还是旧参数或者新 DTS 里 route 节点的状态被改掉了。比如某块屏移除后你顺手把 dsi 节点 status 改成了 disabled但 U-Boot 的 dtb 还是老的它尝试初始化一块已经不存在的屏初始化失败后直接跳过显示。排查方法是先看 U-Boot 的串口日志确认显示驱动有没有探测到 panel再看 U-Boot dtb 和内核 dtb 的节点状态是否一致。如果确实不需要 U-Boot logo那就接受现状如果需要就重新编译 U-Boot把最新的 dtb 烧进去。5.2 U-Boot 有 logo内核起完黑屏U-Boot logo 正常至少说明硬件链路基本是通的屏和背光都没大问题。内核起来黑屏问题基本锁定在内核侧panel 节点的 compatible 没有对应驱动route_dsi 指向的 VOP 不对dsi,lanes 与实际接法不一致或者 DSI 初始化命令没有被内核驱动执行。在板子上执行dmesg | grep -E rockchip-drm|dsi|panel重点看有没有 “failed to find panel” 或者类似的报错。如果有就说明 panel 驱动没有匹配上回查 compatible 字符串和内核里 CONFIG_DRM_ROCKCHIP_* 相关配置。如果日志里能识别到 panel但画面不显示再查 route 和 vop 的绑定以及 DSI 的 lane 数。5.3 屏幕亮但花屏、颜色异常屏幕能亮说明电源、背光、VOP 基本工作正常花屏多半出在数据链路或时序参数上。常见的坑有三个一是 DSI lane 填错了屏是 4 lane 接的你写成 2 lane后续数据错位二是颜色格式不对屏支持 RGB666你写 RGB888颜色发白或者偏色三是时钟频率偏得离谱导致时序不一致。排查时先用示波器量 DSI clock 的波形频率再对照 DTS 里的 clock-frequency。如果是 RGB 接口的屏花屏大多和 hback-porch、hfront-porch 这些时序参数有关可以逐项和屏规格书比对。还有一个很容易忽略的问题U-Boot 和内核两份 dtb 参数不一样内核重新初始化时会闪一下花屏然后恢复正常。这种情况严格说不是“花屏”而是交接过程的数据撕裂但表现形式很像也要列入怀疑清单。5.4 偶发性不亮多半是时序和 GPIO 默认电平偶发不亮是最难查的问题因为很多时候重启一下又好了。我踩过的经验是优先怀疑复位 GPIO 时序和默认电平。有些板子用的 GPIO 在上电瞬间是浮空或者低电平如果 reset 是低有效可能导致屏在上电瞬间一直处于复位状态主控初始化时屏根本没准备好。解决办法是在 pinctrl 里给 reset GPIO 配置一个默认状态比如默认输出高电平避免上电瞬间抖动。另外电源到复位的延时、复位释放到 DSI 命令发送的延时这两个参数在很多屏厂规格书里有明确要求务必确认驱动里有对应延时。5.5 日志怎么看U-Boot 和 kernel 各自的战场U-Boot 里可以打开 CONFIG_CMD_DM在串口命令行执行 dm tree看看 panel 和 backlight 节点有没有被正确绑定。如果驱动报错一般会在初始化时直接打印在串口比如 “failed to bind panel” 之类的信息。内核侧看日志就方便多了dmesg 过滤 drm、dsi、panel、backlight 关键词即可。也可以配合 /sys 节点看背光状态和分辨率。如果 U-Boot 和内核日志都没有直接报错但是屏不亮这时候就得回到硬件层面先量屏供电再量 DSI 的 clock 和 data lane 上有没有波形最后量背光使能脚的电压。软件配置再完美供电没出来也是白搭。5.6 常见问题速查表现象优先排查项可能原因U-Boot 和内核都黑屏硬件供电、route 节点电源没供上或 route 被 disabledU-Boot 不亮内核亮defconfig、U-Boot dtb显示驱动没编进去或 dtb 未同步U-Boot 亮内核黑屏内核 dmesg、compatible内核 panel 驱动没匹配花屏DSI lane、clock-frequencylane 数不对或时序参数误差大偶发不亮reset GPIO 默认电平上电时序、复位时序不满足屏规格背光不亮enable-gpios、PWM 配置GPIO 默认电平错、PWM 未输出颜色异常dsi,formatRGB888/RGB666 格式不匹配我个人干 RK 调屏这几年最大的体会就是不要被“U-Boot DTS”这个词吓住。瑞芯微的设计思路是把显示参数的唯一权威版本放在内核 DTS 里U-Boot 只是搭便车正常情况下你不需要维护两份屏参。真正让你花掉一个下午的往往是那些 DTS 之外的东西——GPIO 默认电平、电源时序、屏厂初始化命令能不能在 U-Boot 简化驱动里完整跑完。如果你正在调一块新屏先把第 3 节那张参数清单拿到手再按第 5 节的排查顺序走一遍大概率能少走不少弯路。最后再分享一个小经验新项目拿来第一件事不要急着写自己的 DTS先在内核源码树里搜一款已经量产的、接口类型和分辨率接近的屏幕节点复制过来改参数成功概率远高于从零开始凭感觉拼节点。屏这东西初始化序列和时序要求非常吃具体型号找到一个接近的模板比对着规格书自己猜省太多时间。
RK平台调屏：U-Boot与内核DTS共享屏参，显示链路一次搞懂
调屏这件事很多从其它 SoC 平台转过来的工程师第一反应就是去 U-Boot 源码里翻 DTS找 panel 节点、找 backlight 节点、找 reset 引脚。但真正在 RK 平台上做过几个项目之后你会发现一个反直觉的现象内核 DTS 里的屏参改了、背光节点改了U-Boot 的 DTS 往往根本不用碰重新编译内核后屏幕照样点亮有些场景下连 U-Boot 都不用重新编译boot logo 也正常出现。这个现象不是运气而是 RK 的显示链路设计和设备树组织方式决定的搞懂了它你调屏的效率会高很多。这篇文章就围绕这个现象展开。我会先讲清楚 RK 从 VOP 到屏幕的链路再说为什么 U-Boot 通常不需要单独维护一份显示 DTS然后以 MIPI DSI 屏为例把完整调屏流程过一遍最后聊聊哪些情况下你必须回头动 U-Boot以及常见的黑屏、花屏问题怎么查。无论你是刚入行调屏的嵌入式工程师还是被一块屏折腾过好几天的老手这篇内容都值得存一下。1. 先掰开 RK 显示链路图像从 VOP 到屏幕到底经过什么1.1 接口类型差异MIPI DSI、eDP、LVDS、RGB 在 DTS 里长啥样RK 的显示控制器叫 VOPVideo Output Processor你可以把它理解成一块“画布”所有要显示的画面最终都在这里合成然后通过片上集成的各种显示接口把数据送出去。调屏的第一步就是搞清楚你的屏幕是通过哪种接口接进来的因为这决定了你在 DTS 里要找哪些节点。常见的 RK 显示接口有这么几类。接口典型场景DTS 里常见节点U-Boot 是否参与MIPI DSI平板、车载、小尺寸消费屏dsi、mipi_dsi、route_dsi可选eDP笔记本、中大尺寸屏edp、route_edp可选LVDS工控、车载大屏lvds、route_lvds可选RGB/CPU低成本小屏、并口屏lcdc、route_rgb一般只看背光不管哪种接口屏幕本身的描述——分辨率、时序、供电、复位时序、初始化命令——都在 panel 节点里接口控制器的参数比如 DSI 的 lane 数、eDP 的 lane 数、时钟频率则在外设控制器节点里。也就是说调屏时你改的其实是一堆互相引用的节点而不是单纯改某一个值。这里有个很多新手容易混淆的点U-Boot 和 Linux 内核是两套完全不同的驱动代码但它们读取的设备树来源却可以是同一份。RK 平台的 U-Boot 并不是像某些老平台那样在 C 代码里写死一组屏幕参数而是同样走设备树解析的路子。这就为“不用单独改 U-Boot DTS”埋下了伏笔。1.2 route 节点谁在决定“哪条路送画面”RK 设备树里有一类特殊节点叫 route 节点比如 route_dsi、route_edp、route_lvds。它干的事情是把某个 VOP 和某个显示输出接口绑定起来决定“画布上的画面到底从哪条物理链路送出去”。看一个典型片段route_dsi { status okay; connect vopb; };意思很直白DSI 这条显示通路要启用并且画面由 vopb 这个显示控制器送出。RK 一般有 VOPB 和 VOPL能力不同VOPB 通常更强一些支持更高分辨率VOPL 是低功耗用途。connect 里面绑的如果不是实际接线的那个 VOP那就会黑屏。这个节点在排查问题时非常关键。如果你把 route_dsi 的状态改成 disabled哪怕 DSI 控制器节点本身是 okay系统也不会往这块屏上送画面。U-Boot 和内核的显示驱动都会读取 route 节点所以当你发现“接口也对了、panel 也对了、背光也亮了但就是没画面”的时候第一件事就该检查 route 节点的状态而不是一头扎进时序参数里。不同 SDK 对 route 节点的命名有一点差异有的叫 route_mipi有的叫 route_dsi老平台可能还有 route_lvds。遇到不清楚的直接在 SDK 自带的 dts 文件里搜 route 就能找到本平台的命名规范。调屏前把这条链路自己在 dts 里追一遍能省下大量在群里问“为什么黑屏”的时间。2. U-Boot 的显示体系和内核不在一个频道但吃的是同一锅饭2.1 U-Boot 显示 logo 的典型流程U-Boot 为什么要管显示主要就一个目的开机时显示 logo或者在 Android 方案的 recovery 模式、fastboot 模式下给用户一个交互画面。它的显示初始化流程和内核 DRM 驱动的流程很像但简化得多。大致是这样的U-Boot 启动后如果 defconfig 里打开了显示驱动相关驱动会去解析 DTS 里的 VOP 节点、route 节点、panel 节点和 backlight 节点然后初始化 VOP 的时钟和控制器再根据 panel 节点里的时序参数配置对应的显示接口比如 DSI 的 lane 数、时钟频率接着初始化 GPIO 完成屏幕复位上电打开背光最后往 framebuffer 里写入 logo 内容。注意一个细节U-Boot 的显示驱动功能上比内核精简很多尤其对 MIPI DSI 屏幕有些屏需要一长串厂商初始化命令U-Boot 的驱动可能只执行了其中一部分甚至有些 SDK 版本根本不执行而是依赖屏硬件上电后的默认状态。这就导致同样一块屏在内核里正常在 U-Boot 里却花屏或者不亮。遇到这种现象不要急着改 U-Boot DTS先确认 U-Boot 驱动到底有没有执行你屏需要的初始化序列。2.2 同一个 DTS 怎么同时服务两套驱动回到核心问题为什么调屏时不用改 U-Boot DTS真正的技术关键在于RK SDK 里 U-Boot 的板级 DTS 文件通常会 include 内核的板级 DTS 文件。举个例子SDK 的 u-boot/arch/arm/dts/ 目录下有一份 rk3568-evb.dts文件内容往往不是从零开始写的而是像这样#include rk3568-evb.dts把它自己需要的一些 U-Boot 专属属性追加进去比如 chosen 节点、u-boot,boot0 标识、bootph-all 属性等。这意味着你在内核 dts 里写的 panel 节点、backlight 节点、route 节点U-Boot 在编译时也能看到。两套驱动吃的是同一棵设备树只是站在不同角度去解析而已。所以更准确的说法是不是“不用改 U-Boot DTS”而是“U-Boot DTS 不需要单独维护一份屏参”。你在内核 DTS 里改的屏参本质上已经是 U-Boot 能看到的参数了。调屏时你真正要做的是修改共享的那份 DTS然后重新编译 U-Boot让新的设备树打包进 uboot.img。要是你的调试流程是单独加载内核 dtb、不走 U-Boot 显示那连重编 U-Boot 这一步都可以省掉。这就是网上很多教程说“不用改 U-Boot”的真相。2.3 defconfig 才是 U-Boot 显示的“总开关”很多时候你觉得自己“没改 U-Boot 就亮了”其实是因为 SDK 默认的 U-Boot defconfig 里已经打开了显示驱动。U-Boot 的显示能力不是靠 DTS 决定是否编译的而是靠 Kconfig 配置。在 U-Boot 的 defconfig 里通常会有类似这样的配置项CONFIG_ROCKCHIP_DRM_DISPLAYy CONFIG_ROCKCHIP_DRM_DSIy CONFIG_ROCKCHIP_DRM_EDPy CONFIG_ROCKCHIP_BACKLIGHTy不同 SDK 版本的宏名会有些区别但思路一致。这些配置决定了 U-Boot 会不会把显示相关驱动编译进固件。如果某个平台把显示驱动整体裁剪掉了那你把 DTS 改成花也没用U-Boot 根本不会去解析显示节点。反过来如果这些宏默认是打开的那么 U-Boot 只要能在 DTS 里找到合法节点就会尝试初始化。这里就出现了一个调屏时很常见的误区有人改了 DTS 里所有显示参数U-Boot 仍然不出 logo于是怀疑是 DTS 哪里写错了折腾半天。其实问题可能在 defconfig 的开关上或者在 U-Boot 的板级文件有没有正确 include 那颗内核 DTS。遇到 U-Boot 显示问题先查“开关”再查“参数”不要一上来就改屏参。2.4 内核接管后U-Boot 的显示工作就结束了还有一个容易让人困惑的点U-Boot 已经把屏点亮了为什么内核起来后又要重新初始化一遍因为 U-Boot 和内核是两套独立的驱动U-Boot 初始化完的寄存器状态在跳转到内核后并不会被完整继承。内核的 DRM 驱动会重新 probe 硬件重新配置 VOP、重新发 DSI 初始化序列、重新调背光。所以 U-Boot 阶段的点亮本质上只是“早班员工先开了灯”内核起来后会再开一次。只要两边读的 DTS 参数一致这个过程用户无感如果两边参数不一致就会出现 logo 正常但内核起来黑屏或者 logo 花屏但内核显示正常这类奇葩现象。RK 为了让这个交接更顺滑在 U-Boot 和内核之间还留了一些 framebuffer 交接机制本质上也是靠 DTS 里的 reserved-memory 配置来对齐地址。但不管机制多复杂源头都是同一份设备树。所以调屏时把内核 DTS 作为“唯一权威版本”让 U-Boot 跟着走是最不容易出错的姿势。3. 调屏实操以 MIPI DSI 屏为例主要工作量其实在内核 DTS3.1 开工前必须从屏厂拿到的参数清单调屏不是拿到一块屏就开写 DTS没参数就是盲人摸象。我一般开工前会找屏厂要一份屏规格书并且重点核对下面这些东西。分辨率hactive、vactive这个不用说。时序hback-porch、hfront-porch、hsync-len、vback-porch、vfront-porch、vsync-len以及 clock-frequency。DSI 配置几 lane数据格式是 RGB888 还是 RGB666DSI 时钟频率。供电屏需要的 VCC、IOVCC、VCI 这些电压值以及上电顺序。复位时序reset 脚是低有效还是高有效拉低多久然后再拉高等多久才能发起操作。初始化命令有些 MIPI 屏上电后需要主控通过 DSI 发一串初始化命令这些命令序列屏厂通常会提供十六进制数组。背光背光 PWM 频率、使能脚电平、默认亮度。特别强调一下复位时序。不同屏差距非常大有的只要 1ms有的要 10ms。曾经遇到一块屏reset 拉低时间不够导致屏偶尔白屏改长时序后问题消失。这种问题是 DTS 参数不好解决的往往要在驱动里加延时或者在上电时序里处理好。3.2 修改 Panel、背光、route 节点的步骤以 MIPI DSI 屏为例典型的内核 DTS 修改包含三个地方。首先是 DSI 控制器下的 panel 节点。dsi { status okay; panel0 { compatible panel-mipi-dsi; reg 0; backlight backlight; reset-gpios gpio3 RK_PB6 GPIO_ACTIVE_LOW; pinctrl-names default; pinctrl-0 lcd_panel_reset; dsi,lanes 4; dsi,format MIPI_DSI_FMT_RGB888; display-timings { timing0 { clock-frequency 140000000; hactive 1080; vactive 1920; hback-porch 40; hfront-porch 40; hsync-len 8; vback-porch 10; vfront-porch 28; vsync-len 4; }; }; }; };其次是背光节点。背光常见方案是 PWM 背光也有 GPIO 开关背光的。PWM 频率要注意一般屏厂会推荐 20k 到 200k 之间太低会有可闻噪声太高可能影响亮度调节线性度。下面是一个典型配置。backlight { status okay; pwms pwm1 0 20000 0; enable-gpios gpio1 RK_PA1 GPIO_ACTIVE_HIGH; pinctrl-names default; pinctrl-0 bl_en; brightness-levels 0 255; default-brightness-level 200; };最后是 route 节点决定 VOP 和 DSI 接口的绑定关系。route_dsi { status okay; connect vopb; };这里必须要注意compatible 字符串要以你 SDK 自带的面板驱动模板为准我示例里的 panel-mipi-dsi 并不一定适用于所有内核版本。另外如果屏需要发初始化命令序列不同 SDK 的写法差别很大有的放在 panel 节点的 init-sequence 里有的用 rockchip,cmd 这种自定义字段还有的直接在驱动里做 switch 分支。别光看网上教程抄去 SDK 里搜一个现成量产的屏幕节点照它的格式改最稳妥。3.3 U-Boot 侧真正要做的三件小事内核 DTS 改完后如果你希望 U-Boot 也能正常显示 logoU-Boot 侧真正要做的事情其实很少通常就三件。第一确认 U-Boot 的 defconfig 里对应显示接口的驱动宏已经打开。这个前面说过是总开关。第二确认 U-Boot 板级 DTS 包含了内核 DTS。如果你的项目是基于 SDK 默认板子改的一般已经 include 了如果是自己新做的板子要检查 u-boot/arch/arm/dts 下的文件是否引用了你正在改的那颗内核 dts 文件。这一步被很多人忽略结果内核侧怎么改都正常U-Boot 永远老样子。第三重新编译 U-Boot 并烧写 uboot.img。这里说的“重编 U-Boot”不是改代码而是让 U-Boot 拿到最新生成的 dtb。如果你是调试阶段通过 fastboot 单独加载内核 dtbU-Boot 自带 dtb 不参与显示流程那确实连这一步都不需要。这也是为什么很多帖子里说“调屏不用动 U-Boot”——人家是在单独的调试加载模式下说的量产烧一体的镜像时还是得把 U-Boot 同步编译一遍。3.4 如果你想让 U-Boot 阶段也能过 logo还要多做什么如果你想在 U-Boot 阶段就把 logo 打出来并且对显示效果有要求光靠 DTS 参数同步还不够。需要确认 U-Boot 的显示驱动执行了屏的初始化流程。有些 MIPI 屏的初始化序列很长U-Boot 的驱动可能没有执行全这种情况你就得去 U-Boot 的 panel 驱动里补充初始化命令或者调整驱动的执行逻辑。另外logo 的格式和位置也有讲究。RK U-Boot 的 logo 一般放在 resource.img 分区内核起来后如果 DTS 里配置了同样的 logo 资源可以做到从 U-Boot logo 平滑切换到内核 logo不闪黑屏。如果你发现 logo 显示后有短暂黑屏再亮多半是内核 drm 重新初始化的过程中清空了 framebuffer而新的 logo 资源没有及时加载。这时候别急着找 U-Boot 的麻烦先检查内核侧 logo 资源有没有配好。4. 什么情况必须动 U-Boot DTS四个典型场景4.1 开机 logo 本身就是产品需求有些产品要求一上电就要看到品牌 logo并且从按 power 键到出 logo 的时间被死死卡住比如必须 300ms 内。这时候 U-Boot 显示是必须工作的U-Boot DTS 里关于 VOP、DSI、panel、backlight 的配置就都必须正确。但这里要分清绝大多数情况下你需要的不是“改 U-Boot 专用屏参”而是“确保 U-Boot 能拿到内核 DTS 里已经改好的屏参”。如果你手头 SDK 的 U-Boot 板级 DTS 没有正确 include 内核 DTS那你确实需要改 U-Boot DTS 的 include 关系否则 U-Boot 看不到屏节点。4.2 有些屏必须由 U-Boot 完成上电复位某些对时序要求苛刻的屏幕如果 U-Boot 阶段不做 GPIO 上电和复位等内核启动到一半才拉屏电源和复位屏幕就会白屏或者花屏。典型的例子是带 MCU 的 DSI 屏主控和屏的握手必须在上电后的很短时间内完成晚了屏可能进入异常状态。这种屏通常要在 U-Boot 阶段就把电源、复位 GPIO 处理好甚至要在 U-Boot 的 board 初始化代码里加延时。DTS 层面能做的是把 panel 节点的 reset-gpios、enable-gpios、pinctrl 配齐让 U-Boot 驱动在初始化时执行。但如果 SDK 的 U-Boot 驱动本身不解析这些 GPIO那你就得改 U-Boot 驱动代码这就超出了“改 DTS”的范畴。遇到这种情况别死磕 DTS直接看驱动源码更实际。4.3 屏参版本分裂一个屏两套参数这个场景主要出现在比较老的 RK 平台比如 RK3288、RK3128 上。早期 SDK 的 U-Boot 里可能还保留着一套独立的 LCDC 面板参数数组它以结构体或者宏的形式写死在 C 文件里根本不读 DTS。内核侧则走设备树。两套参数一旦不一致就会出现 U-Boot logo 正常但内核黑屏或者反过来。这种情况下你不想动 U-Boot 都不行因为内核 DTS 参数根本传不到 U-Boot 的显示代码里。解决方案有两种一是把 U-Boot 里的面板参数改成与内核 DTS 一致二是把旧平台的 U-Boot 显示驱动升级成新平台那套基于 DTS 的 rockchip_display 驱动。具体怎么做取决于项目的改造成本。所以你看网上那些“RK 调屏不用改 U-Boot”的说法其实是针对新平台的老平台该改还得改。4.4 想裁剪 U-Boot 显示省启动时间还有一种反向操作产品压根不想要 U-Boot logo希望内核起来后直接出画面。这时候 U-Boot 显示初始化反而成了负担白白增加几十毫秒启动时间。你可以在 U-Boot DTS 里把 route 节点状态都置为 disabled或者干脆在 defconfig 里去掉显示驱动宏。这种“动 U-Boot”的本质是关闭显示不是调屏参。很多 Android 平板方案为了追求开机速度会做这步裁剪逻辑上也能明显缩短从上电到 kernel 首帧的时间。5. 调屏现场常见问题与排查思路5.1 改了内核 DTSU-Boot logo 反而不见了一个常见场景内核 DTS 改了屏参U-Boot 原本能显示 logo重编内核后发现 U-Boot logo 没了。原因通常是 U-Boot 的 dtb 还是旧参数或者新 DTS 里 route 节点的状态被改掉了。比如某块屏移除后你顺手把 dsi 节点 status 改成了 disabled但 U-Boot 的 dtb 还是老的它尝试初始化一块已经不存在的屏初始化失败后直接跳过显示。排查方法是先看 U-Boot 的串口日志确认显示驱动有没有探测到 panel再看 U-Boot dtb 和内核 dtb 的节点状态是否一致。如果确实不需要 U-Boot logo那就接受现状如果需要就重新编译 U-Boot把最新的 dtb 烧进去。5.2 U-Boot 有 logo内核起完黑屏U-Boot logo 正常至少说明硬件链路基本是通的屏和背光都没大问题。内核起来黑屏问题基本锁定在内核侧panel 节点的 compatible 没有对应驱动route_dsi 指向的 VOP 不对dsi,lanes 与实际接法不一致或者 DSI 初始化命令没有被内核驱动执行。在板子上执行dmesg | grep -E rockchip-drm|dsi|panel重点看有没有 “failed to find panel” 或者类似的报错。如果有就说明 panel 驱动没有匹配上回查 compatible 字符串和内核里 CONFIG_DRM_ROCKCHIP_* 相关配置。如果日志里能识别到 panel但画面不显示再查 route 和 vop 的绑定以及 DSI 的 lane 数。5.3 屏幕亮但花屏、颜色异常屏幕能亮说明电源、背光、VOP 基本工作正常花屏多半出在数据链路或时序参数上。常见的坑有三个一是 DSI lane 填错了屏是 4 lane 接的你写成 2 lane后续数据错位二是颜色格式不对屏支持 RGB666你写 RGB888颜色发白或者偏色三是时钟频率偏得离谱导致时序不一致。排查时先用示波器量 DSI clock 的波形频率再对照 DTS 里的 clock-frequency。如果是 RGB 接口的屏花屏大多和 hback-porch、hfront-porch 这些时序参数有关可以逐项和屏规格书比对。还有一个很容易忽略的问题U-Boot 和内核两份 dtb 参数不一样内核重新初始化时会闪一下花屏然后恢复正常。这种情况严格说不是“花屏”而是交接过程的数据撕裂但表现形式很像也要列入怀疑清单。5.4 偶发性不亮多半是时序和 GPIO 默认电平偶发不亮是最难查的问题因为很多时候重启一下又好了。我踩过的经验是优先怀疑复位 GPIO 时序和默认电平。有些板子用的 GPIO 在上电瞬间是浮空或者低电平如果 reset 是低有效可能导致屏在上电瞬间一直处于复位状态主控初始化时屏根本没准备好。解决办法是在 pinctrl 里给 reset GPIO 配置一个默认状态比如默认输出高电平避免上电瞬间抖动。另外电源到复位的延时、复位释放到 DSI 命令发送的延时这两个参数在很多屏厂规格书里有明确要求务必确认驱动里有对应延时。5.5 日志怎么看U-Boot 和 kernel 各自的战场U-Boot 里可以打开 CONFIG_CMD_DM在串口命令行执行 dm tree看看 panel 和 backlight 节点有没有被正确绑定。如果驱动报错一般会在初始化时直接打印在串口比如 “failed to bind panel” 之类的信息。内核侧看日志就方便多了dmesg 过滤 drm、dsi、panel、backlight 关键词即可。也可以配合 /sys 节点看背光状态和分辨率。如果 U-Boot 和内核日志都没有直接报错但是屏不亮这时候就得回到硬件层面先量屏供电再量 DSI 的 clock 和 data lane 上有没有波形最后量背光使能脚的电压。软件配置再完美供电没出来也是白搭。5.6 常见问题速查表现象优先排查项可能原因U-Boot 和内核都黑屏硬件供电、route 节点电源没供上或 route 被 disabledU-Boot 不亮内核亮defconfig、U-Boot dtb显示驱动没编进去或 dtb 未同步U-Boot 亮内核黑屏内核 dmesg、compatible内核 panel 驱动没匹配花屏DSI lane、clock-frequencylane 数不对或时序参数误差大偶发不亮reset GPIO 默认电平上电时序、复位时序不满足屏规格背光不亮enable-gpios、PWM 配置GPIO 默认电平错、PWM 未输出颜色异常dsi,formatRGB888/RGB666 格式不匹配我个人干 RK 调屏这几年最大的体会就是不要被“U-Boot DTS”这个词吓住。瑞芯微的设计思路是把显示参数的唯一权威版本放在内核 DTS 里U-Boot 只是搭便车正常情况下你不需要维护两份屏参。真正让你花掉一个下午的往往是那些 DTS 之外的东西——GPIO 默认电平、电源时序、屏厂初始化命令能不能在 U-Boot 简化驱动里完整跑完。如果你正在调一块新屏先把第 3 节那张参数清单拿到手再按第 5 节的排查顺序走一遍大概率能少走不少弯路。最后再分享一个小经验新项目拿来第一件事不要急着写自己的 DTS先在内核源码树里搜一款已经量产的、接口类型和分辨率接近的屏幕节点复制过来改参数成功概率远高于从零开始凭感觉拼节点。屏这东西初始化序列和时序要求非常吃具体型号找到一个接近的模板比对着规格书自己猜省太多时间。
