The RISC-V Revolution in Fedora: A Deep Dive into 3 Months of Progress, Pain, and Promise

The Journey Begins

Approximately three months ago, I embarked on what would become one of the most challenging and rewarding technical journeys of my career: bringing Fedora Linux to the RISC-V architecture. What started as a simple exploration has evolved into a comprehensive effort to establish RISC-V as a viable platform for Fedora users worldwide.

The RISC-V ecosystem represents something truly special in the computing world—an open, royalty-free instruction set architecture that promises to democratize processor design and implementation. But theory and reality often diverge, and my three-month deep dive has revealed both the tremendous potential and significant challenges of this emerging platform.

Triaging: The First Battle

My initial approach was methodical and systematic. I began by examining the comprehensive Fedora RISC-V tracker, a living document that cataloged every known issue, bug, and enhancement request for the platform. The tracker served as both a roadmap and a reality check, revealing just how much work lay ahead.

The triage process proved to be more complex than anticipated. Each entry required careful analysis to determine its severity, reproducibility, and potential impact on the broader ecosystem. Some issues were straightforward—missing dependencies, simple build errors, or configuration problems. Others revealed deeper architectural challenges that would require coordinated effort across multiple teams and organizations.

After weeks of intensive work, I managed to reduce the tracker from its initial state to just 17 entries marked as NEW. This reduction represented significant progress, but also highlighted the ongoing nature of platform development. Each resolved issue seemed to reveal another layer of complexity, creating a continuous cycle of discovery and resolution.

The Packaging Marathon

My primary workflow quickly established itself as a rhythm of discovery and iteration. Using the familiar Fedora toolchain, I would clone package sources with fedpkg clone -a, then attempt to build them using fedpkg mockbuild -r fedora-43-riscv64. This process, while straightforward in concept, often revealed subtle incompatibilities, missing dependencies, or architecture-specific issues that required creative solutions.

The results speak for themselves: 86 pull requests submitted to Fedora package repositories, ranging from heavyweight components like LLVM 15 to lightweight utilities like iyfct (a simple yet charming game). This breadth of coverage demonstrates both the comprehensive nature of the effort and the diverse challenges encountered across different types of software.

The merge rate has been encouraging, with most pull requests finding their way into the main repositories. This acceptance is crucial because it means these packages are now building for Fedora 43, allowing us to follow the ‘f43-updates’ tag on Fedora’s koji build system. This integration represents a significant milestone—RISC-V packages are no longer isolated experiments but integrated components of the Fedora ecosystem.

The Elephant in the Room: Performance

However, no discussion of RISC-V development would be complete without addressing the most contentious issue: speed. Or more accurately, the lack thereof.

The performance gap is stark and impossible to ignore. Consider the build times for binutils 2.45.1-4.fc43 across different architectures:

The numbers tell a sobering story. RISC-V builds take nearly 2.5x longer than the next slowest architecture (ppc64le) and almost 5x longer than the fastest (i686). This performance penalty isn’t just inconvenient—it fundamentally impacts the development workflow, testing capabilities, and overall viability of the platform.

Several factors contribute to this performance gap. Current RISC-V hardware typically features 4-8 cores with 8-32 GB of RAM, depending on the specific board. More critically, these cores often compare unfavorably to Arm Cortex-A55 cores—the slowest CPU cores found in contemporary Arm systems. This comparison is particularly damning because it suggests that even within the embedded and mobile computing space, RISC-V lags behind established architectures.

The situation is further complicated by our decision to disable Link-Time Optimization (LTO) system-wide. While this reduces memory usage and build times, it also means we’re not leveraging optimization techniques that could improve final binary performance. The trade-off between build efficiency and runtime performance represents a fundamental challenge in RISC-V development.

Hardware Limitations and Future Prospects

Current build infrastructure relies on a variety of boards and systems, each with its own limitations. The Milk-V Titan motherboard, featuring the UltraRISC UR-DP1000 SoC, offers some promise with support for up to 64 GB of RAM. Similarly, SpacemiT K3-based systems provide another avenue for improvement, though they’re limited to 32 GB of RAM.

