Files
c630/docs/drafts/linux-arm-msm-report.md
rob thijssen 05e54b0b62
All checks were successful
build image / build (push) Successful in 39m26s
Stop the modem crash loop, and record what it is not
Fedora runs rmtfs with -r, which starts the modem remoteproc at boot. Since
the modem never gets past RF init, every C630 sits in a fatal crash and
recovery cycle every ~3.4 seconds from boot onwards — and is already a dozen
crashes deep by the time anyone logs in, which quietly confuses any manual
experiment. Drop the -r so the modem stays offline until asked for.

Also record today's eliminations, each of which closes an avenue: both
published _nm firmware builds are rejected by the boot ROM, not just the
newest; the PEP tables in this machine's own ACPI show Windows gives the
modem seven clocks, one 752 mV rail vote, cx/mx and IPA bandwidth, and
nothing whatsoever for RF — so the host does not power the RF front end on
either OS, and the one clock mainline lacks changes nothing when forced on;
and kernel bracketing is stuck, because 5.10 will not boot here at all.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011XgGF5wfxLDAybVnNz6eNQ
2026-07-28 13:33:39 +03:00

116 lines
5.1 KiB
Markdown

# Draft: report to linux-arm-msm
Send as **plain text** (no HTML), wrapped at ~72 columns. Suggested
recipients:
```
To: linux-arm-msm@vger.kernel.org
Cc: linux-remoteproc@vger.kernel.org,
ath10k@lists.infradead.org,
Bjorn Andersson <andersson@kernel.org>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Steev Klimaszewski <steev@kali.org>
Subject: sdm850-lenovo-yoga-c630: mpss dies at RF init ("RF stuck in QLINK start state"), blocking WCN3990 WiFi
```
---
Hi,
I am trying to get onboard WiFi working on a Lenovo Yoga C630 13Q50
(81JL, SDM850) with the mainline sdm850-lenovo-yoga-c630.dts. WCN3990
never comes up because the wlfw QMI service never appears, and that
traces to the modem: mpss boots and then dies at RF front-end init,
identically on every firmware and kernel combination I can construct:
qcom-q6v5-mss 4080000.remoteproc: MBA booted without debug policy, loading mpss
remoteproc remoteproc1: remote processor 4080000.remoteproc is now up
qcom-q6v5-mss 4080000.remoteproc: fatal error received:
rflm_diag_error.cc:361:RFLM@rflm_qlnk.cpp:1087 [3,3]
RF stuck in QLINK start state: 0x0 after maximum
remoteproc remoteproc1: crash detected in 4080000.remoteproc: type fatal error
The crash lands ~0.4 s after "is now up" and recovery loops every
~3.4 s. I cannot find this error string reported anywhere public, so
here is what I have eliminated:
- Firmware version. WOA-Project publishes nine driver-package versions
for this machine containing five distinct mba/mpss builds (including
a 2018-vintage pair matching this unit's manufacture date and 2019
UEFI, 9UCN33WW(V2.06)); the aarch64-laptops copies differ again by
checksum. All produce the identical fatal.
- Kernel version, at least recently. Fedora 7.1.5 and Fedora 6.12.15
crash identically, same DTB. (I could not get anything older to
boot here to widen the bracket: a 5.10.261 build with the SDM845
platform, UFS, PHY and ext4 support all enabled dies after the EFI
stub with no console output, with earlycon=efifb and
arm-smmu.disable_bypass=0 both tried. Suggestions welcome.)
- Host-side power. I decoded the PEP tables in this machine's ACPI
for \_SB.AMSS: Windows gives the modem seven clocks (the six in
mainline's mss_pil node plus gcc_mss_axis2_clk), one regulator vote
(SMPS2_C at 752 mV), rail_cx/rail_mx at level 384, and IPA bus
bandwidth. No GPIOs, no footswitches, and no votes on the CXO RFCLK
buffers, so the host does not power the RF front end on Windows
either. Holding gcc_mss_axis2_clk enabled from a test module before
starting the modem changes nothing.
- The _nm ("no modem") firmware, in both published builds. The boot
ROM rejects either _nm MBA with "PBL returned unexpected status
-284557301"; with the full MBA the _nm mpss fails authentication.
- Userspace. rmtfs and tqftpserv running (in-kernel qrtr-ns and
pd-mapper); wlanmdsp.mbn reachable through tqftpserv's firmware
path; the modem's writable TFTP area present. I also reconstructed
the full MCFG tree (mcfg_hw + mcfg_sw, 159 files) from the Windows
INF TFTP mappings and served it; the modem crashes before requesting
any of it.
- Hardware. This unit is an LTE SKU: SIM slot, factory-label IMEI,
and the modem worked under Windows on this exact machine.
- clk/pd gating. Booted with clk_ignore_unused pd_ignore_unused
throughout.
Storage-side observations from rmtfs -v, in the half-second before the
fatal: the modem opens /boot/modem_fs1, _fs2, _fsg and _fsc
successfully, additionally requests two partitions rmtfs does not
know, /boot/modem_fsg_oem_1 and /boot/modem_fsg_oem_2 (the names
appear as strings inside qcdsp2850.mbn; nothing in the Windows driver
cabinets seems to provide them either), allocates its 2 MiB buffer,
reads a superblock's worth, and dies. modemst1/modemst2 hold valid
IMGEFS1/IMGEFS2 filesystems; fsg and fsc on this machine are entirely
blank.
Since QLINK is the SoC<->SDR845 SerDes link, "stuck in start state
0x0" looks like the transceiver never answering at all, which makes me
suspect the RF front end is simply not powered under DT boot -- on
Windows that would be hidden in the PEP tables, and the mainline DTS
carries nothing for it. But I cannot confirm that from the ACPI dump,
so before I go further:
1. Does anyone have onboard WiFi working on a C630 (or any SDM850
WoA machine) with a >= 6.x kernel, and if so with which mpss
firmware? aarch64-laptops ticked WiFi in 2019 on their 5.x branch,
but their issue #51 suggests the modem was crash-looping there
too, so possibly wlfw simply appeared before the first crash.
2. Is there any known host-side requirement (regulator, GPIO, PDC
resource) for the SDR845 on these laptops that the DTS would need
to describe?
3. Are the modem_fsg_oem_1/2 requests, and blank fsg/fsc, known
quantities on WoA machines?
Happy to run experiments, capture coredumps (the MBA boots without
debug policy -- is there a usable path to one on production fuses?),
or test patches; the machine is a development box reachable over a
USB WiFi dongle, so nothing is at risk.
Full notes, including the elimination evidence:
https://github.com/<your-repo-or-git-lair-url>
Thanks,
Rob Thijssen