RISC-V

RISC-V is an industry standard, like USB or Wi-Fi. The specifications are publicly available under the Creative Commons license and every engineer, wherever they are in the world, can use them to design their products locally, while engaging with the global RISC-V ecosystem.

This standard is defined by RISC-V International and its members. Decisions are voted upon collectively, ensuring every member is heard. It’s a model that has worked for us for many years, ensuring any updates to the RISC-V ISA happen transparently, without breaking existing designs, and always in service of the broader ecosystem.

The RISC-V ISA is already an industry standard and the next step is impartial recognition from a trusted international organization.

Today, I’m excited to announce that we have taken that first step. RISC-V International has been approved as a recognized PAS (that’s publicly available specification) Submitter by the ISO/IEC Joint Technical Committee (JTC 1).

This means we’re able to submit draft international papers, starting with the The RISC-V Instruction Set Manual, for consideration as true, international standards.

One of the more unexpected talks at last week's Ubuntu Summit 25.10 in London was by Antonio Salvemini of Bolt Graphics, who introduced the company's forthcoming range of Zeus graphics accelerator hardware. These are very unlike any conventional GPUs – or indeed anything else.

[…]

Bolt's Zeus hardware will use an entirely different model, and we found it refreshing that the company's How it works page doesn't mention the dreaded initialism "AI" once. These accelerators are aimed at producing graphics using a specific rendering method called path tracing.

[…] Path tracing is a step further on from simple ray tracing. A few decades ago, ray tracing was a favorite way to demonstrate high-resolution, multi-color computer graphics, taking hours to days to render scenes of shiny spheres.

As Salvemini put it: "The problem with ray tracing is that each light wave only bounces one way. In path tracing, they can bounce anywhere, and you randomly select just some of these paths to display." Thus, Monte Carlo path tracing (MCPT) – as described in this 2024 UCSD computer graphics lecture [PDF] – uses Monte Carlo simulation, as invented by John von Neumann and Stanislaw Ulam during World War II.

Inspired by Easy 6502 by Nick Morgan, this is a quick-ish introductory tutorial to RISC-V assembly programming. This tutorial is intended for those with a basic familiarity with low level computer science concepts, but unfamiliar with RISC-V. If you’re curious about RISC-V, I hope this will be a good start to your journey to learning about it.

In the last article, we covered bare metal programming on RISC-V. Please familiarize yourself with that material before proceeding with the rest of this article, as this article is a direct continuation of the aforementioned one.

This time we are talking about RISC-V SBI (Supervisor Binary Interface), with OpenSBI as the example. We’ll look at how SBI can assist us with implementing operating system kernel primitives and we’ll end the article with a practical example using riscv64 virt machine.

Merged for Mesa 25.3 is adding the necessary device information bits for more supported and unsupported GPU cores. This includes some additional PowerVR Series 6XE, 6XT, 8XE, and B-Series GPUs. This complements the PVR driver currently being focused on the A-Series AXE-1-16M and the B-Series BXS-4-64 / BXM-4-64 GPU IP.

The newly-added documentation for the open-source PVR driver explains:

The following hardware is unsupported and not under active development:

========= =========== ==============

Product Series B.V.N.C

========= =========== ==============

GX6250 Series 6XT 4.45.2.58

GX6650 Series 6XT 4.46.6.62

G6110 Series 6XE 5.9.1.46

GE8300 Series 8XE 22.68.54.30

GE8300 Series 8XE 22.102.54.38

BXE-2-32 B-Series 36.29.52.182

BXE-4-32 B-Series 36.50.54.182

========= =========== ==============

Device info and firmware_ have been made available for these devices, typically due to community requests or interest, but no support is guaranteed beyond this.

The MIPS I8500 features a scalable multithreaded architecture with 4 threads per core and support for multi-cluster deployments, enabling up to 24 threads per cluster. It delivers ultra-low-latency, deterministic data movement with integrated security, ideal for orchestrating packet flows across accelerators and enabling intelligent communication between compute blocks, humans, and networks. Its energy-efficient design ensures optimal performance for edge AI workloads, while RVA23 profile readiness and support for Linux and Real-Time operating systems ensures software portability and ecosystem alignment.

Condor Computing, a subsidiary of Andes Technology that creates licensable RISC-V cores, has a business model with parallels to Arm (the company) and SiFive. Andes formed Condor in 2023, so Condor is a relatively young player on the RISC-V scene. However, Andes does have RISC-V design experience prior to Condor’s formation with a few RISC-V cores under their belt from years past.

