WiFi: WCN3990 WLAN core never registers WLFW (chip alive, BT works) #14

New issue

Closed

opened 2026-08-21 17:14:15 +00:00 by kit · 2 comments

kit commented 2026-08-21 17:14:15 +00:00

Owner

Copy link

BT is now working (see below); WiFi is not. The WCN3990 chip is alive but its WLAN core never boots — ath10k_snoc binds, sets up regulators, and then waits silently forever for a WLFW QMI service that never appears.

Evidence

• ath10k_snoc 18800000.wifi binds. Entire dmesg from it is two lines:

  platform 18800000.wifi: Adding to iommu group 11
  ath10k_snoc: supply vdd-3.3-ch1 not found, using dummy regulator
  

  No firmware load, no QMI, no error, no timeout. It's event-driven, waiting for the WLFW server.
• qrtr-lookup: no WLFW service (0x27) — only the adsp/cdsp/slpi nodes. So the WLAN core isn't on the qrtr bus → its ROM isn't booting.
• No wlan0.

What's ruled out

• Power: the chip is alive — BT reads its version and completes setup. Critically, BT's supplies (vddio/vddxo/vddrf/vddch0 = l1a/l7a/l2c/l11c) are the same four rails as WiFi's cx-mx/xo/rfa/ch0, so BT working proves the WiFi rails are powered. The missing vdd-3.3-ch1 (dummy) is not it — mtp and nabu run without it too.
• DT node: our &wifi is byte-identical to sm8150-xiaomi-nabu (working) — same 4 supplies.
• Memory: our relocated wlan_mem (@0x8c200000, 0x180000) is the default size, no overlap with neighbours.
• RF clock: rf_clk2 confirmed enabled at 38.4 MHz, consumer 18800000.wifi.
• Firmware present: /lib/firmware/ath10k/WCN3990/hw1.0/{board-2.bin,firmware-5.bin} (real files, rootfs, available early). But WLFW comes from the chip ROM, not these, so they're not why it's silent.

So: WLAN-core-specific bring-up

Everything shared with BT works; only the WLAN subsystem fails to come up. Suspects: an SCM/MSA memory-assign step failing silently, a WLAN-specific reset/enable, or the qrtr transport to the WLAN core not being established.

Next steps

1. Build a kernel with CONFIG_DYNAMIC_DEBUG=y (not in the current build) and enable file *ath10k_qmi* +p / file *ath10k_snoc* +p to see exactly where the QMI wait stalls — this is the key missing visibility.
2. Verify the WiFi rail voltages directly with spmird (the display-rail method) rather than trusting the regulator votes.
3. Compare the WCN3990 power-up path vs a known-working ath10k_snoc device boot log.
4. Check for a silent SCM memory-assign failure (MSA permission).

The chip is healthy and BT proves the power domain — this is a focused ath10k_snoc/QMI bring-up, not a power or DT-structure problem.

