Our first encounter with the FriendlyElec NanoPi R6S began with an unremarkable brown cardboard box without any prominent branding save for a single white sticker with the letters ’R6S’ printed on it. Flipping the top open reveals a foam protective bag surrounding a pleasantly hefty metal brick. A lot of the heft comes from the passive thermal solution of the optional custom enclosure, the design of which is in stark contrast with the bland box.
This enclosure is a $20 add-on, which should be accounted for and added to the $119 price tag of the bare R6S board itself. Our review unit, sent to us by FriendlyElec, the manufacturer, came with this accessory, so we’re reviewing the set as a whole.
The front of the case features four LEDs: a red status light and three green network lights for the three ethernet ports. Handily placed at the front are also two USB Type-A ports, one of which is a USB 2.0 port, most suitable for connecting peripherals like keyboards and mice, and one USB 3.0 port (also known as a USB 3.2 Gen 1 port), useful for attaching external drives. Curiously, the board does feature an IR receiver, cut-outs for which are located right underneath the aforementioned USB ports.
Looking at the sides, we see a reset button on the left and a pinhole for the MASKROM button on the right. While not as tucked away as the latter (which is also reasonable, as it’s only used during OS reinstallation), the reset button is still a bit indented into the case and generally requires something to poke it with, which is a tad inconvenient. Also worth noting is the power button, or the lack thereof, the presence of which we’re hoping to become standard on all modern SBCs, as it cuts down power cable fiddling to a minimum.
Next to the MASKROM button lies the SD card slot, which is of the nice push-push variety. Push-pull slots might be more durable in the long run, but require large, unsightly cut-outs in enclosures to avoid becoming tedious to operate.
The back of the NanoPi R6S features most of the connectors: two 2.5 Gbps Ethernet ports labelled ‘WAN’ and ‘LAN1’, a 1 Gbps Ethernet port labelled ‘LAN2’, as well as an HDMI 2.1 capable of outputting 8K video and a USB-C port meant for supplying power to the board, as well as flashing software to the board’s built-in eMMC storage.
We’ve already mentioned the sleek-looking metal chassis, which serves double-duty, both protecting the SBC itself from the elements and providing a degree of passive cooling to the RK3588S SoC. Two soft pads on the bottom prevent damage to the surface the system sits on, and four screws located next to these hold the case together, making assembly and disassembly easy.
There is no power supply shipped with the NanoPi R6S, so you’ll have to bring your own. Do keep in mind that, like with all RK3588 and RK3588S-based systems, it’s best to opt for a 5V/4A supply, with 5V/3A supplies working for some, but not all boards.
A closer look at the FriendlyElec NanoPi R6S hardware
Before we continue, let’s crack the case open and check out the NanoPi R6S board directly. By unscrewing all the screws holding the bottom plate in place we immediately get access to the board. Four more screws hold it tightly against the top of the case. Undoing these lets us extract the board and take a glance at its upper side which houses the heart of the system: the RK3588S SoC. There’s a thermal pad coupling this chip to the top of the case, allowing for efficient heat transfer. While thermal pads are reusable, the design here exposes it to the elements each time the case is opened. We’d recommend replacing it every now and then, especially if dust or other debris gets lodged into it.
The board itself is a pleasant shade of blue and feels solidly built. There’s no M.2 slot anywhere (it’s our understanding that there were no leftover PCIe lanes for this next to three Ethernet controllers), so the only storage options are the 32 GB of built-in eMMC 5.1 produced by FORESEE and an SD card slot. Right next to the RK3588S are two chips, for a total of 8 GB of 2133 MHz Samsung K4UBE3D4AA-MGCL LPDDR4X RAM, two Realtek RTL8125BG 2.5 Gbps Ethernet controllers and one RTL8211F-CG 1 Gbps controller. There’s also a two-pin RTC battery connector and three-pin UART debug header. Unlike most other SBCs, which usually feature 40- or 26-pin GPIO headers, the R6S features a 12-pin ZIF connector. While many of the most common IO protocols can be found among these, including SPI, UART and I2C, as well as some GPIO pins, this implementation which requires some sort of FPC breakout board is less-than-convenient. We’d have preferred the traditional setup here, but can’t be too harsh due to the (visibly) very limited space on the board.
The RK3588S is RK3588’s lesser sibling, offering the same CPU and GPU setup, with four Cortex-A76 and four Cortex-A55 cores running at 2.4 GHz and 1.8 GHz, respectively, and a Mali-G610 MP4 GPU. Both chips also feature the same 6 TOPS neural processing unit. The differences are in the peripherals, with the RK3588 offering extra video outputs, a native video input, additional USB, SATA and PCIe 2.0 lanes, as well as two PCIe 3.0 lanes. There are some other minute differences, but for SBCs, the most notable drawback is the lack of PCIe 3.0 lanes, limiting data transfer speeds to around 350 MB/s.
Unrelated to the processor choice, there’s also no Wi-Fi or Bluetooth on-board. The lack of both an M.2 and 40-pin connectors mean that internal wireless cards are also out of the question (or at least we weren’t aware of any utilizing the 12-pin ZIF connector, which is odd since the case has a hole for an antenna). This leaves us with wireless USB dongles as our only option. Definitely a bit of an oversight.
That’s it for hardware itself. The NanoPi R6S is clearly a device meant for use with an enclosure and not as a bare-board. With significantly less low-level connectivity than most SBCs, it’s clear that it’s envisioned as an edge server, IoT gateway or even as a small desktop.
For reasons listed above, we’ll evaluate the R6S as a “compute box” and not as a traditional SBC. We’ll digress a little here to mention the NanoPi R6C, a similar board lacking one of the Ethernet ports, but gaining a full-size GPIO header instead, as well as an M.2 slot. With the R6C’s connectivity options being much more traditional, it’s the way to go for projects which require more hackability. We’re working on a review of it, as well, and it’ll hopefully be out before long.
Back to the NanoPi R6S! We loved the well-designed and, simply put, easy method of OS installation (this applies to most NanoPi products, by the way). Images can be flashed directly onto SD cards, just like on a Raspberry Pi. This is easy, but limits the read/write performance of the system down the line. Images can also be directly flashed to the built-in eMMC, which is a procedure we know well from other RK3588/RK3588S systems, but is a bit more challenging. Finally, there are special ‘eFlasher’ images which are flashed to SD cards, as usual, but automatically copy the system to the built-in eMMC. Once this is over, the eFlasher utility prompts the user to remove the SD card, at which point the OS boots up as normal from internal storage. This is an extremely easy method of installing operating systems, and we reckon it’s the best way to get all official images onto the board.
The official documentation is pretty comprehensive and accurate. All of the official images – and there’s a decent selection to choose from – as well as many third-party ones work. Ubuntu, Debian, Android, Android TV, FriendlyCore and FriendlyWRT, the official OSs, all work right out-of-the-box.
Armbian and DietPi are two major third-party operating systems for the NanoPi R6S. These are officially maintained for this board by their respective creators, which also makes them great, stable choices.
Generally, all of the offered images, both official, and third-party, use Linux kernel 5.10. Newer versions aren’t generally available yet for RK3588-based boards. Ubuntu is currently available in versions 20.04 and 22.04, with various desktop and window system configurations. Debian 11 is also there, with CLI-only and desktop images. Armbian’s newest version, 23.5, is also available, in both the Debian Bookworm- and Ubuntu Jammy Jellyfish-based builds.
The FriendlyCore distro is developed and maintained by the FriendlyElec team and is based on Ubuntu 20.04 and the 5.10 kernel. It replaces X11 and Wayland with the Qt’s embedded GUI, and is meant for industrial applications. Using FriendlyCore, the NanoPi R6S becomes a capable embedded edge computing platform, capable of driving even demanding multimedia applications.
FriendlyWRT is an in-house version of the OpenWRT embedded distro. Given the three Ethernet ports available on the NanoPi R6S, alongside a powerful RK3588S chip make the NanoPi R6S a handy router, switch or IoT node. Docker is also right at home here, capable of running multiple containerised services in parallel, ideal for WordPress, Nextcloud, Jellyfin, Home Assistant or Minecraft servers.
DietPi is an interesting distro which we stumbled across while analysing some benchmark discrepancies. It’s essentially built on top of Armbian, offering a minimal installation script for producing fast and lightweight system images, squeezing more performance out of lower-end hardware. The NanoPi R6S (and R6C), at the time of writing, are the fastest devices capable of running DietPi software. The handy installer supports quite a few server packages, while still keeping the installation as optimised as possible. DietPi has an active community of users, too, so we’re definitely happy we’re seeing it brought to the NanoPi R6S.
Finally, there are Android and Android TV, both based on Android 12 here. The stock Android image is based on the tablet UI and is a great development sidekick, while Android TV makes for a great media centre. Both images are lightweight and work great on the NanoPi R6S.
Overall, the software support is surprisingly good. We’re used to maybe one or two relatively functional images, with most others being unstable to some degree, requiring significant time and effort to get up to snuff. This isn’t the case here, with almost all of the images being fully stable with some minor quirks here and there, usually related to minor issues with peripherals.
Performance and thermals
Let’s take a look at the thermal performance first. We’re testing with the case on, as it’s supposed be able to keep the system temps at bay (and testing the bare board without any cooling generally leads to immediate thermal throttling; useful data on this can be found in our review of the ICE Tower for the Orange Pi 5). Like always, we stressed the board using s-tui. Even though temperatures quickly began climbing after maxing all the cores out, after about an hour, there was still no throttling and the temperatures settled around 75°C, which is pretty great! Curiously, even though the thermal solution here is fully passive, it does a better job than the one on the Mixtile Blade 3, another SBC which uses a similar style case, but also incorporates a fan into the design. These case-based thermal solutions are inexpensive and fairly effective, with the only drawback being quite predictable: since the case itself is the heatsink, it gets reasonably warm during operation.
Not all RK3588 and RK3588S chips hit the same 2.4 GHz peak clock, with the RK3588S chip in our NanoPi R6S hitting 2352 MHz. That’s 48 MHz less than spec, or exactly 2%. We’ve explained this phenomenon in some previous articles, but we’ll also write a separate blog post about it soon. For now, all you need to know is that these minor deviations are not board manufacturer’s faults, and in general, don’t affect performance all that much.
Let’s move onto the benchmarks. As always, we consider these good indicators of overall performance, and nothing more than than. Even with stable, mature systems many things can lead to inaccurate benchmark results. Software issues, compiler settings and thermal issues are just some of the factors affecting results. While we try to ensure our data is as correct as possible, no benchmark is perfect by design, and should be used for orientation purposes only.
Starting with GeekBench 5.4.4, we get a good 591/2538 single/multicore score. It’s a few percent lower than what we’re used to seeing in RK3588 boards, but we’ll write it off as software-related, as there wasn’t any thermal throttling happening. The lower CPU clock also doesn’t quite explain this as some boards with even more significant throttling (up to 4%) got slightly better results here.
Of course, these results are still much better than those of basically every other ARM-based SBC on the market currently. The aging Raspberry Pi 4 doesn’t even come close, and even some x86-based platforms struggle to compete.
OpenSSL’s speedtest returned very expected values. With hardware acceleration enabled it’s one of the most stable tests, mostly due to the implementation of ARM’s encryption engine. Also due to the implementation of the encryption engine, this test is sensitive to even the tiniest change in processor clock, so the 2% drop in A76’s clock reflects here, too (the score drop is smaller since the four A55 cores still run at their normal 1.8 GHz).
Sysbench’s CPU test is another benchmark where the R6S does great. Compared to other RK3588 boards, we got a slightly lower score, which we’ll again write off as software-related. We’ll look into these tiny discrepancies further and will update this post if we get definitive answers.
Comparing these results to other systems, not based around the RK3588 just confirms the SoC’s standing as the current top dog in the SBC industry, offering some of the best performance we’ve seen yet.
R6S’ 2133 MHz LPDDR4X RAM has a reasonable ~17 GB/s bandwidth per channel. The test results here put it on par with what we’ve seen used in other RK3588-based systems. It’s no LPDDR5, but it’s decently fast for any task, and certainly not the source of any bottlenecks.
Tinymembench results also confirm that we’re, in fact, dealing with dual-channel RAM here. Hurrah!
Unixbench results are also on par with what’s expected, with pretty decent performance, both single- and multi-core.
We don’t use Octane 2.0 anymore as a “mainline” test as it’s heavily reliant on software. Still, it’s a good representation of how “snappy” an OS feels during use, which is, arguably, also reliant on software. The Octane score we get here is a rather decent one, outshined only by x86-based boards.
Finally, testing the built-in eMMC with HDParm gets us a result of 245.31 MB/s, which is on the faster end when it comes to flash storage.
Still not fully sure about thermal throttling, we decided to run the sbcbench script, which also reported what we’ve manually seen before: no thermal throttling was reported, with the cores never exceeding 76°C. One little curiosity we noticed here: even though the cores reported their speed as 2352 MHz, they delivered a bit less, closer to 2300 MHz. If this is the rule when it comes to Rockchip boards, and not the exception here, even boards which report the “full” 2400 MHz might not reach it reliably. We’ll definitely dig a bit deeper into this.
This is all essentially nitpicking, given how much faster these boards are from anything else on the market. We’re talking about a couple percents at best. Much more noteworthy are the performance gains when compared to a Raspberry Pi 4, or a last-generation S905-series or RK3399-based boards.
We’ve seen many boards using this same SoC in the past, and they generally follow the same set of design ideas. The R6S doesn’t do anything groundbreaking (save for, maybe, the three Ethernet ports) when it comes to the physical features present on-board. It’s pretty standard. However, software support truly sets it apart from others, with a wide variety of fully-featured OS images. Perhaps this is due to an active and vibrant community, or just more care given to polishing an often overlooked, albeit essential, component of boards like these.
FriendlyElec did a lot to enable easy and quick OS installation. Sacrificing the traditional GPIO header is a bit of a bummer, but with the well-designed case in mind, it’s definitely not as major of a drawback as it initially seems. What we dislike is the lack of a power switch and wireless connectivity, the latter of which will generally take up one of the two USB ports. Even with minor design flaws, the NanoPi R6S is a great system based on the modern and powerful RK3588S chip, offering some of the best performance currently available in the SBC world thanks to it. It’ll perform great no matter the task: from IoT applications to home routing and various types of servers, the NanoPi R6S can be relied on.
More information: FriendlyElec product page