uboot: 2017.11 -> 2018.03, cross fixes, Rock64 support

[lopsided98]

Primarily, this PR updates U-Boot to the latest version, and fixes cross compilation. It also adds support for building U-Boot for the Rock64.

I had to rebase one of the patches from @dezgeg's repository to work with 2018.01, so I included it in this PR. I also added a patch to increase the maximum length of filenames read from an extlinux.conf file, which makes it possible to boot using a cross compiled kernel (which is normally too long because of the target suffix). Personally, I like keeping patches in the nixpkgs tree, but they could be moved to @dezgeg's repo.

The Rock64 is not yet supported in mainline U-Boot, but a community member has provided a patched version of 2018.01. To make a bootable U-Boot image for the Rock64, an ARM Trusted Firmware image is required. I created a new package for this firmware, which is structured similarly to the U-Boot package. Currently it only has a package for the RK3328 (the SOC in the Rock64). I am close to getting to the Rock64 to boot without any binary blobs, but U-Boot's TPL (which initializes the DRAM) causes the kernel to hang/crash soon after booting. Therefore, I am currently using a binary TPL provided by Rockchip.

Lastly, I switched to using mainline U-Boot for the Sheevaplug and Guruplug. These were added in 2010 and have received no maintenance since. Today, mainline U-Boot has a config for both of these boards, which build successfully. I have no way to test them, but they didn't even build before so this is better than it was.

I have tested that all the packages can be cross-compiled, and I tested native builds for the ODROID-XU3/4, Raspberry Pi 2 and 3, and Rock64. I have only tested booting with the Rock64, but I have an ODROID-XU4, Raspberry Pi 2 and Raspberry Pi 3 that I will be able to test in a few weeks (I don't have physical access to them right now, and I don't want to risk a boot failure).

Please let me know if you have any suggestions or things you want me to change.

cc @dezgeg

• Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

[dezgeg]

Nice! I will take a closer look tomorrow. The U-Boot v2018.03 release is due on 12.03.2018 so I think we can skip straight to it when that's released.

[dezgeg]

I uploaded these to:

https://github.com/dezgeg/u-boot/commit/pythonpath-2018-03.patch
https://github.com/dezgeg/u-boot/commit/extlinux-path-length-2018-03.patch

so we can keep using fetchpatch.

[lopsided98]

@dezgeg I rebased it to use your patches.

[dezgeg]

Actually, setting $ARCH shouldn't be required with U-Boot? It's auto-set by CONFIG_SYS_ARCH from the defconfig.

[lopsided98]

Yeah, it seems to build fine without it.

[lopsided98]

I decided to removeAttrs all the defined arguments to buildUBoot. I had already done that for extraMeta, because it caused the build to fail since it is an attrset. targetPlatforms will have the same problem once #34444 is merged (see here), so I felt I might as well exclude all the unneeded attributes. Does this seem good to you?

[dezgeg]

Hmm, not sure that's worth it, I except the list will quickly get out of date as people forget to add to the list of variables to remove. Maybe we can remove targetPlatforms and instead use extraMeta.platforms directly, so only removing extraMeta suffices?

[lopsided98]

I implemented what you suggested, but I added a little hack that basically transforms platforms to hydraPlatforms. Hopefully #34444 will be merged before this PR, but if not, this will prevent Hydra from attempting to build packages for the wrong platform.

[dezgeg]

If I remember correctly, it works the other way around; i.e. without that PR Hydra would typically attempt to build less packages (it would complain about e.g. error: Package ‘uboot-rpi_defconfig-2017.11’ in pkgs/misc/uboot/default.nix:77 is not supported on ‘x86_64-linux’, refusing to evaluate. even when cross-compilation is set up properly), so it shouldn't be needed. Things might have changed in the meantime though.

[lopsided98]

Yes, that was the case before, because platforms would be compared against the build platform. This would prevent Hydra from building the packages, but it would also prevent me from cross compiling them. My current hack does not set platforms, which allows me to cross compile the packages locally, but prevents Hydra from trying to build them by setting hydraPlatforms.

On second thought, there's really no need for this hack because, until this issue is fixed, I can just set NIXPKGS_ALLOW_BROKEN if I want to cross-compile, so I decided to remove the hack to make things cleaner.

[dezgeg]

On second thought, there's really no need for this hack because, until this issue is fixed, I can just set NIXPKGS_ALLOW_BROKEN if I want to cross-compile, so I decided to remove the hack to make things cleaner.

Great, thanks!

v2018.03 is now out, you can squash in https://github.com/dezgeg/nixpkgs/commit/0c0cb5730d987f16b5fefd31b0d472446c1d0acb.patch to the first commit. It drops a patch that I sent in upstream before the release (in a different file though, so it still looks like it would apply). Also @bendlas pointed out some additional changes in pythonpath-2018-03.patch so the hash has changed. Also https://github.com/NixOS/nixpkgs/commit/fe3acfa41abeb81fac56e5bbfc6d9e0fd20cd65c.patch seems to be now needed for the tools to build, you can squash or pick it up as a separate change, whatever you prefer.

