NanoPi R2S Dual Gigabit Ethernet SBC & Router is Powered by Rockchip RK3328 SoC

FriendlyElec launched NanoPi R1S router with two Ethernet ports based on either Allwinner H3 or H5 processor coupled with 512MB RAM last November. Both ports are “Gigabit” Ethernet port, but one is implemented via a USB 2.0 to Ethernet controller with a maximum bandwidth of around 330 Mbps.

If you’d like to get two Gigabit Ethernet reaching close to 1 Gbps each, and your target application would benefit from a bit more memory, the company is now working on NanoPi R2S based on Rockchip RK3328 processor with 1GB DDR4 memory, one Ethernet port using the GMAC from the chip, and one Ethernet port relying one a USB 3.0 to Ethernet controller. The rest of NanoPi R2S specifications are pretty similar to the earlier board except WiFi is also gone:

  • SoC – Rockchip RK3328 quad-core Cortex-A53 @ 1.5 GHz with Arm Mali-450MP2
  • System Memory – 1GB DDR4 RAM
  • Storage – MicroSD Slot, SPI flash footprint
  • Connectivity
    • 1x Gigabit Ethernet (WAN) up to 941 Mbps (measured)
    • 1x Gigabit Ethernet (LAN) up to 941 Mbps (measured) via Realtek RTL8153 USB 3.0 to Ethernet controller
    • 802.11b/g/n WiFi 4 with IPX-I antenna connector
  • USB – 1x USB Type-A host port, 1x micro USB port (power + slave)
  • Debugging – 3-pin 2.54mm pitch header for serial console
  • Expansion – 10-pin GPIO header with GPIOs, I2C, UART, IR_Rx, 5V, 3.3V and GND
  • Misc – 3x LEDs (WAN, LAN, SYS), K1 reset button, fan header
  • Power Supply – 5VDC/3A via micro USB port
  • Dimensions – 55.6 x 52mm
  • Temperature Range – -20℃ to 70℃

Another addition is the presence of a 10-pin I/O which was completely lacking from NanoPi R1S router board. Since WiFi is missing, the company recommends USB dongles based on RTL8821CU since those are supported by the default firmware out of the box. The board also supports 4G LTE via Huawei 8372H-155 USB dongle.

The company will provide both FriendlyWrt, based on OpenWrt, and FriendlyCore, based on Ubuntu 18.04 Core, for the board. More details can be found in the Wiki (Chinese version only for now).

NanoPi R2S will be compatible with the same yellow case used for NanoPi R1S. The board is not available yet, and since Chinese New Year 2020 is right around the corner, I would only expect a launch after the celebrations at the beginning of February at the earliest.

That also means pricing is not available, but considering NanoPi R1S sells for $19.99 (H3) / $22.99 (H5) with the enclosure,  I’d expect NanoPi R2S to sell for a few dollars more, maybe $26.99?, due to the extra memory and USB 3.0 to Ethernet controller.

Support CNX Software - Donate via PayPal, become a Patron on Patreon, or buy review samples
Subscribe
Notify of
guest
34 Comments
oldest
newest most voted
willy
willy
9 months ago

Interesting. I would have preferred to see a dual-port GigE switch like https://www.microchip.com/wwwproducts/en/KSZ9893 instead of one port over USB and another one over Ethernet. But at least it’s a great improvement. Regarding the price, I guess I’d be OK with spending up to ~$30 for such a dual-port board. Maybe it would be the opportunity for us at work to start to work on a new version of our Aloha Pocket and move away from the GL-iNet which is quite limited.

Rogan Dawes
Rogan Dawes
9 months ago

I have been looking quite actively for a small cheap dual GbE SBC. So far, it has been a case of “pick 2”, although the R1S was pretty close. A bit disappointing that the WiFi interface has to fall away in the process, though, although the USB2.0 port allows for adding an external interface as needed. I agree that using a switch chip would make it more flexible, although I suppose it would also limit the absolute forwarding throughput to 500Mbps? Having the USB3 port available for other uses would be nice, though. And of course, that switch chip itself… Read more »

willy
willy
9 months ago

> I suppose it would also limit the absolute forwarding throughput to 500Mbps No that would still be 1Gbps, it doesn’t change anything, that’s the bandwidth supported by the SoC interface used to connect to the switch’s port (some can actually even reach 2.5G). Regarding the switch’s cost, a 2-port switch is around $4, and you remove $2.5 for the USB-to-ethernet interface, and $1.0 for the RTL8211E. In the worst case adding 50 cents to the whole device price remains pretty reasonable given that it enters the very small team of multi-gig boards, which are all significantly more expensive. There… Read more »

