The OrangePi R2S adopts an open chip micro Ky X1 8-core RISC-V AI processor, providing universal computing power with 2TOPS CPU fusion. It has 2GB/4GB/8GB LPDDR4X operating memory and supports 8GB eMMC, It exquisite and compact, with a size of only 79.2 * 46 * 1.6 mm, making it easy to install in various small spaces. OrangePi R2S supports OpenWrt and Ubuntu.
I've got an RV2 and it works ok to play with as a toy, but could you upstream your OpenWrt support? I'm not going to use any device on my network that only has a hacked up, proprietary version of OpenWrt, it needs to be fully supported.
Haha, both the hardware(ISA) and code all open source, and you can audit and modify the code that suits your own security level. RISC-V is actually a more secure device.
I understand all that, but I'm not going to set up a separate system outside OpenWrt just to support one device. Why don't you just integrate your dts files and other bits into the already-existing RISC-V targets in upstream OpenWrt and allow use of the rich toolset?
$ ssh opi-rv2
BusyBox v1.36.1 (2025-02-03 23:09:37 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 24.10.0, r28427-6df0e3d02a
-----------------------------------------------------
2025-06-10T08:04:02 PDT 1600 MHz 1600 MHz 1600 MHz 1600 MHz 1600 MHz 1600 MHz 1600 MHz 1600 MHz 45.0 C 44.0 C
$ owut download
owut - OpenWrt Upgrade Tool 2025.04.08~ef2bfb4d-r1 (/usr/bin/owut)
ERROR: Response status 404 while downloading
https://downloads.openwrt.org/releases/24.10.1/targets/ky/riscv64/profiles.json
ERROR: Unsupported target 'ky/riscv64'
The pull request (PR) cycle of upstream OpenWrt is too long, taking at least six months or even longer to merge into the mainline. This is not to say that manufacturers are unwilling to integrate their code into upstream OpenWrt, but rather to accelerate device releases, they place their code in their own forked upstream repositories to facilitate faster code adaptation and provide customers with out of the box firmware. If everyone is willing to work together to improve, optimize, and port the manufacturer's example code upstream in the future, the manufacturer's version can ultimately complete the task and exit.
AI is supported by processors and has future scalability, such as being suitable for applications such as AI image recognition processing. Of course, if it is used as a router, there is basically no need for an AI processing unit. In the future, it may be possible to use AI computing power processing units to assist in accelerating the processing of network packets, which is a cutting-edge idea. It is uncertain whether there are professional researchers studying it.
This is exactly what I'm talking about! I have seen several routers marketed with "AI" in their names (Dlink AFAIR) and asked myself 'Did I miss something important?'.
Haha, it is true that software has not yet caught up with the pace of hardware development at this stage. The marketing component of AI is indeed larger, which creates innovative imagination space for us. You can use your intelligence to make AI units work, such as quickly processing the analysis of certain network packets.
Let's just say they don't know how to sell it yet.
DPI is the hardest thing I can come up with, but it can be implemented perfectly well on modern hardware. In fact most applications I'm aware of use FPGA for that for many years.
We will also modify the Linux kernel and adapt to DTS, which are simple things that can be done. FPGA belongs to the skills of professional electronic engineers, and professionalism is too difficult for most ordinary geeks to modify Verilog HDL code for testing and fine-tuning.
There are still many problems with the code automatically written by AI now. In the future, AI may be able to replace anyone, including plumbers, without the need to understand computer science, to write professional programmer quality code for them. haha
the kernels in the SDK provided by the SoC or board manufacturer don't necessarily match up with what we have in OpenWrt - many SDKs are still built on 5.10 or even earlier kernels which is a no-go for trunk.
board manufacturers are free to do what they want in their trees, while getting a board or SoC supported in OpenWrt is a) more strict, b) the additional packages need to build for other targets as well, c) there is not much appetite in a GPU accelerator or a murky camera driver in mainline OpenWrt, as this is a router platform. Dumping (trying to dump) a DTS from an SDK into trunk and pulling in an SDK source in full won't work for mainline.
board manufacturers time after time say "XYZ board/router supports OpenWrt", which causes users to turn to us for support, while supporting a board that has an ancient kernel running ancient OpenWrt (not the case for the R2S of course) is out of our remits.
also, just lightly touching on the fact that most of the OpenWrt developers are not paid for their community efforts - which in turn means a longer timeframe (if there is interest at all) for getting hardware support upstream.
As always, we're happy to help and/or guide vendors to integrate their stuff into mainline, but that's a longer process and it's too late to start "when the device is released to the public".
