📚 课程目录第4章 U-Boot基础

4. U-Boot基础

BootROM 这玩意儿，说白了就是芯片上电后执行的第一段代码。它固化在 ROM 里，你改不了，也删不掉。很多工程师觉得 BootROM 就是个黑盒子，跑完就完事了。但我在做底层固件开发时，吃过不少 BootROM 的亏——启动顺序没搞对，板子死活起不来；签名验证没配好，安全认证直接挂掉。所以这一章，咱们把 BootROM 的内部机制掰开揉碎了讲。

4.1 启动模式选择：芯片怎么知道自己该干啥？

芯片上电后，BootROM 第一件事就是确定启动模式。不同芯片厂商的做法不太一样，但核心思路是相通的——通过采样硬件引脚电平，来决定走哪条路。

我习惯把启动模式分为三类：

启动模式	典型用途	BootROM 行为
正常启动	产品量产，从 Flash 加载 U-Boot	枚举启动设备，找到有效镜像后跳转
下载模式	工厂烧录、开发调试	等待主机通过 USB/UART 下发镜像
恢复模式	固件损坏时的紧急恢复	进入最小系统，等待特定命令

嗯，这里要注意：启动模式的选择引脚，必须在 PCB 设计时就规划好。我遇到过一块板子，因为 BOOT 引脚上拉电阻没焊，导致芯片每次上电都随机进入不同模式。排查了两天才找到原因——说白了就是硬件设计时没仔细看 BootROM 的 datasheet。

核心要点：BootROM 在启动模式选择阶段，只做一件事——读引脚电平，然后查内部映射表，决定下一步执行哪个分支代码。这个过程通常在几十微秒内完成。

4.2 启动设备枚举与优先级：BootROM 按什么顺序找镜像？

确定启动模式后，BootROM 就开始枚举启动设备了。你想想看，芯片可能接了好几个存储设备——SPI Flash、NAND Flash、eMMC、SD 卡，甚至 USB 设备。BootROM 得按优先级一个个试，直到找到有效的启动镜像。

我画了一张流程图，帮你理清这个枚举逻辑：

枚举顺序通常是这样的：

BootROM 先查内部寄存器，看看有没有已经配置好的启动设备信息。
按优先级列表逐个尝试——先试 eMMC，再试 SPI Flash，最后试 SD 卡。
每个设备尝试读取固定偏移处的镜像头（通常是 0x0 或 0x200 等位置）。
校验镜像头中的魔数（Magic Number），匹配则认为设备有效。

我曾经踩过一个坑：某款 SoC 的 BootROM 在枚举 SPI Flash 时，默认只支持 3 字节地址模式。我用的 Flash 容量超过 16MB，需要 4 字节地址。结果 BootROM 读到的全是 0xFF，直接跳过，导致板子无法启动。解决方案是换了一颗小容量 Flash 做一级启动，再用 U-Boot 初始化大容量 Flash。

4.3 安全启动与签名验证：BootROM 如何保证镜像可信？

安全启动，说白了就是 BootROM 在加载 U-Boot 之前，先检查这个镜像是不是官方签发的。如果镜像被篡改过，BootROM 直接拒绝执行。

我参与过一个物联网网关项目，客户要求必须支持安全启动。当时我们用的是 ARM TrustZone + BootROM 签名验证的方案。整个流程是这样的：

步骤	执行者	具体操作
1	开发主机	使用私钥对 U-Boot 镜像进行签名，生成签名数据
2	工厂烧录	将签名后的镜像 + 公钥哈希烧入 Flash
3	BootROM	读取公钥哈希，与 OTP 中存储的哈希比对
4	BootROM	用公钥解密签名，与镜像哈希对比
5	BootROM	验证通过 → 跳转 U-Boot；失败 → 进入恢复模式

你可能会问：公钥存在哪里？ 答案是 OTP（一次性可编程存储器）。芯片出厂时，厂商会把公钥的哈希值烧进 OTP。BootROM 在验证时，会拿 Flash 中镜像附带的公钥哈希，跟 OTP 里的哈希做比对。匹配了，才信任这把公钥。

我个人习惯：在开发阶段，先关闭安全启动，用未签名的镜像调试 U-Boot 功能。等所有功能稳定后，再开启签名验证。否则每次修改镜像都要重新签名，开发效率会很低。

4.4 签名验证的底层实现：BootROM 里到底怎么算的？

BootROM 的签名验证，通常基于非对称加密算法。最常见的是 RSA-2048 或 ECDSA。我以 RSA 为例，给你拆解一下 BootROM 内部的验证逻辑：

// BootROM 签名验证伪代码（简化版）
int bootrom_verify_image(uint8_t *image_base) {
    // 1. 读取镜像头
    boot_header_t *hdr = (boot_header_t *)image_base;
    
    // 2. 检查魔数
    if (hdr->magic != BOOT_MAGIC) {
        return -1;  // 无效镜像
    }
    
    // 3. 从 OTP 读取公钥哈希
    uint8_t otp_hash[32];
    otp_read(OTP_PUBKEY_HASH_OFFSET, otp_hash, 32);
    
    // 4. 计算镜像中公钥的哈希
    uint8_t pubkey_hash[32];
    sha256_calc(hdr->pubkey, hdr->pubkey_len, pubkey_hash);
    
    // 5. 比对哈希
    if (memcmp(otp_hash, pubkey_hash, 32) != 0) {
        return -2;  // 公钥不匹配
    }
    
    // 6. RSA 解密签名，得到镜像哈希
    uint8_t decrypted_hash[32];
    rsa_decrypt(hdr->signature, hdr->signature_len, 
                hdr->pubkey, decrypted_hash);
    
    // 7. 计算实际镜像的哈希
    uint8_t image_hash[32];
    sha256_calc(image_base + HEADER_SIZE, 
                hdr->image_len, image_hash);
    
    // 8. 最终比对
    if (memcmp(decrypted_hash, image_hash, 32) == 0) {
        return 0;   // 验证通过
    } else {
        return -3;  // 签名无效
    }
}

这段代码虽然简化了，但核心逻辑就是这八步。嗯，这里有个细节要注意：BootROM 的 RSA 解密实现通常很精简，它只做公钥运算（加密），不做私钥运算（解密）。因为公钥运算只需要模幂运算，计算量小，适合 ROM 这种资源受限的环境。

关键认知：BootROM 的安全启动，本质上是建立了一条信任链。BootROM 验证 U-Boot，U-Boot 验证内核，内核验证应用。每一级都只信任上一级签发的镜像。这条链的根，就是 OTP 里那个不可篡改的公钥哈希。

4.5 实际项目中的避坑指南

做 BootROM 相关的开发，有几个坑我反复踩过，分享给你：

OTP 烧录不可逆——公钥哈希一旦烧进 OTP，就改不了了。我建议在开发板上先用可擦写的 eFuse 模拟 OTP，等公钥对确定后再量产烧录。
签名算法要留余量——RSA-2048 目前够用，但考虑到产品生命周期，我建议直接上 RSA-4096 或 ECDSA。BootROM 如果只支持小密钥，后续升级会很麻烦。
启动设备时序要测——有些 Flash 芯片上电后需要几十毫秒才能就绪。BootROM 如果枚举太快，可能读到无效数据。我在项目中遇到过，最后在硬件上加了延时电路才解决。
安全启动不是万能的——BootROM 只保证 U-Boot 是可信的。如果 U-Boot 本身有漏洞，攻击者照样可以绕过安全启动。所以 U-Boot 阶段的防护同样重要。