首页/资讯中心/详情

从零构建嵌入式Linux系统镜像：U-Boot、内核与根文件系统实战指南

从零构建嵌入式Linux系统镜像：U-Boot、内核与根文件系统实战指南
📅 发布时间：2026/7/30 8:07:43

1. 项目概述：为什么需要亲手制作嵌入式Linux系统镜像？

如果你玩过树莓派、香橙派这类开发板，或者接触过工业网关、智能摄像头这些嵌入式设备，大概率都接触过“刷系统”这个操作。通常是从官网下载一个现成的.img文件，用工具写到SD卡里，上电就能跑。这很方便，但就像吃预制菜，你永远不知道里面到底加了什么料，也不知道当你的硬件稍有不同时，它会不会“水土不服”。

自己动手制作一个嵌入式Linux系统镜像，就是从零开始“备菜、炒菜”的过程。这个过程的核心价值在于掌控力和定制化。你能够精确控制系统里包含哪些软件包、内核配置了哪些驱动、文件系统如何布局、甚至开机第一个运行的程序是什么。这对于产品开发、性能优化、安全加固和问题调试来说，是至关重要的基础能力。基于SD卡制作，则是嵌入式开发中最经典、最直观的入门方式，它绕开了复杂的烧录器，让硬件和软件的交互变得触手可及。简单来说，这不是一个炫技的操作，而是一个嵌入式开发者必须掌握的、解决实际问题的基本功。

2. 核心思路与方案选型：从零构建的路径选择

制作一个可启动的Linux系统镜像，本质上是准备三个核心部件：引导加载程序（Bootloader）、Linux内核（Kernel）和根文件系统（Root Filesystem），并按照硬件规定的格式，把它们正确地放置到存储介质（这里是SD卡）的特定位置。

目前主流的有两种构建思路，它们的选择取决于你的目标、硬件平台和开发阶段。

2.1 方案一：使用构建系统（如Buildroot/Yocto Project）

这是用于产品级开发的“工业流水线”。Buildroot和Yocto Project这类工具，允许你通过配置菜单或脚本，从源码自动交叉编译出包括Bootloader、内核、根文件系统在内的完整系统镜像。它们能解决复杂的依赖关系，生成高度定制化且可复现的系统。

  • 优点：自动化程度高，可复现性强，适合管理复杂项目，能生成最精简的系统。
  • 缺点：学习曲线陡峭，初始配置耗时，编译过程长（首次可能数小时），对理解底层细节帮助有限。
  • 适用场景：产品量产、需要严格版本控制、追求极致系统尺寸的正式项目。

2.2 方案二：手动组合与部署（本方案重点）

这是我们本次采用的方法，也是理解系统启动链条最直观的方式。我们会分别准备或编译好U-Boot（最流行的Bootloader）、Linux内核，然后准备一个基本的根文件系统（例如使用Debian/Ubuntu的基础文件系统），最后手动将它们“组装”到SD卡上。

  • 优点：过程透明，每一步都可控，极大加深对系统启动流程、磁盘分区、文件系统的理解。调试时，可以单独替换某个部件（如只更新内核），非常灵活。
  • 缺点：步骤繁琐，需要手动处理一些依赖和配置。
  • 适用场景：学习、原型验证、深度定制、以及希望透彻理解系统构成的开发者。

注意：对于像树莓派这类“闭源Bootloader”的板子，其Bootloader（bootcode.bin, start.elf）是博通提供的二进制固件，我们无法替换。我们的“手动”主要体现在配置内核和根文件系统上，但分区和部署逻辑是相通的。

为什么选择手动方案作为讲解主线？因为只有亲手“拆装”一遍，你才能真正明白当你按下开发板电源键后，芯片内部到底发生了什么，系统是如何一步步从SD卡里“活”过来的。这份理解是解决后续各种诡异启动问题、性能瓶颈和定制需求的基石。

3. 环境准备与工具链搭建

在开始“组装”系统之前，我们需要一个工作车间和一套顺手的工具。这个车间就是你的宿主机（通常是一台x86_64的Linux PC或虚拟机），工具就是交叉编译工具链。

3.1 宿主机环境

确保你的宿主机是Linux系统（Ubuntu 20.04/22.04， Debian等是常见选择）。你需要安装一些基础工具：

