SouveraineOS/saf/device/evidence/modem_community_research_20260622.md

# Community research — blueline modem on mainline (2026-06-22)

Purpose: GLM's "cheap parallel" ask — is there a KNOWN blueline/SDM845 modem-on-mainline fix we'd
otherwise rediscover? Done read-only (phone was on Android). Verdict + a new lead that reorders the
frontier.

## Headline: there is no known blueline fix to rediscover
- The **sdm845-mainline** project's actively-supported, modem-working devices are **OnePlus 6/6T
  (enchilada/fajita) and Pocophone F1 (beryllium)** — NOT the Pixel 3 generation.
- **crosshatch (Pixel 3 XL — blueline's near-identical twin) modem is also NOT confirmed working** on
  mainline (kernel boots, SSH ok; WiFi/BT/modem are the open items). So this is a **Pixel-3-generation
  gap, not a blueline-unique one.** Nobody has shipped this modem on mainline.
- Implication: don't wait on / search for a blueline-specific recipe — there isn't one. The play is to
  port the **enchilada** (known-good) path and isolate the **device delta**.

## The concrete bring-up chain (now confirmed from sources)
Modem firmware **RF-init → reads radio CALIBRATION from EFS (`modemst1`/`modemst2`) → via `rmtfs` ↔
the `qcom_rmtfs_mem` reserved-memory carveout**. kernel.org confirms `qcom_rmtfs_mem`'s client "is
generally found in the modem firmware and is used for accessing persistent storage for things such as
**radio calibration**." `modemst1/2` hold the NV/cal the modem needs to come online.

### Why this reorders the frontier (the new lead)
GLM's strongest surviving lead is **Route B: a modem-side EFS NV item** (mcfg_autoselect_by_uim /
power-up op-mode), to be read over **DIAG**. But DIAG NV-read uses the **AP↔modem DIAG channel** — a
*different* path than the modem's **own rmtfs-mediated EFS access during RF-init**. So:

> The NV *content* can be byte-perfect (it is — shared EFS) and the modem can STILL park offline if the
> **rmtfs ↔ qcom_rmtfs_mem ↔ EFS** bridge is broken/misconfigured on pmOS. That bridge is **upstream**
> of the NV-content question and is exactly the kind of device-specific thing that's wrong on an
> untested device tree.

This is consistent with everything GLM proved equal (firmware, EFS bytes, configs, stack, DT
"byte-identical to upstream") — because **upstream blueline DT modem support is itself unproven**
(nobody got the modem up), so a wrong/incomplete `qcom,rmtfs-mem` carveout or modem `memory-region`
would not have been caught.

## What enchilada (works) does that we should check against blueline
- Ships a curated **`firmware-oneplus-sdm845`** set; modem cal/region files matter (VoLTE needs extra
  carrier config files).
- **`rmtfs-copy-files` (pmaports MR !4674, draft):** the modem WRITES to its EFS at runtime and those
  writes must persist; they copy the partitions at boot and write changes back. EFS is "a black box —
  a diff before/after shows almost every byte changed." (We share EFS unslotted, so reads are fine;
  but note the modem expects a writable EFS path via rmtfs.)
- Uses **`hexagonrpcd`** (open Hexagon DSP RPC) — DSP/sensors, but part of the enchilada stack.
- Voice/VoLTE historically needed **provisioning from a specific OxygenOS build first** — i.e. the
  working modem was put in a known EFS/NV state from Android before pmOS. (Rhymes with Route B.)

## Proposed instruments (complementary to GLM's DIAG NV probe — do on the SAME pmOS boot)
All mostly read-only; one clean boot.

1. **Verify the rmtfs/carveout chain is actually bridging during the failed RF-init** (NEW, highest value):
   - Is `qcom_rmtfs_mem` reserved-memory present and at the address the modem firmware expects?
     `cat /proc/iomem | grep -i rmtfs`, `dmesg | grep -i rmtfs`, check the DT `qcom,rmtfs-mem` node.
   - Is `rmtfs` serving `modemst1/2`? Run it foreground/verbose or `strace -f` during modem boot:
     does the modem issue rmtfs read requests for the EFS, and do they **succeed**?
     - modem issues reads that **fail** → that's the gate (wrong partition map / perms).
     - modem issues reads that **succeed** but still offline → bridge is fine, push to GLM's NV-content + SSR reason.
     - modem issues **no** rmtfs reads → RF-init never reaches EFS; gate is earlier (carveout/glink/firmware load).
   - Cross-check rmtfs invocation/flags vs enchilada's (`device-oneplus-enchilada` + its rmtfs service).
2. **GLM's DIAG NV read** (mcfg_autoselect_by_uim, power-up op-mode) via edl-pixel `qc_diag` + nvitems.xml — still worth it, but now interpreted as "content check," with #1 as the bridge check.
3. **Forced modem SSR + devcoredump/minidump for the firmware's own failure reason** (escalation):
   - `echo enabled > /sys/kernel/debug/remoteproc/remoteprocN/coredump`, trigger SSR via
     `/sys/kernel/debug/msm_subsys/modem` or a failed online, then read `/sys/class/devcoredump/devcdN/data`.
   - Also check `sdm845-mainline/pmtools` for an existing diag/modem helper (per diag_capture.md note).

## Open question worth one cheap action
Does **crosshatch** (the twin) hit the **identical** DeviceNotReady(52)? If yes, it's confirmed a
family/DT-level gap and any crosshatch progress is directly portable. A targeted ask in
sdm845-mainline (Caleb Connolly / Joel Selvaraj orbit) about Pixel-3-gen modem status would settle it
without us reverse-engineering blind. (The DeviceNotReady QMI-52 itself is generic — the modemmanager
list thread on it reached no root cause; it just means "modem firmware not in a ready state," which
points back to RF-init/cal, i.e. the chain above.)

