跨越架构鸿沟：如何用一套驱动驾驭 ARM64 与 x64 外设
你有没有遇到过这样的场景？
团队开发了一款高性能智能网卡，既要用在基于 ARM64 的边缘服务器上，又要部署到主流 x64 架构的数据中心。结果发现，两个平台的驱动代码几乎得重写一遍——同样的功能，却要维护两套逻辑，测试、调试、发版全都要翻倍。更头疼的是，某个 Bug 修复后，还得同步改两份代码，稍有疏漏就引发不一致。
这并非个例。随着 ARM64 在服务器和嵌入式领域的强势崛起，x64 和 ARM64 共存已成为现代计算基础设施的常态。然而，这两种架构在外设访问方式上的深层差异，让设备驱动成了“分裂”的重灾区。
难道就没有办法写一份驱动代码，跑在两种架构上吗？
答案是：有。而且这条路不仅走得通，还越来越重要。
为什么外设驱动会“水土不服”？
表面上看，ARM64 和 x64 都能跑 Linux，都能接 PCIe 设备，似乎没什么不同。但当你深入到底层硬件交互时，就会发现它们像说两种语言的人——虽然目标一致，表达方式却大相径庭。
寻址机制：从“专用信道”到“统一内存”
先来看一个最根本的问题：CPU 怎么跟外设通信？
在传统的x64 架构中，有两种方式：
- Port I/O（端口I/O）：使用
in/out这类特殊指令，通过独立的 I/O 地址空间读写寄存器。就像给每个设备分配了一个专属对讲频道。 - MMIO（内存映射I/O）：把外设寄存器映射成一段内存地址，用普通的
mov指令就能访问。
而到了ARM64，一切都被简化了：所有外设都走 MMIO。没有单独的 I/O 空间，也不需要in/out指令。所有的控制寄存器，统统当作内存来访问。
这意味着什么？
如果你在驱动里直接写了outb(0x378, val)，这段代码在 x64 上可能还能编译过去，但在 ARM64 上根本无法链接——因为根本没有对应的指令支持。
✅关键洞察：统一驱动的第一步，就是彻底告别
in/out指令，全面转向 MMIO 编程模型。
好消息是，在现代系统中，尤其是 PCIe 设备，MMIO 已经成为事实标准。即使是 x64 平台，新设备也基本不再依赖 Port I/O。我们完全可以基于 MMIO 构建跨平台接口。
资源描述：设备树 vs ACPI，谁说了算？
另一个让人抓狂的差异在于：操作系统怎么知道设备长什么样？
- 在 ARM64 上，靠的是设备树（Device Tree）——一种文本格式的硬件描述文件，在启动时由 Bootloader 传给内核。它轻量、透明，特别适合 SoC 类芯片。
- 在 x64 上，则普遍采用ACPI（高级配置与电源接口）——一组由 BIOS 提供的二进制表结构，功能强大，支持热插拔和复杂电源管理。
举个例子。你想获取某个设备的寄存器基地址和中断号：
// ARM64: 设备树片段 mydevice@9000000 { compatible = "vendor,mydev"; reg = <0x0 0x9000000 0x0 0x1000>; interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; };而在 x64 上，这些信息藏在_CRS控制方法或_INT对象中，形式完全不同。
如果驱动直接解析这些原始结构，那又得为两种机制写两套代码。
怎么办？
Linux 内核早已替我们想好了出路：platform_device 抽象层。
无论底层是来自设备树还是 ACPI，最终都会被内核统一转换为struct platform_device结构体。你可以用完全相同的 API 去拿资源：
static int get_resources(struct platform_device *pdev, void __iomem **base, int *irq) { struct resource *res; // 获取内存区域 —— 自动适配 DT 或 ACPI res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) return -ENODEV; *base = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(*base)) return PTR_ERR(*base); // 获取中断号 —— 同样屏蔽差异 *irq = platform_get_irq(pdev, 0); if (*irq < 0) return *irq; return 0; }看到没？这个函数不需要关心设备是怎么来的。只要它是platform_device，就能用同一套逻辑处理。这才是真正的“无感切换”。
统一驱动的核心：不是兼容，而是抽象
很多人以为“统一驱动”就是加一堆#ifdef CONFIG_ARM64来分支处理。但这只会让代码越来越臃肿，变成难以维护的“意大利面条”。
真正高效的方案，是分层抽象。
第一层：硬件抽象层（HAL），封装访问细节
我们可以定义一组通用接口，比如：
// hal_io.h u32 hal_read_reg(void __iomem *addr); void hal_write_reg(void __iomem *addr, u32 val); void hal_reg_update(void __iomem *addr, u32 mask, u32 val);这些函数看起来简单，但背后可以有不同的实现：
- 在 ARM64 上，直接调用
readl/writel - 在 x64 上，也可以调用同样的函数（因为现代 x86_64 也推荐用 MMIO）
- 如果真有特殊需求（比如某些 legacy 寄存器需要 port IO），就在 HAL 内部做条件编译，而不是暴露给上层
更重要的是，HAL 可以自动插入必要的内存屏障（memory barrier），确保多核环境下操作顺序正确：
static inline u32 hal_read_reg(void __iomem *addr) { u32 val = readl(addr); rmb(); // 保证后续读取不会被重排序 return val; } static inline void hal_write_reg(void __iomem *addr, u32 val) { writel(val, addr); wmb(); // 确保写入完成后再继续 }这样一来，上层驱动再也不用担心架构间的内存模型差异了。
第二层：解耦控制逻辑与平台操作
再进一步，我们可以把驱动拆成两个部分：
核心控制器（Core Logic）
负责协议解析、状态机管理、数据调度等业务逻辑。这部分应该是纯 C 实现，不依赖任何架构特性。平台适配器（Platform Adapter）
实现具体的 GPIO 控制、时钟开关、电源管理等动作。这部分允许使用平台专属 API。
两者之间通过一个“操作集”连接：
struct hal_ops { int (*init)(void); void (*enable_clock)(bool en); int (*get_gpio_level)(int pin); void (*set_gpio)(int pin, int val); }; struct my_driver_ctrl { void __iomem *regs; int irq; const struct hal_ops *ops; // 动态绑定适配层 bool running; };这样设计的好处非常明显：
- 核心逻辑只需要调用
ctrl->ops->set_gpio(...)，完全不知道自己运行在哪种平台上； - ARM64 和 x64 分别提供各自的
hal_ops实现，只需编译时链接进去即可； - 甚至可以在 x64 上模拟 ARM64 的行为，用于早期验证和 CI 测试。
实战：一次编写，双端编译
假设我们要开发一款跨平台的 GPIO 扩展芯片驱动。它的主控逻辑非常复杂，涉及中断去抖、电平监控、事件上报等。
按照统一模型，我们的目录结构可能是这样：
drivers/gpio/mygpio/ ├── Kconfig ├── Makefile ├── driver_core.c # 共享逻辑，编译为 mygpio_core.o ├── hal_io.h # 统一I/O接口 ├── arm64/ │ └── hal_arm64.c # ARM64适配层 └── x86_64/ └── hal_x86_64.c # x64适配层在Makefile中根据架构选择对象文件：
obj-$(CONFIG_GPIO_MYGPIO) += mygpio_core.o mygpio_core-y := driver_core.o # 条件链接适配层 ifeq ($(CONFIG_ARM64),y) mygpio_core-y += arm64/hal_arm64.o endif ifeq ($(CONFIG_X86_64),y) mygpio_core-y += x86_64/hal_x86_64.o endif整个项目只有一份核心代码，适配层通常不超过几百行。即使将来要支持 RISC-V，也只是新增一个riscv/目录而已。
那些你必须避开的坑
即便有了统一模型，实际开发中仍有不少陷阱需要注意：
| 问题 | 正确做法 |
|---|---|
| 字节序混乱 | 寄存器字段明确标注__be32，读取时用be32_to_cpu()转换 |
| DMA 缓冲区不一致 | 必须用dma_alloc_coherent()分配，不能用kmalloc |
| 物理地址硬编码 | 所有地址必须通过reg属性获取，禁止写死0x9000000 |
| 误用架构专属头文件 | 避免包含<asm/msr.h>、<asm/io.h>等非标准头 |
| 忽略编译检查 | 启用COMPILE_TEST，允许在非目标架构上做语法扫描 |
特别是最后一点，建议在 CI 流水线中加入交叉编译测试：
# 在 x64 主机上编译 ARM64 版本（仅检查语法） make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- modules这能帮你提前发现很多潜在的架构依赖问题。
不只是理论：已经在哪些地方落地了？
这套思路并不是纸上谈兵。事实上，Linux 内核中已有大量成功实践：
- NVMe 驱动：同一个
nvme-core.ko模块可在 ARM64 和 x64 上运行，仅需适配 PCIe Host Controller 的差异； - GPIO 子系统：通过
gpiolib抽象，上层应用无需关心底层是哪种 SoC； - BMC（基板管理控制器）：越来越多厂商采用统一固件框架，支持多种主机架构下的带外管理。
就连 NVIDIA 的 GPU 驱动、Intel 的 DPU 解决方案，也都开始朝着“单一代码库 + 多平台适配”的方向演进。
写在最后
ARM64 和 x64 的共存不是短期现象，而是未来十年的基础设施常态。无论是云原生环境中的混合部署，还是异构计算节点间的协同，都需要我们在软件层面打破架构壁垒。
统一驱动模型的价值，远不止于节省几万行代码。它带来的是：
- 更快的产品迭代速度；
- 更低的维护成本；
- 更高的系统可靠性；
- 更灵活的技术迁移路径。
而这背后的关键，并不是强行统一硬件，而是学会用抽象代替适配，用分层化解复杂性。
当你下次面对“双平台支持”任务时，不妨停下来问一句：
我是在写两套驱动，还是在构建一个可扩展的驱动架构？
选择后者，才是工程师应有的姿态。
如果你正在尝试类似的跨平台驱动开发，欢迎在评论区分享你的挑战与经验。我们一起探索，如何让代码真正“一次编写，处处运行”。