sudo apt update sudo apt install -y build-essential git bison flex libssl-dev libncurses-dev \ parted dosfstools mtools u-boot-tools device-tree-compiler \ qemu-user-static bc rsync
  • build-essential：提供gcc, make等编译工具。
  • git：用于获取源码。
  • bison, flex：某些源码编译所需的语法分析器。
  • libssl-dev, libncurses-dev：编译内核和U-Boot常用的开发库。
  • parted, dosfstools, mtools：用于对SD卡进行分区和创建文件系统。
  • u-boot-tools：提供制作U-Boot镜像的工具（如mkimage）。
  • device-tree-compiler (dtc)：编译设备树源文件（.dts）为二进制文件（.dtb）。
  • qemu-user-static：关键工具！它允许我们在x86宿主机上运行为ARM编译的程序，用于后续构建根文件系统时的chroot环境。
  • bc, rsync：编译内核和高效文件同步所需。

3.2 获取交叉编译工具链

我们的宿主机是x86架构，目标板（如ARM Cortex-A系列）是另一种架构。我们需要一个“翻译官”——交叉编译器，它运行在x86上，但生成ARM架构的可执行文件。

获取方式：

  1. 从芯片厂商或开发板供应商获取：这是最推荐的方式。例如，NXP i.MX系列提供gcc-arm-none-eabi，Rockchip提供专门的工具链。它们通常针对自家芯片的微架构（如Cortex-A53, A72）做过优化。
  2. 从Linaro等社区下载：Linaro提供了通用的ARM工具链。例如，对于ARMv8-A 64位系统：
    wget https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz tar -xf gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz export CROSS_COMPILE=$(pwd)/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- export ARCH=arm64
    将最后两行export命令添加到你的~/.bashrc文件中，以便后续使用。

验证工具链：

${CROSS_COMPILE}gcc --version

如果正确输出了版本信息，且前缀是aarch64-linux-gnu-（64位）或arm-linux-gnueabihf-（32位硬浮点），说明工具链就绪。

实操心得：工具链的版本要与你的内核和库的版本大致匹配。使用太旧的工具链编译新内核可能会失败，使用太新的又可能引入兼容性问题。跟随板厂或芯片原厂的推荐版本是最稳妥的。

4. 系统组件详解与获取

现在，我们来准备系统的三个核心部件。

4.1 Bootloader：以U-Boot为例

U-Boot是嵌入式领域事实上的标准Bootloader。它负责初始化最基本的硬件（如DRAM控制器、时钟、串口），然后从存储设备（SD卡、eMMC、网络）加载Linux内核和设备树到内存，并跳转到内核执行。

获取U-Boot：

git clone https://github.com/u-boot/u-boot.git cd u-boot # 切换到稳定版本分支，如 v2024.01 git checkout v2024.01

配置与编译： U-Boot针对不同的板子有预置的配置文件，位于configs/目录下，通常以_defconfig结尾。例如，对于树莓派3B+（BCM2837）：

# 对于树莓派，我们通常使用其自带的闭源Bootloader，这里以通用的ARMv8开发板（比如基于Rockchip RK3568的某款板子）为例 # 假设其配置名为 rockchip_rk3568_defconfig make CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH} rockchip_rk3568_defconfig # 图形界面配置（可选） # make CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH} menuconfig # 编译 make CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH} -j$(nproc)

编译成功后，会生成关键文件：u-boot.bin（二进制文件）和u-boot.img（可能包含头部信息的镜像）。对于需要SPL（Secondary Program Loader，二级程序加载器）的平台，还会生成u-boot-spl.bin。

注意事项：务必确认你的开发板是否需要以及如何使用SPL。有些平台（如早期的i.MX6）的Boot ROM只能加载很小的一段代码（SPL），再由SPL去加载完整的U-Boot。这通常需要在编译U-Boot时，通过make *_defconfig和make自动生成。

4.2 Linux内核

内核是系统的核心，管理硬件资源，提供系统调用接口。

获取内核：

git clone https://github.com/torvalds/linux.git cd linux # 切换到长期支持(LTS)版本，如 linux-6.1.y git checkout v6.1

配置内核： 内核配置极其复杂，但幸运的是，我们可以基于一个已知可用的配置开始。这个配置可能来自：

  • 开发板供应商提供的SDK中的内核配置文件（.config）。
  • 该板型在主线内核中的defconfig（如make ARCH=arm64 defconfig生成一个极简配置，或make ARCH=arm64 rockchip_defconfig）。
