4、CPU架构抽象：ARM、RISC-V、MIPS等架构的差异、如何通过宏定义和条件编译实现架构无关代码
4.1 为什么Bootloader必须面对架构差异？
做Bootloader开发，说白了就是在跟CPU寄存器、内存映射、中断控制器打交道。不同架构的CPU，这些东西长得完全不一样。
我刚开始做嵌入式那会儿，接手了一个项目，要在同一套代码上支持ARM和MIPS两种芯片。当时年轻，想着「先搞定ARM再说，MIPS后面再改」。结果呢？后面改代码改到怀疑人生——到处都是if-else，代码像打了补丁的旧衣服。
后来我学乖了。做Bootloader，第一件事就是做架构抽象。你想想看，Bootloader的核心任务无非就是：初始化硬件、加载镜像、跳转到内核。这些流程在不同架构上是相似的，但具体实现天差地别。
4.2 三大主流架构的核心差异
先说说我这些年接触最多的三个架构：ARM、RISC-V、MIPS。它们到底差在哪？
| 特性 | ARM (Cortex-A系列) | RISC-V (RV64GC) | MIPS (MIPS32/64) |
|---|---|---|---|
| 异常向量表 | 0x00000000 或 0xFFFF0000 | 可配置，通常由mtvec寄存器指定 | 0x80000000 (BEV=0) 或 0xBFC00000 (BEV=1) |
| 启动模式 | 支持Secure/Non-Secure | M/S/U三种特权级 | Kernel/User两级 |
| 寄存器命名 | R0-R15，有通用和专用之分 | x0-x31，x0恒为0 | $0-$31，$0恒为0 |
| 中断控制器 | GIC (Generic Interrupt Controller) | PLIC (Platform-Level Interrupt Controller) | CP0中断 + 外部中断控制器 |
| MMU页表格式 | 两级/三级页表，支持大页 | Sv39/Sv48，页表项结构不同 | TLB软件管理，页表格式自定义 |
嗯，这里要注意。上面这张表只是冰山一角。真正写代码时，你会发现连最基础的「关中断」操作都不一样。
核心观点：架构抽象不是把代码写成「万能胶」，而是把变化的部分隔离出来，让不变的部分复用。
4.3 宏定义：架构差异的第一道防线
我个人习惯，在Bootloader的顶层头文件里，先定义一套架构相关的宏。比如这样：
// arch.h - 架构抽象层
#if defined(__ARM_ARCH)
#define ARCH_ARM
#define CACHE_LINE_SIZE 64
#define STACK_ALIGNMENT 8
#define BOOT_BASE_ADDR 0x80000000
#elif defined(__riscv)
#define ARCH_RISCV
#define CACHE_LINE_SIZE 64
#define STACK_ALIGNMENT 16
#define BOOT_BASE_ADDR 0x80000000
#elif defined(__mips__)
#define ARCH_MIPS
#define CACHE_LINE_SIZE 32
#define STACK_ALIGNMENT 8
#define BOOT_BASE_ADDR 0x9FC00000
#else
#error "Unsupported CPU architecture!"
#endif你看，这样一写，后面所有代码都不用再关心具体架构了。需要栈对齐？直接用 STACK_ALIGNMENT。需要知道启动地址？直接用 BOOT_BASE_ADDR。
我在项目中遇到过一个问题：某款MIPS芯片的BootROM地址是0xBFC00000，但另一款是0x9FC00000。如果硬编码，换芯片就得改代码。用宏定义之后，只需要在芯片级别的配置文件中重定义一下就行。
4.4 条件编译：让代码「见人说人话」
宏定义只是第一步。真正让代码跑起来，还得靠条件编译。我常用的模式是「三明治结构」：
// cache.c - 缓存初始化
void cache_init(void)
{
#ifdef ARCH_ARM
// ARM架构：使用协处理器CP15
uint32_t ccr;
__asm__ volatile("mrc p15, 0, %0, c1, c0, 0" : "=r"(ccr));
ccr |= (1 << 12); // 开启I-Cache
ccr |= (1 << 2); // 开启D-Cache
__asm__ volatile("mcr p15, 0, %0, c1, c0, 0" : : "r"(ccr));
#elif defined(ARCH_RISCV)
// RISC-V架构：通过CSR操作
uint64_t mstatus;
__asm__ volatile("csrr %0, mstatus" : "=r"(mstatus));
mstatus |= (1 << 3); // MIE位
__asm__ volatile("csrw mstatus, %0" : : "r"(mstatus));
#elif defined(ARCH_MIPS)
// MIPS架构：操作CP0寄存器
uint32_t status;
__asm__ volatile("mfc0 %0, $12" : "=r"(status));
status |= (1 << 0); // 开启全局中断
__asm__ volatile("mtc0 %0, $12" : : "r"(status));
#endif
}这种写法，说白了就是「同一个函数名，不同架构走不同分支」。调用者根本不需要知道底层细节，只需要调用 cache_init() 就行。
小技巧：我建议把架构相关的代码单独放在 arch/arm/、arch/riscv/、arch/mips/ 目录下。然后在Makefile里根据编译目标选择对应的目录。这样代码结构更清晰，也方便后续添加新架构。
4.5 函数指针：运行时多态的妙用
条件编译虽然好用，但有个缺点：编译时就决定了走哪条路。如果你需要同一份二进制支持多种架构（比如U-Boot的Falcon模式），那就得用函数指针。
我曾经在一个项目里，需要在Bootloader阶段动态检测CPU类型（ARM vs Thumb vs Jazelle）。用条件编译做不到，因为编译时不知道目标芯片。后来我用函数指针表搞定了：
// cpu_ops.h
typedef struct {
void (*cpu_init)(void);
void (*cache_enable)(void);
void (*mmu_enable)(void);
uint32_t (*get_cpu_id)(void);
} cpu_ops_t;
extern cpu_ops_t *cpu_ops;
// cpu_detect.c
cpu_ops_t *cpu_ops = NULL;
void cpu_detect_and_init(void)
{
uint32_t id = read_cpu_id_register();
switch (id & CPU_FAMILY_MASK) {
case CPU_ARM_CORTEX_A:
cpu_ops = &arm_cpu_ops;
break;
case CPU_RISCV_U74:
cpu_ops = &riscv_cpu_ops;
break;
case CPU_MIPS_24K:
cpu_ops = &mips_cpu_ops;
break;
default:
while(1); // 不支持
}
cpu_ops->cpu_init();
}这样做的好处是：核心代码完全不用改。想支持新架构？写一个新的 cpu_ops_t 实例就行。
4.6 避坑指南：我踩过的那些坑
讲了这么多理论，说说我实际踩过的坑吧。
坑1：字节序问题
ARM默认小端，MIPS可以配置大端/小端，RISC-V也是小端。但有些MIPS芯片出厂默认大端。我曾经在移植U-Boot时，因为没注意字节序，调试了整整两天才发现是数据对齐问题。解决方案：在架构抽象层加一个 BYTE_ORDER 宏，所有多字节操作都用 cpu_to_le32() 这类函数转换。
坑2：栈对齐要求不同
ARM要求8字节对齐，RISC-V要求16字节对齐。如果你在ARM上写了一个函数，用 __attribute__((aligned(8))) 声明了一个局部变量，拿到RISC-V上可能就崩了。我建议在架构头文件里统一用 STACK_ALIGNMENT 宏，所有栈操作都对齐到这个值。
坑3：中断向量表位置
ARM的异常向量表可以放在0x00000000或0xFFFF0000，由SCTLR.V位控制。RISC-V的mtvec寄存器可以指向任意地址。MIPS的异常入口则跟BEV位有关。我见过有人把ARM的向量表地址硬编码到汇编里，换芯片时忘了改，结果中断全跑飞了。解决方案：用宏定义向量表基址，汇编代码里引用这个宏。
4.7 总结：架构抽象的核心原则
做了这么多年Bootloader，我总结出三条原则：
- 隔离变化：把架构相关的代码放到独立的目录和文件中，不要跟业务逻辑混在一起。
- 统一接口：对外暴露的函数名、参数、返回值保持一致。调用者不需要知道底层是什么架构。
- 编译期决策优先：能用宏定义和条件编译解决的，就不要用运行时判断。性能更好，代码也更简单。
嗯，说白了就是一句话：让架构差异「藏」在抽象层后面。这样你写Bootloader核心逻辑时，眼里只有「初始化、加载、跳转」这三个动作，不用管底下是ARM还是RISC-V。
最后说一句：别想着一次就把抽象层做完美。我每次移植到新架构，都会发现之前的设计有遗漏。没关系，迭代改进就好。Bootloader开发，本来就是个不断「踩坑-填坑」的过程。