ARM Linux 内核启动1 —— 汇编阶段

一、Makefile分析

1、Makefile 分析

(1) kernel 的 Makefile 写法和规则等，和 uboot 的 Makefile 是一样的，甚至 Makefile 中的很多内容都是一样的。

---

(2) kernel 的 Makefile 比 uboot 的 Makefile 要复杂，这里我们并不会一行一行的详细分析。

(3) Makefile 中只有一些值得关注的会强调一下，其他不强调的地方暂时可以不管。

(4) Makefile 中刚开始，定义了 kernel 的内核版本号。这个版本号挺重要（在模块化驱动安装时会需要用到），要注意会查，会改。

---

(5) 在 make 编译内核时，也可以通过命令行给内核 makefile 传参（跟 uboot 配置编译时传参一样）。譬如 make O=xxx 可以指定不在源代码目录下编译，而到另外一个单独文件夹下编译。

---

(6) kernel 的顶层 Makefile 中定义了 2 个变量很重要，一个是 ARCH，一个是 CROSS_COMPILE 。

ARCH 决定当前配置编译的路径，譬如 ARCH = arm 的时候，将来在源码目录下去操作的 arch/arm 目录。CROSS_COMPILE 用来指定交叉编译工具链的路径和前缀。

---

(7) CROSS_COMPILE = xxx 和 ARCH = xxx 和 O=xxx 这些都可以在 make 时，通过命令行传参的方式传给顶层 Makefile。

所以有时候你会看到别人编译内核时：make O=/tmp/mykernel ARCH=arm CROSS_COMPILE=/usr/local/arm/arm-2009q3/bin/arm-none-linux-gnueabi-

---

2、链接脚本分析

(1) 分析链接脚本的目的，就是找到整个程序的 entry。

(2) kernel 的链接脚本并不是直接提供的，而是提供了一个汇编文件 vmlinux.lds.S，然后在编译的时候，再去编译这个汇编文件得到真正的链接脚本 vmlinux.lds。

(3) vmlinux.lds.S 在 arch/arm/kernel/ 目录下。

---

(4) 思考：为什么 linux kernel 不直接提供 vmlinux.lds ，而要提供一个 vmlinux.lds.S ，然后在编译时才去动态生成 vmlinux.lds 呢？

猜测：.lds 文件中只能写死，不能用条件编译。但是我们在 kernel 中，链接脚本确实有条件编译的需求（但是 lds 格式又不支持），于是 kernel 工作者找了个投机取巧的方法，就是把 vmlinux.lds 写成一个汇编格式，然后汇编器处理的时候顺便条件编译给处理了，得到一个不需要条件编译的 vmlinux.lds。

---

(5) 程序的入口在哪里？从 vmlinux.lds 中 ENTRY(stext) 可以知道，入口符号是 stext，在 kernel 工程中搜索这个符号，发现 arch/arm/kernel/ 目录下的 head.S 和 head-nommu.S 中都有。

---

(6) head.S 是启用了 MMU 情况下的 kernel 启动文件，相当于 uboot 中的start.S 。head-nommu.S 是未使用 MMU 情况下的 kernel 启动文件。

---

二、head.S 文件分析

1、内核运行的物理地址与虚拟地址

(1) KERNEL_RAM_VADDR（VADDR 就是 virtual address），这个宏 定义了内核运行时的虚拟地址。值为 0xC0008000。

---

(2) KERNEL_RAM_PADDR（PADDR 就是 physical address），这个宏 定义内核运行时的物理地址。值为 0x30008000。

---

(3) 总结：内核运行的物理地址是 0x30008000，对应的虚拟地址是 0xC0008000。

---

2、内核的真正入口

(1) 内核的真正入口就是 ENTRY(stext) 处。

(2) 前面的 __HEAD 定义了后面的代码属于 段名为.head.text 的段。

---

3、内核运行的硬件条件

(1) 内核的起始部分代码，是被解压代码调用的。回忆之前讲 zImage 的时候，uboot 启动内核后，实际调用运行的是 zImage 前面的那段未经压缩的解压代码，解压代码运行时，先将 zImage 后段的内核解压开，然后再去调用运行真正的内核入口。

---

(2) 内核启动不是无条件的，而是有一定的先决条件，这个条件由启动内核的 bootloader（我们这里就是 uboot ）来构建保证。

