SouveraineOS/saf/device/modem.md

PAF · Modem bring-up

ARCH STATUS (2026-07-10): WORKING — verified live on the Arch install.

mmcli: state connected, LTE, operator Fido, packet service attached, signal 73%. The whole solved stack made the jump to Arch: modemsmem is in our kernel tree (0c2eb6bf3 "soc: qcom: add modemsmem, wire up on blueline"), rmtfs/tqftpserv/pd-mapper/ModemManager run as services, and blueline-clat.service handles 464XLAT. Everything below is the research record of HOW the 52 wall fell (pmOS era, 2026-06/07) — the mechanism is identical on Arch; read it before touching anything modem-adjacent. Deep evidence docs referenced below live in evidence/.

RESOLVED 2026-07-03 — modem ONLINE, registered, passing LTE traffic. Root cause of the 52 wall: missing modemsmem driver (SMEM item 134).

Google Pixel modem firmware reads SoC info from SMEM_ID_VENDOR0 (item 134) during boot; downstream writes it via drivers/soc/qcom/modemsmem/. Mainline never had the driver, so the MPSS RF task found nothing there and parked op-mode OFFLINE → every RF transition illegal → QMI 52. Fix: Richard Acayan's sdm670 mainline port of the driver (commit d9afe44b) + google,modemsmem/qcom,smem = <134> DT node — canonical tree 4ef9b6943, pmaports 9d52b47813 (CONFIG_QCOM_MODEMSMEM=y). Verified live: op-mode online, Fido LTE registration home, IPv6 bearer passing packets. Full details in HANDOFF.md (2026-07-03). Everything below this line is the (closed) investigation record; the leads/ledger remain correct as history. Remaining open threads are identity (SFS/test-IMEI) and polish (IPv4 bearer, calls/SMS), not RF.

TOP LEAD 2026-07-02 #15 — DIAG_DATA glink channel: AP CAN request it, modem acks but never completes its own open. Real firmware-behavior finding, not a kernel gap.

Correction to this doc's own earlier framing tonight: an initial pass concluded mainline's glink core lacked any AP-initiated ("locally initiated") channel-open primitive at all, and that reaching DIAG_DATA would need core qcom_glink infrastructure work. That was wrong — re-read drivers/rpmsg/qcom_glink_native.c properly: qcom_glink_create_local() (a complete, working implementation of exactly this, sends GLINK_CMD_OPEN, waits for both acks) already exists and is already wired into the standard .create_ept op every transport uses. The real, and much smaller, entry-point gap was just: no driver was calling rpmsg_create_ept() against a fresh channel name from an already-bound rpdev. Fixed with zero new kernel code — userspace's existing RPMSG_CREATE_EPT_IOCTL on /dev/rpmsg_ctrl2 (the modem-edge control device; rpmsg_ctrl0/1 are CDSP/ADSP respectively, confirmed via /sys/devices/.../4080000.remoteproc/.../rpmsg_ctrl2) reaches this exact path already. Built a 60-line test binary (diag_open_test.c, cross-compiled via pmbootstrap chroot) to drive it.

Live result, confirmed clean and repeatable across multiple fresh single-attempt modem boots:

• GLINK_CMD_OPEN sent for DIAG_DATA → modem.
• Modem sends GLINK_CMD_OPEN_ACK back, consistently in <10ms when it responds at all.
• The modem never sends its own reciprocal GLINK_CMD_OPEN back — the other half of glink's bidirectional handshake qcom_glink_create_local() requires (wait_for_completion_timeout(&channel ->open_req, ...)) before a channel counts as usable.
• Tested whether this was just slow: bumped the wait from 5s→60s (kernel commit 7441ca3dc), rebuilt, reflashed, ran ONE clean attempt on a fresh modem boot, waited the full 63.84s. Still nothing. Falsified the "just needs more time" theory outright. Reverted the bump (b4185e71b) — no reason to ship a 60s stall for a case that structurally doesn't complete.
• Cross-checked against downstream (references/los-kernel-blueline-4.9/drivers/soc/qcom/glink.c): its GLINK_CONNECTED notification requires the exact same bidirectional ch_is_fully_opened(ctx) condition (checked from both the incoming-open and the open-ack RX handlers) — downstream isn't looser about what counts as "open," it's just event-driven with no hard timeout instead of blocking-with-timeout. So this isn't mainline enforcing an extra requirement Android doesn't have; it's the same requirement, and the modem doesn't satisfy it either way under mainline's bring-up.

What this means: the modem's DIAG service is reachable and responsive at the glink-negotiation level (it correctly acks a request for a channel it recognizes by name) but will not commit to opening it — a "deliberate partial refusal" shape that rhymes with the entire rest of this frontier (SIM/QMI all healthy, DMS answers reads, refuses RF-arming writes; modem parks offline not LPM). Whatever state gate blocks RF-arm plausibly also gates DIAG. F3 access via this channel is not reachable by any change on the AP side alone — this is now a real, evidenced, narrow finding, not an assumption. Retest if/when the LPM-vs-offline or any other frontier item moves; a modem that reaches a healthier init state might complete this handshake as a side effect.

Test binary + method preserved: diag_open_test.c (cross-built via pmbootstrap chroot -b aarch64), RPMSG_CREATE_EPT_IOCTL against /dev/rpmsg_ctrl2, then open() the resulting /dev/rpmsgN — same approach works for probing ANY named glink channel on ANY edge (swap /dev/rpmsg_ctrl0/1/2 for cdsp/adsp/modem) if a similar question comes up for a different service.

---

TOP LEAD 2026-07-02 #14 — frontier #8's 3-precondition test finally run: provisioning-churn fixed & shipped, LPM-vs-offline confirmed unreachable from AP side

Fixed and shipped precondition (b) from frontier #8 below: blueline-uim-select.sh was unconditionally deactivating+reactivating the primary-gw provisioning session even when it already matched the slot/AID it was about to select — churn on an already-correct session, and exactly the class of write the raw-QMI RESULTS.md proved times out during the modem's not-ready window. Patched to skip the deactivate/reactivate when the existing binding already matches (device-google-blueline-modem-tools 7-r18→7-r21, committed 1ed2df1788). Verified live: the log now reads "primary-gw session already bound to slot 1 app 1 ... skipping stock deactivate/reactivate" — the session is genuinely left alone across a modem restart for the first time this whole investigation.

Result: does NOT flip DMS online. Immediately after the clean-session restart, --dms-set-operating-mode=online still returns DeviceNotReady (52). Polled operating-mode every 3s for 18s post-restart: steady offline the entire window, never once observed LPM. So precondition (c) — "modem in LPM (not offline) for the online flip" — is now confirmed, not just suspected, to never occur spontaneously on pmOS: the firmware decides offline vs LPM before any AP-side QMI write is even possible, so no host script/wrapper/choreography (this fix included) can create the window frontier #8 needed.

Where this leaves it: frontier #8's 3-precondition experiment (configs active + clean provisioning + LPM-not-offline) is no longer "untested" — it's tested, with (a) and (b) now cheaply satisfiable and (b) fixed for real, and (c) confirmed firmware-internal and unreachable from any AP-side lever. This converges with TOP LEAD #13's conclusion (SLPI/ADSP/fastrpc/choreography all closed, F3 narration is the remaining instrument) via a different path — both land on "the offline-vs-LPM decision happens inside the firmware before Linux gets a vote." Next: same F3 instrument #13 named, now aimed at a sharper question — not generic RF-init narration, but specifically why the firmware selects offline over LPM at its own boot, since that's now the single remaining precondition standing between here and an online modem.

Also confirmed same session: mainline blueline has no DIAG transport at all (/dev/diag absent, no diagchar-equivalent config, no DIAG glink channel among the live rpmsg devices) — so diag_capture.md's Side B is a real, confirmed dead end on the AP side as of kernel 7.1.1_p20260702080259-r2; F3 access (if pursued) needs either a from-scratch DIAG-over-glink kernel path or stays Android-side-only (Side A) for comparison purposes.

---

TOP LEAD 2026-07-01 #13 — fastrpc pageslen kernel bug FIXED & shipped; 52 wall now proven independent of adsprpcd/ADSP health too

