"再好的交通规则，也需要好的道路和车辆来支撑。"

本章导读

前两章我们学习了 802.11 的协议层面——交通规则。但在数据真正 "上路" 之前，它必须经过一系列硬件处理：数字信号变成模拟信号，基带信号变成射频信号，功率被放大，然后通过天线发射到空中。这一章我们暂时离开协议，了解 "道路基础设施"——WiFi 的射频硬件。

"当第一个十字路口堵车时，人们做的第一件事就是修更宽的路。"

本章导读

1997 年的 802.11 标准只有 2 Mbps——这在拨号上网时代勉强够用，但随着互联网内容的丰富，2 Mbps 远远不够。1999 年，两个几乎同时发布的修正案彻底改变了局面：802.11b 把速率提升到 11 Mbps，802.11a 更是达到了 54 Mbps。

"所有伟大的交通系统，都始于一个简单的十字路口。"

本章导读

1997 年 6 月，IEEE 发布了 802.11 标准——无线局域网的第一个正式标准。在我们的比喻中，这就像是在一个小镇上建立了第一个十字路口：有了基本的交通规则，有了红绿灯，有了简单的道路。虽然简陋，但它定义了所有后续交通系统的基础架构。

"如果你能理解一个十字路口的交通管理，你就能理解 Wi-Fi。"

1 为什么有这个系列？

IEEE 802.11 协议族是现代无线通信的基石。从 1997 年的第一个标准（2 Mbps）到 2024 年的 Wi-Fi 7（46 Gbps），速率提升了 23000 倍。但这些协议标准动辄数千页，充满了密集的技术术语和抽象的状态机描述，让大多数学习者望而却步。

主要是受打击了..md.. 太多不会了，又重新拾起来了，这次为了方便也不搞什么虚拟机了，所有环境完全在 Win10 上，主要是笔记本有点破，再搞个虚拟机有点吃不消了.. 所以参考了下各种教程，最终使用 vscode + gdb + qemu 的组合.. 或许 qemu 会换成 Bochs..

1 环境搭建

1.1 gcc 工具链

可以去这个 github：https://github.com/blessingwater/GCC_x86_64-elf-tools-windows 下载，解压之后添加环境变量即可

作为 OS 研发，在 framework 加点 api，写个 apk 验证想法是常有的事，什么系统 api，隐藏 api 更是想用就用，怎么能被@hide限制？所以一般的写的 apk 都是集成在系统源码里面，比如 Settings，加上系统签名，这样确实没有@hide限制了，但是这样基本都是基于记事本开发，没有 IDE 的提示来得舒服，但是用 Android Studio 打开，由于原生 sdk 的限制，调用隐藏的 api 或咱们自己加的 api 会报红，这代码写起来就不爽。所以咱就是要整个两者兼得的方法，核心是两点，一是系统的 jar 包，也就是 sdk；二是 platform 签名，没有签名认证，是安装不了的

关于 sdk，咱们手上有源码是可以自己编译的，直接lunch sdk-eng，整编就好了，出来个啥，不大清楚，没用过，这里不用这个法子，此处选择用哪个模块导入哪个模块的 jar 包；系统签名相信就按着步骤来生成就好了

上一节 loader 程序装载完 kernel 后，执行了jmp SelectorCode64:OffsetOfKernelFile命令跳转到 kernel 部分了，意味着 Loader 将处理的控制权交给了 Kernel

处理器把控制权交给 kernel 后，kernel 最先执行的是内核执行头程序。内核执行头程序是一段精心设计的汇编代码，而且必须借助特殊的编译链接方法才能得到最先执行。

内核头程序负责为操作系统创建段结构和页表结构，设置某些结构的默认处理函数、配置关键寄存器等工作。在完成上述工作后，依然要借助远跳指令才能进入系统内核主程序。