# 导入基础配置 make CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH} rockchip_defconfig # 启动图形化配置菜单，进行定制（如增加驱动、文件系统支持、调试功能） make CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH} menuconfig

在menuconfig中，你需要确保：

  • 对应的CPU架构和SoC型号被选中。
  • 必要的驱动被编译进内核（*）或编译为模块（M），如SD/MMC控制器驱动、USB驱动、网络驱动等。
  • 你计划使用的根文件系统类型被支持（如EXT4,SQUASHFS,BTRFS）。
  • （可选但推荐）启用CONFIG_DEVTMPFS和CONFIG_DEVTMPFS_MOUNT，这对于/dev设备节点的自动管理很重要。

编译内核与设备树：

# 编译内核镜像和设备树 make CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH} -j$(nproc) Image dtbs # 如果需要编译内核模块（如果你在menuconfig中选择了`M`） make CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH} -j$(nproc) modules

编译产物：

  • arch/arm64/boot/Image： 压缩后的内核镜像（ARM64架构）。
  • arch/arm/boot/zImage： 压缩后的内核镜像（ARM 32位架构）。
  • *.dtb文件： 在arch/arm64/boot/dts/或arch/arm/boot/dts/目录下，对应不同板型的设备树二进制文件。设备树以一种数据结构的形式，向内核描述板子的硬件资源（如内存地址、外设、中断号），是现在嵌入式Linux硬件描述的主流方式。

4.3 根文件系统

根文件系统是内核启动后挂载的第一个文件系统（/），包含了系统运行所需的所有目录结构、配置文件、系统工具和应用程序库。

制作根文件系统有多种方法，这里介绍两种实用的：

方法A：使用Debian/Ubuntu的预编译基础包（debootstrap）这是快速获得一个功能相对完整、易于进行软件包管理（apt）的系统的好方法。

# 1. 创建一个目录作为根文件系统的根 sudo mkdir rootfs # 2. 使用debootstrap构建最小系统。这里以Ubuntu 22.04 (Jammy) 针对ARM64为例。 # 你需要根据目标架构调整 --arch 和 suite。 sudo debootstrap --arch=arm64 --foreign jammy ./rootfs http://ports.ubuntu.com/ubuntu-ports # 3. 复制qemu-aarch64-static到根文件系统，以便在宿主机环境下执行目标架构的程序 sudo cp /usr/bin/qemu-aarch64-static ./rootfs/usr/bin/ # 4. 切换到目标系统环境（chroot）并完成第二阶段安装 sudo chroot ./rootfs /bin/bash # 现在你在一个“模拟”的ARM64系统里了 /debootstrap/debootstrap --second-stage # 安装一些基础包 apt update apt install -y sudo ssh net-tools iputils-ping vim systemd-sysv # 设置root密码 passwd root # 创建一个普通用户 adduser ubuntu # 退出chroot环境 exit

现在，./rootfs目录下就是一个基本的Ubuntu根文件系统了。你还可以在里面安装你需要的任何软件。

方法B：使用BusyBox构建极小系统BusyBox集成了上百个常用Unix命令（ls, cp, mount等）到一个单一可执行文件中，非常适合构建极度精简的根文件系统。

# 1. 下载并编译BusyBox wget https://busybox.net/downloads/busybox-1.36.1.tar.bz2 tar -xf busybox-1.36.1.tar.bz2 cd busybox-1.36.1 make CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH} defconfig # 进入菜单配置，确保选中“Build static binary (no shared libs)”，这样编译出的BusyBox不依赖动态库，更简单。 make CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH} menuconfig make CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH} -j$(nproc} make CROSS_COMPILE=${CROSS_COMPILE} ARCH=${ARCH} install

编译安装后，会在_install目录下生成基本的bin,sbin,usr目录以及指向BusyBox的链接。

# 2. 创建根文件系统目录结构 mkdir -p rootfs_busybox/{bin,dev,etc,home,lib,proc,root,sbin,sys,tmp,usr/{bin,lib},var} # 3. 复制BusyBox cp -r busybox-1.36.1/_install/* rootfs_busybox/ # 4. 创建设备节点（内核启用devtmpfs后，大部分可自动创建，但console和null最好有） sudo mknod rootfs_busybox/dev/console c 5 1 sudo mknod rootfs_busybox/dev/null c 1 3 # 5. 添加基本的初始化脚本 /etc/inittab 和 /etc/init.d/rcS # ... (具体脚本内容略，需配置启动shell等)

