1. 项目概述从黑屏到品牌化启动的必经之路在嵌入式系统开发中从按下电源键到操作系统完全启动中间有一段不短的时间。如果这段时间屏幕一片漆黑或者只有几行滚动的调试信息对于终端用户而言体验无疑是割裂且不专业的。想象一下你打开一台智能电视、一台工业平板或者一台自助服务终端首先映入眼帘的应该是品牌Logo、加载动画或者一个简洁的进度条而不是冷冰冰的硬件自检信息。这就是U-Boot的SPLASH_SCREEN启动画面功能存在的核心价值——它填补了硬件初始化完成与操作系统图形界面如Linux的DRM/FB驱动接管显示设备之间的视觉空白是打造完整、专业产品用户体验的第一个关键环节。我接触过不少项目早期为了赶进度往往忽略了这一环结果产品demo时客户第一句话就是“这开机怎么黑乎乎的像半成品”。后来我们团队把U-Boot启动画面作为产品交付的标配不仅提升了产品质感在调试阶段一个稳定的启动画面也能直观地确认显示子系统如LCD、LVDS、HDMI接口在Bootloader阶段就已经被正确驱动为后续内核启动扫清了一大障碍。今天要聊的就是把这块“画布”在U-Boot上驱动起来的具体方法它不仅仅是贴一张图那么简单涉及到显示框架的选择、内存管理、设备树配置以及和后续内核启动的无缝衔接是个挺有意思的“踩坑”与“填坑”过程。2. 核心思路与方案选型为何是“SPLASH”而非其他在动手之前我们得先理清楚U-Boot显示输出的几种路径以及为什么SPLASH_SCREEN是现阶段最通用和可行的方案。U-Boot本身不是一个图形化系统它的主要任务是初始化硬件、加载内核与根文件系统。因此其显示支持相对“原始”。2.1 U-Boot显示输出方案对比早期为了输出调试信息最常见的是通过串口Serial Console。但这显然与图形画面无关。对于有显示设备的平台U-Boot的图形输出大致经历了以下几个阶段控制台帧缓冲Console FrameBuffer这是最基础的功能。启用CONFIG_VIDEO或CONFIG_DM_VIDEO后U-Boot可以将控制台命令行输出重定向到帧缓冲Framebuffer设备也就是把字符画到屏幕上。这解决了“有显示”的问题但依然是字符模式无法显示复杂的图片或Logo。BMP图像显示U-Boot内置了对BMP位图格式的支持CONFIG_CMD_BMP。开发者可以在命令行手动执行bmp命令来显示一张存储在内存或存储设备中的BMP图片。这是一个进步但它是一个被动的、需要手动触发的功能无法实现自动化的启动画面。SPLASH_SCREEN驱动这正是我们今天的主角。它不是一个独立的驱动而是一个功能框架。它的核心思想是在U-Boot启动的早期阶段通常在板级初始化之后主循环开始之前自动地从指定的存储位置如NOR Flash、eMMC、网络加载一张预设好的图片并将其绘制到已经初始化好的帧缓冲Framebuffer上。整个过程是自动的并且提供了相对丰富的配置选项如图片位置、格式、对齐方式等。此外还有一些SoC厂商提供的私有化方案比如在SPLSecondary Program Loader阶段就初始化显示并显示Logo。但这些方案移植性差高度依赖特定平台。综合来看SPLASH_SCREEN方案在通用性、可配置性和社区支持度上取得了最好的平衡。它基于标准的U-Boot视频驱动模型DM_VIDEO只要你的平台支持DM_VIDEO并正确实现了显示驱动移植SPLASH_SCREEN的工作就会变得有章可循。2.2 关键组件依赖关系剖析理解SPLASH_SCREEN的运作需要明白它依赖的“地基”显示控制器驱动Video Driver这是底层硬件驱动负责初始化LCD控制器、HDMI TX等IP核设置显示时序分辨率、像素时钟、前后肩等并分配和管理帧缓冲内存。它通常由SoC厂商提供基础支持我们需要在板级代码或设备树中进行配置和微调。U-Boot视频驱动模型DM_VIDEO这是U-Boot引入的设备模型Driver Model在视频子系统上的体现。它提供了一套统一的API上层的功能如控制台、SPLASH通过这套API与底层具体的显示控制器驱动交互实现了驱动与应用的解耦。启用CONFIG_DM_VIDEO是使用SPLASH_SCREEN的前提。帧缓冲Framebuffer这是位于内存中的一段区域用来存储当前屏幕需要显示的图像数据。显示控制器会周期性地从这块内存中读取数据转换成时序信号发送给显示屏。SPLASH_SCREEN最终就是把图片数据写入这个区域。图片解码器SPLASH_SCREEN支持多种图片格式如BMP、PNG需额外库支持。需要对应的解码库将图片文件数据解码为原始的RGB像素数据。整个数据流可以概括为启动流程调用SPLASH框架 - SPLASH框架通过DM_VIDEO API获取当前活动的帧缓冲信息 - 从存储设备加载图片文件 - 调用解码器得到像素数据 - 将像素数据写入帧缓冲对应区域。注意在资源极其受限的系统或者SPL阶段中可能会采用更直接的方式比如将Logo图片直接编译成C数组链接到U-Boot镜像中在初始化显示后直接拷贝到帧缓冲。这种方式牺牲了灵活性换Logo需重新编译但节省了存储访问和解码的开销。SPLASH_SCREEN属于更通用、更高级的方案。3. 移植实操详解以NXP i.MX6ULL平台为例理论清晰后我们进入实战环节。我以经典的NXP i.MX6ULL EVK板搭载LCDIF显示控制器为例展示完整的SPLASH_SCREEN驱动移植流程。其他平台如Rockchip、TI、ST等思路完全一致只是底层驱动和设备树配置有所不同。3.1 基础环境与代码准备首先确保你有一个可编译的U-Boot源码树。我使用的是u-boot-imxNXP官方维护的分支版本基于2022.04。# 获取代码 git clone https://github.com/nxp-imx/uboot-imx -b lf-5.15.y-2.0.0 cd uboot-imx # 配置默认配置文件对于imx6ull 14x14 evk make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- imx6ull_14x14_evk_defconfig此时我们需要检查或开启一系列关键配置选项。3.2 内核配置打开必要的开关执行make menuconfig进入图形化配置界面。以下是需要逐项确认或开启的配置它们主要分布在几个菜单中Device Drivers - Graphics support:[ * ] Enable driver model for video (CONFIG_DM_VIDEO)【必须】启用视频设备模型。[ * ] Enable splash screen (CONFIG_SPLASH_SCREEN)【必须】启用SPLASH_SCREEN功能框架。在Video子菜单下找到你平台的显示驱动。对于i.MX6ULL它是[ * ] LCDIF display controller (CONFIG_VIDEO_MXS)【必须】这是i.MX系列的LCD接口驱动。[ * ] Support BMP images in the splash screen (CONFIG_SPLASH_SCREEN_BMP)【常用】启用对BMP格式的支持。BMP格式简单无需额外解码库是首选。[ ] Support PNG images in the splash screen (CONFIG_SPLASH_SCREEN_PNG)【可选】启用PNG支持。PNG带压缩节省存储空间但需要链接libpng库会增加U-Boot体积和启动时的解码时间。除非对镜像大小非常敏感否则BMP足矣。Boot images -:[ * ] Support drawing of a bitmap logo (CONFIG_CMD_BMP)【建议】虽然SPLASH_SCREEN不直接依赖它但开启BMP命令有助于我们后续手动测试图片显示功能。Environment -:确保环境变量支持你计划存放图片的存储设备如CONFIG_ENV_IS_IN_MMCeMMC/SD卡、CONFIG_ENV_IS_IN_SPI_FLASHSPI NOR Flash等。配置完成后保存退出。也可以直接通过修改include/configs/imx6ull_14x14_evk.h板级头文件或configs/imx6ull_14x14_evk_defconfigdefconfig文件来设置这些CONFIG宏。对于产品化项目直接修改defconfig文件是更规范的做法。3.3 设备树配置告诉U-Boot显示设备在哪里U-Boot也使用设备树Device Tree来描述硬件。我们需要确保显示设备在U-Boot的设备树源文件.dts或.dtsi中正确配置。对于i.MX6ULL EVK其设备树文件通常是arch/arm/dts/imx6ull-14x14-evk.dts。我们需要关注lcdif节点和可选的panel节点。检查lcdif节点该节点描述了LCD控制器本身。通常它已经在SoC级别的.dtsi文件如imx6ull.dtsi中定义好板级DTS文件需要启用它并设置正确的状态status “okay”和时钟。配置显示时序与面板参数这是最关键也是最容易出错的一步。参数必须与你的物理显示屏规格严格匹配。一个典型的配置示例如下lcdif { pinctrl-names default; pinctrl-0 pinctrl_lcdif_dat /* 数据线引脚 */ pinctrl_lcdif_ctrl /* 控制线引脚 */; display display0; status okay; display0: display { // 这是一个子节点定义显示面板属性 bits-per-pixel 24; // RGB888每个像素24位 bus-width 24; // RGB数据线宽度24位对应8-8-8 display-timings { native-mode timing0; // 指定主时序模式 timing0: timing0 { // 定义具体的时序参数 clock-frequency 33000000; // 像素时钟单位Hz hactive 800; // 水平有效像素 vactive 480; // 垂直有效像素 hfront-porch 40; // 水平前肩 hback-porch 88; // 水平后肩 hsync-len 48; // 水平同步脉冲宽度 vfront-porch 13; // 垂直前肩 vback-porch 32; // 垂直后肩 vsync-len 3; // 垂直同步脉冲宽度 hsync-active 0; // 水平同步极性0表示低电平有效 vsync-active 0; // 垂直同步极性 de-active 1; // 数据使能极性 pixelclk-active 0; // 像素时钟极性 }; }; }; };实操心得这些时序参数hback-porch,hsync-len等必须从你的显示屏数据手册Datasheet中获取。直接使用不匹配的参数会导致无显示、花屏、闪烁或偏移。我曾经因为pixelclk-active极性设反导致画面出现严重的重影和拖尾调试了很久才发现是极性配置问题。引脚控制Pinctrl配置确保pinctrl_lcdif_dat和pinctrl_lcdif_ctrl这两个引脚控制组在对应的pinctrl节点中正确定义将SoC的引脚复用为LCD功能。3.4 准备启动画面图片格式与尺寸推荐使用BMP格式24位色深RGB888。图片的宽度和高度最好与你在设备树中配置的hactive和vactive分辨率完全一致。如果尺寸不一致SPLASH_SCREEN会根据配置进行拉伸或居中但这可能增加额外的处理开销且效果不一定理想。制作与转换你可以用任何图像软件如GIMP、Photoshop制作一张800x480的BMP图片。在Linux下可以使用convert命令来自ImageMagick套件进行格式转换和尺寸调整convert my_logo.png -resize 800x480! -type truecolor BMP3:u-boot.bmp参数!表示强制缩放到指定尺寸。BMP3:指定输出为BMP Version 3格式兼容性最好。检查图片文件用file命令检查一下file u-boot.bmp # 期望输出u-boot.bmp: PC bitmap, Windows 3.x format, 800 x 480 x 243.5 集成图片到U-Boot镜像或存储设备如何让U-Boot找到这张图片主要有三种方式方式一嵌入到U-Boot镜像中推荐用于产品固化这是最可靠的方式图片和U-Boot二进制文件融为一体。将u-boot.bmp复制到U-Boot源码根目录。修改板级配置文件如include/configs/imx6ull_14x14_evk.h添加#define CONFIG_SPLASH_SCREEN_RAW \ splashimage0x8c000000\0 \ splashsize0x000bb800\0 /* 800*480*3 0xBB800 字节 */这里0x8c000000是i.MX6ULL DDR的加载地址你需要根据你的内存布局找一个不会被U-Boot代码、堆栈、环境变量等覆盖的安全区域。splashsize是图片的原始大小宽x高x3。修改链接脚本如arch/arm/cpu/u-boot.lds或板级特定的链接脚本在.rodata段或末尾添加一个节将图片数据链接进去。但更通用的方法是使用U-Boot的binman工具如果版本支持或直接使用objcopy。 一个更简单粗暴但有效的方法将图片直接追加到U-Boot镜像文件末尾。cat u-boot.bmp u-boot.imx然后你需要计算图片在最终镜像中的偏移地址并在环境变量中通过splashsource和splashoffset来指定。这种方式需要精确计算容易出错。方式二存放在独立的存储分区灵活便于更新这是开发阶段更常用的方式。将u-boot.bmp文件放在启动设备如SD卡、eMMC的某个固定分区比如第一个FAT分区。将图片文件拷贝到SD卡的FAT分区。sudo cp u-boot.bmp /media/yourusername/BOOT/设置U-Boot环境变量告诉它去哪里加载# 在U-Boot命令行中设置或固化到环境区 setenv splashsource mmc # 从MMC设备加载 setenv splashfile /u-boot.bmp # 图片文件路径 saveenv # 保存环境变量也可以直接在板级配置头文件中预设这些环境变量。方式三通过TFTP从网络加载用于调试在开发调试阶段频繁更换Logo时非常方便。setenv splashsource tftp setenv splashfile 192.168.1.100:u-boot.bmp saveenv启动时U-Boot会尝试从指定的TFTP服务器下载图片。注意事项环境变量splashpos可以控制图片位置如m,m表示居中。splash环境变量需要设置为yes来启用SPLASH功能。这些都可以在配置文件中预设。3.6 编译与测试配置和代码修改完成后进行编译make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- -j$(nproc)生成u-boot.imx或u-boot.bin等文件。将其烧录到设备启动。如果一切顺利在串口输出完基本的板级初始化信息后你应该能在屏幕上看到你的启动画面。4. 调试技巧与常见问题排查实录即使按照步骤操作第一次就成功的概率也不高。下面是我在多个项目中总结的排查清单基本能覆盖90%的问题。4.1 问题屏幕完全没有显示背光可能亮也可能不亮。排查思路1电源与背光检查显示屏的电源VCC、GND是否接通。用万用表测量电压。检查背光使能BL_EN和背光电源BL_VCC信号。有些屏幕需要CPU主动拉高一个GPIO来开启背光。检查设备树中背光backlight节点或相关的GPIO pinctrl配置是否正确。排查思路2时钟与复位确认LCD控制器的时钟如pix_clk已经使能。在U-Boot命令行中可以尝试使用clk命令如果支持查看时钟树状态。确认LCD控制器和显示屏的复位信号RESET时序正确。有些屏需要上电后延迟一段时间再释放复位。排查思路3引脚复用这是最高频的问题点使用pinmux命令如果平台支持或在源码中仔细核对设备树的pinctrl配置。确保数据线D0-D23、时钟PCLK、行场同步HSYNC, VSYNC、数据使能DE等引脚都被正确复用为LCD功能而不是其他功能如GPIO、UART。排查思路4设备树节点状态确认lcdif节点的status属性是“okay”。确认设备树编译进了U-Boot的dtb中。可以反编译u-boot.dtb文件来检查dtc -I dtb -O dts u-boot.dtb | grep -A 30 “lcdif”4.2 问题有显示但花屏、错位、滚动、颜色异常。排查思路1时序参数逐字核对设备树中的display-timings与屏幕手册。特别注意hfront-porch,hback-porch,hsync-len这三者的和必须等于手册中的“一行总时间Total Horizontal Time”减去hactive。垂直方向同理。一个像素的误差都可能导致画面不稳定。尝试微调clock-frequency像素时钟。时钟过快或过慢都可能导致采样错位。排查思路2数据格式与位宽检查bits-per-pixel和bus-width。对于24位色RGB888两者通常都设为24。如果是RGB56516位色则设为16同时需要确保图片格式也是16位的或者驱动支持格式转换。检查颜色分量顺序。LCD屏幕的像素数据格式可能是RGB、BGR、甚至其他排列。颜色异常红蓝互换通常就是这个问题。在设备树中寻找类似pixel-format的属性或是在驱动代码中寻找设置颜色格式的寄存器。i.MX的LCDIF有CTRL寄存器可以设置DATA_FORMAT。排查思路3极性信号重点检查hsync-active,vsync-active,de-active,pixelclk-active。这些极性必须与屏幕手册要求一致。用示波器测量这些信号波形是最直接的调试方法。极性反了可能导致画面显示在错误的位置如前肩区域或直接无法同步。4.3 问题U-Boot命令行输出正常但SPLASH图片不显示。排查思路1功能是否真正启用在U-Boot启动时观察串口日志搜索“splash”、“video”、“fb”等关键词。确认没有相关错误信息。在U-Boot命令行输入printenv检查splashsource,splashfile,splashpos,splash等环境变量是否已设置且值正确。尝试手动执行bmp命令显示图片测试显示通路是否畅通# 假设图片在MMC 1:1分区 mmc dev 1 fatload mmc 1:1 ${loadaddr} u-boot.bmp bmp info ${loadaddr} bmp display ${loadaddr}如果手动bmp display能显示说明底层驱动和帧缓冲是好的问题出在SPLASH_SCREEN的自动加载或初始化流程上。排查思路2图片加载失败检查splashsource指定的设备如mmc在SPLASH初始化时是否已经准备好。有时显示初始化很早但存储设备如SD卡驱动初始化较晚导致读取失败。可以调整初始化顺序或在SPLASH代码中添加重试机制。检查文件路径splashfile是否正确文件名大小写是否敏感。对于嵌入式到镜像的方式检查计算的内存地址或文件偏移量是否正确。使用mdmemory display命令查看目标地址的数据看是否是BMP文件头42 4D。排查思路3内存冲突确认用于存放图片数据的内存地址splashimage或加载地址是安全的没有被U-Boot自身代码、堆、栈、设备树覆盖。这通常需要分析链接脚本和系统内存映射图。4.4 问题SPLASH画面显示后引导Linux内核时画面闪烁或消失。原因分析这是“帧缓冲交接”的典型问题。U-Boot初始化了显示设备和帧缓冲并显示了图片。但当Linux内核启动时它的显示驱动如DRM或FB驱动会重新初始化硬件这个过程中可能会重置显示控制器导致屏幕短暂黑屏或闪烁。更严重的是如果内核驱动配置的显示参数分辨率、时序与U-Boot不一致可能导致无法显示。解决方案传递帧缓冲信息确保U-Boot通过设备树或ATAGS旧平台将已经初始化的帧缓冲信息如地址、大小、分辨率、格式传递给内核。现代内核通常通过设备树的chosen节点下的bootargs传递video参数或者U-Boot的fdt命令修改设备树节点。使用内核的Boot Logo更常见的做法是让U-Boot只负责初始化显示硬件到一种稳定状态可能不显示任何内容或显示一个极简的logo然后将一个包含logo的帧缓冲信息传给内核。由内核的bootlogo驱动通常是CONFIG_LOGO在启动早期接管并显示logo直到用户空间的图形服务启动。这样可以实现更平滑的过渡。这就需要配置U-Boot使其不启用SPLASH_SCREEN而是专注于硬件初始化并通过bootargs设置quiet loglevel1等参数抑制内核启动信息输出让内核logo得以显示。保持配置一致最根本的是确保U-Boot的设备树显示配置与Linux内核设备树中的配置完全一致。这样内核驱动在重新初始化时参数不变就不会产生复位闪烁。可以将显示配置放在一个共同的.dtsi文件中供U-Boot和Linux内核引用。移植SPLASH_SCREEN是一个系统工程它串联起了硬件驱动、固件配置和系统启动流程。成功实现的那一刻看到自家Logo在硬件上亮起那种成就感是对开发者最好的回馈。它不仅仅是“一张图片”更是产品从原型走向成熟、从功能实现迈向用户体验打磨的标志。