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

feat(boards): both systems on every board image, chosen at boot -- system=v3 or system=v4

Browse Source 
boards/BRINGUP.md A6, FABRIC-3 SXLIII (ruled: one image, switch at boot).
A STARFORTH_V4 kernel carries v3 too; system= in the boot arguments
chooses, else the build's default (V4_DEFAULT: 1 for plain STARFORTH_V4
builds as before, 0 for board images).  make boot_image builds both and
always writes starforth.cfg / cmdline.txt with system=v3 first, and cleans
its ISA's objects first -- that clean was removing build/<arch>/SER5, not
the kernel's objects, until fixed here.

Each ISA: v3 by default (hash unchanged), v4 with system=v4 (538/538).
The SER5 image under OVMF: v3 as built, v4 after a one-word edit on it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
rajames
2026-10-14 15:11:47 -04:00
co-authored by Claude Opus 5.5
parent e729c64ba3
commit 1a4b163861
32 changed files with 74479 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/fabric/FABRIC-3.md
+34
View File
@@ -5853,3 +5853,37 @@ hot-plugged onto the second controller all attach, and unplugging one detaches t
`-141953`). Standard acceptance, all three: POST 1052, hash unchanged (`-142120`, `-142237`,
`-142449`); five identities hot-plugged on the first controller, all attached (`-142606`).
## XLIII. Both systems on every board image, chosen at boot (`boards/BRINGUP.md` A6) (2026-10-14)
Captain Bob, 2026-10-13, ruled the boards carry "both, switchable"; asked 2026-10-14 where the
switch is: **at boot, one image** -- a word in the boot configuration, v3 as built.
**Built.**
- `STARFORTH_V4=1` already compiled the v4 engine in; `kernel_main` then ran v4 unconditionally.
Now it runs v4 only if the boot arguments say `system=v4`, or say nothing and the build's
default is v4 (`SK_V4_DEFAULT`, from `kernel/Makefile`'s `V4_DEFAULT`: 1 for a plain
`STARFORTH_V4=1` build, as before, so every v4 QEMU boot and test is unchanged). Otherwise v3,
which is compiled in alongside, runs. A kernel without v4 asked for it says so and runs v3. The
boot prints the choice and why: "System: StarForth v4 (system=v4)", "... (this build's
default)", ...
- `cmdline.c`: `system=v3` / `system=v4` (also `--system=`), a later one winning; anything else is
ignored, as every unknown argument is.
- `make boot_image`: `STARFORTH_V4=1 V4_DEFAULT=0` -- both systems, v3 unless asked -- and the
boot arguments file always written, `system=v3` first: `starforth.cfg` on the ESP (SER5, Mars),
`cmdline.txt` on the Pi 5's card (the firmware hands it over as the devicetree's `bootargs`).
- `make boot_image` also cleans its ISA's kernel objects first: they are shared with `make qemu`
and make does not see changed compile flags. Found doing it: the clean was handed the root's
`TARGET=SER5` and removed `build/amd64/SER5`, nothing -- the first SER5 image carried the v4
engine but a `kernel_main` compiled without it. Now `TARGET=kernel`; all three images checked to
carry both.
**Verified.** Board-style build (both, v3 default), each ISA: no argument -- v3, POST 1052, hash
unchanged; `system=v4` -- v4, `PARITY:V4_POST tests=538 pass=538`, `dict_hash=0xe5a57f3eb72ff94a`
(amd64 `logs/20261014-144027`, `-144141`; aarch64 `-144411`, `-144604`; riscv64 `-144934`,
`-145108`). A plain `STARFORTH_V4=1` build still boots v4 by default (`-145331`); a v3-only kernel
asked for v4 says so and runs v3 (`-145550`). The SER5 image itself, booted from its own disk under
OVMF (`logs/20261014-ser5-image/`): v3 as built; after changing the one word in `starforth.cfg` on
it, v4. The Pi 5 and Mars images: built, their `cmdline.txt` / `starforth.cfg` read back from the
image, both systems found in their kernels; not booted (no QEMU model for either). Standard
acceptance, all three ISAs: unchanged (`-150651`, `-150801`, `-151007`).