启动：从BIOS到内核的第一声心跳

按下电源开关的那一瞬间，一切都还处于黑暗之中。电流如同苏醒的巨兽，沿着电路板上的铜线脉络奔涌而去，穿过电容、电阻、各类芯片，最终抵达处理器最核心的部位。在这一刻，内存条还是一片混沌的随机电荷，硬盘尚未开始转动，整个系统等待着被唤醒。而就在这电光石火之间，一场从虚无中创造秩序的旅程悄然开始。

这是一个关于数字生命诞生的故事。当那颗小小的处理器收到第一个时钟脉冲时，它并不知道自己即将成为一台计算机的灵魂。它只是忠实地执行着固化在硅片最深处的指令——那是芯片制造商在工厂里烧录进去的只读存储器（ROM），俗称的固件。在x86架构的世界里，这段固件就是我们熟知的BIOS（Basic Input/Output System）或其现代继任者UEFI（Unified Extensible Firmware Interface）。它们是硬件与软件之间的桥梁，是整个计算世界得以运行的根基。本章将带领读者踏上这趟从电路上电到内核初始化的完整旅程，追踪每一步的关键代码，理解计算机为何能够如此优雅地从冰冷的硬件过渡到生机勃勃的操作系统。

BIOS的自检仪式：POST的庄严序幕

当主板通电的瞬间，CPU的复位信号（RESET pin）被激活，处理器进入一个已知的初始状态。Intel 80486及其后续处理器在复位后，CS寄存器被设置为0xF000，IP寄存器被设置为0xFFF0，这意味着CPU的第一条指令地址是物理地址0xFFFF0——这正是BIOS ROM的入口点。这个地址恰好位于4GB地址空间的顶端附近，距离4GB边界只有16字节。芯片设计者选择这个位置绝非偶然，它确保了无论系统拥有多少物理内存，BIOS的入口地址始终是固定且可预测的。

早期的IBM PC设计者们为这个入口点安排了固件初始化的第一条指令——一条远跳转指令，将控制权交给BIOS代码段的正式起始位置。现代BIOS在这段地址之后通常放置一条跳转指令，引导CPU进入实际的初始化代码。

Power-On Self Test（POST，上电自检）是BIOS最神圣的职责。这段代码负责检测系统中最关键的硬件组件是否正常工作。它首先测试CPU的寄存器是否能够正确读写，然后依次检测和初始化主板芯片组、内存控制器、实时时钟（RTC）、中断控制器（8259A或现代的中断路由控制器）、DMA控制器以及键盘控制器。内存测试是POST中最耗时的部分之一，BIOS需要对RAM进行写入和读取测试，以验证每一存储单元都能正确保存数据。早期的内存测试会逐字节进行完整读写，现代BIOS则采用更智能的算法，如棋盘格测试法（Walking Ones/Zeroes）和地址线测试，以更快的速度覆盖更大的地址范围。

```asm ; 简化的内存测试算法伪代码 function memory_test(start_addr, end_addr): for address in range(start_addr, end_addr, step=8): ; 棋盘格写入模式 write_byte(address, 0xAA) ; 10101010 write_byte(address + 1, 0x55) ; 01010101 write_byte(address + 2, 0xAA) write_byte(address + 3, 0x55)

; 验证写入 if read_byte(address) != 0xAA: return FAIL if read_byte(address + 1) != 0x55: return FAIL

; 互补模式测试 for address in range(start_addr, end_addr, step=8): write_byte(address, 0x55) write_byte(address + 1, 0xAA)

if read_byte(address) != 0x55: return FAIL if read_byte(address + 1) != 0xAA: return FAIL

return PASS ```

POST过程还负责建立BIOS数据区（BIOS Data Area，BDA）和中断向量表。0x0000到0x03FF这段1KB的内存区域存放着BIOS运行时的关键数据结构和中断向量。BIOS会在这段地址空间中填充中断向量表，每个中断向量占4字节（CS:IP格式），指向对应的中断处理程序。这些向量在操作系统接管之前为BIOS的设备驱动提供基础服务。

在完成了所有硬件自检后，POST会发出一声短促的蜂鸣——这是主板扬声器发出的POST完成信号。如果用户在此时听到的是长短不一的蜂鸣序列，那意味着硬件检测发现了问题，BIOS正在通过PC扬声器报告错误代码。不同次数和组合的蜂鸣代表着不同的故障类型：内存问题、显卡故障、键盘错误等。

引导设备的抉择：从固件到软件的接力

POST顺利完成之后，BIOS进入了引导顺序（Boot Order）选择阶段。它会按照用户在CMOS设置中指定的顺序，依次尝试从各个存储设备读取引导扇区。最常见的引导设备包括硬盘、固态硬盘、USB闪存驱动器、光盘以及网络启动（PXE）。对于大多数现代系统而言，硬盘（确切地说是其第一个扇区，即主引导记录所在的位置）是默认的引导设备。

