实习周报（2026-09-05）

与周睿老师交流，WiFi 驱动重构很全面，驱动层面应该没什么可以做的工作了 🫡

本周主要工作是做 d80 版本 WiFi 芯片的驱动修复

本周工作：对主线 WiFi 驱动重构后的 d80 板端适配

本周主线 WiFi 驱动重构已收尾，但主线只在 aic8800dc WiFi 芯片上跑通过验证（#2222），在量产版荔枝派的 aic8800d80 上仍有多处连续错误，逐一修复后恢复到 STA 模式可用的程度；AP 模式暂时仍不可用。

#2276

修复的问题：

1. 开机启动序列失败：两处开机报错，一处等待固件回复超时；
2. AP 模式不可用：命令全部成功返回，但 PC 搜不到热点；
3. WiFi 在大吞吐下罢工：WPA2 连接成功、一般的收发正常（ping 等），但运行 iperf3 数秒内网络彻底卡死，重启才能恢复。

剩余问题：

1. AP 模式下，PC 加入板子的热点无响应："无法加入此网络"；
2. 接收聚合帧（AMSDU）的解析丢帧。

实际改动

1. 启动序列（V3 路径）

• 启动序列会写寄存器把芯片从浅睡眠中唤醒；芯片刚被唤醒时，这条写命令的即时回读字节是写之前的旧值，但代码要求回读必须等于写入值，于是开机直接报错。修复：不再比较回读的值，WiFi 芯片是否好用仍交给之后的轮询负责，其余写入的值校验保持不变。

• 设备中断使能太晚：启动早期固件还运行在芯片内只读代码的阶段，此时固件经设备中断向主机发送回复；代码到启动最后一步才打开设备中断，主机一直等不到回复而超时。修复：把打开设备中断提前到该阶段之前，与厂商驱动的时序一致（这条写入的回读同样是写前旧值，校验方式同唤醒写入）。

涉及提交：ebd0ca2aa、83d794e32、42c8d340f

2. AP 模式：网卡编号硬编码错误，网卡没启动

固件为新建的 AP 网卡分配编号，编号被写成 0，但启动序列已先创建了一张 STA 网卡并占用了编号 0。于是 beacon 上传与 AP 启动命令都发给了错误的网卡，PC 搜不到热点。修复：解析确认回复，状态非零立即报错；把固件分配的真实编号写入后续的 beacon 上传与 AP 启动命令；AP 启动确认的状态同样检查。

涉及提交：4f12a9007

3. 恢复 D80 补丁配置

这是在对照了旧版 WiFi 驱动后所发现的固件上传步骤的不同，不清楚是否实际影响 d80 WiFi 行为，先补上：旧驱动在上传主固件后还会写入三条芯片配置（2.4G 单频、接收聚合开关、功耗校准标志），重构后 D80 路径上没有这个步骤，故按旧驱动逐条恢复，插在上传固件完成与启动应用之间，读写复用与启动期内存读取相同的固件邮箱机制。

涉及提交：f2550689b

4. 负载后数据面停摆（两层根因 + 两项语义对齐）

• 第一层：设备中断的重新打开条件。 固件有数据要交给主机时通过设备中断通知，主机处理完后要重新打开并检查设备中断。代码只在"正在等待中断"的状态才做这件事；而发送缓冲被占满后，主机进入"反复读取发送缓冲状态"的重试循环——这个循环不算等待中断状态，于是主机永远不再检查设备中断：固件有数据发不出、主机收不到中断、发送缓冲也永远不会释放，双向卡死。厂商驱动中断处理与发送路径互不关联，不存在这个窗口。修复：只要设备已就绪且总线上没有正在进行的操作，每次循环结束都重新打开并检查设备中断（这项检查重复执行是安全的），同时删除了原有的等待状态追踪。

• 第二层：发送缓冲状态读数的解释。 发送前主机会读取一个寄存器，了解固件侧还剩多少空闲发送缓冲。读数为 128（0x80）表示固件侧已完全空闲、有 128 个空闲缓冲；代码按 7 位截取读数（丢掉最高位），把 0x80 读成了 0，当作"没有任何空闲缓冲"，从此永久卡住发送。厂商只对 8801/DC/DW 芯片做截取，D80 直接读原始字节。修复：按芯片区分读取方式（D80 读原始字节、其它芯片保持截取）；同时把发送判断从"缓冲数必须大于帧长"修正为"有缓冲就可以发"（厂商语义：有 1 个缓冲即可发送 512 字节的帧），修正了一处边界条件。

涉及提交：79951d9b8、9439e4bea、c7a9cab61

验证

• 静态检查：cargo xtask clippy --package aic8800 通过
• 板卡验证（D80 板，板测用镜像级一次性种子测试）：
  • 开机有 STA 模式的 wlan0，WPA2 正常；
  • AP 模式：beacon 正常，PC 可搜索到热点，但是加入不了；
  • iperf3 吞吐正常：下载 31.2 Mbit/s（10 秒连续，3 次重传）、上传 17.4 Mbit/s（0 重传）、上传下载双向同时正常；多次 iperf3 正常退出。