While these systems represent incremental improvements, they fall short of what’s truly needed. To make RISC-V a viable primary architecture for Fedora, we need hardware capable of building complex packages like binutils in under one hour, with LTO enabled system-wide. This hardware must also be rackable and manageable like conventional servers—without these characteristics, large-scale deployment and management become impractical.

The path to viability requires several key developments: significantly faster CPU cores (likely 2-4x improvement over current offerings), substantially more memory bandwidth, and better multi-core scaling. Additionally, the hardware must meet enterprise requirements for reliability, management capabilities, and integration with existing data center infrastructure.

The QEMU Advantage

Interestingly, the performance limitations of physical hardware have made emulation via QEMU an unexpectedly valuable tool. With 80 emulated cores at my disposal, I can build the LLVM 15 package in approximately 4 hours—a task that takes over 10.5 hours on a Banana Pi BPI-F3 builder. The P550 board might offer better performance, but the gap remains significant.

This emulation capability provides several strategic advantages. First, it allows for rapid iteration during development and testing. Second, it enables parallel builds that would be impossible on the limited physical hardware available. Third, it provides a consistent environment that’s not subject to the variability of different board implementations.

The potential for even greater performance is tantalizing. The Ampere One architecture, with its 192 or 384 cores, could theoretically provide build times that approach those of established architectures. While this remains speculative, it illustrates the potential for RISC-V to eventually compete in terms of development efficiency.

Looking Forward: Fedora 44 and Beyond

The roadmap ahead includes several critical milestones. We plan to begin building Fedora Linux 44, with the goal of using the same kernel image across all builders. Currently, our infrastructure uses a mix of kernel versions, creating complexity and potential compatibility issues. Standardizing on a single kernel image will simplify maintenance and improve reliability.

LTO will remain disabled in the near term, as the performance and memory benefits of disabling it currently outweigh the potential runtime improvements. However, this decision is not set in stone—as hardware improves, we may revisit this trade-off.

The most exciting development on the horizon is the planned introduction of new, faster builders. These systems will likely be assigned the heaviest packages, creating a tiered build infrastructure that optimizes resource utilization. This approach acknowledges the current performance limitations while working within them to maximize productivity.

The Road Ahead

The journey of bringing Fedora to RISC-V has been simultaneously frustrating and exhilarating. The performance limitations are real and significant, but they’re not insurmountable. Each package that builds successfully, each bug that gets resolved, and each improvement in the build infrastructure represents progress toward the ultimate goal: making RISC-V a first-class citizen in the Linux ecosystem.

The challenges are substantial, but so are the opportunities. RISC-V represents more than just another architecture—it embodies principles of openness, accessibility, and innovation that align closely with the values of the open-source community. As hardware continues to improve and the ecosystem matures, the gap between RISC-V and established architectures will narrow.

For now, we continue the work: triaging issues, submitting patches, optimizing builds, and dreaming of faster hardware. The path forward is clear, even if the timeline remains uncertain. Fedora on RISC-V isn’t just a technical achievement—it’s a statement about the future of computing, and we’re determined to see it through.

Tags: #RISC-V #Fedora #Linux #OpenSource #Architecture #Performance #QEMU #BuildSystem #Hardware #Innovation #FutureOfComputing #OpenHardware

Viral Phrases:

• “The RISC-V Revolution is Here”
• “Building the Future, One Package at a Time”
• “When Slowness Becomes a Feature”
• “Emulation: The Unexpected Hero”
• “From Theory to Reality: 3 Months of RISC-V Development”
• “The Performance Gap That Won’t Die”
• “Hardware Limitations: The Elephant in the Room”
• “QEMU: 80 Cores of Pure Productivity”
• “Fedora 44: The Next Chapter”
• “The Road to Primary Architecture Status”
• “Open Source Hardware: More Than Just a Dream”
• “The Build Times That Break Developers”
• “When 143 Minutes Feels Fast”
• “The Memory Bandwidth Crisis”
• “Enterprise-Grade RISC-V: Still a Dream”
• “The Triage That Never Ends”
• “Pull Requests: 86 and Counting”
• “The LLVM Build That Takes All Day”
• “From Banana Pi to Milk-V: The Hardware Journey”
• “LTO Disabled: The Necessary Evil”
• “The Future is Open, But It’s Also Slow”

,