项目地址: github.com/qtopie/mt7603u
十年前我发现了 360 随身WiFi 3 代这款高性价比的设备（MT7603U 芯片，2.4GHz 2T2R 300M），尝试过修复 vendor 驱动但依然有很多 bug；如今借助 AI，我们基于现代 Linux
mac80211子系统和 Rust/C 混合架构把它彻底重写了，实现了从固件下载到 STA、AP、Monitor 及 802.11n 300M MIMO 的全链路实机闭环。本文记录我们如何通过“知识对齐 + 架构决断 + 目标分解 + 硬件在环测试”的人机协作工作流，完成这个内核级无线驱动的开发。
1. 设备背景
十年前我发现了 360 随身WiFi 3 代（USB ID: 0x0E8D:0x760C）这款高性价比的无线网卡，搭载联发科 MT7603U 芯片，板载双天线，硬件规格相当不错。当年我曾尝试过去修复官方提供的 vendor 驱动，但由于其基于陈旧的 RTMP 单体架构，代码冗长混乱，修补后依然存在很多 bug，且无法原生接入现代 Linux 的 mac80211 体系。
如今借助 AI，我们不再给 vendor 旧代码缝缝补补，而是将其作为底层寄存器与协议参考，从零用 C + no_std Rust 重写了一个符合 Linux 主线 mac80211 规范的现代化驱动。
2. 知识注入：如何让 AI 具备内核级的“心智模型”？
让 AI 辅助开发应用程序（如写 Web 后端或前端页面）早已屡见见鲜，但在 Linux 内核驱动开发中，如果直接给 AI 一个 Prompt：“帮我写一个 MT7603U 无线驱动”，得到的结果只会是荒诞的伪代码。硬件开发没有容错空间：一个地址写错、一个位域偏移错误，就会立刻导致 Kernel Panic、Oops，甚至整机死锁重启。
要让 AI 成为真正的系统级协作者，第一步不是急于写代码，而是给 AI 建立高精度的领域认知底座。
在项目启动之初，我们没有将原厂代码直接粗暴塞进上下文，而是分层注入了三份核心知识：
2.1 驱动理论与设计哲学
通过团队沉淀的底层设计笔记，向 AI 对齐 Linux 驱动的核心哲学：
- 机制与策略分离（Mechanism vs Policy）：驱动只负责提供对硬件机制的控制能力（如分配 URB、读写寄存器、下发封包），绝不应该私自实现上层策略；
- 虚拟方法表（vtable）抽象：Linux 内核通过结构体函数指针（如
struct ieee80211_ops、struct usb_driver）实现面向对象式多态； - 统一设备模型与 USB 栈：USB 控制传输（EP0 Vendor Request）与批量传输（Bulk In/Out Endpoint）的异步模型及生命周期。
2.2 姊妹芯片的重构经验借鉴（MT7601U）
MT7601U 是 MT7603U 的上一代单流姊妹芯片，架构极其相似（同属 Andes N9 MCU 架构）。社区著名开发者 Kuba 曾将 MT7601U 的厂商驱动重构成 Linux 主线驱动：
- 梳理了 Andes N9 MCU 的固件散列分片（Scatter Download）下载流程；
- 梳理了 USB 端点布局（EP 0x84 数据环、EP 0x85 命令响应环、EP 0x08 管理/Beacon 直通端点、EP 0x05 WMM 数据端点）；
- 对比了厂商臃肿的私有 RTMP 框架与主线
mac80211的精简对接模式。
2.3 原厂源码作为“硬件事实库”（Grounding Truth）
十万行原厂驱动源码虽然不能直接用，但它是芯片寄存器地址、位域定义、固件命令字节结构、校准参数计算公式的唯一权威事实来源。AI 的核心任务之一，就是像考古学家一样，从混乱的 vendor 代码中“提炼”出精确的规范。
3. 技术框架决断：C 骨架 + no_std Rust 双擎
在架构选型阶段，我们通过架构提案（RFC-0001）做出了两项关键决断：
┌─────────────────────────────────────────────────────────────────┐
│ Linux Kernel (mt7603u.ko) │
│ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ C 骨架驱动层 (Thin Skeleton) │ │
│ │ • USB 设备总线注册 (probe / disconnect) │ │
│ │ • mac80211 核心子系统胶水 (struct ieee80211_ops) │ │
│ │ • URB 分配、锚定 (usb_anchor) 与安全卸载击毙 │ │
│ │ • sk_buff 内存管理与 DMA 零拷贝接收环 │ │
│ └─────────────────────────────┬─────────────────────────────┘ │
│ │ C ABI (no_std FFI 契约) │
│ ┌─────────────────────────────▼─────────────────────────────┐ │
│ │ Rust 纯逻辑核心 (libmt7603u_logic.a) │ │
│ │ • EEPROM / eFuse 1024B 解析与 RSSI 增益校准 │ │
│ │ • 硬件寄存器序列生成器 (MAC/BBP/RF/Channel/TBTT) │ │
│ │ • 802.11 / TMAC_TXD / RMAC_RXD 帧协议编解码器 │ │
│ │ • Andes N9 MCU 命令帧序列化与 Header 打包 │ │
│ │ • WTBL 速率表与硬件 CCMP 密钥槽状态机 │ │
│ └───────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
决断一：全面接入 Linux 原生 mac80211
绝不复用原厂私有协议栈！我们让 MT7603U 注册成为标准的 ieee80211_hw 设备：
- 802.11 状态机、SME 关联管理、WPA2 认证握手、Minstrel 动态速率自适应算法全部交给内核成熟的
mac80211子系统； - 驱动不仅代码体量减少了 80% 以上，而且天然原生支持
iw、nmcli、wpa_supplicant、hostapd及 GNOME 网络桌面控制面板。
决断二：C + 纯 no_std Rust 混合架构
为什么不纯用 C？为什么也不纯用 Rust-for-Linux？
- Linux 现有机制兼容性：当前主流发行版（如我们测试所用的 Ubuntu 7.x 内核）对纯 Rust 驱动模块的基础设施还在快速演进中，直接使用 C 语言编写极薄的驱动骨架（不到 1000 行），处理 USB 探测和
sk_buff内存最为稳妥； - Rust 解决核心痛点：无线驱动中最容易崩溃、溢出的部分在于复杂的字节解包、固件命令打包、寄存器序列变换和多级数据结构索引。我们把这部分纯逻辑全部剥离进 Rust，以
no_std（禁用动态内存分配和标准库）编译为静态库libmt7603u_logic.a，通过极度严格的 C ABI 与 C 骨架链接； - 内核内存零崩溃：利用 Rust 严苛的借用检查器与模式匹配，从根本上杜绝了原厂代码里常见的越界读写、野指针悬挂与未初始化内存。
4. 目标分解与 Spec-First 研发流程
驱动开发的复杂性在于依赖链极长：没有总线枚举就读不到 eFuse；没有 eFuse 就无法初始化射频；固件下载不通就无法拉起 MAC；MAC 队列不通数据帧就发不出……
为了防止 AI 陷入“改东墙补西墙”的混乱试错中，我们确立了一条铁律：Spec-First Gate（规范先于代码，无 Spec 绝不写代码）。
(specs/ 目录)"] B --> C["3. 人工审查与批准
(APPROVE Gate)"] C --> D["4. 编写用户态测试用例
(harness/)"] D --> E["5. 实现 Rust/C 业务代码"] E --> F["6. 自动化自验证
(scripts/check.sh)"]
我们参考 docs/roadmap.md 将整个工程清晰拆解为五大递进阶段：
| 阶段 | 核心任务 | 攻坚点与硬件事实 |
|---|---|---|
| Phase 1: 基础流程 | USB 枚举、eFuse 读取、固件下载 | 19 片 Scatter 固件上传，Andes N9 在 EP 0x84 上的 150μs 极速 ACK 响应，TOP_MISC2 固件就绪轮询 |
| Phase 2: STA 客户端模式 | 信道切换、主动扫描、认证关联、数据通路 | Group3 接收向量 RSSI 校准、802.11 Probe Request 发送、EAPOL 4-Way 握手、DHCP 与 Ping |
| Phase 3: AP 热点模式 | hostapd 支持、Beacon 广播、多客户端管理 | LPON/ARB 硬件 BssSync/TBTT 定时器调度、mac80211 NL80211_CMD_FRAME_TX_STATUS 异步状态回报 |
| Phase 4: Monitor 监听模式 | 混杂模式抓包、Radiotap 空口元数据逆向 | RMAC_RFCR 动态混杂过滤切换、Group3 RXV1_1ST_CYCLE 速率/频点/SGI 解码、Raw 帧注入 |
| Phase 5: 高级物理层特性 | 802.11n 2T2R 300M、HT40 频宽、BlockAck | build_txwi 2 空间流计算（nss = 1 + (mcs >> 3)）、Minstrel-HT 速率控制对接、WTBL2 DW15 A-MPDU 聚合会话 |
在整个推进过程中，所有的行为契约全量沉淀在仓库的 specs/modules/ 中（mcu.spec.md、sta.spec.md、ap.spec.md、rx_tx.spec.md），成为不可动摇的单一事实来源（SSOT）。
5. 破案现场：AI 如何定位那些“离谱”的硬件暗坑？
硬件开发最痛苦的不是实现逻辑，而是**“驱动代码每行看起来都对，但硬件就是没有任何反应”**。
在本次开发中，AI 展现出的最震撼能力，并非写普通代码，而是结合寄存器实测遥测数据、内核 Dump 与原厂源码，跨模块定位深层次硬件 Bug 的破案能力。
案例一：消失的 EAPOL M2 帧——表项跨度与 DMA 调度器之谜
在推进 STA 模式 WPA2 握手时，出现了一个诡异现象：网卡扫描极其正常，也能顺利收到 AP 的 Authentication 和 Association Response，但在 4-Way 握手阶段，wpa_supplicant 明明发出了 M2 帧，AP 却永远收不到，反复重传 M1，最终超时断开。
我们与 AI 联合展开了一场抽丝剥茧式的联合排查：
- 排除密码与抓包污染：确认 PSM 密码完全正确，M1 帧 ANonce 每次稳定解包；
- 确认 M2 帧内存未损坏：在驱动入口 Dump skb 字节，确认 MIC、SNonce 和 Replay Counter 逐字节完全正确；
- 硬件是否收到数据？：开启硬件 TX 状态回报（
tx_status_2_host），发现 LMAC 对该端点根本没有任何完成包！说明数据帧根本没走出网卡！ - 致命破案 1：WTBL1 表项跨度误写（32B vs 20B）
AI 深入比对原厂
wf_wtbl.h，发现原厂WTBL_1_STRUC包含 5 个数据字加 3 个 dummy 字，总长应为 32 字节（0x20）。而此前代码中误定义成了 20 字节（0x14）！ 这一细微偏差导致：写入关联 AP（WCID 1）的地址被错位写进了 WCID 0 的 dummy 区域，而真正的 WCID 1 基址内有效位全为 0！硬件将该数据帧直接判定为非法客户端而静默抛弃。 - 致命破案 2：完全未初始化的 HIF/PSE DMA 调度器
修完表项后，数据帧依然发不出。我们通过寄存器读取指令读取了硬件调度器寄存器（
SCH-DIAG），结果显示：全都是 0！ AI 顺藤摸瓜回查原厂FC_P0=0x02880288 SCH1=0x00000000 SCH2=0x00000000 G0=0x00000000 BMAP0=0x00000000AsicDMASchedulerInit，终于揪出了终极根因：MT7603 内部的硬件调度器极其严苛，当MT_SCH_REG_2（单包最大页数）、MT_GROUP_THD（组门限）和MT_BMAP全为 0 时，芯片内部的 HIF DMA 调度器会判定该队列超出阈值，将 WMM 数据端点（EP 0x05）永久阻塞在芯片入口，从不送进 LMAC 发射机！
当 AI 生成并补齐了包含 40 余个时序寄存器的 build_dma_scheduler_sequence 序列后，再次加载驱动，dmesg 瞬间打出了：
[1198574.022203] mt7603u: TXS[0]: pid=0x42 dw0=0x00009288 => LMAC_TX_OK
紧接着，wpa_supplicant 绿灯全亮：WPA2 握手成功，DHCP 租约获取通过，Ping 网关 0% 丢包！
6. 硬件在环测试流：人机协作的高效实战
硬件开发如果必须每次依赖人工在桌面上拿手机点连接、反复插拔网卡，AI 的研发效率就会大打折扣。为此，我们设计了一套多梯级的闭环测试工程体系：
精彩案例：调度 Milk-V Duo S 完成 AP 模式全自动验证
在测试 AP 模式时，主机拉起了 hostapd，我们需要一个真实的 WiFi 客户端来验证能不能连上、能不能分配 IP、数据包能不能双向转发。
我们利用局域网中一台在线的 Milk-V Duo S（平头哥 SG2000，RISC-V 64 边缘计算板） 作为测试仪：
- 守护看门狗保障安全：Duo S 自身通过 WiFi 连接路由器进行 SSH 通信，切换热点会导致网络断开。AI 设计了一个带有
trap cleanup EXIT INT TERM的后台自治脚本：- 先通过
wpa_cli临时添加测试 APMT7603U-Test-AP； - 切换连接、建立 WPA2 关联；
- 握手成功后配置
192.168.76.2/24； - 执行空中双向 Ping 测试；
- 测试完毕无论成功与否，看门狗自动切回原网络，确保边缘板永不失联。
- 先通过
- 测试结果直接闭环：
--> Ping from Duo S to AP 192.168.76.1: PING 192.168.76.1 (192.168.76.1) from 192.168.76.2: 56 data bytes 64 bytes from 192.168.76.1: seq=0 ttl=64 time=6.669 ms 64 bytes from 192.168.76.1: seq=1 ttl=64 time=2.671 ms 64 bytes from 192.168.76.1: seq=2 ttl=64 time=2.648 ms --- 192.168.76.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss
整个过程无需人工手动掏出手机输密码，几秒内完成从 AP 广播到客户端关联、加解密数据转发的全自动验收。
7. 结语与思考：AI 时代的系统工程范式
从十年前尝试修复 vendor 驱动却被各种 bug 困扰，到今天与 AI 一起在现代 Linux 内核中重构出架构清晰、测试完备的开源驱动，这个过程给了我们几点实在的体会：
- AI 并没有“消灭”底层工程师，而是将工程师提升为“系统架构师与裁判员”：
- 人类工程师决定系统架构（选用 mac80211、C/Rust 边界）、划定安全红线（宿主机网卡保护、看门狗保护）、提供真实测试场景；
- AI 承担了最耗时但极具价值的工作：在数十万行遗留代码中精确定位事实、逆向寄存器逻辑、翻译类型安全的规范与自动化测试套件。
- “规范驱动开发（Spec-First）”是让 AI 保持理性的唯一良方：
- 如果任由 AI 随意改写内核代码，哪怕是经验丰富的工程师也会在连环崩溃中迷失；
- 将事实提炼为 SSOT（
specs/），并让 Harness 测试门禁卡在每一步代码前面，AI 就能爆发出令人惊叹的高可靠交付能力。
所有的 Spec、Rust 核心与 C 驱动已完整开源：github.com/qtopie/mt7603u。希望这段实践能为探索 AI 辅助嵌入式与底层系统开发的同学提供参考。