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

fix(rpi4): use the mainline kernel, not the uncached Pi vendor one

Browse source 
nixos-hardware's raspberry-pi/4 module mkDefaults boot.kernelPackages to
the Raspberry Pi vendor kernel (linux-rpi, via common/kernel.nix). That
kernel is in no binary cache: Hydra does not build nixos-hardware's
overlay kernels, and it is not in aiolabs.cachix.org either. So every Pi
compiles a kernel from source, on an SD card, and recompiles on every
bump.

Found the hard way during the first Pi 4 bring-up, which spent hours on

  building linux-rpi-6.18.39-stable_20260724 (buildPhase):
    CC [M]  fs/overlayfs/inode.o

before anyone looked closely enough to notice it was not the app. I had
told the operator only the app would build, having checked that Electron
and the Pi firmware were cached and never checked the kernel.

Mainline aarch64 kernels are cached, and mainline demonstrably boots a
Pi 4 — it is what the stock NixOS aarch64 SD image runs, which is how this
machine was bootstrapped in the first place. The vendor kernel's
Pi-specific patches buy nothing this kiosk needs: display, USB serial and
WiFi are all mainline, and vc4/v3d KMS has been mainline for years.

  before: linux-rpi-6.18.39-stable_20260724   not cached, hours to build
  after:  linux-6.12.90                       cached, downloads

Verified the config still evaluates, which also clears nixos-hardware's
assertion that the kernel be at least 6.1.

Watch the graphics path. fkms-3d is a nixos-hardware overlay built around
the vendor kernel's firmware-KMS route; the mainline equivalent is full KMS
(vc4-kms-v3d). If X lands on the framebuffer with Electron rendering in
software, that overlay is where to look, not this kernel choice.

rpi5 is left alone deliberately and still carries the vendor kernel, so it
will pay the same cost whenever someone first builds it. Mainline Pi 5
support is younger than Pi 4's and the RP1 southbridge needed vendor
patches for longer, so that one wants its own check rather than the same
change applied on faith.
This commit is contained in:
Padreug 2026-09-25 15:27:12 +02:00
commit b2bf2ffe4b
1 changed files with 22 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -22,6 +22,28 @@
# line documents/asserts it.)
nixpkgs.hostPlatform = lib.mkDefault "aarch64-linux";
# Mainline kernel, NOT the Raspberry Pi vendor one.
#
# nixos-hardware's raspberry-pi/4 module mkDefaults boot.kernelPackages to
# the vendor kernel (linux-rpi, via common/kernel.nix). That kernel is in no
# binary cache — Hydra does not build nixos-hardware's overlays, and it is
# not in aiolabs.cachix.org either — so every Pi compiles a kernel from
# source, on an SD card, and recompiles on every bump. The first bring-up
# attempt spent hours on `CC [M] fs/overlayfs/inode.o` before anyone noticed
# what it was doing.
#
# Mainline aarch64 kernels are cached, and mainline demonstrably boots a
# Pi 4: it is what the stock NixOS aarch64 SD image runs. The vendor kernel's
# Pi-specific patches buy nothing this kiosk needs — display, USB serial and
# WiFi are all mainline, and vc4/v3d KMS has been mainline for years.
#
# Watch the graphics path when changing this. fkms-3d below is a
# nixos-hardware overlay built around the vendor kernel's firmware-KMS route;
# the mainline equivalent is full KMS (vc4-kms-v3d). If X ends up on the
# framebuffer with Electron rendering in software, that overlay is where to
# look — not the kernel choice, which is worth keeping either way.
boot.kernelPackages = pkgs.linuxPackages;
# Bootloader: the aarch64 sd-image uses the extlinux-compatible generator;
# nixos-hardware's rpi4 module wires the firmware/u-boot. No systemd-boot.
boot.loader.grub.enable = lib.mkDefault false;