Raspberry Pi 4 support

[majewsky]

Raspberry Pi just announced immediate availability of the Model 4. It will probably be some time until the aarch64 maintainers can get their hands on these, but I figured this can go into the backlog already.

[jbaum98]

I have a PR #91295 that makes it actually clean up the boot partition when you nixos-rebuild switch, so that also might be helpful for this. Also, if people test it and write feedback on the PR that will probably help get it merged.

[golddranks]

I tried @jbaum98 's PR that fixes /boot/old taking too much space for me. Seems to work well!

I also tried the rpi-eeprom-update linked here: https://github.com/NixOS/nixpkgs/issues/63720#issuecomment-647893093 I managed to upgate the firmware to the newest STABLE (Jun 15) that supports USB boot. (You need to change the version of the Nix expression.) However, taking the MicroSD card off and trying to boot purely from USB, still doesn't work for me.

Here's the error message:

start4.elf: is not compatible
USB_MSD boot requires never software

Edit: an image.

Re-inserting the MicroSD card allows me to boot. It seems that rpi-eeprom-update doesn't update the binaries in /boot and something else needs to do that. It's quite clear that something else is here: https://github.com/NixOS/nixpkgs/tree/master/nixos/modules/system/boot/loader/raspberrypi ...but on a cursory look I'm not sure where does it specify the version and fetch the package? I guess that I need to match the versions with the firmware.

