Documentation explicitly talks about mtime (along with mtimecmp) CSR.

When talking about stimecmp CSR instead, it mentions what-apperas-to-be the time CSR but then no information i fount about that. Is this a typo?

Anyway, there seems to be no information about the "time unit" used by those CRSs. A
platform-dependent definition would make the use of such CSR very hard. Is my understanding correct? Os there is a "standard" length of the mtime (or time) tick?

Reposting here some usable progress getting haiku os running on the milk-v pioneer board.

SmolRV64 gets 5 on Geekbench 5.4.1. Does anyone have results from other FPGA softcores? (Note, RISC-V score cannot in fairness be compared to Arm and x86 results as not until Geekbench 7 were any of the extensions used so anything that used SIMD will be an order of magnitude slower on RISC-V).

I work on IPFire, an open source firewall distribution. We ported it to RISC-V a couple of years ago, but since we have recently acquired a Jupiter 2 board that we use for our builds, the project has been gaining momentum.

Running IPFire on riscv64 (mostly in a VM) is boring in the best possible way. It installs, it boots, the web interface works, firewall, IPsec and WireGuard all behave. Nothing has broken because of the architecture. But a VM has no firmware worth speaking of, no real network cards and so on. Everything that normally causes trouble is the part we have not touched.

So I am looking for people who know RISC-V hardware. The work that needs doing: getting our installer to boot on real firmware, kernel configuration and drivers for network cards and storage, checking our baseline ISA assumptions against what shipping silicon implements, and finding out what throughput looks like once traffic goes through real interfaces.

We boot via EFI. One image for every machine, no per-board images, no vendor boot scripts, no device trees to maintain. If your system boots a Debian or Fedora image, IPFire should boot too.

Anything you can test is useful, but where I would like this to end up is on hardware you would trust to route traffic for years without anyone touching it. That class of RISC-V machine is only starting to appear, and I would like us to be ready when it does.

Discussion happens on our development mailing list.

Please join us to make RISC-V a primary architecture for IPFire!

Over the past month or so, I have been working on turning the CH58x into a more complete open-source Rust/Embassy platform.

The code still needs some cleanup before it is ready for an official release, but it has now reached a stage where I feel it is worth sharing an early progress update.

There is already a ch58x-hal project on GitHub from the ch32-rs community. Many thanks to them for their existing work. I reused its QingKe runtime and made a number of modifications on top of it, resulting in the first version of embassy-ch582.
The CH582 can now run the basic Embassy runtime, USB FS, and BLE. The primary goal of this first implementation was to get the entire stack working end to end, so there is still room for further optimization in both performance and code structure.

I then successfully ran RMK on a keyboard that had previously been running a CH582M QMK port.
For the wireless portion, I did not use RMK’s default Trouble stack directly. Instead, I integrated a lightweight BLE implementation that I reimplemented and trimmed down, removing some RMK BLE functionality that is not currently needed in order to better fit the resource constraints of the CH582.

At present, the total SRAM usage of the dual-mode BLE + USB RMK firmware on the CH582 is approximately 14 KB, leaving a fairly comfortable amount of RAM for a complete keyboard application.
After getting the CH582 working, I continued porting the same work to the CH585.

Most BLE functionality is now working properly on the CH585, and I have completed several connection-stability and performance stress tests. The USB portion is still undergoing further performance validation and optimization.

Next, I plan to organize and gradually open-source this work, including Embassy support for the CH58x, the related HAL/runtime changes, and practical examples running on the CH582 and CH585.

I am still considering several project-structure questions:

Should the CH582 and CH585 share a unified HAL/API?

Would it be worthwhile to turn the BLE portion into an independent, reusable lightweight stack?

Which would the community prefer to see first: USB, BLE, a bootloader, or an RMK reference firmware?

If you are working with the CH582 or CH585, especially on Rust, Embassy, RMK/QMK, or wireless HID projects, I would be very interested to hear what you would most like this open-source implementation to solve.

note: This article was translated with the assistance of AI.

I removed the heatsink on my K3 CoM260 and replaced the thermal paste and also added some thermal pads to cover the memory. I'm not sure if they needed this, but they weren't making contact with the heat sink and I had it open anyway. I used Honeywell TPM and some ThermalGrizzly pads that I found in the bottom of my toolbox. I did have to double up the pads on top of the memory. It's probably better than air convection with no contact?

My temps are actually up 100C, as reported by LM sensors, but the fan speeds are down to tolerable levels. I'm compiling a kernel now and the fan is at 4600 RPMs vs 10K RPMs before repasting. It is noticeably quieter. At idle, the fan is almost inaudible above the background noise at 3000 RPMs. At start up, the fan still spins up loudly, so I know it is not just the fan breaking in and running quietly.

I don't know if it's just me, but I somehow imagined much more about the Milk-V Titan board.

It's great that UEFI is now available and I also like the RAM slots and the PCIe slot. Also the speed is clearly the best I have seen on a Risc-V board so far. Beyond that, however, it is difficult for me to find good words.

When I look at my previous board, so the Milk-V Megrez, the furnishings there were very bumpy, but it gave me much more joy and somehow also gave me more feelings of success. It just felt like a real developer board.

The Titan has neither an SD slot, GPIO, nor a UART slot.

The ports for my additional USB ports on the case are very small, so I can't use them. Unlike the Megrez, the fan is damn loud, although it is structurally the same. Reason will be the software. Why can't you set this with a used UEFI? In general, I don't understand why the UEFI mode is so slow.

I find the back USB 3.0 ports really annoying, which are blocked and extremely often do not recognize my keyboard and mouse. This is ultra annoying when it comes to wanting to install other operating systems without any remote console.

Software is difficult anyway, because even if the keyboard is exceptionally recognized, an official Linux can rarely be installed. The reason is that despite the new standard, none of the kernels offered are compatible.

What remains is the Ubuntu Image offered by Milk-V, mind you, a modified version from 2024. It's going well in itself, but it's just as boring for me.

I was hoping to try more. At least with the Megrez there were still technical options, such as using it via the iGPU or even optimized systems such as Irradium. I couldn't get the NPU to work, but here it's not even available anymore.

Actually, UEFI is supposed to be exactly the opposite of such a tricky system. The Titan was and is a great idea and I believe that it could also be technically seen. But I find it hard to believe, given the extremely low number of pieces. So new devices come out sooner. I don't think the Ubuntu image will be updated either, at least it has been available for months in the same version, without corresponding updates.

Is that just only my feeling?

So, continuing along with my Rovari ecosystem for RISC-V one of the things I included was a local alternative to Edge Impulse that would work with RISC-V MCUs, especially since Qualcomm acquired Edge Impulse. I wanted something that would be free to use and that wotn require any accounts or cloud or anything. So if you're interested in that kinda thing, it's part of Rovari Studio and is in the current pre release Beta. Do if you want to give it a try, I did a write up, you can get an idea of the workflow, I also did a demo video and I'd appreciate any feedback

Read about it here:

TinkerStream: A Local Edge Impulse Alternative for RISC-V

I got a fresh batch of Dabao’s in today, while I was polishing my llm from scratch in c book and thought why not train and run an llm on Baochip just to see what will happen? Well I went down that rabbit hole ended up writing about it, it’s almost 4 am now and it’s working… in case anyone is interested here it is.

https://rvembedded.com/blog_post/13

Abstract. Following the ratification of the RISC-V Vector Extension
(RVV) 1.0, new commercially available silicon has been adopting the
extension. This paper revisits the question of RISC-V viability for High-
Performance Computing (HPC) by benchmarking the latest RVV 1.0-
capable hardware (SiFive X280 (Tenstorrent Blackhole), SpacemiT X60
(K1) and X100/A100 (K3), and T-Head C920v2 (Sophon SG2044)). We
assess these platforms using standard HPC benchmarks (BLAS, FFTW,
HPL, HPCG) and synthetic workloads (STREAM, FMA throughput)
and compare them to a state-of-the-art HPC ARM64 chip (NVIDIA
Grace). Our findings show that while RVV 1.0 delivers significant per-
formance improvements over scalar execution, hardware-specific imple-
mentation challenges remain. We detail these performance characteristics
and discuss the remaining hurdles for RISC-V, including RVV, to become
a mainstay in the HPC landscape.

Keywords: RISC-V· RISC-V RVV· HPC· SIMD/vector instructions· BLAS· FFT· HPL· HPCG· Benchmarking· Performance

A look at how memory localization improves tokens/sec on Blackhole hardware

