FriendlyELEC has launched its sixth generation router with the NanoPi R6S equipped with a Rockchip RK3588S processor, two 2.5GbE ports, one Gigabit Ethernet port, and two USB interfaces.
But the device will not exactly be limited to router functions as it comes with 8GB RAM, a 32GB eMMC flash, and an HDMI 2.1 port that support up to 8Kp60 video output, not to mention 8K video decoding capability and the integrated 6 TOPS NPU for AI workloads.
NanoPi R6S specifications:
- SoC – Rockchip RK3588S octa-core processor with:
- CPU – 4x Cortex-A76 cores @ up to 2.4 GHz, four Cortex-A55 cores @ 1.8 GHz
- GPU – Arm Mali-G610 MP4 quad-core GPU with OpenGL ES3.2 / OpenCL 2.2 / Vulkan1.1 support
- VPU – 8Kp60 H.265/VP9/AVS2 video decoder, 8Kp30 H.264 decoder, 4Kp60 AV1 decoder, 8Kp30 H.265/H.264 video encoder
- AI accelerator – 6 TOPS NPU
- System Memory – 8GB LPDDR4X @ 2133 MHz
- Storage
- 32 GB eMMC flash
- Optional SPI flash for network boot
- MicroSD card socket
- Video Output – 1x HDMI 2.1 port up to 8Kp60, or 4Kp120
- Networking
- 2x 2.5GbE RJ45 ports (via 2x Realtek RTL8125BG PCIe controllers) tested up to 2.35 Gbps (Rx) and 2.35 Gbps (Tx)
- 1x Gigabit Ethernet RJ45 port (via Realtek RTL8211F) tested up to 941 Mbps (Tx and Rx)
- USB – 1x USB 3.0 port, 1x USB 2.0 port
- Expansion – 12-pin 0.5mm pitch FPC connector with up to 1x SPI, 3x UART, 1x I2C, 8x GPIO
- Debugging – 3-pin UART header
- Misc
- Mask key for eMMC flash update
- RTC connector for HYM8563TS real-time clock
- 5V fan header
- 1x user button
- 4x user LEDs for system and Ethernet ports
- IR receiver
- Power Supply – 5V/9V/12V USB Type-C port (USB PD support)
- Dimensions – PCB: 90 x 62 mm; enclosure: 96.5 x 68 x 30 mm
- Weight – TBD
- Temperature Range – 0 to 70
The NanoPi R6S will be much more powerful than the Rockchip RK3568-based NanoPi R5S mini router introduced last year, but some features are been removed such as the M.2 socket for an NVMe SSD, the 16-pin GPIO header on the SBC is gone, and the company also had to replace one of the USB 3.0 ports with a USB 2.0 port. That’s just because RK3588S has fewer interfaces than the RK3568 SoC.
2.5 Gbps Ethernet appears to have improved, while the R5S could receive data at up to 2.35 Gbps, it would only transmit up to 1.8 Gbps, and the R6S delivers 2.35 Gbps in both directions. As usual, there’s no WiFi because the company expects customers to add a USB dongle if needed. FriendlyELEC offers three OS images for the board/router, with FriendlyWrt based on the latest OpenWrt 22.03, FriendlyWrt with Docker, and FriendlyCore Lite based on Ubuntu 20.04 with all images relying on the Linux 5.10 LTS kernel. More details can be found in the Wiki.
FriendlyELEC contacted me last week about sending NanoPi R6S samples, so expect a review soon. The NanoPi R6S is available as either a bare SBC for $119 or a router with a metal enclosure for $139.
Via Liliputing
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
Meanwhile, here I am, still waiting for Rock5B–while grabbing another elitedesk 800 G4 mini.
and me still waiting for the Banana Pi BPI-M2S
Hope that your banana pi available soon. My elitedesk mini has arrived. Testing now with the i5-8500, 512GB nvme and 12GB RAM. Good power consumption, hovering around > 5 to < 6 when idle when using windows 11, measured from the wall. Nice figure, better than prodesk 600 G4, G2.
A pity that
> with all images relying on the Linux 5.10 LTS kernel
I highly doubt this is 5.10 LTS. More likely the same RK 5.10 BSP kernel we can’t trust into (few exploit issues listed here) with some version string cosmetics applied.
BTW: FriendlyELEC has in its BLOB repo since few weeks a more recent DRAM initialization for RK356x: rk3568_ddr_{1560…324}MHz_v1.14.bin
And also a more recent boot BLOB for RK3588/3588s/3588m (rk3588_bl31_v1.28.elf). RK3588m is this here:
https://i0.wp.com/techacute.com/wp-content/uploads/2022/03/Rockchip-Launched-Flagship-Smart-Vehicle-Solution-Architecture.png
where do i get this 1.14 ddr bin for rk3568? i dont see any git repo with >1.13. Thanks
a bit too expensive if you’d ask me…
This is arm-world, real companies making real low-volume product. Not regime-subsidized backdoor-your bum free-candy van product.
You think this is bad, wait until you see their absurd shipping quotes. Total waste of time
It’s an over powered router with limited storage options. Why no m pcie storage interface?
> Why no m pcie storage interface?
Since the SoC is too crippled. RK3588s features only two PCIe Gen2 lanes and each of them is occupied by a RTL8125BG NIC already. Without utilizing a PCIe switch (further inflating the costs) there’s no way to get anything else with PCIe here.
Sorry, but how is 32 GB of eMMC limited storage on a router?
Most routers to this day, have no more than 32 or 64 MB of internal storage.
It’s trying to be a little more than a router with that HDMI 2.1 port. 😛
Actually it depends. The CPU is far too powerful to be only a router. For a VPN gateway it can make sense, of course. However it could also be used for network captures as a bridge, but then 32 GB of storage is insufficient and that’s where an M.2 slot could have helped. I too consider that the product is a bit awkward, using a desktop CPU in a router. That doesn’t make it bad at all, it’s just that I think its capacity will never be exploited. For the first time I felt like I wouldn’t have any reasonable use for a NanoPi device. Admittedly it’s also because I already have a number of other models and don’t need this one to complete the family. Maybe for someone looking for a generic board, it could make a more versatile one than other devices.
With a SSD, this router is capable to be used as IDS/IPS in enterprise
Will be interesting to see what the actual throughput is and if this thing can handle things like acting as a VPN server without griding to a halt.
You want to run this device as router or VPN node with vulnerabilities as funny as ‘a trivially exploitable misfeature in the RGA driver that can be used to escalate privileges to system root even from inside a container‘?
Hopefully Jean-Luc will check kernel config for CONFIG_DRM_IGNORE_IOTCL_PERMIT and access to the various exploitable device nodes in question when conducting also security checks for his review.
You have done a very good job exposing such vulnerabilities, and any buyers who expect to use such a device out of the box must be aware about them.
Nevertheless, software problems can be corrected. Much more important is to have a cheap and well documented hardware, with schematics, datasheets and technical manuals, which both NanoPi R5S and NanoPi R6S provide.
This is significantly cheaper than the previous RK3588 boards with similar connectivity, even if they had to accept some compromises in order to achieve the low cost.
The most annoying is that one of the USB ports is now 2.0. With NanoPi R5S, one can have four 2.5 Gb/s ports, after adding 2 USB adapters. On R6S, at most three 2.5 Gb/s ports can be used. So one must choose between more ports and a much faster CPU, which can cope with much more complex firewall rules.
If I will buy either NanoPi R5S or NanoPi R6S, I do not intend to use the provided software, except as documentation for what the device drivers must contain. Instead of that, I would port FreeBSD to the board, because that is what I currently use in the routers/firewalls that would be replaced by these devices.
> the previous RK3588 boards with similar connectivity,
This is not a RK3588 board but RK3588s instead which is a weird SoC since rather powerful wrt CPU but lacking decent I/O capabilities (RK3568 in R5S is way better here but just 4 x A55 at below 2.0GHz and as such limited in terms of dealing with 4 x 2.5GbE).
As for ‘cheap’ better check shipping first (unfortunately FriendlyELEC doesn’t care about an EU distributor)
> I would port FreeBSD to the board
Your main challenge will be bringing up the PCIe controller in EDK2 UEFI since afterwards you should already be able to use all three NICs in *BSD (only thing remaining: dealing with the RealTek driver situation there).
> Your main challenge will be bringing up the PCIe controller in EDK2 UEFI
Forgot to post a link to Rockchip’s own EDK2 repo (please keep in mind that those RTL8125BG are not connected to the PCIe3x4 controller mentioned there).
> exposing such vulnerabilities, and any buyers who expect to use such a device out of the box must be aware about them
There are 3rd parties like Armbian who try to masquerade the messy and dangerous situation with this specific Rockchip 5.10 kernel that’s forward ported since ages.
They do version string cosmetics up to 5.10.149 to trick their clueless users into believing they would deal with an up-to-date LTS kernel 🙁
The kernel situation is pathetic. Vendors are cheating on kernel versions like they were cheating on frequencies 10 years ago. The only positive thing we can hope for is that after they make the headlines of the press for critical vulnerabilities that were never fixed, they’ll start to pressure the SoC vendors to provide *real* kernels and not 13-year old forks where versions are purely invented.
I would love to be able to write a kernel version assessment utility that would verify that the claimed version really contains what it pretends to be, like we did to put an end to frequency cheating. But here it’s much more work and particularly difficult. There are only a few bugs here and there that we could possibly use as hints, that would be difficult.
Is there an easy/automated way to report count of merge conflicts trying to rebase those crappy vendor BSP kernels on the respective LTS kernel version?
> 5V/9V/12V USB Type-C port (USB PD support)
Since according to schematics R6S can cope with 20V via USB-C it’s this simple device-tree change that will allow also higher USB PD negotiations: https://github.com/radxa/kernel/commit/7afb45601d6c3d473096d47fea926a89c91061cf
Another potentially brilliant board without an easily accessible serial port !
Can somebody please enlighten me, why are companies like this making SBC cases without a debug port ? If anything goes wrong and you can’t ssh into it, you have to take the whole thing apart just to connect to UART. This is so incredibly frustrating !
I’ve implored the FriendlyElec team for this for several years already, for each and every single device they release. No change. It’s a real pity. Just a CH340E and a micro-usb or usb-c port would be awesome. With plastic boxes you can easily drill a hole but in the R4S there’s nowhere to place such an extra port. Actually this new board is the first one of their multi-port boards to have an HDMI connector so you can arrange yourself to avoid the screwdriver. But still its extremely annoying and by far their biggest defect, it’s really sad that after several years they insist on not understanding this. For networking stuff I’m only using SolidRun for this exact reason because FriendlyElec is not usable in field 🙁
Thanks for comiserating 🙂
Good point about the hdmi though, it’s at least salvageable now with a screen and keyboard
Except if you need to touch the boot loader.
real bummer.
I was expecting uboot could display some text over HDMI. I must have gotten wrong expectations from the x86 world.
What is the difference between R5S and R6S? I see more powerful CPU, the HDMI port has moved, only 1x USB3 port on the R6S. Anything else?
I think that the mainline support for the 3588 lags a lot behind the 3566 one (though I could be wrong for the 3566), and that’s a problem because the rockchip BSP kernel is totally broken and full of security holes that cannot be fixed since nobody can figure what’s broken there. For a router I’d prefer to use a mainline kernel where I can adjust options to suit my needs. Having suffered from BSPs in the past on routers left me a bitter taste that I’m not willing to experience again.
The CPU is indeed powerful but I’m having a hard time imagining what workload can make good use of it. There’s enough processing power to route 20-30 Gbps there, and since the device doesn’t have much more than ethernet devices, you can hardly imagine doing much more (e.g. traffic capture etc). This will nonetheless make an excellent networking gear once support reaches mainline in a year or two.
Was excited until I went to check out. Their shipping is insanely inflated. $86 to ship this miniscule thing to Canada. Absolute joke
strange as it’s just estimated 13$ (snail mail ~2months) to a few countries in Europe I’ve checked – like UK or HU – mine (Romania) is not available though although part of the European Union
Yeah, not just Friendlyelec stock their products. There is their distributor list as well as Aliexpress.
> There is their distributor list
Check it and you’ll be disappointed. Allnet is stopping EU distribution since FriendlyELEC doesn’t care about CE certification, Industrial ARMWorks, Venus Supply and AntraTek all do not stock FriendlyELEC products made in recent years, the 1st on the list actually still ‘distributing’ their boards is Korean Centron.
Which is a shame given FriendlyELEC IMO being one of the few good SBC makers.
“The NanoPi R5S is an open sourced mini router with two 2.5G and one Gpbs Ethernet ports []”
Rk3568B2 (quad A55, 2GB mem)
“The NanoPi R6S is an open source and high performance platform [] It supports multiple OS systems including FriendlyWrt, Android [TV12], Debian [10 Desktop], Ubuntu [22.04 LTS Desktop (Coming Soon)] and more.
[]
The R6S is especially featured for enterprise applications such as mini machine vision systems that need multiple Ethernet ports, as well as platforms for electronic hobbyists to explore various possibilities.”
Rk3588S (quad A76, quad A55, 8GB mem)
including hw accelerated GPU, VPU, NPU
while implementing Rk3588S, seems optimizing for networking applications was not most important for this device anymore (continuity and FriendlyWrt/OpenWrt would imply networking emphasis) and keeping the naming scheme “RxS” was not that consistent, if so?
I’m pretty sure it simply boils down to “how do we justify using that powerful a chip in a router?”. So they’re trying to find extra use cases and probably are left like us with few ideas. Let’s be honest, often we complain that chips are too small for the task, this time it’s too big. The first cause is likely Rockchip having left too few I/Os in this chip to make efficient use of its processing capabilities. Probably that 2xA76+2xA55 could have been enough for that amount of I/O.
> Probably that 2xA76+2xA55 could have been enough for that amount of I/O
In an attempt to ‘save energy’ the A76 could be disabled altogether since the A55 cores in RK3588 could be ‘fast enough’ and even slightly faster than the same A55 in RK3568/R5S due to the much faster memory. At least the A55 are twice as energy efficient in RK3588 compared to RK3568 🙂
It’s no complaint about performance or idling energy consumption, just summarizing some of previous and reasonable points towards an explanation (also FriendlyElec’s pov). If a R6S is to costly (might be around double price) for tasks and devices required (now) a R5S still might be a justifiable alternative, depending on average consumption (idling/performance emphasis) what might be ~300mW (Rk3568:Rk3588(S)) idling/’lowMHz’ difference and ~600mW (~15Wh/device for 24h) performance difference for A55 cores (different production nodes, comparable MIPS)?
Considering I/O, network storage might solve some router usage dependent limitations, but that’s not what a double USB3 (without downstream hubs) provided on previous R5S (mentioned from Jiri Brejcha).
Rk3588 being replacement (pin compatible?) for Rk3588S would be an additional (2/4 to 8GB RAM) ~10% price increase (from low volume prices for SoCs)?
“too small for the task, this time it’s too big”
duties for guarantees for Kernel, drivers compatibility or distribution libraries adjustment is getting more diverse (at least at the moment on ARM standardization levels) and concentration only towards big companies is not (always==prices dev) what a dev community (nor mass markets for the long ways) wants to get and many advanced SoCs are on performance levels where users feel less or even no constraint on average tasks.
USB3 introduced satisfying hardware performance (for decades?, considering 3.x versions), Rk3588 level SBCs will for some time (complexity into devices varieties, apart from mobiles market & prices) and NPUs could provide useful tasks to enhance abilities on hard- and software standards (, PCIe will be closing a gap towards pc class connectivity, while expecting > version4 seems too costly?).
I/O (above Rk3588) is for Rk37xx (Rpi5) or other ‘ISA’s?
maybe ‘give it (and the peripherals) time for adjust and increase resources before (extraordinary) performance demand’?
maybe that’s interesting to add also: Rk3399pro to Rk3588 is ~115% addition to cost for a SBC (based on comparable low volume SoC prices and these days production volumes), roughly $40-50 (Rk3568 is at ~50% to Rk3399pro)
(&new, more capable peripherals, probably)
Looks like lots of wasted potential to cram it into the tiniest form factor… just 12 GPIO. no MIPI-DSI. no MIPI-CSI. USB-C just for PD and not for DP/USB3.1!
at least the price is nice.
At least it’s larger than the old and busted Pi Model B form factor. Also note that the RK3588S is a cheaper variant of the RK3588 with less I/O, and this is ostensibly a router, not a desktop PC.