Real, named, diff-attached kernel defect — the first of the whole investigation — found, fixed, shipped, verified. fastrpc_init_create_static_process() in drivers/misc/fastrpc.c advertised inbuf.pageslen = 0 while actually passing one remote_heap page in args[2]; the sibling dynamic fastrpc_init_create_process() correctly sets pageslen = 1 for the identical one-page layout. The DSP trusts the metadata field, believes zero pages were passed, and aborts INIT_CREATE_STATIC — surfacing in userspace as Broken pipe and the adsprpcd coredump cascade (dsp information is incorrect err: -1 for ADSP+CDSP). One-line fix (0→1); matches FisiFla/nabu-cachyos 0005-fastrpc-fix-init-create-static-pageslen.patch (SM8250, independently shipped for the identical signature, commit claims it also killed an SLPI crash loop there). Committed e3c47d44e in references/linux-7.1.1-sdm845-CANONICAL. Also committed the previously-floating-uncommitted RTC read-only fix (68ffb014b — the load-bearing half of the 0-SPMI-writes result; it had never been committed, only sitting in the worktree). Both shipped in kernel 7.1.1_p20260701093924-r1, flashed to boot_a.

Process correction (saved to memory pmos-src-skips-apkbuild-patches): pmbootstrap --src builds the working tree as-is, not committed-only. A first build silently included the two then-uncommitted RTC/DTS files; caught by inspecting chroot_native/mnt/pmbootstrap/source-override/. "Bake as commits" is necessary but not sufficient — the worktree itself must be in the intended state at build time.

Verified live post-flash:

• adsprpcd: no longer a fatal crash-loop. Previously coredumped every boot with dsp information is incorrect / Broken pipe. Now: coredumps ONCE on first probe, systemd restarts it (NRestarts=1), then runs stably — successfully opens adsp_default_listener handles on ADSP (domain 0). Old fatal signatures absent from the journal. Residual non-fatal noise remains: remote_handle64_invoke ... method 2 ... Operation not permitted + open_mod_table_handle_invoke ... Error 0xe on domain 0 — a separate ADSP-invoke-permissions issue, not the pageslen bug; next fastrpc thread if pursued.
• SPMI write flood: still 0 — RTC read-only fix preserved across the rebuild.
• /dev/fastrpc-sdsp still ABSENT → hexagonrpcd-sdsp still "Could not attach to FastRPC node: Operation canceled". The pageslen fix targets ADSP/CDSP static-process creation; the SDSP node is a different path (depends on SLPI remoteproc fastrpc edges), so the SLPI/sensor-island story is not changed by this fix.
• dms-ui-ready (r17 C binary): ran clean, same DMS 0x0064 RESULT: FAILURE (result=1 error=58) as before (unchanged, expected — orthogonal to fastrpc).

Modem 52 wall: STILL THERE — now proven independent of adsprpcd/ADSP health too. First mmcli --enable of the entire session with a non-crashing adsprpcd (all chain units active: modem-qrtr-ready, qcril-autoselect, qcril-prov, dms-ui-ready, ModemManager): identical QMI protocol error (52): 'DeviceNotReady' on Set Operating Mode=online, op-mode stays offline, state disabled, lock sim-pin2, SIM on slot 2 (correct). Combined with TOP LEAD #12's SLPI proof, the modem's RF-ready gate is now robust to the entire host-side DSP coordination layer (SLPI state × 3 boots, adsprpcd/ADSP health × 1 boot). The ADSP-PD/servreg candidate is substantially weakened. The wall is the modem firmware's own internal decision; nothing host-side we can move has touched it.

Where that leaves the candidate space: of los-mss-translated.c's four deltas — (1) EFS NV item, (2) bootloader/ABL verified-boot state, (3) subsystem coordination [SLPI/PD], (4) host-QMI-replay timing — #3 is now closed and #4 is substantially exhausted (DMS 0x0064 sends+responds but error 58; NAS mode-pref fails DeviceUnsupported pre-RF). #1/#2 were researched to ground with no static delta. The one instrument that could show the modem's own RF-init reasoning — F3 narration — remains uncaptured (QCSuper's blanket arm skips the NAS/RRC SSID ranges; per-range SET_RT_MASK arms cleanly but yields no traffic, and we lack a Qualcomm SSID name table to confirm those ranges are NAS/RRC). That F3 capture + SSID identification is the most likely remaining source of new signal.

---

TOP LEAD 2026-07-01 #12 — SLPI independence now PROVEN (not just argued); DMS 0x0064 "UI ready" built, untested

SLPI-state dependency is now definitively closed, with hard repeated evidence (2026-06-30 night → 2026-07-01, three separate boots, live hardware). Fixed a real regression along the way: blueline-slpi-ready.sh disabled SLPI crash-recovery for a "single-shot" start; when the SAR/CHRE firmware fault crashed it, the disabled-recovery path left the glink-edge channel permanently torn — intent request timed out storming every ~10s indefinitely, which took the modem's own QMI/QRTR transport down with it (endpoint hangup, Connection reset by peer). Fix: recovery must stay enabled (matches Android's ssr_setup/ssr_diag, which never disables it) so the kernel's own crash handler tears down/rebuilds glink cleanly; the script then does ONE clean attempt and parks SLPI (echo stop) once caught in a healthy running window, instead of crash-looping forever. Verified over three clean boots: SLPI crashed (0 times / 50 times / 0 times depending on timing), every single time DeviceNotReady on RF-enable was byte-for-byte identical regardless of SLPI's state (crashed continuously, running, offline, or cleanly parked). Also wired modem-qrtr-ready.service After=/Wants=blueline-slpi-ready.service to match Android's real architecture — vendor.qcom.devup (what modem-qrtr-ready mirrors) is literally set by init.qcom.devstart.sh right after it kicks SLPI (echo 1 > /sys/kernel/boot_slpi/boot; setprop vendor.qcom.devup 1), confirmed by reading the real Android script off the mounted LOS vendor image. Architecturally correct, safe, zero cost — but does not move the 52 wall. Candidate #4 ("Subsystem coordination — SLPI PD state?") in los-mss-translated.c's delta list is now closed.

Checked and closed a real diagnostic gap: qmicli --dms-get-operating-mode's output includes an optional "Offline reason:" line (libqmi qmi_message_dms_get_operating_mode_output_get_offline_reason, bitmask of HOST_IMAGE_MISCONFIGURATION/PRI_IMAGE_MISCONFIGURATION/PRI_VERSION_INCOMPATIBLE/ DEVICE_MEMORY_FULL) that no prior capture had actually looked for. Checked the existing captured output (tools/modem-online-provisioner/modem-online-provision-20260622-063154.log): the field never appears — the modem doesn't populate any of the four documented reasons. Dead end, but a clean one.

Built AND tested: dms-ui-ready.py/.service + a raw-C fallback. Sends clean, modem responds, 52 unchanged. PAF/qcril_online_sequence.md (prior session, full disassembly of libril-qc-hal-qmi.so) identified DMS message 0x0064 ("telephony UI ready") as the one load-bearing pre-online step QCRIL performs that pmOS had never replayed. The Python/GI implementation (Qmi.Message + raw TLV writers) failed at runtime: this libqmi build does not expose a generic raw-message type via GObject-Introspection at all — only per-message typed classes exist in the typelib, confirmed by enumerating dir(Qmi) live on the phone. Built a small C program instead, cross-compiled against the same libqmi (openimsd fork, 1.39.0) via pmbootstrap chroot -b aarch64, linked directly against the .so already on the phone. Ran it live: the modem answered 0x0064 with a real, understood protocol response (not "unsupported message"), RESULT: FAILURE (result=1 error=58). Error 58's standard libqmi meaning (WMS_ENCODING, an SMS-service code) can't be its true meaning for an OEM DMS message — almost certainly a vendor-private error space reusing that numeric slot. Immediately retried mmcli --enable: DeviceNotReady (52), byte-identical to every attempt all night. Full detail + the C source path in qcril_online_sequence.md. Kept dms-ui-ready.service wired in the boot chain (best-effort, harmless, now proven to do something real) — the Python version in the package needs porting to the same raw-C approach before it'll actually work at boot; that's the concrete next step, not another blind guess.

---

