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

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”的板子其Bootloaderbootcode.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 rsyncbuild-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架构的可执行文件。获取方式从芯片厂商或开发板供应商获取这是最推荐的方式。例如NXP i.MX系列提供gcc-arm-none-eabiRockchip提供专门的工具链。它们通常针对自家芯片的微架构如Cortex-A53, A72做过优化。从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 ARCHarm64将最后两行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-Bootgit clone https://github.com/u-boot/u-boot.git cd u-boot # 切换到稳定版本分支如 v2024.01 git checkout v2024.01配置与编译 U-Boot针对不同的板子有预置的配置文件位于configs/目录下通常以_defconfig结尾。例如对于树莓派3BBCM2837# 对于树莓派我们通常使用其自带的闭源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可能包含头部信息的镜像。对于需要SPLSecondary 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 ARCHarm64 defconfig生成一个极简配置或make ARCHarm64 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 --archarm64 --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。实操心得对于学习和快速原型推荐使用方法Adebootstrap。它虽然比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/sdb25.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 ifu-boot-spl.bin of/dev/sdb bs1k seek1 convfsync # 可能需要先写SPL sudo dd ifu-boot.bin of/dev/sdb bs1k seek64 convfsync # 常见的写入偏移重要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 ARCHarm64 INSTALL_MOD_PATH/mnt/rootfs modules_install清理与卸载sync # 确保所有数据写入磁盘 sudo umount /mnt/boot /mnt/rootfs6. 上电启动与调试将SD卡插入开发板连接串口调试线通常是USB转TTL连接板子的UART引脚到电脑使用串口终端工具如minicom,picocom,screen或Windows下的Putty、MobaXterm打开对应的串口如/dev/ttyUSB0设置波特率常见115200。给开发板上电。在串口终端中你应该能看到U-Boot的启动日志然后是内核解压和启动的信息。如果一切顺利最终会看到登录提示符。6.1 常见启动问题与排查启动过程很少一帆风顺以下是几个经典“坑位”及排查思路无任何输出串口一片寂静检查硬件连接串口线是否接对TX-RX交叉GND相连波特率设置是否正确检查Bootloader是否成功写入用dd命令写入U-Boot时seek参数是否正确可以用hexdump -C /dev/sdb | head -100查看SD卡头部是否有U-Boot的魔数或字符串。检查启动介质开发板是否配置为从SD卡启动有些板子需要通过拨码开关或eFuse设置启动顺序。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 consolettyS2,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}内核panic无法挂载根文件系统检查root参数bootargs中的root指定了根文件系统所在设备。/dev/mmcblk0p2对应SD卡的第二个分区。确认分区号是否正确。检查文件系统类型内核是否编译了对应文件系统如EXT4的支持在menuconfig中确认CONFIG_EXT4_FSy。检查根文件系统完整性确保/mnt/rootfs下的文件复制完整特别是/sbin/init或指向/lib/systemd/systemd的链接存在且可执行。启用更早的console在bootargs中添加earlycon和earlyprintk可以看到更早的内核输出有助于定位panic发生的位置。内核启动后卡在“Starting kernel ...”或类似地方设备树不匹配这是最常见的原因之一。.dtb文件与你的实际硬件不匹配。请确认你使用的设备树文件是否完全对应你的开发板型号包括内存大小、外设地址等。尝试使用最接近的板型dtb或从供应商获取正确的dts源文件自行编译。内存地址问题U-Boot传递给内核的fdt_addr_r是否在有效的RAM地址范围内设备树本身是否描述了正确的内存大小和地址6.2 调试利器U-Boot下的网络与TFTP当需要频繁更新内核或设备树进行调试时反复插拔SD卡非常低效。可以通过网络TFTP来加载镜像。宿主机搭建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/配置开发板网络确保开发板和宿主机在同一局域网。在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通过TFTP加载并启动# 在U-Boot命令行下 tftp ${kernel_addr_r} Image tftp ${fdt_addr_r} rk3568-evb.dtb setenv bootargs consolettyS2,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 ofmy_embedded_system.img bs1M 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开发任督二脉的关键一步。