Rogan Dawes
Rogan Dawes
9 months ago

I can’t say that I totally understand your reasoning for saying that the total bandwidth would still be 1Gbps. According to https://en.wikipedia.org/wiki/Media-independent_interface#High_serial_gigabit_media_independent_interface, the key feature of HSGMII is the 2.5Gbps capacity, implying that RGMII is only capable of 1Gbps throughput. In which case, the CPU would be able to send and receive a total of 1Gbps traffic from the switch, suggesting that if it is acting in a forwarding role, that it would have to send the same amount of data out of the outbound port as it receives on the inbound. And so the maximum traffic rate it could… Read more »

willy
willy
9 months ago

Ah now I think I understand your reasoning, you probably missed the most important part which is that GigE (and hence RGMII) is full duplex 🙂 So you both receive AND transmit 1 Gbps at the same time. This is why you do really forward 1 Gbps on one port.

Rogan Dawes
Rogan Dawes
9 months ago

Sure, but that doesn’t change the equation. You have 2 duplex 1 Gbps interfaces, i.e. 2 Gbps duplex total, trying to squeeze into a 1 Gbps duplex RGMII channel. It’s just not possible. While it IS possible to pass 1 Gbps inbound on one interface to the CPU via RGMII, and route those packets outbound from the CPU via RGMII onto the other interface due to the duplex capability, as soon as interface 2 starts responding to those packets, there will become a bottleneck, and the throughput from interface 1 will have to drop to allow those response packets to… Read more »

Willy
Willy
9 months ago

No, it has nothing to do with 500 Mbps. If you want to forward 1 Gbps, it will exactly pass through thanks to the full duplex: one port gets 1 Gbps inbound traffic, which leaves the RGMII port, enters the SoC, is processed, and is routed back to the RGMII port, and directed to the second port. You have 1 Gbps in each direction on the RGMII, so you an effectively forward 1 Gbps of traffic between two ports, and there is no such artificial 500 Mbps. Said differently, this supposed 500 Mbps bit rate exists nowhere in the chain.… Read more »

Rogan Dawes
Rogan Dawes
9 months ago

:facepalm: Yeah, I see what you mean. I will get there eventually. Thanks for being patient with me.

C3be
C3be
9 months ago

I beg to differ regarding the use of a switch chip:

A switch, even with VLAN support, *may* connect the WAN & LAN ports into the same network at a given moment (during initial boot sequence, for example, when switch and VLANs are not initialized/configured yet).

Having two distinct network interfaces is an absolute requirement for a router. And, I do agree with you, this is actually a nice board / device for such usage (particularly if the price can actually be around $30 or euros).

willy
willy
9 months ago

The power-on behavior is often configurable on many switch chips. Some require an external EEPROM, some just use some pull-ups. I remember reading a datasheet a long time ago where there was a special mode where each port was put in a distinct VLAN (same ID as the port number). I don’t know if the device I linked to above supports such power-on choices, but that’s definitely something that needs to be validated. Another approach may consist in changing the default port interface mode so that the link cannot automatically go up until the chip is configured by the OS.… Read more »

dgp
dgp
9 months ago

>A switch, even with VLAN support, *may* connect the WAN & LAN ports into the same network at a given moment

The espressobin did just that for me and it caused a ton of issues. I changed over to the odroid h2 because it has two actual interfaces.

Rogan Dawes
Rogan Dawes
9 months ago

Yes, the Espressobin was a notorious offender. However, if you install the latest UBoot firmware, it configures the switch in a non-forwarding mode, avoiding this problem until the OS takes over.

tkaiser
tkaiser
9 months ago

> instead of one port over USB

We should keep in mind that the used RTL8153 is a really solid choice. Even the ‘experts’ over at RPi Trading Ltd. had to admit that when being confronted with the crappy behavior of their crippled GbE USB choice on the RPi 3B+: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=208512&start=100#p1297857

willy
willy
9 months ago

I do not contest this at all. It’s just that when you build a router based on totally different driver stacks depending on the port you use, you observe awkward things that start to make you think what should be put on what port. There’s not just the bandwidth, but the latency, losses, the driver itself, the offloading capabilities, the bugs that can differ between them, etc. It increases the amount of head scratching when observing strange phenomenons. With all that said, we’re still talking about a $30 or so consumer device, which is why I’m still totally positive on… Read more »

willy
willy
9 months ago

> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=208512&start=100#p1297857 BTW I remember this thread now, it was totally hilarious. “Experts” using Samba to measure network losses, and having no idea why some boards were randomly freezing during speed tests after the users had tuned their TCP stack to use 32GB of RAM 🙂 There was absolutely zero trustable information in all that thread, by total lack of methodology and an extreme dose of amateurism from all parties involved. The deepest analysis was “it now seems to work better for me with RTL8153 but still no idea why”. I’d say that I won’t use that thread as a… Read more »

dgp
dgp
9 months ago

>extreme dose of amateurism

They should put a warning with that in at the top of each thread over there.

back2future
back2future
9 months ago

What share of consumer behaviour do they represent?
Guess could be around 10% of people able doing even os adjustments or individual hardware&software interaction?
90% switch-on devices and want them functional (enough for >100Mbit/s and mostly <1-2.5Gbit/s)?
There's less lack of cheap devices, but long term usable hardware, with nowadays SoC performance capabilities?

willy
willy
9 months ago

It’s not just a matter of bitrate but reliability in every day use. Those connecting their RPis to 100 Mbps switches can experience higher performance and stability than those connecting them to gigabit switches just due to reduced losses, hence less retransmissions. Their USB chip has so small buffers that it simply cannot buffer the incoming data for the time it takes the OS to retrieve them, resulting in important losses if they don’t enable flow control (hence why Jamesh asks each and every problem reporter to try to enable flow control on their switches). But that’s too much to… Read more »

manuti
9 months ago

I would have preferred to see a USB-C power.

benjamin
benjamin
9 months ago

Too bad there isn’t an usb3 port available as well.

zoobab
9 months ago

Yeah the “1x USB 3.0 Gigabit Ethernet (LAN) up to 941 Mbps (measured) via Realtek RTL8153” is pretty confusing.

tkaiser
tkaiser
9 months ago

Why/how? The single SuperSpeed port of the SoC is directly connected to the RTL8153b on the PCB. So no more SuperSpeed ports available…

Diego
Diego
9 months ago

Why not adding a hub?

Benjamin Hojnik
9 months ago

or a 3-1 switch to the MAC

willy
willy
9 months ago

Also not sure why the CPU is on top on this board. While cooling is rarely an issue on a router, it’s still more complicated this way than at the bottom like they do on other nanopis.

tkaiser
tkaiser
9 months ago

They have a rather large heatsink as accessory for these router thingies:

http://wiki.friendlyarm.com/wiki/images/8/8a/PSU-ONECOM-R1S.jpg

willy
willy
9 months ago

Yes, it should be way enough for any workload I guess.

tkaiser
tkaiser
9 months ago

With RK3328 you really don’t need much wrt cooling. I’ve set up recently a new backup server using a Libre Computer Renegade (pretty much the same as Rock64 rev3) and this thing just equipped with a small passive heatsink will never throttle (overall consumption when backing up 2 Macs simultaneously: slightly above 3W — but the backup media is a SanDisk Extreme Pro A2 400GB 😉 ) Just started an sbc-bench run and even at 1.5GHz the RK3328 stays below 80°C when running cpuminer for 5 minutes: http://ix.io/27Dq (though there’s something seriously wrong with memory performance, both bandwidth and latency… Read more »

willy
willy
9 months ago

This also matches my observation on the same board, which is pretty nice by the way, hence my comment above 🙂

e97
e97
9 months ago

Finally FriendlyArm will build what I requested years ago. Nice step in the right direction!

Currently using an Atomic Pi + USB 3.0 RTL8153 adapter (~$30 USD) on OpenWrt and it runs line rate 1000 Mbps with QoS @ 25% peak load. With 2GB RAM and built-in 16GB eMMC I’m pretty satisfied with it.

The NanoPi R2S is more compact and integrated, if they can bring down the price point a bit – it will be a huge success vs the similar pfsense appliance that retails around $99

Peter Scargill
7 months ago

Hi Jean-Luc – this is great “the company recommends USB dongles based on RTL8821CU since those are supported by the default firmware out of the box. The board also supports 4G LTE via Huawei 8372H-155 USB dongle.” but up to now I’ve been unable to get a straight answer from FriendlyArm as to how to support a WiFi USB dongle with FriendlyWrt “out of the box”. I’ve installed FriendlyWrt, I’ve added a WiFi dongle (one of the very commonly available ones which simply state “802.11n” on the side of the USB WiFi dongle) – and there is no sign in… Read more »

theguyk
theguyk
7 months ago

Lauched and now on sale @ $22.00. Note Coronavirus shipping advice.

Advertisements