Fimeg/SouveraineOS
Watch
1
0
Fork
You've already forked SouveraineOS
 0
Code Releases Activity
SouveraineOS/saf/device/evidence/modem_dt_rf_analysis_20260622.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

9 KiB
Raw Permalink Blame History

Modem DT/RF gap analysis — pmOS vs Android-downstream vs enchilada (2026-06-22)

Phase 1 of the "is the RF/DT lever still alive?" task. All comparisons are between three device trees on the SAME SoC (SDM845):

  • blueline-pmos (FAILS RF arm) — dt-work/blueline-pmos.dts, sourced from upstream sdm845-google-blueline.dts + sdm845-google-common.dtsi.
  • blueline-Android downstream (modem WORKS, Fido LTE) — dt-work/android-dtb/android-base.dts (base DTB) + dt-work/blueline-live.dts (live capture from /proc/device-tree, includes DTBO).
  • enchilada (OnePlus 6) mainline (modem WORKS on the exact same mainline kernel/pmaports stack) — dt-work/sdm845-oneplus-enchilada.dts.

Two working references on the same silicon is the strongest possible control. Where BOTH working trees agree and pmOS differs, that difference is a real, citable suspect.

VERDICT: DT IS NOT THE GATE

The modem DT is functionally identical between working Android and non-working pmOS. Every modem-relevant node (remoteproc@4080000, reserved-memory, rmtfs, power-domains, clocks, glink, SPMI/PMIC) is structurally the same. The remaining differentiator is runtime kernel driver behavior, not the device tree.

RANKED CANDIDATES

#1 (LIVE — Android applies the 32MB offset map; pmOS must carry it too) — Modem reserved-memory map

The subagent's top candidate claimed pmOS uses a non-standard MPSS size (0x9800000) and MBA address (0x98500000) while Android uses the standard map (0x7800000 / 0x96500000). This is wrong.

The subagent compared pmOS against android-base.dts (the raw base DTB) and enchilada.dts (standard map). But it failed to account for the DTBO overlay (dtbo_idx=8) that the bootloader applies at boot. The DTBO transforms the base standard map into the Pixel 3 override on the live Android device. The live captured DTS (blueline-live.dts, from /proc/device-tree) proves this:

Region Android base DTB Android LIVE (with DTBO) pmOS enchilada
MPSS 0x8e000000 sz 0x7800000 0x8e000000 sz 0x9800000 0x8e000000 sz 0x9800000 0x8e000000 sz 0x7800000
MBA 0x96500000 0x98500000 0x98500000 0x96500000
venus 0x95800000 0x97800000 0x97800000 0x95800000
cdsp 0x95d00000 0x97d00000 0x97d00000 0x95d00000

Live Android and pmOS use the IDENTICAL Pixel 3 override map. The modem works on Android with this map. Therefore the memory map cannot be the gate. (The override comes from sdm845-google-common.dtsi:17-77 which /delete-node/s the standard regions and redefines them. pmOS includes this via the mainline DTS chain; Android gets it via the DTBO overlay.)

Citations:

  • Base DTB: android-dtb/android-base.dts:19146 (reg 0x7800000), :19167 (mba@96500000)
  • Live Android: blueline-live.dts:931 (reg 0x9800000), :949 (mba@98500000)
  • pmOS: blueline-pmos.dts:906 (reg 0x9800000), :924 (mba@98500000)
  • enchilada: sdm845-oneplus-enchilada.dts:884 (reg 0x7800000), :902 (mba@96500000)
  • DTBO source: references/sdm845-linux-20260610-ONHOLD-DAVID-TREE/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi:17-77

#2 (REFUTED twice) — pm8998 LDOs absent from pmOS rpmh-regulators

