ARM64 Linux开启MMU后早期启动硬卡死问题及更新进展

一、__enable_mmu阶段卡死的常见异常原因 #

• 恒等映射覆盖范围缺失：开启MMU后，PC寄存器值仍为开启前的物理地址，需要对应的虚拟-物理恒等映射才能正常取指，若页表未覆盖内核加载地址0x10000000所在的区间，会直接触发指令预取中止导致卡死
• 页表属性配置错误：内核代码段对应的页表项未开启可执行权限，或者内存区域的MAIR属性被配置为设备内存而非普通内存，访问时会触发权限错误或对齐故障
• TTBR寄存器配置错误：写入TTBR的页表基地址不是物理地址，或者页表本身存放在0x0-0x80000000之外的无效内存区间，MMU遍历页表时访问非法地址
• 缓存一致性问题：开启MMU前未完成dcache、icache的完整刷写与失效，旧缓存行内容和实际内存不一致，开启MMU后取指或读数据读取到错误内容

二、页表配置错误的验证与修复方法 #

• 通过JTAG读取TTBR寄存器值，定位页表在物理内存中的存储位置，dump对应地址的页表项内容，逐段检查是否覆盖了0x10000000开始的整个内核镜像范围，恒等映射的虚拟地址与物理地址是否一一对应
• 检查页表项的权限与属性位：代码段页表项需要配置UXN=0、PXN=0以开放可执行权限，普通内存区域的MAIR索引要对应Normal Memory属性，不能配置为设备内存
• 确认页表存放的内存区间未被u-boot、内核镜像、dtb等其他内容覆盖，避免页表内容被篡改

三、禁用dcache可绕过卡死问题的根因分析 #

该现象直接指向缓存相关故障，常见触发原因有两类：

1. 开启MMU前的缓存操作不完整：如果开启MMU前没有对整个dcache执行**刷写（clean）+失效（invalidate）**操作，dcache中残留的脏数据、旧地址标签的缓存行会和开启MMU后的虚拟地址寻址冲突，导致读到错误的指令或数据触发异常。禁用dcache后CPU所有内存访问直接和物理内存交互，绕过了缓存匹配逻辑，因此可以正常推进启动流程
2. FPGA平台缓存控制器实现缺陷：若仿真的Cortex-A53缓存逻辑、缓存与内存控制器的交互时序不符合官方规范，开启dcache后会出现内存读写错误，禁用缓存后即可规避该问题

这种通过禁用dcache绕过故障的方案仅能用于临时调试，缓存一致性问题会持续影响后续内核运行，是后续驱动挂载阶段崩溃的潜在诱因。

四、后续驱动挂载阶段崩溃的排查思路 #

• 首先验证设备树内存节点配置：确认节点中声明的内存范围0x0-0x80000000与实际硬件完全一致，不存在多配、漏配的内存区间
• 检查内核缓存相关配置：开启CONFIG_ARM64_ERRATA_A53相关的勘误补丁配置，确认内核中缓存刷写、失效的适配逻辑符合你使用的Cortex-A53仿真版本要求，若确认是仿真平台缓存逻辑缺陷，可临时在内核启动参数中添加cachepolicy=uncached全局禁用缓存验证
• 排查内核完整页表映射逻辑：进入C语言启动阶段后内核会替换早期恒等映射，建立完整的内核虚拟地址空间页表，确认该阶段的页表映射覆盖了所有外设寄存器、内存区间，属性配置正确

内容的提问来源于stack exchange，提问作者rish_1n4