《INUXI386引导协议.docVIP

LINUX/I386引导协议 ---------------------------- H. 彼得安文 hpa@ 最后更新于2002-01-01 在i386平台上,Linux内核使用一个相当复杂的引导协定。演变至此，这一方面是由于历史方面的原因，另一方面是由于早期要求将内核本身做成可引导镜像、复杂的PC内存模型，以及因实模式的DOS作为主流操作系统的实际消亡而引发的对PC工业的预期发生的转变。 现在，存在四个版本的Linux/i386引导协议。 旧内核：只支持zImage和Image。有些很早期的内核甚至不支持命令行。 2.00协议：（1.3.73内核） 添加了对bzImage和initrd的支持，以及引导加载程序和内核之 间通信的规范方法。尽管传统的setup区域仍然假定是可写的， 但是Setup.S做成了可 重定位的了。（译者注：setup区域会被旧内核的实模式代码重写，比如0x9XXXX处的命 令行参数。） 2.01协议：（1.3.76内核）添加了堆超出警告。 2.02协议：（2.4.0-test3-pre3内核）新加的命令行协议。降低了传统的内存顶端地址。禁止 重写传统的setup区域，这使得从系统管理模式（SMM）或从32位BIOS调用的入口地 址那里使用扩展BIOS数据区（EBDA）的系统安全引导。zImage不建议使用，但依然支 持。 2.03协议：（2.4.18-pre1内核） 显式地给引导加载程序给出initrd的最高可能地址。 **** 内存布局 传统的Image或zImage使用的内核加载器的典型内存布局如下： | | 0A0000 +------------------------+ | BIOS保留 | 不要使用。保留给BIOS EBDA。 09A000 +------------------------+ | 堆栈/堆/命令行 | 内核实模式代码使用。 098000 +------------------------+ | 内核setup | 内核实模式代码。 090200 +------------------------+ | 内核引导扇区 | 内核遗留引导扇区。 090000 +------------------------+ | 保护模式内核 | 内核镜像块。 010000 +------------------------+ | 引导加载程序 | -引导扇区入口点0000:7C00 001000 +------------------------+ | MBR/BIOS保留 | 000800 +------------------------+ | 一般由MBR使用 | 000600 +------------------------+ | 仅BIOS使用 | 000000 +------------------------+ 当使用zImage时，保护模式的内核要被迁移到0x100000（“高端内存”）处，内核实模式块（引导扇区、setup以及堆栈和堆）被做成可以迁移到从地址0x10000到低端内存地址末尾之间的任何位置。然而，在2.00协议和2.01协议里，命令行依然必须放在0x9XXXX的地址范围，那段范围的内存依然会被早期的内核重写。2.02协议解决了那个问题。 最好保持“内存顶端”，即低端内存中被引导加载程序触摸到的最高点，越低越好。因为一些较新的BIOS已经开始在低端内存顶部附近分配一些相当多数量的内存了，称作扩展BIOS数据区（EBDA）。引导加载程序应该用“INT 12h”BIOS调用检查有多少低端内存可以用。 但是，如果INT 21h报告说内存数量不足，那引导加载程序除了给用户报错外什么也干不了了。因此，引导加载程序要设计得当，尽量少占用低端内存空间。zImage或老的bzImage内核需要在0x90000段内写数据，引导加载程序要确保不要使用0x9A000地址以上的内存，有太多的BIOS会闯入那个地址以上。 **** 实模式内核头 下文以及内核引导系列的任何地方，一个“扇区”指512字节。和底层媒体的实际扇区大小无关。 加载Linux内核的第一步是加载实模式代码（引导扇区和setup代码）然后检测下面的内核头的偏移量0x01f1处。实模式代码最大总共可以有32K，但引导加载程序却可能只选择开始的两个扇区（1K）加载，然后检测启动扇区大小。 内核头如下： 偏移 协议 字段名 释义 /大小 01F1/1 所有