uboot: 2023.01 -> 2023.07

[NickCao]

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 23.05 Release Notes (or backporting 22.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.

[NickCao]

Result of nixpkgs-review pr 227947 run on x86_64-linux 1

5 packages built:

• diffoscope
• diffoscope.dist
• diffoscope.man
• ubootQemuX86
• ubootTools

[lopsided98]

@ofborg build ubootRockPro64

[lopsided98]

Some minor changes are needed to support boards that now use binman. binman depends on pyelftools, and boards that use binman no longer have a u-boot.itb target (it is still built, but is not a separate target). This effects at least all the Rockchip boards, and maybe others.

[lopsided98]

It looks like you can just remove the extraMakeFlags lines from ubootRock64 and ubootRockPro64.

[lopsided98]

I tested this on my RockPro64 and ran into two problems caused by the switch from "distro boot" to "standard boot". First, I had my environment saved to SPI flash, so it was still trying to use the distro boot scripts, but these failed because many commands are not available. I fixed this by resetting the environment, but then boot failed with the following error:

** Booting bootflow '[email protected]_3' with distro
------------------------------------------------------------
1:      NixOS - Default
2:      NixOS - Configuration 90 (2023-03-28 16:58 - 23.05.20230323.3f8507e)
3:      NixOS - Configuration 89 (2023-01-20 17:36 - 23.05.20221230.bb40baa)
4:      NixOS - Configuration 88 (2023-01-20 17:11 - 23.05.20221230.bb40baa)
5:      NixOS - Configuration 87 (2022-11-21 18:27 - 22.11.20221105.44f307d)
Enter choice: 1:        NixOS - Default
Retrieving file: ../nixos/7d6gg2g0n0k9rhgfi66dbxmgq8ymkxgg-linux-6.1.20-Image
Skipping nixos-default for failure retrieving kernel
2:      NixOS - Configuration 90 (2023-03-28 16:58 - 23.05.20230323.3f8507e)
Retrieving file: ../nixos/7d6gg2g0n0k9rhgfi66dbxmgq8ymkxgg-linux-6.1.20-Image
Skipping nixos-90 for failure retrieving kernel
3:      NixOS - Configuration 89 (2023-01-20 17:36 - 23.05.20221230.bb40baa)
Retrieving file: ../nixos/45dpaa13gqvh8p13xbrbp3rx6k7rjb25-linux-6.0.15-Image
Skipping nixos-89 for failure retrieving kernel
4:      NixOS - Configuration 88 (2023-01-20 17:11 - 23.05.20221230.bb40baa)
Retrieving file: ../nixos/45dpaa13gqvh8p13xbrbp3rx6k7rjb25-linux-6.0.15-Image
Skipping nixos-88 for failure retrieving kernel
5:      NixOS - Configuration 87 (2022-11-21 18:27 - 22.11.20221105.44f307d)
Retrieving file: ../nixos/jn68515lk8x1qqq0sm3xrzldbh70mik6-linux-5.15.76-Image
Skipping nixos-87 for failure retrieving kernel
Boot failed (err=-14)

It boots successfully if I edit extlinux.conf to use absolute rather than relative paths.

[NickCao]

Let's draft this until issues are resolved.

[asonix]

Hey there! I'm doing fun things with uboot 2023.07-rc3 right now and I hit the relative path vs absolute path bug. Is there a reason it can't be hardcoded to /boot/nixos? if extlinux.conf is always in /boot/extlinux and the path is always ../nixos then it would seem like that implies it's always in the same location

For reference I'm booting on SoQuartz Blade & PineTab2

[samueldr]

Hey there! I'm doing fun things with uboot 2023.07-rc3 right now and I hit the relative path vs absolute path bug. Is there a reason it can't be hardcoded to /boot/nixos? if extlinux.conf is always in /boot/extlinux and the path is always ../nixos then it would seem like that implies it's always in the same location

The /boot path may or may not be on the rootfs. So those files may or may not be at /boot/... or at /.... This is because it may be necessary for some setups (e.g. FDE) to have a separate boot partition to the rootfs.

[samueldr]

I'll have more of an understanding of the problems once I'll have ported forward Tow-Boot to standard[sic] boot era U-Boot. (Which I'm going to tackle soon~ish.)

[asonix]

fwiw the relative path issue was fixed in a recent 2023.07 release candidate. No longer an issue for nixos.

[samueldr]

Now v2023.07.02

• https://source.denx.de/u-boot/u-boot/-/commit/83cdab8b2c6ea0fc0860f8444d083353b47f1d5c

Though I guess it's not strictly an issue?

[samueldr]

I tested this on my RockPro64 and ran into two problems caused by the switch from "distro boot" to "standard boot". First, I had my environment saved to SPI flash, so it was still trying to use the distro boot scripts, but these failed because many commands are not available. I fixed this by resetting the environment, but then boot failed with the following error:

So, it looks like only Rockchip boards, for now, in the boards we support have been switched entirely to "standard[sic] boot", and removed the previous distroboot support entirely.

So testing will now require to track which boards have started supporting "standard[sic] boot", and which haven't, until their move to "standard[sic] boot" is complete.

And that environment issue sure tells me I should fast track saving a "diff" of the environment instead of a full dump every time... I knew it would cause trouble for Tow-Boot usage, as anyone saving the environment would end-up with old information in there :(

[MatthewCroughan]

I've tested this for the past few days in order to make a Nix expression for the Rock 4C+ U-Boot, which works fine. I'm waiting on the merge of this PR in order to make my PR.

[plmercereau]

Any chance to merge this PR soon?
Many thanks in advance

[samueldr]

If anyone gets stuck (mainly on rockchip boards) after this update, clear the environment.

[a problem] caused by the switch from "distro boot" to "standard boot" [was that] I had my environment saved to SPI flash, so it was still trying to use the distro boot scripts, but these failed because many commands are not available. I fixed this by resetting the environment

— #227947 (comment)

This is quite unlikely, and requires having a saved U-Boot environment in some permanent storage.

[samueldr]

Note: Allwinner boards may not build as they are right now due to a change in the build tooling. As reported in #156034 (comment).

EDIT: just looked at the line, it was from the previous update.

       > binman: Filename 'scp.bin' not found in input path (.,.,./board/sunxi,arch/arm/dts) (cwd='/build/u-boot-2023.01')

Solution will be to provide either an SCP binary path, or /dev/null via SCP

SCP = "/dev/null";

In the future all U-Boot builds exposed in Nixpkgs should be built successfully before building, through pkgsCross.the-right-arch-here.

[lopsided98]

I tested this on my ODROID-XU4 and ran into two issues:

• Loads the wrong device tree: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012269. To temporarily work around this, run env default -a. Note that saving the environment with the correct fdtfile value doesn't fix this, since it gets updated with the wrong value after loading the environment.
• Ethernet adapter (connected internally over USB) is not detected in Linux. I have experienced this occasionally after a warm reboot, but now it is never detected.

I updated from 2020.04, so these issues may have been around for a while (the first is definitely not new), but I just wanted to report them to inform others.

[lopsided98]

The C2 has Ethernet connected directly to the SoC; also, the XU4 is Samsung Exynos based.

[samueldr]

Oh, right, that one, don't mind it then.