(Edit: Oops, it occurred to me that the image written on the USB SSD drive might be simply old. I'll try and update it.)

[golddranks]

Ah, the firmware package that contains the bootloader is here: https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/firmware/raspberrypi/default.nix

According to the EEPROM repo, version BETA 2020-06-12 requires a new version of start.elf binary: https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md#2020-06-12-improve-support-for-powered-usb-sata-devices---beta

The newest version of the binary provided by Nix is 1.20200601. I think that this might not be new enough, since in the 2020-06-12 update they said that the compatible bootloader will be distributed in few day's time, so something newer than 2020-06-12 is required.

[golddranks]

https://github.com/NixOS/nixpkgs/compare/master...golddranks:update_rpi_firmware?expand=1 Preparing an update PR, but haven't yet tested whether it helps. Continuing later.

[purcell]

@goldranks In case it helps you, I achieved a successful install with USB boot this weekend using the following process:

• Put 64-bit Pi OS on an SD and on a USB disk
• Booted from SD, updated the package list, and ran the eeoprom updater
• Booted from USB disk, with SD removed
• Installed Nix on top of Pi OS, cloned the nixpkgs tree
• Built the SD image from the nixpkgs master branch (after increasing the boot partition size, and applying the fix in https://github.com/NixOS/nixpkgs/pull/93824) -- obviously this takes a few hours
• Put that SD image on a USB disk, and booted into NixOS from that

[golddranks]

@purcell Thanks, if it works like that for you, then my hypothesis about the version requirement is likely to be wrong. Upon further investigation, turned out I was running a really old version, 1.20190925; turns out I hadn't managed to successfully change the channel from 2020-03 to unstable. I'm having some trouble upgrading (a library named Trifecta-2.1 fails tests), but once I manage to do that, I'll test again.

[golddranks]

Hmm, I'm unable to upgrade channels with Pi 4 (4GB), it seems that Trifecta's quickcheck tests take too much memory, or something. Maybe it would help to build a whole new image that's directly based on unstable, but it's seems hard because I don't have any other working Linux system at the moment. Perhaps I'll try doing that in Docker. Was there any pre-built images available yet though?

[purcell]

Was there any pre-built images available yet though?

Nope, latest passing trunk build seems to be from 3 Jul, before the recent updates to the firmware and kernel versions. Check out https://github.com/Robertof/nixos-docker-sd-image-builder for building SD images if you have a suitable machine available.

[mohe2015]

After https://github.com/NixOS/nixpkgs/pull/93824 is merged there should be new images available. Also I think you currently need the release candidate of qemu to cross compile the image.

[malte-v]

Has anyone been successful setting up a Wayland compositor? I'm using https://hydra.nixos.org/build/125030040.

Edit: See https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi, "With GPU".

[golddranks]

I'm continuing having troubles with updating NixOS on Raspberry Pi 4. The package Trifecta fails some tests. I'm curious whether the failures are reproduceable. The issue seems to be similar to this: https://gitlab.haskell.org/ghc/ghc/-/issues/15275 Those with working Raspberry Pi 4 setups, does nix-env -f "<nixpkgs>" -iA haskellPackages.trifecta build and install the package properly?

It seems that that the dependency chain that requires Trifecta is raspberrypi-builder.sh→shellcheck-0.7.1→pandoc-2.9.2.1→haddock-library-1.8.0→tree-diff-0.1. raspberrypi-builder.sh is the one of this PR: https://github.com/NixOS/nixpkgs/pull/91295

[golddranks]

Managed to circumvent the Trifecta problem by not using PR #91295. Successfully booted from USB. But I'm encountering a non-fatal error message "mmc0: Timeout waiting for hardware interrupt" that gets printed to the console every few seconds:

[golddranks]

Adding dtparam=sd_poll_once=on to /boot/config.txt, as described here https://github.com/raspberrypi/linux/issues/3092 fixes the logspam, which happens when there is no SD card plugged in. I wonder if this is something the Nix support should provide; it's something that happens when booting from USB or from network.

[matthewbauer]

Has anyone been successful setting up a Wayland compositor? I'm using https://hydra.nixos.org/build/125030040.

Edit: See https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi, "With GPU".

I have! I think you need to set dtoverlay=vc4-fkms-v3d in config.txt if you're using the raspberry pi loader. See https://github.com/matthewbauer/nixiosk/blob/master/hardware/raspberrypi.nix for the config.

[mohe2015]

If you need to revert because it doesn't boot you would need to use a PC to manually edit the files, wouldn't you? Or you could always network boot?

[golddranks]

Hi, I'm trying to cross-compile for Raspberry Pi 4 using a x86_64 system:

nix build -f channel:nixos-unstable pkgsCross.aarch64-multiplatform.shellcheck

This eventually fails with:

builder for '/nix/store/8cwh2w6a285v7g6qqj6jm5hr7p18vjdn-QuickCheck-2.13.2-aarch64-unknown-linux-gnu.drv' failed with exit code 1; last 10 log lines:
  integer-gmp-1.0.2.0, pretty-1.1.3.6, template-haskell-2.15.0.0, time-1.9.3,
  transformers-0.5.6.2
  Warning: --source-* options are ignored when --hyperlinked-source is enabled.
  Haddock coverage:
  haddock: panic! (the 'impossible' happened)
    (GHC version 8.8.4 for x86_64-unknown-linux):
         nativeCodeGen: No NCG for ARM64

  Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
cannot build derivation '/nix/store/a1akjc98j6fbh0439200whxwmpw50lkn-ShellCheck-0.7.1-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/a0sy4rnwgjzk2ahpln7nfz5ih5h84cks-shellcheck-0.7.1-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
[234 built (1 failed), 303 copied (931.8 MiB), 191.5 MiB DL]
error: build of '/nix/store/a0sy4rnwgjzk2ahpln7nfz5ih5h84cks-shellcheck-0.7.1-aarch64-unknown-linux-gnu.drv' failed

Any ideas what to do about this?

[glglwty]

@golddranks I'm not familiar with GHC but looks like some features need to be turned off on arm https://gitlab.haskell.org/ghc/ghc/-/issues/14586

[golddranks]

I have an impression that NCG is a GHC backend that produces machine code directly (as opposed to the other backends that produce C or LLVM IR). If the NCG doesn't support compiling to AArch64, I don't see how the build is supposed to work even when NOT cross-compiling. Are backends allowed to be switched when cross-compiling or not? (Are cross-compiled packages even expected to be the same as the natively built ones?)

[golddranks]

FWIW, native builds for the same seem to work fine.

A tip for people struggling with long build times on Raspberry Pi: I tried building a bunch of packages on AWS Graviton, an AArch64 instance type (tried with the the type a1.xlarge: 4 cores, 8GB of RAM), and it was cheap and painless. There is an available Nix image in the community images: NixOS-20.03.2351.f8248ab6d9e-aarch64-linux. nix-copy-closure makes it easy to deploy the result :)

[numinit]

Question - what prereqs do you all think this issue would need to be closed for 20.09? What are the main headaches (other than in #91295) that we'd like to see resolved to be able to say that NixOS supports the Raspberry Pi 4 well?

For me, the first rebuild is a bit annoying because I need to manually mount /boot. But, in a sense, this is common to all NixOS installs. What other pain points are people experiencing?

[numinit]

According to #97399, the rpi4 image isn't going to be built for 20.09 anymore, so we might have to continue using unstable.

[samueldr]

@numinit you can change the channel of the raspberry pi image you already have, or from one coming from unstable.

What differs is that the stable channels don't produce images, since they are best-effort images, and not officially supported. This is because the Raspberry Pi 4B image is only temporary, until mainline supports the Raspberry Pi 4B enough to allow the user to change it to the Raspberry Pi Foundation's kernel if they so desire. Turns out it's temporary for a longer time than initially expected :).

For what it's worth, the same happened for 20.03.

[samueldr]

Hi, anyone following this issue might be interested in #97883, if you have concerns, questions, do ask on the PR.

If you have reasons not to follow through with the change, please voice them. Though note that at some point it is expected that the generic AArch64 image is going to be the image used for the Raspberry Pi 4B too, and this PR removes most of the differences compared to the generic AArch64 image.

This means that concerns against this change might not stop us from implementing the change. It was never considered to be a stable "API" to provide a vendor-specific image. Though I still want to hear the concerns, in case something non-obvious escaped me.

[numinit]

@samueldr I've been following your work with the other issues! Great work, closer and closer to getting a generic aarch64 build that works with the rpi. Barring actual kernel support, anyway. :-)

[peti]

Has anyone managed to get Bluetooth running? I added hardware.bluetooth.enable = true; in configuration.nix, but the kernel won't even discover the bluetooth device. Am I doing something wrong?

EDIT: OK, my kernel now can see the bluetooth controller:

[    7.392688] Bluetooth: Core ver 2.22
[    7.392781] NET: Registered protocol family 31
[    7.392784] Bluetooth: HCI device and connection manager initialized
[    7.396387] Bluetooth: HCI socket layer initialized
[    7.396400] Bluetooth: L2CAP socket layer initialized
[    7.396437] Bluetooth: SCO socket layer initialized
[    7.402700] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    7.404570] Bluetooth: Generic Bluetooth SDIO driver ver 0.1
[    9.378818] 8021q: 802.1Q VLAN Support v1.8
[    9.420734] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[   10.798671] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[   11.170426] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   11.170431] Bluetooth: BNEP filters: protocol multicast
[   11.170441] Bluetooth: BNEP socket layer initialized