BT is now working (see below); WiFi is not. The WCN3990 chip is alive but its WLAN core never boots — `ath10k_snoc` binds, sets up regulators, and then waits silently forever for a WLFW QMI service that never appears. ## Evidence - `ath10k_snoc 18800000.wifi` binds. **Entire** dmesg from it is two lines: ``` platform 18800000.wifi: Adding to iommu group 11 ath10k_snoc: supply vdd-3.3-ch1 not found, using dummy regulator ``` No firmware load, no QMI, no error, no timeout. It's event-driven, waiting for the WLFW server. - `qrtr-lookup`: **no WLFW service (0x27)** — only the adsp/cdsp/slpi nodes. So the WLAN core isn't on the qrtr bus → its ROM isn't booting. - No `wlan0`. ## What's ruled out - **Power:** the chip is alive — BT reads its version and completes setup. Critically, BT's supplies (`vddio/vddxo/vddrf/vddch0` = l1a/l7a/l2c/l11c) are the **same four rails** as WiFi's `cx-mx/xo/rfa/ch0`, so BT working **proves the WiFi rails are powered**. The missing `vdd-3.3-ch1` (dummy) is not it — mtp and nabu run without it too. - **DT node:** our `&wifi` is byte-identical to sm8150-xiaomi-nabu (working) — same 4 supplies. - **Memory:** our relocated `wlan_mem` (@0x8c200000, 0x180000) is the default size, no overlap with neighbours. - **RF clock:** `rf_clk2` confirmed enabled at 38.4 MHz, consumer `18800000.wifi`. - **Firmware present:** `/lib/firmware/ath10k/WCN3990/hw1.0/{board-2.bin,firmware-5.bin}` (real files, rootfs, available early). But WLFW comes from the chip ROM, not these, so they're not why it's silent. ## So: WLAN-core-specific bring-up Everything shared with BT works; only the WLAN subsystem fails to come up. Suspects: an SCM/MSA memory-assign step failing silently, a WLAN-specific reset/enable, or the qrtr transport to the WLAN core not being established. ## Next steps 1. **Build a kernel with `CONFIG_DYNAMIC_DEBUG=y`** (not in the current build) and enable `file *ath10k_qmi* +p` / `file *ath10k_snoc* +p` to see exactly where the QMI wait stalls — this is the key missing visibility. 2. Verify the WiFi rail *voltages* directly with `spmird` (the display-rail method) rather than trusting the regulator votes. 3. Compare the WCN3990 power-up path vs a known-working ath10k_snoc device boot log. 4. Check for a silent SCM memory-assign failure (MSA permission). The chip is healthy and BT proves the power domain — this is a focused ath10k_snoc/QMI bring-up, not a power or DT-structure problem.

kit commented 2026-08-22 06:39:58 +00:00

Author

Owner

Copy link

2026-08-22: WLAN firmware now boots and takes its BDF. Full chain identified.

Went from "ath10k silent forever" to "WLAN firmware running, BDF downloaded". Correction to an earlier claim in this issue: WiFi IS gated on the modem. The original assessment was right; my later "not gated on the modem" note was wrong. Proof: sm8150-xiaomi-nabu is a WiFi-only tablet with no cellular and it still enables &remoteproc_mpss — purely for WiFi. On WCN3990 the WLAN firmware runs on the modem DSP (hence wlanmdsp.mbn) and provides the WLFW QMI service.

The chain (all five links were missing)

1. Modem remoteproc — &remoteproc_mpss { status = "okay"; firmware-name = "qcom/sm8150/samsung/gts6l/modem.mdt"; }. Firmware = modem.mdt + 30 modem.bXX, copied out of the modem partition (/dev/disk/by-partlabel/modem → image/).
2. rmtfs_mem DT region — our bug. It was deleted with the MTP-layout carveouts and never restored, so the modem had no EFS/NV access: it booted, then died fatal error without message, crash-looping. Re-added at 0x9e400000 (2 MiB, free space above cont_splash_mem), qcom,client-id = <1>, qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>. Creates /dev/qcom_rmtfs_mem1; verified in use: [RMTFS] alloc 0, 2097152 => 0x9e400000.
3. rmtfs + pd-mapper + tqftpserv — none packaged for Arch ARM. Built from linux-msm sources on-device (plus libqrtr from linux-msm/qrtr via meson).
4. modem_pr/mcfg — the modem fetches /readonly/firmware/image/modem_pr/mcfg/... over tqftpserv, which maps to /lib/firmware/. Copied (not symlinked — /firmware mounts at t≈16 s, far too late) /mnt/modem/image/modem_pr → /lib/firmware/modem_pr.
5. Board data (BDF) — ath10k found upstream board-2.bin, matched its generic qmi-board-id=ff entry (our chip reports board_id 0xff, i.e. unprovisioned) and the firmware crash-looped. Samsung's own BDF is /firmware/vendor/firmware/wlan/qca_cld/bdwlan.bin (26328 B) → installed as /lib/firmware/ath10k/WCN3990/hw1.0/board.bin, and upstream board-2.bin moved aside so the fallback is taken.

