Looking Towards the Future: FreeBSD on the RISC-V Architecture

Looking Towards the Future: FreeBSD on the RISC-V Architecture

The majority of people in the tech community are well aware of the two main chip architectures: x86 and ARM. Each has its own strengths and weaknesses. Today, however, we’re continuing our conversation on RISC-V by introducing the way FreeBSD would work on RISC-V platforms. If you need to catch up, read our previous entry on this topic.


The software and hardware worlds are constantly evolving, so one can never get too comfortable. For decades now, much of the world has grown accustomed to the x86 architecture forming the basis of the personal computer, but the continued growth of the 64-bit ARM architecture presents a new challenge to this notion. Large-scale changes of this type are inevitable, so it is important for a project of the scale and scope of FreeBSD to be proactive about supporting the hardware platforms of the future, and letting go of the platforms of the past.

The RISC-V architecture is FreeBSD’s youngest supported platform, and despite its age it has a lot of momentum behind it. This article will introduce this history of the platform, and why this support is important for the FreeBSD project.

A Brief History

The RISC-V (pronounced “risk five”) ISA started as a research project at the University of California, Berkleley, in 2010. The intention behind this project was to provide a new CPU architecture free of the licensing restrictions that exist in other ISAs, enabling entities in academia and industry alike to design, implement, and modify RISC-V CPUs without the need to pay heavy licensing fees. This continues to be the case, as the ISA and related specifications are permissively licensed under BSD and Creative Commons licenses. RISC-V was not the first ISA to adopt such a license, but the fact that it has done so from its inception, rather than later in its life, offers something unique: a modern CPU architecture which anyone can adopt or extend, free of charge.

Work on FreeBSD’s support for this new ISA began in 2015, with the initial version of the port being merged to the FreeBSD src tree at the beginning of the following year. While this early version ran mainly on software simulators and FPGA soft-chips, this was no small feat. In fact, FreeBSD was the first mainstream open-source OS to officially include RISC-V support in its source tree. Since then, support has continued to grow and improve. The release of FreeBSD 13.0 saw the platform’s support tier increased to Tier-2, and the production of official release images.

Despite recently celebrating its 10th birthday, RISC-V is still young on the scale of CPU architectures. There exist a few RISC-V systems capable of running FreeBSD, with more arriving each year, but on the whole these chips don’t yet offer price/performance that is competitive with 64-bit ARM or x86.

What’s Involved in Porting?

Porting an entire operating system can be a huge effort. Despite the fact that we like software to have layers of abstractions, changing something as fundamental as the underlying CPU architecture has implications at all levels of the software stack.

On the surface, it might seem like most of what’s required is a compiler toolchain capable of generating RISC-V instructions. After all, C code is C code, right? For typical userspace programs making use of standard libraries, this can be the case, but it is certainly not true in general. Many of the systems and libraries that enable ‘portable’ software can do so because they themselves hide the necessary details. Things like libc, the dynamic linker, the C runtime – all of these require intimate knowledge of the processor-specific ABI, and are under the purview of the operating system to implement.

Of course, the kernel presents some of the largest portability challenges. Most modern CPU architectures offers similar – yet incompatible – interfaces for things all operating systems take for granted. Mechanisms such as trap/interrupt handling, virtual memory management, device I/O and discovery; all of these pieces of core functionality require a unique implementation adapted to the CPU in question. This collection of CPU-specific code is referred to as the Machine Dependent layer of the FreeBSD kernel, and porting it to a new architecture can take months of full-time work.

Unfortunately, the work doesn’t end there. Device driver code can often be shared across different platforms, but sometimes doing so will expose platform-specific assumptions made when the code was originally written. Bootloaders and release images present a whole other set of platform-specific challenges. New architectures will typically play catch-up for several years as they try to reach feature parity with more mature architectures.

Why Support a New Architecture?

