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

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

@@ -38,12 +38,27 @@ here is what I have eliminated:
   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.
+  checksum. All produce the identical fatal.
 
 - Kernel version, at least recently. Fedora 7.1.5 and Fedora 6.12.15
-  crash identically, same DTB.
+  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

docs/firmware.md

@@ -317,8 +317,19 @@ differences are informative:
 
 The `_nm` ("no modem") variants are the obvious idea — Fedora ships the
 equivalent `modem_nm.mbn` for generic sdm845, and skipping cellular RF is
-exactly what is wanted here. They are not signed for this device and cannot be
-made to load.
+exactly what is wanted here. They cannot be made to load. WOA-Project's nine
+packages contain **two** distinct `_nm` builds (an older one in `200.0.1.0`
+through `200.0.10.0`, a newer one from `200.0.11.0` on), and both are rejected
+by the boot ROM in the same way:
+
+```
+qcom-q6v5-mss 4080000.remoteproc: PBL returned unexpected status -284557301
+remoteproc remoteproc3: can't start rproc 4080000.remoteproc: -22
+```
+
+So this is not a matter of finding the right vintage: the PBL will not accept
+either `_nm` MBA on this hardware, and without the `_nm` MBA the `_nm` mpss
+fails authentication. The avenue is closed.
 
 #### Firmware has been eliminated as the variable
 
@@ -384,6 +395,64 @@ configs for the SDX20 — into `readonly/firmware/image/modem_pr/mcfg/...`.
 Serving all of it changes nothing: the modem crashes before requesting any of
 it.
 
+#### The host provides no RF power, on either operating system
+
+The obvious remaining theory was that Windows powers the SDR845 through some
+rail the device tree does not describe. It does not. The C630's ACPI tables
+carry Qualcomm's PEP power-management data, and decoding every PEP entry for
+`\_SB.AMSS` gives the complete set of host resources Windows gives the modem:
+
+- seven clocks — `gcc_boot_rom_ahb_clk`, `gcc_mss_cfg_ahb_clk`,
+  `gcc_mss_q6_memnoc_axi_clk`, `gcc_mss_snoc_axi_clk`, `gcc_mss_mfab_axis_clk`,
+  `gcc_prng_ahb_clk` and `gcc_mss_axis2_clk`
+- one regulator vote, `SMPS2_C` at 752 mV — the MSS core rail
+- ARC/NPA votes on `rail_cx` and `rail_mx` at level 384
+- IPA bus bandwidth
+
+No GPIOs, no footswitches, and — decisively — **no votes on the CXO RF clock
+buffers** (`RFCLK1/2/3`), even though the PMIC registry defines them and the
+audio tables vote on their own buffers. RF front-end power is managed by the
+modem firmware itself over RPMh/SPMI on both operating systems, so there is no
+missing host-side rail to add to the device tree.
+
+Mainline's `mss_pil` node already carries six of the seven clocks. The seventh,
+`gcc_mss_axis2_clk`, is the only host-side difference, and it is not the cause:
+holding it enabled with an out-of-tree module before starting the modem
+produces the identical QLINK crash.
+
+The modem's own coredump would settle it, but `/sys/class/remoteproc/*/coredump`
+yields a 124 MB image with none of the firmware's strings in it — production
+fuses, encrypted dump. The strings are plainly visible in `qcdsp2850.mbn`
+itself, so the dump is not simply empty.
+
+#### Kernel bracketing has not been possible
+
+The remaining hypothesis is age: something between the 2019 kernel
+aarch64-laptops used and today. Testing it needs an old kernel that boots here,
+and that has not been achieved. A 5.10.261 build (defconfig plus the SDM845
+platform, UFS, PHY and ext4 support, all verified present in `.config`) reaches
+the EFI stub and dies before userspace — no journal, no console output, with
+`earlycon=efifb` and `arm-smmu.disable_bypass=0` both tried. Fedora's 6.12.15
+does boot, and crashes identically to 7.1.5, so the bracket is currently
+6.12 ≤ broken ≤ 7.1 with nothing older testable.
+
+Booting test kernels here is otherwise cheap and safe: add a BLS entry, set
+`next_entry` in the GRUB environment for a one-shot boot, and a power-cycle
+returns to the pinned default. Pin the default by entry id rather than
+`set default=0` — adding an entry can otherwise silently make the *test* kernel
+the default.
+
+#### The modem starts itself, and crashes forever
+
+Fedora runs `rmtfs -r`, and `-r` makes rmtfs start the modem remoteproc at
+boot. Since the modem cannot get past RF init, the machine sits in a fatal
+crash and recovery cycle every ~3.4 seconds from boot until shutdown. It is
+easy to miss — the modem is already at crash #15 or so by the time anyone logs
+in, which also makes manual experiments confusing, and rapid start/stop cycling
+on top of it will wedge the remoteproc until a reboot.
+`overlay/etc/systemd/system/rmtfs.service.d/50-no-remoteproc.conf` drops the
+`-r`, so the modem stays offline until started deliberately.
+
 Things that sound like they should help and do not:
 
 - **Unplugging the USB WiFi dongle.** Different bus, different driver.
@@ -397,11 +466,15 @@ Things that sound like they should help and do not:
   gets far enough to ask for it.
 - **`clk_ignore_unused pd_ignore_unused`.** Already on the command line
   (postmarketOS ships the same for this machine).
+- **`gcc_mss_axis2_clk`.** The one clock Windows enables that mainline does
+  not; holding it on changes nothing. See above.
+- **Both `_nm` firmware builds.** Rejected by the boot ROM. See above.
 
 Untried, in rough order of promise: reporting upstream — the error string
 appears nowhere public, and linux-arm-msm (Bjorn Andersson, Dmitry Baryshkov,
-Steev Klimaszewski all have C630 history) is where the RF-power hypothesis
-could be confirmed or killed; Lenovo's Digital Download Recovery Service image
+Steev Klimaszewski all have C630 history) is now clearly the best next step,
+since every locally testable hypothesis above has been eliminated; Lenovo's
+Digital Download Recovery Service image
 for this serial, which would show the exact original driver set and whatever
 provides `modem_fsg_oem_*` under Windows; building `board-2.bin` from the
 C630's own `bdwlan.*` files (only relevant once the modem stays up); and the