[WIFI学院] - 00-04 FullMAC、SoftMAC 与 RTL8812EU 定位

FullMAC、SoftMAC 与 RTL8812EU 定位

一、WiFi 功能应该由谁负责

1.1 从分工问题出发

前面已经建立了 WiFi 系统中的几个重要角色：

Host Driver
Firmware
MAC Hardware
BB Hardware
RF Hardware

接下来会遇到一个重要问题：

WiFi 的各种功能，究竟应该放在 Host Driver 中实现，还是放在 WiFi 芯片内部实现？

答案并不是固定的, 不同 WiFi 芯片会采用不同的分工方式, 这就引出了：

FullMAC
SoftMAC

两种重要架构。

1.2 Host 与 WiFi 芯片之间存在不同的分工方式

假设一个 WiFi 系统需要完成：

802.11 Frame处理
扫描
认证
关联
ACK
重传
速率控制
省电管理
加密
数据收发
PHY控制

这些功能并不一定全部由同一个处理单元完成。

一种设计思路是：

Host只负责较高层控制
        ↓
大量WiFi功能交给WiFi芯片

另一种设计思路是：

Host承担更多802.11处理
        ↓
WiFi芯片主要负责更底层的无线收发

因此，理解 FullMAC 和 SoftMAC 的关键不是记住两个名称，而是始终问：

MAC 以及相关 802.11 管理功能主要放在哪里实现？

二、FullMAC 架构

2.1 FullMAC 是什么

FullMAC 的基本思想是：

将较完整的 MAC 和 WiFi 管理功能放在 WiFi 芯片内部完成。

Linux Wireless 文档对 FullMAC 的一个重要描述是：MLME 由硬件/设备侧管理

MLME 是 MAC Sublayer Management Entity, 即 MAC 子层管理实体, 它涉及 WiFi 中很多管理状态和流程。

例如 STA 连接 AP 时会涉及：

扫描 -> 认证 -> 关联 -> 建立连接

在 FullMAC 架构中，这类 WiFi 管理功能的大量具体工作位于 WiFi Device 一侧。

因此可以建立一个简化模型：

              Host
+-----------------------------+
|                             |
| Operating System            |
| FullMAC Driver              |
|                             |
+-----------------------------+
              |
              | Command / Data
              |
              v
          WiFi Device
+-----------------------------+
|                             |
| Firmware                    |
| MAC相关功能                  |
| BB                          |
| RF                          |
|                             |
+-----------------------------+
              |
           Antenna

Host 不需要自己实现全部 802.11 MAC 管理逻辑, 它可以通过命令告诉 WiFi Device：

扫描网络
连接这个AP
断开连接
设置Channel

设备内部再完成大量具体操作。

2.2 FullMAC 中 Host Driver 负责什么

FullMAC 并不意味着不需要Driver, Driver 仍然是 Host 操作系统与 WiFi Device 之间的重要桥梁。

只是相比把更多 MAC 功能放在 Host 的架构，FullMAC Driver 可以把更多具体 WiFi 操作交给设备内部完成。

例如：

Operating System
       ↓
Driver
       ↓
“扫描附近网络”
       ↓
WiFi Device
       ↓
内部执行具体扫描流程

Driver 仍然需要负责：

设备初始化
Firmware加载
Host与设备之间的数据交换
Host与Firmware之间的命令交换
向操作系统提供WiFi接口
处理设备事件
错误处理
设备资源管理

所以 FullMAC 的“Full”不能理解成：

WiFi 芯片完全独立工作，Host 什么都不用做。

它表达的是：

MAC 和相关 WiFi 管理功能更多地位于 Device 一侧。

2.3 FullMAC 的基本数据与控制模型

FullMAC 可以建立两条基本路径。

控制路径：

Operating System
       ↓
FullMAC Driver
       ↓
Command
       ↓
Firmware / Device
       ↓
WiFi功能

例如：

Host要求扫描
       ↓
