第1章 系统移植概述：嵌入式系统移植的定义与目标、交叉编译环境搭建、Bootloader与内核的关系
各位同学，咱们今天聊聊系统移植。说实话，我刚入行那会儿，觉得移植就是把代码换个平台重新编译一遍。后来被现实狠狠教育了一次——那次项目 deadline 前三天，板子死活起不来，最后发现是 Bootloader 里一个内存映射配错了。从那以后，我才真正理解什么叫「移植不是搬运，是重构」。
1.1 嵌入式系统移植的定义与目标
什么叫系统移植？说白了，就是把一套软件系统从一个硬件平台搬到另一个硬件平台上运行。你想想看，同样是 ARM Cortex-A7，全志的芯片和 NXP 的芯片，外设寄存器地址、时钟树、中断控制器完全不一样。代码不能直接跑，就得移植。
移植的核心目标有三个：
- 功能完整：新平台上所有硬件模块都能被正确驱动
- 性能达标：实时性、吞吐量、功耗满足产品规格
- 可维护性：移植后的代码要方便后续升级和复用
我个人的经验法则：移植工作 60% 的时间花在硬件抽象层（HAL）的适配，30% 花在 Bootloader 和内核的启动流程调试，剩下 10% 才是应用层的修改。很多新手把顺序搞反了，上来就改应用代码，结果底层一换全白干。
1.2 交叉编译环境搭建
嵌入式开发离不开交叉编译。为什么？因为你的开发机是 x86 架构，目标板是 ARM/MIPS/RISC-V，两种指令集不同，没法直接在 PC 上编译出能在板子上跑的程序。
搭建交叉编译环境，我建议按这个步骤来：
- 选择工具链：根据芯片厂商推荐来。我用过 Linaro GCC、ARM GCC、Buildroot 生成的工具链，各有优劣。
- 设置环境变量：把工具链的 bin 目录加到 PATH 里，设置 CC、CXX、LD 等变量。
- 验证工具链：写一个 Hello World，用交叉编译器编译，然后在目标板上运行。
一个小技巧：我习惯在项目根目录下放一个 setenv.sh 脚本，每次打开终端先 source 一下。这样不会污染全局环境，多个项目切换也方便。
下面是一个典型的交叉编译环境配置示例：
#!/bin/bash
# 交叉编译环境配置脚本
export CROSS_COMPILE=arm-linux-gnueabihf-
export CC=${CROSS_COMPILE}gcc
export CXX=${CROSS_COMPILE}g++
export LD=${CROSS_COMPILE}ld
export AR=${CROSS_COMPILE}ar
export OBJCOPY=${CROSS_COMPILE}objcopy
export SYSROOT=/opt/arm-sysroot
export CFLAGS="--sysroot=$SYSROOT -march=armv7-a -mfpu=neon"
export LDFLAGS="--sysroot=$SYSROOT"
echo "交叉编译环境已就绪: $CROSS_COMPILE"我曾经踩过的坑：工具链的 glibc 版本必须和目标板上的根文件系统一致。有一次我用了高版本 glibc 编译的程序，放到老版本根文件系统的板子上，运行时直接报 FATAL: kernel too old。折腾了两天才找到原因。
1.3 Bootloader 与内核的关系
Bootloader 和内核的关系，我经常用这个比喻：Bootloader 是「引路人」，内核是「管理者」。引路人把管理者请到台上，交接完权力就退场了。
具体来说，Bootloader 要做这几件事：
- 初始化硬件（时钟、DDR、串口、存储控制器）
- 从存储介质（NAND Flash、eMMC、SD 卡）加载内核镜像
- 解压内核（如果是压缩镜像）
- 设置内核启动参数（设备树、cmdline）
- 跳转到内核入口点，把控制权交给内核
内核启动后，Bootloader 就完成了使命。内核会重新初始化所有硬件，建立完整的内存管理、进程调度、文件系统等机制。
下面这张图展示了从 Bootloader 到内核的完整启动流程：
从图中可以看到，Bootloader 分为两个阶段。第一阶段（SPL/MLO）非常精简，由芯片固化的 ROM 代码加载，主要负责初始化 DDR 和加载第二阶段的完整 Bootloader。第二阶段（通常是 U-Boot）才是我们常说的 Bootloader，它提供命令行交互、网络下载、文件系统支持等功能。
核心要点：Bootloader 和内核之间通过「设备树」（Device Tree）和「内核命令行」（cmdline）传递信息。设备树描述硬件拓扑，cmdline 传递启动参数。这两个东西一旦配错，内核要么起不来，要么找不到关键外设。
1.4 系统移植的关键决策点
做移植时，有几个决策点直接影响项目成败：
| 决策项 | 选项 | 我的建议 |
|---|---|---|
| Bootloader 选择 | U-Boot / Barebox / 自研 | 除非有特殊需求，否则用 U-Boot。社区支持好，资料多 |
| 内核版本 | LTS / 最新主线 / 厂商 BSP | 量产项目用 LTS，原型验证用厂商 BSP |
| 设备树 vs 板级文件 | DTB / board.c | 新项目一律用设备树，别再写板级文件了 |
| 根文件系统 | Buildroot / Yocto / 手动构建 | 小项目用 Buildroot，大项目用 Yocto |
我曾经犯过的错：在一个量产项目中，我为了省事直接用了厂商 BSP 里的内核，没仔细看版本号。结果产品上市半年后，发现一个内核安全漏洞，但厂商 BSP 的内核版本太老，社区已经不维护了。最后不得不花两个月做内核版本升级。从那以后，我坚持用 LTS 内核，哪怕前期适配工作多一些。
1.5 本章小结
系统移植不是简单的代码搬运，而是对硬件、Bootloader、内核三者关系的深刻理解。交叉编译环境是基础，搭不好后面全是坑。Bootloader 和内核的交接是移植中最容易出问题的环节，设备树和 cmdline 必须反复核对。