Testing reports

[gnull]

Submit here what worked and what didn't work on your device when using this flake.

Be sure to include:

• board model,
• flake version you used,
• bootloader you use,
• relevant details of your NixOS config.

As I have only Orange Pi 5 Plus and I only test the changes on it, this thread will help me know what works on other boards.

[axunes]

I tried the opi5plus flake (main branch) with my orange pi 5 max, using whatever bootloader armbian installed for me. surprisingly it booted and the hdmi worked, but ethernet and usb appeared to be non-functional. if you have something you want me to try on it, I'm always available to test

[Redhawk18]

This flake won't build anymore due to that kernel going end of life.

[gnull]

@Redhawk18 The linuxPackages_6_17 or linuxPackages_6_18 should be available in nixpkgs 25.11. These worked for me on OPi5 plus, but as I understand, those upstream kernels don't yet have DTS files for 5 Pro.

I checked the tarballs from https://www.kernel.org/ (Nixpkgs seems to be using them) and looked for DTS files under arch/arm64/boot/dts/rockchip/rk3588-orangepi-5* path there. The https://github.com/Joshua-Riek/linux-rockchip fork we use now, on the other hand, has the DTS files, this is one reason I haven't switched to upstream kernel for now.

[Redhawk18]

Is there a rockchip kernel in nixpkgs?

[Redhawk18]

I also don't see the dtb's for the pro in either the forked or upstream kernel.

upstream kernel

[gnull]

