08-内核入口_head.o

5.2.1　内核入口： head.o

内核开发人员的意图是想让 head.o 这个与架构相关的模块通用化，不依赖于任何机器^[9]类型。这个模块是由汇编语言源文件head.S生成的，它的具体路径是.../arch//kernel/head.S，其中替换成具体的架构名称。本章中的例子基于ARM/XScale架构，我们已经都看到了，=arm。

[9]　这里的机器指的是具体的硬件平台。

head.o 模块完成与架构和CPU相关的初始化，为内核主体的执行做好准备。与CPU相关的初始化工作尽可能地做到了在同系列处理器中通用。与机器相关的初始化工作是在别处完成的，很快你就会看到。 head.o 还要执行下列底层任务：

• 检查处理器和架构的有效性；
• 创建初始的页表（page table）表项；
• 启用处理器的内存管理单元（MMU）；
• 进行错误检测并报告；
• 跳转到内核主体的起始位置，也就是文件main.c中的函数 start_kernel() 。

这些功能很复杂。很多嵌入式开发的新手都曾尝试单步调试这些代码，但最终发现调试器并不能派上用场。这些复杂的功能是由汇编语言实现的，并且涉及虚拟内存的硬件细节，虽然相关讨论超出了本书的范围，但是对于这个复杂的模块，有几点还是需要特别注意一下。

当启动加载程序将控制权第一次转交给内核的 head.o 时，处理器运行于我们过去常说的实地址模式（real mode，这里使用了x86架构中的术语）。处理器的程序计数器^[10]或其他类似寄存器中所包含的地址值称为逻辑地址（logical address），而处理器的内存地址引脚上的电信号地址值称为物理地址（physical address）。实际上，在实地址模式下，这两个值是相同的。为了启用内存地址转换，需要先初始化相关的寄存器和内核数据结构，当这些初始化完成后，就会开启处理器的MMU。在MMU开启的一瞬间，处理器看到的地址空间被替换成了一个虚拟地址空间，而这个空间的结构和形式是由内核开发者决定的。要想真正理解这个复杂的过程，需要仔细分析汇编语言源代码的逻辑流程，并且非常清楚CPU中的硬件地址转换机制。简而言之，当MMU的功能开启时，物理地址被替换成了逻辑地址。这就是为什么调试器不能像调试普通代码一样单步调试这段代码的原因。

[10]　一般称为指令指针（Instruction Pointer），是寄存器中记录了下一条机器指令的内存地址。

第二点需要注意的是，在内核引导过程的早期阶段，地址的映射范围是有限的。很多开发者都曾尝试修改 head.o 以适应特定平台^[11]，但因为这个限制的存在而犯错。一个典型的场景如下，假设你有一个硬件设备，而你需要在系统引导的早期阶段加载一个固件（firmware）。一种解决方案是将必需的固件静态编译到内核镜像中，然后使用一个指针引用它，并将它下载到你的设备中。然而，由于是在内核引导的早期阶段，其地址映射存在限制，很有可能固件镜像所处的位置超出了这个范围。当代码执行时，它会产生一个页面错误（page fault），因为这时你想访问一个内存区域，但处理器内部还没有建立起对应这块区域的有效映射。更糟糕的是，在早期阶段，页面错误处理程序还没有安装到位，所以最终结果会是莫名其妙的系统崩溃。在系统引导的早期阶段，有一点非常确定，不会有任何错误消息能够帮助你找到问题所在。

[11]　不建议修改定制平台中的head.S，一般都会有其他更好的办法。

明智的做法是考虑尽可能推迟所有定制硬件的初始化工作，直到内核完成引导之后。用这种方式，你可以使用众所周知的设备驱动程序模型来访问定制硬件，而不是去修改复杂很多的汇编语言启动代码。这一层级的代码使用了很多技巧，而它们都没有说明文档可供参考。这方面最常见的一个例子就是解决硬件上的一些错误，而这些错误可能有文档说明，也可能没有。如果你必须修改汇编语言早期启动代码，你需要在开发时间、费用和复杂度等方面付出更高的代价。硬件和软件工程师应该在硬件开发的早期阶段讨论这些现实问题，此时往往硬件设计的一个小的改动就能够节省大量的软件开发时间。

在虚拟内存环境中，开发人员会面临一些约束，认识到这一点很重要。很多有经验的嵌入式开发人员都不太熟悉这种环境，我们刚刚提到的那个场景只不过是一个小的示例，如果你是一位对虚拟内存架构不太了解的开发人员，会碰到很多类似的陷阱。几乎所有主流的32位或更高位微处理器都包含了内存管理的硬件单元，用于实现虚拟内存架构。虚拟内存机器有一个显著优点，它能够帮助不同团队的开发人员编写大型复杂的应用程序，同时保护其他软件模块和内核本身，使它们不受编程错误的影响。