NanoPi R6S Review – Part 1: Unboxing, Teardown, OpenWrt 22.03, and iperf3

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.

NanoPi R5S on top of NanoPi R6S

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.

LED status during firmware installation

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:


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


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.53 Gbps. It’s better than Gigabit Ethernet, but it should be possible to improve upon.

Let’s do that again in reverse mode:


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.

Share this:

Support CNX Software! Donate via cryptocurrencies or become a Patron on Patreon

20 Replies to “NanoPi R6S Review – Part 1: Unboxing, Teardown, OpenWrt 22.03, and iperf3”

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

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

  2. 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…?

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

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

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

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

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

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

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *