rajames/LithosAnanke
1
1
Fork 0
Code Issues 41 Pull Requests Actions Packages Projects Releases Activity

feat(kernel): Artemis and Zuse from one disk -- the stick; virtio Artemis leaves v4

Browse Source 
sk_v4_identity.c: a USB drive is this system's stick if its GPT has both StarshipOS partitions and
it is the disk the loader booted from (BootDisk's DiskGUID), or, when the boot was not from a
stick, the first such disk while none is attached. Then: its Artemis partition must carry a good
artemis_sig ('Artemis: the stick's signature is bad -- not used' otherwise), is attached first --
the first disk slot -- ('Artemis: the stick's partition attached'), Zuse's key is read from its
genesis marker, and its identity partition is checked and attached as before. Any other drive,
raw or GPT: 'USB: a drive that is not this system's stick -- not used'. On a pull the identity
partition is detached, then Artemis. sk_v4_identity_boot / sk_v4_run take the loader's BootDisk.
kernel_main.c: no virtio Artemis on the v4 path. kernel/Makefile: ARTDISK= attaches no virtio disk
(every QEMU target); ARTDISK stays for system=v3.

STICK.md 4 amended as ruled (R2): on v4 only this system's stick is used; users' drives minted by
this system's Zuse come with the users design after INSTALL. BRINGUP.md: Secure Boot off on every
PC (ruled 2026-10-28), RDRAND in QEMU, the SER5 smoke-test stick, A4 not on v4.

Tests: new stick_artemis (x3, no virtio disk), stick_zuse, two_sticks (replaces datastick),
artemis_unsigned, raw_ident; changed stick_boot, gpt_zuse, gpt_hotplug, midpull (replug) -- all
failed before, pass after (two test defects found and fixed: the signature's offset, the 63-char
log cut). Regression 20/20. Acceptance: amd64, aarch64, riscv64 to [zuse@Hera] ok>, POST 538/538,
dict_hash 0xfec8c47cfc6f437f; v4 suite and test-32 0 failures.

Plan: docs/v4.0.0/plans/2026-10-27-stick-4-one-disk.md, Task 4.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
rajames
2026-10-28 16:10:33 -04:00
co-authored by Claude Opus 5.5
parent 1b45f5f85f
commit 1e8a6fed34
99 changed files with 16418 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files
boards/BRINGUP.md
+12 -3
View File
@@ -26,7 +26,7 @@ None has been fixed: each needs your word.
| A1 | **Fixed 2026-10-14.** The USB controller was matched by QEMU's own IDs (`1B36:000D`) on PCI bus 0 alone. Now: found by its PCI class (`0C/03/30`) on any bus, slot and function; its register window mapped at the size its BAR reports; taken from the firmware through the USB Legacy Support capability (SMIs off); and 64-byte contexts (`CSZ=1`, common on real controllers) laid out instead of refused. Every controller is driven, up to 8 (since 2026-10-14, `FABRIC-3.md` XLII): a stick or keyboard may be in any port. | `kernel/src/usb/xhci.c`, `kernel/src/pci/pci.c`; `FABRIC-3.md` XL | Rehearsed in QEMU with another vendor's controller behind a bridge, all three ISAs. Not rehearsable: the firmware handoff and 64-byte contexts (QEMU's controller has neither). |
| A2 | **No prompt without a login.** The production default, `EMERGENCY_CONSOLE_ENABLED=n`, keeps the system headless until an identity logs in by thumbdrive. | `Kconfig.heartbeat:68`; `FABRIC-3.md` VIII.1 | With A1, the v3 system never shows a prompt on hardware. A bring-up build must set `EMERGENCY_CONSOLE_ENABLED=1`. |
| A3 | **Fixed 2026-10-14.** A USB boot-protocol keyboard is driven (xHCI interrupt endpoint, `SET_PROTOCOL(boot)`), its reports become the same key events as the PS/2 and virtio keyboards, and the console treats a full keyboard as one: Caps Lock and Num Lock as toggles shown on the keyboard's lights, the keypad as digits or navigation, the arrows and navigation block mapped (the line editor itself still has no cursor movement). While a USB keyboard runs, the console services its reports every timer tick. | `kernel/src/usb/usb_kbd.c`, `kernel/src/usb/xhci.c`, `kernel/src/repl.c`; `FABRIC-3.md` XLI | Rehearsed in QEMU on all three ISAs; on amd64 with the USB keyboard the only keyboard. Limits: a keyboard whose first interface is not the keyboard is not used; no key repeat. Several keyboards, on any controllers, each its own. |
| A4 | **The only disk driver is virtio.** | `kernel/src/virtio/virtio_blk.c`; `kernel_main.c:493` | On hardware Artemis finds no disk ("Artemis: no virtio-blk disk"). What the fleet then does has not been tried even in QEMU: see step 3.3. |
| A4 | **The only disk driver is virtio** (v3). Since 2026-10-28 the v4 boot takes Artemis from the stick over USB, not from virtio (`docs/v4.0.0/STICK.md` §4): on v4, A4 no longer applies. | `kernel/src/virtio/virtio_blk.c`; `kernel_main.c:493` | On hardware Artemis finds no disk ("Artemis: no virtio-blk disk"). What the fleet then does has not been tried even in QEMU: see step 3.3. |
| A5 | **Entropy:** RDRAND on amd64 only. aarch64 and riscv64 have virtio-rng alone. | `kernel/src/rng/rng.c` | Pi 5 and Mars print the "no entropy backend available" warning; anything that needs random bytes is refused. Minting needs them. |
| A6 | **Fixed 2026-10-14.** Every board image carries both systems, v3 and v4, and the boot arguments choose: `system=v4` (as built: v4 is the default) or `system=v3` -- one word in `starforth.cfg` on the SER5's and the Mars's stick or card, in `cmdline.txt` on the Pi 5's card. No rebuild to switch. | root `Makefile`, `kernel/Makefile`, `kernel/src/kernel_main.c`, `kernel/src/boot/cmdline.c`; `FABRIC-3.md` XLIII | The SER5 image itself, booted under OVMF: v3 as built, v4 after the one-word edit. The boot says which system runs and why ("System: ..."). |
@@ -112,7 +112,9 @@ In this order, each as a design for approval first:
**To know before starting**
- [ ] SER5: Secure Boot is off (`FABRIC-3.md` III says it is on this unit); which key opens
the firmware's boot menu; whether there is a serial header.
the firmware's boot menu; whether there is a serial header. **Secure Boot stays off for
every PC** (Captain Bob, 2026-10-28): the stick's loader is unsigned, and the user
instructions say to turn Secure Boot off; there is no shim and no Microsoft signing.
- [ ] Pi 5: the EEPROM firmware is recent enough to honour `kernel_address` and `os_check`
(boot Raspberry Pi OS once and note the version).
- [ ] Mars: the SPI flash holds a U-Boot that scans the SD card for an EFI loader; the boot
@@ -195,7 +197,14 @@ the one QEMU exercises most closely, and the Pi 5's can be rehearsed only in par
- [ ] Watch for, in order: `StarKernel UEFI Loader`; `GOP: linear framebuffer found`;
`LithosAnanke v...`; `PMM initialized.`; `VMM initialized`; `APIC: init done`;
`Timer: init done`; `Kernel heap initialized.`; `Stadium: ...`; POST; the verdict lines.
- [ ] `rng: backend = rdrand`. In QEMU it says `virtio-rng`; this line is new on hardware.
- [ ] `rng: backend = rdrand`, as in QEMU since 2026-10-28 (amd64 QEMU runs `+rdrand` and has
no virtio-rng).
- [ ] **The smoke test's stick** (2026-10-28, after the stick's increment 4): `make boot_image
TARGET=PC STICK_PAIR=disk/zuse-scratch`, Zuse's minted pair in the stick's partitions;
`system=v4 screen=boot` in its `starforth.cfg` once `screen=boot` exists (increment 4,
Task 5). Watch for `Boot disk: a StarshipOS stick`, `Artemis: the stick's partition
attached`, then `[zuse@Hera] ok>`. The same image boots in QEMU first:
`make -f kernel/Makefile ARCH=amd64 qemu-stick STICK_PAIR=disk/zuse-scratch`.
- [ ] The timer lines differ from QEMU's by design: no hypervisor, so the HPET path runs for
the first time. S1 is the finding to remember if it stops there.