Orange Pi RV2 is a single-board PC with an 8-core RISC-V processor | Hacker News Reader

Orange Pi RV2 is a single-board PC with an 8-core RISC-V processor

liliputing.com

98 pointsndsipa_pomu44 comments

https://www.cnx-software.com/2025/03/08/orange-pi-rv2-low-co... has more info

SoC – Ky X1

    CPU – 8-core 64-bit RISC-V processor
    GPU – Not mentioned
    VPU – Not mentioned
    AI Accelerator – 2 TOPS

The most annoying thing here is the complete lack of information on caches.

If it's the same as K1/M1 then ok, 512 MB L2 per 4 core cluster is simply inadequate for a normal Linux workstation workload.

I don't know where they (or SpacemiT) get the "30% faster than A55" claim because I certainly haven't seen any such thing. On some micro benchmarks such as my own primes one the K1 comes in at slightly more clock cycles than the U74 in JH7110, but pulls slightly ahead on high clock speed. Both are right around A55 performance, and 30% faster than A53.

On real-world tasks such as building software (e.g. Linux kernel, gcc) all 8 cores on a K1 working together come in slightly slower than the 4 cores on the JH7110 -- not much in it, call it the same. If you use `-j4` then it's miles slower.

I'm pretty sure that's down to the smaller caches. Or possibly TLB misses. U74 has 40-entry L1 Data and Instruction TLBs, and a direct-mapped 512-entry L2 TLB -- bigger than A53, smaller than A55. I haven't seen any information on the X60 core's TLB structure.

Will this run off the mainline kernel? Or will require strange patches from somewhere?

Half the problem with orange pi is lack of main Linux distribution support.

All my (ARM) Orange Pi boards run Armbian just fine. This one, of course, is unlikely to, but I'm curious to see what it ships with.

I know Armbian for the Orange Pi 4 had broken video out for at least a year: https://forum.armbian.com/topic/26818-opi-4-lts-no-hdmi-outp...

Haven't tried it on mine recently so no clue if it's better now.

Depends on whether things are officially supported or just community contributes, in my experience. I tend to stick to officially supported devices.

Armbian adds all sorts of non-mainline Linux kernels and other stuff in order to achieve the hardware support it does have. Other more standard distros like Debian or Fedora don't do this.

Well, do you want things to work or are you willing to wait years until things are mainlined?

That's the thing, it forces me into a specific distro/kernel where the stuff that I actually want to run isn't available.

I have a pair of Orange Pi 5Bs and they didn't really replaced my old Raspberries after spending more time on it than what I was initially willing to spend on my upgrade.

My definition of "work" is a Linux kernel that can be upgraded as CVEs are discovered and new features added. Modified versions of Linux usually aren't that, much of the time they are stuck on the same kernel version, which eventually leaves security support periods.

> Well, do you want things to work or are you willing to wait years until things are mainlined?

What I want is for the SoC vendors to actually learn how to participate in the kernel process. Design their drivers from the ground up to be maintainable and mainlineable.

The problem with "wanting things to work now" that we've seen over and over and over in the ARM SoC world is that each family of chips ends up with its own fork of the kernel which never gets mainlined because of one or more of the following:

* It can't actually be compiled as provided

* Successful compilation depends heavily on the build environment which is undocumented

* It depends on binary drivers

* It is written in ways that do not meet the standards of the kernel

* It modifies kernel interfaces in ways that break other drivers

* It's just bad code in general.

When this happens the vendor might update it a couple of times over the product's profitable life but inevitably they will stop doing so. If there's enough of a community around the platform and they're lucky enough to have complete source it's sometimes possible for the community to take over development of the fork and try to port the vendor code to newer kernels while slowly cleaning it up. Most of the time though there's a binary driver somewhere critical to many if not all users which will only work with a certain range of kernel versions, at which point the community is left supporting an obsolete kernel and mostly just backporting relevant fixes rather than gaining anything new. Sometimes there's a way to shim an old driver to work with a new kernel, and sometimes a driver for a newer piece of hardware from the same vendor can be made to work on the older versions, but in neither case can it be counted on.

The worst part IMO is that it's usually not even a LTS kernel that these vendors decide to settle on, it's all too often one that was obsolete and unsupported before the SoC was ever in the public's hands. If you're going to launch a Linux-based product with no intent of mainlining the kernel code at least make it run either the latest LTS or SLTS kernel.