BIOS使用传统的BIOS中断服务来完成存储设备的访问。在实模式下，BIOS中断13h（INT 13h）提供了磁盘服务的标准接口。通过这个中断，引导加载程序可以读取磁盘的任意扇区，而无需了解底层控制器（IDE、SATA、NVMe等）的具体实现细节。BIOS负责将请求转换为对应的控制器命令，处理硬件差异，对上层代码屏蔽实现细节。

```c // BIOS INT 13h 磁盘读取参数结构 struct disk_packet { uint16_t packet_size; // 包大小（必须为16） uint16_t block_count; // 要读取的扇区数 uint16_t buffer_offset; // 内存缓冲区偏移地址 uint16_t buffer_segment; // 内存缓冲区段地址 uint64_t lba_number; // 逻辑块地址（48位） } __attribute__((packed));

// 使用扩展INT 13h读取磁盘的示例 void read_sectors(uint8_t drive, uint64_t lba, uint16_t count, void* buffer) { struct disk_packet packet = { .packet_size = 16, .block_count = count, .buffer_offset = (uint16_t)(uint32_t)buffer, .buffer_segment = (uint16_t)((uint32_t)buffer >> 16), .lba_number = lba };

// 通过INT 13h扩展读取 register_t regs = {0}; regs.ah = 0x42; // 扩展读取功能 regs.dl = drive; // 驱动器号 regs.ds = (uint16_t)((uint32_t)&packet >> 16); regs.si = (uint16_t)((uint32_t)&packet & 0xFFFF);

int13h_call(&regs); } ```

当BIOS找到有效的引导设备后，它会从该设备的第一个扇区（扇区0）读取512字节到内存地址0x7C00处。这512字节的结构有着严格的规定：最后的两个字节必须是0x55和0xAA，这个签名（Signature）告诉BIOS这是一个有效的可引导扇区。在0x55AA之前的446字节是主引导记录（MBR）的引导代码区，剩余的64字节是分区表，最后的2字节是引导签名。

主引导记录是整个计算机启动过程中最关键的交接点之一。它虽然只有512字节，却承载着操作系统引导的重要使命。标准的MBR分区表最多支持四个主分区，每个分区项占16字节，记录了分区的起始扇区、大小、分区类型等关键信息。引导代码的任务是扫描分区表，找到标记为可引导（Active）的分区，然后从该分区的第一个扇区读取后续的引导代码。

GRUB：多系统时代的优雅引导者

在个人计算机的早期年代，操作系统直接嵌入在引导扇区中，boot loader简单得只需几行代码。随着DOS和早期Windows的普及，这个模式运行得相当好。但当Linux、BSD、Windows NT等多种操作系统开始在同一台机器上共存时，简单的引导方式已经无法满足需求。用户需要一个能够管理多个操作系统、提供启动菜单、处理不同文件系统的引导管理器——GRUB（GRand Unified Bootloader）应运而生。

GNU GRUB是目前Linux系统最广泛使用的引导加载程序。它的发展经历了两个主要版本：GRUB Legacy（1.x）和GRUB 2（2.x）。现代系统几乎全部使用GRUB 2，它支持更灵活的配置、模块化设计、脚本化配置以及更完善的硬件支持。理解GRUB的工作原理对于深入理解系统启动过程至关重要。

GRUB的引导过程分为多个阶段，这种分层设计体现了软件工程的智慧。Stage 1是最小的引导代码，它被安装在MBR中（有时候安装在分区的引导扇区中）。由于MBR只有446字节可用，Stage 1的代码极其精简，它的唯一任务是定位并加载Stage 1.5。Stage 1.5位于紧跟MBR的扇区中（通常是文件系统启动扇区的位置），它包含了足够的文件系统驱动代码，能够理解特定的文件系统格式（如ext4、btrfs、XFS等），从而能够直接读取/boot/grub目录下的文件。

Stage 2是GRUB的主程序所在，它提供了用户界面——那个我们熟悉的启动菜单。当GRUB 2加载后，它会读取配置文件/boot/grub/grub.cfg，这个文件通常由update-grub或grub-mkconfig工具根据/etc/default/grub和/etc/grub.d/目录下的脚本自动生成。GRUB 2的配置语法支持变量、条件判断、循环等脚本特性，提供了极大的灵活性。

```bash

GRUB 2 配置文件示例 (grub.cfg)

Generated by grub-mkconfig using templates

/etc/default/grub

set default=0 # 默认启动项序号 set timeout=5 # 等待用户选择的时间（秒） set root='hd0,gpt2' # 设置GRUB根分区

menuentry 'Ubuntu' --class ubuntu --class gnu-linux { load_video # 加载视频模块 insmod gzio # 加载压缩解压模块 insmod part_gpt # 加载GPT分区支持 insmod ext2 # 加载ext文件系统支持

echo 'Loading Linux kernel...' # 显示加载信息

加载Linux内核镜像

linux /boot/vmlinuz-5.15.0-generic root=/dev/sda2 ro quiet splash echo 'Loading initial ramdisk...'

加载初始内存文件系统

initrd /boot/initrd.img-5.15.0-generic }

menuentry 'Memory Diagnostic' { insmod part_gpt insmod memdisk echo 'Loading Memtest86+...' linux16 /boot/memtest86+.bin } ```

