从 bootloader 到 rootfs：嵌入式 Linux 系统的完整构建与启动链路剖析

从 bootloader 到 rootfs：嵌入式 Linux 系统的完整构建与启动链路剖析

一、嵌入式 Linux 的"第一脚"：从上电到 Shell 的漫长旅途

在 x86 服务器上，按下电源键到出现登录提示符，整个过程不到 10 秒，用户几乎不会关注中间发生了什么。但在嵌入式设备上，启动链路的每一步都需要精确控制------bootloader 的初始化时序决定了外设是否就绪、内核的设备树配置决定了驱动能否加载、rootfs 的挂载方式决定了系统是否可写。任何一个环节配置错误，设备就是一块"砖"。

更棘手的是，嵌入式 Linux 的启动链路涉及多个独立组件的协作：ROM Code → SPL → U-Boot → Linux Kernel → init进程 → rootfs。每个组件有自己的构建工具链、配置格式和调试方法。如果只停留在"照着教程敲命令"的层面，遇到启动失败时根本无法定位问题------是 U-Boot 的设备树传参错了，还是内核的驱动匹配失败，还是 rootfs 的 init 程序崩溃了？

二、启动链路的完整时序与机制

sequenceDiagram participant ROM as ROM Code participant SPL as SPL(MLO) participant UBoot as U-Boot participant Kernel as Linux Kernel participant Init as init(PID 1) participant Rootfs as rootfs ROM->>SPL: 加载 SPL 到 SRAM Note over SPL: 初始化 DDR 时序<br/>配置时钟树 SPL->>UBoot: 加载 U-Boot 到 DDR Note over UBoot: 初始化网络/存储<br/>解析环境变量 UBoot->>Kernel: 加载内核镜像+设备树 Note over UBoot: 传递 bootargs<br/>指定 rootfs 位置 Kernel->>Kernel: 设备树解析<br/>驱动匹配与加载 Kernel->>Init: 挂载 rootfs，启动 init Note over Kernel: free_initmem()<br/>释放内核初始化代码 Init->>Rootfs: 执行 /etc/inittab Note over Init: 挂载 /proc, /sys, /dev<br/>启动用户空间服务

2.1 ROM Code 阶段

芯片上电后，CPU 从固定的 ROM 地址开始执行 Boot ROM 代码。这段代码固化在芯片内部，不可修改。它的任务是：从预定义的启动介质（SD卡 eMMC、NAND Flash）中读取 SPL（Secondary Program Loader）到芯片内部的 SRAM 中执行。

SRAM 通常只有 64-256KB，因此 SPL 必须非常精简。SPL 的唯一任务是初始化 DDR 内存控制器，为后续加载更大的 U-Boot 镜像做准备。

2.2 U-Boot 阶段

U-Boot 是嵌入式领域最常用的 bootloader。它的核心职责包括：

• 初始化板级硬件（网络、USB、显示等）
• 提供交互式命令行（用于调试和手动引导）
• 加载 Linux 内核镜像和设备树到内存
• 构造内核启动参数（bootargs），传递给内核

U-Boot 通过 bootargs 环境变量向内核传递关键信息：console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait。其中 root= 指定了 rootfs 的位置，rootwait 告诉内核等待存储设备就绪后再挂载。

2.3 内核启动阶段

内核启动后，首先解析 U-Boot 传递的设备树（Device Tree），根据设备树中的节点信息匹配和加载驱动程序。设备树是硬件描述文件，告诉内核"这个板子上有几个 UART、I2C 总线上挂了哪些设备、GPIO 的引脚复用配置"。

内核启动的最后一步是挂载 rootfs 并执行 init 程序。如果 rootfs 挂载失败，内核会抛出 VFS: Unable to mount root fs 的 panic，这是嵌入式 Linux 开发中最常见的启动失败原因之一。

三、完整构建流程与关键代码实现

3.1 U-Boot 编译与配置

#!/bin/bash
# U-Boot 编译脚本：以 i.MX6ULL 平台为例
set -euo pipefail

# 1. 设置交叉编译工具链
export CROSS_COMPILE=arm-linux-gnueabihf-
export ARCH=arm

# 2. 加载板级默认配置
make mx6ull_14x14_evk_defconfig

