Raspberry Pi 3B+ doesn't boot without a screen

I’m experiencing very strange behaviour. I’m trying to install NixOS on a Raspberry Pi 3B+. It works fine, I can ssh into the board or use it with a keyboard and a screen, but the board won’t boot without a connected screen. If I try to start the board without a screen, I cannot ssh into it. Then, if i plug a screen to it, the boot menu shows, and the board starts kernel etc. After this I can ssh into it normally. Does someone know how to troubleshoot this? Here’s my config:

{ config, pkgs, lib, ... }:

boot.loader.grub.enable = false;
boot.loader.generic-extlinux-compatible.enable = true;
boot.kernelPackages = pkgs.linuxPackages_4_19;
boot.kernelParams = ["cma=32M"];
fileSystems = {
  "/" = {
    device = "/dev/disk/by-label/NIXOS_SD";
    fsType = "ext4";
swapDevices = [ { device = "/swapfile"; size = 1024; } ];
services.openssh.enable = true;
networking.firewall.allowedTCPPorts = [ 22 80 8010 9989 ];
networking.hostName = "rasp";
networking.wireless.enable = true;
users.users = {
  nixos = {
    extraGroups = [ "wheel" ];
    isNormalUser = true;
    uid = 1001;

I have the same problem, serial output:

U-Boot 2019.04 (Apr 09 2019 - 01:40:40 +0000)

DRAM:  948 MiB
RPI 3 Model B+ (0xa020d3)
MMC:   mmc@7e202000: 0, sdhci@7e300000: 1
Loading Environment from FAT... *** Warning - bad CRC, using default 

mbox: Header response code invalid
bcm2835: Could not configure display
"Synchronous Abort" handler, esr 0x96000004
elr: 00000000000c9ed4 lr : 000000000009c220 (reloc)
elr: 000000003b3a6ed4 lr : 000000003b379220
x0 : 000000003af5c168 x1 : 0030343035313265
x2 : 000000003af58c50 x3 : 0000000000000000
x4 : 0000000000000073 x5 : 000000003af5c168
x6 : 00000000000092e1 x7 : 000000003af6ddd0
x8 : 000000003ae00000 x9 : 0000000000000008
x10: 0000000000200000 x11: 0000000000000000
x12: 0000000000000002 x13: 000000003ae00000
x14: 0000000000000000 x15: 00000000ffffffff
x16: 0000000000004110 x17: f46c768001842400
x18: 000000003af58de8 x19: 000000003af5c160
x20: 0030343035313265 x21: 000000003b3db128
x22: 000000003af5c1c0 x23: 000000003b3db188
x24: 000000003af5c170 x25: 000000003af64050
x26: 0000000000000000 x27: 000000003af64058
x28: 0000000000000002 x29: 000000003af58ca0

Resetting CPU ...

resetting ...

Maybe @dezgeg knows something about this? I believe he is the one who has put the most effort on ARM stuff.

This is a firmware problem. I don’t know what state is with more recent firmware versions, but using an older firmware fixed it for me back when I had it:

mkdir /firmware
mount /dev/mmcblk0p1 /firmware
nix build -f channel:nixos-19.03 raspberrypifw
cp result/share/raspberrypi/boot/{bootcode.bin,fixup*,start*} /firmware

Yeah, I’ve run into this in the past with other distributions. I currently use the UEFI firmware from the Pi Firmware Task Force to run my Pi 3B+ headless, which works pretty well and lets you use the normal infrastructure for setting up on a UEFI-based device.

Does this approach work through new nixos-rebuilds or does it have to be done every time? Or can I somehow embed this into the configuration?

This is a “one-off” action — the firmware is never updated by NixOS itself, only written once on image creation. It’s also not necessary if you start from an image with working firmware and upgrade from there.

1 Like

If you use the raspberryPi loader, it should update each time:

If you use the raspberryPi loader, it should update each time:

As far as I understood, $target is /boot, but the firmware partition is not meant to be mounted under /boot since sd-image: FAT free /boot by samueldr · Pull Request #62462 · NixOS/nixpkgs · GitHub. There is a pull request to restore firmware-updating behavior: raspberrypi-bootloader: support new firmware partition concept by lopsided98 · Pull Request #67902 · NixOS/nixpkgs · GitHub.

1 Like