Physical CPU0 heartbeat, 2026-10-12
First execution of a program of ours on physical CPU0 (the small C908 core), while physical CPU1 runs U-Boot. Runbook: ../heartbeat-runbook.md. Driver: tools/small-core-heartbeat-session.py.
Evidence class: physical board, serial console transcript. No camera, no Linux coexistence.
Authorization. The operator chose “Yes, go” on 2026-10-12 when asked whether to release CPU0 from reset on the normal card once the payload was ready. The spare card and recovery rehearsal were already waived on 2026-09-28 (quoted in the runbook).
Payload and card
tools/test-small-core-heartbeat.shbuiltheartbeat.bin: 80 bytes, SHA-25611d675ac6a4993c5ea820603a59778993487a478d07b1e30d3e9545ae22ba133, CRC323db6c1eb(identical to ../heartbeat-host.md).- Copied over SSH to the normal card’s
/boot/small-core-heartbeat.bin(/dev/mmcblk1p1, ext4); the board’ssha256summatched. - Board before the sessions: installed system
298a2bf6…, boot94fd02a1-….
Sessions
All three ran under flock -n /tmp/k230-board.lock from the host. Each
warm-rebooted Linux, stopped autoboot, and ran the runbook’s checks:
help boot_baremetal, bdinfo, printenv mmc_boot_dev_num,
ext4load mmc 1:1 0x7000000 /small-core-heartbeat.bin, printenv fileaddr filesize, crc32 0x7000000 0x50.
The pre-release checks passed every time. boot_baremetal is present.
fileaddr=7000000, filesize=50 (80 bytes), CRC 3db6c1eb.
mmc_boot_dev_num=1. U-Boot’s relocated image, malloc area and stack lie at
0x3fb35920–0x3fffffff (lmb reserved region, relocaddr
0x3ff39000, sp 0x3fb36970), clear of the payload window
0x07000000–0x07004fff.
| Session | Command | Result |
|---|---|---|
| dry run | checks only, then reset | checks PASS; no release; Linux back |
| release 1 | boot_baremetal 0 0x7000000 0x5000, pages read 1.2 s apart | counters 1, 1, 2: FAIL (not strictly increasing); prompt alive; Linux back |
| release 2 | same, pages read 5 s apart | counters 2, 4, 6: PASS; prompt alive; Linux back |
Release 2’s first page also reads mhartid=0x0 and
misa=0x800000000094112f. These are written by the payload itself on the
released core, and they match the CPU0 identity measured from CPU0 SPL in
../cpu0-identity-physical-trial.md.
Why release 1 failed. The counter advances about once every 2.5 s (release 2: 2, 4, 6 at roughly 5 s spacing). The payload’s ~8M-iteration delay loop is far slower than the cached-core estimate. That is consistent with CPU0 running from reset with caches off (instruction fetch from DRAM), but cache state on CPU0 is not measured here. Readings 1.2 s apart can repeat. The runbook only requires “at least one second apart”, so release 2 used 5 s. Release 1 stays recorded as a failure of its own run.
Restored Linux (SSH, 2026-10-12T20:07:46Z, after release 2’s reset):
possible=0, present=0, online=0, nproc 1, system
298a2bf6…, and shell, shell-ui and theme-helper active.
Limits
- Proves physical CPU0 execution while CPU1 sits at the U-Boot prompt. It says nothing about CPU0 running while Linux runs. That is the coexistence stage, which needs reserved memory and a Linux-side start.
- Each output page was read once, per the runbook’s cache caution. No cross-core coherency claim is made.
- CPU0 was stopped by the board
reset; no stop path was exercised. /boot/small-core-heartbeat.binwas left on the card (80 bytes) for the next stage.- Raw transcripts, including the console’s IP address line, stay in the private run directory.