This is the DTS from the fork we use (it's rk3588s).

I couldn't find any rockchip-specific kernel forks in Nixpkgs. I think they just use upstream.

[Redhawk18]

I have an orange pi 5 pro and haven't tried that flake yet, but both the orange pi 5 and plus 5 image do not work.

[gnull]

Interesting, I'll have a look at them. How did you build the generic one, more specifically?

[Redhawk18]

I hope this was the right command

nix build github:ryan4yin/nixos-rk3588/2024092600#sdImage-opi5

I think I just got confused, this is building via qemu

[gnull]

If you want to test the PR #8 I just made for OPi 5 Pro, try this

nix build github:gnull/nixos-rk3588/opi5-pro#sdImage-opi5pro

Put #sdImage-opi5pro-cross instead of #sdImage-opi5pro if your build machine is not aarch64.

If you want to try the OPi5 (non Pro) image, put #sdImage-opi5 or #sdImage-opi5-cross instead. The cross and non-cross versions only differ in what machine they are expected to be built on, their resulting images should be the same.

The command you show uses the original repo of ryan4yin, not my fork. Did you find it somewhere in the docs? Maybe I forgot to change it when forking.

Ryan4yin has also published some prebuilt images. They're only for OPi 5 and OPi5 Plus. They are more or less the same as what you get with nix build github:gnull/nixos-rk3588/main#sdImage-opi5 today.

[gnull]

I guess the non-cross version could trigger qemu-user on x86 if you have binfmt set up, yeah ☺.

[Redhawk18]

Yeah in both the uboot and uefi you refer to ryan's flake, I thought it was weird but trusted you, the blame on the flake was old as well.

[natrow]

Board model: Orange Pi 5
Flake version: sdImage-opi5 (non-cross, main branch)
Bootloader: Vendor bootloader from google drive
NixOS config: TODO

Had some trouble getting board to detect NVME. With this flake and the VENDOR version of u-boot I was able to get it to work. The current armbian stable version (ubuntu gnome) weren't able to detect it, this seems to be a regression. OPi OS (Arch) also detected the drive which is the only reason I didn't give up.

Do you have any tips for starting the config? Do I just copy the example flake and start from there, or do I modify the sdImage somehow?

[gnull]

Did you manage to boot NVMe with this flake? Is it only an Armbian regression or is there one here too?

Below is my answer for U-Boot. Let me know if you specifically want a UEFI setup, it also works but is a bit more nuanced.

About making a config: Do you want vendor kernel of this flake specifically? If you're ok with the upstream kernel, start with this minimal config (it does not use this flake, just pure nixpkgs). Otherwise, if you want the vendor kernel we provide here, then create a new flake, add this flake nixos-rk3588 to inputs, define a regular nixosConfigurations.yourHostname = nixpkgs.lib.nixosSystem {, and make it import these modules:

modules = [
  nixos-rk3588.nixosModules.boards.orangepi5.core
  nixos-rk3588.nixosModules.boards.orangepi5.sd-image
];

The rest of the config is up to you. This will essentially make a customized version of sdImage-opi5 with your own settings. You can use this new system config to run nixos-rebuild boot --flake .#yourHostname on the board. Or you can use it to make an SD card image like so:

# add this to your flake
packages = {
  your-sdImage-opi5 = self.nixosConfigurations.yourHostname.config.system.build.sdImage;
}

and running nix build .#your-sdImage-opi5 in your flake.

Another example you of importing this flake and using in your own is Demo we have in this repo. It's a bit more advanced since it uses Colmena for remote deployments, but you may find snippets to borrow from there.

[natrow]

Did you manage to boot NVMe with this flake? Is it only an Armbian regression or is there one here too?

Yes this flake worked once I flashed the vendor version of u-boot to the SPI flash and used the vendor kernel, just building the sdImage from this flake.

Thanks for the config tips! I started writing a config based on the demo. Edit: I didn't realize I should use nixos-generate-config after installing to get a default configuration

[natrow]

Update: I've noticed one issue so far with the Orange Pi 5. The board seems randomize its MAC address each boot, preventing a static DHCP assignment from working. It can be fixed with networking.networkmanager.ethernet.macAddress = <fixed address>.

[gnull]

It sounds like something caused by other NixOS packages you use (network manager maybe?), not this flake. I'm using systemd-networkd instead of network manager, and the MAC stays the same. I looked for NixOS system config options that menton macAddress, they all seem to preserve it by default, but something else you use could indirectly maybe change those options.

[natrow]

I think the MAC address thing is either a hardware bug or a u-boot bug, either way not caused by the flake. I noticed it even on the sdImage with all the default flake settings.

See:

• https://www.reddit.com/r/OrangePI/comments/14sleyi/orange_pi_5_mac_address_keeps_changing/
• Orange Pi 5 | MAC address changes on reboot MichaIng/DietPi#6663
• https://forum.armbian.com/topic/28005-mac-adress-change-everyboot-orange-5/
• https://forum.openmediavault.org/index.php?thread/50181-omv-on-orange-pi-5-and-dynamic-mac-address-solution-kind-of/

Since I had issues with other u-boot builds not detecting my NVME, fixing it with networkmanager is good enough for now.

Anyways, I just got Jellyfin to live transcode with this board! See the following config snippet:

{ config, pkgs, nixos-rk3588, ... }:
{
  # use podman container for libmali driver
  virtualisation.podman.enable = true;
  virtualisation.oci-containers.containers."jellyfin" = {
    privileged = true;
    autoStart = true;
    image = "jellyfin/jellyfin";
    volumes = [
      "/var/lib/jellyfin:/config"
      "/var/cache/jellyfin:/cache"
      "/data/media/movies:/movies"
      "/data/media/shows:/shows"
      "/data/media/music:/music"
    ];
    devices = [
      "/dev/dri:/dev/dri"
      "/dev/dma_heap:/dev/dma_heap"
      "/dev/rga:/dev/rga"
      "/dev/mpp_service:/dev/mpp_service"
      "/dev/mali0:/dev/mali0"
    ];
    ports = [ "8096:8096/tcp" "7359:7359/udp" ];
    environment = {
      JELLYFIN_LOG_DIR = "/log";
    };
  };

  hardware.firmware = [
    (pkgs.callPackage "${nixos-rk3588}/pkgs/mali-firmware" {})
  ];

  hardware.deviceTree.overlays = [
    {
      name = "rk3588s-mali";
      dtsText = ''
        /dts-v1/;
        /plugin/;

        / {
          compatible = "rockchip,rk3588";
        };

        &gpu {
          status = "disabled";
        };

        &gpu_mali {
          status = "okay";
          mali-supply = <&vdd_gpu_s0>;
          sram-supply = <&vdd_gpu_mem_s0>;
        };
      '';
    }
  ];
};