Driver发送Command
       ↓
Firmware执行扫描
       ↓
Firmware返回结果
       ↓
Driver
       ↓
Operating System

数据路径则可以理解成：

Host Packet
    ↓
Driver
    ↓
Bus
    ↓
WiFi Device
    ↓
MAC / BB / RF
    ↓
Antenna

因此 FullMAC 最重要的特征不是数据是否经过 Host，而是：

大量 MAC 管理功能被放在 WiFi Device 一侧。

三、SoftMAC 架构

3.1 SoftMAC 是什么

SoftMAC 采用另一种分工方式, 其核心思想是：

把一部分原本可以由 WiFi Device 完成的 MAC 和 802.11 协议功能放到 Host 软件中实现。

因此, SoftMAC 中的 Soft 可以帮助理解为：

更多 MAC 功能通过 Host Software 实现。

可以先建立：

                Host
+--------------------------------+
|                                |
| Operating System               |
|                                |
| 802.11 MAC Software            |
|                                |
| SoftMAC Driver                 |
|                                |
+--------------------------------+
                |
                | Bus
                |
                v
          WiFi Hardware
+--------------------------------+
|                                |
| Lower MAC / PHY                |
| BB                             |
| RF                             |
|                                |
+--------------------------------+
                |
             Antenna

这里的 WiFi Device 仍然具有 MAC Hardware。

SoftMAC 并不意味着芯片里面没有MAC硬件, 而是：

MAC 功能的实现被拆分了，其中一部分放到了 Host Software。

3.2 SoftMAC 中 Host 负责什么

SoftMAC 中 Host 需要参与更多 802.11 处理。

例如 Host 软件可能需要处理：

802.11 Frame管理
部分MAC状态管理
速率控制
扫描相关逻辑
接口管理
Management Frame处理

具体哪些功能由 Host 完成，哪些功能仍由 Firmware 或 Hardware 完成，取决于具体芯片和驱动。

因此 SoftMAC 不应该理解成所有MAC功能全部由CPU用软件实现, 更准确的认识是：

完整MAC功能
     |
     +---- 一部分由Host Software完成
     |
     +---- 一部分由Firmware完成
     |
     +---- 一部分由MAC Hardware完成

例如时间要求极高的操作，通常不适合完全依靠 Host 软件实时完成。

所以 SoftMAC 仍然需要大量硬件支持。

3.3 mac80211 在 SoftMAC 中的位置

Linux 为 SoftMAC WiFi Driver 提供了一个非常重要的框架 mac80211,

Linux Wireless 官方文档将 mac80211 描述为：

用于编写 SoftMAC 无线设备驱动的框架。

因此，一个典型 Linux SoftMAC 系统可以粗略表示为：

            User Space
                |
                v
             Linux
                |
                v
            cfg80211
                |
                v
            mac80211
                |
                v
         SoftMAC Driver
                |
                v
          WiFi Hardware

其中, mac80211 实现了一套通用的 802.11 MAC 软件框架。

这样，不同 WiFi 芯片的 Driver 就不需要分别从头实现大量相同的 802.11 MAC 软件功能。

例如：

Driver A ──┐
           |
Driver B ──┼──> mac80211提供通用802.11功能
           |
Driver C ──┘

这也是 Linux 使用统一 WiFi 框架的重要意义。

现在不需要继续深入：

cfg80211
nl80211
mac80211 API
struct ieee80211_hw

这些内容会在：

阶段4：Linux WiFi子系统

正式学习。

现阶段只需要记住：

mac80211 是 Linux 为 SoftMAC Driver 提供的重要 802.11 MAC 软件框架。

3.4 SoftMAC 的基本数据与控制模型

典型 SoftMAC 架构可以粗略表示成：

                   Host
+--------------------------------------+
|                                      |
| Application                          |
|                                      |
| Linux                                |
|                                      |
| cfg80211                             |
|                                      |
| mac80211                             |
|                                      |
| SoftMAC Driver                       |
|                                      |
+--------------------------------------+
                   |
                 Bus
                   |
                   v
              WiFi Device