BusyBox方案更底层，需要手动配置更多东西，但生成的系统尺寸可以非常小（几MB）。

实操心得：对于学习和快速原型，推荐使用方法A（debootstrap）。它虽然比BusyBox大一些（可能几百MB），但带来了完整的包管理器和丰富的软件生态，后续开发调试会方便很多。你可以先做一个“胖”系统把流程跑通，再考虑如何裁剪。

5. SD卡分区与镜像部署实战

这是最关键的“组装”环节。我们需要将SD卡（在宿主机上通常识别为/dev/sdX，例如/dev/sdb）进行分区，并将准备好的组件放入正确的位置。

警告：以下操作会清空指定磁盘的所有数据，请务必确认设备标识符（/dev/sdX）是你的SD卡，而不是你的硬盘！

5.1 分区规划

一个典型的可启动SD卡布局如下：

  • 第一个分区（FAT32）： 通常很小（几十到几百MB），用于存放Bootloader、内核镜像（Image/zImage）、设备树文件（.dtb）以及可能的启动配置文件（如U-Boot的boot.scr或树莓派的config.txt）。这个分区之所以用FAT32，是因为很多SoC的Boot ROM只支持读取FAT文件系统。
  • 第二个分区（EXT4）： 剩余的全部空间，用于存放根文件系统。

我们使用parted工具进行分区：

# 假设SD卡是 /dev/sdb sudo parted /dev/sdb --script mklabel msdos # 创建MBR分区表（对于大多数嵌入式板子） sudo parted /dev/sdb --script mkpart primary fat32 1MiB 256MiB # 创建256MB的FAT32分区 sudo parted /dev/sdb --script mkpart primary ext4 256MiB 100% # 剩余空间创建EXT4分区 sudo parted /dev/sdb --script set 1 boot on # 将第一个分区标记为可启动（某些Bootloader需要）

然后，在两个分区上创建文件系统：

sudo mkfs.vfat -F 32 -n BOOT /dev/sdb1 sudo mkfs.ext4 -L ROOTFS /dev/sdb2

5.2 部署组件

挂载分区：

mkdir -p /mnt/boot /mnt/rootfs sudo mount /dev/sdb1 /mnt/boot sudo mount /dev/sdb2 /mnt/rootfs

复制Bootloader： 对于U-Boot，需要将编译好的二进制文件写入SD卡起始扇区，而不仅仅是复制到分区里。这通常使用dd命令。具体写入位置取决于硬件。有些平台需要先写SPL，再写U-Boot。

# 示例：将U-Boot写入SD卡起始位置（偏移量为0）。请务必查阅你的开发板文档！ # sudo dd if=u-boot-spl.bin of=/dev/sdb bs=1k seek=1 conv=fsync # 可能需要先写SPL sudo dd if=u-boot.bin of=/dev/sdb bs=1k seek=64 conv=fsync # 常见的写入偏移

重要：dd命令的seek（跳过多少块）参数因平台而异，错误的值会导致无法启动。请务必参考官方文档。

复制内核与设备树到BOOT分区：

sudo cp /path/to/linux/arch/arm64/boot/Image /mnt/boot/ sudo cp /path/to/linux/arch/arm64/boot/dts/rockchip/rk3568-evb.dtb /mnt/boot/ # 以实际板型dtb为准 # 如果需要，创建U-Boot启动脚本 boot.scr # echo "load mmc 0:1 ${kernel_addr_r} /Image; load mmc 0:1 ${fdt_addr_r} /rk3568-evb.dtb; booti ${kernel_addr_r} - ${fdt_addr_r}" > boot.cmd # mkimage -A arm64 -O linux -T script -C none -d boot.cmd boot.scr # sudo cp boot.scr /mnt/boot/

复制根文件系统到ROOTFS分区：