Current state

qmi chip_id 0x30224 chip_family 0x4001 board_id 0xff soc_id 0x40060000
qmi fw_version 0x3204038e ... WLAN.HL.3.2.0.c3-00910-QCAHLSWMTPLZ-...
boot fw request 'ath10k/WCN3990/hw1.0/board.bin': 0
using board api 1
qmi bdf download request completed
...
could not probe fw (-110)   <- new failure point
soc power off

So: modem stable (0 crashes), WLFW up, MSA regions negotiated, BDF accepted. It now times out waiting for firmware-ready.

Next fix — confirmed under-volt on the WiFi RF rail

Samsung's downstream specifies qcom,vdd-3.3-ch0-config = <3104000 3312000>, but our vreg_l11c_3p3 is regulator-min-microvolt = <3000000> and measured live at 3000000 µV — below the required minimum. Our other three rails match downstream exactly (cx-mx 752000, xo 1800000, rfa 1304000). Raise vreg_l11c_3p3 min to 3104000. This is the prime suspect for the -110.

Also try, if that isn't enough: the other BDF variants (bdwlan.bin1, bdwlan.bin2 — board revisions), and setting qcom,ath10k-calibration-variant (log says DT bdf variant name not set.).

Gotchas for whoever continues

• Test only from a clean boot. The MSA assign is one-shot per boot; after a failed attempt an ath10k unbind/bind gives failed to assign msa map permissions: -22.
• Do NOT enable rmtfs/pd-mapper/tqftpserv/gts6l-modem as boot services yet — doing so wedged the device (USB enumerated, carrier=1, but NETDEV WATCHDOG: transmit queue timed out; no ssh, no ACM). Recovery needed a power cycle, and TWRP could not repair the rootfs (its e2fsck rejects our fs: unsupported feature(s): FEATURE_C12 FEATURE_R16 = orphan_file). Recovered instead by booting with systemd.mask= on the four units via kernel cmdline, then deleting the symlinks from multi-user.target.wants/. Start them manually until the boot-time hang is understood.
• The vdd-3.3-ch1 not found, using dummy regulator warning is a red herring — Samsung's downstream uses the same four supplies and no ch1.

Kernel commits so far: 91cee1ce (TDM framing, audio), modem + rmtfs_mem DT changes still uncommitted locally.