如何将内核执行头程序编译生成到整个内核程序文件的起始处？手动编写内核程序的链接脚本，在内核程序的链接过程中，链接器会按照链接脚本描述的地址空间布局，把编译好的各个程序片段填充到内核程序文件中。

看完有点懵，都是内核程序为啥要咱手动指定谁先谁后？大概是因为内核头是汇编写的，内核是 c 写的.. 要让 head 先执行就得在 lds 中指定第一条指令是啥.. 编译部分参考哈: ld - 链接脚本学习笔记与实践过程

之前 gitee 图床挂了，然后 gitee 想用 pages 也必须用身份证，折腾一整最后放弃了 gitee，直接用 github 好了 (还是 github 靠谱)，本想着研究一下 hugo，但是新东西费时间啊，就继续使用 hexo+next 了，算是升了个级，并且添加了 github CI，解决环境，部署问题，一个字，爽！

首先搭建 hexo 博客步骤还是和 Use hexo + github to build a blog | Sidney God 一样，按照步骤做就好了，注意这里不要去改 node_modules 源码了 (好像除了 markdown 和 mathjax 冲突，也没啥需要改的，kmarked 不适用新版本 hexo，别折腾了..)，环境部署麻烦

《64 位》比《32 位》多了一步 loader.bin 似乎，《32 位》的下一步直接就是导入 C 语言，开始搞系统了，《64 位》还得再来个 loader，接着干吧.. 这一节很重要，承上启下，甚至于内容也是

这次把书上的源码上传的 gitee 了: 00_一个 64 位操作系统的设计与实现/一个 64 位操作系统的设计与实现 - 源代码/第二部分 初级篇/第 3 章/程序/程序 3-4・Sidney/MakeOS - 码云 - 开源中国 (gitee.com)

书上说，Loader 的作用很大，大概包括：

• 检测硬件信息

  主要是通过 BIOS 中断服务程序来获取和检测硬件信息。BIOS 上电自检的大部分信息只能在实模式下获取，内核运行在非实模式下，所以需要在进入内核前将信息检测出来，再作为参数提供给内核程序使用。比如获取 ROM，RAM，设备寄存器和内存空洞等资源的物理地址范围交给内存管理单元模块维护；通过 VBE 功能检测出显示器支持的分辨率，显示模式，刷新率以及显存物理地址以配置合理的显示模式

• 处理器模式切换

  BIOS 运行的实模式到 32 位操作系统用的保护模式，再到 64 位操作系统用的 IA-32e 模式 (长模式)

• 向内核传递数据

  向内核传递两种数据，控制信息：控制内核执行流程或限制内核某些功能；硬件数据信息：检测出来的硬件数据信息，保存在固定的内存地址中，并将数据其实内存地址和数据长度作为参数传递给内核。

1 执行环境介绍

在 find loader 那一节之后，发现后面的代码真的看不懂了，直接抄也没有意义，于是补了一下相关的知识.. 希望能继续下去

1.1 CPU 工作模式

参考 Intel 手册卷 3 第 2.2 MODES OF OPERATION

32 位的支持三种工作模式和一种准工作模式

• 实地址模式 (Real-address mode)，处理器上电 (power-up) 或复位 (reset) 后处于该模式。这个模式实际上是为了兼容 8086，因为地址线只有 20 根，限制了寻址只能是 1M 大小，也就是通过$\text {段寄存器} << 4 + \text {偏移地址}$方式寻址。进入这个模式，也就只使用 20 根地址线，主要是因为 A20M# 引脚被屏蔽了

• 保护模式 (Protected mode)，这个是 80386 时期引入的，也就是 32 位处理器原本的工作模式。在这个模式下不再使用$\text {段寄存器} << 4 + \text {偏移地址}$的方式寻址，而是通过段描述符的方式描述基址和限长，并通过描述符中的属性设置实现对内存段的访问限制和数据保护。

• 虚拟 8086 模式 (Virtual-8086 mode)，是一种准工作模式，目的是为了在保护模式下能够执行 8086 程序

  Read more »