+--------------------------------------+
|                                      |
| MAC Hardware                         |
| BB                                   |
| RF                                   |
|                                      |
+--------------------------------------+
                   |
                Antenna

其中 Host 软件参与更多 802.11 MAC 处理。

所以与 FullMAC 相比，SoftMAC 最值得关注的变化是：

更多MAC功能
     ↑
     |
从WiFi Device一侧
     |
移动到Host Software一侧

四、FullMAC 与 SoftMAC 的本质区别

4.1 两种架构真正不同的是什么

现在可以把两种架构放在一起。

FullMAC：

Host
 |
 | 相对高层的命令和数据
 |
 v
WiFi Device
 |
 | 大量MAC和管理功能
 |
 v
PHY / RF

SoftMAC：

Host
 |
 | 更多802.11 MAC处理
 |
 v
SoftMAC Driver
 |
 v
WiFi Device
 |
 | 更底层的MAC / PHY功能
 |
 v
RF

所以区分 FullMAC 与 SoftMAC 时，最重要的问题是：

802.11 MAC 和相关管理功能主要在哪里实现？

可以建立一个概念上的连续方向：

更多功能放在Host
        ↑
        |
     SoftMAC
        |
        |
     FullMAC
        |
        ↓
更多功能放在WiFi Device

这张图表达的是分工思想，而不是严格的量化比例。

4.2 两种架构并不是简单的非黑即白

真实 WiFi 芯片往往比 FullMAC, SoftMAC 两个名字复杂得多。

实际功能可能分布在：

Host Software
Firmware
MAC Hardware

多个位置。

例如某个功能可能：

Host负责决策
     ↓
Firmware负责执行流程
     ↓
Hardware负责实时操作

另一个功能则可能：

Host直接配置Hardware

所以不能建立这样的绝对认识：

FullMAC：所有MAC工作都在Firmware
SoftMAC：所有MAC工作都在Host

这两句话都过度简化, 更准确的理解是：

FullMAC 和 SoftMAC 描述的是 MAC 与相关管理功能在 Host 和 Device 之间的总体分工方式。

具体芯片仍然需要具体分析。

4.3 Driver、Firmware、Hardware 分工与 FullMAC / SoftMAC 的关系

现在可以把上一讲与本讲统一起来。

WiFi 系统中存在：

Host Driver
Firmware
Hardware

大量 WiFi 功能需要分配给这三个执行位置。

例如：

某项WiFi功能
     |
     +---- Host Driver
     |
     +---- Firmware
     |
     +---- Hardware

不同芯片选择不同的分工方式，就会形成不同的 WiFi 架构。

因此, FullMAC / SoftMAC 并不是突然出现的两个孤立概念, 它们本质上是在回答上一讲留下的问题：

WiFi MAC 功能到底应该由 Host、Firmware 和 Hardware 中的谁来完成？

五、Realtek Vendor Driver 是什么

5.1 什么叫 Vendor Driver

Vendor 是厂商, Vendor Driver 可以简单理解成：

由芯片厂商提供或基于芯片厂商原始代码形成的驱动实现。

例如 Realtek 为自己的 WiFi 芯片提供 Linux Driver 时，因为 Realtek 最了解自己的：

Register
Firmware
TX / RX Descriptor
MAC
BB
RF
Power Sequence
Calibration
不同芯片之间的差异

所以 Driver 中会包含大量 Realtek 自己的实现, 这类 Driver 往往拥有自己的完整软件框架。

例如我们后面会在 RTL8812EU 中看到：

core/
hal/
include/
os_dep/
platform/

这意味着它并不是只有少量“Linux 与硬件之间的胶水代码”, Driver 自己包含了相当庞大的 WiFi 驱动框架。

5.2 Vendor Driver 与 Linux mac80211 的关系