Condor is presenting their Cuzco core at Hot Chips 2025. This core is a heavyweight within the RISC-V scene, with wide out-of-order execution and a modern branch predictor and some new time based tricks. It’s in the same segment as high performance RISC-V designs like SiFive’s P870 and Veyron’s V1. Like those cores, Cuzco should stand head and shoulders above currently in-silicon RISC-V cores like Alibaba T-HEAD’s C910 and SiFive’s P550.

Besides being a wide out-of-order design, Cuzco uses mostly static scheduling in the backend to save power and reduce complexity. Condor calls this a “time-based” scheduling scheme. I’ll cover more on this later, but it’s important to note that this is purely an implementation detail. It doesn’t require ISA modifications or special treatment from the compiler for optimal performance.

This release for the first time officially supports the riscv64 architecture, allowing users to run Debian on 64-bit RISC-V hardware and benefit from all Debian 13 features.

The Wiki provides more details about riscv64 support in Debian.

Downloads:

• debian-13.0.0-riscv64-DVD-1.iso (torrent)
• debian-13.0.0-riscv64-netinst.iso (torrent)

As you may have heard, Ubuntu 25.10 will only run on RISC-V devices with RVA23 profile extensions, a change made to allow the distro to take full advantage of newer hardware capabilities without backwards-looking compromise.

But if you’re worried that Ubuntu’s pivot to the RISC-V RVA23 profile would leave you without hardware to run it on (since, right now, no RVA23 devices are available) you can relax a little as a slate of RVA23-compatible chips are due to launch in 2026 – and some this year.

Given the lack of hardware on sale right now, some have questioned the move by Canonical. Yet, it didn’t happen in a vacuum. Its engineers have access to development hardware and close partnerships with silicon vendors. Not on sale doesn’t mean they don’t exist.

cross-posted from: https://midwest.social/post/31797333

I came across the post about Milk-V Titan, and there was a comment asking about the lack of the V extension would hinder running Ubuntu 25.10 which was targetting a particular RISC-V configuration, and it made me wonder if there were an opportunity for micro kernels to exploit.

Now, up-front: it's been literally decades since I had an OS design class, and my knowledge of OS design is superficial; and while I've always been interested in RISC architectures, the depth of my knowledge of that also dates back to the 90's. In particular (my knowledge of) RISC-V's extension design approach is really, really shallow. It's all at a lower level than I've concerned myself with for years and years. So I'm hoping for an ELI-16 conversation.

What I was thinking was that a challenge of RISC-V's design is that operating systems can't rely on extensions being available, which (in my mind) means either a lot of really specific kernel builds -- like, potentially an exponential number -- or a similar number of code paths in the kernel code, making for more complicated and consequently more buggy kernels (per the McConnell rule). It made me wonder if this is not, then, an opportunity for micro kernels to shine, by exploiting an ability to load extension-specific modules based on a given CPU capability set.

As I see it, the practicality of this depends on whether the extensions would be isolatable to kernel modules, or whether (like the FP extension) it'd just be so intrinsic that even the core kernel would need to vary. Even so, wouldn't having a permutation of core kernel builds be smaller, more manageable, and less bug-prone than permutations of monolithic kernels?

Given the number of different possible RISC-V combinations, would a micro kernel design not have an intrinsic advantage over monolithic kernels, and be able to exploit the more modular nature of their design?

8 High-Performance RISC-V Cores UR-CP100 (up to 2.0GHz)

• 1 Cluster (4x UR-CP100 cores) sharing 4MB, total 8MB
• System-level cache: 16MB shared by 2 cluster (8 cores)

The Most Powerful RISC-V Core in Mass Production to Date - UR-CP100 (RV64GCBHX)

• 64-bit out-of-order 4-issue superscalar microarchitecture
• SPECCPU2006 single-core INT@10.4/GHz
• SPECCPU2006 single-core FP@12/GHz
• UltraRISC proprietary high-performance "X" instruction set extension

Compliant with RISC-V International Foundation Standards

• Fully Compliant with RVA22
• Compliant with RVA23* (excluding "V" extension)

Supports DDR4 Memory Stick, Up to 64GB

• Compatible with standard PC-grade memory stick (UDIMM)
• Supports standard DDR4 JEDEC JESD79-4A protocol
• Supports maximum speed of 3200MT/s
• Supports ECC

Supports UEFI Boot

• Supports ACPI, CPPC, SMBIOS
• Standardized boot support
• Native ISO file mounting
• More flexible boot options
• Enhanced security

Supports Commodity NVMe SSDs (PCIe Gen4 4-lane)

Supports High-Speed USB3 5Gbps

Onboard Full-Size PCIe Connector with PCIe Gen4 16-lane