ARM内存管理基础：入门级全面讲解

深入ARM内存管理：从零理解MMU与页表机制

你有没有遇到过这样的问题——在调试一段裸机代码时，程序一开启MMU就崩溃？或者在移植操作系统时，发现某个外设寄存器读写异常，查了半天才发现是内存属性配置错了？这些问题的背后，往往都指向同一个核心模块：内存管理单元（MMU）。

今天，我们就来彻底拆解ARM架构下的内存管理系统。不堆术语、不抄手册，用“人话”讲清楚：
虚拟地址是怎么转成物理地址的？页表到底是怎么组织的？为什么开了MMU之后连内存都访问不了了？ARMv7和ARMv8到底差在哪？

准备好了吗？我们从最基础的问题开始。

什么是虚拟内存？为什么需要它？

在没有MMU的小型单片机上（比如Cortex-M系列），CPU发出的地址就是真实物理地址——这种模式叫物理寻址。简单直接，但也意味着所有程序共享同一块内存空间。

一旦系统复杂起来，这就成了灾难：一个bug就能把整个系统的内存踩烂。

而现代操作系统（如Linux、Android）采用的是虚拟内存机制：每个进程看到的都是独立的、完整的4GB（或更大）地址空间。你的App以为自己独占内存，其实它所访问的每一个地址，都要经过MMU翻译后才能真正落到物理内存上。

这就像你住在一个公寓楼里，你以为你家门牌是“301”，但快递员知道那其实是“东区B栋第3层第1户”。MMU就是那个翻译门牌号的快递分拣系统。

MMU的核心任务有三个：

地址转换：把虚拟地址（VA）变成物理地址（PA）
权限控制：检查当前操作是否允许（例如用户程序不能随便读内核内存）
内存保护：非法访问时触发异常，防止系统崩溃

要完成这些任务，靠的就是——页表 + TLB + 控制寄存器。

MMU是怎么工作的？一步步带你走完地址转换流程

假设你的程序想读取虚拟地址0x80001000上的数据。这个请求发到CPU后，会经历以下过程：

第一步：先去TLB里查缓存

MMU不会每次都去翻页表，那样太慢了。它有一个高速缓存叫TLB（Translation Lookaside Buffer），专门用来存最近用过的地址映射。

如果命中 → 直接拿到物理地址，结束。
如果没命中 → 进入下一步，查页表。

小知识：TLB命中率对性能影响极大。一次TLB miss可能导致几十甚至上百个周期的延迟。

第二步：根据页表基址寄存器定位根目录

页表是一个多级树结构，就像文件系统的目录一样。要找到某个页面的映射，必须从根开始逐级查找。

ARM处理器有两个关键寄存器保存页表根地址：
-TTBR0：用于用户空间（通常映射0–3GB）
-TTBR1：用于内核空间（通常映射3–4GB）

这两个寄存器决定了当前使用的页表是谁的。每次进程切换时，操作系统就会更换TTBR的值，从而实现不同进程之间的地址隔离。

第三步：逐级遍历页表，找到最终物理页

以ARMv7为例，典型的两级页表结构如下：

一级页表（L1）：全局索引

共4096个条目，每个4字节，总共16KB
每个条目可以是两种类型：
段描述符（Section Entry）：直接映射1MB物理内存
页表描述符（Page Table Entry）：指向一个二级页表

二级页表（L2）：精细控制

每个二级页表管理1MB虚拟空间
条目对应4KB小页或64KB大页
每个PTE包含：物理页号 + 属性位（可读/可写/可执行等）

举个例子：
你要访问0x12345678，拆解它的地址结构：

地址部分	位域	值	含义
高12位	[31:20]	`0x123`	L1索引
中间8位	[19:12]	`0x45`	L2索引（若使用）
低12位	[11:0]	`0x678`	页内偏移

流程如下：
1. 用0x123查L1页表 → 得到一个条目
2. 判断该条目类型：
- 若为段描述符 → 物理地址 = (PPN << 20) + 0x45678
- 若为页表指针 → 取出L2页表地址
3. 用0x45查L2页表 → 得到4KB页的PPN
4. 最终PA = (PPN << 12) + 0x678

整个过程就像查电话簿：先找区号，再找街道，最后找门牌号。

ARMv8来了：四级页表如何应对更大的地址空间？

随着应用需求增长，32位地址已经不够用了。ARMv8引入AArch64模式，支持最多48位虚拟地址（即256TB空间）。为了高效管理这么大的空间，页表也升级成了四级结构：

