evidence · 5.7 KiB

mainline-restart-source-audit-2026-10-02.md

Committed at docs/evidence/mainline-display/physical-2026-10-01/mainline-restart-source-audit-2026-10-02.md. This is what grounds the requirements that cite it.

Open raw source

Mainline restart-path source audit

This is a read-only source audit of the reset path relevant to the physical minimal-initrd run recorded in minimal-probe-2026-10-02/README.md. It separates that run’s observed systemctl refusal from what the pinned kernel sources imply would happen if a later request reached the kernel restart path.

The run used controller source d209a062f6826877173a7d2669d99b18c82c6416 and the candidate bundle /nix/store/gf3aqks2dg0z3ksz33ysfprnlbk83vw3-k230-mainline-drm-trial-boot-files. Its Image-mainline-drm SHA-256 is befebfd67ea9aa829ace3bfd97d12ced42068ab412b9789221d90028a1328426; it matches /nix/store/i77i3ppi72k9hw0v2xmnhilc3q7rvv50-linux-riscv64-unknown-linux-gnu-7.3.0-rc5/Image. The kernel source pin is Linux commit 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e from nix/kernel-mainline-src.nix. The matching kernel build configuration is available in the dev output of the same linux-riscv64-unknown-linux-gnu-7.3.0-rc5.drv as lib/modules/7.3.0-rc5/build/.config.

The physical run established receipt in the initrd shell, /bin/true returning zero, and /proc/uptime failing because /proc was absent. /bin/reboot -ff then printed the systemd chroot refusal and returned to the shell; it did not issue a kernel reboot request. Normal-login recovery timed out and the observation was pending-physical-reset when the controller stopped. A later operator power cycle and protected postflight verified normal-system recovery. This is not a physical test of the candidate kernel’s reset behavior.

The exact 7.3-rc5 boot logs report SBI specification 2.0 and detect TIME, IPI, RFENCE, DBCN, and HSM, but do not report SBI SRST extension detected (serial-boot.txt, serial-diagnostic-boot.txt). In the pinned kernel source at arch/riscv/kernel/sbi.c, SRST is probed and the SBI restart notifier registered only inside the success branch (lines 682–689). The candidate’s generated .config has CONFIG_RISCV_SBI=y, so this code is present; System.map also contains sbi_srst_reboot, which proves linkage, not that the conditional notifier was registered on this firmware. The same boot logs say UEFI is absent. Without a different restart handler, arch/riscv/kernel/reset.c::machine_restart() calls do_kernel_restart() and then loops forever.

The candidate trial reused the protected normal stage-one wrapper, whose manifest SHA-256 is 9627edbeea9b115d7040beea27cc61b23b6aca61cd502fd7760d7ee179f42c99. nix/opensbi-k230.nix pins OpenSBI v1.4 with the Canaan overlay and builds PLATFORM=generic; the exact board boot log reports implementation ID 1, version 0x10004 (OpenSBI 1.4). This identifies the loaded stage-one artifact and observed SBI response; it does not claim what an unadvertised firmware extension might do if called directly.

The generated .config has CONFIG_RESET_K230=y, CONFIG_POWER_RESET=y, CONFIG_POWER_RESET_GPIO_RESTART=y, CONFIG_POWER_RESET_SYSCON=y, CONFIG_POWER_RESET_SPACEMIT_P1=y, and CONFIG_WATCHDOG=y. The generic GPIO/syscon reset drivers need matching device-tree nodes to register hardware handlers. The mainline board DTS (k230-tdisplay-mainline.dts) and included k230.dtsi contain no gpio-restart, syscon-reboot, or watchdog node; the spacemit,p1 handler is for a different platform. The K230 node is a normal canaan,k230-rst reset controller. Mainline’s drivers/reset/reset-k230.c provides reset-control assert/deassert/reset operations but has no restart registration. CONFIG_RESET_K230=y therefore does not provide a system restart handler.

This differs from the pinned vendor kernel’s drivers/reset/reset-k230.c: its probe calls k230_restart_register(), which registers a K230 restart notifier before registering the peripheral reset controller. The archived normal-system serial evidence shows the vendor kernel’s restart path reaching U-Boot SPL after reboot: Restarting system (serial-boot.txt). That is evidence for the vendor kernel path, not for mainline.

Source prediction, not board proof: after /proc is mounted and the systemd chroot guard is cleared, the current mainline image may emit its restart message and remain in the RISC-V restart loop because this boot did not detect SBI SRST and the mainline DT/reset driver provides no replacement handler. The reboot marker observed before systemd’s refusal cannot establish that the kernel can reset. This risk does not explain the prior systemd initrd’s missing login and must not be presented as its cause.

The next kernel-side requirement is a documented system restart mechanism for this board: either make OpenSBI expose and implement SRST for the loaded K230 platform, or forward-port a reviewed K230 restart handler alongside the mainline reset driver. Do not write the reset register from an ad-hoc initrd command. The controller’s /proc setup correction can be reviewed and landed independently; this audit does not authorize another board trial or claim successful mainline restart. No board, serial, build, or kernel source change was used for this audit.