Patrick Wildt ( patrick@ ) reports on progress with arm64 platform support:

I knew that as soon as I stepped out of the airplane, I would be going to melt. In preparation for my impeding death I had spent the week before on debugging and bringing up the OpenBSD/arm64 port in QEMU.

Surprisingly I survived the heat (it actually cooled down only for me I think), and as history now shows, even the deadly spiders preferred to keep me alive. I wonder what kind of stakes they got in the port's success...

When I arrived at the hackathon I had arm64 running in QEMU, and I somehow had managed to work around the 100 blobs to start our kernel on the Pine64. Since QEMU is rather slow and we really prefer running on real hardware, no matter how much of a toy it is, I got to work and implemented the driver bits for the Pine64. After an interesting debugging session with deraadt@, finding a few uninitialized variables, we finally had OpenBSD running on actual hardware. Now this allowed us to start working on a release build.

And that's where the waiting game begins. Even though arm64 sounds fast, the Pine64 as I used it isn't. First of all, we only use one core. We don't change the core's frequency. There is only one USB port available (connected to EHCI instead of OTG). MMC doesn't work right now and would probably not be any faster. We don't support the Ethernet chip yet. So in the end I had a USB hub with two USB drives and an USB-to-Ethernet adapter on a single USB port. Well, that does not scream performance at all.

The biggest changes required to make this port work is not only doing the machine-dependent code, but all the infrastructure changes around it. This port will be the first architecture that does not use the in-base GCC. Instead it relies on the LLVM project's clang as our new compiler, but also lld as the linker as our binutils is way too old to support the 64-bit ARM architecture. LLVM's lld has grown a lot over the last few months, which made it essential to upgrade the in-base LLVM to the 4.0.0 Release Candidate 1. With that all set, we still need tools like objdump, objcopy, readelf and more. Fortunately most of these can be enabled by implementing a rather dummy 64-bit ARM implementation in binutils 2.17. Which is exactly what kettenis@ promptly did.

We're still missing a few pieces here and there, there are plenty of tiny bugs here and there, but it's slowly coming along. The biggest hurdle is finding proper server hardware to work with and run future release builds on. We're still looking for that.

All that said, it has been a team work effort where basically Dale Rahn did all the heavy lifting on the 64-bit ARM bits, relying on a bit of preparation that I had done before, which I then was able to put together to a running port.

Huge thanks to the OpenBSD Foundation for enabling my journey to a2k17 to meet up, discuss and work with my fellow ARM enthusiasts. Without dlg@ and jmatthew@ the a2k17 would have never happened, so I want to thank you as well. It's been a pleasure, see you next time.