Fimeg/SouveraineOS
Watch
1
0
Fork
You've already forked SouveraineOS
 0
Code Releases Activity
SouveraineOS/saf/device/evidence/modem_community_research_20260626.md
Fimeg bde961c6f2 saf: one spine — device, state, and work under the index 
PAF becomes saf/device (history kept), STATE.md dissolves
into saf/state.md with the dated era archived, the substrate
SAF moves up from souveraine, and every agreement points at
saf/INDEX.md and nowhere else. one map, nothing to remember
2026-08-18 09:47:30 -04:00

4.6 KiB
Raw Permalink Blame History

PAF · Community research + reconciliation (2026-06-26)

Prior-art sweep run against our live evidence from this session (the modem XPU-violation crash-loop = the 52; see modem.md TOP LEAD #11). Conclusion up front: the community's known fix does NOT match our failure mode; our wall (secure-load / XPU) is likely uncharted in the public SDM845 mainline ecosystem.

What the evidence RULES OUT

  • tqftpserv rsize/seek MCFG bug (the Fairphone 4 / SM7225 unblock).
    • Refs: ModemManager issue #484 (gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/484); tqftpserv PR #13 (github.com/andersson/tqftpserv/pull/13); pmaports !4747 / #2550.
    • Their modem fetched MCFG with rsize=/seek= TFTP options that an old tqftpserv mis-served → modem never RF-inits → permanent DeviceNotReady(52).
    • NOT us: our tqftpserv RRQ lines show rsize=0 seek=0, and tqftpserv is actively serving /readwrite/mcfg.tmp. Transport works. Our modem also does NOT sit stably offline — it crash-loops (theirs stayed up and refused).

What the evidence RULES IN / leaves open

  • pd-mapper / MPSS protection domains. Research: SDM845 needs rmtfs + pd-mapper + tqftpserv; pd-mapper brokers mpss_root_pd / mpss_wlan_pd.

    • Refs: in-kernel pd-mapper v9 (mail-archive linux-kernel msg2570727); LWN 973399; RFC linux-remoteproc msg00281 (modemuw.jsn side-load).
    • Our state: userspace pd-mapper = inactive / not-found (likely not installed). Kernel PDR framework is partly alive (PDR: Indication … adsp/audio_pd). OPEN next-session check: does the MPSS protection domain actually register in-kernel, or is the modem's PD coordination missing? PD = the secure-memory layer the XPU violation lives in, so this is the lead that fits our evidence.
    • Note: no public source explicitly ties pd-mapper absence to DeviceNotReady(52) or to an XPU violation — inference, not documented.

  • Platform MCFG missing (0 platform configs, 25 software, Rogers active).

    • openimsd qcom-baseband-profile-manager (openimsd.com; NLnet VoLTE-Qualcom grant) selects among EXISTING software configs — it does not manufacture a missing platform/HW MCFG. OnePlus 6 ships firmware-oneplus-sdm845 with factory MCFG extracted from Android; blueline's EFS lacks the platform MCFG.
    • No prior art for the zero-platform-MCFG case or --pdc-load-config of a platform MBN from scratch. Possibly novel. But per our timeline the modem crashes (XPU) before the platform-MCFG layer matters, so this is downstream of the secure-load fault, not the first blocker.

Confirmed external bugs (not ours to fix)

  • qmicli --pdc-list-configs segfault = upstream libqmi issue #24 (gitlab.freedesktop.org/mobile-broadband/libqmi/-/issues/24, since 1.24.0, segfaults in PDC response cleanup AFTER printing). Not the openimsd fork's fault. Workaround: ignore exit code / 2>&1. Watch libqmi git log on qmi-pdc.c cleanup for the fix version.
  • PDC Set Feature 0x2E timeout — zero public reports. Inferred cause: PDC service present on QRTR but not processing because the modem hasn't finished init (consistent with our crash-loop). Not independently a blocker.

Net direction (for next session)

The 52 is a secure-load / TZ-XPU problem unique enough that the community has no recipe. Concrete next experiments, cheapest first:

  1. Confirm whether MPSS protection domain registers in-kernel; if not, try installing/running userspace pd-mapper (apk add pd-mapper) and re-capture whether the XPU violation changes.
  2. Pull the qcom_scm_assign_mem -22 thread: diff LOS pil-tz secure-load region/VMID setup (mba qcom,mba-mem, mpss assign) vs mainline q6v5_mpss on this device — the XPU violation means the modem's secure regions aren't assigned the way TZ expects.
  3. Verify whether 6.16.7 also XPU-crash-loops — but NOT as a regression test. Correction (Casey, 2026-06-26): no mainline kernel ever had a working modem. 6.16.7 "booted + QMI registered" (lead #10) but never went online either — that is NOT a working-modem baseline. The ONLY known-working modem state is LineageOS on its downstream kernel (PAF provenance: msm-4.9 4.9.337, slot B — Casey recalls it as ~4.x; the substance is downstream LOS, not mainline). So the only valid parity yardstick is mainline vs LineageOS, never 6.16-vs-7.1.1. Checking whether 6.16.7 XPU-loops is still useful (tells us if the XPU fault is mainline-wide vs 7.1.1-specific), but frame it as a mainline-wide question, not "did we regress from a working 6.16."