Generic BSD installations on ARM64 UEFI: results and first impressions

After turning RockPro64 into a "normal" UEFI PC time to test generic UEFI ARM64 installations of major BSDs, see if any can be used as a desktop OS on this machine. Images used are FreeBSD-14.3-RELEASE-arm64-aarch64-disc1.iso, NetBSD-10.1-evbarm-aarch64.iso and install77.img (OpenBSD). Procedure for each is to prepare a 10 GiB partition on SATA drive for installation, write image on USB stick, reboot and go through installation.

FreeBSD

(TL;DR) Impressions:

• Excellent UEFI support on ARM64, straightforward installation
• Easy to get all package build definitions from https://git.freebsd.org/ports.git
• Looks like no graphics support for Mali T860 GPU on RockPro64
• Spoofs MAC address without being told to, in my case breaking Internet access
• Dependency tree is very bloated - installing a small Wayland compositor (Sway) pulled in 2 GiB of dependencies including LLVM. On Arch it's about 16 MiB.

FreeBSD refused to be installed on the prepared partition so I deleted it and created a new one in the partitioning step of the installation. FreeBSD installer recognized EFI partition and created EFI executables there, very nice. Install finished, on reboot U-boot recognized EFI files and offered FreeBSD as a boot option. System loaded fine, did not spoof the MAC address of the builtin ethernet interface (like it did on Cubieboard) maybe because it is written in U-boot configuration on SPI chip, so it got DHCP IP from ISP. To test if I can get a graphical desktop I installed sway and seatd. According to post-install instructions displayed by pkg, started seatd service as root, added regular user to video group, logged off and on, tried to start sway as a regular user - it couldn't find any DRM backends (no GPU devices).

RockPro64 has a Mali T860 GPU, is it not supported on FreeBSD? https:///bsd-hardware.info has no info on the board or GPU, digging in FreeBSD source code I found only this declaration:

sys/contrib/device-tree/Bindings/gpu/arm,mali-midgard.yaml
- items:
  - enum:
      - rockchip,rk3399-mali
  - const: arm,mali-t860

After some online searching it turns out DRM drivers are not part of the base FreeBSD system, they are in ports tree (FreeBSD's name for installable packages). The build definitions are available as a single git repo https://git.freebsd.org/ports.git - very convenient. According to graphics/drm-kmod/pkg-descr, only amdgpu/i915/radeon DRM modules are there. There are references to Panfrost though (Linux name for Mali GPU driver) in graphics/mesa-dri/Makefile. Mesa is userspace, not the kernel module, but I wanted to install it to see if it would pull some dependencies and make it work, unlikely but worth a try. Rebooted to FreeBSD aaand... FreeBSD spoofs the MAC address. No DHCP IP from ISP = no Internet = can't install packages.

Looks like there's no DRM driver for Mali T860 GPU in FreeBSD 14.3, making it not usable as a dekstop OS. If there is one I'll give it another try.

OpenBSD

I had a serial connection to the board at the time, so monitored the messages there - the system loads the kernel, goes through hardware enumeration to something like creating/attaching to wsdisplay0 and hangs there presenting a blank screen (the HDMI output is active though, monitor doesn't turn off). No reactions to keyboard/mouse or input via serial. Can't proceed with installation.

NetBSD

(TL;DR) Impressions:

• Installer for ARM64 is full of bugs
• Shell in installation image, which I had to use to work around said bugs, is extremely primitive - no working backspace, no history, no tab completion, not even arrow keys. Even on a physical typewriter you can move back a space, come on NetBSD...
• Spoofs MAC address without being told to, in my case breaking Internet access

Installer started by replacing firmware-provided MAC address with a generated one (same as FreeBSD, but earlier), leaving machine without internet access - so no fetching sets from mirrors. If choosing "Use already existing GPT partitions" it fails to mount EFI partition. Choosing not to mount EFI partition results in installer silently installing bootloader (EFI executable) to /boot in root partition. By default it doesn't recognize the USB stick it booted off as storage to get the sets from, so I had to manually put device name sd0a (thanks to helpful people on IRC). Choosing "Expert partitioning" (pretty much same functionality, duplicated) resulted in some other errors. While extracting the kernel from USB stick there was a warning ar: pattern ./netbsd.ub not matched but it finished anyway. After that I manually mounted the EFI partition to /tmp/efi, newly installed root partition to /tmp/root and copied /tmp/root/boot/EFI/boot/bootaa64.efi to /tmp/efi/EFI/boot/bootaa64.efi.

Well, it's a mess, ain't it, sheriff? If it ain't, it'll do till the mess gets here. (No Country for Old Men, 2007)

Remove USB stick, reboot - U-boot presented NetBSD EFI option and it booted.

On the MAC address issue people on IRC suggested checking ofctl -p to see if firmware-provided MAC was all zeroes to begin with. No - the value of local-mac-address matches the one in U-boot. So NetBSD reads MAC address of an interface from firmware but sets a new one anyway? The same helpful person on IRC suggested a workaround - create /etc/ifconfig.<ifname> with link <correct_MAC> active line. Sounds like adding a second layer of spoofing, don't like it but tried anyway - the address: line in ifconfig output changed, the link: line didn't. dhcpcd still not getting DHCP lease with this configuration - tries to solicit 2 times, gives up and assigns IP4LL 169.* address. Changing dhcpcd options to ones recommended in dhcpcd.conf for less RFC-conforming DHCP servers didn't help. Is there a way to force NetBSD to simply use MAC provided by firmware?