Welcome to the FOSDEM 2026 RISC-V DevRoom
FFmpeg is the most versatile multimedia codec and format support library, and was one of the first open-source project to include some RISC-V-specific optimisations, though there is still a long way to go. The RISC-V Vector extension was also the first scalable vector extension to be supported. We will cover the background, challenges and outcomes of this effort.
https://www.ffmpeg.org/
A discussion of historical lessons that RISC-V did learn from, and mistakes that it repeated. Focused on the design constraints forced by RVC and RVV, as well as the choices around breaking out the F and D profiles out from a mandatory vector unit, and the state changes that come with it.
The broad context will be specific to OoO SS processors
Efforts to port Fedora Linux to RISC-V began in 2016, long before physical hardware was accessible to developers. Today, the vast majority of Fedora packages have already been ported to riscv64 (i.e. the RV64GC baseline) and OS images—both generic and board-specific—are available for recent releases.
RISC-V is currently an alternative architecture in Fedora, so these (non-official) images are built by a dedicated team of community contributors, the Fedora RISC-V team. However, the end goal is to make RISC-V a primary architecture on Fedora.
So, what changed since the last update at DevConf 2024? What does the path for RISC-V to become a primary architecture on Fedora look like? What are we currently working on and what are our future plans?
Beyond software, we'll also survey the current hardware reality. Today several development boards are available. If one is getting started with RISC-V today, what board to pick? We'll review the available hardware, from the "VisionFive 2" to other capable boards, and outline our experience building Fedora on it.
Finally, whether you have a board on your desk or just a desire to contribute, there are many ways to help push Fedora’s RISC-V journey across the finish line. Join us to learn more!
This talk will introduce the architecture and instruction set of the ET Minion, a RISC-V CPU with custom extensions used in the ET platform, AI Foundry's open-source manycore architecture.
The talk will describe the details of the custom vector and tensor extensions implemented in this minimal RISC-V core.
For more information about the ET-platform and AI Foundry, visit https://github.com/aifoundry-org/et-platform
In this talk I'll present the pain and joy of working on a BootROM we use for booting our RISC-V SoC prototypes in the lab, with networking capabilities. First I'll give an overview on how writing bare metal code looks like, the challenges one has to deal with, and how we solved it in a prototype-independent way. Then I'll present netboot as an example use case, give an idea of the constraints we had to deal with and where they came from, why such a thing is a requirement when working with SoC prototypes (or even in production), how I did it, and finally do a live demo if time permits.
Last year, I gave a talk about running upstream embedded Linux on RISC-V with the powerful SpacemiT K1-based Banana Pi BPI-F3 as an example. Fast forward one year, and we have many a new contender on the block. This talk first revisits the BPI-F3, looking at the upstreaming progress made and issues remaining. Secondly, it introduces the new Siflower SF21H8898-based Banana Pi BPI-RV2, the ESWIN Computing EIC7700-based EBC77 with SiFive HiFive Premier P550 cores and the Ky X1-based Orange Pi RV2 and R2S. Those are all interesting new boards I added to my embedded Linux testing lab. Comparing the various downstream vendor options with the upstreaming efforts will show us the overall progress embedded Linux has made on RISC-V. Last but not least, I will discuss the upcoming RVA23-compatible boards based on chips like the SpacemiT K3 SoC with its X100 cores, the Tenstorrent TT-Ascalon IP SoC, the UltraRISC UR-DP1000 and the Zhihe A600 SoC. The time is truly ripe for embedded Linux to shine on RISC-V!
RISC-V hardware momentum is everywhere: more tape-outs, more open cores, more startups, and increasingly affordable boards that everyone can try. But hardware alone doesn’t make a usable platform. From blinking LEDs to critical space exploration missions, adoption depends on the software ecosystem being mature, well-integrated, and ready for developers to rely on.
So, how ready is RISC-V software today? Toolchains, kernel support, hypervisors, RTOSes and simulators are all evolving, but progress happens at different speeds across the stack. Users still encounter rough edges, and contributors often struggle to navigate the ecosystem and find where help is needed most.
This talk shares a personal journey through RISC-V software enablement: from building Linux images and contributing to Zephyr, to enabling hypervisors and firmware. I’ll highlight what’s solid, what’s still forming, and the challenges faced along the way - and how anyone can begin contributing and using RISC-V.
The last decade of CPU vulnerabilities has shown how microarchitectural performance optimizations can undermine isolation. Transient execution attacks like Meltdown and Spectre exposed deep flaws in x86 CPUs. RISC-V, by contrast, enters with the promise of simplicity and transparency—a clean slate. Yet the question remains: will we repeat the same mistakes, or can we design a secure architecture from the start?
This talk takes a critical look at how RISC-V implementations handle microarchitectural security today. We show that even "simple" in-order designs already suffer from architectural flaws and powerful side channels. In our earlier work, we demonstrated novel attacks, such as Cache+Time and CycleDrift, on the first commercial RISC-V CPUs, exploiting unprivileged access to instruction-retirement counters and cache-timing leakage.
But manual analysis does not scale. RISCover, our open-source differential fuzzing framework, automatically discovers architectural vulnerabilities across closed-source RISC-V CPUs. By comparing instruction behavior across 8 commercial CPUs from 3 vendors, RISCover found what manual analysis missed: GhostWrite, a bug in T-Head's XuanTie C910 that lets unprivileged code write directly to physical memory, completely bypassing virtual memory isolation. We also discovered multiple "halt-and-catch-fire" sequences that crash CPUs from userspace, leading to denial-of-service.
These findings reveal a pattern: while the RISC-V specification provides strong security primitives (e.g., PMP and cleaner privilege separation), implementations consistently choose insecure defaults—leaving unprivileged timing sources enabled, shipping undocumented vendor extensions like XTheadVec without proper validation, and omitting features to limit speculation. RISC-V is at an inflection point: the architecture is still young enough to fix, but adoption is accelerating fast. The decisions vendors make today—insecure defaults, unvalidated extensions, missing mitigations—will be baked into billions of chips we cannot patch.
Why buy a bottle when you can have your own keg? Open source hardware might not shout “free beer” but the new Unified RISC-V IP Access Platform, maintained by OpenHW Foundation, is just that – free recipes for your own free-flowing beer. From CVA6 superscalers to UVM support on Verilator, Chips JU project TRISTAN has united Europe’s biggest industry players with academia to move open source semiconductors from the lab to the real world. Now with the UAP, you can benefit from all of this hard work. In this talk, you’ll get uncensored access to recent advancements in European RISC-V, and a demonstration of how you can immediately leverage industry-ready open source designs from projects across Europe, all explained with glorious beer.
In the course of the past months, Michael has contributed to support for OrangePi RV2 and R2S in the mainline Linux kernel (6.19+), in Yocto's meta-riscv BSP layer and hopefully before FOSDEM 2026, in the U-Boot bootloader. Hoping to attract more users and contributors, and to inspire owners of other RISC-V boards, this presentation will review what has been done so far and the necessary steps to achieve this. It will also cover what's left to do on each board.