Hi! 👋

Thanks for your contribution!

Some notes, but do note I'm being extra-pedantic since this is my current area of expertise :).

Board's SoC is based on Trusted Firmware-A architecture and needs extra closed-source early bootloaders to be combined with U-boot in order to boot properly, similar to Odroid-C2 board.

I'm not sure what you're describing here. TF-A is a particular OSS reference implementation of the "trusted firmware" concept required for AArch64. The BL31 bit here would be a trusted firmware, but I don't know if it even is TF-A. With Amlogic boards, this bit is signed and verified by the BootROM, and thus is provided as a binary blob. The secure boot scheme from the SoC will verify up to and exculding the "U-Boot proper" binaries.

But yes, it has to be done basically like this.

For reference:

The linux-meson wiki lists hardware generations, which is useful as when it's identified you basically know how to handle those annoying bits.

• https://linux-meson.com/hardware.html

For reference, here's the Tow-Boot equivalent for GXL (S905X)

• https://github.com/Tow-Boot/Tow-Boot/blob/2f8fff7be70ebfd22098ee6a351b0075f63955fc/modules/hardware/amlogic/default.nix#L168-L217

If you want to get this going and supported in Tow-Boot, I can help out, I would like to support all hardware by Libre Computer, they're generally well done. And amlogic support being what it is it should be quite trivial to get going.

If you don't know what it is, it is the way forward I'm working on to help make booting on ARM overall better, you can read more in Planning for a better NixOS on ARM, the NixOS on ARM/UEFI wiki page, my older introductory blog post, and the project website. </shameless-plug>

NOTE: even though I'm heavily plugging the Tow-Boot approach here, it's still welcome to package stock mainline U-Boot in this way in Nixpkgs, at least for the foreseeable future. I'm only proselytizing so it's part of the common knowledge that in my opinion distros shouldn't have to maintain the basic platform initialization component for every board out there, just like they aren't maintaining scores and scores of x86_64 BIOS/UEFI images.

One note, specific to this vendor: while we shouldn't need to package any U-Boot, this particular board is an outlier. It's because there is no built-in dedicated or dedicated-enough storage for the platform firmware. E.g. no SPI flash, and eMMC is optional [and detachable]. Though it might still be preferable to use their U-Boot build as they are built with expectation that UEFI boot can be used, and e.g. ships an updated device tree built-in.

Hi @samueldr, thanks for the quick and detailed feedback!

In addition to this being my first contribution to nixpkgs, the subject is way out of my area of expertise. I just happen to own a "LePotato" and would like it to run Nixos :) It's currently running a vendor-packaged Armbian, so I never had to worry about bootloaders...
I did not know about Tow-boot, but solving "how do I boot $THING on my $ARM_SBC" seems like a valuable goal :)

I'm not sure what you're describing here.

This is what I somewhat understood from the U-Boot doc, but it may be unaccurate indeed.

Not sure how to move forward with this change:

1. In its current form, I'm not so happy about how the extra repo is handled (copying files and "rewriting" Makefile in postBuild).
2. As you point out, it seems it would work with linux-meson, but I need to dig more for how to use it.
3. I would not mind doing with tow-boot though it's another new thing for me :)
   What do you think ?

This is what I somewhat understood from the U-Boot doc, but it may be unaccurate indeed.

Right, I now just searched through the upstream docs:

“The Amlogic ARMv8 based SoCs uses a vendor variant of the Trusted Firmware-A boot architecture.”

• https://u-boot.readthedocs.io/en/latest/board/amlogic/pre-generated-fip.html?highlight=pre-generated%20fip

So, extrapolating in simpler terms for distro packaging: "up to and excluding U-Boot proper (BL33) the previous boot stages come as signed-and-verified binary blobs provided by the vendor". The wording in U-Boot's documentation is more geared toward U-Boot development.

Not sure how to move forward with this change

The changes as implemented here are fine. They are idiomatic "amlogic blobs with mainline U-Boot".

I would not mind doing with tow-boot though it's another new thing for me :)

It's not an either situation, but an and situation. We can move forward with the stock mainline U-Boot here without worry, and have a Tow-Boot build going too.

Reworded commit as suggested.

Shall this be merged, given test made in Tow-Boot/Tow-Boot#213 ?

So, to rephrase what was said elsewhere, you are saying that this mainline U-Boot build booted a fedora iso fine?

And yes. I assume nothing is bad in the U-Boot build even if the NixOS iso fails to boot. There are other reasons that could happen. You can alternatively try the SD image, which can be burned to a usb drive even, as it doesn't use GRUB.

I kinda assume any S905X, or maybe any GXL system may exhibit the same issue. I might try and test with my La Frite board, which is GXL too (S805X).

So, to rephrase what was said elsewhere, you are saying that this mainline U-Boot build booted a fedora iso fine?

Yes indeed!
I'll look further into the Nixos image part when I have some time.

So the Nixos aarch64 sdcard image worked with USB, and this is building a working sdcard image that boots on an actual sd card \o/

Anything else you need to close this ?

This helps confirm the assumption that the problem you faced lives somewhere at the EFI bootloader layer. Likely nothing specific to this U-Boot build. Or if it is, something specific to Amlogic + U-Boot + GRUB. That there is nothing wrong with the U-Boot build compared to a normal mainline build (since this is a normal mainline build). Everything is likely to be working as implemented.

I'd like to see what @lopsided98 thinks about how we're slowly accumulating bespoke~ish builders... but I guess it's not a problem for this PR, but something to think about in the future.

I don't mind the bespoke builder. If we ever think the file is getting too big, we can just split it up.

On the other hand, I do think we should add some kind of assertion/error to enforce that this must be cross-compiled from a x86_64 machine, since aml_encrypt_gxl is an x86_64 binary.

Added assertion for x86_64 buildPlatform.

Thanks for your guidance!