From d33b68b2d55d532bb261a8d9d7056c6913c26303 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Sat, 22 Aug 2026 07:15:05 -0400 Subject: [PATCH] FABRIC-2.md Sections W/X: correct execution order -- validate Artemis in QEMU first, defer real-hardware USB boot to last; add UEFI-only boot-path constraint Captain Bob's explicit correction: real-hardware boot is "difficult and lots of blind guesswork" (no serial log, unknown firmware quirks) and isn't worth attempting until there's a working Artemis subsystem to actually demonstrate, not just an empty kernel proving UEFI boot works. QEMU's own USB hotplug emulation is sufficient to build and validate the entire home-blocks subsystem without touching real hardware at all. Milestone IDs in Section X kept stable (not renumbered, to avoid breaking cross-references between milestones) with an explicit execution-order note instead: 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 1, networking (9) still deferred past all of them. New scope constraint captured for whenever Milestone 1 resumes: UEFI- only boot path, no legacy BIOS/MBR, no GRUB2 -- starkernel_loader.efi is meant to be the entire boot path, not one stage in a longer chain. Co-Authored-By: Claude Sonnet 5 --- FABRIC-2.md | 65 +++++++++++++++++++++++++++++++++-------------------- 1 file changed, 41 insertions(+), 24 deletions(-) diff --git a/FABRIC-2.md b/FABRIC-2.md index 508a529..918b961 100644 --- a/FABRIC-2.md +++ b/FABRIC-2.md @@ -2945,23 +2945,29 @@ overwritten; the zuse credential, once minted, can never be re-minted. | Install path ("install it") | area H | ❌ not started, explicitly deferred — "not that risky yet" | | QEMU monitor socket (dev iteration) | area B | ❌ one-line gap, not blocking | -**Sequencing, as currently stated across the whole conversation, nearest-term first:** +**Sequencing — corrected 2026-08-22, real-hardware boot moved to last, not first.** +Captain Bob's explicit call, reversing this section's original draft order: get Artemis (the +actual home-blocks/USB subsystem) working and validated **inside QEMU first** — real-hardware +boot is "difficult and lots of blind guesswork" (no serial log, unknown firmware quirks, +Secure Boot variance — the exact caveats this section already listed as real, now treated as +reason to defer rather than a footnote) and isn't worth attempting until there's something +real to boot *into*, not just an empty kernel proving UEFI boot works at all. -1. **Bare-metal boot from a physical USB stick, demo/"try it" mode only — the actual next - milestone**, confirmed this session as *not* gated on the USB-hardware-driver gap above. - Booting *from* USB is a UEFI firmware responsibility, not a kernel one — the same - `starkernel.iso` (amd64/aarch64, El Torito) or raw disk image (riscv64) already rebuilt on - every QEMU launch this session is, mechanically, the artifact to `dd` onto a physical drive. - Two 64GB SanDisk drives are on hand and available right now for this; one currently carries - a Kubuntu 26.04-era live ISO, re-flashable without loss (re-downloadable). Real-hardware - UEFI firmware varies from QEMU's OVMF, so the first real boot is a genuine test, not a - formality — noted, not treated as a blocker. -2. Everything in this section's component table below the live-boot-ISO row — the actual - home-blocks/thumbdrive-as-persistent-identity-storage subsystem — waits on the USB - hardware driver (area B), which is the honest, singular hard prerequisite once milestone 1 - is done. -3. Contributor capsules/trust tiers, explicitly sequenced after the ACL/PKI work closes. -4. Networking (capsule distribution server, WiFi), explicitly sequenced after that. +1. **USB hardware stack (Milestone 3) and the rest of the Artemis subsystem (Milestones + 4-8), built and validated entirely in QEMU** — QEMU's own USB hotplug emulation + (`device_add`/`device_del` via the QMP socket, Milestone 2) is sufficient to build and test + all of it without touching real hardware at all. This is now the actual near-term work. +2. Contributor capsules/trust tiers, still explicitly sequenced after the ACL/PKI work closes. +3. Networking (capsule distribution server, WiFi), still sequenced after that. +4. **Bare-metal boot from a physical USB stick (demo/"try it" mode) — moved to last, not + first.** Still confirmed not *technically* gated on the USB-hardware-driver work (booting + *from* USB is UEFI's job, not the kernel's), but no longer worth doing until there's a + working Artemis subsystem to actually demonstrate. **Added scope constraint for whenever + this does happen: the boot path must be UEFI-only — no legacy BIOS/MBR support, no GRUB2 + or any other bootloader in the chain.** The existing `starkernel_loader.efi` is meant to be + the entire boot path, generic and minimal, not one stage in a longer chain. Two 64GB + SanDisk drives remain on hand and available whenever this gets picked back up; one + currently carries a Kubuntu 26.04-era live ISO, re-flashable without loss. Not started: no code, no capsule work, no hardware testing yet. This section exists so a future session (or Captain Bob re-reading cold) gets the whole shape in one read, rather than @@ -2972,17 +2978,28 @@ needing to reconstruct it by reading U, V, and this section's own cross-referenc ## X. Artemis punch list — deep detail, one task at a time, 2026-08-22 Requested explicitly: deep, function-level granularity, no code written yet — this is the -task breakdown only. Organized by milestone, in the sequence Section W established. Each -milestone is independently checkable off; sub-items within a milestone are ordered (later -items generally depend on earlier ones in the same milestone unless noted). `[ ]` = not -started, matching this file's existing convention (Section F). Where a task genuinely needs -spec research before it can even be scoped precisely (mostly in Milestone 3, USB hardware), -the research step is its own punch-list item rather than skipped. +task breakdown only. Each milestone is independently checkable off; sub-items within a +milestone are ordered (later items generally depend on earlier ones in the same milestone +unless noted). `[ ]` = not started, matching this file's existing convention (Section F). +Where a task genuinely needs spec research before it can even be scoped precisely (mostly in +Milestone 3, USB hardware), the research step is its own punch-list item rather than skipped. + +**Execution order — corrected same day, see Section W's sequencing update.** Milestone +numbers below are stable IDs (kept as originally assigned so cross-references between +milestones stay valid), *not* execution order. Real-hardware boot (Milestone 1) moved to +**last** — build and validate Artemis entirely in QEMU first. Actual order to work through: +**2 → 3 → 4 → 5 → 6 → 7 → 8 → 1**, with Milestone 9 (networking) deferred past all of them per +its own section below. ### Milestone 1 — Bare-metal boot from physical USB (demo/"try it" mode) -Confirmed not gated on any other milestone below (Section W). Smallest, nearest-term, -actionable now. +**Deferred to last, not first — see the execution-order note above.** Technically not gated +on any milestone below (booting from USB is UEFI's job, not the kernel's), but deliberately +not attempted until Milestones 2-8 give it something real to demonstrate; real-hardware boot +is "difficult and lots of blind guesswork" and not worth the detour yet. **Scope constraint +for whenever this resumes: UEFI-only boot path, no legacy BIOS/MBR support, no GRUB2 or any +other bootloader in the chain** — `starkernel_loader.efi` is meant to be the entire boot path, +generic and minimal, not one stage in a longer one. - [ ] Confirm which physical machine will receive the first real-hardware boot test (CPU arch — amd64 assumed given the SanDisk drives on hand, but confirm)