RVV trial preparation on the expanded card

This is an independent CPU-vector experiment. It does not enable the second core or GPU, change the normal renderer, or replace default Pixman acceptance. The card interaction budgets remain open.

Matching system and image

artifacts.json records the actual cross-builds at master 648eab07, including the now-verified root-growth service. The trial kernel, external Wi-Fi module, initrd and context probe form one complete system. Host extraction of the built boot partition verifies the kernel bytes, wrapped initrd payload/CRCs and selected system in bootargs. These are host proofs.

The complete closure was imported over Wi-Fi and pinned on the board. Its 112,751,696-byte Nix export SHA256 is 561037e0780a6cfa6367bb628e05d108d23c2e5c3ae0e990c473db0ad4e589a9. Only 16 paths differed from the current normal system. This now fits because the physical root expanded during the earlier storage boot trial.

The trial bootargs, DTB and wrapped initrd are staged below /var/lib/k230/rvv-trial/. Their 27,402,240-byte transport bundle SHA256 is fdf22f14b6166e3048cdd05b214dd992ea5ba9fe95bb44031c4216dac91186da. The normal boot partition and system profile were not replaced. All files are public build artifacts; runtime credentials are excluded.

Boot controller and guards

tools/rvv-board-preflight.py checks the current normal system/profile, physical layout and filesystem size against the committed storage capture, protected firmware/boot hashes, every staged artifact’s SHA256 and size, complete registered closure, trial GC root and running shell. The host runs it with Python’s isolated mode and requires a fresh complete token line.

tools/rvv-board-boot.py holds the board lock, catches U-Boot, and loads five artifacts into the established non-overlapping boot addresses. It verifies actual reported lengths and CRC32 of each loaded memory region. Trial files come from root partition 2; the unchanged SBI payload comes from boot partition

1. Its default mode then resets to the ordinary boot selection. --boot instead imports the verified trial bootargs only into volatile U-Boot state and boots the matching in-memory kernel/initrd/DTB once. No saveenv, flash, partition change or persistent boot selection command is issued.

If a load fails while U-Boot remains available, the controller resets to normal boot and records whether a fresh Linux login appeared. A login alone is never claimed as vector execution, context preservation, shell recovery or speedup. A kernel hang after entering a trial may still require a physical reset; the normal persistent boot selection remains the recovery target.

Five host tests reject malformed paths, oversized artifacts, echoed/short or ambiguous load reports, wrong memory CRCs and stale/incomplete preflight tokens. The first physical preflight-parser failure is preserved in load-check.json and its analysis: the board guard passed, but the host did not account for the Linux shell’s leading bracketed-paste reset. No reboot was attempted by that failed run. The corrected parser removes only that known leading artifact and retains strict complete-line matching.

The next load attempt also remains failed in load-check2.json and its protocol analysis. The actual first-file CRC matched the expected value, but the vendor prints crc32 in lowercase. The inherited CRLF sender also supplied a second empty U-Boot command, repeating its previous command. The controller rejected the reply and observed Linux login after resetting into normal boot. It now sends exactly one CR per command and accepts the observed case while retaining exact, unique length/CRC requirements. No vector instruction was executed in either failed attempt.

Physical load-and-return proof

load-check3.json passes: U-Boot read the staged bootargs, SBI payload, trial kernel, DTB and trial initrd at the expected sizes, and every in-memory CRC32 matched the extracted image artifact. The controller then reset, without importing trial arguments or executing its kernel. The following ordinary boot reached Linux login. Selected console lines and provenance preserve this distinction.

load-normal-recovery.json separately passes the physical recovery checks: a fresh boot ID, the exact normal system, unchanged persistent boot-file/firmware hashes and root layout, successful no-op growth service, active shell/seatd, and Wi-Fi association plus HTTPS over wlan0. This proves read access from the expanded root and normal recovery. At this load-only checkpoint, the trial kernel had not executed. The later physical vector result is recorded below; rendering benefit remains open.

The next explicit operator trial uses the same controller with --boot:

python3 tools/rvv-board-boot.py --manifest HOST_TRIAL_MANIFEST \
  --private-log PRIVATE_LOG --output NEW_EVIDENCE/boot.json --boot

The host manifest combines artifacts.json with a normal member copied from docs/evidence/storage-capacity/board-repeat.json; the identical manifest and tools/rvv-board-preflight.py are staged with the verified boot files. Use new log/output names because prior runs must not be overwritten. After an actual trial boot, verify the selected running system and kernel configuration, then run the scalar hwprobe gate and the context probe. Preserve the ordinary boot selection and verify its recovery again before treating the experiment as safe.

Physical trial boot and vector context

The one-time trial now reached Linux login: boot1.json, selected boot lines and raw-log provenance. The verified five loads were followed by volatile trial-argument import and bootm; no persistent selection command was used.

capture-vector-state.py was transferred with matching MD5 and run through the serial console with isolated Python. It requires the physical device-tree model, exact trial /run/current-system, matching kernel command-line selection and all five expected vector configuration values. It then makes a scalar hwprobe query and invokes the immutable, capability-gated context diagnostic under a 15-second timeout.

vector-state1.json and its serial report record physical PASS at boot ID 3f80b720-c0e6-4f41-9437-e97aff248d28:

• Running system is the matching fm8136… trial; all five vector settings are enabled.
• Standard hwprobe succeeds with value 63, including the standard V capability.
• Both diagnostic processes complete 2,000 checks. The parent records 2,002 signals and 477 involuntary context switches; parent result, child status and process exit are all zero.
• Shell/seatd are active, Wi-Fi is associated and HTTPS succeeds over wlan0.
• Persistent system profile and bootargs still select the normal gnr36q… system.

The diagnostic verifies representative vector arithmetic/control state across signals and scheduling. It does not exhaustively test every instruction or register, establish Pixman pixel correctness, measure card performance, or prove real-finger interaction. The normal renderer remains unchanged.

Preparation reconciliation maps the earlier build/full-guest/load checkpoints to proposal tasks with exact evidence hashes. The Pixman host detector test was rerun with its required pinned source environment variable; the initially bare invocation failed before running.

Normal recovery after executing vectors

An ordinary serial reboot returned to the persistent normal selection without operator intervention. trial-normal-recovery.json and its serial report pass the independent root-growth recovery checker: fresh normal boot, exact gnr36q… system, unchanged boot/firmware hashes and root layout, successful no-op growth service, active shell/seatd, protected credential permissions, Wi-Fi association and HTTPS over wlan0. No full-image flash or readback was performed.

The proposal’s build, guest, physical load, actual boot/context and subsequent normal recovery tasks are complete (9/14). Pixel comparison, optional renderer packaging, paired card costs, final decision and final publication remain open.