tstat / raspberry-pi-nix Goto Github PK

re-open of #8

It would be handy if hardware.raspberry-pi.config-output would contain an attrset with keys text and package, so that way I can use nixos-option to view the contents of the file without having to actually build it.

Hello! Just came across your project and I wanted to thank you for your nice work.

So, I've been trying to use it in the config of my RPi3B, but upon building I realised the cachix instance didn't provide the kernel package (6.1.63), which made the build quite endless.

I tried again building the default configuration provided in the readme, alone, and the exact same thing happened. Can someone confirm that the cache does or doesn't work?

Thanks

Hello ive tried to use your module to fix this error on Raspberry 3b, but it doesnt help.

Do you have any advice why nixos get stuck on a jumbled boot screen when i connect this hat https://abelectronics.co.uk/p/77/rs485-pi but works fine without? I need to read data from /dev/serial device but have been unsuccessful using Nixos. This serial interface hat works out of the box with RaspberianOS though.

This is my config, i basically just cloned your rpi-example and flashed the sd-image with dd.

{inputs, ...}: {
  imports = [inputs.raspberry-pi-nix.nixosModules.raspberry-pi];
  nix.settings = {
    substituters = ["https://raspberry-pi-nix.cachix.org"];
    trusted-public-keys = ["raspberry-pi-nix.cachix.org-1:WmV2rdSangxW0rZjY/tBvBDSaNFQ3DyEQsVw8EvHn9o="];
  };
  hardware = {
    bluetooth.enable = false;
    raspberry-pi.config = {
      all = {
        options = {
          # ive tried a bunch of options here
        };
      };
    };
  };
}

Help much appreciated, thanks.

Edit: seems like just creating loopback with RX and TX on the GPIO results in the same error

I built an image using this flake, however bluetooth does not work. See issue title as well as full dmesg output.

I'm seeing two incorrect narHashes in your flake.lock. I had to work around this by manually "updating" each input back to the same revision. In both cases the lastModified and rev stayed the same, but the narHash changed. This was with Nix 2.13.3.

• rpi-firmware-stable-src - the hash I see is sha256-00XrEDj2n3627MJ75waI3M0t40MFevFgGOnpHjjP0dQ=
• rpi-linux-5_15-src - the hash I see is sha256-/5UStX6DUxWQ2WFWvB5u1TszLUzCo+b/qiBVetEkBTE=

I have no explanation for why the hashes are wrong, unless github actually changed the archive file it returns for the locked revisions (which would be a rather big surprise).

Is it easy to update this for the Linux 6.1 kernel? NixOS 23.05 switched to that as the default, and the upstream raspberrypi/linux repo now defaults to the rpi-6.1.y branch.

Have you considered adding a license to this project?
I would love to use this in a project, but I am unable due to the lack of a license.

As per the GitHub FAQ:

You're under no obligation to choose a license. However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work. If you're creating an open source project, we strongly encourage you to include an open source license. The Open Source Guide provides additional guidance on choosing the correct license for your project.

I finally managed to build my existing configuration using raspberry-pi-nix instead of nixos-hardware and deploy it to my raspberry pi, and rebooted, and now bluetooth is gone. bluetoothctl says no default controller available and rfkill doesn't list bluetooth.

My configuration uses the following, which AIUI should be sufficient:

{
  hardware = {
    bluetooth.enable = true;
    raspberry-pi = {
      config.all.base-dt-params = {
        # enable autoprobing of bluetooth driver
        # https://github.com/raspberrypi/linux/blob/c8c99191e1419062ac8b668956d19e788865912a/arch/arm/boot/dts/overlays/README#L222-L224
        krnbt = {
          enable = true;
          value = "on";
        };
      };
    };
  };
}

I really don't know very much about the Linux booting process, is there any way to confirm that it is indeed booting through the correct process?