FriendlyELEC NanoPi R3S is a low-cost Rockchip RK3566 SBC and router with two gigabit Ethernet ports, a USB 3.0 host ports, a USB-C port for power and data, a microSD card slot, Reset and Mask buttons, and a few LEDs. It also features a MIPI DSI connector for people wanting to connect a display.
Its design and size are similar to the NanoPi R5C dual 2.5GbE SBC and router, so it could be viewed as a low-cost alternative with dual GbE, no M.2 socket for WiFi & Bluetooth, only one USB 3.0 port, and no HDMI video output. The company promotes it as an inexpensive platform for IoT applications, basic NAS solutions, and so on.
NanoPi R3S specifications:
- SoC – Rockchip RK3566
- CPU – Quad-core Cortex-A55 processor @ up to 2.0 GHz
- GPU – Arm Mali-G52 MP2 GPU
- NPU – 0.8 TOPS AI accelerator
- VPU
- 4Kp60 H.265/H.264/VP9 video decoder
- 1080p60 H.264/H.265 video encoder
- System Memory – 2GB LPDDR4X
- Storage
- Optional 32GB eMMC flash
- MicroSD card socket
- Display Interface – 30-pin MIPI DSI FPC connector (CNXSoft: I could not find documentation about it nor a display known to work)
- Networking – 2x gigabit Ethernet RJ45 ports
- WAN via Realtek RTL8111H PCIe to GbE controller tested up to 934 Mbps (Tx) and 936 Mbps (Rx)
- LAN via Realtek RTL8211E tested up to 934 Mbps (Tx) and 941 Mbps (Rx)
- USB
- 1x USB 3.2 Gen 1 Type-A port
- 1x USB-C port for power and data (e.g. to flash firmware)
- Debugging – 3-pin UART header (1.5 Mbps baudrate)
- Misc
- Mask key for eMMC flash update
- User button
- 2-pin connector for RTC
- 3x user LEDs for SYS, LAN, WAN
- Power Supply – 5V via USB Type-C port
- Dimensions – PCB: 57 x 57 mm; enclosure: 61.5 x 61.5 x 25 mm
- Weight – 30 grams without the case, 144 grams with the metal enclosure
- Temperature Range – 0 to 80°C
FriendlyELEC provides Ubuntu Noble 24.04 Core, Debian 12 Core, OpenMediaVault 6.1, and FriendlyWrt (fork of OpenWrt 21.02 or 23.05) images for the board, all based on Linux 6.1.x and u-boot
v2017.09. They can be flashed to the eMMC flash via a microSD card or a USB-C cable through the eFlasher utility or booted directly from the microSD card. You’ll find documentation and OS images on the wiki.
I compared the NanoPi R5C in the introduced since both are based on Rockchip RK3566/RK3568 processor, but it’s more like an update to the Rockchip RK3328-based NanoPi R2S dual GbE IoT board and gateway with better performance and extra features like a USB 3.0 Type-A port and MIPI DSI. FriendlyELEC shows the R3S runs much cooler than the R2S when used in the same/similar metal enclosure.
The NanoPi R3S board can be purchased for as low as $30 without eMMC flash (or $35 with 32GB flash), and the metal case adds $5, so a complete kit with 32GB eMMC flash and a metal case sells for $40 plus shipping.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
How does it compare to RPI 5 2gb ram version?
It’s 60% of the price. It’s smaller. It completely lacks any GPIO.
I meant with regards of compute power.
It’s four A55’s vs four A72’s, it’s not going to go in the A55’s favor. Unless It’s AI in which this board will likely win. Or video compression that uses this boards encoder–which the Pi 5 completely lacks. Also, the Pi 5 only decodes H.265, so H.264 and VP9 decoding (youtube) will work better on this board.
That’s all assuming that FriendElec actually got the video codec support right–which I realize is a big ask from them considering their history.
A76, not A72.
Thank you. The A55 is even more boned.
Any chance to use this as an edge firewall? (after being affected by unifi edgerouter vulnerability, I’m looking to put something between my router and the ONT)
I wanted to use its bigger brother R5C for this (dual-2.5G) because it’s the perfect choice of components and form factor, but it lacks the console port, and I’m really fed up with machines dying upon kernel updates and having to use a screwdriver to connect wires inside and access the boot loader. Unfortunately they did the same stupidity on this one again. I really think they don’t understand why a boot loader access is absolutely mandatory on an edge device. Otherwise you can’t safely update it, and you’re torn between letting it run outdated code or risking to lose it for several hours. Some will say that when you use the SD version (no eMMC), you can pull off the SD and try to fix it from another machine. But quite frankly I’m really really fed up with spending my nights and week-ends fixing stuff that should normally just require connecting a cable to select the alternate boot choice, press enter and be done.
I asked them again a few days ago if/when they plan to finally make the console accessible on such devices, otherwise I’ll go with Radxa which has understood this a while ago now.
New kernel it is usually coming with new u-boot. When you fixing it in chroot environment you risking damaging u-boot on host device so you can endup with 2 bricked devices instead 1.
It has happened to me few times with Armbian system.
Why do they keep releasing network focused boards with general purpose ARM SoCs?
Makes no sense. A router doesn’t need a VPU but it would benefit from a packet accelerator.
Exactly that. General purpose ARM SoC + two Realtek chips doesn’t make this board a router. It’s still an ARM SBC with dual gigabit Ethernet.
I disagree. The RK3568 offers a very good balance between power draw and I/O performance, and it is a general purpose SoC. Here it’s an RK3566 which is slightly smaller and lacks a bit of I/O. But these chips are quite good to make routers and firewalls. And as a bonus they’ve been very well supported in mainline for a while now.
They’re terrible as router/firewalls. No buffers/queing (besides what you implement in software), no PPPoE/NAT/etc offloading so will perform terribly at any real world rates. Just use a network focused ARM SoC (of which there are many – e.g Marvell Armada)
At gigabit speeds, software implementation running on this kind of hardware should be more than enough to keep up (unless you define bajillion rules (which would probably be a problem even for the SoC with HW offload)). Also, from my experience with some openwrt devices, drivers for the HW network offloading are usually out-of-tree/proprietary or pita to get working correctly (but I didn’t check recently, so the situation might have changed).
Yeah clearly. My Odroid-M1 based on RK3568 is twiddling thumbs saturating the GigE link using rsync from the SATA SSD. And it’s using the poor internal GMAC, not even a PCIe NIC. I was already forwarding at GigE speed 10 years ago with the Mirabox running off a 32-bit single-core armada-370 at 1 GHz with 32-bit RAM. It would be dramatic if any entry-level chip in 2024 couldn’t deal with GigE once connected to a correct NIC!
Finally, my tests on the RK3588 showed it can forward 20 Gbps of traffic. This device is not 20 times more powerful than an RK3568, having “only” twice the number of cores among which 4 much more powerful ones, so there’s a lot of headroom on the 3568.
WRT Marvell, sadly they’ve completely disappeared. I hoped to see an updated Clearfog with an Octeon10 but nothing appeared on this front 🙁 Given how the good old mcbin was doing at 20Gbps, I guess that a more modern core with higher memory bandwidth and more recent PCIe would do wonders.
I guarantee it cannot do even close to 1Gbps PPPoE – and it’ll be sweating whilst trying. This “meh, it’s good enough for some people” attitude is what encourages companies like FriendlyElec to keep throwing these pointless boards out.
OpenWRT is a bit of a mess, largely due to targeting opaque vendor SoCs from the likes of Mediatek and Qualcomm who aren’t overly forthcoming with the super secret sauce needed for offloading (or forthcoming with anything tbh).
DPDK (and VPP) are changing things (especially in the x86 space) but the only ARM SoCs you’ll see are the usual suspects – Marvell, NXP, Nvidia, etc.
I don’t even understand why you’re insisting on this regarding PPPoE. PPPoE is just 8 bytes to be extracted or appended, that’s as tiny an effort as dealing with a VLAN without offloading (i.e. peanuts).
What difficulties exactly are you dealing with regarding PPPoE processing ? GigE is only 1.488 packets per second. I don’t see the problem of inserting/parsing 8 bytes at that speed on a 1+ GHz core. 11 years ago I made a small stateless HTTP server running on the single core of my mirabox above handling wire-speed GbE at any request size, reaching 660k req/s for the smallest ones (that’s one packet per direction per request) and that requires to parse the HTTP request and headers. Believe me, the quad-A55 at 2 GHz are wayyyyy more powerful than this old beast. BTW I mentioned the mirabox was running 32-bit DRAM, I was wrong, it was only 16-bit! So I’m still puzzled by what you find difficult in dealing with GbE speeds nowadays (especially a single Gbps).
RK3566s embedded MAC handles push/pop ops for dot1q tagged frames, not the CPU. As it does for FCS too. It doesn’t handle other encap/decap.
If you don’t believe me about PPPoE performance then I encourage you to try yourself. (or see the countless stories of people with far more powerful boards struggling to get past 600mbps)
With regard to your Mirabox story – you do realise the Armada 370 is a network focussed SoC, right?
still waiting openWrt to support any of these rockchip chips..
there is already suport for Radxa cm3-io board with a rk3566 soc and upcoming support for other rk3566 boards like rock 3c & zero3e+w
No need to to wait any more:
https://openwrt.org/toh/friendlyelec/nanopi_r3s
@jean-luc
The Odroid Vu8s display uses a 30 pin MIPI DSI Connector, I’m not sure if it’s the same.
I guess Jean-Luc mentioned the ‘LCD situation’ since FriendlyELEC has a history of ‘plug and play LCD support’. I have this LCD-HD101 thingy still lying around somewhere. When attached u-boot detected it at boot and adjusted kernel cmdline accordingly (with FriendlyELEC OS images only of course).
Ah now I understand! They offered me one as well when I was testing the NanoPC-T3, and I, too, noticed that it was automatically detected by the OS. By then I didn’t have much interest in using that so I didn’t investigate further, but I wondered how the kernel decided what console to enable. Of course if it’s u-boot that enables it and passes the info to the kernel, I understand now 😉
It’s because I don’t think there’s a standard MIPI DSI connector layout. Every company does it its own way sometimes with a different number of pins. So unless a specific display is mentioned, we never know which display will work.
Looks quite versatile for the price.