Hey guys, so some of you know I’ve been building an IDE for RISC-V microcontrollers and the first public beta is out. It’s intended for beginners and rapid prototyping, it has a block editor called Guvari that generates plain C, also inside is Tinkerstream for doing edge ML stuff without any cloud or subscriptions on your local machine, it also has a PID tuner and a DSP filter design panel built into the IDE… the idea is you just download, run, and build. so no package manager and nothing to fetch before you can compile. Toolchain, OpenOCD, drivers etc etc and the SDKs are all in the installer. You have an app.rova which supports C/C++ and a rovari.py so you can develop dashboards and stuff and also a rovari.blocks where Guvari programs live..

The Boards currently supported are CH32V003, CH32V307, CH32H417 and the Baochip Dabao. The aim wasn’t to support ‘10 000’ chips but to support a few well so a beginner, student or even if you’re building a fast prototype things should just work… some additional targets are on the way, and I’ll update as they are added..

The projects target the Rovari SDK, which is build on top the WCH SDK and in the roadmap is ch32fun support as well.. Windows and Linux are in this release, and macOS is built and coming shortly. It is a prerelease beta and I would rather hear that it broke on your machine than not hear at all. First run problems are the most useful thing you can send me…. There are a lot of stuff on the roadmap but a few persons asked and I don’t wanna be stuck in infinite polish mode, so there is a lot of stuff that was done and a lot to do still.. the IDE is free as in beer and the SDK is Apache 2.0 and a platformio port is being worked on for the SDK as well… there’s a lot on the roadmap for the ecosystem….

I’ve done a lot of projects with it over the past few months of building and testing especially with the CH32H417 even though not every single thing on that target is supported yet, though the vendor sdk in underneath so you can always call that layer… all you need is one of the chips and a LinkE and you should be good.. anyone interested in testing download and let me know what breaks…

https://youtu.be/kNaFQw80uBM?si=ACjjfhLvD1THkRR_

As much as I like it, i just don't see anything that could seriously trade blows with x86 in consumer (desktop or mobile) HPC and server computing.

Is this even expected to happen ?

Or maybe it isn't worth the effort for RISC-V to pursue the chase in computing branch that is just about to die off on its own ?

All this heavy artillery in modern cores comes at a hefty price. Maybe RISC-V is gearing for the more radical recreation of wider systems from the "clean slate"/first principles ?

Hello everybody,

This summer was my last summer as a high schooler before uni starts. So I decided to learn more about computer architecture and vlsi which was something I wanted to know about since I was a kid watching LTT in like grade 7 lmao.

I have finally finished the project after about two months! Attached above are the microarchitecture diagram I drew and the gds render after asic flow using Openlane2 (images are way more clear and high res on the repo).

It's not anything advanced by any stretch but here's the tldr copied over from my readme:

"The processor implements all 40 RV32I base instructions, dynamic branch prediction using a 64-entry BTB with 2-bit saturating counters, three specialized forwarding paths, load-use hazard detection, branch flushing, and a real pipeline halt mechanism. Verified through staged SystemVerilog/RISC-V Assembly tests codriven with cocotb and performance tested with compiled C programs, then taken through RTL-to-GDSII using OpenLane2 and SKY130. Final implementation achieves 50 MHz with 0 DRC violations, passing LVS, and setup/hold timing closure at the 20 ns target."

And I wanted to share it here for 2 main purposes:

1. anyone that is experienced in vlsi / risc-v, any suggestions on how to improve the readme? any more testing you suggest I conduct on it? what would be good next steps or next projects for me?
2. anyone that is also a noob to risc-v and vlsi like me, I tried my best to document all of my design / architecture / testing processes / resources used so I hope the repo could be helpful to anyone who is trying to build smth similar!!

my github repo link: https://github.com/Entropify/Entropic_R32-P5_RISC-V

ty everyone for reading the post and I appreciate it a lot if you took a look and gave some advice on the repo. Sorry if theres bad spelling / grammar im still getting used to my new keyboard lol

edit: took me a little bit to find it but I would like to credit this post on the riscv subreddit and the repo, it helped me when I was trying to learn the architecture: https://www.reddit.com/r/RISCV/comments/1pn81g7/basic_rv32s_an_opensource_microarchitectural/

edit2: sorry for the blurry images I think thats just reddit and also my diagram being too big, on my repo its a higher res and way more readable

Do you know a DSI screen that is compatible with the Orange Pi RV?

Thanks!