接上一篇
从地址0x8200开始的是lzma_decompress.img。这是由startup_raw.S编译生成的。这个文件稍微复杂点。首先一开始就是个跳转指令：
ljmp $0, $ABS(LOCAL (codestart)) /* 机器码：ea 1c 82 */
跳转到0x821c，这里是真正的开始代码。0x8203到0x821b之间存放的是一些特殊数据，如压缩数据前后的长度、冗余数据的长度等，由GRUB安装时填写，后面会用到。
接下来设置实模式堆栈后，切换到保护模式：DATA32 call real_to_prot
然后打开Gate A20，即第21根地址线的控制线： call grub_gate_a20 这是在80286时代IBM想出来的通过开闭Gate A20来兼容8086/8088实模式的方法。在保护模式下，为了正常寻址必须把Gate A20打开。
然后开始利用里德-所罗门（Reed Solomon）算法对GRUB受保护数据进行检查和修复:
call EXT_C (grub_reed_solomon_recover)
RS恢复代码是用C写的，文件是lib/reed_solomon.c。编译时会先编译成rs_decoder.S然后被startup_raw.S包含。（最新的GRUB版本应该生成的文件名是rs_decoder.h，只是改了个名字。）
RS保护的范围以reed_solomon_part标记开始（Gate A20代码后，多重启动代码前），到lzma_decompress.img结尾，再到后面接着的压缩过的kernel.img映像结尾。在此后面是冗余数据区。冗余数据是被算法利用对受保护数据进行修复的。
这样算来GRUB数据的前5个扇区（0-4）以及部分第6个扇区是不受保护的，其他都受到了保护。
为什么要做这件事情？如之前提到的，硬盘2-62号扇区是不安全的，有可能被其他软件写入数据破坏。利用冗余数据，GRUB有能力从这种破坏中正常引导，如果破坏的数据量在可接受范围内的话。我记得GRUB社区有一场讨论，关于如何处理与其他软件冲突的问题。就像一场罗马元老院辩论一样，有人忿忿不平，觉得这种在保留扇区写隐藏数据的行为是邪恶的，GRUB应该以牙还牙，数据恢复过来后，就应该写回硬盘，虽然这会造成其他软件不能工作。也有人认为，普通用户并不会理解这里面的是非曲折，而把一切问题怪罪到GRUB头上，GRUB应仅仅支持防御性的操作。
RS恢复操作执行完后跳转到标记post_reed_solomon对余下的压缩过的kernel.img进行解压缩：
jmp post_reed_solomon /* 偏移量：0x07a6，不同版本会有差异 */
解压后的数据存放在地址0x100000开始的内存区域。
解压算法采用LZMA算法。具体实现在lzma_decode.S中，是手工优化精简的版本。
最后执行跳转指令：
jmp *%esi /* GRUB_MEMORY_MACHINE_DECOMPRESSION_ADDR = 0x100000 */
跳转到地址0x100000执行下一条指令。也就是刚才解压缩出来的第一条指令。
至此startup_raw.S执行完毕。