FreeBSD on the Pine H6
Pine makes a bunch of different bits of hardware. The Pine64 was a bit of a breakthrough in single-board-computing (SBC) – very different from the Raspberry Pi, and a lot more open-source. We could argue about just how open it is, but it did spawn the Pinebook and the Pinebook Pro. I hear the latter is really nice, and runs OpenBSD and FreeBSD too. Somewhat forgotten amongst all these is the Pine H6.
When the A64 came out originally (was that 2018?), closely followed by the H6, the H6 was clearly a more-capable board: more memory, even if you can’t access all 4GiB that is soldered on, eMMC, barrel power-connection. The Pine64-LTS remedied a lot of that, and the H6 was then also surpassed in compute-power by the Rock64 and RockPro. By that time, though, I had ordered a couple.
At one point, I had a plan, which was to take a beautiful pine plank, and use 4mm threaded rods screwed through it, to build a pine-based Pine rack. With a switch nearby, and a 50W power supply, I could run four of them and have my own 16-core ARM build cluster!
Such is the exuberance of youth, and you can see in the photo that all the parts have gotten dusty, and not much use. Somewhere my ISA-enthusiasm was swept away, and my amd64 stable has grown much fatter than my aarch64 heap. It didn’t help that there was no FreeBSD (11- at the time) support for the H6.
Moving forward a few years, I was getting annoyed at the old amd64 machine I use as all-network-services thing in my house, and decided to take another stab at using SBCs for this purpose. That pile of Pines has got to be usable in some way, and aarch64 SBC support on FreeBSD has come a long long way.
My Rock64 turns out to be a v2 board, with a misplaced SMD resistor somewhere. It runs Linux just fine, with decent network connectivity, but FreeBSD does something different with the PHY, I guess, and ends up with 3-7% packet loss. It’s fixable – if soldering SMD components is in your skill set. I checked, and it’s missing in mine.
Somewhat discouraged, I mentioned the Rock64 and H6 in a thread on the FreeBSD ARM mailing list, and it was pointed out that there’s a u-boot port for H6 – “port” being FreeBSD words for “that is packaged”. There is also a complete PineA64 image available from the FreeBSD 13.0 ISO Images. So the thing to do is get the image, get the u-boot bits, write to an SD-card, and go!
dd if=FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img \
of=/dev/da0 bs=1M conv=notrunc
dd if=/usr/local/share/u-boot/u-boot-pine-h64/u-boot-sunxi-with-spl.bin \
of=/dev/da0 bs=128k seek=1 conv=sync
While doing this – couple of writes back and forth, trying out a Linux distro in between – I was reminded that micro-SD cards are crap. At least one fell over hard enough to pretend it was a write-only 8MB card. A hammer, followed by the dustbin, is the solution.
With an SBC like this, the first round of “fiddling with the bits” goes via serial – although now I think about it, bhyve + qemu would have allowed me to do all the image-wrangling I wanted to beforehand, virtually. I dropped the board off the edge of the table and the pins and the USB-to-serial converter came off much the worse, but (surprisingly?) everything still works.
Boot looks like this (slightly edited):
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f:
Fri Apr 9 06:07:07 UTC 2021
root@releng1.nyi.freebsd.org:arm64.aarch64/sys/GENERIC arm64
FreeBSD clang version 11.0.1 (llvmorg-11.0.1-0-g43ff75f2c3fe)
Given the way SD cards behave, I got a 32GiB eMMC ship with one of the H6 boards, and snapped it into place, which tells me
mmcsd0: 31GB <MMCHC DF4032 0.1 SN FB4FF63B MFG 10/2017 by 69 0x0000>
at mmc0 52.0MHz/8bit/4096-block
After shuffling some bits around, I now have the machine booting from
SD card, read-only, and keeping logs and data and things in /var which is
on the eMMC. I hope that has better write-endurance overall.
I’ve got some spare eMMC, it turns out, that I can cannibalize from
other gadgets in-house. In extremis, USB hard-disk or that
tempting-but-buggy mini-PCIe slot.
Lesson Learned
Good things come to those who wait. They would have come sooner if I had contributed, somehow, to development and testing. Big thanks to manu@ who does most of the heavy lifting in the u-boot department. Time will tell if quassel and DNS and DHCP are suitable workloads (without too much write-wear) for the storage media (and I suppose I should build my Matrix meeting-management-bot over there as well).