diff --git a/docs/drafts/linux-arm-msm-report.md b/docs/drafts/linux-arm-msm-report.md index b3a96f9..f879a7a 100644 --- a/docs/drafts/linux-arm-msm-report.md +++ b/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 diff --git a/docs/firmware.md b/docs/firmware.md index f7bf28e..bb7bddf 100644 --- a/docs/firmware.md +++ b/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 diff --git a/overlay/etc/systemd/system/rmtfs.service.d/50-no-remoteproc.conf b/overlay/etc/systemd/system/rmtfs.service.d/50-no-remoteproc.conf new file mode 100644 index 0000000..0d2cff7 --- /dev/null +++ b/overlay/etc/systemd/system/rmtfs.service.d/50-no-remoteproc.conf @@ -0,0 +1,15 @@ +# Fedora runs rmtfs with -r, which makes it start the modem remoteproc at boot. +# On this machine the modem cannot get past RF init (see docs/firmware.md), so +# that means a fatal crash and recovery cycle every ~3.4 seconds, forever: log +# spam, wasted power, and a wedged remoteproc if anything else pokes it. +# +# Drop -r so the modem stays offline until someone asks for it: +# +# echo start | sudo tee /sys/class/remoteproc/remoteprocN/state +# +# (N varies between boots — find it by matching 4080000.remoteproc in +# /sys/class/remoteproc/*/name.) Delete this file to restore the auto-start +# once the modem is fixed. +[Service] +ExecStart= +ExecStart=/usr/bin/rmtfs -P -s