admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FABRIC-2.md Sections W/X: correct execution order -- validate Artemis

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-08-22 07:15:05 -04:00
co-authored by Claude Sonnet 5
parent 1a6b164fdc
commit d33b68b2d5
1 changed files with 41 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC-2.md
+41 -24
View File
@@ -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)