从 x86 到 ARM：一次真实的 Linux 发行版跨架构移植实践

最近接手了一个项目——要把我们内部维护的一个基于 Debian 的定制 Linux 系统，从传统的amd64（x86-64）平台完整迁移到arm64（AArch64）架构上，跑在一块搭载 Rockchip RK3399 的开发板上。起初我以为只是换个编译器的事，结果第一轮构建失败就打了我一个措手不及：内核启动卡死、用户空间init找不到、串口输出一堆乱码。

这才意识到，这不是简单的“重新编译”，而是一次彻头彻尾的系统级重构。整个过程涉及工具链、内核、设备树、根文件系统、引导程序等多层协同，稍有疏漏就会导致系统无法启动。经过两周踩坑和调试，终于跑通了第一个可用镜像。今天我就把这套完整的移植流程梳理一遍，不讲空话，只说实战中真正用得上的东西。

一、先搞清楚：x86 和 ARM 到底差在哪？

很多人以为 amd64 和 arm64 只是 CPU 不同，其实它们从底层设计哲学就开始分道扬镳。

这些差异意味着：

• 不能直接运行二进制文件：你在 x86 上编译的.deb包，在 ARM 上根本跑不动。
• 代码行为可能不同：尤其是涉及原子操作或多线程同步时，弱内存序可能导致数据竞争。
• 硬件初始化方式完全不同：x86 有 BIOS/ACPI 自动探测设备；ARM 靠设备树（Device Tree）显式描述硬件。

所以移植的本质不是“迁移”，而是“重建”——用同一套源码，在新架构上重新构建整套系统。

✅关键认知：跨架构 ≠ 跨操作系统。Linux 内核早已支持多架构，但每一层都需要针对目标平台重新适配。

二、第一步：搭好交叉编译环境

要在 x86 主机上生成 ARM 程序，必须使用交叉编译工具链。这是整个流程的地基。

安装标准 GNU 工具链（Ubuntu/Debian）

sudo apt update sudo apt install \ gcc-aarch64-linux-gnu \ g++-aarch64-linux-gnu \ binutils-aarch64-linux-gnu \ libc6-dev-arm64-cross

安装后你会得到几个关键命令：
-aarch64-linux-gnu-gcc：ARM64 编译器
-aarch64-linux-gnu-ld：链接器
-aarch64-linux-gnu-as：汇编器

测试是否正常工作

写个最简单的程序试试：

// hello.c #include <stdio.h> int main() { printf("Hello from ARM64!\n"); return 0; }

编译并检查输出格式：

aarch64-linux-gnu-gcc -o hello_arm64 hello.c file hello_arm64

输出应该是：

hello_arm64: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked...

如果看到ARM aarch64，说明工具链没问题。

⚠️坑点提醒：某些发行版（如 Alpine）使用 musl libc 而非 glibc。如果你的目标系统是 Alpine，要选择aarch64-linux-musl工具链，否则动态库会不兼容。

三、第二步：编译适合 ARM 的 Linux 内核

Linux 内核是平台相关的。虽然代码是通用的，但必须为 arm64 架构单独编译。

获取内核源码

git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git cd linux make ARCH=arm64 defconfig

这里ARCH=arm64是重点，告诉构建系统目标架构是 ARM64。

选择合适的配置

对于通用虚拟平台，可以用：

make ARCH=arm64 virt_defconfig

如果是具体开发板（比如树莓派 4），厂商通常会提供.config文件或 DTS 支持。

编译内核与设备树

make -j$(nproc) \ ARCH=arm64 \ CROSS_COMPILE=aarch64-linux-gnu- \ Image dtbs

成功后你会得到两个关键产物：
-arch/arm64/boot/Image：内核镜像
-arch/arm64/boot/dts/rockchip/rk3399.dtb：设备树 blob（DTB）

🔍为什么设备树这么重要？
在 x86 上，BIOS 会自动告诉内核有哪些串口、多少内存、PCI 设备在哪。但在 ARM 上，这一切都靠设备树来声明。如果 DTB 错了，哪怕只是 GPIO 编号差一位，系统也可能起不来。

四、第三步：构建 arm64 根文件系统（rootfs）

这是最容易出问题的一环。你需要在一个 x86 主机上，创建一个能被 ARM CPU 启动的完整用户空间。

使用 debootstrap 创建 Debian rootfs

sudo debootstrap \ --arch=arm64 \ --foreign \ bullseye \ /mnt/arm64-root \ http://deb.debian.org/debian

注意--foreign参数：它表示这是一个跨架构安装，只会下载基础包，不会立即配置。

借助 QEMU 实现跨架构 chroot

为了让后续脚本能运行（比如 postinst 脚本），我们需要让系统“假装”能执行 ARM 程序。这就是qemu-user-static的作用。

sudo apt install qemu-user-static binfmt-support sudo cp /usr/bin/qemu-aarch64-static /mnt/arm64-root/usr/bin/

现在可以进入 chroot 环境完成第二阶段安装：

sudo chroot /mnt/arm64-root /debootstrap/debootstrap --second-stage

这个命令会在模拟的 ARM 环境中解压所有.deb包，并运行安装脚本。

配置基本系统

进入 chroot 后做一些必要设置：

sudo chroot /mnt/arm64-root # 设置主机名 echo "armbox" > /etc/hostname # 配置 fstab cat >> /etc/fstab << EOF /dev/mmcblk0p2 / ext4 defaults 0 1 /dev/mmcblk0p1 /boot/vmlinuz vfat defaults 0 2 EOF # 设置 root 密码 passwd root # 安装必要软件 apt update apt install systemd-sysv bash network-manager ssh locales # 退出 chroot exit

