A short demo of openRuyi Creek running on the SpacemiT K3 Pico ITX with EDK2 UEFI firmware.

This demonstrates a RISC-V board booting through an open UEFI firmware stack and launching openRuyi Creek with a Wayland desktop environment.

Hardware / Software:

• Board: SpacemiT K3 Pico ITX
• SoC: SpacemiT K3
• OS: openRuyi Creek riscv64
• Kernel: Linux 7.3.0
• Wayland compositor: labwc (wlroots-based)
• Firmware: EDK2

Graphics / System:

• glmark2-wayland
• OpenGL rendering information
• System monitoring with htop

Project: openRuyi
https://github.com/openRuyi-Project/openRuyi

Firmware: Ruyi Firmware
https://github.com/openRuyi-Project/ruyifirmware

Video demo:
https://www.youtube.com/watch?v=nWcAJ6ZVwnM

It uses Baikal Electronics BE-U1000, a microcontroller with two CloudBear BR-350 RV32IMAFCB cores at 200 MHz and one BR-310 RV32IMCB core at 100 MHz. Long time since Russian companies stopped joining RISC-V Summit, but they still do their business.

I have been working on rvwasm: a full Debian riscv64 desktop running KDE Plasma 6, entirely inside a browser tab. Nothing is streamed from a server; the whole machine runs on your own computer, in the page. This is a follow-up with what changed since the first post, with a bit more on the RISC-V side for this sub.

Try it: https://plasmaontheweb.com (Chrome / Edge / Brave are fastest, Firefox works too; a fast CPU helps a lot)

Source: https://github.com/Pogo-Bash/rvwasm

The RISC-V part

• The userland is the real Debian trixie riscv64 port: unmodified packages straight from the Debian mirrors. apt-get install works.
• Every riscv64 binary runs through rv, a riscv64 (RV64GC) → WebAssembly JIT I wrote. It translates whole regions of guest code to wasm at run time, and keeps the translations in a cache that survives across visits, so a second visit starts warm.
• Since the last post the JIT’s memory-access path got reworked (page-check grouping, wasm branch hints): in Chrome, a jbox2d physics benchmark runs 29% faster and CPython 13% faster. It’s still far from native: about 18× slower than native on that physics benchmark, measured before this change.
• fork() for riscv64 programs is done inside the emulator by copying the guest, so bash, apt, dpkg and Python behave like on real hardware.
• Chromium and Firefox ESR (riscv64 builds) both run inside the machine, slowly.

How the rest works

• Kernel: Joel Severin’s linux-wasm, a Linux kernel compiled to WebAssembly where every process is a Web Worker.
• The desktop is native WebAssembly: plasmashell, Qt 6 and KDE Frameworks are compiled straight to wasm, so the panel, Kickoff and widgets don’t go through emulation.
• New: Konsole, Dolphin, Kate, System Settings, Okular, Gwenview and Ark are now native wasm too, and they’re the default. The first launch downloads their libraries, then each one opens in 2–3 s. Everything else is riscv64 through the JIT.
• Wayland: a small compositor written in JavaScript runs in the page.
• GPU, sound and video: OpenGL goes to WebGL2/WebGPU through virgl. Sound goes through a kernel sound card to PulseAudio and the page’s audio output. Video decodes on your real GPU through WebCodecs (VA-API). New: experimental Vulkan over WebGPU with ?exec=webgpu (Chrome/Edge).
• Networking goes through rvRelay, a relay limited to an allowlist (Debian, PyPI, npm, GitHub, crates.io, the KDE Store, a few weather services). It isn’t an open proxy.

New since the last post

• Firefox support (as the host browser): it works, it’s just slower than Chrome.
• KDE Store / Get New Stuff: Global Themes and widgets install from inside System Settings. Catppuccin Mocha installs in about 20 s in Chrome, weather widget included.
• The network tray icon shows rvRelay as a Wi-Fi network, so you can see when the machine’s network is up.
• Links you open inside the machine pop up a prompt and open in a real tab of your own browser.
• Xwayland only starts when an X11 app needs it, which saves memory at boot.
• In progress: memory protection, where each process gets its own WebAssembly memory instead of all sharing one. That also gives native wasm programs a real fork(). It’s not live yet.