## 2026-08-22: WLAN firmware now boots and takes its BDF. Full chain identified. Went from "ath10k silent forever" to "WLAN firmware running, BDF downloaded". **Correction to an earlier claim in this issue: WiFi IS gated on the modem.** The original assessment was right; my later "not gated on the modem" note was wrong. Proof: `sm8150-xiaomi-nabu` is a WiFi-only tablet with no cellular and it still enables `&remoteproc_mpss` — purely for WiFi. On WCN3990 the WLAN firmware runs on the modem DSP (hence `wlanmdsp.mbn`) and provides the WLFW QMI service. ### The chain (all five links were missing) 1. **Modem remoteproc** — `&remoteproc_mpss { status = "okay"; firmware-name = "qcom/sm8150/samsung/gts6l/modem.mdt"; }`. Firmware = `modem.mdt` + 30 `modem.bXX`, copied out of the `modem` partition (`/dev/disk/by-partlabel/modem` → `image/`). 2. **`rmtfs_mem` DT region — our bug.** It was deleted with the MTP-layout carveouts and never restored, so the modem had no EFS/NV access: it booted, then died `fatal error without message`, crash-looping. Re-added at `0x9e400000` (2 MiB, free space above `cont_splash_mem`), `qcom,client-id = <1>`, `qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>`. Creates `/dev/qcom_rmtfs_mem1`; **verified in use**: `[RMTFS] alloc 0, 2097152 => 0x9e400000`. 3. **rmtfs + pd-mapper + tqftpserv** — none packaged for Arch ARM. Built from `linux-msm` sources on-device (plus `libqrtr` from `linux-msm/qrtr` via meson). 4. **`modem_pr/mcfg`** — the modem fetches `/readonly/firmware/image/modem_pr/mcfg/...` over tqftpserv, which maps to `/lib/firmware/`. **Copied** (not symlinked — `/firmware` mounts at t≈16 s, far too late) `/mnt/modem/image/modem_pr` → `/lib/firmware/modem_pr`. 5. **Board data (BDF)** — ath10k found upstream `board-2.bin`, matched its generic `qmi-board-id=ff` entry (our chip reports `board_id 0xff`, i.e. unprovisioned) and the firmware crash-looped. Samsung's own BDF is `/firmware/vendor/firmware/wlan/qca_cld/bdwlan.bin` (26328 B) → installed as `/lib/firmware/ath10k/WCN3990/hw1.0/board.bin`, and upstream `board-2.bin` moved aside so the fallback is taken. ### Current state ``` qmi chip_id 0x30224 chip_family 0x4001 board_id 0xff soc_id 0x40060000 qmi fw_version 0x3204038e ... WLAN.HL.3.2.0.c3-00910-QCAHLSWMTPLZ-... boot fw request 'ath10k/WCN3990/hw1.0/board.bin': 0 using board api 1 qmi bdf download request completed ... could not probe fw (-110) <- new failure point soc power off ``` So: modem stable (0 crashes), WLFW up, MSA regions negotiated, BDF accepted. It now times out waiting for firmware-ready. ### Next fix — confirmed under-volt on the WiFi RF rail Samsung's downstream specifies `qcom,vdd-3.3-ch0-config = <3104000 3312000>`, but our `vreg_l11c_3p3` is `regulator-min-microvolt = <3000000>` and **measured live at 3000000 µV** — below the required minimum. Our other three rails match downstream exactly (cx-mx 752000, xo 1800000, rfa 1304000). Raise `vreg_l11c_3p3` min to `3104000`. This is the prime suspect for the `-110`. Also try, if that isn't enough: the other BDF variants (`bdwlan.bin1`, `bdwlan.bin2` — board revisions), and setting `qcom,ath10k-calibration-variant` (log says `DT bdf variant name not set.`). ### Gotchas for whoever continues - **Test only from a clean boot.** The MSA assign is one-shot per boot; after a failed attempt an ath10k unbind/bind gives `failed to assign msa map permissions: -22`. - **Do NOT enable rmtfs/pd-mapper/tqftpserv/gts6l-modem as boot services yet** — doing so wedged the device (USB enumerated, `carrier=1`, but `NETDEV WATCHDOG: transmit queue timed out`; no ssh, no ACM). Recovery needed a power cycle, and TWRP could not repair the rootfs (its `e2fsck` rejects our fs: `unsupported feature(s): FEATURE_C12 FEATURE_R16` = `orphan_file`). Recovered instead by booting with `systemd.mask=` on the four units via kernel cmdline, then deleting the symlinks from `multi-user.target.wants/`. Start them manually until the boot-time hang is understood. - The `vdd-3.3-ch1 not found, using dummy regulator` warning is a **red herring** — Samsung's downstream uses the same four supplies and no ch1. Kernel commits so far: `91cee1ce` (TDM framing, audio), modem + rmtfs_mem DT changes still uncommitted locally.

kit commented 2026-08-22 19:33:58 +00:00

Author

Owner

Copy link

Resolved — WiFi works

$ nmcli -t -f SSID,SIGNAL,SECURITY device wifi list
KitKat:100:WPA2
lagtastic:89:WPA2
Vorpal Blade:82:WPA2
Bandersnatch:80:WPA2
lagtastic5g:75:WPA2
Tulgey Wood:45:WPA2
...
16 networks

WLFW now registers, ath10k_snoc loads firmware, and the station scans and associates.

What it took

The WLAN core needs the modem up with rmtfs/pd-mapper/tqftpserv already running, and the unit ordering that guarantees this was not enabled:

