读Kernel感悟-Linux内核启动-setup辅助程序

文章来源：http://www.top-e.org/jiaoshi/class/

 

我们发现，在起点与终点之间，还有几个中转站。最近的一站叫作MBR。BIOS，带你到MBR后，说：“对不起，只能送你到这里了。”

那其它几个中转站是什么呢？我们知道，在x86上，保护模式有两种，32位页式寻址的保护模式和32位段式寻址的保护模式。显然，32位页式寻址的保护模式要求系统中已经构造好页表。从16位实地址模式直接到32位页式寻址的保护模式是很有难度的，因为你要在16位实地址模式下构造页表。所以不妨三级跳，先从16位实地址模式跳到32位段式寻址的保护模式，再从32位段式寻址的保护模式跳到32位页式寻址的保护模式。

我们需要这样一个程序，负责从16位实地址模式跳到32位段式寻址的保护模式，然后设置eip，启动内核。这个程序的确存在，就是arch/i386/boot/setup.S。最后汇编成setup程序。

事实上，平时所见的压缩内核映象bzImage，其实由三部分组成。这可以从arch/i386/boot/tools/build.c中看出来。build.c是用户态工具build的源代码，后者用来把bootsect(MBR),setup(辅助程序)和vmlinux.bin(压缩过的内核)拼接成bzImage。

setup有了，它可以启动内核，然而新的问题来了。谁来启动setup呢？第一个想到的是MBR。可惜，MBR只有512个字节，而且有64个字节来存放主分区表。这样看来，MBR的功能就很有限了。所以，最好在setup和MBR之间再架一座桥梁。引导程序，对，用它来引导setup再合适不过了。现有的引导程序如grub,lilo不仅功能强大，而且还提供了人机交互的功能。再合适不过了。

所以，我们理清了大概思路，查阅相关资料可知：

1.CPU加电，从0xffff0处，执行BIOS（可以理解为“硬件”引导BIOS）

2.BIOS执行扫描检测设备的操作，然后将MBR读到物理地址为0x7c00处。然后从MBR头部开始执行（可以理解为BIOS引导MBR）

3.MBR上的代码跳转到引导程序，开始执行引导程序的代码，例如grub（引以理解为BIOS引导boot loader）。

4.引导程序把内核映象(包括bootsect，setup，vmlinux)读到内存中，其中setup位于0x90200处，如果是zImage，则vmlinux.bin位于0x10000（64K）处。如果是bzImage，则vmlinux.bin位于0x100000（1M）处。然后执行setup（可以理解为boot loader引导setup）

5.setup负责引导linux内核vmlinux.bin

现在，让我们看看setup做了些什么。

首先，运行一下file setup

它报告说这是一个MS DOS的可执行程序。看来，file也有不正常工作的时候。不过有一点是肯定的。setup不是普通的elf可执行程序。事实上，gcc可以编译出各种格式的程序，具体可以运行objdump -i，查看ld（gcc的链接器）支持的输出格式。其中有一个是binary格式。

从start开始，setup做了很多操作，例如，如果是zImage，则把它从0x10000拷贝到0x1000，调用bios功能，查询硬件信息，然后放在内存中供将来的内核使用，然后建立临时的idt和gdt，负责把16位实地址模式转化为32位段式寻址的保护模式。前面这些我们不关心。我们关心的是后者：

_

832         movw    $1, %ax                         # protected mode (PE) bit

833         lmsw    %ax                             # This is it!

正是以下指令开启了保护模式的大门。

最后，再临门一脚

对bzImage来说：

jmpi    0x100000,__BOOT_CS

对zImage来说：

jmpi    0x1000,__BOOT_CS

就大功告成了。

不过，且慢，由于当时CS寄存器还没有设置为__BOOT_CS，所以，尽管在保护模式下，也仍然不能用通常的方式访问大于1M的内存。

不过，x86处理器提供了特殊的手段来访问大于1M的内存，那就是在指令前加前缀0x66。由于跳转地址与内核大小相关（zImage和bzImage不一样）所以用一个小技巧，即把该指令当作数据处理。在计算机看来，指令和数据是没什么区别的，只要ip寄存器指向内存中某地址，计算机就把地址中的数据当作指令来看待。

854         .byte 0x66, 0xea                        # prefix + jmpi-opcode

855 code32: .long   0x1000                          # will be set to 0x100000

856                                                 # for big kernels

857         .word   __BOOT_CS

我不仅发出感慨：看setup.S的代码真是一种痛苦的体验，并且有以下感悟：

1.为什么不用C写呢？

原因很简单，因为setup要尽量短小精悍，由于种种原因，它的大小不能超过63.5K.启动时内存分配如下：

0x00000~0x00400 BIOS中断向量表

0x00400~0x01000

0x01000~0x10000

0x10000~0x8f000 用来存放zImage所以最多508K

0x8f000~0x90000 引导程序的命令行参数以及bios查询的信息

0x90000~0x90200 MBR

0x90200~0xA0000 setup

0xA0000~0x100000 映射到BIOS和外设硬件等

0x100000~ 存放bzImage(如果大于508K)

2.如何引用变量？

在setup.S中，定义了不少全局变量。在编译生成setup文件时，链接参数

LDFLAGS_setup    := -Ttext 0x0 -s --oformat binary -e begtext

意为text段的地址为0，输出格式为binary（而不是默认的elf32-i386），入口地址begtext。

由于基本上处于16位实模式下，所以只要设置好CS等段寄存器就可以正确地寻址了。

现在我们跳到vmlinux.bin的开头(位于0x1000或者0x100000)，也就是startup_32()，执行相应代码。

3.helloworld，vmlinux，arch/i386/boot/compressed/vmlinux，setup,bootsect的区别与联系。

这几个可执行文件都是由gcc编译生成。只是格式不一样。

其中，helloworld,vmlinux,arch/i386/boot/compressed/vmlinux都是elf32_i386格式的可执行文件。setup，bootsect是binary格式的可执行文件，它们的区别在于

1).helloworld是普通的elf32_i386可执行文件。它的入口是_start。运行在用户态空间。变量的地址都是32位页式寻址的保护模式的地址，在用户态空间。由shell负责装载。

2).vmlinux是未压缩的内核，它的入口是startup_32(0x100000，线性地址)，运行在内核态空间，变量的地址是32位页式寻址的保护模式的地址，在内核态空间。由内核自解压后启动运行。

3).arch/i386/boot/compressed/vmlinux是压缩后的内核，它的入口地址是startup_32(0x100000，线性地址).运行在32位段式寻址的保护模式下，变量的地址是32位段式寻址的保护模式的地址。由setup启动运行。

4).setup是装载内核的binary格式的辅助程序。它的入口地址是：begtext（偏移地址为0。运行时需要把cs段寄存器设置为0x9020）。运行在16位实地址模式下。变量的地址等于相对于代码段起始地址的偏移地址。由boot loader启动运行。

5).bootsect是MBR上的引导程序，也为binary格式。它的入口地址是_start()，由于装载到0x7c00处，运行时需要把cs段寄存器设置为0x7c0。运行在16位实地址模式下。变量地址等于相对于代码段起始地址的偏移地址。由BIOS启动运行。

问题出现了。startup_32有两个，分别在这两个文件中：

arch/i386/boot/compressed/head.S

arch/i386/kernel/head.S

那究竟执行的是哪一个呢？难道编译时不会报错么？