[WIFI学院] - 00-03 Host、Driver、Firmware、硬件的分工

Host、Driver、Firmware、硬件的分工

一、建立 Host、Driver、Firmware、Hardware 四层模型

1.1 四个角色分别运行在哪里

研究 WiFi 驱动时，经常会同时遇到四个概念：

Host
Driver
Firmware
Hardware

理解它们的第一步，是先明确它们分别位于哪里。

以 RTL8812EU 为例，可以先建立下面的模型：

                     Host
+------------------------------------------+
|                                          |
| Host CPU                                 |
|                                          |
| Application                              |
| Linux                                    |
| RTL8812EU Driver                         |
|                                          |
+------------------------------------------+
                     |
                    USB
                     |
                     v
                 RTL8812EU
+------------------------------------------+
|                                          |
| MCU                                      |
|  └── Firmware                            |
|                                          |
| MAC Hardware                             |
| BB Hardware                              |
| RF Hardware                              |
|                                          |
+------------------------------------------+
                     |
                  Antenna

这里存在两个不同的处理器世界。

第一个是 Host CPU, 它运行：

Application
Linux
RTL8812EU Driver

第二个是 WiFi 芯片内部可能存在的 MCU, 它运行：

Firmware

除此之外，WiFi 芯片内部还有大量专用硬件电路：

MAC Hardware
BB Hardware
RF Hardware

因此，首先要建立一个非常重要的区别：

Driver   → Host CPU 执行的软件
Firmware → WiFi 芯片内部处理器执行的软件
Hardware → WiFi 芯片内部真正的硬件电路

1.2 四个角色之间如何连接

从最粗略的控制关系来看，可以暂时画成：

Application / OS
        ↓
      Driver
        ↓
     Firmware
        ↓
     Hardware

但这张图只能用来帮助理解“谁控制谁”，不能理解成所有数据都必须严格按照这条路径逐层流动。

实际系统中可能同时存在：

Driver → Firmware
Driver → Hardware
Firmware → Hardware

几种关系。

例如 Driver 可能直接写某个硬件寄存器：

Driver -> Register Write -> Hardware

也可能向 Firmware 发送一条命令：

Driver -> Command -> Firmware -> 执行对应操作

因此，Driver、Firmware、Hardware 并不是简单的三个串联流水线模块。

后面会进一步区分 Control Path 和 Data Path

二、Host 与 Driver

2.1 Host 是什么

Host 指负责运行主要软件系统并控制 WiFi 设备的主机。

它可以是：

PC
嵌入式 Linux SoC
OpenIPC 摄像机 SoC
树莓派
MCU

对于我们目前研究的 OpenIPC + RTL8812EU：

OpenIPC SoC = Host
RTL8812EU = WiFi Device

两者通过 USB 连接：

OpenIPC Host
      |
      | USB
      v
  RTL8812EU

Host 拥有自己的：

CPU
RAM
Operating System
Application

所以 Host 和 RTL8812EU 是两个相对独立的系统。

2.2 Driver 运行在哪里

Driver 是运行在 Host 上的软件。

对于当前 Linux 系统：

              Host
+-------------------------------+
|                               |
| Application                   |
|                               |
| Linux Kernel                  |
|   |                           |
|   +-- RTL8812EU Driver        |
|                               |
+-------------------------------+
               |
              USB
               |
               v
           RTL8812EU

因此 RTL8812EU Driver 中的大量 C 代码最终都是：

由 Host CPU 执行。

例如以后源码中会看到很多类似：

rtw_*
hal_*
usb_*

的函数。

这些函数属于 Host 端 Driver 的一部分。

这和运行在 RTL8812EU 内部的 Firmware 是两个不同的软件执行环境。

2.3 Driver 主要负责什么

Driver 位于：

Operating System -> Driver -> WiFi Device

所以它一方面需要面对操作系统，另一方面需要理解具体 WiFi 硬件。

Driver 的主要职责可以粗略分成几类。

与操作系统交互

Linux 并不希望每个应用程序都自己研究：

