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.

Introduction

The RISC-V architecture is FreeBSD’s youngest supported platform, but despite its age it has a lot of momentum behind it.

The world has grown accustomed to the x86 architecture forming a default basis of the personal computer, but the continued growth of the 64-bit ARM architecture challenged this notion, and RISC-V continues this challenge. On a long timeline, changes like this 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.

This article will introduce this history of the RISC-V platform, and supporting it 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. Permissively licensing the ISA and related specifications under BSD and Creative Commons licenses enables entities in academia and industry alike to design, implement, and modify RISC-V CPUs without the need to pay heavy licensing fees. 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.

The kernel itself presents some of the largest portability challenges. Most modern CPU architectures offer 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 require unique implementations 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 yet another 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 so many challenges, it’s reasonable to ask whether the effort invested into supporting RISC-V on FreeBSD is worthwhile. Surely, one might think, 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 
  engineering.

Ultimately, an architecture must justify its own maintenance and support costs. Several architectures that have come to and gone from FreeBSD as their hardware and industry relevance changes—the most recent example being the removal of sparc64 support in FreeBSD 13.0. Being proactive about removal helps reduce the maintenance burden on the project, so the support status of each platform should be considered with each new release.

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

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?

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. Although it is being rapidly adopted in the embedded / microcontroller spaces where flexibility and low cost are key, the general purpose computing spaces are much more difficult to break into. Competing 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 in general-purpose computing environments.

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!

• Share on Facebook
• Share on Twitter
• Share on LinkedIn
• Share via Email
• Share on Reddit