However, I still cannot enable it or use it:

# bluetoothctl
Agent registered
[bluetooth]# show
No default controller available
[bluetooth]# power on
No default controller available

[domenkozar]

Would be good to know which kernels are used since that's a moving target.

[clkamp]

I'm currently trying to get a RPi 4 8Gb working with NixOS and have some problems with the GPU Setup. I tried to follow the wiki: https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi_4#With_GPU, but since #79370 the way to load the overlay changed. What I already tried:

• just removing the base option, like in https://github.com/NixOS/nixpkgs/pull/79370#issuecomment-695332599 but than the GPU is not found
• loading the overlay manually with dtoverlay, but that fails. This causes me to think, that maybe the base dtree is the wrong one. Is there still a way to use the base dtree from raspberrypifw?

Does anyone have an idea, how I could test this further or what I can try to get around this issue?

[Renha]

What is the current status of loading from usb support? I've just ordered an USB-to-sata adapter and wonder if I could boot from SSD using it

[purcell]

What is the current status of loading from usb support? I've just ordered an USB-to-sata adapter and wonder if I could boot from SSD using it

I booted my rpi4 from raspbian recently and updated the firmware, and now it happily boots nixos off USB. Unsure if there's a way to update the firmware from nixos, but this was good enough for me.

[panchoh]

