evidence · 3.4 KiB

heartbeat-runbook.md

Committed at docs/evidence/second-core/heartbeat-runbook.md. This is what grounds the requirements that cite it.

Open raw source

Physical CPU0 heartbeat runbook

This is a proposed operator procedure. No command below has been executed on the board for this change. The board operator must hold /dev/ttyACM0 and the user’s explicit authorization for this specific session. 2026-09-28 update: the disposable rollback card and external-reader recovery rehearsal previously required here are waived by the operator’s decision that day: “we can easily fix the sd card damn. don’t worry about recovery we’ve literally done that fine already before. i don’t want to do a heartbeat test on a spare card.” This procedure now runs on the normal card. If a release fails or hangs the board, recover with the already-proven U-Boot one-shot boot from boot-prev (docs/evidence/card-shell/bottom-band-flicker/kernel-patch-boot-panic.md) or ums/flash reimaging (docs/uboot-ums.md) — no external card reader is needed. See heartbeat-host.md for source, payload hash, cache limits and memory map.

  1. Build the payload on the host and check its hash:

    SMALL_CORE_OUTPUT_DIR=/tmp/k230-small-core-heartbeat-host bash tools/test-small-core-heartbeat.sh
    
  2. Put that exact heartbeat.bin on the normal card’s boot partition as /small-core-heartbeat.bin. Record its SHA-256 and the card identity. At the CPU1 U-Boot prompt, inspect bdinfo and confirm the address interval 0x07000000..0x07004fff is free of U-Boot relocation, stack, malloc, framebuffer, and currently loaded boot files. Stop if it is not.

  3. Confirm the fallback recovery route (U-Boot one-shot from boot-prev, or ums/flash reimaging) is available for this session before proceeding. Then load the test image. ext4load must report 80 bytes and fileaddr=0x7000000:

    ext4load mmc 1:1 0x7000000 /small-core-heartbeat.bin
    printenv fileaddr filesize
    

    The board’s active boot partition may differ from mmc 1:1; verify it from the current mmc_boot_dev_num and partition table before running. Never run the release if the size/hash or memory check differs.

  4. With the console transcript running, release physical CPU0 using the pinned command and read each separate output page once, at least one second apart:

    boot_baremetal 0 0x7000000 0x5000
    md.l 0x7002000 6
    md.l 0x7003000 2
    md.l 0x7004000 2
    echo CPU1_UBOOT_PROMPT_ALIVE
    

    The first page holds counter, mhartid, and misa as three little-endian 64-bit words. Decode two 32-bit md.l cells per word. Require three strictly increasing counter values and a responsive prompt; any static value, fault, reset or hang fails this probe. The mhartid value directly tests the published report that both physical cores report zero.

  5. End the bare-metal test with a board reset and restore normal boot (via the fallback route in step 3 if the release misbehaved). Do not run U-Boot boot while CPU0 executes from 0x07000000: the normal boot command loads /bootargs.txt at that same address, overwriting the running payload. Capture the restored Linux CPU mask and normal UI/console result separately from the probe result.

This proves at most physical CPU0 execution while physical CPU1 runs U-Boot. The separate Linux-coexistence stage in openspec/changes/the-small-core-runs-a-recoverable-heartbeat/tasks.md remains unverified until an experimental SPL/DT and board transcript exist.