你有没有想过这个问题:按下电源键的一瞬间,CPU 的 CS:IP 寄存器指向哪里?是谁把它设置成那个值的?为什么开机后屏幕亮起来,你看到的是一个选择菜单,而不是一片黑屏?
这不是魔法,是一条漫长的接力链——从 CPU 上电那一刻,到 GRUB 把控制权交给内核,中间经历了至少三个阶段:BIOS/UEFI 固件 → Bootloader(GRUB) → OS 入口点。每一棒都有严格交接手续,不是谁都能跑下一程的。
今天,我们来拆解这条链路——BIOS、UEFI、GRUB 是怎么一步步把控制权交到你写的 OS 代码手上的。
BIOS 时代的启动:0xFFFF0 是怎么来的
CPU 上电的第一跳
x86 CPU 上电后,第一件事不是读硬盘,是认死理——CS = 0xFFFF,IP = 0x0000,形成物理地址 CS << 4 + IP = 0xFFFF0。这个地址在 640KB 主内存之外(靠近 1MB 顶端),是留给 BIOS ROM 用的。
CPU 上电瞬间:
CS = 0xFFFF
IP = 0x0000
────────────────
物理地址 = 0xFFFF0(ROM BIOS 入口点)BIOS ROM 在这个地址放了一条 jmp 指令,跳到真正的初始化代码。这就是整个系统软件的第一条指令——不是 Linux,不是 GRUB,是 BIOS 固化在 ROM 里的一条跳转。
POST 和硬件自检
BIOS 做的第一件正事是 POST(Power-On Self Test):检查 CPU、内存、显卡、键盘控制器有没有问题。如果 POST 失败,你听到的是一串蜂鸣声(不同的蜂鸣模式代表不同的故障);如果成功,屏幕会亮起来,显示厂商 Logo。
POST 检查顺序:
① CPU 测试(寄存器、标志位)
② 内存检测(通过 SPD 读取 DIMM 大小)
③ 显卡初始化(显示 BIOS 启动画面)
④ 键盘/鼠标/USB 初始化
⑤ CMOS 配置读取(启动顺序、频率设置)实模式下的磁盘启动
POST 完成后,BIOS 按照启动顺序(Boot Order)依次尝试每种启动设备:
启动顺序(典型 CMOS 配置):
1. NVMe SSD(UEFI 模式)
2. SATA HDD(UEFI 模式)
3. USB Drive(UEFI 或 Legacy)
4. 光驱(Legacy only)
5. 网络(PXE,Legacy)对于传统 BIOS(Legacy)模式启动,BIOS 会读取磁盘的第一个扇区(MBR,0 柱 0 磁头 1 扇区,共 512 字节),把它加载到内存 0x7C00 处,然后检查最后 2 字节是否是 0x55AA(可启动标志):
# 用 hexdump 看 MBR 的结尾标志
hexdump -C /dev/sda -n 512 | tail -2
# 输出:000001fe 00 00 00 00 00 00 00 00 00 00 00 00 aa 55
# ^^^^
# 可启动标志 0x55AA如果 MBR 有 0x55AA,BIOS 就跳转到 0x7C00 处执行——把控制权交给 Bootloader 的第一棒。
实模式内存布局(启动初期)
0x00000 ────────────────── 0x9FFFF:常规内存(640KB)
0xA0000 ────────────────── 0xBFFFF:VGA显存(128KB)
0xC0000 ────────────────── 0xFFFFF:硬件映射区
0xC0000 - 0xC3FFF:VGA BIOS ROM(显卡固件)
0xE0000 - 0xEFFFF:系统 BIOS 扩展(部分机器)
0xF0000 - 0xFFFFF:系统 BIOS ROM(512KB,包含启动代码)
0xFFFF0:BIOS 入口点(CPU 上电跳到这里)
0x7C00:MBR 被加载的地址(GRUB 第一阶段代码从这里开始)UEFI 时代:不再需要 MBR
BIOS 的历史局限
Legacy BIOS 有几个根本性缺陷:
- 只能读磁盘第一个扇区:512 字节塞进所有启动代码,根本不够用
- 实模式限制:只能访问 1MB 内存,无法驱动超过 2TB 的磁盘(用 48-bit LBA 才能超过)
- 没有安全验证:任何代码都能运行,rootkit 可以藏在 MBR 里
UEFI 的设计
UEFI(Unified Extensible Firmware Interface)用 GPT(GUID Partition Table)替代 MBR,用 EFI 分区(FAT32 文件系统)存储 Bootloader。
GPT 磁盘结构:
┌────────────────────────────────────────────────────────────┐
│ Protective MBR(兼容旧BIOS,指向GPT头) │
├────────────────────────────────────────────────────────────┤
│ GPT Header(位置在 LBA 1,包含分区表位置、分区数量等) │
├────────────────────────────────────────────────────────────┤
│ 分区表(通常在 LBA 2-33,每个分区有唯一 GUID) │
├────────────────────────────────────────────────────────────┤
│ 分区 1:EFI System Partition(ESP,FAT32,≥100MB) │
│ 分区 2:Linux 分区 │
│ 分区 N:... │
└────────────────────────────────────────────────────────────┘ESP 分区里放的是 .efi 文件——不是裸二进制,是符合 PE/COFF 格式的可执行文件。这和 Windows 的 .exe 是同一套格式,所以 UEFI 能同时启动 Windows Boot Manager 和 GRUB。
UEFI 启动流程
① 上电 → UEFI 固件初始化(比 BIOS 快,因为它有 C 语言级别的驱动栈)
② 读取 NVRAM 里的 BootOrder(启动顺序列表)
③ 按顺序尝试加载 \EFI\Boot\BootX64.efi(默认)或 NVRAM 里注册的条目
④ 验证签名(Secure Boot)或直接执行(非 Secure Boot)
⑤ 找到 .efi 文件后,跳到它的入口点——控制权交给 BootloaderSecure Boot 是 UEFI 的安全机制:固件里内置了微软/厂商的公钥,只有签名过的 .efi 才能启动(即使磁盘被拆走塞入另一台机器也启动不了)。
# 查看当前机器的 Secure Boot 状态(Linux)
cat /sys/firmware/efi/efivars/SecureBoot-* 2>/dev/null
# 输出:5 0 0 0 表示 Secure Boot 已启用(数据第三个字节为 1)
mokutil --sb-state # 更友好的查看方式两个世界的分叉
Legacy BIOS 模式:
MBR(512B) → Bootloader Stage 1 → Stage 2(GRUB) → Kernel
UEFI 模式(无 Secure Boot):
EFI System Partition → *.efi 文件 → Kernel(或 GRUB)
UEFI 模式(Secure Boot):
EFI System Partition → *.efi(签名验证) → Kernel(或 GRUB)UEFI 不需要 MBR,所以 UEFI 模式下安装的系统,磁盘前 512 字节可能是空或只含 protective MBR(GPT 兼容层)。这也是为什么"用 MBR 修复工具修复 UEFI 安装的系统"通常无效——根本就没用 MBR。
GRUB:承上启下的 Bootloader
为什么需要 GRUB
问题来了:固件(BIOS 或 UEFI)只知道"加载某个扇区"或"执行某个 .efi 文件",它怎么知道哪个文件是 Linux 内核?内核文件可能很大(10MB+),放不进一个扇区,也不可能让固件理解 ELF 格式。
答案是:需要一个中间人,来理解文件系统 + 加载内核。GRUB 就是这个中间人。
GRUB 的两阶段加载
第一阶段(Stage 1):存放在 MBR 里(446 字节),只有最最基本的启动代码。它的工作是加载 Stage 1.5。
Stage 1.5(通常在 MBR 后的扇区,或嵌入在 GPT 的 BIOS Boot 分区):这部分代码能理解文件系统(ext4/XFS/FAT),从而能读取 Stage 2 的文件(/boot/grub/normal.mod 等)。
Stage 2:真正的 GRUB 主程序,支持菜单、命令行、配置文件(grub.cfg)。
GRUB 加载链:
MBR(Stage 1, 446B) → 读文件系统 → Stage 1.5(理解分区格式)
↓
Stage 2(grub.cfg、菜单)
↓
加载 Linux kernel + initramfsGRUB 和 Multiboot 协议
GRUB 和 Linux 之间的"交接手续"靠 Multiboot 协议。内核文件在开始处放一个特殊的 header:
; multiboot.S(见 demos/multiboot)
.section .multiboot
.align 4
.long 0x1BADB002 /* magic = GRUB 认识这个值 */
.long 0x00010003 /* flags = 需要内存信息和图形模式 */
.long -(0x1BADB002 + 0x00010003) /* checksum = 必须为零 */GRUB 看到这 3 个 long(12 字节),就知道:
- magic = 0x1BADB002:这个文件是 Multiboot 兼容的内核
- flags = 0x00010003:告诉 GRUB"我需要哪些信息"(内存映射、命令行等)
- checksum:校验 magic + flags 是否正确(防损坏)
交接时,GRUB 设置好寄存器:
- eax = 0x2BADB002(magic,证明 GRUB 已加载)
- ebx = boot_info 结构体指针(内存映射、命令行、模块列表等)
- 关闭保护模式之前的实模式环境,切换到平坦模型
GRUB 加载 Linux 内核的实际步骤
# /boot/grub/grub.cfg(简化)
menuentry 'Arch Linux' {
load_video
set root='hd0,gpt2' # 第二分区(Linux root)
linux /boot/vmlinuz-linux root=/dev/sda2 # 加载内核镜像
initrd /boot/initramfs-linux.img # 加载临时文件系统
}GRUB 加载 Linux 流程:
① 读取 vmlinuz(gzip 压缩的 ELF)
② 解压到 0x100000(1MB 处,这是 Linux 的惯例入口)
③ 读取 initramfs(cpio 格式的临时根文件系统)
④ 跳转到 0x100000,开始执行 Linux 的入口点Linux 内核入口点:是 /arch/x86/boot/header.S 里的 _start。这段代码在 arch/x86/boot/compressed/ 里,职责是解压内核(如果启用了 CONFIG_KERNEL_GZIP),然后跳到真正的内核入口 startup_32 或 startup_64。
vmlinuz 结构(压缩内核):
[compressed kernel image(gzip)] + [setup code + boot protocol header]
GRUB 跳到这里 → header.S 的 _start:
① 确认启动标志(0x01B0 处的 word)
② 设置 edx = boot_params 指针(内存布局信息)
③ 解压(如果需要)
④ 跳到 0x100000 + 偏移(真正的内核入口)wandos 的第一条指令:boot.asm 分析
wandos 的 boot 代码在 /tmp/wandos/ 里(需要确认目录结构)。一个典型的 PC Bootloader 汇编如下(参考 PC Boot Protocol):
; wandos/boot/boot.asm(参考结构)
bits 16
section .text
global _start
_start:
; CPU 上电后第一条指令在这里(GRUB 加载点)
cli ; 关闭中断(保护模式切换前)
xor ax, ax
mov ds, ax
mov es, ax
mov ss, ax
mov sp, 0x7C00 ; 设置栈(向下生长)
; 开启 A20 地址线(访问 1MB 以上内存)
in al, 0x92
or al, 2
out 0x92, al
; 进入保护模式(GDT 已在 GRUB 或 wandos 设置)
lgdt [gdt_descriptor]
mov eax, cr0
or eax, 1 ; CR0.PE = 1(保护模式开启)
mov cr0, eax
; 远跳转到 32 位代码段
jmp 0x08:protected_mode
bits 32
protected_mode:
; 现在是平坦模型(4GB 线性地址空间)
mov ax, 0x10 ; 数据段选择子
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
mov ss, ax
; 跳到 C 入口点 kernel_main()
extern kernel_main
call kernel_main
; 停机
jmp $wandos 和 Linux 的对比:
- wandos 假设 GRUB(或其他 bootloader)已经建立了 GDT;Linux 有自己的 boot protocol,可以不依赖 GRUB 的 GDT
- wandos 的入口是 kernel_main()(C 函数);Linux 的入口是 startup_32(汇编),再做模式切换到 C 代码
- wandos 是简化的教育内核,没有 initramfs 解压链路;Linux 的启动链路更复杂(有解压、ACPI 探测、多核 Init 等)
Linux 实践:观察自己的启动链路
查看 GRUB 菜单配置
# 查看当前系统的 GRUB 配置
cat /boot/grub/grub.cfg | grep -A5 'menuentry'
# 或者更友好的方式(不编辑文件)
grep "^menuentry" /boot/grub/grub.cfg查看内核启动参数
# 当前内核的启动参数(GRUB 传给内核的)
cat /proc/cmdline
# 输出示例:
# BOOT_IMAGE=/boot/vmlinuz-linux root=/dev/sda2 mitigations=auto这些参数就是 GRUB 的 linux /boot/vmlinuz... 行传给 Linux 的——Linux 在 /arch/x86/kernel/head_64.S 里解析这些参数。
手动查看 MBR 内容
# 读取当前磁盘的 MBR(仅前 512 字节)
dd if=/dev/sda bs=1 count=512 2>/dev/null | hexdump -C | tail -5
# 分区表(MBR 里 64 字节分区表,从 0x1BE 开始)
# 每条分区记录 16 字节,最多 4 条(主分区)
dd if=/dev/sda bs=1 count=512 2>/dev/null | hexdump -C | sed -n '1p;2p'查看 UEFI 启动条目
# 用 efibootmgr 查看 UEFI NVRAM 里的启动条目
sudo efibootmgr -v
# 输出示例:
# BootOrder: 0001, 0000
# Boot0001* Arch Linux HD(1,GPT,...)/File(\EFI\arch\grub.efi)
# Boot0000* Windows Boot Manager HD(2,GPT,...)/File(\EFI\Microsoft\Boot\bootmgfw.efi)手动触发 GRUB 命令行(观察启动过程)
# 重启,在 GRUB 菜单按 'c' 进入命令行模式
grub> ls # 列出所有设备
grub> ls (hd0,gpt1)/ # 查看第一个 GPT 分区内容
grub> linux (hd0,gpt2)/boot/vmlinuz-linux root=/dev/sda2 # 手动加载内核
grub> boot # 手动启动从零实现:写一个最小化的 Multiboot 内核
参考 demos/multiboot/:
; multiboot.S — 最小 Multiboot 内核
.section .multiboot
.align 4
.long 0x1BADB002
.long 0x00010003
.long -(0x1BADB002 + 0x00010003)
.text
.global _start
.type _start, @function
_start:
# GRUB 已经把 eax=0x2BADB002, ebx=boot_info 指针设置好
movw $0x10, %ax
movw %ax, %ds
movw %ax, %es
movw %ax, %fs
movw %ax, %gs
movw %ax, %ss
movl $0x90000, %ebp
movl %ebp, %esp
cli
call kernel_main
jmp .// main.c — 内核主函数
void kernel_main(unsigned long magic, void *boot_info) {
if (magic != 0x2BADB002) while(1);
// GRUB 成功加载了我们
}编译并用 GRUB 启动:
as --32 multiboot.S -o multiboot.o
gcc -m32 -fno-pie -c main.c -o main.o
ld -m elf_i386 -Ttext 0x100000 -o kernel.elf multiboot.o main.o
grub-mkrescue -o kernel.iso kernel.elf
qemu-system-i386 -cdrom kernel.iso踩坑与注意事项
坑 1:MBR 被破坏后系统无法启动
现象:重装 Windows 后,Linux 的 GRUB 消失了(Windows 安装程序会覆盖 MBR)。
原因:Windows 的安装程序只认 Windows,不扫其他 OS 的 Bootloader。
解决:用 Linux Live USB 启动,运行 grub-install /dev/sda 重建 GRUB。
# 从 Live USB 启动后
mount /dev/sda2 /mnt
grub-install --boot-directory=/mnt/boot /dev/sda坑 2:UEFI + Legacy 混合模式导致启动混乱
现象:装了双系统后,有时进 Windows,有时进 GRUB菜单。
原因:有些机器的 CSM(Compatibility Support Module)同时启用了 UEFI 和 Legacy 模式,磁盘的 ESP 分区和 MBR 同时存在,启动优先级不稳定。
解决:在 BIOS/UEFI 设置里明确选"UEFI Only"或"Legacy Only",不混用。
坑 3:GRUB 找不到内核(UUID 变了)
现象:换了硬盘或重新分区后,GRUB 报 "Unknown filesystem"。
原因:GRUB 用 UUID 或 PARTUUID 定位内核,grub.cfg 里的 UUID 和实际磁盘不匹配。
解决:用 blkid 查实际 UUID,手动更新 grub.cfg,或用 grub-mkconfig -o /boot/grub/grub.cfg 自动重建。
写在最后
从按下电源键到内核第一条指令,这条链路是接力赛,不是魔法:
CPU 上电 → BIOS/UEFI 固件 → MBR/ESP → GRUB Stage 1/2
→ Multiboot Header 验证 → GRUB 加载内核到 0x100000
→ 内核入口点(startup_32/startup_64)→ kernel_main()GRUB 和内核之间靠 Multiboot 协议交接,magic + checksum + boot_info 结构体,这就是标准的"签证"。
wandos 的 boot 代码是简化版(依赖 GRUB 建 GDT),Linux 有完整的 boot protocol + 解压流程 + initramfs 多级加载——教育内核和工业内核的差距就在这里。
下篇预告(361):下一个候选方向——第一个用户态进程(init 之前世:从内核启动到 /sbin/init 的完整链路),或者 TTY 与终端:键盘中断是怎么变成 shell 提示符的。你选哪个?
仓库:https://github.com/golang12306/os-kernel-from-scratch
相关阅读
- Linux Kernel Source:
arch/x86/boot/header.S(Linux 的 Multiboot 兼容 header) - Linux Kernel Source:
arch/x86/boot/compressed/(内核解压链路) - Linux Kernel Source:
arch/x86/entry/entry_64.S(64 位入口点) - GRUB Manual: https://www.gnu.org/software/grub/manual/grub/
- Multiboot Specification: https://www.gnu.org/software/grub/manual/multiboot/
- https://github.com/zhangfuwen/wandos — Linux 内核教程
动手环节
想深入理解本文内容?动手实践是最好的方式:
今天的目标:下载 wandos 代码仓库,找到 boot.asm,对比它和 Linux boot protocol 的差距,然后编译运行。
-
下载 wandos:
bash git clone https://github.com/zhangfuwen/wandos.git cd wandos -
找到对应模块:在
boot/目录下找到boot.asm(或等效的启动汇编),读懂它的 GDT/保护模式切换逻辑 -
编译 Multiboot 内核(参考 demos/multiboot/):
bash as --32 multiboot.S -o multiboot.o gcc -m32 -fno-pie -c main.c -o main.o ld -m elf_i386 -Ttext 0x100000 -o kernel.elf multiboot.o main.o grub-mkrescue -o kernel.iso kernel.elf qemu-system-i386 -cdrom kernel.iso -
观察 QEMU 里的启动过程:在 GRUB 菜单按
c进入命令行,手动linux /boot/kernel.elf看 GRUB 如何加载
提示:wandos 采用 C++ + x86 汇编实现,参考 boot/ 下的现有代码风格,注释清楚再提交。
仓库:https://github.com/golang12306/os-kernel-from-scratch
夜雨聆风