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

Compare commits

base: admin/LithosAnanake:09857b7228d52df70f2bf8cfb6ac0a804b9d8e87
Branches Tags
admin/LithosAnanake:master admin/LithosAnanake:v2.0.1
admin/LithosAnanake:v2.0.0
...
compare: admin/LithosAnanake:master
Branches Tags
admin/LithosAnanake:master admin/LithosAnanake:v2.0.1
admin/LithosAnanake:v2.0.0
109 Commits
09857b7228 ... master
Author SHA1 Message Date
Robert Allan JamesandClaude Sonnet 5 63b8b3bc29 Migrate Hera->Artemis storage-attach to a real message round-trip
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Hera still polls xHCI and sig-checks attached drives, but the storage
registration step (blk_subsys_attach_device(), now wrapped as the
BLK-ATTACH primitive) moves to Artemis's own dictionary, reached via
HERA-BLK-ATTACH-REQ/BLK-ATTACH-ACK (VM-EXEC, since Hera can't load her
own messaging.4th -- see the doc comment in repl.c). Identity birth
(Zuse genesis / WIREBIND) is deferred until the ack confirms storage
actually succeeded, instead of running synchronously underneath a
storage call that might fail ("wait for ack, safer for identity data").

Caught and fixed a real bug live during acceptance testing: Artemis's
ACK-APPEND-NUM fed a single-cell value into <# #S #> (which expects a
double-cell pair), causing a stack underflow the first time
HERA-BLK-ATTACH-REQ ran. Fixed with the same `0 SWAP` convention every
other numeric-append helper in this codebase already uses.

Verified booting clean to (zuse) ok> with no VM-EXEC errors on all
three architectures (amd64/aarch64/riscv64).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
 2026-09-07 21:22:04 -04:00
Robert Allan JamesandClaude Sonnet 5 c4f94c409f FABRIC-2.md: update stale MSGMIGRATE tracking node 
Console→user-VM command relay is already real messaging (repl.c:971,
a genuine CONSOLE-CMD-EVENT/MSG-SEND), not hardwired -- this predates
today but the tracking graph still marked the whole node unstarted.
Updated to PARTIAL, with the real remaining gap (attach detection/
verify/birth is still 100% hardwired) and the documented fallback
(relay skips a line containing a double-quote character, repl.c:962-965)
both called out explicitly. Found via a research pass auditing
messaging.4th and the current hardwired-vs-messaged boundary, prompted
by Captain Bob's "get Hermes nailed down" -- Hermes/Artemis themselves
are already equally wired and session-less, not the actual gap.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
 2026-09-07 19:51:25 -04:00
Robert Allan JamesandClaude Sonnet 5 f4ded3e1a8 MINT: add a FORTH-79/83-standard-words-only lockdown personality 
Captain Bob, 2026-09-07: "starting with that 00 user we created, we're
going to give access only to FORTH 79 and 83 standard words. everything
else is locked down."