On my side I will try to test this on my boards this friday.

[lopsided98]

I can't get the tools to cross compile using sandbox_defconfig (native builds work). It is unable to find an openssl header:

In file included from tools/default_image.c:20:0:
include/image.h:1058:12: fatal error: openssl/evp.h: No such file or directory

I looked into the problem with allnoconfig. It seems like the build system is not setting values for certain hex and int config options without default values (or with conditional default values that are not enabled). This is not new behavior (it happens in 2018.01 with allyesconfig), but recently CONFIG_SYS_TEXT_BASE was changed (see u-boot/u-boot@278b90c) so that it triggers this issue with allnoconfig. I have worked around this by manually giving this option an arbitrary value. This makes native and cross builds of ubootTools work. We could also look into trying to fix this upstream.

[lopsided98]

I tested 2018.03 on my Raspberry Pi 2 and ODROID-XU4 and haven't seen any problems.

[dezgeg]

In file included from tools/default_image.c:20:0:
include/image.h:1058:12: fatal error: openssl/evp.h: No such file or directory

Ah, so the sandbox has CONFIG_FIT_SIGNATURE enabled, so it now attempts to build the fit_info and fit_check_sign tools which does need the OpenSSL headers but they aren't found. Mysterious.

I looked into the problem with allnoconfig. It seems like the build system is not setting values for certain hex and int config options without default values (or with conditional default values that are not enabled). This is not new behavior (it happens in 2018.01 with allyesconfig), but recently CONFIG_SYS_TEXT_BASE was changed (see u-boot/u-boot@278b90c) so that it triggers this issue with allnoconfig. I have worked around this by manually giving this option an arbitrary value. This makes native and cross builds of ubootTools work.

Ok, sounds fine.

[dezgeg]

I have tested so far on RPi 1, RPi 3 (in both 32 & 64-bit modes), Wandboard Quad, Beaglebone Black, pcDuino 3 Nano and QEMU for both ARM & AArch64. I will test a couple of more boards soon but all is fine here as well.

[dezgeg]

BTW @lopsided98 if you happen to have a spare SD card and cycles, would you mind testing if https://www.cs.helsinki.fi/u/tmtynkky/sd-image-armv7l-with-linux-rpi.img boots for you on RPi 2? It's an image built with linux_rpi aka the Raspbian kernel fork. I haven't had any success on RPi3 while it should work in theory.

[dezgeg]

Applied to master.

[lopsided98]

I tested your SD card image, and it hangs after u-boot starts the kernel. Here is the boot log:

U-Boot 2017.11 (Nov 14 2017 - 01:08:06 +0000)

DRAM:  948 MiB
RPI 2 Model B (0xa21041)
MMC:   sdhci@7e300000: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 5 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
reading /extlinux/extlinux.conf
851 bytes read in 20 ms (41 KiB/s)
------------------------------------------------------------
1:      NixOS - Default
Enter choice: 1:        NixOS - Default
Retrieving file: /extlinux/../nixos/h1dgpfgw25ybghnycq2b8vmc6zhpfr80-initrd-initrd
reading /extlinux/../nixos/h1dgpfgw25ybghnycq2b8vmc6zhpfr80-initrd-initrd
7183744 bytes read in 512 ms (13.4 MiB/s)
Retrieving file: /extlinux/../nixos/wjxr12srr7prdvc6hlkyy814x2kby1yl-linux-4.9.59-1.20171029-zImage
reading /extlinux/../nixos/wjxr12srr7prdvc6hlkyy814x2kby1yl-linux-4.9.59-1.20171029-zImage
3395792 bytes read in 265 ms (12.2 MiB/s)
append: systemConfig=/nix/store/v22c57rphxybzp9aha8l5zyc207s3543-nixos-system-nixos-18.09pre-git init=/nix/store/v22c57rphxybzp9aha8l5zyc207s3543-nixos-system-nixos-18.09pre-git/init loglevel=7 console=ttyS0,115200n8 console=ttymxc0,115200n8 console=ttyAMA0,115200n8 console=ttyO0,115200n8 console=ttySAC2,115200n8 console=tty0
Retrieving file: /extlinux/../nixos/wjxr12srr7prdvc6hlkyy814x2kby1yl-linux-4.9.59-1.20171029-dtbs/bcm2836-rpi-2-b.dtb
reading /extlinux/../nixos/wjxr12srr7prdvc6hlkyy814x2kby1yl-linux-4.9.59-1.20171029-dtbs/bcm2836-rpi-2-b.dtb
16693 bytes read in 47 ms (346.7 KiB/s)
Kernel image @ 0x3000000 [ 0x000000 - 0x33d0d0 ]
## Flattened Device Tree blob at 00000100
   Booting using the fdt blob at 0x000100
   reserving fdt memory region: addr=0 size=1000
   Using Device Tree in place at 00000100, end 00007234

Starting kernel ...