RTL8812EU寄存器
USB Endpoint
TX Descriptor
RX Descriptor
Firmware Command

这些具体硬件细节。

Driver 需要把具体硬件接入 Linux 提供的设备和网络体系。

因此：

Linux
  ↓
Driver
  ↓
RTL8812EU

Driver 是 Linux 与具体硬件之间的适配层。

设备初始化

RTL8812EU 上电以后，并不是简单插入 USB 就立即处于完整可工作状态。

Driver 需要参与：

设备识别
硬件初始化
Firmware准备
寄存器配置
工作状态建立

等过程。

配置设备

例如上层希望：

设置 Channel
设置 Bandwidth
设置工作模式
设置 TX Power

Driver 需要把这些软件层面的配置要求转换成 RTL8812EU 能够理解的控制操作。

组织 TX / RX

发送和接收数据时，Driver 还需要处理 Host 与 RTL8812EU 之间的数据交换。

例如：

Host Data
    ↓
Driver
    ↓
USB
    ↓
RTL8812EU

以及：

RTL8812EU
    ↓
USB
    ↓
Driver
    ↓
Host

以后学习 TX/RX 数据通路时，会进一步打开这一部分。

现阶段可以把 Driver 的职责概括为：

与操作系统交互
      +
管理和配置设备
      +
组织数据收发
      +
与 Firmware / Hardware 交互

三、Firmware 与 WiFi 芯片内部 MCU

3.1 Firmware 是什么

Firmware 通常翻译为 固件, 它本质上也是程序。

但与普通 Application 和 Linux Driver 不同，它通常运行在设备内部的处理器上，用来控制设备自身的行为。

可以先建立：

Host CPU
   |
   +-- Application
   +-- Linux
   +-- Driver

WiFi Chip Internal MCU
   |
   +-- Firmware

所以, Driver ≠ Firmware, 它们都是软件，但运行位置不同。

可以粗略类比成：

Driver：Host一侧负责管理和控制WiFi设备的软件

Firmware：WiFi芯片内部负责执行部分设备控制任务的软件

Firmware 的存在，使 WiFi 芯片不必把所有复杂控制过程都交给 Host CPU 完成。

3.2 Firmware 运行在哪里

很多 WiFi 芯片内部除了 MAC、BB、RF 等专用硬件之外，还包含一个或多个内部处理器。

这里为了建立模型，可以统一称为 MCU。

于是：

             RTL8812EU

+--------------------------------+
|                                |
| MCU                            |
|  |                             |
|  +-- Firmware                  |
|                                |
| MAC Hardware                   |
| BB Hardware                    |
| RF Hardware                    |
|                                |
+--------------------------------+

Firmware 代码由这个内部 MCU 执行。

因此系统中实际上存在至少两个不同的软件执行环境：

Host CPU -> 执行 Linux Driver

WiFi Internal MCU -> 执行 Firmware

这也是为什么 Driver 与 Firmware 可以互相通信。

它们并不是同一个程序中的两个普通函数。

而是：

运行在两个不同处理器环境中的两套软件。

3.3 Firmware 从哪里来

Firmware 必须先存在于 WiFi 芯片能够执行的位置，内部 MCU 才能运行它。

不同芯片的 Firmware 保存和加载方式可能不同。

一种情况是 Firmware 已经保存在设备内部的非易失性存储器中。

例如可以抽象成：

WiFi Device
    |
Internal Flash / ROM
    |
Firmware

另一种常见方式是：

Firmware 文件保存在 Host 一侧，由 Driver 在设备初始化过程中下载到 WiFi 芯片。

可以表示成：

Host
 |
 | Firmware Image
 v
Driver
 |
 | 下载 Firmware
 v
WiFi Chip
 |
 v
Internal MCU
 |
 v
运行 Firmware

RTL8812EU 驱动研究过程中，我们后面会专门遇到 Firmware Download 这个过程。

所以以后看到“下载 Firmware”，这里的“下载”并不是：

从互联网下载一个文件。

而是：

Host Driver 把 Firmware Image 传输到 WiFi 芯片，使芯片内部 MCU 能够执行它。

