# Physical CPU0 heartbeat: host preparation only

Prepared 2026-09-26 America/Chicago; no board release was run for this file.
The working tree was `impl/small-core-heartbeat-20260926` at base
`ba23c967`. `bash tools/test-small-core-heartbeat.sh` passed on the host. With
`SMALL_CORE_OUTPUT_DIR=/tmp/k230-small-core-heartbeat-host`, the generated
80-byte `heartbeat.bin` had SHA-256
`11d675ac6a4993c5ea820603a59778993487a478d07b1e30d3e9545ae22ba133`.
The temporary output is a host artifact, not a committed firmware image.

## Source-backed physical path

The pinned `k230_linux_sdk` revision is
`1104236db4d1e47873bd68924f912747b820228c` (`nix/k230-sdk-src.nix`).
`nix/uboot-k230.nix` copies that U-Boot overlay and uses
`k230_canmv_v3_defconfig`. In its `board/canaan/common/sdk_autoconf.h:16`,
`CONFIG_LINUX_RUN_CORE_ID` is 1. `k230_spl.c:150` loads U-Boot;
`k230_img.c:276-285` releases physical CPU1 into that U-Boot image and parks
physical CPU0 in `wfi`. Thus the normal U-Boot prompt is on physical CPU1,
supported by source and the later RVV/256 KiB L2 Linux observation.

The same overlay's `arch/riscv/cpu/k230/cpu.c:125-166` defines
`boot_baremetal 0`, which writes physical CPU0's vector at `0x91102100`,
asserts/deasserts `CPU0_RST_CTL` at `0x91101004`, and flushes the specified
image range. The built U-Boot ELF in
`/nix/store/zzz867rp8drrwkhibj0rlqc04sk9g7f8-uboot-k230_canmv_v3_defconfig-riscv64-unknown-linux-gnu-2022.10`
contains that command (`nm` and a string search). The vendor default
environment and this project's `firmware/stage1/tdisplay.env:29` load a
physical CPU0 bare-metal image at `0x07000000` before that command. This
grounds the scratch load address, not a claim that the new payload has run.

The 80-byte program loads at `0x07000000`. It writes CPU0's read-only
`mhartid` and `misa` CSRs at `0x07002008` and `0x07002010`, and emits the same
monotonic 64-bit counter at `0x07002000`, `0x07003000`, and `0x07004000`.
Those three output pages lie within the vendor's CPU0 bare-metal scratch
range and outside the actual 80-byte file. The program issues `fence rw,rw`
and Canaan U-Boot's documented `l2cache.ciall` encoding (`cache.c:158-161`,
`0x0170000b`) after each update. Each output page is read **once** from the
CPU1 U-Boot prompt, separated in time, to avoid relying on a second read of
a line CPU1 may retain in its own cache. This is a bounded diagnostic
protocol, not a demonstrated CPU-to-CPU coherency contract.

`llvm-objdump` and `readelf` confirmed entry `0x07000000`, the output symbol
at `0x07002000`, scalar RV64 ELF attributes without V, CSR reads, the three
stores, and the L2 maintenance word. The host check proves only layout and
instruction selection. It does not prove that CPU0 starts, that its L2 flush
publishes to CPU1, or that the board's U-Boot reads those pages freshly.

The live Linux memory snapshot collected by the coordinator at
`2026-09-27T03:34:24Z` (`/tmp/k230-core-memory-result.txt`) describes 1 GiB
at `0x00000000..0x3fffffff`, with `0x10000000..0x103fffff` reserved for the
framebuffer and no second-core reservation. It does not reserve these probe
pages for Linux; this first test stays at the U-Boot prompt and ends in a
reset. A Linux-coexistence candidate must use a separate DT reservation and
read-only observer before it can boot.

`python3 -m unittest discover -s tests -p test_ums_target.py` passed 16 host
tests. It proves the UMS helper's refusal guards, not that a disposable card
or a recovery rehearsal was available during this preparation.