引导程序与系统启动
CPU 上电时内存是空的，操作系统还在磁盘上——谁把它搬进内存？引导程序，一层一层接力搬。
CPU 上电后 PC 指向一个固定地址（ROM 映射区），里面只有一小段固件，磁盘上的内核还远在天边。这一章解决一个问题：怎么从”CPU 刚通电、什么都没加载”走到”内核在内存里跑起来”？
要解决什么
| 阶段 | 问题 |
|---|---|
| 上电 | CPU 只能执行 ROM 里的固件，RAM 还没初始化 |
| 找内核 | 内核在磁盘/Flash 上，但固件不认得文件系统 |
| 加载 | 加载到哪？怎么跳过去？权限怎么交接？ |
思路：一次性搬不完，就分好几层接力。每层只负责找到下一层并加载。
怎么解决的：分层引导
各层在哪
| 层 | 存放位置 | 典型大小 | 职责 |
|---|---|---|---|
| 固件（BIOS / UEFI） | 主板 ROM / Flash | 几 MB | 硬件自检 + 初始化 + 找引导设备 |
| 第一级引导（MBR / SPL） | 磁盘第 0 扇区 / 片内 SRAM | 446 B / 几十 KB | 找到第二级引导，加载到 RAM |
| 第二级引导（GRUB / U-Boot） | /boot 分区 / Flash | 几百 KB | 提供菜单、识别文件系统、加载内核 |
| 内核 | /boot/vmlinuz / Flash 固定偏移 | 几 MB | 接管一切 |
每一层只盯一个问题：下一层在哪、怎么装进来。装完就把控制权交过去。
x86 传统 BIOS 流程
上电 → BIOS(POST自检) → 读 MBR(磁盘第0扇区, 446B 代码)
→ MBR 找活动分区 → 加载分区引导记录(PBR)
→ PBR 加载 GRUB stage2 → GRUB 显示菜单
→ 加载内核到内存 → 跳内核入口，CPU 切保护模式/长模式
- MBR 只有 446 字节代码空间，连文件系统驱动都装不下，只能靠分区表硬编码扇区号来找 GRUB
- GRUB stage2 才真正支持文件系统（ext4、FAT 等），能从
/boot读内核
UEFI 流程
上电 → UEFI 固件(POST + 初始化) → 读 GPT 分区表
→ 找 ESP 分区(FAT32) → 直接读 EFI 可执行文件(.efi)
→ 加载内核 → 跳内核入口
UEFI 天生认得 FAT32，不需要 MBR 那套”446 字节硬编码扇区号”的 hack。GPT 替代了 MBR 分区表（支持 >2T 磁盘、128 个分区）。
ARM 嵌入式（以 Cortex-A + U-Boot 为例）
上电 → ROM Boot(固化在芯片内)
→ 加载 SPL(Secondary Program Loader) 到片内 SRAM
→ SPL 初始化 DDR → 加载 U-Boot 到 DDR
→ U-Boot 初始化外设 + 网络/tftp → 加载内核到 DDR
→ 跳内核，CPU 切到 EL1
ROM Boot 只能加载几十 KB 到片内 SRAM，所以 SPL 必须小。SPL 唯一的新增能力是初始化 DDR 控制器——DDR 一初始化，几百 MB 空间就有了，U-Boot 就能装进去，后续事情就好办了。
嵌入式里 U-Boot 还常兼做固件更新：上电时检测按键/标志，决定进”刷机模式”还是正常引导。
三套方案对比
| 传统 BIOS + MBR | UEFI + GPT | ARM 嵌入式 | |
|---|---|---|---|
| 固件位置 | 主板 ROM | 主板 Flash | 芯片内 ROM |
| 分区表 | MBR（4 主分区，<2T） | GPT（128 分区，无 2T 限制） | 无，裸分区 |
| 第一级大小 | MBR 446 B | ESP 分区（通常 100~512 MB） | SPL 几十 KB（片内 SRAM） |
| 文件系统 | GRUB stage2 才支持 | 固件天生支持 FAT32 | U-Boot 支持 ext4/FAT |
| 内核位置 | /boot | /boot | Flash 固定偏移 / SD 卡 |
| 安全启动 | 无 | Secure Boot（验签名） | 芯片 fuse 验签名 |
有什么局限
- MBR 的 446 字节是硬伤：甚至不够装一个 FAT32 解析器，GRUB 只好分 3 个阶段（stage1/1.5/2），复杂度高
- SPL 受片内 SRAM 限制：若 DDR 控制器初始化复杂、代码膨胀，SPL 可能装不下，需要再分一级（TPL → SPL → U-Boot）
- 启动速度：分层越多越慢。嵌入式常跳过 U-Boot、直接从 SPL 跳内核（Falcon mode）
- 安全：传统 BIOS 没有任何签名验证，UEFI Secure Boot 和 ARM 的 fuse 签名是对策
如果你正在跟随梳理, 返回 MOC←