Phase 3: the CDSP boots from stock firmware (2026-11-03)

Attempt 2026-11-03-7. Image 72eebf1b6e678b3f, kernel #6 (2026-11-03 2:23 PM ET, unchanged), commit 19128c0. Sources: the netlog dumps/firstboot/2026-11-03-netlog.txt and the AP console log dumps/firstboot/2026-11-03-ap.log (both gitignored).

Why

Every boot up to attempt -6 logged remoteproc remoteproc1: Direct firmware load for qcom/x1e80100/google/mica/cdsp.mdt failed with error -2 at about 0.57 s, and /init reported cdsp offline. The DTS already named the stock files (remoteproc_cdsp firmware-name, dts/x1e80100-google-mica.dts), mica-el2.fixups already dropped its iommus (as for the ADSP), and QCOM_Q6V5_PAS=y. Only the firmware was missing from the initramfs.

Changes (commit 19128c0)

• scripts/stage-firmware.sh: stock_mdt adds cdsp cdsp_dtb, read from the same stock modem_a /image/ (recovery-stick copy) as the ADSP. 16 cdsp files and 4 cdsp_dtb files.
  • No cdsp.b14 exists in /image/. The boot shows the loader does not need it.
  • kernel/firmware.sha256: 20 new hashes, no changed ones (90 files in total).
• /init: reports every remoteproc again at the end (rproc-late: state, recovery), so a DSP that crashes after the early capture shows up.
• No kernel, DTS or command-line change.

Result: pass

• CDSP up: Booting fw image qcom/x1e80100/google/mica/cdsp.mdt at 1.876 s, remote processor cdsp is now up at 1.995 s.
• Still running at the end: rproc-late=remoteproc1 cdsp running recovery=enabled (and remoteproc0 adsp running), after about 130 s, with no crash or recovery lines in the log.
• Everything else unchanged: Type-C, PCIe, Wi-Fi (6 GHz, DHCP), eDP at 2560x1600, GPU firmware and GMU loaded, netlog sent (1350 lines). reboot: Restarting system at 189.5 s (about 4:00 PM ET).
• Deferred at the end: only arm-scmi (mailbox 17430000).

Side effect: the ADSP starts 5 s later

• In attempt -6 the ADSP was up at 0.931 s. Here: powering up adsp at 1.873 s, then qcom_q6v5_pas 32300000.remoteproc: timeout waiting for subsystem event response at 7.408 s, and remote processor adsp is now up at 7.410 s.
• Cause, from the source at a804c57: when a remoteproc starts, sysmon_start() sends each already-running peer a “powered up” event (drivers/remoteproc/qcom_sysmon.c:496-530). For SSCTL v2 peers, ssctl_send_event() waits up to 5 s for the reply (qmi_txn_wait(&txn, 5 * HZ), :405) and logs this exact message on timeout (:407). The message names 32300000.remoteproc, the CDSP, so the ADSP’s start waited on the CDSP, which never answered.
• Not known: why the stock CDSP firmware does not answer the SSCTL event. It costs one 5 s delay per boot (Type-C, battery and USB SuperSpeed come up later), with no lasting effect seen.
• New in this boot, inference: the later ADSP start shifts probe order, so pmic-glink now also logs Failed to create device link (0x180) for a600000.usb (connector@0) and a800000.usb (connector@1). These are the same sync-state-only links as in dp-2026-11-03.md, “The device-link warning”.

Update 2026-11-03: the SSCTL timeout is not mica-specific

Read the same afternoon, no boot:

• Which side waits: the message carries sysmon->dev, the remoteproc’s parent device (qcom_sysmon.c:635), so 32300000.remoteproc is the CDSP’s sysmon. The ADSP’s sysmon_start() runs the sysmon_notifiers chain (:509); the CDSP’s sysmon_notify() (:585-605) sees ssctl_version == 2 and sends the event to the CDSP. ssctl_version is set only when a matching SSCTL server appears (:425-440, instance 0x17 from x1e80100_cdsp_resource, qcom_q6v5_pas.c:1282). So the CDSP’s SSCTL service is registered and does not answer.
• Another X1 laptop shows the same line. A Dell Latitude 5455 (x1p64100) on the Ubuntu Concept kernel logs qcom_q6v5_pas 32300000.remoteproc: timeout waiting for subsystem event response at boot, next to the same pmic-glink … Failed to create device link (0x180) lines (Ubuntu Discourse, “Ubuntu Concept ♥️ Snapdragon X Elite”, page 99, post #2008, 2026-07-09). Its CDSP firmware is Dell’s Windows set, not mica’s stock files. No reply there explains or fixes it.
• No upstream fix found: a web search for the exact message (2026-11-03) found the driver source, an SDM845 modem report and the Dell post, but no patch for x1e80100.
• Inference: the X1 CDSP firmware does not answer SSCTL subsystem events, whoever built it. The cost is the one 5 s wait in whichever remoteproc starts after the CDSP; nothing else depends on it.

Decision: no change on mica. A kernel fix (skip the event for a peer that never answers, or a shorter timeout) belongs upstream in qcom_sysmon.c and needs evidence from more than two machines.

Next

• FastRPC (QCOM_FASTRPC=m, so not loaded): needed before anything can use the CDSP.