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
5.1 KiB
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:
-
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.
-
Is there any known host-side requirement (regulator, GPIO, PDC resource) for the SDR845 on these laptops that the DTS would need to describe?
-
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/
Thanks, Rob Thijssen