Milestone 243: something to say before kernel_main, and a screen on the boards

[calef]

Lane: milestone/243-no-serial-port, written by an agent; calef's account is the author GitHub shows.

Closes milestone 243's two Outstanding items. 243 is now BUILT.

1. Early boot: bounded, and it cannot be more than bounded

The premise was checked before it was answered, and half of it turned out to be unanswerable rather than unanswered. From ExitBootServices to console::attach_screen there is no console on a serial-less machine: the firmware's is gone by specification, the kernel's is not up, and everything in between (the loader's trampoline, boot.s's 32-bit half, the page tables, the long-mode jump) runs 32-bit with no IDT, so a fault there is a triple fault and a silent reset. No code in that window knows where the screen is.

So it is bounded instead. uefi_loader clears the screen and writes two lines as its final act, after ExitBootServices and before the jump:

nife loader: firmware released, entering the kernel.
If this line is still here, the kernel stopped before its console came up.

Five outcomes are now distinguishable where four shared one black rectangle. The third is the one that did not exist: the firmware never started the stick / the loader refused and said why over ConOut / the kernel never reached its first statement / the kernel armed its console and died after (black) / the boot tour.

Proved rather than reasoned. With a temporary halt in place of the jump, cargo xtask uefi-boot's screendump had ink in exactly the top sixteen pixel rows of a 1280x800 screen and they read those two lines. The painting itself is host-tested in uefi_loader::screen (three tests plus a doctest).

2. aarch64 and riscv64: a screen, through ramfb

x86_64 gets a screen because UEFI already lit one. QEMU's virt boards are entered from -kernel with nothing configured, so there was nothing to discover. ramfb is what they can present, and it inverts the arrangement: the guest owns the pixels and tells the emulator where they are over fw_cfg.

Piece	Where
The fw_cfg wire format, 8 host tests + 2 doctests	crates/firmware_configuration (name provisional)
The register poking, two DMA transactions before arch::mmu::init	kernel/src/drivers/ramfb.rs
The memory and the wiring	kernel/src/screen.rs (provisional), console::peek_screen (provisional)
Painting text	crates/screen_console, unchanged
The gate	cargo xtask screen-boot <arch> (provisional), board_console::screen unchanged

Measured, and both legs run inside script/test:

screen-boot: read 33 non-blank row(s) of the aarch64 tour back off a ramfb, ending
screen-boot:   | nife self-test: 5 of 5 passed
screen-boot: read 47 non-blank row(s) of the riscv64 tour back off a ramfb, ending

The surprise worth reading the diff for: the inversion breaks milestone 400's handover, which maps the screen's physical range into a userspace driver. Right for a display adapter's BAR, a hole for a framebuffer that is the kernel's own .bss. user::boot_screen_terminal now refuses a screen inside the kernel image, checked before the yield so a refusal leaves the kernel still painting. It is a range test rather than a flag, so milestone 157's U-Boot aperture passes it with nothing to remember.

script/shell-check --graphical and --graphical-serial are green, so the one-painter invariant still holds.

Gates, all from this worktree

Gate	Exit
NIFE_CC=… script/lint	0
script/names (refusals unchanged)	0
script/test (all three architectures, plus both new screen-boot legs)	0
script/shell-check, --graphical, --graphical-serial	0, 0, 0
script/bench --check	0
script/icount	0
script/fastpath-footprint	0

This lane took the machine-global nife-dev link, as every gating lane does. It did not run script/roadmap --write; only its own block was edited.

Identified work, with a home

• design/roadmap/proposals/the-boards-screen-under-uefi.md (new). Milestone 441 landed uefi_loader boot files for aarch64 and riscv64 while this lane was running, so those boards now have a firmware stage that has lit a display. The banner could move there, and the loader could hand the kernel a real GOP aperture by synthesising the simple-framebuffer node milestone 157 will read from U-Boot, retiring the ramfb's 1.9 MB of .bss. The second half is a wire format between two boot stages and wants a decision rather than a lane.
• Recorded as BUGS where a reader meets them: the .bss cost, the missing cache maintenance (QEMU-only by construction), the handover refusal, and the fact that the loader's banner is unobservable in a healthy boot.

🤖 Generated with Claude Code

https://claude.ai/code/session_01STu3VeDYnEHem3iKCbzBF2

[calef]

merge-drain: STALLED. #998 is failing cpu matrix (riscv64 across QEMU CPU models) (Milestone 243: something to say before kernel_main, and a screen on the boards)

[calef]

Lane: milestone/243-no-serial-port, written by an agent; calef's account is the author GitHub shows.

The red cpu matrix (riscv64) leg, fixed

It was this lane's wiring, not a CPU model, and it reproduces on rv64 as well as on the four narrow ones.

The bug. cargo() exports NIFE_INITRD pointing at the aarch64 archive, because it is the aarch64 path's helper; every other riscv64 caller in xtask overrides it and says in a comment that it has to. screen_boot did not. The archive it built (initrd_riscv()) was correct; the variable pointed somewhere else.