With all this said, is the effort invested into supporting RISC-V on FreeBSD worthwhile? Surely the engineering efforts that have gone into it over the course of the past 6 years could have been used for other things, so is the expense justified? Consider the following excerpt from the FreeBSD Committer’s Guide, which describes the project’s point of view on the subject of supporting multiple architectures:

  FreeBSD is a highly portable operating system intended to function
  on many different types of hardware architectures. Maintaining clean 
  separation of Machine Dependent (MD) and Machine Independent (MI) 
  code, as well as minimizing MD code, is an important part of our 
  strategy to remain agile with regards to current hardware trends. 
  Each new hardware architecture supported by FreeBSD adds substantially 
  to the cost of code maintenance, toolchain support, and release 

You might also be interested in

Get more out of your FreeBSD development

Kernel development is crucial to many companies. If you have a FreeBSD implementation or you’re looking at scoping out work for the future, our team can help you further enable your efforts.

This notion that an architecture must justify its own maintenance costs is key to making decisions about its support over time. There have been several architectures that have come and gone along with their hardware and industry relevance, the most recent example being the removal of sparc64 support in FreeBSD 13.0. With each new release, the support status of each platform should be considered. Being proactive about removal helps reduce the maintenance burden on the project.

The decision to adopt support for a new architecture to FreeBSD comes down to two factors:

  1. Perceived interest/relevance to the Project
  2. Someone willing to do the work

Both of these points should be obvious, but are worth dissecting a little bit. Without someone able to do the work, the software support may be incomplete, or never arrive, despite any widespread interest. On the other hand, if someone were to show up one day with a complete port of FreeBSD for the VAX, they would face difficulties in getting this work accepted upstream, as the future maintenance costs of such a thing are not justified.

For the specific case of RISC-V, it met both criteria early on, resulting in the initial port. Since then, its relevance to the project and industry has only increased, attracting more committers, contributors, and users willing to do the work. Thus, the platform continues to justify itself in the eyes of FreeBSD.

What will the future bring?

At this point it is still too early to clearly see the future of RISC-V. The ISA presents a compelling case as a replacement for small and/or highly customized embedded CPUs, due to its modular and extendable nature. It is also quickly becoming the clear favorite in academia, providing a cost-free and permissively licensed platform for research and teaching. However, it is hard to say how well RISC-V will do in other areas of the industry. To compete in the server or commodity hardware spaces means going up against the giants: x86_64 and 64-bit ARM. Although RISC-V hardware and software continues to improve year after year, it still does not yet offer a clear advantage over these more well-established architectures.

Only time can tell how these things will unfold, but FreeBSD’s early and improving support for the RISC-V architecture makes it a viable option for the platforms that will be built on top of this technology.

Like this article? Share it!

You might also be interested in

Improve the way you make use of ZFS in your company

ZFS is crucial to many companies. We guide companies and teams towards safe, whitepaper implementations of ZFS that enhance and improve the way the infrastructure is enabling your business.

More on this topic

Demystifying OpenZFS 2.0

OpenZFS 2.0 has been released for a while now and, needless to say, FreeBSD 13 was shipped with OpenZFS 2.0. However, there are still questions about how the change from feature flags happened and why version 2.0 of OpenZFS was decided.
With this article, we’re hoping to clear the air around the release of OpenZFS 2.0.

Advanced ZFS Snapshots 

In our previous articles, we introduced you to the basics of ZFS snapshot management, and explained concepts such as creating OpenZFS snapshots, restoring files from a snapshot, and deleting snapshots.
With this article, we dive a bit deeper into OpenZFS snapshot management with snapshot holds, clone creation and promotion, and assigning permissions to snapshot-related operations.

Manipulating a Pool from the Rescue System

We’ve all been there: that moment of panic when a system fails to boot back up. Perhaps there was a glitch with an upgrade. Maybe you’re wondering if you fumble-fingered a typo when you made that last change to loader.conf.
Fortunately, with FreeBSD and its built-in rescue mechanisms it is possible to quickly recover from most scenarios that prevent a system from booting into normal operation. And if you’re using OpenZFS, you can rest assured that your data is intact.
With this article, let’s take a look at some common recovery scenarios.

Tell us what you think!