grounded
The kernel is pinned, and its divergence from upstream is recorded
The kernel SHALL be built from a pinned revision of the Xuantie tree used by Canaan's Linux SDK, and every patch this project carries on top SHALL be recorded with what it does and why it is needed.
groundingk230_canmv_v3_defconfig in kendryte/k230_linux_sdk builds ruyisdk/linux-xuantie-kernel at 7d4e1f444f461dbe3833bd99a4640e7b6c2cd529 with the k230 defconfig.
The kernel SHALL carry support for this board's panel and touch controller. Panel support is configuration — a device tree describing the RM69A10 to the generic Canaan panel support already in the tree. Touch support is a patch, because the pinned tree predates GT9895 support.
Where this project's device tree diverges from the k230-canmv-v3 reference, the divergence SHALL be recorded. The reference describes a different display — an ST7701 at 480x800 — so the divergence is expected and is the point.
scenarios The kernel derivation is inspected
- WHEN someone asks what this project changed about the kernel
- THEN the pinned revision, each carried patch, and the device tree divergences from the reference board are all recorded
A patch is added to the kernel
- WHEN a patch is carried
- THEN it is recorded with its origin and the reason it is needed, so a later kernel bump can tell whether it is still required
grounded
An optional vector system trial retains the normal recovery path
Physical grounding: docs/evidence/card-shell/kernel-rvv/board-trial/boot1.json, vector-state1.json and trial-normal-recovery.json record one-time trial boot, matching running identity and normal shell/Wi-Fi return with protected hashes unchanged. Earlier failed load reports and recovery are retained in the same directory. Grounding for the approach: the matching kernel/system/image builds and actual boot-artifact inspection are recorded in docs/evidence/card-shell/kernel-rvv/; storage first/repeat boot evidence is in docs/evidence/storage-capacity/. Host builds do not prove a trial kernel boots.
The system SHALL provide an explicitly selected CPU-vector trial with matching kernel, external modules, initrd and userspace. Trial preparation and one-time boot SHALL retain the known normal persistent boot selection and protected credential procedure. The operator SHALL verify artifact identity before loading the trial and verify the normal system, shell and Wi-Fi after returning. A failed load SHALL stop trial execution and attempt normal recovery while the bootloader remains available. Recovery requiring an operator reset SHALL be reported rather than claimed as automatic success.
evidence in this repository scenarios A person returns from the vector trial
- WHEN the operator resets after a one-time trial without selecting a new persistent system
- THEN the known normal system boots with its protected boot data intact
- AND the shell and Wi-Fi recovery are recorded separately from trial success
A staged artifact cannot be verified
- WHEN an artifact has an unexpected identity, size or loaded-memory checksum
- THEN the operator does not execute the trial kernel
- AND the failure and observed recovery outcome are retained
grounded
Vector execution is gated by actual kernel and context support
Physical grounding: docs/evidence/card-shell/kernel-rvv/board-trial/vector-state1.json records hwprobe value 63 and a two-process PASS with 2,000 checks per process across signals and scheduling. This is representative state proof, not exhaustive ISA coverage. Grounding: docs/evidence/card-shell/pixman-rvv/kernel-probe.json records successful hwprobe with value 59 and no standard V bit; docs/evidence/card-shell/kernel-rvv/context-probe/board-skip.json records safe SKIP/77. Full-system guest context and deliberate-corruption cases are separate diagnostic proof.
The optional vector path SHALL require the kernel's runtime capability report and physical vector computation with preserved state across asynchronous signals and process scheduling. A processor name, ISA string, successful cross-build or guest result SHALL NOT substitute for that physical evidence. If capability is absent or the state check fails, rendering SHALL retain scalar fallback and the failed or skipped result SHALL remain visible. The trial SHALL NOT force vector instructions merely to bypass a failed runtime gate.
evidence in this repository scenarios The running kernel does not expose usable standard vectors
- WHEN the scalar capability query omits standard vector support or returns an error
- THEN the diagnostic skips vector execution and rendering retains its fallback
- AND no acceleration result is claimed
The trial advertises usable vectors
- WHEN the trial kernel advertises standard vector support
- THEN representative vector computation must survive signals and scheduling on the physical board before vector rendering is evaluated
grounded
A vector rendering decision includes correctness and matched cost evidence
groundingphysical-board comparison in docs/evidence/card-shell/kernel-rvv/card-cost/README.md, run1/result.json and comparison.json record six matched physical runs with unchanged budgets. CPU-cost changes are small and mixed; every workload fails overall acceptance, four upward-throw checks fail, and the decision retains the ordinary image. This is injected-input measurement, not real-finger or optical proof. Partial physical grounding: docs/evidence/card-shell/pixman-rvv/pixel-trial/board/result.json records 192 exact byte comparisons, real RVV callback counts and a detected one-byte corruption control. This proves only its declared pixel cases, not card costs.
The optional userspace renderer trial SHALL compare its declared pixel cases against the scalar reference and measure the same live-card workload with vector dispatch enabled and disabled on the same trial kernel. It SHALL retain frame/update, input-latency, CPU and memory measurements and all existing card interaction budgets. A compiled vector path, isolated instruction test or faster synthetic operation SHALL NOT be presented as a card-shell speedup. The recorded decision SHALL preserve negative results and distinguish an optional experiment from a default image change.
evidence in this repository scenarios Vector operations are correct but do not improve the card workload
- WHEN the vector pixel cases pass but matched card measurements do not improve the declared costs
- THEN the result records that outcome and does not claim an accepted performance improvement
- AND the ordinary renderer remains unchanged
Vector rendering is considered for future default use
- WHEN the optional trial passes correctness and shows a measured benefit
- THEN the evidence names the workload, repeated measurements and remaining compatibility limits
- AND default promotion remains a separate reviewed change
grounded
A parallel mainline kernel build exists and does not affect the default system
The project SHALL provide a mainline-Linux kernel, device-tree, and boot-files build (.#kernelMainline, .#deviceTreeMainline, .#kernelMainlineBootFiles) pinned to the newest mainline revision carrying basic Canaan K230 support, built entirely separately from the pinned vendor Xuantie kernel .#kernel uses. No vendor package or vendor nixosConfigurations output SHALL depend on or be changed by this build existing. .#sdImage deliberately ships the mainline system (see "The flashable default image ships the mainline coherent shell").
groundingnix/kernel-mainline-src.nix pins torvalds/linux at the dereferenced v7.3-rc5 commit — the newest tag with arch/riscv/boot/dts/canaan/k230.dtsi present, confirmed absent at v7.2 by direct tag diff. nix/kernel-mainline.nix and nix/device-tree-mainline.nix share no code path with nix/kernel.nix or nix/device-tree.nix; flake.nix's new kernelMainline/ deviceTreeMainline/kernelMainlineBootFiles outputs are additive only.
scenarios Someone builds the mainline kernel
- WHEN someone runs nix build .#kernelMainline - THEN it exits 0 and produces a riscv64 kernel Image, independent of whether .#kernel has ever been built
Someone builds the default system
- WHEN someone builds .#nixosConfigurations.k230.config.system.build.toplevel or .#sdImage-coherent - THEN the result is byte-identical to what it would be if nix/kernel-mainline.nix, nix/kernel-mainline-src.nix, nix/device-tree-mainline.nix, and this change's other new files did not exist
grounded
A parallel full system variant boots the mainline kernel without changing the default system
The project SHALL provide a full NixOS system variant (nixosConfigurations.k230-mainline-console) that substitutes the mainline kernel for the vendor kernel via the same k230Kernel specialArg substitution mechanism the existing k230-rvv-trial variant already uses, built from the shell-off k230-console base rather than the graphical k230-coherent-shell base, and SHALL exclude any out-of-tree kernel module that is not expected to compile against the mainline pin. No existing nixosConfigurations output SHALL be changed by this variant existing.
groundingflake.nix's k230-mainline-console extends k230-console with specialArgs.k230Kernel = self.k230MainlineKernel and force-clears boot.extraModulePackages/boot.kernelModules (the out-of-tree RTL8189FTV module nix/hardware.nix builds against config.boot.kernelPackages.kernel dynamically, with no reason to expect it compiles against a v7.3-rc5 API seven major versions newer than its 6.6-era vendor origin, and no SDIO DT node enabled for it to bind to regardless). Proven: nix build .#toplevel-mainline-console exits 0, producing /nix/store/d488a1cibw8r7ip7hbbb9j52hy0kzb0h-nixos-system-nixos-26.11.20260919.20b1ddd. Deviates from the coordinator's suggested "-shell-" name for the reason above; flagged rather than silently decided.
scenarios Someone builds the mainline system variant
- WHEN someone runs nix build .#toplevel-mainline-console - THEN it exits 0 and produces a NixOS system closure built against kernelMainline, independent of whether any other nixosConfigurations output has ever been built
grounded
The mainline build's hardware ceiling is recorded, not assumed
The project SHALL record, per hardware function, whether mainline Linux at the pinned revision can drive it, citing direct file-existence or device-tree-content checks rather than changelog summaries. Hardware functions with no mainline driver SHALL be recorded as blocked rather than silently omitted, and any of this project's own vendor-kernel patches that cannot be forward-ported to mainline SHALL be recorded individually with the reason, not summarized as a single negative finding.
groundingdocs/research/mainline-kernel-inventory.md's Inventory table (each row cites gh api repos/torvalds/linux/contents/<path> returning 200 or 404) and its per-patch disposition list (all eleven vendor-kernel patches checked individually; ten target files absent upstream, one already fixed upstream independently, none require porting as a patch today).
evidence in this repository scenarios Someone asks whether mainline can drive the display
- WHEN someone reads docs/research/mainline-kernel-inventory.md's panel row - THEN it states that the pinned upstream tree had no DSI/VO/Canaan DRM drivers at the time of the inventory, cites the exact file-existence checks, and points to the separately tracked kernelMainlineDrm continuation without claiming that continuation is complete
A vendor-kernel patch is checked against mainline
- WHEN someone asks whether a specific patch in nix/kernel.nix applies to the mainline build - THEN the inventory names that exact patch, the file it targets, and whether that file exists upstream today
grounded
Forward-ported drivers are grounded in the vendor tree and checked against the pinned mainline API
Where this project forward-ports a vendor-tree driver onto the mainline pin so a boot-critical function (GPIO, SD/MMC, USB) is available, the ported file or hunk SHALL be traceable to its exact vendor-tree origin by path, and any API difference between the vendor tree's kernel version and the pinned mainline revision that required a code change (not just a Kconfig/Makefile wiring change) SHALL be recorded with what changed and how it was confirmed, rather than silently patched around.
groundingnix/patches/mainline/gpio-k230.c and nix/patches/mainline/sdhci-of-kendryte.c are forward-ported from ruyisdk/linux-xuantie-kernel @ 7d4e1f444f461dbe3833bd99a4640e7b6c2cd529; nix/kernel-mainline.nix's postPatch carries the drivers/usb/dwc2/ {params.c,core.h,core.c} hunks from the same tree. Two real API migrations were found and fixed this way, each only after a failed build named the exact missing symbol: struct gpio_chip's .read_reg/ .write_reg/.bgpio_lock and bgpio_init() were replaced upstream by struct gpio_generic_chip/gpio_generic_chip_init() (include/linux/gpio/generic.h), confirmed against mainline's own already-migrated gpio-dwapb.c; sdhci_pltfm_free() was removed upstream entirely, confirmed against mainline's own sdhci-of-dwcmshc.c, whose probe error paths and .remove call no equivalent function.
scenarios A forward-ported driver fails to compile against the pinned mainline API
- WHEN nix build .#kernelMainline fails with an unknown-symbol or missing-member compiler error in a forward-ported file - THEN the fix is recorded against the exact API change found, citing a mainline reference file that already uses the new API, not a guess
grounded
A mainline hardware boot is a named, unclaimed evidence gate
Reaching a mainline-booted serial console, rootfs, or any further hardware milestone on the physical board SHALL be treated as hardware evidence, never inferred from a successful cross-build. A change that only cross-builds the mainline kernel/device-tree SHALL say so explicitly and SHALL NOT claim any hardware milestone until a board console transcript exists.
groundingthis change's own tasks.md "Remaining evidence gate" section names the exact operator command (flock /tmp/k230-board.lock python3 tools/console.py /dev/ttyACM0 --wait=10) and the manual U-Boot ext4load steps it depends on, without performing them.
scenarios Someone asks if the mainline kernel boots on the board
- WHEN someone asks whether .#kernelMainline has booted on the T-Display-K230 - THEN the answer cites a committed board console transcript under docs/evidence/, or states plainly that none exists yet
grounded
A mainline display port remains isolated and evidence-bounded
The project MAY provide an opt-in mainline DRM candidate, but it SHALL remain a separate derivation from the console-only kernelMainline and SHALL NOT change the vendor kernel, default device tree, system configuration, or image outputs. Source/API checks, complete kernel builds, DTB checks, and physical display/touch observations SHALL be recorded as distinct evidence; one class SHALL NOT be described as proof of another.
evidence in this repository scenarios Someone builds the console-only mainline kernel
- WHEN someone runs nix build .#kernelMainline - THEN the optional DRM candidate does not modify that kernel or its existing console boot-files/DTB outputs
Someone asks whether the DRM candidate drives the panel
- WHEN the complete derivation builds, prepared-header object check, and DTB round-trip are available, but no physical observation exists - THEN the answer reports those host results and leaves board probe, display power, panel illumination, and touch behavior unverified
grounded
The optional mainline trial owns an explicit restart recovery boundary
The optional DRM mainline kernel SHALL provide a documented restart mechanism traceable to the pinned vendor source, isolated from vendor/default and console-only mainline outputs. Source/API object proof, complete candidate kernel build, matching trial-bundle proof and physical restart/recovery SHALL be recorded separately. Physical automatic restart remains UNVERIFIED until a committed console transcript shows a kernel restart request reaching stage 1 and the protected normal system returning with a fresh boot identity.
groundingthe read vendor drivers/reset/reset-k230.c at 7d4e1f444f461dbe3833bd99a4640e7b6c2cd529 registers a priority-128 restart handler and writes bits 0/16 at 0x91102060. The source audit at docs/evidence/mainline-display/physical-2026-10-01/mainline-restart-source-audit-2026-10-02.md records the mainline peripheral-only reset driver, absent advertised SBI SRST, the systemd refusal and distinct operator recovery. Group 5d owns the kernel/Nix continuation and its separate evidence gates. docs/evidence/mainline-restart/README.md records the initial GCC failure, corrected source/object/full-kernel/matching-bundle proof and unchanged base-relative default outputs; its host checks do not provide physical restart proof.
Physical grounding: docs/evidence/mainline-restart/physical-clock-comparison-2026-10-02/README.md records a real candidate kernel restart → SPL → protected normal return, fresh boot ID, matching identities, active shell services and eight unchanged hashes with temporary clk_ignore_unused. This proves that diagnostic selection only; the baseline still stalls and restart without the flag requires a separate clock-consumer fix and physical proof.
Further physical grounding: docs/evidence/mainline-sd1-clocks/physical-no-flag-2026-10-03/README.md records the targeted five-clock candidate with ordinary clock cleanup, no clk_ignore_unused, real kernel restart → SPL → protected normal boot, fresh boot identity, three active shell services and eight unchanged hashes. The full initrd-shell result and artifact identities are committed; ordinary root activation and deliberate touch remain separately unverified.
evidence in this repository scenarios The operator requests restart from the mainline diagnostic trial
- WHEN a real kernel restart request is issued from the reviewed optional candidate after the userspace prerequisites pass - THEN the console shows stage 1 restarting and the protected normal system returning with a fresh boot identity and verified protected hashes
A reboot command returns a userspace refusal
- WHEN systemd refuses the reboot command or the operator power-cycles the board to recover - THEN that result is recorded with its limits and does not satisfy the optional mainline kernel's automatic restart evidence gate
Only the host restart checks have passed
- WHEN the changed object, complete kernel and matching trial bundle build - THEN their source/artifact identities are recorded and physical restart remains UNVERIFIED; usable-root, panel and touch requirements remain open
unverified
Optional mainline progress records distinguish receipt from execution
why it is unverified physical counter values, receipt and autonomous progress remain unproved.
The project MAY provide a separately named runtime-opt-in kernel diagnostic for the observed userspace-prompt/no-receipt boundary. It SHALL record bounded cached UART/IRQ/time progress independently of foreground shell input, with explicit unavailable/busy/unknown states and no UART register/settings changes. Observer source/API/object, matching artifact and physical results SHALL be separate. Existing default and diagnostic outputs SHALL remain unchanged; finite reporter output SHALL NOT establish ordinary root, Bash receipt, physical timer health, automatic recovery or a production fix.
evidence in this repository scenarios The serial operator sees a shell prompt but cannot get a reply
- WHEN the reviewed optional matching diagnostic is reserved for a physical trial and its fresh prompt receives one bounded receipt stimulus - THEN finite independently captured records distinguish driver RX counts, actual mapped IRQ accounting and reporter/time progress with their limits - AND missing receipt/records stop further input and keep root/recovery open
Someone interprets a progress record
- WHEN reporter sequence, RX or timer IRQ counters increase - THEN the report names scheduling, processed RX/break counts or kernel-accounted timer interrupts respectively, without inferring a physical FIFO read for every RX increment, Bash delivery or a causal fix
Only diagnostic host checks have passed
- WHEN optional source/object/kernel/bundle/protocol checks pass
- THEN physical output/receipt/return remain UNVERIFIED and task 5b.5 stays open
unverified
Optional progress breadcrumbs keep worker and wakeup evidence distinct
why it is unverified new variant/source/object/controller/full-build and physical breadcrumb proof are planned.
The project MAY provide a separately selected finite reporter variant for the observed zero-report boundary. It SHALL preserve every existing package/source/ trial identity and attempt only fixed worker-entry and first-post-sleep public SBI records in its normal-priority worker, with ordinary aligned page-contained storage and no IRQ/TTY/PID1 instrumentation. Both exact runtime opt-ins and actual DBCN availability SHALL gate breadcrumbs; absent/invalid breadcrumb selection SHALL retain the original six-sample behavior. The six numeric sample formats, sleeps, getter semantics and stop checks SHALL remain unchanged.
The explicit controller selection SHALL keep exact candidate/argument and protected normal qualification, accept only bounded complete fresh fixed records, and distinguish breadcrumb presence, numeric samples and receipt. Missing/malformed output SHALL remain unknown and SHALL NOT cause another stimulus or candidate reboot. Neither breadcrumb presence nor absence SHALL be described as a causal diagnosis, ordinary-root acceptance or recovery.
evidence in this repository scenarios The operator captures an entry record without a delayed sample
- WHEN an exactly qualified fresh trial emits only worker-entry
- THEN the report states that the worker reached that output call
- AND it leaves firmware return, sleep/wakeup, counters and receipt unknown
The first post-sleep record is observed
- WHEN the qualified first-post-sleep record is complete - THEN the report states that the first sleep and existing stop checks passed and the earlier entry call returned - AND it does not claim complete earlier output, physical timer health, successful snapshot or Bash receipt
Output is missing or malformed
- WHEN fixed records are absent, duplicated, stale, reordered, truncated or interleaved with other console text - THEN the controller preserves private raw evidence and incomplete/unknown status without repairing text, another stimulus or a candidate reboot - AND root, deliberate touch and independent recovery gates remain open
unverified
Optional post-sample breadcrumbs separate return from wakeup evidence
why it is unverified after-n1-write/third-post-sleep output, receipt, automatic recovery and ordinary root/glass remain unproven. Source/exact/full/controller and incomplete physical capture are committed.
The project MAY provide a separately selected reporter variant for the observed n1/no-n2 boundary. It SHALL preserve all existing package/source/config/trial identities, samples, sleeps, cached getters, stop checks and normal priority. It SHALL attempt only two additional fixed public SBI records: after the n1 numeric call returns, and after the third sleep/stop check before snapshot. Ordinary aligned page-contained storage, the new exact opt-in plus both existing opt-ins, CONFIG_RISCV_SBI and DBCN availability SHALL gate the records. At most ten one-call attempts SHALL occur; absent/invalid new selection SHALL retain current behavior without a retry, fallback or IRQ/TTY/PID1 instrumentation.
The separately typed controller SHALL preserve exact candidate/argument and protected normal qualification, one fresh stimulus and private bounded capture. It SHALL accept only exact bounded complete fresh records and keep new-point, old-breadcrumb, numeric-sample, receipt and recovery facts distinct. Missing or malformed output SHALL remain unknown without another stimulus or candidate reboot, and SHALL NOT establish a causal fix, root/touch or automatic return.
evidence in this repository scenarios The point following the second numeric write appears
- WHEN a qualified fresh trial emits complete after-n1-write
- THEN the report states that the earlier n1 firmware call returned
- AND it does not claim its full count, the new call's return or third wakeup
The third post-sleep point appears
- WHEN the exact third-post-sleep record is complete - THEN the report states that the earlier point's call returned and the third sleep/stop checks passed - AND it leaves snapshot, n2 output, RX/Bash delivery and recovery separate
A point is missing or malformed
- WHEN the new record is missing, stale, echoed, duplicated, reordered, truncated or interleaved with other text - THEN private raw evidence and partial facts are retained as unknown - AND there is no further stimulus/reboot or inferred ordinary-root/touch, firmware-return or automatic-recovery result
Subsequent actual [PostSample packet](../../../../docs/evidence/mainline-uart-progress-post-sample/physical-2026-10-03/README.md) records matched args/Bash/worker-entry only, one stimulus and no receipt/samples/ new points in180.0975s. It does not prove reaching either new point or entry-call return; subsequent NEW operator reset passed guarded fresh normal postflight and Home observation. Host and incomplete capture completion do not satisfy the scenarios above or ordinary-root task5b.5.
unverified
Optional memory-progress comparison isolates repeated worker output
why it is unverified memory comparison source/artifacts/controller/physical results are planned.
The project MAY provide a separately selected explicit memory-progress reporter. It SHALL retain existing outputs/identities and, only under its exact opt-in, preserve six sleeps/cached snapshots/stop checks while suppressing every worker output call and publishing finite consistent ordinary-memory progress. A separate normal-priority observer SHALL use one finite kernel wait and at most one aligned bounded-size DBCN summary attempt. It SHALL NOT add MMIO, IRQ/TTY/PID1 output, retry/fallback, firmware/console-policy or scheduler changes. Gate absence or invalid values SHALL retain inherited behavior without observer creation.
The typed minimal controller SHALL qualify exact host artifacts/source/config, fresh received arguments/Bash readiness and protected normal state. It SHALL send at most one receipt then bounded passive capture, with no further input or candidate reboot. Summary, receipt and recovery SHALL remain independent facts; missing output SHALL NOT identify a cause or prove ordinary root/glass.
evidence in this repository scenarios A consistent completed summary arrives
- WHEN one exact fresh summary records all six worker snapshots completed
- THEN it establishes recorded progress before the observer's final output call
- AND it does not establish that call's return, a root cause or ordinary boot
Summary or receipt is absent
- WHEN bounded capture has no complete qualified summary or receipt
- THEN preserve each missing fact as unknown, including observer/output limits
- AND send no further candidate input or reboot and require separate recovery
unverified
Optional same-image zero-stimulus comparison keeps receive untested
why it is unverified typed zero-stimulus comparison implementation/host/physical proof are planned.
The controller MAY provide an explicit Memory-only no-stimulus comparison. It SHALL require minimal/same-image/progress/Memory selectors, preserve exact candidate/source/config/archive/load guards and identical volatile bootargs, and reject conflicts before UART access. After candidate boot it SHALL send zero candidate bytes on success/error/timeout/finally paths and retain bounded passive capture and strict fresh summary parsing. It SHALL record receipt NOT_REQUESTED, stimulus_attempts=0 and RX NOT_TESTED rather than infer receive or ordinary-root acceptance. Default one-stimulus behavior SHALL remain unchanged.
Only the existing ordered fresh normal-recovery qualification SHALL permit protected normal postflight writes; recovery remains independent of summary completeness. Missing output SHALL stay unknown and SHALL NOT establish input causation, an IRQ/timer/firmware fault or ordinary mainline acceptance.
evidence in this repository scenarios A completed summary arrives without a stimulus
- WHEN an exact qualified fresh summary records six worker snapshots complete
- THEN report that pre-output memory progress with zero candidate stimulus
- AND preserve RX NOT_TESTED and independent recovery/ordinary-root limits
Capture fails or no summary arrives
- WHEN passive capture times out or records malformed/missing output
- THEN preserve unknown facts and send no additional candidate bytes
- AND require independently qualified normal recovery or operator reset
unverified
Optional polling comparison changes only qualified idle policy
why it is unverified typed polling controller and physical idle-policy comparison are planned.
The controller MAY offer a typed Memory polling-idle comparison. It SHALL require minimal/same-image/progress/Memory/no-stimulus selectors and reject conflicts before UART access. It SHALL qualify the same realized source/config/ Image/archive/manifest and append exactly one bare volatile nohlt after checking the selected built-in polling setup. It SHALL reject hlt, duplicates, value variants and arbitrary bootarg changes; defaults SHALL remain unchanged.
After boot it SHALL send zero candidate bytes and retain bounded passive capture, strict fresh args/summary parsing, receipt NOT_REQUESTED, zero stimulus attempts and RX NOT_TESTED. Protected normal recovery SHALL remain independently gated. A difference SHALL be described only as idle/tick-policy dependence, without inferring WFI/IRQ/timer/firmware cause, ordinary-root acceptance or a production power policy. Missing output SHALL remain unknown.
evidence in this repository scenarios Polling produces a valid completed summary
- WHEN exact received arguments include the sole bare nohlt intervention
- AND a strict fresh summary reports six completed snapshots
- THEN record that progress with zero input and idle/tick-policy limits
- AND preserve separate RX, normal recovery and ordinary boot acceptance
Polling capture is incomplete
- WHEN output is absent, malformed or capture fails
- THEN preserve unknown progress and send no additional candidate bytes
- AND require independent protected recovery or operator reset
unverified
Separate observer output through the registered Linux console
why it is unverified Linux-console variant/source/build/controller/physical proof are planned.
The diagnostic MAY offer a separately built MemoryPrintk variant with an exact gate requiring existing Memory/progress gates. It SHALL retain six worker sleeps/ cached snapshots/atomic publication and one observer completion wait/acquire, suppress worker output, and replace its one final explicit DBCN attempt with one ordinary KERN_INFO fixed K230_UMK1 summary. The same call SHALL begin with a newline to separate an existing shell prompt from the timestamped summary line; the parser SHALL not strip prompts to recover malformed records. It SHALL not force console ownership, use emergency/raw-MMIO/fallback/retry output or change IRQ/firmware/priority policy. Every prior source/config/package/trial identity SHALL remain unchanged.
The typed controller SHALL require minimal/same-image/progress/Memory/no-stimulus and reject combined idle/point/trace selectors before UART. It SHALL qualify the new actual source/config/Image/format/setup and exact DT/archive/load guards, receive exact arguments and fresh Linux8250 ttyS0 registration/console markers. It SHALL parse only the observed timestamp-prefixed fixed new namespace and bounded coherent fields, rejecting old/wrong-channel/stale/malformed/duplicate/ truncated records. It SHALL keep zero input, NOT_REQUESTED/RX NOT_TESTED, bounded capture and independent protected normal recovery.
A record SHALL establish only observer progress through the changed output channel, not output-call return, DBCN causation, ordinary-root or glass acceptance. Missing output SHALL remain unknown. Native, target object, full artifact, controller qualification, physical observation and recovery SHALL stay separate.
evidence in this repository scenarios A fresh Linux-console summary is observed
- WHEN exact new gate/args and fresh Linux ttyS0 backend markers are observed
- AND one timestamp-prefixed K230_UMK1 summary satisfies bounded state rules
- THEN preserve recorded worker/observer progress with zero input
- AND retain separate output-return, recovery and ordinary-boot limits
No qualified Linux-console summary arrives
- WHEN capture is incomplete or output fails strict qualification
- THEN preserve unknown scheduling/timeout/output facts with no further input
- AND require independent protected recovery or operator reset
unverified
Optional same-image comparison disables tickless activation only
why it is unverified typed nohz-off controller, actual host preparation and new physical comparison are planned.
The controller MAY offer a typed MemoryPrintk nohz-off comparison. It SHALL require minimal/same-image/progress/Memory/no-stimulus/MemoryPrintk selectors and reject type/mode/competing selector conflicts before UART access. It SHALL qualify the same actual source/config/Image/archive/manifest/DT/load identities, NO_HZ_COMMON/NO_HZ_FULL/HIGH_RES_TIMERS/HZ=250/RISCV_TIMER/RISCV_SBI support and unique linked nohz setup. It SHALL append exactly one trailing nohz=off to the qualified baseline, reject original/alternate/bare/empty/duplicate nohz forms and arbitrary additions, and preserve all existing default transports.
The diagnostic SHALL keep its source/worker/observer/output gate and fresh exact arguments/backend/strict UMK parsing. It SHALL send zero candidate bytes through bounded capture/error/finally, record NOT_REQUESTED and RX NOT_TESTED and keep protected normal recovery independently gated. A valid record SHALL support progress under changed tickless policy only, without inferring hardware periodic interrupts, a timer/IRQ/firmware cause, printk return or ordinary boot acceptance. Missing output SHALL remain unknown. Runtime policy observation SHALL remain distinct from compiled parser support and received-token evidence.
evidence in this repository scenarios Tickless-off comparison yields a qualified summary
- WHEN fresh exact arguments include the sole nohz=off intervention
- AND one strict fresh UMK record satisfies the existing bounded state rules
- THEN record progress under changed tickless policy with zero input
- AND preserve separate output-return, RX, recovery and ordinary boot limits
Tickless-off comparison remains incomplete
- WHEN output is absent, malformed or capture fails
- THEN preserve unknown facts without sending candidate bytes
- AND require independent protected recovery or a new operator reset
unverified
Fixed autonomous PID1 comparison remains constrained and passive
why it is unverified typed autonomous PID1 native parser/controller/actual host/physical proof are planned.
The controller MAY offer a separately typed autonomous Bash-PID1 comparison using the same actual Image/initrd/DT. It SHALL require minimal/same-image-shell selectors and reject all diagnostic progress/timer/trace/shutdown conflicts before UART. It SHALL reconstruct only the reviewed fixed script and fresh 32-hex nonce, remove reporter gates, preserve qualified original init/rdinit and boot controls and enforce the unchanged literal transport bound. It SHALL not expose arbitrary scripts or weaken existing transport/default policies.
Before physical use it SHALL establish native exact Hush lexer/variable/quote/ command execution and selected Linux argv handling, actual artifact/archive sh/sleep/Bash builtin proof and exact printed bootargs. Source models alone SHALL NOT satisfy native execution. Fresh candidate phase/args/backend/bin-sh entry SHALL qualify only complete exact-nonce begin/end records; echoed scripts and commandline text SHALL NOT count. Malformed/stale/duplicate/reversed/ truncated records SHALL retain unknown facts without repair.
The script SHALL check PID1/UID0, attempt begin, one five-second sleep and end after success, then attempt an interactive exec independently of that chain. It SHALL deliberately issue no exit/reboot. The controller SHALL keep a bounded 60-second zero-input capture on all paths, RX NOT_TESTED and independent protected normal recovery. Record presence SHALL NOT authorize candidate input, prove that record's own output-call return, a full runtime identity guard, a timer/IRQ cause or ordinary boot/touch acceptance. Missing output SHALL remain unknown.
evidence in this repository scenarios Autonomous PID1 produces begin and end
- WHEN qualified exact arguments and fresh complete nonce records occur in order
- THEN record limited PID1/UID0 output and successful earlier printf/sleep
- AND preserve distinct prompt/output-return, RX, recovery and boot limits
Autonomous PID1 evidence is incomplete
- WHEN a record is absent or fails strict qualification
- THEN keep unknown facts and send no candidate bytes
- AND require independent protected recovery or a NEW operator reset
unverified
Fixed ordinary-init manager logging comparison
why it is unverified ordinary mainline root/panel/glass acceptance remains open; bounded controller/host/physical logging comparison is recorded below.
The system trial controller SHALL offer typed begin-only --initrd-debug-logging requiring synchronous-initramfs and marker-free ordinary init. It SHALL append only rd.systemd.log_level=debug rd.systemd.log_target=console, reject inherited conflicting logging keys including underscore/hyphen aliases and invalid types/combinations before UART, retain unchanged defaults and transport bound, and preserve the selected policy through guarded continuation.
It SHALL retain exact artifact/load/CRC/printed/live-argument and normal identity guards, a 180-second passive readiness bound and complete private logging past rolling-buffer capacity. Unknown readiness or I/O SHALL send no candidate input. Manager job/ExecStart state SHALL NOT be reported as nested command or syscall tracing, ordinary-root acceptance or protected recovery.
evidence in this repository scenarios Qualified logging comparison reaches an observed unit boundary
- WHEN fresh qualified candidate output names manager jobs or ExecStart state
- THEN record only the observed queued/spawned/running/completed unit facts
- AND retain separate login, identity, blocked-call and recovery limits
Verbose comparison does not reach qualified readiness
- WHEN login or I/O completion is unknown within the fixed bound
- THEN preserve the complete private log without candidate input or fallback
- AND require independent protected recovery or a NEW operator reset
unverified
Fixed info-level ordinary-init console comparison
why it is unverified ordinary mainline acceptance remains open; bounded controller/host/physical comparison is recorded below.
The system trial controller SHALL offer typed begin-only --initrd-info-logging, requiring synchronous initramfs and marker-free ordinary init, excluding debug logging, and selecting only rd.systemd.log_level=info rd.systemd.log_target=console. It SHALL preserve old/default/debug behavior, typed resumed selection, pre-UART alias/conflict/type rejection, the transport bound and all immutable artifact, normal identity, load/CRC and exact printed/live argument guards.
The comparison SHALL keep a 180-second passive readiness bound, complete private logging and unknown-no-input behavior. Changed observed progress SHALL NOT be reported as a blocked output-call diagnosis, ordinary boot acceptance or recovery.
evidence in this repository scenarios Lower verbosity changes observed progress
- WHEN qualified same-artifact info/console output reaches new messages
- THEN record those observations and the sole changed value
- AND retain independent runtime identity, cause and recovery limits
Info comparison remains silent
- WHEN qualified login or I/O completion remains unknown
- THEN preserve private facts without candidate input or fallback
- AND require independent protected recovery or a NEW operator reset
unverified
Fixed info-level ordinary-init kmsg comparison
why it is unverified physical kmsg output/ordinary acceptance remains open; independently reviewed controller and actual host proof are recorded below.
The userspace trial controller SHALL offer typed begin-only --initrd-info-kmsg-logging, requiring synchronous initramfs and marker-free ordinary init, excluding debug and info-console. It SHALL select exactly rd.systemd.log_level=info rd.systemd.log_target=kmsg, preserve existing profiles/defaults and typed saved continuation with old missing=false, and reject aliases/conflicts/types before UART.
It SHALL preserve the immutable artifacts, normal identity, five load/CRC, printed/live argument and transport guards,180-second passive readiness, complete private logging and unknown-no-input behavior. It SHALL NOT report kmsg selection as proof that console was unused, every record was delivered, a blocked call was identified, ordinary root worked or recovery succeeded.
evidence in this repository scenarios Changing the destination changes observed progress
- WHEN qualified same-artifact info/kmsg output reaches new messages
- THEN record the sole changed destination and observed boundary
- AND retain fallback/filtering, runtime identity, cause and recovery limits
Kmsg comparison remains unknown
- WHEN qualified login or I/O completion is absent
- THEN keep complete private output without candidate input or fallback trial
- AND require independent protected recovery or a NEW operator reset
unverified
The ordinary baseline is repeated before another boot intervention
why it is unverified ordinary acceptance remains pending; independently reviewed physical repeat did not reproduce the former closure boundary and subsequent NEW protected recovery passed.
The operator SHALL be able to repeat one unchanged quiet p2 ordinary policy with existing synchronous-initramfs and marker-free selectors, without any logging selector or new artifacts. Actual qualification SHALL establish exact 299-byte arguments/317-byte literal command and unchanged immutable/root/init/ mask/console/helper/load/CRC guards after NEW protected recovery.
The repeat SHALL retain the180-second passive readiness bound, complete private logging and unknown-no-input policy. Its outcome SHALL be reported as a reproducibility control, not a logging cause, ordinary-root acceptance, glass proof or automatic recovery. Subsequent recovery SHALL be independently verified or explicitly pending a NEW operator reset.
evidence in this repository scenarios The unchanged baseline reaches the previous unit boundary
- WHEN one qualified repeat again reaches closure lookup
- THEN record that reproduced boundary and any additional observed progress
- AND retain nested-command, cause, root and independent recovery limits
The unchanged baseline does not reproduce prior progress
- WHEN qualified startup/readiness or I/O remains unknown
- THEN preserve the temporal difference without compensating changes/input
- AND require independent protected recovery or a NEW reset
unverified
Selected ramdisk init exec return is observable with a bounded optional probe
why it is unverified userspace transition, output-call return and ordinary acceptance remain pending; physical capture recorded one valid ret=0 with no qualified login within180s, independently reviewed. Subsequent NEW protected normal recovery passed independent review.
An additive default-disabled diagnostic SHALL emit at most one fixed versioned INFO record containing only the signed return value after the selected ramdisk init exec attempt, before the original success/error branch. It SHALL preserve original init bytes/ABI/argv/env, return/fallback behavior, old Nix outputs and protected root/console/mask/load/CRC/identity guards. Its typed begin-only selection SHALL reject aliases/conflicts/types before UART and require exact new source/build/archive/arguments/manifests with independent review.
The physical trial SHALL retain the180-second passive readiness bound, full private coverage and unknown-no-input policy. Zero SHALL indicate successful exec setup only, not user-mode transition, loader, constructors or systemd main. Missing/partial records SHALL remain unknown. Record presence SHALL NOT imply its own output call returned, a failing instruction was found, ordinary root worked or recovery succeeded. Recovery SHALL be independently verified or explicitly pending NEW reset.
evidence in this repository scenarios Selected init exec returns zero
- WHEN a qualified fresh capture contains the fixed complete zero result
- THEN record successful exec setup with the exact artifacts and observation
- AND retain userspace-execution, output-call-return, cause and recovery limits
Returned error or absent record
- WHEN a qualified capture contains a nonzero result or no complete result
- THEN record the returned value or unknown boundary without causal inference
- AND send no candidate input on unknown readiness and require protected recovery
unverified
PID1 return and first userspace syscall have bounded optional witnesses
why it is unverified source/controller/native/parent-header objects are independently reviewed; full matching artifact qualification and physical two-point behavior remain unverified.
An additive default-disabled child of the selected init exec-return diagnostic SHALL preserve the parent record and offer at most two additional fixed versioned INFO records, scoped to armed PID1: after kernel_init returns before user-exit preparation, and after successful syscall entry from user mode before dispatch. The arm SHALL be set only for selected ramdisk exec success with both exact parent and transition runtime gates enabled. Ordinary-lifetime exact1 gate and consumed-before-output one-shots SHALL prevent fallback/task/ retry output. The diagnostic SHALL NOT modify init/argv/env, return values, assembly/sret, IRQ/timer/vector/exit-work state or existing Nix output identities.
A typed begin-only selection SHALL require exact parent/new gates, synchronous initramfs and marker-free ordinary init, reject conflicting/invalid selection before UART, and require independently reviewed source/context/object plus actual build/config/DT/archive/arguments/manifest qualification. Records SHALL be fresh and strictly ordered among present records; duplicates, malformed or reversed observations SHALL fail closed. Missing earlier frames SHALL remain incomplete/unknown without negating an independently valid later user ECALL witness or fabricating missing observations. The physical capture SHALL preserve complete private logging, protected staging/normal/load/CRC guards,180-second passive readiness and unknown no-input behavior. Recovery SHALL be independently verified or explicitly pending NEW reset. Ordinary root/panel/glass acceptance SHALL remain separate.
evidence in this repository scenarios Kernel init returns before entering userspace
- WHEN a qualified capture records kernel-init-return after exec-result0
- THEN record that the original kernel_init and exec-result output call returned
- AND retain the new output-call-return and user-execution unknowns
PID1 executes a userspace environment call
- WHEN a qualified capture records a valid first-user-ecall witness
- THEN record a user ECALL instruction and successful kernel entry setup
- AND retain missing earlier records as incomplete/unknown plus syscall completion, loader/constructors/systemd-main and cause limits
A planned witness is missing or invalid
- WHEN qualified progress or record validity is absent
- THEN preserve the unknown boundary without candidate input or compensating changes
- AND require independent protected recovery or a NEW operator reset
grounded
Every mainline kernel variant carries the proven clock and firewall fixes
Each mainline kernel the repository builds (console and DRM) SHALL keep running the clocks that physical bisection showed the SoC needs (spi2axi, the display DDR port vpu_ddrcp2) and SHALL carry the same firewall kernel configuration as the vendor kernel. The protected normal system is not changed by this.
evidence in this repository scenarios Console mainline boot survives unused-clock cleanup
- WHEN an operator boots the console mainline variant through the guarded trial with ordinary clock cleanup - THEN the serial console reaches a qualified root login, as the DRM variant already does Grounding: observed on hardware 2026-10-06 (docs/evidence/mainline-shell-parity-2026-10-06/README.md): console variant qualified login with cleanup, then rebooted itself to normal.
Firewall unit starts on mainline
- WHEN the full mainline shell boots - THEN systemctl is-active firewall reports active on the serial console Grounding: observed on hardware 2026-10-06 (docs/evidence/mainline-shell-parity-2026-10-06/README.md): firewall active on the full mainline shell.
grounded
The K230 clock gates match the vendor register map
Every mainline gate SHALL use the register bit the vendor clock tree uses, and any deliberate difference (a bit the vendor shares between clocks, or a vendor gate mainline leaves unmodelled) SHALL be recorded with the reason, so a driver claiming one clock cannot silently change another device.
evidence in this repository scenarios Comparison is committed
- WHEN a reader opens the committed vendor-versus-mainline gate comparison - THEN every gate shows matching register and bit, or a recorded reason: usb_480m/usb_100m share 0x100 bit 0 exactly as the vendor usb_clk480/usb_clk100 do; the display clkext gate (0x74 bit 5) stays unmodelled because no Linux consumer exists and modelling it would expose it to unused-clock cleanup Grounding: read from source 2026-10-06 (docs/research/k230-clock-gates-vendor-vs-mainline.md): mainline clk-k230.c against the vendor k230_clock_provider.dtsi, matched by register and bit.
grounded
SoC temperature is readable under mainline
The mainline kernel SHALL expose the K230 thermal sensor so that a person at the console can read the SoC temperature, matching the vendor kernel's reading within the sensor's resolution.
evidence in this repository scenarios Temperature reads back
- WHEN an operator reads the thermal zone on the mainline shell - THEN a plausible SoC temperature is reported and it changes under load Grounding: observed on hardware 2026-10-06 (docs/evidence/mainline-shell-parity-2026-10-06/README.md): 52.4 °C idle, 54.5 °C after 60 s load (vendor driver reports raw codes).
grounded
Remaining vendor-only drivers have a recorded disposition
ADC, PWM and crypto SHALL each be recorded as forward-ported, or as an explicit non-goal naming which shipped service would need them; none may be silently absent.
evidence in this repository scenarios Inventory lists each driver's disposition
- WHEN a reader opens the mainline driver inventory - THEN ADC, PWM and crypto each show ported or non-goal with a reason and date Grounding: read from the repository 2026-10-06 (docs/research/mainline-kernel-inventory.md): no shipped unit, package or tool consumes ADC, PWM or the crypto engine.
grounded
The board boots the mainline kernel by default with a proven way back
Powering on or rebooting the board SHALL boot the mainline kernel and the full coherent shell without operator intervention, and the vendor 6.6 kernel SHALL remain restorable as the default by a recorded, tested rollback.
evidence in this repository scenarios Power-on reaches the shell on mainline
- WHEN the board is reset or rebooted after installation - THEN the serial console reports kernel 7.3.0-rc5, the installed mainline system is booted, and the shell services are active with no failed units Grounding: observed on hardware 2026-10-07/08 (docs/evidence/mainline-default-boot/README.md): ordinary reboot after install and after reinstall, and one reset-button power-on (reset-button-postboot.json), each 7.3.0-rc5, mainline system/profile, three services active, running, no failed units.
Rollback restores the vendor kernel
- WHEN the operator runs the installer's rollback and reboots - THEN the board boots the vendor 6.6 kernel with the previous system and boot files byte-identical to their recorded backups Grounding: observed on hardware 2026-10-07 (docs/evidence/mainline-default-boot/README.md): install.py rollback PASS with every restored file re-hashed against its backup, then an ordinary boot on 6.6.36 with the vendor profile.
This selection is board state installed from .#kernelMainlineDrmShellBootFiles; .#sdImage ships the same mainline system for freshly flashed cards.
grounded
SD storage under mainline runs at the vendor kernel's card clock
Under the mainline kernel, the SD card and the SDIO radio SHALL be clocked at the same card-clock rate the vendor kernel uses (High-Speed, 50 MHz actual), and every SD controller clock gate SHALL stay claimed by its driver.
evidence in this repository scenarios Sequential reads match vendor throughput
- WHEN an operator runs dd if=/dev/mmcblk1 of=/dev/null bs=4M count=32 iflag=direct on the installed mainline system - THEN /sys/kernel/debug/mmc1/ios reports an actual clock of 50000000 Hz and the read rate is within 15% of the vendor kernel's 23.3 MB/s on the same card Grounding: observed on hardware 2026-10-08 (docs/evidence/mainline-sd-throughput/README.md): 50000000 Hz actual on mmc0/mmc1, 23.8 MB/s (trial) and 23.4 MB/s (installed) vs vendor 23.3 MB/s; all ten SD gates enabled.
Wi-Fi still associates over SDIO
- WHEN the mainline system with the new SD clocks boots and Wi-Fi is enabled - THEN the RTL8189FTV interface associates and obtains an address Grounding: observed on hardware 2026-10-08 (docs/evidence/mainline-sd-throughput/README.md): wlan0 associated with an IPv4 address on trial and installed boots.
grounded
The flashable default image ships the mainline coherent shell
nix build .#sdImage SHALL produce a card image whose root holds the k230-mainline-drm-shell system and whose boot partition holds that system's mainline kernel, its initrd, and the mainline DRM device tree under the filename stage 1 loads, with stage 1 unchanged.
evidence in this repository scenarios Host inspection of the built image
- WHEN someone builds .#sdImage and inspects its boot partition - THEN Image is the mainline 7.3.0-rc5 kernel of k230-mainline-drm-shell, k230-tdisplay.dtb carries the mainline DRM tree with /chosen/bootargs selecting that system's init, and the stage-1 slots match .#stage1 Grounding: host inspection 2026-10-08 (docs/evidence/mainline-sd-image/host-inspection.json): boot Image/initrd.uimg byte-identical to the installed mainline bundle, DTB /chosen/bootargs init selects kp6ldmdx…, stage-1 slots equal .#stage1.
A freshly flashed card boots to the shell
- WHEN the image is flashed to a card and the board is powered on - THEN the serial console reports kernel 7.3.0-rc5 and the shell services become active Grounding: observed on hardware 2026-10-08 (docs/evidence/mainline-sd-image/README.md): flashed over U-Boot ums, first power-on reached login on 7.3.0-rc5 with the three shell services active and no failed units.
grounded
The ordinary system exposes proven vector execution with a scalar fallback
The system SHALL include a matching vector-capable kernel, modules, initrd and userspace renderer in its ordinary image. The renderer SHALL require the running kernel's vector capability before executing vector instructions and SHALL retain scalar fallback and a runtime disable control. The system SHALL record exact artifact and runtime identities; a processor name, device-tree string, host build or emulated run SHALL NOT replace physical default-image proof.
evidence in this repository scenarios A person starts the ordinary system on the board
- WHEN the ordinary image boots and reports vector capability
- THEN representative vector state preservation and exact declared pixel cases are observed on the physical board
- AND the recorded renderer identity shows runtime-gated vector dispatch
Vector capability is unavailable
- WHEN the kernel does not report usable vectors or the operator disables vector dispatch
- THEN the renderer uses its scalar path without requiring vector execution
- AND that fallback remains visible in the recorded result
unverified
Extension enablement follows an auditable evidence boundary
why it is unverified no reason given
Partial grounding: the pinned vendor arch/riscv/boot/dts/canaan/k230.dtsi lists base, vector, bit-manipulation, cache-block and supervisor extensions; docs/evidence/card-shell/kernel-rvv/board-trial/boot1-selected.log reports base acdfimv on this board. docs/evidence/cpu-extensions/README.md records the inventory and decisions, and docs/evidence/cpu-extensions/installed-mainline-2026-10-11/README.md records physical Zba/Zbb/Zbc/Zbs single-opcode execution on the mainline system. Safe default use of every listed extension remains .
The system SHALL inventory useful CPU extensions named by its pinned device tree and relevant firmware, kernel, toolchain and library support. Each enabled non-baseline userspace instruction path SHALL have a supported execution environment, an appropriate runtime gate or explicit hardware restriction, and representative physical verification. The inventory SHALL explain exclusions and distinguish standard userspace instructions from privileged features, hints, and vendor-specific or version-dependent instructions. Unknown support SHALL remain explicitly unverified rather than trigger a global ISA build flag.
evidence in this repository scenarios Someone reviews an extension proposed for the ordinary image
- WHEN an extension is proposed for a kernel, toolchain or library path
- THEN its source declaration, execution privilege, runtime evidence, enablement layer and exclusion or inclusion reason are recorded
An extension is not yet physically grounded
- WHEN source or emulation evidence exists without safe physical execution evidence
- THEN the inventory marks that extension unverified for default userspace use
- AND the ordinary image does not require it to boot
unverified
Default vector deployment retains a recovery route and honest workload results
why it is unverified no reason given
The system SHALL reach a persistent vector-capable image only through a deployment that preserves a known-good rollback selection and protected boot data. It SHALL record representative console, shell, network and card workload results on the installed image without relaxing existing card budgets or calling an unproved speedup accepted. The preserved rollback route SHALL be checked and recorded on the board.
evidence in this repository scenarios The vector image is evaluated
- WHEN the vector-capable ordinary image runs on the physical board
- THEN its exact artifacts, observed boot and representative workloads are recorded
- AND any failing budget or interaction remains visible
The vector image must be abandoned
- WHEN the operator needs to return to the preserved earlier selection
- THEN the rollback roots, staged boot-file backups and protected boot hashes it depends on have been recorded as intact