# 3. 自定义配置（修改启动参数、环境变量存储位置等）
# 通过 menuconfig 交互式配置，或直接修改 .config
# 关键配置项：
#   CONFIG_BOOTDELAY=3           # 启动延迟，留出进入U-Boot命令行的时间
#   CONFIG_ENV_SIZE=0x2000       # 环境变量分区大小
#   CONFIG_ENV_OFFSET=0xC0000    # 环境变量在eMMC中的偏移
#   CONFIG_BOOTCOMMAND="run findfdt; run mmcboot"
#   CONFIG_BOOTARGS="console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait"

# 4. 编译
make -j$(nproc)

# 5. 生成 SPL 和 U-Boot 镜像
# 输出文件：
#   SPL              → 第一阶段加载器
#   u-boot.img       → U-Boot 主镜像
#   u-boot.dtb       → U-Boot 自身的设备树
ls -la SPL u-boot.img u-boot.dtb

3.2 Linux 内核编译与设备树定制

#!/bin/bash
# Linux 内核编译脚本
set -euo pipefail

export CROSS_COMPILE=arm-linux-gnueabihf-
export ARCH=arm

# 1. 加载默认配置
make imx_v6_v7_defconfig

# 2. 自定义内核配置
# 关键配置项：
#   CONFIG_LOCALVERSION="-custom"   # 内核版本后缀
#   CONFIG_INITRAMFS_SOURCE=""      # 不使用内置initramfs
#   CONFIG_EXT4_FS=y               # 启用ext4文件系统支持
#   CONFIG_MMC_SDHCI_ESDHC_IMX=y   # 启用eMMC驱动
#   CONFIG_FEC=y                    # 启用以太网驱动
#   CONFIG_SERIAL_IMX_CONSOLE=y     # 启用串口控制台

# 3. 编译内核和设备树
make -j$(nproc) zImage dtbs

# 4. 编译内核模块（驱动以模块形式编译，放入rootfs）
make -j$(nproc) modules
make INSTALL_MOD_PATH=/opt/rootfs modules_install

# 输出文件：
#   arch/arm/boot/zImage                    → 压缩内核镜像
#   arch/arm/boot/dts/imx6ull-14x14-evk.dtb → 设备树
ls -la arch/arm/boot/zImage arch/arm/boot/dts/imx6ull-14x14-evk.dtb

3.3 设备树定制：添加自定义 I2C 设备

/* 自定义设备树覆盖：在 I2C1 总线上添加温度传感器 */
/dts-v1/;
/plugin/;

/* 覆盖基础设备树，添加自定义硬件描述 */
&i2c1 {
    status = "okay";
    clock-frequency = <100000>;  /* 100kHz 标准模式 */

    /* 温度传感器 LM75 */
    temperature_sensor: lm75@48 {
        compatible = "nxp,lm75b";  /* 驱动匹配标识 */
        reg = <0x48>;              /* I2C 从设备地址 */
    };

    /* 加速度传感器 MMA8451 */
    accelerometer: mma8451@1c {
        compatible = "fsl,mma8451";
        reg = <0x1c>;
        interrupt-parent = <&gpio1>;
        interrupts = <18 IRQ_TYPE_LEVEL_LOW>;  /* INT1 连接 GPIO1_18 */
    };
};

/* 保留 GPIO 引脚用于 LED 指示 */
&gpio1 {
    status-led {
        gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
        default-state = "off";
        linux,default-trigger = "heartbeat";
    };
};

3.4 rootfs 构建：使用 Buildroot

#!/bin/bash
# Buildroot 构建 rootfs
set -euo pipefail

# 1. 下载并解压 Buildroot
cd /opt/buildroot

# 2. 配置目标平台和软件包
make menuconfig
# 关键配置：
#   Target options → ARM little endian, cortex-A7
#   System configuration → 主机名、root密码、串口getty
#   Filesystem images → ext4格式，镜像大小128MB
#   Target packages → 选配：dropbear(SSH)、busybox、alsa-utils

# 3. 编译（自动下载源码、交叉编译、生成rootfs镜像）
make -j$(nproc)

# 4. 输出文件
#   output/images/rootfs.ext4  → ext4 格式的 rootfs 镜像
#   output/images/rootfs.tar   → tar 格式，可解压到SD卡分区
ls -la output/images/rootfs.ext4 output/images/rootfs.tar

3.5 完整烧录脚本

#!/bin/bash
# SD卡完整烧录脚本：将所有组件写入SD卡
set -euo pipefail

