Record trajectory beyond v2.5.0: Zynq FPGA next, after a "coloring in" hardening phase

The next big milestone after the three-board bare-metal cut (v2.5.0) is
transferring the battle-tested amd64/aarch64/riscv64 story to a Zynq (AMD
Xilinx) FPGA SoC — configurable silicon with soft/hard CPU cores, PL fabric,
and a non-standard memory map, a genuinely larger step than any prior board
(expected on a new even-major line). Between v2.5.0 and the Zynq sits a
"coloring in" period: hardening that thickens the shape of what exists rather
than adding silicon (USB BOT/xHCI + block robustness, live-entropy and
Zuse-cert hardening on real ASICs, SMP/multi-core + IRQ routing from the HAL
notes, driver breadth) so the FPGA carries a production-honest shape forward.

Authoritative form in ROADMAP.md "Beyond v2.5.0"; FABRIC-3.md tracks the same
horizon in the post-release section and re-points G.6's Next at the
v2.2.0/v2.4.0/v2.5.0 cadence.
This commit is contained in:
Robert Allan James
2026-08-29 10:28:22 -04:00
parent 25276ae359
commit 8e94522d10
4 changed files with 36 additions and 4 deletions
+14 -3
View File
@@ -3470,9 +3470,10 @@ this is what makes the image "as generic as possible."
(READ CAPACITY10 → MSC device ready → READ10 CSW PASS). This mirrors the real SER5 flow: (READ CAPACITY10 → MSC device ready → READ10 CSW PASS). This mirrors the real SER5 flow:
firmware boots the thumbdrive's ESP, and the OS's own storage rides the same USB BOT/xHCI firmware boots the thumbdrive's ESP, and the OS's own storage rides the same USB BOT/xHCI
path. Works for all three arches via the arch-mapped EFI boot name. path. Works for all three arches via the arch-mapped EFI boot name.
- **Next (v2.0.1):** G.4 requires real entropy on the SER5 — amd64 **RDRAND** backend behind - **Next (v2.0.1→v2.2.0):** G.5 real-board proof on the SER5 (in hand) — boot the thumbdrive
`rng_get_bytes()` (QEMU-verifiable: `qemu64` exposes RDRAND), then flashing this image to image, live RDRAND entropy, real Zuse mint on a second stick — then extend per arch to
a physical stick and the G.5 real-board boot attempt. v2.4.0 (RasPi 5) and v2.5.0 (Milk-V). Authoritative cadence in `ROADMAP.md`
"Board-by-board hardware rollout".
--- ---
@@ -3492,3 +3493,13 @@ the punch lists above explicitly delimit what is excluded from each milestone:
- Dirty-event granularity (1.11, blocked on 4.3) and the §17.4 framebuffer heat/decay design. - Dirty-event granularity (1.11, blocked on 4.3) and the §17.4 framebuffer heat/decay design.
- Re-run the DoE on the new substrate (§A 5.1). - Re-run the DoE on the new substrate (§A 5.1).
- First-touch allocation first-call-free. - First-touch allocation first-call-free.
**Beyond v2.5.0 — Zynq FPGA, then a coloring-in period, decided 2026-08-29.** The next big
milestone after the three-board bare-metal cut (v2.5.0) is transferring the story to a
**Zynq FPGA** (configurable silicon — soft/hard cores, PL fabric, non-standard memory map) —
a genuinely larger step than any prior board, expected on a new even-major line. Between
v2.5.0 and starting the Zynq sits a **"coloring in"** hardening phase: making v2.5.0's
real-hardware story production-honest (USB BOT/xHCI + block robustness; live-entropy and
Zuse-cert hardening on real ASICs; SMP/multi-core + IRQ routing from the HAL notes; driver
breadth) so the FPGA carries a thickened, not thin, shape forward. Full form in
`ROADMAP.md` "Beyond v2.5.0 — Zynq FPGA is the next big milestone".
+1 -1
View File
@@ -1,5 +1,5 @@
# Capsule Block Manifest — Auto-generated # Capsule Block Manifest — Auto-generated
<!-- Generated by mkcapsule --manifest 2026-08-29T14:16:48Z --> <!-- Generated by mkcapsule --manifest 2026-08-29T14:22:56Z -->
<!-- DO NOT EDIT — re-run mkcapsule --manifest to refresh. --> <!-- DO NOT EDIT — re-run mkcapsule --manifest to refresh. -->
<!-- Hand-written justifications and immutability notes live --> <!-- Hand-written justifications and immutability notes live -->
<!-- in MANIFEST.md alongside this auto-generated index. --> <!-- in MANIFEST.md alongside this auto-generated index. -->
BIN
View File
Binary file not shown.
+21
View File
@@ -47,6 +47,27 @@ not a separate dev line):
- **v2.5.0 — all three bare metal.** Adds Milk-V (riscv64) to the above; the Zkr (RNDR) - **v2.5.0 — all three bare metal.** Adds Milk-V (riscv64) to the above; the Zkr (RNDR)
backend live. This is the full "same story on all three arches on real silicon" cut. backend live. This is the full "same story on all three arches on real silicon" cut.
**Beyond v2.5.0 — Zynq FPGA is the next big milestone, after a hardening phase.** Once the
three general-purpose boards close, the next major transfer is to a **Zynq (AMD Xilinx)
FPGA** SoC — the step where the battle-tested amd64/aarch64/riscv64 story rides on
configurable silicon. That is a genuinely bigger milestone than any single prior board: an
FPGA demands its platform be carried forward rather than ported with trivial
architecture-delta work, and it reshapes the hardware story (soft/hard CPU cores, PL fabric,
non-standard memory map, custom peripherals). Expect a new even-major line for it once the
coloring-in period below lands.
**Before the FPGA — "coloring in", decided 2026-08-29.** The period between the all-three
bare-metal cut (v2.5.0) and starting the Zynq is finishing/hardening work that thickens the
shape of what already exists rather than adding new silicon. This is not idle time; it is
the point where v2.5.0's real-hardware story is made production-honest before the FPGA asks
to carry it further. Concrete items to define during it (draft scope, to be firmed at v2.5.0
close): Zynq-preflight robustness of the USB BOT/xHCI and block paths; live-entropy and
Zuse-cert hardening on the three real boards; SMP/multi-core bring-up and IRQ routing on real
ASICs (parked in the HAL notes); driver set expansion beyond the three boards before
committing an FPGA port; and whatever v2.5.0's real-board validation surfaces. As boards
land and the v2.5.0 gates close, this list is edited down to the concrete coloring-in punch
list, and the Zynq becomes the even-major target after it.
QEMU remains the zero-degradation reference on every line; each `X.Y.0` must reproduce the QEMU remains the zero-degradation reference on every line; each `X.Y.0` must reproduce the
QEMU acceptance story (`POST 1012/0/0` + `ok>`, block-fence Zuse true, backend entropy QEMU acceptance story (`POST 1012/0/0` + `ok>`, block-fence Zuse true, backend entropy
non-deterministic) on its board before it closes. non-deterministic) on its board before it closes.