Rough edges, honestly

• It needs a fast CPU per core (Apple M1+ or a recent Intel/AMD); 16 GB of RAM is comfortable.
• The first visit downloads about 1 GB before the desktop appears, so give it a minute or a few on slower connections. Later visits are cached.
• Emulated riscv64 apps (Firefox, compiling things) are much slower than the native ones.
• Some widgets still don’t render fully. Anything that uses Qt Quick ShaderEffects isn’t drawn, because the software renderer doesn’t support them.

This is an unofficial hobby project, and I’m not affiliated with KDE e.V. or Debian. Huge thanks to the Debian riscv64 porters (none of this works without that port), the KDE developers, and Joel Severin for linux-wasm, which everything sits on.

I’d love feedback, especially on the JIT side. If you know RISC-V emulation, binary translation or wasm codegen, tell me what you’d do differently, what’s slow on your machine, and which riscv64 software you’d want to see running.

project was assisted by claude code

Last week we set up a SpacemiT K3 board and AMD GPU at the openKylin booth and people could come up and play x86 games on RISC-V via felix86.

Here's a pic of the setup:

Hi r/RISCV! I've been building **YesOS**, a bare-metal OS for RV64GCV (`rv64gcv_zba_zbb_zbc_zbs`) written from scratch in C, Rust `no_std` and assembly: no Linux, no libc, no OpenSBI, no binary blobs. It's inspired by TempleOS.

It uses the ISA in a slightly unusual way, which is why I'm posting here:

- **M-mode only, isolated by the PMP.** There is no S-mode or U-mode. Every hart programs its PMP with the **L bit set**, so the rules bind M-mode itself until reset. The layout (NULL guard, R-X `.text`, R-- `.rodata`, RW- data/heap, one RWX JIT arena, a private key region and a locked deny-all catch-all) uses 9 of 16 entries under QEMU.

