HoneyComb LX2K, first impressions
The HoneyComb LX2K is a developer workstation board by SolidRun that first came to my attention via this Phoronix post, boasting 16 2ghz ARM A72 cores in a mini-ITX form factor. I was in the market for a new home server and was interested in going ARM this time seeking energy efficiency, and since this had a beefier processor than the Synquacer, I gave it a shot. I've been running my various services on an AMD 5350 with CentOS7 since 2016. It's time for that thing to retire.
The Build
I'll start out by cluttering things up with what I've put together. I used a pair of 1TB WD solid state drives with the intention of a mirror, 32GB of ECC ram from Kingston, and a compact case from In-Win. This case doesn't have room for a video card and the HoneyComb doesn't have onboard video, so I'm running it entirely headless using the serial console out via USB when necessary.
Getting started
Before I get into details, I want to shout out to a couple of bloggers on dev.to whose own first setup posts were greatly informative. You can find those below:
The HoneyComb LX2K has a 64GB eMMC on board and loads its firmware from an SD card. The firmware is built for the speed of your memory using build scripts at https://github.com/SolidRun/lx2160a_build. When I ran this the first time, it used about 29GB of space as it not only built an u-boot loader, but also an Ubuntu 20.04 image to go with it. It's meant to be used with Debian, so if you're running Windows, you're probably going to want to fire up a Debian VM to do this in. I am fortunately already a Debian user.
So I installed Ubuntu on the eMMC and it worked fine. Chances are that you didn't buy this because it's an overgrown Raspberry Pi, so my goal at this point was to get the UEFI firmware flashed instead and install Debian.
This chunk of the article will get edited out when this changes, but as of right now, the UEFI loader will not build from that script. I spent a week hacking my way through the build script and its dependencies trying to make it happen. You can get a working one from SolidRun. I contacted their technical support and the architect of the board actually answered me with an invitation to their Discord. When I get there I see the pinned post is a link to a firmware image. Aside from that, I just lurked and used the search feature to see what people were doing with Debian.
Okay, so you have your working UEFI image, what next? Get a current Linux iso (think Debian Testing, Ubuntu 20 or Fedora 33), fire it up, and add the following to your kernel arguments:
arm-smmu.disable_bypass=0
Also, the ethernet adapter doesn't work under the UEFI firmware yet, so you'll need a USB dongle.
Getting busy
So now I'm ready to play with it. I planned to encrypt my hard drives and got lackluster AES benchmarks under the u-boot firmware, around 250MB/s. I got far better numbers booting Debian on UEFI.
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 779.6 MiB/s 1187.4 MiB/s
serpent-cbc 128b 53.0 MiB/s 56.5 MiB/s
twofish-cbc 128b 87.3 MiB/s 89.6 MiB/s
aes-cbc 256b 574.9 MiB/s 817.5 MiB/s
serpent-cbc 256b 53.6 MiB/s 55.4 MiB/s
twofish-cbc 256b 88.3 MiB/s 89.5 MiB/s
aes-xts 256b 761.4 MiB/s 764.9 MiB/s
serpent-xts 256b 54.2 MiB/s 56.9 MiB/s
twofish-xts 256b 96.2 MiB/s 95.2 MiB/s
aes-xts 512b 694.7 MiB/s 697.3 MiB/s
serpent-xts 512b 56.0 MiB/s 56.9 MiB/s
twofish-xts 512b 95.4 MiB/s 93.2 MiB/s
That's faster than my hard drives, so that's all I really care about.
So I went ahead and installed Debian to the eMMC first. I wanted to see if I could actually get encrypted ZFS on root working with Debian, which I'd never tried before, and I imagine it's not very well tested on ARM. I loosely followed this guide from the OpenZFS site and took some liberties with it, mainly using the eMMC for boot/efi and adding both hard drives to the zpool without partitioning them first.
I don't torrent, so my multimedia collection is small enough that I didn't need to get more than 1TB. I tried dedup initially and found that it gave me no benefit at all versus compression; 10GB got shaved off either way, so I ditched dedup. I've been setting up datasets for all my services as I go.
So it sat up for a couple days with Postgres and InfluxDB running with nothing on them. I wanted to make sure my unstable operating system on my not exactly mainstream hardware would be stable by itself. It was! So I went ahead and setup Radicale and Turtl. I could have backported a newer kernel to Buster, but with Bullseye settling on Python 3.8 and Postgresql 12, I'm happy to not have to upgrade for another 5 years. I installed node 12 LTS from nodesource since it's still node 10 in Debian's repos. I tried 14 first, but Turtl isn't compatible yet.
Current impression
Once I got a working UEFI image my buyer's remorse started to subside. It can compile a kernel in the time it takes me to make a sandwich, so it's certainly fast. I have more than enough resources for all the services I'm going to run, considering that I'm the only user. The community is small but very enthusiastic. It takes up barely any space on my desk. Now here's hoping it lasts as long as my last AMD build did.
On deck to be setup: Firefox Sync, Vault, Icinga and Grafana.