从x64到ARM64：固件工程师的迁移实战手记
你刚收到一封邮件：“凌云计划启动，Q3前完成首台ARM64服务器固件交付。”
没有过渡期，没有兼容模式，只有一页PDF——《ARM DEN0042: ACPI for ARM64》和一行加粗提醒：“I/O ports are not supported. Do not use them.”
那一刻，你盯着屏幕上那段熟悉的x86汇编：
movq %cr0, %rax andq $0xfffffffffffffffe, %rax movq %rax, %cr0突然意识到——这行代码在ARM64上不仅“不能跑”，它所代表的整套思维惯性，才是迁移真正的拦路虎。
这不是换个编译器的事。这是把一栋用砖块（段寄存器、IDT、SMM内存、I/O端口）垒了二十年的楼，一砖一瓦拆下来，用钢筋混凝土（ELx异常等级、GIC、MMIO、TF-A信任链）重建。而你，是那个既要看懂新图纸、又要亲手砸墙的人。
下面这些内容，来自我们踩过的真实坑、调通的每一行msr sctlr_el3, x0、抓过的每一段dsb ish失效导致的cache不一致，以及产线凌晨三点对着串口log逐字比对的72小时。
汇编不是翻译，是重写世界观
x86固件里，“inb $0x61”像呼吸一样自然；ARM64里，连“端口”这个概念都被标准抹掉了。这不是语法差异，是底层执行模型的彻底分叉。
你真正要放弃的三样东西
- 段寄存器：x86靠
cs/ds/ss切地址空间，ARM64靠TTBR0_ELx+TCR_ELx做页表切换。mov %ax, %ds这种操作，在AArch64里连对应指令都没有——地址空间本就是扁平的，根本不需要“段”。 - CR寄存器：
cr0,cr4,cr8……这些控制开关，在ARM64里被拆成几十个SYS_*寄存器（如SCTLR_EL3,CPACR_EL1,HCR_EL2），每个只管一件事，且访问受异常等级严格约束。想关MMU？必须在EL3下读写SCTLR_EL3.M位，EL1直接msr会触发UNDEFINED异常。 - 隐式内存顺序：x86的
mov天然带acquire语义，ARM64的ldr/str默认不保证顺序。你以为str x0, [x1]写完就能被外设看到？错。必须显式加dsb sy（全系统数据屏障），否则可能卡在write buffer里，直到你重启三次才偶然成功。
关键动作：把“指令”变成“意图”
别再想着“x86的cli对应ARM64哪个指令”。要问：此刻我要达成什么硬件效果？
| x86意图 | ARM64实现要点 | 容易翻车的点 |
|---|---|---|
| 禁用中断 | msr daifset, #2（屏蔽IRQ） | 忘记daifset只在当前EL生效；若在EL2调用，EL1中断照常进来 |
| 清零某控制位 | bic x0, x0, #0x1+msr reg, x0 | bic后漏掉isb，后续指令可能在旧配置下执行 |
| 等待外设就绪 | ldr w0, [x1]→cbz w0, loop | 外设寄存器未声明为volatile，编译器优化成死循环 |
💡真实案例：某次调试PCIe设备枚举失败，最终发现是
mrs x0, mpidr_el1后没跟dsb sy，导致后续str写入配置空间时，CPU以为写完了，其实数据还卡在总线缓冲区——外设根本没收到。加一行dsb sy，问题消失。
寄存器命名背后是设计哲学
x86的rax/rbx/rcx是历史包袱；ARM64的x0-x30+sp/pc/zr是刻意设计：
-x0-x7：参数传递寄存器（AAPCS64），函数入口第一眼就看到输入在哪；
-x29/x30：帧指针/返回地址，栈回溯不再靠rbp推算，而是硬编码约定；
-sp：不是通用寄存器，add sp, sp, #16合法，mov x0, sp非法——SP被当作特殊资源管理。
这意味着：你的汇编代码必须按AAPCS64写，否则调用C函数时参数全乱套。
ACPI不是填表，是重新定义“硬件存在的方式”
x86 BIOS里，FADT.PM1a_EVT_BLK = 0x1000是常识；ARM64里，这个值必须为0，否则Linux内核直接拒绝启动——因为标准白纸黑字写着：“I/O port access is prohibited.”
这不是限制，是解放。
从“I/O端口”到“内存映射”的思维跃迁
x86的ACPI依赖一套I/O端口约定：
-PM1a_EVT_BLK：电源事件寄存器组（如0x1000）
-PM1a_CNT_BLK：电源控制寄存器组（如0x1004）
-RESET_REG：软复位端口（如0xcf9）
ARM64全部废除，改用MMIO地址：
-X_PM1a_EVT_BLK.Address：指向GIC Distributor基址（如0x80000000）
-X_PM1a_CNT_BLK.Address：指向GIC CPU Interface基址（如0x80100000）
-RESET_REG.Address：指向SBSA看门狗控制器（如0x80200000）
🚨致命陷阱：
X_PM1a_EVT_BLK字段是ACPI_GENERIC_ADDRESS_STRUCTURE，包含Address,AddressSpaceId,BitWidth等6个子字段。很多人只填Address，忘了设AddressSpaceId = 1（表示Memory Space），结果内核解析出错，GIC初始化失败，系统卡在“Waiting for root device”。
GIC不是可选项，是ACPI的基石
x86用APIC，ARM64用GIC——但关键区别在于：GIC的物理地址、中断号映射、CPU接口数量，必须由ACPI表精确描述，否则Linux连第一个中断都收不到。
看这段MADT（Multiple APIC Description Table）关键片段：
// MADT entry for GIC Distributor ACPI_MADT_GENERIC_DISTRIBUTOR *Gicd; Gicd->BaseAddress = 0x80000000; // GICD base Gicd->GlobalIrqBase = 0; // First SPI interrupt number // MADT entry for GIC CPU Interface ACPI_MADT_GENERIC_INTERRUPT *Gicc; Gicc->BaseAddress = 0x80100000; // GICC base Gicc->ArmMpidr = 0x80000000; // CPU0's MPIDR_EL1 value Gicc->Flags = ACPI_MADT_ENABLED; // Must be set!如果Gicc->Flags没置ACPI_MADT_ENABLED，Linux会认为这个CPU接口不可用，直接跳过初始化——你的CPU0永远收不到任何中断，包括timer。
HID标识符：让OS认出你是“ARM服务器”，不是“x86模拟器”
x86设备用PNP0A08（PCI Express Root Bridge），ARM64必须用ARMHC0001。为什么？因为Linux内核的ACPI驱动匹配逻辑是：
// drivers/acpi/bus.c if (acpi_match_device_ids(device, arm_hardware_ids) == 0) { // 加载ARM专用驱动，如acpi_gic_init() }如果你的PCIe Root Bridge仍报PNP0A08，内核会加载x86的acpi_pci_root.c，而它根本不认识GIC，最终设备无法枚举。
SMM不是消失，是进化成更细的“安全域”
x86的SMM像一个黑箱：SMI#一来，CPU跳进SMRAM，执行完再RSM回来。ARM64没有这个黑箱，它把安全功能切成三层：
-EL3（Secure Monitor）：硬件信任根，运行TF-A BL1/BL2，只干一件事——校验下一级镜像签名；
-EL2（Hypervisor）：虚拟化管理层，运行TF-A BL31，管理GIC、MMU、MPAM；
-Secure World（EL1 Secure）：OP-TEE OS，运行可信应用（TA），处理密钥、度量、加密。
UEFI（BL33）只是其中一员，且必须在EL2下被加载——它不再是“最高特权”，而是“安全世界的服务消费者”。
Secure Boot链条：从“层层签名”到“原子化验证”
x86流程：Boot ROM → Option ROM → UEFI DXE → OS Loader
每层自己校验下一层，密钥存在SPI Flash变量区。
ARM64流程：ROM → TF-A BL1（校验BL2）→ BL2（校验BL31/BL32/BL33）→ BL31（启动OP-TEE）→ UEFI（作为BL33）
关键变化：UEFI本身不参与签名验证，它只是被BL2验证通过后才加载的“普通应用”。密钥管理完全交给TF-A和OP-TEE。
如何让UEFI安全地拿到PK？
x86里gRT->SetVariable("PK", ...)直接写Flash；ARM64里，这行代码必须经过EL3授权：
// 正确姿势：通过SMC调用TF-A获取公钥 UINT64 SmcArgs[4]; SmcArgs[0] = ARM_SMC_ID_TFA_GET_PUBKEY; // 自定义SMC ID SmcArgs[1] = PUBKEY_TYPE_PK; arm_smc(SmcArgs); // 触发EL3处理 // TF-A在EL3验证调用者身份后，将PK拷贝到共享内存并返回地址如果UEFI试图绕过SMC，直接SetVariable写PK，TF-A会在下次启动时检测到变量被篡改，拒绝加载BL33。
SMM服务重写：不是替换，是解耦
x86的SmmControlProtocol提供LockMemoryRegion()等接口；ARM64没有SMM，但你需要同样的功能——比如锁定一段内存防DMA攻击。
正确做法：
1. 在OP-TEE中写一个TA（Trusted Application），实现内存锁定逻辑；
2. UEFI通过SMC调用该TA；
3. TA在Secure World中调用mpam_set_partition()设置MPAM寄存器，完成硬件级锁定。
✅ 这样做的好处：内存锁定逻辑在Secure World执行，不受Non-Secure World软件干扰；坏处：每次调用都要进出EL3，有开销。所以，把高频操作（如读温度）放在UEFI，低频安全操作（如锁内存）放TA——这是工程权衡，不是技术妥协。
工程落地：那些文档不会告诉你的细节
内存布局——安全世界的“地契”
TF-A要求为各组件划固定内存区，且绝对禁止重叠：
| 组件 | 起始地址 | 大小 | 用途 |
|--------|------------|--------|------|
| TF-A BL2 |0x80000000| 512KB | 镜像加载与验证 |
| OP-TEE |0x80100000| 4MB | Secure World OS |
| UEFI |0x80500000| 8MB | BL33，含ACPI表、DXE驱动 |
| Shared Memory |0x81000000| 1MB | UEFI ↔ OP-TEE数据交换区 |
如果UEFI动态分配内存时不小心占用了0x81000000，OP-TEE TA读取共享内存就会崩溃——而错误日志只显示“SMC call failed”，根本看不出是内存冲突。
调试：双日志通道比单串口救命
TF-A_CONSOLE：输出BL1/BL2/BL31初始化日志（如GIC base address, MMU setup）；UEFI_DEBUG：输出UEFI Driver Binding、ACPI Table Parsing日志。
关键技巧：在TF-A的plat_setup_psci_ops()中，把console_init()的基地址设为UART0；在UEFI的PlatformPei中，把SerialPortInitialize()指向UART1。两个串口同时接PC，用screen /dev/ttyUSB0 115200和screen /dev/ttyUSB1 115200分开看——当UEFI卡住时，先看TF-A日志是否成功跳转到BL33；如果TF-A日志停在jumping to bl33...，说明UEFI镜像加载失败，立刻去查Image Base Address是否对齐。
兼容性兜底：#ifdef ARM64是短期方案，不是长期答案
保留x86 DXE驱动源码，用条件编译适配ARM64，能快速交付初版。但很快你会遇到：
- x86的PciIo->PollMem()依赖I/O端口，ARM64必须重写为MmioRead32()；
- x86的TimerLib基于HPET，ARM64必须切换到Generic Timer；
建议：在ArmPlatformPkg下新建ArmDxe目录，把所有ARM64专用驱动放进去，用INF文件明确指定[Sources.ARM64]。这样，当未来支持RISC-V时，只需新增[Sources.RISCV64]，无需动老代码。
你合上调试器，屏幕还亮着最后一行log：[UEFI] ACPI: Found table FADT (0x80501234)[TF-A] BL31: GICv3 init done, GICD=0x80000000, GICC=0x80100000[OP-TEE] TA invoked: secure_boot_verify_os_loader
这不是终点。这只是你第一次用ARM64的思维，让硬件真正“活”了过来。
下一次，当你要集成ARMv9的CCA机密计算特性时，你会想起今天为dsb ish加的那一行屏障——原来所有宏大的架构演进，都始于对最基础指令的一次敬畏。
如果你在迁移中也卡在某个SMC调用或MADT解析上，欢迎把log贴出来，我们一起看。