sudo cp -a /path/to/your/rootfs/* /mnt/rootfs/ # 如果是使用debootstrap构建的，并且编译了内核模块，需要安装模块 cd /path/to/linux sudo make ARCH=arm64 INSTALL_MOD_PATH=/mnt/rootfs modules_install

清理与卸载：

sync # 确保所有数据写入磁盘 sudo umount /mnt/boot /mnt/rootfs

6. 上电启动与调试

将SD卡插入开发板，连接串口调试线（通常是USB转TTL，连接板子的UART引脚）到电脑，使用串口终端工具（如minicom,picocom,screen或Windows下的Putty、MobaXterm）打开对应的串口（如/dev/ttyUSB0），设置波特率（常见115200）。

给开发板上电。在串口终端中，你应该能看到U-Boot的启动日志，然后是内核解压和启动的信息。如果一切顺利，最终会看到登录提示符。

6.1 常见启动问题与排查

启动过程很少一帆风顺，以下是几个经典“坑位”及排查思路：

  1. 无任何输出（串口一片寂静）：

    • 检查硬件连接：串口线是否接对（TX-RX交叉，GND相连）？波特率设置是否正确？
    • 检查Bootloader是否成功写入：用dd命令写入U-Boot时，seek参数是否正确？可以用hexdump -C /dev/sdb | head -100查看SD卡头部是否有U-Boot的魔数或字符串。
    • 检查启动介质：开发板是否配置为从SD卡启动？有些板子需要通过拨码开关或eFuse设置启动顺序。

  2. U-Boot启动后卡住，不加载内核：

    • 检查U-Boot环境变量：在U-Boot倒计时时按任意键进入命令行，使用printenv查看bootcmd,bootargs等变量。确保bootcmd能正确找到内核和设备树文件（路径、设备号如mmc 0:1）。
    • 检查文件是否存在：在U-Boot命令行下，可以尝试使用fatls mmc 0:1列出BOOT分区文件，确认Image和.dtb文件存在。
    • 手动加载启动：在U-Boot命令行下，尝试手动执行加载和启动命令，观察错误信息。
      # 示例 setenv bootargs console=ttyS2,115200 earlycon root=/dev/mmcblk0p2 rootwait rw load mmc 0:1 ${kernel_addr_r} /Image load mmc 0:1 ${fdt_addr_r} /rk3568-evb.dtb booti ${kernel_addr_r} - ${fdt_addr_r}

  3. 内核panic，无法挂载根文件系统：

    • 检查root=参数：bootargs中的root=指定了根文件系统所在设备。/dev/mmcblk0p2对应SD卡的第二个分区。确认分区号是否正确。
    • 检查文件系统类型：内核是否编译了对应文件系统（如EXT4）的支持？在menuconfig中确认CONFIG_EXT4_FS=y。
    • 检查根文件系统完整性：确保/mnt/rootfs下的文件复制完整，特别是/sbin/init或指向/lib/systemd/systemd的链接存在且可执行。
    • 启用更早的console：在bootargs中添加earlycon和earlyprintk，可以看到更早的内核输出，有助于定位panic发生的位置。

  4. 内核启动后卡在“Starting kernel ...”或类似地方：

    • 设备树不匹配：这是最常见的原因之一。.dtb文件与你的实际硬件不匹配。请确认你使用的设备树文件是否完全对应你的开发板型号（包括内存大小、外设地址等）。尝试使用最接近的板型dtb，或从供应商获取正确的dts源文件自行编译。
    • 内存地址问题：U-Boot传递给内核的fdt_addr_r是否在有效的RAM地址范围内？设备树本身是否描述了正确的内存大小和地址？

6.2 调试利器：U-Boot下的网络与TFTP

当需要频繁更新内核或设备树进行调试时，反复插拔SD卡非常低效。可以通过网络（TFTP）来加载镜像。

  1. 宿主机搭建TFTP服务器：

    sudo apt install tftpd-hpa sudo systemctl start tftpd-hpa # 默认目录是 /var/lib/tftpboot， 将你的Image和.dtb文件放进去 sudo cp Image rk3568-evb.dtb /var/lib/tftpboot/

  2. 配置开发板网络：

    • 确保开发板和宿主机在同一局域网。
    • 在U-Boot中设置网络环境变量（也可以在编译U-Boot时预设）：
      setenv ipaddr 192.168.1.100 # 开发板IP setenv serverip 192.168.1.50 # 宿主机（TFTP服务器）IP setenv netmask 255.255.255.0 # 保存环境变量 saveenv

  3. 通过TFTP加载并启动：

    # 在U-Boot命令行下 tftp ${kernel_addr_r} Image tftp ${fdt_addr_r} rk3568-evb.dtb setenv bootargs console=ttyS2,115200 root=/dev/mmcblk0p2 rw booti ${kernel_addr_r} - ${fdt_addr_r}

    这样，每次修改内核后，只需在宿主机重新编译并复制到TFTP目录，然后在U-Boot中重新tftp加载即可，极大提升调试效率。

7. 进阶优化与生产考量

当你成功制作出第一个能启动的镜像后，可以考虑以下优化，让系统更贴近产品需求。

7.1 内核裁剪与优化

使用make menuconfig进入内核配置，目标是减小内核体积和内存占用，并针对特定硬件启用优化。

  • 移除无用驱动：去掉你的板子上没有的硬件驱动（如其他型号的GPU、声卡、网络芯片驱动）。
  • 精简文件系统：只保留你需要的文件系统类型（如EXT4, SQUASHFS）。
  • 关闭调试功能：生产环境可以关闭CONFIG_DEBUG_INFO,CONFIG_DEBUG_KERNEL等，能显著减小内核大小。
  • 优化CPU调度与电源管理：根据你的CPU架构，选择对应的调度器（如CONFIG_SCHED_MUQSS用于低延迟）和CPU频率调节器（如CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND）。

7.2 根文件系统精简

对于debootstrap构建的系统，可以移除不需要的包和文档。

# 在chroot环境中进行 apt-get clean # 清理包缓存 # 移除不需要的包，例如不需要的locale、文档、开发包 apt-get purge -y `deborphan` # 删除孤立库（谨慎使用） # 删除 man pages, info pages, doc rm -rf /usr/share/man/* /usr/share/info/* /usr/share/doc/* # 清理日志和临时文件 find /var/log -type f -exec truncate -s 0 {} \; rm -rf /tmp/* /var/tmp/*

7.3 创建可分发系统镜像文件

为了方便备份和分发，我们可以将整个SD卡的内容打包成一个.img文件。

# 1. 计算SD卡总大小（假设是16GB） IMG_SIZE=$((16 * 1024 * 1024 * 1024)) # 字节 # 2. 创建一个空镜像文件 dd if=/dev/zero of=my_embedded_system.img bs=1M count=$((IMG_SIZE / 1024 / 1024)) # 3. 在镜像文件上分区并格式化（使用类似第5.1节的parted和mkfs命令，但针对的是镜像文件，如 /dev/loop0） sudo losetup -fP my_embedded_system.img # 假设回环设备是 /dev/loop0 sudo parted /dev/loop0 ... sudo mkfs.vfat /dev/loop0p1 sudo mkfs.ext4 /dev/loop0p2 # 4. 挂载镜像文件的分区 sudo mount /dev/loop0p1 /mnt/boot sudo mount /dev/loop0p2 /mnt/rootfs # 5. 将你SD卡上已部署好的内容（或重新部署）复制进去 sudo cp -r /path/to/your/boot_contents/* /mnt/boot/ sudo rsync -a /path/to/your/rootfs/ /mnt/rootfs/ # 6. 卸载、分离回环设备 sudo umount /mnt/boot /mnt/rootfs sudo losetup -d /dev/loop0

现在，my_embedded_system.img就是一个完整的、可以直接用dd或balenaEtcher等工具烧录到任何同容量或更大容量SD卡中的系统镜像。

7.4 自动化构建脚本

将上述所有步骤（获取源码、配置、编译、分区、部署）编写成一个Shell脚本（如build.sh），是实现一键构建、保证环境可复现的最佳实践。脚本中应包含各种参数的配置（如工具链路径、目标板型号、内核版本等），并做好错误检查。这是从“手工制作”迈向“工程化”的关键一步。

整个流程走下来，你会发现制作一个嵌入式Linux系统镜像远不止是运行几条命令。它贯穿了硬件启动原理、软件编译工具链、系统组成结构、存储介质管理和实际调试排错。每一次失败和解决的过程，都是对“系统如何工作”这一问题的深刻理解。当你最终看到串口终端上出现那个熟悉的登录提示符时，这份完全由自己构建起来的系统所带来的成就感和掌控感，是使用现成镜像无法比拟的。这不仅是完成了一个任务，更是打通了嵌入式Linux开发任督二脉的关键一步。