Closed purcell closed 1 year ago
@purcell do you know what version of nixos-unstable this last worked with? I can confirm the issue too
Yeah, I didn't bisect, but I update very regularly and it started failing in the last two weeks, so I think it was the latter commit, but see also NixOS/nixpkgs@f4e0f22a2bf and NixOS/nixpkgs@6c0773fc34b.
Just noting that hardware.raspberry-pi."4".audio.enable = true;
also appears broken based on the same output and might be okay to track in here also (but happy to open a new issue if required)
As far as I could tell, the error message referred to applying the overlays to the CM4 device tree.
I also tried to change the device tree filter to only match the raspberry pi 4 (and in my case 400). Unfortunately, I could not get this to run in any configuration, as the vc4 kernel module would always create oopses on loading and I would always get a black screen, with none of the usual fixes working.
Perhaps @samueldr (and possibly @tfc) as past contributors to that overlay could suggest what we might try to tinker with here?
I stumbled into the same issue while trying to upgrade to NixOS 23.05. I noticed the audio overlay is not needed in my setup, at least pulseaudio outputs sound just fine in my setup but without audio.enable
. But without the fkms-3d
overlay, kodi won't start. It seems I have to revert for now...
Maybe the error message with apply-overlays-dtmerge
enabled is helpful:
Applying overlay rpi4-vc4-fkms-v3d-overlay to bcm2711-rpi-cm4-io.dtb... DTOVERLAY[error]: can't find symbol 'fb'
Perhaps @samueldr (and possibly @tfc) as past contributors to that overlay could suggest what we might try to tinker with here?
This is a complete shot in the dark, but maybe the overlays just need to be updated. Have a look at the following comment which explains how it's done: https://github.com/NixOS/nixos-hardware/blob/master/raspberry-pi/4/dwc2.nix#L41
Hello, I have the same problem and noticed that the same error (FDT_ERR_NOTFOUND
) happens when applying the gpio-fan overlay for the 6.1 kernel.
My configuration contains only a slight change to the compatible
line and trip point temperature which worked with NixOS 22.11, maybe this information can be useful?
This is a complete shot in the dark, but maybe the overlays just need to be updated.
I wanted to try this but don't really know how to do it.
The comment didn't provide enough details because I wasn't able to find this file: ${config.hardware.deviceTree.kernelPackage}/dtbs/overlays/dwc2.dtbo
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/23-05-is-broken-for-raspberry-pi-4/28749/1
I tried setting hardware.raspberry-pi."4".apply-overlays-dtmerge.enable = true
but the error persists.
With the option enabled:
error: builder for '/nix/store/8kbsnm22g8spv9k49k1rwjjmdacxp6vb-device-tree-overlays.drv' failed with exit code 1;
last 10 log lines:
> Applying overlay rpi4-cma-overlay to bcm2711-rpi-4-b.dtb... ok
> Applying overlay rpi4-vc4-fkms-v3d-overlay to bcm2711-rpi-4-b.dtb... ok
> Applying overlay rpi4-cpu-revision to bcm2711-rpi-4-b.dtb... ok
> Applying overlay gpio-fan-overlay to bcm2711-rpi-4-b.dtb... ok
> Applying overlay rpi4-cma-overlay to bcm2711-rpi-400.dtb... ok
> Applying overlay rpi4-vc4-fkms-v3d-overlay to bcm2711-rpi-400.dtb... ok
> Skipping overlay rpi4-cpu-revision: incompatible with bcm2711-rpi-400.dtb
> Applying overlay gpio-fan-overlay to bcm2711-rpi-400.dtb... ok
> Applying overlay rpi4-cma-overlay to bcm2711-rpi-cm4-io.dtb... ok
> Applying overlay rpi4-vc4-fkms-v3d-overlay to bcm2711-rpi-cm4-io.dtb... DTOVERLAY[error]: can't find symbol 'fb'
For full logs, run 'nix log /nix/store/8kbsnm22g8spv9k49k1rwjjmdacxp6vb-device-tree-overlays.drv'.
error: 1 dependencies of derivation '/nix/store/28215q3pp444aja810c14s1k9l6pgna0-nixos-system-unimatrix-01-23.05.20230606.a558f7a.drv' failed to build
Without:
error: builder for '/nix/store/q3k46mf6356xnni89rz8dnh9rlaczsd1-device-tree-overlays.drv' failed with exit code 1;
last 10 log lines:
> Applying overlay rpi4-vc4-fkms-v3d-overlay to bcm2711-rpi-4-b.dtb... ok
> Applying overlay rpi4-cpu-revision to bcm2711-rpi-4-b.dtb... ok
> Applying overlay gpio-fan-overlay to bcm2711-rpi-4-b.dtb... ok
> Applying overlay rpi4-cma-overlay to bcm2711-rpi-400.dtb... ok
> Applying overlay rpi4-vc4-fkms-v3d-overlay to bcm2711-rpi-400.dtb... ok
> Skipping overlay rpi4-cpu-revision: incompatible with bcm2711-rpi-400.dtb
> Applying overlay gpio-fan-overlay to bcm2711-rpi-400.dtb... ok
> Applying overlay rpi4-cma-overlay to bcm2711-rpi-cm4-io.dtb... ok
> Applying overlay rpi4-vc4-fkms-v3d-overlay to bcm2711-rpi-cm4-io.dtb...
> Failed to apply '/nix/store/41pw339s0jhvbyvbyajdav306x36qima-rpi4-vc4-fkms-v3d-overlay-dtbo': FDT_ERR_NOTFOUND
For full logs, run 'nix log /nix/store/q3k46mf6356xnni89rz8dnh9rlaczsd1-device-tree-overlays.drv'.
error: 1 dependencies of derivation '/nix/store/2bh5nj2gwyjhga5nc5pdwa3kbxypz3jh-nixos-system-unimatrix-01-23.05.20230606.a558f7a.drv' failed to build
I noticed that the file bcm2711-rpi-cm4-io.dtb
(actually bcm2711-rpi-cm4-io.dtb.in
on disk) is missing in the NixOS 22.11 configuration, does anybody know what the .in
extension means?
After ignoring it with hardware.deviceTree.filter = "bcm2711-rpi-4*.dtb"
the build is successful and the kernel boots, but stage 1 init complains about Timed out for waiting the udev queue being empty.
, which may be caused by something else since the same happens if only bcm2711-rpi-cm4-io.dtb
is excluded.
Update: The udev timeout is fixed by not setting hardware.raspberry-pi."4".fkms-3d.enable = true;
and after setting udev.log-priority=debug
in kernel params there are messages about a udev task for the GPU taking very long and being killed after some time.
Thanks to the help of the Matrix chat I was able to fix my setup. The nixos-hardware module isn't required anymore since the mainline kernel works as well. I was told that everything works except ISP (don't know what that is). However, I can confirm that I got my USB-OTG setup working. Please forgive me if this isn't true I have very little knowledge about the hardware side of Linux but I wanted to share a working config. I will gladly update this comment if necessary.
I had to take the following settings from nixos-hardware to get my config working. I'm not 100% sure that everything is required but it is working with this.
boot = {
initrd.availableKernelModules = [
"usbhid"
"usb_storage"
"vc4"
"pcie_brcmstb" # required for the pcie bus to work
"reset-raspberrypi" # required for vl805 firmware to load
];
loader = {
grub.enable = false;
generic-extlinux-compatible.enable = true;
};
};
boot.extraModulePackages = [ ];
boot.kernelParams = [ ];
hardware.enableRedistributableFirmware = true;
My base config lives here: https://git.2li.ch/Nebucatnetzer/nixos/src/commit/1a3c748c8e5466359c92cfd1d81954199c5d69be/modules/hardware/raspi4/raspi-base.nix And the config for USB-OTG lives here: https://git.2li.ch/Nebucatnetzer/nixos/src/commit/1a3c748c8e5466359c92cfd1d81954199c5d69be/modules/hardware/raspi4/raspi-base.nix
@Nebucatnetzer Thanks for sharing that! Feeling optimistic, I pulled nixos-hardware
out of my config and incorporated your settings above, but still failed to get a booting system with nixos-unstable
. I'm using the raspberryPi
loader, though, so that portion was different. Iterating on tests is painful because of the hassle of rolling back — any tips there? If I can eliminate the rpi boot loader and magically get a boot-time menu of generations then I can test more easily.
(I managed to switch over to a boot menu with u-boot now, at least.)
raspberryPi loader
How does that look like in a config?
As for testing, I first did a nixos-rebuild dry-build
and after that was working I built an image which a flashed onto an SD card I use for testing and from there I then built the config on my notebook and pushed it to the test Pi until everything was working.
Afterwards I swapped the "production" SD card back in.
How does that look like in a config?
boot.loader.raspberryPi.enable = true
But that's the boot loader mode where it dumps the latest boot files into the VFAT boot partition, with no grub or extlinux, and therefore no rollbacks. My Pi was like this as an historical accident — not recommended!
and pushed it to the test Pi until everything was working.
So you're completely re-imaging the Pi each time, or how does that work? (This is getting off-topic, sorry, but just curious.)
For my part, I just nixos-rebuild
on the Pi itself, rather than trying to cross-build from my M2 Mac.
But that's the boot loader mode where it dumps the latest boot files into the VFAT boot partition, with no grub or extlinux, and therefore no rollbacks. My Pi was like this as an historical accident — not recommended!
Ah right I see, really not an optimal setup.
So you're completely re-imaging the Pi each time, or how does that work? (This is getting off-topic, sorry, but just curious.)
No, no this was just for testing the 23.05 image. I could roll back but since I had a spare SD card it was safer just to swap it.
Usually I just push the config with the following script, since 22.11 aarch64-linux is binary cached and I don't really have to compile much on my notebook. And I'm not 100% sure but it could be that I safe some space on the Pis, they only have 64GB each and most have less than 10 GB used. Is there even a lot of overhead when building on an M2 Mac for aarch64-linux?
https://git.2li.ch/Nebucatnetzer/nixos/src/branch/2305/scripts/remote_switch.sh#L34
This is getting off-topic, sorry, but just curious.
Right, please excuse, everyone :)
I can confirm the problems and that the RPi4 boots and runs on NixOS 23.05 without nixos-hardware and just with the modules from the comment from @Nebucatnetzer. Although I haven't yet tried a graphical desktop, video acceleration, audio, etc., I will report back once I do.
But that's the boot loader mode where it dumps the latest boot files into the VFAT boot partition, with no grub or extlinux, and therefore no rollbacks. My Pi was like this as an historical accident — not recommended!
If I'm not mistaken, even that only works if the FAT firmware partition is mounted on /boot
, which it isn't by default. The NixOS SD images doesn't mount the firmware partition at all...
If you're interested, I have written some stuff about bootloader config on an RPi with NixOS and deploying remotely onto it here: https://www.eisfunke.com/article/nixos-on-raspberry-pi.html, although that's about a RPi 3, it applies similarly to the 4.
I've documented my install for the 4 as well, where I used an entirely different approach to booting. I mentioned this issue there as well: https://www.eisfunke.com/article/nixos-on-raspberry-pi-4.html
Although I haven't yet tried a graphical desktop, video acceleration, audio
Audio works for me with Nebucatnetzer
's settings. Accelerated desktop not.
I also tried to change the device tree filter to only match the raspberry pi 4 (and in my case 400). Unfortunately, I could not get this to run in any configuration, as the vc4 kernel module would always create oopses on loading and I would always get a black screen, with none of the usual fixes working.
In particular vc4
isn't ever loaded, /dev/dri
are empty. Upon modprobe vc4
the initial kernel oops is like so:
[ 45.346364] # Subtest: vc4-pv-muxing-combinations
[ 45.346380] 1..2
[ 45.346387] # Subtest: drm_vc4_test_pv_muxing
[ 45.353717] [drm] Initialized vc4 0.0.0 20140616 for drm-kunit-mock-device on minor 0
[ 45.353842] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058
[ 45.353905] Mem abort info:
[ 45.353972] ESR = 0x0000000096000005
[ 45.354000] EC = 0x25: DABT (current EL), IL = 32 bits
[ 45.354042] SET = 0, FnV = 0
[ 45.354060] EA = 0, S1PTW = 0
[ 45.354078] FSC = 0x05: level 1 translation fault
[ 45.354105] Data abort info:
[ 45.354120] ISV = 0, ISS = 0x00000005
[ 45.354137] CM = 0, WnR = 0
[ 45.354153] user pgtable: 4k pages, 39-bit VAs, pgdp=000000006221b000
[ 45.354179] [0000000000000058] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[ 45.354226] Internal error: Oops: 0000000096000005 [#1] SMP
[ 45.354251] Modules linked in: vc4 snd_soc_hdmi_codec drm_kunit_helpers cec drm_dma_helper drm_display_helper drm_kms_helper snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine kunit wireguard libchacha20poly1305 chacha_neon poly1305_neon libcurve25519_generic libchacha ip6_udp_tunnel udp_tunnel nfnetlink 8021q garp btsdio bluetooth ecdh_generic ecc libaes brcmfmac joydev bcm2835_codec(C) bcm2835_v4l2(C) bcm2835_isp(C) rpivid_hevc(C) brcmutil v4l2_mem2mem bcm2835_mmal_vchiq(C) snd_bcm2835(C) videobuf2_vmalloc cfg80211 videobuf2_dma_contig nls_cp437 videobuf2_memops videobuf2_v4l2 snd_pcm videobuf2_common videodev snd_timer rfkill snd raspberrypi_hwmon crct10dif_ce mc vc_sm_cma(C) nvmem_rmem uio_pdrv_genirq uio sch_fq_codel atkbd libps2 serio vivaldi_fmap tun tap macvlan bridge drm stp llc fuse backlight efi_pstore ip_tables x_tables xhci_pci xhci_pci_renesas dm_mod dax
[ 45.354670] CPU: 1 PID: 1873 Comm: kunit_try_catch Tainted: G C N 6.1.21 #1-NixOS
[ 45.354767] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
[ 45.354819] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 45.354853] pc : vc4_hvs_get_fifo_frame_count+0xa4/0xf4 [vc4]
[ 45.354998] lr : vc4_hvs_get_fifo_frame_count+0x48/0xf4 [vc4]
[ 45.355068] sp : ffffffc009253ce0
[ 45.355083] x29: ffffffc009253ce0 x28: 0000000000000000 x27: 0000000000000000
[ 45.355124] x26: 0000000000000000 x25: ffffff8047f5a168 x24: 00000000ffffffff
[ 45.355161] x23: ffffff804ac53e98 x22: 0000000000000038 x21: ffffff804ac53c80
[ 45.355197] x20: 0000000000000000 x19: 0000000000000058 x18: ffffffffffffffff
[ 45.355227] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 45.355256] x14: 0000000000000040 x13: 0000000000000000 x12: 0000000000000000
[ 45.355286] x11: 0000000000000000 x10: ffffff804bfb6800 x9 : ffffffd84f392f44
[ 45.355315] x8 : ffffffd84f3ec000 x7 : 0000000000000000 x6 : 0000000000000000
[ 45.355345] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
[ 45.355377] x2 : ffffffa8a7a20000 x1 : 0000000000000000 x0 : 0000000000000001
[ 45.355409] Call trace:
[ 45.355429] vc4_hvs_get_fifo_frame_count+0xa4/0xf4 [vc4]
[ 45.355517] vc4_hvs_mark_dlist_entry_stale+0x50/0x14c [vc4]
[ 45.355638] vc4_crtc_destroy_state+0x30/0x50 [vc4]
[ 45.355708] drm_atomic_state_default_clear+0x11c/0x344 [drm]
[ 45.355978] __drm_atomic_state_free+0x80/0xbc [drm]
[ 45.356112] vc4_pv_muxing_test_exit+0xac/0xc0 [vc4]
[ 45.356205] kunit_try_run_case+0x60/0xb0 [kunit]
[ 45.356246] kunit_generic_run_threadfn_adapter+0x28/0x34 [kunit]
[ 45.356282] kthread+0xe0/0xe4
[ 45.356314] ret_from_fork+0x10/0x20
[ 45.356344] Code: d50323bf d65f03c0 f9400ab3 91016273 (b9400273)
[ 45.356381] ---[ end trace 0000000000000000 ]---
Seems like an upstream issue, although I'd be interested which fixes there might be.
Although I haven't yet tried a graphical desktop, video acceleration, audio
Audio works for me with
Nebucatnetzer
's settings. Accelerated desktop not.I also tried to change the device tree filter to only match the raspberry pi 4 (and in my case 400). Unfortunately, I could not get this to run in any configuration, as the vc4 kernel module would always create oopses on loading and I would always get a black screen, with none of the usual fixes working.
In particular
vc4
isn't ever loaded,/dev/dri
are empty. Uponmodprobe vc4
the initial kernel oops is like so:[ 45.346364] # Subtest: vc4-pv-muxing-combinations [ 45.346380] 1..2 [ 45.346387] # Subtest: drm_vc4_test_pv_muxing [ 45.353717] [drm] Initialized vc4 0.0.0 20140616 for drm-kunit-mock-device on minor 0 [ 45.353842] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [ 45.353905] Mem abort info: [ 45.353972] ESR = 0x0000000096000005 [ 45.354000] EC = 0x25: DABT (current EL), IL = 32 bits [ 45.354042] SET = 0, FnV = 0 [ 45.354060] EA = 0, S1PTW = 0 [ 45.354078] FSC = 0x05: level 1 translation fault [ 45.354105] Data abort info: [ 45.354120] ISV = 0, ISS = 0x00000005 [ 45.354137] CM = 0, WnR = 0 [ 45.354153] user pgtable: 4k pages, 39-bit VAs, pgdp=000000006221b000 [ 45.354179] [0000000000000058] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 45.354226] Internal error: Oops: 0000000096000005 [#1] SMP [ 45.354251] Modules linked in: vc4 snd_soc_hdmi_codec drm_kunit_helpers cec drm_dma_helper drm_display_helper drm_kms_helper snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine kunit wireguard libchacha20poly1305 chacha_neon poly1305_neon libcurve25519_generic libchacha ip6_udp_tunnel udp_tunnel nfnetlink 8021q garp btsdio bluetooth ecdh_generic ecc libaes brcmfmac joydev bcm2835_codec(C) bcm2835_v4l2(C) bcm2835_isp(C) rpivid_hevc(C) brcmutil v4l2_mem2mem bcm2835_mmal_vchiq(C) snd_bcm2835(C) videobuf2_vmalloc cfg80211 videobuf2_dma_contig nls_cp437 videobuf2_memops videobuf2_v4l2 snd_pcm videobuf2_common videodev snd_timer rfkill snd raspberrypi_hwmon crct10dif_ce mc vc_sm_cma(C) nvmem_rmem uio_pdrv_genirq uio sch_fq_codel atkbd libps2 serio vivaldi_fmap tun tap macvlan bridge drm stp llc fuse backlight efi_pstore ip_tables x_tables xhci_pci xhci_pci_renesas dm_mod dax [ 45.354670] CPU: 1 PID: 1873 Comm: kunit_try_catch Tainted: G C N 6.1.21 #1-NixOS [ 45.354767] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT) [ 45.354819] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 45.354853] pc : vc4_hvs_get_fifo_frame_count+0xa4/0xf4 [vc4] [ 45.354998] lr : vc4_hvs_get_fifo_frame_count+0x48/0xf4 [vc4] [ 45.355068] sp : ffffffc009253ce0 [ 45.355083] x29: ffffffc009253ce0 x28: 0000000000000000 x27: 0000000000000000 [ 45.355124] x26: 0000000000000000 x25: ffffff8047f5a168 x24: 00000000ffffffff [ 45.355161] x23: ffffff804ac53e98 x22: 0000000000000038 x21: ffffff804ac53c80 [ 45.355197] x20: 0000000000000000 x19: 0000000000000058 x18: ffffffffffffffff [ 45.355227] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 45.355256] x14: 0000000000000040 x13: 0000000000000000 x12: 0000000000000000 [ 45.355286] x11: 0000000000000000 x10: ffffff804bfb6800 x9 : ffffffd84f392f44 [ 45.355315] x8 : ffffffd84f3ec000 x7 : 0000000000000000 x6 : 0000000000000000 [ 45.355345] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001 [ 45.355377] x2 : ffffffa8a7a20000 x1 : 0000000000000000 x0 : 0000000000000001 [ 45.355409] Call trace: [ 45.355429] vc4_hvs_get_fifo_frame_count+0xa4/0xf4 [vc4] [ 45.355517] vc4_hvs_mark_dlist_entry_stale+0x50/0x14c [vc4] [ 45.355638] vc4_crtc_destroy_state+0x30/0x50 [vc4] [ 45.355708] drm_atomic_state_default_clear+0x11c/0x344 [drm] [ 45.355978] __drm_atomic_state_free+0x80/0xbc [drm] [ 45.356112] vc4_pv_muxing_test_exit+0xac/0xc0 [vc4] [ 45.356205] kunit_try_run_case+0x60/0xb0 [kunit] [ 45.356246] kunit_generic_run_threadfn_adapter+0x28/0x34 [kunit] [ 45.356282] kthread+0xe0/0xe4 [ 45.356314] ret_from_fork+0x10/0x20 [ 45.356344] Code: d50323bf d65f03c0 f9400ab3 91016273 (b9400273) [ 45.356381] ---[ end trace 0000000000000000 ]---
Seems like an upstream issue, although I'd be interested which fixes there might be.
Same here on KMS (not just FKMS) and linuxKernel.kernels.linux_rpi4
of version 6.1.21-1.20230405
.
What are some things we could try in order to debug or fix this? Some thoughts I have which might be completely uninformed and off-base:
linux_rpi4
package doesn't work out of the box, is there a compatibility mismatch with the DTOs in raspberrypifw
? Did you try those, @WizardUli? I'm guessing they need to be specified, since afaict the kernel package says nothing about the overlays to use.raspberrypifw
? Again, we'd perhaps need to specify them?dtoverlay=vc4-fkms-v3d-pi4
What are some things we could try in order to debug or fix this? Some thoughts I have which might be completely uninformed and off-base:
* Is this perhaps even a known issue with that kernel version on the Pi? * Given that even the `linux_rpi4` package doesn't work out of the box, is there a compatibility mismatch with the DTOs in `raspberrypifw`? Did you try those, @WizardUli? I'm guessing they need to be specified, since afaict the kernel package says nothing about the overlays to use. * With the stock kernel, would we also expect to use and enable the DTOs distributed in `raspberrypifw`? Again, we'd perhaps need to specify them? * Does it work/help/inform to explicitly load an overlay, e.g. with `dtoverlay=vc4-fkms-v3d-pi4`
nixos-hardware
at all right now).raspberrypifw
.linux_rpi4
output.. i.e. "${config.boot.kernelPackages.kernel}/dtbs/overlays/vc4-kms-v3d-pi4.dtbo"
(where the config.boot.kernelPackages
is actually the linux_rpi4
in my setup). There is no incompatibility. Those DTBOs are built literally from the same tarball downloaded from github as the kernel itself.dtmerge
utility while also applying overlays params).AFAIK this may be an upstream bug as well as wrong combination of kernel (def)config, patches and selected DTBOs (and possibly their parameters which dtmerge applies (or not if you are using merging algorithm from here).
There's also no way for me to use dtoverlay=vc4-fkms-v3d-pi4
- which AFAIK is parameter for Raspberry's bootloader which literally incorporates dtmerge
functionality - because I'm not using it. I'm using uboot.
What can be done is to check and match Raspbery OS's latest kernel version & kernel config & apply same overlays & with same overlay params and if it works then go from there and try to narrow down where the problem is.
I plan to create a copy of linux_rpi4
package and start matching those mentioned things to Raspberry OS's latest on the weekend if no one else solve this before then.
does anybody know what the
.in
extension means?
Sounds like GNU autotools stuff? Some people use these as template files for (IIRC) configure
to generate the final file (same filename with .in
stripped away)
I encounter the same problem.
Compared to the tutorial config https://tinyurl.com/nixos-rpi4-tutorial, I have to comment the following line:
# hardware.raspberry-pi."4".fkms-3d.enable = true;
This lets me install nixOS and boot into it without problems. I don't have to comment hardware.pulseaudio.enable = true;
. Investigating further..
Uhm, excuse my ignorance. With hardware.raspberry-pi."4".apply-overlays-dtmerge.enable = true
the error changes to indicate the symbol 'fb' wasn't found. When modifying hardware.deviceTree.overlays
and removing the first fragment from rpi4-vc4-fkms-v3d-overlay
, it cannot find the symbol 'firmwarekms'. When also removing the second fragment, it builds the device tree just fine. However, I don't understand what the implications are and hope it rings a bell with some knowledgeable person.
Hello, what is the current status on this? I am trying to install nixos on a Raspi 4b as well and ran into the same issue. Setting fmks-3d.enabled
to true in an attempt to enable GPU acceleration errors saying fb is not found, enabling drmerge gives the same error phrased a different way. Is there a workaround/fix found yet?
Okay, I don't know what I did, but now it builds fine, except that if I enable the 3D overlay, it boots with a blank screen. Otherwise things like the poe+ hat works. And if I include <nix-hardware/raspberry-pi/4> in the config at all, the graphical environment doesn't show. Going into tty if 3d overlay is off and said blank screen if overlay is true.
Hi, also had no luck on either 23.05 nor 23.11 ...
Recent updates still seem to include some changes that are may causing compatibility problems i assume? By reverting to a last known stable build, i'd hope to restore functionality while avoiding any potential bugs that were introduced in the later versions....
@purcell would you be so kind and let me know of any working version(s) which i could down/upgrade to ? (kernel support for 6.1 or higher would be great!) @Ciel-MC could you share some more insights on your configuration and how you've fixed it ?
Thanks in advance for your time!
Hi, also had no luck on either 23.05 nor 23.11 ...
Recent updates still seem to include some changes that are may causing compatibility problems i assume? By reverting to a last known stable build, i'd hope to restore functionality while avoiding any potential bugs that were introduced in the later versions....
@purcell would you be so kind and let me know of any working version(s) which i could down/upgrade to ? (kernel support for 6.1 or higher would be great!) @Ciel-MC could you share some more insights on your configuration and how you've fixed it ?
Thanks in advance for your time!
Honestly I don't know what I did 😅, just one time randomly it decided to compile. But it is far from being fixed, the X server would simply refuse to work if I have nixos-hardware/raspberry-pi/4 included at all. But if I don't include it, the fans on the poe+ hat don't spin and the entire thing ends up being super hot. I have tried manually setting up (kms?) was it with the guidance of someone in the unofficial Discord, since apparently nixos-hw is using fkms which is like outdated, but still no luck, the behavior was exactly the same, X server doesn't start, and if I start it manually, it just freezes. So now I am stuck with either get desktop with no fans, or fans but only tty.
@purcell would you be so kind and let me know of any working version(s) which i could down/upgrade to ?
@Just-Ch33s3 I'm pinned to these pre-breakage versions, personally:
inputs = {
nixpkgs.url = "github:nixos/nixpkgs?rev=29339c1529b2c3d650d9cf529d7318ed997c149f";
nixos-hardware.url = "github:nixos/nixos-hardware?rev=ca29e25c39b8e117d4d76a81f1e229824a9b3a26";
};
Hi, also had no luck on either 23.05 nor 23.11 ...
Recent updates still seem to include some changes that are may causing compatibility problems i assume? By reverting to a last known stable build, i'd hope to restore functionality while avoiding any potential bugs that were introduced in the later versions....
@purcell would you be so kind and let me know of any working version(s) which i could down/upgrade to ? (kernel support for 6.1 or higher would be great!) @Ciel-MC could you share some more insights on your configuration and how you've fixed it ?
Thanks in advance for your time!
Honestly I don't know what I did 😅, just one time randomly it decided to compile. But it is far from being fixed, the X server would simply refuse to work if I have nixos-hardware/raspberry-pi/4 included at all. But if I don't include it, the fans on the poe+ hat don't spin and the entire thing ends up being super hot. I have tried manually setting up (kms?) was it with the guidance of someone in the unofficial Discord, since apparently nixos-hw is using fkms which is like outdated, but still no luck, the behavior was exactly the same, X server doesn't start, and if I start it manually, it just freezes. So now I am stuck with either get desktop with no fans, or fans but only tty.
I also have a RP4 and my fan works just fine. I submitted a PR here, too, to fix the POE hat with the Linux kernel update.
I don't have my computer here right now, but I'll post my config later
Edit:
Thanks for your fast reply and your config later on @gador !
that did the trick @purcell !
thanks for leading me to the correct path! 👍 👍 👍
that did the trick @purcell !
thanks for leading me to the correct path! 👍 👍 👍
How did you change the version of nixos-hardware to use? Sorry, I'm not very familiar with this.
@Ciel-MC haha was about to edit my post rn, keep it in mind its a dirty workaround, @purcell 's solution is far better, to implement it right in the configuration, but here you go;
(nix-channel --list) nix-channel --remove nixos nix-channel --add https://github.com/NixOS/nixpkgs/archive/29339c1529b2c3d650d9cf529d7318ed997c149f.tar.gz nixos nix-channel --remove nixos-hardware nix-channel --add https://github.com/NixOS/nixos-hardware/archive/ca29e25c39b8e117d4d76a81f1e229824a9b3a26.tar.gz nixos-hardware nix-channel --update (nix-channel --list)
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/failed-attempts-to-install-nixos-on-the-raspberry-pi-4/30681/7
Related documented case here: https://mtlynch.io/notes/nixos-pi4-failed-attempts/
@WizardUli Since it sounds from your comment above like you've had some success with applying overlays selectively yourself, I wonder if you have a config (or snippets) you could share?
@WizardUli Since it sounds from your comment above like you've had some success with applying overlays selectively yourself, I wonder if you have a config (or snippets) you could share?
Something like this https://github.com/NixOS/nixos-hardware/issues/262#issuecomment-1540135363 ?
I haven't had time to do what I said in the last two sentences in https://github.com/NixOS/nixos-hardware/issues/631#issuecomment-1591841464 which is what have to be done IMO. Nix on Pi is essential for several of my projects but there's some other work to be done on those and other projects but I'm going to get to it eventually in a month or six unless hopefully somebody else solves it by then :D
For me the solution was to make two changes:
hardware.deviceTree.filter = "bcm2711-rpi-4*.dtb";
to exclude the cm4 variants device trees, since the fkms-3d overlays did not apply thereCONFIG_KUNIT=n
, which fixed the Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058
crash also reported in https://github.com/NixOS/nixos-hardware/issues/631#issuecomment-1585757552. I submitted this to nixpkgs: https://github.com/NixOS/nixpkgs/pull/247826@yu-re-ka: Thanks for sharing! I guess you mean this allowed you to build and run a newer Nixpkgs with the nixos-hardware
overlays, but what hardware is working for you after that? Do you have video acceleration, for example, and is the config in nixos-hardware
providing a benefit for you?
This is with the nixos-hardware profile imported and hardware.raspberry-pi."4".fkms-3d.enable = true;
on a Raspberry Pi 4B. So yes, with hardware accelerated graphics.
@yu-re-ka I'm assuming this requires a rebuild of the kernel because of what you ultimately had to edit?
btw do you have an overlay where you have edited CONFIG_KUNIT=n ?
I tried for a few moments to figure out how to get the override right but got distracted.
Yes, this requires rebuilding the kernel (would not recommend trying that on the Raspberry Pi, I built it on another aarch64 machine and then copied it over)
I don't have an overlay, but instead you can specify my branch when building the system:
when building with flakes: --override-input nixpkgs github:yu-re-ka/nixpkgs/rpi4-no-kunit
when building without flakes: -I nixpkgs=https://github.com/yu-re-ka/nixpkgs/archive/rpi4-no-kunit.tar.gz
Obviously, once the PR linked above has been merged, you will no longer need to rebuild the kernel.
anyone who wants to work around the crash without recompiling can use this:
boot.kernelParams = [ "kunit.enable=0" ];
Unfortunately, with including latest `nixos-hardware, and the settings you provided @yu-re-ka - plus the kcmdline, I get a new error:
warning: Git tree '/etc/nixos' is dirty
building the system configuration...
warning: Git tree '/etc/nixos' is dirty
error: builder for '/nix/store/ddnxv8l1ngbdxgg2v4znh9f56bjnliqm-device-tree-overlays.drv' failed with exit code 1;
last 6 log lines:
> ./broadcom -> /nix/store/jgbs3gvv4lrq9gdn5m3032v76nj8nqmy-device-tree-overlays/./broadcom
> './broadcom/bcm2711-rpi-400.dtb' -> '/nix/store/jgbs3gvv4lrq9gdn5m3032v76nj8nqmy-device-tree-overlays/./broadcom/bcm2711-rpi-400.dtb'
> './broadcom/bcm2711-rpi-4-b.dtb' -> '/nix/store/jgbs3gvv4lrq9gdn5m3032v76nj8nqmy-device-tree-overlays/./broadcom/bcm2711-rpi-4-b.dtb'
> Applying overlay rpi4-cma-overlay to bcm2711-rpi-400.dtb... ok
> Applying overlay rpi4-vc4-fkms-v3d-overlay to bcm2711-rpi-400.dtb...
> Failed to apply '/nix/store/pwh10249gllri428w872y8zn65jv1ml5-rpi4-vc4-fkms-v3d-overlay-dtbo': FDT_ERR_NOTFOUND
For full logs, run 'nix log /nix/store/ddnxv8l1ngbdxgg2v4znh9f56bjnliqm-device-tree-overlays.drv'.
error: 1 dependencies of derivation '/nix/store/8q32kcyvj05lwmdyxqmlrmmn7z9pxn4m-nixos-system-SMITH-LINUX-23.05.20230807.011567f.drv' failed to build```
I'll post a config as soon as I sanitise it.
I have not tested this with nixos 23.05. Only nixpkgs master.
Also make sure you have the correct kernel: boot.kernelPackages = pkgs.linuxPackages_rpi4;
- which is set by the nixos-hardware profile, but maybe you also set it somewhere else?
@yu-re-ka Thanks, setting boot.kernelParams = [ "kunit.enable=0" ];
got hardware acceleartion working for me again!
I have
hardware.raspberry-pi."4".fkms-3d.enable = true;
and found that the deviceTree failed to build with recentunstable
Nixpkgs. The error was the generic "FDT_..." one which wasn't very helpful.This build failure happened both before and after #627, a recent PR from @gador which updated some of the device tree overlays for compatibility with the 6.x kernel.
modesetting.nix
still looks reasonable w.r.t. the latest upstream definition of the overlay (though I note there's also a neighbouring version of this labelled-pi4
, which looks quite different) so I tried changing the device tree filter inraspberry-pi/4/default.nix
too, as was done in #627 (adding the-4*
in the filter pattern). However, the resulting system wasn't bootable, for reasons I couldn't fathom. Debugging it all has been a bit beyond me, and I resorted to painstakingly restoring an older working boot configuration. Any pointers welcome!