💡技巧：建议先做最小系统，确认能启动后再装图形界面或其他服务。

五、第四步：准备引导程序 U-Boot

ARM 没有 BIOS，启动靠的是U-Boot或EFI stub。我们以更通用的 U-Boot 为例。

编译 U-Boot

git clone https://source.denx.de/u-boot/u-boot.git cd u-boot # 选择对应开发板的配置 make rk3399_defconfig make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu-

生成的u-boot.bin需要烧录到存储介质特定位置（通常是偏移 64 扇区）。

配置启动参数

U-Boot 启动时读取环境变量决定如何加载系统。常用设置如下：

setenv bootargs "console=ttyS2,115200 root=/dev/mmcblk0p2 rootwait" setenv bootcmd "load mmc 0:1 $kernel_addr_r Image; load mmc 0:1 $fdt_addr_r rk3399.dtb; booti $kernel_addr_r - $fdt_addr_r" saveenv

解释一下：
-console=：指定串口控制台（RK3399 通常是 ttyS2）
-root=：根文件系统所在分区
-booti：启动 AArch64 内核的命令

六、第五步：合成最终镜像并部署

现在我们有了四样东西：
1. U-Boot (u-boot.bin)
2. 内核镜像 (Image)
3. 设备树 (rk3399.dtb)
4. 根文件系统 (/mnt/arm64-root)

接下来把它们打包成一张 SD 卡镜像。

创建磁盘镜像

# 创建一个 2GB 的空白镜像 dd if=/dev/zero of=arm64-image.img bs=1M count=2048 # 分区：s1（FAT32 引导），s2（ext4 根） parted arm64-image.img mklabel msdos parted arm64-image.img mkpart primary fat32 4MB 100MB parted arm64-image.img mkpart primary ext4 100MB 100%

挂载并写入内容

# 关联 loop 设备 losetup -fP arm64-image.img # 查看分配的设备名（如 /dev/loop0） export LOOPDEV=$(losetup -j arm64-image.img | cut -d: -f1) # 格式化分区 mkfs.vfat ${LOOPDEV}p1 mkfs.ext4 ${LOOPDEV}p2 # 挂载 mkdir -p /tmp/boot /tmp/root mount ${LOOPDEV}p1 /tmp/boot mount ${LOOPDEV}p2 /tmp/root

写入各组件

# 写入 U-Boot（跳过 MBR，写入 SPL 区域） dd if=u-boot/u-boot.bin of=${LOOPDEV} seek=64 conv=notrunc # 写入内核和 DTB cp linux/arch/arm64/boot/Image /tmp/boot/ cp linux/arch/arm64/boot/dts/rockchip/rk3399.dtb /tmp/boot/ # 写入 rootfs rsync -aHAXxSP /mnt/arm64-root/ /tmp/root/

卸载并烧录

umount /tmp/boot /tmp/root losetup -d ${LOOPDEV} # 烧录到 SD 卡（假设为 /dev/sdb） sudo dd if=arm64-image.img of=/dev/sdb bs=4M status=progress sync

七、第六步：上板调试，看能不能活过来

插上 SD 卡，接好串口线（115200-8-N-1），打开 minicom 或 screen：

screen /dev/ttyUSB0 115200

观察启动日志。常见问题及排查方法：

🛠️调试建议：
- 开启earlyprintk和loglevel=8查看详细日志；
- 使用init=/bin/sh进入紧急 shell 检查环境；
- 优先保证串口输出可用，这是唯一的“生命线”。

八、进阶技巧：自动化与可持续构建

手动操作一遍就够了，生产环境一定要自动化。

写个 Makefile 统一管理

KERNEL_VER := 6.1.75 UBOOT_VER := v2023.04 all: u-boot kernel rootfs image flash kernel: git clone --depth=1 -b v$(KERNEL_VER) https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git cd linux && make ARCH=arm64 defconfig && make -j$(shell nproc) Image dtbs rootfs: sudo debootstrap --arch=arm64 --foreign bookworm /mnt/arm64-root sudo cp /usr/bin/qemu-aarch64-static /mnt/arm64-root/usr/bin/ sudo chroot /mnt/arm64-root /debootstrap/debootstrap --second-stage image: kernel rootfs ./scripts/create-disk-image.sh .PHONY: all kernel rootfs image

推荐使用容器构建

避免污染本地环境，用 Docker + QEMU 构建纯净的 arm64 编译环境：

FROM debian:bookworm RUN dpkg --add-architecture arm64 RUN apt update && apt install -y crossbuild-essential-arm64 qemu-user-static ENV CC=aarch64-linux-gnu-gcc

然后就可以在任何机器上一致地构建系统。

最后一点思考：这条路还会走多久？

随着 AWS Graviton、Apple Silicon、NVIDIA Jetson 等 ARM 平台崛起，跨架构部署正成为常态。未来可能会有更多抽象层来简化这一过程，比如：

• Rust 编写的 SBI 固件（如 rustsbi）替代传统 U-Boot；
• 统一设备描述标准（类似 ACPI on ARM）减少设备树依赖；
• WASM 系统运行时实现真正的跨架构应用兼容。

但至少在未来十年，理解底层差异、掌握手动构建能力，仍然是系统工程师的核心竞争力。

如果你也在做类似的移植工作，欢迎留言交流遇到的具体问题。特别是那些“文档里没写，只有踩过才知道”的坑，咱们一起填平。