Files
bfe-core1106-sdk/kernel/rv1106-enablement/wifi/VERIFIED-on-c8a3.md
T
BFE EngineeringandClaude Opus 4.8 92905bf4d4 kernel/rv1106: M5 wifi VERIFIED on c8a3 — wlan0 scan works (module build)
On-hardware proof (self-built 6.18.46, _b slot): aic8800 modules load,
download firmware, wlan0 up ([device-mac]), iw scan finds real APs
incl. SSID BlueFlare @ -43dBm. RF path fully functional. See
wifi/VERIFIED-on-c8a3.md.

Two changes from the initial built-in attempt:
- Built-in =y DEADLOCKS: aicbsp_init's eager SDIO bring-up (device_initcall,
  sequential) blocks the dw_mmc controller probe that would enumerate the
  card it waits for (aicsdio.c:597 2s down_timeout -> unregister). Converted
  to modules (=m): AIC_WLAN_SUPPORT bool->tristate; loaded late, after the
  mmc-pwrseq enumerates the card — the vendor-proven flow.
- Restored fdrv's own md5.o (each .ko needs its own MD5; bsp doesn't export
  it). Refreshed kbuild snapshot accordingly.

Kernel-size fix (CONFIG_KERNEL_GZIP -> XZ): the wifi kernel's 12.12MB gzip
zImage overran U-Boot's DTB-at-0xc00000 load boundary (Sysmem Error, FLARE-AB
fell back to _a). XZ -> 8.15MB, ~4MB headroom; also correct for a firmware
kernel. Uncompressed Image ~30MB but the ARM decompressor relocates the FDT
at runtime, so only the U-Boot load-time overlap mattered.

DRIVER-PARITY: wifi  M5; BT 🔨 (module built, HCI not yet exercised).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017wB8KB3MMQztRDXCMCkPrf
2026-08-25 00:34:25 -06:00

45 lines
2.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# AIC8800 wifi — VERIFIED on warden-c8a3 (self-built 6.18.46), 2026-08-25
**Result: wifi works end-to-end on our self-built Linux 6.18.46.** Modules built
from the ported source (vermagic `6.18.46 SMP mod_unload ARMv7 p2v8`), loaded on
the panel, downloaded firmware to the AIC8800DC, created `wlan0`, and completed a
live RF scan.
## Evidence (serial console, _b slot = our 6.18 kernel)
- `insmod aic8800_bsp.ko` → firmware download OK: `aicwf_patch_config_8800dc done`,
`Start app: 00120000`, BSP_RC=0.
- `insmod aic8800_fdrv.ko``ieee80211 phy0: HT supp 1, VHT supp 1, HE supp 1`,
FDRV_RC=0.
- `wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> ... link/ether [device-mac]`
- `iw dev wlan0 scan` found real APs:
- **the site AP [bssid] 2412 MHz 43 dBm**
- a neighboring guest AP [bssid] 2412 MHz 73 dBm
- +several more, correct signal strengths → RF path fully functional.
## Why MODULES, not built-in (=y)
Built-in device_initcalls run BEFORE the dw_mmc/SDIO controller probes. Initcalls
are sequential: `aicbsp_init` blocked 3.37.5 s doing the eager chip bring-up, and
the mmc controller only probed at 7.9 s (SDIO card at 8.2 s) — AFTER aicbsp had
already given up (`aicsdio.c:597` 2 s `down_timeout``sdio_unregister_driver`).
Extending the timeout can't help (aicbsp blocks the very mmc probe that would
enumerate the card — a deadlock). Loaded as modules AFTER boot (mmc up, card at
4 s), `insmod aic8800_bsp` registers the SDIO driver against an already-present
card → probe fires immediately → firmware download → fdrv → wlan0. This is the
vendor-proven flow.
## Kernel-size fix (needed to boot the wifi kernel at all)
The wifi kernel grew the gzip zImage to 12.12 MB; rockchip U-Boot loads the kernel
blob at 0x8000 and relocates the DTB to 0xc00000 (12 MB), so a >~11.95 MB zImage
overruns the FDT at U-Boot load time (`Sysmem Error: KERNEL overlap with FDT`) and
FLARE-AB falls back to _a. Switched `CONFIG_KERNEL_GZIP``CONFIG_KERNEL_XZ`:
zImage 12.12 MB → 8.15 MB (module build), ~4 MB headroom under the FDT. Also the
right call for a firmware kernel. (Uncompressed Image is ~30 MB; the ARM
decompressor relocates the FDT at runtime, so only the U-Boot LOAD-time overlap
mattered — proven by the kernel booting once the zImage fit.)
## Boot-time auto-load (follow-up, deployment layer — not the kernel port)
Modules were insmod'd manually for this verify. Production auto-load needs a
loader that inserts `aic8800_bsp.ko``aic8800_fdrv.ko` (→ `aic8800_btlpm.ko`) in
order from wherever they're staged; the vendor `insmod_wifi.sh` references a
different variant (`aic_load_fw.ko`/`bcmdhd.ko`, absent here). Track in the rootfs.