## Sources
- [SDM845 Mainlining — postmarketOS Wiki](https://wiki.postmarketos.org/wiki/SDM845_Mainlining)
- [OnePlus 6 (oneplus-enchilada) — postmarketOS Wiki](https://wiki.postmarketos.org/wiki/OnePlus_6_(oneplus-enchilada))
- [Pixel 3 XL (google-crosshatch) — postmarketOS Wiki](https://wiki.postmarketos.org/wiki/Google_Pixel_3_XL_(google-crosshatch))
- [pmaports MR !4674 — modem/rmtfs: add rmtfs-copy-files](https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4674)
- [pmaports MR !1640 — make modem work on downstream again](https://gitlab.com/postmarketOS/pmaports/-/merge_requests/1640)
- [kernel.org — qcom,rmtfs-mem.txt binding](https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt)
- [linux-msm/rmtfs](https://github.com/linux-msm/rmtfs)
- [Caleb Connolly — state of mainline on SDM845 (5.14)](https://connolly.tech/posts/2021_07_20-sdm845-mainline-5.14/)
- [FOSDEM 2022 — From Android to mainline on the Snapdragon 845 (slides)](https://archive.fosdem.org/2022/schedule/event/mobile_kernel_snapdragon_845/)
- [sdm845-mainline GitLab group](https://gitlab.com/sdm845-mainline)
- [crosshatch mainlining attempt (#153)](https://gitlab.com/postmarketOS/pmaports/-/issues/153)
- [modemmanager-devel — DeviceNotReady on set operating mode](https://www.mail-archive.com/modemmanager-devel@lists.freedesktop.org/msg07101.html)

---

## pmOS-side LIVE RESULTS (2026-06-22 boot, slot A, kernel 7.1.0-rc1) — instruments run, doors closed

Ran the proposed battery on a fresh pmOS boot. Results eliminate the rmtfs lead AND both pmOS deep-probe paths, and corroborate GLM's reframe from a second angle.

1. **rmtfs bridge: HEALTHY this boot — eliminated as the gate.** `rmtfs -P -s` (pid 697) has every link
   open: `/dev/qcom_rmtfs_mem1` (fd5), `remoteproc2/state` (fd6), `modemst1`/`modemst2` (sdf3/sdf4),
   `fsg`/`fsc` (sdf5/sdf6), and OEM copies in `/var/lib/rmtfs/`. Carveout `rmtfs-region@f2700000`
   present. The `Failed to get rprocfd` crashes are *other* boots, not this one. **Modem reads its EFS
   via rmtfs successfully and still parks offline** → bridge is not the gate.
2. **DIAG unavailable on pmOS** — no `/dev/diag`, no diagchar module (mainline doesn't ship it, as
   diag_capture.md warned). **GLM's Route-B DIAG NV read cannot run on pmOS.** It's Android-only.
3. **SIM/UIM fully ready** — `uim-get-card-status`: card present, USIM app `ready`, Primary GW
   provisioned (slot 1 / app 1), PIN1 disabled. Reads work.
4. **NEW corroborating signal — modem refuses STATE CHANGES, serves all READS:**
   - `dms-set-operating-mode=online` → instant `DeviceNotReady (52)` (clean QMI: Alloc CID → Set Op
     Mode → FAILURE → Release CID; modem replies immediately, does not hang).
   - `uim-change-provisioning-session` (what `msm-modem-uim-selection` runs) → **Transaction timed out**,
     repeatably, even with modem fully up.
   - vs reads (card status, op-mode get, qrtr service list) → all succeed instantly.
   - The modem registered its QMI services on qrtr (NAS, Voice, PDC, **Modem EFS svc 21**, etc.).
5. **devcoredump path yields nothing** — armed `remoteproc2/coredump=enabled`, attempted online: modem
   does NOT crash/SSR, no `devcdN`, no SMEM failure string, no dmesg modem reaction. **There is no crash
   reason to harvest** — the modem is in a stable, deliberate "offline / not RF-ready" state.
6. ModemManager is **masked** (intentional, for manual qmicli testing). Modem not poisoned by the
   attempt (clean refusal); phone still usable on pmOS.

### What this leaves (frontier now)
Every STATIC AP-side layer is proven equal/healthy: firmware loads, rmtfs serves EFS, EFS bytes shared
& identical to Android, SIM ready, configs active (GLM), DT byte-identical. The modem firmware itself
decides RF-init is incomplete and **fast-refuses every state transition** while answering queries — and
exposes no reason on pmOS (no DIAG, no crash). So a *static* NV/EFS diff is NULL (confirmed direction)
and the deep-probe instruments are exhausted on pmOS.

**The remaining differentiator is RUNTIME: the QMI choreography Android's `qcril` performs before/around
going online** that pmOS (cold `set-operating-mode=online`) never does. The qcril strings we pulled show
exactly this shape — `INTERNAL_MMGSDI_CARD_POWER_UP`, indication-register / set-event-report across
DMS/NAS/UIM, `qcril_qmi_nas_trigger_polling_operating_mode`, `POST_OPRT_ONLINE_ACTION`, the bootup
optimization state machine. The `uim-change-provisioning-session` timeout is plausibly part of the same
missing handshake.

### Next action (the fix path, not another probe)
Decompile the pulled `qcrild` / `libril-qc-hal-qmi.so` (`android-reference/vendor-stack-20260621/`) to
extract the exact pre-online QMI request sequence, then **replay that choreography on pmOS over
libqmi/qmicli before `set-operating-mode=online`** (the qcom-imsd / provisioner pattern). That is the
discriminating *and* corrective experiment; the read-only probes have told us all they can.