New capsules/acl-std79.4th (blocks 4023-4047): walks a VM's own
dictionary (>LINK/LINK> traversal, same as ACL-INIT-PRIMITIVES/WORDS
already use) and permanently denies+pins every word not on an explicit
FORTH-79/83 allowlist, extracted from the real registered word set
(stack_words.c through control_words.c), not recited from memory.
Deliberately excludes, beyond plain non-standard words: BYE (100% ACL
bypass to the emergency console -- "needs more discussion, exclude for
now"), COLD/WARM/REBOOT/SAVE-SYSTEM (system lifecycle), the block/screen
editor L/S/SHOW/EDIT/UPDATE/SAVE-BUFFERS (lets a session rewrite
persistent block/capsule content, defeating the lockdown even though
nominally standard), BLK-ACL-*/BLK-OWNER@ (StarForth-specific), and
FORGET/FENCE (flagged as an unrestricted superpower word, 2026-09-03
audit). Keeps WORDS/VLIST/SEE (introspection only -- ACL is enforced
per-target-word at execution time regardless of how an XT was
obtained) and the parenthesized control-flow runtime primitives
((BRANCH) etc. -- IF/DO/LOOP compile calls to these; denying them
breaks ordinary control flow, not security).

MintPersonality enum (capsule_mint.h) lets capsule_mint_identity()
select which personality-source template gets written to a new
identity's devblock -- MINT_PERSONALITY_DEFAULT (unchanged) or
MINT_PERSONALITY_STD79_LOCKDOWN (EXECs acl-std79.4th then
ACL-LOCKDOWN-STD79 as the VM's own last bootstrap step). The actual
restriction logic stays entirely in FORTH per .claude/CLAUDE.md's
Word-Level ACL System rules ("ACL policy belongs in ACL.4th, never in
C") -- capsule_mint.c only picks which few-line bootstrap stub to
write. MINT's own stack signature gains a trailing restrict? flag;
capsule_zuse_boot.c's genesis mint (Zuse herself) explicitly passes
MINT_PERSONALITY_DEFAULT -- the superuser is never restricted.

Two real bugs found and fixed live during testing, both the same class
of self-referential fault: ACL-LOCKDOWN-STD79's own walk loop calls
ACL-STD79-ALLOWED?/ACL-STD79-LIST/ACL-ALLOW!/ACL-PIN on every single
iteration to do its job -- none of those are FORTH-79/83 standard
words, so the walk was denying its own load-bearing infrastructure
partway through and then faulting the next time it tried to call it
("VM fault -- emergency console disabled; halting", reproduced twice
live). Fixed by explicitly protecting all four in the allowlist
(block 4047) -- they must stay allowed for the walk to finish, not
because they belong on a "standard words" list.

Verified live end-to-end: minted a throwaway test identity with the
restrict? flag, confirmed her WIREBIND birth completes cleanly (no
faults, no shadow conflicts) on a single real attach, then USE'd into
her VM and confirmed standard arithmetic and user-defined words work
(1 2 + . -> 3; : X 5 5 * . ; X -> 25) while KILL is entirely unknown to
her dictionary and VM-EXEC is denied. One real, non-fatal side effect
found and left as-is (not asked to fix): the fleet's inter-VM messaging
pump (MSG-ARENA) is also denied by the lockdown, logging a harmless
per-idle-tick warning -- a fully locked-down VM doesn't participate in
message routing.

Not yet applied to the real identity 00 -- this commit is the
mechanism, verified against a disposable test identity only.

Three-arch clean qemu acceptance (single Zuse device, standard
regression case) passed on amd64, aarch64, and riscv64.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
 2026-09-07 15:41:56 -04:00
Robert Allan JamesandClaude Sonnet 5 8471d529bc FABRIC-3.md §X.4: correct a false claim about kmalloc.c lacking block splitting
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
The claim ("coalesces but doesn't split") was never actually checked
against kmalloc.c -- it was carried over from alloc_kernel.c's own doc
comment about itself and mis-applied to a different file. Asked to fix
it, re-reading kmalloc.c showed allocate_from_block() already has a
complete, unconditional splitting implementation. Nothing was broken;
correcting the record instead of "fixing" working code.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
 2026-09-07 14:34:03 -04:00
Robert Allan JamesandClaude Sonnet 5 b106a4b0b5 FABRIC-3.md §X.4: document the allocator resolution — sf_malloc/sf_free now on the real kernel heap
Build / build-riscv64-img (push) Canceled after 0s
Details
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details 
Updates §X.4 (and §X's own title) from "capacity question still OPEN"
to resolved: Captain Bob's framing (unknown VM count in advance, heap
should use whatever memory is actually available once this is a full
OS) led to routing alloc_kernel.c's sf_malloc()/sf_free() through the
kernel's existing kmalloc.c heap (2 GiB floor, PMM-backed, coalescing,
already boot-tested) instead of a separate 4MB arena -- commit 56e19a0.
Verified live: all 9 identities now attach where only 6 did before.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
 2026-09-07 12:47:05 -04:00
Robert Allan JamesandClaude Sonnet 5 56e19a00f9 Route VM-dictionary sf_malloc/sf_free through the kernel's kmalloc heap 
Captain Bob's call after seeing the identity-heap-capacity findings
(FABRIC-3.md §X.4): the number of concurrently-running VMs is not known
in advance, and once this is a complete operating system the heap should
be able to use whatever memory is actually available -- not a hardcoded
compile-time ceiling. This was already half-built and just not wired up.

src/starkernel/vm/alloc_kernel.c previously implemented sf_malloc()/
sf_free() (platform_alloc.h's allocator abstraction -- what
vm_create_word() calls for every VM's word dictionary) as its own
isolated static 4MB arena: first-fit free list, no splitting or
coalescing. That's exactly the allocator that topped out around 6
concurrent WIREBIND-born identities, failing from fragmentation before
true capacity exhaustion (§X.4's own measurements).

Sitting right next to it, unused for this purpose: src/starkernel/memory/
kmalloc.c, the kernel's general heap. Already initialized at boot (M6,
kernel_main.c, well before any VM is ever born), reserved from real
PMM-tracked physical memory rather than a fixed array, defaults to a
2 GiB floor explicitly sized "for 256+ baby VMs" per its own comment,
overridable via the --heap= boot flag, and its free list actually
coalesces neighboring blocks on every free.

Change: alloc_kernel.c's sf_malloc()/sf_free() now delegate to
kmalloc_aligned()/kfree() instead of managing a separate arena.
sf_alloc_init() becomes a no-op (kmalloc is already initialized by the
time any VM allocation can happen, and "resetting" a heap now shared by
every kernel subsystem would be actively wrong -- confirmed no external
caller depended on its old reset semantics). sf_alloc_get_stats() reads
kmalloc_get_stats() fresh rather than shadowing byte counts locally;
alloc_count/free_count (which kmalloc.c doesn't track) stay as simple
local counters. sf_calloc()/sf_realloc() are otherwise unchanged. Kernel-
only: the hosted (non-kernel) StarForth build keeps its own separate
alloc_host.c implementation, untouched.

Verified live: replaying the exact hotplug sequence that previously
topped out at 6 identities (Zuse + 8 identities, one at a time via QMP
device_add) now succeeds for all 9, where identity 05 specifically used
to fail. Three-arch clean qemu acceptance (single Zuse device, the
standard regression case) passed on amd64, aarch64, and riscv64 -- one
aarch64 attempt hit an unrelated, already-documented one-off QEMU hiccup
(empty log, boot never progressed past firmware) and passed cleanly on
retry with no rebuild.

Not addressed here: the underlying free-list itself is still first-fit
without splitting (only coalescing changed, inherited from kmalloc.c);
per-VM dictionary sizing (shrinking what each WIREBIND VM's word set
actually needs) is a separate, still-open lever from FABRIC-3.md §X.4's
open architecture question.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
 2026-09-07 12:46:14 -04:00
Robert Allan JamesandClaude Sonnet 5 36f1d6ae9e FABRIC-3.md §X: document the §IX.5 follow-on — xHCI root-cause/fix, live hotplug walkthrough, identity heap capacity findings
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Documents three commits' worth of live-tested work in one continuous
arc, picking up exactly where §IX.5 left off:

- X.1: the "4th-device enumeration failure" was a QEMU test-harness
  port-topology artifact, not a driver bug (commit 30c26ad).
- X.2: the real driver bug it uncovered once ports were fixed --
  Configure Endpoint completions silently dropped under concurrent
  multi-device enumeration, root-caused via temporary reverted probes
  and fixed with the same single-in-flight discipline the rest of the
  driver already uses (commit e10fb76).
- X.3: a live 9-device hotplug walkthrough (Zuse, bob/rajames, 00-06,
  one at a time via QMP) verifying the dynamic attach path and
  per-device identity data integrity, distinct from the boot-time scan
  path X.1/X.2 exercised.
- X.4: exact, live-measured kernel-heap-arena numbers per identity VM
  (457,392 bytes, zero variance across 6 identities), a real leak found
  and fixed (orphaned console VM never torn down on user-VM birth
  failure, commit d8a195b), and the open architecture question this
  surfaces -- identity capacity is fragmentation-limited around 6
  concurrent identities today, not yet decided how to address.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
 2026-09-07 11:39:18 -04:00
Robert Allan JamesandClaude Sonnet 5 d8a195b8d8 WIREBIND: kill the orphaned console VM when the user VM birth fails 
Found live during identity-heap-capacity testing (2026-09-07,
hotplugging Zuse + 8 identities one at a time and measuring the kernel
heap arena via a temporary allocator-stats probe, since reverted): every
WIREBIND identity attach births two VMs in sequence -- a "console" VM,
then the real "user" VM. When the second birth failed (arena
fragmentation under concurrent VM load, a separate, not-yet-fixed
capacity issue), capsule_wirebind_try_attach() logged the failure and
returned, but the console VM that had *already succeeded* was never
torn down. It stays live and registered under the identity's username,
consuming its own ~228KB of the fixed 4MB kernel heap arena forever --
nothing ever points a real user at it, since WIREBIND only ever hands
the caller the user VM's id.

This turns every failed identity attach into a permanent net loss of
heap rather than a neutral retry: confirmed live that a failed attach
left the arena 228,576 bytes worse off than before the attempt, and
every subsequent attempt starts from that worse baseline, compounding.

Fix: call capsule_vm_kill(username) on the now-orphaned console VM
before returning from the failure path -- the same teardown
capsule_wirebind_eject()/capsule_wirebind_unclean_detach() already use
elsewhere in this file (vm_cleanup() + sf_free(), confirmed live to
actually reclaim per-word dictionary allocations, FABRIC-3.md
§IX.2/§IX.3).

Verified live with the same allocator-stats probe (written, captured,
reverted -- not part of this commit): after the fix, a forced user-VM
birth failure now returns the arena to exactly its pre-attempt byte
count (3,526,256, matching the baseline precisely) instead of leaking
228,576 bytes. Three-arch clean qemu acceptance (single Zuse device,
the standard regression case) passed on amd64, aarch64, and riscv64.

The underlying capacity/fragmentation question (why the 7th concurrent
identity's arena allocation fails at all despite technically-sufficient
free bytes) is a separate, open architecture question -- not addressed
here. See project memory for the full measured numbers.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
 2026-09-07 11:37:06 -04:00
Robert Allan JamesandClaude Sonnet 5 e10fb76fb2 xhci: fix Configure Endpoint completion drop under concurrent multi-device enumeration
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Root cause of the FABRIC-3.md §IX.5 follow-on: with 9 devices attached
concurrently at boot (Zuse + 8 identities), only 1 of 9 ever completed
enumeration and reached blkio_usb: MSC device ready -- the other 8 produced
no error and no success, just silence.

xhci_poll_events()'s deferred per-slot dispatch loop submitted a Configure
Endpoint command (a Command Ring op) unconditionally for every slot with
that action pending in a single pass -- unlike every other Command Ring op
in this driver (Enable Slot, Address Device, Disable Slot), which is
correctly gated behind dev->connect_state == XHCI_CONN_IDLE before ever
submitting. With 2+ devices enumerating concurrently, this let multiple
Configure Endpoint commands sit outstanding on the Command Ring at once.
Their completion is correlated purely via the single shared
dev->connect_state field (== XHCI_CONN_AWAIT_CONFIGURE_ENDPOINT), not the
completion event's own Slot ID -- so whichever slot's completion happened
to land while connect_state still read AWAIT_CONFIGURE_ENDPOINT got
correctly chained into SET_CONFIG, and every other slot's completion
arrived after connect_state had already moved on, silently swallowed by
the handler's generic "unrelated command completion" catch-all. No error
path exists for this, which is why it produced total silence rather than
a diagnosable failure.

Root-caused live via temporary WARN-level diagnostic probes (written,
captured, and fully reverted per the project's own probe convention --
this commit contains only the functional fix and its explanatory comment,
no probe code) added at four points: the initial port scan, the connect
handler, the Command Completion Event handler, and the deferred dispatch
loop itself. The probes showed all 9 devices correctly completing Enable
Slot + Address Device (ruling out the connect-state queue as the cause,
the original hypothesis), then all 9 correctly submitting Configure
Endpoint and all 9 commands completing successfully in hardware (code=
SUCCESS, no errors logged) -- but only 1 of 9 ever got its next_action
chained to SET_CONFIG.

Fix: apply the same single-in-flight discipline this driver already uses
for every other Command Ring op. If the Ring isn't free when a slot's
Configure Endpoint action is due, put the action back on that slot instead
of submitting a second command onto a busy Ring -- the next tick's
dispatch pass retries it once the Ring frees up.

Verified live: booting Zuse + all 8 identity drives concurrently (9
devices, one per real xHCI port via the XHCI_PORTS fix from the previous
commit) now produces 9 "MSC device ready" lines and zero xHCI errors,
where it previously produced exactly 1. Three-arch clean qemu acceptance
(single Zuse device, the standard regression case) passed on amd64,
aarch64, and riscv64 -- no change in that baseline behavior.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
 2026-09-07 09:02:45 -04:00
Robert Allan JamesandClaude Sonnet 5 30c26ade3d Give each xHCI usb-storage device its own port; fix stale ZUSEDISK default
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
FABRIC-3.md §IX.5's "4th-device enumeration failure" was never a driver
bug: QEMU's default qemu-xhci controller (p2=4,p3=4) exposes only 4 real
dual-role ports, not 8 as the parameter names suggest. Attaching more
devices than that on bus=xhci0.0 without an explicit port= makes QEMU
silently auto-insert a USB2 hub past the 4th slot; the xHCI/BOT driver
correctly reports that hub as "not a Mass Storage/SCSI/BOT device" because
it genuinely isn't one, and every drive behind it is unreachable (no hub
descent in this driver). Confirmed live via QEMU's own `info usb` before
touching any kernel code.

Fix is entirely in the QEMU test harness, not the kernel:
- New XHCI_PORTS Make variable (default 16, overridable) sizes p2/p3 on
  all three arches' qemu-xhci controller with real headroom above the
  current 9-device identity roster, per Bob's standing ruling against
  hardcoding a bound to today's scale (FABRIC-3.md §VII.4).
- ZUSEDISK_QEMU_ARGS now gives Zuse's drive an explicit port=1.
- QEMU_EXTRA's own doc comment shows the port= pattern for additional
  devices.

Also fixed in passing: ZUSEDISK's default path (disk/zuse.img) was stale
-- that file was deleted from git at c3db963, superseded by
disk/thumbdrives/zuse-thumb-ident.img, but the Makefile default was never
updated, so a plain `make qemu` silently failed to attach Zuse at all.
Now defaults to the real minted image.

Not addressed here, flagged for later: scripts/bleach_zuse_img.sh and
disk/README.md still reference the deleted disk/zuse.img path. The
9-device concurrent enumeration itself (the scenario that originally
surfaced §IX.5) remains unverified against the real kernel -- this change
only confirms single-device boots are unaffected on all three arches.

Three-arch clean qemu acceptance passed (single Zuse device, port 1):
amd64, aarch64, riscv64 all reached POST: PASSED / PARITY:OK / "Zuse:
identity confirmed from attached thumbdrive" / (zuse) ok>.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
 2026-09-06 20:24:05 -04:00
Robert Allan JamesandClaude Sonnet 5 2c1b3cd695 Four bugs found live verifying the 8 identity thumbdrives (FABRIC-3.md §IX)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
All found by actually running the identity workflow §VII/§VIII made
possible, not by code review:

1. Zuse/WIREBIND cross-contamination on detach: capsule_zuse_boot_logout()
   and capsule_wirebind_unclean_detach() both had no device parameter, so
   an unrelated device detaching (while the real owner's own stayed
   attached) incorrectly tore down the wrong session. Both now compare
   the departing device against their own tracked one, mirroring
   capsule_wirebind.c's pre-existing g_wirebind_attached_dev precedent.

2. Dictionary-entry memory leak: vm_create_word()'s sf_malloc()'d
   DictEntry (plus a second per-entry allocation for transition_metrics)
   was never freed by vm_cleanup(), in both the hosted and kernel
   implementations. Caused a real kernel PANIC after 8-9 repeated VM
   birth/kill cycles in one boot. Fixed by walking vm->latest in both.

3. sf_malloc/sf_free (alloc_kernel.c) was a 4MB bump arena with a
   deliberate no-op free, sized on "VM born once, never killed" -- fix #2
   alone didn't stop the panic because free() itself discarded the
   pointer regardless. Given a real free list (first-fit reuse).

4. Headless-console gate didn't re-engage after a mid-boot logout: the
   original fix (sk_console_mark_login(), one-way sticky) only gated the
   first login of the boot. Replaced with a live check
   (sk_console_identity_present()) re-evaluated continuously, including
   inside sk_console_readline()'s own blocking idle loop -- the console
   is normally sitting blocked there when a hot-unplug logout happens, so
   checking only at the top of the REPL loop wasn't enough.

Also: MINT now verifies its own write (verify_mint(), capsule_mint.c) by
reading back through the same check a real attach performs, rather than
trusting blkio_write()'s BLK_OK alone -- logged via log_message(), not
console_println(), per direct instruction.

Verified live, amd64: the full 8-identity repeated attach/detach cycle
that previously panicked at the same point every time now completes
clean, and a full serial-log sweep found zero bare unauthenticated
prompts anywhere in the run. Three-arch clean-qemu acceptance passed.

Still open, not fixed here: a 3+-simultaneous-device USB enumeration
failure found in a separate live test, not yet root-caused.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4
 2026-09-06 01:49:13 -04:00
Robert Allan JamesandClaude Sonnet 5 0bae928aad Mint the 8 identity thumbdrives (bob, 00-06) with real MINT data
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
zuse-thumb-ident.img was already minted; bob-thumb-ident.img (Captain
Bob / rajames / rajames440@gmail.com) and 00-thumb-ident.img through
06-thumb-ident.img (full_name=username=the number, no email/phone) are
now real minted identities, not blank images.

Done via the actual kernel MINT word at a live console (Zuse
authenticated, drives hot-plugged one at a time via the QEMU HMP
monitor) -- no Python orchestration, per direct instruction: a small
StarForth word, MINT-NUM, wraps MINT for the 7 uniform numeric
identities, driven by plain bash + socat against the monitor/serial
unix sockets.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4
 2026-09-05 22:42:41 -04:00
Robert Allan JamesandClaude Sonnet 5 9e81de3f43 xHCI/BOT driver: genuine multi-device support (FABRIC-3.md §VII)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Per-slot registry (xhci_msc_slot_t/dev->msc_slots, sized off the
controller's own reported max_slots) replaces the single-device scalar
fields the driver carried since Milestones 2e-2h. Boot-time port scan no
longer stops at the first connected device; a connect/disconnect that
arrives while the Command Ring is busy is now queued and drained instead
of dropped. blkio_usb.c and repl.c's own single-device state (device
descriptor buffers, blkio_dev_t, attach bookkeeping) became per-slot
registries the same way.

Live multi-device testing (not just compiling) surfaced a second, more
severe bug outside the original plan: transfer_purpose and next_action
were also single scalars shared across the whole controller. Two devices
enumerating concurrently could have one's completion silently overwrite
the other's still-outstanding one, permanently stalling it with no error.
Fixed by moving both per-slot and, critically, reading the Transfer Event
TRB's own real Slot ID field instead of trusting external bookkeeping.

Verified live, all three architectures, mandatory clean-qemu acceptance:
existing single-device path unchanged, and two devices attached
simultaneously (amd64) both progress independently through enumeration
without corrupting or stalling each other.

Also in this pass (implemented and verified in earlier turns this
session, committed together per direct instruction):
- Headless-until-login console policy: no prompt/banner until a real
  identity logs in via an attached thumbdrive (WIREBIND or Zuse, neither
  special), reusing EMERGENCY_CONSOLE_ENABLED as the debug/recovery
  escape hatch (now default-off).
- KILL/g_repl_active_vm dangling-pointer fix: killing the VM the console
  is currently USE'd onto now detaches back to Hera first, matching the
  existing EJECT/UNCLEAN precedent.

FABRIC-3.md §VII/§VIII carry full closure notes for all three.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4
 2026-09-05 22:14:14 -04:00
Robert Allan JamesandClaude Sonnet 5 cc6fcb6a0b FABRIC-3.md §VII: rewrite punch list to real code-level detail
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Previous pass was too abstract for this series' own bar. Re-traced
xhci.c/repl.c function-by-function: found max_slots is already read and
correctly sizes the DCBAA (so the fix reuses that value, not "start
reading a register"); found xhci_scan_ports_for_already_connected()
deliberately breaks after the first hit, missing a second already-
connected device at boot entirely; found block_subsystem.c's attach
layer is already multi-device-capable, narrowing the real singleton to
xhci_dev_t's own fields plus three repl.c pointers. Punch list items now
name exact functions/fields/line numbers and what's proposed vs. already
true. Also drops the earlier small-fixed-N concurrency bound per
direct correction -- size off dev->max_slots, not a guessed ceiling.

Still plan-only. No driver code touched.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4
 2026-09-05 21:00:45 -04:00
Robert Allan JamesandClaude Sonnet 5 c3db963164 FABRIC-3.md §VII: xHCI/BOT single-device architecture — plan only, halted
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Documents the full scope of the driver's single-device-at-a-time state
(connect/enumerate, control-transfer, and BOT state machines), the
persistent-vs-in-flight distinction that bounds the fix, the concurrency
target, and a numbered punch list. No driver code has been touched —
implementation is explicitly held pending go-ahead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4
 2026-09-05 20:45:20 -04:00
Robert Allan JamesandClaude Sonnet 5 4ce28edf8f 3-arch QEMU acceptance + live diagnostic logs for the WIREBIND overflow trigger
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Per .claude/CLAUDE.md's non-negotiable acceptance criteria, ran
`make -f Makefile.starkernel ARCH=<amd64|aarch64|riscv64> clean qemu`
sequentially (one instance at a time, TCG) against the preceding commit.
All three booted cleanly to `(zuse) ok>` with identical dictionary hashes,
no regression from the new idle-tick overflow check.

Also includes the amd64 run (20260905-161517) that carried the temporary
TEST-OWNER-CLAIM diagnostic via SK_CMD, confirming blk_owner_has_claim()
live before the diagnostic word itself was reverted: PASS, no FAIL lines.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4
 2026-09-05 16:17:35 -04:00
Robert Allan JamesandClaude Sonnet 5 4d4ab59189 Build the FIRSTTOUCH overflow trigger flagged in FABRIC-2.md §I.2 
The overflow-triggered migration path (a WIREBIND-attached identity's own
drive running low on space) was scoped but never built -- only the
trigger-detection call site was missing, per this section's own text.

- capsule_wirebind.c now tracks the attached blkio_dev* alongside the
  already-tracked VM id, set in try_attach() and cleared in both
  EJECT/UNCLEAN paths.
- New capsule_wirebind_overflow_idle_check(), called once per idle tick
  in repl.c right alongside blk_migration_idle_check() (same cadence):
  reads the attached drive's free/total via blk_get_device_free_blocks(),
  and if free space is below a fixed 10% threshold, extends the
  identity's pool with a one-time blk_firsttouch_claim() of 8 additional
  devblocks on Artemis's system-resident device.
- New blk_owner_has_claim(owner_fp) in block_subsystem.c answers the
  debounce question blk_firsttouch_claim()'s own doc comment had left
  open: a disk scan, not a RAM flag, so the already-extended answer
  survives reboot/reattach, matching BMAPFMT's "ownership travels with
  the block" model.

Premise checked before building (does a WIREBIND-attached drive actually
give a real free/total signal, or does it stay PROVISIONAL/raw): traced
repl.c's attach sequence and confirmed blk_subsys_attach_device() runs on
the same dev pointer right after WIREBIND, and a WIREBIND-eligible drive
is always already STFR/v2-formatted, so the signal is real. Premise held,
unlike the BAM item's overstated one.

Verified with the mandatory 3-arch QEMU acceptance (identical dictionary
hashes, no regression) plus a live logic test of blk_owner_has_claim():
a temporary TEST-OWNER-CLAIM word, run once via SK_CMD and reverted,
confirmed it correctly detects the claiming owner and rejects an
unrelated one. The low-disk-space-triggers-a-claim path itself is not
verified end-to-end -- that needs a real minted WIREBIND-user thumbdrive
with deliberately tiny capacity, out of scope for this pass; noted as
such in the FABRIC-2.md §I.2 closure note rather than overclaimed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4
 2026-09-05 16:17:19 -04:00
Robert Allan JamesandClaude Sonnet 5 d8ac27abb2 3-arch QEMU acceptance + live diagnostic logs for the BAM reconciliation fix
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Per .claude/CLAUDE.md's non-negotiable acceptance criteria, ran
`make -f Makefile.starkernel ARCH=<amd64|aarch64|riscv64> clean qemu`
sequentially (one instance at a time, TCG) against the preceding commit.
All three booted cleanly to `(zuse) ok>` with the full Tripod fleet
(Hera/Hermes/Artemis) alive and identical dictionary hashes:

  Mama:    dict_hash=0x8d712e07c690d713
  Hermes:  dict_hash=0xa07a57d794c1665d
  Artemis: dict_hash=0x9cc9a7e72b590250

Also includes the amd64 run (20260905-155329) that carried the temporary
TEST-BAM-RECON diagnostic via SK_CMD, confirming the fix live before the
diagnostic word itself was reverted: TEST-BAM-RECON: PASS, no FAIL lines.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4
 2026-09-05 15:57:21 -04:00
Robert Allan JamesandClaude Sonnet 5 aa33aedca8 Fix blk_meta_t/BAM accounting reconciliation flagged in FABRIC-2.md §I.2 
FIRSTTOUCH ownership (blk_meta_t's BLK_FLAG_CLAIMED/owner_fp) and the
generic block-allocation bitmap (BAM, blk_bam_entry_t) were two parallel,
unreconciled accounting systems: blk_firsttouch_claim() never touched the
BAM, and blk_allocate()/devblock_is_free() never checked BLK_FLAG_CLAIMED.
A FIRSTTOUCH claim could be silently overwritten by a later blk_allocate()
call, or could itself steal a devblock already in ordinary use via
BLOCK/UPDATE.

- devblock_is_free() (shared by blk_firsttouch_claim() and
  blk_migration_idle_check()) now also checks the BAM entries of all
  BLK_PACK_RATIO member LBNs, not just blk_meta_t.
- New devblock_claimed_by_lbn() helper wired into blk_allocate()'s
  free-scan, so it skips any LBN whose devblock is BLK_FLAG_CLAIMED.
- blk_firsttouch_claim() now marks the BAM allocated for all 3 member
  LBNs of each devblock it claims, which also fixes vol_meta.free_blocks
  never decrementing for FIRSTTOUCH claims.
- blk_meta_relocate_devblock() traced and confirmed NOT part of the bug —
  it already keeps BAM in sync via blk_subsys_relocate_block()'s own
  blk_mark_free()/blk_update() calls.

Both boundary cases (the reserved/user LBN split at a slot's start_lbn,
and BAM-array bounds) are guarded explicitly.

Verified with the mandatory 3-arch QEMU acceptance (identical dictionary
hashes, clean BYE) plus a live logic test: a temporary TEST-BAM-RECON
word, run once via SK_CMD and fully reverted, confirmed on running code
that ordinary allocation and a FIRSTTOUCH claim land on disjoint LBN
ranges in both directions. FABRIC-2.md §I.2 updated in place with the
closure note, per this project's documentation discipline.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4
 2026-09-05 15:57:03 -04:00
Claude 04cc17920e 3-arch QEMU acceptance logs for the FINDINGS.md defect-repair commits
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Per .claude/CLAUDE.md's non-negotiable acceptance criteria, ran
`make -f Makefile.starkernel ARCH=<amd64|aarch64|riscv64> clean qemu`
sequentially (one instance at a time, TCG) against the two preceding
commits. All three booted cleanly to `(zuse) ok>` with the full Tripod
fleet (Hera/Hermes/Artemis) alive, Stadium conservation holding
(resident_sum=43691 reservoir=21845 sum=65536), and identical dictionary
hashes across all three ISAs:

  Mama:    dict_hash=0x8d712e07c690d713
  Hermes:  dict_hash=0xa07a57d794c1665d
  Artemis: dict_hash=0x9cc9a7e72b590250

Confirms cross-arch determinism holds with the EXECUTE/format/TYPE/
vocabulary/control-flow fixes applied.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Qf6YcnHgaEtEygq3knx19
 2026-09-05 14:46:24 +00:00
Claude 7191ce5a56 Refresh lfs/amd64/starforth binary artifact
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Rebuilt after the EXECUTE/format/TYPE/vocabulary/control-flow fixes in
the two preceding commits, per lfs/README.md's convention (this binary
is synced whenever the hosted amd64 build runs).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Qf6YcnHgaEtEygq3knx19
 2026-09-05 14:07:51 +00:00
Claude d6895bdd15 Move vocabulary and control-flow state off file-scope statics onto VM 
proof/FINDINGS.md's Isabelle/HOL word-source sweep (§1) found the two
defects severe enough to actively corrupt the live Tripod multi-VM fleet:
file-scope C statics standing in for state that belongs on struct VM.

- vocabulary_words.c (highest severity in the sweep): forth_vocab/
  context_vocab/current_vocab, context_var_addr/current_var_addr, the
  ctx_fc/forth_fc first-char search index, and the `initialized` guard
  were all process-wide statics. Only the first VM to touch any
  vocabulary word ever ran setup; every VM after that silently shared
  VM #1's dictionary-chain pointers and reused VM #1's byte-offset
  addresses as if valid in its own vm->memory. One VM's VOCABULARY/
  DEFINITIONS/FORTH silently changed where every other VM looked up and
  defined words.

- control_words.c: cf_stack/cf_sp/cf_last_mode (IF/THEN/BEGIN/DO/CASE
  compile-time nesting) and the LEAVE/ENDOF patch-site bookkeeping
  (leave_addrs/leave_sp/leave_mark_*, endof_addrs/endof_sp/endof_mark_*)
  were also process-wide statics. Two VMs compiling colon definitions at
  overlapping times would corrupt each other's nesting state.

Both moved onto struct VM, following the existing hold_addr/hold_pos
precedent in include/vm.h ("lives in each VM's own memory... so child
VMs never alias Hera's buffer"):

- New VocabularyState struct (vm->vocab): chain heads, VM-cell addresses,
  first-char index, initialized flag.
- New ControlFlowState struct (vm->cf): cf_stack/cf_sp/cf_last_mode plus
  the LEAVE/ENDOF patch-site stacks. cf_tag_t/cf_item_t/CF_STACK_MAX
  moved from control_words.c into include/vm.h since they're now part of
  the struct VM field's type.
- Sentinel fields (-1/-999, meaning "empty") explicitly initialized in
  both vm_init_with_host() implementations (hosted src/vm_bootstrap.c and
  kernel src/starkernel/vm/vm_bootstrap.c) alongside the existing
  dsp/rsp = -1 initialization, since the preceding zero-init leaves them
  at 0 rather than their empty sentinel.

Every word function in both files already took VM *vm, so no call sites
outside these two files needed to change; cf_push_item/cf_pop_item/
cf_peek_item gained a VM* parameter to reach vm->cf.

Verified: hosted (amd64) and kernel (amd64, __STARKERNEL__) both build
clean with -Wall -Werror after a full clean rebuild (struct VM's layout
changed size, and this Makefile has no header-dependency tracking, so a
stale incremental build would have linked mismatched object layouts).
Hosted POST suite 1012/1012 passing (0 regressions). Manually exercised
VOCABULARY/DEFINITIONS/FORTH/ORDER, and IF/ELSE, DO/LOOP/LEAVE,
BEGIN/WHILE/REPEAT, and CASE/OF/ENDOF/ENDCASE (including nested DO with
I/J) in the REPL -- all correct and unchanged from pre-refactor behavior.

Note: a pre-existing CASE/ENDCASE default-clause bug (the code after the
last OF...ENDOF pair does not correctly become the "default" value once
DROP runs) was found while testing this refactor and confirmed present
on unmodified master too -- not touched here, out of scope for this pass.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Qf6YcnHgaEtEygq3knx19
 2026-09-05 14:07:41 +00:00
Claude c36bd99e1e Fix EXECUTE/?/DUMP/TYPE/DECIMAL-HEX-OCTAL/ALIGN defects from proof sweep 
proof/FINDINGS.md's Isabelle/HOL word-source sweep (§4) flagged five real
defects; this fixes all five and records resolution in that doc:

- EXECUTE (system_words.c): cast a popped cell straight to a DictEntry*
  and called through it with only a null check. Now validates via a new
  shared vm_dict_entry_ok(), promoted out of starforth_words.c's
  ENTROPY@/ENTROPY! guard (dictionary_management.c) so EXECUTE gets the
  same live-entry check.

- ? and DUMP (format_words.c): dereferenced the popped cell as a raw host
  pointer, bypassing vm_addr_ok entirely (out-of-VM-bounds read). Both now
  go through VM_ADDR/vm_addr_ok/vm_load_cell/vm_ptr like every other
  memory word (@, `,`, editor_words.c).

- TYPE (io_words.c): bounds check computed addr+count in signed 64-bit
  arithmetic, which can overflow and bypass the check on large operands.
  Replaced with vm_addr_ok(), which is written to avoid that overflow.

- DECIMAL/HEX/OCTAL (format_words.c): wrote only the BASE memory cell,
  never vm->base, the host-mirror field number-output words actually read
  via current_base() -- so these words silently affected number parsing
  but never printing. Now call the existing vm_set_base() (previously
  only used at boot init), which updates both. vm_get_base/vm_set_base
  promoted to public declarations in include/vm.h.

- ALIGN vs ALLOT/,/C,/2, (dictionary_words.c): disagreed on dictionary
  growth ceiling (2MB vs 5MB). Investigated which was correct rather than
  blindly widening: vm_get_block_addr() maps block N to
  vm->memory + N*BLOCK_SIZE across the full 5MB arena, and
  USER_BLOCKS_START (block 2048) lines up exactly with
  DICTIONARY_MEMORY_SIZE -- so ALLOT/,/C,/2, letting `here` grow past 2MB
  could silently corrupt live block/user data sharing that memory.
  Tightened ALLOT/,/C,/2, to DICTIONARY_MEMORY_SIZE to match ALIGN.

Verified: hosted (amd64) and kernel (amd64, __STARKERNEL__) both build
clean with -Wall -Werror; hosted POST suite 1012/1012 passing (0
regressions); manually exercised EXECUTE, ?/DUMP, TYPE, HEX/DECIMAL/OCTAL,
and large-ALLOT rejection in the REPL.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Qf6YcnHgaEtEygq3knx19
 2026-09-05 14:07:11 +00:00
Robert Allan JamesandClaude Sonnet 5 70dc8beba4 FABRIC-2.md §I.9 follow-on: blinking | cursor instead of static block
Build / build-riscv64-img (push) Canceled after 0s
Details
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details 
Captain Bob asked for the framebuffer cursor to render as a blinking
vertical bar rather than the previous static solid-block glyph.

vt100_draw_cursor() (hal/vt100.c) now fills a thin bar (cell_w()/8, min
1px, full cell height) at the cursor's left edge instead of the whole
cell -- an I-beam shape. vt100_erase_cursor() is unchanged (clearing the
whole cell already safely covers the narrower bar).

Blinking is new in repl.c: sk_console_readline()'s idle branch toggles the
cursor on/off every SK_CURSOR_BLINK_INTERVAL (50 ticks, 500ms at 100Hz)
via alternating console_fb_draw_cursor()/console_fb_erase_cursor() calls,
independent of the heartbeat/idle-beat mechanism the §I.9 fix just touched
(deliberately not reused, to avoid recoupling to that path). Runs
regardless of n, so it blinks whether sitting at a bare prompt or paused
mid-edit. Every deterministic draw site (initial prompt, prompt reanchor,
backspace, character echo) now goes through a new helper, sk_cursor_show(),
which resets the blink cycle to "on" and redraws -- typing always shows a
solid cursor, never mid-blink.

Verified via the mandatory foreground 3-arch QEMU acceptance boot: amd64
(logs/20260905-021054, extensive live interactive typing including
multi-line : / ; word definitions and error cases, prompts stayed
correctly attached throughout), aarch64 (logs/20260905-021551), riscv64
(logs/20260905-022324) -- all three reached (zuse) ok> and shut down
cleanly via BYE.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-05 02:24:51 -04:00
Robert Allan JamesandClaude Sonnet 5 8edb95b65d FABRIC-2.md §I.9: fix the terminal phantom-linebreak defect
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
console_ensure_line_start() (hal/console.c) used to emit its newline
immediately via a path that deliberately skipped the tx-byte counter, so
that sk_repl_idle()'s unconditional per-beat call to it (repl.c, ~1s idle
heartbeat) could force a real newline the REPL's own prompt-reanchor logic
never noticed -- the prompt was never reprinted, and the next real
keystroke echoed onto the now-blank line, indistinguishable from Enter
having already been pressed at a bare prompt. Root-caused in the previous
commit (704573b); this commit applies the fix per explicit go-ahead.

Fix: defer the newline instead of emitting it eagerly.
console_ensure_line_start() now only sets a flag (g_pending_line_close);
the newline is realized -- for real, and counted by g_console_tx_count
like any other output -- on the next actual console_putc() call, or
silently discarded via the new console_cancel_deferred_line_start() if the
caller decides nothing was actually printed. sk_repl_idle() captures
tx_before_idle right after its console_ensure_line_start() call and cancels
the deferred newline at both of its exit points when console_tx_count()
hasn't moved. A beat with nothing to report now leaves the console
untouched; a beat that does print still closes the dangling prompt line
first, properly counted this time. The pre-existing n > 0 mid-edit gate in
sk_console_readline() is untouched -- independent purpose, not the bug.

Verified via the mandatory foreground 3-arch QEMU acceptance boot
(clean qemu, amd64 -> aarch64 -> riscv64, one at a time): all three reached
(zuse) ok>, all echoed the first real input on the same log line as the
prompt rather than a fresh line, all shut down cleanly via BYE. amd64's log
additionally shows live human backspace-correction still glued to the same
prompt line. Logs: logs/20260905-015854 (amd64), logs/20260905-020248
(aarch64), logs/20260905-020552 (riscv64); logs/20260905-015813 is a
foreground-rule-violation retry killed and redone correctly, kept per this
project's "never delete logs/" convention.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-05 02:08:06 -04:00
Robert Allan JamesandClaude Sonnet 5 704573bdfc FABRIC-2.md §I.9: root-cause the terminal defect, not fixed (identify-only)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
No code changed. This is a closure annotation on an existing open item
where it lives (FABRIC-2.md, marked archival by CLAUDE.md, but §I's punch
list landed there after the FABRIC series rename and genuinely still
lives there) -- not new design content in an archival doc.

Used QMP send-key to inject a real keypress into a running headless QEMU
guest -- no physical keyboard needed, overturning this item's own
"no way to observe the live QEMU GTK window from this environment"
assumption. A first pass (amd64 + aarch64, real first keypress after a
fresh boot, pre/post log captures) actually reproduced the defect but
misread it as clean: both logs showed the echoed key on a bare new
"[Hera]" line instead of appended to the still-visible "(zuse) ok> "
line, which looks like normal REPL output unless you know the prompt
should still be there. QMP screendump on aarch64 confirmed it visually.

Root cause traced to two specific interacting lines, not guessed:
console_ensure_line_start() (hal/console.c:312) emits its newline via
the tx-count-exempt console_putc_inner(), by design, so idle chatter
doesn't spam the REPL's prompt reanchor. But sk_repl_idle() (repl.c:178)
calls it unconditionally on every ~1s idle beat, including at a bare
prompt with nothing typed (n==0, repl.c:610) -- forcing a real but
tx-count-invisible newline that the reanchor check (repl.c:633) never
notices, so the prompt is never reprinted. The next real keystroke
echoes onto the now-blank line with a lazily-emitted "[VMName] " prefix,
indistinguishable from Enter having already been pressed. Not a
first-keypress race -- it fires on any ~1s+ human pause at a bare
prompt, i.e. nearly always, matching "consistent and reproducible."

repl.c's own comment at lines 598-609 already half-diagnosed this
exact failure mode and gates it for n>0 (mid-edit); the gap is the
identical n==0 case (bare prompt) was treated as harmless. Likely fix
location noted, not designed here.

Verified reproducible on both amd64 (i8042) and aarch64 (virtio-input)
input paths; riscv64 shares aarch64's virtio-input code path. Evidence:
three fresh boot logs plus before/after screendump PNGs
(evidence/aarch64/qemu-screenshot-20260905-013835-i9-*.png). No 3-arch
acceptance boot run for this commit -- no code changed, and these
logs/screenshots are themselves the evidentiary artifact, not a
generic regression check.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-05 01:47:53 -04:00
Robert Allan JamesandClaude Sonnet 5 dbaead0af2 xhci: route driver chatter through log_message(), silence at default log level
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
xhci.c and repl.c's USB attach/detach path printed every xHCI command
submission, completion, and BOT transfer step unconditionally via
console_println()/console_puts() -- floods the serial log on every boot,
regardless of whether anyone is debugging the USB stack.

Converted every "xhci:"-prefixed line to log_message() with a level
chosen by what it reports, not blanket debug:
- LOG_ERROR: allocation/mapping failures, timeouts, command failures,
  CSW signature/tag mismatches, CSW FAILED/PHASE ERROR, "not implemented"
  refusals, every "deferred ... setup failed" path
- LOG_WARN: dropped/skipped conditions (command ring busy, tracked-port
  range exceeded), unrecognized media (bad version/CRC), TUR retry
- LOG_DEBUG: routine progress (command submitted, succeeded, transfer
  completed, port connected) and expected outcomes (recognized/blank
  media)

Default log level is LOG_INFO, so the LOG_DEBUG chatter that was the
actual complaint is now silent by default and re-enabled with
--log-level=debug; LOG_ERROR/LOG_WARN stay visible so real faults aren't
buried.

xhci_log_hex32() now routes through log_message(LOG_DEBUG, ...) instead
of console_puts()/console_println() directly -- kept its own zero-padded
8-digit hex formatting rather than switching to log_message()'s %x
(which has no width control), since register values lining up in the
log is the reason this helper exists. console.h dropped from xhci.c,
no longer used directly.

Verified functionally unchanged, not just "still boots": all three
architectures reach zuse)ok>, log_message()-instrumented lines are gone
from the default-level log (grep -c xhci == 0 on all three, versus dozens
before), and the USB thumbdrive path still works end to end --
"Zuse: identity confirmed from attached thumbdrive" appears on all three
boots exactly as before.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-05 01:25:50 -04:00
Robert Allan JamesandClaude Sonnet 5 1bd041e84d FABRIC-3.md §IV.3 item 5: pci_init() DTB path re-scoped, doc-only, nothing implementable this pass
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Re-examined the Pi 5 RP1 PCIe access re-scoping (§IV.3 item 5) to see what
was actually buildable before real hardware arrives (2026-09-17), and
found nothing safely implementable this pass -- recorded three corrections:

1. The "vmm_map_range() needed for native boot" secondary finding is
   wrong as stated: arch_mmu_init() is a stub on both non-amd64 ISAs,
   vmm.c's load_cr3() is a no-op outside __x86_64__, and riscv64's satp
   is explicitly left at Bare (this session's own §V.3 item 7 fix). No
   non-amd64 ISA ever turns its own MMU on today, so VA==PA and there is
   nothing to map. Reframed as a future concern conditional on MMU
   bring-up, not a current prerequisite.

2. No silent-wrong-answer risk exists today: with no ACPI on native Pi 5
   boot, pci_init()'s MCFG parse already fails cleanly and aarch64 takes
   no ECAM fallback, rather than misreading RP1's 37 KB indirect window
   as flat ECAM.

3. The "make config-space dispatch runtime instead of compile-time" half
   of the re-scoped fix, considered on its own, isn't separable:
   portio_read32() and siblings use outl/inl inline asm that cannot exist
   in an aarch64/riscv64 translation unit, so any case referencing them
   stays #ifdef-gated regardless -- an enum wearing the same compile-time
   selection. It only becomes real dispatch once a second non-amd64
   mechanism is actually compiled in.

Broadcom indirect access itself remains unimplemented: no QEMU model
exists for "brcm,bcm2712-pcie" (zero branches would ever execute before
real hardware, unlike the guard-exercised GIC/PLIC DTB fixes), and
config-space access alone is insufficient for RP1 to enumerate without
the real driver's controller bring-up (link training, PERST, window
setup) -- building only the index/data window would compile and boot
while silently never working.

No code changed. 3-arch acceptance run anyway per convention: all three
reach zuse)ok> with identical virtio-blk/xHCI PCI device discovery to
the pre-change baseline (commit 9b6de5d), confirming no regression from
a change that touched no source.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-05 01:06:24 -04:00
Robert Allan JamesandClaude Sonnet 5 9b6de5d6c7 riscv64: PLIC base address DTB-discovered, QEMU-virt constant as fallback (§V.3 item 3)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
plic_init() now takes boot_info->dtb (threaded through apic_init()) and
tries fdt_find_node_by_compatible(dtb, "sifive,plic-1.0.0") ->
fdt_find_prop_in_node(..., "reg", ...) before falling back to the
QEMU-virt-specific constant it previously hardcoded unconditionally.
Reuses the node-scoped DTB lookup primitive built for the aarch64 GIC
base fix unchanged. s_plic_base is now a runtime uintptr_t, same shape
as apic.c's s_gicd_base/s_gicc_base.

This system's QEMU/UEFI riscv64 firmware does not forward a DTB to the
guest (timer.c's own timebase-frequency read falls back too, confirmed
in this boot's own log), so only the no-DTB fallback branch is exercised
here -- the success branch (a real DTB with a matching PLIC node) stays
unverified until real Milk-V Mars hardware. FABRIC-3.md's first-drafted
claim that the success branch would run (based on a stale comment in
plic.c's own pre-fix header) was checked against the actual log and
corrected before this commit.

3-arch acceptance: amd64/aarch64 don't compile these files, so their
runs are non-regression on untouched files only. riscv64's own boot log
confirms the fallback path prints exactly as designed and boot reaches
zuse)ok> unchanged.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-05 00:56:25 -04:00
Robert Allan JamesandClaude Sonnet 5 90ee8deb6d riscv64: skip satp Bare-mode switch when already Bare (§V.3 item 7 audit fix)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
arch_early_init() unconditionally cleared satp on every boot, justified
only by behavior observed under QEMU/EDK2 firmware (satp.MODE=10/Sv57,
kernel identity-mapped within it). That reasoning never applied to the
native U-Boot+OpenSBI boot path, where satp is conventionally already 0
at S-mode handoff -- the unconditional clear was likely a harmless no-op
there, but on an unverified assumption.

Fix: read satp.MODE first and return early when it's already 0 (nothing
to switch away from, no safety argument needed). The unconditional
csrw/sfence pair still runs unchanged for the confirmed QEMU/EDK2 case.
No Sv39/Sv48/Sv57 page-table walker built -- out of proportion to this
finding's severity.

3-arch acceptance: amd64/aarch64 don't compile this file, so their runs
are non-regression on untouched files only. riscv64's own boot log
confirms satp.MODE = 0xa at entry, so the mode != 0 branch ran and
"satp cleared -- Bare mode, explicit" printed exactly as before the fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-05 00:17:35 -04:00
Robert Allan JamesandClaude Sonnet 5 350287850f arch/aarch64: fix VBAR_EL2 stale comment + hardcode HVC PSCI conduit
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
FABRIC-3.md §IV.3 item 7's code audit found two more findings; fixed both
per direct instruction naming them specifically.

Comments only, no behavior change:
interrupts.c's arch_interrupts_init() doc comment (and its matching
runtime EL2 console message) claimed VBAR_EL2 was "a known gap... not yet
wired." Checked against isr.S's aarch64_install_vectors() and found that
claim stale: the assembly already branches on aarch64_current_el() and
writes vbar_el2/vbar_el1 correctly, threading the same answer through
el2_mode_flag for the IRQ trampoline's ELR/SPSR selection too. There was
no gap to close -- only the comment was wrong. Also fixed a same-vintage
one-word staleness in arch.c's aarch64_install_vectors extern comment
("installs VBAR_EL1" -> EL-aware), caught while touching this.

Real behavior change, gated to preserve existing QEMU behavior:
arch_cold_reset() hardcoded the PSCI conduit to HVC, a documented
QEMU-specific workaround (QEMU's AAVMF has no genuine EL3 to answer SMC).
Real Pi 5 hardware's ATF means EL3 exists there; confirmed further this
pass that bcm2712.dtsi's own /psci node declares method="smc" directly,
not just inferred from ATF's presence.

New aarch64_psci_conduit_init(dtb) in arch.c: fdt_valid(dtb) ->
fdt_find_node_by_compatible(dtb, "arm,psci-1.0") ->
fdt_find_prop_in_node(..., "method", ...) -- sets a module-static
s_psci_use_smc flag to 1 only when method reads exactly "smc"; every
other outcome (no DTB, no PSCI node, method="hvc", property absent)
leaves it at its default 0/HVC, preserving this system's existing QEMU
behavior exactly. arch_cold_reset() now branches on that flag between
smc #0/hvc #0. Called once from apic_init() (arch/aarch64/apic.c), the
one point in boot with boot_info->dtb already in hand -- collocated with
its consumer in arch.c rather than defined in apic.c, since
arch_cold_reset() has no boot_info of its own by the time it runs (called
from deep in VM execution, via BYE).

Three-arch QEMU acceptance run exercised both new guard branches: the
aarch64 boot log shows "PSCI: no DTB -- using HVC (QEMU virt-machine
default)" immediately before the existing GIC discovery lines, then
boots clean to zuse)ok> -- confirming the QEMU/UEFI path is unchanged.
The SMC success branch itself stays unverified until real Pi 5 hardware
runs BYE.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-05 00:06:41 -04:00
Robert Allan JamesandClaude Sonnet 5 dc9445abec apic.c (aarch64): fix GIC base address for real Pi 5 hardware
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
FABRIC-3.md §IV.3 item 7's code audit found GICD_BASE_PA/GICC_BASE_PA
hardcoded to QEMU virt-machine constants (0x08000000/0x08010000),
self-documented as a deliberate exception because QEMU's aarch64 UEFI
firmware never forwards a DTB. That premise doesn't hold on the native
Pi 5 boot path (rpi5_native_boot.c), which does have a real DTB and calls
this same, unmodified apic_init() -- which ignored boot_info entirely and
always programmed the QEMU addresses. Real BCM2712 GIC-400 is at
0x10_7fff9000 (confirmed against bcm2712.dtsi's axi/gicv2 nodes), a
completely different region of the address space. Fixed per direct
instruction, naming this finding specifically.

apic_init() now calls gic_bases_from_dtb() first: fdt_valid(dtb) ->
fdt_find_node_by_compatible(dtb, "arm,gic-400") ->
fdt_find_prop_in_node(..., "reg", ...), reading the first two
2-address-cell/2-size-cell entries (GICD, then GICC -- the standard
arm,gic-400 binding order). Falls back to the QEMU constants on any
failure (no DTB, no matching node), so the existing QEMU/UEFI path is
unchanged. GICD_BASE_PA/GICC_BASE_PA became s_gicd_base/s_gicc_base
(module-static uintptr_t, no longer compile-time constants on this path)
-- every MMIO call site (apic_init, apic_spi_enable, apic_read_iar,
apic_eoi_intid) now reads through them.

Three-arch QEMU acceptance run exercised the guard itself, not just
compiled it: the aarch64 boot log shows "GICv2: no DTB GIC node -- using
QEMU virt-machine defaults" followed by the unchanged "distributor+CPU
interface enabled, PPI 30" line, then boots clean to zuse)ok>. The
success branch (a real DTB with a matching node) stays unverified until
real Pi 5 hardware -- this build never has a devicetree to exercise it
against.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 23:54:39 -04:00
Robert Allan JamesandClaude Sonnet 5 0f798256a0 FABRIC-3.md: aarch64/riscv64 boot-path code audit pass (§IV.3/§V.3 item 7)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Reviewed arch/aarch64/{apic,arch,timer,interrupts}.c and
arch/riscv64/{apic,plic,arch,interrupts,timer}.c for the same class of
QEMU-virt-vs-real-hardware assumption §III item 6's amd64 audit looked for.
Report only, per this project's "identify, don't fix unless asked" rule --
no source files changed.

Findings, aarch64:
- Severe, confirmed live: apic.c's GICD/GICC base addresses are hardcoded
  QEMU-virt constants, self-documented as a deliberate exception because
  QEMU's aarch64 firmware never forwards a DTB. That premise no longer
  holds -- the native Pi 5 boot path (item 2) receives a real DTB and
  calls the same, unmodified kernel_main(), whose M4 sequence calls
  apic_init(boot_info) unconditionally (kernel_main.c:413); apic_init()
  still ignores boot_info entirely. Real BCM2712 GIC-400 is at
  0x10_7fff9000, confirmed against bcm2712.dtsi -- a different region of
  the address space entirely from the hardcoded 0x08000000. With the MMU
  off at this point in boot, this blocks reaching ok> on real hardware as
  the code stands.
- Doc-only correction: interrupts.c's own comment claims VBAR_EL2 is never
  installed ("a known gap"). Checked against isr.S and found stale -- the
  actual implementation already branches on aarch64_current_el() and
  installs vbar_el2/vbar_el1 correctly. No functional gap; the comment
  describes one the code already closed.
- arch_cold_reset() hardcodes the PSCI conduit to HVC, a QEMU-specific
  workaround (QEMU's AAVMF has no genuine EL3). The Pi 5's real ATF means
  EL3 firmware exists there, making SMC the conventional real-hardware
  conduit -- no runtime detection exists.

Findings, riscv64:
- plic.c's QEMU-virt-hardcoded PLIC_BASE is already tracked (§V.3 item 3);
  this pass confirms rather than rediscovers it.
- arch_early_init()'s satp clear is justified entirely by behavior
  observed under QEMU's EDK2 firmware; the native boot path (U-Boot+
  OpenSBI, no EDK2) doesn't share that observation, though the action is
  likely still safe since OpenSBI's handoff conventionally leaves satp=0
  already. Lowest-severity finding in the set.
- Clean: the SBI timer path and arch_cold_reset()'s SBI SRST call are both
  genuinely hardware-independent -- named as the portable pattern amd64's
  i8042-pulse reset and aarch64's hardcoded-HVC PSCI call both lack.

Doc-only change. Three-arch QEMU acceptance (amd64/aarch64/riscv64, in
order) run to confirm non-regression only.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 23:31:38 -04:00
Robert Allan JamesandClaude Sonnet 5 6a6ff9353f FABRIC-3.md: amd64 boot-path code audit pass (§III item 6)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Reviewed src/starkernel/boot/uefi_loader.c and every file in arch/amd64/
(arch.c, apic.c, ioapic.c, interrupts.c, i8042.c, timer.c) for anything that
assumes SER5-specific hardware rather than standard UEFI/ACPI. Report only,
per this project's "identify, don't fix unless asked" rule -- no source
files changed.

Verified clean: uefi_loader.c's COM1 presence probe, its two-pass ACPI
2.0-then-1.0 GUID preference, the GetMemoryMap/ExitBootServices golden
path, and GOP BltOnly degradation. apic.c/ioapic.c derive LAPIC mode,
APIC timer frequency, and I/O APIC base/GSI at runtime, not from hardcoded
constants.

Four findings recorded (not fixed):
1. HPET base (timer.c) hardcoded at 0xFED00000, never cross-checked against
   the ACPI "HPET" table -- the same bug class this file's own comment
   already documents and fixed for the PM_TMR port.
2. LAPIC base always 0xFEE00000; apic_init()'s own doc comment flags MADT
   relocation as unimplemented. Narrower than that suggests: ioapic.c's
   parser already reads MadtHeader.local_apic_address, just never plumbs
   it to apic.c. MADT type 5 (Local APIC Address Override) isn't parsed
   at all.
3. i8042 PS/2 controller (i8042.c) and the legacy 8259 PIC (interrupts.c)
   are poked unconditionally with no ACPI FADT presence check, unlike this
   same file's own raw_serial_init() COM1 probe.
4. arch_cold_reset() (confirmed live via BYE, mama_forth_words.c:1437)
   pulses the i8042 reset line instead of using the FADT's standards-defined
   RESET_REG/RESET_VALUE, which doesn't depend on i8042 existing at all.

None are certain to bite on the real SER5 -- the conventions assumed hold
on the large majority of PC-compatible x86_64 systems -- but the decision
in FABRIC-3.md §III requires arguing genericity from standards compliance,
not from "it booted," and these are the concrete gaps.

Doc-only change. Three-arch QEMU acceptance (amd64/aarch64/riscv64, in
order) run to confirm non-regression only.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 23:15:09 -04:00
Robert Allan JamesandClaude Sonnet 5 ecdb32e0d6 boot_media/rpi5/config.txt: Pi 5 native boot config (FABRIC-3.md §IV.3 item 6)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Researched against the official raspberrypi.com config.txt reference and one
real, working Pi 5 bare-metal project's own checked-in config.txt
(leopoldch/BatMetal), not assumed from general Pi knowledge:

- kernel=kernel_2712.img, os_check=0, device_tree=bcm2712-rpi-5-b.dtb
- enable_uart=1 added (correction to the item's original text): costs
  nothing when unused, and is the only diagnostic channel that would survive
  a framebuffer failure on the untested mailbox path (rpi5_native_boot.c).
- arm_64bit=1 dropped (correction to the item's original text): confirmed
  inert on Pi 5 by official docs.
- dtparam=pciex1 researched, deliberately omitted with rationale recorded --
  community-reported only, not needed until item 5's re-scoped RP1/PCIe work.
- os_check=0 vs. BatMetal's own config (which omits it) recorded as an open,
  unresolved discrepancy rather than silently picked.

boot_media/rpi5/README.md notes the one remaining gap this exposes:
kernel_2712.img names a file nothing currently builds (item 1's
separate-image build target is still outstanding future work).

Doc-and-config only, no compiled code changed. Three-arch QEMU acceptance
(amd64/aarch64/riscv64, in order) run to confirm non-regression only.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 23:05:39 -04:00
Robert Allan JamesandClaude Sonnet 5 11c93773d0 FABRIC-3.md: pci_init() DTB path item was wrong -- re-scope, don't build the ECAM version
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Investigated before writing code, per this document's own discipline, and
found the original item 5 text's assumption doesn't hold: it framed this
as "swap the ACPI MCFG lookup for a DTB one, same flat-ECAM access
underneath." Confirmed against three primary sources that this is wrong:

- bcm2712-rpi-5-b.dts: RP1 sits under pcie2 ("brcm,bcm2712-pcie"),
  reg = <0x10 0x00120000 0x00 0x9310> -- a ~37KB window, far too small
  for a flat 256MB ECAM region.
- pcie-brcmstb.c (the real Linux driver for this compatible string):
  brcm_pcie_map_bus() computes a standard ECAM-shaped offset but accesses
  it through an IDX_ADDR/DATA_ADDR indirect index+window pair, not a
  direct MMIO read. A real third config-access mechanism, not a bigger
  version of the DTB-lookup task.

Re-scoped item 5 (§IV.3) to record the real shape: pci.c's cfg_read32/
cfg_write32 family dispatches today via #ifdef ARCH_AMD64 vs. everything
else (flat ECAM) -- but QEMU aarch64 (flat ECAM, real ACPI MCFG) and Pi 5
aarch64 (Broadcom indirect windowing) are the same build, so this needs a
runtime dispatch change to a file all three architectures currently boot
through, not a small addition. Also flagged: pci_init()'s vmm_map_range()
for the ECAM window is amd64-only today (aarch64/riscv64 rely on UEFI's
identity map); native boot has no UEFI identity map at all, so any PCIe
work here needs its own explicit mapping regardless of access mechanism.

Also corrected §V.3 item 5's now-stale "shares the same code" cross-
reference -- the Mars's JH7110 PCIe controller needs its own primary-
source check, not an assumed-shared implementation with RP1's.

Not implemented this pass -- recording the real shape is the deliverable;
building the runtime-dispatch version is a materially larger, separate
task. Doc-only change; 3-arch boot verified per the project's standing
rule, proving only that nothing regressed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 22:47:18 -04:00
Robert Allan JamesandClaude Sonnet 5 7187d68082 rpi5_native_boot.c: carve /reserved-memory out of the Pi 5 memory map
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Previously deferred (rpi5_native_boot.c's own header comment flagged this
as needing interval-splitting logic written blind against hardware not
yet in hand) -- revisited by fetching bcm2712-ds.dtsi directly rather than
assuming reserved-memory was empty or absent. It has one static child
(atf@0, ARM Trusted Firmware's own region) and one dynamic child
(linux,cma, size/alloc-ranges only, no fixed reg) -- the dynamic one is
skipped, nothing fixed to carve and no allocator this early to service it
against anyway.

Adds two fdt.c primitives: fdt_find_node_by_name() (reserved-memory has
neither compatible nor device_type per DT spec) and fdt_next_child_node()
-- one exported symbol, not the two-primitive general sibling-walker
originally sketched, collapsed after review since the only real use here
is "iterate one node's direct children."

collect_reserved_ranges() reads each child's own #address-cells/
#size-cells with a fallback to root's only if absent -- confirmed
necessary, not just defensive: reserved-memory's own declared <2>/<1>
genuinely differs from root's <2>/<2>. emit_region_with_carveouts()
clips a sorted reserved-range list against each RAM region, emitting
alternating EfiConventionalMemory gaps and EfiReservedMemoryType
carve-outs (insertion sort, no libc qsort in freestanding).
RPI5_MAX_MEMMAP_ENTRIES is the exact worst-case count, recomputed rather
than estimated -- the rpi5_mailbox.c buffer-size bug is the standing
lesson for this pattern.

Compile-only-verified; nothing in the existing UEFI/QEMU path calls
rpi5_native_boot(), so this cannot be exercised until real hardware.
Verified 3-arch boot to ok>/zuse)ok>.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 22:24:57 -04:00
Robert Allan JamesandClaude Sonnet 5 67e3fb7459 rpi5_native_boot.c: Pi 5 DTB->BootInfo constructor (FABRIC-3.md §IV.3 item 2)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
rpi5_native_boot() populates the existing BootInfo struct from the
devicetree instead of UEFI protocols, then calls the existing, unmodified
kernel_main() -- the crux of why most of M1-M9 stays shared between the
UEFI and native boot paths. native_rpi5_entry.S now tail-calls into it
instead of halting.

memory_map is built from /memory's own reg, honoring the *root* node's
#address-cells/#size-cells (confirmed against bcm2712.dtsi's actual root
node -- <2>/<2> -- not assumed; a wrong cell width here would compile and
boot clean in QEMU while silently corrupting the real memory map on real
silicon). Required a new fdt_find_node_by_device_type() since /memory is
identified by device_type = "memory" per DT spec, not compatible.

args comes from /chosen's bootargs fed into the existing
cmdline_parse_ascii() (confirmed pure C99 with no UEFI coupling before
reusing it). framebuffer comes from the already-built
rpi5_mailbox_get_framebuffer() at a fixed 1920x1080x32 default -- no EDID
query exists in this codebase, flagged rather than guessed past.

Deliberately scoped out, not silently skipped: /reserved-memory is not
parsed. Carving reserved sub-ranges out of /memory's span needs
interval-splitting logic that would be written blind against hardware not
yet in hand -- exactly the kind of code that hides a bug until real
silicon. pmm.c's Pass 3 only ever clears pages this file lists as
EfiConventionalMemory, so the gap is "less usable RAM than optimal," never
"reserved RAM wrongly marked free." Left as its own future item.

Also fixes a real link failure this work surfaced: boot/cmdline.c was only
in LOADER_SRCS_BASE (the .efi target), not KERNEL_SRCS_BASE (the separate
.elf target arch/aarch64/*.c also wildcards into) -- added it there too.

Compile-only-verified; nothing in the existing UEFI/QEMU path calls
rpi5_native_boot(), so this cannot be exercised until real hardware.
Verified 3-arch boot to ok>/zuse)ok>.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 14:42:32 -04:00
Robert Allan JamesandClaude Sonnet 5 281de9547c native_rpi5_entry.S: Pi 5 native (non-UEFI) boot entry stub (FABRIC-3.md §IV.3 item 1)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
rpi5_native_start masks x0 down to the documented 32-bit DTB-pointer range
(the firmware's own entry protocol leaves the upper 32 bits unspecified),
stores it into g_rpi5_dtb_ptr for the still-open DTB->BootInfo constructor
(item 2) to read, then switches sp to a dedicated 2 MiB BSS stack -- this
path has no EDK2 boot stack to inherit, unlike every other entry path in
this codebase.

Intentionally halts (wfe/b loop) afterward rather than tail-calling into
item 2's constructor, which doesn't exist yet -- no stub function pretending
to be more than it is.

Not yet linked at the real 0x80000 load address; that needs its own linker
script/build target, not scoped into this item. Compiles and links into the
existing ARCH=aarch64 QEMU/UEFI acceptance build as dead code (ELF kernel
build's KERNEL_ASM wildcards every *.S in arch/aarch64/; nothing there
branches to it), same as rpi5_dtb.c/rpi5_mailbox.c before it.

Verified 3-arch boot to ok>/zuse)ok>.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 14:12:42 -04:00
Robert Allan JamesandClaude Sonnet 5 a32b0ebcbe rpi5_mailbox.c: wire the VideoCore mailbox message protocol (FABRIC-3.md §IV.3 item 3)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
New rpi5_mailbox_get_framebuffer() sends one property-tag request buffer
(phys size, virt size, depth, pixel order, virtual offset, allocate-buffer,
get-pitch) over the register layout rpi5_dtb.c already discovers, populating
an Rpi5FramebufferInfo kept in exact field-for-field sync with uefi.h's
FramebufferInfo so console.c/vt100.c/framebuffer.c need no downstream changes
once this is wired into a real entry stub.

Register offsets (+0x00/+0x18 MBOX0 read/status, +0x20/+0x38 MBOX1
write/status) confirmed against a Pi-5-specific bare-metal reference,
independently cross-checked against this codebase's own rpi5_dtb.c
translated base address.

Caught and fixed a real buffer-overflow bug before compiling: the static
request buffer was sized 32 words against an actual 35-word requirement for
the 7-tag sequence, recomputed exactly rather than re-estimated; resized to
40 words.

Two things flagged as genuinely unverified against real hardware (not
guessed past the comment): the allocate-buffer tag's request-size field
value, and whether its response address needs classic bus-alias masking on
Pi 5 specifically.

Compile-only-verified -- no caller yet (that's the still-open entry-stub/DTB
constructor items). Verified 3-arch boot to ok>/zuse)ok>.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 14:00:32 -04:00
Robert Allan JamesandClaude Sonnet 5 ca52ce8243 rpi5_dtb.c: wire fdt.c's node-scoped lookup into the Pi 5 UART/mailbox addresses
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
New include/starkernel/rpi5_dtb.h / src/starkernel/arch/aarch64/rpi5_dtb.c:
rpi5_uart_base()/rpi5_mailbox_base(), each finding their peripheral by
compatible string ("arm,pl011" / "brcm,bcm2835-mbox") via fdt_find_node_by_
compatible() then reading its "reg" via fdt_find_prop_in_node().

Found and fixed a real translation gap before it could have silently
produced a wrong address: confirmed directly against bcm2712.dtsi
(raspberrypi/linux) that both peripherals live under one "soc"
simple-bus node whose ranges property adds a fixed 0x10_0000_0000
offset to every child reg value. fdt.c's reader deliberately doesn't
apply ranges translation generally (not a general devicetree
library); this file applies that one, fixed, SoC-wide offset
explicitly, documented with the exact devicetree excerpt that
confirmed it.

Compile-only verification -- no caller wired in yet, these two
functions are what the still-open entry-stub and mailbox-framebuffer-
driver punch-list items will call. Verified 3-arch boot to ok>
(amd64/aarch64/riscv64, each in the foreground; rpi5_dtb.o confirmed
built on aarch64, the only arch that compiles this file).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 13:36:08 -04:00
Robert Allan JamesandClaude Sonnet 5 5e46f18fd9 fdt.c: node-scoped lookup extension (FABRIC-3.md SSIV.3/SSV.3 shared item)
Build / build-riscv64-img (push) Canceled after 0s
Details
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details 
Adds fdt_find_node_by_compatible() and fdt_find_prop_in_node() to the
minimal FDT reader -- the extension fdt.h's own header comment already
flagged as a known future need ("item 0.6 will need node-scoped reg
lookups"), now with real consumers: the Pi 5's UART/mailbox register
addresses (native boot, no ACPI) and the Milk-V Mars's real PLIC base
address (currently hardcoded to QEMU-virt's own value).

fdt_find_node_by_compatible() matches any entry in a node's
NUL-separated "compatible" list, first match in document order.
fdt_find_prop_in_node() scopes to that one node's own direct
properties only -- stops at the first child node or the node's own
end, per the DT spec's ordering guarantee that a node's properties
always precede its children. Same minimal, non-tree-building,
single-linear-scan-per-call style as the existing reader; no new
state, no allocation.

Compile-only verification -- no caller wired in yet, this is the
shared primitive both boards' own punch-list items will call once
built. Verified 3-arch boot to ok> (amd64/aarch64/riscv64, each in
the foreground).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 13:05:42 -04:00
Robert Allan JamesandClaude Sonnet 5 bffd87615d FABRIC-3.md: riscv64 (Milk-V Mars) planning decided + punch list
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Resolved SS V.1's flagged gap: standard RISC-V SBI boot protocol,
confirmed via OpenSBI's own docs -- a0=hart ID, a1=DTB pointer, S-mode
entry, universal across FW_DYNAMIC firmware regardless of vendor, not
chain-specific guesswork.

Decided: observation is HDMI-only, same reasoning and constraint as
the Pi 5 (no bridge hardware for this board's own first bring-up
either).

Traced boot_info->acpi_table's real riscv64 consumers the same way as
aarch64: pci_init() again (Mars's M.2 slot is PCIe-attached, same
shape of gap as the Pi 5's RP1); timer.c is already fully DTB-driven,
no work needed there.

One real, already-flagged risk found while tracing this: PLIC_BASE is
a QEMU-virt-specific constant, not DTB-discovered -- arch/riscv64/
plic.c's own doc comment already warned about this; it becomes
concrete now that real hardware is actually in scope. Real punch-list
item, not hypothetical.

6-item no-hardware-needed punch list (entry stub, DTB->BootInfo
constructor, DTB-discovered PLIC base, unresearched JH7110 framebuffer
flagged honestly rather than assumed, shared pci_init() DTB path with
the Pi 5, image-packaging tooling) plus 5 items deferred to
2026-09-17.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 12:55:28 -04:00
Robert Allan JamesandClaude Sonnet 5 1ec2a29384 FABRIC-3.md: aarch64 (Pi 5) planning decided + punch list
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Decisions from conversation: observation is HDMI-only for this
board's own bring-up (no second Pi, no dedicated USB-serial adapter;
using the Milk-V Mars as a bridge before it's independently validated
would be circular). Both boards arrive 2026-09-17, giving real runway
to finish design/code work first ("plan well before doing").

Traced boot_info->acpi_table's actual aarch64 consumers against real
code before writing the punch list: only pci_init() (unconditional,
relevant since RP1 is PCIe-attached) and this session's own
running_under_hypervisor() (already degrades safely on NULL). GIC
init (arch/aarch64/apic.c) already only tries boot_info->dtb, never
acpi_table -- Pi 5 native boot removes its stated blocker for free.

6-item no-hardware-needed punch list: entry stub at 0x80000, a DTB ->
BootInfo constructor calling the existing unmodified kernel_main()
(the crux of why most of M1-M9 stays shared), the mailbox-interface
framebuffer driver, an fdt.c node-scoped-lookup extension (its own
header already flagged this as a known future need), a DTB-based
pci_init() path for RP1, and config.txt contents. Plus 5 items
deliberately deferred until hardware is in hand 2026-09-17.

Also fixed a formatting slip from an in-progress edit (a bullet
accidentally turned into a malformed heading) before it could compound.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 12:52:37 -04:00
Robert Allan JamesandClaude Sonnet 5 9142d50b73 FABRIC-3.md: Zynq-7000 (Puzhi PZ7010/PZ7020 StarLite) added to hardware reference
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Recorded only, no work scoped -- but unlike BeagleBone Black, this
one isn't a random addition: ROADMAP.md already names Zynq FPGA as
the next big milestone beyond v2.5.0 (the "configurable silicon"
step, tied to the three-product split's HOL-proven sealed-execution
hardware product). This puts a concrete, purchasable board under that
already-named milestone: Puzhi PZ7010-StarLite (XC7Z010) or
PZ7020-StarLite (XC7Z020), dual-core Cortex-A9 PS + Artix-7/Kintex-7
PL fabric, DDR3/JTAG/UART/HDMI/GbE/USB2.0/40-pin, MIPI CSI on the
7020 variant only.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 12:44:57 -04:00
Robert Allan JamesandClaude Sonnet 5 5eeb993ca2 FABRIC-3.md: riscv64 boot chain resolved, BeagleBone Black noted, header bug fixed
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Milk-V Mars boot chain resolved via VisionFive 2 research: the Mars is
a documented mainline U-Boot target using the exact same binaries as
the VisionFive 2 (same StarFive JH7110 SoC) -- U-Boot + OpenSBI +
devicetree, not UEFI, same fork already decided for aarch64. Entry
point 0x40000000, mhartid CSR for core ID, UART at 0x10000000/115200 --
DTB pointer/hart-ID register convention at actual kernel entry not yet
confirmed for this specific chain.

Fixes a real bug from the earlier aarch64 edit: the "## V. riscv64 --
Milk-V Mars" section header had been accidentally dropped, leaving a
stale duplicate "Already true"/"Genuinely open" block sitting where
the real section should have started. Removed the duplicate, restored
the header, folded today's research into the section properly.

BeagleBone Black added to SS VI's hardware-identification reference per
direct instruction -- recorded only, no work scoped around it: it's a
32-bit ARM (TI AM335x, Cortex-A8) SoC, a genuinely different, fourth
architecture this kernel has no support for, not another board under
an existing one.

FABRIC-4.md SS2: captured the pinned-GPIO-VM idea raised in conversation
(Pi 5 needs one, Milk-V Mars explicitly undecided) as a theory-stage
note, cross-referenced from SSIV/SSV's own open-questions lists.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 12:43:15 -04:00
Robert Allan JamesandClaude Sonnet 5 987c751352 FABRIC-3.md: per-board hardware-identification reference (SS VI)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Consolidated SoC/CPU/RAM/I-O facts for all three real-hardware
targets, researched via web search with sources cited rather than
assumed from memory:

- amd64 (Beelink SER5): Ryzen 7 family confirmed; exact SKU
  (5700U/5800H/7735HS all shipped under this branding) not yet
  confirmed against the actual unit -- flagged, not guessed.
- aarch64 (Raspberry Pi 5): BCM2712, quad-core Cortex-A76 @ 2.4GHz,
  VideoCore VII GPU, LPDDR4X-4267. FEAT_RNG (RNDR) presence on this
  core flagged as unconfirmed either way.
- riscv64 (Milk-V Mars): StarFive JH7110, 4x SiFive U74-MC + 1x S7
  monitor core, up to 1.5GHz. Noted it shares its SoC with the
  StarFive VisionFive 2 -- existing VisionFive 2 bring-up material
  may transfer directly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 12:37:29 -04:00
Robert Allan JamesandClaude Sonnet 5 a66af477ac FABRIC-3.md: aarch64 boot-chain decision -- native boot flow, not UEFI
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Researched both options before deciding. The UEFI path (rpi5-uefi,
TF-A+EDK2, SBBR-compliant) is real but archived since 2025-02-04 --
support ended when newer Pi EEPROM firmware broke compatibility, and
its own README says ACPI support is limited/incomplete. Decided:
native boot flow instead (config.txt/kernel_2712.img/DTB, x0=DTB
pointer at entry, no ACPI at all).

Named the real scope rather than estimating it small: a new,
non-UEFI aarch64 entry path, a DTB-driven BootInfo equivalent, and a
new mailbox-property-interface framebuffer driver (no precedent in
this codebase). The one genuine piece of reusable groundwork:
starkernel/hal/fdt.c's minimal FDT reader, already built for
riscv64's timebase-frequency lookup, extends directly to Pi 5
peripheral discovery.

Also documents the peripheral-RNG research: BCM2712 has no
brcm,bcm2712-rng200 (or equivalent) entry anywhere in current
mainline Linux, and RP1's own published peripheral list doesn't
mention an RNG -- genuinely unresolved, not just under-researched.

Not yet turned into a punch list -- the boot-chain fork's own shape
needs thinking through first.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 12:34:30 -04:00
Robert Allan JamesandClaude Sonnet 5 e5e28d5198 FABRIC-3.md: amd64 bare-metal-boot planning decided + punch list
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 12:27:38 -04:00
Robert Allan JamesandClaude Sonnet 5 7f9a4d4d4a FABRIC-3.md: three per-architecture bare-metal-boot planning sections
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
Per direct instruction: amd64's real goal is genericity (any x86_64
laptop/desktop/tower/mini, not just the Beelink SER5 reference
machine); aarch64 targets the Raspberry Pi 5 exclusively; riscv64
targets the Milk-V Mars exclusively -- no cross-board genericity
requirement for the latter two, unlike amd64.

Each section starts from what's already true (ROADMAP.md's existing
v2.2.0/v2.4.0/v2.5.0 board-by-board gates, the already-built
thumbdrive/iso-usb Makefile targets, the amd64 RDRAND backend) and
names what's genuinely still unknown rather than assuming -- most
notably whether the Milk-V Mars boots via UEFI (like this project's
QEMU riscv64 target) or via U-Boot+OpenSBI+devicetree, which would
need a different boot entry path, not just different peripheral
addresses.

Doc-only change, no acceptance build needed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 12:02:45 -04:00
Robert Allan JamesandClaude Sonnet 5 8717416d36 FABRIC-3.md: version correction -- LITHOS_VERSION back to 2.0.0, plus a rename-gap fix
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
LITHOS_VERSION 2.0.1 was premature: per this project's own versioning
policy, 2.0.1 claims SER5 hardware-track progress (RDRAND backend +
thumbdrive image) that was never actually verified on real hardware --
that verification is FABRIC-3.md's own open topic. Reset to 2.0.0
(still a QEMU-only release, correctly). Verified 3-arch boot shows
"LithosAnanke v2.0.0" in each serial log directly, not assumed from the
Makefile edit alone.

Also closes a real gap found in today's earlier FABRIC-series rename:
Makefile.starkernel, Kconfig.kernel, scripts/bleach_zuse_img.sh, four
proof/*.thy files, and isr.S were never swept -- the original file list
only matched *.md/*.c/*.h/*.4th, silently skipping every other
extension. Fixed with the same safe placeholder substitution.
.claude/settings.local.json's historical permission-grant log and
ClaudeEXPORT/'s frozen export were deliberately left untouched.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 11:53:44 -04:00
Robert Allan JamesandClaude Sonnet 5 fcba528273 FABRIC-3.md: Task 1 closed -- master fast-forwarded to v2.0.1, verified
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
master (d2a0305) was a strict ancestor of v2.0.1 (72c14cb) -- pure
fast-forward, no real merge needed. Fast-forwarded local master,
pushed to origin (58c59e8..72c14cb). Verified on a genuinely clean
master tree rather than inferring from the fast-forward: hosted build
clean, 3-arch kernel acceptance (amd64/aarch64/riscv64, each in the
foreground) all reached ok>/zuse)ok> and shut down cleanly, identical
to v2.0.1's own last acceptance pass. master and v2.0.1 are now
identical on both local and origin.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 11:37:29 -04:00
Robert Allan JamesandClaude Sonnet 5 72c14cb9eb FABRIC-3.md: open new living document (bare metal boot); close FABRIC-2.md
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details 
FABRIC-2.md closed/archival as of 2026-09-04 -- its full punch list
(§I) was worked through to completion this session. FABRIC-3.md opens
as the new living document, topic: bare metal boot (FABRIC-2.md §I.6's
own Milestone 8, the one item that couldn't close from a coding
session -- needs a real machine and a human present).

First task written up before executing, per this series' own standing
discipline: merge v2.0.1 into master and verify build/function
equivalence on a clean master tree. Investigated the branch topology
first -- master is a strict ancestor of v2.0.1 (47 commits behind, no
divergent history), so this is a pure fast-forward, not a real merge.

Updated FABRIC-4.md's and .claude/CLAUDE.md's stale pointers at
FABRIC-2.md as "current/living" to point at FABRIC-3.md instead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 11:31:04 -04:00
Robert Allan JamesandClaude Sonnet 5 b031b802e3 Rename FABRIC series: FABRIC.md->0, FABRIC-2.md->1, FABRIC-3.md->2, FABRIC-4.md unchanged 
FABRIC.md -> FABRIC-0.md
FABRIC-2.md -> FABRIC-1.md
FABRIC-3.md -> FABRIC-2.md (the current/living document)
FABRIC-4.md unchanged (new #3 to follow separately)

Every cross-reference repo-wide updated to match, including doc-comment
citations inside kernel source (.c/.h) files -- done via an ordered
placeholder substitution (FABRIC-3.md->placeholder2, FABRIC-2.md->
placeholder1, FABRIC.md->placeholder0, then placeholders resolved to
final names) in a single pass per file to avoid double-shifting
already-renamed references.

One line in capsules/font.4th grew past the 64-char block-format limit
as a side effect of the longer filename; shortened it and reverified
with mkcapsule --lint (34/34 pass) before rebuilding.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64, each in the
foreground) after the fix; logs and DoE CSVs from this session's
verification runs included per this repo's own audit-artifact
convention.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 11:22:51 -04:00
Robert Allan JamesandClaude Sonnet 5 ff2941dfb9 FABRIC-3.md §I.7: close Milestone 9 deferral now that its precondition is met 
The item only ever tracked whether the deferral itself was still
correctly in force, not the networking work. Milestone 7 (§I.5) closed
this session, satisfying the precondition, so the deferral resolves --
Milestone 9's actual networking design stays a separate, still-unscoped
effort, correctly out of scope on its own terms (FABRIC-2.md's own
sequencing: after ACL/PKI/contrib, not concurrent with it).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 11:05:51 -04:00
Robert Allan JamesandClaude Sonnet 5 eeceec21a5 FABRIC-3.md §I.5: Milestone 7 trust tiers (QEMU-vs-real-hardware), closing it 
Closes the contributor-capsule/trust-tier punch-list item. Decided
direction: QEMU-vs-real-hardware conditional enforcement.

Found before building on that decision: the obvious mechanism (expose
TimerInfo.vm_mode) only works on amd64 -- aarch64 and riscv64 both had
vm_mode hardcoded to 1 unconditionally, meaning they'd always report
"running under QEMU" even on real hardware. Built real detection for
both instead of shipping that: aarch64 checks the ACPI RSDP's OEM ID
for QEMU's "BOCHS " SeaBIOS-heritage signature; riscv64 checks the
devicetree root compatible property for "qemu". Confirmed vm_mode was
otherwise unread anywhere else in either file first -- zero risk to
existing timing behavior.

CAPSULE_FLAG_CONTRIB (mkcapsule.c: FLAG_CONTRIB) path-matches on
capsules/contrib/, mirroring FLAG_MAMA_INIT's exact-match pattern.
contrib_capsule_refused() (capsule_birth.c) enforces: no additional
check under QEMU (same WARN-only as everything else); on real hardware,
a contrib capsule additionally requires CAPSULE_SIG_OK, since it has no
other provenance to fall back on. Wired into capsule_birth_baby() and
capsule_run_experiment().

Also updates §I.7 (Milestone 9): its stated precondition (Milestone 7
closing) is now met, flagged as stale rather than treated as a green
light to design networking from nothing.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64, each in the
foreground) -- compile/boot verification only; the real-hardware
enforcement branch is unverifiable from this environment, same as all
of §I.6. logs and DoE CSVs from this session's verification runs
included per this repo's own audit-artifact convention.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 11:04:25 -04:00
Robert Allan JamesandClaude Sonnet 5 5567d03c12 FABRIC-3.md §I.4: magic-number content-type detection, closing Milestone 6 
Closes both remaining Milestone 6 (PKI) punch-list items.

Signature-status column: doc-only closure -- the underlying need was
already redirected to capsules/BLOCK_MAP.md's real Signed column
(2026-08-26); checking the box off as moot-as-worded rather than
leaving an accurate-but-permanently-unchecked marker.

Magic-number content-type detection (Section U item 14): built in
tools/mkcapsule.c. detect_content_type() classifies a file's actual
leading bytes (TTF/OpenType sfnt tags, DER's 0x30 SEQUENCE tag, or a
printable-ASCII/TAB/CR/LF heuristic for text) against
expected_type_from_ext()'s .4th/.md/.der/.ttf mapping; process_file()
warns on mismatch, never refuses -- same WARN-first rollout this
project already used for capsule signing. Verified against every real
capsule in the repo (38 files) with zero false positives. This is the
shared primitive Milestone 7's contrib-capsule validation can reuse
next.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64, each in the
foreground); logs and DoE CSVs from this session's verification runs
included per this repo's own audit-artifact convention.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 10:45:57 -04:00
Robert Allan JamesandClaude Sonnet 5 4018fe8b04 FABRIC-3.md §I.2: FIRSTTOUCH + migration state machine (blk_meta_relocate_devblock) 
Closes the block-subsystem punch-list item -- built exactly to §F.11's
already-decided algorithm after re-verifying it against current
blk_meta_t (a 2026-09-03 re-scoping note had wrongly claimed the chain
fields no longer existed; they do, untouched by BMAPFMT).

blk_firsttouch_claim(): one linear scan of Artemis's own device
(new blk_get_first_disk_range(), correctly bounding the scan instead of
the global multi-device LBN space), scattered-chain claim via
prev_block/next_block/chain_length, owner_fp stamped on every member
devblock, fails outright with no partial claim.

blk_meta_relocate_devblock(): the real migration primitive -- bridges
the existing FORTH-block-granularity blk_subsys_relocate_block() up to
devblock granularity (BLK_PACK_RATIO=3, corrected mid-design), running
it 3x and transferring blk_meta_t ownership fields. The "migration
state machine" turned out to be just the 2 states BLK_FLAG_MIGRATING
already reserved; the real design work was the trigger. Two were
scoped in conversation (overflow onto Artemis; heat-based wear
leveling); heat/wear-leveling is built and wired into sk_repl_idle()
via blk_meta_t.write_count. Overflow is deliberately left open,
precisely scoped (needs a slot-lookup-by-device-pointer call site
threaded from WIREBIND) rather than guessed at.

Also flagged, not fixed: BMAPFMT's owner_fp/CLAIMED and the pre-existing
BAM allocator are two parallel, unreconciled accounting systems --
FIRSTTOUCH/relocate only touch the former.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64, each in the
foreground); logs and DoE CSVs from this session's verification runs
included per this repo's own audit-artifact convention.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 10:33:47 -04:00
Robert Allan JamesandClaude Sonnet 5 1d468a65b1 FABRIC-3.md §I.1: (user) console prompt segment, closing the 4.4s->4.3->1.11 chain 
Extends the REPL prompt to "[VM name] (user) ok>" (e.g. "[Hera]
(zuse) ok>") per the locked FABRIC.md §4.4s spec, unblocked by this
session's own §I.3/§I.8 identity-tracking work. Adds
capsule_wirebind_attached_username() alongside the existing tracked
VMUuid, and a new sk_print_prompt() helper (repl.c) that all three
prompt call sites now go through -- checks Zuse first, then a WIREBIND
user, prints nothing when neither is attached.

Closes 4.4s, 4.3 (console umbrella), and formally settles 1.11
(dirty-event granularity) as region-based per FABRIC-2.md's own "no
independent path" ruling -- a decision closure only, not an
implementation, so §17.4 (framebuffer heat/decay physics) stays open,
re-scoped precisely: blocked on the dirty-region-tracking mechanism
existing, not on 1.11's decision.

Documents a reported-but-unreproduced terminal defect (§I.9) as a new
punch-list item -- investigated the readline/keyboard-bridge code
paths, found nothing conclusive, needs a live repro with a serial log
before it's actionable.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64, each in the
foreground); logs and DoE CSVs from this session's verification runs
included per this repo's own audit-artifact convention.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 09:42:26 -04:00
Robert Allan JamesandClaude Sonnet 5 60d9c2520e FABRIC-3.md §I.3/§I.8: WIREBIND EJECT/detach + EXPIRE re-scoped as logout 
Closes §I.3 (Milestone 5 remainder): WIREBIND now tracks which VM is
attached via the home-blocks USB path, and a new EJECT word plus the
existing hot-unplug signal both flush/reset-console/kill through it
(FABRIC-3.md §F.10).

Closes §I.8 (EXPIRE/ACL), re-scoped: the original "admit the zuse
session as a Stadium patron and reap on TTL" plan was invalidated a
second time -- Zuse authenticates directly onto Hera, who is patron
zero and permanently pinned, so there is no patron for a reap sweep to
ever find. Built instead as a detach-triggered logout
(capsule_zuse_boot_logout()), the same trigger EJECT/hot-unplug use for
regular WIREBIND users, so neither identity is a special case. Required
a companion fix: install_and_activate() used to skip re-running
ACL-ZUSE-BOOT whenever the cert was already installed, which made a
logout permanent for the rest of the boot; the outer re-attach gate now
checks zuse_session (clears on logout) instead of zuse_cert_installed
(a deliberate permanent one-way ratchet, left untouched).

Verified 3-arch boot to ok> (amd64/aarch64/riscv64, each in the
foreground) after both steps; logs and DoE CSVs from this session's
verification runs included per this repo's own audit-artifact
convention.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
 2026-09-04 09:21:01 -04:00
Robert Allan JamesandClaude Sonnet 5 34203613bb FABRIC-4.md: new forward-looking design-notes scratchpad 
Not a successor to FABRIC-3.md (still the living document) -- a
separate, lower-discipline space for theory-stage ideas caught before
they have real scope. First entry: the Stadium-level "wheel" idea from
conversation with Captain Bob -- a second, Q48.16 phase-accumulator
clock fed by RWOT + the inference engine, meant to schedule when a
future sieve-stack slips in, rate starting fixed and graduating to
adaptive later, mirroring L8's own hardcoded-to-inferred history.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QgooKd5hJNtTYqB6CyK5f9
 2026-09-03 14:11:08 -04:00
Robert Allan JamesandClaude Sonnet 5 b16b54f5a8 FABRIC-3.md: add §I, consolidated live punch list of open items 
Groups the 23 confirmed-still-open items from the 2026-09-03 stale-
checkbox audit (commit 403f53d) by subsystem instead of scattered
document chronology, each pointing back to its full original entry.
Doesn't replace §A/§B as historical record -- it's the live index;
closing an item here should also update its original location.

Two findings surfaced while writing this:
- The block-map first-touch allocation item's own described mechanism
  (blk_meta_t prev_block/next_block/chain_length) is stale -- those
  fields don't exist since §H.12's BMAPFMT rebuild; flagged for
  re-scoping against the current layout.
- EXPIRE (ACL)'s stated blocker ("Phase 8 doesn't exist yet") is now
  stale -- Phase 8 closed 2026-08-26/27 -- but the real remaining gaps
  (no zuse-session lifetime/logout, no Stadium generic ttl-reap
  mechanism) are narrower and still real, so it's flagged, not unblocked.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QgooKd5hJNtTYqB6CyK5f9
 2026-09-03 13:48:33 -04:00
Robert Allan JamesandClaude Sonnet 5 403f53d056 FABRIC-3.md: retroactively check 11 stale-carried-forward items 
Audited all 34 unchecked checklist lines against the actual codebase.
Checked off 11 that were already done -- most were completed in
FABRIC-2.md/FABRIC-3.md sections written after the item's own carry-
forward, never reconciled back to the original checkbox: the DoE
Stadium-substrate re-run (5.1), xHCI stall recovery (G.1), CERTVERIFY,
the whole BINDSTEP cluster (key/lock design, hotplug-to-birth wiring,
USE guard), and the Milestone 6 PKI generation/embedding/signing steps.
Each gets a RETROACTIVELY CHECKED annotation citing real file:line
evidence. One item (MANIFEST_AUTO.md signature column) investigated and
left unchecked on purpose -- the goal was met via a different file
(BLOCK_MAP.md's Signed column), not the one this item names.
The other 23 unchecked items were verified still genuinely open (several
require real hardware, not verifiable from code) and left untouched.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QgooKd5hJNtTYqB6CyK5f9
 2026-09-03 13:34:29 -04:00
Robert Allan JamesandClaude Sonnet 5 2b9fa02354 §H.12 steps 21-22: ELEVATE-REQUEST + ELEVATE-GRANT + SEND-ELEVATE-REQUEST 
Phase 7 complete, closing out §H.12's punch list. MSG-DELIVER turned out
to VM-EXEC payload text directly rather than dispatching by type, so the
"handler" is ELEVATE-GRANT, a word the delivered text calls. New Hera-only
C primitives (ZUSE-ELIGIBLE?, NAME>XT, ELEVATE-PUBKEY-UNPACK) stay plain
and unconditional; capsules/zuse-eligibility.4th composes the actual
eligibility check + ACL-ALLOW!/ACL-TTL! grant in FORTH.
SEND-ELEVATE-REQUEST (common:messaging.4th) builds the payload text and
sends it via the item-20-gated CH-REQUEST.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QgooKd5hJNtTYqB6CyK5f9
 2026-09-03 13:15:40 -04:00
Robert Allan JamesandClaude Sonnet 5 cb6e079a73 §H.12 step 20: CH-REQUEST initiator-only gate (MY-CH-ID) 
Added VARIABLE MY-CH-ID to messaging.4th (fail-closed -1 default) and
set it per-VM in hermes/init.4th and artemis/init.4th. CH-REQUEST now
refuses if the caller-supplied 'from' doesn't match the calling VM's
own id, closing a real spoofing gap found while implementing this.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QgooKd5hJNtTYqB6CyK5f9
 2026-09-03 12:09:29 -04:00
Robert Allan JamesandClaude Sonnet 5 7d53344875 §H.12 step 19: ZUSE-ELIGIBILITY-ADD word, no gating (corrected mid-step) 
Plain FORTH word wrapping zuse_eligibility_add() unconditionally. Two
wrong first attempts (C-level zuse_session check, then a FORTH wrapper
checking it) both corrected: zuse_session isn't a special axis needing
its own gate anywhere -- Zuse's authority is the absence of any ACL
restricting her, not a flag any word checks.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QgooKd5hJNtTYqB6CyK5f9
 2026-09-03 11:38:07 -04:00
Robert Allan JamesandClaude Sonnet 5 f4615cf605 §H.12 step 18: zuse_eligibility.c -- read/add/membership-check 
is_member() (fail-closed) and add() (idempotent, chains new devblocks
onto the tail as needed) over the item-17 eligibility-list devblock
chain, mirroring capsule_zuse_boot.c's magic/version/CRC-64 validation
convention. No callers yet.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QgooKd5hJNtTYqB6CyK5f9
 2026-09-03 11:24:24 -04:00
Robert Allan JamesandClaude Sonnet 5 21ad5f7373 §H.12 step 17: zuse_eligibility_list.h -- eligibility-list record format 
Growable owner_pubkey[32]-list devblock type for the metadata fence,
one slot over from zuse_genesis_marker_t (§H.5 Phase 6). Type only,
no read/add/check logic yet.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QgooKd5hJNtTYqB6CyK5f9
 2026-09-03 11:12:37 -04:00
Robert Allan JamesandClaude Opus 5 46d89dd5be §H.12 step 16: block-acl.4th policy capsule -- Phase 5 (BMAPFMT) complete 
capsules/block-acl.4th (blocks 4019-4020, next free range per
BLOCK_MAP.md): BLK-ACL-CHECK (block# -- allow?), a real fast-deny check
mirroring vm.c:611-624's pattern for blocks instead of words. First
touch lazily claims the block (allow=1, TTL=256, same base as ACL.4th's
own), matching the word card's default-permissive baseline. Not a stub --
genuinely does something on every call.

Loaded via a new EXEC line in init.4th right after ACL.4th's own;
confirmed ACL.4th's own activation is unaffected. Passed mkcapsule
--lint. Live-tested via QMP keystrokes: 1 BLK-ACL-CHECK executed cleanly.

Phase 5 (BMAPFMT) is now fully complete -- field layout, flags bits, C
accessors, FORTH wrappers, and a real policy word.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 07:44:28 -04:00
Robert Allan JamesandClaude Opus 5 405c713c4a §H.12 step 15: FORTH wrappers for BMAPFMT block-ACL fields 
BLK-ACL-ALLOW@/!, BLK-ACL-TTL@/!, BLK-OWNER@ registered in block_words.c.
BLK-OWNER@ packs the 8-byte owner fingerprint into one cell (cell_t is
int64_t). No BLK-OWNER! -- ownership stays a controlled C-only operation.

Live-tested via QMP keystrokes on a running instance: 1 BLK-ACL-ALLOW@
executed cleanly against a real block. Verified 3-arch boot to ok>
(amd64/aarch64/riscv64) plus a hosted sanity build (shared source).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 07:36:57 -04:00
Robert Allan JamesandClaude Opus 5 15e6836ca3 §H.12 step 14: C accessors for BMAPFMT block-ACL fields 
blk_owner_fp_get/_set, blk_acl_allow_get/_set, blk_acl_ttl_get/_set,
blk_flags_get/_set -- thin read-modify-write wrappers over the existing
blk_get_meta()/blk_set_meta() (caching/dirty-tracking already owned
there). Sets up the C-primitive layer FORTH wrappers (step 15) will call,
mirroring the word-level ACL system's own split.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 07:29:01 -04:00
Robert Allan JamesandClaude Opus 5 c19cc07ee3 §H.12 step 13: blk_meta_t flags bit constants 
BLK_FLAG_CLAIMED/BLK_FLAG_MIGRATING/BLK_FLAG_STALE (bits 0/1/2), matching
the decided §F.4/§H.6 layout. Orthogonal bits, not a mutually-exclusive
enum.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 07:23:27 -04:00
Robert Allan JamesandClaude Opus 5 edd7effb5a §H.12 step 12: BMAPFMT field layout in blk_meta_t 
Replaced the old 40-byte owner_id/permissions/acl_block/signature[2]
with owner_fp[8]/acl_allow/acl_ttl (u32)/acl_reserved[3]/reserved_future,
matching the decided §F.4/§H.6 layout.

Found a pre-existing bug via a real offsetof/sizeof compile check
(not hand math, per this step's own instruction): sizeof(blk_meta_t)
was already 344, not the 341 its own BLK_META_PER_BLOCK constant and
"341-byte slice" comment claimed -- harmless since that constant has
zero callers anywhere. New size after this edit's own alignment
padding is 336. Added a _Static_assert matching blk_volume_meta_t's
existing precedent, and fixed the stale comment to point at it.
BLK_META_PER_BLOCK itself untouched -- unused, out of scope.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 07:18:41 -04:00
Robert Allan JamesandClaude Opus 5 a268abe925 §H.12 steps 10-11: creator-ceiling enforcement, birth-time ACL snapshot 
dictionary_snapshot_acl_from_parent(child, parent): walks the child's
dictionary, copies acl_allow/acl_mode/acl_pinned/acl_ttl from the
parent's matching word (by name, via vm_find_word() -- FIND's own
lookup, not modified) onto the child's entry. One-time snapshot at
birth, no live sync, matching H.3's decided rationale (a program
developed against one ACL set must not have it silently changed by
later parent changes).

Called once, after dict_hash/parity logging rather than before -- the
snapshot depends on the parent's current ACL state, which can vary
run-to-run once Zuse elevations exist, so applying it earlier would
break the "same capsule twice produces the same dict hash" determinism
invariant.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 06:44:58 -04:00
Robert Allan JamesandClaude Opus 5 ed86a759e1 §H.12 steps 7-9: thread real parent VMUuid through the birth call chain 
Session.parent now comes from the actual birthing VM's own
stadium_vm_id, not a hardcoded vm_uuid_hera(). Added a VMUuid parent
parameter to capsule_birth_baby() and, one level up, to
capsule_console_birth()/capsule_runcap_birth() (neither had a VM* in
their own signature, but every caller did). Updated all 6 real call
sites: BIRTH, CAPSULE-BIRTH, CONNECT-ARTEMIS, CONNECT-HERMES,
RUNCAP-TEST, PAIR-TEST (mama_forth_words.c) and the console+user birth
pair in capsule_wirebind_try_attach() (capsule_wirebind.c). Two
functions had their vm parameter marked __attribute__((unused)), now
genuinely used -- attribute removed.

Steps 8 (Session.name from capsule name) and 9 (identity defaults to
installed=0) were already satisfied by step 5's existing
session_register() call and its identity-zeroing -- confirmed by
inspection, no further code needed.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 06:38:32 -04:00
Robert Allan JamesandClaude Opus 5 09998af999 §H.12 steps 5-6: pin Hera/Hermes/Artemis in generic capsule-birth admission 
capsule_birth.c's generic admission block now registers a session for
every born VM (session_register) and pins it (session_set_pinned) when
the birthing capsule is Hera/Hermes/Artemis.

Bug found and fixed via a temporary probe (written, run, captured,
reverted): the fleet-foundation name check first used an exact-match
comparison against "Hermes"/"Artemis", but capsule_name is actually
"hermes:init.4th"/"artemis:init.4th" (the real namespace:filename
convention) -- the check silently never matched, both would-be-pinned
VMs stayed unpinned. Fixed with a new vm_name_prefix_eq_nocase() helper
matching everything before a literal ':'. Probe confirmed pinned=0 before
the fix, pinned=1 after, on all relevant VMs.

Session.parent is hardcoded to vm_uuid_hera() for now (every birth
through this path is Hera-initiated today); step 7 generalizes this to
the actual birthing VM's own id.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64) on the final,
probe-free code.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 06:26:50 -04:00
Robert Allan JamesandClaude Opus 5 67793ea4a1 §H.12 step 4: Hera registers as session zero; punch list to checkboxes 
Rewired stadium_birth_hera() to admit unpinned then register through
session_register()/session_set_pinned() instead of setting
STADIUM_FLAG_PIN directly on the candidate header. Self-referential
parent (vm_uuid_hera(), vm_uuid_hera()), matching capsule_run.h's
parent_vm_id == vm_id root convention. Soft-fail, non-fatal, if
session_register() fails -- Hera's actual Stadium admission is what the
patron-zero invariant is about. Wired session_boot_init() into
kernel_main.c right after stadium_boot_init(), before stadium_birth_hera().

Also converted §H.12's punch list from bold "DONE" markers to this
document's established - [ ]/- [x] checkbox convention (already used
throughout §A), for consistency.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64), no soft-fail message
on any arch, Hermes/Artemis births unaffected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 06:15:53 -04:00
Robert Allan JamesandClaude Opus 5 a621131ef6 §H.12 step 3: session_set_pinned/session_is_pinned pin-authority choke point 
session_is_pinned() reads Session.pinned directly (authoritative, no
Stadium re-derivation); session_set_pinned() writes both Session.pinned
and the mirrored STADIUM_FLAG_PIN bit on the session's own patron cell,
keeping Stadium's internal eviction/admission logic (which must stay
self-contained) in sync without it calling back into session.c.

Added Session.stadium_cell (index into stadium_cells()) -- necessary
plumbing not in the original H.2 field list; the choke point can't reach
the right patron header without it. Moved STADIUM_FLAG_PIN from a
stadium.c-private #define to stadium.h (public) so session.c can
reference it without a duplicate definition.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 06:10:11 -04:00
Robert Allan JamesandClaude Opus 5 6d9fe3f515 §H.12 step 2: session-slot table, session_find/session_register 
src/starkernel/vm/session.c: kmalloc'd-at-boot slot table sized from
stadium_max_vm_count() (mirrors stadium.c's own StadiumVMQuota, not a
fixed compile-time array as originally planned -- that table was already
moved off a fixed array for the same "population isn't knowable in
advance" reason). session_boot_init()/session_find()/session_register()
implemented for real, no stubs; session_register() zeroes identity and
leaves pinned=0, matching VMIdentity's own documented default and
deferring pin policy to callers. Added session.c to Makefile.starkernel's
explicit source lists. No callers yet.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 06:03:14 -04:00
Robert Allan JamesandClaude Opus 5 668e36bb17 §H.12 step 1: add Session struct (type only) 
include/starkernel/session.h: vm_id (VMUuid), pinned (int, authoritative
over Stadium's STADIUM_FLAG_PIN per H.10), parent (VMUuid), name (fixed
64-byte buffer), identity (embedded VMIdentity, reusing the existing
type rather than inventing a new one). No logic yet, no callers -- next
step wires the session-slot array and register/find functions.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 05:57:01 -04:00
Robert Allan JamesandClaude Opus 5 4cd18734ee FABRIC-3.md §H.12: 22-item implementation punch list 
One coding task per item across 7 phases, each gated by the mandatory
3-arch QEMU boot acceptance test. Two corrections found while grounding
this against live code: capsule_birth.c's generic admission path already
admits every VM as a Stadium patron (just hardcoded unpinned), so no new
stadium_birth_hermes()/_artemis() functions are needed -- the real task
is making that path pin Hera/Hermes/Artemis specifically. VMIdentity
(vm_identity.h) already exists fully built; Session.identity reuses it
directly rather than inventing a new type.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 05:50:00 -04:00
Robert Allan JamesandClaude Opus 5 89d814f9f3 FABRIC-3.md §H: close all three remaining design gaps 
Gap #1: closed set of four cards (VM/word/block/message), no new cards
for now. Gap #2: creator-ceiling enforcement is a birth-time snapshot
copy, not a live ACL-RECHECK-time check -- reversed mid-conversation once
the live-check approach's cross-VM dictionary-lookup problem surfaced;
final rationale is child program stability (a program developed against
one ACL set must not have it silently changed by later parent changes).
Gap #3: Zuse's eligibility list persists in the existing growable
metadata-fence mechanism as a simple owner_pubkey[32] list, no extra
per-entry metadata.

Every design-level question in this refactor is now closed. What remains
is pure implementation (5 items) and two intentional deferrals.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-03 05:43:22 -04:00
Robert Allan JamesandClaude Opus 5 d86b6de9cd FABRIC-3.md §H.11: refreshed gap analysis, end of session 
Full sweep across the whole session-refactor design pass -- 7 of the
original 10 §H.9 gaps are now closed. Compiles the current accurate
picture: one genuinely open design question (more cards beyond the four
named?), two small undecided pieces (creator-ceiling enforcement location,
Zuse eligibility-list storage), five pure implementation gaps (design
fully decided, nothing coded), and two explicitly-deferred non-goals
(VM card multi-owner, elevation trigger alternates). Also updates H.10's
stale "elevation trigger not yet usable" note now that H.7 confirmed the
messaging substrate is already real.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 19:04:48 -04:00
Robert Allan JamesandClaude Opus 5 91dfb0a079 FABRIC-3.md §H: close gap #8 -- EXPIRE/D.2 relationship reconciled 
No actual conflict between D.2 and H.1. D.2 (2026-08-27, "session ending =
VM detach, reuse COOL") was scoped to user sessions, written before
Hera/Hermes/Artemis were framed as having their own persistent sessions.
D.2 is a special case of H.1's broader pinned/non-pinned model, fully
subsumed: it describes exactly how the non-pinned branch behaves. Pinned
sessions have no D.2-style "ending" at all -- permanent by construction.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 19:00:32 -04:00
Robert Allan JamesandClaude Opus 5 26b91f1ca4 FABRIC-3.md §H: close gap #7 -- private-topic traffic stays ungated 
Checked MSG-SEND directly -- no ACL check anywhere in it today, on common
or a private topic alike. Confirmed: private-topic traffic stays ungated;
trust is established once at the handshake (CH-REQUEST/CH-ACCEPT/
CH-CONFIRM) and never re-checked per-message afterward. The message
card's scope is now final: it gates the single CH-REQUEST call, nothing
else in the messaging path.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:57:06 -04:00
Robert Allan JamesandClaude Opus 5 b15339ca1f FABRIC-3.md §H: close gap #6 -- CH is the topic, and H.7/H.8 are real code 
Checked capsules/common/messaging.4th directly instead of assuming: the
H.7 messaging protocol isn't design vision, it's already substantially
built -- COMMON-CH, CH-REQUEST, CH-ACCEPT, CH-CONFIRM, CH-CLOSE, and
local ACK/NACK (MSG-ACK-LAST/MSG-NACK-LAST/MSG-NACKED) all exist and work
today. CH already is the topic, 1:1, no new representation needed.
Upgrades H.7/H.8's framing from "protocol groundwork, not yet real" to
"the mechanism exists, the ACL gate on top of it is the remaining work" --
the message card is now a concrete wiring task, not a hypothetical one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:55:09 -04:00
Robert Allan JamesandClaude Opus 5 33286cb3a2 FABRIC-3.md §H: close gap #3 -- word card IS the existing ACL system 
Checked capsules/ACL.4th directly: both existing modes (STRICT, TTL)
already default to allow=1, matching the word card's default-permissive
baseline. Since each VM has its own dictionary, existing per-word ACL
state is already scoped per-session for free. Confirmed: the word card is
the existing acl_ttl/acl_allow/acl_mode/acl_pinned system reused as-is,
not a new parallel structure. Surfaces one new follow-on gap: creator-
ceiling enforcement at VM birth time isn't designed anywhere yet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:52:32 -04:00
Robert Allan JamesandClaude Opus 5 fdecb91908 FABRIC-3.md §H: close gap #2 -- parent/name session fields confirmed 
Both fields (parent VMUuid, name) confirmed as-is with no adjustment. All
five session fields (vm_id, pinned, parent, name, identity) are now
confirmed, none still model-proposed-only.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:50:23 -04:00
Robert Allan JamesandClaude Opus 5 de513483e3 FABRIC-3.md §H: close gap #1 -- non-pinned session mapping 
Confirmed: an ephemeral user VM's session lands as a non-pinned,
COOL-subject Stadium patron -- synthesized from D.2's earlier finding
(session ending = VM detach, reuse COOL) rather than a fresh decision.
Thumbdrive detach is the explicit trigger. No exception case for a
temporarily-pinned user VM.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:48:25 -04:00
Robert Allan JamesandClaude Opus 5 197ff03963 FABRIC-3.md: BMAPFMT gets FORTH wrappers, design fully closed 
Decided: yes, FORTH wrappers for the block-card ACL primitives, mirroring
the word-level ACL split (raw C accessors, policy composed in FORTH).
zuse_cert_seed's C-only precedent doesn't apply -- that's key material,
block ACL fields are ordinary ACL state like DictEntry's. BMAPFMT's
field/API design (owner_fp, acl_allow, acl_ttl, flags bits, FORTH
wrappers) is now fully decided across this and the prior three passes --
only the actual code edit remains.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:36:52 -04:00
Robert Allan JamesandClaude Opus 5 ce1618dcd8 FABRIC-3.md: BMAPFMT flags bit values decided -- CLAIMED/MIGRATING/STALE 
blk_meta_t's existing unused flags field (uint64_t) uses orthogonal bits,
not a mutually-exclusive enum: bit 0 = CLAIMED, bit 1 = MIGRATING (serves
MIGSM), bit 2 = STALE (serves UNCLEAN), 61 bits reserved. BMAPFMT's field
design (owner_fp, acl_allow, acl_ttl, and now these flags bits) is fully
decided; only the actual code edit to block_subsystem.h/.c remains.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:29:05 -04:00
Robert Allan JamesandClaude Opus 5 a05e6d60ba FABRIC-3.md: BMAPFMT gets a TTL -- blocks support temporary elevation too 
Resolves part of section F.4's deferred item #1 (allow-list/grant shape
beyond the single fast-deny bit): blk_meta_t's acl_reserved[7] becomes a
4-byte acl_ttl (mirroring DictEntry's countdown shape) plus 3 bytes still-
open slack, reusing the same ACL-TTL/Zuse-eligibility-list mechanism as
the word card. Kept lean -- no acl_mode/acl_pinned mirror, since a block
isn't pinned/strict the way a word is. Updated both F.4 (the field design)
and H.6 (the block card) to match.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:26:27 -04:00
Robert Allan JamesandClaude Opus 5 316de60671 FABRIC-3.md §H.10: close pin-authority choke point -- session owns both directions 
Decided: session_set_pinned()/session_is_pinned() (or equivalent) are the
sole read AND write path for pin state -- nothing, including existing
Stadium code, touches STADIUM_FLAG_PIN on the patron header directly
anymore. Not just a write-side guard.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:22:43 -04:00
Robert Allan JamesandClaude Opus 5 a93d4fa2cd FABRIC-3.md §H.10: verify dictionaries are per-VM, not shared 
Checked the load-bearing assumption underneath the word card's
creator-ceiling invariant and the H.5 elevation trigger, both of which
live on DictEntry ACL fields -- confirmed each VM gets its own separate
memory/dictionary buffer at birth (vm_bootstrap.c:181), so DictEntry ACL
state is already naturally scoped per-session. No conflict, no redesign.
Also notes two smaller, lower-risk open items: pin-authority sync between
Session and Stadium's flag, and the elevation trigger's dependency on
not-yet-real Hermes messaging.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:20:13 -04:00
Robert Allan JamesandClaude Opus 5 ba97623349 FABRIC-3.md §H: close gap #4 -- temporary Zuse elevation trigger decided 
Trigger: live message-based request (ELEVATE-REQUEST on common or a
private topic, Zuse's session grants/NACKs, ACL-ALLOW!/ACL-TTL! write on
receipt), gated by a Zuse-held eligibility list keyed by owner_pubkey.
Grounded against capsules/ACL.4th directly -- ACL-TTL is a recheck-cadence
cache, not a grant mechanism; reuse means calling its ACL-ALLOW!/ACL-TTL!
primitives from new Zuse-triggered code, not new C primitives. Live-console
sudo-style grant and pre-signed capability tickets remain deferred, not
rejected, alternates.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:15:44 -04:00
Robert Allan JamesandClaude Opus 5 1349e783aa FABRIC-3.md §H: session refactor capture -- struct shape + identity/ACL cards 
Design capture from today's session-refactor discussion, back to Hera:
session-as-Stadium-patron struct shape (references the patron by VMUuid,
pin-authoritative, identity embedded), and the identity ACL "stack of
cards" model with all four named dimensions scoped so far (VM, word,
block, message) plus the PubSub/topics messaging-protocol groundwork the
message card depends on. Closes with a numbered gap-analysis list (§H.9)
of everything still explicitly open.

Capture-only, matching this document's own established discipline -- no
struct written, no code changed. Mirrors §D's Tripod-vision capture in
style and structure.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 18:08:35 -04:00
Robert Allan JamesandClaude Opus 5 f81e9c92bc Fix framebuffer console: scroll drift causes progressive line overlap in TTF mode 
fb_scroll_rows() hardcoded the pixel distance it physically shifts the
framebuffer by as char_rows * 16 * scale -- the bitmap-font (font_8x16.c)
cell height -- regardless of which glyph mode vt100.c actually had active.
In TTF mode (the REPL's default, cell height 24px via VT100_TTF_CELL_H_PX)
this meant every scroll_up(1) call physically shifted the framebuffer by
only 16px while the text model (g_vt.rows, py_of()) placed each row 24px
apart. That 8px-per-scroll shortfall compounds with every subsequent
scroll: a few scrolls barely show it, but enough scrolls -- or scrolling
quickly, which is just many scrolls in a short span -- accumulates into
visible pixel overlap between rows, with newer lines drawn on top of the
tail end of older ones.

fb_scroll_rect() (the box-confined scroll added later for 4.4t) already
carried a doc comment calling this out explicitly, describing its own
explicit pixel_rows parameter as the fix for fb_scroll_rows()'s "fixed
16px-row assumption" -- fb_scroll_rows() itself was just never updated to
match.

Fixed by changing fb_scroll_rows()'s parameter from an implicit char_rows
count to an explicit pixel_rows count (matching fb_scroll_rect()'s
existing convention), and having its one caller (vt100.c's scroll_up())
pass lines * cell_h() -- the real active cell height -- instead of a raw
line count for the callee to guess at.

Verified: booted amd64 to the REPL (TTF mode active per sk_repl()'s own
console_fb_enable_ttf() call), let boot chatter + WORDS output scroll the
screen through thousands of accumulated scroll_up() calls, then measured
every visible line's y-position via a QMP screendump. Spacing held at a
perfectly consistent 24px (TTF cell height) top to bottom with zero drift
-- the old hardcoded-16px bug could not have produced that after this many
scrolls. Re-verified boot to ok> on all three architectures
(amd64/aarch64/riscv64) per repo acceptance policy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 17:25:06 -04:00
Robert Allan JamesandClaude Opus 5 c14324f498 Fix framebuffer console: idle heartbeat corrupts in-progress input line 
sk_repl_idle() (called every ~1s from sk_console_readline()'s idle loop)
opens with console_ensure_line_start(), which unconditionally forces a
newline whenever the console isn't at a line boundary -- including
mid-edit, after characters have been typed and echoed but before Enter.
This fired on every elapsed SK_IDLE_BEAT_INTERVAL regardless of whether
sk_repl_idle() had anything to print, visually snapping the in-progress
input line to a fresh empty line -- indistinguishable from Enter having
been pressed. Most noticeable on the space key since it's the most common
key hit during a pause.

Gate the idle beat on n == 0 (no in-progress edit), mirroring the n > 0
guard the prompt reanchor logic just below already uses. Deferring the
xhci/block-sync idle service by at most one more interval while a line
is being edited is within its own documented "coarse cadence, cheap
early-exit" tolerance.

Verified: reproduced via QMP send-key against a live amd64 QEMU boot
(multi-character line typed with pauses across several idle intervals
stayed intact after the fix, where it previously broke on each interval).
Re-verified boot to ok> on all three architectures (amd64/aarch64/riscv64)
per repo acceptance policy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-02 17:12:21 -04:00
Robert Allan James daf9021ea5 Initial commit 
Signed-off-by: Robert Allan James <robert.allan.james@gmail.com>
 2026-09-01 12:09:20 -04:00
Robert Allan James 58c59e87e5 Initial commit 
Signed-off-by: Robert Allan James <robert.allan.james@gmail.com>
 2026-09-01 12:07:32 -04:00
Robert Allan James d2a0305703 Record driving deadlines for #1 (provisional expiry) and #2 (December deliverable) 
Clarified 2026-08-29 with the author: "no hurry" is wrong for #1 and #2.

  - #1 (Hosted StarForth): the provisional will expire before conversion. Its
    priority claim is time-boxed (provisional filed ~Dec 2025, window ~Dec
    2026); if the non-provisional isn't filed claiming benefit before the
    window lapses the priority is lost and the same subject matter can't be
    re-staked by refiling thereafter. Hard clock regardless of December scope.
  - #2 (full StarshipOS): the December deliverable that keeps the flagship
    covered; pending counsel confirmation it may also be the conversion
    vehicle for #1's provisional.

Open point to resolve: is #2 (or the December delivery) the conversion vehicle
for #1, or is #1 converted by a filing separate from #2? Decision record only;
no filing made. Authoritative form in ROADMAP.md; FABRIC-3.md tracks it.
 2026-08-29 10:36:19 -04:00
Robert Allan James 31dfc5de63 Record IP framing of the three products: 3 patent applications + 3 marks (StarForth, StarshipOS/LithosAnanke, Compudynamics) 
The three-product split is treated as three patent applications, each matched
to a trademark (decided 2026-08-29):

  - Patent 1 + mark StarForth                  -> hosted/interpreted runtime
  - Patent 2 + marks StarshipOS (canonical spelling; noted as "StarshopOS"
    in the decision words) + LithosAnanke       -> full standalone OS
  - Patent 3 + mark Compudynamics               -> Zynq steady-state machinery
    with sealed executions, HOL-proven, anchored by the physics-adaptive runtime

Flagged open for counsel (not assumed/filed): the repo already carries a
"Patent pending" USPTO provisional filed Dec 2025 for the Compudynamics
physics-adaptive runtime (docs/patent/). Whether patent 3 is a continuation/
refinement of that provisional, and whether the three product applications are
additive to or fold it in, must be reconciled. Records intent only; no legal
text drafted or filed. Authoritative form in ROADMAP.md; FABRIC-3.md tracks it.
 2026-08-29 10:32:04 -04:00
Robert Allan James 936d046ca6 Record the FPGA three-product split: Hosted StarForth / full StarshipOS / HOL-proven sealed-execution hardware 
The Zynq FPGA is not a fourth platform to port to — it is the pivot that
forces the project into three distinct products, each with its own host,
delivery, and proof character (decided 2026-08-29):

  1. Hosted StarForth - the existing hosted/interpreted StarForth runtime
     (3-arch acceptance-tested), delivered as a portable embedded runtime.
  2. A full StarshipOS - the standalone OS built on LithosAnanke
     (LithosAnanke -> StarshipOS), a self-booting OS on general silicon
     (SER5/RasPi/Milk-V line).
  3. Hardware steady-state machinery with sealed executions, HOL-proven -
     the FPGA-native product: hardware-enforced sealed executions and
     steady-state machinery machine-checked in a proof assistant (HOL);
     delivery is the bitstream + HOL proof artifacts, not just an OS port.

The coupling is the point: product 3 is born on the FPGA, and its existence
is what cleanly separates 1 from 2 from 3. Product 1 ships hosted on an OS,
product 2 as an OS on general silicon, product 3 as proven hardware. Per-
product gates and the even-major line carrying the three as separate tracks
are scoped at v2.5.0 close / during the coloring-in phase. Complements, and
does not retract, the existing hardware bare-metal release policy.

Authoritative form in ROADMAP.md; FABRIC-3.md tracks the same horizon.
 2026-08-29 10:30:09 -04:00
Robert Allan James 8e94522d10 Record trajectory beyond v2.5.0: Zynq FPGA next, after a "coloring in" hardening phase 
The next big milestone after the three-board bare-metal cut (v2.5.0) is
transferring the battle-tested amd64/aarch64/riscv64 story to a Zynq (AMD
Xilinx) FPGA SoC — configurable silicon with soft/hard CPU cores, PL fabric,
and a non-standard memory map, a genuinely larger step than any prior board
(expected on a new even-major line). Between v2.5.0 and the Zynq sits a
"coloring in" period: hardening that thickens the shape of what exists rather
than adding silicon (USB BOT/xHCI + block robustness, live-entropy and
Zuse-cert hardening on real ASICs, SMP/multi-core + IRQ routing from the HAL
notes, driver breadth) so the FPGA carries a production-honest shape forward.

Authoritative form in ROADMAP.md "Beyond v2.5.0"; FABRIC-3.md tracks the same
horizon in the post-release section and re-points G.6's Next at the
v2.2.0/v2.4.0/v2.5.0 cadence.
 2026-08-29 10:28:22 -04:00
Robert Allan James 25276ae359 Decide board-by-board hardware rollout: v2.2.0 (SER5 amd64) / v2.4.0 (RasPi5 aarch64) / v2.5.0 (all three) 
Real silicon arrives incrementally (Beelink SER5 in hand now; RasPi 5 + Milk-V
orderable around Mon 2026-08-31), so the hardware release is split per board
in hand, each an even-minor LTS point-in-time cut on the same line:

  - v2.2.0  amd64 bare metal  — Beelink SER5 (two 16GB sticks: one boots the
                                thumbdrive image, one mints a real Zuse user)
  - v2.4.0  aarch64 bare metal — Raspberry Pi 5
  - v2.5.0  all three bare     — adds Milk-V (riscv64)

Each closes only when its board's items are proven live (boot to ok>, block-
fence Zuse true, backend entropy non-deterministic), never build-only.

Records the decision in the authoritative Release Versioning Policy
(docs/lithosananke/ROADMAP.md, "Board-by-board hardware rollout, decided
2026-08-29") and re-maps G.4/G.5 in FABRIC-3.md onto the new cadence, noting
v2.0.0 was cut (tag v2.0.0).
 2026-08-29 10:22:36 -04:00
Robert Allan James 28de700645 v2.0.1: G.4 amd64 RDRAND backend behind rng_get_bytes() (SER5 entropy) 
First real per-arch RNG backend, added to the v2.0.0 unified entry point in
src/starkernel/rng/rng.c, #if-guarded to amd64: CPUID.01H:ECX[30] RDRAND
detection + inline-asm rdrand draws feeding rdrand_fill() (whole-byte
emission from the low end; a partial final draw is discarded -- throwing
away entropy is always safe).

Probe order honors the release policy: virtio-rng is tried first, so the
QEMU path stays on virtio-rng unchanged; RDRAND is the fallback only real
hardware (which has no virtio-rng device) reaches. QEMU-verified both ways
on amd64: with virtio-rng present -> "rng: backend = virtio-rng" (unchanged);
with virtio-rng absent and RDRAND exposed (-cpu max) -> "rng: backend =
rdrand" + "entropy: ready" + Zuse attach confirmed. rdrand_fill()'s exact
logic host-proven: fills 32-byte/16-byte buffers and yields differing draws
run-to-run (non-deterministic). aarch64/riscv64 builds unaffected (guarded
off). riscv64 Zkr and aarch64 peripheral-RNG backends remain parked for their
real boards.

FABRIC-3.md G.4 amd64 slice marked BUILT + QEMU-verified.
 2026-08-29 10:18:07 -04:00
Robert Allan James 19bc90c97d v2.0.1: document G.6 generic thumbdrive image milestone in FABRIC-3.md 2026-08-29 10:12:58 -04:00
Robert Allan James bd266942ce v2.0.1: generic GPT/FAT32 UEFI bootable thumbdrive image (thumbdrive goal) 
New `make -f Makefile.starkernel thumbdrive` goal builds a generic
UEFI-bootable GPT disk image (disk image -> GPT + one FAT32 "STARKERNEL"
EFI System partition with EFI/BOOT/BOOT<ARCH>.EFI + startup.nsh) that can be
written directly to a USB thumbdrive with dd and boots on any real amd64 UEFI
firmware (Beelink SER5 path) as well as under QEMU. The monolithic loader
embeds the whole kernel, so the ESP needs only the UEFI fallback boot path.

Verified under QEMU by attaching the image as a USB mass-storage device (not
cdrom): OVMF BDS auto-selected "UEFI QEMU QEMU USB HARDDRIVE" (Boot0002),
then kernel booted normally -- LithosAnanke v2.0.0, POST 1012/0/0 + ok>,
rng: backend = virtio-rng + entropy: ready, Artemis ready, and the USB BOT/
xHCI storage path enumerated (READ CAPACITY10 -> MSC device ready -> READ10
CSW PASS). This mirrors the real-hardware SER5 flow: firmware boots the USB
thumbdrive's ESP, and the OS's own storage rides the same USB BOT/xHCI path.

Works for all three arches via the arch-mapped EFI boot name.
 2026-08-29 10:12:43 -04:00
Robert Allan James 2efd7fe7e7 v2.0.0: QEMU release — bump LITHOS_VERSION to 2.0.0 
The §G v2.0.0 QEMU release-gate punch list is complete (G.1 xHCI stall
recovery, G.2 unified rng_get_bytes() entropy entry point, G.3 NVRAM
de-scoped). Bump the kernel version to 2.0.0 (even major = LTS, per the
Release Versioning Policy: X.0.0 = QEMU release, X.5.0 = hardware bare-metal
release). Update README and .claude/CLAUDE.md version references and the
Makefile.starkernel version-roadmap comment.

Verified: all three arches (amd64/aarch64/riscv64) build clean with v2.0.0
embedded; QEMU amd64 boot shows "LithosAnanke v2.0.0", POST 1012/0/0 + ok>,
rng: backend = virtio-rng + entropy: ready, and Zuse identity confirmed from
the attached thumbdrive.
 2026-08-29 10:09:37 -04:00
594 changed files with 2294082 additions and 9583 deletions
Expand all files Collapse all files
.claude/ARTEMIS.md
+4 -4
View File
@@ -5,11 +5,11 @@
---
> **SUPERSEDED (Captain Bob, 2026-08-15).** This document is no longer authoritative.
> `FABRIC.md`/`FABRIC-2.md` (repo root — read `FABRIC-2.md` first, it is the current/living
> `FABRIC-0.md`/`FABRIC-1.md` (repo root — read `FABRIC-1.md` first, it is the current/living
> one) are the sole design-of-record for Artemis work now. Kept here as historical record
> only; do not read this for current design authority, and do not cite it in place of
> `FABRIC.md`/`FABRIC-2.md`. Artemis becoming the pre-Artemis-closeout blocker (item 4.6) is
> tracked in `FABRIC-2.md`, not here. See `.claude/CLAUDE.md`'s own pointer.
> `FABRIC-0.md`/`FABRIC-1.md`. Artemis becoming the pre-Artemis-closeout blocker (item 4.6) is
> tracked in `FABRIC-1.md`, not here. See `.claude/CLAUDE.md`'s own pointer.
---
@@ -148,7 +148,7 @@ for this scope. `capsules/artemis/init.4th` implements the full flat-pool
target above.
**Corrected 2026-08-13 — the "boots live in the Tripod fleet... on every
kernel boot" claim below is stale since item 0.1 (`FABRIC.md` Phase 0),
kernel boot" claim below is stale since item 0.1 (`FABRIC-0.md` Phase 0),
same pattern already found and fixed in `TRIPOD.md`.** Two distinct things
were being conflated: Artemis's block-storage *device* (the virtio-blk
disk, `disk/artemis.img`) genuinely does auto-attach at the C level at
.claude/CLAUDE.md
+10 -9
View File
@@ -10,12 +10,13 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
> **Superseded subsystem docs (Captain Bob, 2026-08-15):** `.claude/TRIPOD.md`,
> `.claude/HERMES.md`, `.claude/ARTEMIS.md`, and `.claude/CONSOLE.md` are all superseded —
> `FABRIC.md` and `FABRIC-2.md` (both design history/archival as of 2026-08-25) and
> `FABRIC-3.md` (current/living, read this one first) are the sole authoritative source for
> Tripod/Hermes/Artemis/Console work now. The four subsystem docs remain in the repo as
> historical record only; each carries its own superseded-header pointing here. Do not treat
> them as current, do not read them for design authority, and do not cite them in place of
> `FABRIC.md`/`FABRIC-2.md`/`FABRIC-3.md`.
> `FABRIC-0.md`, `FABRIC-1.md`, and `FABRIC-2.md` (all design history/archival as of
> 2026-09-04) and `FABRIC-3.md` (current/living, topic: bare metal boot, read this one first)
> are the sole authoritative source for Tripod/Hermes/Artemis/Console work now. The four
> subsystem docs remain in the repo as historical record only; each carries its own
> superseded-header pointing here. Do not treat them as current, do not read them for design
> authority, and do not cite them in place of `FABRIC-0.md`/`FABRIC-1.md`/`FABRIC-2.md`/
> `FABRIC-3.md`.
> **Scope:** This repo is LithosAnanke — the bare-metal UEFI kernel that boots StarForth
> directly on hardware. StarForth (the hosted FORTH-79 VM) has its own separate repository
@@ -133,14 +134,14 @@ The word-level ACL system is fully implemented, including kernel parity. Key con
- Measured overhead: +0.0054%–+0.0088% across all 9 cells; CV = 0.000%
- Report confirmed to exist: `experiments/bare_metal/analysis/report/bare_metal_doe_report.pdf`
(~2MB, with LaTeX source and figures) — patent support material
- **Correction (found 2026-08-20/21, `FABRIC-2.md` §§M–T):** the "ACL-RWT" name itself was
- **Correction (found 2026-08-20/21, `FABRIC-1.md` §§M–T):** the "ACL-RWT" name itself was
wrong — the Rolling-Window-of-Truth mechanism it was named after was dead code, removed
2026-07-08 (`ACL-RECHECK-RW` was never reachable — `acl_recheck()` only ever looks up the
11-char `ACL-RECHECK`, never the 14-char `-RW` variant). What this campaign actually
measured was the live `ACL-TTL` mechanism under a misleading name, and at `-O0`, before
real compiler optimization landed. The corrected, current figure — same live mechanism,
correct name, re-run on the current substrate — is **+0.0603% ACL-TTL enforcement overhead,
architecture-independent, CV=0.000%** (`FABRIC-2.md` §T, memory
architecture-independent, CV=0.000%** (`FABRIC-1.md` §T, memory
`project_acl_ttl_overhead_final.md`). Use that number, not the one above.
**Before writing or modifying any `.4th` capsule file**, read `experiments/bare_metal/README.md`
@@ -211,7 +212,7 @@ Output: `build/<arch>/kernel/starkernel_loader.efi` + `build/<arch>/kernel/stark
Two independently tracked version strings flow into the generated `include/version.h`:
`VERSION` (`Makefile.starkernel` — the embedded StarForth engine version, currently `3.1.0`;
note this does **not** auto-sync with the standalone StarForth repo's own version) and
`LITHOS_VERSION` (`Makefile.starkernel` — the kernel version, currently `1.5.4`).
`LITHOS_VERSION` (`Makefile.starkernel` — the kernel version, currently `2.0.1`).
### Build configuration (Kconfig — real, wired, not vestigial)
.claude/CONSOLE.md
+3 -3
View File
@@ -20,11 +20,11 @@
> **SUPERSEDED (Captain Bob, 2026-08-15).** This document is no longer authoritative, and its
> core premise below ("Console is a 4th Tripod VM, Quadrupod, StarForth-dialect-only") was
> architecturally reversed by a later, decided ruling: `FABRIC.md` §17.5 — the framebuffer is
> architecturally reversed by a later, decided ruling: `FABRIC-0.md` §17.5 — the framebuffer is
> a **utility**, not a patron, not a VM. What actually shipped is direct C
> (`src/starkernel/hal/console.c`/`vt100.c`/`framebuffer.c` plus keyboard drivers), called
> straight from the kernel, no Hera-spawned Console VM anywhere. `FABRIC.md`/`FABRIC-2.md`
> (repo root — read `FABRIC-2.md` first) are the sole design-of-record for Console/framebuffer
> straight from the kernel, no Hera-spawned Console VM anywhere. `FABRIC-0.md`/`FABRIC-1.md`
> (repo root — read `FABRIC-1.md` first) are the sole design-of-record for Console/framebuffer
> work now. Kept here as historical record only. See `.claude/CLAUDE.md`'s own pointer.
---
.claude/HERMES.md
+2 -2
View File
@@ -5,10 +5,10 @@
---
> **SUPERSEDED (Captain Bob, 2026-08-15).** This document is no longer authoritative.
> `FABRIC.md`/`FABRIC-2.md` (repo root — read `FABRIC-2.md` first, it is the current/living
> `FABRIC-0.md`/`FABRIC-1.md` (repo root — read `FABRIC-1.md` first, it is the current/living
> one) are the sole design-of-record for Hermes work now. Kept here as historical record
> only — note its message-layout table (8 cells) is confirmed stale against the real shipped
> capsule (9 cells, `capsules/hermes/init.4th`), see `FABRIC-2.md`. Do not read this for
> capsule (9 cells, `capsules/hermes/init.4th`), see `FABRIC-1.md`. Do not read this for
> current design authority. See `.claude/CLAUDE.md`'s own pointer.
---
.claude/TRIPOD.md
+4 -4
View File
@@ -5,10 +5,10 @@
---
> **SUPERSEDED (Captain Bob, 2026-08-15).** This document is no longer authoritative.
> `FABRIC.md`/`FABRIC-2.md` (repo root — read `FABRIC-2.md` first, it is the current/living
> `FABRIC-0.md`/`FABRIC-1.md` (repo root — read `FABRIC-1.md` first, it is the current/living
> one) are the sole design-of-record for Tripod work now. Kept here as historical record
> only; do not read this for current design authority, and do not cite it in place of
> `FABRIC.md`/`FABRIC-2.md`. See `.claude/CLAUDE.md`'s own pointer.
> `FABRIC-0.md`/`FABRIC-1.md`. See `.claude/CLAUDE.md`'s own pointer.
---
@@ -35,8 +35,8 @@ or work execution logic in Hera — stop. You have the wrong VM.
## The Immediate Goal
**Corrected 2026-08-13 — stale since item 0.1 (`FABRIC.md` Phase 0), flagged in
`FABRIC-2.md` §A item 5.3, never fixed until now.** This section used to say Hera spawns
**Corrected 2026-08-13 — stale since item 0.1 (`FABRIC-0.md` Phase 0), flagged in
`FABRIC-1.md` §A item 5.3, never fixed until now.** This section used to say Hera spawns
Hermes and Artemis automatically at boot. She does not, by deliberate design: item 0.1
pruned `capsules/init.4th` to boot Hera alone (confirmed current —
`capsules/init.4th` births no other VM). Hermes and Artemis-as-VM-patron births happen
CHANGELOG.md
+1 -1
View File
@@ -42,7 +42,7 @@ corrected to the valid SMC32 encoding (`0x84000009`).
Full three-arch DoE campaign (`L8-DOE`, 48 trials each) re-run clean on all
three architectures post-fix: stress campaigns 30/30 PASS, clean `BYE` exit,
no exceptions. Full investigation trail, evidence, and dead ends in
`FABRIC-2.md` Sections H and I.
`FABRIC-1.md` Sections H and I.
## 2026-07-24 — Kernel 3-arch acceptance test re-run; amd64 dict_hash non-determinism root-caused (`lithosananke`)
FABRIC.md → FABRIC-0.md
+17 -17
View File
@@ -1,8 +1,8 @@
# FABRIC.md — the Stadium
# FABRIC-0.md — the Stadium
**Status: CLOSED, 2026-08-12.** This document is archival. It is not edited further and no
new work is added to it — everything still open as of the closure date was carried forward
into **`FABRIC-2.md`**, which is now the living document. Read `FABRIC-2.md` first for
into **`FABRIC-1.md`**, which is now the living document. Read `FABRIC-1.md` first for
current status; come back here only for the historical design argument and decision record
behind it.
@@ -20,7 +20,7 @@ places were found where something had actually been resolved by later work but t
document's own note was never updated (§19.6 #3, §21.5 #4, the §25.7 `stadium_owner[idx]`
bullet, and item 4.5's own parent checkbox) — those four are fixed in place below, since
they were bookkeeping errors, not open work. Everything else genuinely still open is in
`FABRIC-2.md`.
`FABRIC-1.md`.
**How to read what remains.** §1–15 are the original design argument, written before any
code was examined. §16 onward are findings and decisions made against the actual tree, in
@@ -35,7 +35,7 @@ quotes that reproduce an earlier section verbatim, and in §12's preserved quest
which several sections quote.
**On `docs/lithosananke/ROADMAP.md`.** As of 2026-08-11, Captain Bob stated this document
superseded ROADMAP.md entirely. That still holds, transitively, through `FABRIC-2.md` now.
superseded ROADMAP.md entirely. That still holds, transitively, through `FABRIC-1.md` now.
---
@@ -375,7 +375,7 @@ Ten minutes on paper. It confirmed the design and caught one case, which is what
## 10. Sequencing
**FABRIC.md first, then Hermes native on the fabric, then measure, then Console, then
**FABRIC-0.md first, then Hermes native on the fabric, then measure, then Console, then
Artemis last.**
> **Amended by §16.5 and §21.2.** This ordering is still right for the *subsystems*, but it
@@ -419,7 +419,7 @@ re-running it. Automated, but budget for it.
This is why the admission test comes before code.
**Early signal:** ARTEMIS.md, HERMES.md, CONSOLE.md and TRIPOD.md each currently describe
their own heat mechanics. After FABRIC.md, each should shrink to roughly three lines —
their own heat mechanics. After FABRIC-0.md, each should shrink to roughly three lines —
what an entry is here, what heat means, what the reap event is. If any one of them gets
*longer*, that subsystem is fighting the fabric, and you will know which one before
writing code.
@@ -1562,7 +1562,7 @@ noun was overloaded.
2.1** — `vm_physics_touch()` was restated on the virtual tick (no `now_ns` parameter at
all), closing exactly the gap this point raised. This item's own cross-reference (*Refs:*
§19.6 #3) points back here; this note closes the loop the other direction. Never annotated
here at the time (found during the 2026-08-12 FABRIC-2.md audit).
here at the time (found during the 2026-08-12 FABRIC-1.md audit).
---
@@ -1623,13 +1623,13 @@ There is no renormalisation anywhere. `vm_physics_conserved()` tests a genuine i
dropped. **The "guarded, shouldn't happen" description was only half right** — the
Hera-is-root case was reachable via `S" Hera" KILL` (`mama_word_kill()` called
`vm_physics_retire()` before `capsule_vm_kill()`'s own Hera guard ran), fixed 2026-08-13
(`FABRIC-2.md` §C). The broken-parent-chain case remains genuinely unreachable
(`FABRIC-1.md` §C). The broken-parent-chain case remains genuinely unreachable
(`parent_vm_id` is set once at birth, never rewritten) and is not tracked further.
2. ~~**Truncation** (`:304-305`). The proportional fan-out computes
`(moved_total * heat) / others_total` per VM in integer arithmetic. The shares sum to
*less than* `moved_total`. **Every multi-VM touch loses a little heat**, so the sum drifts
downward monotonically. `VM_PHYSICS_EPSILON_Q48` is 3277 — 5% of `Q48_ONE` — so given
enough touches this would eventually trip.~~ **WRONG, corrected 2026-08-13** (`FABRIC-2.md`
enough touches this would eventually trip.~~ **WRONG, corrected 2026-08-13** (`FABRIC-1.md`
§B "Fleet heat leak," investigated when item 4.2 made this measurable) — the truncated
`share` is what actually moves on *both* sides of `vm_physics_transfer()`, so the fleet
sum cannot drift from this path; only path 1 above can. Left standing here per this
@@ -1655,7 +1655,7 @@ conservation law the project makes claims about. It is small per touch and may b
tolerable, but it is monotonic, and nobody has measured how far it drifts over a long run.~~
**WRONG, corrected 2026-08-13** — see the strikethrough correction on path 2 above. Path 1
(the dying-VM-is-root/broken-chain drop) is the only live defect; it is tracked in
`FABRIC-2.md` §C, not here, per this document's closure.
`FABRIC-1.md` §C, not here, per this document's closure.
### 20.3 Nesting — §12 Q6 is less open than it looks
@@ -1898,7 +1898,7 @@ level it was born on.
4. ~~**§20.5 #4 remains open.**~~ **RESOLVED by item 1.7 (§25.2), 2026-08-04** — this
section (§21.5) was written before that ruling and never updated to point to it. Bounded
by a Kconfig-tunable cap, default 2, enforced at VM-birth time. See §20.5 #4 for the full
resolution. Stale cross-reference, not new work (found during the 2026-08-12 FABRIC-2.md
resolution. Stale cross-reference, not new work (found during the 2026-08-12 FABRIC-1.md
audit).
---
@@ -3672,7 +3672,7 @@ document and committing that amendment as its own item.*
> - Self-test scaffolding (`kernel_main.c`, diagnostic-only, not production code):
> +119 / −0, 1 file.
> - **Total: 12 implementation files, +759 / −120 (879 lines changed).**
> - **File count:** 12 implementation files (13 including this write-up in `FABRIC.md`
> - **File count:** 12 implementation files (13 including this write-up in `FABRIC-0.md`
> itself).
- [ ] **4.3 — Console.** Settles 1.11 as part of the work. *Refs:* §17.5.
@@ -5109,7 +5109,7 @@ document and committing that amendment as its own item.*
- [x] **4.4c — Wire `console_fb_init()` into the boot path.** Found while verifying 4.4d
(below) by screendump — not a bug in 4.4a/4.4b, a pre-existing, deliberate gap.
`kernel_main.c:830-834` has an explicit comment: *"console.c / vt100.c are superseded by
the Console drawing-fabric redesign (FABRIC.md §27) and are deliberately not invoked
the Console drawing-fabric redesign (FABRIC-0.md §27) and are deliberately not invoked
here... `fb_init()` wires the raw GOP framebuffer directly... nothing else touches it."*
Only raw `fb_init()` runs; `console_fb_init()` (which calls `vt100_init()`) is never
called anywhere in the boot sequence. Consequence, confirmed by screendump: `vt100_putc()`
@@ -6261,11 +6261,11 @@ document and committing that amendment as its own item.*
> **Parent closed 2026-08-12.** All six sub-items (4.5a–4.5f) below are `[x]` done; 4.5f's
> own done-when is satisfied by 4.4g's real landing, not a separate pass. This checkbox was
> never flipped at the time — pure bookkeeping, not new work (found during the FABRIC-2.md
> never flipped at the time — pure bookkeeping, not new work (found during the FABRIC-1.md
> audit). One real loose end surfaced by 4.5f's own text, not closed by any of this: the
> ACL-RWT DoE campaign's overhead numbers (CLAUDE.md, "+0.0054%–+0.0088%") were all measured
> at `-O0`, before this item enabled real optimization — nobody has re-measured or even
> asked whether they're still comparable. Carried forward to FABRIC-2.md.
> asked whether they're still comparable. Carried forward to FABRIC-1.md.
- [x] **4.5a — Full ISR/interrupt-context global-state audit, all three architectures.**
Investigation only, no code change. For each architecture, enumerate every vector actually
@@ -6797,7 +6797,7 @@ so.*
folded into item 4.2's scope by explicit Captain Bob ruling**, fixed and verified: a
resident cell's evict-credit lands in the correct VM's reservoir with two VMs holding
quotas (Hera + Hermes), not just asserted from reading the code. This bullet was never
struck through at the time; stale, not new work (found during the 2026-08-12 FABRIC-2.md
struck through at the time; stale, not new work (found during the 2026-08-12 FABRIC-1.md
audit). See item 4.2's *Done when* list and its 2026-08-05 addendum.
- **Taxonomy and lexicon.** Raised by Captain Bob 2026-08-04, mid-item-3.1. This document's
physics-flavored vocabulary (heat, mass, density, patron, Stadium, and the rest) needs a
@@ -6805,7 +6805,7 @@ so.*
covers the growing set of Kconfig build knobs (`STADIUM_MAX_VM_COUNT` and its siblings) so
the terminology in code, Kconfig help text, and this document stays one language instead
of drifting apart. Not scoped, not placed in a phase. Captain Bob: "I guess that we didn't
finish out FABRIC.md quite as much as we thought."
finish out FABRIC-0.md quite as much as we thought."
### 25.7.1 Second review pass — 2026-08-03, pre-coding. Awaiting rulings.
FABRIC-1.md
+4420
View File
File diff suppressed because it is too large Load Diff
FABRIC-2.md
+4769 -4357
View File
File diff suppressed because it is too large Load Diff
FABRIC-3.md
+1668 -3439
View File
File diff suppressed because it is too large Load Diff
FABRIC-4.md
+106
View File
@@ -0,0 +1,106 @@
# FABRIC-4.md — forward-looking design notes
**Status:** Not a successor to `FABRIC-3.md` and not a punch-list document. `FABRIC-3.md` is
the current living document (bare metal boot, opened 2026-09-04, successor to the now-closed
`FABRIC-2.md`) — nothing here supersedes it, and this file doesn't follow the
close-and-carry-forward discipline `FABRIC-0.md` → `FABRIC-1.md` → `FABRIC-2.md` → `FABRIC-3.md`
used (that chain triggers on *closing* a document; `FABRIC-3.md` isn't closed). This is a
separate, lower-discipline scratchpad for design ideas caught early — theory-stage,
pre-punch-list, often missing a stated "why" on purpose (captured as raised, not fully
justified yet). An idea graduates out of here into `FABRIC-3.md` (or wherever the living
document is by then) once it has a real scope, not before.
---
## 1. Stadium-level "wheel" — a second clock alongside the heartbeat (2026-09-03)
Raised in conversation with Captain Bob, theory stage — no code, no scope, deliberately not
punch-listed yet.
**The mechanism.** A second clock, independent of but derived from the true heartbeat
(`HeartbeatState`, Loop #7), advanced by a fixed-point (Q48.16, this project's standard)
phase accumulator: each master heartbeat tick adds a `rate` scalar to the wheel's own
`phase`; whenever `phase` crosses `1.0` the wheel fires (advances its own state) and the
crossing remainder carries forward. This is a continuous scalar, not an integer tick-divisor
— `rate` can sit anywhere, including above `1.0`. A wheel with `rate > 1` fires more than
once per master tick (multiple threshold-crossings per tick, remainder still carried); one
with `rate < 1` accumulates across several master ticks before firing once. Nothing about the
mechanism privileges either side of `1.0` — "runs ahead of baseline" and "runs stretched
behind baseline" are the same math with a different scalar.
**What feeds it.** Not a new signal source — this wheel listens to two already-real, already-
built mechanisms: `rolling_window_of_truth.c` (Loop #2's circular-buffer execution history —
`rolling_window_measure_diversity()`, `rolling_window_find_hottest_word()`,
`rolling_window_count_transition()`, `rolling_window_pattern_capture_rate()`,
`rolling_window_is_warm()`) and `inference_engine.c` (Loops #5/#6 — `InferenceOutputs`:
decay-slope, variance-inflection point, fit quality). Both exist today at the **per-VM**
level (each patron/word-owning VM has its own rolling window and runs its own inference
pass) — the wheel itself is meant to live at the **Stadium** level, one layer up. This is a
genuinely new axis: nothing today aggregates RWOT/inference-engine output across the whole
Stadium floor into one fleet-wide signal. **Open, not decided:** what the aggregation actually
is (sum across patrons? mean? the hottest patron's own values only? something else) — flagged
in conversation, not resolved.
**What it's for.** Not a sieve itself. The wheel is a *scheduler/gate*: it decides *when* to
slip an appropriate sieve into a stack of sieves that doesn't exist yet (see §2 below) —
running its own clock, potentially ahead of the true heartbeat, is what buys it lead time to
notice a transition worth reacting to before the baseline heartbeat would get there on its
own. It is not itself the thing doing the sieving.
**Build sequencing, decided in conversation.** `rate` starts as a fixed build parameter (same
shape as `ACL-BASE-TTL`/`Q.SLOT` — a plain constant or Kconfig symbol, not adaptive from day
one). Reasoning, Captain Bob's own: a fixed rate is the only version that can go through this
project's existing DoE apparatus and produce a clean, attributable measurement (rate held
constant, everything else varies) — if the rate self-tunes from day one there's no fixed
baseline to compare "does the wheel actually help" against. Only *after* a real, measured
baseline exists does `rate` itself graduate to adaptive/self-tuning — reusing the same
inference-engine machinery the wheel already listens to, not new plumbing. This mirrors the
L8 Jacquard selector's own real history: hardcoded compudynamics constant first, later
replaced by the VM Fleet Attractor's dynamically-inferred rate
(`docs/working/architecture/VM-FLEET-ATTRACTOR-DESIGN-20260705.md`). Same graduation, one
level up the stack.
**Explicitly not decided yet, per Captain Bob ("we'll talk about why later"):**
- The actual *purpose* — why this wheel, what real problem it solves. Deferred on purpose.
- The sieve stack itself — what a "sieve" is concretely, what gets sieved, how many. A larger,
separate vision (128–256 wheels, each fed by an "appropriate" — possibly learned/neural,
vocabulary not yet resolved against anything this codebase currently has — source, forming
a coincidence-pattern sieve) was raised earlier in the same conversation as a *distinct*,
further-out idea; this single-wheel scheduler is deliberately scoped smaller and doesn't
presuppose that larger picture is right.
- Whether "trivial to add a wheel" (an earlier framing) still matters once there's only one —
a generic `{rate, phase, state}` table is a premature abstraction for a single instance;
build the one wheel concretely first, generalize only if/when a second one is actually
needed (this project's own standing convention — three similar lines beat a premature
abstraction).
## 2. A pinned GPIO VM per real-hardware board (2026-09-04)
Raised in conversation with Captain Bob during `FABRIC-3.md` §IV/§V's bare-metal-boot
planning — theory stage, no code, no scope, deliberately not punch-listed yet.
**The idea, as stated:** the Raspberry Pi 5 will need a special pinned VM dedicated to GPIO —
presumably following the same Tripod precedent Hermes/Artemis already established (a
permanently-pinned, born-at-boot VM with a fixed role, per `FABRIC-2.md` §H.1's "pinned
sessions never leave" model). Whether the Milk-V Mars needs the same treatment is explicitly
**not yet decided** — Captain Bob's own framing: "same for Milk-V (? not sure here)." Worth
noting the Mars does have its own 40-pin GPIO header (§VI), so the question isn't "does it
have GPIO" but whether it needs its own *dedicated pinned VM* for it the same way the Pi 5
does, or whether GPIO access there fits some other shape.
**Why a dedicated VM, not just a C driver, presumably (not yet confirmed as the actual
reasoning — inferred from the Tripod precedent, not stated outright):** GPIO is shared,
stateful hardware that multiple capsules/patrons might want to touch — the same category of
problem Hermes (messaging) and Artemis (block storage) already solve by being a dedicated,
addressable VM other patrons talk to, rather than a bare C primitive anyone can call directly.
**Explicitly not decided yet:**
- Whether Milk-V Mars needs the same pinned-VM treatment, or something else.
- What this VM's own vocabulary/interface would look like (a `GPIO-READ`/`GPIO-WRITE`-shaped
word set? something richer, given the Pi 5's GPIO header also muxes UART/SPI per §IV.1?).
- Whether this is one pinned VM per board doing double duty (GPIO + whatever else that board's
bring-up needs) or GPIO specifically warrants its own separate VM distinct from, say, a
future UART-handling VM.
- How this interacts with §IV.1's own still-open native-boot-flow work — a GPIO VM needs GPIO
register addresses from the DTB the same way the rest of that bring-up does, so this idea
isn't independent of that work, just downstream of it.
Kconfig.heartbeat
+14 -9
View File
@@ -66,15 +66,20 @@ config HEARTBEAT_SLOPE_VALIDATION_FREQUENCY
revalidation runs.
config EMERGENCY_CONSOLE_ENABLED
bool "Interactive fault handler / error-recovery REPL (EMERGENCY_CONSOLE_ENABLED)"
default y
bool "Interactive fault handler / debug-escape REPL (EMERGENCY_CONSOLE_ENABLED)"
default n
help
y = REPL recovers from errors and continues (interactive
fallthrough surface). Set to n for production, embedded, or
high-security builds where an error should not hand control back
to an interactive console. Applies to both the hosted VM and the
kernel build; the kernel's emergency_console VM flag additionally
applies only to the bare `ok>` REPL -- zuse sessions are always
subject to ACL regardless of this setting.
Decided 2026-09-05: no console for the running system unless a
thumbdrive is present -- n (the new default) is the production/
high-security posture. When n: the kernel boots headless (no
banner, no prompt, no interactive surface at all) until a real
identity logs in via an attached thumbdrive (a regular user's
WIREBIND login or Zuse's own attach/genesis-mint -- neither is
special), and a runtime error halts the VM rather than handing
control back to an interactive console (no fallthrough surface).
Set to y only for debugging/recovery builds: the kernel shows its
interactive console immediately at boot regardless of any
thumbdrive, and REPL errors recover and continue instead of
halting. Applies to both the hosted VM and the kernel build.
endmenu
Kconfig.kernel
+11 -11
View File
@@ -46,7 +46,7 @@ config STADIUM_VM_MEMORY_PERCENT
(kmalloc_get_stats(), taken AFTER the cell array's own allocation),
divided by VM_MEMORY_SIZE (5 MiB, include/vm.h), floored to 1 so Hera
can always boot. No upper ceiling -- birth is refused once the
computed bound is reached (FABRIC.md item 1.5's refusal behaviour is
computed bound is reached (FABRIC-0.md item 1.5's refusal behaviour is
unchanged), it just isn't a compile-time guess anymore. Default of
50% is an untuned placeholder, not a derived optimum, same DoE-later
treatment as STADIUM_MEMORY_PERCENT.
@@ -55,7 +55,7 @@ config STADIUM_CONTAINS_DEPTH_MAX
int "Patron containment chain depth cap (STADIUM_CONTAINS_DEPTH_MAX)"
default 5
help
Hard bound on how many patrons deep a `contains` chain (FABRIC.md
Hard bound on how many patrons deep a `contains` chain (FABRIC-0.md
item 1.1, the ninth cell wire) may nest. A patron with a non-none
`contains` link cannot be reaped -- reap-gating enforcement of
this bound is item 3.5's scope, not yet implemented. Distinct
@@ -71,12 +71,12 @@ config STADIUM_CAPACITY_TICK
transfer-slope estimate (vm_physics_tick() -- a passive median
recompute over recent touch samples, not a capacity/transfer
decision itself), expressed in virtual ticks -- never wall-clock.
Wired in 2026-08-15 (FABRIC-2.md F.2/§12 Q5): this counter is fed
Wired in 2026-08-15 (FABRIC-1.md F.2/§12 Q5): this counter is fed
by EVERY live VM's own vm_tick(), not one VM's, so it previously
shared HEARTBEAT_INFERENCE_FREQUENCY (1000) and fired roughly
(live VM count) times faster than a single VM's own heat-inference
gate -- backwards from the "order of magnitude apart" minimum
(FABRIC.md §22.4). Default of 4000 is a flat, untuned placeholder
(FABRIC-0.md §22.4). Default of 4000 is a flat, untuned placeholder
picked to roughly restore that separation at Tripod's known
4-VM topology (Hera + two Hermes + Artemis) -- not computed from
live VM count at runtime, deliberately: a fixed constant, same
@@ -90,11 +90,11 @@ config STADIUM_MEMORY_PERCENT
help
The Stadium's global cell array is sized at boot from
pmm_get_stats().free_bytes, taken at the point of allocation
(FABRIC.md item 3.2, §17.6 position (b): "sized at boot from the
(FABRIC-0.md item 3.2, §17.6 position (b): "sized at boot from the
memory budget", not a hardcoded cell count). This is the fraction
of that free-byte figure the array claims, rounded down to whole
64-byte cells. Default of 1% is conservative -- comfortably clears
the ~4096-cells-per-VM illustrative figure in FABRIC.md §23.3
the ~4096-cells-per-VM illustrative figure in FABRIC-0.md §23.3
against a QEMU -m 1024 test config while leaving the kernel heap
and everything else nearly all of physical memory.
@@ -102,7 +102,7 @@ config STADIUM_WORD_HEAT_QUANTUM
int "Q48.16 heat quantum moved per word touch/starter-grant (STADIUM_WORD_HEAT_QUANTUM)"
default 2048
help
FABRIC.md §17.7 (item 4.1): the fixed Q48.16 amount transferred between
FABRIC-0.md §17.7 (item 4.1): the fixed Q48.16 amount transferred between
a VM's Stadium reservoir and a word patron's cell on every touch
(already-resident) or starter-grant admission attempt (non-resident,
Option B). Q48_ONE is 65536; the default of 2048 is Q48_ONE divided by
@@ -116,7 +116,7 @@ config STADIUM_WORD_COOL_RATE_Q48
int "Q48.16 fraction of resident heat removed per tick (STADIUM_WORD_COOL_RATE_Q48)"
default 21845
help
FABRIC.md §17.7 (item 4.1): redirects Loop #3's decay shape onto
FABRIC-0.md §17.7 (item 4.1): redirects Loop #3's decay shape onto
Stadium word-patron heat instead of discarding it -- cooled heat
returns to the VM's reservoir rather than vanishing, so this must be a
fraction of the patron's OWN current heat removed per elapsed tick
@@ -132,7 +132,7 @@ config STADIUM_BLOCK_HEAT_QUANTUM
int "Q48.16 heat quantum moved per block touch/starter-grant (STADIUM_BLOCK_HEAT_QUANTUM)"
default 2048
help
FABRIC-3.md §B (MIGRATE punch-list item): same role as
FABRIC-2.md §B (MIGRATE punch-list item): same role as
STADIUM_WORD_HEAT_QUANTUM above, for block patrons touched via
BLOCK/BUFFER/UPDATE (stadium_block_dispatch(), stadium_blocks.c).
Default matches the word quantum -- no evidence yet that blocks need a
@@ -144,7 +144,7 @@ config STADIUM_BLOCK_COOL_RATE_Q48
int "Q48.16 fraction of resident block heat removed per tick (STADIUM_BLOCK_COOL_RATE_Q48)"
default 21845
help
FABRIC-3.md §B (MIGRATE punch-list item): same role as
FABRIC-2.md §B (MIGRATE punch-list item): same role as
STADIUM_WORD_COOL_RATE_Q48 above, for block patrons. Default matches
the word cool rate for the same reason the heat quantum above does --
untuned placeholder, not a derived optimum.
@@ -153,7 +153,7 @@ config STADIUM_BLOCK_TRACK_CAP_MULT
int "Multiplier on stadium_cell_count() for the block residency table's capacity"
default 2
help
FABRIC-3.md §B (MIGRATE punch-list item): stadium_blocks.c's
FABRIC-2.md §B (MIGRATE punch-list item): stadium_blocks.c's
(quota_slot, lbn) -> cell_index hash table is a fixed-capacity
open-addressing table sized at stadium_blocks_init() as
stadium_cell_count() * this value. At most stadium_cell_count() blocks
Makefile.starkernel
+132 -15
View File
@@ -71,12 +71,16 @@ MAKEFLAGS += -j$(NPROC)
endif
# Version
# Roadmap:
# Roadmap (per docs/lithosananke/ROADMAP.md "Release Versioning Policy" and
# FABRIC-2.md §G — X.0.0 = QEMU release, X.5.0 = hardware bare-metal release):
# v1.0.x — serial-only production (released)
# v1.5.x — framebuffer VT100 terminal/console milestone (current)
# v2.0.0 — StarForth SDK release; v2.x.x development begins from there
# v1.5.x — framebuffer VT100 terminal/console milestone (released)
# v2.0.0 — QEMU release (even major = LTS): three-arch QEMU story complete
# v2.0.1 — SER5 hardware-track line: RDRAND backend + generic thumbdrive image goal
# v2.2.0 — amd64 bare-metal (Beelink SER5) — see ROADMAP "Board-by-board rollout"
# v2.5.0 — hardware bare-metal release: real per-arch RNG + real-board boot
VERSION ?= 3.1.0
LITHOS_VERSION ?= 1.5.4
LITHOS_VERSION ?= 2.0.0
# ==============================================================================
# BUILD PATHS
@@ -101,6 +105,20 @@ DOE_LATEST_DIR := experiments/bare_metal/latest
CAPSULES_DIR ?= capsules
ARTDISK ?= disk/artemis.img
# XHCI_PORTS -- real top-level port count the qemu-xhci controller exposes on the
# xhci0.0 bus (p2 == p3 == this value; these are the SAME physical dual-role ports
# counted from the USB2 and USB3 register sets respectively, NOT additive to p2+p3 --
# confirmed live 2026-09-06, the stock default p2=4,p3=4 exposes exactly 4 real ports,
# not 8). Every usb-storage device attached below or via QEMU_EXTRA must get its own
# explicit port=N less than this value: exceed it and QEMU silently drops the overflow
# onto an auto-inserted internal USB2 hub, which the xHCI/BOT driver correctly refuses
# to treat as Mass Storage (root cause of the FABRIC-3.md §IX.5 "4th-device enumeration
# failure" -- misread as a driver bug at the time, it never was one). Sized with real
# headroom above the current 9-device identity roster (Zuse + 8 minted identities)
# rather than matching it exactly, per Bob's standing ruling against hardcoding a bound
# to today's scale (FABRIC-3.md §VII.4). Override if a future test needs more, e.g.
# `make -f Makefile.starkernel qemu XHCI_PORTS=32`.
XHCI_PORTS ?= 16
# ZUSEDISK -- Zuse's own minted USB thumbdrive, attached by default so a
# plain `make qemu` lands already authenticated into the Zuse identity
# (Captain Bob, 2026-08-28). Attached at QEMU launch time via -drive/
@@ -110,7 +128,7 @@ ARTDISK ?= disk/artemis.img
# xhci_poll_events() alone is purely hotplug-event-driven and would never
# see a device present before controller reset. Override to "" (empty) to
# boot without Zuse attached, e.g. `make -f Makefile.starkernel qemu ZUSEDISK=`.
ZUSEDISK ?= disk/zuse.img
ZUSEDISK ?= disk/thumbdrives/zuse-thumb-ident.img
# Precomputed (not inlined as $(if ...,...)) because the drive/device specs
# below are comma-heavy and GNU make's $(if) function splits its own
# arguments on every top-level comma -- inlining it silently truncated the
@@ -118,7 +136,7 @@ ZUSEDISK ?= disk/zuse.img
# dropped, confirmed live via `ps aux` showing the truncated qemu command
# line (2026-08-28).
ifneq ($(strip $(ZUSEDISK)),)
ZUSEDISK_QEMU_ARGS := -drive if=none,id=zusedrv,file=$(ZUSEDISK),format=raw -device usb-storage,bus=xhci0.0,drive=zusedrv
ZUSEDISK_QEMU_ARGS := -drive if=none,id=zusedrv,file=$(ZUSEDISK),format=raw -device usb-storage,bus=xhci0.0,port=1,drive=zusedrv
else
ZUSEDISK_QEMU_ARGS :=
endif
@@ -129,7 +147,7 @@ MKCAPSULE_SRC = tools/mkcapsule.c tools/pkcs8_ed25519.c \
src/starkernel/crypto/sha512.c
MKCAPSULE_BIN = $(BUILD_DIR)/tools/mkcapsule
# Milestone 6 (Phase 8): the snakeoil intermediate's private key, generated
# offline outside this repo entirely (see FABRIC-3.md's Phase 8 §Milestone 6
# offline outside this repo entirely (see FABRIC-2.md's Phase 8 §Milestone 6
# writeup) -- not present in CI or a fresh checkout, so signing is skipped
# gracefully ($(wildcard ...) below) rather than failing the build. Override
# with `make SIGN_KEY=/path/to/key.pem ...` on a machine that holds it.
@@ -223,7 +241,7 @@ LOADER_LD ?= $(LD)
# has no dynamic linker to populate a GOT, so those reads silently returned
# NULL. PLATFORM_TIME_NO_INLINE (removed 2026-08-06) was a symbol-specific
# workaround for the same underlying bug, made unnecessary once amd64 got
# the real fix; see FABRIC.md for the write-up).
# the real fix; see FABRIC-0.md for the write-up).
COMMON_CFLAGS := \
-std=c99 -Wall -Werror -Wextra \
-O2 -U_FORTIFY_SOURCE \
@@ -266,7 +284,9 @@ DOE_SEED ?= 12345
# EMERGENCY_CONSOLE_ENABLED is blanket-forwarded (unlike the opt-in-only
# knobs below), so it's repointed through the Kconfig bridge the same way
# as the hosted Makefile's STRICT_PTR (Phase 3) -- Phase 4 heartbeat family.
$(eval $(call kconfig_bool,EMERGENCY_CONSOLE_ENABLED,1))
# Default flipped 0 (was 1) 2026-09-05: headless-until-login is now the
# production default (Kconfig.heartbeat's own default n, same decision).
$(eval $(call kconfig_bool,EMERGENCY_CONSOLE_ENABLED,0))
LOADER_CFLAGS := $(LOADER_BASE_CFLAGS) -I$(KERNEL_SRC)/vm
KERNEL_CFLAGS := $(COMMON_CFLAGS) -D__STARKERNEL__ -I$(KERNEL_SRC)/vm
@@ -475,6 +495,7 @@ endif
KERNEL_SRCS_BASE := \
$(KERNEL_SRC)/kernel_main.c \
$(KERNEL_SRC)/boot/cmdline.c \
$(wildcard $(KERNEL_SRC)/hal/*.c) \
$(wildcard $(KERNEL_SRC)/memory/*.c) \
$(wildcard $(KERNEL_SRC)/math/*.c) \
@@ -524,7 +545,8 @@ LOADER_EXTRA_SRCS := \
$(KERNEL_SRC)/vm/q48_stubs.c \
$(KERNEL_SRC)/vm/stadium.c \
$(KERNEL_SRC)/vm/stadium_words.c \
$(KERNEL_SRC)/vm/stadium_blocks.c
$(KERNEL_SRC)/vm/stadium_blocks.c \
$(KERNEL_SRC)/vm/session.c
KERNEL_EXTRA_SRCS := $(LOADER_EXTRA_SRCS)
@@ -554,6 +576,7 @@ KERNEL_OBJS := \
.PHONY: all clean clean-kernel kernel kernel-all
.PHONY: qemu qemu-esp qemu-gdb
.PHONY: thumbdrive iso-usb
.PHONY: info help
# ==============================================================================
@@ -759,7 +782,18 @@ QEMU_DISPLAY ?= gtk
# boot). Existing use: attaching a disposable USB test image for WRITE(10)
# validation, e.g.
# QEMU_EXTRA="-drive if=none,id=usbtest,file=disk/usbwrite-test.img,format=raw \
# -device usb-storage,bus=xhci0.0,drive=usbtest"
# -device usb-storage,bus=xhci0.0,port=2,drive=usbtest"
# Give every extra usb-storage device its own explicit port= (ZUSEDISK_QEMU_ARGS
# above already claims port 1), distinct from every other device attached on
# bus=xhci0.0 -- without it, QEMU's own port auto-assignment fills the
# controller's real top-level ports in device order and then silently drops
# any further device behind an auto-inserted internal USB2 hub, which the
# xHCI/BOT driver correctly refuses to treat as Mass Storage (confirmed live,
# 2026-09-06, root cause of the FABRIC-3.md §IX.5 "4th-device enumeration
# failure" -- it was never a driver bug, the emulated controller only exposes
# 4 real ports for p2=4,p3=4 despite the port count parameters implying 8).
# The qemu-xhci controller below is sized via XHCI_PORTS (see its own doc comment
# above) to give real ports to Zuse plus every identity drive attached this way.
QEMU_EXTRA ?=
qemu: all
@@ -807,7 +841,7 @@ ifeq ($(ARCH),amd64)
-cdrom $(QEMU_ISO) -boot d \
-drive id=artdisk,file=$(ARTDISK),format=raw,if=none \
-device virtio-blk-pci,drive=artdisk \
-device qemu-xhci,id=xhci0 \
-device qemu-xhci,id=xhci0,p2=$(XHCI_PORTS),p3=$(XHCI_PORTS) \
$(ZUSEDISK_QEMU_ARGS) \
-object rng-random,id=rng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=rng0 \
@@ -891,7 +925,7 @@ else ifeq ($(ARCH),aarch64)
-drive id=artdisk,file=$(ARTDISK),format=raw,if=none \
-device virtio-blk-pci,drive=artdisk \
-device virtio-keyboard-pci,addr=0x3 \
-device qemu-xhci,id=xhci0,addr=0x4 \
-device qemu-xhci,id=xhci0,addr=0x4,p2=$(XHCI_PORTS),p3=$(XHCI_PORTS) \
$(ZUSEDISK_QEMU_ARGS) \
-object rng-random,id=rng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=rng0,addr=0x5 \
@@ -981,7 +1015,7 @@ else ifeq ($(ARCH),riscv64)
-drive id=artdisk,file=$(ARTDISK),format=raw,if=none \
-device virtio-blk-pci,drive=artdisk,addr=0x1 \
-device virtio-keyboard-pci,addr=0x3 \
-device qemu-xhci,id=xhci0,addr=0x4 \
-device qemu-xhci,id=xhci0,addr=0x4,p2=$(XHCI_PORTS),p3=$(XHCI_PORTS) \
$(ZUSEDISK_QEMU_ARGS) \
-object rng-random,id=rng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=rng0,addr=0x5 \
@@ -1000,7 +1034,88 @@ else ifeq ($(ARCH),riscv64)
echo "=== Extracting DOE CSV ==="; \
bash scripts/extract_doe.sh $$LOG $$CSV || true; \
cp $$CSV $(DOE_LATEST_DIR)/riscv64.csv 2>/dev/null || true
endif
endif
# thumbdrive — build a generic UEFI-bootable GPT/FAT32 disk image that can be
# written directly to a USB thumbdrive (dd) and boots on real amd64 UEFI
# hardware (e.g. Beelink SER5) as well as under QEMU. This is the "generic
# thumbdrive bootable OS" image for the v2.5.0/SER5 bare-metal path: the
# monolithic loader embeds the whole kernel, so the ESP needs only the UEFI
# fallback boot path EFI/BOOT/BOOT<ARCH>.EFI. Storage on real hardware is the
# USB BOT/xHCI path (already live), not virtio.
thumbdrive: all
@mkdir -p $(BUILD_DIR)
@if ! which sgdisk >/dev/null 2>&1; then echo "Error: sgdisk not found. Install gdisk (apt-get install gdisk)."; exit 1; fi
@if ! which mkfs.fat >/dev/null 2>&1; then echo "Error: mkfs.fat not found. Install dosfstools (apt-get install dosfstools)."; exit 1; fi
@case "$(ARCH)" in \
amd64) BOOTNAME="BOOTX64.EFI" ;; \
aarch64) BOOTNAME="BOOTAA64.EFI" ;; \
riscv64) BOOTNAME="BOOTRISCV64.EFI" ;; \
*) echo "Error: no thumbdrive EFI boot name for ARCH=$(ARCH)"; exit 1 ;; \
esac; \
# Geometry: 128 MiB disk (262144 sectors), GPT partition 1 spans sectors \
# 2048..262110 (the GPT last-usable sector for this disk size), i.e. \
# 260063 sectors. The FAT32 ESP image MUST match the partition size \
# exactly; a larger ESP overruns the disk (GPT grows corrupt) or \
# spills past the partition end, both of which made earlier builds \
# unbootable on hardware. \
DISK=$(BUILD_DIR)/starkernel-thumbdrive.img; \
ESP_SECTORS=260063; \
rm -f $$DISK $(BUILD_DIR)/thumbdrive-esp.img; \
dd if=/dev/zero of=$(BUILD_DIR)/thumbdrive-esp.img bs=512 count=$$ESP_SECTORS 2>/dev/null; \
mkfs.fat -F 32 -n "STARKERNEL" $(BUILD_DIR)/thumbdrive-esp.img >/dev/null 2>&1; \
mmd -i $(BUILD_DIR)/thumbdrive-esp.img ::/EFI; \
mmd -i $(BUILD_DIR)/thumbdrive-esp.img ::/EFI/BOOT; \
mcopy -i $(BUILD_DIR)/thumbdrive-esp.img $(LOADER_EFI) ::/EFI/BOOT/$$BOOTNAME; \
printf 'FS0:\\EFI\\BOOT\\%s\r\n' "$$BOOTNAME" > $(BUILD_DIR)/thumbdrive-startup.nsh; \
mcopy -i $(BUILD_DIR)/thumbdrive-esp.img $(BUILD_DIR)/thumbdrive-startup.nsh ::/startup.nsh; \
dd if=/dev/zero of=$$DISK bs=1M count=128 2>/dev/null; \
sgdisk -n 1:2048:0 -t 1:ef00 -c 1:"EFI System" $$DISK >/dev/null 2>&1; \
dd if=$(BUILD_DIR)/thumbdrive-esp.img of=$$DISK bs=512 seek=2048 conv=notrunc 2>/dev/null; \
rm -f $(BUILD_DIR)/thumbdrive-esp.img $(BUILD_DIR)/thumbdrive-startup.nsh; \
echo "Thumbdrive image: $$DISK"; \
echo "Write to a USB stick with: dd if=$$DISK of=/dev/sdX bs=4M status=progress"
# iso-usb — build a PURE UEFI isohybrid ISO for the Iso Image Writer workflow
# (GNOME Disks "Restore Disk Image...", or dd). Writes a single .iso to a USB
# stick as a raw image; the ISO carries a clean GPT with an EFI System
# Partition holding EFI/BOOT/BOOT<ARCH>.EFI, so real UEFI firmware (e.g.
# Beelink SER5) scans the ESP and boots it. No GRUB, no isolinux, no MBR boot
# code — the protective MBR template is zeroed (partition metadata only).
# Also still boots under QEMU via -cdrom. This is the novice path: one ISO,
# picked with a GUI, written to the stick.
iso-usb: all
@mkdir -p $(BUILD_DIR)
@if ! which xorriso >/dev/null 2>&1; then echo "Error: xorriso not found. Install xorriso (apt-get install xorriso)."; exit 1; fi
@if ! which mformat >/dev/null 2>&1 || ! which mmd >/dev/null 2>&1 || ! which mcopy >/dev/null 2>&1; then echo "Error: mtools not found. Install mtools (apt-get install mtools)."; exit 1; fi
@case "$(ARCH)" in \
amd64) BOOTNAME="BOOTX64.EFI" ;; \
aarch64) BOOTNAME="BOOTAA64.EFI" ;; \
*) echo "Error: iso-usb EFI boot name only defined for amd64/aarch64 yet"; exit 1 ;; \
esac; \
ISODIR=$(BUILD_DIR)/iso-usb; \
rm -rf $$ISODIR; mkdir -p $$ISODIR; \
dd if=/dev/zero of=$$ISODIR/efi.img bs=512 count=8192 2>/dev/null; \
mformat -i $$ISODIR/efi.img :: >/dev/null 2>&1; \
mmd -i $$ISODIR/efi.img ::/EFI; mmd -i $$ISODIR/efi.img ::/EFI/BOOT; \
mcopy -i $$ISODIR/efi.img $(LOADER_EFI) ::/EFI/BOOT/$$BOOTNAME; \
printf 'FS0:\\EFI\\BOOT\\%s\r\n' "$$BOOTNAME" > $$ISODIR/startup.nsh; \
mcopy -i $$ISODIR/efi.img $$ISODIR/startup.nsh ::/startup.nsh; \
head -c 432 /dev/zero > $$ISODIR/protmbr.bin; \
ISO=$(BUILD_DIR)/starkernel-iso-usb.iso; \
rm -f $$ISO; \
xorriso -as mkisofs \
-V STARKERNEL -r -J \
-isohybrid-mbr $$ISODIR/protmbr.bin \
-eltorito-alt-boot -e efi.img -no-emul-boot \
-isohybrid-gpt-basdat \
-o $$ISO $$ISODIR >/dev/null 2>&1; \
rm -rf $$ISODIR; \
echo "Iso Image Writer ISO (pure UEFI): $$ISO"; \
echo " In GNOME Disks, pick the ISO with 'Restore Disk Image...' and select your USB stick."; \
echo " Or: dd if=$$ISO of=/dev/sdX bs=4M status=progress"
# qemu-esp — interactive dev boot from FAT directory (no disk image rebuild,
# no auto-kill/timeout/DOE-injection logic — stays up until you quit it
@@ -1134,6 +1249,8 @@ help:
@echo " qemu — clean boot, serial tee'd live + logs/<session>/<arch>/ + DOE CSV → doe/ (all arches)"
@echo " qemu-esp — quick boot from FAT directory (amd64, aarch64)"
@echo " qemu-gdb — boot with GDB stub on :1234"
@echo " thumbdrive — build generic GPT/FAT32 UEFI disk image (write to a USB stick with dd; real-hardware/SER5 path)"
@echo " iso-usb — build UEFI isohybrid ISO for Iso Image Writer / GNOME Disks 'Restore Disk Image...' (novice path; real-hardware/SER5)"
@echo ""
@echo "QEMU display:"
@echo " QEMU_DISPLAY=gtk — framebuffer window backend for 'qemu' goal (default: gtk)"
ONTOLOGY.md
+31 -31
View File
@@ -513,9 +513,9 @@ Slide 2: "Formally: f(t) = f₀ * e^(-λt)"
**Added 2026-08-13**, closing a real, acknowledged documentation-debt item: the physics
vocabulary built on top of the original heat/decay/inference model above (patron, mass,
density, Stadium, and the Kconfig knob names built on them) accumulated across
`FABRIC.md`/`FABRIC-2.md` without an explicit statement, in one place, that these are named
`FABRIC-0.md`/`FABRIC-1.md` without an explicit statement, in one place, that these are named
analogies — the same discipline Section III already applies to "heat," extended to the
newer terms. Definitions below are drawn directly from `FABRIC.md`'s own DECIDED sections
newer terms. Definitions below are drawn directly from `FABRIC-0.md`'s own DECIDED sections
(cited inline), not invented here.
### 9.1 The metaphor, restated for this layer
@@ -537,7 +537,7 @@ LITERAL IMPLEMENTATIONS (No Metaphor):
K → Σ execution_heat_q48 across live entries, conserved at 1.0
```
The Stadium metaphor is a **venue**, not a building: §2 (`FABRIC.md`) is explicit that a
The Stadium metaphor is a **venue**, not a building: §2 (`FABRIC-0.md`) is explicit that a
patron *arrives and departs* — the Stadium holds what is live, not everything that exists.
That is the load-bearing distinction between "Stadium" and "warehouse" below, and it is why
the dictionary-at-rest is warehouse, not Stadium, even though every dictionary entry is
@@ -549,29 +549,29 @@ the dictionary-at-rest is warehouse, not Stadium, even though every dictionary e
*Definition*: The Stadium's fixed-size unit of storage — a patron header, or a continuation
cell owned by exactly one patron.
*Formal*: A closed, two-constructor sum type: `Cell = Header | Continuation(owner)`, fixed
at build time (`FABRIC.md` §3).
*Measurement*: Proposed size 64 bytes (`FABRIC.md` §23.3, **not yet built** — see
`FABRIC-2.md`'s §23.4 #2 closure: the one real patron kind actually shipped, Hermes
at build time (`FABRIC-0.md` §3).
*Measurement*: Proposed size 64 bytes (`FABRIC-0.md` §23.3, **not yet built** — see
`FABRIC-1.md`'s §23.4 #2 closure: the one real patron kind actually shipped, Hermes
messages, did not adopt this cell shape).
*Category*: Storage unit.
*Warning*: Not a pointer target — links between cells are Stadium-array indices, never
addresses (`FABRIC.md` §3, §13).
addresses (`FABRIC-0.md` §3, §13).
**Code field**
*Definition*: A closed-enumeration behaviour tag stored in a patron header, dispatched by
the engine rather than branched on by kind.
*Formal*: `behaviour ∈ {MIGRATE, DELIVER, EXPIRE, COOL, ...}` — a fixed datatype, not an
open extension point (`FABRIC.md` §3, §13, §18.3).
open extension point (`FABRIC-0.md` §3, §13, §18.3).
*Category*: Dispatch mechanism.
*Note*: This is deliberately **the entire type system** — the engine never asks what kind
of patron it holds, only what its code field says to do (`FABRIC.md` §3).
of patron it holds, only what its code field says to do (`FABRIC-0.md` §3).
**Density**
*Definition*: A patron's heat share divided by its mass — heat per unit of occupied
Stadium floor space.
*Formal*: `density(p) = heat(p) / mass(p)`, derived, never stored (`FABRIC.md` §19.2).
*Formal*: `density(p) = heat(p) / mass(p)`, derived, never stored (`FABRIC-0.md` §19.2).
*Measurement*: Used for ranking and admission (denser evicts sparser), not computed by a
separate scheduler — it is read, not decided (`FABRIC.md` §19.3).
separate scheduler — it is read, not decided (`FABRIC-0.md` §19.3).
*Category*: Derived quantity.
*Warning*: This is the one place the thermodynamic metaphor is literal in form (quantity
per unit volume) even though heat itself remains metaphorical.
@@ -581,65 +581,65 @@ per unit volume) even though heat itself remains metaphorical.
*Formal*: `K = Σ execution_heat_q48`, held at `Q48_ONE` (1.0) by construction — verified by
`vm_physics_conserved()` (`capsule_vm_physics.c`).
*Measurement*: A correctness check, not a diagnostic — it is 1.0 by construction and can
never itself signal system state (`FABRIC.md` §14, §19.1). Entropy over the heat
never itself signal system state (`FABRIC-0.md` §14, §19.1). Entropy over the heat
*distribution* is the actual instrument; K is not.
*Category*: Invariant.
*Warning*: Not an occupancy ratio (`Σmass / capacity`) — that definition was considered and
explicitly rejected because it contradicts the already-implemented, tested mechanism
(`FABRIC.md` §19.1).
(`FABRIC-0.md` §19.1).
**Mass**
*Definition*: The number of Stadium cells a patron occupies — its footprint.
*Formal*: Integer ≥ 1, an entry field independent of heat; never enters K
(`FABRIC.md` §3, §19.2).
(`FABRIC-0.md` §3, §19.2).
*Category*: Structural quantity, not conserved.
*Note*: A large patron is not "referenced" from the Stadium — it simply occupies more
cells. By-reference storage is reserved for things outside the Stadium entirely
(`FABRIC.md` §19.3, §23.1).
(`FABRIC-0.md` §19.3, §23.1).
**Mass conservation vs. heat conservation**
*Definition*: Two independent invariants that must not be confused. Heat (K) is conserved
globally and moved by traffic. Mass is conserved *per patron* during a residency —
identity and mass never change as a side effect of use — but is not a fleet-wide summed
invariant the way heat is (`FABRIC.md` §24.2).
invariant the way heat is (`FABRIC-0.md` §24.2).
**Patron**
*Definition*: A live thing occupying a Stadium cell or linked run of cells — the unit the
Stadium actually holds.
*Formal*: One structure, no variants, no type field — identified by its code field's
behaviour, not by a kind tag (`FABRIC.md` §3, §13).
behaviour, not by a kind tag (`FABRIC-0.md` §3, §13).
*Measurement*: Nine header wires: identity, heat, TTL, pin, link, code field, mass,
payload, contains (`FABRIC.md` §3, with amendments cited in place).
payload, contains (`FABRIC-0.md` §3, with amendments cited in place).
*Category*: The Stadium's sole occupant type.
*Known kinds (as of this writing)*: words (dictionary — fully migrated and live via
`stadium_word_dispatch()`, `FABRIC.md` §16.3/§17.7), blocks (Artemis), messages (Hermes — shipped with a
**different** shape than this header, see `FABRIC-2.md`'s §23.4 #2 closure), VMs (Tripod,
`FABRIC.md` §20), dirty events (console, `FABRIC.md` §17.5). Five kinds, not four — an
earlier draft undercounted (`FABRIC.md` §1).
`stadium_word_dispatch()`, `FABRIC-0.md` §16.3/§17.7), blocks (Artemis), messages (Hermes — shipped with a
**different** shape than this header, see `FABRIC-1.md`'s §23.4 #2 closure), VMs (Tripod,
`FABRIC-0.md` §20), dirty events (console, `FABRIC-0.md` §17.5). Five kinds, not four — an
earlier draft undercounted (`FABRIC-0.md` §1).
**Reap**
*Definition*: The event that ends a patron's residency — not destruction, a return of its
cells and remaining heat to the pool.
*Formal*: Consumed on delivery (messages), on redraw (dirty events), on cooling below floor
(VMs), or on eviction by a denser newcomer (`FABRIC.md` §17.2, §17.5, §19.3).
(VMs), or on eviction by a denser newcomer (`FABRIC-0.md` §17.2, §17.5, §19.3).
*Category*: Lifecycle event.
**Stadium**
*Definition*: A single, bounded region of memory outside any VM, holding everything
currently live.
*Formal*: A fixed-size array of cells, index-linked (not pointer-linked), allocated at
boot before any VM exists, not part of the heap (`FABRIC.md` §2, §17.6).
boot before any VM exists, not part of the heap (`FABRIC-0.md` §2, §17.6).
*Measurement*: Per-VM quota over a single global cell pool, elastic under pressure,
arbitrated by Hera (`FABRIC.md` §22) — not per-VM physical regions.
arbitrated by Hera (`FABRIC-0.md` §22) — not per-VM physical regions.
*Category*: The bounded live-state substrate this whole vocabulary describes.
*Warning*: "Live" is the operative word — the Stadium holds what is live, not everything
that exists. A dictionary word sitting cold and unexecuted is warehouse, not Stadium, even
once the dictionary itself migrates into this representation (`FABRIC.md` §2, §16.3).
once the dictionary itself migrates into this representation (`FABRIC-0.md` §2, §16.3).
**Warehouse**
*Definition*: What lies beneath the Stadium — storage for things not currently live.
*Formal*: Artemis (block storage) and the resting dictionary are warehouse; the Stadium is
the floor above it (`FABRIC.md` §17.5's three-category taxonomy: warehouse / Stadium /
the floor above it (`FABRIC-0.md` §17.5's three-category taxonomy: warehouse / Stadium /
utility).
*Category*: Storage layer, outside the engine's live-state model.
@@ -647,7 +647,7 @@ utility).
*Definition*: External infrastructure the Stadium consumes but never contains — beside the
building, not inside or beneath it.
*Formal*: The framebuffer and devices generally; the engine never learns about a utility's
existence, which is what makes it a boundary rather than an exception (`FABRIC.md` §17.5).
existence, which is what makes it a boundary rather than an exception (`FABRIC-0.md` §17.5).
*Category*: Third taxonomy category, coordinate with warehouse and Stadium, not a
sub-case of either.
@@ -655,7 +655,7 @@ sub-case of either.
Per Bob's own flag: code, Kconfig, and documentation terminology must not drift apart.
The table below is the current, verified wiring status of every `STADIUM_*` Kconfig
symbol — confirmed by direct source grep during the `FABRIC-2.md` closure work this
symbol — confirmed by direct source grep during the `FABRIC-1.md` closure work this
vocabulary accompanies, not assumed from the symbol's name or Kconfig help text alone.
| Kconfig symbol | Vocabulary term | Wiring status (2026-08-13) |
@@ -664,8 +664,8 @@ vocabulary accompanies, not assumed from the symbol's name or Kconfig help text
| `STADIUM_MEMORY_PERCENT` | Stadium capacity sizing | **Live** — read in `stadium.c` |
| `STADIUM_WORD_HEAT_QUANTUM` | Heat (word-patron admission) | **Live** — read in `stadium_words.c` |
| `STADIUM_WORD_COOL_RATE_Q48` | Heat decay rate (word patrons) | **Live** — read in `stadium_words.c` |
| `STADIUM_CONTAINS_DEPTH_MAX` | `contains` wire depth cap (§3, §8) | **Declared, not yet enforced** — reap-gating enforcement is item 3.5's scope, not implemented (`FABRIC-2.md` §A item 5.3 area; not a bug, a known sequencing gap) |
| `STADIUM_CAPACITY_TICK` | Capacity-loop cadence, distinct from heat's (§22.4) | **Dead** — declared with the correct intended default (1000, matching §22.4's precedent) but never read by any code path; only appearance beyond its own default is a compile-time `> 0` static assertion in `stadium.h`. Found and reported during this session's §12 Q5 closure (`FABRIC-2.md`) — `vm_physics_heartbeat_tick()` still literally shares `HEARTBEAT_INFERENCE_FREQUENCY` instead |
| `STADIUM_CONTAINS_DEPTH_MAX` | `contains` wire depth cap (§3, §8) | **Declared, not yet enforced** — reap-gating enforcement is item 3.5's scope, not implemented (`FABRIC-1.md` §A item 5.3 area; not a bug, a known sequencing gap) |
| `STADIUM_CAPACITY_TICK` | Capacity-loop cadence, distinct from heat's (§22.4) | **Dead** — declared with the correct intended default (1000, matching §22.4's precedent) but never read by any code path; only appearance beyond its own default is a compile-time `> 0` static assertion in `stadium.h`. Found and reported during this session's §12 Q5 closure (`FABRIC-1.md`) — `vm_physics_heartbeat_tick()` still literally shares `HEARTBEAT_INFERENCE_FREQUENCY` instead |
This table is a snapshot, not a promise — it will drift the moment any of these symbols is
wired or unwired. Re-verify against source before relying on it for anything past a casual
README.md
+1 -1
View File
@@ -1,4 +1,4 @@
# LithosAnanke v1.5.4
# LithosAnanke v2.0.1
**UEFI-bootable FORTH microkernel.** Boots from firmware, initialises memory and interrupts, then runs the StarForth VM as its sole userspace runtime. No libc. No OS. Just stone and necessity.
ROADMAP.md
+1 -1
View File
@@ -6,7 +6,7 @@
> Tripod/Stadium/word-level ACL existed, and before "Phase 1 Starting (HAL)" had any of the
> meaning it has now. Kept for historical record only. For current status, see
> `docs/lithosananke/ROADMAP.md` (repo-specific, LithosAnanke roadmap) and
> `FABRIC.md`/`FABRIC-2.md`/`FABRIC-3.md` (design history and current work) — not this
> `FABRIC-0.md`/`FABRIC-1.md`/`FABRIC-2.md` (design history and current work) — not this
> document.
**Version**: 1.0
boot_media/rpi5/README.md
+12
View File
@@ -0,0 +1,12 @@
# Raspberry Pi 5 native boot media
What goes on the SD card for the native (non-UEFI) boot path (FABRIC-3.md §IV):
- `config.txt` — checked in here, done (§IV.3 item 6).
- `bcm2712-rpi-5-b.dtb` — Raspberry Pi firmware's own stock DTB; not built by this
project, copied from the firmware release the card is otherwise built from.
- `kernel_2712.img` — **does not exist yet.** `config.txt` names it, but no build target
in `Makefile.starkernel` currently emits a raw image by this name at load address
0x80000 — item 1 (entry stub) explicitly scoped a separate-image build target as future
work, not part of that item. Building this file is the remaining prerequisite before
item 7 (assembling the card) is possible.
boot_media/rpi5/config.txt
+62
View File
@@ -0,0 +1,62 @@
# LithosAnanke native (non-UEFI) boot config for Raspberry Pi 5 (BCM2712).
# FABRIC-3.md §IV.3 item 6 -- see that section's own doc comment for the
# research trail behind each line (confirmed against raspberrypi.com's
# current config.txt reference and a real, working Pi 5 bare-metal
# project's own checked-in config.txt, not assumed from general Pi
# knowledge).
# Load our own kernel image directly -- no UEFI, no Linux. kernel_2712.img
# is the real filename Pi 5/500/CM5 firmware looks for first (its own
# 16K-page-size build); naming our own image this exactly, rather than
# falling back to kernel8.img, removes any ambiguity about which file the
# firmware picks up.
kernel=kernel_2712.img
# Disable the firmware's Linux-compatible-image sanity check. Without
# this, official docs describe it as checking for "a compatible Device
# Tree file before attempting to boot" and warn that "older non-compatible
# kernels would be loaded and then hang" -- documented specifically as the
# bare-metal-development escape hatch. One real working Pi 5 bare-metal
# project's own config.txt does NOT set this and still boots, so it may
# not be strictly required for every non-Linux image; kept here anyway
# since the official doc names this exact use case and there is no
# hardware in hand yet to verify which behavior is actually gated.
os_check=0
# Pin the exact devicetree explicitly rather than relying on the
# firmware's own board-revision auto-selection (which would also resolve
# to this file on real Pi 5 hardware, per general config.txt convention --
# explicit is certain, not just probably-correct).
device_tree=bcm2712-rpi-5-b.dtb
# Enable the dedicated debug UART (Pi 5's own JST connector, not the GPIO
# 14/15 header pins). Not because serial capture hardware is set up for
# this bring-up (that decision is HDMI-only, FABRIC-3.md §IV) -- this is
# a firmware-side switch that costs nothing when nothing is listening, and
# it is the only diagnostic channel that survives a framebuffer failure.
# rpi5_uart_base() (rpi5_dtb.c) already exists and is currently uncalled;
# this is the hook a UART-based fallback console would use if the mailbox
# framebuffer driver's two documented unverified details turn out wrong on
# real hardware.
enable_uart=1
# Deliberately NOT set, researched but not included this pass:
# dtoverlay=uart0 -- GPIO 14/15 header UART; needs a USB-serial
# adapter this bring-up doesn't have (HDMI-only
# decision). enable_uart=1 above covers the JST
# debug UART instead, which needs no extra cable.
# dtparam=pciex1 -- one real Pi 5 bare-metal project's own config.txt
# comments this as "Required for RP1 access", which
# would be surprising (RP1 is always-on in stock Pi
# 5 boots) and is community-reported, not confirmed
# against official docs. Not needed for this boot
# (no RP1 access yet -- FABRIC-3.md §IV.3 item 5 is
# still re-scoped, not implemented). Revisit if that
# item's own real Broadcom-indirect PCIe work needs
# it.
# arm_64bit=1 -- researched and dropped: official docs state
# "Models that only support a 64-bit kernel ignore
# this flag" -- inert on Pi 5, not wrong to include,
# just meaningless. The original item 6 wording
# named this; corrected here rather than carried
# forward.
capsules/BLOCK_MAP.md
+226 -188
View File
@@ -1,5 +1,5 @@
# Capsule Block Manifest — Auto-generated
<!-- Generated by mkcapsule --manifest 2026-08-29T13:51:54Z -->
<!-- Generated by mkcapsule --manifest 2026-09-08T01:19:50Z -->
<!-- DO NOT EDIT — re-run mkcapsule --manifest to refresh. -->
<!-- Hand-written justifications and immutability notes live -->
<!-- in MANIFEST.md alongside this auto-generated index. -->
@@ -9,14 +9,16 @@
| Capsule | Blocks claimed | xxHash64 | Signed |
|---------|----------------|----------|--------|
| `ACL.4th` | 4000, 4001, 4002, 4003, 4004, 4005, 4006, 4007, 4015 | `0xd781d22148ff171d` | yes |
| `artemis:init.4th` | 4110, 4111, 4112, 4113, 4122, 4123, 4124, 4125, 4126, 4127, 4128, 4129, 4130, 4131, 4132, 4133, 4134, 4135, 4136, 4137, 4138, 4139, 4140, 4141, 4160, 4161, 4162, 4163, 4164, 4165, 4166, 4167, 4168, 4169, 4170, 4171, 4172, 4173, 4174, 4177, 4178, 4179, 4180, 4181, 4182, 4851, 4852, 4853, 4854 | `0xfe6e570467368153` | yes |
| `common:messaging.4th` | 5003, 5004, 5005, 5006, 5007, 5008, 5009, 5010, 5011, 5012, 5013, 5014, 5015, 5016, 5017, 5018, 5019, 5020, 5021, 5022, 5023, 5024, 5025, 5026, 5027, 5028, 5029, 5030, 5031, 5032, 5033, 5034, 5035, 5036, 5037, 5038 | `0x892fd1c86d8c175e` | yes |
| `acl-std79.4th` | 4023, 4024, 4025, 4026, 4027, 4028, 4029, 4030, 4031, 4032, 4033, 4034, 4035, 4036, 4037, 4038, 4039, 4040, 4041, 4042, 4043, 4044, 4045, 4046, 4047 | `0x5a622e41d1fd0bb9` | yes |
| `artemis:init.4th` | 4110, 4111, 4112, 4113, 4122, 4123, 4124, 4125, 4126, 4127, 4128, 4129, 4130, 4131, 4132, 4133, 4134, 4135, 4136, 4137, 4138, 4139, 4140, 4141, 4160, 4161, 4162, 4163, 4164, 4165, 4166, 4167, 4168, 4169, 4170, 4171, 4172, 4173, 4174, 4177, 4178, 4179, 4180, 4181, 4182, 4851, 4852, 4853, 4854, 4856, 4857, 4858 | `0xac215ecb873c4db3` | yes |
| `block-acl.4th` | 4019, 4020 | `0xf6cc2a59e3a6734e` | yes |
| `common:messaging.4th` | 5003, 5004, 5005, 5006, 5007, 5008, 5009, 5010, 5011, 5012, 5013, 5014, 5015, 5016, 5017, 5018, 5019, 5020, 5021, 5022, 5023, 5024, 5025, 5026, 5027, 5028, 5029, 5030, 5031, 5032, 5033, 5034, 5035, 5036, 5037, 5038, 5039, 5040, 5041 | `0x5cfb02a42f4a8323` | yes |
| `common:msg.4th` | 4055 | `0x850a0382344ea6c4` | yes |
| `doe-campaign.4th` | 4060, 4061, 4062, 4063, 4064, 4065 | `0x3d4549142d91ec20` | yes |
| `doe.4th` | 2100, 2101, 2102, 2103, 2104, 2105, 2106, 2107 | `0xf154616d248e861f` | yes |
| `fabric.4th` | 4900, 4901, 4902, 4903, 4904, 4905, 4906, 4907, 4908, 4909, 4910, 4911, 4912, 4913, 4914, 4915, 4916, 4917, 4918, 4919, 4920, 4921, 4922, 4923, 4924, 5000, 5001, 5002 | `0x9b1d061339cea98d` | yes |
| `font.4th` | 4925, 4926, 4927, 4928, 4929, 4930, 4931, 4932, 4933, 4934, 4935, 4936, 4937, 4938, 4939, 4940, 4941, 4942, 4943, 4944, 4945, 4946, 4947, 4948, 4949, 4950, 4951, 4952, 4953, 4954, 4955, 4956, 4957, 4958, 4959, 4960, 4961, 4962, 4963, 4964, 4965, 4966, 4967, 4968, 4969, 4970, 4971, 4972, 4973, 4974, 4975, 4976, 4977, 4978, 4979, 4980, 4981, 4982, 4983, 4984, 4985 | `0x720792b4fc758156` | yes |
| `hermes:init.4th` | 4153, 4855, 5116 | `0x9d6119b69d4113af` | yes |
| `fabric.4th` | 4900, 4901, 4902, 4903, 4904, 4905, 4906, 4907, 4908, 4909, 4910, 4911, 4912, 4913, 4914, 4915, 4916, 4917, 4918, 4919, 4920, 4921, 4922, 4923, 4924, 5000, 5001, 5002 | `0x9d9489cbeca4099b` | yes |
| `font.4th` | 4925, 4926, 4927, 4928, 4929, 4930, 4931, 4932, 4933, 4934, 4935, 4936, 4937, 4938, 4939, 4940, 4941, 4942, 4943, 4944, 4945, 4946, 4947, 4948, 4949, 4950, 4951, 4952, 4953, 4954, 4955, 4956, 4957, 4958, 4959, 4960, 4961, 4962, 4963, 4964, 4965, 4966, 4967, 4968, 4969, 4970, 4971, 4972, 4973, 4974, 4975, 4976, 4977, 4978, 4979, 4980, 4981, 4982, 4983, 4984, 4985 | `0x3f305911500c78f6` | yes |
| `hermes:init.4th` | 4153, 4855, 5116 | `0x2df61924448a6812` | yes |
| `init-0.4th` | 2200, 2201 | `0xd0a9550baf786bb3` | yes |
| `init-1.4th` | 4406, 4415, 4425, 4435 | `0x63e251adb0a03613` | yes |
| `init-2.4th` | 4506, 4515, 4525, 4535, 4545 | `0xf113b3d0bcccae47` | yes |
@@ -33,21 +35,22 @@
| `init-l8-temporal.4th` | 4830, 4831 | `0x51abd4c138246651` | yes |
| `init-l8-transition.4th` | 4840, 4841, 4842 | `0xbcc1a81976f0a4c9` | yes |
| `init-l8-volatile.4th` | 4810, 4811, 4812, 4813 | `0x98caabbbd92abac4` | yes |
| `init.4th` | 2049, 2050, 2057 | `0x9ac6523d24b80cd0` | yes |
| `init.4th` | 2049, 2050, 2057 | `0x5d35c5c6a6eafe04` | yes |
| `lib.4th` | 4050 | `0x4b216635c359ef73` | yes |
| `process.4th` | 4300, 4301 | `0x781afc1dbd0294f7` | yes |
| `sdk.4th` | 5109, 5110, 5111, 5112, 5113, 5114, 5115 | `0x008fdbbb62c94a3a` | yes |
| `turtle.4th` | 5100, 5101, 5102, 5103, 5104, 5105, 5106, 5107, 5108 | `0x4d470418ca543365` | yes |
| `user-font-demo.4th` | 4200, 4201, 4202 | `0xce1fd7d1b581a56d` | yes |
| `zuse-eligibility.4th` | 4021, 4022 | `0x8b49c1bc1e01dc58` | yes |
| `zuse.4th` | 4016, 4017, 4018 | `0x490ded9be257a90b` | yes |
## Block Map (sorted by LBN)
| LBN | Capsule | xxHash64 | Status |
|-----|---------|----------|--------|
| 2049 | `init.4th` | `0x9ac6523d24b80cd0` | ok |
| 2050 | `init.4th` | `0x9ac6523d24b80cd0` | ok |
| 2057 | `init.4th` | `0x9ac6523d24b80cd0` | ok |
| 2049 | `init.4th` | `0x5d35c5c6a6eafe04` | ok |
| 2050 | `init.4th` | `0x5d35c5c6a6eafe04` | ok |
| 2057 | `init.4th` | `0x5d35c5c6a6eafe04` | ok |
| 2064 | `init-l8-omni.4th` | `0x5979e314d6452045` | ok |
| 2065 | `init-l8-omni.4th` | `0x5979e314d6452045` | ok |
| 2066 | `init-l8-omni.4th` | `0x5979e314d6452045` | ok |
@@ -107,6 +110,35 @@
| 4016 | `zuse.4th` | `0x490ded9be257a90b` | ok |
| 4017 | `zuse.4th` | `0x490ded9be257a90b` | ok |
| 4018 | `zuse.4th` | `0x490ded9be257a90b` | ok |
| 4019 | `block-acl.4th` | `0xf6cc2a59e3a6734e` | ok |
| 4020 | `block-acl.4th` | `0xf6cc2a59e3a6734e` | ok |
| 4021 | `zuse-eligibility.4th` | `0x8b49c1bc1e01dc58` | ok |
| 4022 | `zuse-eligibility.4th` | `0x8b49c1bc1e01dc58` | ok |
| 4023 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4024 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4025 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4026 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4027 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4028 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4029 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4030 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4031 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4032 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4033 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4034 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4035 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4036 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4037 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4038 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4039 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4040 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4041 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4042 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4043 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4044 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4045 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4046 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4047 | `acl-std79.4th` | `0x5a622e41d1fd0bb9` | ok |
| 4050 | `lib.4th` | `0x4b216635c359ef73` | ok |
| 4055 | `common:msg.4th` | `0x850a0382344ea6c4` | ok |
| 4060 | `doe-campaign.4th` | `0x3d4549142d91ec20` | ok |
@@ -115,52 +147,52 @@
| 4063 | `doe-campaign.4th` | `0x3d4549142d91ec20` | ok |
| 4064 | `doe-campaign.4th` | `0x3d4549142d91ec20` | ok |
| 4065 | `doe-campaign.4th` | `0x3d4549142d91ec20` | ok |
| 4110 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4111 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4112 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4113 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4122 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4123 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4124 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4125 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4126 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4127 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4128 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4129 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4130 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4131 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4132 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4133 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4134 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4135 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4136 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4137 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4138 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4139 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4140 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4141 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4153 | `hermes:init.4th` | `0x9d6119b69d4113af` | ok |
| 4160 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4161 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4162 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4163 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4164 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4165 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4166 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4167 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4168 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4169 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4170 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4171 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4172 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4173 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4174 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4177 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4178 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4179 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4180 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4181 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4182 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4110 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4111 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4112 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4113 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4122 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4123 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4124 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4125 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4126 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4127 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4128 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4129 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4130 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4131 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4132 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4133 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4134 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4135 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4136 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4137 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4138 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4139 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4140 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4141 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4153 | `hermes:init.4th` | `0x2df61924448a6812` | ok |
| 4160 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4161 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4162 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4163 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4164 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4165 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4166 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4167 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4168 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4169 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4170 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4171 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4172 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4173 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4174 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4177 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4178 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4179 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4180 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4181 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4182 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4200 | `user-font-demo.4th` | `0xce1fd7d1b581a56d` | ok |
| 4201 | `user-font-demo.4th` | `0xce1fd7d1b581a56d` | ok |
| 4202 | `user-font-demo.4th` | `0xce1fd7d1b581a56d` | ok |
@@ -200,136 +232,142 @@
| 4840 | `init-l8-transition.4th` | `0xbcc1a81976f0a4c9` | ok |
| 4841 | `init-l8-transition.4th` | `0xbcc1a81976f0a4c9` | ok |
| 4842 | `init-l8-transition.4th` | `0xbcc1a81976f0a4c9` | ok |
| 4851 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4852 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4853 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4854 | `artemis:init.4th` | `0xfe6e570467368153` | ok |
| 4855 | `hermes:init.4th` | `0x9d6119b69d4113af` | ok |
| 4900 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4901 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4902 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4903 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4904 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4905 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4906 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4907 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4908 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4909 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4910 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4911 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4912 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4913 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4914 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4915 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4916 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4917 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4918 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4919 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4920 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4921 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4922 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4923 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4924 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 4925 | `font.4th` | `0x720792b4fc758156` | ok |
| 4926 | `font.4th` | `0x720792b4fc758156` | ok |
| 4927 | `font.4th` | `0x720792b4fc758156` | ok |
| 4928 | `font.4th` | `0x720792b4fc758156` | ok |
| 4929 | `font.4th` | `0x720792b4fc758156` | ok |
| 4930 | `font.4th` | `0x720792b4fc758156` | ok |
| 4931 | `font.4th` | `0x720792b4fc758156` | ok |
| 4932 | `font.4th` | `0x720792b4fc758156` | ok |
| 4933 | `font.4th` | `0x720792b4fc758156` | ok |
| 4934 | `font.4th` | `0x720792b4fc758156` | ok |
| 4935 | `font.4th` | `0x720792b4fc758156` | ok |
| 4936 | `font.4th` | `0x720792b4fc758156` | ok |
| 4937 | `font.4th` | `0x720792b4fc758156` | ok |
| 4938 | `font.4th` | `0x720792b4fc758156` | ok |
| 4939 | `font.4th` | `0x720792b4fc758156` | ok |
| 4940 | `font.4th` | `0x720792b4fc758156` | ok |
| 4941 | `font.4th` | `0x720792b4fc758156` | ok |
| 4942 | `font.4th` | `0x720792b4fc758156` | ok |
| 4943 | `font.4th` | `0x720792b4fc758156` | ok |
| 4944 | `font.4th` | `0x720792b4fc758156` | ok |
| 4945 | `font.4th` | `0x720792b4fc758156` | ok |
| 4946 | `font.4th` | `0x720792b4fc758156` | ok |
| 4947 | `font.4th` | `0x720792b4fc758156` | ok |
| 4948 | `font.4th` | `0x720792b4fc758156` | ok |
| 4949 | `font.4th` | `0x720792b4fc758156` | ok |
| 4950 | `font.4th` | `0x720792b4fc758156` | ok |
| 4951 | `font.4th` | `0x720792b4fc758156` | ok |
| 4952 | `font.4th` | `0x720792b4fc758156` | ok |
| 4953 | `font.4th` | `0x720792b4fc758156` | ok |
| 4954 | `font.4th` | `0x720792b4fc758156` | ok |
| 4955 | `font.4th` | `0x720792b4fc758156` | ok |
| 4956 | `font.4th` | `0x720792b4fc758156` | ok |
| 4957 | `font.4th` | `0x720792b4fc758156` | ok |
| 4958 | `font.4th` | `0x720792b4fc758156` | ok |
| 4959 | `font.4th` | `0x720792b4fc758156` | ok |
| 4960 | `font.4th` | `0x720792b4fc758156` | ok |
| 4961 | `font.4th` | `0x720792b4fc758156` | ok |
| 4962 | `font.4th` | `0x720792b4fc758156` | ok |
| 4963 | `font.4th` | `0x720792b4fc758156` | ok |
| 4964 | `font.4th` | `0x720792b4fc758156` | ok |
| 4965 | `font.4th` | `0x720792b4fc758156` | ok |
| 4966 | `font.4th` | `0x720792b4fc758156` | ok |
| 4967 | `font.4th` | `0x720792b4fc758156` | ok |
| 4968 | `font.4th` | `0x720792b4fc758156` | ok |
| 4969 | `font.4th` | `0x720792b4fc758156` | ok |
| 4970 | `font.4th` | `0x720792b4fc758156` | ok |
| 4971 | `font.4th` | `0x720792b4fc758156` | ok |
| 4972 | `font.4th` | `0x720792b4fc758156` | ok |
| 4973 | `font.4th` | `0x720792b4fc758156` | ok |
| 4974 | `font.4th` | `0x720792b4fc758156` | ok |
| 4975 | `font.4th` | `0x720792b4fc758156` | ok |
| 4976 | `font.4th` | `0x720792b4fc758156` | ok |
| 4977 | `font.4th` | `0x720792b4fc758156` | ok |
| 4978 | `font.4th` | `0x720792b4fc758156` | ok |
| 4979 | `font.4th` | `0x720792b4fc758156` | ok |
| 4980 | `font.4th` | `0x720792b4fc758156` | ok |
| 4981 | `font.4th` | `0x720792b4fc758156` | ok |
| 4982 | `font.4th` | `0x720792b4fc758156` | ok |
| 4983 | `font.4th` | `0x720792b4fc758156` | ok |
| 4984 | `font.4th` | `0x720792b4fc758156` | ok |
| 4985 | `font.4th` | `0x720792b4fc758156` | ok |
| 5000 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 5001 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 5002 | `fabric.4th` | `0x9b1d061339cea98d` | ok |
| 5003 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5004 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5005 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5006 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5007 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5008 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5009 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5010 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5011 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5012 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5013 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5014 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5015 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5016 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5017 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5018 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5019 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5020 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5021 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5022 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5023 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5024 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5025 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5026 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5027 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5028 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5029 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5030 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5031 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5032 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5033 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5034 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5035 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5036 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5037 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 5038 | `common:messaging.4th` | `0x892fd1c86d8c175e` | ok |
| 4851 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4852 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4853 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4854 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4855 | `hermes:init.4th` | `0x2df61924448a6812` | ok |
| 4856 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4857 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4858 | `artemis:init.4th` | `0xac215ecb873c4db3` | ok |
| 4900 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4901 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4902 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4903 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4904 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4905 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4906 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4907 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4908 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4909 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4910 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4911 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4912 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4913 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4914 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4915 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4916 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4917 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4918 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4919 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4920 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4921 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4922 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4923 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4924 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 4925 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4926 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4927 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4928 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4929 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4930 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4931 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4932 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4933 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4934 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4935 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4936 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4937 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4938 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4939 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4940 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4941 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4942 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4943 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4944 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4945 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4946 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4947 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4948 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4949 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4950 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4951 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4952 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4953 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4954 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4955 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4956 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4957 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4958 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4959 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4960 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4961 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4962 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4963 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4964 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4965 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4966 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4967 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4968 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4969 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4970 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4971 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4972 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4973 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4974 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4975 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4976 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4977 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4978 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4979 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4980 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4981 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4982 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4983 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4984 | `font.4th` | `0x3f305911500c78f6` | ok |
| 4985 | `font.4th` | `0x3f305911500c78f6` | ok |
| 5000 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 5001 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 5002 | `fabric.4th` | `0x9d9489cbeca4099b` | ok |
| 5003 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5004 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5005 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5006 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5007 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5008 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5009 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5010 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5011 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5012 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5013 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5014 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5015 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5016 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5017 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5018 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5019 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5020 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5021 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5022 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5023 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5024 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5025 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5026 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5027 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5028 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5029 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5030 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5031 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5032 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5033 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5034 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5035 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5036 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5037 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5038 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5039 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5040 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5041 | `common:messaging.4th` | `0x5cfb02a42f4a8323` | ok |
| 5100 | `turtle.4th` | `0x4d470418ca543365` | ok |
| 5101 | `turtle.4th` | `0x4d470418ca543365` | ok |
| 5102 | `turtle.4th` | `0x4d470418ca543365` | ok |
@@ -346,11 +384,11 @@
| 5113 | `sdk.4th` | `0x008fdbbb62c94a3a` | ok |
| 5114 | `sdk.4th` | `0x008fdbbb62c94a3a` | ok |
| 5115 | `sdk.4th` | `0x008fdbbb62c94a3a` | ok |
| 5116 | `hermes:init.4th` | `0x9d6119b69d4113af` | ok |
| 5116 | `hermes:init.4th` | `0x2df61924448a6812` | ok |
## Conflicts
None.
---
*32 capsule(s) scanned. Re-run `mkcapsule --manifest <dir>` to refresh.*
*35 capsule(s) scanned. Re-run `mkcapsule --manifest <dir>` to refresh.*
capsules/acl-std79.4th
+179
View File
@@ -0,0 +1,179 @@
Block 4023
( acl-std79.4th - FORTH-79/83 standard-word-only lockdown )
( Denies+pins every dict word not on ACL-STD79-LIST below. )
( Excludes: BYE, COLD/WARM/REBOOT/SAVE-SYSTEM, the block )
( editor (L S SHOW EDIT UPDATE SAVE-BUFFERS), BLK-ACL-*, )
( FORGET/FENCE. Kept: (BRANCH) etc -- IF/DO/LOOP compile )
( calls to these; denying them breaks control flow. )
( Full rationale: FABRIC-3.md, 2026-09-07. )
CREATE ACL-STD79-LIST
Block 4024
( Stack + return stack )
' DROP , ' DUP , ' ?DUP , ' SWAP , ' OVER ,
' ROT , ' -ROT , ' DEPTH , ' PICK , ' ROLL ,
' >R , ' R> , ' R@ ,
Block 4025
( Memory )
' @ , ' ! , ' C@ , ' C! , ' +! , ' -! ,
' 2@ , ' 2! , ' FILL , ' MOVE , ' ERASE ,
' CELLS ,
Block 4026
( Arithmetic )
' + , ' - , ' * , ' / , ' MOD , ' /MOD ,
' */ , ' */MOD , ' 1+ , ' 1- , ' 2+ , ' 2- ,
' 2* , ' 2/ , ' ABS , ' NEGATE , ' MIN , ' MAX ,
Block 4027
( Logical / comparison, part 1 )
' AND , ' OR , ' XOR , ' NOT , ' INVERT ,
' LSHIFT , ' RSHIFT , ' 0= , ' 0< , ' 0> ,
' 0<> , ' = , ' <> ,
Block 4028
( Logical / comparison, part 2 )
' < , ' > , ' >= , ' <= , ' U< , ' U> ,
' WITHIN , ' TRUE , ' FALSE ,
Block 4029
( Mixed / double arithmetic, part 1 )
' M+ , ' M- , ' M* , ' M/MOD ,
' S>D , ' D+ , ' D- , ' DNEGATE , ' DABS ,
' DMAX , ' DMIN , ' D< , ' D= ,
Block 4030
( Mixed / double arithmetic, part 2 )
' 2DROP , ' 2DUP , ' 2SWAP , ' 2OVER ,
' 2ROT , ' 2>R , ' 2R> , ' 2R@ ,
' D0= , ' D0< , ' D2* , ' D2/ ,
Block 4031
( Formatted output )
' . , ' .R , ' U. , ' U.R , ' D. , ' D.R ,
' .S , ' ? , ' DUMP , ' <# , ' # , ' #S ,
' #> , ' HOLD , ' SIGN , ' BASE ,
' DECIMAL , ' HEX , ' OCTAL ,
Block 4032
( Strings, part 1 )
' COUNT , ' EXPECT , ' SPAN , ' QUERY ,
' TIB , ' WORD , ' (s") , ' S" , ' >IN ,
' SOURCE , ' BL , ' ['] ,
Block 4033
( Strings, part 2 )
' LITERAL , ' [LITERAL] , ' CONVERT ,
' NUMBER , ' ENCLOSE , ' -TRAILING ,
' CMOVE , ' CMOVE> , ' COMPARE ,
' SEARCH , ' SCAN , ' SKIP , ' BLANK ,
Block 4034
( I/O )
' EMIT , ' CR , ' KEY , ' ?TERMINAL ,
' TYPE , ' SPACE , ' SPACES ,
' (do-string) , ' ." ,
Block 4035
( Block -- read-only subset, no editor/writer )
' BLOCK , ' BUFFER , ' FLUSH , ' LOAD ,
' LIST , ' THRU , ' SCR , ' --> ,
Block 4036
( Dictionary space )
' HERE , ' ALIGN , ' ALLOT , ' , , ' C, ,
' 2, , ' PAD , ' SP! , ' SP@ , ' LATEST ,
Block 4037
( Dictionary internals -- introspection only; )
( execution stays gated per-target-word. )
' SMUDGE , ' HIDDEN , ' >BODY , ' >NAME ,
' NAME> , ' >LINK , ' LINK> , ' CFA ,
' LFA , ' NFA , ' PFA , ' TRAVERSE ,
' INTERPRET , ' FIND ,
Block 4038
( Vocabulary / search order )
' VOCABULARY , ' DEFINITIONS , ' CONTEXT ,
' CURRENT , ' FORTH , ' ORDER , ' (FIND) ,
Block 4039
( System -- lifecycle words excluded )
' WORDS , ' VLIST , ' SEE , ' PAGE ,
' EXECUTE , ' NOP , ' QUIT , ' ABORT ,
' (ABORT") , ' ABORT" , ' ( , ' \ ,
Block 4040
( Defining words -- FORGET/FENCE excluded )
' : , ' ; , ' CREATE , ' VARIABLE ,
' CONSTANT , ' IMMEDIATE , ' STATE ,
' [ , ' ] , ' COMPILE , ' [COMPILE] ,
' LIT , ' DOES> ,
Block 4041
( Control flow runtime primitives -- kept, )
( IF/DO/LOOP compile calls to these. )
' (BRANCH) , ' (0BRANCH) , ' (?DO) ,
' (DO) , ' (LOOP) , ' (+LOOP) , ' (LEAVE) ,
Block 4042
( Control flow, part 1 )
' IF , ' ELSE , ' THEN , ' BEGIN ,
' WHILE , ' REPEAT , ' AGAIN , ' UNTIL ,
Block 4043
( Control flow, part 2 )
' ?DO , ' DO , ' LOOP , ' +LOOP ,
' LEAVE , ' I , ' J , ' UNLOOP ,
' EXIT , ' CASE , ' OF , ' ENDOF ,
' ENDCASE ,
Block 4044
( ACL-STD79-ALLOWED? ( xt -- flag ) )
: ACL-STD79-ALLOWED? ( xt -- flag )
>R
ACL-STD79-LIST
BEGIN
DUP @
WHILE
DUP @ R@ = IF R> DROP DROP TRUE EXIT THEN
1 CELLS +
REPEAT
DROP R> DROP FALSE ;
Block 4047
( ACL-LOCKDOWN-STD79's own walk loop calls all )
( four of these on every iteration -- if the )
( walk denied any one, it would deny its own )
( ability to keep running: a real self- )
( referential fault caught live 2026-09-07 (VM )
( fault, emergency console disabled), twice, one )
( word at a time. Must all stay allowed. Sentinel )
( last. )
' ACL-STD79-LIST , ' ACL-STD79-ALLOWED? ,
' ACL-ALLOW! , ' ACL-PIN ,
0 , ( sentinel )
Block 4045
( ACL-WALK-MARK's own xt = correct walk- )
( start (the true dictionary head at the )
( moment the walk runs). Same >LINK/LINK> )
( traversal ACL-INIT-PRIMITIVES/WORDS use. )
: ACL-WALK-MARK ( -- ) ;
Block 4046
: ACL-LOCKDOWN-STD79 ( -- )
['] ACL-WALK-MARK
BEGIN
DUP
WHILE
DUP ACL-STD79-ALLOWED?
IF 1 OVER ACL-ALLOW!
ELSE 0 OVER ACL-ALLOW!
THEN
DUP ACL-PIN
DUP >LINK LINK>
SWAP DROP
REPEAT
DROP ;
capsules/artemis/init.4th
+39 -1
View File
@@ -65,7 +65,7 @@ Block 4137
( item 4.6 -- Stadium cell-index arena, not a heat arena. One )
( slot per possible LBN, holding STADIUM-NONE or a live cell )
( index -- residency exists only while a block is allocated )
( (admission-on-allocate, FABRIC-2.md item 4.6's ruling). )
( (admission-on-allocate, FABRIC-1.md item 4.6's ruling). )
CREATE BLK-CELL ART-DATA-BLKS CELLS ALLOT
Block 4138
( Cell-index accessors and LBN conversion. Heat itself now )
@@ -497,5 +497,43 @@ Block 4854
( INIT). Hermes always exists by Artemis's birth. )
S" common:messaging.4th" EXEC
MSG-CD-INIT
2 MY-CH-ID !
S" 2 COMMON-CH @ CH-ADD-MBR" S" Hermes" VM-EXEC
STARTUP-BANNER
Block 4856
( Storage-attach ack builder. Hera sends "<dev-addr> )
( HERA-BLK-ATTACH-REQ"; reply is "<dev-addr> <ok?> )
( BLK-ATTACH-ACK" so identity birth only proceeds once )
( storage is confirmed (repl.c's BLK-ATTACH-ACK). Bob, )
( 2026-09-07. )
CREATE ATTACH-ACK-BUF 64 ALLOT
VARIABLE ATTACH-ACK-LEN
: ACK-APPEND ( src-addr len -- )
DUP >R
ATTACH-ACK-BUF ATTACH-ACK-LEN @ +
SWAP CMOVE
ATTACH-ACK-LEN @ R> + ATTACH-ACK-LEN ! ;
Block 4857
: ACK-APPEND-CHAR ( char -- )
ATTACH-ACK-BUF ATTACH-ACK-LEN @ + C!
ATTACH-ACK-LEN @ 1+ ATTACH-ACK-LEN ! ;
: ACK-APPEND-NUM ( n -- )
0 SWAP <# #S #> ACK-APPEND ;
Block 4858
( HERA-BLK-ATTACH-REQ ( dev-addr -- ): VM-EXEC'd by MSG- )
( DELIVER when Hera's request arrives. Runs BLK-ATTACH on )
( Artemis's own dictionary (real ACL gating, same as any )
( other message payload), then replies to Hera (idx 0). )
: HERA-BLK-ATTACH-REQ ( dev-addr -- )
0 ATTACH-ACK-LEN !
DUP ACK-APPEND-NUM
BL ACK-APPEND-CHAR
DUP BLK-ATTACH ACK-APPEND-NUM
DROP
BL ACK-APPEND-CHAR
S" BLK-ATTACH-ACK" ACK-APPEND
BLK-ATTACH-EVENT 2 0 ATTACH-ACK-BUF
ATTACH-ACK-LEN @ 0 MSG-SEND ;
capsules/block-acl.4th
+25
View File
@@ -0,0 +1,25 @@
Block 4019
( block-acl.4th - Block-Level Access Control BMAPFMT )
( C prims: BLK-ACL-ALLOW@ BLK-ACL-ALLOW! BLK-ACL-TTL@ )
( BLK-ACL-TTL! BLK-OWNER@ )
( Policy words this file: BLK-ACL-CHECK )
( Mirrors ACL.4th's C-primitive/FORTH-policy split, )
( applied to blocks instead of words. )
( FABRIC-2.md H.12 step 16, 2026-09-03. )
256 CONSTANT BLK-ACL-BASE-TTL
Block 4020
( BLK-ACL-CHECK block# -- allow? )
( Fast-deny check, vm.c 611-624's pattern applied to )
( a block. First touch: default-permissive claim -- )
( allow=1, TTL=BLK-ACL-BASE-TTL -- matching the word )
( card's own default. No automatic TTL decrement loop )
( exists for blocks yet -- words decrement per word )
( dispatch, blocks have no equivalent hot path -- but )
( this is a real, working fast-deny gate either way. )
: BLK-ACL-CHECK ( block# -- allow? )
DUP BLK-ACL-TTL@ 0= IF
DUP BLK-ACL-BASE-TTL SWAP BLK-ACL-TTL!
DUP 1 SWAP BLK-ACL-ALLOW!
THEN
BLK-ACL-ALLOW@ ;
capsules/common/messaging.4th
+53 -1
View File
@@ -19,6 +19,21 @@ Block 5038
( CONSOLE-CMD-EVENT: console-VM -> paired user-VM command )
( relay message type, async MSG-SEND/MSG-DELIVER. )
7 CONSTANT CONSOLE-CMD-EVENT
( ELEVATE-REQUEST: H.5/H.8 -- word-ACL elevation ask, )
( carried to Zuse via CH-REQUEST. See SEND-ELEVATE- )
( REQUEST/ELEVATE-GRANT below and in zuse-eligibility.4th. )
8 CONSTANT ELEVATE-REQUEST
Block 5041
( BLK-ATTACH-EVENT: Hera -> Artemis storage-attach request, )
( and Artemis -> Hera ack. Payload is FORTH text, executed )
( by the receiver, same as every other message here -- see )
( HERA-BLK-ATTACH-REQ (artemis:init.4th) and BLK-ATTACH-ACK )
( (repl.c). Messaging-migration decision, Bob, 2026-09-07: )
( Hera keeps polling/sig-checking; the storage-registration )
( step (blk_subsys_attach_device) moves to a real message )
( instead of a direct C call, so identity birth only )
( proceeds once Artemis confirms storage succeeded. )
9 CONSTANT BLK-ATTACH-EVENT
Block 5004
( StadiumBehaviour tags, match stadium.h's enum )
0 CONSTANT SB-MIGRATE
@@ -42,6 +57,7 @@ VARIABLE MBR-FREE-HEAD
VARIABLE MSG-SEQ
VARIABLE CH-ACTIVE
VARIABLE COMMON-CH
VARIABLE MY-CH-ID
Block 5006
( VM name routing table -- same fixed table every VM loads, )
( so IDX>NAME resolves identically everywhere. )
@@ -351,7 +367,10 @@ Block 5031
: CH-MINT-ID ( owner -- id )
MSG-SEQ @ 1+ DUP MSG-SEQ !
SWAP 32 LSHIFT OR ;
( H.8: initiator-only gate. Refuses if `from` doesn't )
( match MY-CH-ID -- no posting while claiming another VM. )
: CH-REQUEST ( type from to paddr plen -- )
3 PICK MY-CH-ID @ <> IF 2DROP 2DROP DROP EXIT THEN
COMMON-CH @ CH-STATE@ CH-OPEN = IF
COMMON-CH @ MSG-SEND
ELSE 2DROP 2DROP DROP THEN ;
@@ -385,7 +404,7 @@ Block 5033
MBR-INIT-FREE
0 MSG-SEQ !
0 MSG-LAST-MSG !
0 CH-ACTIVE !
0 CH-ACTIVE ! -1 MY-CH-ID !
COMMON-INIT
VM-NAMES-INIT ;
Block 5034
@@ -435,3 +454,36 @@ VARIABLE BC-CH VARIABLE BC-SCAN
BC-PADDR @ BC-PLEN @ BC-CH @ MSG-SEND
BC-SCAN @ MBR-NEXT@ BC-SCAN !
REPEAT ;
Block 5039
( H.8: SEND-ELEVATE-REQUEST payload builder -- )
( scratch text buffer + append primitives. )
CREATE ELEVATE-REQ-BUF 256 ALLOT
VARIABLE ELEVATE-REQ-LEN
: ELEVATE-REQ-RESET ( -- ) 0 ELEVATE-REQ-LEN ! ;
: ELEVATE-REQ-PUTC ( c -- )
ELEVATE-REQ-BUF ELEVATE-REQ-LEN @ + C!
1 ELEVATE-REQ-LEN +! ;
: ELEVATE-REQ-APPEND ( addr u -- )
>R
ELEVATE-REQ-BUF ELEVATE-REQ-LEN @ +
R@ CMOVE
ELEVATE-REQ-LEN @ R> + ELEVATE-REQ-LEN ! ;
: ELEVATE-REQ-NUM ( n -- )
<# 0 SWAP #S #> ELEVATE-REQ-APPEND ;
Block 5040
( SEND-ELEVATE-REQUEST: ask Zuse for word-ACL )
( elevation. pk3..pk0 order so top-down emits )
( pk0 first; waddr/wu = target word name text. )
: SEND-ELEVATE-REQUEST ( pk3 pk2 pk1 pk0 waddr wu -- )
ELEVATE-REQ-RESET
83 ELEVATE-REQ-PUTC 34 ELEVATE-REQ-PUTC
32 ELEVATE-REQ-PUTC
ELEVATE-REQ-APPEND
34 ELEVATE-REQ-PUTC 32 ELEVATE-REQ-PUTC
ELEVATE-REQ-NUM 32 ELEVATE-REQ-PUTC
ELEVATE-REQ-NUM 32 ELEVATE-REQ-PUTC
ELEVATE-REQ-NUM 32 ELEVATE-REQ-PUTC
ELEVATE-REQ-NUM 32 ELEVATE-REQ-PUTC
S" ELEVATE-GRANT" ELEVATE-REQ-APPEND
ELEVATE-REQUEST MY-CH-ID @ 0 ELEVATE-REQ-BUF
ELEVATE-REQ-LEN @ CH-REQUEST ;
capsules/contrib/README.md
+32
View File
@@ -0,0 +1,32 @@
# capsules/contrib/
Milestone 7 (contributor capsules / trust tiers), FABRIC-2.md §I.5.
Any `.4th` file placed here gets `FLAG_CONTRIB` in addition to the usual
`FLAG_PRODUCTION | FLAG_EXPERIMENT` pair — `tools/mkcapsule.c`'s
`flags_from_name()` path-matches on the colon-separated capsule name
starting with `contrib:`, mirroring `FLAG_MAMA_INIT`'s own exact-match
pattern one line up in that same function.
**Trust-tier direction, decided in conversation 2026-09-04:** QEMU-vs-real-
hardware conditional enforcement — a contributor capsule is validated more
strictly on real hardware than under QEMU, using
`timer_calibration_record()->vm_mode` (`include/starkernel/timer.h`) as the
signal. `vm_mode` is a real per-architecture hypervisor-vs-hardware
detection as of this same pass (amd64: `CPUID.1:ECX[31]`; aarch64: ACPI
RSDP OEM ID; riscv64: devicetree `compatible` string) — not a build-time
flag, so the same binary enforces differently depending on where it
actually boots.
**Enforcement rule, built 2026-09-04:** `contrib_capsule_refused()`
(`capsule_birth.c`), called from both `capsule_birth_baby()` and
`capsule_run_experiment()` (never `capsule_birth_mama()` — Mama's own init
can never carry `FLAG_CONTRIB`, mutually exclusive with `FLAG_MAMA_INIT` by
construction). Under QEMU (`vm_mode == 1`): no additional check, same
WARN-only treatment every other capsule gets. On real hardware
(`vm_mode == 0`): a contrib capsule additionally requires `CAPSULE_SIG_OK`
— `MISSING`/`NO_ROOT_KEY`, which stay WARN-only for every other capsule
(most machines lack the offline signing key), are refused here specifically
because a contributor's capsule has no other provenance to fall back on.
Additive to, never a replacement for, the existing `CAPSULE_SIG_INVALID`
refusal already enforced on every capsule regardless of `FLAG_CONTRIB`.
capsules/fabric.4th
+1 -1
View File
@@ -1,6 +1,6 @@
Block 4900
( fabric.4th -- Console drawing-fabric coordinate machinery )
( FABRIC.md item 4.3.3. 45-degree cavalier orthographic )
( FABRIC-0.md item 4.3.3. 45-degree cavalier orthographic )
( projection. Z is depth-into-screen, not height. Q48.16 )
( throughout. Raw pixel write (PLOT/FB-WIDTH/FB-HEIGHT) is )
( C; this capsule is the FORTH-side policy on top of it. )
capsules/font.4th
+4 -4
View File
@@ -6,7 +6,7 @@ Block 4925
( (fabric.4th 5000-5002); straight strokes stay G-LINE. Not )
( every round-ish letter was converted -- only ones a single )
( circle/arc/ellipse renders cleanly without per-glyph angle )
( tuning (S/s/&/2/3/5/6/8/9 etc. stay blocky; see FABRIC.md). )
( tuning (S/s/&/2/3/5/6/8/9 stay blocky; FABRIC-0.md). )
Block 4926
( Digit 0: ELLIPSE -- true oval, not a 6-line rectangle. )
: G-0 ( -- adv )
@@ -534,7 +534,7 @@ Block 4969
500 ;
Block 4970
( Latin-1 Supplement, 11 glyphs. codepoints per FABRIC.md )
( Latin-1 Supplement, 11 glyphs. codepoints per FABRIC-0.md )
( 27.6.4. DEGREE/CENT use curves; rest are line-only. )
: G-DEGREE ( -- adv ) 250 600 60 G-CIRCLE 350 ;
: G-CENT ( -- adv )
@@ -600,7 +600,7 @@ Block 4975
: G-NBSP ( -- adv ) 300 ;
Block 4976
( General Punctuation, 7 glyphs. codepoints per FABRIC.md )
( General Punctuation, 7 glyphs. codepoints per FABRIC-0.md )
( 27.6.4. ELLIPSIS uses three CIRCLEs, matching PERIOD. )
: G-LSQUOTE ( -- adv )
230 650 220 600 G-LINE
@@ -636,7 +636,7 @@ Block 4978
Block 4979
( Real DISPATCH-DIGIT, replaces fabric.4th's placeholder. )
( Redefinition needed -- CASE binds early (FABRIC.md 27.6.5).)
( Redefinition needed -- CASE binds early (FABRIC-0.md 27.6.5).)
: DISPATCH-DIGIT ( codepoint -- adv ) CASE
48 OF G-0 ENDOF 49 OF G-1 ENDOF 50 OF G-2 ENDOF
51 OF G-3 ENDOF 52 OF G-4 ENDOF 53 OF G-5 ENDOF
capsules/fonts/README.md
+3 -3
View File
@@ -1,13 +1,13 @@
# capsules/fonts/
Font capsule for FABRIC.md items 4.3.7/4.3.7b (TrueType rendering, adjunct
Font capsule for FABRIC-0.md items 4.3.7/4.3.7b (TrueType rendering, adjunct
to the stroke font — §27.7).
| File | License | Provenance |
|------|---------|------------|
| `JetBrainsMono-Regular.ttf` | SIL Open Font License, Version 1.1 | The JetBrains Mono Project Authors, copyright 2020 (https://github.com/JetBrains/JetBrainsMono). License string confirmed by reading the font's own embedded `name` table directly (`strings -e b JetBrainsMono-Regular.ttf`) — not taken on trust from the filename. |
Chosen as the v1 test/default TTF font 2026-08-10 (FABRIC.md §27.7 "Update
Chosen as the v1 test/default TTF font 2026-08-10 (FABRIC-0.md §27.7 "Update
2026-08-10"), resolving that item's licensing-check blocker.
**Embedded as a raw-binary capsule, not text-encoded.** `tools/mkcapsule.c`'s
@@ -21,7 +21,7 @@ relative path, per `build_capsule_name()`). Fetch it with
`capsule_find_by_name()` (`include/starkernel/capsule.h`) — that returns
`offset`/`length` into the arena without ever routing through
`capsule_exec_payload()`, so nothing tries to interpret the font bytes as
FORTH source. This superseded FABRIC.md §27.7 decision #3 (hex/base64
FORTH source. This superseded FABRIC-0.md §27.7 decision #3 (hex/base64
text-encoding) — see that section's 2026-08-10 correction note.
No SIL OFL 1.1 full license text is bundled here yet — only the font's own
capsules/hermes/init.4th
+2 -1
View File
@@ -1,6 +1,6 @@
Block 4855
( Hermes v1 -- WELCOME. Generic messaging vocab moved to )
( common:messaging.4th, FABRIC-3.md Phase C 2026-08-28. )
( common:messaging.4th, FABRIC-2.md Phase C 2026-08-28. )
: WELCOME ( -- ) LOG-INFO" Hermes: loaded" ;
WELCOME
Block 4153
@@ -15,6 +15,7 @@ Block 5116
( VM that doesn't exist yet at Hera's own birth. )
S" common:messaging.4th" EXEC
MSG-CD-INIT
1 MY-CH-ID !
S" lib.4th" EXEC
1 COMMON-CH @ CH-ADD-MBR
0 COMMON-CH @ CH-ADD-MBR
capsules/init.4th
+2
View File
@@ -14,6 +14,8 @@ Block 2049
: VM-PARENT ( -- id ) 0 ;
: VM-CHILDREN ( -- ) ." (none)" CR ;
S" ACL.4th" EXEC
S" block-acl.4th" EXEC
S" zuse-eligibility.4th" EXEC
S" lib.4th" EXEC
S" fabric.4th" EXEC
S" font.4th" EXEC
capsules/zuse-eligibility.4th
+26
View File
@@ -0,0 +1,26 @@
Block 4021
( zuse-eligibility.4th - H.5/H.8 elevation grant )
( C prims: ZUSE-ELIGIBILITY-ADD ZUSE-ELIGIBLE? )
( NAME>XT ELEVATE-PUBKEY-UNPACK )
( Policy word this file: ELEVATE-GRANT. Runs in )
( Hera's own dict -- delivered here by messaging.4th's )
( MSG-DELIVER via VM-EXEC when a session calls the )
( common:messaging.4th SEND-ELEVATE-REQUEST entrypoint. )
( FABRIC-2.md H.12 step 21, 2026-09-03. )
CREATE ELEVATE-PK-BUF 32 ALLOT
Block 4022
( ELEVATE-GRANT ( waddr wu pk0 pk1 pk2 pk3 -- ) )
( Reconstructs the caller's pubkey, checks Zuse's )
( eligibility list, and on match grants the named )
( word ACL-ALLOW!/ACL-TTL! via the same reused )
( ACL-TTL mechanism H.5 decided on. No grant, no )
( error, on any mismatch -- silent refusal. )
: ELEVATE-GRANT ( waddr wu pk0 pk1 pk2 pk3 -- )
ELEVATE-PK-BUF ELEVATE-PUBKEY-UNPACK
ELEVATE-PK-BUF ZUSE-ELIGIBLE? IF
NAME>XT DUP IF
1 OVER ACL-ALLOW!
ACL-BASE-TTL SWAP ACL-TTL!
ELSE DROP THEN
ELSE 2DROP THEN ;
disk/README.md
+2 -2
View File
@@ -85,7 +85,7 @@ carrying timestamp noise in git history.
- `artemis-metafence-fresh.img` — 30MB raw image, blank at creation,
added 2026-08-26 for the top-of-device system-metadata fence
(`meta_fence_blocks` in `blk_volume_meta_t`, FABRIC-3.md Phase 8 §C).
(`meta_fence_blocks` in `blk_volume_meta_t`, FABRIC-2.md Phase 8 §C).
Same reasoning as `artemis-reloc-test.img` above: the fence is only
initialized to `BLK_META_FENCE_INIT` (128) by
`blk_compute_fresh_geometry()` on a fresh format, so a genuinely blank
@@ -103,7 +103,7 @@ carrying timestamp noise in git history.
or misreading adjacent fields.
- `zuse.img` — 64MB raw image simulating the physical Zuse superuser
thumbdrive for QEMU testing (FABRIC-3.md, Phase 8: `zuse.img` "bleach"
thumbdrive for QEMU testing (FABRIC-2.md, Phase 8: `zuse.img` "bleach"
mechanism, added 2026-08-26). **64MB is only this fixture's size, not a
constraint on real home-blocks thumbdrives** (Captain Bob, 2026-08-26) —
the design is not bound to any particular drive size; `homeblocks_sig_t`'s
disk/artemis.img
BIN
View File
Binary file not shown.
disk/thumbdrives/00-thumb-ident.img
BIN
View File
Binary file not shown.
disk/thumbdrives/01-thumb-ident.img
BIN
View File
Binary file not shown.
disk/thumbdrives/02-thumb-ident.img
BIN
View File
Binary file not shown.
disk/thumbdrives/03-thumb-ident.img
BIN
View File
Binary file not shown.
disk/thumbdrives/04-thumb-ident.img
BIN
View File
Binary file not shown.
disk/thumbdrives/05-thumb-ident.img
BIN
View File
Binary file not shown.
disk/thumbdrives/06-thumb-ident.img
BIN
View File
Binary file not shown.
disk/thumbdrives/bob-thumb-ident.img
BIN
View File
Binary file not shown.
disk/zuse.img → disk/thumbdrives/zuse-thumb-ident.img
View File
docs/lithosananke/DICTIONARY.md
+3 -3
View File
@@ -597,7 +597,7 @@ like `ttf_words.c`, not a word-registration file.
## Console Fabric — Framebuffer (`framebuffer_words.c`)
Kernel-only (`__STARKERNEL__`); no-ops on hosted builds. Raw hardware-boundary access —
FABRIC.md item 4.3.3.
FABRIC-0.md item 4.3.3.
| Word | Stack Effect | Description |
|---|---|---|
@@ -618,7 +618,7 @@ FABRIC.md item 4.3.3.
## Console Fabric — TrueType Text (`ttf_words.c`)
Kernel-only (`__STARKERNEL__`); no-op on hosted builds. FABRIC.md item 4.3.7e.
Kernel-only (`__STARKERNEL__`); no-op on hosted builds. FABRIC-0.md item 4.3.7e.
| Word | Stack Effect | Description |
|---|---|---|
@@ -626,7 +626,7 @@ Kernel-only (`__STARKERNEL__`); no-op on hosted builds. FABRIC.md item 4.3.7e.
## Console Fabric — Scrollback (`scroll_words.c`)
Kernel-only (`__STARKERNEL__`); no-op on hosted builds. FABRIC.md item 4.4q (boot-mode
Kernel-only (`__STARKERNEL__`); no-op on hosted builds. FABRIC-0.md item 4.4q (boot-mode
scrollback added by 4.4ac).
| Word | Stack Effect | Description |
docs/lithosananke/M7.1.md
+1 -1
View File
@@ -1,7 +1,7 @@
# M7.1: Init Capsule Architecture
**Status:** Shipped and live, not just designed — this document predates the actual
capsule/Tripod/Stadium work; see `FABRIC.md`/`FABRIC-2.md`/`FABRIC-3.md` for real status
capsule/Tripod/Stadium work; see `FABRIC-0.md`/`FABRIC-1.md`/`FABRIC-2.md` for real status
(per `.claude/CLAUDE.md`'s standing redirect)
**Branch:** `master` (post-split; the old `lithosananke` branch no longer exists in this repo)
**Prerequisite:** M7 (VM Parity Validation)
docs/lithosananke/ROADMAP.md
+122 -14
View File
@@ -3,7 +3,7 @@
**Branch:** `master` (post-split: this repo's `master` is the sole LithosAnanke production
line; the old `lithosananke` branch belonged to the pre-split combined monorepo and no
longer exists here — see `.claude/CLAUDE.md`'s "On the branch topology" note)
**Current:** M7.1 in progress — see `FABRIC.md`/`FABRIC-2.md`/`FABRIC-3.md` for real status
**Current:** M7.1 in progress — see `FABRIC-0.md`/`FABRIC-1.md`/`FABRIC-2.md` for real status
---
@@ -28,7 +28,115 @@ belongs here.
Applied to the two planned releases: the **v2.0.0** cut (even major, so LTS) is the QEMU
release; **v2.5.0** is the hardware bare-metal release that transfers v2.0.0's QEMU story to
real boards. See `FABRIC-3.md` §G for the release-gate punch lists.
real boards. See `FABRIC-2.md` §G for the release-gate punch lists.
**Board-by-board hardware rollout, decided 2026-08-29 (extends the above as boards come
online).** Real silicon is arriving incrementally (Beelink SER5 in hand now; RasPi 5 + Milk-V
orderable around Mon 2026-08-31), so the hardware release is split per real board in hand,
each its own even-minor cut on the same line (each `X.Y.0` here is an LTS point-in-time cut,
not a separate dev line):
- **v2.2.0 — amd64 bare metal.** Beelink SER5 (in hand). Gate: the generic GPT/FAT32
thumbdrive image (`make -f Makefile.starkernel ARCH=amd64 thumbdrive`) flashes to and boots
on the real SER5 via its real UEFI; POST + `ok>`; the amd64 **RDRAND** backend
(`rng: backend = rdrand`) serves live entropy; and a real Zuse identity is minted on a
second thumbdrive in real hardware and re-attaches. Two 16 GB sticks available: one to boot
the image, one to mint the Zuse user.
- **v2.4.0 — aarch64 bare metal.** Raspberry Pi 5 (orderable ~Mon 2026-08-31). Gate: boots
on the real board, aarch64 peripheral-RNG backend live, Zuse mint/attach on real media.
- **v2.5.0 — all three bare metal.** Adds Milk-V (riscv64) to the above; the Zkr (RNDR)
backend live. This is the full "same story on all three arches on real silicon" cut.
**Beyond v2.5.0 — Zynq FPGA is the next big milestone, after a hardening phase.** Once the
three general-purpose boards close, the next major transfer is to a **Zynq (AMD Xilinx)
FPGA** SoC — the step where the battle-tested amd64/aarch64/riscv64 story rides on
configurable silicon. That is a genuinely bigger milestone than any single prior board: an
FPGA demands its platform be carried forward rather than ported with trivial
architecture-delta work, and it reshapes the hardware story (soft/hard CPU cores, PL fabric,
non-standard memory map, custom peripherals). Expect a new even-major line for it once the
coloring-in period below lands.
**The FPGA creates a three-product split, decided 2026-08-29.** The Zynq is not just a fourth
platform to port to — it is the pivot that forces the project to separate into three
distinct products, each with its own host, delivery, and proof character. This is the neat
partition the FPGA's configurable-silicon nature makes possible and demands:
1. **Hosted StarForth** — the hosted/interpreted StarForth product that already exists
(3-arch acceptance-tested; runs StarForth hosted on an OS). Its delivery is the Forth
+ VM + capsule semantics as a portable, embeddable interpreted runtime.
2. **A full StarshipOS** — the standalone operating system built on LithosAnanke
(LithosAnanke → StarshipOS). Its delivery is a self-booting OS on general-purpose
silicon (the SER5/RasPi/Milk-V line already covers this).
3. **Hardware steady-state machinery with sealed executions, HOL-proven** — the
FPGA-native product: hardware-enforced sealed executions and steady-state machinery
whose guarantees are machine-checked in a proof assistant (HOL). This is the product only
configurable silicon can honor — secret/hardware-boundary enforcement and formally
verified behavior carried in silicon rather than software. Its delivery is the bitstream +
the HOL proof artifacts (not just a port of the OS).
The coupling is the point: the FPGA is where product 3 is born, and product 3's existence is
what cleanly separates 1 from 2 from 3. Product 1 ships hosted on an OS; product 2 ships as
an OS on general silicon; product 3 ships as proven hardware. Anything that straddles those
boundaries after this decision is a conscious product-line choice, not an accident of history.
Scoping of each product's concrete gates, and the new even-major line that carries products 1
through 3 as separate tracks, is defined at v2.5.0 close / during the coloring-in phase.
(This complements, and does not retract, the existing "hardware bare-metal release" policy
above.)
**IP framing of the three products — 3 patent applications + 3 marks, decided 2026-08-29.**
The three products are treated as **three patent applications**, each matched to a trademark,
with one caveat about the pre-existing provisional:
- **Patent 1 + mark StarForth.** The hosted/interpreted StarForth runtime product.
- **Patent 2 + marks StarshipOS + LithosAnanke.** The full standalone OS
(LithosAnanke → StarshipOS). (Noted as "StarshopOS" in the 2026-08-29 decision words;
canonical repo spelling and mark is **StarshipOS** — confirmed as the literal mark
to register.)
- **Patent 3 + mark Compudynamics.** The Zynq hardware steady-state machinery with sealed
executions, HOL-proven — anchored by the physics-adaptive runtime.
**Driving deadlines (why "no hurry" is wrong for #1 and #2), clarified 2026-08-29.** Two
clocks bind the near term, independent of product #3 and the FPGA:
- **#1 — the provisional will expire before conversion.** Its priority claim is time-boxed:
if the non-provisional isn't filed claiming benefit before the provisional's window lapses
(provisional filed ~Dec 2025 → window ~Dec 2026), the provisional's priority is lost and
the same subject matter cannot be re-staked by refiling thereafter. So #1 is on a hard
clock regardless of the December scope.
- **#2 — full StarshipOS is the December deliverable.** This is what "keeps the flagship
covered": the standalone-OS product (and, pending confirmation below, possibly the vehicle
that converts #1's provisional) must deliver by December.
- **Open point to resolve with counsel:** is **#2's** application (or the December delivery)
the **conversion vehicle** for #1's provisional — i.e., does it claim benefit from the
#1 provisional and thereby secure what would otherwise lapse — or is #1 converted by a
filing separate from #2? Captured as a decision record; no filing made.
**Relationship to the existing provisional (must be reconciled, not assumed).** The repo
already carries a **"Patent pending"** USPTO **provisional filed December 2025** for the
physics-grounded self-adaptive runtime (the Compudynamics adaptive runtime), sourced in
`docs/patent/` and referenced in `README.md`. Compudynamics is therefore already staked as
the brand of that foundation. Open points to resolve with counsel before any filing, so
nothing is invented or double-filed: is patent 3 the continuation/refinement of that
provisional (its HOL hardware realization) or a fresh application? Are the three product
applications additive to, or folding in, the Dec-2025 provisional? This record states intent;
it does not file, claim, or draft legal text.
**Before the FPGA — "coloring in", decided 2026-08-29.** The period between the all-three
bare-metal cut (v2.5.0) and starting the Zynq is finishing/hardening work that thickens the
shape of what already exists rather than adding new silicon. This is not idle time; it is
the point where v2.5.0's real-hardware story is made production-honest before the FPGA asks
to carry it further. Concrete items to define during it (draft scope, to be firmed at v2.5.0
close): Zynq-preflight robustness of the USB BOT/xHCI and block paths; live-entropy and
Zuse-cert hardening on the three real boards; SMP/multi-core bring-up and IRQ routing on real
ASICs (parked in the HAL notes); driver set expansion beyond the three boards before
committing an FPGA port; and whatever v2.5.0's real-board validation surfaces. As boards
land and the v2.5.0 gates close, this list is edited down to the concrete coloring-in punch
list, and the Zynq becomes the even-major target after it.
QEMU remains the zero-degradation reference on every line; each `X.Y.0` must reproduce the
QEMU acceptance story (`POST 1012/0/0` + `ok>`, block-fence Zuse true, backend entropy
non-deterministic) on its board before it closes.
---
@@ -43,8 +151,8 @@ M4 APIC ██████████████████
M5 Timer ████████████████████ COMPLETE
M6 Heap ████████████████████ COMPLETE
M7 VM Parity ████████████████████ COMPLETE
M7.1 Capsules ████████████████░░░░ LIVE — see FABRIC.md/FABRIC-2.md/FABRIC-3.md
M8 REPL ░░░░░░░░░░░░░░░░░░░░ OBSOLETE — see FABRIC.md §25.5 item 4.4
M7.1 Capsules ████████████████░░░░ LIVE — see FABRIC-0.md/FABRIC-1.md/FABRIC-2.md
M8 REPL ░░░░░░░░░░░░░░░░░░░░ OBSOLETE — see FABRIC-0.md §25.5 item 4.4
M9 Block I/O ░░░░░░░░░░░░░░░░░░░░ PLANNED
M10 Networking ░░░░░░░░░░░░░░░░░░░░ FUTURE
```
@@ -220,15 +328,15 @@ APIC Timer: started
**Goal:** Content-addressed, immutable init capsules for VM birth
**Status:** Design Complete (see [M7.1.md](M7.1.md)) — this section predates the actual
capsule/Tripod/Stadium work and is not current. **See `FABRIC.md`/`FABRIC-2.md` for real
capsule/Tripod/Stadium work and is not current. **See `FABRIC-0.md`/`FABRIC-1.md` for real
status** (per `.claude/CLAUDE.md`'s standing redirect) — Tripod (Hera/Hermes/Artemis),
word-level ACL Phases 1–7, and the Stadium physics-economy migration are all live, not just
designed. Most recently: item 4.6 (Artemis's block-heat arena migrated to Stadium
admission-on-allocate) verified passing its 30-rep stress campaign on all three
architectures 2026-08-18, after fixing a quota-grant ordering bug (`capsule_birth.c`) that
had made every admission fail; see `FABRIC-2.md` Section H. The same pass also fixed a
had made every admission fail; see `FABRIC-1.md` Section H. The same pass also fixed a
long-standing aarch64-only crash on `BYE` (wrong PSCI conduit — SMC has nothing to answer it
under AAVMF/no-EL3 boot; switched to HVC), see `FABRIC-2.md` Section I.
under AAVMF/no-EL3 boot; switched to HVC), see `FABRIC-1.md` Section I.
**Core Concepts:**
@@ -271,7 +379,7 @@ under AAVMF/no-EL3 boot; switched to HVC), see `FABRIC-2.md` Section I.
## Phase 4: Interactive Forth (M8)
> **⚠ OBSOLETE (2026-08-11).** This entire M8 section is superseded by
> `FABRIC.md` §25.5 item 4.4 (REPL). The console/REPL design has moved past
> `FABRIC-0.md` §25.5 item 4.4 (REPL). The console/REPL design has moved past
> what's scoped here — do not use this section as a source for REPL or
> CANVAS design decisions. Kept in place for history only.
@@ -279,7 +387,7 @@ under AAVMF/no-EL3 boot; switched to HVC), see `FABRIC-2.md` Section I.
**Status:** Scoped 2026-08-11 (this section). Substrate (interrupt-driven keyboard
input, glyph rendering) already complete via Stadium's Console fabric work
(FABRIC.md §25.5 items 4.3.5–4.3.7f) — see "What's already done" below. This
(FABRIC-0.md §25.5 items 4.3.5–4.3.7f) — see "What's already done" below. This
scoping pass covers what's left: wiring the existing keyboard-event stream into
the REPL's character input path.
@@ -293,11 +401,11 @@ is a second input source feeding the same loop.
aarch64/riscv64 virtio-keyboard-pci + GIC/PLIC), converged behind one shared
interface: `KEY-EVENT ( -- keycode pressed -1 | 0 )` in
`src/word_source/keyboard_words.c`, `keycode` in the Linux input keycode
namespace. FABRIC.md items 4.3.5–4.3.5f, verified live on all three
namespace. FABRIC-0.md items 4.3.5–4.3.5f, verified live on all three
architectures with real keypresses.
- Glyph rendering, both paths: the stroke-drawn font (`TEXT`, capsule-based,
113-glyph v1 repertoire, FABRIC.md 4.3.6–4.3.6g) and TrueType (`TTF-TEXT`,
proportional spacing via real `hmtx` advance widths, FABRIC.md 4.3.7–4.3.7f).
113-glyph v1 repertoire, FABRIC-0.md 4.3.6–4.3.6g) and TrueType (`TTF-TEXT`,
proportional spacing via real `hmtx` advance widths, FABRIC-0.md 4.3.7–4.3.7f).
Neither is required for the REPL text itself, though — see the VT100 finding
below.
- **The REPL's on-screen text already renders independently of both of the
@@ -360,7 +468,7 @@ ok 1 2 + .
3 ok
```
(via a real keypress on all three architectures, same live-keypress
verification standard FABRIC.md 4.3.5f already established — not a
verification standard FABRIC-0.md 4.3.5f already established — not a
serial-injected synthetic test, though serial injection must still work
identically afterward.)
@@ -438,7 +546,7 @@ LithosAnanke is successful when:
1. **M7 Parity** — VM dictionary hash reproducible across boots
2. **M7.1 Capsules** — Birth protocol enforced, provenance logged
3. ~~**M8 REPL** — Interactive Forth at bare metal~~ — superseded, this criterion is now met
via Stadium's Console fabric work (`FABRIC.md` §25.5 item 4.4), not a standalone M8; see
via Stadium's Console fabric work (`FABRIC-0.md` §25.5 item 4.4), not a standalone M8; see
the OBSOLETE banner above Phase 4
4. **M9 Persistence** — State survives reboot
docs/working/architecture/DOE-LIBRARY-HOWTO-20260819.md
+1 -1
View File
@@ -27,7 +27,7 @@ What actually exists, as of 2026-08-19:
|-----------|------|--------------|---------------|
| Word-level DoE (**this HOWTO**) | `doe.4th` | `DOE` / `EXEC-DOE ( seed n-reps -- )` | A single embedded arithmetic workload (`DOE-WORK`), run across the 16 L8 factor configurations, streaming a CSV row per run to serial. Not auto-run anywhere. |
| Compudynamics fleet campaign | `doe-campaign.4th` | `CAMPAIGN` / `SMOKE-CAMPAIGN` / `THREE-VM-CAMPAIGN` | Spawns Hermes/Artemis and drives real `VM-EXEC` touches between them to measure fleet heat conservation (`VM-CONSERVED?`). Not auto-run anywhere. |
| Artemis stress campaign | `capsules/artemis/init.4th` | `ART-STRESS-CAMPAIGN` | Runs unconditionally at the bottom of the file, so it fires automatically every time Artemis is born. This is the actual source of the live `[Artemis][HADES][DOE ]` CSV rows visible during every kernel boot — unrelated to either mechanism above, and the subject of FABRIC-2.md's item 4.6 fix. |
| Artemis stress campaign | `capsules/artemis/init.4th` | `ART-STRESS-CAMPAIGN` | Runs unconditionally at the bottom of the file, so it fires automatically every time Artemis is born. This is the actual source of the live `[Artemis][HADES][DOE ]` CSV rows visible during every kernel boot — unrelated to either mechanism above, and the subject of FABRIC-1.md's item 4.6 fix. |
Only the first is a self-contained "package/library" in the sense the
cookbook wants — a capsule you load and call with your own parameters, not
docs/working/architecture/SDK-HOWTO-20260819.md
+2 -2
View File
@@ -4,7 +4,7 @@
# SDK HOWTO — `capsules/sdk.4th`
**Status:** WORKING. Part of the v1.9.0 scoping work (FABRIC-2.md section K).
**Status:** WORKING. Part of the v1.9.0 scoping work (FABRIC-1.md section K).
Loads the two cookbook capsules (turtle graphics, DoE library) and adds an
`SDK` vocabulary entry point plus `FENCE` protection on top of them.
@@ -54,7 +54,7 @@ word wrongly destroyed every other word back to the fence too; forgetting
an older word (which correctly cascades to remove newer words, per
FORTH-79 semantics) crashed with a SIGSEGV — a use-after-free in the
dictionary relink logic. Found and fixed as part of this work; full
root-cause writeup in FABRIC-2.md section K. Three POST cases were added to
root-cause writeup in FABRIC-1.md section K. Three POST cases were added to
`dictionary_manipulation_words_test.c` (Module 14) alongside `FORGET`'s
own, including the exact regression scenario, so it can't silently return.
docs/working/architecture/TURTLE-GRAPHICS-HOWTO-20260819.md
+1 -1
View File
@@ -144,7 +144,7 @@ rather than a `POLYGON` call with `n=5`.
documented in `DOE-LIBRARY-HOWTO-20260819.md`) — it carried a stale
`TEMP: ... revert once that run is done` comment for a verification
run that had already closed. Reverted to disabled, matching the
file's own note (FABRIC-2.md section K/L).
file's own note (FABRIC-1.md section K/L).
- The kernel's heartbeat CSV logging (`[HADES][DOE ]` rows) draws to
the *same* console surface `PLOT` draws pixels to, and scrolls
continuously — anything drawn gets visually overwritten within a
evidence/aarch64/qemu-screenshot-20260905-013835-i9-after-keypress-phantom-linebreak.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.5 KiB

evidence/aarch64/qemu-screenshot-20260905-013835-i9-before-keypress.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.2 KiB

experiments/bare_metal/analysis/report/stadium_relaunch_report.tex
+2 -2
View File
@@ -87,7 +87,7 @@ inactive.
\section{Context}
Item 4.6 (Section H, \texttt{FABRIC-2.md}) migrated Artemis's block-heat
Item 4.6 (Section H, \texttt{FABRIC-1.md}) migrated Artemis's block-heat
tracking onto Stadium-resident cells, fixing a quota-grant-ordering bug
that had been causing her boot-time stress self-test to fail 100\% of the
time on all three architectures. With that item closed, the next open
@@ -415,7 +415,7 @@ Sum Sq of precisely zero on the one field that does vary.
\texttt{ACL.4th} is not self-activated in this repository's default
\texttt{init.4th} (\verb|\ S" ACL.4th" EXEC|, commented out); every cell in
this campaign, like every other boot recorded in \texttt{FABRIC-2.md}, ran
this campaign, like every other boot recorded in \texttt{FABRIC-1.md}, ran
with ACL inactive. This report validates the campaign mechanism and its
determinism properties; it does not produce an ACL-RWT overhead number.
Reproducing the original campaign's \texttt{+0.0054\%--+0.0088\%} overhead
experiments/bare_metal/runs/doe-aarch64-20260902-170928.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260902-172210.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-055405.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-060019.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-060712.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-061306.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-062340.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-063526.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-064158.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-071534.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-072038.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-072611.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-073217.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-074127.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-112010.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-113443.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-114945.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-143320.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260903-145147.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-073852.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-080015.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-082459.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-092947.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-101430.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-103835.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-105725.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-111845.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-113320.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-114910.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-130112.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-133140.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-135352.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-140833.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-143821.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-222027.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-224329.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-230146.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-231112.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-232737.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260904-235007.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260905-000232.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260905-001326.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260905-005123.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260905-010234.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260905-012155.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260905-013102.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260905-013835.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260905-020248.csv
View File
experiments/bare_metal/runs/doe-aarch64-20260905-021551.csv
View File

Some files were not shown because too many files have changed in this diff Show More