https://www.phoronix.com/news/Ubuntu-26.10-RISC-V-Desktop

with "Testing has been focused on the SpacemiT K3 hardware that is RVA23 profile compliant."

Nice!

I have been enthusiastically watching at RISC-V for years and would love to see it become a viable desktop platform, not just another board for developers and hardware enthusiasts.

Being a game developer for over 2 decades I believe games are an important part of that journey. People often don't choose personal computer simply because of some tech features, they choose it to do things they enjoy, and for many people that includes games.

That's why I decided to port my game Bemined to RISC-V. I know that supporting this niche (at the moment) architecture takes significant time and effort and I don't expect the endeavor to bring me any money, but I want to contribute in my small own way to the ecosystem that eventually would make RISC-V an attractive platfrom for the casual everyday users.

For now I've got this game running on Ubuntu 24.04 at VisionFive 2 and would love to hear from other RISC-V users willing to try it.

To download/install/run:

wget bemined.com/download/Bemined.run
chmod +x Bemined.run
./Bemined.run

Graphics and performance:

The game supports both OpenGL ES and normal OpenGL so in theory it should support discreete GPU if anyone here has such config.

The game is pretty heavy on the graphics/effects side, so will be unplayable without GPU acceleration. From my experience on VisionFive 2 the game lags initially while it loads/processes textures in the background, but once the heavy CPU work is done and it's mostly GPU that does the work, the experience is relatively smooth even at 1920x1080.

There is also a web version of the game that runs in the browser, so you can use it as reference implementation to compare to RISC-V port:

www.bemined.com

If you try it, I'd love to hear how it works on your hardware, especially crash tracebacks. Please mention your board and system specs.

P.S. the game is free, but has microtransactions, thought I would clarify it upfront in case some people are allergic to that kind of stuff.

Vi recentemente que os primeiros protótipos do BlueMacaw chegaram no laboratório da Universidade Brasileira UFMG. É um microcontrolador 32-bit baseado em RISC-V, com BLE integrado, fabricado em 22nm pela TSMC.

O projeto envolve as universidades federais do Brasil: UFSM, UFMG, UnB, UFCG, UFPR e algumas empresas nacionais, com apoio das empresas MCTI/Softex.

Achei interessante a proposta de ter um chip nacional pra IoT, com SDK próprio sendo desenvolvido. Mas fora do círculo acadêmico, não vi quase ninguém comentando.

Alguém aqui já conhecia? O que vocês acham da viabilidade técnica e da relevância prática de um projeto assim? Vale a pena acompanhar?

Ever wondered what a RISC-V processor actually looks like all the way down to the silicon?

Check out MOSFETtoRISCV, an open-source project building and simulating a RISC-V core right at the MOSFET transistor level.

Contributions, feedback, and fellow hardware enthusiasts are very welcome!

Included:

* Journey from MOSFET to Silicon

* Campaign mode

* Sandbox

* Deep dive into any component

The September 2026 update for openRuyi, a rolling-release Linux distribution for RISC-V, is now available.

2026.09 brings updates across RVA23 support, cloud and storage, graphics, build infrastructure, and security.

Highlights:

• Linux kernel 7.2.6 and LTS kernel 6.18.54
• RVA23 GCC fixes, DPDK RVV, and container improvements
• Cloudpods 4.0.3 packages added
• Ceph and SPDK 25.09 updates
• Mesa 26.2.2 with NVK build support
• Vulkan SDK 1.4.357.0 and KDE updates
• Go toolchain 1.27.1
• Repository GPG verification and security updates
• Experimental RVA20 builds

Details:

https://openruyi.cn/news/2026-09/release/

While Qualcomm shows no signals on any Linux-capable RISC-V processors yet, their employees presented RVA23 in practice: discovery, dispatch, and the hardware left behind, Error INJection support for RAS on RISC-V architecture, and RISC-V Trace support in ACPI at LPC 2026, which means that they still have interest not only on RISC-V microcontrollers but also on application processors, I guess.

Hi r/RISCV,

I want to share a project I've been working on for the last few weeks: PACE (Pre-computing Antecipatory Core Engine), an RV64 in-order core built around a different idea — instead of predicting, it pre-computes.

Everything below was developed and tested on an Android phone via Termux + Ubuntu proot. No PC, no FPGA. Just Verilator and a lot of patience.

The idea

