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

47 comments

·March 9, 2025

homarp

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

brucehoult

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.

null

[deleted]

UK-AL

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.

dhalucario

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.

rcarmo

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.

pabs3

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.

rcarmo

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

ThatPlayer

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.

rcarmo

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

sberder

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接口」点击链接直接打开或者淘宝搜索直接打开

ralferoo

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."

Bosinski

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..

thomashabets2

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.

thomashabets2

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...).

dlcarrier

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.

kcb

This is not JH7110 based.

camel-cdr

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...

ralferoo

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

camel-cdr

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.

kcb

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

kcb

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

thomashabets2

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

-__---____-ZXyw

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?

Narishma

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

hulitu

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

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

Narishma

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.

sylware

This hardware is very interesting (RISC-V).

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

dlcarrier

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.

sylware

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.

dlcarrier

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...

plagiarist

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.

amelius

Why is that unacceptable?

plagiarist

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.

ndsipa_pomu

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.

oiuqoiro

[dead]

iwriawei

[dead]