rajamesandClaude Opus 5.5
c95191736e
Each board has one serial line that is its console, the lowest common denominator beside the screen and keyboard. Its address was QEMU's, fixed: on a Raspberry Pi 5 the aarch64 one is ordinary RAM, written to with every character printed; on a Milk-V Mars the riscv64 one is the board's UART with registers four bytes apart, and the UEFI loader would have waited for ever on its first character; on a PC with no COM1 the prompt read 0xFF for ever. console_attach_serial(), called before anything prints: COM1 if a UART answers there; elsewhere the UART that /chosen/stdout-path names (fdt_uart.c: alias, path, the address carried up through each bus's ranges, reg-shift and reg-io-width); with no devicetree, QEMU's. A devicetree that names no usable console gives no line, not a guess. A line that does not come ready is given up, not waited on. The riscv64 loader's early serial does the same. tools/fdt_uart_test.c, run by hand, 19 checks plain and under the sanitizers: devicetrees shaped like the Mars's, the Pi 5's and QEMU's, what must find nothing, and a block cut short at every length; and the Pi 5's real devicetree gives a PL011 at 0x107d001000. Acceptance, one QEMU at a time: v3 on amd64 (logs/20261013-204436), aarch64 (-204803) and riscv64 (-205001) to the zuse prompt, no unknown word, hash 0x08873e0f44b7cb2a on all three as before. -204600 is an aarch64 run during which the disk images were restored under it by a script that had been refused a second QEMU; it passed and is kept, and was run again. v4 on the three ISAs (-211149, -211444, -211857): POST 538 of 538, dict_hash 0xe5a57f3eb72ff94a, the typed session unchanged. The Mars image through OpenSBI and U-Boot in QEMU took its line and its interrupt controller from the devicetree and passed POST. Found on the way and not mended (boards/BRINGUP.md 1.6): built with EMERGENCY_CONSOLE_ENABLED=1 the prompt floods with empty lines. -210442 shows it; the commit before this does the same. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
include/starkernel/
Headers for LithosAnanke, the bare-metal UEFI kernel (src/starkernel/).
Built only via Makefile.starkernel; gated by __STARKERNEL__ when shared
with hosted code.
uefi.h— UEFI protocol/type definitions consumed by the loader.elf64.h,elf_loader.h— ELF64 parsing and kernel-image loading.boot_info_offsets.h— struct-offset constants shared between the assembly bootstrap and the C boot path.arch.h,apic.h,timer.h— architecture init, APIC interrupt controller, timer (TSC/HPET/APIC, 100 Hz heartbeat).console.h,framebuffer.h,vt100.h— UART 16550 console, framebuffer driver, and VT100 terminal emulation over the framebuffer.pmm.h,vmm.h,kmalloc.h— physical memory manager (bitmap allocator), 4-level x86_64 paging, kernel heap allocator.pci.h,virtio_blk.h— PCI enumeration and the VirtIO block device driver (disk backend for the kernel block subsystem).capsule.h,capsule_birth.h,capsule_loader.h,capsule_run.h,capsule_vm_physics.h,capsule_generated.h— capsule system types, birth protocol, physics-runtime capsule bindings, and the build-time- generated capsule directory (seetools/mkcapsule.c).kernel_args.h,cmdline.h— boot-time kernel argument parsing (starforth.cfg/ command line).repl.h— kernel REPL.log.h,doe_log.h— kernel logging and DoE metrics logging.q48_16.h— kernel-build copy of Q48.16 fixed-point arithmetic.xxhash64.h— content-addressing hash used for capsule IDs.hal_memory.h— hardware-abstraction-layer memory interface.
Subdirectories:
hal/— top-level hardware-abstraction-layer interface.vm/— kernel VM subsystem headers (capsule arena, parity logging, bootstrap wiring).freestanding/— minimal libc-shim headers (assert.h,ctype.h,errno.h,inttypes.h,math.h,sched.h,signal.h,stdio.h,stdlib.h,string.h,time.h,sys/time.h,sys/types.h) for building shared VM code in the freestanding kernel environment, where no real libc is available.