这里需要区分两个不同维度的概念。

Vendor Driver 强调的是：

这套 Driver 主要来自芯片厂商自己的驱动架构。

而 mac80211 是：

Linux 提供的通用 SoftMAC 框架。

典型 mac80211 SoftMAC Driver 可以想象成：

Linux
 ↓
cfg80211
 ↓
mac80211
 ↓
Chip Driver
 ↓
Hardware

Driver 可以利用 Linux 已经提供的 mac80211 来完成大量通用 802.11 MAC 功能。

而一些 Vendor Driver 会拥有自己较完整的：

MAC管理
TX / RX
Security
Power Management
Firmware管理
Hardware Abstraction

等代码。

这种 Driver 不一定采用：

mac80211 -> 简单Chip Driver

这样的典型结构。

因此：

看到一个 Linux WiFi Driver，不能默认它一定建立在 mac80211 上。

5.3 为什么 RTL8812EU 源码会很庞大

这也解释了为什么打开 Realtek RTL8812EU Driver 后，会看到非常庞大的源码。

因为里面不只是 USB读写 和 寄存器访问, 还可能包含大量：

802.11相关逻辑
TX
RX
Security
Power Management
Station管理
AP功能
Monitor Mode
Firmware管理
Hardware初始化
MAC配置
BB配置
RF配置
USB适配
Linux适配
不同芯片支持
不同平台支持

所以我们以后看到：

core/

里面大量代码时，不应该奇怪：

为什么一个“硬件驱动”里面还有这么多 WiFi 协议代码？

原因就在于：

Realtek Vendor Driver 自己承担了大量 WiFi 软件功能，而不是把所有这些工作都交给 Linux mac80211。

六、RTL8812EU 到底属于什么位置

6.1 RTL8812EU 不是典型的 mac80211 SoftMAC Driver

现在回到我们的实际研究对象：

https://github.com/svpcom/rtl8812eu.git

这个仓库是基于 Realtek v5.15.0.1-249 Vendor Driver 的 RTL8812EU / RTL8822EU Linux Driver，并由 svpcom 在此基础上加入和维护 FPV、packet injection 等相关修改。

从源码组织和 Linux 接入方式看，它不是典型的：

cfg80211
   ↓
mac80211
   ↓
SoftMAC Chip Driver

结构。

它拥有自己的：

core
hal
os_dep
platform

等完整驱动框架。

同时它会与 Linux cfg80211 发生交互。

这里有一个很重要的区别：使用 cfg80211 并不等于 使用 mac80211

Linux Wireless 的架构本身就允许：

FullMAC Driver
      ↓
直接使用 cfg80211

以及：

SoftMAC Driver
      ↓
mac80211
      ↓
cfg80211

这两种不同结构。

因此以后研究 RTL8812EU 时，不能拿典型 mac80211 SoftMAC Driver 的源码结构直接套在它身上。

6.2 RTL8812EU 的实际分工特点

对于 RTL8812EU，我们更应该采用前面已经建立的：

Host Driver
Firmware
Hardware

三者分工模型来理解。

可以先建立：

                  Host
+--------------------------------------+
|                                      |
| Linux                                |
|                                      |
| Realtek RTL8812EU Vendor Driver      |
|                                      |
| 大量WiFi Driver逻辑                   |
|                                      |
+--------------------------------------+
                   |
                  USB
                   |
                   v
              RTL8812EU
+--------------------------------------+
|                                      |
| Firmware                             |
| MAC Hardware                         |
| BB Hardware                          |
| RF Hardware                          |
|                                      |
+--------------------------------------+
                   |
                Antenna

也就是说：

RTL8812EU 并不是一个“Host 什么都不管，只向 Firmware 下高级命令”的极端黑盒设备。

Host 侧 Realtek Driver 本身包含大量 WiFi 逻辑和硬件控制代码。

与此同时：

RTL8812EU 芯片内部也有 Firmware 和专用 MAC/BB/RF Hardware 承担大量工作。