@Renha: you can also get the firmware of your RPi 4 updated, as well as resetting the config to the factory defaults, with the released images available here: https://github.com/raspberrypi/rpi-eeprom. The flash process is quite quick, almost instant, and you get a green image when the process finishes OK.

[scaredmushroom]

@clkamp Did you managed to adapt the config to the changes? I'm having the same problem right now.

[chayward1]

@clkamp @scaredmushroom I am having the same issues with the GPU on both my Raspberry Pi 4 and Raspberry Pi 400, following the guide on the wiki

[drewrisinger]

@clkamp @scaredmushroom @chayward1 this GPU issue can be resolved with

{ config, pkgs, ...}:
{
  # GPU Support
  hardware.opengl = {
    enable = true;
    setLdLibraryPath = true;
    package = pkgs.mesa_drivers;
  };
  hardware.deviceTree = {
    kernelPackage = pkgs.linux_rpi4;
    overlays = [ "${pkgs.device-tree_rpi.overlays}/vc4-fkms-v3d.dtbo" ];
  };
  ...
}

I'm currently building my install, so I'll update if something changes, but errors with configuration.nix are resolved with this.

I'll also update the wiki soon with my experience.

[clkamp]

@drewrisinger I tried your config, but it does not work for me. There is still no video card found by the X-Server.

Did you have success with your config?

EDIT: I also manually compared the bcm2711-rpi-4-b.dtb from /boot/ with the ovelay file and found out that these are absolutely not compatible, the symbol names have changed. Also tried to manually make a new overlay but failed for now.

