Build the vc4 driver into the arm64 kernel so a Pi has a console - #165
Merged
Conversation
FOS builds without DRM and relies on firmware handing over a framebuffer, the way CONFIG_FB_EFI/FB_VESA works off EFI GOP on a PC. That assumption does not hold on a Raspberry Pi. Our bcm2711-rpi-4-b.dtb carries brcm,bcm2711-hdmi0/1 nodes but no simple-framebuffer node, and the simple-framebuffer node the VideoCore firmware would otherwise inject is suppressed whenever config.txt enables the vc4-kms-v3d overlay -- which current Raspberry Pi OS ships on by default. The result is a Pi that produces no console output at all, so a healthy boot and an early hang are indistinguishable (forums topic 18229). DRM_VC4 cannot simply be switched on. It depends on DRM, on SND && SND_SOC because HDMI audio is integral to the driver, and on PM -- three subsystems this config deliberately excludes. Enabling only CONFIG_DRM_VC4 is silently dropped by oldconfig with no error, which is the ADR-0010 trap; it took two rounds of adding a dependency and re-running olddefconfig before the symbol survived. Verified linked rather than merely configured: 378 vc4_* symbols in vmlinux. Cost measured on matched builds, same box and toolchain: Image grows from 28,353,024 to 29,420,032 bytes, +1,067,008 (+3.8%). DRM_V3D is deliberately not enabled -- it is the 3D accelerator and buys nothing for a console. This is a branch build for hardware testing. It needs an ADR and a guard in tests/checks/arm64-platform-config.sh before it belongs on master, since a silently-dropped DRM_VC4 would reintroduce exactly the blank screen this fixes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Validated on real hardware 2026-08-27 (forums topic 18229): with EXP_20260827-114033 the Pi 4 initialised HDMI, reached FOS userspace, and Partclone captured /dev/sda to the server. First end-to-end FOS imaging run on a Raspberry Pi, and the first real-hardware exercise of ADR-0015's platform support and of the mount -t nfs fix, both of which had only ever run under QEMU and VirtualBox. ADR-0017 records why the firmware-framebuffer approach that works on every PC does not reach a Pi: our shipped bcm2711-rpi-4-b.dtb has no simple-framebuffer node, and the node the VideoCore firmware would inject into its own DTB is suppressed once config.txt enables vc4-kms-v3d, which current Raspberry Pi OS ships enabled. It also records the measured cost (+1,067,008 bytes, +3.8%) and why DRM_V3D stays off. The harness gains DRM, DRM_VC4, DRM_FBDEV_EMULATION and FRAMEBUFFER_CONSOLE, and also PM, SND and SND_SOC -- the dependencies whose absence makes oldconfig drop DRM_VC4 with no error, for the same reason SERIAL_8250_SHARE_IRQ is already listed beside SERIAL_8250_BCM2835AUX. Proven to fail before being trusted: three mutations, each restored from a copy rather than git checkout. Dropping DRM_VC4 from the committed config goes red, dropping SND_SOC goes red, and dropping DRM_VC4 from the post-oldconfig .config goes red under -b, which is the mode that catches the actual trap. Full suite green: 15/15 checks plus the golden fixture. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A Raspberry Pi 4 booting FOS stopped on the firmware's four-raspberry splash with no text at all — no kernel messages, no FOS, nothing to type into. It was diagnosed as an early hang twice. It wasn't one: the kernel was running and had no way to say so.
Reported as forums topic 18229.
Why the existing approach doesn't reach a Pi
FOS builds no DRM on any architecture and attaches
fbconto a framebuffer the firmware set up —CONFIG_FB_EFI/FB_VESAoff EFI GOP on a PC, where every UEFI implementation publishes a GOP so it is guaranteed. On a Pi it is not:arm_dtbs.tar.gzships mainline'sbroadcom/bcm2711-rpi-4-b.dtb, which hasbrcm,bcm2711-hdmi0/1— nodes only vc4 binds to — and zerosimple-framebuffernodes. The firmware injects that node into the DTB it hands the bootloader; a DTB fetched over TFTP has never been through the firmware.vc4-kms-v3doverlay tells the firmware not to set the display up. Current Raspberry Pi OS ships that overlay enabled.Both directions fail silently, and a healthy boot renders identically to a dead one — which is what made the original report unreadable.
The change
CONFIG_DRM+CONFIG_DRM_VC4+CONFIG_DRM_FBDEV_EMULATION, so the kernel programs the HDMI block itself and no longer depends on firmware cooperation.Measured cost:
Image28,353,024 → 29,420,032 bytes, +1,067,008 (+3.8%), on matched local builds, same box and toolchain. The published CI pair moved 30,253,568 → 31,386,112, agreeing to within 0.1pp.CONFIG_DRM_V3Dis deliberately off — it's the 3D accelerator and a console doesn't use it.The dependency trap
CONFIG_DRM_VC4=ycan't just be switched on. Perdrivers/gpu/drm/vc4/Kconfigitdepends on DRM, onSND && SND_SOC(HDMI audio is integral to the driver), and onPM— all three excluded by FOS. Miss any one andoldconfigdrops it with no error, leaving a config that reads right in git and a kernel with no display driver. That's the ADR-0010 trap, and it fired twice here.So the driver is asserted linked, not configured: 378
vc4_*symbols invmlinux.Verification
EXP_20260827-114033: HDMI initialised, FOS reached userspace, Partclone captured/dev/sdato the server. First end-to-end FOS imaging run on a Raspberry Pi — and the first real-hardware exercise of ADR-0015's platform support and of themount -t nfsfix, both previously only QEMU/VirtualBox.CONFIG_DRM_VC4=yconfirmed in the publishedarm_Imageviaextract-ikconfig, not just in the config file.git checkout: droppingDRM_VC4from the committed config → red; droppingSND_SOC→ red; droppingDRM_VC4from the post-oldconfig.configunder-b→ red. That last mode is the one that catches the actual trap.tests/checksplus the golden fixture.ADR-0017 records the decision and the trap.