bde961c6f2
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
76 lines
4.6 KiB
Markdown
76 lines
4.6 KiB
Markdown
# 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."
|