Watch

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

10 KiB

Raw Blame History

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.

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).
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.
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

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.

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.
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.
SIM/UIM fully ready — uim-get-card-status: card present, USIM app ready, Primary GW provisioned (slot 1 / app 1), PIN1 disabled. Reads work.
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.).
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.
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.

10 KiB Raw Blame History