Aarch64 (ARM64) support #22117
Aarch64 (ARM64) support #22117
Conversation
Looks generally nicer and used recently in nixpkgs in e.g. 3e197f7 ("top-level: Normalize stdenv booting")
Because if we define it, then gcc compilation fails because it doesn't support --with-float for aarch64.
This is required for Aarch64 since a lot of source tarballs ship with outdated configure scripts that don't recognize aarch64. Simply replacing the config.guess and config.sub with new versions from upstream makes them build again. This same approach is used by at least Buildroot and Fedora. In principle this could be enabled for all architectures but conditionalizing this on aarch64 avoids a mass rebuild on x86.
Our bootstrap tools are actually broken right now due to busybox not working when invoked directly from a store path. (It says e.g. "0qqqw19y4gmknajw8vg4fvhx9gxdqlhz-busybox: applet not found"). Make this test actually fail in such case, the next commit will fix the problem with busybox.
This fixes the usage for stdenv bootstrap. Additionally, dezgeg ported the patch from 1.25.1 to 1.26.1
These are temporary and will be switched to Hydra-build ones once all the aarch4 changs are merged.
[dezgeg: note that we are currently using just 'Image' instead of 'Image.gz' as U-Boot doesn't support the latter yet. We might switch once it does since the kernel images are quite big]
So that the boot blobs can be copied. FIXME: This makes the dynamic linker of the ARM binaries point to a aarch64 linker.
|
@dezgeg, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Phreedom, @edolstra and @Ericson2314 to be potential reviewers. |
|
@dezgeg Cavium ThunderX, the Octeons are MIPS64. |
This makes Raspberry Pi 3 and some Cavium ThunderX server hardware work.
And rename the old ubootRaspberryPi3 to ubootRaspberryPi3_32bit.
This one works on the Raspberry Pi 3 so far.
dezgeg
force-pushed
the
aarch64-for-merge
branch
from
86eb926
to
0e4c1bf
Compare
|
D'oh! Fixed... |
| assertions = lib.singleton { | ||
| assertion = pkgs.stdenv.system == "aarch64-linux"; | ||
| message = "sd-image-aarch64.nix can be only built natively on Aarch64 / ARM64; " + | ||
| "it cannot be cross compiled"; |
There was a problem hiding this comment.
It would be nice to have some instructions somewhere (here, or in the manual) for how to go about creating an image.
| selectPlatformBySystem = system: { | ||
| "i686-linux" = pc32; | ||
| "x86_64-linux" = pc64; | ||
| "armv5tel-linux" = sheevaplug; |
There was a problem hiding this comment.
nice cleanup! (not actionable)
|
Documented now. |
|
This is great! Can you look at |
|
I think the code I added there some time ago will automatically pick up the bootstrap tools job (similar to http://hydra.nixos.org/build/46896671). |
|
@dezgeg ah, that's right you did do that. Then it would just be a matter of those other per-pkg jobs, but sure the bootstrap job may subsume them. |
|
Perhaps I missed this information: is there interest in having aarch64 support in 17.09? (i.e. binaries + CI on Hydra) Currently the jobset is only for I believe it wouldn't put additional significant strain on the build farm, as large rebuilds aren't frequent on stable branches, and aarch64-linux tend lately not to be the most over-queued platform on Hydra anyway. On the other hand, if there was no interest, it would be probably useless... |
|
I wouldn't do it just yet given that it's a thousand or so Hydra jobs to fix. And it's easier to see what's specifically broken for aarch64 once the ZHF for 17.09 is done. |
|
Right, better postpone that after ZHF #28643. I don't think we need to promise "zero failures" on all platforms, though the errors might be annoying if they are too many inside the same jobset. EDIT: to be clear, I don't expect to use |
This series adds support for the Aarch64 architecture, which is the 64-bit variant of ARM. I have tested this on a HiKey, Raspberry Pi 3 and some Cavium ThunderX server hardware. For RPi3, an expression for building an SD card image using U-Boot is provided (which should work out-of-the-box). For the rest, UEFI + GRUB is used, which still needs some more work to make GRUB work properly in a serial-only environment.
Most of the changes are quite straightforward except for one change to stdenv. This is needed because a lot of packages using tarballs containing autotools-generated stuff are built with obsolete versions of autotools and don't recognize aarch64. Fortunately, this is easy to work around by looking for files named
config.subandconfig.guessand replacing them with new versions. I have added a stdenv hook for that (updateAutotoolsGnuConfigScriptsHook), only enabled for aarch64. The current way of enabling that is slightly ugly, any suggestions on doing that in a cleaner way are welcome.Thanks to @edef1c for testing and some of the patches here, and @grahamc for providing me access for the Cavium ThunderX box.