头图 | CSDN 下载自视觉中国
出品 | CSDN（ID：CSDNnews）
以下为译文：
不久前，我曾撰文先容了内核的解压缩，结果那篇文章（https://people.kernel.org/linusw/how-the-arm32-linux-kernel-decompresses）收到了大量的评论和留言，这有点出乎猜想。我估计可能是由于那篇文章跟火爆七十年代末的《莱昂氏UNIX源代码剖析第六版》同样的缘故原由吧。操作系统开拓职员喜好阅读深度扩展的代码注释，而那篇文章便是这种类型。
我所说的“ARM32”的正式名称为Aarch32，在ARM架构中，从ARMv4到ARMv7这几个版本实现了该架构。
本文我将谈论在经由解压缩和勾引、加载到物理内存后，内核如何自我勾引，直到在虚拟内存中实行由C编写的通用内核代码的过程。
统统的开端
在经由解压、增强，并收到了设备树块（DTB）之后，程序计数器（pc）被置于符号stext的物理地址（即文本段的开始处），从而调用ARM32内核。这段代码可以参考arch/arm/kernel/head.S。
宏 __HEAD 会将这里的代码放到一个名为 .head.text 的连接器节中。查看ARM架构的连接器文件（arch/arm/kernel/vmlinux.lds.S）就会创造，这一操作表明了该节中的目标代码为首先被实行的代码。
此处的物理地址被均匀分割为16MB加上额外的32KB的 TEXT_OFFSET（其缘故原由稍后会详细阐明），以是stext的地址大致为0x10008000（即本例中利用的地址）。
head.S 包含一小段密集的非常处理，用于各种旧的ARM平台，因此很难读懂。ATAGs和设备树勾引的标准问世大致与 head.S 的建立处于同一韶光，以是多年来这段代码变得越来越繁芜。
为了理解下面的内容，你须要对页式虚拟内存有基本的理解。如果以为维基百科上的先容太粗略，可以参考Hennesy & Patterson的《打算机体系构造：量化研究方法》一书。本文还假设你懂得一些基本的ARM汇编措辞，以及Linux内核的根本知识。
ARM的虚拟内存分割
首先先容一下内核在虚拟内存中的何处实行。内核的RAM基址在 PAGE_OFFSET 符号中定义，其位置可以配置。从 PAGE_OFFSET 的名字中可以看出，它是内核RAM第一页的虚拟内存偏移量。
你可以从四种内存分割方法中选择一种，这让我想起了快餐店。这一点目前在 arch/arm/Kconfig 中定义如下：
config PAGE_OFFSET hex default PHYS_OFFSET if !MMU default 0x40000000 if VMSPLIT_1G default 0x80000000 if VMSPLIT_2G default 0xB0000000 if VMSPLIT_3G_OPT default 0xC0000000
首先把稳到，如果没有MMU（例如在运行ARM Cortex-R类设备，或旧的ARM7芯片时），就会在物理内存和虚拟内存之间建立1:1的映射。页表的浸染仅仅是添补缓存，地址不会被重写。这种情形下，PAGE_OFFSET常日会位于地址 0x00000000。不带虚拟内存的Linux内核被称为“uClinux”，曾经是Linux内核的一个分支，多年后才被吸纳成为主线内核的一部分。
不该用虚拟内存，在Linux乃至任何POSIX类系统中都是另类。后文我们假设勾引都会利用虚拟内存。
PAGE_OFFSET 虚拟内存分割符号会在上述地址处建立虚拟内存空间，供存放内核利用。以是内核会将所有代码、状态和数据构造（包括虚拟内存到物理内存的转译表）保存不才面的虚拟内存地址之一：
● 0x40000000-0xFFFFFFFF
● 0x80000000-0xFFFFFFFF
● 0xB0000000-0xFFFFFFFF
● 0xC0000000-0xFFFFFFFF
在这四者中，末了一个 0xC0000000-0xFFFFFFFF 是目前最常见的，这样内核就有1GB的地址空间可以利用。
内核下方的内存用于用户空间的代码，地址范围为0x00000000-PAGE_OFFSET-1（常日地址位于0x00000000-0xBFFFFFFF，共3GB）。Unix习气供应逾额内存，即操作系统乐不雅观地给程序供应的虚拟内存空间，其大小常日会超过可用的物理内存大小。每个新天生的用户空间进程都以为自己有3GB的内存可用！
这种逾额供应从上世纪七十年代就成了Unix的特点。
为什么有四种分割办法？
答案很大略：ARM在嵌入式系统中有大量运用，这些系统可能更重视用户空间（如常日的平板电脑、手机乃至台式电脑），也可能更重视内核空间（如路由器）。绝大多数系统都重视用户空间，或者内存很少，以是若何分割实在关系不大（不论若何分割，内存都会很拥挤），以是最常见的分割便是将 PAGE_OFFSET 设置为 0xC0000000。
图：内核空间和用户空间之间最常见的虚拟内存分割位于0xC0000000。关于本图须要把稳的一点：这里说一块内存在“上面”的意思是上图中更靠下的位置，即沿着箭头朝着高位地址的方向。我知道有人会认为这不符合逻辑，更方向于将上图颠倒过来，将0xFFFFFFFF画在上面，不过这是我的个人习气，也是绝大多数硬件手册中的老例。
有可能系统有很多内存，且更重视内核空间，例如带有很多内存（如4GB RAM）的路由器或NAS。此时你可能希望内核能够将一些内存作为页面缓存和网络缓存利用，提高最常见的操作的速率，以是你会希望分割出更多的内核内存，比如在极度情形下可以将 PAGE_OFFSET 设置为 0x40000000。
这个虚拟内存映射永久存在，纵然内核在实行用户空间代码时也是。一贯保持内核映射，可以非常快地进行户空间到内核空间的高下文切换，这样当用户空间进程须要调用内核时，不须要进行任何页表更换。只须要启动一个软件陷阱，切换到监督模式（supervisor mode），实行内核代码即可，虚拟内存的配置不须要变革。
在不同的用户空间之间实行高下文切换也更快：只须要用一段预先定义好的物理RAM块更换页表的低端部分（常日会更换内核映射，由于它很大略）即可。这段预先定义好的物理RAM是线性映射的，乃至被存储在一个分外的地方：页表缓存（translation lookaside buffer）。页表缓存位于芯片上，是“非常快的转译表”，以是能更快地进入内核空间。这些地址永久存在，永久是线性映射的，而且永久不会产生页面缺点。
在哪里实行？
我们连续看 arch/arm/kernel/head.S 处的符号 stext。
下一步便是处理在未知内存地址处运行的问题。内核可以加载到任何地方（只假如合理的偶数地址即可）并实行，以是我们要处理这一点。把稳内核代码不是位置无关的，内核经由编译和连接后，必须在特定的地址实行。但我们还不知道这个地址。
内核首先要检讨一些分外特性，如虚拟化扩展、LPAE（大型物理地址扩展），然后进行以下操作：
adr r3, 2f ldmia r3, {r4, r8} sub r4, r3, r4 @ (PHYS_OFFSET - PAGE_OFFSET) add r8, r8, r4 @ PHYS_OFFSET (...) 2: .long . .long PAGE_OFFSET
.long . 在连接时赋值为标签 2: 处的地址，以是 . 会解析为标签 2: 实际被连接到的地址，连接器认为该地址会被定位到内存中。该地址将位于内核指定的某块虚拟内存中，即常日位于 0xC0000000 上方的某个地方。
之后便是编译好的常量PAGE_OFFSET，我们已经知道它的值大概为 0xC0000000。
我们将 2: 在编译时天生的地址加载到 r4 中，将常量 PAGE_OFFSET 加载到 r8 中。然后从中减去 2: 的真实地址。之后利用相对指令从 r4 中得到 2: 的真实地址并保存到 r3，再从 r3 中减去 r4。记住ARM汇编的参数顺序就像打算器一样，sub ra, rb, rc 相称于 ra = rb - rc。
这样在 r4 中得到的结果便是内核在编译时得到的运行地址和实际的运行地址之间的偏移量。以是这里的注释 @ (PHYS_OFFSET - PAGE_OFFSET) 表明我们得到了该偏移量。如果内核符号 2: 在编译时的实行地址是虚拟内存中的 0xC0001234，但实际上在 0x10001234处实行，那么 r4 的值便是 0x10001234 - 0xC0001234 = 0x50000000。这个值的实际含义是“-0xB0000000”，由于这里的算术是可交流的：0xC0001234 + 0x50000000 = 0x10001234。证明完毕。
下面，将这个偏移量加到编译时确定的 PAGE_OFFSET 上。我们已知后者类似于 0xC0000000。利用循环算术，如果内核实行的实际地址还是 0x10001234，我们将得到 0xC0000000 + 0x50000000 = 0x10000000 并保存在 r8 中，这便是内核实行时的基址的物理地址。以是注释写的是 @PHYS_OFFSET 。r8中保存的这个值便是我们要利用的值。
旧的ARM内核中有一个叫做 PLAT_PHYS_OFFSET 的符号，个中包含的正是这个偏移量（如0x10000000），不过是在编译时确定的。现在已经不这样做了，而是在实行时动态确定。如果你的操作系统比Linux大略，那很可能会创造，开拓职员常日会做出类似于“物理偏移量是常量”的假设进行简化。Linux发展到本日这种做法，是由于它须要在各种内存布局中勾引同一个内核。
图：本文示例中的物理内存到虚拟内存的映射。
关于 PHYS_OFFSET 有一些规则：它须要知足一些基本的对齐哀求。在确定第一个解压后的代码中的第一个物理内存块的位置时，我们实行 PHYS = pc & 0xF8000000，意思是物理RAM必须从偶数的128MB边界上开始。例如从 0x00000000 开始就很好。
这段代码考虑了XIP（execute in place，原地实行）的一些分外情形，例如内核直接从ROM中实行，不过这里不再谈论，由于这种情形更罕见，乃至比不该用虚拟内存的情形还罕见。
还有另一点须要把稳。如果你考试测验过加载一个解压后的内核并勾引，就会创造它对付加载位置非常挑剔——必须放在类似于 0x00008000 或 0x10008000 （假设你的 TEXT_OFFSET 为 0x8000）之类的地址上。而利用压缩后的内核就没有这个问题，由于解压缩程序会将内核解压到得当的位置上（大多数情形下为 0x00008000），以是这个问题办理了。这便是人们常常以为压缩后的内核“更好用”的缘故原由。
给物理地址打补丁，转换成虚拟地址（P2V）
现在我们有了虚拟内存和物理内存之间的偏移量。接下来就会碰着第一个Kconfig符号：CONFIG_ARM_PATCH_PHYS_VIRT。
建立这个符号的缘故原由是，开拓职员须要让内核在不重新编译的情形下，在不同内存配置的系统中勾引。内核可能被编译成在特定的虚拟地址（如 0xC0000000 ）处实行，但实际可能被加载到 0x10000000 （如本文中的例子），也有可能是 0x40000000 或其他地址。
当然，内核中的绝大多数符号不须要担心这一点，由于它们都在虚拟内存中实行，对付它们而言，它们永久在 0xC0000000 处实行。但我们写的不是用户空间的程序，以是事情没那么大略。我们必须知道实行所处位置的物理地址，由于我们便是内核，意思便是我们须要在页表中建立物理地址到虚拟地址的映射，还须要常常更新这些页表。
而且，由于我们并不知道实际运行所处的物理地址，以是没办法依赖诸如编译时常量等技巧。这些技巧即是作弊，而且会造成非常难以掩护的代码。
内核有两个函数可以在物理地址和虚拟地址之间进行转换： __virt_to_phys 和 __phys_to_virt （仅限于内核内存利用的地址）。在内存空间中，这个转换是线性的（每个方向上只需利用一个偏移量），以是大略的加减法就可以实现。因此得名“P2V运行时补丁”。该方法由Nicolas Pitre、Eric Miao和Russell King于2011年发明，2013年Santosh Shilimkar将其扩展并运用到了LPAE系统上，特殊是TI Keystone SoC上。
这里的重点是，如果对付一个物理地址 PHY 和一个内核虚拟地址 VIRT （两者的观点拜会上一幅插图），以下关系成立的话：
PHY = VIRT – PAGE_OFFSET + PHYS_OFFSET
VIRT = PHY – PHYS_OFFSET + PAGE_OFFSET
那么根据算术定律可知，下述关系依然成立：
PHY = VIRT + (PHYS_OFFSET – PAGE_OFFSET)
VIRT = PHY – (PHYS_OFFSET – PAGE_OFFSET)
以是，只需给虚拟地址加上一个常量就可以得到物理地址，给物理地址减去一个常量就可以得到虚拟地址。以是最初的代码大概如下所示：
static inline unsigned long __virt_to_phys(unsigned long x){ unsigned long t; __pv_stub(x, t, \"大众add\公众); return t;}static inline unsigned long __phys_to_virt(unsigned long x){ unsigned long t; __pv_stub(x, t, \"大众sub\公众); return t;}
__pv_stub 包含一个汇编宏，用于实行加法或减法。从那往后，LPAE开始支持多于32位的地址，因此这段代码变得更为繁芜，但基本事理是不变的。
每当在内核中调用 __virt_to_phys 或 __phys_to_virt 时，它们会被更换成一段内联汇编代码（位于 arch/arm/include/asm/memory.h），然后连接器就会将节切换到一个名为 .pv_table 的节上，然后在该节中添加一个指针，指向刚刚添加的汇编指令的位置。这便是说，.pv_table 接会扩展成一个指针的表格，指向所有这些内联汇编代码所在的位置。
在勾引过程中，我们会遍历全体表格，取出每一个指针，检讨指针所指位置的指令，然后利用物理和虚拟内存之间的偏移量对这些指令打补丁。
图：每个利用汇编宏将物理地址转换为虚拟地址的地方，都在勾引过程的前期进行打补丁。
为什么要进行如此繁芜的操作，而不是大略地将偏移量保存到一个变量中呢？这是为了提高效率，由于这些路径会被反复实行。更新页表以及从物理内存到虚拟内核内存的交叉引用的调用，其性能极其关键。所有访问内核虚拟内存的用例，不论是设备块层还是网络层的操作，乃至是用户空间到内核空间的转译，理论上任何流经内核的数据都会在某个韶光点调用这些函数。以是它们必须非常非常快。
这个办理方案并不大略，实际上是非常繁芜的办理方案，但效率非常高！
遍历补丁表
在实际打补丁时，我们会利用前面插图中求出的偏移量给所有的位置打补丁。这是通过调用符号 __fixup_pv_table 实现的，此时就须要用到 r8 中保存的偏移量了：从一个名为 __pv_table 读入五个符号至 r3 ~ r7 中，这五个符号都须要直接引用物理内存地址，接下来用上面说过的方法来增强它们（这便是为何这个表前面有个 .long）：
__fixup_pv_table:adrr0, 1fldmiar0, {r3-r7}mvnip, #0subsr3, r0, r3@ PHYS_OFFSET - PAGE_OFFSETaddr4, r4, r3@ adjust table start addressaddr5, r5, r3@ adjust table end addressaddr6, r6, r3@ adjust __pv_phys_pfn_offset addressaddr7, r7, r3@ adjust __pv_offset addressmovr0, r8, lsr #PAGE_SHIFT@ convert to PFNstrr0, [r6]@ save computed PHYS_OFFSET to __pv_phys_pfn_offset(...)b__fixup_a_pv_table1: .long. .long__pv_table_begin .long__pv_table_end2: .long__pv_phys_pfn_offset .long__pv_offset
这段代码利用第一个值（加载到了 r3 中）打算物理内存的偏移量，然后将其加到其他寄存器上，这样 r4 ~ r7 都直接指向各个标签的物理内存地址。以是 r4 指向保存了 __pv_table_begin 的物理内存地址，r5 指向 __pv_table_end，r6 指向 __pv_phys_pfn_offset，r7 指向 __pv_offfset。如果是C措辞，这些地址都将是 u32 ，即指向32位整数。
__pv_phys_pfn_offset 特殊主要，它的含义是给物理地址打补丁成虚拟地址时须要的偏移量，以是我们首先通过 mov r0, r8, lsr #PAGE_SHIFT，利用前面打算出的 r8 （内核内存相对付0的偏移量，本例中为 0x10000000）对其实行右移操作，然后利用 str r0, [r6] 将结果写入实际保存该变量的位置。这个值在内核启动的前期不会用到，但后面的虚拟内存管理须要用到它。
接下来调用 __fixup_a_pv_table，它会遍历从 r4 到 r5 的每个地址（这个表格中保存的指针指向了须要打补丁的指令），然后利用一个自定义的二进制补丁程序依次打补丁，该程序可以将ARM或THUMB2的指令（指令类型在编译时确定）转换成带有一个立即偏移量的指令，该立即偏移量表示的是物理地址到虚拟地址的偏移量。这段代码非常繁芜，包含了许多奇怪的操作，用来处理大头字节序。
把稳每次内核加载模块的时候也会经历这个步骤，因此该步骤必须知道新的模块是否须要在物理地址和虚拟地址之间进行转换！
以是，所有模块的ELF文件必须包含一个相同类型的 .pv_table 节，而且每次加载模块的时候都会调用这个汇编循环。
设置初始页表
开始在虚拟内存中实行之前，我们必须设置一个MMU转译表，将物理内存映射到虚拟内存。这个表常日称为“页表”，只管初始的映射利用的是节，而不是页。ARM架构哀求页表必须放在物理内存中的偶数16KB边界上。而页表的尺寸也永久是16KB，以是这个哀求很合理。
初始页表的位置由一个名为 swapper_pg_dir 的符号定义，意为“交流页目录”，是内核对于初始页表的称呼。后来，该页表被一个更详细的页表更换（或者说交流，因此得名“交流”页目录）。
“页表”这个名字有点误导，由于个中的初始映射在ARM的术语中实在叫做“节”（section），而不是页。但页表这个词还是被模糊地用来指代“在勾引时卖力将物理地址转译成虚拟地址的那个东西”。
符号 swapper_pg_dir 定义为 KERNEL_RAM_VADDR - PG_DIR_SIZE 。我们来仔细看看。
如你所料，KERNEL_RAM_VADDR 正是内核在虚拟内存中的位置。它便是内核在编译期间被连接到的地址。
KERNEL_RAM_VADDR 的定义为 (PAGE_OFFSET + TEXT_OFFSET)。PAGE_OFFSET 可以是前面谈论过的Kconfig符号的四个位置之一，常日是 0xC0000000。TEXT_OFFSET常日为 0x8000，以是 KERNEL_RAM_VADDR 常日是 0xC0008000，但在某些虚拟内存分割办法或极度的 TEXT_OFFSET 设置下，它也可能是其他的值。TEXT_OFFSET 来自 arch/arm/Makefile中的 textof-y，常日是 0x8000，但在某些高通平台上可能是 0x00208000，在某些博通平台上可能是 0x00108000，以是 KERNEL_RAM_VADDR 可能是 0xC0208000 等。
我们可以确定的是，在连接内核时，这个地址通报给了连接器。检讨ARM架构的连接器文件（arch/arm/kernel/vmlinux.lds.S）就可以看到，连接器确实指示了将其放在 . = PAGE_OFFSET + TEXT_OFFSET。内核被编译成在 KERNEL_RAM_VADDR 指定的地址实行，纵然是我们现在剖析的最早期的代码，也是按照位置无关的办法编写的。
TEXT_OFFSET是一个很小的区域，常日为32KB，在物理空间和虚拟空间中都位于内核RAM上方。图中内核在物理RAM中的位置0x10000000仅仅是一个例子，实际上可以是任意偶数的16MB边界。
把稳内核上方的一小片空隙，最常见的位置是 0xC0000000-0xC0007FFF （TEXT_OFFSET最常见的32KB大小）。虽然它属于内核空间内存的一部分，但内核不会被放入这片内存中。它包含的是初始页表，也可能是勾引程序供应的ATAGs和一些临时区域，如果内核位于 0x00000000 的情形下，这片区域还可以用于中断向量。这里的初始页表当然是供内核利用 的，但后来就被放弃了。
把稳，我们给物理和虚拟内存都加上了同样的 TEXT_OFFSET 区域。这一步其实在解压缩代码的时候就完成了，解压缩的过程会把内核的第一个字节放到 PHYS_OFFSET +TEXT_OFFSET 处，这样内核位置在物理内存和虚拟内存的之间的线性差异可以一贯利用32位字的几个高位比特表示，例如比特24~比特31（8比特），因此只需利用立即数算术运算，在指令中直接加入偏移量即可。从此时开始，内核RAM就必须位于可被16MB（0x01000000）整除的地址上了。
通过给 PAGE_OFFSET 加上 TEXT_OFFSET 的方法，我们在虚拟内存中找到了 swapper_pg_dir 的物理位置，然后退却撤退 PG_DIR_SIZE。常日结果是 0xC0000000 + 0x8000 - 0x4000，以是初始页表将位于虚拟内存中的 0xC0004000处，相应的物理内存中的偏移量（用本例的 PHYS_OFFSET 0x10000000来打算的话）为 0x10004000。
在我们的例子中，swapper_pg_dir符号位于16KB处（0x4000字节），在物理内存中位于.text段之前。在利用传统的ARM MMU时，PHYS_OFFSET为0x10000000，TEXT_OFFSET为0x8000，以是swapper_pg_dir符号位于 0x10004000。
如果利用LAPE，那么页表 PG_DIR_SIZE 为 0x5000，这样就会得到 0xC0003000 的虚拟地址和 0x10003000 的物理地址。汇编宏 pgtbl 会为我们打算该地址：我们用 r8 中计算的物理地址和 TEXT_OFFSET，减去 PG_DIR_SIZE，就得到了初始转译表的物理地址。
初始转译表的构建办法很相似：首先用零添补页表，然后构建初始页表。这些操作位于符号 __create_page_tables 处。
ARM32页表格式
ARM32上的页表布局由两到三层组成。在ARM文档中，两层页表称为“短格式”，而三层页表称为“长格式”。长格式是LPAE（大型物理地址扩展）的一个特性，顾名思义，它用来处理大型物理内存，最多可处理40位物理地址。
这些转译表能够以1MB的节（在LPAE中为2MB，不过暂时先不考虑）或16kB的页为单位对内存进行转译。初始页表利用节，以是初始页表中的内存转译仅限于1MB的节上。
这样可以简化初始映射的操作：节可以直接编码到页表的第一层。这样，一样平常情形下就不须要处理两层构造的繁芜性，可以直接把机器当做只有一层1MB节表来处理。
但是如果在LPAE上运行，那就要处理额外的一层，以是这里要处理最初的两层而不是一层。这便是为何此处会有LPAE代码的缘故原由。它的任务便是在2MB节转译表中插入一个64位的指针。
在传统MMU中，我们仅将MMU指向第一层页表（个中只有1MB的节），而对付LPAE，我们须要一个中间层来访问2MB的节。这些项称为节描述符。
Linux页表的术语
从这里开始，代码中开始包含一些三个字母的缩写。很难说在谈论初始页表时这些缩写是否故意义，但开拓职员习气利用这些缩写。
● PGD：page global directory，全局页目录。这个词指最上面的转译表，全体MMU遍历该表来解析节和页的起始点。在我们的例子中，它指的是物理内存中0x10004000的位置。在ARM32的天下中，我们还会将它写入分外的 CP15 转译表寄存器（有时候叫做 TTBR0），来见告MMU在何处探求转译。如果利用LPAE，它的值便是 0x10003000，留出 0x1000 的空间和一个指向下一层（称为PMD）的64位指针。
● P4D：page 4th level directory（第四层页目录），PUD：page upper directory（上方页目录）是Linux VMM（虚拟内存管理器）中的观点，在ARM中没有利用，由于它用于处理四层或五层转译表，而我们仅利用了两层或三层。
● PMD：page middle directory（中层页目录），是第三层转译的名字，仅在LPAE中利用。这便是为何要给LPAE初始页表保留额外的 0x1000 字节的缘故原由。对付传统的ARM MMU（非LPAE）而言，PMD和PGD是一样的。这便是为什么代码对付传统MMU和LPAE都引用了 PMD_ORDER。由于在Linux VMM的术语中，它被认为是“PTE:s正上方的表格的格式”，由于我们没有利用PTEs，而是利用了节映射，以是“PMD节表”便是映射的终极产物。
● PET:s，页表项，它将RAM从物理内存映射到虚拟内存。初始勾引转译表不会利用它，而是利用节。
再次把稳：对付传统ARM来说，MMU、PGD和PMD是同一个东西。对付LPAE而言，它们是两个不同的东西。有时候这被称为将PMD“折叠”到PGD中。由于我们也可以说“折叠”P4D和PUD，因此这些术语加倍令人迷惑了。
如果你用过虚拟内存，你肯定会反复碰着上述术语。对付我们构建初始“页”的目的而言，完备不须要关心这些术语。我们要构建的只是一个由1MB大小的节组成的列表，卖力将虚拟内存映射到物理内存。此时我们乃至都不会处理页，以是“页”这个术语都令人迷惑。
转译表的二进制格式
在后续谈论中，我们只考虑传统ARM中的MMU。
从物理地址 0x10004000 到 0x10007FFF，共有 0x1000 （4096）个节描述符，每个描述符为32位（4字节）。它们该如何利用呢？
在打开MMU之后，程序计数器和所有的CPU访问都在虚拟地址上进行，以是转译会如下事情：在访问总线之前，将一个虚拟地址转译成物理地址。
由虚拟地址决定物理地址的方法如下：
利用虚拟地址的31-20比特作为索引，查找转译表中的某个32位节描述符。
● 卖力转译虚拟内存中的地址 0x00000000-0x000FFFFF （第一个1MB）的索引位于 0x10004000-0x10004003处，是转译表的第一个四字节，称为索引 0 。
● 卖力转译虚拟地址 0x00100000-0x0001FFFF 的是位于 0x10004004-0x10004007 处的索引1，以是索引编号乘以4便是描述符的字节地址。
● ……
● 虚拟地址 0xFFF00000-0xFFFFFFFF 由位于 0x10003FFC-0x10003FFF 处的索引 0xFFF 转译。
真聪明。0x4000 （16KB）的内存恰好能够超过32位，即4GB的内存空间。以是利用这个MMU表，我们可以将任意1MB的虚拟内存块映射到1MB的物理内存块上。这并不是巧合。
这便是说，如果内核的虚拟基址为 0xC0000000，那么表的索引将是 0xC0000000 >> 20 = 0xC00，由于索引须要乘以4，以是实际的字节索引为 0xC00 4 = 0x3000，以是在物理地址 0x10004000 + 0x3000 = 0x10007000 的地方就能找到内核空间内存的第一个 1MB 的节描述符。
我们利用的32位 1MB节描述的格式大致如下：
MMU 会查看比特0和比特1，其值“10”表示这是一个节映射。然后我们给其他比特设置一些默认值。除此之外，我们真正关心的只有将比特31-20设置为精确的物理地址，而且我们还有一个可用的节描述符。这便是代码的内容。
对付LPAE而言，情形有点不一样：我们利用64位的节描述符（8字节），但同时，节的大小是2MB而不是1MB，以是终极转译表的大小恰好是0x4000字节。
MMU启用代码中的全等映射
首先我们要环绕符号 __turn_mmu_on 创建一个全等映射，表示这段代码将在一段物理地址和虚拟地址1:1映射过的内存上实行。如果代码位于 0x10009012，那么代码的虚拟地址也是 0x10009012。如果查看这段代码就会创造，它被放在一个单独的名为 .idmap.text 的节中。创建单独的节的意思是，这个节会连接到一个单独的物理页上，这个页中没有任何其他东西，以是映射的 1MB 完备供这段代码利用（乃至可能有两个 1MB，如果恰好超过节的边界的话），以是全等映射是专门为这段代码准备的。
仔细考虑一下就会创造这样做很奥妙，纵然超过 2MB 也是如此：如果像本例一样，将内核加载到 0x10000000，那么代码就会位于比如 0x10000120 处，还有一个位于同样地址的全等映射。这不会滋扰到位于 0xC0000000 处的内核，或者在极度的内核内存分割的情形下，也不会滋扰到位于 0x40000000 处的内核。如果有人想把物理内存的起始点放在比如 0xE0000000 处，就会造成大问题。我们希望不会发生这种情形。
映射别的部分
接下来我们创建紧张部分的物理到虚拟内存的映射，从物理内存的 PHYS_OFFSET 处（在前面“在哪里实行”一节中先容过的 r8 中保存的值）和虚拟内存中的 PAGE_OFFSET （编译时的常量）开始，接下来每次移动一页，直达到到虚拟内存中的 _end 符号。该符号位于内核目标代码中的 .bss 节的末端。
在勾引的前期，初始页表 swapper_pg_dir 和1:1映射过的仅包含一页的节 __turn_mmu_on，以及物理到虚拟内存的映射。在本例中，我们没有利用LPAE，以是初始页表为 PHYS_OFFSET 中的 -0x4000，内存的末端为 0xFFFFFFFF。
BSS指的是二进制内核在内存中的末了一节，C编译器会在此处设置所有运行时变量的位置。该节的地址已经定义好，但没有二进制数据：其内存包含未定义的内容（即在映射时个中包含的任何内容）。
这段汇编循环值得好好学习一下，才能理解个中的映射代码如何事情：
ldr r7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags (...) add r0, r4, #PAGE_OFFSET >> (SECTION_SHIFT - PMD_ORDER) ldr r6, =(_end - 1) orr r3, r8, r7 add r6, r4, r6, lsr #(SECTION_SHIFT - PMD_ORDER)1: str r3, [r0], #1 << PMD_ORDER add r3, r3, #1 << SECTION_SHIFT cmp r0, r6 bls 1b
我们来逐步看看。我们假设本例利用的是非LPAE的传统ARM的MMU（你可以认为同样的剖析对付LPAE也成立）：
add r0, r4, #PAGE_OFFSET >> (SECTION_SHIFT - PMD_ORDER
r4 包含页表（PGD或PMD）的物理地址，我们将在那里设置节。(SECTION_SHIFT - PMD_ORDER) 会解析成 (20 - 2) = 18，以是实行 PAGE_OFFSET 0xC0000000 >> 18 = 0x3000，恰好是转译表中 0xC0000000 的绝对索引，跟我们前面看到的一样。这也正常，由于索引是4字节的。以是每当我们看到 (SECTION_SHIFT - PMD_ORDER) 就知道它的意思是“转化成该虚拟地址在转译表中的绝对索引”，在本例中其值为 0x10003000。
以是第一条语句会在 r0 中天生内核空间内存的第一个32位节描述符的物理地址。
ldr r6, =(_end - 1)
r6 显然被设置成内核空间内存的最末端。
ldr r7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags (...) orr r3, r8, r7
r8 包含 PHYS_OFFSET，本例中为 0x10000000 （我们依赖于比特19-0均为零），然后将其与 r7 进行 OR 操作，后者表示MMU的标志，每个CPU有不同的定义，位于 arch/arm/mm/proc-.S 中。每个文件都包含一个分外的节，名为 .proc.info.init，位于索引 PROCINFO_MM_MMUFLAGS （其值大致是 0x08 这样）处是 OR 的右值，这样就可以得到我们所用的CPU对应的节描述符。这个构造体本身的名称为 struct proc_info_list，可以在 arch/arm/include/asm/procinfo.h 中找到。由于汇编无法真正处理C构造体，以是须要利用一些索引技巧才能得到这个邪术术字。
以是，节描述符的物理地址位于比特31-20，r7 中的值会设置更多的比特（如最低两比特），以是MMU就能精确处理节描述符。
add r6, r4, r6, lsr #(SECTION_SHIFT - PMD_ORDER)
这一行会为我们映射的内存的末了一MB构建节描述符的绝对物理索引地址。我们不会在 r7 上实行操作，只是用它作为循环的比较，而不会真正写入转译表，以是不须要。
现在 r0 是我们设置好的第一个节描述符的物理地址，r6是我们将要设置的末了一个节描述符的物理地址。接下来进入循环：
1: str r3, [r0], #1 << PMD_ORDER add r3, r3, #1 << SECTION_SHIFT cmp r0, r6 bls 1b
这段代码将第一个节描述符写入MMU表中的 r0 指向的地址，在本例中从 0x10003000处开始。然后在循环末端给 r0 中的地址增加 ( 1<< PMD_ORDER)，本例中为4。然后给描述符的物理地址部分（比特20及以上）增加1MB，即 (1 << SECTION_SHIFT)，并检讨是否到达末了一个描述符，否则返回 1: 处连续循环。
这样就能建立全体内核（包括所有段和 .bss 的1MB块）的虚拟内存到物理内存的映射。
末了的映射
接下来要映射一些其他的东西，详细来说是映射勾引参数，可以是ATAG，或者是添加的设备树块（DTB）。ATAG常日是内存的第一页（位于 PHYS_OFFSET + 0x0100），而当代DTB常日位于内核的下方。你会创造，将DTB放在内核上方太远的地方是不明智的，由于它可能会越界并回到低地址上。
如果进行调试，那么还须要将串口映射到物理和虚拟内存中指定的地址上。这样才能在虚拟内存中实行时进行调试。
这里再次涌现了“原地实行”的特例：如果在ROM中实行，那就须要将内核从某个分外地址处进行映射，而不是从编译时确定的内存地址处进行。
跳转到虚拟内存
现在险些到了全体 stext 过程的末端，开始实行内核了。
首先调用“procinit”函数，这个函数对付每个CPU类型都不一样。这是一段由C和汇编写成的底层CPU管理代码，位于arch/arm/mm/proc-.S 中。例如，大多数 v7 CPU的初始化代码都在 proc-v7.S 中，而ARM920的初始化代码在 proc-arm920.S中。稍后这些代码会有用，但常日“procinit”的调用都是空的，只有XScale的函数才有实际操作，用于处理勾引程序初始状态中的bug。
procinit函数通过传统的 ret lr 返回，意味着连接寄存器（lr）中的值会赋给程序计数器（pc）。
在进入procinit函数之前， 我们将 lr 设置为标签 1: 的物理地址，从而会相对分支到符号 __enable_mmu。我们还给 r13 赋值为 __mmap_switched 的地址，该符号的地址是编译时确定的，是在MMU启用之后的下一个实行指针处的非相对虚拟地址。我们已经靠近相对代码构建的末端了。
接下来跳转到 __enable_mmu。r4 包含初始页表的地址。我们利用一条分外的 CP15 指令将物理内存中的页表指针加载到 MMU 中：
mcr p15, 0, r4, c2, c0, 0
到目前为止还没发生任何事情。页表地址设置到了MMU中，但还没有在物理地址和虚拟地址之间进行转译。接下来跳转到 __turn_mmu_on。这里会发生许多神奇的事情。__turn_mmu_on 被编译到 .idmap.text 节中，意味着它的物理地址和虚拟地址是一样的。接下来启用MMU：
mcr p15, 0, r0, c1, c0, 0 @ write control reg mrc p15, 0, r3, c0, c0, 0 @ read id reg
现在MMU启用了。下一条指令（恰好是打消指令缓存的指令）将从虚拟内存中实行。最初不会把稳到任何东西，但实际上是在虚拟内存中实行的。在跳转到 r13中的地址以实行返回时，我们会进入该函数的虚拟内存地址中的 __mmap_switched，它位于 PAGE_OFFSET（常日为 0xC0nnnnnn）下方的某处。现在可以进行绝对寻址了，内核会按照预期的办法实行。
图：从物理内存实行切换到虚拟内存实行时，程序计数器上发生的跳转。
现在已经成功地启动了初始页表，终于可以在C编译器认为内核该当在的位置上实行内核了。
重点
__mmap_switched 位于文件 arch/arm/kernel/head-common.S 中，会实行一些分外的事情。
首先是一条非常语句，又是由于原地实行（XIP）：只管内核的 .text 段可以连续在ROM中实行，但无法在 .data 段中保存任何变量。以是首先须要通过将该段复制到RAM中，或者利用某些代码将其解压到RAM中的办法（比较节省芯片）来设置。
接下来将 .bss 段清零，由于Linux内核须要静态变量的初始值为零。其他的C运行时可能不须要这样做，但在运行Linux内核时，你可以可靠地认为在进入函数时静态变量的值为零。
现在机器已经切换到虚拟内存，完备可以实行C运行时环境了。我们还给所有的交叉引用打了物理内存到虚拟内存的补丁。现在统统就绪。
接下来我们将处理器ID、机器类型和ATAG或DTB指针保存下来，然后分支到符号 start_kernel。这个符号会解析成绝对地址，它是 init/main.c 靠下的地方定义的一个C函数。它是完备通用的，任何Linux架构都会调用该函数，以是我们已经到达了C编写的通用内核代码处。
我们来看看现在在哪里。我利用了工具链中的objdump工具来反汇编内核，然后用管道输出至less命令：
arm-linux-gnueabihf-objdump -D vmlinux |less
在less中利用 /start_kernel 命令搜索 start_kernel，然后跳转到第二次涌现的位置：
c088c9d8 <start_kernel>:c088c9d8: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, lr}c088c9dc: e59f53e8 ldr r5, [pc, #1000] ; c088cdccc088c9e0: e59f03e8 ldr r0, [pc, #1000] ; c088cdd0c088c9e4: e5953000 ldr r3, [r5]c088c9e8: e24dd024 sub sp, sp, #36 ; 0x24c088c9ec: e58d301c str r3, [sp, #28]c088c9f0: ebde25e8 bl c0016198 <set_task_stack_end_magic>
非常好！
我们在实行 0xC088C9D8 处的C代码，现在可以随便反汇编和调试内核了。每当碰着随机崩溃转储的情形，我常日会利用同样的方法，合营利用objdump和less来反汇编内核，并搜索崩溃处的符号，来查找可能涌现的问题。
内核开拓职员常用的另一个技巧是启用底层内核调试，并在start_kernel处放置一条print语句，这样就能知道实行到了该点。我个人的做法如下（只需在 start_kernel() 中插入这些行）：
#if defined(CONFIG_ARM) && defined(CONFIG_DEBUG_LL){ extern void printascii(char ); printascii(\公众start_kernel\n\公众);}#endif
可见，要想让类似于此的底层调试print正常事情，须要启用 CONFIG_DEBUG_LL，然后就能在内核的标志“Linux...”打印之前看到一个标志。
Linux的内核开拓职员该当都很熟习该文件和该函数了，以是空隙韶光就可以阅读该文件中的代码。这些代码便是Linux启动的通用代码。
通用代码总是短暂的，由于一下子就要调用setup_arch，又要回到arch/arm中了。我们可以确定的是，初始转译表会被一个更详细的转译表更换。目前还没有用户空间的虚拟内存到物理内存的映射。不过这是其余一个话题了。
原文：https://people.kernel.org/linusw/how-the-arm32-kernel-starts
本文为 CSDN 翻译，转载请注明来源出处。
点分享
