BIOS vs UEFI — 固件的本质 / BIOS and UEFI: Understanding Firmware
📅 创建时间：2026-06-17 🏷️ 标签：#固件 #BIOS #UEFI #CSM #启动 📚 前置知识：[[01-storage-hardware]]
📋 本章目标
- 理解按下电源键到第一条指令执行之间的硬件流程
- 掌握 BIOS 的工作方式——16 位实模式、中断向量表、POST 自检、Legacy 启动
- 理解为什么 BIOS 已经成为"历史的包袱"
- 掌握 UEFI 的革命性变化——32/64 位、GPT、ESP、安全启动
- 理解 CSM 兼容模式：新旧世界的桥梁
- 能够在自己的电脑上判断当前是 BIOS 还是 UEFI 模式
第1部分：按下电源键之后
1.1 CPU 的"第一口奶"
┌─────────────────────────────────────────────────────────────┐
│ 通电启动时序 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 你按下电源键 │
│ ↓ │
│ 2. 电源模块上电，等待电压稳定 │
│ ↓ │
│ 3. 主板"Power Good"信号拉高 │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 4. CPU 的 RESET 引脚从高电平变为低电平（复位解除） │ │
│ │ │ │
│ │ CPU 内部硬件逻辑自动执行： │ │
│ │ ┌──────────────────────────────────────────┐ │ │
│ │ │ 1. 所有寄存器清零（除 CS 和 IP） │ │ │
│ │ │ 2. CS (代码段寄存器) = 0xF000 │ │ │
│ │ │ 3. IP (指令指针) = 0xFFF0 │ │ │
│ │ │ 4. 第一条指令地址 = CS×16 + IP │ │ │
│ │ │ = 0xFFFF0 │ │ │
│ │ │ │ │ │
│ │ │ 这个地址 0xFFFF0 叫做 复位向量 │ │ │
│ │ │ (Reset Vector) │ │ │
│ │ └──────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 5. 地址 0xFFFF0 处的物理内存（映射到主板固件 ROM） │
│ 包含一条 JMP 指令，跳转到固件的入口点 │
│ ↓ │
│ 6. 固件开始执行 —— 这就是 BIOS 或 UEFI 的起点 │
│ │
│ 关键认知: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ CPU 不知道什么是"操作系统" │ │
│ │ 它只知道去 0xFFFF0 读指令，然后执行 │ │
│ │ 0xFFFF0 指向的东西，就是固件 │ │
│ │ │ │
│ │ 固件的工作：初始化硬件 → 找到可启动设备 → 加载 OS │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
1.2 固件的职责
┌─────────────────────────────────────────────────────────────┐
│ 固件的四大职责 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 硬件初始化 (POST / Pre-EFI Initialization) │
│ → 检测和初始化 CPU、内存、芯片组、外设 │
│ │
│ 2. 发现可启动设备 │
│ → 扫描磁盘、USB、网络，找到"能启动的东西" │
│ │
│ 3. 加载并执行引导程序 │
│ → 从磁盘读入 bootloader（GRUB、Windows Boot Manager） │
│ │
│ 4. 提供运行时服务 │
│ → BIOS 中断 (INT 10h 显示, INT 13h 磁盘) │
│ → UEFI 协议 (Block I/O, File System, Graphics) │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
第2部分：BIOS — 来自 1981 年的遗产
2.1 BIOS 的运行环境：16 位实模式
┌─────────────────────────────────────────────────────────────┐
│ 16 位实模式的限制 │
├─────────────────────────────────────────────────────────────┤
│ │
│ CPU 从 RESET 出来时，工作在 实模式 (Real Mode): │
│ │
│ • 16 位寄存器 — 每个寄存器最多存 65535 │
│ • 地址空间 — 1MB（地址线只有 20 根，2^20 = 1MB） │
│ • 寻址方式 — 段地址 × 16 + 偏移 │
│ • 没有内存保护 — 任何代码可以读写任何内存 │
│ • 没有多任务 — 单线程 │
│ │
│ 1MB 地址空间布局: │
│ │
│ 0xFFFFF ┌─────────────────────────┐ │
│ │ BIOS ROM (64KB) │ ← 固件代码在这里 │
│ 0xF0000 ├─────────────────────────┤ │
│ │ 扩展卡 ROM (128KB) │ │
│ 0xD0000 ├─────────────────────────┤ │
│ │ 视频内存 (128KB) │ ← 显存 │
│ 0xB0000 ├─────────────────────────┤ │
│ │ 视频内存 (128KB) │ │
│ 0x90000 ├─────────────────────────┤ │
│ │ 常规内存 (640KB) │ ← OS 和程序只能 │
│ │ │ 用这 640KB │
│ 0x00000 └─────────────────────────┘ │
│ │
│ 这就是著名的 "640KB 应该对任何人都足够了" 的来源 │
│ —— 这不是一个武断的限制，而是 20 位地址线的物理天花板 │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
2.2 BIOS 启动流程
┌─────────────────────────────────────────────────────────────┐
│ BIOS Legacy 启动流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. POST (Power-On Self-Test) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • 检测 CPU 是否正常 │ │
│ │ • 检测并初始化内存控制器 │ │
│ │ • 检测键盘、鼠标等外设 │ │
│ │ • 检测显卡 │ │
│ │ • 蜂鸣器响一声 = 自检通过 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 2. 初始化 BIOS 中断服务 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • INT 10h — 显示服务（写字符、设模式） │ │
│ │ • INT 13h — 磁盘服务（读/写扇区） │ │
│ │ • INT 16h — 键盘服务 │ │
│ │ OS 引导阶段会大量调用这些中断来读磁盘、输出文字 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 3. 扫描启动设备 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 按 CMOS 中配置的顺序: │ │
│ │ HDD → USB → CD-ROM → Network PXE │ │
│ │ │ │
│ │ 对每块磁盘: │ │
│ │ 读 LBA 0 (第一个扇区, 512 字节) │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 4. 检查 MBR 签名 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 读取 LBA 0 的最后两个字节: │ │
│ │ 如果 == 0x55 0xAA → 这是一块可启动磁盘 │ │
│ │ 如果不是 → 跳过，试下一个磁盘 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 5. 执行 MBR 引导代码 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 把 LBA 0 的前 446 字节复制到内存 0x7C00 │ │
│ │ JMP 0x7C00 —— CPU 开始执行 bootloader │ │
│ │ │ │
│ │ 自此，BIOS 的使命结束 │ │
│ │ 控制权交给 bootloader (GRUB / NTLDR / ...) │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
2.3 MBR 的 446 字节 —— 为什么 512 字节扇区是一个诅咒
┌─────────────────────────────────────────────────────────────┐
│ MBR 512 字节布局 (LBA 0) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Offset 大小 内容 │
│ ───────────────────────────────────────── │
│ 0x000 440B 引导代码 (Bootstrap Code) │
│ BIOS 直接跳转到这里的机器码 │
│ │
│ 0x1B8 4B 磁盘签名 (Disk Signature) │
│ 某些 OS 用来识别磁盘 │
│ │
│ 0x1BC 2B 保留 (通常为 0x00 0x00) │
│ │
│ 0x1BE 16B 分区表项 #1 │
│ 0x1CE 16B 分区表项 #2 │
│ 0x1DE 16B 分区表项 #3 │
│ 0x1EE 16B 分区表项 #4 │
│ 每个 16B 包括: │
│ - 1B 活动标志 (0x80 = 可启动) │
│ - 3B CHS 起始地址 │
│ - 1B 分区类型 (0x83=Linux, 0x07=NTFS...) │
│ - 3B CHS 结束地址 │
│ - 4B LBA 起始扇区 │
│ - 4B 扇区总数 │
│ │
│ 0x1FE 2B 魔数 0x55 0xAA （必须！） │
│ │
│ 引导代码只有 440 字节。 │
│ 440 字节能干什么？只能加载另一个更大的加载器。 │
│ GRUB 的第一阶段 (boot.img) 就是这么小。 │
│ │
│ 为什么可以往 MBR 写引导代码？ │
│ → 因为 MBR 所在的扇区不属于任何分区 │
│ → 它是"磁盘最前面、分区表之前"的空间 │
│ → bootloader 安装时直接 dd 进去 │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
2.4 BIOS 的问题总结
┌─────────────────────────────────────────────────────────────┐
│ BIOS 的"罪状" │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 16 位实模式 │
│ → OS 启动后必须自己切换到 32/64 位保护模式 │
│ → 切换过程极其复杂（设置 GDT/IDT、开启 A20 线...） │
│ │
│ 2. 1MB 地址空间 │
│ → bootloader 被限制在 640KB 可用内存 │
│ → 现代内核镜像动辄几十 MB，必须分多次加载 │
│ │
│ 3. MBR 只有 4 个主分区 │
│ → 扩展分区的蹩脚设计由此而来 │
│ │
│ 4. MBR 用 32 位存储扇区总数 │
│ → 最大寻址 2^32 × 512B = 2TB │
│ → 超过 2TB 的磁盘无法用 MBR 格式 │
│ │
│ 5. 各厂商实现不同 │
│ → 没有统一的规范文档 │
│ → 不同主板的 BIOS 行为不一致 │
│ │
│ 6. 没有网络栈/文件系统驱动 │
│ → BIOS 只能通过 INT 13h 读原始扇区 │
│ → 不能直接读文件 │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
第3部分：UEFI — 一次彻底的革命
3.1 UEFI 不是"新版 BIOS"
┌─────────────────────────────────────────────────────────────┐
│ BIOS 和 UEFI 的本质区别 │
├─────────────────────────────────────────────────────────────┤
│ │
│ BIOS UEFI │
│ ───────── ────────────── │
│ 汇编代码 主要用 C 编写 │
│ 16 位实模式 32/64 位保护/长模式 │
│ 1MB 地址空间 完整 64 位地址空间 │
│ MBR 分区表 GPT 分区表 │
│ 读原始扇区 文件系统驱动（读 FAT） │
│ 单线程 支持多任务 │
│ 无网络 有 TCP/IP 网络栈 │
│ 文本界面 支持 GUI │
│ 无安全机制 安全启动 (Secure Boot) │
│ │
│ 关键认知: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ UEFI 本身就是一个微型操作系统 │ │
│ │ 它能理解文件系统、能连网、能显示图形界面 │ │
│ │ 它不需要像 BIOS 那样"跳到磁盘的第一个扇区" │ │
│ │ 它可以直接读取 ESP 分区里的 .efi 文件并执行 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
3.2 ESP — EFI System Partition
┌─────────────────────────────────────────────────────────────┐
│ ESP 分区详解 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ESP 是一个普通的 FAT32 格式分区 │
│ （FAT32 是 UEFI 规范唯一要求支持的读文件系统格式） │
│ │
│ 分区类型 GUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B │
│ │
│ 典型内容: │
│ │
│ /boot/efi/ │
│ └── EFI/ │
│ ├── BOOT/ │
│ │ └── BOOTX64.EFI ← 默认的 fallback 启动文件 │
│ ├── Linux/ │
│ │ └── grubx64.efi ← GRUB 的 EFI 可执行文件 │
│ └── Microsoft/ │
│ └── Boot/ │
│ └── bootmgfw.efi ← Windows Boot Manager │
│ │
│ UEFI 做的事: │
│ 1. 扫描所有磁盘的 ESP 分区 │
│ 2. 读取 NVRAM 中的启动项列表 │
│ 3. 运行对应的 .efi 文件 │
│ │
│ 为什么是 FAT32？ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ FAT32 是最简单的文件系统，实现驱动力小 │ │
│ │ UEFI 固件自带一个 FAT32 驱动力，直接读文件 │ │
│ │ 写一个 FAT32 驱动力只需要几百行 C 代码 │ │
│ │ NTFS/ext4 的驱动力动辄上万行，固件 ROM 放不下 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
3.3 UEFI 启动流程
┌─────────────────────────────────────────────────────────────┐
│ UEFI 启动流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. Pre-EFI Initialization (PEI) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • 初始化最基本的硬件（CPU、芯片组、少量内存） │ │
│ │ • 发现并初始化系统内存 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 2. Driver Execution Environment (DXE) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • 加载各种驱动（PCI 总线、USB、磁盘、网络...） │ │
│ │ • 建立完整的硬件驱动栈 │ │
│ │ • 此时已具备访问文件和网络的完整能力 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 3. Boot Device Selection (BDS) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • 读取 NVRAM 中的启动项 (Boot#### 变量) │ │
│ │ • 按 BootOrder 顺序依次尝试 │ │
│ │ • 启动项格式: │ │
│ │ "从 PCI(0x1,0x0)/SATA(0x0,0x0)/HD(1,GPT,...) │ │
│ │ /\\EFI\\Linux\\grubx64.efi" │ │
│ │ │ │
│ │ 这是一条"设备路径"——描述了如何找到 .efi 文件 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 4. 加载并执行 .efi 文件 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ .efi 是一个标准的 PE/COFF 可执行文件 │ │
│ │ （和 Windows .exe 同格式，但不依赖 Windows） │ │
│ │ 固件加载它、重定位、调用 Entry Point │ │
│ │ │ │
│ │ GRUB → grubx64.efi │ │
│ │ systemd-boot → systemd-bootx64.efi │ │
│ │ Windows → bootmgfw.efi │ │
│ │ Linux 内核自身 → 可以直接编译为 EFI Stub │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 5. 控制权交给 bootloader/OS │
│ │
│ 注意：UEFI 运行在保护模式/长模式下 │
│ → OS 启动时不需要做"实模式→保护模式"的切换 │
│ → 可以通过 UEFI 提供的 GOP 协议直接设置高分辨率显示 │
│ → 可以通过 UEFI 内存映射获得完整的物理内存布局 │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
3.4 Secure Boot（安全启动）
┌─────────────────────────────────────────────────────────────┐
│ 安全启动原理 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 问题: 恶意软件可以替换 ESP 里的 grubx64.efi │
│ UEFI 会不加区分地执行它 → 从启动阶段就被控制 │
│ │
│ 解法: Secure Boot │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 固件里存有一套受信任的证书 (Platform Key / KEK / db)│ │
│ │ │ │
│ │ 执行 .efi 文件前: │ │
│ │ 1. 检查 .efi 的签名是否有效 │ │
│ │ 2. 签名证书链是否回溯到受信任的根证书 │ │
│ │ 3. 如果验证通过 → 执行 │ │
│ │ 如果失败 → 拒绝执行 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 对 Linux 用户的影响: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ • Microsoft 签名的 shim 作为中间层 │ │
│ │ • 或自行注册 Machine Owner Key (MOK) │ │
│ │ • Arch Linux 的 GRUB 支持 Secure Boot │ │
│ │ • 不想折腾 → 在固件设置中关闭 Secure Boot │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
第4部分：CSM — 新旧世界的桥梁
4.1 CSM 是什么
┌─────────────────────────────────────────────────────────────┐
│ CSM 兼容模式 │
├─────────────────────────────────────────────────────────────┤
│ │
│ CSM = Compatibility Support Module │
│ 在 UEFI 固件中嵌入一个 BIOS 模拟层 │
│ │
│ 架构: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ UEFI 固件 │ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ CSM 模块 (可选) │ │ │
│ │ │ 模拟 BIOS 中断 (INT 10h/13h/16h) │ │ │
│ │ │ 提供 Legacy 启动路径 │ │ │
│ │ │ 允许 MBR 方式启动 │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 当 CSM 开启时: │
│ → 固件会同时尝试 UEFI 和 Legacy 两种启动方式 │
│ → 可以安装 Windows 7 这种不支持 UEFI 的系统 │
│ │
│ 当 CSM 关闭时: │
│ → 只能 UEFI 启动 │
│ → GPT 分区表必须、ESP 分区必须 │
│ → 需要 64 位引导程序 │
│ │
│ 趋势: 越来越多的固件默认关闭 CSM │
│ Microsoft 要求 Windows 11 必须 UEFI + Secure Boot │
│ Intel 正在推动到 202X 年彻底移除 CSM │
│ │
└─────────────────────────────────────────────────────────────┘1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
第5部分：如何判断你的电脑
5.1 在 Linux 下检查
bash
# 方法1: 检查 /sys/firmware/efi 是否存在
ls /sys/firmware/efi
# 如果存在 → 当前是 UEFI 模式启动
# 如果不存在 → 当前是 BIOS/Legacy 模式启动
# 方法2: 用 efibootmgr 查看 UEFI 启动项
efibootmgr
# 如果有输出 → UEFI 模式
# 如果报错 "EFI variables are not supported" → Legacy 模式
# 方法3: 查看固件类型
cat /sys/class/dmi/id/bios_version
dmesg | grep -i efi1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
核心总结
总结1：BIOS 和 UEFI 的分水岭
BIOS: 16 位实模式 → MBR → 读扇区 → 512 字节启动代码
UEFI: 32/64 位 → GPT → 读文件 → 直接执行 .efi 文件1
2
2
总结2：ESP 的本质
ESP = 一个 FAT32 格式的分区，UEFI 固件能直接读里面的文件
它不是神秘的"系统保留区"，就是一个普通 FAT32 分区
所有 OS 的启动文件都放在这里，共享这同一个分区1
2
3
2
3
总结3：UEFI 的三大改进
1. 启动前有完整 OS 能力——文件系统、网络、GUI
2. 直接从 GPT 磁盘读取 .efi 文件执行，不需要"扇区 0 的 446 字节"
3. Secure Boot 建立启动链的信任基础1
2
3
2
3
章节测试
测试1：复位向量
CPU 通电后的第一条指令从哪里读取？这个地址叫什么？
测试2：BIOS 的内存上限
BIOS 的 1MB 地址空间限制的根源是什么？
测试3：MBR 魔数
BIOS 如何判断一个磁盘是否可启动？
测试4：ESP 为什么是 FAT32
UEFI 规范为什么选择 FAT32 作为 ESP 的文件系统？
测试5：CSM
什么是 CSM？为什么它正在被淘汰？
测试6：模式判断
你在 Linux 终端运行 ls /sys/firmware/efi 返回了 "No such file or directory"。这意味着什么？
参考答案
测试1答案
第一条指令从地址 0xFFFF0（物理内存）读取。对于 Intel x86 CPU，CS=0xF000, IP=0xFFF0，物理地址 = CS×16 + IP = 0xFFFF0。这个地址叫做复位向量（Reset Vector），指向主板固件 ROM 的入口。
测试2答案
根源是 CPU 只有 20 根地址线。2^20 = 1MB。这不是软件限制，而是硬件限制。80286 增加到 24 根线（16MB），80386 增加到 32 根线（4GB）。
测试3答案
读取 LBA 0（第一个扇区）的最后两个字节，如果等于 0x55 0xAA，则这是一块可启动磁盘。这两个字节被称为 MBR 签名/魔数。
测试4答案
因为 FAT32 是最简单的文件系统，实现一个 FAT32 驱动只需要几百行 C 代码。UEFI 固件的 ROM 空间有限（通常 16-32MB），放不下 ext4/NTFS 这类复杂文件系统的驱动。FAT32 是无专利负担的通用标准，微软、苹果、Linux 都能读。
测试5答案
CSM（Compatibility Support Module）是在 UEFI 固件中模拟 BIOS 的兼容层，允许用传统 MBR 方式启动旧系统。它正在被淘汰是因为：维护成本高、阻碍 Secure Boot 推广、微软和 Intel 都在推动纯 UEFI 生态。
测试6答案
你当前是 BIOS/Legacy 模式启动的。/sys/firmware/efi 只在 UEFI 启动时存在，它是内核暴露的 efivarfs 接口。不存在意味着内核没有检测到 UEFI 运行时服务，系统是通过传统的 BIOS → MBR → bootloader 路径启动的。
相关笔记
- [[01-storage-hardware]] - 固件操作的"磁盘"到底是什么
- [[03-partition-table]] - GPT 和 MBR 分区表的底层结构
- [[06-linux-boot]] - Linux 启动链：UEFI 之后的 GRUB→内核→登录
下一步学习
- [ ] 阅读 03 - 磁盘分区表：GPT 与 MBR
学习状态：🟡 开始学习