因此后面真正研究源码时，与其只记一个 FullMAC 或者 SoftMAC 标签，更重要的是逐渐搞清楚：

这个具体功能是谁做的 :

Host Driver？
Firmware？
MAC Hardware？
BB Hardware？
RF Hardware？

这才是以后源码分析和 MCU 移植真正需要的能力。

6.3 svpcom/rtl8812eu 在整个系统中的位置

现在把实际研究仓库放入 OpenIPC 系统：

                    OpenIPC Host
+----------------------------------------------+
|                                              |
| WFB-NG                                       |
|                                              |
| Linux                                        |
|                                              |
| Linux WiFi相关接口                            |
|                                              |
| svpcom/rtl8812eu                             |
|                                              |
| Realtek Vendor Driver                        |
|                                              |
+----------------------------------------------+
                       |
                      USB
                       |
                       v
                   RTL8812EU
+----------------------------------------------+
|                                              |
| Firmware                                     |
| MAC Hardware                                 |
| BB Hardware                                  |
| RF Hardware                                  |
|                                              |
+----------------------------------------------+
                       |
                    Antenna
                       |
                       v
                Wireless Medium

svpcom 的仓库 README 明确说明，该仓库是 RTL8812EU / RTL8822EU Linux Driver，基于 Realtek v5.15.0.1-249 Driver，并且当前分支主要面向 FPV 使用。

因此我们后面的源码研究对象，本质上是：

Realtek Vendor Driver  + svpcom针对FPV进行的修改

6.4 为什么这个架构对 MCU 移植很重要

现在可以第一次从架构角度看我们的最终目标：

把 RTL8812EU 移植到 MCU 或其他非 Linux 平台。

如果 RTL8812EU Driver 只是：

Linux API -> 几个简单硬件寄存器

那么移植可能非常简单。

但实际情况是 Realtek Vendor Driver 内部包含大量不同性质的代码。

例如可以初步分类为：

Linux Specific
      |
      +-- Linux Device Model
      +-- Linux Network API
      +-- cfg80211
      +-- Kernel Thread / Lock / Timer
      +-- Memory API

Realtek Driver Core
      |
      +-- WiFi Core Logic
      +-- TX / RX
      +-- Device State

Firmware Interface
      |
      +-- Firmware Download
      +-- H2C
      +-- C2H


USB Transport
      |
      +-- USB Control
      +-- USB Bulk TX
      +-- USB Bulk RX


Hardware HAL
      |
      +-- Register
      +-- MAC
      +-- BB
      +-- RF

未来移植时，不能简单：

复制Linux Driver -> 在MCU编译

而是需要：

RTL8812EU Linux Driver
          ↓
识别Linux依赖
          ↓
识别Realtek Core
          ↓
识别USB Transport
          ↓
识别Firmware Interface
          ↓
识别Hardware HAL
          ↓
重新设计Platform Layer
          ↓
MCU / RTOS Driver

这也是为什么当前整个学习路线不能只研究几个 TX/RX 函数。

我们最终需要真正理解：

哪些代码属于 Linux，哪些代码属于 WiFi 协议，哪些代码属于 Realtek Driver 框架，哪些代码则是控制 RTL8812EU 硬件不可缺少的部分。

七、阶段 0 最终系统地图

7.1 把四讲知识组合起来

经过阶段 0 的四讲，现在可以第一次建立比较完整的 RTL8812EU 系统地图：

                         Host
+----------------------------------------------------+
|                                                    |
| Application / WFB-NG                               |
|                                                    |
| Linux                                              |
|                                                    |
| Linux Network / WiFi System                        |
|                                                    |
| Realtek RTL8812EU Vendor Driver                    |
|                                                    |
|   Driver Core                                      |
|   Hardware Control                                 |
|   Firmware Interface                               |
|   USB Interface                                    |
|                                                    |
+----------------------------------------------------+
                         |
                        USB
                         |
                         v
                      RTL8812EU