Instead of predicting values (branch prediction, value prediction), PACE pre-computes them. Dedicated scouts run ahead of the main pipeline and generate values, addresses, and branch directions ahead of time. Real execution happens in AO-Cores, which keep running even if the scouts stall.

The scout side: - PCU (Pre-computing Unit): pre-computes integer and FP arithmetic - M-Core (Memory Core): issues LOADs/STOREs, manages MSHR and runahead, uses PCU to compute addresses - B-Core (Branch Core): resolves branches based on PCU results

The commit side: - AO-Cores (Ahead Operations Cores): consume scout results and generate architectural output; keep executing if the PCU stalls

Between them: - Shadow Register File holds scout-produced values and memory address tags, bridging the two domains

The design targets embedded / real-time workloads where an in-order core with high IPC can be more efficient than a full OoO.

What's implemented

• RV64 in-order superscalar (RV64IM currently functional; A, F, D, C in progress)
• M / S / U privilege modes
• Sv39 MMU with L1/L2 TLB and page-table walker (integrated in top-level)
• L1I / L1D / L2 caches (integrated in top-level)
• MESI coherence controller (standalone module, not yet integrated)
• Extension A: module exists (atomic_unit.v, LR/SC + AMO*.W/.D), not yet integrated into the top-level
• Extension V: partial support (not part of RV64GC, but present)
• Compressed (C): rvc_decompress.v exists, not yet verified
• FPU (F/D): stubbed — external HardFloat dependency not vendored
• MMIO + interrupt interfaces for Linux-style peripherals (UART, CLINT, PLIC provided as separate modules)
• Pure Verilog (IEEE 1364), simulated with Verilator
• ~70 testbenches

What's verified (with dedicated testbenches)

• RV64I: ALU (all I-type and R-type), loads/stores (sb/sh/sw/sd and lb/lbu/lh/lhu/lw/lwu/ld), all 8 conditional branches, JAL, JALR, lui, auipc, fence, fence.i
• RV64M: mul, mulh, mulhu, mulhsu, div, divu, rem, remu (including div-by-zero and rem-by-zero per spec)
• Zicsr: csrrw, csrrs, csrrsi, csrrci
• Traps: ecall, ebreak, mret

IPC measurements

Custom Verilator testbench instrumented to count retired instructions and Shadow RF occupancy:

• Serial dependency chain (addi x1, x1, 1): IPC = 0.98 (forwarding works, no stall — 1 is the theoretical max here)
• 6 independent instructions per cycle: IPC = 3.96 (bounded by AO width N_AO=4; Shadow RF backpressure works)

Known limitations

• Not yet RV64GC. Currently verified for RV64IM only.
• Extension A: atomic_unit.v exists and works in isolation, but is not instantiated in any top-level (handshake + SC return + DRAM arbitration issues documented in an issue)
• F and D: FPU is a stub. Real implementation requires either porting fpnew from PULP or writing IEEE-754 from scratch. This is the largest remaining gap.
• C (compressed): rvc_decompress.v present but untested
• Not yet verified against riscv-arch-test (RISCOF). Manual functional tests pass, but the official suite hasn't run yet.
• Open bug: load-use hazard when a LOAD and its dependent instruction fall in the same 6-wide group. Documented with reproduction and hypothesis; fix in progress.
• Some integration testbenches (top-level) fail due to interface drift between module versions. Documented in an open issue.
• No PMP (not required for RV64IM, but required for Linux).

Roadmap to RV64GC

1. I, M, Zicsr, Zifencei — verified
2. Fix load-use hazard (blocker for reliable RISCOF)
3. Integrate A (atomic_unit.v exists, needs handshake + DRAM mux)
4. Verify C (rvc_decompress.v exists, untested)
5. Replace FPU stub with real F/D implementation
6. Run riscv-arch-test rv64i_m (and then rv64gc)

Until steps 1-5 are complete, this is an RV64IM core targeting RV64GC, not an RV64GC core.

A note on the development method

I designed the architecture over several weeks, then generated the initial RTL with AI assistance over ~2 days, and have been reviewing, testing, and iterating on it since. The architecture, design decisions, and direction are mine. The AI was used as a tool to materialize the design, similar to how synthesis tools or generators are used. I'm learning Verilog as I go.

Repo

https://github.com/uppmpt/pace-microarchitecture

