From e5e28d5198a13d766f065ec8640a40a0b1dd0683 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Fri, 4 Sep 2026 12:27:38 -0400 Subject: [PATCH] FABRIC-3.md: amd64 bare-metal-boot planning decided + punch list Decisions from conversation: observation is HDMI (interactive) + serial via the Raspberry Pi's own GPIO UART as the bridge, if the SER5 exposes a UART header (not yet confirmed); genericity is verified by a code audit against real UEFI/ACPI standards rather than a second physical machine (none available); Secure Boot is already disabled on this SER5, so no signed-loader work is needed for this pass. 9-item punch list follows: build+flash the thumbdrive image, physically inspect for a UART header, connect HDMI, boot, a code-audit pass for SER5-specific assumptions (the actual genericity bar), capture the boot (POST/ok>/rdrand backend/serial transcript), mint+re-attach Zuse on real hardware, then update this section with results before moving to aarch64. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var --- FABRIC-3.md | 48 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 39 insertions(+), 9 deletions(-) diff --git a/FABRIC-3.md b/FABRIC-3.md index 0eeab57..acd7a59 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -162,15 +162,45 @@ what's still genuinely unknown, not assumed. `ok>`, document) is the closest thing to an existing plan — but it predates the genericity requirement and was written with no hardware in hand yet. -**Genuinely open, not yet decided:** -- What "generic enough" actually needs to be verified against, beyond the SER5 — is there a - second, different machine available to cross-check against, or does genericity get argued - from firmware-standards-compliance (real UEFI, no vendor-specific assumptions in the boot - code) rather than a second physical test right away? -- Observation method for a headless/serial-less real machine (no QMP/serial socket the way - QEMU gives us) — HDMI + keyboard? A serial console cable if the board exposes UART pins? -- Whether Secure Boot needs handling, and how, on real UEFI firmware (QEMU/OVMF's own Secure - Boot behavior may not match every real vendor's). +**Decided in conversation, 2026-09-04:** +- **Observation: HDMI (interactive) + serial (logged transcript), both.** The kernel's own + VT100 framebuffer console (`console.c`/`vt100.c`/`framebuffer.c`) already gives a real + interactive display over HDMI — no new code needed there. Serial capture, if the SER5 + exposes a UART header, uses the Raspberry Pi's own GPIO UART as the USB-serial bridge + (already available hardware, not a purchase blocker) — this needs the SER5's own UART pins + physically identified first (not yet confirmed it has an accessible header at all). +- **Genericity is verified by standards-compliance, not a second machine** — no second x86_64 + box is available right now. The bar is: nothing in the boot path may depend on an + SER5-specific assumption (a particular ACPI table shape, a specific UEFI implementation's + quirk) — argued by code audit against real UEFI/ACPI standards, not by testing on a second + board, until one becomes available. This is a real constraint on the punch list below (item + 6), not a deferred nice-to-have. +- **Secure Boot: already disabled on this SER5.** No signed-loader work needed for this pass — + "Secure Boot disabled in firmware setup" is the supported path, documented as such rather + than built around. + +**Punch list, this cadence's actual next steps:** +1. Build the generic thumbdrive image: `make -f Makefile.starkernel ARCH=amd64 thumbdrive`. +2. Flash it to a USB stick (`dd`, per the target's own existing usage message). +3. Physically inspect the SER5 for an exposed UART header/pins; if present, wire the + Raspberry Pi's GPIO UART to it as the serial bridge. If absent, HDMI-only for this pass — + not a blocker, just a scope note for step 7's log. +4. Connect HDMI + keyboard to the SER5. +5. Boot the SER5 from the flashed stick (firmware boot-order menu as needed — Secure Boot + already disabled, confirmed above, so no signing prompt expected). +6. **Code audit pass** (can happen before or in parallel with 1–5, doesn't need the hardware + in hand): review the amd64 boot path (`src/starkernel/boot/uefi_loader.c`, + `arch/amd64/*.c`) for anything that assumes SER5-specific hardware rather than standard + UEFI/ACPI — this is what "genericity" actually rests on per the decision above, not the + SER5 boot succeeding alone. +7. Capture the boot: confirm POST reaches the same `1012/0/0` result QEMU shows, confirm + `ok>`/`zuse)ok>`, confirm `rng: backend = rdrand` (live entropy, not the QEMU-only + `virtio-rng` path), save the serial transcript (if wired) the same way `logs/` already + keeps QEMU's. +8. Mint a Zuse identity on a second thumbdrive on the real SER5, confirm it re-attaches — + the same real-hardware round-trip `ROADMAP.md`'s `v2.2.0` gate already names. +9. Update this section with results — pass/fail per step, any SER5-specific or genuinely + generic-UEFI finding either way, before moving to aarch64. ## IV. aarch64 — Raspberry Pi 5