dt-work/regulator-diff-android-vs-pmos.txt: Android defines ldo4/6/8/9/10/11/15/16/18/23/27 that pmOS omits. Already refuted twice (modem.md #9/#10): (a) enchilada's WORKING modem does NOT declare these RF LDOs either — same minimal mainline rpmh-regulators set as pmOS; (b) all 11 show use=0 from the AP on live working Android (rf-rail-diff-FINAL.txt) — the modem votes its RF rails via RPMh directly, not the AP regulator framework. Since enchilada arms RF without them, they are not the gate. Do NOT add the LDOs / do NOT flash blueline-live.dtb.

#3 (eliminated) — RFFE / SPMI bus / RF-frontend regulator nodes

No RFFE node and no WTR/QFE/PA/FEM/GRFC regulator node exists in ANY of the three trees, including both working ones. RF front-end power/control is modem-firmware-driven over RFFE/GRFC, not an AP DT resource. Dead.

#4 (eliminated) — modem node clocks / power-domains / smem-states / glink

remoteproc@4080000 is structurally identical across all three trees: same qcom,sdm845-mss-pil, same clocks, same power-domains, same glink-edge. Only firmware-name path and phandles differ. rmtfs carveout structurally identical. Dead.

#5 (eliminated) — DTBO overlay modem content

The DTBO (dtbo_a.img.dtb8, 112 fixups) touches display, audio, camera, charger, thermal, GPIO, touchscreen, NFC, UFS, PCIe, debug/ramoops. Zero modem/remoteproc/rmtfs/glink fragments. modemsmem node is a no-op placeholder (compatible only, no properties). The DTBO's only modem-relevant effect is transforming the memory map from standard to Pixel 3 override (fragment@45 for MPSS, fragment@48 for MBA) — which pmOS already has natively. Dead.

#6 (eliminated) — CDT / bootargs / hardware identifiers

Android has a chosen/cdt/cdb2 node (IMEI, MEID, BT/WLAN MACs, SKU, PCB config, eSIM) and androidboot.* bootargs that pmOS lacks. These are AP-side identifiers — the modem gets IMEI from EFS, not DT. Mainline kernel parses none of the androidboot.* params. Dead.

#2 (WEAK / for-the-record) — pm8998 LDOs absent from pmOS rpmh-regulators

dt-work/regulator-diff-android-vs-pmos.txt: Android defines ldo4/6/8/9/10/11/15/16/18/23/27 that pmOS omits. Already refuted twice (modem.md #9/#10): (a) enchilada's WORKING modem does NOT declare these RF LDOs either — same minimal mainline rpmh-regulators set as pmOS; (b) all 11 show use=0 from the AP on live working Android (rf-rail-diff-FINAL.txt) — the modem votes its RF rails via RPMh directly, not the AP regulator framework. Since enchilada arms RF without them, they are not the gate. Kept here only so it is not re-chased. Do NOT add the LDOs / do NOT flash blueline-live.dtb.

#3 (eliminated) — RFFE / SPMI bus / RF-frontend regulator nodes

No RFFE node and no WTR/QFE/PA/FEM/GRFC regulator node exists in ANY of the three trees, including both working ones (rf-rail-diff-FINAL.txt, re-verified today: qcom,rffe absent everywhere; SPMI bus spmi@c440000 qcom,spmi-pmic-arb present and identical in pmOS + enchilada + Android). RF front-end power/control is modem-firmware-driven over RFFE/GRFC, not an AP DT resource. Nothing to add. Dead.

#4 (eliminated) — modem node clocks / power-domains / smem-states / glink

remoteproc@4080000 is structurally identical between blueline-pmos and enchilada: same qcom,sdm845-mss-pil, same clock-names (iface/bus/mem/gpll0_mss/snoc_axi/mnoc_axi/prng/xo), same power-domains (cx/mx/mss), same qcom,smem-states "stop", same glink-edge label "modem" remote-pid 1 (dt-work/modem-blueline.txt vs enchilada :3647). Only firmware-name path and phandles differ (correct). rmtfs carveout structurally identical (size 0x202000, vmid 0x0f, client-id 1, guard-pages); base differs (0xf2700000 vs enchilada 0xf5b00000) which is normal per-device placement and already proven to serve EFS fine on pmOS (modem_community_research_20260622.md live result #1). Dead.

Runtime time-injection angle (secondary lead from the task)

Checked: pmOS does NOT run a modem time daemon. The qrtr "Time" service (TS, svc 64) sync that Android's RIL feeds is not provided by ModemManager. However this is downstream of the 52 wall — the modem refuses the dms-set-operating-mode=online write itself instantly (modem_community_research_20260622.md result #4: clean Alloc CID -> Set Op Mode -> FAILURE 52, immediate), before any time-dependent NAS attach logic runs. Time injection gates attach, not the op-mode flip. Only worth chasing if the 52 gate is cleared and the modem then fails to attach.

VERDICT (Phase 1) — CORRECTED

The DT is not the gate. Every modem-relevant node is byte-identical between working Android and non-working pmOS. The subagent's #1 candidate (memory map difference) was refuted by accounting for the DTBO overlay: live Android and pmOS use the identical Pixel 3 override map.

The remaining differentiator is runtime: the mainline kernel's remoteproc/PIL driver, firmware load sequence, power-domain sequencing, QMP link bring-up, or glink/mailbox initialization differs from the downstream Android kernel. The modem firmware is identical (same files, same EFS, same shared partition). The DT is identical. The kernel and its drivers are what's different.

Next steps (kernel/driver level, not DT)

  1. Compare remoteproc driver behavior: dmesg on Android vs pmOS during modem boot — look for differences in power-domain enable order, QMP link state, firmware load timing.
  2. Check if mainline qcom_q6v5_pas driver handles the MSS PIL differently from the downstream driver — e.g., missing a handover step, wrong power-domain sequence, or not waiting for a firmware-ready signal.
  3. diag_mdlog F3 trace on Android: capture the modem's own RF-init narration to see exactly where it succeeds on Android — this is the one instrument that can name the gate directly.