+----------------------------------------------------+
|                                                    |
| Internal MCU                                       |
|      |                                             |
|      +-- Firmware                                  |
|                                                    |
| MAC Hardware                                       |
|      |                                             |
|      v                                             |
| PHY                                                |
|      |                                             |
|      +-- BB                                        |
|      |                                             |
|      +-- RF                                        |
|                                                    |
+----------------------------------------------------+
                         |
                      Antenna
                         |
                         v
                 Wireless Medium

发送方向：

Application
    ↓
Linux
    ↓
RTL8812EU Driver
    ↓
USB
    ↓
RTL8812EU
    ↓
MAC
    ↓
BB
    ↓
RF
    ↓
Antenna
    ↓
Wireless Signal

接收方向：

Wireless Signal
    ↓
Antenna
    ↓
RF
    ↓
BB
    ↓
MAC
    ↓
RTL8812EU
    ↓
USB
    ↓
RTL8812EU Driver
    ↓
Linux
    ↓
Application

同时还有控制路径：

Driver
   |
   +--------→ Hardware
   |
   +--------→ Firmware
                  |
                  +--------→ Hardware

这三张图：

系统架构图
数据通路图
控制通路图

就是阶段 0 最重要的成果。

7.2 阶段 0 之后哪些部分仍然是黑盒

现在我们已经知道整个系统：

有什么
在哪里
大概负责什么
彼此怎么连接

但是几乎所有模块内部仍然是黑盒。

例如：

Linux Driver 到底是什么？不知道。

Linux Network Stack 如何把 Packet 交给 Driver？ 不知道。

cfg80211, mac80211, nl80211 具体怎么工作？不知道。

802.11 Frame 究竟长什么样？不知道。

USB 如何真正传输一个 TX Packet？不知道。

Firmware Download 具体如何完成？不知道。

TX Descriptor / RX Descriptor 是什么？ 不知道。

MAC / BB / RF Register 如何控制 RTL8812EU？也不知道。

这些并不是阶段 0 遗漏的内容, 它们正是后续各阶段需要逐渐打开的黑盒：

阶段1     Linux Driver基础
阶段2     Linux网络设备基础
阶段3     IEEE 802.11基础
阶段4     Linux WiFi子系统
阶段5     USB WiFi设备基础
阶段6以后   正式进入RTL8812EU源码

        ↓

初始化
Firmware
TX
Packet Injection
RX
MAC / BB / RF

        ↓

最终进入MCU / RTOS移植

阶段 0 的任务并不是把这些东西学会, 阶段 0 的任务是：

在深入任何一个黑盒之前，先知道它在整个系统中的什么位置。

八、本讲知识总结

• FullMAC 与 SoftMAC 的核心区别之一，是 802.11 MAC 和管理功能在 Host 与 WiFi Device 之间的分工不同。
• Linux mac80211 是面向 SoftMAC Driver 的通用 802.11 软件框架。
• Vendor Driver 是厂商自己的驱动实现方式，与 FullMAC/SoftMAC 不是完全相同维度的概念。
• RTL8812EU 的 Realtek Vendor Driver 自身包含大量 WiFi 逻辑和硬件控制代码，并不是典型的简单 mac80211 SoftMAC Driver。
• 后续研究 RTL8812EU 时，比简单记住 FullMAC/SoftMAC 标签更重要的是判断一个具体功能究竟由 Host Driver、Firmware 还是 Hardware 完成。

九、阶段 0 结束

阶段 0 到这里完成。

我们已经建立：

Host
Driver
USB
Firmware
MAC
PHY
BB
RF
Antenna

之间的第一版整体关系。

下一阶段：

阶段1：Linux驱动基础

将开始打开第一个真正的技术黑盒：

Linux Driver

研究 Linux 中 Driver 到底是什么，以及一个 .ko 驱动模块是怎样被 Linux 加载并开始控制硬件设备的。