GRUB 2支持模块化设计，核心代码只包含最基本的功能，其他功能如文件系统支持、硬件检测、加密支持等都以模块形式加载。insmod命令用于加载特定模块，load_video用于初始化视频模式，terminal_output用于设置输出终端。当用户从菜单选择某个启动项后，GRUB会执行linux命令加载内核镜像，initrd命令加载临时根文件系统（initramfs），然后将控制权交给内核。

在加载内核之前，GRUB会做好几项关键工作。首先，它需要将内核镜像从磁盘读取到内存中。Linux内核镜像通常是压缩的（由gzip、xz或lz4等压缩），因此GRUB需要知道内核的解压入口点。其次，如果系统使用了initramfs，GRUB会将其加载到内存的特定位置，内核初始化代码会使用它作为临时根文件系统。最后，GRUB会准备内核启动参数（kernel command line），这些参数通过寄存器传递给内核，告知内核根文件系统位置、控制台设备、内核参数等信息。

从实模式到保护模式：跨越CPU的世纪跨越

当GRUB准备将控制权交给Linux内核时，它面临着一个根本性的挑战：CPU当前运行在实模式（Real Mode）下，而现代Linux内核需要保护模式（Protected Mode）才能发挥全部能力。实模式是x86处理器的16位兼容模式，它源自8086时代，具有1MB地址空间限制和直接内存访问的特点。保护模式则是32位或64位模式，提供虚拟内存、分页、特权级别等现代操作系统所需的功能。

实模式和保护模式的核心差异在于地址转换机制。在实模式下，物理地址通过段寄存器左移4位加上偏移量计算得出：$PhysicalAddress = Segment \times 16 + Offset$。这种简单的地址计算方式意味着任何代码都可以访问任何物理内存，毫无安全性可言。保护模式引入了段描述符表（GDT或LDT）和分页机制，通过硬件级别的检查来隔离不同的内存区域，实现特权级保护。

Global Descriptor Table（GDT，全局描述符表）是保护模式的基础数据结构。每个段描述符占8字节，包含段基地址、段限长、访问权限等信息。CPU通过GDTR寄存器定位GDT，访问内存时，CPU会根据段选择子（Segment Selector）查找对应的描述符，验证访问权限，然后才允许内存访问。

```asm ; GDT设置示例 gdt_start:

; 空描述符（必须的第一项） gdt_null: dq 0x0000000000000000

; 内核代码段描述符 gdt_code: dw 0xFFFF ; 段限长（低16位） dw 0x0000 ; 基地址（低16位） db 0x00 ; 基地址（中高8位） db 10011010b ; 访问权限（存在、可执行、读/执行、特权级0） db 11001111b ; 标志（4K粒度、32位） db 0x00 ; 基地址（高8位）

; 内核数据段描述符 gdt_data: dw 0xFFFF dw 0x0000 db 0x00 db 10010010b ; 访问权限（存在、可写、特权级0） db 11001111b db 0x00

gdt_end:

gdt_descriptor: dw gdt_end - gdt_start - 1 ; GDT限长 dd gdt_start ; GDT基地址

; 加载GDTR并启用保护模式 switch_to_pm: cli ; 禁用中断 lgdt [gdt_descriptor] ; 加载GDT mov eax, cr0 or eax, 0x1 ; 设置PE位（保护模式启用） mov cr0, eax

; 远跳转刷新流水线，加载新的代码段选择子 jmp 0x08:flush_cs

flush_cs: ; 设置数据段选择子 mov ax, 0x10 ; 内核数据段选择子 mov ds, ax mov es, ax mov fs, ax mov gs, ax mov ss, ax

; 更新栈指针 mov esp, 0x9C000 ; 设置临时栈顶 jmp start_kernel ; 跳转到内核入口 ```

对于64位系统，启动过程更加复杂。现代x86_64系统通常采用UEFI启动或传统的BIOS启动，但最终都需要切换到长模式（Long Mode）。长模式是x86-64架构的64位模式，它结合了32位保护模式的基本框架和64位地址能力。启用长模式需要经过多个步骤：首先启用PAE（Physical Address Extension）分页，然后启用IA-32e模式，最后设置64位模式。AMD和Intel在长模式的实现细节上略有差异，但软件层面需要兼容两者。

内核镜像的结构：压缩与自解压

Linux内核镜像并非简单的可执行文件，而是一种特殊的打包格式。当你查看/boot目录下的vmlinuz文件时，你看到的是一个压缩的自解压归档。这个设计的精妙之处在于：它允许内核镜像占用比实际可用空间更小的存储空间，同时提供统一的解压入口点，简化了引导加载程序的工作。

在arch/x86/boot目录下的代码是内核镜像的压缩打包部分。这段代码在构建内核时被打包到内核镜像的头部，负责最基本的初始化和自解压工作。内核镜像的头部结构有着固定的格式，其中包含了一些magic值、负载段位置、解压算法信息等。

``` ┌──────────────────────────────────────────────