It doesn't take years to get code mainlined, lots of vendors are doing it every day for hardware that hasn't even been released yet. A lot of SoC vendors either just don't care or actively don't want to.

I have a similar issue with the MangoPi MQ Pro. Its great to have a RISC-V processor now but not having HDMI available on my SBC kinda massively sucks.

Based on the listings on taobao (1), it appears to be a Ky X1

1. 【淘宝】https://e.tb.cn/h.Tx3SapHVd5dL2Td?tk=zhC2eNxK64H CZ028 「香橙派Orange Pi开发板RV2八核RISC-V架构双网口WiFi蓝牙双M2接口」点击链接直接打开或者淘宝搜索直接打开

As per the article: "The biggest difference between the two boars is that the Orange Pi RV has a 1.5 GHz StarFive JH7110 quad-core processor, while the new Orange Pi RV2 has a an octa-core Ky X1 chip with a 2 TOPS AI accelerator."

I can not find infos about the Vector-extensions ? Is this cpu/board suitable to test the RISC-V Vector extensions ?

thx for any insights..

Yeah, they somehow released a SBC without telling us what processor it contains.

It seems to be the same one as the BananaPi BPI-F3, see: https://www.reddit.com/r/RISCV/comments/1j6c6xz/orange_pi_rv...

The link you posted goes to the exact same board as in the article.

It's not about the article, but the comment from u/12101111:

> It's a cheaper Spacemit K1.

> The CPU spec from dtb:

> compatible = "ky,x60", "riscv"; model = "Ky(R) X60"; riscv,isa = "rv64imafdcv"; riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom", "zicboz", "zicntr", "zicond", "zicsr", "zifencei", "zihintpause", "zihpm", "zfh", "zfhmin", "zba", "zbb", "zbc", "zbs", "zkt", "zvfh", "zvfhmin", "zvkt", "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";

> It also have a ARM China Linlon v5 VPU and Imagination IMG GPU. The PMIC and UART is same as K1.

> And the ubuntu image from orangepi just use the same BSP kernel/uboot/opensbi from Spacemit's linux-bianbu.

From memory, the SpacemiT K1 doesn't support extensions like Zvkt?

EDIT: okay, looks like the official documentation lists it, but many places I looked didn't. Maybe it wasn't being detected in cpuinfo?

https://docs.banana-pi.org/en/BPI-F3/SpacemiT_K1

It seems likely to be the same as this chip, so yes. https://docs.banana-pi.org/en/BPI-F3/SpacemiT_K1

It has a JH7110 onboard. From what I can tell, all of the vector processing is in dedicated hardware subsystems, not individual vector instructions.

We're still very early in the RISC V ecosystem, so most of the processors in production pre-date current standardizations, which requires applications to target specific silicon. To add insult to injury, those individual processors are relatively new, so the dedicated image processing and vector/tensor hardware doesn't have much support yet.

This is not JH7110 based.

I have one.

Yes, I'm currently using it to successfully test vector instructions. A blog post is being written, but may take a week or so.

Keep an eye on blog.habets.se, or ping me here on HN in about a week.

