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>
boards/
One directory per physical target. make boot_image TARGET=<NAME> (repo root) maps the
name to a directory here, reads its board.mk, and builds the single file that goes on
that board's boot medium into build/boards/<board>/.
| TARGET | Directory | ISA | Boot path | Image |
|---|---|---|---|---|
SER5 |
ser5/ |
amd64 | UEFI firmware, removable-media path | GPT + FAT32 ESP: EFI/BOOT/BOOTX64.EFI |
RASPI |
raspi/ |
aarch64 | Pi 5 EEPROM firmware, native | MBR + FAT32: config.txt, kernel_2712.img, bcm2712-rpi-5-b.dtb |
MILKV |
milkv/ |
riscv64 | SPI-flash U-Boot + OpenSBI, bootefi |
GPT + FAT32 ESP: EFI/BOOT/BOOTRISCV64.EFI |
ZYNQ7020 |
zynq7020/ |
armv7 | BootROM, BOOT.BIN, U-Boot |
not yet: needs kernel/src/arch/armv7 |
board.mk sets:
BOARD_DESC: one-line description (make boards)BOARD_ARCH: kernel ISA (kernel/src/arch/<arch>)BOARD_BOOT: image recipe inkernel/Makefile(uefi-esp,rpi-native, ...)BOARD_IMAGE: output file name
Disk images are assembled by scripts/mkdiskimage.sh, which needs no root access and no loop
devices. KERNEL_ARGS="..." is written as starforth.cfg (UEFI boards) or cmdline.txt
(Pi 5, where the firmware copies it into /chosen/bootargs). BOOT_IMAGE_SIZE_MIB sets the
image size; the default is 128.
Hardware status: none of these images has been booted on real silicon from this build. The
SER5 image has been booted in QEMU (q35 + OVMF, from its own disk) through POST. The Pi 5
native path (raspi/README.md) and the JH7110 peripherals have still only been checked by
compiling.