Pi5 resource appliance

A Raspberry Pi 5 can network-boot directly into custom aarch64-unknown-none fabricBIOS firmware and become a small resource appliance. There is no Linux kernel or target-side daemon in this path. The firmware authenticates itself and its callers, reports real memory, CPU, and block capacity, grants exact leases, serves lease-bound data paths, and tears them down or fences them when cleanup cannot be confirmed.

grafOS remains the layer above it. grafOS constructs the application graph, chooses placement, reacts to thermal and provider events, stages replacement work, and explains graph rewrites. The firmware reports and enforces; it does not quietly acquire scheduling policy.

What the physical proof covers

The current two-board proof uses immutable production firmware, DHCP/TFTP, durable provisioned node identities, exact server-certificate pins, controller mTLS, and two distinct workload principals. One bounded transaction proves:

• truthful MEM, CPU, and BLOCK inventory;
• six concurrent leases, three for each workload principal;
• byte-exact memory I/O, deterministic CPU tasklets, and block checkpoint/readback;
• typed cross-principal denial without capacity or peer-data mutation;
• a checked eight-node, twelve-port, six-edge grafOS application graph;
• synchronous revoke and the first denied data-plane operation as separate observations;
• expiry, bounded grace, same-lease resurrection, and terminal cleanup;
• thermal-policy handoff in which authenticated firmware telemetry changes grafOS placement;
• stable durable identity and stale-authority denial after provider reboot; and
• exact reverse cleanup or an explicit fence, checksum-closed evidence, and final power-off.

The teardown-failure arm exercises the real BLOCK cleanup path. The firmware returns a typed fenced outcome, denies subsequent data-plane access, and removes exactly the failed 4 KiB extent from admission while sibling resources remain available. A verified reboot restores that boot-local quarantine. This is the practical meaning of the fabricBIOS teardown-or-fence contract: an ambiguous release never becomes reusable capacity.

Measured envelope

The first quantitative release used three Raspberry Pi 5 boot samples and a separate same-source two-board revoke/recovery run. With only three samples, the values below are observations, not adopted service-level budgets.

Measurement	Observed median
Production firmware image	3,051,560 bytes
Bootloader DHCP from pre-power marker	28.549 s
Firmware DHCP after TFTP	43.360 s
Authenticated service from pre-power marker	53.808 s
Established-connection PING	9.566 ms
Lease allocation	30.318 ms
Lease free	13.349 ms
Allocator heap high-water	52,059 bytes
Revoke acknowledgement	18.685 ms median across BLOCK, CPU, and MEM
Controlled provider recovery	80.219 s for one observation

The provider-recovery interval includes the deliberate five-second power-off, switch execution, bootloader/TFTP/firmware work, and a two-second verifier polling floor. The revoke-to-denial experiment is an upper-bound sequential probe, not an internal enforcement timestamp or p99. Power is reported as unavailable because the switch has no calibrated per-port measurement source; the proof does not estimate it.

Reproduction surfaces

The first-party lab entry point is:

scripts/lab appliance pi-4 pi-5 --evidence-dir /tmp/pi5-appliance
scripts/lab evidence verify /tmp/pi5-appliance --json

Provider reboot, teardown-fence, lease-grace, and calibrated thermal acts are separate options because they have distinct starting conditions and failure semantics. The command owns deployment, strict preflight, bounded execution, evidence capture, reverse cleanup, and final power state. It refuses dirty source, insecure profiles, stale or hot telemetry, uncertain cleanup, and weaker fallback paths.

A one-board external evaluator is also implemented. Its build accepts only the evaluator’s public provisioning root, compiles a root-bound production image, signs the exact bundle with the Tenura release identity, and verifies a draft release after downloading it again. The evaluator keeps the provisioning private key. Ordinary success uses DHCP/TFTP and exact mTLS pins without Tenura’s internal hostnames, managed switch, or UART.

That external workflow has not yet produced an independent result. The current physical results are first-party lab evidence, not design-partner or production-deployment evidence. The source repositories and release surface are also currently private, so distribution is authenticated rather than an anonymous public download.

What this does not claim

• Raspberry Pi inference throughput is not production accelerator performance. The firmware has generated a bounded SmolLM2 token sequence, but that is a portability and mechanism proof.
• Thermal handoff is workload handoff, not opaque process-memory migration.
• Controlled provider reboot after cleanup is not recovery from abrupt loss during I/O. Live provider-loss graph recomposition is the next proof.
• The current evidence is not a hardware-rooted measured-boot attestation.
• Fanless boards report passive cooling. No active-fan capability is inferred.

For the normative contracts, continue with the fabricBIOS v1.1 specification, wire encoding, and fabricBIOS vs grafOS.