《操作系统真象还原》第三章“完善MBR”是我在这个系列里感觉最有“分水岭”意义的一章。前两章还在用汇编直接操作显存、在屏幕上打印字符多少有点“玩具”味道。到了第三章MBR 真正开始干操作系统启动过程中的“脏活累活”从磁盘读取数据到内存然后跳转执行。这一章做完你再回头看 MBR 就不再是一段在屏幕上打印“1 MBR”的演示代码而是能扛起引导重任的“半成品操作系统引导程序”。这一章的内容本质上是在解决一个非常具体的问题CPU 上电后BIOS 把 MBR 从磁盘的 0 扇区加载到 0x7C00 处然后跳转执行。但 MBR 只有 512 字节引导代码、分区表、结束标志加在一起能留给代码的存储空间非常有限。要在 512 字节里完成操作系统引导不可能更别说后续还要加载内核、解析 ELF。所以需要 MBR 先把更复杂的引导程序 Loader 从磁盘读进内存再让 Loader 去完成真正的加载任务。整个过程里你要亲手和磁盘控制器打交道——通过 PIO 方式操作硬盘端口设置 CHS/LBA 参数发送读写命令轮询状态然后从数据端口一个字一个字地把数据搬进内存。这一章做完你会对“CPU 与外部设备怎么通信”“内存地址怎么规划”“代码段、栈、数据段为什么会发生冲突”有远比看书更深刻的理解。我自己的感觉是这一章是很多人的分水岭。能独立把代码写通、跑起来的人后面几章包括特权级、中断、内存管理都会顺畅不少卡在这一章的多半是卡在了“不知道怎么排查问题”——做好了放在硬盘里看不出来运行后没有输出或者输出异常人一下就懵了。所以这篇文章我打算把第三章的完整过程拆开讲从整体设计思路到每一个关键指令和寄存器的含义到调试方法再到我实际踩过的坑。希望能帮你把这一章“吃透”。1. 项目整体设计与核心思路拆解1.1 为什么 MBR 必须“完善”直接写完不行吗先回到一个看起来很基础的问题为什么不能把操作系统引导逻辑全部塞进 MBR最多也就 512 字节我刚学这一章的时候也有这个疑惑。512 字节看着不多但如果你只是想打印几行字、读几个扇区那确实够。但想想后面要做的加载内核到内存、解析内核文件格式、进入保护模式、开启分页、建立内存管理结构……这些随便一个功能写出来都是几百行起步512 字节连塞个开头都费劲。所以说MBR 的定位不是“完成引导”而是“启动引导”。它的任务只有一个把真正的引导程序 Loader 从磁盘加载到内存中某个约定好的地址然后跳转过去。至于 Loader 怎么加载内核、怎么进入保护模式那是后面章节的事情MBR 不需要操心。这里其实藏着一个操作系统的经典设计思想层层负责、逐级放大。BIOS 负责加载 MBR是因为 BIOS 足够小、足够固定MBR 加载 Loader是因为 Loader 可以做得比 MBR 大得多、灵活得多Loader 再加载内核是因为内核需要更大的空间和更复杂的环境。每一层只需要完成“把下一层带起来”这件事不需要越俎代庖。这种分层的思路贯穿整个操作系统。你以后看 UEFI、看 grub、看 Linux 的启动流程会发现全都是这个套路一个很小的引导块加载一个稍大的引导程序引导程序再加载更大的内核镜像。第三章做的这件事实际上是把操作系统的“信任链”建立了起来。1.2 MBR、Loader、内核三者的内存规划才是这章的灵魂“完善 MBR”如果只看代码会觉得很琐碎设置栈、读取磁盘、跳转。但代码背后作者其实是在搭建整本书后续所有章节的内存布局框架。书里给出的内存规划大概是这样的MBR 被 BIOS 加载到物理地址 0x7C00MBR 自己把自己从 0x7C00 搬到 0x900腾出 0x7C00 这片区域然后跳转到新位置继续执行。后续为 Loader 分配的内存地址是 0x900加载到 0x900偏移 0x200 处也就是 0xB00 开始存放 Loader 代码内核的加载地址则在更高的位置比如 0x1500各版本可能略有差异。为什么要搬 MBR因为 0x7C00 这块区域在内存里属于“低端内存”比较黄金的位置。后面 Loader 要加载进来可能需要用到这块区域如果 MBR 一直占着 0x7C00 不挪地方Loader 加载过来时可能直接覆盖掉还在执行的 MBR 代码导致指令混乱。所以在跳转之前先用一段代码把 MBR 程序整体搬到 0x900 处逻辑上相当于“给后续程序腾地方”。这个细节非常能体现裸机开发的思维方式没有操作系统帮你管理内存你必须在写代码之前就规划好哪个地址归谁用、哪个区域不能碰。在写应用程序的时候内存地址分配这种事根本不用操心编译器、链接器、操作系统全都给你管好了。但在裸机上你既是程序员又是操作系统又是链接器。内存布局想不清楚后面的代码写得再漂亮也是白搭。2. 磁盘读写与端口操作这章的技术核心2.1 机械硬盘是“一盘磁带加上一个指针”——CHS 与 LBA第三章代码里花了大篇幅去读磁盘扇区而读磁盘前首先要搞清楚磁盘的寻址方式。老式机械硬盘内部有盘片、磁头、磁道、扇区。一个数据块的物理位置可以用“柱面Cylinder、磁头Head、扇区Sector”三个维度来描述这就是 CHS 寻址方式。但 CHS 有个问题它和硬盘的物理结构绑定太深。不同厂家、不同型号的硬盘内部磁头数、柱面数都不一样用 CHS 写程序得先知道硬盘的几何参数很麻烦。而且 CHS 在逻辑上并不连续——扇区编号从 1 开始跨磁道时会有编号跳变写代码容易出错。所以后来出现了 LBALogical Block Address逻辑块地址。它的思想很简单把硬盘的扇区从 0 开始按顺序编号第一个扇区就是 LBA 0第二个就是 LBA 1依此类推。软件只需要告诉硬盘控制器“我要读写第几个逻辑扇区”控制器自己负责换算成物理位置。你可以把 CHS 想象成靠“城市名街道名门牌号”找地址把 LBA 想象成直接把所有地址编成序号用“第几号地址”来找。显然后者更适合写代码。第三章的代码中用到的就是 LBA 方式确切地说是 28 位的 LBA 地址。2.2 操作 IDE 硬盘就是操作一堆端口CPU 和外设通信有很多种方式第三章用的是最经典、最底层的一种端口映射 I/OPort-Mapped I/O。也就是说CPU 访问外设不是通过内存地址而是通过一组专门的端口号。每个端口有一个编号CPU 用in/out指令从端口读数据、往端口写数据。用生活里的类比来说端口就像酒店前台的一组电话分机你要客房服务就拿起电话拨某个分机号码说你的需求然后前台帮你安排你不会直接跑进客房去要毛巾。端口也是这个意思——CPU 不会直接把数据写到硬盘盘片上而是往对应端口发指令和数据然后硬盘控制器自己完成真正的读写。第三章涉及的硬盘端口主要是以下这几个0x1F0数据端口用于读写硬盘数据16 位读写0x1F2扇区数端口告诉硬盘要读/写几个扇区0x1F3、0x1F4、0x1F5LBA 地址端口分别存放 LBA 地址的 0~7 位、8~15 位、16~23 位0x1F6驱动器/磁头端口低 4 位存放 LBA 地址的 24~27 位高 4 位用于选择主盘/从盘和 LBA 模式0x1F7状态/命令端口读它得到硬盘状态写它发出命令如读扇区命令 0x20看着端口 0x1F6 内容换算有点绕我记这个的方式很简单0x1F6 的 bit 6 表示是否启用 LBA 模式置 1 启用 LBA置 0 使用 CHSbit 7 必须恒为 1bit 4 决定是主盘还是从盘0 为主盘1 为从盘低 4 位就是 LBA 地址的 24~27 位。所以往 0x1F6 写什么值时正常情况下是0xE0 | (lba 24)。0xE0 就是把 bit 7、bit 6、bit 5 都置 1bit 5 在旧规范里代表 device 位在现代 ATA 规范里常被称为 LBA bit但你在兼容模式下把它写成0xE0即可。这个组合值在第三章代码里非常高频很多初学者会在这里犯迷糊一会儿 E0一会儿 A0一会儿 40其实区别就在这些 bit 的控制上。2.3 读一个扇区的完整流程拆解把前面的端口知识串起来读一个扇区的流程就是往 0x1F2 写入要读取的扇区数本例中通常为 1往 0x1F3、0x1F4、0x1F5 依次写入 LBA 地址的低 8 位、中 8 位、高 8 位往 0x1F6 写入合并了主盘/从盘、LBA 模式、LBA 高 4 位的字节往 0x1F7 写入读命令 0x20反复读取 0x1F7 端口检查硬盘是否忙第 7 位为 1 表示忙以及数据是否就绪第 6 位为 1 表示数据准备就绪从 0x1F0 数据端口连续读取数据每次 16 位也就是一个 word第 2 步和第 3 步有个特别容易踩的坑写入顺序不能反。从 0x1F3 到 0x1F6 必须按照“先低后高”的顺序写因为硬盘控制器期望你按照这个顺序填充 LBA 寄存器。如果你先把高 4 位写进 0x1F6再回头填低 24 位部分硬盘控制器会直接报错或者读取到错误的地址。第 5 步等待状态时我建议除了查“忙”位还要查“数据请求DRQ”位。有些资料只告诉你等硬盘不忙就开读但实际上“不忙”不代表数据已经准备好。稳妥判断是0x1F7读回来bit 7 为 0不忙且 bit 6 为 1数据就绪这时候再去读 0x1F0 才靠谱。第 6 步每次从数据端口读入 16 位。很多人会忽略这一点0x1F0 是 16 位数据端口所以一次务必读一个 word即两个字节不能一次只读一个字节。读完后内存地址要加 2而不是加 1。对应汇编代码里通常会用mov dx, 0x1F0in ax, dxmov [es:bx], ax然后add bx, 2的方式循环搬数据。这里有个小细节在读数据时你看到代码里会先写mov cx, 256、rep insw或手动循环。一个扇区 512 字节用 16 位端口读正好要读 256 次。明白这个 256 是怎么来的你就知道为什么代码里循环次数写的是 256 而不是 512。2.4 为什么代码里要用 ES 段寄存器配合 BX读磁盘时目标地址通常表示为es:bx这样的“段基址:偏移地址”组合。在实模式下CPU 用段寄存器左移 4 位加上偏移量来形成物理地址。所以如果你想把数据读到物理地址 0x9000可以设es0x9000、bx0x0000或者es0x8000、bx0x1000再或者es0x0000、bx0x9000。表示方式很多只要物理地址算出来一致就行。第三章代码里读取 Loader 时通常会设置es0x9000、bx0x0000那实际物理地址就是0x9000 4 0 0x90000。等等这里要注意0x9000 左移 4 位是 0x90000物理地址大概是 576KB 的位置0x90000。而前面的 MBR 搬到 0x900那是 0x900 这个地址两者差很远。实际第三章内存布局里Loader 并不是加载到 0x900MBR 复制后的位置而是更高地址。具体以书里的内存布局图为准别把 “0x900” 和 “0x9000” 搞混。我看到过不少初学者在调试时发现“为什么我读出来的数据明明是乱码”结果一查是es和bx的组合写错了数据被放到了另一个地方。裸机上调试全靠你自己检查寄存器这种段地址换算错误非常隐蔽因为代码不会报错只是数据不在你预期的地方。3. 实操环节从代码到运行3.1 准备工作编译器和虚拟机的那些事第三章会用 NASM 编译汇编源文件然后用dd把编译出的 MBR 写到磁盘镜像的第一个扇区。这个流程我强烈建议一步一步来先确认每个工具单独能跑通再进行组合。我经常看到初学者一上来就写了个长长的makefile出了错不知道是该查汇编语法、查链接脚本还是查dd命令参数排查起来特别痛苦。NASM 的安装很简单各大 Linux 发行版都有现成的包。编译 MBR 的命令通常是nasm -I include/ -o mbr.bin mbr.S这里用-I指定头文件搜索路径是为了配合书里的 include 目录结构。生成的mbr.bin应该正好是 512 字节可以用ls -l确认。如果大于 512 字节说明代码里哪里多了内容如果小于 512 字节后面dd写入时需要注意补齐。实际上 512 字节并不是编译时的约束而是 MBR 这个区域的固定大小——BIOS 只读 512 字节你也只能写 512 字节进去。写盘命令一般是dd if/path/to/mbr.bin of/path/to/hd.img bs512 count1 convnotruncconvnotrunc特别重要它的意思是“写入时不要截断目标文件”。不加这个参数dd会把hd.img整个文件从指定偏移处截断硬盘镜像就毁了。如果你在 Ubuntu 或其它发行版上都装好了 QEMU 和 Bochs建议先各跑一遍感受一下两者的差异。我个人更推荐调裸机程序时用 Bochs原因后面说。3.2 完整阅读磁盘流程的汇编实现思路第三章的read_disk函数写得很经典。我先给你捋一下整体思路代码本身书里都有不逐行抄了; Read disk sectors into ES:BX ; Parameters: dx LBA address, cx sector count read_disk: mov al, cl mov dx, 0x1F2 ; sector count port out dx, al mov dx, 0x1F3 ; LBA low byte mov al, bl ; assume bl stores the low byte of LBA out dx, al ; ... similar for 0x1F4 (middle), 0x1F5 (high), 0x1F6 (high mode drive) ; then, issue read command (0x20) to 0x1F7 .wait_disk: in al, dx ; dx 0x1F7 test al, 0x80 ; busy jnz .wait_disk test al, 0x40 ; data ready jz .wait_disk ; read data from 0x1F0, 256 times for one sector mov cx, 256 mov dx, 0x1F0 .read_loop: in ax, dx mov [es:bx], ax add bx, 2 loop .read_loop ret真实代码里会有更多的参数传递、段寄存器保护、栈操作但核心骨架就是这样。这里有个细节等待硬盘就绪这一段我不能只检查忙位然后直接读。很多老外的资料里会简化为“等 not busy 就开读”但实测下来某些硬盘控制器在命令发出后会先把状态寄存器置为忙数据可用后再把“数据请求”位置 1。如果你在“不忙”但“数据请求还没置位”时就去读 0x1F0读出来的可能是无效数据。稳妥写法是循环里同时判断 bit 6 和 bit 7直到满足“不忙且数据就绪”为止。这个过程像什么呢就像你在餐厅点餐你把菜名报给服务员写命令端口服务员说“稍等厨房在忙”busy 位为 1等了一会儿服务员说“你的菜好了可以来取”busy 位为 0DRQ 位为 1这时你才去吧台端菜读数据端口。如果你服务员还在忙时就去端菜很可能端到一半的菜甚至别人的菜。3.3 搬移 MBR 与跳转的细节读磁盘之前代码还做了一件很容易被忽略的事把 MBR 从 0x7C00 搬到 0x900。这个操作本身就是一个“内存拷贝”在裸机上通常用rep movsw实现。需要注意rep movsw默认使用 DS:SI 作为源地址、ES:DI 作为目的地址所以要先把si、di设置好并且保证ds和es指向正确的段。有一个相关的细节搬运前需要关闭中断。为什么因为 MBR 运行期间理论上没有中断处理程序如果某条指令执行过程中来了个不可屏蔽中断NMI或者你在调试时打开了硬件中断中断向量表位于内存最低端被 BIOS 占用的部分没问题但如果在搬运中途发生重入或异常整个引导流程就全乱了。书里代码通常在搬运阶段会写cli清除中断标志来避免这种风险。当然如果你开了 A20、进入了保护模式之后中断是必须重新设置的但至少在这一步cli是标准做法。不要小看这个cli。我第一次写的时候偷懒没关中断结果在个别机器/虚拟机上偶发死机排查了很久发现是搬运过程中 0x7C00 区域的指令被覆盖了一半。搬到一半CPU 取到的下一条指令可能已经变成“半条”代码后续行为完全不可预测。每一条 MBR 代码都可能在这种脆弱时刻执行所以关中断是防患于未然。搬运完成之后代码会使用一个“绝对跳转”跳到新地址继续执行。常见的写法是jmp 0:0x904或者先设置栈、段寄存器然后用一条jmp 段基址:偏移完成跳转。这种段间跳转far jump会把 CS 也一起设置到目标段同时会刷新指令预取队列。这是“搬到新位置后继续执行”的标准做法。如果你只是jmp near很可能因为 CS 还是旧值出现指令预取混乱。3.4 栈地址的设置与背后的计算第三章里关中断之后、搬移数据之前通常会先把栈指针设到一个安全位置。常见的是mov sp, 0x7C00或者类似值意思是把栈设在 0x7C00 以下向低地址增长。为什么选 0x7C00因为在实模式下同一段 64KB 范围内栈向下增长而 MBR 代码和数据在 0x7C00 开始向上占用栈放在 0x7C00 并向下增长两者不会相互覆盖。如果你把栈设在 0x900也就是 MBR 复制后的代码区那调用call、ret时会直接压进代码区覆盖正在执行的指令。这种栈和代码抢内存的经典问题在裸机开发里非常常见。提示实模式下栈段寄存器 SS 和栈指针 SP 必须保持一致来算物理地址。比如ss0x0000、sp0x7C00那栈底就在 0x7C00压栈时栈向低地址移动最多可以往下长到 0x0000空间有 31KB 左右对 MBR 阶段来说绰绰有余。但如果你不小心设置ss0x07C0、sp0x0000物理地址同样算出 0x7C00这也没错只是不同的段基址表示方式。要命的是不小心设成ss0x9000、sp0x0000那栈底直接到了 0x90000和预期差了十万八千里。4. 调试环境与常见问题排查实录4.1 裸机调试不是靠 printf而是靠断点和寄存器窗口到了这章如果你还想着“出问题了我在代码里加几行print看看”那你可能会非常痛苦。MBR 阶段根本没有完整的打印函数往显存里写字符也算一种调试手段但有局限只能展示你预留好的信息拿不到寄存器的实时值。调试 MBR 我强烈建议用 Bochs。它自带的调试器可以下断点、单步执行、查看寄存器、查看内存这对定位“数据有没有读对”“寄存器是不是预期的值”非常方便。QEMU 也可以调试-s -S配合 GDB但 Bochs 的info registers、x /512bx 0x90000、xp /512bx 0x90000这类命令在实模式下更直观。我调试裸机引导代码时常做的操作是这样在0x7C00下断点确认 BIOS 正确地把 MBR 加载进来了。单步到read_disk之前查看寄存器确认参数传得对。执行完读取流程后查看目标内存地址确认读出来的字节和loader.bin文件一致。有个非常实用的小技巧如果你想验证“读进来的 Loader 数据对不对”可以直接在宿主机上对loader.bin做xxd拿到前几个字节的十六进制值然后在 Bochs 里执行x /16bx 目标物理地址对比一下。如果完全一致那就说明整条数据通路没问题问题在别的环节。这招极大地缩小了排查范围——到底是“读数据读错了”还是“跳转后执行错了”一目了然。4.2 状态端口永远读不对都是时序的锅使用真实硬盘或者某些模拟器时最容易遇到“读 0x1F7 状态端口值一直不变”的问题。这种情况多半不是端口号写错了而是你向 0x1F7 写入命令后没有正确等待足够的时间。硬盘操作是机械动作不是 CPU 执行指令那种纳秒级速度磁头移动需要毫秒级时间。你如果命令刚发出就去轮询状态硬盘可能还在切换状态你读到的自然还是旧状态。解决的办法有几种正确循环等待忙位和数据就绪位有些老资料会建议先读一次状态、再等一次或者中间加一段nop/jmp $小延时对纯粹的模拟器Bochs/QEMU延时不需要太大但养成轮询等待的习惯很重要我自己的经验是代码里宁可多写几行.wait_disk循环也不要在没有任何状态判断的情况下“闷头读”。有些时候程序“在真机正常、在模拟器不正常”往往是模拟器时序和真机不完全一致。裸机代码必须讲究“协议正确”不能靠运气。4.3 读出来的数据是乱码或全 0 的几个因素如果读出来的目标内存区域跟 Loader 文件完全对不上除了前面说的段地址设置错误还有几个经典嫌疑第一个是 LBA 地址写错了。Loader 在磁盘镜像上存放的位置和你传给read_disk的 LBA 数值必须一致。第三章里 MBR 位于 0 号扇区Loader 一般在 MBR 之后的扇区比如第 2 个扇区LBA 1或者更高。如果你实际把 Loader 写到了第 3 个扇区LBA 2但代码里读的是 LBA 1那读出来的自然是别的扇区的内容甚至全是 0。第二个是扇区数不对。一次读了多个扇区但实际只写了一个扇区或者反过来。这种问题多发生在dd命令的参数上bs512 count1只写了一个扇区但程序想读 2 个扇区第二个扇区从镜像文件末尾越界读出来可能全是 0 或者随机数据。第三个是 0x1F6 写错了。低 4 位是高 4 位 LBA 地址高位控制主从盘和 LBA 模式。如果你把第 4 位代表主从盘写反了那么硬盘控制器会认为你要访问另一块盘——而你的系统里可能根本没有另一块盘于是读数据直接失败。我建议把 read_disk 里的参数传递写得尽量明确比如用寄存器传递 LBA 地址、扇区数不同位对应哪些操作注释写清楚不要图省事写成一连串魔法数字。裸机代码半年后你自己都会忘注释是最好的 debug 伙伴。4.4 MBR 跳转后屏幕完全无输出的排查顺序很多人写完这章后遇到最心塞的场景程序运行屏幕什么都没有。没有输出意味着 MBR 可能根本没执行或者执行了但代码死循环卡死了。排查顺序我一般是这样的先确认 Bochs 是否在0x7C00处断住。如果断不住说明磁盘镜像的 MBR 根本没写对或者 BIOS 没认出来。如果在0x7C00断住了单步看第一条指令是否按照预期执行尤其是段寄存器设置和栈设置。代码里是否包含“死循环等待”的逻辑。比如状态轮询里条件写反了jnz和jz搞混会导致永远等待。跳转目标是否写错。如果 MBR 把自己搬到了 0x900但跳转时写成了jmp 0:0x901那指令从第二个字节开始执行结果必然是花式乱码甚至 CPU 异常。显存操作是否被跳过。屏幕无输出也可能是代码执行到了 Loader但 Loader 里打印函数没生效。排查这五步基本能定位九成的问题。裸机调试有个好处出错很“硬”要么完全没反应要么是在某个指令上异常不像应用开发里内存泄漏、空指针这些“软错误”那么隐晦。只要你信息足够完整问题链条是能一条条串起来的。4.5 常见问题速查表现象最可能原因解决方案Bochs 无法断在 0x7C00MBR 写盘失败或写错扇区检查dd参数、文件大小是否为 512 字节屏幕无任何输出跳转地址错误或死循环等待检查 jmp 目标、状态轮询逻辑、栈设置读取数据全是 0LBA 地址或扇区数错误对比dd写盘位置与代码读取的 LBA读取数据乱码段地址/偏移地址组合错误用x /16bx检查目标内存地址执行到一半卡死栈设在代码区导致覆盖把栈设在低地址、确认不与代码区冲突读 0x1F7 状态异常发送命令前端口参数未完整写入按顺序完整写 0x1F2~0x1F6再写命令代码在真机正常、模拟器异常时序时序时序确认状态轮询条件不依赖特定时序4.6 一个调试小技巧用显存直接看内存内容如果你不想在 Bochs 里一条条看寄存器也可以在 Loader 的最前面写一段临时代码把读到的内存里第一个字节、第二个字节转换成 ASCII 打印到屏幕上。我做过类似操作从目标内存地址取 4 个字节转成十六进制字符往显存 0xB8000 处填。这样就相当于在裸机上写了一个“十六进制查看器”。这种方法的麻烦在于你需要一段额外的转换代码而且容易破坏现场。但好处是它可以在物理机上用不用调试器也能给你一种“我在给操作系统写诊断程序”的真实感。我在学习过程中来回用过几次虽然现在更多依赖 Bochs但这种方式在后续写内核、调试中断时依然很管用建议练一练。5. 从第三章往后看这一章到底在为什么做准备5.1 你不知不觉学到的“广义引导”思维第三章的内容表面上是“读磁盘、搬数据、跳转”但把视角拉高一点你会发现你其实在完成一个通用模式从一个可靠的初始源把一段更大的程序搬到内存中的指定位置然后把控制权交给它。这个模式在现代操作系统的每次启动时都会发生。UEFI 固件加载启动管理器、启动管理器加载内核镜像、内核加载 initramfs……形式上都是这个套路。不同的只是存储介质网络、NVMe、分区镜像和协议复杂度。有了第三章亲手写 MBR 的经验你再看任何“引导链”相关的资料都会有一种“哦原来就是 0x7C00 - Loader - kernel”的亲切感。而且你还会意识到真正的困难不在“读磁盘”而在于“约定”每一层都需要知道上一层的入口地址在哪里、参数放在哪里、内存要不要清理、段寄存器应该是什么状态。这些约定没有写在硬盘上而是写在了程序员的脑子里。调试引导代码的很多痛苦都源于“没有明确约定”。5.2 保护模式、内存分页、ELF 加载全都建立在这套思维上再往后翻几章你会进入保护模式接触 GDT、特权级、分段和分页。那时候你会发现很多代码依然在“搬数据、跳转、约定地址”这三件事上打转只是从实模式换到了保护模式从 LBA 换成了文件系统从直接读扇区换成了解析 ELF。第三章的 MBR 算是一个“最小可用”的模型它足够简单让你看清楚整个引导链条的骨架它又足够真实让你感受到硬件协议和软件逻辑的交互。你可以把这一章当作整套系统在硬件上的“根”——后面所有的内存布局、权限机制、设备抽象本质上都是在这个根上生长出来的。5.3 关于内存布局图值得反复对照第三章里应该有张内存布局图标出了 MBR0x7C00/0x900、Loader、内核内核栈、显存等的位置。我建议把它单独截图或抄下来后续学习每一章时都拿它出来对照一下。学保护模式时看它对不对学分页时再看它对不对。等你学完中断、任务切换再回头看这张图会发现它的很多预留位置都是经过精心计算的。说实话这张图在第三章时的全局意义还没那么明显但越往后它越像一张“城市地图”。你写每一段内核代码都需要知道自己身在哪个“街区”段/页邻居是谁其他模块垃圾倒在哪儿栈区。裸机开发不像是写普通程序倒像是自己当城市规划师所有地块都得提前规划好不能说水管埋好了再挖路。5.4 我的一点实际体会最后说说我自己的体会。做完第三章时我一度觉得自己只是在“照着书抄代码”。但后来回头看真正值钱的不是那几百行汇编而是我在排查各种诡异问题过程中逐渐建立起来的“底层直觉”——看到段寄存器会立刻算物理地址看到端口操作会去查时序看到跳转指令会确认 CS 是否更新。这些直觉在写应用层代码时用不太上但在操作系统开发里是每时每刻都在用的。如果你在这一章卡住了我的建议很简单不要急着往下翻花一个晚上只做一件事——用 Bochs 把 0x7C00 开始的每一条指令都单步执行一遍同时打开寄存器窗口和内存窗口。看着地址、数据、端口值的每次变化你很快会建立起“CPU 在干什么”的图景。这个过程很枯燥但值得。我见过太多人跳过这一步结果后面写内核在地址换算上反复踩坑。另外把代码里的魔数都改成语义化符号也是个好习惯。比如把0xE0、0x20、0x1F0写成有含义的常量并注释哪怕只是DISK_CMD_READ equ 0x20这种简单替换。这对你之后复用read_disk到 Loader 甚至内核里都非常有帮助。毕竟第三章写的这段磁盘读程序后面几章还会频繁出现你要是写得又乱又散后面改起来会想哭。 
长河君 · 2026/10/17 15:06:19 · 阅读 1.2k 操作系统引导从MBR到Loader：磁盘读取与端口编程实战解析
《操作系统真象还原》第三章“完善MBR”是我在这个系列里感觉最有“分水岭”意义的一章。前两章还在用汇编直接操作显存、在屏幕上打印字符多少有点“玩具”味道。到了第三章MBR 真正开始干操作系统启动过程中的“脏活累活”从磁盘读取数据到内存然后跳转执行。这一章做完你再回头看 MBR 就不再是一段在屏幕上打印“1 MBR”的演示代码而是能扛起引导重任的“半成品操作系统引导程序”。这一章的内容本质上是在解决一个非常具体的问题CPU 上电后BIOS 把 MBR 从磁盘的 0 扇区加载到 0x7C00 处然后跳转执行。但 MBR 只有 512 字节引导代码、分区表、结束标志加在一起能留给代码的存储空间非常有限。要在 512 字节里完成操作系统引导不可能更别说后续还要加载内核、解析 ELF。所以需要 MBR 先把更复杂的引导程序 Loader 从磁盘读进内存再让 Loader 去完成真正的加载任务。整个过程里你要亲手和磁盘控制器打交道——通过 PIO 方式操作硬盘端口设置 CHS/LBA 参数发送读写命令轮询状态然后从数据端口一个字一个字地把数据搬进内存。这一章做完你会对“CPU 与外部设备怎么通信”“内存地址怎么规划”“代码段、栈、数据段为什么会发生冲突”有远比看书更深刻的理解。我自己的感觉是这一章是很多人的分水岭。能独立把代码写通、跑起来的人后面几章包括特权级、中断、内存管理都会顺畅不少卡在这一章的多半是卡在了“不知道怎么排查问题”——做好了放在硬盘里看不出来运行后没有输出或者输出异常人一下就懵了。所以这篇文章我打算把第三章的完整过程拆开讲从整体设计思路到每一个关键指令和寄存器的含义到调试方法再到我实际踩过的坑。希望能帮你把这一章“吃透”。1. 项目整体设计与核心思路拆解1.1 为什么 MBR 必须“完善”直接写完不行吗先回到一个看起来很基础的问题为什么不能把操作系统引导逻辑全部塞进 MBR最多也就 512 字节我刚学这一章的时候也有这个疑惑。512 字节看着不多但如果你只是想打印几行字、读几个扇区那确实够。但想想后面要做的加载内核到内存、解析内核文件格式、进入保护模式、开启分页、建立内存管理结构……这些随便一个功能写出来都是几百行起步512 字节连塞个开头都费劲。所以说MBR 的定位不是“完成引导”而是“启动引导”。它的任务只有一个把真正的引导程序 Loader 从磁盘加载到内存中某个约定好的地址然后跳转过去。至于 Loader 怎么加载内核、怎么进入保护模式那是后面章节的事情MBR 不需要操心。这里其实藏着一个操作系统的经典设计思想层层负责、逐级放大。BIOS 负责加载 MBR是因为 BIOS 足够小、足够固定MBR 加载 Loader是因为 Loader 可以做得比 MBR 大得多、灵活得多Loader 再加载内核是因为内核需要更大的空间和更复杂的环境。每一层只需要完成“把下一层带起来”这件事不需要越俎代庖。这种分层的思路贯穿整个操作系统。你以后看 UEFI、看 grub、看 Linux 的启动流程会发现全都是这个套路一个很小的引导块加载一个稍大的引导程序引导程序再加载更大的内核镜像。第三章做的这件事实际上是把操作系统的“信任链”建立了起来。1.2 MBR、Loader、内核三者的内存规划才是这章的灵魂“完善 MBR”如果只看代码会觉得很琐碎设置栈、读取磁盘、跳转。但代码背后作者其实是在搭建整本书后续所有章节的内存布局框架。书里给出的内存规划大概是这样的MBR 被 BIOS 加载到物理地址 0x7C00MBR 自己把自己从 0x7C00 搬到 0x900腾出 0x7C00 这片区域然后跳转到新位置继续执行。后续为 Loader 分配的内存地址是 0x900加载到 0x900偏移 0x200 处也就是 0xB00 开始存放 Loader 代码内核的加载地址则在更高的位置比如 0x1500各版本可能略有差异。为什么要搬 MBR因为 0x7C00 这块区域在内存里属于“低端内存”比较黄金的位置。后面 Loader 要加载进来可能需要用到这块区域如果 MBR 一直占着 0x7C00 不挪地方Loader 加载过来时可能直接覆盖掉还在执行的 MBR 代码导致指令混乱。所以在跳转之前先用一段代码把 MBR 程序整体搬到 0x900 处逻辑上相当于“给后续程序腾地方”。这个细节非常能体现裸机开发的思维方式没有操作系统帮你管理内存你必须在写代码之前就规划好哪个地址归谁用、哪个区域不能碰。在写应用程序的时候内存地址分配这种事根本不用操心编译器、链接器、操作系统全都给你管好了。但在裸机上你既是程序员又是操作系统又是链接器。内存布局想不清楚后面的代码写得再漂亮也是白搭。2. 磁盘读写与端口操作这章的技术核心2.1 机械硬盘是“一盘磁带加上一个指针”——CHS 与 LBA第三章代码里花了大篇幅去读磁盘扇区而读磁盘前首先要搞清楚磁盘的寻址方式。老式机械硬盘内部有盘片、磁头、磁道、扇区。一个数据块的物理位置可以用“柱面Cylinder、磁头Head、扇区Sector”三个维度来描述这就是 CHS 寻址方式。但 CHS 有个问题它和硬盘的物理结构绑定太深。不同厂家、不同型号的硬盘内部磁头数、柱面数都不一样用 CHS 写程序得先知道硬盘的几何参数很麻烦。而且 CHS 在逻辑上并不连续——扇区编号从 1 开始跨磁道时会有编号跳变写代码容易出错。所以后来出现了 LBALogical Block Address逻辑块地址。它的思想很简单把硬盘的扇区从 0 开始按顺序编号第一个扇区就是 LBA 0第二个就是 LBA 1依此类推。软件只需要告诉硬盘控制器“我要读写第几个逻辑扇区”控制器自己负责换算成物理位置。你可以把 CHS 想象成靠“城市名街道名门牌号”找地址把 LBA 想象成直接把所有地址编成序号用“第几号地址”来找。显然后者更适合写代码。第三章的代码中用到的就是 LBA 方式确切地说是 28 位的 LBA 地址。2.2 操作 IDE 硬盘就是操作一堆端口CPU 和外设通信有很多种方式第三章用的是最经典、最底层的一种端口映射 I/OPort-Mapped I/O。也就是说CPU 访问外设不是通过内存地址而是通过一组专门的端口号。每个端口有一个编号CPU 用in/out指令从端口读数据、往端口写数据。用生活里的类比来说端口就像酒店前台的一组电话分机你要客房服务就拿起电话拨某个分机号码说你的需求然后前台帮你安排你不会直接跑进客房去要毛巾。端口也是这个意思——CPU 不会直接把数据写到硬盘盘片上而是往对应端口发指令和数据然后硬盘控制器自己完成真正的读写。第三章涉及的硬盘端口主要是以下这几个0x1F0数据端口用于读写硬盘数据16 位读写0x1F2扇区数端口告诉硬盘要读/写几个扇区0x1F3、0x1F4、0x1F5LBA 地址端口分别存放 LBA 地址的 0~7 位、8~15 位、16~23 位0x1F6驱动器/磁头端口低 4 位存放 LBA 地址的 24~27 位高 4 位用于选择主盘/从盘和 LBA 模式0x1F7状态/命令端口读它得到硬盘状态写它发出命令如读扇区命令 0x20看着端口 0x1F6 内容换算有点绕我记这个的方式很简单0x1F6 的 bit 6 表示是否启用 LBA 模式置 1 启用 LBA置 0 使用 CHSbit 7 必须恒为 1bit 4 决定是主盘还是从盘0 为主盘1 为从盘低 4 位就是 LBA 地址的 24~27 位。所以往 0x1F6 写什么值时正常情况下是0xE0 | (lba 24)。0xE0 就是把 bit 7、bit 6、bit 5 都置 1bit 5 在旧规范里代表 device 位在现代 ATA 规范里常被称为 LBA bit但你在兼容模式下把它写成0xE0即可。这个组合值在第三章代码里非常高频很多初学者会在这里犯迷糊一会儿 E0一会儿 A0一会儿 40其实区别就在这些 bit 的控制上。2.3 读一个扇区的完整流程拆解把前面的端口知识串起来读一个扇区的流程就是往 0x1F2 写入要读取的扇区数本例中通常为 1往 0x1F3、0x1F4、0x1F5 依次写入 LBA 地址的低 8 位、中 8 位、高 8 位往 0x1F6 写入合并了主盘/从盘、LBA 模式、LBA 高 4 位的字节往 0x1F7 写入读命令 0x20反复读取 0x1F7 端口检查硬盘是否忙第 7 位为 1 表示忙以及数据是否就绪第 6 位为 1 表示数据准备就绪从 0x1F0 数据端口连续读取数据每次 16 位也就是一个 word第 2 步和第 3 步有个特别容易踩的坑写入顺序不能反。从 0x1F3 到 0x1F6 必须按照“先低后高”的顺序写因为硬盘控制器期望你按照这个顺序填充 LBA 寄存器。如果你先把高 4 位写进 0x1F6再回头填低 24 位部分硬盘控制器会直接报错或者读取到错误的地址。第 5 步等待状态时我建议除了查“忙”位还要查“数据请求DRQ”位。有些资料只告诉你等硬盘不忙就开读但实际上“不忙”不代表数据已经准备好。稳妥判断是0x1F7读回来bit 7 为 0不忙且 bit 6 为 1数据就绪这时候再去读 0x1F0 才靠谱。第 6 步每次从数据端口读入 16 位。很多人会忽略这一点0x1F0 是 16 位数据端口所以一次务必读一个 word即两个字节不能一次只读一个字节。读完后内存地址要加 2而不是加 1。对应汇编代码里通常会用mov dx, 0x1F0in ax, dxmov [es:bx], ax然后add bx, 2的方式循环搬数据。这里有个小细节在读数据时你看到代码里会先写mov cx, 256、rep insw或手动循环。一个扇区 512 字节用 16 位端口读正好要读 256 次。明白这个 256 是怎么来的你就知道为什么代码里循环次数写的是 256 而不是 512。2.4 为什么代码里要用 ES 段寄存器配合 BX读磁盘时目标地址通常表示为es:bx这样的“段基址:偏移地址”组合。在实模式下CPU 用段寄存器左移 4 位加上偏移量来形成物理地址。所以如果你想把数据读到物理地址 0x9000可以设es0x9000、bx0x0000或者es0x8000、bx0x1000再或者es0x0000、bx0x9000。表示方式很多只要物理地址算出来一致就行。第三章代码里读取 Loader 时通常会设置es0x9000、bx0x0000那实际物理地址就是0x9000 4 0 0x90000。等等这里要注意0x9000 左移 4 位是 0x90000物理地址大概是 576KB 的位置0x90000。而前面的 MBR 搬到 0x900那是 0x900 这个地址两者差很远。实际第三章内存布局里Loader 并不是加载到 0x900MBR 复制后的位置而是更高地址。具体以书里的内存布局图为准别把 “0x900” 和 “0x9000” 搞混。我看到过不少初学者在调试时发现“为什么我读出来的数据明明是乱码”结果一查是es和bx的组合写错了数据被放到了另一个地方。裸机上调试全靠你自己检查寄存器这种段地址换算错误非常隐蔽因为代码不会报错只是数据不在你预期的地方。3. 实操环节从代码到运行3.1 准备工作编译器和虚拟机的那些事第三章会用 NASM 编译汇编源文件然后用dd把编译出的 MBR 写到磁盘镜像的第一个扇区。这个流程我强烈建议一步一步来先确认每个工具单独能跑通再进行组合。我经常看到初学者一上来就写了个长长的makefile出了错不知道是该查汇编语法、查链接脚本还是查dd命令参数排查起来特别痛苦。NASM 的安装很简单各大 Linux 发行版都有现成的包。编译 MBR 的命令通常是nasm -I include/ -o mbr.bin mbr.S这里用-I指定头文件搜索路径是为了配合书里的 include 目录结构。生成的mbr.bin应该正好是 512 字节可以用ls -l确认。如果大于 512 字节说明代码里哪里多了内容如果小于 512 字节后面dd写入时需要注意补齐。实际上 512 字节并不是编译时的约束而是 MBR 这个区域的固定大小——BIOS 只读 512 字节你也只能写 512 字节进去。写盘命令一般是dd if/path/to/mbr.bin of/path/to/hd.img bs512 count1 convnotruncconvnotrunc特别重要它的意思是“写入时不要截断目标文件”。不加这个参数dd会把hd.img整个文件从指定偏移处截断硬盘镜像就毁了。如果你在 Ubuntu 或其它发行版上都装好了 QEMU 和 Bochs建议先各跑一遍感受一下两者的差异。我个人更推荐调裸机程序时用 Bochs原因后面说。3.2 完整阅读磁盘流程的汇编实现思路第三章的read_disk函数写得很经典。我先给你捋一下整体思路代码本身书里都有不逐行抄了; Read disk sectors into ES:BX ; Parameters: dx LBA address, cx sector count read_disk: mov al, cl mov dx, 0x1F2 ; sector count port out dx, al mov dx, 0x1F3 ; LBA low byte mov al, bl ; assume bl stores the low byte of LBA out dx, al ; ... similar for 0x1F4 (middle), 0x1F5 (high), 0x1F6 (high mode drive) ; then, issue read command (0x20) to 0x1F7 .wait_disk: in al, dx ; dx 0x1F7 test al, 0x80 ; busy jnz .wait_disk test al, 0x40 ; data ready jz .wait_disk ; read data from 0x1F0, 256 times for one sector mov cx, 256 mov dx, 0x1F0 .read_loop: in ax, dx mov [es:bx], ax add bx, 2 loop .read_loop ret真实代码里会有更多的参数传递、段寄存器保护、栈操作但核心骨架就是这样。这里有个细节等待硬盘就绪这一段我不能只检查忙位然后直接读。很多老外的资料里会简化为“等 not busy 就开读”但实测下来某些硬盘控制器在命令发出后会先把状态寄存器置为忙数据可用后再把“数据请求”位置 1。如果你在“不忙”但“数据请求还没置位”时就去读 0x1F0读出来的可能是无效数据。稳妥写法是循环里同时判断 bit 6 和 bit 7直到满足“不忙且数据就绪”为止。这个过程像什么呢就像你在餐厅点餐你把菜名报给服务员写命令端口服务员说“稍等厨房在忙”busy 位为 1等了一会儿服务员说“你的菜好了可以来取”busy 位为 0DRQ 位为 1这时你才去吧台端菜读数据端口。如果你服务员还在忙时就去端菜很可能端到一半的菜甚至别人的菜。3.3 搬移 MBR 与跳转的细节读磁盘之前代码还做了一件很容易被忽略的事把 MBR 从 0x7C00 搬到 0x900。这个操作本身就是一个“内存拷贝”在裸机上通常用rep movsw实现。需要注意rep movsw默认使用 DS:SI 作为源地址、ES:DI 作为目的地址所以要先把si、di设置好并且保证ds和es指向正确的段。有一个相关的细节搬运前需要关闭中断。为什么因为 MBR 运行期间理论上没有中断处理程序如果某条指令执行过程中来了个不可屏蔽中断NMI或者你在调试时打开了硬件中断中断向量表位于内存最低端被 BIOS 占用的部分没问题但如果在搬运中途发生重入或异常整个引导流程就全乱了。书里代码通常在搬运阶段会写cli清除中断标志来避免这种风险。当然如果你开了 A20、进入了保护模式之后中断是必须重新设置的但至少在这一步cli是标准做法。不要小看这个cli。我第一次写的时候偷懒没关中断结果在个别机器/虚拟机上偶发死机排查了很久发现是搬运过程中 0x7C00 区域的指令被覆盖了一半。搬到一半CPU 取到的下一条指令可能已经变成“半条”代码后续行为完全不可预测。每一条 MBR 代码都可能在这种脆弱时刻执行所以关中断是防患于未然。搬运完成之后代码会使用一个“绝对跳转”跳到新地址继续执行。常见的写法是jmp 0:0x904或者先设置栈、段寄存器然后用一条jmp 段基址:偏移完成跳转。这种段间跳转far jump会把 CS 也一起设置到目标段同时会刷新指令预取队列。这是“搬到新位置后继续执行”的标准做法。如果你只是jmp near很可能因为 CS 还是旧值出现指令预取混乱。3.4 栈地址的设置与背后的计算第三章里关中断之后、搬移数据之前通常会先把栈指针设到一个安全位置。常见的是mov sp, 0x7C00或者类似值意思是把栈设在 0x7C00 以下向低地址增长。为什么选 0x7C00因为在实模式下同一段 64KB 范围内栈向下增长而 MBR 代码和数据在 0x7C00 开始向上占用栈放在 0x7C00 并向下增长两者不会相互覆盖。如果你把栈设在 0x900也就是 MBR 复制后的代码区那调用call、ret时会直接压进代码区覆盖正在执行的指令。这种栈和代码抢内存的经典问题在裸机开发里非常常见。提示实模式下栈段寄存器 SS 和栈指针 SP 必须保持一致来算物理地址。比如ss0x0000、sp0x7C00那栈底就在 0x7C00压栈时栈向低地址移动最多可以往下长到 0x0000空间有 31KB 左右对 MBR 阶段来说绰绰有余。但如果你不小心设置ss0x07C0、sp0x0000物理地址同样算出 0x7C00这也没错只是不同的段基址表示方式。要命的是不小心设成ss0x9000、sp0x0000那栈底直接到了 0x90000和预期差了十万八千里。4. 调试环境与常见问题排查实录4.1 裸机调试不是靠 printf而是靠断点和寄存器窗口到了这章如果你还想着“出问题了我在代码里加几行print看看”那你可能会非常痛苦。MBR 阶段根本没有完整的打印函数往显存里写字符也算一种调试手段但有局限只能展示你预留好的信息拿不到寄存器的实时值。调试 MBR 我强烈建议用 Bochs。它自带的调试器可以下断点、单步执行、查看寄存器、查看内存这对定位“数据有没有读对”“寄存器是不是预期的值”非常方便。QEMU 也可以调试-s -S配合 GDB但 Bochs 的info registers、x /512bx 0x90000、xp /512bx 0x90000这类命令在实模式下更直观。我调试裸机引导代码时常做的操作是这样在0x7C00下断点确认 BIOS 正确地把 MBR 加载进来了。单步到read_disk之前查看寄存器确认参数传得对。执行完读取流程后查看目标内存地址确认读出来的字节和loader.bin文件一致。有个非常实用的小技巧如果你想验证“读进来的 Loader 数据对不对”可以直接在宿主机上对loader.bin做xxd拿到前几个字节的十六进制值然后在 Bochs 里执行x /16bx 目标物理地址对比一下。如果完全一致那就说明整条数据通路没问题问题在别的环节。这招极大地缩小了排查范围——到底是“读数据读错了”还是“跳转后执行错了”一目了然。4.2 状态端口永远读不对都是时序的锅使用真实硬盘或者某些模拟器时最容易遇到“读 0x1F7 状态端口值一直不变”的问题。这种情况多半不是端口号写错了而是你向 0x1F7 写入命令后没有正确等待足够的时间。硬盘操作是机械动作不是 CPU 执行指令那种纳秒级速度磁头移动需要毫秒级时间。你如果命令刚发出就去轮询状态硬盘可能还在切换状态你读到的自然还是旧状态。解决的办法有几种正确循环等待忙位和数据就绪位有些老资料会建议先读一次状态、再等一次或者中间加一段nop/jmp $小延时对纯粹的模拟器Bochs/QEMU延时不需要太大但养成轮询等待的习惯很重要我自己的经验是代码里宁可多写几行.wait_disk循环也不要在没有任何状态判断的情况下“闷头读”。有些时候程序“在真机正常、在模拟器不正常”往往是模拟器时序和真机不完全一致。裸机代码必须讲究“协议正确”不能靠运气。4.3 读出来的数据是乱码或全 0 的几个因素如果读出来的目标内存区域跟 Loader 文件完全对不上除了前面说的段地址设置错误还有几个经典嫌疑第一个是 LBA 地址写错了。Loader 在磁盘镜像上存放的位置和你传给read_disk的 LBA 数值必须一致。第三章里 MBR 位于 0 号扇区Loader 一般在 MBR 之后的扇区比如第 2 个扇区LBA 1或者更高。如果你实际把 Loader 写到了第 3 个扇区LBA 2但代码里读的是 LBA 1那读出来的自然是别的扇区的内容甚至全是 0。第二个是扇区数不对。一次读了多个扇区但实际只写了一个扇区或者反过来。这种问题多发生在dd命令的参数上bs512 count1只写了一个扇区但程序想读 2 个扇区第二个扇区从镜像文件末尾越界读出来可能全是 0 或者随机数据。第三个是 0x1F6 写错了。低 4 位是高 4 位 LBA 地址高位控制主从盘和 LBA 模式。如果你把第 4 位代表主从盘写反了那么硬盘控制器会认为你要访问另一块盘——而你的系统里可能根本没有另一块盘于是读数据直接失败。我建议把 read_disk 里的参数传递写得尽量明确比如用寄存器传递 LBA 地址、扇区数不同位对应哪些操作注释写清楚不要图省事写成一连串魔法数字。裸机代码半年后你自己都会忘注释是最好的 debug 伙伴。4.4 MBR 跳转后屏幕完全无输出的排查顺序很多人写完这章后遇到最心塞的场景程序运行屏幕什么都没有。没有输出意味着 MBR 可能根本没执行或者执行了但代码死循环卡死了。排查顺序我一般是这样的先确认 Bochs 是否在0x7C00处断住。如果断不住说明磁盘镜像的 MBR 根本没写对或者 BIOS 没认出来。如果在0x7C00断住了单步看第一条指令是否按照预期执行尤其是段寄存器设置和栈设置。代码里是否包含“死循环等待”的逻辑。比如状态轮询里条件写反了jnz和jz搞混会导致永远等待。跳转目标是否写错。如果 MBR 把自己搬到了 0x900但跳转时写成了jmp 0:0x901那指令从第二个字节开始执行结果必然是花式乱码甚至 CPU 异常。显存操作是否被跳过。屏幕无输出也可能是代码执行到了 Loader但 Loader 里打印函数没生效。排查这五步基本能定位九成的问题。裸机调试有个好处出错很“硬”要么完全没反应要么是在某个指令上异常不像应用开发里内存泄漏、空指针这些“软错误”那么隐晦。只要你信息足够完整问题链条是能一条条串起来的。4.5 常见问题速查表现象最可能原因解决方案Bochs 无法断在 0x7C00MBR 写盘失败或写错扇区检查dd参数、文件大小是否为 512 字节屏幕无任何输出跳转地址错误或死循环等待检查 jmp 目标、状态轮询逻辑、栈设置读取数据全是 0LBA 地址或扇区数错误对比dd写盘位置与代码读取的 LBA读取数据乱码段地址/偏移地址组合错误用x /16bx检查目标内存地址执行到一半卡死栈设在代码区导致覆盖把栈设在低地址、确认不与代码区冲突读 0x1F7 状态异常发送命令前端口参数未完整写入按顺序完整写 0x1F2~0x1F6再写命令代码在真机正常、模拟器异常时序时序时序确认状态轮询条件不依赖特定时序4.6 一个调试小技巧用显存直接看内存内容如果你不想在 Bochs 里一条条看寄存器也可以在 Loader 的最前面写一段临时代码把读到的内存里第一个字节、第二个字节转换成 ASCII 打印到屏幕上。我做过类似操作从目标内存地址取 4 个字节转成十六进制字符往显存 0xB8000 处填。这样就相当于在裸机上写了一个“十六进制查看器”。这种方法的麻烦在于你需要一段额外的转换代码而且容易破坏现场。但好处是它可以在物理机上用不用调试器也能给你一种“我在给操作系统写诊断程序”的真实感。我在学习过程中来回用过几次虽然现在更多依赖 Bochs但这种方式在后续写内核、调试中断时依然很管用建议练一练。5. 从第三章往后看这一章到底在为什么做准备5.1 你不知不觉学到的“广义引导”思维第三章的内容表面上是“读磁盘、搬数据、跳转”但把视角拉高一点你会发现你其实在完成一个通用模式从一个可靠的初始源把一段更大的程序搬到内存中的指定位置然后把控制权交给它。这个模式在现代操作系统的每次启动时都会发生。UEFI 固件加载启动管理器、启动管理器加载内核镜像、内核加载 initramfs……形式上都是这个套路。不同的只是存储介质网络、NVMe、分区镜像和协议复杂度。有了第三章亲手写 MBR 的经验你再看任何“引导链”相关的资料都会有一种“哦原来就是 0x7C00 - Loader - kernel”的亲切感。而且你还会意识到真正的困难不在“读磁盘”而在于“约定”每一层都需要知道上一层的入口地址在哪里、参数放在哪里、内存要不要清理、段寄存器应该是什么状态。这些约定没有写在硬盘上而是写在了程序员的脑子里。调试引导代码的很多痛苦都源于“没有明确约定”。5.2 保护模式、内存分页、ELF 加载全都建立在这套思维上再往后翻几章你会进入保护模式接触 GDT、特权级、分段和分页。那时候你会发现很多代码依然在“搬数据、跳转、约定地址”这三件事上打转只是从实模式换到了保护模式从 LBA 换成了文件系统从直接读扇区换成了解析 ELF。第三章的 MBR 算是一个“最小可用”的模型它足够简单让你看清楚整个引导链条的骨架它又足够真实让你感受到硬件协议和软件逻辑的交互。你可以把这一章当作整套系统在硬件上的“根”——后面所有的内存布局、权限机制、设备抽象本质上都是在这个根上生长出来的。5.3 关于内存布局图值得反复对照第三章里应该有张内存布局图标出了 MBR0x7C00/0x900、Loader、内核内核栈、显存等的位置。我建议把它单独截图或抄下来后续学习每一章时都拿它出来对照一下。学保护模式时看它对不对学分页时再看它对不对。等你学完中断、任务切换再回头看这张图会发现它的很多预留位置都是经过精心计算的。说实话这张图在第三章时的全局意义还没那么明显但越往后它越像一张“城市地图”。你写每一段内核代码都需要知道自己身在哪个“街区”段/页邻居是谁其他模块垃圾倒在哪儿栈区。裸机开发不像是写普通程序倒像是自己当城市规划师所有地块都得提前规划好不能说水管埋好了再挖路。5.4 我的一点实际体会最后说说我自己的体会。做完第三章时我一度觉得自己只是在“照着书抄代码”。但后来回头看真正值钱的不是那几百行汇编而是我在排查各种诡异问题过程中逐渐建立起来的“底层直觉”——看到段寄存器会立刻算物理地址看到端口操作会去查时序看到跳转指令会确认 CS 是否更新。这些直觉在写应用层代码时用不太上但在操作系统开发里是每时每刻都在用的。如果你在这一章卡住了我的建议很简单不要急着往下翻花一个晚上只做一件事——用 Bochs 把 0x7C00 开始的每一条指令都单步执行一遍同时打开寄存器窗口和内存窗口。看着地址、数据、端口值的每次变化你很快会建立起“CPU 在干什么”的图景。这个过程很枯燥但值得。我见过太多人跳过这一步结果后面写内核在地址换算上反复踩坑。另外把代码里的魔数都改成语义化符号也是个好习惯。比如把0xE0、0x20、0x1F0写成有含义的常量并注释哪怕只是DISK_CMD_READ equ 0x20这种简单替换。这对你之后复用read_disk到 Loader 甚至内核里都非常有帮助。毕竟第三章写的这段磁盘读程序后面几章还会频繁出现你要是写得又乱又散后面改起来会想哭。