A new Fuchisa RFC proposes adding support for the RISC-V CPU architecture to Fuchsia. The proposed board name is
riscv64. The proposal was submitted on February 14, 2023, and has been approved on March 7, 2023.
RISC-V is a free and open instruction set architecture originally developed at UC Berkeley which has become increasingly popular in recent years. RISC-V International, a nonprofit based in Switzerland whose founding members include Google, defines the RISC-V specifications. All work is done through an open collaboration process that takes place on GitHub and the resulting specifications are freely available to the public. The RISC-V architecture is designed to be flexible enough to be used for everything between small microcontrollers and server-class CPUs. It has 32- and 64-bit address space variants and defines sets of instruction extensions which are grouped into categories that are convenient for modern operating system support. In addition, implementations can define custom non-standard instructions for special applications.
The recent availability of high-performance 64-bit cores from companies like SiFive has moved RISC-V from being primarily a small microcontrollers solution into the space where Fuchsia is currently doing the most development. Google believes this is the perfect time for Fuchsia to support this architecture. By building robust RISC-V support now, we will ensure that Zircon and Fuchsia will be ready to support the next generation of computing devices from the very beginning of their appearance in the market.
The open philosophy of RISC-V is a good fit with goals for the open source Fuchsia project and will help Google in collaborating with other stakeholders in the RISC-V world.
Fuchsia only targets 64-bit processors. So RISC-V support will target 64-bit CPUs only. Here we propose that only the QEMU virt platform is targeted. AEMU support is not considered in this RFC and as such, workflows or testing that require AEMU will not be supported. Support for a specific development board will be proposed separately in a future RFC.