SouveraineOS/saf/device/evidence/modem_consumer_chain_20260626.md

# PAF · The modem userspace CONSUMER CHAIN — why the modem stays OFFLINE (2026-06-26, Opus)

> ## SESSION-3 UPDATE (2026-06-27, Opus) — SLPI SAR CRASH LOOP **FIXED**; ~~PROVEN the SLPI does NOT gate the modem 52~~
>
> ### TL;DR
> Built the missing **AP-side SNS registry provider** (a patched `hexagonrpcd`) that feeds the
> SLPI its sensor registry over FastRPC `apps_std`. The SLPI's `sar.cc:27:chre_utils fatal`
> crash-loop (150+ crashes/boot) is **broken — SLPI now stays up indefinitely** (0 crashes over
> multiple 25–40s windows). **Then enabled the modem anyway → still `QMI error 52
> DeviceNotReady`.** So the SLPI/SAR subsystem is **independent of** the modem-52 wall. That
> question (could not be answered by *disabling* SLPI — only by making it actually work) is now
> settled: **error 52 is not SLPI-gated.**
>
> **🟠 SUPERSEDED 2026-06-29 (Casey) — this conclusion is INVALID.** The "SLPI fixed / 0 crashes / stays
> up" above was only *remoteproc-not-crashing*: this doc's own body (search *"never exposes an SNS QMI
> service"*) shows the SLPI firmware never completed CHRE init / never exposed SNS QMI — i.e. **not a
> functioning sensor stack.** The reasoning "disabling couldn't answer it, only making it work can" was
> correct — but "making it work" was never achieved, only "stopped crashing." If the modem's RF-init
> queries the SLPI and gets silence from a never-initialized sensor stack, it parks OFFLINE regardless.
> The SLPI is a **candidate root-cause**, NOT proven-independent. See `slpi.md` top banner + `HANDOFF.md`.
>
> ### HOW the SLPI was fixed (the real consumer chain Android calls `sscrpcd`)
> The SLPI boots → makes FastRPC **reverse** calls (`apps_std` fopen/fread) back to the AP to read
> `/persist/sensors/registry/...`. pmOS shipped **no AP-side listener**, so the registry sensor
> starved and the SAR (sx932x) CHRE nanoapp fataled → crash loop. The pmOS-native listener
> **`hexagonrpcd`** (linux-msm, already in the repo, `-s` = attach sensorspd on `/dev/fastrpc-sdsp`)
> is the right tool but had two gaps:
> 1. **Ran as `User=fastrpc`** → couldn't read the persist registry files. Fixed with a systemd
>    drop-in `User=root` (`/etc/systemd/system/hexagonrpcd-sdsp.service.d/10-root.conf`).
> 2. **`construct_root_dir()` (rpcd_builder.c) only mapped `registry/registry/*`** — its virtual
>    FS had **no nodes** for the top-level `sns_reg_config` / `sns_reg_version` / `sns_reg_ctrl`
>    that blueline's SLPI requests at `/persist/sensors/registry/<file>`. hexagonfs is node-based
>    (no real-FS fallthrough), so those ENOENT'd no matter what was on disk. **Patched** to add
>    those three nodes (`hfs_map_or_empty`). NOTE: `hfs_map_or_empty` presents a missing physical
>    file as an empty **directory** (`S_IFDIR`), which still fails a *file* open — so the physical
>    file must EXIST (even 0 bytes). `sns_reg_version` is absent from the Android dump → `touch` an
>    empty one and it serves as a regular empty file, which satisfies the SLPI.
> 3. Registry DATA staged to **`/usr/share/qcom/sensors/registry/`** (hexagonrpcd's default `-R`
>    root; the 177 groups from the LineageOS persist dump + `sns_reg_config`, empty `sns_reg_version`,
>    `sns_reg_ctrl`). Persist files also `chmod -R a+rX` (they were `0600 casey:casey` from a tar
>    restore).
>
> ### STATE OF THE FIXES — now converted from live temps to REAL in-code fixes (2026-06-27)
> All of the live drop-in/temp changes have been turned into aport sources so a clean
> `pmbootstrap install` reproduces them (idempotent fresh + upgrade). What's in code now:
> - **hexagonrpcd patch → local aport** `pmaports/temp/hexagonrpcd/` (fork of Alpine community
>   aport, `pkgrel=4`, adds `hexagonrpcd-blueline-registry-nodes.patch`, checksums regenerated).
>   `pmbootstrap build hexagonrpcd` produces the patched binary instead of the live hand-installed
>   `/usr/bin/hexagonrpcd` overwrite.
> - **root drop-in** → `device-google-blueline/hexagonrpcd-sdsp-root.conf`, installed to
>   `/usr/lib/systemd/system/hexagonrpcd-sdsp.service.d/10-root.conf` (APKBUILD `package()`).
> - **registry data** → NOT shipped as blobs. `blueline-sns-registry-stage.sh` +
>   `.service` (oneshot, `Before=hexagonrpcd-sdsp`, ordered after persist mount) stage the registry
>   from the device's OWN `/mnt/vendor/persist/sensors/registry` into `/usr/share/qcom/sensors/registry`
>   (hexagonrpcd's served root; persist layout is off-by-one for a single `-R`). Touches the empty
>   `sns_reg_version`. Idempotent, ships no proprietary calibration.
> - **service enable** → preset enables `blueline-sns-registry-stage.service` + `hexagonrpcd-sdsp.service`.
> - **persist perms**: handled by the stage script's `chmod -R a+rX` on the served copy; the persist
>   `chmod` I did live is NOT needed by the real fix (hexagonrpcd reads `/usr/share/qcom`, not persist).
>
> **REMAINING build/verify steps (need device + reflash — do NOT half-run unattended):**
> 1. `pmbootstrap build hexagonrpcd` (local aport) + `pmbootstrap build device-google-blueline`.
> 2. Install/upgrade on device (`pmbootstrap` sideload or apk add the built .apk) — replaces the
>    hand-installed binary + lands the drop-in/stage-service/preset.
> 3. Reboot clean and VERIFY idempotency: SLPI stays up (0 `crash #` delta), provider active,
>    `blueline-sns-registry-stage` populated `/usr/share/qcom/sensors/registry`.
> 4. Revert the hand-installed temps once the packages own them: restore `/usr/bin/hexagonrpcd.orig`
>    is NOT needed (apk upgrade overwrites), remove the manual `systemctl enable` (preset handles it).
> - **Kernel DT vmid change** (`sdm845.dtsi` sdsp fastrpc `qcom,vmids = <HLOS SSC_Q6>`): I hand-patched
>   the DTB into boot_a to test the TZ hyp-assign theory. LOGGED RESULT: with `<3 5>` live (confirmed
>   via `dtc` decompile of `/sys/firmware/fdt`), `dmesg` still prints
>   `SDSP fastrpc hyp-assign rejected by TZ (-22); registering node without reserved-heap assignment`
>   (32 occurrences). So the vmid change did NOT change the TZ result — the crash fix was the registry
>   serving, not the heap. The change is harmless but unnecessary.
>   - Orig boot.img backups: scratchpad `boot.img` + `/tmp/boot-backup_a.img` on device.
>   - NOTE on a reboot during testing: `lsusb` showed `18d1:d001` and SSH returned `Network is
>     unreachable`; root cause was the HOST iface `enp0s20f0u6 DOWN` (per `ip -br addr`), fixed by
>     `ip link set up` + `ip addr add 172.16.42.2/24` → phone answered, `uptime` = up 2 min. The
>     phone had booted normally; it was a host USB-net enumeration issue, not a device boot failure.
>
> ### THE REMAINING WALL — modem `QMI 52 DeviceNotReady`, now provably INDEPENDENT of SLPI
> With SLPI fully up + sensors registry served, `mmcli -m 0 -e` still fails at DMS
> `set-operating-mode` with **QMI 52**. modem0 enumerates (QUALCOMM, SIM present, slot 2 active),
> sits `disabled / power off`, enable → `enabling → (QMI 52) → disabled`. The MSS remoteproc
> (`4080000.remoteproc`) is `running`. LOGGED: `mmcli -m 0 -e` → `state changed (disabled ->
> enabling)`, `couldn't enable interface: 'Couldn't set operating mode: QMI protocol error (52):
> DeviceNotReady'`, `state changed (enabling -> disabled)`. So 52 comes from the modem path, with the
> SLPI fully up — the two are independent.
> **Scope note:** the goal is the WHOLE device, not just telephony. The SLPI/sensors fix is a real
> bringup win on its own (sensors infra now functional). For the 52 specifically, the SLPI is not the
> lever. **Next session for 52: modem NV/EFS/identity** (the `model 0` / LOW_POWER hypothesis from
> session 2), rmtfs/EFS sync, or modem firmware-init.
>
> ### Open loose end (minor): hexagonrpcd reconnect churn
> Provider shows `activating` with ~18 restarts/min — it exits on FastRPC "Broken pipe" when the
> SLPI closes the session after serving, then `Restart=always` reattaches. SLPI stays up regardless
> (0 crashes), so it's cosmetic, but worth a `RestartSec`/keepalive tweak later.
>
> ---
>
> ## SESSION-2 UPDATE (2026-06-26 late, Opus) — CHAIN BUILT + WORKING; wall is now the modem 52 / SLPI-SAR firmware crash
>
> ### What got BUILT this session (all in pmaports `device/testing/device-google-blueline/`, deployed live + wired into APKBUILD/preset — idempotent)
> The whole consumer chain now comes up automatically on a clean boot and ModemManager
> starts + creates the modem. Verified on hardware.
> 1. **`modem-qrtr-ready.service` + `modem-qrtr-ready.sh`** (NEW) — the pmOS equivalent of
>    Android's `wait_for_prop vendor.qcom.devup 1`. Blocks until modem QMI answers and is stable
>    (2 probes/3s) before releasing consumers. Killed the boot race
>    (`node with id 0 not found in QRTR bus`). VERIFIED: gate waits, then releases.
> 2. **UIM-selection fix** — `blueline-uim-select.sh` (NEW) wraps the stock binary: it selects the
>    SIM app fine but then a trailing QMI op times out (SLPI/XPU churn) and exits 1 — a false
>    negative that failed MM's hard `Requires=`. Wrapper treats "app selected" as success.
>    `uim-wait.conf` rewritten: gate on modem-qrtr-ready, Type=oneshot, run the wrapper. VERIFIED
>    `msm-modem-uim-selection` now = active.
> 3. **`qcril-prov.py` — fully fixed** (was crashing on `out.get_configs()`):
>    - `list_configs` + `get_selected_config` reworked to read the PDC **indication**
>      (`IndicationPdc*Output.get_configs()/get_active_id()`), not the response.
>    - GI array-length args fixed (`set_id(id)`, `set_type_with_id_v2(t,id)`).
>    - Targets configs by **sha1(.mbn) == PDC config id**; selects+activates HW + Rogers SW.
>    - **Skip-if-already-active**: checks get_selected_config; if the inherited config is already
>      active, skips select/activate → **0 modem restarts** (was 2). VERIFIED:
>      "HW/SW already SELECTED+ACTIVE — no restart".
>    - **Deadlock fix**: exits 0 after provisioning even if RF not armed (RF arming is MM's job,
>      and MM is gated behind this service — requiring RF here deadlocked). VERIFIED exit 0.
> 4. **`blueline-dpm-open-port.service` / `qcril-prov.service`** — gated on modem-qrtr-ready + retry.
> 5. Kernel: mem-protect skip reverted (`980c4ae1f`); on clean baseline 7.1.1; `verify-fixes.sh` green.
>
> ### THE WALL NOW (single, precise)
> Full chain runs → **ModemManager starts, creates `modem0`** (qcom-soc plugin, 3 ports), reads the
> SIM ATR, goes `disabled → enabling` → calls set-operating-mode → **`QMI error 52 DeviceNotReady`**
> → falls back to `disabled`. This is the SAME 52 from day one. The modem is **OFFLINE, model `0`**
> (up-but-unprovisioned) and **refuses to enable even when driven correctly by MM**. So the entire
> userspace plumbing is now proven-good; the wall is the modem itself refusing RF.
>
> ### SLPI / SAR — the suspected gate (Casey's thesis), what we proved
> - SLPI **crash-loops `sar.cc:27:chre_utils fatal` every ~10s** (crash #15+). SAR = Semtech
>   **SX932x**, the modem's RF SAR/TX-power sensor.
> - It is a **CHRE nanoapp crash INSIDE the SLPI firmware at init**, and **qrtr-lookup is empty —
>   the SLPI never exposes an SNS QMI service before it dies**. So an AP-side QMI "SAR consumer"
>   has nothing to attach to; the producer fatals first. A downstream subscribe-consumer is NOT
>   the missing piece.
> - The real missing piece is whatever **feeds the SLPI its sensor registry / CHRE settings at
>   init**: the SAR registry data (`sx932x_0.sar`, `.config`, `_platform.*`) IS present at
>   `/persist/sensors/registry/registry/` but is **NOT delivered to the SLPI** (its RFS dir
>   `/persist/rfs/msm/slpi` is empty; tqftpserv serves only `/persist/rfs`, not `/sensors`).
> - Android's consumer stack (proprietary, NO open-source equivalent):
>   **`chre_daemon_msm` + `sensors.qti` + `sscrpcd`** (in `android-reference/vendor-stack-.../vendor/bin/`),
>   plus the registry under `android-reference/persist-sensors-20260625/`. Our
>   `drivers/soc/qcom/qcom_ssc_sensors.c` is a **passive ABI shim** — it does NOT deliver the
>   registry or run CHRE, so it cannot prevent the firmware crash. This is the "shim lacking
>   components LineageOS has" Casey referenced.
>
> ### NEXT ANGLE (Casey's call — start here next session)
> 1. **DECISIVE CHEAP TEST FIRST — is SAR actually the modem gate?** Stop the SLPI remoteproc so it
>    is NOT crash-looping (`echo stop > /sys/class/remoteproc/remoteproc2/state`), then let MM try
>    to enable the modem (or `qmicli --dms-set-operating-mode=online` once). If still **52** →
>    SLPI/SAR is NOT the modem gate (independent symptoms) → stop chasing SAR for telephony and look
>    elsewhere for the 52. If it **goes online** → the SLPI churn was the blocker and the SAR/CHRE
>    consumer becomes critical. **Run this before building anything.**
> 2. If SAR IS the gate: the buildable "consumer" is a **registry/CHRE provider** that feeds the
>    SLPI at boot (reverse the SNS/CHRE QMI registry protocol; or port pieces; or boot SLPI
>    on-demand AFTER preparing its env, like LineageOS `sensors_ssc.c` does — it does NOT auto-boot
>    the SLPI raw). Investigate `chre_daemon_msm` / `sscrpcd` behaviour + how the registry reaches
>    the SLPI on Android (RFS path? SNS QMI? direct?).
> 3. Independent of SAR: chase **why the modem boots OFFLINE/model-0** (vs Android's LOW_POWER).
>    model `0` = NV/identity not fully loaded — possible EFS/NV or firmware-init issue.
> 4. Fallback: downstream-kernel hybrid (Droidian/Halium) — the realistic telephony path if mainline
>    SLPI/CHRE proves intractable.
>
> ### SAR consumer — EXACT mechanism (from slpi.mbn strings) + the build blocker
> The SLPI firmware reveals precisely what the consumer must be:
> - Reads registry from **`/persist/sensors/registry/registry`** (+ `sns_reg_config`, `sns_reg_version`).
> - **`Sending registry request for group name:%s` / `SNS_REG_INIT` / `Decoding registry group %s` /
>   `Error decoding registry event`** → the SLPI **requests registry groups over the SNS QMI service
>   and expects encoded registry-event responses**. The SAR (sx932x) nanoapp fatals (`sar.cc:27
>   chre_utils fatal`) when it can't get its group → crash-loop.
> - Fallback strings exist: **`Registry disabled, leaving default mode enabled` / `LPI Registry
>   Disabled`** — there may be a registry-disabled mode worth forcing (SAR likely still needs its
>   device config though).
> - **The consumer = an SNS registry provider** (QRTR/QMI daemon) that reads
>   `/persist/sensors/registry/registry/<group>` and answers the SLPI's requests. On Android this is
>   `sensors.qti` + `sscrpcd` + `chre_daemon_msm` (binary-only in
>   `android-reference/vendor-stack-20260621/vendor/bin/`).
> - **BUILD BLOCKER (why it's not done):** the SNS protocol is Qualcomm proprietary protobuf
>   (`sns_client.proto` / `sns_registry`); there are **NO .proto defs or SNS source anywhere in the
>   tree** — only the registry DATA and the binary daemons. A working provider needs that encoding;
>   building blind yields non-functional code. Options: (a) extract/RE the SNS protobuf from the
>   vendor .so (`libsnsapi`/`sensors.qti`) — multi-day; (b) find an open SNS impl to port;
>   (c) run the vendor `sscrpcd`/`sensors.qti` binaries under a libhybris/Halium shim;
>   (d) downstream-kernel hybrid (sidesteps mainline SLPI entirely).
>
> ### CLEAN decisive test to run next boot (settles whether SAR even gates the modem — do BEFORE any SNS build)
> The session test was contaminated (modem already poisoned by prior online attempts). Clean version:
> `systemctl mask ModemManager qcril-prov qcril-autoselect blueline-dpm-open-port` → reboot →
> on boot immediately `echo stop > /sys/class/remoteproc/remoteproc2/state` (kill SLPI before it
> crash-loops) → wait for modem QMI up → ONE `qmicli -p -d qrtr://0 --dms-set-operating-mode=online`.
> - Still **52** with SLPI cleanly stopped from boot → **SLPI/SAR is NOT the modem gate** (the 52 /
>   model-0 is independent — chase modem NV/EFS/firmware-init instead; don't invest in the SNS build).
> - **Goes online** → SLPI/SAR churn WAS the blocker → the SNS registry provider is worth the build.
> Unmask afterwards: `systemctl unmask ModemManager qcril-prov qcril-autoselect blueline-dpm-open-port`.
>
> ### Files touched this session (for the next agent)
> - `references/linux-7.1.1-sdm845-CANONICAL` @ `980c4ae1f` (revert skip); `tools/verify-fixes.sh` (skip-absent check)
> - pmaports `device/testing/device-google-blueline/`: `qcril-prov.py`, `modem-qrtr-ready.sh`+`.service`,
>   `blueline-uim-select.sh`, `uim-wait.conf`, `blueline-dpm-open-port.service`, `qcril-prov.service`,
>   `APKBUILD`, `80-device-google-blueline.preset`. All also deployed live to the phone.
> - NOTE: APKBUILD `sha512sums` NOT yet regenerated for the new/changed sources — run
>   `pmbootstrap checksum device-google-blueline` before the next package build.

---


THE session that reframed the whole problem. The modem-online blocker is **not** (only) a
kernel/secure-load issue — it is that the **userspace consumer chain that drives the modem is
half-built / failing**, exactly as Casey kept saying. Everything below is VERIFIED LIVE on the
reverted-baseline 7.1.1 build, not inference.

## TL;DR causal chain (verified end to end)
1. Modem firmware boots, MBA loads MPSS, modem reaches `running`. It has identity (IMEI
   990012001581294, ESN 8074BB5D, MEID, SW `g845-00194-210812`). **The assign/-22/secure-load is
   NOT the modem blocker** — the modem loads. (The only `-22`s are fastrpc + ath10k wifi, both
   tolerated.) One XPU violation at boot, self-recovers (Casey was right).
2. BUT the modem comes up **op-mode OFFLINE (3), model `0`** = up-but-unprovisioned/not-ready.
   `--dms-set-operating-mode=online` → **QMI 52 DeviceNotReady**. Forcing online does nothing.
3. **SLPI crash-loops every ~10s**: `err_qdi.c:456:EF:sensor_process:1:sar.cc:27:chre_utils fatal`
   → recover → up → crash. SAR (Semtech SX932x) is the modem's RF SAR/TX-power sensor.
4. The modem+SLPI instability makes the **QRTR node flap**, so the boot-time consumer services
   race an unready modem and **fail**:
   - `msm-modem-uim-selection.service` → `node with id 0 not found in QRTR bus` (boot) /
     `Transaction timed out` (later). **This is a hard `Requires=` of ModemManager.**
   - `blueline-dpm-open-port.service` → `node with id 0 not found` at boot (succeeds if re-run later).
   - `qcril-prov.service` → crashed on a code bug (now FIXED, see below).
5. Because `msm-modem-uim-selection` (hard dep) failed → **ModemManager never started at boot.**
   So nothing ever drove the modem: enable → set-power → register. It just sits OFFLINE.
6. Started MM manually (bypassing deps): it DOES reach the modem over qrtr://0, creates `modem0`,
   reads the SIM ATR — then fails: **`couldn't start parent initialization: Couldn't get primary
   port`** and `couldn't load carrier config: Operation timed out`. MM can't initialize a modem
   that's OFFLINE/flapping.

## What is SOLID now (do not redo)
- On reverted-baseline 7.1.1 (`blueline` branch, mem-protect skip reverted `980c4ae1f`). Built,
  flashed `boot_a`, deployed. `verify-fixes.sh` green (13 checks; mem-protect check now asserts the
  skip is ABSENT). Android slot B / EFS / userdata untouched.
- ~~pd-mapper: in-kernel `CONFIG_QCOM_PD_MAPPER=m`, module loaded … **pd-mapper is fine — ruled
  out.**~~ **WRONG (corrected 2026-06-29).** The pmaports config sets `=m`, but the running kernel
  has `# CONFIG_QCOM_PD_MAPPER is not set` — the in-tree `arch/arm64/configs/sdm845.config` carries
  the upstream `=n` and `merge_config.sh -m` applies it *after* the pmaports config, so `=n` wins
  every build. Userspace pd-mapper is also uninstalled ⇒ **no pd-mapper of either kind runs.** Caught
  via the wifi outage (no `wlan0`; ath10k_snoc bound but probe defers with no wlan PD). The Mobian
  0171 observation stands, but "pd-mapper is fine" did not. Fixed: in-tree fragment → `=m` (commit
  pending), then rebuild+reflash. Whether this also unblocks the modem-52 is now an open re-test, not
  a closed lead.
- Infra present & correct: `rmtfs -P -s` (block EFS), `tqftpserv` (serves `/persist/rfs` →
  modem mcfg), sensor registry 177 files at `/mnt/vendor/persist/sensors/registry/registry/`,
  all mcfg carrier configs incl `mcfg_sw/generic/NA/Rogers/Commercial/CA/mcfg_sw.mbn`.
- udev tags MM correctly: `ID_MM_QCOM_SOC=1`, `ID_MM_CANDIDATE=1` on rmnet_ipa0; MM qcom-soc
  plugin loads. Transport (QMI-over-QRTR) works — MM exchanges QMI with the modem.

## FIXED this session — qcril-prov.py (the MBN provisioner)
Source: `pmaports/device/testing/device-google-blueline/qcril-prov.py` (also live-deployed to
`/usr/bin/qcril-prov.py` on phone). Was crashing; now runs end-to-end and provisions Rogers.
Bugs fixed (all real, in code):
1. `list_configs` read configs from the response (`out.get_configs()` — doesn't exist;
   `MessagePdcListConfigsOutput` only has `get_result`). The config list arrives via the
   **`list-configs` INDICATION** → `IndicationPdcListConfigsOutput.get_configs()`; each element has
   `.id` + `.config_type` only. Reworked to indication-driven (mirrors the working `load-config`).
2. GI array-length args: `set_id(cfg_id, len)` → `set_id(cfg_id)`; `set_type_with_id_v2(t,id,len)`
   → `set_type_with_id_v2(t,id)`. (`set_config_chunk` was already correct.)
3. Strategy: blueline INHERITS Android's full mcfg set (1 platform + 25 software) on shared
   persist. Don't delete+reload (delete is a no-op; reload → error 41 "already exists"). Instead:
   compute target id = **sha1 of the .mbn file** (== the PDC config id, verified: HW sha1
   `6fe571a9…` matched the on-modem id), confirm present, **select + activate by sha1**. Treat
   load error_code=41 as success. Helpers added: `_sha1_id`, `_hex`, `_id_present`.
Result: provisioner selects+activates HW (platform) and Rogers (software) configs cleanly. The
modem still ends OFFLINE afterward (carrier config alone doesn't lift it — needs MM to drive it).

## THE PLAN (next session — ordered)
Goal: get ModemManager to fully initialize the modem and drive OFFLINE → online → registered.
Two intertwined blockers: (A) modem won't initialize while OFFLINE/flapping; (B) SLPI crash-loop.

1. **Make MM actually manage the modem (primary blocker).**
   - Why `Couldn't get primary port`? Check MM qcom-soc plugin port expectations for a pure-QRTR
     SDM845 modem; check nothing else holds the QMI client (our qcril-* one-shots, the stray
     `dbus-monitor`, manual `qmicli -p`). Try MM with everything else stopped.
   - Fix the boot ORDERING/retry so `msm-modem-uim-selection` + `blueline-dpm-open-port` +
     `qcril-prov` don't race the unready modem: add wait-for-QRTR-node / Restart=on-failure /
     proper `After=` on a "modem-qrtr-up" condition. This is how the chain stays up like Lineage
     (Lineage's RIL waits for the modem to be ready before UIM select / PDC).
   - Once MM inits: it should set-power-up and the OFFLINE→online may resolve via MM's sequence
     (it owns DMS set-operating-mode). The manual `online`=52 is because nothing did the proper
     enable sequence first.

2. **SLPI SAR crash-loop (`sar.cc:27`).** SAR = SX932x, governs RF TX-power; Casey's position is
   it gates modem RF. The SLPI sensor REGISTRY (`/persist/sensors/registry`) is NOT served to the
   SLPI — tqftpserv serves `/persist/rfs` only (sibling tree). Leads:
   - Does the SLPI read registry via tqftpserv (needs `/sensors` served too) or a different path?
     The tqftp log shows only modem mcfg requests, no `/sensors` requests → SAR may crash BEFORE
     requesting registry (early init / SX932x i2c on the SLPI bus). Investigate how LineageOS
     `sensors_ssc.c` + sensor HAL bring SAR up (registry delivery + SX932x i2c/GPIO).
   - Our `qcom_ssc_sensors.c` is a passive ABI shim; it does NOT boot or feed the SLPI. Mainline
     auto-boots the SLPI (DTS firmware-name) with no consumer → SAR talks to nobody → crash.
     LineageOS boots SLPI ON DEMAND after the sensor HAL is up.

3. **Verify on a clean boot**: fix the services so the whole chain comes up at boot (not manually),
   reboot, confirm MM auto-starts, modem → registered. One online attempt per boot still applies.

## Hard constraints (unchanged)
- pmOS = slot A; flash ONLY boot_a. NEVER touch Android slot B / EFS (modemst1/2,fsg,fsc) /
  userdata / TZ-XBL-ABL. rmtfs `-P -s`. No pmic@4/5 SPMI nodes. One `online` attempt per boot.
  sudo pw 147147. USB 172.16.42.1 (host iface enp0s20f0u6 → `ip addr add 172.16.42.10/24`).
- pmOS is Alpine/ash: embedded `sh -c "...(...)..."` with parens fails — use script files via scp.