Rockchip Uboot SPL启动优化:定制存储介质探测顺序以缩短启动时间

张开发
2026/4/15 3:49:46 15 分钟阅读

分享文章

Rockchip Uboot SPL启动优化:定制存储介质探测顺序以缩短启动时间
1. 为什么需要优化Rockchip Uboot SPL的存储介质探测顺序每次按下电源键嵌入式设备都要经历一场与时间的赛跑。以智能盒子为例从开机到出现第一个画面用户能容忍的等待时间通常不超过2秒。但你可能不知道在这短短几秒里系统正在挨个敲开eMMC、SD卡、NAND等存储设备的大门就像快递员非要按固定路线送件哪怕你家永远只用京东快递。RK3568这类芯片默认的SPL启动流程就像个固执的检查员即便产品明确只使用eMMC存储它仍会按部就班检查SD卡槽、NAND芯片等所有可能的存储介质。实测数据显示每多探测一个无效介质启动时间就会增加80-150ms。当你的产品需要毫秒级响应时这种浪费就变得难以接受。我曾在工业网关项目上吃过亏——原本设计用纯eMMC方案却因保留默认探测顺序导致启动比竞品慢400ms。后来通过修改spl-boot-order节点直接把启动时间从1.8秒压缩到1.3秒效果堪比给系统换了固态硬盘。这告诉我们存储介质探测不是全家福拍照不需要所有成员到场。2. 深入理解SPL启动阶段的存储探测机制2.1 SPL阶段的启动顺序决策逻辑当RK3568芯片上电时小小的SPLSecondary Program Loader就像个刚睡醒的管家它要做的第一件事就是翻找u-boot,spl-boot-order这个任务清单。这个藏在设备树里的神秘列表决定了管家检查储物柜的先后顺序。原始配置sdmmc0, sdhci, nandc0, spi_nand, spi_nor意味着先翻抽屉ASD卡再开柜子BeMMC接着检查保险箱CNAND...每个存储接口都有对应的初始化代码在drivers/mmc/和drivers/mtd/目录下。以mmc为例探测过程就像是在问三个哲学问题你是谁设备ID你能存多少容量检测你速度怎样时钟校准这些操作看似简单却要消耗宝贵的时钟周期。2.2 存储介质探测的时间成本分析用示波器抓取RK3568的启动波形时我发现个有趣现象当SPL尝试访问不存在的SD卡时会先等待200ms的超时再优雅地放弃。这就像你打电话找人非要等彩铃唱完才肯挂断。具体耗时分布如下存储类型存在时探测耗时不存在时探测耗时eMMC120ms150msSD卡90ms200msNAND180ms220msSPI NOR60ms100ms更糟的是这些探测是串行进行的。假设产品只用eMMC但默认配置把SD卡放在第一位系统就会先浪费200ms在虚无的SD卡上。这就解释了为什么修改探测顺序能带来立竿见影的效果。3. 实战修改RK3568的SPL启动顺序3.1 定位和修改设备树关键节点打开rk3568-u-boot.dtsi这个藏宝图在约第15行会发现这样的配置chosen { u-boot,spl-boot-order sdmmc0, sdhci, nandc0, spi_nand, spi_nor; };假设我们的产品仅使用eMMC对应sdhci那么可以大胆裁剪为chosen { u-boot,spl-boot-order sdhci; };注意sdmmc0和sdhci的区别就像USB2.0和3.0接口。RK3568的sdhci对应eMMC控制器而sdmmc0对应SD卡槽。曾经有工程师误删sdhci导致系统找不到eMMC这种错误就像把自家钥匙扔出窗外。3.2 编译和部署修改后的SPL修改后需要特殊编译命令唤醒SPL的构建系统./make.sh rk3568 --spl-new生成的u-boot-spl.bin就像新培训的管家需要替换到指定位置cp spl/u-boot-spl.bin ../rkbin/bin/rk35/rk356x_spl_v1.14.bin这里有个坑我踩过三次SPL版本号必须与原有文件一致。比如原厂SDK使用v1.14你替换时若随意改成v1.15会导致后续uboot阶段找不到匹配的SPL。就像配钥匙时改了齿形却没告诉锁匠。4. 进阶优化技巧与避坑指南4.1 多介质场景下的顺序优化策略对于同时使用eMMC和SPI NOR的产品比如需要快速启动的工业HMI可以这样配置u-boot,spl-boot-order spi_nor, sdhci;把小巧的SPI NOR放在前面是因为它的探测耗时通常只有eMMC的一半。就像查宿舍时先检查人少的单间再查大通铺。但要注意SPI NOR容量有限通常8-16MB可能放不下完整固件此时需要配合uboot的二级加载机制。4.2 常见问题排查手册当修改后出现启动失败时建议按以下步骤排查检查串口日志用sudo minicom -D /dev/ttyUSB0 -b 1500000查看SPL报错验证设备树绑定确保节点名称与include/dt-bindings/block/rockchip-sfc.h中的定义一致测量电源时序有些NAND需要3.3V稳定后才能被识别过早探测会导致失败有次客户反映修改后启动变慢最后发现是错把spi_nand写成spi_nor。这种错误就像把冰箱写成冰霜虽然一字之差但后果很严重。

更多文章