c630/docs/drafts/linux-arm-msm-report.md

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. The _nm ("no modem") variants are rejected earlier (PBL "unexpected status" / MPSS header authentication failed -3), as expected for the wrong SKU.

• Kernel version, at least recently. Fedora 7.1.5 and Fedora 6.12.15 crash identically, same DTB.

• 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/

Thanks, Rob Thijssen