- **The layout is proven, not just generated.** At build time a script reads the linked ELF, computes the `pmpaddr`/`pmpcfg` values (TOR + NAPOT) and asks **Z3** to prove that, for every physical address and access type, the hardware semantics match the policy (W^X outside the JIT arena, immutable code, nothing falling through to M-mode's default allow). A mutation self-test checks that 7 deliberately broken layouts are rejected. If the proof fails, the ELF is deleted. At boot, each hart writes its PMP, reads it back and sweeps it against the build certificate.

- **PMP "cells" for untrusted code.** A hart locks its own PMP so it only sees its runtime, a 64 KiB code arena and 192 KiB of data. The PMP doesn't cover CSRs, so an instruction verifier rejects the SYSTEM opcode class (CSRs, `ecall`, `mret`, `wfi`), `fence.i`, compressed and custom encodings.

- **A key kept in vector registers.** The vault key lives only in `v30`/`v31` of a dedicated "key hart" and never touches memory. The C code on that hart is compiled without V (clang emits RVV even for struct copies), and a build check walks the call graph to make sure no vector instruction is reachable outside the assembly that holds the key.

- **Zkr** `seed` for entropy (probed at runtime, with a warning when it's missing, e.g. on the JH7110), **Zbc** for CRC, and **CLINT `mtime`** as the clock.

Boot excerpt (QEMU `virt`, 4 harts):

```

[ OK ] PMP locked on hart 0: 9/16 entries, 56-bit PA, Z3-proven + boot-verified

[ OK ] PMP cell on hart 3: locked 6 entries, readback verified

[ OK ] Key hart 2: private key vault locked (9 PMP entries), DEK never visible to other harts

[ OK ] Key hart 2: DEK held in vector registers only; XChaCha20-Poly1305 KAT matches RustCrypto

[ OK ] CPU : RISC-V RV64GC + Zba/Zbb/Zbc/Zbs + RVV 1.0 (VLEN 128)

YesOS [/]> pmp

pmp0 addr=0x0000000000004000 cfg=0x88 TOR --- LOCKED

pmp1 addr=0x0000000020000000 cfg=0x8B TOR RW- LOCKED

pmp2 addr=0x0000000020010C00 cfg=0x8D TOR R-X LOCKED

pmp3 addr=0x0000000020015400 cfg=0x89 TOR R-- LOCKED

pmp4 addr=0x00000000203AFC00 cfg=0x8B TOR RW- LOCKED

pmp5 addr=0x00000000203F0400 cfg=0x8F TOR RWX LOCKED

pmp6 addr=0x00000000205F4C00 cfg=0x88 TOR --- LOCKED

pmp7 addr=0x0000000028000000 cfg=0x8B TOR RW- LOCKED

pmp8 addr=0x003FFFFFFFFFFFFF cfg=0x98 NAPOT --- LOCKED

```

On top of the core there are three products: a NAS (TLS 1.3 inside the kernel, WebDAV, snapshots), an invisible bridge firewall, and a desktop that's just starting.

**Honest limits:** it runs under QEMU only, with virtio devices. The Orange Pi RV2 (SpacemiT X1) and the VisionFive 2 (JH7110) build and link with their own PMP layouts, but they still need storage and network drivers, and the CLINT address and timebase are QEMU's for now. The PMP doesn't stop the kernel from reading its own data, and it doesn't cover DMA.

Built with heavy AI assistance (Claude); the design, priorities and review are mine.

Code (MIT): https://github.com/yesos-project (start with `yesos-core`).

Questions for people who know the hardware:

1. I use classic PMP with the L bit, not **Smepmp** (`mseccfg.MML`/`MMWP`) yet. For an M-mode-only design, would you move to Smepmp, and is it available on current boards?

2. Does anyone know the PMP entry count and granularity on the **SpacemiT X60** cores? The Orange Pi RV2 layout needs 9 entries.

3. Is Zkr's `seed` actually implemented on the X60?

Zvknhk, stands for “standard vector extension (Zv) for cryptography (k): NIST-selected (n) hash algorithm (h) Keccak (k)”, calculates round(s) of the Keccak sponge function, introduced as the core of SHA-3. Keccak is not only used by SHA-3 but also by other post-quantum cryptography algorithms including ML-KEM, ML-DSA and SLH-DSA.

I need to set some details before a formal release, but my humble RV32I core that I designed entirely on graphical simulators (no single line of HDL written) is running the Rabinowitz-Borwein spigot algorithm. I am using that algorithm because it calculates each digit individually, and as my microcontroller only has a serial (UART) and parallel port, I can just send the digits over serial as they come up (which is what you can see on the screnshot).

The title is straightforward. I would like to ask the community what would be a realistic performance (MHz and DMIPS/MHz) expectation for an RV32IMC soft core implemented on a mature process (say, 55nm, aka Cyclone 3/4/10LP, Max 10, Gowin GW2A, etc.) LUT4-based FPGA?

I was able to find a solution that runs at 120MHz with 1.64DMIPS/MHz (gcc 15.2, -O3) on GW2A (slightly lower but comparable numbers on Altera's 55nm offerings) for under 2500 LUTs (proportionally, FF consumption is much less so only comparing LUT count), that has proper bus stall and interrupt support.

Wonder if there are better options available out there, preferably open source, under a permissive license would be better. I'd also be happy to find something commercial from a relatively lesser-known consulting company so I can afford it.

Application would be running network protocols and light DSP jobs on FreeRTOS platform. Thanks in advance!

Hi,

I've been getting more interested in RISC-V, especially Linux kernel development and QEMU.

But honestly, I'm having a hard time figuring out where to start.

I don't want to just follow tutorials or work on something that nobody actually needs. I'd like to find a real problem, understand it properly, and work toward contributing something useful.

I looked over RISE, mentor programs but not helped..

I'm not necessarily looking for an easy task or a quick first PR. I'm willing to spend time learning, even if it takes months.

Anyone could help me where to start!?

Ideally, I'd love to find a task that someone already knows needs to be done, but simply hasn't had the time to work on.

Thanks!

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/