aarch64 Toolchain

To support CPSC359, I needed to get access to an aarch64 cross-compiler, specifically for baremetal targets. Turns out this is…harder than it needs to be. This is a brain dump of some of the work I did to get the toolchain up and running.

Generally speaking, I don’t recommend trying to build your own toolchain. But hey, go nuts if you want to. In my role as a CPSC tech I cannot support you if you try to do this, but it could be helpful if you need to waste a few hours :)

Locating a toolchain

Many distributions - Fedora and Arch to name a few - provide cross-compilers in their repos, but these are usually for linux and mingw32 targets. That’s….not super useful for baremetal! We don’t have an ABI to build against in baremetal.

Linario do provide fully built binary toolchains, but the latest version they have for aarch64-elf is 7.5.0!. To be honest, I don’t really remember how I even stumbled upon this.

A more up to date toolchain is found at ARM’s developer site, but it targets the none-elf ABI which I found didn’t always build correctly. In the early days of supporting 359 I simply packaged both of these up in my development VM and as Fedora packages for use in MS-252. But now things are weird - I’m proving two different toolchains for two different ABIs and the GCC versions are very different. And at this stage of the project, I don’t even really understand the differences between the two toolchains.

At any rate, the Winter 2023 semester went off without much of a problem, and students completed their assignments. Some code some students shared with me built nicely with aarch64-elf, thankfully!

Building a toolchain

Two GCC versions for two ABIs. That’s… not ideal. A professor and TA can adapt just fine, but we can streamline this some more. I set about working to update the toolchain and provide a consistent ABI.

I found very little use for the none-elf target, so I decided to get rid of that. But I still needed to get the VM and 252 away from such an old version of GCC - we should not expect students to use such old versions! So let’s build a toolchain.

Turns out - building a toolchain is so ridiculously hard that no one recommends doing it, but thankfully a project known as crosstool-ng exists. Thank goodness! crosstool-ng vastly simplifies the process of building a toolchain by grouping together known-good versions and baselines and produces, at the end of a download, extract, and compile process, a nice tarball of a toolchain. And there is plenty of flexibility!

Thankfully, a template for the Pi 4 existed and using crosstool’s excellent menuconfig utility I could change the ABI from Linux to none! Now I had a working toolchain I could build my test code on and deploy to MS-252 and the VM! Almost.

Packaging the toolchain

crosstool-ng makes the whole process of building a toolchain super simple, but it also makes a ton of assumptions. Primarily, it makes the assumption that if you are building a toolchain, you’re most likely not distributing it. Distros have standard ways of building toolchains (we use Fedora here at the University, and I just don’t understand Fedora packaging enough to crib from upstream there), so crosstool doesn’t want to advertise itself as a way of creating a new standard (insert relevant XKCD here). That’s fair, and I’m happy with that. Buuut I kinda need to get this packaged up for deployment to 252 - our sysadmins aren’t going to happy with a bash script that copies everything into /usr/bin.

So I cobbled together enough knowledge on how Fedora’s rpmbuild works to make a disgustingly hacky .spec file for building a package - I have it published on GitLab here for reference. The spec is not good - it would make a real Fedora packager weep. But we need something that will work!

Like crosstool itself, the spec assumes you have already built a crosstool binary and can provide it to rpmbuild. It then uses the .config file from crosstool to build the toolchain and stick it in an rpm.

Don’t use this spec. Don’t even look at it. It’s embarasing!

Final thoughts

So as I write this we are between semesters and the Fall semester will rely on this new toolchain. Early testing and feedback is good, but once the floodgates are opened, who knows what will happen? Updates here once we know more.