1. 从第三次作业说起：系统引导与程序装载到底在拼什么
如果你正在被操作系统课程的第三次作业折磨，说明你已经碰到了这门课第一个真正硬核的分水岭。先亮明观点：系统引导与程序装载，表面上只是让一台裸机把磁盘里的内核镜像读进内存再跳转过去，实际上它把实模式寻址、中断调用、内存布局、链接脚本、汇编调用约定全部串成了一条完整的数据链。我在某高校完成这份作业时，前两次上机几乎全灭，QEMU窗口要么黑屏要么反复重启，直到我把每一个失败症状记录下来、逐条对照寄存器状态排查，才真正想明白引导程序不是“写一段代码”，而是在一个资源精确到字节的环境里完成一次受控交接。
很多同学第一次拿到这份作业会困惑：为什么课程组不直接给一个能用的引导框架，非要让我们从零手写？我的理解是，这个项目恰好卡在“硬件细节”和“软件抽象”的交界处。后面你要学进程调度、虚拟内存、文件系统，这些概念全都建立在 CPU 已经能稳定取指执行的前提上；而“稳定取指执行”这件事，恰恰是引导代码和装载代码用一条条 INT 指令、一次次内存搬运铺出来的。只有亲手处理过 512 字节的空间限制，你才会明白操作系统内核镜像为什么需要自己的链接脚本，为什么不能随便编译完就扔到磁盘上。这份作业的产出物不大，但信息密度极高。
这篇复盘我会按我当时的推进顺序来写：先拆解引导扇区那 512 字节的每一处细节，再讲内核装载时读盘、选址、跳转的完整链路，然后把我踩过的三个典型启动失败症状做成一个排查记录，最后聊几点作业之外我认为值得继续深挖的东西。如果你也卡在“为什么我的引导代码没反应”或者“内核明明读进来了却不执行”，这篇应该能帮你少走一大截弯路。
1.1 为什么这一步必须手写，不能直接上现成框架
站在课程设计者的角度，这一关没法用现成引导加载器替代。因为引导装载本质上是在回答三个基础问题：计算机开机后第一条指令从哪里来？CPU 凭什么相信磁盘第一扇区是可执行代码？内核镜像被搬到内存后，怎么确保它看到的地址和链接时看到的地址一致？
这三个问题如果只是看书，五分钟就能背下来；但只有自己写一遍，才会掉进那些真正决定成败的坑里。比如“0xAA55 放在引导扇区最后两个字节”，听起来只是一句话，实际操作时你得先把汇编代码变成二进制，再算好填充长度，最后精确地把 0x55 0xAA 写到第 510、511 字节，漏掉任何一步，BIOS 都会直接拒绝引导。再比如“用 INT 13h 读磁盘”，光是把 CHS 三个参数换算对，就足以让第一次做的人折腾半个晚上。这些过程没法靠“读一遍概念”来掌握，只能靠动手碰壁。
我把这次作业理解为一次“最小化启动链路”实验。引导扇区是起点，内核装载是桥梁，最终在屏幕上输出一行来自内核的信息是终点。它排除了所有无关模块，逼你把注意力集中在地址、指令、数据和设备交互这些最底层的要素上，而这正是后续理解任何操作系统机制的基础。
1.2 作业的核心交付物与执行链路
从交付形态看，最终要产出的东西其实很朴素：
- 一个不超过 512 字节的引导扇区二进制（boot.bin）；
- 一个被装载到指定内存地址的内核镜像（kernel.bin）；
- 一个能生成上述二进制并写入磁盘镜像的构建脚本；
- 一个用于启动验证的虚拟机运行脚本。
整个系统从上电到运行内核，大致会走这样一条链路：BIOS 自检完成后，读取磁盘第 0 磁头第 0 柱面第 1 扇区的 512 字节，检查末尾魔数，合法的话把这段代码搬到物理地址 0x7C00，然后用跳转指令进入引导代码；引导代码初始化环境后，通过磁盘中断把后续扇区里的内核镜像读入内存的某个指定位置；最后引导代码把执行权交给内核入口。这个流程里每一步都藏着一个或多个容易出错的分支，理解整条链路比单独抠某条汇编指令更有价值。
2. 引导扇区手写实录：实模式下 512 字节的生存战
2.1 从 BIOS 到 0x7C00：你的代码是怎么被“搬”进内存的
第一次打开引导扇区反汇编输出时，我很不理解为什么代码明明写在引导扇区里，运行地址却要固定在 0x7C00。后来查资料才弄明白，这个地址是 IBM PC 时代就定下来的硬件约定：0x7C00 往上是引导代码可用的内存区域，往下则留给了中断向量表、BIOS 数据区等系统结构。BIOS 在自检后会把引导扇区从磁盘搬到这个固定位置，然后设置 CS:IP 指向它。所以你的引导代码在编译链接时，必须按照“将要运行在 0x7C00”这个事实来安排内存访问。
这里就引出了实模式最核心的地址换算规则：物理地址等于段寄存器左移四位再加偏移地址。比如我当时的引导代码开头有这样一段：
.code16 .globl start start: cli xorw %ax, %ax movw %ax, %ds movw %ax, %es movw %ax, %ss movw $0x7c00, %sp stixorw %ax, %ax先把 AX 清零，再把 DS、ES、SS 全部归零，这样后续访问内存时，段基址就是 0，偏移地址直接等于物理地址，省去很多换算上的心理负担。栈指针 SP 设置成 0x7C00，是因为栈在实模式下通常是向下生长的，从 0x7C00 开始往下压栈，就不会覆盖掉位于低地址的 BIOS 中断向量表，也不会往上顶掉正在执行的引导代码。别小看这几行寄存器初始化，我后面踩的“跳转后自动重启”的坑，根因就是忘了给 SS 和 SP 一个合理值。
2.2 引导代码的骨架：每一条指令都在解决什么问题
除去环境初始化，引导扇区里还必须完成几类工作：在屏幕上输出提示信息、读取磁盘上的内核镜像、设置跳转参数、最后把控制权交给内核。输出提示信息最简单直接的做法是调用 BIOS 的INT 10h字符显示服务：
movw $0x0e41, %ax # 0x0e 表示滚动 Teletype 模式，0x41 是字符 'A' movw $0x0f00, %bx # 页面号 0，颜色属性 0x0f int $0x10这种“用中断干一切”的写法和现代操作系统里“用系统调用干一切”的思想很像。在实模式下，BIOS 就是最底层的驱动程序库，它帮你屏蔽了显卡寄存器、磁盘控制器的复杂细节。不过这里有个非常明显的分界线：引导阶段可以用 BIOS 中断，一旦跳进 32 位内核，BIOS 中断基本就失效了，所有硬件访问都得换成直接操作端口和内存映射寄存器。这也是为什么很多内核入口的第一件事就是重新设置段寄存器、加载 GDT、切换到保护模式。
引导扇区的代码量不大，但每一字节都要精打细算。当时的 Makefile 里有一段检查逻辑：
$(BOOT_BIN): boot.S $(CC) -m32 -c boot.S -o boot.o $(LD) -m elf_i386 -Ttext 0x7c00 boot.o -o boot.elf $(OBJCOPY) -O binary -j .text boot.elf $@ @if [ $$(stat -c%s $@) -gt 512 ]; then echo "boot.bin too large"; exit 1; fild -Ttext 0x7c00是关键，它告诉链接器，这段代码运行时会被放在 0x7C00，之后所有绝对地址引用都会按这个基址计算。如果你不指定这个地址，链接器默认从 0 开始排布，生成的跳转地址就是错的，机器一开机执行第一条指令就会跑飞。
2.3 0xAA55：不是玄学，是 BIOS 和引导扇区之间的契约
引导扇区最后两个字节必须是 0x55 0xAA，这个细节几乎是所有初学者最先背下来的知识点，但它背后其实是一种非常朴素的校验思路：BIOS 读到 512 字节后，会先看偏移 510 和 511 处的值，只有匹配魔数才认为这个扇区是可引导的，否则就尝试下一个启动设备。
实际操作中有一个容易忽略的点：魔数在二进制文件里的字节顺序是 0x55 在前、0xAA 在后。我在汇编里这样声明：
.org 510 .word 0xaa55.org 510会把当前位置推进到文件偏移 510，.word 0xaa55按小端序在内存里写入 0x55 0xAA。如果你用手工方式填充，也要记住是先写 0x55 再写 0xAA。我见过有人把两个字节写反，结果 BIOS 怎么都不认这个盘，还以为是虚拟机镜像路径配置错了。排查到最后才发现只是顺序问题，那种感觉真的又气又好笑。
3. 内核装载完整链路：从读盘到跳转，每个地址都得算明白
3.1 用 INT 13h 读盘前，先搞清楚扇区几何
引导扇区完成自检和输出后，下一步就是把磁盘上后续扇区里的内核镜像搬进内存。这一步最常用的入口是 BIOS 的磁盘服务INT 13h，功能号AH=2表示读取扇区。调用前需要准备好一堆参数：
AL：要读取的连续扇区数；CH：柱面号低 8 位；CL：扇区号（低 6 位）加上柱面号高 2 位；DH：磁头号；DL：驱动器号，0x80 通常表示第一块硬盘；ES:BX：数据被读入的内存缓冲区地址。
我当时第一次看到 CL 既要装扇区号、又要拼柱面号的高位，就觉得这个设计很别扭。后来想想也合理，这是为了在 24 位空间里塞下 CHS 三元组，属于历史遗留的紧凑编码。实操时只要记住：软盘镜像里常见的参数组合是柱面 0、磁头 0、起始扇区 2，那么CH=0, DH=0, CL=2, DL=0x80。如果内核镜像比较大，需要跨多个磁道读取，那就得自己维护递增逻辑，每读完一段就调整 CH/CL/DH，再继续发下一次 INT 13h。
我在这里踩过一个印象深刻的坑：读盘前忘了把 ES 设置成目标段地址，只改了 BX。ES 还停留在引导代码刚启动时的 0，结果内核数据被读到了物理地址很低的位置，直接把中断向量表抹掉了一部分。症状表现为：引导代码运行正常，但跳转前系统已经处于半损坏状态。修复方法也很简单，每次发起磁盘读取前，统一设置：
movw $0x1000, %ax movw %ax, %es xorw %bx, %bx也就是让ES:BX指向0x1000:0x0000，物理地址 0x10000。
3.2 装载地址为什么选在 0x10000
内核镜像放在哪个内存地址，是整份作业里最需要想清楚的决策之一，因为它直接影响链接脚本和跳转指令。我最后用的装载地址是物理地址 0x10000，也就是段 0x1000、偏移 0 的位置。选择这个地址有三个理由：
第一，它避开了实模式下低端 1MB 里的许多保留区域。比如 0xA0000 到 0xBFFFF 是 VGA 显存和设备内存区，不能乱占；0x7C00 附近正住着引导代码；而 0x10000 属于比较干净的常规内存区，从 1MB 往下的 RAM 都能用。
第二，它离引导代码足够远，不会在搬运内核时覆盖掉正在执行的引导代码。如果读盘目标地址和引导代码所在地址重叠，搬运过程就可能一边执行一边把自己改掉，结果不可预测。
第三，从 0x10000 开始是个整页边界。地址对齐在底层开发里永远值得多看一眼，虽然实模式下不涉及分页，但后续如果内核要开启保护模式、加载页表，在一个对齐边界上起步会更省力。
确定装载地址后，内核的链接脚本就要明确告诉链接器：
OUTPUT_FORMAT(binary) SECTIONS { . = 0x10000; .text : { *(.text) } .data : { *(.data) } .bss : { *(COMMON) *(.bss) } }这段脚本的含义是：所有代码段、数据段从物理地址 0x10000 开始排布。如果你这里写的是 0x0000，而引导代码按 0x10000 搬运内核，那内核入口函数里所有绝对地址引用都会指向错误位置；反过来也一样。这是一个初学者非常容易犯的错：总觉得“反正内核已经被搬到内存了，跳过去不就行了”，但实际上程序里的跳转指令、变量地址都是链接时确定的绝对值，装载地址和链接地址不一致，代码就算被原样搬进内存也跑不对。
3.3 交接跳转：一条远跳转指令并不仅仅是改一个寄存器
内核数据全部读进内存后，引导代码最后一步是把执行权交到内核入口。最直接的做法是：
ljmp $0x1000, $0x0000ljmp是一条远跳转（far jump）指令，它会同时修改 CS 和 IP，使之指向 0x1000:0x0000，即物理地址 0x10000。为什么不能用普通的jmp？因为普通跳转只改 IP，CS 保持不变。引导代码此时运行的段基址是 0，跳转仍然只能在当前 64KB 段内转悠；远跳转则能一次性切到内核所在的 0x1000 段。
跳转前还有一件容易被漏掉的事：把栈切到内核自己的区域。引导阶段设置的栈顶在 0x7C00 附近，但进入内核后，栈指针还继续往低地址方向生长，可能会碰到内核镜像所在的高地址区域，也可能在后续调用子程序时发生混乱。稳妥的做法是在跳转前重新设置：
movw $0x9000, %ax movw %ax, %ss movw $0xffff, %sp给内核一个全新的栈底。这样做之后，内核入口只需要关心自己的初始化逻辑，不需要替引导阶段收拾栈的烂摊子。
4. 启动失败排查全记录：三次典型翻车让我真正理解了引导流程
4.1 症状一：QEMU 窗口黑屏，只有光标在闪
这是我第一次把自己的引导扇区塞进镜像后遇到的现象。看起来毫无反应，既没有输出字符，也没有重启。当时第一反应是“代码写错了”，但反复检查指令语法又看不出问题。后来用十六进制工具检查生成的 boot.bin，发现文件末尾的魔数位置不对——我把.org 510写成了.org 511，导致 0x55 0xAA 落在了第 511、512 字节，而 BIOS 检查的是第 510、511 字节。镜像扇区本身只有 512 字节，bin 文件加到 512 字节后就截断了，第 512 字节根本不存在，BIOS 自然不认这个引导设备。
排查这类问题有一个笨但有效的思路：先用十六进制工具从文件偏移 0x1FE 处开始看：
xxd -g 1 -l 512 boot.bin | tail -n 3如果最后两字节不是55 aa，就说明引导扇区的魔数契约没满足。这个检查应该在写任何调试代码之前做，因为它能直接排除掉“BIOS 根本没引导”这一整类原因。
4.2 症状二：引导代码输出了字符，但内核入口没有执行
跨过第一关后，屏幕上能看到引导阶段打印的字符了，但跳转进内核后，什么都没有发生。这个症状比黑屏更难受，因为它说明引导链路已经走通了一大半，问题出在装载或者交接环节。
我的排查从内核二进制本身开始。我反汇编了 kernel.bin，找到入口处的第一条指令，再去引导代码里对照跳转目标。结果发现一个典型错位：内核链接脚本里写的是0x8000，但我引导代码里读盘时把数据装载到了0x10000。这就导致 CPU 跳转到 0x10000 后，那里虽然确实有内核代码，可代码里的各类地址引用都按 0x8000 计算过，所有的函数调用和全局变量访问全部落到了错误的位置。程序很快就执行到非法指令，最终表现为“像死机一样没反应”。
这个问题的根因总结起来就是两句话：引导程序负责把二进制搬到“某个约定的内存位置”；链接脚本负责保证内核代码的所有内部地址都按“同一个位置”生成。两个位置必须相等，这就是装载地址和链接地址一致性原则。修复方法是把链接脚本里的起始地址改成和ES:BX指向的物理地址完全一致，也就是都用 0x10000。
4.3 症状三：跳转后 QEMU 自动重启，像进入了死循环
最让我头疼的症状是：内核入口的汇编代码明明能看到一条条跳转指令，也在预期位置输出了一个字符，但紧接着 QEMU 就重启了。这个现象通常意味着执行流跑飞到了不可预期的位置，最可能是栈指针不合理，或者是内核里某个绝对地址引用错了，导致跳到空内存后触发了异常，而当时的异常处理又回到了复位向量。
我用 QEMU 的-monitor功能反复看寄存器状态，发现 CS:IP 并不在预期的0x1000:0x0000，而是一路跑到了非常靠后的位置。接着我用objdump把内核入口的汇编全部反汇编出来，逐条和源码对比，最后定位到一个非常隐蔽的坑：入口函数中有一条指令依赖某个变量地址，而该变量的地址按链接脚本是 0x10000 附近，实际装载时却被引导代码放到了 0x8000。也就是说，第一个输出字符之所以能打出来，是因为它用的是 RIP 相对寻址或者栈上数据，侥幸没受影响；一旦访问全局变量，立即跳到错误内存地址。
这类问题的排查手段，本质上就三步：确认装载地址、确认链接地址、确认跳转目标。三者中间任何一步不一致，后续执行都会像多米诺骨牌一样连锁出错。
4.4 排查工具链的固定组合
反复踩了几次坑之后，我整理了一套固定排查工具组合，后面做任何引导相关实验都用它：
xxd/hexdump：检查引导扇区二进制布局，确认魔数位置和填充情况；objdump -D -b binary -m i386：反汇编二进制文件，对照检查代码生成是否符合预期；readelf/nm：查看内核镜像的符号地址，核实链接脚本生效情况；- QEMU 的
-d int,cpu_reset -D qemu.log：记录异常中断和 CPU 复位事件，能直接看到哪一步触发了复位。
这套组合最大的价值在于把“代码逻辑问题”和“系统环境问题”分开来。举个例子：当你确定引导扇区魔数没问题、跳转前的寄存器也正确时，再去怀疑链接脚本和内存布局，而不是盲目修改汇编代码。排查顺序如果反了，只会越改越乱。
5. 作业之外值得继续深挖的三件事
5.1 引导装载的“契约思想”以后还会反复出现
完成这份作业后，我最大的收获不是学会了那几十行汇编，而是建立起一种“契约”意识。引导扇区末尾的魔数，是 BIOS 和引导代码之间的契约；装载地址与链接地址一致，是引导代码和内核镜像之间的契约；ES:BX指向的缓冲区，是调用者和 BIOS 磁盘服务之间的契约。整个启动过程就是一系列契约的连锁传递，任何一个环节没有按约定执行，链条立刻断掉。
这种思维到后面学习进程加载、动态链接时依然适用。比如可执行文件里的入口点、段地址重定位、页表映射，本质上都是在维护“程序编译时预期的地址”和“运行时实际使用的地址”之间的一致性。早期引导装载的经验越扎实，后面理解这些概念就越顺。
如果你在做完作业后想着手扩展，可以考虑给内核加入保护模式切换，也可以尝试把自己的引导扇区换成模拟 UEFI 启动流程。地址、契约、跳转这些核心要素还在，只是表现形式从实模式中断变成了固件协议和页表。
5.2 把程序装载的调试思路沉淀成一套固定心法
我再分享一个实际体会：排查这类基础系统问题时，最容易出错的反而是“想当然”。比如“我已经读了三个扇区，内核肯定全在内存里”这种假设，其实值得被验证。我当时用一个很土但有效的方法：在内核入口第一条指令处临时写入一个字符输出中断，如果引导后能看到这个字符，说明跳转成功；如果看不到，就倒退回去检查装载。把验证点一点点往前挪，比盯着代码空想要快得多。
这种从现象倒推、沿着执行链路切分验证点的方法，是这次作业给我留下的最有长期价值的东西。它在后面调试更复杂的内核模块、甚至是工作中的嵌入式固件问题时，一直很管用。
至于那些曾经折磨过我的症状，现在回头看，基本都是对链路理解不够导致的。引导代码的输出只是一个信号，真正核心的是地址一致性和控制权交接。抓住这两条线，系统引导与程序装载里那些看似玄乎的坑，就都能一个一个填平了。
