从零移植 Linux 到 ARM 开发板，需要做哪些事？
把 Linux 移植到一块新的 ARM 开发板上，最容易被低估的地方，不是某个命令怎么敲，也不是内核菜单里某个选项怎么选，而是“这块板子到底要从哪里开始被系统认识”。硬件上电以后，CPU、DDR、存储、串口、时钟、电源、设备树、驱动、根文件系统，每一环都必须接上。少一环，现象可能只是串口没输出；错一环，系统可能能启动但长期不稳定。
这类工作更像一条工程链路：先让板子能稳定启动，再让内核正确描述硬件，再把外设逐个拉起来，最后把镜像、日志、问题记录和交付物整理成可复现的版本。下面按这个节奏拆开讲。
一、Linux 移植不是只编译一个内核
很多人刚接触移植时，会把目标简化成“交叉编译 Linux kernel”。这句话没错，但只覆盖了中间一段。真正能跑起来的板级 Linux，至少包含六类工作：确认硬件平台、打通启动链路、适配内核、描述设备树、构建 RootFS、完成调试交付。
1.1 先确认硬件边界
移植开始前要拿到 SoC 型号、板级原理图、DDR 型号、Flash/eMMC/SD 启动方式、晶振频率、电源时序、调试串口和常用外设连接。没有这些信息，后面很多问题只能靠猜。比如串口波特率不对、DDR 初始化参数不匹配、eMMC 分区偏移错误，都会让系统表现得像“内核坏了”，但根因其实在更早的位置。
1.2 交付物不只是 zImage
一个可交付的 Linux 移植包通常包括 Bootloader、内核镜像、设备树、根文件系统、烧录脚本、分区表、配置文件、版本记录和测试说明。工程上要追求的是别人拿到同一套输入，也能构建出同一套输出。
●●●# 固定工具链路径，避免不同终端使用到不同版本
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
# 保存默认配置，后续修改都要能追溯
make myboard_defconfig
# 同时构建内核镜像、设备树和模块
make -j8 zImage dtbs modules
二、启动链路要从上电顺序开始看
ARM 板子的启动通常不是内核直接运行。更常见的路径是 BootROM 先执行 SoC 内部固化代码，随后加载 SPL，SPL 初始化 DDR，再加载 U-Boot，U-Boot 负责加载内核、设备树和根文件系统参数。内核起来以后，才进入用户态初始化流程。
2.1 串口输出是最早的生命体征
移植早期，串口日志比屏幕、网络、文件系统都重要。能看到 BootROM 或 U-Boot 输出，说明供电、晶振、启动介质、串口复用至少有一部分是通的。若连 SPL 都没有日志，就应该先查启动拨码、烧录偏移、DDR 初始化和串口引脚复用，而不是急着改内核。
2.2 U-Boot 负责把启动条件交给内核
U-Boot 的关键职责包括加载内核镜像、加载 dtb、准备 bootargs，并把控制权交给内核入口。这里最常见的问题是地址冲突、设备树路径错误、根文件系统参数不正确。
●●●# 查看当前启动参数，确认 root、console、init 等字段
printenv bootargs
# 手工加载内核和设备树，便于定位自动启动脚本问题
fatload mmc 0:10x82000000 zImage
fatload mmc 0:10x83000000 myboard.dtb
bootz 0x82000000 - 0x83000000
2.3 先稳定启动，再扩展功能
移植工作不要一开始就追求所有外设齐活。建议先把最小闭环跑通：串口可用、内核能解压、设备树能加载、RootFS 能挂载、用户态能进入 shell。这个闭环稳定以后，再逐步增加网口、显示、USB、音频、摄像头等复杂外设。
三、板级适配的核心是让软件正确理解硬件
Linux 内核并不会天然知道你的板子怎么连线。SoC 驱动可能已经存在，但板级差异要靠设备树、内核配置和少量驱动适配来表达。这里的重点不是“写很多代码”，而是把硬件资源描述准确。
3.1 设备树是板级信息的入口
设备树里要描述 CPU、内存、时钟、pinctrl、GPIO、I2C、SPI、UART、MMC、Ethernet 等资源。一个外设驱动能否 probe 成功，往往取决于 compatible、reg、中断、时钟、复位、引脚复用这些字段是否匹配。
●●●/* UART 节点示例：先保证调试串口稳定可用 */
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins>;
status = "okay";
};
/* eMMC 节点示例：启动介质相关参数要和硬件一致 */
&mmc0 {
bus-width = <8>;
non-removable;
status = "okay";
};
3.2 驱动适配要先看绑定关系
驱动不工作时，不要直接怀疑驱动主体逻辑。更高效的顺序是：确认设备树节点存在，确认 compatible 能匹配驱动表，确认时钟和复位打开，确认 pinctrl 生效，确认 probe 日志。很多问题其实停在“驱动根本没绑定”。
●●●/* probe 里先打印关键资源，方便确认设备树是否传入正确 */
staticint mydev_probe(struct platform_device *pdev)
{
struct resource *res;
/* 读取寄存器资源，失败说明设备树 reg 字段要先检查 */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -EINVAL;
dev_info(&pdev->dev, "resource start=%pa size=%pa\n",
&res->start, &resource_size(res));
return0;
}
3.3 外设验证要从低复杂度开始
建议按 UART、GPIO、I2C/SPI、MMC、Ethernet、USB、Display、Camera 的顺序推进。原因很简单：低复杂度外设能帮你验证 pinctrl、时钟、中断和基础驱动框架；复杂外设依赖链更长，过早处理会把问题混在一起。
四、移植完成的标准是可复现、可定位、可交付
能启动一次不等于移植完成。真正可用的板级 Linux，需要经得起断电重启、长时间运行、外设压力、异常恢复和版本复现。这个阶段要把调试方式工程化，而不是靠临时命令堆经验。
4.1 启动日志要形成基线
每次内核、设备树、Bootloader 或 RootFS 变更，都应该保存启动日志。日志里重点看内核命令行、内存布局、设备树加载、驱动 probe、RootFS 挂载、用户态初始化。出现回归时，基线日志能迅速缩小范围。
4.2 常见问题要按链路定位
启动卡住，先判断停在 Bootloader、内核解压、驱动初始化还是用户态；RootFS 挂载失败，先看 root 参数、文件系统格式、驱动是否内建；驱动 probe 失败，先看 compatible、资源、中断、时钟和电源域；性能抖动，则要关注频率、DMA、中断负载、缓存和调度。
●●●# 保存完整内核日志，便于和历史版本做差异对比
dmesg -T > boot-$(date +%Y%m%d-%H%M%S).log
# 查看驱动是否绑定到预期设备
find /sys/bus/platform/drivers -maxdepth 2 -type l | sort
# 检查根文件系统挂载和空间情况
mount
df -h
4.3 交付清单决定后续维护成本
最终建议至少归档这些内容：源码仓库 commit、工具链版本、构建命令、Bootloader 配置、kernel defconfig、设备树文件、RootFS 制作脚本、烧录说明、测试报告、已知问题列表。缺少这些，后续换人维护或者升级内核时，很容易重新踩坑。
五、总结
从零移植 Linux 到 ARM 开发板，本质上是把硬件事实逐层翻译成软件可执行的配置和代码：启动链路负责把 CPU 带到内核入口，设备树负责描述板级资源，驱动负责把资源变成能力，RootFS 负责承接用户态，测试和归档负责让结果可复现。
最稳的推进方式是小步闭环：先串口，再 Bootloader，再内核，再 RootFS，再外设，再压力测试。每一步都留下配置、日志和版本记录。这样做看起来慢，但它能让问题有边界，让移植工作从“玄学点灯”变成可交付的工程流程。
