docs: record what firmware fixed, and what it turns out not to fix

The motd was the worst of it — it told anyone logging in that "WiFi and
Bluetooth work with the firmware Fedora ships", which is precisely backwards for
the onboard adapter, and pointed at a Windows partition this machine no longer
has.

What the blobs did fix, verified: the GPU initialises, ADSP/CDSP/SLPI all run,
sensors appear as IIO devices, venus registers /dev/video0-3.

What they did not, and why, so nobody repeats the search:

Onboard WiFi is loaded by the modem — wlan*mdsp* is the WLAN Modem DSP — so
ath10k_snoc binds and then waits silently on a QMI service that never arrives.
The modem boots and dies at "RF stuck in QLINK start state", the RF front-end,
which is board-specific wiring in a way the SoC-level blobs are not. These are
Qualcomm *reference* drivers; good enough for the GPU and DSPs, evidently not
for this machine's radio. Three plausible fixes that do not work are recorded
too: rmtfs (correct to enable, does not help), the _nm firmware variants
(rejected at PBL), and unplugging the USB dongle (different bus entirely — it
was never competing).

Audio gets further than expected. The codec answers over SLIMbus with its chip
id, so hardware and ADSP are fine; what fails is the codec's SoundWire block
declaring two data-in ports where the controller expects six. That is a kernel
mismatch and needs a kernel change.

Also record the mesa caveat properly: the GPU works, but freedreno's EGL path
segfaults gnome-shell into a login loop, and LIBGL_ALWAYS_SOFTWARE does nothing
because mutter uses EGL. MESA_LOADER_DRIVER_OVERRIDE=kms_swrast is what works.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS

docs/firmware.md

@@ -194,6 +194,76 @@ circulated before, and any 81JL's copy is as good as your own.
 Whichever route, drop the result into `firmware/local/` and rebuild — see
 [Baking firmware into the image](#baking-firmware-into-the-image).
 
+## What the firmware does not fix
+
+Installing all of it still leaves two things broken, both for reasons that are
+not about firmware. Recorded here so nobody repeats the search.
+
+### Onboard WiFi needs the modem, and the modem needs firmware nobody publishes
+
+The name gives it away: **wlan*mdsp*** is the WLAN *Modem* DSP. On SDM845 the
+WiFi firmware is loaded by the modem subsystem, so `ath10k_snoc` binds to
+`18800000.wifi` and then sits silent, waiting on a QMI service that only appears
+once the modem is up. It never logs an error, because from its point of view
+nothing has gone wrong yet.
+
+The modem itself boots and then dies:
+
+```
+qcom-q6v5-mss 4080000.remoteproc: MBA booted without debug policy, loading mpss
+qcom-q6v5-mss 4080000.remoteproc: fatal error received:
+    RFLM@rflm_qlnk.cpp:1087 [3,3] RF stuck in QLINK start state: 0x0 after maximum
+remoteproc remoteproc0: crash detected ... recovering
+```
+
+QLINK is the RF front-end interface, and RF front-end wiring is board-specific
+in a way the DSP and GPU images are not. The WOA-Project cabinets are Qualcomm
+*reference* drivers: good enough for the SoC-level blobs, evidently not for this
+machine's radio. It restarts about every 42 seconds until stopped.
+
+Things that sound like they should help and do not:
+
+- **`rmtfs`.** The modem stores its NV and calibration on the `modemst1`,
+  `modemst2`, `fsg` and `fsc` partitions and reaches them through the `rmtfs`
+  daemon. Fedora packages it, and it is disabled by default. Enabling it is
+  correct and worth doing — `sudo systemctl enable --now rmtfs` — but the QLINK
+  failure persists with it running. Its "failed to update start state" warnings
+  are its optional remoteproc-control helper and are harmless.
+- **The `_nm` firmware variants.** `qcdsp1v2850_nm.mbn` and `qcdsp2850_nm.mbn`
+  are the no-modem images, 5.7 MB against 60 MB, analogous to the `modem_nm.mbn`
+  Fedora ships for generic sdm845. They are rejected before they even run:
+  `PBL returned unexpected status`.
+- **Unplugging the USB WiFi dongle.** Different bus, different driver, no
+  interaction. `ath10k_snoc` is waiting on the modem, not competing for a radio.
+
+A USB dongle or USB tethering from a phone is the practical answer.
+
+### Audio is a kernel driver problem
+
+The ADSP runs, the audio services register, and the codec answers:
+
+```
+wcd934x-slim 217:250:1:0: WCD934x chip id major 0x108, minor 0x1
+```
+
+So SLIMbus, the ADSP and the hardware are all fine. What fails is one sub-device
+of the codec:
+
+```
+qcom-soundwire wcd934x-soundwire.12.auto: din-ports (2) mismatch with controller (6)
+platform sound: deferred probe pending: msm-snd-sdm845: SLIM Playback: codec dai not found
+```
+
+The codec's SoundWire block declares two data-in ports where the controller
+expects six, so it never probes, so the sound card has no codec DAI and never
+appears. That is a mismatch inside the kernel, and needs a kernel or
+device-tree change rather than any blob.
+
+One thing worth knowing if you go looking: `slim_qcom_ngd_ctrl` can probe before
+the ADSP is ready and log `QMI wait timeout`. Reloading the module afterwards
+gets the codec detected, which is how the chip ID above was obtained — but it
+does not get past the SoundWire mismatch.
+
 ## Extracting them
 
 The image ships Fedora's `qcom-firmware-extract`. Run it once: