linux_rpi5: init at 6.1.63-stable_20231123

[leo60228]

Description of changes

Builds the BCM2712/Raspberry Pi 5 defconfig for linux-rpi. linux_rpi4 works, but uses 4K pages instead of 16K, and is thus not recommended by Raspberry Pi.

Relates to #260754.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[alyssais]

There's this note in linux-kernels.nix about not adding new vendor kernels:

# NOTE: PLEASE DO NOT ADD NEW VENDOR KERNELS TO NIXPKGS.
# New vendor kernels should go to nixos-hardware instead.
# e.g. https://github.com/NixOS/nixos-hardware/tree/master/microsoft/surface/kernel

[leo60228]

Technically, this isn't a *new* kernel, just building an existing one with a different config.... Adding it to nixos-hardware isn't an amazing option, since compiling the kernel on-device takes several hours.

…

On Sun, Jan 28, 2024, 5:08 AM Alyssa Ross ***@***.***> wrote: There's this note in linux-kernels.nix about not adding new vendor kernels: # NOTE: PLEASE DO NOT ADD NEW VENDOR KERNELS TO NIXPKGS. # New vendor kernels should go to nixos-hardware instead. # e.g. https://github.com/NixOS/nixos-hardware/tree/master/microsoft/surface/kernel — Reply to this email directly, view it on GitHub <#284391 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7X32IVJ6KC5Y6JSFFEOL3YQYPRPAVCNFSM6AAAAABCN2M37CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGU2DCOJVGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[alyssais]

It would be good indeed if nixos-hardware could be built by Hydra.

[malteneuss]

Is there anything missing for this PR to be merged?

@leo60228 What is the relation to https://gitlab.com/vriska/nix-rpi5/-/blob/main/linux-rpi.nix?ref_type=heads from your wiki page https://wiki.nixos.org/wiki/NixOS_on_ARM/Raspberry_Pi_5 ? It looks equivalent, so could we remove that external dependency?

[leo60228]

Is there anything missing for this PR to be merged?

Policy clarification: this probably should go in nixos-hardware, but that's not built by Hydra.

What is the relation to https://gitlab.com/vriska/nix-rpi5/-/blob/main/linux-rpi.nix?ref_type=heads from your wiki page https://wiki.nixos.org/wiki/NixOS_on_ARM/Raspberry_Pi_5 ? It looks equivalent, so could we remove that external dependency?

This PR is an attempt to upstream that, yes.

[malteneuss]

Ah nice. Who could we ping for clarification? You're argument of not actually adding a new config seems reasonable.

[malteneuss]

I just tried compiling the rpi5 kernel natively via bin-fmt/qemu and gave up after 4h on an average laptop. So if there's no cached binary, the user experience indeed goes towards zero :(
Is this another argument to merge it here and not nixos-hardware?

[alyssais]

Well, I wrote that note, so I know what I meant by it. Other people generally involved in this sort of conversation include @samueldr, @K900, @RaitoBezarius. (I think we possibly even discussed this PR on Matrix at the time.)

[alyssais]

Is this another argument to merge it here and not nixos-hardware?

It's an argument for having Hydra on nixos-hardware.

[samueldr]

We're not making the mistake we kept making in the past with this new hostile vendor platform.

If anything has to be done, a PR removing linuxPackages_rpi* would be the more proper action to take.

[malteneuss]

@leo60228 Could you create a PR against Nixos-hardware then? Letting it be build by Hydra could be another topic/PR.

@samueldr What are your thoughts on Hydra for Nixos-hardware? And is there any deprecaction workflow we could start here?

[samueldr]

@samueldr What are your thoughts on Hydra for Nixos-hardware? And is there any deprecaction workflow we could start here?

Due to how infrastructure stuff is going at the moment, it's not the time to plan this. So for now the status quo of not changing this is the better option.

Though, we might want to already start planning to move rpi1/rpi2 to nixos-hardware and deprecate it "outright" considering anyway those are not being built in any form by our infra.

It would leave the 64-bit pair as a whole, and those one we would need to figure out the plan going forward.

TLDR: there is no pressure to remove anything at the moment. I mainly wanted to confirm @alyssais's understanding, and signal the intention clearly.

[leo60228]

Superseded by NixOS/nixos-hardware#927.