CPU0 started from Linux through remoteproc, 2026-10-12

Coprocessor task 5.1: a fully booted Linux (mainline 7.3.0-rc5 on CPU1, the shell compositor running) loads the echo payload into the CPU0 carveout, writes the CPU0 boot vector and pulses RST_CPU0 through the standard remoteproc state file, then exchanges requests with CPU0 through the shared slot page.

Evidence class: physical board, one serial-console session (host-stamped) plus a native grim capture of the panel’s compositor output. No camera. One run.

Authorization. The operator answered “yeah go for it” on 2026-10-12 to running task 5.1 as a one-off boot of the trial kernel and DT with the installed default unchanged. CPU0 release on the normal card was authorized earlier (“Yes, go”; see ../echo-physical-2026-10-12/README.md).

What ran

Trial files were copied over SSH to /var/lib/k230/cpu0-trial/ (hashes matched on the board). Command, under the board lock:

flock /tmp/k230-board.lock tools/cpu0-linux-start-session.py --out run-1.txt \
  --stage /var/lib/k230/coherent-boot/kc3iyr4cnjlswa87kkpi81qgc1is6hli-20261012f \
  --bundle /nix/store/kjlnrxv8vdk92lh84w2bkd1v0mx456hy-k230-coherent-shell-boot-files \
  --image <kernel>/Image --dtb <dtb>/k230-tdisplay-mainline-drm-hotplug-cpu0.dtb --hold 45

Excerpt: run-1-serial-excerpt.txt (escape and OSC sequences removed; they carried terminal titles and systemd session identifiers). The full raw transcript stays private.

Result

U-Boot loaded all five files with matching CRC32 (Image cbfe8fd7, DTB 8ecd8d13, initrd c5a9d6cc, fw_jump 99b89787, bootargs 762be152) and booted. Linux logged OF: reserved mem: 0x0000000007000000..0x00000000070fffff (1024 KiB) nomap non-reusable cpu0-firmware@7000000.

Before the start (Linux uptime ~207 s, systemctl is-system-running → running, shell and seatd active, swaymsg -t get_version answered):

• insmod → 0; remoteproc0 named k230-cpu0, state offline.
• cpu0_status: boot_vector 0x91200000 (value left by reset and stage 1; not ours), reset_status -524 (-ENOTSUPP: reset-k230 has no .status, as the skeleton predicted), carveout [mem 0x07000000-0x070fffff], slot_magic 0x00000000.
• Pre-start request 0x5a5a5a5a → No such device. That is the driver’s magic check refusing to post, not a measurement of CPU0; it shows the slot page held no echo magic before the start.

Start (echo start > state, kernel 208.058 s):

remoteproc remoteproc0: powering up k230-cpu0
remoteproc remoteproc0: Booting fw image small-core-echo.bin, size 224
remoteproc remoteproc0: CPU0 released at 0x07000000
remoteproc remoteproc0: remote processor k230-cpu0 is now up

start_rc=0, state running, boot_vector 0x07000000, slot_magic 0x4f484345 (echo payload), served 0 — the magic was zeroed by .load, so CPU0 wrote it in this boot.

Echo requests, each a different value, answered by CPU0:

Then 1000 more requests (values 0–999) in a shell loop: ECHO_BULK ok=1000 of 1000, last seq 1008 value 0x000003e7 rsp 0x000003e8 inv 0xfffffc18 served 1008 OK. Every answer is checked in the driver (rsp == value+1, inv == ~value, rsp_seq == seq); a mismatch or a 100 ms timeout fails the write. Latency is from the req_seq store to the poll that saw rsp_seq, and includes the poll’s usleep_range(10, 50), so it is an upper bound at that granularity.

After the start (immediately, and again after a 45 s hold):

• remoteproc state running; systemctl is-system-running → running; shell and seatd active; swaymsg -t get_version answered (sway 1.12).
• grim capture of the compositor output succeeded (grim_rc=0): cpu0-start.png, SHA-256 a6a8591d874042351b5785b57b87277c1af63eeb007045ebb220960a896a03e8; it shows the shell’s terminal prompt on the panel’s 568×1232 output.
• Requests seq 1009 and seq 1010 (0xa5a5a5a5 → 0xa5a5a5a6/0x5a5a5a5a) answered, served 1009/1010.
• dmesg --level=err,warn holds only boot-time lines (dummy regulators, DRM plane blend notice, a BTF mismatch note for modules, the 8189fs taint); nothing after the module load or the start.

Then reboot. The board returned to the installed default: over SSH, /run/booted-system is kc3iyr4c…, /sys/class/remoteproc does not exist, the DT has no remoteproc node, shell active.

Notes and limits

• Linux side, no cache maintenance. The driver maps the no-map carveout with devm_memremap(..., MEMREMAP_WC); on this kernel (CONFIG_RISCV_ISA_SVPBMT=y, a non-RAM range) that goes through ioremap_wc and is expected to be an Svpbmt NC mapping. The page-table attribute itself was not inspected (UNVERIFIED); what was observed is that 1010 exchanges were correct with no Linux-side cache maintenance at all, while CPU0 runs l2cache.ciall per poll. Contrast the U-Boot run, where CPU1’s cacheable view gave 0/4 until it was evicted.
• Task wording. Task 5.1 names reset_control_deassert(). The binding decision (../mainline-reset-binding-decision.md) and the spec delta supersede that: RST_CPU0 has only .reset (a pulse), and the driver uses it. No other reset line, power register or mailbox register is written.
• Daily modules on the trial kernel. The installed system’s modules (same version string) loaded into the trial kernel; the only notice was “Kernel module BTF mismatch detected”. Not a concern for the daily boot, which never runs this kernel.
• Session tool fix after the run. The shell-readiness poll looked for \nactive, but bash’s bracketed-paste reset puts \x1b[?2004l\r before the answer, so the poll ran to its 120 s limit (100–217 s) although every answer was active. The match was changed to the line ending after run 1; nothing else in the tool changed. The measurements above were taken after that wait.
• Not shown. Stop/restart without a reboot (5.2: no held reset exists), repeated start cycles or a concurrent workload (5.3), interrupts or the hardware mailbox, a camera view of the panel during the run, and touch interaction with the shell. “Shell responsive” here means the serial root shell answered every command, systemd reported running, the compositor answered IPC and produced a frame for grim.