rajamesandJunie
a8b70e88d3
Source tree reorganization: - Move StarForth v3 engine to v3/ (src/, include/, Makefile) - Move kernel to kernel/ (src/, include/, linker/, Makefile) - Create v4/ skeleton for F18-ISA golden model (DECOMPOSITION.md, JUSTIFICATION.md) - Move FABRIC-0..4.md to docs/fabric/ - Move ONTOLOGY.md and ROADMAP.md to docs/ Board infrastructure: - Add boards/ser5/, boards/raspi/, boards/milkv/, boards/zynq7020/ - Each board has board.mk (ISA, CPU flags, boot recipe) and README.md - Root Makefile becomes thin dispatcher: boot_image, all, clean, docs take TARGET - make boot_image TARGET=SER5|RASPI|MILKV builds one GPT/MBR image per board - ZYNQ7020 target exists but stops with clear error (ARMv7 port not built yet) - scripts/mkdiskimage.sh builds disk images for all boards Docs pipeline: - docs/book/ with LaTeX master (main.tex) and Makefile - pandoc converts Markdown to LaTeX at build time - Two Lua filters: table-widths.lua (wide tables wrap), code-breaks.lua (inline code breaks) - make docs builds single PDF (754 pages, 0 missing characters) - make docs TARGET=<board> adds board appendix - build/docs/<book|board>/meta.tex stamps git commit into PDF Bug fixes: - 42 include paths that only worked by accident now use correct relative paths - clang-18 hardcode replaced with configurable CC variable (fixed aarch64 build) - Pi 5: kernel_2712.img linked at 0x80000, .bss zeroed, memory reserved - Doxyfile, .clang-tidy, README.md, Kconfig paths updated Verified: - Hosted v3 build passes 1012 tests, 0 failures - SER5 image boots in QEMU (OVMF), POST passes, K exact (65536 = Q48_ONE) - Milk-V image boots in QEMU (OpenSBI + U-Boot + bootefi), POST passes - make clean TARGET=<board> removes only that board and its ISA objects - make all builds all boards, hosted v3, and docs in one run Co-authored-by: Junie <junie@jetbrains.com>
70 lines
3.9 KiB
Plaintext
70 lines
3.9 KiB
Plaintext
# LithosAnanke native (non-UEFI) boot config for Raspberry Pi 5 (BCM2712).
|
|
# FABRIC-3.md §IV.3 item 6 -- see that section's own doc comment for the
|
|
# research trail behind each line (confirmed against raspberrypi.com's
|
|
# current config.txt reference and a real, working Pi 5 bare-metal
|
|
# project's own checked-in config.txt, not assumed from general Pi
|
|
# knowledge).
|
|
|
|
# Load our own kernel image directly -- no UEFI, no Linux. kernel_2712.img
|
|
# is the real filename Pi 5/500/CM5 firmware looks for first (its own
|
|
# 16K-page-size build); naming our own image this exactly, rather than
|
|
# falling back to kernel8.img, removes any ambiguity about which file the
|
|
# firmware picks up.
|
|
kernel=kernel_2712.img
|
|
|
|
# Pin the load address to the one the image is linked at
|
|
# (kernel/linker/starkernel-native-rpi5.ld). Pi 5 firmware's own default
|
|
# for kernel_2712.img is 0x200000, not the classic 0x80000 -- leaving it
|
|
# implicit would load a 0x80000-linked flat image 1.5 MiB away from where
|
|
# every absolute address in it points.
|
|
kernel_address=0x80000
|
|
|
|
# Disable the firmware's Linux-compatible-image sanity check. Without
|
|
# this, official docs describe it as checking for "a compatible Device
|
|
# Tree file before attempting to boot" and warn that "older non-compatible
|
|
# kernels would be loaded and then hang" -- documented specifically as the
|
|
# bare-metal-development escape hatch. One real working Pi 5 bare-metal
|
|
# project's own config.txt does NOT set this and still boots, so it may
|
|
# not be strictly required for every non-Linux image; kept here anyway
|
|
# since the official doc names this exact use case and there is no
|
|
# hardware in hand yet to verify which behavior is actually gated.
|
|
os_check=0
|
|
|
|
# Pin the exact devicetree explicitly rather than relying on the
|
|
# firmware's own board-revision auto-selection (which would also resolve
|
|
# to this file on real Pi 5 hardware, per general config.txt convention --
|
|
# explicit is certain, not just probably-correct).
|
|
device_tree=bcm2712-rpi-5-b.dtb
|
|
|
|
# Enable the dedicated debug UART (Pi 5's own JST connector, not the GPIO
|
|
# 14/15 header pins). Not because serial capture hardware is set up for
|
|
# this bring-up (that decision is HDMI-only, FABRIC-3.md §IV) -- this is
|
|
# a firmware-side switch that costs nothing when nothing is listening, and
|
|
# it is the only diagnostic channel that survives a framebuffer failure.
|
|
# rpi5_uart_base() (rpi5_dtb.c) already exists and is currently uncalled;
|
|
# this is the hook a UART-based fallback console would use if the mailbox
|
|
# framebuffer driver's two documented unverified details turn out wrong on
|
|
# real hardware.
|
|
enable_uart=1
|
|
|
|
# Deliberately NOT set, researched but not included this pass:
|
|
# dtoverlay=uart0 -- GPIO 14/15 header UART; needs a USB-serial
|
|
# adapter this bring-up doesn't have (HDMI-only
|
|
# decision). enable_uart=1 above covers the JST
|
|
# debug UART instead, which needs no extra cable.
|
|
# dtparam=pciex1 -- one real Pi 5 bare-metal project's own config.txt
|
|
# comments this as "Required for RP1 access", which
|
|
# would be surprising (RP1 is always-on in stock Pi
|
|
# 5 boots) and is community-reported, not confirmed
|
|
# against official docs. Not needed for this boot
|
|
# (no RP1 access yet -- FABRIC-3.md §IV.3 item 5 is
|
|
# still re-scoped, not implemented). Revisit if that
|
|
# item's own real Broadcom-indirect PCIe work needs
|
|
# it.
|
|
# arm_64bit=1 -- researched and dropped: official docs state
|
|
# "Models that only support a 64-bit kernel ignore
|
|
# this flag" -- inert on Pi 5, not wrong to include,
|
|
# just meaningless. The original item 6 wording
|
|
# named this; corrected here rather than carried
|
|
# forward.
|