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.

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

Has anybody put ECC UDIMMs in a Milk-v Titan?

If so, which ones?

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