TOP LEAD 2026-06-26 #11 — THE 52 IS A MODEM XPU (SECURE-MEMORY) CRASH-LOOP

🔴 SUPERSEDED 2026-06-29. Captured on the pre-DELTA-1 r2 LLVM kernel, where the modem genuinely crash-looped on an XPU violation. DELTA-1 (c2923cb49 MPSS assign-ordering) fixed the load — on the current kernel the modem MSS runs steady (MBA boots, MPSS loads, remoteproc running, no XPU crash-loop, zero −22 on 4080000; the only crash-lines are the SLPI's SNS_REG_INIT). Yet it still parks OFFLINE / model 0 / 52. So 52 is NOT an XPU crash-loop — it's a firmware-internal RF-init decision, kernel-independent (6.16.7 and 7.1-rc1 both give 52, see #10). The −22 referenced below is the SLPI's fastrpc heap. Kept as the XPU/load investigation record.

Captured live on the rebuilt r2 LLVM kernel (slot A, full system, ssh). The DeviceNotReady (52) wall is now explained at the mechanism level: the modem boots then crash-loops on a hardware secure-memory protection violation, so it can never complete RF-init and parks offline. dmesg (qcom-q6v5-mss 4080000.remoteproc, remoteproc3):

Booting fw image qcom/sdm845/Google/blueline/mba.mbn ... MBA booted ... loading mpss
remote processor 4080000.remoteproc is now up
crash #1: fatal error received: SFR Init: wdog or kernel error suspected.
crash #2: fatal error received: modem_xpu_int.c:456:[modem_sec_xpu_I]XPU violation
... port failed halt ... modem offline ... starting ... up ... crash ... (loop)

XPU = Qualcomm eXtreme Protection Unit — hardware memory guard programmed by TrustZone. modem_sec_xpu XPU violation = the modem firmware accessed a memory region the XPU does not permit it → the modem's secure memory regions are not assigned/programmed correctly for mainline. The modem comes up, touches a protected region, XPU faults it, q6v5 recovers it, repeat. The "running" state in a one-shot remoteproc/state read is just a momentary up-window between crashes — do not trust a single-sample running; watch journalctl -b -p err over ~30s.

This is the same TZ layer as the SLPI/fastrpc failure. Every modem AND slpi restart also logs qcom_scm firmware:scm: Assign memory protection call failed -22 (hyp-assign / qcom_scm_assign_mem → -EINVAL). The fastrpc patch tolerates it; the modem cannot — it needs its secure regions actually assigned. Shared root: this blueline's TZ rejects mainline's secure-memory-assign, → modem XPU violation → 52. See secure_load_tz_frontier.md.

Ruled OUT as the cause of 52 (this session, hard evidence):

• Provisioning / MCFG — software MCFG Rogers_Canada (Casey's real carrier) is Active (PDC --pdc-list-configs=software). Selecting the carrier config — the thing qcril/Set-Feature does on Android — is already done, and 52 reproduces anyway. Platform configs = 0 (blueline EFS gap) and PDC Set Feature 0x2E times out, but neither is the 52: the modem crashes below the QMI layer.
• Kernel config regression — 52 reproduces on the corrected 1135-module r2 LLVM kernel with SLPI/SSC in. Not the GCC-stripped-config disaster.
• libqmi — confirmed the openimsd fork is installed (apk desc: "openimsd fork, adds PDC Set Feature msg 0x2E"; ships Qmi-1.0.typelib). Not the blocker.

[RETIRED 2026-07-01 — see HANDOFF CORRECTIONS] The one-per-boot online attempt was spent this boot ... Modem now poisoned until power-cycle. Online attempts are retry-safe within a boot; QMI Set Operating Mode = RESET (4) cleanly reinitializes, no reboot needed (tools/modem-online-provisioner/RESULTS.md). Kept for history: that boot's attempt gave 52, mode stayed offline, serving-system not-registered/detached, signal InformationUnavailable.

Next frontier: make TZ accept the modem's secure-memory assignment — i.e. the XPU/hyp-assign region setup. Compare LOS pil-tz secure-load (mba region qcom,mba-mem, mpss region assign, qcom_scm_assign_mem VMID lists) vs mainline q6v5_mpss region handling on this device. The assign -22 is the thread to pull. (qmicli also segfaults on --pdc-list-configs — separate libqmi/fork bug to log.)

TOP LEAD 2026-06-21 #10 — KERNEL-REGRESSION HYPOTHESIS: DISPROVEN. Kernel layer ruled out airtight.

Result (clean-boot test, 2026-06-21 eve): built blueline on sdm845-6.16.7-r0 (last pre-regression stable, 2025-09-19), flashed boot_b, booted clean. The modem boots fully on 6.16.7 — firmware loads (Booting fw image …/mba.mbn → remote processor is now up), ALL QMI services register (qrtr-lookup shows DMS/NAS/UIM/Voice/WDS/PDC…), UIM is healthy (card present, USIM ready, Primary-GW slot1/app1), remoteproc2 = running. Yet --dms-set-operating-mode=online → DeviceNotReady (QMI 52), mode stuck offline, Networks '', Max TX/RX 0 — byte-for-byte identical to 7.1rc1. A second run on a clean boot (modem auto-started at boot-time, UIM freshly provisioned) reproduced the same 52, removing the manual-start confound. Per this lead's own triage rule (still-52 on the pre-regression kernel) = the kernel is ruled out airtight. The online wall is NOT a kernel regression; it is device-internal (Route B) — the modem's own firmware RF-init never self-completes, so it parks offline and refuses online (Android never has to ask; see frontier #8 REFRAME). 6.16.7 is now a known-good working kernel for blueline (modem boots clean); either 6.16.7 or 7.1rc1 is fine going forward (both give 52). The live frontier is Route B — see frontier #8 REFRAME below.

Firmware-path gotcha found + fixed (RECORD — bites any upstream-tree blueline DTB)

The 6.16.7 upstream sdm845-google-blueline.dts requests firmware at qcom/sdm845/pixel3/{mba,modem,adsp,cdsp,ipa_fws,a630_zap}.mbn, but pmaports packages blueline firmware at qcom/sdm845/Google/blueline/. So the upstream-tree DTB silently fails request_firmware (ENOENT -2) → modem/ADSP/CDSP never boot (remoteproc: Boot failed: -2). The 7.1rc1 pmaports DTB uses Google/blueline/ (correct) — which is why 7.1rc1 loaded firmware and 6.16.7 did not until fixed. Fix applied on the rootfs (persists across reboots): ln -snf /lib/firmware/qcom/sdm845/Google/blueline /lib/firmware/qcom/sdm845/pixel3 Any future build using the upstream blueline DTB needs this symlink (or a DT patch correcting firmware-name paths) or the modem will not load firmware. (Stray: the 6.16.7 DTB also references qcom/sdm845/oneplus6/venus.mbn for venus — harmless, video-decoder only.)

Kernel-swap procedure (RECORD — the modular-modem-stack gotcha)

The blueline modem stack is fully modular on this config: qcom_q6v5_mss, qrtr/qrtr-smd, qcom_glink_smem, qcom_sysmon, mhi* all =m. So swapping kernels needs the matching modules on the rootfs or the modem never loads (a false 52). UFS + USB-gadget-NCM are built-in (=y), so a module-mismatched boot still reaches rootfs + USB. Working procedure (validated this session): build kernel .apk → tar xzf it → extract lib/modules/<kver>/ → scp to phone → sudo cp -a into /lib/modules/ + depmod <kver> → reboot. Boot.img = cat vmlinuz <blueline>.dtb + the standing initramfs, mkbootimg (header v0, base 0x0, kernel_off 0x8000, ramdisk_off 0x1000000, tags 0x100, the real cmdline quiet splash … pmos_boot_uuid=2CE8-836F pmos_root_uuid=26733d78…). USB iface enp0s20f0u6 (cdc_ncm) needs manual bring-up each boot: nmcli dev set … managed no; ip addr add 172.16.42.2/24 dev …; ip link set … up.

Original #10 thesis + bisect-window analysis (HISTORICAL — hypothesis disproven above)

Thesis (Casey): the 7.1rc1 bump (pmaports MR !8446, merged 2026-04-28, "basic smoke testing… Pixel 3") never validated blueline's modem; the modem may have regressed there. Corroboration: beryllium wiki flags 7.1.0-rc1-sdm845 for modem breakage on the same SoC; Joel Selvaraj had SDM845 modem working on mainline back at 5.11, so the capability predates the regression. Running test: rebuild blueline kernel against sdm845-6.16.7-r0 (last pre-regression stable, 2025-09-19), flash boot_b, retry --dms-set-operating-mode=online. Outcomes: online → regression confirmed, bisect the bump; flaky like beryllium → kernel layer validated, inherit beryllium recipe; still DeviceNotReady(52) → kernel ruled out airtight, it's device-internal firmware/EFS state (Route B).

Kernel-tree pull (2026-06-21) — what the AP-driver diff says about the bisect window

Pulled references/sdm845-linux-20260610-ONHOLD-DAVID-TREE (codeberg sdm845-next-20260610, base 7.1.0) and the sdm845-next-20260306 tarball (base 7.0.0) and diffed the modem-relevant subsystems:

• drivers/remoteproc/qcom_q6v5_mss.c: functionally identical 7.0→7.1 (brace-whitespace only).
• drivers/soc/qcom/pdr_interface.c + pdr_internal.h: rename-only — SERVREG_LOCATOR_SERVICE→ QMI_SERVICE_ID_SERVREG_LOC (both 0x40), SERVREG_NOTIFIER_SERVICE→QMI_SERVICE_ID_SERVREG_NOTIF (both 0x42), reason[257]→reason[SERVREG_PFR_LENGTH+1](=257). No behaviour change.
• qcom_pd_mapper.c present in BOTH trees → the in-kernel pd-mapper is NOT new to 7.1 (already in-kernel by 20260306 / 7.0.0; it landed ~mainline 6.13, so 6.16.7 has it too). The "in-kernel pd-mapper is the regression" sub-hypothesis is weak; the sdm845-mainline rebase is the live one.
• qmi_interface.c, qmi_encdec.c, rmtfs_mem.c: identical 7.0→7.1. Implication for the bisect: in the codeberg 7.0→7.1 window there is NO functional change in mss/pdr/qmi/rmtfs — so if the regression is real and in that window, it is NOT in those drivers (look at clk/regulator/interconnect/scm/smem/glink/IPA instead). Caveat: pmaports tracks gitlab.com/sdm845-mainline/linux, NOT codeberg sdm845/linux (the two repos the Matrix thread argues over), and my window (7.0→7.1) does not cover the 6.16.7→7.0 jump. So this scopes, it does not pin — Casey's 6.16.7 build is still the right swing.

Upstream blueline DTS confirms our DT is already correct (kills #9 a second way)

The 20260610 tree ships an in-tree sdm845-google-blueline.dts + sdm845-google-common.dtsi (model "Google Pixel 3"). Its modem nodes: &mss_pil = blueline/mba.mbn+blueline/modem.mbn, &ipa = blueline/ipa_fws.mbn, mpss memory@8e000000 size 0x9800000, rmtfs-region@f2700000 vmid MSS_MSA. dt-work/blueline-pmos.dts already matches all of these byte-for-byte. Zero WTR/QFE/RFFE/FEM/GRFC regulator nodes in the upstream blueline DTS — same as fajita, same as pmOS. So the pmOS modem DT is upstream-aligned, not a fajita guess. RF power is modem-firmware/RFFE driven (see dt-work/rf-rail-diff-FINAL.txt). Lead #9 (add 11 pm8998 LDOs) is refuted by (a) the upstream blueline DTS not declaring them either, and (b) all 11 candidate LDOs showing use=0 from the AP on live working Android. Do NOT flash dt-work/blueline-live.dtb for this reason.

qrild finding folded in — there is no hidden online handshake

references/qrild (abandoned AOSPM RIL): its modem bring-up (qrild_android_modem.cc ctor) is DMS Set Operating Mode RESET → powerup → NAS register-indications, with setRadioPower a no-op stub. Same levers ModemManager already pulls — no secret QMI sequence that arms RF. This corroborates the #8 REFRAME (qcril_bringup_capture.md): on Android the modem firmware SELF-onlines at its own RF-init; replaying a "QCRIL/RIL online handshake" on pmOS is a dead end because there isn't one.

---

(REFUTED 2026-06-21) #9 — pmOS DT under-defines the pm8998 regulator set

Refuted by #10 above (upstream blueline DTS does not declare these LDOs either; all 11 are use=0 on live Android) and by dt-work/rf-rail-diff-FINAL.txt (RF power is firmware/RFFE-driven, not AP-DT). Kept for the record; do NOT flash the LDO DTB. Original reasoning below.

Direction (Casey + GLM): the fix is in OUR pmOS implementation/DT, make it mimic Android. Concrete, evidenced bug found this session:

Our mainline blueline DT instantiates only ~14 of the 24 pm8998 LDOs. Android defines all of them. Missing from dt-work/blueline-pmos.dts rpmh-regulators (present in downstream Android DTB): ldo4, ldo6, ldo8, ldo9, ldo10, ldo11, ldo15, ldo16, ldo18, ldo23, ldo27. Voltages (from dt-work/android-dtb/android-base.dts, full diff in dt-work/regulator-diff-android-vs-pmos.txt): ldo6=1.856V ldo8=1.2V ldo9=1.704V ldo10=1.704V ldo11=1.0V ldo15=1.8V ldo16=2.704V ldo18=2.704V ldo23=3.0V.

Why this matters even though all 11 are deviceless/use=0 in BOTH regulator_summaries: the modem votes its RF-frontend rails (WTR5975/PA/tuners) directly via RPMh, not the AP regulator framework. If the AP DT doesn't define a rail in the rpmh-regulators node, it isn't in the Linux RPMh regulator set — so when the modem's RF-init requests it, the vote can't be satisfied/arbitrated. Modem RF-init fails → modem parks in offline and refuses LPM/online (DeviceNotReady / silent no-op). This fits every symptom: modem boots (DSP up) but RF never inits; offline won't flip; configs don't help.

Supporting evidence this session:

• Modem FATAL crash in pmOS dmesg: qcom-q6v5-mss: fatal error received: ...Asserted in wlan_vdev.c:_wlan_vdev_create + port failed halt on stop (subsystem not halting cleanly → modem can't flush NV → MCFG selection lost across restart → 0 configs every boot).
• Modem comes up offline (not LPM like Android); set low_power/online return rc=0 but mode never changes; PDC autoselect (Set Feature) does NOT persist across modem restart (RIL-layer, not firmware NV).

Executable plan (start here next session — do NOT re-derive):

1. Diff our blueline DTS rpmh-regulators block vs UPSTREAM linux-next sdm845-google-blueline.dts (Heidelberg's). Our pmaports kernel build may predate the full regulator set. If upstream already defines all LDOs, bump/patch the kernel DTS; if not, add them.
2. Add the 11 missing LDOs to the pm8998-rpmh-regulators node in the blueline DTS at the Android voltages above; mark the RF-candidate analog rails regulator-always-on so they're up at RF-init.
3. Build via pmbootstrap (linux-postmarketos-qcom-sdm845), flash boot_b (see platform.md), boot.
4. dmesg | grep -iE 'regulator|vreg|q6v5|fatal' — confirm no rail/halt errors; then --dms-set-operating-mode=online → --dms-get-capabilities Networks non-empty = RF armed.
5. Leverage other devs (Casey): do NOT silo. Cross-check the SDM845 mainlining wiki, sargo/bonito (Google sister devices) DTS, and the #sdm845:postmarketos.org channel for how RF rails are declared. Heidelberg's blueline series on lore.kernel.org is the authoritative reference.

Artifacts: dt-work/regulator-diff-android-vs-pmos.txt, dt-work/android-dtb/android-base.dts (decompiled downstream DTB), dt-work/blueline-pmos.dts.

---

The modem is a self-contained DSP (MPSS) running Qualcomm firmware. Linux only loads it, powers it, and talks QMI to it. RF is the modem's own internal state machine — Linux cannot drive RF directly. Read this stack bottom-up; the blocker is at L6.

The bring-up stack

L	Layer	What it is	Status (2026-06-19)
L0	Silicon / RF	SDM845 SoC; SDR845 + WTR5975 transceivers; pm8005/pm8998 PMICs	fixed HW
L1	Firmware load	mba.mbn (238 KB) → modem.mbn (67 MB MPSS), via remoteproc q6v5-mss	healthy — "remote processor is now up" ~12.8 s
L2	Power	rpmhpd domains cx/mx/mss; mss→mss.lvl ARC→pm8005_s2_level	healthy — q6v5 votes mss INT_MAX; verified vs Android
L3	Transport	QMI over QRTR; glink-edge to the modem PID	healthy — all QMI services register
L4	Host services	rmtfs (EFS), pd-mapper, tqftpserv, qrtr-ns	CRITICAL 06-19: rmtfs binary was replaced (69KB→141KB) and config changed from -r -P -s to -P -s, causing EFS corruption + modem crash + system freeze at "[stack] dump". Original binary at /usr/bin/rmtfs.orig-20260618 must be restored. CORRECTION (06-19 #2): -r = read-only is WRONG for arming the modem — Android serves EFS read-write and the modem writes modemst2 on boot. Use -P -s (read-write). The 02:38 corruption was the wrong binary, not the rw flag.
L5	SIM / UIM	card detect, app select, primary-GW provisioning	healthy — usim (2) ready, slot1/app1
L6	RF arm	DMS Set Operating Mode → online arms the RF stack	BLOCKED — DeviceNotReady (QMI 52). The 06-19 #2 "rmtfs read-only" root-cause is DISPROVEN (2026-07-02): rmtfs runs -P -s read-write live (drop-in enforced, all EFS partitions present) and 52 persists. rmtfs ruled out. Real cause is the modem's own boot-time RF-init decision (Route B), not an AP EFS-write path.
L7	Data / voice	IPA/rmnet, ModemManager, calls/SMS/data	gated behind L6

The blocker, precisely: DMS Set Operating Mode=online → DeviceNotReady (QMI 52); DMS Get Capabilities → zero channel rates / empty networks = the RF stack never initialized inside the DSP. Everything upstream (L1–L5) is proven healthy. ModemManager reaches enabling, hits this, falls back to disabled, cycles.

Eliminated leads — DO NOT RE-CHASE

Each killed with proof. The "proof" column is why it's dead, not a hypothesis.

Lead	Verdict	Proof
rmtfs NV-files / msm-cros-efs-loader (serve EFS from file copies)	DEAD ( UPDATED 06-19 )	REAL CAUSE FOUND: rmtfs binary was replaced (69KB→141KB) on 06-19 02:38 and service config changed from -r -P -s to -P -s. This broke EFS partition access, causing modem crash → "[stack] dump" → system freeze. Fixed by restoring /usr/bin/rmtfs.orig-20260618 (69192 bytes) and resetting /etc/systemd/system/rmtfs.service.d/writable.conf to -r -P -s. The NV-files approach is dead; the original partition-mode rmtfs MUST be used.
removed-region@88f00000 carveout (was "lead #1")	DEAD	Android iomem: 88f00000-8aafffff : System RAM. The device whose modem works leaves it allocatable. OnePlus-specific quirk. (06-19)
cmd-db maps mss.lvl to wrong PMIC (was "lead #3")	DEAD	Android regulator tree: 4080000.qcom,mss → pm8005_s2_level (correct rail). cmd-db is the same firmware blob on both OSes. pm8005 absent from pmOS regulator_summary is expected — mainline drives it via rpmhpd/genpd, not the regulator framework. (06-19)
vdd_mss-supply / SPMI pm8005@4 in DT	DEAD	Mainline q6v5-mss is power-domains-only for SDM845 (no devm_regulator_get). qcom,pm8005 has no SPMI driver in mainline → adding pmic@4/5 panics the kernel. Only smps1/2 under the rpmh-regulators-2 block is safe. (06-18/19)
"blueline lacks soc-qcom-sdm845-modem dep"	DEAD (stale doc)	Current pmaports pkg is soc-qcom-modem; blueline depends on it just like enchilada. Device-pkg deps + firmware manifests are equivalent. (06-19)
fcc-unlock missing	DEAD	fcc-unlock exists nowhere in pmaports; no SDM845 device uses one. Modem is not FCC-locked-waiting. (06-19)
Modem DT node differs from working device	DEAD	blueline modem node is byte-identical to fajita (same power-domains/clocks/resets); only firmware path + phandles differ. (06-18)
Storage / EFS calibration is missing	DEAD	rmtfs writable + Android-primed EFS (modem online in Android first) → still DeviceNotReady in pmOS. EFS content is not what's missing. (06-18)

Net: every kernel / DT / power / packaging layer is proven equal to blueline-Android (which runs the modem online, Fido LTE) on the same silicon. The blocker is not there.

The frontier (REVISED 2026-06-20 #8 — QCRIL does more at bring-up; mainline stack under-initializes the modem)

Casey's standing thesis (correct, and the through-line of this whole effort): QCRIL powers and initializes more of the modem than ModemManager does — and mainline pmOS, as a minimal port, under-powers/under-initializes the board. We are hunting the specific delta. Evidence gathered:

1. QCRIL sends a 'UI ready' / power-on-optimization handshake to the modem that MM never sends. Android cold-boot capture (android-live-20260619/deep/radio-boot.txt): qcril_qmi_nas_telephony_ready: poweron_opt: send 'UI ready' to modem (qcril_qmi_nas.cpp:17527), plus an active radio-power state machine (qcril_qmi_nas_update_radio_power_request_info → BOOTUP_RADIO_POWER_OFF, qcril_qmi_nas_radio_power_transaction_handler, state line telephony LPM | ril NONE | card UP | modem ONLINE). ModemManager has no equivalent of this poweron_opt / UI-ready signalling.

2. No DT RF node on either OS (see retracted #6) — so the delta is QMI-level (modem-side init/power), not a Linux regulator we can add. The mainline DT brings up cx/mx/mss + the basic stack; it does NOT replicate QCRIL's QMI bring-up choreography.

3. Provisioning race (real bug, partially validated). msm-modem-uim-selection fails every boot: it fires during the early QRTR window ("node with id 0 not found"), then its primary-GW provisioning ACTIVATE times out → service exits FAILURE → the live primary-gw-provisioning session loops end-with-failure/app-reset. Run manually AFTER boot it SUCCEEDS (Successfully changed provisioning session). KEY: with provisioning freshly+cleanly active, --dms-set-operating-mode= online no longer returns DeviceNotReady(52) (returns rc=0) — though the modem still stays offline because PDC configs were 0 that boot. We have never had configs-active AND clean-provisioning AND the QCRIL init handshake all at once.

4. QCRIL online path captured (airplane off→on, android-capture-20260620/qcril-online-capture.txt): qcril_qmi_nas_dms_handle_modem_operating_mode (qcril_qmi_nas.cpp:18289) → "modem's operating mode needs to be changed" → ril SETTING_OP_MODE → modem LPM → ONLINE in ~30ms (a plain DMS set-operating-mode=online). post-transition: set_bootup_power_optimization_state=2, ATEL UI-READY, enable networking/sys-info indications. No hidden RF-power QMI command — the modem is already powered (LPM) and the flip arms RF. KEY STATE DIFFERENCE: Android modem starts in LPM (low_power) and does LPM→online; the pmOS modem sits in offline (deeper state) and offline→online is what fails. So the gate is the combination: (a) MCFG configs loaded, (b) primary-GW provisioning active, (c) the modem in LPM (not offline) for the online flip. We have NEVER had all three at once on pmOS — that is the decisive untested experiment.

The decisive instrument (next): a QMI-message-level capture of QCRIL's bring-up on the rooted Android (enable QMI verbose radio logging, cold boot or airplane-toggle), then diff the QMI request sequence against ModemManager's (we already have MM's via --debug). The delta = exactly what to replay on pmOS (UI-ready/poweron_opt, any NAS/DMS/RF config QCRIL issues). Then replay on pmOS with configs active + provisioning clean. Rooted Android (slot B) is the instrument; keep this doc current as the capture lands.

---

The frontier (REVISED 2026-06-20 #7 — live RF-init trace: blocker reframed to primary-GW provisioning, NOT RF cal)

Ran the decisive pmOS-side RF-init trace (slot B, kernel 7.1.0-rc1, modem over qrtr://0). Two big results — one closes a thread, one opens a sharper one.

The modem is not faulting and nothing it requests is missing. dmesg: clean boot, mba→mpss→ running→handover, NO crash/coredump/fatal in the RF-arm window; an online attempt produces ZERO dmesg delta. tqftpserv serves only the readonly MBN tree (read OK) + an empty mcfg.tmp scratch file the modem RRQ/WRQ-loops on — and mcfg.tmp being 0 bytes is NORMAL (tqftpserv is bind-mounted to the persistent persist partition /dev/sdf2[/rfs] — NOT volatile tmpfs as first feared — and persist is SHARED with Android, so if the working modem needed content there it would persist; it's empty on both). So serving is correct and complete. The modem boots healthy and simply REFUSES online at the QMI layer (DeviceNotReady = clean refusal, not a load failure).

NEW lead — primary-GW SIM provisioning session fails. ModemManager's log during the refusal: refresh indication received: session type 'primary-gw-provisioning', stage 'end-with-failure', mode 'app-reset' — looping every MM retry (~72s), alongside a NAS system-info indication that returns FAILURE: InformationUnavailable. Operating mode offline, HW restricted no (not FCC/HW-locked), serving system fully detached, radio interface none. AND msm-modem-uim-selection failed this boot: "Application was already selected" → operation failed: Transaction timed out → service exit FAILURE. Yet the static card read is healthy: Primary GW bound (slot1/app1), USIM app ready, personalization ready, PIN1 disabled. So the binding exists but the live provisioning SESSION keeps failing + app-resetting. This is distinct from (and more proximate than) the RF-cal lead — the modem may refuse online because primary-GW subscription provisioning never completes, not because RF is uncalibrated. (mBands=[] is non-diagnostic per #6; generic IMEI works on Android per Casey — so cal/QCN lead is weak.)

OPEN — causality not yet proven. Why does the provisioning session end-with-failure while the GW binding shows bound+ready? Candidates: (a) msm-modem-uim-selection timing out leaves the subscription half-selected; (b) the modem triggers an app-reset refresh (post-MCFG) that nothing on the AP side completes the way Android's RIL does; (c) downstream symptom of offline state. Decisive next test (fresh boot, one clean shot): on a fresh slot-B boot, before MM enables, (1) confirm whether the primary-gw-provisioning refresh fails on its own; (2) re-run UIM selection cleanly (the service timed out) and retry online; (3) capture the UIM/provisioning QMI sequence. Compare to what Android's RIL does on the same refresh. Known: a remoteproc reset (online is retry-safe, see CORRECTIONS) both clear UIM provisioning, so this needs a clean boot.

---

The frontier (REVISED 2026-06-20 #5 — MCFG SOLVED; online blocker isolated to device-specific RF bring-up)

Live pmOS run this session SOLVED the MCFG provisioning blocker AND, by doing so, proved MCFG was never the RF-arm blocker. The online wall (DeviceNotReady QMI 52) survives every config/stack/SIM fix. Full elimination, all on hardware (slot B, kernel 7.1.0-rc1-sdm845):

SOLVED — persistent MCFG self-provisioning. qcril-autoselect.py (PDC Set Feature 0x2E, Selection Mode=3) made the modem self-load 2 platform (SS-LA-SDM845) + 25 software (Rogers_Canada) configs from the tqftpserv tree; survives reboot (self-loads at RF-init). Both ACTIVE; software version 0x801481A == Android's exact value. The "0/0 every cold boot" blocker (frontier #3/#4) is dead. Tooling: tools/qcril-autoselect.py + tools/build-openimsd-libqmi.sh (openimsd libqmi fork, has Set Feature). Believed a Pixel 3 mainline first.

RULED OUT as the online (RF-arm) blocker — every one tested on hardware:

• MCFG/PDC — both configs ACTIVE, matching Android. online still 52.
• UIM/SIM — card present, USIM app ready, Primary GW slot1 app1 provisioned.
• timing/lock — MM stopped, 10 patient online retries over 30s, all 52.
• ModemManager — its full 9-step enable (power-state → op-mode indication register → Set Operating Mode 0x2E=online) returns the same 52. Not a manual-qmicli artifact.
• missing stack — pd-mapper, hexagonrpcd, q6voiced, rmtfs (-P -s rw), tqftpserv ALL running; soc-qcom-modem installed; PD JSONs (modemr.jsn/modemuw.jsn) + firmware present; no errors. Matches working SDM845 devices (enchilada/fajita) component-for-component.
• EFS not served — modemst1/2, fsg, fsc all populated (~260K nonzero) + served. (modemcal sdd4 is all-zero; persist sdf2 has data.)
• firmware mismatch — modem sw version g845-00194-210812-B-7635520 IDENTICAL to Android; revision MPSS.AT.4.0.c2.17-00194-SDM845_GEN_PACK.

THE REMAINING BLOCKER = device-specific RF bring-up. Same firmware + same shared EFS + complete stack + DT byte-identical to fajita, yet: NAS get-system-info empty, nas-get-rf-band-info → no bands, mode stuck offline, DeviceNotReady on online. The modem boots but its RF never inits. Two leads:

1. RF cal / QCN — generic test IMEI 990012001581294, model 0, no bands. Classic no-calibration signature. UNCONFIRMED: does the WORKING Android show the REAL IMEI (→ pmOS isn't loading cal/QCN) or the same generic one (→ red herring)? Decisive next test: reboot slot A, read IMEI + DMS caps + bands; compare. (Not done autonomously — avoids leaving the phone off-pmOS while unattended.)
2. Board RF-frontend — fajita (OnePlus 6T) works on mainline; blueline (Pixel 3) shares the q6v5-mss DT node but has a different PMIC/RF frontend (WTR/QFE/antenna tuners). If blueline's RF frontend needs power/GPIO/cal mainline doesn't provide for THIS board, the modem can't arm RF even with identical firmware. (Distinct from the DEAD pm8005/mss-rail lead — this is the RF frontend, not the modem-subsystem rail.)

2026-06-20 #6 — RETRACTED: do NOT treat the board-power lead as closed

I previously wrote this section as "lead #2 CLOSED with positive proof." That was an overclaim and Casey was right to reject it. What the regulator/DT evidence below actually shows is narrower: there is no labeled RF-frontend regulator node in the device tree — confirmed on BOTH mainline AND the downstream Android DTB (dt-work/android-dtb/android-base.dts, decompiled from slot-A boot_a; its qcom,mss@4080000 declares only vdd_cx/vdd_mx/vdd_mss, no RF/WTR/antenna node anywhere). That means we can't fix this by copying an "RF rail" node — NOT that board power is irrelevant. Mainline blueline is a minimal fresh port: it instantiates only rails with explicit consumers and leaves every other board rail off, whereas the downstream stack + QCRIL bring up far more (subsystems, power-on handshakes, NV/RF init via QMI). The live lead remains: what does the modem need powered/ initialized — via Linux rails the mainline port omits, or via QMI commands QCRIL sends — that pmOS does not provide. See the #8 frontier (top of file) for the QCRIL-does-more evidence.

(original text retained below for the evidence it contains)

Brought the "power Android provides" thread full circle on live hardware (Android slot A, rooted):

• No Linux-side RF rail exists on EITHER OS. In both the Android (rf-compare/regulators-android.txt) and pmOS (regulators-pmos.txt) regulator dumps, the modem 4080000.qcom,mss consumes ONLY the Q6 DSP level rails (s6_level=CX, s9_level=MX, s2_level=MSS). There is no WTR/PA/tuner regulator in Linux on Android either — RF-frontend power is driven by the modem firmware over RFFE + GRFC, not the Linux regulator framework. So a "missing regulator in the pmOS DT" was never possible.
• DT modem node is correct + complete (dt-work/blueline-pmos.dts): power-domains cx/mx/mss, xo/bus/mem clocks, glink "modem" transport, gpio-reserved-ranges = <0 4, 81 4> (Linux leaves the modem-owned GPIOs alone). No regulator-supply phandles — correct for mainline q6v5-mss.
• Pinctrl: no AP/modem GPIO conflict. Android TLMM (3400000.pinctrl) owns only camera-CCI, gpio-keys, and USB-extcon pins; the modem's GRFC/RF-control pins are MSS-internal and not AP-routed. The AP cannot be stepping on an RF pin.
• "No bands" is NOT a distinguishing signal. The fresh working-Android radio capture (android-capture-20260620/android-radio-log.txt) shows mBands=[] in CellIdentityLte while fully attached to Fido LTE (REG_HOME, EARFCN 2000 = B4). So the empty mBands we saw on pmOS does not by itself mean RF is dead — weakens (does not kill) lead #1's reasoning.

Verdict: every AP-side power/GPIO/pinctrl/DT input the modem receives is provably equal to blueline-Android (which arms RF on the same silicon). Lead #2 is closed the same way IMEI closed lead #1. The blocker lives strictly inside the modem firmware's RF-init, which the AP only feeds via: firmware blobs, EFS (rmtfs), persist/rfs (tqftpserv), power-domains, clocks, QMI. All proven present/equal — EXCEPT we have never traced what the modem requests from rmtfs/tqftpserv during its RF-init, nor captured the modem's own failure reason.

Decisive next experiment (pmOS-side, not yet run): boot slot A, attempt online, and capture (a) tqftpserv/rmtfs request trace during RF-init — which file/NV path the modem asks for and whether it's served (frontier #4 showed Android rmt_storage reads on boot; we never logged the pmOS read side), and (b) the modem remoteproc coredump / SSR reason on the failed online. This is the one byte-for-byte trace we still lack; it points at the specific RF-init resource that differs.

Route B (autoselect EFS NV item) is DEPRIORITIZED: it would only persist the config state we already achieved, and config-active does not fix online.

---

The frontier (REVISED 2026-06-20 #4 — Android boot is VERIFY-ONLY; the modem persists MCFG itself)

Source: analysis of the captured Android radio logs in android-live-20260619/deep/ (radio-boot.txt, radio-full.txt, ssr-capture.txt), 2026-06-20. This overturns both frontier #3's "just make the platform config active" and the qcril_full_provisioning.md §D.4 "load+activate every boot" model. Read this before either.

What the captures actually show

Across all three logs (~12K PDC log lines, including a full modem SSR) QCRIL made only query calls — never load/select/activate, never pdc_enable_auto_selection:

• ssr-capture.txt:24293 — the decision point: qcril_qmi_pdc_is_modem_mbn_updated: prev_ver_info: MCFG-g845-00194-220517-B-8604334, cur_ver_info: MCFG-g845-00194-220517-B-8604334 → prev == cur → reload SKIPPED.
• ssr-capture.txt:23949 — get_active_config_info_ind: config_version = 0x801481a, Update CNV from 0x48 to 0x48 (0x48 = 72 = cnv=[72] = persist.vendor.radio.mbn0=72).
• Only PDC functions logged anywhere: get_active_config_info, get_selected_mbn_config, get_selection_carrier, is_modem_mbn_updated. Zero *_load_config, *_select_config, *_activate_config, enable_auto_selection, enable_modem_update.

What that means

Android's steady-state boot does almost nothing to PDC. The modem holds its MCFG persisted in its own EFS (modemst1/2 — the 2 MB write to modem_fs2 the rmt_storage capture caught), self-applies it at firmware RF-init every boot, and QCRIL just confirms the active version matches persist.vendor.radio.cnv.ver_info and stops. The full load→select→activate path runs only on first provision or an MCFG version change (the prev_ver != cur_ver branch) — which we have never captured, because every capture was an already-provisioned device. That is exactly why pdc_enable_auto_selection never appears: it lives on the unobserved path.

Consequences for the two prior theories

• Frontier #3 ("just need an active platform config") — necessary but NOT sufficient. PROGRESS L165–172 had BOTH configs active (SS-LA-SDM845 + Rogers) and DMS Networks stayed empty. Active ≠ armed. Don't chase "make it active" as the finish line.
• §D.4 ("load+activate every boot, accept two restarts") — that is a reconstruction of the unobserved first-provision path, not what Android does in steady state. It remains a valid pmOS workaround (see tools/qcril-prov.py), but it is unproven on hardware and is not the mechanism that actually arms RF on Android.

The pmOS problem, restated from the evidence

The "0/0 configs every cold boot" volatility (PROGRESS L140–144) is not something QCRIL fixes per-boot. It's that the modem cannot persist/restore its PDC selection in EFS the way Android does. The earlier "rmtfs read-write didn't fix it" result (ledger L38) is a chicken-and-egg: writable EFS is useless if the modem never had a valid MCFG to commit, and a one-shot userspace activate is useless if it cannot persist to survive the next firmware RF-init. Both are required: a valid config loaded AND modem-side persistence that survives reboot.

Two candidate paths forward

• (A) Per-boot provisioner workaround — tools/qcril-prov.py loads HW+SW, selects, activates each boot. Mirrors the reconstructed first-provision path. Unproven; "active ≠ armed" is the open risk.
• (B) Provision-once + persistence (the Android mechanism) — get a valid MCFG into the modem once, then ensure modemst persistence so the modem self-restores + self-applies at RF-init, and userspace reverts to verify-only. This is what the captures show actually works on hardware.

The capture we still need (next experiment)

A normal-boot capture only re-shows the skip path. To record the real first-provision load sequence (and settle whether pdc_enable_auto_selection / enable_modem_update is a required precondition), force a first-provision on Android: clear /data/vendor/modem_config/ and persist.vendor.radio.cnv.ver_info, reboot, then capture. Runbook: PAF/first_provision_capture.md.

---

The frontier (SUPERSEDED 2026-06-19 #3 — see #4 above — PDC platform config is the blocker)

After a full day of Android-vs-pmOS forensics, the blocker is identified:

What's actually wrong

The modem's PDC (Policy Decision Control) stores MBN configs in modem NV:

• 25 software (carrier) configs loaded — Rogers_Canada is ACTIVE (133KB, v0x801481A)
• 2 platform (hardware) configs loaded — SS-LA-SDM845 is INACTIVE (56KB)

Without an active platform config, the modem doesn't know its RF hardware capabilities. DMS reports Networks: '', NAS home network returns NotProvisioned (QMI 16), and Set Operating Mode=online returns DeviceNotReady (QMI 52).

On Android, QCRIL (libril-qc-hal-qmi.so) loads MBN files from /vendor/rfs/msm/mpss/readonly/vendor/mbn/ via QMI PDC, activates both platform and software configs, and the modem restarts with full RF.

ModemManager does none of this — it assumes the modem is pre-provisioned.

Attempted: direct PDC activation

qmicli --pdc-activate-config=platform,6FE571A9... returned "Successfully requested config activation" but triggered a modem restart that cleared the platform config (0 configs after restart). The activation request succeeded at the QMI level but the modem's internal handling removed the config during restart. Needs Android QCRIL to re-load it.

qmicli --pdc-load-config=... segfaults on MBN binary files (qmicli 1.39.0 / libqmi 1.38.0). Cannot load MBN files from pmOS side — libqmi bug or MBN format incompatibility.

Key facts confirmed (06-19)

• IMEI: identical on Android and pmOS (990012001581294). NOT the blocker. Android works on Fido LTE with this same test IMEI.
• Modem firmware: identical SHA256 (97c1d19c...) between slots A and B.
• Modem crashes (SFR Init / XPU violation): intermittent — some boots 0 crashes, some 2. Even clean boots get DeviceNotReady. Not the blocker.
• rmtfs DOES serve correct partitions: partlabels are GPT-stable; UFS LUN renumbering changes /dev/sdX names between boots but by-partlabel symlinks always resolve correctly.
• DMS Get Capabilities consistently shows Networks: '' and Max TX/RX: 0 on pmOS. Android shows populated networks (Fido LTE, Rogers 302720, full band support).
• NAS Get System Selection Preference shows FULL band tables on both OSes (43 LTE bands + extended). NAS has the data; DMS doesn't. The bridge is the platform MBN activation.
• Android rmt_storage: reads EFS on boot (no writes), writes 2MB to modem_fs2 AFTER going online. Normal operation — not initial provisioning.
• pmOS rmtfs journal: empty (rmtfs doesn't log successful reads/writes). No errors either.

Fix path

1. Boot Android to let QCRIL re-load the platform MBN into PDC (it was there before activation)
2. Boot pmOS — do NOT touch PDC, do NOT run qmicli activation
3. Verify: qmicli --pdc-list-configs=platform shows SS-LA-SDM845 as Active
4. Verify: qmicli --dms-get-capabilities shows Networks: 'gsm, wcdma, lte'
5. Let ModemManager drive enable→online (NEVER manual qmicli online)
6. If platform config is still Inactive after Android: need to fix qmicli --pdc-load-config segfault, or write a minimal MBN loader using libqmi directly

What we have on device

• rmtfs: read-write (-P -s), serving correct EFS partitions via partlabels
• tqftpserv: bind-mounted to /mnt/vendor/persist/rfs (persist partition)
• pd-mapper: installed and running from boot
• MBN files: 179 files (11MB) at /mnt/vendor/persist/rfs/readonly/vendor/mbn/ (extracted from Android /vendor/rfs/msm/mpss/readonly/vendor/mbn/)
• MCFG version: g845-00194-220517-B-8604334
• Rogers Canada MBN: mcfg_sw/generic/NA/Rogers/Commercial/CA/mcfg_sw.mbn
• SDM845 LA/SS platform MBN: mcfg_hw/generic/common/SDM845/LA/SS/mcfg_hw.mbn (56KB)
• Kernel: building from sdm845/7.1-dev HEAD (85f1df2a), config fixed to sdm845

Android vs pmOS service comparison

Component	Android	pmOS	Notes
EFS storage	rmt_storage r/w	rmtfs -P -s r/w	Parity
TFTP	tftp_server → vendor/rfs	tqftpserv → persist bind	Parity
pd-mapper	running (maps PDs)	running	Parity
RIL	QCRIL (libril-qc-hal-qmi.so)	ModemManager	Missing PDC provisioning
ipacm	running (/dev/ipa FDs)	not installed	Data path only
Keymaster	decrypts persist blobs	none	IMEI encrypted at rest
QMI services	comparable (50+)	comparable (50+)	Parity

(superseded) earlier frontiers

Read-only rmtfs theory (06-19 #2): rmtfs read-only prevented modem from persisting EFS writes. Fixing to read-write didn't resolve DeviceNotReady. EFS r/w is necessary but not sufficient — the modem needs valid MCFG in EFS first, which comes from PDC provisioning.

QMI-handshake theory (original): "MM doesn't send QCRIL's init sequence." Dead — same MM binary works on OnePlus 6. The missing sequence is PDC MBN loading, not a handshake gap. Other SDM845 devices likely have platform config pre-loaded from factory.

fsg_oem theory: Modem requesting modem_fsg_oem_1/2. Patched rmtfs to serve them. Modem never actually requests these when EFS is properly provisioned. Symptom, not cause.

XPU violation theory: Modem crashes twice on some boots. Even on clean (0-crash) boots, DeviceNotReady persists. Not the blocker.

Useful commands (pmOS)

qrtr-lookup | awk '$1==11'                       # UIM service → note Port
qmicli -p -d qrtr://0/<port> --uim-get-card-status
qmicli -d qrtr://0 --dms-get-operating-mode
qmicli -d qrtr://0 --dms-set-operating-mode=online
qmicli -d qrtr://0 --dms-get-capabilities         # zero rates = RF uninit
# clean modem re-init (rmtfs runs -P -s read-write; see 2026-07-02 correction):
echo stop  | sudo tee /sys/class/remoteproc/remoteproc2/state ; sleep 3
echo start | sudo tee /sys/class/remoteproc/remoteproc2/state
# preferred: QMI Set Operating Mode = RESET (4) reinitializes without touching UIM/provisioning.

Forcing a remoteproc reset clears UIM provisioning; msm-modem-uim-selection only re-runs at boot. (The old note here claimed -r -P -s read-only was required for re-provisioning — stale and wrong; rmtfs runs -P -s read-write live and the modem re-provisions fine across a stop→start. For a clean reinit that does NOT drop provisioning, use QMI RESET, not remoteproc.)

Cross-references worth mining

• Working SDM845 (same SoC): OnePlus 6/6T (enchilada/fajita), Poco F1 (beryllium), SHIFT6mq (axolotl) — data + SMS work via the same mainline kernel + pmaports packages. Their AP-side config is already in ~/pmos/pmaports; nothing to pull. Their working firmware/EFS is device-specific and not transplantable.
• Pixel 3a (sargo) / 3a XL (bonito): the closest Google analogs with modem support in pmaports (SDM670). Best target if a Google-specific RIL quirk is suspected.
• Android on this exact device is the cleanest reference: same silicon, modem works. Diff blueline-Android vs blueline-pmOS, not against OnePlus.

TOP LEAD 2026-07-02 #16 — locally-initiated DIAG_CTRL/DIAG_DATA open CRASHES the modem (glink_channel_migration assertion), repeatably

Real, causal, previously-unknown finding — not a theory. Following up #15's ack-but-no-reciprocal- open result: tried the same locally-initiated open against DIAG_CTRL (not just DIAG_DATA). Confirmed via dmesg -T (not my own client's stderr, which kept getting lost across SSH session churn — the KERNEL'S OWN log line is the ground truth here): rpmsg rpmsg0: failed to open DIAG_CTRL fires cleanly at the expected 5s mainline timeout, exactly as designed. But roughly 18-40 seconds LATER, every single time this was attempted (three separate occasions, two of them minutes apart on different modem boots), the modem hard-crashes:

qcom-q6v5-mss 4080000.remoteproc: fatal error received: [disable_ssr]glink_channel_migration.c:602:
[IST336]Assertion status == GLINK_STATUS_SUCCESS failed
remoteproc remoteproc3: crash detected in 4080000.remoteproc: type fatal error
remoteproc remoteproc3: handling crash #N in 4080000.remoteproc

This is a repeatable causal chain, confirmed across crashes #5 and #6 in the same dmesg buffer, both immediately following a failed to open DIAG_CTRL line, both with the identical glink_channel_migration.c:602 assertion. glink_channel_migration.c is the FIRMWARE's own glink channel-transport-migration logic (this is a modem-firmware-side log line, reported via SFR/fatal error, not an AP-side kernel message) — meaning the incomplete/abandoned local-open handshake left channel/migration bookkeeping in a state the modem's own firmware asserts on and can't tolerate.

Practical, urgent implication: DO NOT locally-initiate an open for DIAG_DATA or DIAG_CTRL casually or repeatedly during further investigation — it reliably crashes the whole modem MSS a short time later, disrupting whatever else was being tested (this crashed WLAN's firmware too, via the shared XPU/hyp-assign path, matching TOP LEAD #11's earlier finding about shared secure-memory fragility). If this path is pursued further, it needs to be done RARELY, with full crash-recovery tolerance, ideally on a boot with nothing else running that a modem SSR would disrupt.

What this actually tells us, functionally: the modem's glink/migration layer is NOT robust to an AP-initiated open attempt that times out — downstream never hits this because (a) it doesn't time out in 5s (event-driven, no hard deadline, per #15's downstream comparison) and/or (b) Android's DIAG daemon presumably completes successfully before any abandonment would occur. This is now a second, independent data point (alongside offline-vs-LPM, #14) that mainline's bring-up leaves this modem's firmware in a MORE FRAGILE state than Android's does — not just "missing a feature" but "structurally less tolerant of imperfect AP-side timing/sequencing." Worth weighing against #14's LPM finding: both point at the same underlying idea -- whatever Android's fuller bring-up sequence does before touching these channels, mainline's minimal sequence skips, and the modem firmware was never hardened against being touched without it.

Honest gap, not yet resolved: unclear if the crash is specific to DIAG_CTRL/DATA's particular migration-eligible status, or would happen for ANY locally-initiated open of ANY channel abandoned via timeout. Worth testing later (carefully, expecting a crash) against a channel we know is NOT normally migration-sensitive, to isolate whether this is DIAG-specific or a general "don't abandon a local open" hazard on this modem.