NanoPi R6S is a Rockchip RK3588S powered device that can not only work as a router with two 2.5GbE ports, but also as a mini PC with HDMI and USB ports, and an Edge AI computer thanks to the 6 TOPS NPU found in the processor.
FriendlyElec has just sent me two samples of the NanoPi R6S for review. Today, I’ll start with an unboxing, a teardown, and install OpenWrt 22.03 to run some iperf3 benchmarks. I’ll try other features with either Debian or Ubuntu Desktop in a few weeks.
NanoPi R6S unboxing
The router/mini PC ships with 6 rubber feet (3M), and nothing else. The front panel comes with four LEDs for the system and Ethernet ports, a USB 2.0 port and a USB 3.0 port, as well as an IR receiver “window” (under the USB 3.0 port). The rear panel includes a USB Type-C port that supports 5V to 20V DC input, an 8K capable HDMI 2.1 port, one Gigabit Ethernet “LAN” port, one 2.5GbE “LAN” port, and one 2.5GbE “WAN” port, each of which can be reconfigured to LAN or WAN to meet your requirements.
The side panels feature a MaskROM pinhole, a MicroSD card slot, and a Reset button.
The new NanoPi R6S has the same dimensions as the NanoPi R5S router, but with some notables differences.
The NanoPi R6S loses on USB 3.0 port replaced by a USB 2.0 port but gains an IR receiver and a Reset button. The rest of the ports are the same, but the layout of the ports is different. The NanoPi R5S supports 5V/9V/12V DC input, while the NanoPi R6S can also handle 20V DC. There’s no marking on the device that indicates where it is an R5S or R6S, so it may be useful to remember those small differences or simply mark them accordingly to avoid potential issues if you need to reflash the firmware.
NanoPi R6S teardown
Let’s loosen and pull out the four screws on the bottom of the device to remove the cover and check out the main board.
The bottom side of FriendlyElec’s NanoPi R6S SBC comes with a FORESEE eMMC flash (right side) and an STM32G030F6P6 microcontroller to handle the power circuitry, the IR receiver, and the RTC.
We’ll need to remove four more screws to completely take out the board from the metal enclosure.
There’s a thermal pad on the Rockchip RK3588S processor to make sure it’s in contact with the metal enclosure so it can act as a large heatsink for cooling the system.
The board features two Realtek RTL8125BG 2.5GbE PCIe controllers and one Realtek RTL8211F Gigabit Ethernet controller as listed in the specifications. Other notable chips include the Rockchip RK806-1 PMIC and two Samsung K4UBE3D4AA-MGCL LPDDR4x chips with 4GB capacity for a total of 8GB RAM.
Installing OpenWrt 22.03 and first boot
The NanoPi R5S routers I received earlier this year shipped with OpenWrt preloaded. But this time around, the device would not boot and all I could see was the red SYS LED blinking forever…
So I downloaded the eflasher image “rk3588-eflasher-friendlywrt-22.03-20221101.img.gz” from the Wiki, flashed it to a microSD card using USBImager, and inserted the microSD into the board to have OpenWrt 22.03 (FriendlyWrt 22.03) automatically installed to the eMMC flash.
If you connect an HDMI display you’ll see the progress on your TV/monitor, but I did not have mine with me, so instead, I just looked at the LEDs on the front panel. Once all Green LEDs are on the firmware update is complete.
I had connected the WAN port to a 2.5 GbE switch, LAN1 to the 2.5GbE port of the UP Xtreme i11 mini PC, and LAN2 to my laptop with a Realtek RTL8156BG USB 3.0 to 2.5GbE dongle. But somehow, LAN2 link would not go up. I naively believe FriendlyElec would provide an image where all three Ethernet ports would be configured, I initially thought there might be a problem with the hardware or the firmware image.
I was able to enter the LuCI interface after moving the Ethernet cable connected to my laptop to LAN1, and it turns out there’s no link for the LAN2 Gigabit Ethernet port because it is not configured in OpenWrt.
It does not matter too much for now, since I’ll focus on the 2.5GbE ports.
iperf3 interface and routing testing
I had poor performance when I tested the NanoPi R5S with iperf3 last June, so let’s see if anything has improved with the NanoPi R6S and the latest OS.
Let’s start by running iperf3 between my laptop (192.168.2.130) and LAN1 (192.168.2.1) on the router:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
jaufranc@cnx-laptop-4:~$ iperf3 -t 60 -c 192.168.2.1 -i 10 Connecting to host 192.168.2.1, port 5201 [ 5] local 192.168.2.130 port 44466 connected to 192.168.2.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 2.71 GBytes 2.33 Gbits/sec 0 3.80 MBytes [ 5] 10.00-20.00 sec 2.72 GBytes 2.34 Gbits/sec 0 3.80 MBytes [ 5] 20.00-30.00 sec 2.72 GBytes 2.34 Gbits/sec 0 3.80 MBytes [ 5] 30.00-40.00 sec 2.72 GBytes 2.34 Gbits/sec 0 3.80 MBytes [ 5] 40.00-50.00 sec 2.72 GBytes 2.34 Gbits/sec 0 3.80 MBytes [ 5] 50.00-60.00 sec 2.73 GBytes 2.34 Gbits/sec 0 3.80 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 16.3 GBytes 2.34 Gbits/sec 0 sender [ 5] 0.00-60.00 sec 16.3 GBytes 2.34 Gbits/sec receiver iperf Done. |
Excellent! No retransmission at all and a 2 .34 Gbps average bitrate.
Let’s repeat the same with the WAN port, after disabling the firewall (in /etc/config/firewall):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
jaufranc@cnx-laptop-4:~$ iperf3 -t 60 -c 192.168.31.181 -i 10 Connecting to host 192.168.31.181, port 5201 [ 5] local 192.168.31.85 port 51772 connected to 192.168.31.181 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 2.74 GBytes 2.35 Gbits/sec 0 1.27 MBytes [ 5] 10.00-20.00 sec 2.74 GBytes 2.35 Gbits/sec 0 1.27 MBytes [ 5] 20.00-30.00 sec 2.74 GBytes 2.35 Gbits/sec 0 1.27 MBytes [ 5] 30.00-40.00 sec 2.74 GBytes 2.35 Gbits/sec 0 1.27 MBytes [ 5] 40.00-50.00 sec 2.74 GBytes 2.35 Gbits/sec 0 1.27 MBytes [ 5] 50.00-60.00 sec 2.74 GBytes 2.35 Gbits/sec 0 1.27 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 16.4 GBytes 2.35 Gbits/sec 0 sender [ 5] 0.00-60.00 sec 16.4 GBytes 2.35 Gbits/sec receiver iperf Done. |
Same perfect result.
Now that we have confirmed the 2.5GbE ports are working at ~2.35 Gbps, let’s test routing with the following arrangement:
- UP Xtreme i11 mini PC connected to the LAN1 port with IP address: 192.168.2.207
- NanoPi R6S with LAN @ 192.168.2.1 and WAN @ 192.168.31.181
- Ubuntu 22.04 Laptop with RTL8156BG dongle with IP address: 192.168.31.85
I’ll start iperf3 -s on my laptop, and run the following command from the UP Xtreme i11 mini PC:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
devkit@UPX-i11:~$ iperf3 -t 60 -c 192.168.31.85 -i 10 Connecting to host 192.168.31.85, port 5201 [ 5] local 192.168.2.207 port 58202 connected to 192.168.31.85 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 1.77 GBytes 1.52 Gbits/sec 0 3.02 MBytes [ 5] 10.00-20.00 sec 1.78 GBytes 1.53 Gbits/sec 0 3.02 MBytes [ 5] 20.00-30.00 sec 1.77 GBytes 1.52 Gbits/sec 0 3.02 MBytes [ 5] 30.00-40.00 sec 1.78 GBytes 1.53 Gbits/sec 0 3.02 MBytes [ 5] 40.00-50.00 sec 1.80 GBytes 1.54 Gbits/sec 0 3.02 MBytes [ 5] 50.00-60.00 sec 1.80 GBytes 1.55 Gbits/sec 0 3.02 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 10.7 GBytes 1.53 Gbits/sec 0 sender [ 5] 0.00-59.98 sec 10.7 GBytes 1.53 Gbits/sec receiver iperf Done. |
1.53 Gbps. It’s better than Gigabit Ethernet, but it should be possible to improve upon.
Let’s do that again in reverse mode:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
devkit@UPX-i11:~$ iperf3 -t 60 -c 192.168.31.85 -i 10 -R Connecting to host 192.168.31.85, port 5201 Reverse mode, remote host 192.168.31.85 is sending [ 5] local 192.168.2.207 port 58206 connected to 192.168.31.85 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 2.71 GBytes 2.32 Gbits/sec [ 5] 10.00-20.00 sec 2.74 GBytes 2.35 Gbits/sec [ 5] 20.00-30.00 sec 2.74 GBytes 2.35 Gbits/sec [ 5] 30.00-40.00 sec 2.74 GBytes 2.35 Gbits/sec [ 5] 40.00-50.00 sec 2.74 GBytes 2.35 Gbits/sec [ 5] 50.00-60.00 sec 2.74 GBytes 2.35 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 16.4 GBytes 2.35 Gbits/sec 0 sender [ 5] 0.00-60.00 sec 16.4 GBytes 2.35 Gbits/sec receiver iperf Done. |
2.35 Gbps average bitrate, now that’s cool. The NanoPi R6S is a massive improvement compared to the NanoPi R5S, at least with my 2.5GbE networking gear, since it works at the advertised speed.
That will be all for today. I’m still not sure what I will review in the second part, but I think focusing on the router part might not be useful since the Rockchip RK3588S is so powerful and I’ll probably install Debian or Ubuntu to review the NanoPi R6S as a mini PC and also try the NPU if the SDK is ready and working.
I’d like to thank FriendlyElec for sending two NanoPi R6S samples for review. The model reviewed here sells for $139 plus shipping.
Continue reading “NanoPi R6S RK3588S mini PC & router review – Part 2: Ubuntu 22.04“.
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
s/last year/5 months ago/g (multiple times)
And you might check ‘/sys/module/pcie_aspm/parameters/policy’ (defaulting to powersave with R5S back then and most probably now with the R6S image being default) and IRQ affinity since RK3588s is a DynamicIQ design with cpu0 being the same lame A55 as in R5S/RK3568. With crappy (AKA default) IRQ distribution and everything ending up on cpu0 both SoCs will underperform identical.
I could clearly remember reviewing the R5S at the end of the last year, but I remembered that wrong :p
It’s still set as powersave:
Congratulations in being one of the first people to review the R6S as it looks to be an upgrade over the earlier models so I keenly await a future review where you test its viability as a mini PC running Debian, Ubuntu or even Android12…?
how about testing wireguard performance too ?
Maybe you could also test wireguard and/or openvpn performance with openwrt ?(sorry about the duplicate post :p)
Pcie is the bottleneck when having 2 x 2.5g lan on pcie2 lanes
They should use rk3588 and utilize pcie2 and 3 both for Ethernet then we can get full 2.3g over routing as the soc can handle it very well.
> Pcie is the bottleneck when having 2 x 2.5g lan on pcie2 lanes
How? Each NIC is attached to a single PCIe Gen2 lane capable of 5GT/s with 8b10b coding as such plenty of headroom.
> then we can get full 2.3g over routing
Jean-Luc demonstrated 2.35 Gbits/sec routed through R6S. Why it’s just 1.53 Gbits/sec in the other direction can be caused by a lot of reasons (many not related to R6S at all).
And actually it would be nice to use a single lane with a dual-port chip to save one lane for something else (e.g. M.2), because in practice, you won’t have traffic on two ports in the same direction at once, and most cases that matter are single-direction per port (e.g. routing or file serving). Unless I’m mistaken, this cannot be done with two ports and a bridge (would require two outstanding transactions from/to two distinct devices), but should be doable for two functions of the same device.
oops, you listed 2.5GbE “WAN” twice.
So whats the timeline for a fully patched and mainlined kernel support?
Because otherwise it’s like using a router without firewall and hope all devices in your lan are hardened/pentested
OpenWrt has a firewall, so no, it wouldn’t be like using one without.
With unpatched CVE‘s in the BSP Kernel‘s network stack it makes zero difference whether one uses a firewall or not…
Note: i don‘t actually know if there are unpatched cve‘s in there, but i highly doubt anyone knows.
> i don‘t actually know if there are unpatched cve‘s in there
One of the early adopters spotted in this Rockchip BSP kernel some nice local privileges escalations (including container escape). This CONFIG_DRM_IGNORE_IOTCL_PERMIT stuff is there since years (at least since RK’s 4.4 dating back almost 7 years) but nobody cares in this stupid SBC world. No idea whether anyone had a closer look into the DW GMAC driver already.
@tkaiser has anyone dug up the scoop on that strange 2 year delay with the RK3588?
No exposed PCIe – no love.
there is (but, what’s hardware without software, and there are enough things to learn about)
Please do not use “OpenWrt” this device is not officially supported.FriendlyWrt is a completely different thing, they obfuscate the bsp kernel in to the OpenWrt web UI.
Living with 4GB SBC’s as daily drivers now since 5 years (Jetson and VIM3 Pro) I think this meme sums it up.
https://0x0.st/oI4E.jpg
Zram makes life bearable though for now but these 8GB new kids on the block will be tempting if the drivers can get beaten into shape and the blobs banished.
> if the drivers can get beaten into shape and the blobs banished.
Asides drivers and BLOBs you seem to forget that giant security issue called ‘BSP kernels’?
One may want to measure latency (responsiveness) too. Also, a GPS PPS signal is good to get into the system. Check out iperf 2 for more.