这一区别很重要。

3.4 Firmware 主要负责什么

为什么 WiFi 芯片已经有 MAC、BB、RF Hardware，还需要 Firmware？

因为硬件适合执行大量高速、固定、重复的操作，而一些控制逻辑更加适合由程序执行。

例如可以把 WiFi 芯片内部粗略想象成：

              Firmware
                  |
        控制、协调、状态管理
                  |
       +----------+----------+
       |          |          |
      MAC        BB         RF
    Hardware   Hardware   Hardware

Firmware 可以参与一些设备内部控制和管理任务，例如：

状态管理
电源管理
部分协议控制
硬件协调
响应 Host Command
向 Host 上报 Event

具体哪些功能由 Firmware 完成，取决于芯片和驱动架构。

因此不能建立这样的绝对规则：

某个 WiFi 功能一定由 Firmware 完成

更准确的认识是：

WiFi 功能可能分布在 Host Driver、Firmware 和专用 Hardware 三个位置。

不同 WiFi 架构之间，一个重要区别正是：

这些工作究竟被放在了哪里。

这会直接引出下一讲的：

FullMAC
SoftMAC

四、Driver、Firmware 与 Hardware 如何协作

4.1 Driver 直接控制 Hardware

Driver 并不是所有事情都必须先告诉 Firmware。

很多情况下，Driver 可以直接通过硬件接口访问 WiFi 芯片中的寄存器。

例如可以抽象成：

Driver
   ↓
Register Write
   ↓
MAC / BB / RF Hardware

假设某个硬件寄存器控制一个功能：

Register X
Bit 3 = 1

表示开启某项硬件能力。

Driver 就可能通过寄存器访问完成：

读取 Register X
      ↓
修改 Bit 3
      ↓
写回 Register X
      ↓
Hardware 行为发生改变

以后研究 RTL8812EU 源码时，会大量看到：

MAC Register
BB Register
RF Register

以及对应的读写操作。

这些代码的本质就是：

Host Driver -> 访问芯片寄存器 -> 改变 Hardware 状态

所以存在一条直接控制路径：

Driver -> Hardware

4.2 Driver 通过 Firmware 控制芯片

另一种情况是：

某个操作不是简单修改一个寄存器就能完成，而是需要 Firmware 执行一段控制逻辑。

这时 Driver 可以向 Firmware 发送命令。

基本模型是：

Host
+----------------+
|     Driver     |
+----------------+
        |
        | Command
        v
WiFi Chip
+----------------+
|    Firmware    |
+----------------+
        |
        v
    Hardware

例如 Driver 可以告诉 Firmware：执行某项操作

Firmware 收到命令后：

解析 Command -> 执行内部控制逻辑 -> 操作相关 Hardware

这种方式的重要意义在于：

Host 不需要亲自执行设备内部所有细节步骤。

Host Driver 只需要表达：“我要做什么”, Firmware 则负责：“在芯片内部具体怎么做”

以后 RTL8812EU 源码中会遇到 H2C, 即 Host To Controller, 它就是理解这类机制的重要概念之一。

阶段 0 暂时只需要知道它的基本方向：

Driver -> H2C Command -> Firmware

4.3 Firmware 如何向 Driver 返回信息

通信并不是只有 Driver → Firmware, Firmware 也可能需要把设备内部发生的事情通知 Host。

例如：

某个操作完成
某个状态发生变化
某个事件发生

于是存在反方向：

WiFi Chip
+----------------+
|    Firmware    |
+----------------+
        |
        | Event
        v
Host
+----------------+
|     Driver     |
+----------------+

以后研究 RTL8812EU 时会遇到 C2H, 可以暂时理解成 Controller To Host

因此：

H2C：Host / Driver -> Firmware

C2H：Firmware -> Host / Driver

这就建立了 Driver 与 Firmware 之间最基本的双向通信关系。

4.4 数据通路与控制通路的区别

这是理解 WiFi Driver 架构时非常重要的一个概念。

需要区分 Data Path 和 Control Path

Data Path

Data Path 关注的是：

真正需要发送和接收的数据如何移动。

例如 TX 可以粗略表示成：

Host Packet
    ↓
Driver
    ↓
USB
    ↓
WiFi Hardware Data Path
    ↓
MAC / BB / RF
    ↓
Antenna

RX 则反过来：

Antenna
    ↓
RF / BB / MAC
    ↓
WiFi Hardware Data Path
    ↓
USB
    ↓
Driver
    ↓
Host Packet

Control Path

Control Path 关注的是：

Driver 如何配置和管理 WiFi 芯片。

例如：

Driver
   ↓
Register Access
   ↓
Hardware

或者：

Driver
   ↓
H2C Command
   ↓
Firmware
   ↓
Hardware

因此不能简单认为每一个 TX Packet 都一定按照：

Driver
 ↓
Firmware
 ↓
MAC
 ↓
BB
 ↓
RF

这样的软件流水线逐级执行。

Firmware 可能参与设备控制和协调，但大量高速数据处理会由专门的 Hardware Data Path 完成。

这也是专用硬件存在的重要原因。

假设每一个 WiFi Symbol、每一次 OFDM 运算、每一个射频采样都让内部 MCU 用普通软件逐条执行，效率和实时性都会成为严重问题。

所以高速、固定的处理通常更适合 Dedicated Hardware

而复杂但速度要求相对不同的控制逻辑则可以由 Firmware 执行。

4.5 四者完整协作模型

现在可以把 Driver、Firmware、Hardware 组合起来。

首先看控制路径：

                     Host
+------------------------------------------+
|                                          |
|                Driver                    |
|                                          |
+------------------------------------------+
          |                       |
          | Register Access       | Command
          |                       |
          v                       v
+-------------------+      +-------------------+
|     Hardware      |      |     Firmware      |
+-------------------+      +-------------------+
                                   |
                                   | Control
                                   v
                            +-------------------+
                            |     Hardware      |
                            +-------------------+

也就是说 Driver 可以直接控制 Hardware, 也可以通过 Firmware 控制 Hardware.

Firmware 也可以通过 Event 把信息返回 Driver：

Driver <- Event <- Firmware

而数据通路则可以单独理解：

TX Data

Host
 ↓
Driver
 ↓
USB
 ↓
WiFi Data Path
 ↓
MAC
 ↓
BB
 ↓
RF
 ↓
Antenna

因此最终应该建立两个并存的视角：

数据通路：

Host Data
   ↕
Driver
   ↕
USB
   ↕
WiFi Hardware Data Path
   ↕
MAC / BB / RF


控制通路：

Driver
   ├────────→ Hardware
   │
   └────────→ Firmware
                  │
                  └────→ Hardware

这两个路径以后都会成为 RTL8812EU 源码研究的重要主线。

五、回到 RTL8812EU

5.1 RTL8812EU 系统中的四个角色

现在把四个角色映射到我们的实际研究对象。

Host

在 OpenIPC 场景中, OpenIPC SoC 就是 Host。

它拥有自己的 CPU 和 RAM，并运行 Linux。

Driver

我们正在准备研究的 svpcom/rtl8812eu 属于 Host 端 Driver。

这些代码最终运行在 OpenIPC SoC CPU, 而不是 RTL8812EU 内部。

Firmware

RTL8812EU 工作过程中还涉及运行在 WiFi 芯片内部控制处理器上的 Firmware。

Driver 初始化设备时，需要处理 Firmware 相关工作。

后面进入 RTL8812EU 源码以后，我们会真正跟踪 Firmware Download, 以及 H2C, C2H 等机制。

Hardware

RTL8812EU 内部还有实际完成无线通信工作的专用硬件。

现阶段重点认识 MAC, BB, RF, 所以可以得到：

                    OpenIPC Host
+---------------------------------------------+
|                                             |
| Application                                 |
| Linux                                       |
| RTL8812EU Driver                            |
|                                             |
+---------------------------------------------+
                     |
                    USB
                     |
                     v
                   RTL8812EU
