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

FABRIC.md: check off 4.4c/4.4d/4.4e/4.4f, root-cause and reframe 4.4g

Browse Source 
Three-arch acceptance boot (amd64/aarch64/riscv64) clean, all reaching
[Hera] ok>, plus amd64 screendump evidence for each item -- checking off
4.4c (console_fb_init wiring), 4.4d ([VMName] prefix reaching the
framebuffer), 4.4e (\r/\n fix), and 4.4f (glyph-flip fix, previous commit).
Screendump verification itself stays amd64-only pending future
aarch64/riscv64 screendump tooling; Captain Bob accepted that gap as
non-blocking for these checkboxes.

4.4g reframed from "anomaly, not root-caused" to a design decision: traced
the missing hundreds of lines of boot output to console_fb_init() running
after capsule_birth_mama() (which births the whole Tripod fleet and their
self-tests) rather than before it, so that output is serial-only by
construction -- not a scroll/CSI-parser bug. Left unchecked pending a call
on whether to reorder console_fb_init() earlier in boot.

Also commits routine artifacts from this session's three-arch runs:
capsules/BLOCK_MAP.md (regenerated manifest), disk/artemis.img (Artemis
writes on every boot), DOE CSVs, and the corresponding QEMU serial logs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-08-11 09:03:31 -04:00
co-authored by Claude Sonnet 5
parent da88a9a546
commit 7ee498705e
14 changed files with 73054 additions and 130 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC.md
+66 -42
View File
@@ -5070,7 +5070,7 @@ document and committing that amendment as its own item.*
> color reaches the screen* — those are orthogonal, confirmed by reading the call chain
> rather than assumed.
- [ ] **4.4c — Wire `console_fb_init()` into the boot path.** Found while verifying 4.4d
- [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
@@ -5096,15 +5096,18 @@ document and committing that amendment as its own item.*
three-arch QEMU boot + logs per CLAUDE.md.
*Refs:* §27.8.
> **amd64 mechanism confirmed 2026-08-11**, three-arch still pending:
> **Done 2026-08-11.** amd64 screendump:
> [evidence/amd64/qemu-screenshot-20260811-081837-pre-4.4e-fix.png](evidence/amd64/qemu-screenshot-20260811-081837-pre-4.4e-fix.png)
> shows real boot/REPL text on the framebuffer for the first time (not just the corner
> blocks) — the fix's core mechanism works. Not marked done: verifying this screendump
> surfaced three further bugs, tracked as 4.4e/4.4f/4.4g below, and 4.4c's own *Done when*
> requires a clean three-arch match with the serial log, not yet attempted on
> aarch64/riscv64.
> blocks) — the fix's core mechanism works, confirmed further legible by the 4.4f fix
> (see below). Three-arch serial boot clean (`logs/20260811-084941/amd64/`,
> `logs/20260811-085022/aarch64/`, `logs/20260811-085119/riscv64/`, all reaching
> `[Hera] ok>`). Screendump verification itself remains amd64-only — no aarch64/riscv64
> screendump tooling exists yet (Captain Bob's call 2026-08-11: acceptable gap, not a
> blocker for this checkbox; building that tooling is separate future work if wanted).
> Verifying this screendump surfaced three further bugs, tracked as 4.4e/4.4f/4.4g below.
- [ ] **4.4d — Fix: `[VMName]` prefix never reaches the framebuffer.** Depends on 4.4c (the
- [x] **4.4d — Fix: `[VMName]` prefix never reaches the framebuffer.** Depends on 4.4c (the
framebuffer console must be live before this matters). Found while scoping 4.4h, given its
own item per §25.0 rule 3 rather than folded in silently. `console.c`'s
`emit_prefix()` (called from `console_putc()` at line-start when `g_active_vm_name` is set)
@@ -5121,13 +5124,11 @@ document and committing that amendment as its own item.*
logs per CLAUDE.md.
*Refs:* §27.8.
> **amd64 mechanism confirmed 2026-08-11**, three-arch still pending: same evidence as
> 4.4c — [evidence/amd64/qemu-screenshot-20260811-081837-pre-4.4e-fix.png](evidence/amd64/qemu-screenshot-20260811-081837-pre-4.4e-fix.png)
> shows `[Hera] ok>` genuinely on screen, not just in the serial log. Not marked done for
> the same reason as 4.4c: three-arch not yet attempted, and 4.4e/4.4f/4.4g were found
> verifying this same screendump.
> **Done 2026-08-11.** Same evidence and three-arch serial-boot basis as 4.4c:
> [evidence/amd64/qemu-screenshot-20260811-081837-pre-4.4e-fix.png](evidence/amd64/qemu-screenshot-20260811-081837-pre-4.4e-fix.png)
> shows `[Hera] ok>` genuinely on screen, not just in the serial log.
- [ ] **4.4e — Fix: `console_putc()` forwards `\n` to `vt100_putc()` without `\r`, corrupting
- [x] **4.4e — Fix: `console_putc()` forwards `\n` to `vt100_putc()` without `\r`, corrupting
line starts.** Found while verifying 4.4c/4.4d by screendump — code is pre-existing, not
introduced by either item, just invisible until 4.4c turned the framebuffer console on.
`console.c`'s `raw_putc()` auto-injects `\r` before `\n` for the serial path (line
@@ -5143,48 +5144,71 @@ document and committing that amendment as its own item.*
three-arch QEMU boot + logs per CLAUDE.md.
*Refs:* §27.8.
> **Fix applied and amd64-confirmed 2026-08-11**, three-arch still pending:
> **Done 2026-08-11.** amd64 screendump:
> [evidence/amd64/qemu-screenshot-20260811-082822-post-4.4e-fix.png](evidence/amd64/qemu-screenshot-20260811-082822-post-4.4e-fix.png)
> shows every line starting at column 0, compared against the pre-fix screendump above
> where lines started at scattered x-positions. 4.4f (glyph flip) and 4.4g (missing lines)
> are both still present, unchanged, in this same screendump — confirming they are
> independent bugs, not caused by the `\r`/`\n` issue. Not marked done: three-arch not yet
> attempted.
> independent bugs, not caused by the `\r`/`\n` issue. Three-arch serial boot clean, same
> basis and same logs as 4.4c.
- [ ] **4.4f — Bug, not root-caused: character glyphs render vertically flipped on the
framebuffer.** Found while verifying 4.4c/4.4d by screendump. `[Hera] ok>` is legible in
content and position but every glyph appears upside-down under 6× zoom. Not yet traced to
a call site — candidate location is the glyph row-blit loop in `font_8x16.c` /
`fb_draw_glyph()`, unverified.
- [x] **4.4f — Fix: character glyphs rendered vertically flipped on the framebuffer.** Found
while verifying 4.4c/4.4d by screendump. `[Hera] ok>` was legible in content and position
but every glyph appeared upside-down under 6× zoom.
**Root cause:** `font_8x16_data` (font_8x16.c) stores each glyph's 16 scanline bytes
bottom-to-top, not top-to-bottom, confirmed by hand-decoding two glyphs' raw bytes —
`'A'` (0x41) reads as a shape converging to a point at the *bottom* unless the row order
is reversed, at which point it becomes the textbook capital A (narrow apex, crossbar,
splayed feet); `'T'` (0x54) reads as a bar *under* a stem unless reversed. `fb_draw_glyph()`
(framebuffer.c:186-192) mapped glyph data row 0 to the top pixel row
(`py + row*scale`), assuming top-to-bottom storage — wrong for this table.
**Fix:** flip the row-to-pixel mapping in `fb_draw_glyph()` to
`py + (15 - row) * scale`, leaving the 4096-byte font table itself untouched.
*Done when:* root cause identified and three-arch screendump shows glyphs in correct
orientation; three-arch QEMU boot + logs per CLAUDE.md.
*Refs:* §27.8.
> **Evidence, amd64, 2026-08-11:**
> [evidence/amd64/qemu-screenshot-20260811-082822-post-4.4e-fix.png](evidence/amd64/qemu-screenshot-20260811-082822-post-4.4e-fix.png)
> — zoom in on `[Hera] ok>`; every glyph reads upside-down. Confirmed present both before
> and after the 4.4e fix, so it's independent of the `\r`/`\n` issue.
> **Done 2026-08-11.**
> [evidence/amd64/qemu-screenshot-20260811-084630-4.4f-fix-legible.png](evidence/amd64/qemu-screenshot-20260811-084630-4.4f-fix-legible.png)
> — `[Hera] Heartbeat: ...`, `[Hera] LithosAnanke v1.5.4`, `[Hera] ok>` all legible in
> correct orientation, compared against the upside-down glyphs in the pre-fix screendump
> linked from 4.4d/4.4e above. Three-arch serial boot clean, same basis as 4.4c.
> Screendump verification remains amd64-only, same accepted gap as 4.4c/4.4d/4.4e.
- [ ] **4.4g — Anomaly, not root-caused: hundreds of lines of boot output never reach the
framebuffer.** Found while verifying 4.4c/4.4d by screendump. amd64 at 1280×800/scale=1
has room for 50 character rows, but the captured screendump shows content in only ~6-8
rows near the top; the rest of the screen is untouched background despite `log_message()`
(vm/host/shim.c:283-331) routing ANSI-colored HADES/ECW trace output plus Stadium/
self-test text through `console_puts()` → `console_putc()` → `vt100_putc()` hundreds of
times during boot. `fb_scroll_rows()` (framebuffer.c:257) was read and appears
structurally sound on inspection — not ruled out, just not implicated by inspection alone.
Not caused by 4.4e's cursor-column bug: the anomaly is confirmed unchanged in the
post-4.4e-fix screendump, same row count, same blank region. Possibly the CSI/SGR parser's
handling of the heavy stream of embedded color-code escapes; not confirmed.
*Done when:* root cause identified and three-arch screendump shows the full boot/REPL
transcript visibly scrolled/filled on the framebuffer, matching the serial log;
three-arch QEMU boot + logs per CLAUDE.md.
- [ ] **4.4g — Design decision needed: `console_fb_init()` runs after capsule birth, not
before, so almost all boot output is framebuffer-invisible by construction.** Found while
verifying 4.4c/4.4d by screendump — initially logged as an unexplained rendering anomaly
(hundreds of lines of `log_message()`-driven HADES/ECW/Stadium/self-test output missing
from a screen with room for 50 character rows), but root-caused 2026-08-11, and it isn't a
rendering bug at all.
**Root cause:** `capsule_birth_mama()` (kernel_main.c:622) runs `init.4th`, which births
the whole Tripod fleet (Hermes ×2, Artemis) and their self-tests — this single C call is
where essentially all of `log_message()`'s HADES/ECW trace and the Stadium/self-test output
originates, synchronously, inside FORTH interpretation. `console_fb_init()` doesn't run
until kernel_main.c:852, well after that call returns. So that entire block of output is
serial-only by construction, the same structural reason M1–M6 output is serial-only —
just far larger in extent than originally scoped (this item's initial framing wrongly
assumed "boot output" meant only the pre-VM M1–M6 messages). Only the small tail after
line 852 — heartbeat summary, version banner, REPL banner, `ok>` — ever reaches the
framebuffer, and that tail is legible and correctly scrolled once 4.4c/4.4e/4.4f are
applied; there is no scroll or CSI-parser defect. `fb_scroll_rows()` (framebuffer.c:257)
was read during the original investigation and is fine.
**Open question, not decided:** does 4.4c's stated goal ("every character reaching [the
serial console] reaches the [framebuffer] other") require moving `console_fb_init()`
earlier — e.g. before `capsule_birth_mama()` — so the fleet-birth/self-test transcript
becomes framebuffer-visible too? That's a boot-sequencing change with its own
considerations (framebuffer must still be probed/available at that point; scroll volume
during birth would be substantial), not something to decide unprompted.
*Done when:* Captain Bob decides whether to reorder `console_fb_init()` relative to
capsule birth; if yes, implement and three-arch-verify; if no, close this item as
"working as designed" with this root-cause note as the record.
*Refs:* §27.8.
> **Evidence, amd64, 2026-08-11:**
> [evidence/amd64/qemu-screenshot-20260811-082822-post-4.4e-fix.png](evidence/amd64/qemu-screenshot-20260811-082822-post-4.4e-fix.png)
> — compare the ~780px of untouched black background below the visible text against the
> 50-row capacity computed from 1280×800 at scale=1.
> [evidence/amd64/qemu-screenshot-20260811-084630-4.4f-fix-legible.png](evidence/amd64/qemu-screenshot-20260811-084630-4.4f-fix-legible.png)
> — the visible tail (Heartbeat/version/REPL banner/`ok>`) is exactly, and only, the
> `console_putc()` calls issued after kernel_main.c:852; everything above that line in the
> serial log predates the framebuffer console's existence.
- [ ] **4.4h — Apply color to the prompt.** Depends on 4.4d (coloring a bracket that isn't
drawn on screen accomplishes nothing). Per 4.4b's finding: either an independent