Various: Add support for raspberry pi 4. #68265
Conversation
ofborg
bot
added
6.topic: nixos
8.has: module (update)
8.has: clean-up
8.has: package (new)
labels
The last time I checked (a couple weeks ago) u-boot were waiting on the mainline kernel to produce a device tree file, so that u-boot could sync theirs from the mainline kernel. I'm not sure this is the latest patch set. AFAIK it means it's mostly a question of time, and that mainline and u-boot support should coincide nicely.
This is a hard situation. The Though with that said, we shouldn't make it harder than necessary to build an image for the Raspberry Pi 4. What I was considering, in the past few weeks, is to have a raspberry-pi specific image builder, that doesn't rely on u-boot, but rather on the specific raspberry pi boot chain. The main drawback would be the loss of generation selection at boot, but if we're careful, it may produce images that are easier to deal with the raspberry pi-isms compared to u-boot and its generic handling of things. Thoughts? |
|
That seems reasonable. I didn't look deep enough to realise the sd images were generic, I just did a I agree that waiting for a mainline uboot probably makes sense, and an interim rpi4 specific sd card builder may make sense. I may look into how to do that next week. |
|
I've added an sd image builder, that builds a sensible-looking image, which is yet untested (I'll check later today). |
|
To better answer your question, Though this in itself doesn't add it to the tested jobset, which is what is used for channel advances. |
|
The current sd image doesn't boot - I'll have to look into why not, at a glance, I can't tell what's different to my known working config. |
tkerber
force-pushed
the
rpi4
branch
2 times, most recently
from
c102a6e
to
2989a21
Compare
|
Turns out I should have actually used the right kernel 🙄 The latest push builds an image with boots fine. |
|
Yes, just verified, it boots fine. Do you have X11 running? if so, what else did you need to do? I'm trying to use modesetting / vc4, but can't seem to have drm and vc4 working. I tried a couple things, searched around online about whether the raspberry pi foundation fork should work (it should), but haven't found clues yet. (Though, to be fair, I stopped mostly as I was frustrated by the slowness of the SD card.) |
|
I think the only thing I did to get X11 booting was set { pkgs, ... }:
{
hardware.opengl = {
enable = true;
setLdLibraryPath = true;
package = pkgs.mesa_drivers;
};
boot.loader.raspberryPi.firmwareConfig = ''
dtoverlay=vc4-fkms-v3d
gpu_mem=192
'';
} |
:/ that's what I did, and X11 doesn't start, doesn't see any screen.
Yes, that's a known irritating thing from the ecosystem.
Here, does "upstream" mean the raspberry pi foundation, or the mainline kernel? Tested by adding the config fragment from the last comment: |
|
Hmm... I'll look into this. I dimly remember having a similar issue, and fixing it in my own config. I just have to figure out which part is the fix :p Scratchpad for ideas on what could be going on:
Update 1:
|
|
Alright, I misunderstood how overlays are supposed to work in nixos, and the non-uboot builder wasn't set up to deal with them. I've pushed fixes to this, and have been able to get an sdcard booting into xorg both with and without gpu acceleration: Without GPU{ pkgs, ... }:
{
imports = [ <nixpkgs/nixos/modules/installer/cd-dvd/sd-image-raspberrypi4.nix> ];
networking.wireless.enable = false;
services.xserver = {
enable = true;
displayManager.slim.enable = true;
desktopManager.gnome3.enable = true;
videoDrivers = [ "fbdev" ];
};
}With GPU{ pkgs, ... }:
{
imports = [ <nixpkgs/nixos/modules/installer/cd-dvd/sd-image-raspberrypi4.nix> ];
networking.wireless.enable = false;
hardware.opengl = {
enable = true;
setLdLibraryPath = true;
package = pkgs.mesa_drivers;
};
hardware.deviceTree = {
base = pkgs.device-tree_rpi;
overlays = [ "${pkgs.device-tree_rpi.overlays}/vc4-fkms-v3d.dtbo" ];
};
services.xserver = {
enable = true;
displayManager.slim.enable = true;
desktopManager.gnome3.enable = true;
videoDrivers = [ "modesetting" ];
};
boot.loader.raspberryPi.firmwareConfig = ''
gpu_mem=192
'';
}I don't believe either of these should be in this PR directly, although the information should definitely go in the wiki once this is merged. |
| @@ -11,7 +11,7 @@ stdenvNoCC.mkDerivation { | |||
|
|
|||
| cp ${raspberrypifw}/share/raspberrypi/boot/bcm*.dtb . | |||
|
|
|||
| cp bcm2708-rpi-0-w.dtb bcm2835-rpi-zero-w.dtb | |||
| cp bcm2708-rpi-zero-w.dtb bcm2835-rpi-zero-w.dtb | |||
There was a problem hiding this comment.
Here's where the change comes from:
I don't know if we want this to handle both possibilities of an older downstream kernel with the older name for the dtb or not.
There was a problem hiding this comment.
Intesting. Here the dtb's are grabbed from raspberrypifw however, which just consists of binary blobs. Makes me question if that's the right approach, but for now, the firmware package has only one version in the repo, and it's quite unlikely anyone will override it with an older version, imo.
There was a problem hiding this comment.
Yeah, that was my thought too. I wasn't sure how likely a user would rely on an older kernel revision, while using a newer nixpkgs. Unlikely I guess, and at that point, they may as well patch this package in their overlay.
|
Great work! Is there anything stopping it getting merged? |
|
Quick note, as a de-facto lead on ARM stuff.
This is a convenience for the arguably most popular aarch64 platform, and we don't intend to add and keep board-specific builders in Nixpkgs. Generic and mainline support is preferred. |
|
thanks for this, just as i'm about to setup my pi4 this hit the repo, so i can go for a nix setup - made my day - you are awesome |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/boot-loader-raspberrypi-deprecated/30694/3 |
Motivation for this change
Run NixOS on the Raspberry Pi 4B #63720. I'm reopening as the WiFi / 4G issues are resolved in the rpi kernel branch now.
This pull request has breaking changes that need feedback!
Changes Mage:
linux_rpi, which uses differentdefconfigsettings depending on architecture. The rpi4 has the same architecture as the rpi3, but should use a differentdefconfigsetting. I cannot see how to modify the current kernel package backwards-compatibly to do this. As a result, I've split it into several. Feedback on this would be good. It will break any existing builds using this kernel.Outstanding issues:
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nix-review --run "nix-review wip"./result/bin/)nix path-info -Sbefore and after)Notify maintainers
cc @lopsided98 @dezgeg @tavyc