aiolabs/bitspire
9
0
Fork 0
Code Issues 52 Pull requests 2 Projects Releases Packages Wiki Activity Actions

feat: Raspberry Pi 4 (aarch64) target #110

Open
padreug wants to merge 12 commits from feat/rpi4-target into feat/rpi5-apex-hal
pull from: feat/rpi4-target
merge into: aiolabs:feat/rpi5-apex-hal
Conversation 0 Commits 12 Files changed 13 +21 -5
1 changed files with 21 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 11cc1b88d6 - Show all commits

fix(rpi4): drop fkms-3d, mainline does full KMS without an overlay

Prev Next 
With the mainline kernel from the previous commit, the device-tree overlay
step fails outright:

  Applying overlay rpi4-cma-overlay
  Applying overlay rpi4-vc4-fkms-v3d-overlay
  libfdt.FdtException: pylibfdt error -1: FDT_ERR_NOTFOUND

nixos-hardware's fkms-3d applies two overlays that patch nodes present in
the Raspberry Pi VENDOR kernel's DTBs and absent from mainline's. Predicted
when the kernel changed; this is it arriving.

It is also the wrong thing to want. "fkms" is FIRMWARE KMS, the older
arrangement where the VideoCore firmware owns the display and Linux drives
it at arm's length. Mainline does full KMS, and mainline's own
bcm2711-rpi-4-b.dtb already describes the hardware: it carries
brcm,bcm2711-vc5 and brcm,2711-v3d nodes, confirmed by decompiling the DTB
with dtc. The vc4 and v3d drivers bind to those directly, no overlay
involved.

So the overlay was not providing capability, it was translating for a
kernel we no longer use.

hardware.deviceTree.overlays is now empty, so there is nothing left for the
overlay builder to fail on. Verified by evaluating the config.

No replacement needed for videoDrivers either. fkms-3d used to set it as a
side effect, but the shared configuration.nix already declares modesetting,
which is correct for full KMS and is what the x86 machines use. Setting it
again here just produced ["modesetting" "modesetting"].

Still unproven on hardware: whether X comes up on vc4 rather than falling
back to a framebuffer. That is the next thing to read out of
/var/log/X.0.log once the machine boots, and it is now a minutes-long
iteration rather than a kernel compile per attempt.
Padreug 2026-09-25 15:45:56 +02:00
commit 11cc1b88d6

26
deploy/nixos/hardware/raspberry-pi-4.nix
View file

@ -59,11 +59,27 @@
# the kernel falls back to the device tree's stdout-path, i.e. this UART.
boot.kernelParams = [ "console=tty0" ];
# Kiosk display: vc4/v3d kernel modesetting via the firmware KMS overlay.
# This is the Pi 4's equivalent of the Pi 5's default KMS path — it also
# sets services.xserver.videoDrivers to modesetting (fbdev fallback), so we
# don't set that here. Electron renders through it as on the UP Board.
hardware.raspberry-pi."4".fkms-3d.enable = true;
# Kiosk display: mainline full KMS, NOT nixos-hardware's fkms-3d.
#
# fkms-3d applies the rpi4-cma-overlay and rpi4-vc4-fkms-v3d-overlay device
# tree overlays. Those target nodes that exist in the Raspberry Pi VENDOR
# kernel's DTBs and not in mainline's, so with the mainline kernel above the
# overlay step fails outright:
#
# Applying overlay rpi4-vc4-fkms-v3d-overlay
# libfdt.FdtException: pylibfdt error -1: FDT_ERR_NOTFOUND
#
# It is also unnecessary. "fkms" is FIRMWARE KMS, the older route where the
# VideoCore firmware owns the display and Linux drives it at arm's length.
# Mainline does full KMS instead, and mainline's own bcm2711-rpi-4-b.dtb
# already describes the hardware — it carries brcm,bcm2711-vc5 and
# brcm,2711-v3d nodes, checked with dtc. The vc4 and v3d drivers bind to
# those directly with no overlay involved.
#
# fkms-3d used to set services.xserver.videoDrivers as a side effect. Nothing
# needs to replace it: the shared configuration.nix already declares
# modesetting, which is the correct driver for full KMS and what the x86
# machines use. Setting it again here only produced a duplicate entry.
hardware.enableRedistributableFirmware = true;