EDIT2: The reason for not matching overlay is that linuxPackages_rpi (see https://github.com/NixOS/nixpkgs/blob/83cbad92d73216bb0d9187c56cce0b91f9121d5a/pkgs/os-specific/linux/kernel/linux-rpi.nix#L5) was not updated while the firmware was (see https://github.com/NixOS/nixpkgs/blob/4903ef48f9f9b1806b788b45b1227e02f37e23ee/pkgs/os-specific/linux/firmware/raspberrypi/default.nix#L5). I tried the overlay from the corresponding version, there the video card was found but than there is a core dump in the X server.

[clkamp]

I finally got it working! The core dumping of the Xserver seems to be unrelated to the RPi GPU problems. Using a newer version of Xserver (1.20.10, the newest version in nixos) it works. But currently at least ssdm and lightdm are not build for aarch64 from the current unstable because of #106558.

However, overriding psautohint everything works so far using the overlay device-tree from the 1.20200601 firmware. This is done in the following way:

1. Place the vc4-fkms-v3d.dtbo in /boot/overlays/
2. add dtoverlay=vc4-fkms-v3d to boot.raspberryPi.firmwareConfig

Still the next step should be to bump the version of linux-rpi. When again firmware and kernel have the same versions all this should not be necessary any more and the simple solution is sufficient (https://github.com/NixOS/nixpkgs/issues/63720#issuecomment-741335632)

[sternenseemann]

But currently at least ssdm and lightdm are not build for aarch64 from the current unstable because of #106558.

Afaik neither ssdm nor lightdm depend on psautohint. I suspect the failure is cropping up because noto-fonts-emoji which requires psautohint to build is enabled for some reason. The most likely explanation for this would be if fonts.enableDefaultFonts is true. This could be a workaround for now or of course overriding the offending package.

[drewrisinger]

I updated a lot of firmware/linux packages in #107637. Reviews/testing appreciated! The Linux kernel at least built & ran on my Pi 4 (after ~12 hours of emulated-building).

Now that I have this working, my next project is going to be trying mainline Linux 5.10 on the Rpi4. According to https://github.com/lategoodbye/rpi-zero/issues/43 most of the main changes have been upstreamed, with the last ones being the GPU's V3D (VideoCore VI) driver, though the VC4 driver is mainlined.

[Renha]

@drewrisinger what is the testing procedure as you would recommend it?

[r-burns]

Hmm, as far as I can tell from reading this thread, all the necessary fixes have been applied for booting NixOS from USB. But although I can boot the ordinary Raspberry Pi OS image from SD and USB, the RPi4 image built by Hydra (https://hydra.nixos.org/job/nixos/trunk-combined/nixos.sd_image_raspberrypi4.aarch64-linux) only boots from SD for me. Are there still more changes needed for that image to work with USB boot?

[golddranks]

@drewrisinger Thanks, I tried updating, at it seems to boot without problems. I run headless, so can't say anything about the graphical side.

@r-burns Just my experience: I'm running unstable with USB boot, but I originally bootstrapped this installation from an SD card, and changed the settings to the USB boot later. Have you flashed the latest (2020-09-03) EEPROM firmware, that's required for the USB boot to work? (https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md#2020-09-14-promote-the-2020-09-03-release-to-be-the-default-eeprom-images)

Btw. I'm still running a modified build that includes this PR: https://github.com/NixOS/nixpkgs/pull/91295 that helps with the garbage accumulating in /boot. I wonder what will be its final destiny?

[axelsimon]

Hi, i realise this was asked a while back but has anyone got hardware acceleration working for video? I've got a Raspberry Pi 4 running Jellyfin on NixOS, and while i'm really pleased with how simple configuring the overall setup was in the end, Jellyfin currently can't use the rpi4's hw acceleration for video transcoding.

I'm not sure if what @drewrisinger suggested a month ago does the trick. It seems to imply that vc4-fkms-v3d.dtbo is present in /boot/overlays, but it isn't for me. Any help would be appreciated! :slightly_smiling_face:

[mohe2015]

Anybody knows what this is about? Using mainline from master with beta firmware in a Raspberry Pi 4 and trying to boot using USB.

[ghost]

Anybody knows what this is about? Using mainline from master with beta firmware in a Raspberry Pi 4 and trying to boot using USB.

I encountered this too. Only on the 8GiB pi, my 4GiB versions are fine. It loops through this resetting cpu boot loop, but oddly, as soon as I unplug a hdmi cable from it, and put it back in, it boots fine.

[LucaFulchir]

I can boot from usb easily enough, but only if I maintain MBR partitioning.
...which is bad for me since I wanted to use two 4TB drives for NAS and other stuff, and MBR only supports 2TB max.

Details on what I tried to convert MBR->GPT: https://discourse.nixos.org/t/rpi4-usb-boot-gpt/11440

Basically I think it reaches u-boot which does not find what it needs and tries network boot only. I have no experience on that unfortunately. Suggestions (should I open a different ticket?)?

[wizeman]

@LucaFulchir I also had some trouble with GPT at first, until I figured out what partition type to use.

My first partition is a 2 GB /boot filesystem formatted using mkfs.vfat which contains the firmware files, config.txt, initrd and kernel. My second partition contains the root filesystem (formatted with ext4).

This is what my partitions look like under fdisk:

Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: SSD 850 EVO 500G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt

Device       Start       End   Sectors   Size Type
/dev/sda1     2048   4196351   4194304     2G EFI System
/dev/sda2  4196352 976773134 972576783 463.8G Linux filesystem

Command (m for help): i
Partition number (1,2, default 2): 1

         Device: /dev/sda1
          Start: 2048
            End: 4196351
        Sectors: 4194304
           Size: 2G
           Type: EFI System
      Type-UUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B
           Name: EFI system partition

Command (m for help): i
Partition number (1,2, default 2): 2

         Device: /dev/sda2
          Start: 4196352
            End: 976773134
        Sectors: 972576783
           Size: 463.8G
           Type: Linux filesystem
      Type-UUID: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
           Name: Linux filesystem

Under gdisk:

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Model: SSD 850 EVO 500G
Sector size (logical/physical): 512/512 bytes
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         4196351   2.0 GiB     EF00  EFI system partition
   2         4196352       976773134   463.8 GiB   8300  Linux filesystem

Command (? for help): i
Partition number (1-2): 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI system partition)
First sector: 2048 (at 1024.0 KiB)
Last sector: 4196351 (at 2.0 GiB)
Partition size: 4194304 sectors (2.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'EFI system partition'

Command (? for help): i
Partition number (1-2): 2
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
First sector: 4196352 (at 2.0 GiB)
Last sector: 976773134 (at 465.8 GiB)
Partition size: 972576783 sectors (463.8 GiB)
Attribute flags: 0000000000000000
Partition name: 'Linux filesystem'

I'm not sure if the /boot partition has to be the first one, I don't remember exactly how boot works on the Raspberry Pi. Pay attention especially to the partition type (EFI system partition / EF00). You may also have to upgrade the RPI's EEPROM with rpi-eeprom-update -a for this to work (possibly even with a raspberry pi firmware package from nixos-unstable?), I'm not sure about that either. Note, however, that I'm not using u-boot, so I'm not sure if this will work for you.

[LucaFulchir]

Eeprom already upgraded (the September version). The first partition must be the one with the firmware, yes. But technically the /boot can stay in an other partition if everything is cleartext like in the default image

I still can't get it to work. I can create a usb key that boots with GPT. basically it's just:

• erase various fileystem signatures and partitions
• create gpt, first partition in ef00 in vfat
• create second partition 8300 and dump there the installation partition

this boots with my 8G usb key, it does not with my 4TB hd. I get a load of "gpt partition table header signature is wrong"

I tried erasing all gpt/mbr signatures multiple times and my laptop never warns of gpt errors with any tool on those disks.

I think everybody is using u-boot with nixos/raspberry, it's the last stage before the kernel loading (file u-boot-rpi4.bin in the firmware directory)

After a while of trying to boot via network I get a u-boot prompt, and I tried with the files from the installation image.

I'll open an other ticket, it's probably wrong to hijack this thread

[astrojhgu]

On nixos-unstable kernel 5.4.79 (pkgs.linuxPackages_rpi4), neither sound nor wifi works.

My rpi4 is a 8GB version.

I have already set the firmware config "dtparam=audio=on" and enabled the sound.

my nixos information:

 - system: `"aarch64-linux"`
 - host os: `Linux 5.4.79, NixOS, 21.05pre273435.0aeba64fb26 (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.10`
 - channels(root): `"nixos-21.05pre273435.0aeba64fb26"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

$> lspci
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge (rev 10)
01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host Controller (rev 01)
$> aplay -l
aplay: device_list:274: no soundcards found...

$> sudo modprobe snd_bcm2835
$> ls /dev/snd/
seq  timer
$> cat /proc/asound/cards 
--- no soundcards ---

My configuration.nix is attached configuration.txt

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/has-any-one-succeeded-to-drive-all-devices-of-rpi4b-8gb/11850/1

[tfc]

Hi there, i have discovered the same problem with the raspberry image, and when trying to build a new one from master i additionally get this problem:

$ nix-build nixos/release.nix -A sd_image_raspberrypi4
...
root module: sun4i_drm
modprobe: FATAL: Module sun4i_drm not found in directory /nix/store/4p7kd78cdzb93zqvhs651nlqvwk94ry5-linux-5.4.79-1.20201201-modules/lib/modules/5.4.79
builder for '/nix/store/kpmyrhdgbxqka3zly1q0p55a5v9dxm6y-linux-5.4.79-1.20201201-modules-shrunk.drv' failed with exit code 1
...

when removing those modules from the file nixos/modules/installer/sd-card/sd-image-aarch64.nix, it builds again.

[mohe2015]

Hi there, i have discovered the same problem with the raspberry image, and when trying to build a new one from master i additionally get this problem:

$ nix-build nixos/release.nix -A sd_image_raspberrypi4
...
root module: sun4i_drm
modprobe: FATAL: Module sun4i_drm not found in directory /nix/store/4p7kd78cdzb93zqvhs651nlqvwk94ry5-linux-5.4.79-1.20201201-modules/lib/modules/5.4.79
builder for '/nix/store/kpmyrhdgbxqka3zly1q0p55a5v9dxm6y-linux-5.4.79-1.20201201-modules-shrunk.drv' failed with exit code 1
...

when removing those modules from the file nixos/modules/installer/sd-card/sd-image-aarch64.nix, it builds again.

On which system are you trying to build? e.g. x86 or arm? Because if you are on x86 or so I think you need to add "--system aarch64-linux" or so. But maybe I just forgot and this is a different issue