uboot: 2024.10 -> 2025.01

[RadxaYuntian]

Build tested with an expression based on #347188.

let
  pkgs = import ./. { };
  inherit (pkgs) lib;
in

pkgs.linkFarm "uboot-all" (
  lib.mapAttrsToList
    (name: pkg: {
      inherit name;
      path = pkg;
    })
    (
      lib.mapAttrs
        (
          name: pkg:
          let
            inherit (pkg.meta) platforms;
          in
          if builtins.elem "x86_64-linux" platforms then
            pkgs.${name}
          else if builtins.elem "aarch64-linux" platforms then
            pkgs.pkgsCross.aarch64-multiplatform.${name}
          else if builtins.elem "armv7l-linux" platforms then
            pkgs.pkgsCross.armv7l-hf-multiplatform.${name}
          else if builtins.elem "riscv64-linux" platforms then
            pkgs.pkgsCross.riscv64.${name}
          else if builtins.elem "armv6l-linux" platforms then
            pkgs.pkgsCross.raspberryPi.${name}
          else if builtins.elem "armv5tel-linux" platforms then
            pkgs.pkgsCross.sheevaplug.${name}
          else
            builtins.throw "don't know how to build ${name} on platforms ${toString platforms}"
        )
        (
          lib.filterAttrs (
            name: _:
            (builtins.match "^uboot.*" name != null)
            && (!builtins.elem name [
              "ubootBeagleboneBlack" # The target is removed. Currently it is an error throwing alias.
            ])
          ) pkgs
        )
    )
)

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 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.

[RadxaYuntian]

I had to disable 2 ARMv6 targets since the build environment seems to be broken. There was no HOST_ARCH defined.

Rest of the targets built fine:

at 17:32:06 ❯ ls result
ubootA20OlinuxinoLime       ubootClearfog     ubootNanoPCT4            ubootOlimexA64Teres1  ubootOrangePiZero         ubootPine64LTS         ubootQemuX86             ubootRock4CPlus   ubootRockPro64    ubootUtilite
ubootA20OlinuxinoLime2EMMC  ubootCM3588NAS    ubootNanoPCT6            ubootOrangePi3        ubootOrangePiZero2        ubootPinebook          ubootRaspberryPi2        ubootRock5ModelB  ubootROCPCRK3399  ubootWandboard
ubootAmx335xEVM             ubootCubieboard2  ubootNovena              ubootOrangePi3B       ubootOrangePiZero3        ubootPinebookPro       ubootRaspberryPi3_32bit  ubootRock64       ubootSheevaplug
ubootBananaPi               ubootGuruplug     ubootOdroidC2            ubootOrangePi5        ubootOrangePiZeroPlus2H5  ubootQemuAarch64       ubootRaspberryPi3_64bit  ubootRock64v2     ubootSopine
ubootBananaPim3             ubootJetsonTK1    ubootOdroidXU3           ubootOrangePi5Plus    ubootPcduino3Nano         ubootQemuArm           ubootRaspberryPi4_32bit  ubootRockPi4      ubootTools
ubootBananaPim64            ubootLibreTechCC  ubootOlimexA64Olinuxino  ubootOrangePiPc       ubootPine64               ubootQemuRiscv64Smode  ubootRaspberryPi4_64bit  ubootRockPiE      ubootTuringRK1

@jmbaur did you encounter ARMv6 building issue when updating to 2024.10?

[jmbaur]

@jmbaur did you encounter ARMv6 building issue when updating to 2024.10?

I don't recall running into any issues building armv6 for 2024.10. Maybe something related to the recent gcc bump?

[RadxaYuntian]

Running nix-shell -p pkgs.pkgsCross.raspberryPi.ubootRaspberryPiZero still works, so something is changed in 2025.01 to break the build.

[RadxaYuntian]

So the issue is caused by how U-Boot parses the host triplets. It does not have a match for armv6l. I guess people don't deal with non arm- platforms very often, so I'm just patching it in nixpkgs.

Now everything builds:

❯ ls result
ubootA20OlinuxinoLime       ubootCM3588NAS    ubootNovena              ubootOrangePi5            ubootPcduino3Nano  ubootQemuRiscv64Smode    ubootRaspberryPi4_64bit  ubootRockPiE      ubootUtilite
ubootA20OlinuxinoLime2EMMC  ubootCubieboard2  ubootOdroidC2            ubootOrangePi5Plus        ubootPine64        ubootQemuX86             ubootRaspberryPiZero     ubootRockPro64    ubootWandboard
ubootAmx335xEVM             ubootGuruplug     ubootOdroidXU3           ubootOrangePiPc           ubootPine64LTS     ubootRaspberryPi         ubootRock4CPlus          ubootROCPCRK3399
ubootBananaPi               ubootJetsonTK1    ubootOlimexA64Olinuxino  ubootOrangePiZero         ubootPinebook      ubootRaspberryPi2        ubootRock5ModelB         ubootSheevaplug
ubootBananaPim3             ubootLibreTechCC  ubootOlimexA64Teres1     ubootOrangePiZero2        ubootPinebookPro   ubootRaspberryPi3_32bit  ubootRock64              ubootSopine
ubootBananaPim64            ubootNanoPCT4     ubootOrangePi3           ubootOrangePiZero3        ubootQemuAarch64   ubootRaspberryPi3_64bit  ubootRock64v2            ubootTools
ubootClearfog               ubootNanoPCT6     ubootOrangePi3B          ubootOrangePiZeroPlus2H5  ubootQemuArm       ubootRaspberryPi4_32bit  ubootRockPi4             ubootTuringRK1

❯ ls result | wc
     58      58     972

[RadxaYuntian]

CC @K900 and @thefossguy since I don't have permission to request reviewers in this account.

[K900]

Maybe we just drop armv<7 targets at this point? Doesn't feel worth it.

[RadxaYuntian]

Doesn't feel much of a maintenance burden at this point. The issue is only relevant to cross compile.

If anything, they can just serve as tests against our cross compile infrastructure.

[K900]

I mean there's no way in hell we're actually building those non-cross.