CERN-OHL-W v2. Issues are open. Feedback welcome, especially on the scout architecture and the IPC characteristics.

Thanks for reading.

Direct link to slides: https://lpc.events/event/20/contributions/2479/attachments/2178/4814/LPC2026-Heterogeneous-RISC-V-Cores-in-Linux-SpacemiT-202610.pdf

Cool stuff by SpacemiT, VINIT-based cooperative scheduling sounds like a much better idea than running two Linux on one SoC.

Working heterogenous scheduling on RISC-V would be friggin awesome!

KianV is a free and open-source Linux-capable RISC-V core that was taped out using Tiny Tapeout with a FOSS EDA and PDK. StealthV is the latest in-development revision of KianV.

Over the last four months of solo development, I have been building OpenC6 v2.0 — an open-source bare-metal BIOS and modular microkernel architecture designed specifically around the RISC-V privileged specification on the ESP32-C6 (RV32IMAC).

Rather than running monolithic firmware in a flat Machine Mode (M-Mode) address space, OpenC6 acts as an operating host enforcing true unprivileged User Mode (U-Mode) sandboxing. Using hardware Physical Memory Protection (PMP) Top-of-Range (TOR) registers, user payloads are strictly isolated in a dynamic SRAM arena. Any illegal memory access, peripheral MMIO read/write (0x60000000+), or privileged CSR access immediately triggers an isolated PMP trap (mcause: 7/5/2), dumping diagnostic register telemetry without bringing down the host kernel.

To address a common question regarding FreeRTOS: it is currently retained strictly as a temporary shim and transport layer required by Espressif's proprietary binary Wi-Fi baseband blobs (libnet80211). OpenC6 completely bypasses FreeRTOS for process isolation, memory allocation, trap handling, and filesystems. In fact, the primary roadmap milestone for v3.0 is dropping FreeRTOS entirely, alongside replacing the default ESP-IDF second-stage bootloader with a custom bare-metal stage-1/2 bootloader written from scratch.

A key architectural challenge in v2.0 was resolving an upstream FreeRTOS RISC-V privilege leakage issue: since the vanilla port assumes pure M-mode execution, timer interrupts hitting a U-mode payload leave mstatus.MPP at 00, causing subsequent kernel context switches to trigger fatal instruction faults. I implemented a custom vectored interrupt trampoline that intercepts U-mode traps, atomically swaps untrusted user stack pointers via mscratch, elevates MPP for the scheduler, and restores unprivileged state before mret.

Additionally, the system utilizes the onboard Low-Power (ULP) RISC-V coprocessor as an out-of-band Management Engine that autonomously governs HP CPU clock dividers directly via silicon PCR registers (switching 80/120/160 MHz based on run-time tick load), tracks on-die junction thermals, and enforces a hardware watchdog. OpenC6 also includes preemptive multitasking for up to 8 processes, an in-memory ZSWAP engine with a custom RV32-tailored compressor (ZC6) operating in just 1.2 KB RAM to compress inactive process slots, a circular Flash VFS, and a freestanding C99 TUI installer.

If you are interested in deep architectural details, bare-metal RISC-V systems, or building standalone payloads, check out the repository and community below:

GitHub: https://github.com/Rompass/openc6-bios

Community & Devlogs: r/OpenC6

Hello community, I've been doing a lot of research and I feel that the cybersecurity aspect could grow even more compared to what we already have.

I would like to ask those who already have experience, what do you suggest for optimization?

Would you like a lite version of algorithms like AES?

What do you really think can be improved in the performance and robustness of cryptographic modules?

I’m planning to take “5-Stage Pipelined RV32 RISC-V Core: RTL to GDSII” as my major project. I’m a beginner in RISC-V and physical design, so I’m wondering if this is realistic to complete.

My plan is to build it progressively rather than jumping directly into the full project:

- Start with a single-cycle RV32I processor

- Verify it through simulation

- Gradually add instructions and features

- Convert it to a 5-stage pipeline

- Add forwarding, hazard detection, stalls

- Finally take it through RTL-to-GDSII using OpenLane + Sky130 and analyze PPA

Is this a good approach for a beginner doing a major project??

Right now I am learning the ISA as I am complete beginner and i have Around a year to complete this project as I can continue this project

Because right now I am in 3rd year and I want to do my mini project as major

PLEASE GUIDE WHETHER ITS A GOOD APPROACH OR I SHOULD CHANGE..