gts6l-modem   enabled=disabled   <-- the unit that Requires= all three daemons
pd-mapper     enabled=disabled   <-- has an empty WantedBy=, so it ONLY starts via gts6l-modem

With gts6l-modem disabled, pd-mapper never ran at all, and the DT's remoteproc_mpss auto-booted the modem long before any daemon existed. Enabling gts6l-modem fixes the whole chain — journal now shows pd-mapper, rmtfs and tqftpserv all starting before it:

19:04:28.427  Started Qualcomm protection domain mapper.
19:04:28.435  Started Qualcomm remote filesystem service (modem EFS/NV access).
19:04:28.460  Started Qualcomm TFTP server for the modem (serves mcfg from /lib/firmware).
19:04:28.466  Starting Boot the modem remoteproc (required for WiFi)...

Two red herrings, recorded so they are not chased again

• board_id 0xff looks alarming but is present on every boot in the log, including boots where WiFi worked and associated. It is normal for this WCN3990 and is not a fault.
• chan info: invalid frequency 0 (idx 41 out of bounds) appears on only 3 of 37 boots, so it is intermittent noise rather than the blocker it appeared to be.

Also worth knowing: iw is not installed on the rootfs. iw dev wlan0 scan | grep -c ^BSS therefore returns 0 and looks exactly like "scan found nothing". Use nmcli device wifi list. This cost real debugging time.

Follow-up

WiFi's availability is gated on modem stability — see #16, where the modem asserts on ~half of boots and the SSR recovery takes the AP down. WiFi itself is working; keeping it up depends on that.

Closing.

## Resolved — WiFi works ``` $ nmcli -t -f SSID,SIGNAL,SECURITY device wifi list KitKat:100:WPA2 lagtastic:89:WPA2 Vorpal Blade:82:WPA2 Bandersnatch:80:WPA2 lagtastic5g:75:WPA2 Tulgey Wood:45:WPA2 ... 16 networks ``` WLFW now registers, `ath10k_snoc` loads firmware, and the station scans and associates. ## What it took The WLAN core needs the modem up **with rmtfs/pd-mapper/tqftpserv already running**, and the unit ordering that guarantees this was not enabled: ``` gts6l-modem enabled=disabled <-- the unit that Requires= all three daemons pd-mapper enabled=disabled <-- has an empty WantedBy=, so it ONLY starts via gts6l-modem ``` With `gts6l-modem` disabled, `pd-mapper` never ran at all, and the DT's `remoteproc_mpss` auto-booted the modem long before any daemon existed. Enabling `gts6l-modem` fixes the whole chain — journal now shows pd-mapper, rmtfs and tqftpserv all starting before it: ``` 19:04:28.427 Started Qualcomm protection domain mapper. 19:04:28.435 Started Qualcomm remote filesystem service (modem EFS/NV access). 19:04:28.460 Started Qualcomm TFTP server for the modem (serves mcfg from /lib/firmware). 19:04:28.466 Starting Boot the modem remoteproc (required for WiFi)... ``` ## Two red herrings, recorded so they are not chased again - **`board_id 0xff`** looks alarming but is present on **every** boot in the log, including boots where WiFi worked and associated. It is normal for this WCN3990 and is not a fault. - **`chan info: invalid frequency 0 (idx 41 out of bounds)`** appears on only 3 of 37 boots, so it is intermittent noise rather than the blocker it appeared to be. Also worth knowing: **`iw` is not installed on the rootfs.** `iw dev wlan0 scan | grep -c ^BSS` therefore returns 0 and looks exactly like "scan found nothing". Use `nmcli device wifi list`. This cost real debugging time. ## Follow-up WiFi's availability is gated on modem stability — see #16, where the modem asserts on ~half of boots and the SSR recovery takes the AP down. WiFi itself is working; keeping it up depends on that. Closing.

kit closed this issue 2026-08-22 19:34:04 +00:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

gts6l/6.17

No results found.

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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#14

No description provided.