Seems I can't add another reply, nor edit the one I created. But [here's more info about the Orange Pi RV2 and RVV](https://blog.habets.se/2025/03/Exploring-RISC-V-vector-instr...).

I have my hands on one, if anyone has questions.

Hmm. As a fairly non-experienced person with a strong interest in experimenting with RISC-V, I read the comments here, and the article, and still feel, maybe this isn't the thing to get me started. Maybe the ecosystem still isn't there for a beginner to jump in.

Is there such a thing as a (cheap) SBC that runs RISC-V, which has good documentation (books, forums, whatever) on getting started programming on it? I'd like to get into assembly more, and hardware, and I'm interested in RISC-V for its open nature, but it can feel overwhelming getting the foot in the door.

Or is this it, and I'm just being overwhelmed by all the talk? Where would I go to get clear documentation on programming and experimenting with an Orange Pi RV2, if I went that route?

You don't need new hardware for that, you can just use qemu.

> You don't need new hardware for that, you can just use qemu

And what will Qemu emulate ? A nonexisting processor ? /s

Yes? How is that a problem? If you're interested in learning the RISC-V ISA, which is what I gathered from OP's post, the specific CPU doesn't matter much.

I am moreso looking for an actual board, maybe a few flashy lights, ya know, all that. I've played with QEMU a bit for a few little things, it's fun enough, but I'd like to play with some RISC-V hardware - again, if possible, if there were something appropriate for a relative beginner to get going.

This hardware is very interesting (RISC-V).

Is the hardware open and simple enough I can reasonably run a custom assembly written mini-kernel?

The StarFive JH7110 should be fine for that, but there's some lower-power hardware that's even better for your use case.

The Bouffalo Labs BL808 and Sophgo SG2000 series are both asymmetric multiprocessor SoCs that allow you to run a full OS, such as Linux, on one core, and run bare metal on the other. Unlike symmetric multiprocessing, you aren't just running a premptable thread on a spare core, but you get full control of the core, with direct GPIO access and a mailbox for messaging the OS core.

You can set up a development environment in Linux, on the faster core, and compile and run your application on the smaller core, for really fast development and debugging.

Check out the Ox64 and Oz64 boards from Pine64 or the Duo series from Milk-V, for cheap breakout boards using those processors.

If I remember well I did dodge the BL808 as it seems to be very difficult to have a clean RISC-V 64bits kernel to run since the real core is a RISC-V 32bit MCU. It seems to be the same thing with the SG2000.

I may go first with some code extraction and customization from linux, before probably ending with a lot of "hand compiled" linux code.

And yes, lower-power for the moment, since I would first use that for self-hosting.

The BL808 does use a 32-bit core for the secondary core, but the SG2000 series uses the same 64-bit C906 core for both RISC-V cores. The only difference is the reduced clock speed and a lack of vector extensions.

Here's an English datasheet for the SG2000 series: https://github.com/sophgo/sophgo-doc/releases/download/sg200...

…and for the C906 core itself: https://occ-intl-prod.oss-ap-southeast-1.aliyuncs.com/resour...

Indeed, it seems there is something about the SG2000, maybe I should have a look at the various boards with it. I don't really mind about the vector extensions right now as I do code RISC-V core only assembly (not even compressed) with near 0 pre-processing (as it should be for all system software, and yes that includes the kernel).

EDIT ---

It seems the SG200X includes an ARM block and this is a definitive nono for me. I want to buy a SOC free from ARM royalties. I tolerate HDMI/mpeg royalties though.

The CV1800B on the original 64 MB Milk-V Duo does not have an Arm core. It is otherwise very similar to the 256 MB and 512 MB SG2000 chips (Sophgo bought CVITECH, so the CV -> SG is just a rename)

Well, we can all expect sophgo will refrain putting ARM cores in their SOC in the future :( (... and I would not mind displayport instead of hdmi and av1/opus codec block instead of a mpeg one neither... 0 royalties...)

All MP3, MP4, and H.264 patents have expired, so you don't have to worry there. I don't get why more hardware doesn't adopt DisplayPort, though. At least HDMI ports accept DVI signals, and DVI is also in the public domain.

I mostly agree with you, but nowadays codec blocks are mostly h.265 and ac3 :( They are smart as they will just do a little bit more things in a new codec and renew their patents. The thing is displayport, yep, something is off here, hardware ppl don't need a expensive hdmi connector, just another USB-C... I wonder if the HDMI people are not doing things in the shadow to end up favored...

That said, I have to point the fact, those patents are only valid in some countries, namely subject to royalties (USA, UK, Japan... but not EU for instance).

I don't know why raspberry is not selling some of their SOCs with the ARM blocks hard disabled at sell time, namely they did not pay for the ARM royalties.

In the end, it is near impossible to buy all those RISC-V boards in my country with a noscript/basic (x)html browser, and if possible with wallet codes (or bank swift) instead of a credit card.

I was excited about Orange Pi ARM but they made an idiotic boot loader that always uses the SD when any SD is present. I think that's unacceptable for an "embedded" thing. This board also has a USB port where plugging in something it doesn't like takes down that entire bus until a reboot.

It's cool to see RISC-V, but I'd go with a different company.

Why is that unacceptable?

If I have an SD card for extra storage and tuck it away somewhere, any interruption in power would mean it needs to be manually reset. I actually wanted something with SD storage that I could turn on and off remotely.

I think the SD card is thought of as the worst tier of storage, so if you're not wanting to boot from the SD card, then the idea is to use something like a USB disk etc. Presumably, it causes more problems (bricked devices) if they don't always boot from the SD card preferentially.

One solution would be to always boot from the SD card and either have it partitioned to provide the SD storage that you want, or use the eMMC etc to provide the storage.

Reply on news.ycombinator.com