---

(3) ARM 体系中，函数调用时实际是通过寄存器传参的（函数调用时，传参有两种设计：一种是寄存器传参，另一种是栈内存传参）。所以 uboot 中最后 theKernel (0, machid, bd->bi_boot_params); 执行内核时，运行时 实际把 0 放入 r0 中，machid 放入到了 r1 中，bd->bi_boot_params 放入到了 r2 中。ARM 的这种处理技巧刚好满足了 kernel 启动的条件和要求。

---

(4) kernel 启动时，MMU 是关闭的，因此硬件上需要的是物理地址。

但是内核是一个整体（zImage），只能被链接到一个地址（不能分散加载），这个链接地址肯定是虚拟地址。

因此内核运行时，前段 head.S 中尚未开启 MMU 之前的这段代码就很难受。所以这段代码必须是位置无关码，而且其中涉及到操作硬件寄存器等时，必须使用物理地址。

---

三、内核启动的汇编阶段

1、__lookup_processor_type

(1) 我们从 cp15 协处理器的 c0 寄存器中，读取出硬件的 CPU ID 号，然后调用这个函数来进行合法性检验。如果合法则继续启动，如果不合法则停止启动，转向 __error_p 启动失败。

---

(2) 该函数检验 cpu id 的合法性方法是：内核会维护一个 本内核支持的 CPU ID 号码的数组，然后该函数所做的就是：将从硬件中读取的 cpu id 号码，和数组中存储的各个 id 号码依次对比，如果没有一个相等，则不合法，如果有一个相等的，则合法。

---

(3) 内核启动时设计这个校验，也是为了内核启动的安全性着想。

---

2、__lookup_machine_type

(1) 该函数的设计理念和思路，和上面校验 cpu id 的函数一样的。不同之处是本函数校验的是机器码。

---

3、__vet_atags

(1) 该函数的设计理念和思路，和上面 2 个一样，不同之处是用来校验 uboot 给内核的传参 ATAGS 格式是否正确。这里说的传参指的是，uboot 通过 tag 给内核传的参数（主要是板子的内存分布 memtag、uboot 的 bootargs）。

---

(2) 内核认为，如果 uboot 给我的传参格式不正确，那么我就不启动。

---

(3) uboot 给内核传参的部分 如果不对，是会导致内核不启动的。 譬如 uboot 的 bootargs 设置不正确，内核可能就会不启动。

---

4、__create_page_tables

(1) 顾名思义，这个函数用来建立页表。

(2) linux 内核本身被链接在虚拟地址处，因此 kernel 希望尽快建立页表，并且启动 MMU 进入虚拟地址工作状态。

但是 kernel 本身工作起来后，页表体系是非常复杂的，建立起来也不是那么容易的。kernel 想了一个好办法。

(3) kernel 建立页表其实分为 2 步。

第一步，kernel 先建立了一个段式页表（和 uboot 中之前建立的页表一样，页表以 1MB 为单位来区分的），这里的函数就是建立段式页表的。段式页表本身比较好建立（段式页表 1MB 一个映射，4GB 空间需要 4096 个页表项，每个页表项 4 字节，因此一共需要 16KB 内存来做页表），坏处是比较粗，不能精细管理内存；

第二步，再去建立一个细页表（4kb 为单位的细页表），然后启用新的细页表，废除第一步建立的段式映射页表。

(4) 内核启动的早期建立段式页表，并在内核启动的前期使用；内核启动后期，就会再次建立细页表并启用。等内核工作起来之后就只有细页表了。

---

5、__switch_data

(1) 建立了段式页表后，进入了__switch_data 部分，这东西是个函数指针数组。

(2) 分析得知下一步要执行 __mmap_switched 函数。

(3) 复制数据段、清除bss段（目的是构建 C 语言运行环境）。

(4) 保存起来 cpu id 号、机器码、tag传参的首地址。

(5) b start_kernel 跳转到 C 语言运行阶段。

---

总结：汇编阶段其实也没干啥，主要原因是 uboot 干了大部分的工作。

汇编阶段主要就是：校验启动合法性、建立段式映射的页表，并开启MMU，以方便使用内存、跳入 C 阶段。

---

源自朱有鹏老师.