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

boards: the amd64 target is PC -- a generic x86-64 UEFI PC, not the SER5

Browse Source 
Captain Bob, 2026-10-14: "change to PC, not SER5. it's not supposed to be
specific, but PC generic."  boards/ser5 -> boards/pc, TARGET=PC,
lithos-pc.img; the image was never specific to one machine (the generic
UEFI/ACPI path, FABRIC-3 III).  The Beelink SER5 stays named where the text
means the unit on the bench (its Secure Boot, BIOS, serial header) and in
the records.  Built: lithos-pc.img, system=v4, with its SBOM.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
rajames
2026-10-14 17:22:32 -04:00
co-authored by Claude Opus 5.5
parent 1ce8576b76
commit 3b49cb15a2
10 changed files with 55 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files
boards/BRINGUP.md
+6 -6
View File
@@ -8,7 +8,7 @@ on the date above; where it comes from a document instead, the document is named
has been booted, its results go in `docs/fabric/FABRIC-3.md` (sections III, IV, V) and its
`README.md` here, and this file is corrected.
The four boards: `SER5` (amd64), `RASPI` (Pi 5, aarch64), `MILKV` (Mars, riscv64), `ZYNQ7020`
The four boards: `PC` (amd64, any x86-64 UEFI PC; the one on the bench is a Beelink SER5 -- the target was named `SER5` until 2026-10-14), `RASPI` (Pi 5, aarch64), `MILKV` (Mars, riscv64), `ZYNQ7020`
(ARMv7, no port yet). See `boards/README.md` for what each image is.
---
@@ -30,7 +30,7 @@ None has been fixed: each needs your word.
| A5 | **Entropy:** RDRAND on amd64 only. aarch64 and riscv64 have virtio-rng alone. | `kernel/src/rng/rng.c` | Pi 5 and Mars print the "no entropy backend available" warning; anything that needs random bytes is refused. Minting needs them. |
| A6 | **Fixed 2026-10-14.** Every board image carries both systems, v3 and v4, and the boot arguments choose: `system=v4` (as built: v4 is the default) or `system=v3` -- one word in `starforth.cfg` on the SER5's and the Mars's stick or card, in `cmdline.txt` on the Pi 5's card. No rebuild to switch. | root `Makefile`, `kernel/Makefile`, `kernel/src/kernel_main.c`, `kernel/src/boot/cmdline.c`; `FABRIC-3.md` XLIII | The SER5 image itself, booted under OVMF: v3 as built, v4 after the one-word edit. The boot says which system runs and why ("System: ..."). |
### 1.2 SER5
### 1.2 PC (the SER5 on the bench)
| # | What | Where | Effect |
|---|---|---|---|
@@ -127,7 +127,7 @@ In this order, each as a design for approval first:
### 3.1 Build
```
make boot_image TARGET=SER5 EMERGENCY_CONSOLE_ENABLED=1
make boot_image TARGET=PC EMERGENCY_CONSOLE_ENABLED=1
make boot_image TARGET=RASPI EMERGENCY_CONSOLE_ENABLED=1
make boot_image TARGET=MILKV EMERGENCY_CONSOLE_ENABLED=1
```
@@ -136,7 +136,7 @@ make boot_image TARGET=MILKV EMERGENCY_CONSOLE_ENABLED=1
objects itself (2026-10-14): make does not see a change of compile flags, and an image
built over old objects booted headless (2026-10-13) or would have lacked v4.
- [ ] The images boot v4. To boot v3 instead: change `system=v4` to `system=v3` in
`starforth.cfg` (SER5, Mars) or `cmdline.txt` (Pi 5) on the medium. The boot prints "System: ..." with the choice.
`starforth.cfg` (PC, Mars) or `cmdline.txt` (Pi 5) on the medium. The boot prints "System: ..." with the choice.
- [ ] Each ends with its image in `build/boards/<board>/`. Record `sha256sum` of each.
- [ ] Confirm the switch took: the image booted in QEMU (3.2) shows a prompt with no
thumbdrive attached. After a clean build it does (tried on `MILKV`).
@@ -149,7 +149,7 @@ make boot_image TARGET=MILKV EMERGENCY_CONSOLE_ENABLED=1
One QEMU at a time. Use a copy of the image: the kernel writes to its disk.
- [ ] **SER5:** q35 with OVMF, the image as the only disk, no `-cdrom`, no virtio disk, no
- [ ] **PC:** q35 with OVMF, the image as the only disk, no `-cdrom`, no virtio disk, no
thumbdrive. This is the machine the README's "booted in QEMU" refers to.
- [ ] **MILKV:** the command in `boards/milkv/README.md` (OpenSBI, U-Boot, `bootefi`).
- [ ] **RASPI:** there is no QEMU model of the Pi 5, but its native path -- raw image, entry
@@ -182,7 +182,7 @@ the one QEMU exercises most closely, and the Pi 5's can be rehearsed only in par
- [ ] `sudo dd if=build/boards/<board>/<image> of=/dev/sdX bs=4M conv=fsync status=progress`
- [ ] Read it back and compare: `sudo cmp -n $(stat -c %s <image>) <image> /dev/sdX`.
### 4.2 SER5
### 4.2 PC (the SER5)
- [ ] Serial, if there is a header: 115200 8N1, logged to a file from before power-on.
- [ ] HDMI and keyboard connected. Stick in a rear port.
boards/README.md
+3 -2
View File
@@ -6,7 +6,7 @@ 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` |
| `PC` | `pc/` | amd64 | UEFI firmware, removable-media path -- any x86-64 PC | 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` |
@@ -24,6 +24,7 @@ devices. `KERNEL_ARGS="..."` is written as `starforth.cfg` (UEFI boards) or `cmd
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
PC image has been booted in QEMU (q35 + OVMF, from its own disk) through POST. (`PC` was named
`SER5` until 2026-10-14, after the first PC on the bench; the image was never specific to it.) The Pi 5
native path (`raspi/README.md`) and the JH7110 peripherals have still only been checked by
compiling.
boards/pc/README.md
+20
View File
@@ -0,0 +1,20 @@
# PC boot media (generic x86-64, UEFI)
`make boot_image TARGET=PC` builds `build/boards/pc/lithos-pc.img`: a GPT disk with one FAT32
EFI System Partition, for any x86-64 PC whose UEFI firmware boots a removable medium. Write it to
a USB stick with `dd`. The partition holds:
- `EFI/BOOT/BOOTX64.EFI`: the amd64 monolithic loader, with the whole kernel embedded. Firmware
finds it through the UEFI removable-media path, so no boot entry has to be created.
- `startup.nsh`: runs the loader if the firmware drops into the UEFI shell.
- `starforth.cfg`: the boot arguments -- `system=v4` as built; change the word to `system=v3` to
boot v3 (and `KERNEL_ARGS="..."` adds to it).
Beside the image, `lithos-pc.spdx` / `.spdx.json`: its SBOM, every file on it with its SHA-256.
Nothing in the image is specific to one machine: it follows the generic UEFI/ACPI path in
FABRIC-3.md §III. Until 2026-10-14 this target was named `SER5`, after the first PC to be brought
up -- a Beelink SER5 (AMD Ryzen), which is still the one on the bench (`boards/BRINGUP.md`).
Status: booted in QEMU (q35 + OVMF, from this image as its own disk): v4 as built, v3 with
`system=v3`. Not yet booted on real hardware.
boards/pc/board.mk
+12
View File
@@ -0,0 +1,12 @@
# boards/pc/board.mk -- a generic PC: x86-64, UEFI firmware, ACPI.
#
# Not one machine: the standards-compliant UEFI path (FABRIC-3.md §III), so
# any x86-64 PC whose firmware boots a UEFI removable medium. (The first to be
# brought up on the bench is a Beelink SER5, an AMD Ryzen mini-PC -- see
# boards/BRINGUP.md.) The monolithic loader embeds the whole kernel, so the
# image is a GPT disk with one FAT32 EFI System Partition holding
# EFI/BOOT/BOOTX64.EFI. Write it to a USB stick with dd.
BOARD_DESC := Generic PC (x86-64, UEFI, ACPI)
BOARD_ARCH := amd64
BOARD_BOOT := uefi-esp
BOARD_IMAGE := lithos-pc.img
boards/ser5/README.md
-14
View File
@@ -1,14 +0,0 @@
# Beelink SER5 boot media
`make boot_image TARGET=SER5` builds `build/boards/ser5/lithos-ser5.img`: a GPT disk with one
FAT32 EFI System Partition. Write it to a USB stick with `dd`. The partition holds:
- `EFI/BOOT/BOOTX64.EFI`: the amd64 monolithic loader, with the whole kernel embedded. Firmware
finds it through the UEFI removable-media path, so no boot entry has to be created.
- `startup.nsh`: runs the loader if the firmware drops into the UEFI shell.
- `starforth.cfg`: only present when `KERNEL_ARGS="..."` is given.
Nothing in the image is SER5-specific. It follows the generic UEFI/ACPI path in FABRIC-3.md §III.
Status: booted in QEMU (q35 + OVMF, from this image as its own disk) through POST, with Stadium
conservation exact (sum 65536 = `Q48_ONE`). Not yet booted on the SER5 itself.
boards/ser5/board.mk
-10
View File
@@ -1,10 +0,0 @@
# boards/ser5/board.mk -- Beelink SER5 (AMD Ryzen, x86-64, UEFI/ACPI).
#
# Generic standards-compliant UEFI path (FABRIC-3.md §III): nothing in the
# image is SER5-specific. The monolithic loader embeds the whole kernel, so
# the image is a GPT disk with one FAT32 EFI System Partition holding
# EFI/BOOT/BOOTX64.EFI. Write it to a USB stick with dd.
BOARD_DESC := Beelink SER5 (AMD Ryzen, x86-64, UEFI)
BOARD_ARCH := amd64
BOARD_BOOT := uefi-esp
BOARD_IMAGE := lithos-ser5.img