WiFi: ath10k gets board_id 0xff, random MAC, no usable channels #18

New issue

Open

opened 2026-08-25 10:50:18 +00:00 by kit · 0 comments

kit commented

2026-08-25 10:50:18 +00:00

Owner

WiFi now comes up as far as a netdev but has no working RF. Unblocked by the modem work (#16) — ath10k_snoc needs the WLFW QMI service, which only exists once the modem is running.

Current state

With the modem up (started late, per #16), modprobe ath10k_snoc gets all the way to a netdev:

ath10k_snoc 18800000.wifi: qmi chip_id 0x30224 chip_family 0x4001 board_id 0xff soc_id 0x40060000
ath10k_snoc 18800000.wifi: qmi fw_version 0x3204038e fw_build_timestamp 2022-08-08 10:50
        fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.0.c3-00910-QCAHLSWMTPLZ-1.493553.2.512591.6
ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000
ath10k_snoc 18800000.wifi: htt-ver 3.89 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1
ath10k_snoc 18800000.wifi: invalid MAC address; choosing random
ath10k_snoc 18800000.wifi: chan info: invalid frequency 0 (idx 41 out of bounds)

wlan0 exists. iw dev wlan0 scan returns 0 BSS.

Diagnosis

board_id 0xff is the giveaway — the firmware is reporting "board id not set", so ath10k cannot select the right variant out of a board-2.bin container and ends up with defaults. The invalid frequency 0 (idx 41 out of bounds) messages are the downstream consequence: the channel list the firmware hands back is not valid for this board.

The random MAC is the same root cause — the per-device MAC normally comes from board data / the WLFW response.

Not the regulatory database

regulatory.db was missing from the rootfs entirely (cfg80211: failed to load regulatory.db, and wireless-regdb was not installed). Fixed by installing it — and it changed nothing. Same board_id 0xff, same invalid channels, same 0 BSS. Worth recording so nobody re-tries it.

What's needed

gts6l-firmware-links already links the stock bdwlan.bin* blobs into /usr/lib/firmware/ath10k/WCN3990/hw1.0/stock/, with a comment anticipating exactly this: "WiFi board data (raw bdwlan; convert to board-2.bin later if ath10k needs)". That conversion is now the blocker.

Identify which bdwlan.bin* variant is this board's (the stock vendor partition ships several).
Build a board-2.bin container with the right board id so ath10k's lookup succeeds — or, if the firmware genuinely reports 0xff, work out where stock gets its board id from (WLFW response vs a NV item vs the modem).
Recover the real MAC (likely from the same board data or a Samsung NV partition).

Depends on

#16 — WiFi only works while the modem is alive, and today that means starting the modem after ~75 s.
#17 — testing needs a device that boots reliably; keep display off.

WiFi now comes up as far as a netdev but has no working RF. Unblocked by the modem work (#16) — `ath10k_snoc` needs the WLFW QMI service, which only exists once the modem is running. ## Current state With the modem up (started late, per #16), `modprobe ath10k_snoc` gets all the way to a netdev: ``` ath10k_snoc 18800000.wifi: qmi chip_id 0x30224 chip_family 0x4001 board_id 0xff soc_id 0x40060000 ath10k_snoc 18800000.wifi: qmi fw_version 0x3204038e fw_build_timestamp 2022-08-08 10:50 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.0.c3-00910-QCAHLSWMTPLZ-1.493553.2.512591.6 ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000 ath10k_snoc 18800000.wifi: htt-ver 3.89 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1 ath10k_snoc 18800000.wifi: invalid MAC address; choosing random ath10k_snoc 18800000.wifi: chan info: invalid frequency 0 (idx 41 out of bounds) ``` `wlan0` exists. `iw dev wlan0 scan` returns **0 BSS**. ## Diagnosis **`board_id 0xff`** is the giveaway — the firmware is reporting "board id not set", so ath10k cannot select the right variant out of a `board-2.bin` container and ends up with defaults. The `invalid frequency 0 (idx 41 out of bounds)` messages are the downstream consequence: the channel list the firmware hands back is not valid for this board. The random MAC is the same root cause — the per-device MAC normally comes from board data / the WLFW response. ## Not the regulatory database `regulatory.db` was missing from the rootfs entirely (`cfg80211: failed to load regulatory.db`, and `wireless-regdb` was not installed). Fixed by installing it — and it changed nothing. Same `board_id 0xff`, same invalid channels, same 0 BSS. Worth recording so nobody re-tries it. ## What's needed `gts6l-firmware-links` already links the stock `bdwlan.bin*` blobs into `/usr/lib/firmware/ath10k/WCN3990/hw1.0/stock/`, with a comment anticipating exactly this: *"WiFi board data (raw bdwlan; convert to board-2.bin later if ath10k needs)"*. That conversion is now the blocker. 1. Identify which `bdwlan.bin*` variant is this board's (the stock vendor partition ships several). 2. Build a `board-2.bin` container with the right board id so ath10k's lookup succeeds — or, if the firmware genuinely reports 0xff, work out where stock gets its board id from (WLFW response vs a NV item vs the modem). 3. Recover the real MAC (likely from the same board data or a Samsung NV partition). ## Depends on - #16 — WiFi only works while the modem is alive, and today that means starting the modem after ~75 s. - #17 — testing needs a device that boots reliably; keep display off.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

kit/linux-gts6l#18

No description provided.

Rows
Columns