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芯片上电时，小小的SPL（Secondary Program Loader）就像个刚睡醒的管家，它要做的第一件事就是翻找u-boot,spl-boot-order这个任务清单。这个藏在设备树里的神秘列表，决定了管家检查储物柜的先后顺序。原始配置&sdmmc0, &sdhci, &nandc0, &spi_nand, &spi_nor意味着：先翻抽屉A（SD卡），再开柜子B（eMMC），接着检查保险箱C（NAND）...
每个存储接口都有对应的初始化代码在drivers/mmc/和drivers/mtd/目录下。以mmc为例，探测过程就像是在问三个哲学问题：你是谁（设备ID）？你能存多少（容量检测）？你速度怎样（时钟校准）？这些操作看似简单，却要消耗宝贵的时钟周期。
2.2 存储介质探测的时间成本分析
用示波器抓取RK3568的启动波形时，我发现个有趣现象：当SPL尝试访问不存在的SD卡时，会先等待200ms的超时，再优雅地放弃。这就像你打电话找人，非要等彩铃唱完才肯挂断。具体耗时分布如下：
| 存储类型 | 存在时探测耗时 | 不存在时探测耗时 |
|---|---|---|
| eMMC | 120ms | 150ms |
| SD卡 | 90ms | 200ms |
| NAND | 180ms | 220ms |
| SPI NOR | 60ms | 100ms |
更糟的是，这些探测是串行进行的。假设产品只用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。这种错误就像把"冰箱"写成"冰霜"，虽然一字之差，但后果很严重。