SDCARD=${1:?用法: $0 /dev/sdX}
BOOTLOADER_DIR=/opt/firmware
KERNEL_DIR=/opt/linux
ROOTFS_DIR=/opt/rootfs

# 安全检查：确认目标是SD卡而非系统磁盘
if [[ "$SDCARD" == /dev/sda* ]]; then
    echo "错误：目标设备 $SDCARD 可能是系统磁盘，拒绝操作"
    exit 1
fi

# 1. 分区：100MB boot分区 + 剩余空间 root分区
sudo sfdisk "$SDCARD" <<EOF
label: dos
unit: sectors

${SDCARD}1 : start=8192, size=204800, type=c
${SDCARD}2 : start=212992, type=83
EOF

# 2. 写入 SPL 和 U-Boot（写入SD卡裸扇区，不走文件系统）
sudo dd if=$BOOTLOADER_DIR/SPL of=$SDCARD bs=1K seek=1 conv=fsync
sudo dd if=$BOOTLOADER_DIR/u-boot.img of=$SDCARD bs=1K seek=69 conv=fsync

# 3. 格式化并写入 boot 分区
sudo mkfs.vfat ${SDCARD}1
sudo mount ${SDCARD}1 /mnt/boot
sudo cp $KERNEL_DIR/zImage /mnt/boot/
sudo cp $KERNEL_DIR/imx6ull-14x14-evk.dtb /mnt/boot/
sudo umount /mnt/boot

# 4. 格式化并写入 rootfs 分区
sudo mkfs.ext4 ${SDCARD}2
sudo mount ${SDCARD}2 /mnt/rootfs
sudo tar xf $ROOTFS_DIR/rootfs.tar -C /mnt/rootfs
sudo umount /mnt/rootfs

echo "烧录完成，可将SD卡插入目标板启动"

四、构建方案的 Trade-offs 分析

方案一：Buildroot vs Yocto

维度	Buildroot	Yocto
学习曲线	低，配置简单	高，概念体系复杂
构建速度	快（单次约 30 分钟）	慢（首次约 2-4 小时）
包管理	无（每次全量构建）	有（rpm/deb 包管理）
可复现性	中等	高（锁定配方版本）
社区生态	中等	丰富（BSP 层多）
适用场景	快速原型、小团队	产品级维护、大团队

方案二：initramfs vs 直接挂载 rootfs

initramfs 是一个嵌入内核或独立存储的微型 rootfs，内核先挂载它，再由 initramfs 中的脚本加载必要的驱动模块后切换到真正的 rootfs。适用场景：rootfs 在 USB/NFS 等需要额外驱动才能访问的介质上。如果 rootfs 在 eMMC/SD 卡上，内核自带存储驱动，可以直接挂载，无需 initramfs，减少启动时间约 0.5-1 秒。

关键边界条件：

• SPL 的 DDR 初始化时序必须与目标板上的 DDR 芯片型号完全匹配。不同厂商、不同容量的 DDR3L 芯片，时序参数差异很大。如果时序配置错误，DDR 无法正常工作，U-Boot 加载后会出现随机崩溃
• 设备树的 compatible 属性必须与内核驱动中的 of_device_id 表匹配。大小写敏感，字符串完全一致才能触发驱动加载。这是设备树调试中最常见的低级错误
• rootfs 的 init 程序（通常是 /sbin/init 或 BusyBox 的 init）必须是动态链接器可找到的。如果 rootfs 缺少 /lib/ld-linux-armhf.so.3，init 无法执行，内核会 panic

五、总结

嵌入式 Linux 的完整构建链路涉及五个独立组件的协作，每个组件都有明确的职责边界：ROM Code 加载 SPL，SPL 初始化 DDR，U-Boot 加载内核，内核匹配驱动并挂载 rootfs，init 进程启动用户空间服务。理解这条链路的关键是抓住"谁加载谁、谁传参给谁"的主线。

落地建议：先用厂商提供的 BSP 快速验证硬件可用性，再逐步替换各组件为自定义构建。每次只替换一个组件，确认启动正常后再替换下一个。设备树是调试频率最高的组件，建议在 U-Boot 阶段通过 fdt addr 和 fdt print 命令检查设备树内容，避免将设备树问题误判为驱动问题。构建工具选型上，小团队用 Buildroot 足够，大团队或需要长期维护的产品考虑 Yocto。