CPU0 carveout and read-only remoteproc skeleton (tasks 4.1-4.3)

Evidence class: host device-tree build and cross kernel build, 2026-10-12. No board. Nothing here has booted; task 5.1 is the first board use.

4.1 Carveout and node (DT build proof)

nix/dts/k230-tdisplay-mainline-cpu0-rproc.dtsi, included only by the opt-in nix/dts/k230-tdisplay-mainline-drm-hotplug-cpu0.dts (.#deviceTreeMainlineDrmHotplugCpu0). The daily tree is untouched: deviceTreeMainlineDrmHotplug and mainlineDrmHotplugDeviceTreeNormalName evaluate to the same derivations as master a486398a (2nf5ryig…-k230-tdisplay-mainline-drm-hotplug.dtb.drv, k5939fzs…-k230-mainline-drm-hotplug-dtb-normal-name.drv), as does the daily system toplevel (lhdphdj8…-nixos-system-…drv). nix/device-tree-mainline-drm.nix gained extraIncludes (empty default, byte-identical script) so the variant can include the hotplug dts.

Decompiled k230-tdisplay-mainline-drm-hotplug-cpu0.dtb (fdtget):

The carveout covers the window the heartbeat and echo payloads already ran in (image at +0, slot page at +0x2000), which Linux could otherwise allocate. 0x07000000 holds only U-Boot’s bootargs.txt before bootm.

Limit: deviation from the task text, which names nix build .#deviceTree (the vendor tree); the decision note moved this work to the mainline tree the board runs.

4.2 Driver skeleton (cross-build proof)

nix/patches/mainline/k230_cpu0_rproc.c, built in-tree by nix/kernel-mainline-drm-rproc.nix (.#kernelMainlineDrmRproc): the daily DRM kernel plus CONFIG_REMOTEPROC=y and CONFIG_K230_CPU0_REMOTEPROC=m. The daily kernel is not changed.

What it does at probe: refuses any resets other than a single <&rst RST_CPU0>; devm_reset_control_get_exclusive(); one read-only reset_control_status() (reset-k230.c registers no .status, so an error code is expected and reported); maps the vector register with devm_platform_ioremap_resource() and the carveout with devm_memremap(WC); registers a remoteproc with auto_boot = false and sysfs_read_only = true. .start/.stop return -EOPNOTSUPP. A cpu0_status attribute reports the vector register, the reset status code, the carveout and the slot-page magic. It contains no writel, no reset_control_reset/assert/deassert.

Proofs:

• scripts/checkpatch.pl --no-tree --strict -f: 0 errors, 0 warnings, 0 checks.
• Early out-of-tree compile against the daily kernel’s headers (gcc 15.3.0, the kernel’s own compiler): compiles with no warnings; modpost lists only devm_rproc_alloc/devm_rproc_add undefined, because the daily kernel has no CONFIG_REMOTEPROC. That is why the in-tree variant exists.
• In-tree build, nix build .#kernelMainlineDrmRproc (2026-10-12, under the build lock, --max-jobs 1 --cores 4): exit 0, kernel /nix/store/qawjbc553pihf38izgf5v0qmwb4h3sgl-linux-riscv64-unknown-linux-gnu-7.3.0-rc5; CC [M] drivers/remoteproc/k230_cpu0_rproc.o with no compiler warning, no modpost warning. Its .config has CONFIG_REMOTEPROC=y and CONFIG_K230_CPU0_REMOTEPROC=m.
• Module …-7.3.0-rc5-modules/lib/modules/7.3.0-rc5/kernel/drivers/remoteproc/k230_cpu0_rproc.ko.xz (SHA-256 19a6ff34bb073b442f3bef125ee388edeec6d952460d586f9b0dc5b0ab1feda8): modinfo vermagic 7.3.0-rc5 SMP preempt mod_unload riscv, alias of:N*T*Ccanaan,k230-cpu0-rproc. Its only reset-API imports (nm -u) are __devm_reset_control_get and reset_control_status: no reset_control_reset, _assert or _deassert is linked, so the module cannot pulse CPU0. The source has no writel.

4.3 Why no mailbox yet

Stated in the driver’s header comment: the TRM’s mailbox map (section 2.9) lacks the interrupt-group wiring, lock semantics and CPU0 routing (docs/research/second-core-feasibility.md, UNVERIFIED), so the transport stays the polled slot page until a firmware speaks virtio/rpmsg; then a poll-mode (txdone_poll) mailbox controller attaches through .kick (design.md Decisions 1 and 5), replaceable by the hardware mailbox later.

Successor

Task 5.1 extended this driver to load and start CPU0; its board run and the new module hash are in linux-start-2026-10-12/README.md. The module hash above is the read-only skeleton’s.