I’ve been playing with getting a full ARM64 version of cardano built and running, mainly for the Pi, but also to test AWS’s ARM processors. Inspired by this post on the haskell site, I had success using cabal 220.127.116.11 from here and ghc-8.10.2
Followed the instructions (again) from the stake pool school, apart from also having to sudo apt install llvm-9 and libnuma-dev, it compiles and is currently running as a relay node on an AWS ARM instance. It’s a 4GB RAM, 2 vCPU instance (I’d noticed on x86_64 VMs it was chewing through 2.4GB RAM and 1 vCPU didn’t cut it.) which I’ll leave running for a day or two before I add a BP node.
The other experiment is to get the compiled binaries and see if they’ll “just run” on a Pi.
I’ll report back…
Copied the binaries compiled on Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-1038-aws aarch64) to a Pi 4 4GB RAM running Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-1029-raspi aarch64), sudo apt install llvm-9, copy a relatively up to date testnet db and config files, issue cardano-node run blah blah blah and
It’s these little successes that make being a geek so much fun
You can follow the instructions here to prepare the Pi4 and then these to get up and running. The whole process should probably take less than 10min.
Thanks for the reply, it was your work and comments that inspired me to have a go at getting it compiled from scratch. I wanted to avoid using Raspbian as the base OS, hence compiling from scratch. I did have a look around the nessus-cardano project, got inspired again, will have to go learn Nix and see if I can contribute.
Thank you for the inspiration.
Lovely, that’s great to hear. If all goes well, we will eventually have most/all of that upstream. You can support that cause here and here.
This is great. I can confirm that I have also been able to build a 1.26.0 node on AWS ARM instances. specifically on the C6g class of instances. Thanks for posting this. I need those required packages
I’ve been having a go at figuring out what’s happening on the nixOS build (Segmentation fault) issue. I suspect that the Boehm Garbage Collector (libgc, where the seg fault occurs) is having trouble with ARMs weak memory ordering model. I need to spend more time (if only there were more than 24 hours in a day!) with it to be certain.