And I had already been told, an hour before CI was. The first local riscv64 run printed MEASURED BOOT REFUSED: 'progenitor' is not what this kernel image was built against, which is precisely a riscv kernel loading an aarch64 archive, and I read it as noise because the gate's own assertion still passed. The defect had two faces: with the aarch64 archive on disk the boot carried on refused, and in a job that never built one QEMU would not start (could not load ramdisk). That dismissal is written into the block, because it is the reusable part.

Two changes, and they are different kinds of thing.

1. The wiring (98a…): the archive is chosen per architecture at the spawn. Verified by reproducing CI's condition rather than by reasoning: with target/initrd.img moved out of the tree, cargo xtask screen-boot riscv64 exits 0 and reads 45 rows off the screen. The tour also reaches further than it used to, because the progenitor now composes userspace instead of refusing the archive.

2. The screen legs no longer run under --cpu. A cost decision on its own merits, not a way around the failure: the matrix runs the suite five times to narrow the ISA, and nothing here varies with -cpu (byte moves, MMIO stores, integer arithmetic, all of it already executed on that model by the three hundred tests above). script/cpu-matrix's own warning is about dropping a model; no model is dropped, and the leg still runs on every ordinary script/test, --arch riscv64 included.

Local reruns

script/cpu-matrix sifive-u54	0 — and its log mentions screen-boot zero times, so the matrix job runs exactly what it ran before this branch
cargo xtask screen-boot riscv64, with target/initrd.img absent	0, 45 rows
cargo xtask screen-boot aarch64	0, 33 rows
script/lint, script/names	0, 0

On the diagnostic line

Noted in the block and in notes/serial-less-output.md as a shape to copy, since it is what made a red matrix readable without a local re-run:

screen-boot: nothing decodable was ever on the screen (did QEMU get a ramfb and a monitor?)
screen-boot: the tour never reached the SERIAL line either, so this is a boot failure and not a screen one

The second line is a control, not a detail. A screen gate that only reports "the screen was blank" sends the next reader into the framebuffer path, which is where I would have gone and where nothing was wrong. Asserting the same marker on the channel the screen is replacing costs one contains and separates "this milestone's mechanism is broken" from "the machine did not boot". Any gate reading a machine through one channel should do the same.

🤖 Generated with Claude Code

https://claude.ai/code/session_01STu3VeDYnEHem3iKCbzBF2

[calef]

merge-drain: STALLED. #998 has conflicts a person must resolve (Milestone 243: something to say before kernel_main, and a screen on the boards)

[calef]

Lane: milestone/243-no-serial-port, written by an agent; calef's account is the author GitHub shows.

Rebased onto 365's xtask split, and one flake fixed that was not mine

Two things happened after the last comment, and the second is worth reading.

1. Milestone 365 split xtask/src/main.rs into twenty modules

The gate could not be rebased, because the file it was written against stopped existing in that shape. Re-landed rather than replayed, which is why it arrives as one commit instead of three: xtask/src/screen.rs beside uefi.rs whose uefi_boot it is the twin of, the dispatch entry in main.rs, the two suite legs in suite.rs behind the --cpu guard, and the icount exclusions in icount.rs. Nothing changed but where it lives.

2. uefi-boot's tour stage was asserting a race, and the premise behind it was false

Re-verifying after that rebase, uefi-boot went red intermittently: four consecutive runs read 19, 27, 40 and 0 rows. Milestone 400's own BUGS predicted it in those words.

The obvious suspect was my loader banner, so I tested it instead of arguing. With the banner's paint disabled and nothing else changed, the same gate failed two runs in four — worse. Not the cause.

The cause was a premise that was already false when it was written. The marker was boot_ladder::SELF_TEST, chosen "near the end of the boot on purpose" because a 1280x800 screen is 100 character rows and the boot was believed to be longer, so early lines would have scrolled off. Measured, the tour tops out at 98 non-blank rows: nothing scrolls, the banner is on the screen the whole time, and what the marker actually selected for was the last line before the handover's clear — a few hundred milliseconds. The comment describes the flake it was written to prevent.

The marker is now the banner. Five consecutive runs: 52, 68, 78, 84, 89 rows, all green, on the same loaded machine that had been failing one in two.

The total claim is unchanged, and that is the thing to check before accepting any gate that got easier. The screen's job is to prove the pixels — LocateProtocol, byte order, stride, the mapping surviving mmu::init, the glyphs — and any decoded row proves all five. That the boot reached the self-test is asserted separately and unconditionally on the serial transcript a few dozen lines above. Depth is now reported rather than required.

Two things for you, because a lane may not do them.

• This edits milestone 400's gate, not 243's. Flagged rather than done quietly.
• 400's BUGS entry is now stale in its last clause (the one beginning "The tour stage of uefi-boot now has a window"). It needs striking or rewording; I did not touch that block.

Gates, re-run after all of the above

script/test (three architectures, uefi-boot, uefi-test, both screen-boot legs)	0
script/lint, script/names	0, 0
script/cpu-matrix sifive-u54	0, and its log mentions screen-boot zero times
cargo xtask uefi-boot x5 after the marker change	0 x5
cargo xtask screen-boot riscv64 with target/initrd.img absent	0

No leaked QEMU, clean tree, branch on top of main.

🤖 Generated with Claude Code

https://claude.ai/code/session_01STu3VeDYnEHem3iKCbzBF2