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

7.4 KiB
Raw Permalink Blame History

QCRIL modem bring-up — CAPTURED exact sequence (recreate this on pmOS)

This is the captured, ordered sequence QCRIL runs to bring the modem online on the working blueline Android. The standing goal (Casey): recreate this exactly on pmOS — approximating has been the failure. Do NOT re-capture this; analyze the saved files below.

Capture files (in repo, android-capture-20260620/)

  • qcril-ssr-fullinit.txt — the primary capture. Modem SSR (echo restart > /sys/kernel/debug/msm_subsys/modem) with verbose radio logging → QCRIL re-runs its FULL bring-up → modem ONLINE. 66k lines, ts 21:07:04–21:07:35.
  • qcril-ssr-TIMELINE.txt — distilled ordered timeline (section A: QMI sends per endpoint; section B: per-module handling order).
  • qcril-online-capture.txt — airplane off→on (the LPM→online flip in isolation).
  • android-radio-log.txt — steady-state runtime reference (attached, Fido LTE).

SIM identity (for replay)

ICCID <redacted>, IMSI <redacted>, MCC/MNC 302/370 (Fido), carrierId 1962, GW app1 AID A0000000871002F310FFFF89B00140FF, slot 1.

The exact ordered sequence (SSR → ONLINE), with evidence

  1. Modem SHUTTING_DOWN → re-init. qcril_qmi_nas_log_radio_power_process_state: telephony ONLINE | ril NONE | card UP | modem SHUTTING_DOWN.
  2. Endpoint-status indications fire for EVERY service as it re-registers (qcril-ssr-fullinit lines ~252–1325): IMSS, IMSA, PDC (→ MbnModule), SMS, NAS, PBM, DMS (→ DmsModule AND MbnModule), UIM (uim.card_status_update slot 0), VS, Voice, WDS, Auth. QCRIL drives each service's endpoint, not just DMS.
  3. MbnModule re-syncs PDC — VERIFY ONLY, no load/select/activate. PDC_ENDPOINT_STATUS_IND and DMS_ENDPOINT_STATUS_IND both forwarded to MbnModule; no load_config/select_config/ activate_config/enable_auto_selection anywhere in the SSR window. MCFG persisted in modem NV across the SSR (consistent with frontier #4). → On pmOS we must get MCFG in modem NV ONCE; it then persists.
  4. UIM provisioning is NOT re-run on SSR (no change_provisioning_session in the capture) — it persisted. → On pmOS, primary-GW provisioning must be established once and stick.
  5. NAS config burst (the "QCRIL does more" set), then power. QCRIL calls, in the bring-up window: qcril_qmi_nas_init, request_set_preferred_network_type (tells the modem which RATs to acquire), request_radio_tech, set_reported_voice_radio_tech, request_set_unsol_response_filter, configure_sig_info, set_lpm_after_ssr_in_apm, set_bootup_power_optimization_state, request_power. ModemManager issues only a small subset of these.
  6. DMS operating-mode flip: LPM → ONLINE. qcril_qmi_nas_dms_handle_modem_operating_mode: modem's operating mode needs to be changed → ril SETTING_OP_MODE → modem ONLINE (~270 ms after SSR; line ~15967). post: set_bootup_power_optimization_state=2, ATEL UI-READY, enable networking/sys-info indications → is_online 1 → forces NW search.

The decisive state difference (Android vs pmOS)

  • Android: the modem is held in LPM (low_power, powered, RF parked); QCRIL flips LPM→online.
  • pmOS: the modem sits in offline (deeper) and offline→online is what returns DeviceNotReady / no-ops. Plus pmOS boots with 0 PDC configs (autoselect not active that boot) and provisioning failing on the early-boot race.

Recreate-exactly plan for pmOS (the test we have NEVER fully run)

On one clean slot-B boot, in order, all three prereqs together:

  1. Get MCFG into modem NV (PDC autoselect / load+select+activate) → configs ACTIVE.
  2. Establish primary-GW provisioning cleanly (run AFTER the QRTR race; it succeeds manually: --uim-change-provisioning-session=slot=1,activate=yes,session-type=primary-gw-provisioning,aid= A0000000871002F310FFFF89B00140FF).
  3. Set the NAS preferred-network-type / radio-tech (QCRIL step 5) — replicate via libqmi NAS.
  4. Bring the modem up through LPM (set --dms-set-operating-mode=low_power if it's in offline) THEN =online. Do NOT flip offline→online directly.
  5. Verify --dms-get-capabilities Networks non-empty + NAS serving system registers.

Replay vehicle: the openimsd libqmi fork (Set Feature for autoselect) + libqmi NAS/DMS/UIM via python-GI. The point is the ORDER and the LPM state, captured above — not a partial subset.

2026-06-21 LIVE — clean provisioning + configs is NOT sufficient (eliminated)

Fresh slot-B boot, modem running (remoteproc2 up, no fatal in dmesg, zero modem rail failure). State: mode=offline, configs PRESENT (sw 0x8013303 + platform loaded), USIM app=ready.

  • msm-modem-uim-selection FAILED at boot (early-QRTR race: "Application was already selected" then Transaction timed out) — the #7 symptom.
  • Replicated the service BY HAND post-boot: deactivate timed out, but ACTIVATE returned "Successfully changed provisioning session" => primary-gw provisioning now cleanly active.
  • Immediately retried: low_power => InvalidTransition(60); online => DeviceNotReady(52). Mode stayed offline. Networks '', Max TX 0. CONCLUSION: configs-active + clean-primary-gw-provisioning + USIM-ready + healthy rails is NOT enough to arm RF. The modem is wedged in offline (RF subsystem not-ready) and refuses BOTH offline->low_power and offline->online. PAF #7's "clean provisioning -> online stops returning 52" did NOT reproduce. The remaining differentiator is QCRIL's boot-time QMI/NAS choreography (#8: radio-power state machine + UI-ready/poweron_opt) that brings the modem to LPM. Android boots the modem INTO low_power; pmOS boots it into the deeper offline. NEXT: capture how QCRIL puts/keeps the modem in LPM on rooted Android, replay on pmOS.

2026-06-21 REFRAME — Android modem SELF-ONLINES (mode 0); there is no QCRIL online handshake

Mined existing captures (android-live-20260619/deep/radio-boot.txt, android-capture-20260620/ qcril-ssr-fullinit.txt). The op-mode VALUE settles the "LPM" confusion:

  • radio-boot.txt:3694 qcril_qmi_nas_dms_get_current_power_state: ".. known modem operating mode 0" (DMS op-mode 0 = ONLINE).
  • radio-boot.txt:3949 "telephony LPM | ril NONE | card UP | modem ONLINE" => the "LPM" is the AP/telephony airplane-state layer; the MODEM is ONLINE.
  • radio-boot.txt:3862 qcril_qmi_nas_telephony_ready: "poweron_opt: 'UI ready' NOT sent to modem" (skipped BECAUSE modem already online).
  • ssr-fullinit: QCRIL only POLLS op-mode ("Operating mode is not available, polling...") and sets bootup_power_optimization_state=2. It never issues DMS Set Operating Mode = online.

CONCLUSION (corrects #8's "Android boots modem into LPM"): on Android the modem firmware SELF-COMPLETES RF-init and SELF-TRANSITIONS to ONLINE (mode 0) with NO online command from QCRIL. The Android "LPM" is the RIL/airplane layer, not the modem. Therefore replaying a "QCRIL online handshake" on pmOS is a dead end -- there isn't one.

The pmOS gate, precisely: the modem firmware's own RF-init does NOT complete on pmOS, so it parks in OFFLINE (mode 3) and returns DeviceNotReady(52) when we ASK it to online (Android never has to ask). Everything AP-side is equal/eliminated. The remaining differentiator is what the modem reads/does at its OWN firmware RF-init -- strongest lead = modem-side EFS NV state (Route B: /nv/item_files/.../power-up operating mode and/or mcfg_autoselect_by_uim), i.e. something the Android modem persisted that makes RF-init succeed and self-online.