无需bootloader，BootROM -＞ Linux Kernel 启动模式

BootROM -> Linux Kernel 这种直接启动模式，是一种非常优雅且高效的引导方案，它代表了嵌入式系统引导流程的“终极简化”。

这种模式的核心理念是：最大限度地利用芯片内置的、固化的 BootROM 的能力，跳过专用的二级引导程序（如 U-Boot），让 BootROM 直接加载并启动 Linux 内核。

这并非适用于所有情况，但在满足条件的场景下，它具有巨大优势。

一、 为什么这可能？BootROM 的进化

传统的引导流程是：
BootROM -> SPL -> U-Boot -> Linux Kernel

而我们现在讨论的是：
BootROM -> Linux Kernel

之所以能实现这种简化，是因为现代芯片（特别是应用处理器 SoC）的 BootROM 变得越来越智能。它不再只是一个简单的、只能从单一源读取少量代码的固件。现代的 BootROM 通常集成了以下关键功能：

1. 支持多种启动设备：如 eMMC、SD卡、SPI NOR/NAND Flash、UART、USB等。开发者可以通过芯片的引脚电平（Boot Mode）在复位时选择从哪个设备启动。
2. 集成基础驱动：BootROM 内部固化了读取这些启动设备所需的最基础的驱动程序。
3. 文件系统解析能力：这是最关键的一点！许多 BootROM 现在具备了识别 FAT、EXT4 等常见文件系统的能力。这意味着它不再只是从存储设备的固定绝对偏移地址读取数据，而是可以像电脑的 BIOS 一样，从格式化的分区中按文件名查找并读取文件。
4. 安全启动：高端的 BootROM 还支持从硬件层面验证加载代码的密码学签名，确保只有受信任的软件才能被加载。

二、 如何实现？

实现 BootROM -> Kernel 启动，需要完成以下步骤：

1. 硬件配置（Boot Mode）
• 通过设置芯片的引导引脚（Boot Pin），选择从期望的设备启动，例如设置为从 eMMC 启动。

2. 存储设备布局

• 你的存储设备（eMMC/SD卡）需要被正确分区和格式化。通常至少需要两个分区：
◦ 第一个分区（FAT/EXT4）：这是一个可挂载的文件系统分区。BootROM 会自动识别并挂载它。这个分区里存放着关键文件：
▪ Linux Kernel Image：通常是 zImage 或 uImage。
▪ Device Tree Blob (DTB)：描述硬件信息的设备树文件。
▪ （可选）启动脚本或其他配置文件。
◦ 第二个分区（EXT4/UBIFS等）：这是 Linux 系统的根文件系统（rootfs）。

3. 内核准备
• 内核必须被编译成 BootROM 可接受的格式（例如，uImage 格式包含一个 BootROM 能识别的头信息，其中包含加载地址和入口地址等信息）。

• 内核需要被配置为能够“自解压”（CONFIG_KERNEL_GZIP 等），因为 BootROM 通常不会帮你解压。

• 内核的编译配置中，必须指定正确的机器类型或设备树，因为此时没有 U-Boot 来动态传递 fdt_addr 等参数。

4. 启动流程详解

1. 芯片上电，运行 BootROM。
2. BootROM 读取引导引脚，初始化对应的外部设备控制器（如 eMMC 控制器）。
3. BootROM 读取存储设备的第一个分区（假设是 FAT32），并在这个文件系统中查找预定义文件名的内核镜像（例如 zImage）和设备树文件（例如 dtb）。
4. BootROM 将内核镜像和设备树文件加载到内存的预定义地址。这些地址是硬件平台约定的，或者由内核镜像头信息指定。例如，内核可能约定必须被加载到 0x80008000，设备树放到 0x83000000。
5. BootROM 直接跳转到内核的入口地址，将控制权交给 Linux Kernel。
6. Linux Kernel 开始执行：自解压、解析设备树、初始化硬件、最后挂载根文件系统并启动用户空间的 init 进程。

三、 优势与劣势

优势

简单 | 精简 | 快速 | 安全

• 极致的简单与可靠：引导链更短，出问题的环节更少。没有复杂的 U-Boot 配置和环境变量。

• 节省存储空间：完全省去了 U-Boot 和 SPL 所占用的几十甚至几百KB的存储空间。对于成本极度敏感的项目，每一分钱都很重要。

• 启动速度更快：跳过了一整个软件的加载和执行阶段，启动时间可以缩短几十到几百毫秒。

• 安全性（潜在）：如果 BootROM 支持安全启动，并且内核镜像也签署了相应的证书，那么可以实现从开机第一刻就开始的信任链验证。

劣势与挑战

• 灵活性极大降低：这是最致命的缺点。没有 U-Boot，意味着你失去了：

◦   强大的命令行修复工具：设备出问题时，你无法通过串口中断启动去手动修复、测试硬件、重新烧写系统。◦   网络启动（TFTP）：开发阶段最常用的快速刷机调试方式无法使用。◦   动态配置：无法通过 U-Boot 环境变量（如 bootargs）动态修改内核启动参数。所有参数必须在编译内核时就确定，或者通过修改文件系统分区里的配置文件来间接修改，非常不便。

• 高度依赖芯片 BootROM：启动能力锁定在硅前验证阶段。如果 BootROM 有 Bug（例如对某个 eMMC 芯片兼容性差），几乎无法修复。

• 开发和调试极其困难：在开发硬件驱动或调试启动问题时，没有 U-Boot 这个“中间人”提供打印信息和交互能力，问题排查会像盲人摸象。

• 内存布局固定：内核和设备树的加载地址必须在编译时就与 BootROM 的约定保持一致，缺乏 U-Boot 动态重定位的灵活性。

四、 典型应用场景

这种直接启动模式非常适合以下情况：

1. 大规模量产的低成本消费电子产品：例如智能家居设备、简单的 IoT 节点、玩具等。这些产品功能固定，软件出厂后永不更新，对成本和启动速度有要求，且不需要复杂的现场调试功能。
2. 极其注重安全启动的场合：信任链从 BootROM 开始，到内核结束，非常清晰简洁。
3. 芯片内置内存极小的微控制器（MCU）级芯片，根本无法容纳 U-Boot SPL。

总结

BootROM -> Linux Kernel 是一种优雅、高效但牺牲了灵活性的引导方案。它代表了嵌入式系统设计中的一个重要权衡：用开发调试的便利性，去换取生产时的成本、复杂度和启动速度的优化。

对于产品定义非常明确、硬件稳定、不需要后期现场维护的场景，它是一个非常理想的选择。然而，对于绝大多数产品开发和原型阶段，U-Boot 提供的灵活性和可调试性是不可或缺的，这也是为什么 U-Boot 至今依然如此流行的根本原因。