层级	名称	功能
L0	PGD（Page Global Directory）	全局入口
L1	PUD（Page Upper Directory）	上层分支
L2	PMD（Page Middle Directory）	中间分支
L3	PTE（Page Table Entry）	末级映射，指向4KB页

每级用9位索引（共36位），加上12位页内偏移，正好构成48位虚拟地址。

相比ARMv7的两级结构，ARMv8的设计更灵活，扩展性更强。而且支持多种粒度（granule size），常见有：
- 4KB（标准）
- 16KB
- 64KB

同时保留兼容模式，可以在AArch64下运行类似ARMv7风格的两层页表（例如Linux内核常用3级简化版）。

实战提示：如果你在调试AArch64启动代码，务必确认EL1阶段的TCR_EL1寄存器设置正确，否则页表可能解析失败！

页表项里到底存了啥？别忽视这些关键属性！

很多人只关注“地址映射”，却忽略了页表项中的内存属性字段，而这恰恰是导致系统不稳定最常见的原因之一。

一个典型的页表项不仅包含物理页号，还有以下几个重要标志位：

字段	作用说明
Valid bit	是否有效，无效则触发缺页异常
AP[2:0]	访问权限：只读/读写、用户/特权级
PXN / UXN	执行禁止位（Privileged/User eXecute Never）
AttrIdx	指向MAIR_ELx寄存器，定义缓存属性
NS bit	安全区/非安全区（TrustZone相关）

其中最容易被忽略的是内存类型配置：

内存属性三大类：

Normal Memory
- 可缓存（Cacheable）
- 支持乱序访问
- 适用于DRAM、堆栈、代码段
- 需配合cache维护指令（如__clean_dcache_area）
Device Memory
- 不可缓存
- 强顺序访问（Strongly Ordered）
- 必须每次真实访问硬件
- 用于外设寄存器、FIFO等
Shared vs Non-shared
- 多核环境下需标记共享内存，确保一致性

⚠️ 经典坑点：
如果你把设备寄存器映射成“Normal Cacheable”，那么CPU可能会从缓存中读旧值，导致外设状态不同步！反过来，如果把DDR映射成Device类型，性能会暴跌。

开启MMU之前必须做好的几件事

很多初学者写完页表就立刻开MMU，结果系统直接跑飞。原因往往是忽略了几个关键前提条件。

✅ 正确姿势 checklist：

页表本身必须位于物理内存且可访问
- MMU开启后，CPU走的是虚拟地址
- 所以页表区域必须提前建立恒等映射（identity mapping）
- 即 VA == PA，保证能正常读写页表数据
设置正确的TTBR和TCR寄存器
- ARMv7：写 TTBR0/TTBR1 + SCTLR
- ARMv8：写 TTBR0_EL1 + TCR_EL1 + SCTLR_EL1
- 注意使能域、选择页大小、地址宽度等参数
同步流水线与缓存
在修改页表或控制寄存器后，必须插入屏障指令：
c __asm__ volatile("dsb sy; isb" ::: "memory");
-DSB：等待所有内存操作完成
-ISB：刷新取指流水线，避免执行旧代码
清空TLB
修改页表后不清TLB = 白改！
c // ARMv7 清TLB全部条目 __asm__ volatile("mcr p15, 0, %0, c8, c7, 0" :: "r"(0));
按顺序操作
推荐步骤：
构建页表（静态映射内核、RAM、设备）
设置TTBR/TCR
DSB + ISB
清TLB
开MMU（写SCTLR）
再次ISB

实际应用场景与调试技巧

场景一：Bootloader如何初始化MMU？

典型流程（如U-Boot）：

// 1. 关闭中断 // 2. 设置栈（仍在物理地址） // 3. 创建临时页表（映射低1GB为identity mapping） // 4. 加载TTBR0 // 5. 配置SCTLR（使能MMU、对齐检查、数据/指令cache） // 6. 跳转到虚拟地址函数（注意PC必须连续）

提示：跳转时不要用BL，建议用MOV PC, #label，避免返回原物理地址造成错乱。

场景二：进程切换时怎么办？

Linux内核的做法：
- 每个进程有自己的页表（mm_struct）
- switch_to时调用__switch_mm()：
- 更新TTBR0（用户空间变了）
- 可选更新ASID（Address Space ID），避免频繁清TLB
- 发送TLB维护指令（TLBI by ASID or VMID）