evidence · 7.1 KiB

README.md

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

Open raw source

Second-core readiness decision

Collected 2026-09-22 America/Chicago (2026-09-23 UTC) on the working persistent Wi-Fi image. Live handoff is the output of sh tools/second-core-readiness.sh transferred to /run and executed through the coordinator’s exclusive console session. The OpenSBI banner is a whitelisted excerpt from the previously captured reboot of this image; OpenSBI output is not part of Linux’s dmesg. No extra reboot or register access was needed for this investigation.

The initial evidence established a one-hart handoff, rather than an attempted secondary CPU that failed to boot. The later physical CPU0 diagnostic measured CPU0’s mhartid=0. The pinned OpenSBI source shows that its Boot HART ID : 0 is a direct CSR read on the CPU1-side boot path, establishing the same value for CPU1 through the source-backed physical handoff attribution.

GateObserved/source evidenceDecision
Hart identity/domainOpenSBI count 1, Domain0 0*; live DT contains only cpu@0, hart ID 0; physical CPU0 SPL and CPU1-side OpenSBI’s direct CSR read both returned mhartid=0Duplicate hardware IDs require an independently grounded virtual-ID or other supported two-hart mapping; current generic OpenSBI cannot distinguish the cores
Firmware startOpenSBI reports HSM device ---; Linux detects the generic HSM extensionExtension availability does not prove a secondary reset/vector implementation
Interrupt/timerLive PLIC routes CPU phandle 3 to interrupts 11/9; CLINT routes the same CPU to 3/7Current handoff describes one CPU’s external, software and timer routes
Linux statepossible, present, online all 0; one CPU brought upSMP is compiled, but there is no second described CPU to start
ISA/cache/coherencyCurrent C908 has RVV/Sv39; vendor AMP source explicitly manages cache and reserved memoryCPU1 ISA/cache topology and a CPU-to-CPU coherent atomic-sharing contract remain unproved

2026-09-26 read-only continuation

The coordinator, holding the exclusive console, ran the fixture-tested v2 collector on the normal board. The complete output is timestamped 2026-09-27T03:32:04Z; the first attempt stopped when Python’s read-only map of PWR returned EPERM. The collector was then changed to emit that error per register and continue. It opens /dev/mem with O_RDONLY and maps only the three named registers with PROT_READ when SECOND_CORE_READ_MMIO=1. Neither run wrote MMIO, changed CPU state, or rebooted. The PWR permission boundary was preserved, so those two register values are unknown.

The operator’s host runner was /tmp/k230-core-probe-run.py; it transferred the inspected tools/second-core-readiness.sh to /run/second-core-readiness.sh through tools/console.py /dev/ttyACM0 --wait=10 and checked its SHA-256 before running this exact board command:

env SECOND_CORE_READ_MMIO=1 PATH=/nix/store/v189xydz6qkcd4cbkixcmv91w8hbc560-python3-riscv64-unknown-linux-gnu-3.14.7/bin:/run/current-system/sw/bin:/run/wrappers/bin sh /run/second-core-readiness.sh

The source script staged by the operator was /tmp/k230-second-core-readiness-v2.sh. The installed/booted system was /nix/store/11y992kp7bikr5hg21i2azfvmca43i7i-nixos-system-nixos-26.11.20260919.20b1ddd (source 433a4226, kernel /nix/store/9w07l7qyhd3xykq9wfhjlg3qqc3ijqhs-linux-riscv64-unknown-linux-gnu-6.6.36-xuantie).

New fieldPhysical observationInterpretation
CPU1 reset control 0x9110100c0x00013000, bit 0 clearConsistent with physical CPU1 released; the pinned stage-1 source describes its release into U-Boot. It is not a standalone physical-to-hart map.
PWR CPU1 control/status 0x91103018/0x9110301cBoth <unavailable:EPERM>No power-state conclusion from these reads.
Linux CPU ISA/cacherv64imafdcv..., L2 256K; CPU masks still all 0Corroborates the physical big-core handoff, with one Linux CPU.

The pinned stage-1 overlay at k230_linux_sdk revision 1104236db4d1e47873bd68924f912747b820228c resolves the U-Boot prompt’s physical owner: sdk_autoconf.h sets CONFIG_LINUX_RUN_CORE_ID 1, k230_img.c:276-285 releases physical CPU1 into U-Boot and parks physical CPU0 in wfi. This source finding, together with the live RVV/256K profile, supports Linux running on physical CPU1. It does not make the one Linux logical hart ID (0) a unique identifier across both physical cores. A first-hand K230 Linux DTS review reports the big core’s mhartid as 0, and a later K230 board modeling discussion reports both cores as 0. Those reports have not been tested on this board. They strengthen the stop condition against adding a guessed cpu@1 node.

Host checks on 2026-09-26: sh tools/test-second-core-readiness.sh passed both populated and denied-mapping fixtures; python3 -m unittest discover -s tests -p test_ums_target.py passed 16 tests, including refusal of a wrong sector count. The known UMS card in docs/uboot-ums.md has 249872384 sectors, but that number was not remeasured in this session, so a live UMS fallback check remains open. These host results do not complete the PWR read, recovery rehearsal, or second-core release gates.

Decision: retain the working single-hart image. Do not add a guessed DT CPU node or release/reset a core. The source investigation identifies the vendor AMP reset-vector sequence but does not establish Linux SMP compatibility. AMP would also need a separate payload, reserved memory, cache-maintained shared buffers, mailbox protocol and peripheral ownership.

The next bring-up proposal must first pin source or vendor documentation for the physical hart map, CPU1 vector/domain/HSM startup, timer/IPI/PLIC contexts and coherency/atomics. Once those gates are met, use a recoverable experimental image and require two enumerated OpenSBI harts, two Linux CPUs, timer/IPI stress and shared-memory atomic tests before running video comparisons. If coherency cannot be established, scope an AMP offload protocol instead of claiming a second Linux CPU. The readiness investigation is complete; second-core enablement is not.

2026-09-27 bounded physical identity trial

The default-off diagnostic package was installed in the two raw SPL slots after original 512 KiB slot backups were verified both on and off board. It printed CPU0_SPL_IDENTITY mhartid=0x0 misa=0x800000000094112f, then the existing one-CPU Linux boot completed. Both original SPL slots were restored, direct-read hashes matched the originals, and a subsequent normal reboot reached the root prompt with all four shell services active. The trial record gives commands, hashes, captures, and the pinned OpenSBI source chain showing that the CPU1-side Boot HART ID : 0 is a direct CSR.MHARTID read. Both physical cores therefore report zero through distinct boot paths. This does not establish a usable two-hart mapping or Linux SMP.