+---------------------------------------------+
|                                             |
| MCU                                         |
|  └── Firmware                               |
|                                             |
| MAC Hardware                                |
| BB Hardware                                 |
| RF Hardware                                 |
|                                             |
+---------------------------------------------+
                     |
                  Antenna

5.2 RTL8812EU 上电后的基本关系

RTL8812EU 刚刚连接到 Host 时，整个系统需要经历初始化过程。

阶段 0 暂时只建立非常粗略的顺序：

RTL8812EU连接到USB
        ↓
Host发现设备
        ↓
RTL8812EU Driver开始工作
        ↓
Driver进行设备初始化
        ↓
准备 / 下载 Firmware
        ↓
配置相关 Hardware
        ↓
设备进入可工作状态

真实过程会复杂得多。

例如：

USB初始化
Power Sequence
Firmware Download
MAC初始化
BB初始化
RF初始化

之间存在具体顺序和大量硬件操作。

这些内容会在后面的：

RTL8812EU驱动初始化
Firmware与硬件初始化

阶段真正进入源码研究。

现在只需要知道：

Driver、Firmware 和 Hardware 都会参与 RTL8812EU 从“刚刚上电”到“能够正常收发数据”的过程。

5.3 RTL8812EU 的第一版完整系统架构

到目前为止，可以建立阶段 0 中第一张包含 Host、Driver、Firmware 和 Hardware 的 RTL8812EU 系统图：

                       Host
+------------------------------------------------+
|                                                |
| Application                                    |
|      ↓                                         |
| Linux                                          |
|      ↓                                         |
| RTL8812EU Driver                               |
|                                                |
+------------------------------------------------+
              |                       |
              | USB Data              | Control
              |                       |
              v                       v
                    RTL8812EU
+------------------------------------------------+
|                                                |
|          MCU / Firmware                        |
|                 |                              |
|                 | Control                      |
|                 v                              |
|                                                |
|          MAC Hardware                          |
|               ↕                                |
|          BB Hardware                           |
|               ↕                                |
|          RF Hardware                           |
|                                                |
+------------------------------------------------+
                       |
                    Antenna
                       |
                       ↕
                Wireless Medium

如果只观察数据通路：

Host
 ↓
Driver
 ↓
USB
 ↓
RTL8812EU Data Path
 ↓
MAC
 ↓
BB
 ↓
RF
 ↓
Antenna

如果只观察控制通路：

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

如果观察软件运行位置：

Host CPU
   |
   +-- Linux
   +-- RTL8812EU Driver


RTL8812EU Internal MCU
   |
   +-- Firmware


RTL8812EU Dedicated Hardware
   |
   +-- MAC
   +-- BB
   +-- RF

这三张图分别回答三个不同的问题：

数据怎么走？
控制命令怎么走？
代码在哪里运行？

以后分析 RTL8812EU 源码时，遇到一个函数或机制，可以逐渐养成判断习惯：

这是 Data Path 还是 Control Path？
这是 Host Driver 做的还是 Firmware 做的？
这是软件行为还是 Hardware 行为？

这也是最终进行 MCU / RTOS 移植时必须具备的判断能力。

六、本讲知识总结

• Driver 运行在 Host CPU 上，Firmware 运行在 WiFi 芯片内部处理器上。
• MAC、BB、RF 属于 WiFi 芯片内部的专用硬件功能。
• Driver 可以直接控制 Hardware，也可以通过 Firmware 完成部分控制。
• H2C 表示 Host 向芯片控制侧发送命令，C2H 表示芯片控制侧向 Host 返回信息。
• Data Path 与 Control Path 是两个不同视角，不能把 Firmware 简单理解成每个 TX/RX Packet 必经的软件流水线。

七、下一讲

下一讲：

00-04_FullMAC_SoftMAC与RTL8812EU定位

将研究 WiFi 功能在 Host、Firmware 和 Hardware 之间有哪些不同的分工方式，并由此理解 FullMAC、SoftMAC 以及 RTL8812EU Driver 的基本定位。