OpenBSD Journal

a2k17 hackathon report: Patrick Wildt on the arm64 port

Contributed by rueda on from the pining-for-proper-server-hardware dept.

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.

Thanks Patrick!

(Comments are closed)


Comments
  1. By schojo (185.130.205.167) on

    if you need help testing, i have a rpi3 lying around that has nothing to do...

    Comments
    1. By Anonymous Coward (188.110.76.206) on

      > if you need help testing, i have a rpi3 lying around that has nothing to do...

      https://www.blueri.se/openbsd/arm64/current/

      Here you go...

  2. By Jon (ventejuy) on http://ventejuy.es

    "100 blobs to start our kernel on the Pine64", this is a bit disappointing. So ARM is not cleaner than amd64 ...

    Comments
    1. By Anonymous Coward (2003:78:ef2c:de00:8131:899a:acd1:30b2) on

      > "100 blobs to start our kernel on the Pine64", this is a bit disappointing. So ARM is not cleaner than amd64 ...

      It's the same thing everywhere. Only on the Pine64 you actually see the blobs. It's the same stuff with the Raspberry Pi. If you don't see it you don't care.

  3. By Anonymous Cowboy (62.210.83.220) on

    Why bother with yet another heavily-proprietary SBC? https://www.youtube.com/watch?v=3CKO9kWLxS4

    They only seem to care about Android apps.
    How is this compared to the RPi?

    Probably better off waiting until lowRISC SoC and hardware shows up before even bothering with a port.

    Comments
    1. By Patrick Wildt (2003:78:ef2c:de00:8131:899a:acd1:30b2) on

      > Why bother with yet another heavily-proprietary SBC? https://www.youtube.com/watch?v=3CKO9kWLxS4
      >
      > They only seem to care about Android apps.
      > How is this compared to the RPi?
      >
      > Probably better off waiting until lowRISC SoC and hardware shows up before even bothering with a port.
      >

      I would prefer to work on server-type machines. If you go to AMD you spend at least $500. If you go to Cavium you spend at least $1700. If you take that thing you spend $35. Give OpenBSD nice hardware and you'll see us work on that instead.

      Comments
      1. By Motley Fool (MotleyFool) on

        I have some Cavium systems in my lab running Linux. In conversations with them I suggested they provide h/w to OpenBSD project, so far I have not been able to convince them to do so.

        I'll contact them again, see if I can get them to move on this request.

    2. By kraileth (212.77.224.251) on elderlinux.org

      > Probably better off waiting until lowRISC SoC and hardware shows up before even bothering with a port.

      lowRISC will be RISC-V based and RISC-V is not ARM. I also hope that they will succeed in providing a real alternative that's an Open Hardware solution, but that's going to take some more time. RISC-V and OpenBSD could be a dream come true but we're living in today's world and so ARM64 is a good thing to run on (and an excellent "excuse" to get LLVM/Clang into base!). Thanks a lot for your work, Patrick and everybody else who drives this forward!

      And while we wait for usable RISC-V hardware (obviously a requirement for OpenBSD to even bother taking a closer look), we can always play around with it in Qemu. On the BSD side of things a lot of work has been done on FreeBSD and I think NetBSD, too. Definitely enough to get your feet wet for anybody seriously interested in that arch.

      Comments
      1. By Chas (142.79.57.1) on

        > I also hope that they will succeed in providing a real alternative that's an Open Hardware solution, but that's going to take some more time.

        Isn't Sparc T2 completely open?

        http://www.oracle.com/technetwork/systems/opensparc/opensparc-t2-page-1446157.html

        Isn't the LEON Sparc also open?

        http://www.gaisler.com/index.php/products/processors/leon3

        Comments
        1. By kraileth (212.77.224.251) kraileth@elderlinux.org on http://www.elderlinux.org

          > > I also hope that they will succeed in providing a real alternative that's an Open Hardware solution, but that's going to take some more time.
          >
          > Isn't Sparc T2 completely open?
          >
          > http://www.oracle.com/technetwork/systems/opensparc/opensparc-t2-page-1446157.html
          >
          > Isn't the LEON Sparc also open?
          >
          > http://www.gaisler.com/index.php/products/processors/leon3

          Let me quote just this from your second link: "The full source code is available under the GNU GPL license, allowing free and unlimited use for research and education. LEON3 is also available under a low-cost commercial license"

          If it's that vs. BSD-licensed RISC-V, I'm totally on RISC-V's side. Yes, it's a pitty what happened to SPARC technology in general, but what you link to here are quite obscure projects that failed to really get traction. It's there but it hasn't taken off noticeably. And worse: It's been there for a bit of time already and didn't do that well. RISC-V is fairly new and already a lot of the big players gathered around it.

          Sure, it has yet to prove its worth, there's no guarantee that it'll succeed. But after hoping for the GPL'd OpenRISC to become a thing I'd rather place my bets (and hopes) on RISC-V now.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]