Posted on by Jean-Luc Aufranc (CNXSoft) - 50 Comments on NanoPi R4S SBC preview with OpenWrt and Ubuntu Core

NanoPi R4S SBC preview with OpenWrt and Ubuntu Core

Rockchip RK3399 powered NanoPi R4S router SBC launched at the beginning of the month, and FriendlyELEC kindly sent a review sample to CNX Software. I intended to test thermally performance, Ethernet, and USB like I did for NanoPi R2S and NanoPi NEO3,  but Armbian is not available right now, so I could not use some of the tools I normally used right now.

So instead, I tested the board/gateway with the image from FriendlyELEC. First FriendlyCore based on Ubuntu Core 20.04, but there some issues which we’ll detail in this preview, so I then switch to FriendlyWrt built upon OpenWrt 19.07 which works better, but I still encountered some problems. That’s just to say it might be better to wait a little longer until Armbian images are released, or until FriendlyELEC fixes some of the shortcomings.

NanoPi R4S gateway unboxing

Before testing the software, let’s see what I’ve received.NanoPi R4S 16GB MicroSD card
NanoPi R4S SBC inside its metal enclosure together with a 16GB class A1 microSD card that, as I found later, comes preloaded with FriendlyWrt.

dual ethernet 5V USB reset
The rear panel includes a USB-C port for power, WAN and LAN Gigabit Ethernet ports, and a reset button.
USB 3.0 microSD camera threadThe front side of the devices comes with two USB 3.0 ports, a MicroSD card slot, and what looks like a standard thread to mount cameras…NanoPi R4S camera-mount
Yes, it is! I could mount the gateway on a camera’s tripod. This should allow for some innovative and inexpensive mounting options…

NanoPi NEO3 R2S R4S
Before I teardown the device, let’s have a little family reunion with from left to right: NanoPi NEO3, NanoPi R2S, and NanoPi R4S. The latter is quite bigger than the other two.

NanoPi R4S “teardown”

Let’s open the enclosure. After taking out the four rubber pads and loosening the four screws on the bottom of the enclosure we can access the board.

NanoPi R4S gateway teardown
After removing two more screws, we can completely take out the board and see the processor is in contact with the metal case through a thermal pad, as it should be.NanoPi R4S Metal Case Thermal Pad
NanoPi R4S SBC

FriendlyCore 20.04 (Ubuntu Core)

I initially thought the microSD card was blank so I went to the Wiki and downloaded the latest version of FriendlyCore namely rk3399-sd-friendlycore-focal-4.19-arm64-20201027.img and flash it to the MicroSD card using USBImager. I then inserted the card into NanoPi R4S, connected Ethernet cables to the WAN and LAN ports, and powered it using MINIX NEO P2 USB-C power adapter.

NanoPi R4S review

I can see the power LED (red) is on, and the status LED (green) is blinking, but the LAN and WAN LEDs are off. I go to my router’s web interface to check for new devices and find out the IP and nothing. Maybe the first boot is quite long, but five minutes later still no IPs. Finally, I decided to power cycle the board, it got an IP address, and I could finally access it via SSH using the default pi/pi credentials.

Let’s check out the details with inxi:


Both Ethernet devices are detected but eth1 down. However even if we turn it on, there’s no link detected:


I thought maybe it could be configured with npi-config that’s supposed to be pre-installed in FriendlyCore, but:


We’ll also notice the temperature is odd at just 26°C, but the same value is reported by sbc-bench.sh:


The temperature measured with an IR thermometer is around 39°C.

NanoPi R4S temperature

That’s truly magic! Now if I look at sysfs, we can see three temperature zones:


zone2 appears to be what is used now, but it’s clearly hard-coded to 26°C. However sbc-bench script checks for another file before going into /sys/devices/ directory:


That’s also hard-coded to 26C, so I’ll comment the part related to this file in the script, making it use thermal_zone0 instead.


It looks better. Let’s run the benchmark:


No throttling was detected, and for instance, 7-zip scores (~5800) are roughly the same as for  RockPi 4C with the Rockchip RK3399 clocked a 1.8/1.4GHz for both SBC.

Since we can’t install armbianmonitor, there’s no pretty chart, but we can still check out the log above and temperature for 7-zip multi-core and cpuminer never exceeded 60C:


That means cooling is working very well, and I suppose running the CPU at 2.0 GHz might also be fine. By comparison, NanoPi R2S reached 85°C and throttled a little during the same test. Note this is winter here, so while the ambient temperature was 30°C for R2S test against around 24°C now.

Let’s check the Gigabit Ethernet port that works (eth0) with iperf using a full-duplex transfer:

  • Upload only:

  • Download only:

FriendlyWrt (OpenWrt)

FriendlyCore has some issues, and limited information in NanoPi R2S Wiki, so instead let’s try FriendlyWrt, and I flashed rk3399-sd-friendlywrt-5.4-20201111.img.zip to the MicroSD card. I did not get any problems to get an IP address this time, and the WAN and LED are working as expected  (green ON) on the board. I could login as root without any password using SSH:


But instead of carrying on with the command, I went on my laptop web browser to access LuCi web interface instead.

NanoPi R4S OpenWrt LuCi

We can also see how the LAN and WAN ports are configured. The WAN port is a DHCP and DHCPv6 client…

FriendlyWrt default configuration… and the LAN port is configured as a bridge set to manage 192.168.2.0 subnet. That’s fine, and the way it should be configured as a router.

But for testing purpose, I deleted the bridge, and set eth1 LAN port as DHCP client so I could get an IP on the same network:

Eth1 Eth0 NanoPi R4S OpenWrtI then tested the WAN port with a full-duplex transfer:


and repeated the same with the LAN port:


All good. I’ve also tested  the USB 3.0 port by connecting a USB 3.0 hard drive on the port next to the MicroSD card, but I got some errors:


So I switched to the other USB 3.0 port, and it worked just fine:


I then configured a SAMBA share in LuCi and the command line, to transfer files from my laptop to the USB drive connected to NanoPi R4S.

NanoPi R4S OpenWrt SAMBA

It works, but at around 16MB/s it’s really slow especially for a USB 3.0 drive. Other Arm-based platforms with Gigabit Ethernet and USB 3.0 running OpenWrt could achieve close to 50MB/s in the same test (and same USB hard drive). Maybe it’s just a question of software optimization.

Conclusion

NanoPi R4S has been better designed than the previous NanoPi R2S notably in terms of thermal design, as the board, while fitted in the metal case, never exceeded 60°C under load. Networking performance seems to be fine too. However, it looks like FriendlyELEC focused on OpenWrt image (FriendlyWrt) more than on Ubuntu Core for now which has a few issues. I also had one issue with one of the USB 3.0 ports but it may be transient.  If you plan on using OpenWrt with the router/gateway, then it may be good, but for Debian based Linux distributions waiting for Armbian images may be advised both for stability and improved performance.

I’d like to thank FriendlyELEC for sending NanoPi R4S for review, and if interested you can get the model with 4GB RAM and metal enclosure as reviewed here for $69 plus shipping on FriendlyELEC store or Aliexpress.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus

50 Replies to “NanoPi R4S SBC preview with OpenWrt and Ubuntu Core”

  1. Armbian images for NaniPi M4 V2 might work out of the box (most probably same LPDDR DRAM initialization). And if you do the test I would choose mainline kernel (FriendlyELEC obviously uses Rockchip’s ‘new’ 4.19 BSP kernel branch and maybe that one is not fully up to the task yet).

    Reply

  2. Ethernet performance is very poor for something that’s being called a router.
    Samba performance is terrible and could easily be improved by better software tuning. Been involved in tuning a router in the past and it went from 25MB/s to 100MB/s.

    Reply

    1. Poor Samba performance is most probably due to combination of UAS with Seagate USB3 disks and missing IRQ affinity settings (both Ethernet and XHCI interrupts being processed on the little cpu0 core where maybe also the smbd task is scheduled to). Can be checked easily with htop and by looking at /proc/interrupts after such a benchmark attempt.

      Reply

    1. I’ve just connected MINIX USB-C hub with SSD, and the SSD is not recognized, so no OTG support I’m afraid.

      Reply

  4. I wonder what can be a real use case for such a form factor?
    For a NAS, it misses SATA connectivity like odroid HC4 (which is multimedia with HDMI).
    For a router, 1 input, 1 output: I call it a cable and it is cheaper.
    An ethernet repeater with firewall functionality: the topology is limited with only 1 output port and why use such a powerful multimedia chip for this?
    I must be missing something.

    Reply

    1. “For a router, 1 input, 1 output: I call it a cable and it is cheaper.”
      This device can do routing stuff: NAT, firewall, IPv6 tunneling.

      NAS is feasible as it has USB3. No fantastic speeds, but maybe enough for medium usage. I have a very small Intel box, with a 5TB 2.5 USB disk connected, and it works as a NAS for me.

      Reply

    2. This is placed between your VDSL router and your WiFi router and GbE switch. You disable everything on your router and setup your network on the Nanopi-R4S, configure your VPNs, firewall, DHCP and network rules using OpenWRT. Now your network configuration is completely independent from your router. You can switch your provider and router at any moment and don’t care if your router supports the services you need.

      Reply

    3. I bought it to replace my 1Gb fiber french ISP box consuming 20watts at idle. Ten times this r4s !

      To remove the ISP box, I need WAN side VLAN tagged packets, kind of DHCP specific config, 6to4 tunnelling for ipv4 traffic, etc, the r4s will handle that on wan side.

      Also I have a manageable switch in which I want to setup separated vlans + firewall rules (separated guest wifi, children controlled wan accès + specific dns, home automation critical subnet, dmz….)

      Last but not least, I want a remote access using wireguard. And if possible vpn also for one of my remote rent server to make it appear in my local network.

      For me, only one LAN port on r4s is fine, as I can easily VLAN tag each machine.

      My 2 cents.

      Reply

  5. Hi,

    Very interresting, thanks for that.
    Would you have any info about its power consumption (at idle and under heavy load) ?

    Reply

        1. I’ve only tested the device as a router, so the load means both interfaces working at max throughput for 2 mins. You can have a look here if you’re interested.

          I believe the increased consumption is due to the fact that the docker daemon runs in the background (OpenWRT) and uses 20-30% of the CPU at idle.

          Reply

          1. Thank you for the article. I wonder how IRQ affinity settings in the FriendlyWRT image look like (checking /proc/interrupts after a while).

          3. > It seems that everything goes only through CPU0

            As expected. This explains also a lot wrt poor Samba performance (where UAS blacklisting of the Seagate disk is missing too).

            Once you send eth0 and eth1 IRQs to cpu2/cpu3 (with appropriate tunables for RPS – Receive Packet Steering – as well) performance with smaller packet sizes might improve. Maybe with small packet sizes it’s necessary to move the stuff to the two big cores which are almost twice as fast as the A53 cores with such tasks.

            At least avoiding the artificial bottleneck on cpu0 would already be a great step into the right direction.

          4. Thanks for the info regarding RPS, this seems interesting. I will try to test this. Tbh, this sounds more interesting to test on the Nanopi-R2S, because the R4S is buffed enough as it is to handle the bridged interface even like that. I may try to test on both for comparison.

          5. OK, cool. I’ve actually seen significant difference by moving the IRQs and the RPS to CPU4 for eth0 and CPU5 for eth, which are the 1.8GHz cores.

            This is the script I’ve used:

            As you can see from this output here, the IRQs seem to be mapped properly.

            Now I’ve tried with 1500 and 512 MTU and the client in LAN and the server in WAN, as I’ve also done in my post.

            Server IP: 192.168.0.2
            Client IP: 192.168.2.126

            Server command (WAN):

            Client command (LAN):

            CPU: 0 / MTU: 1500

            CPU: 4&5 / MTU: 1500

            CPU: 4&5 / MTU: 512

            I don’t know why I’m getting this warning about losing the last ack. It doesn’t make sense only losing that. I’ve tried two times with the MTU set at 512 and I’m getting the same warning.

            And this is a TCP test.

            Server command (WAN):

            Client command (LAN):

            CPU: 4&5 / MTU: 512

            I’ll update my post at some point with those results, too.

          6. Today I’ve done more thorough tests and it seems that there’s no real benefit in a benchmark environment by using those network optimizations. I’ve wrote more details here. I think that my yesterday enthusiasm was based on a number that probably is wrong, since it seems that the UDP packets are actually lost when the MTU is set to 512 and using those optimizations. I didn’t had more time to investigate this, though.

          7. > it seems that there’s no real benefit in a benchmark environment

            Those IRQ affinity optimizations are not for a benchmark environment but for real world scenarios where ‘everything on cpu0’ pretty often creates an artificial bottleneck. Another topic is SMP affinity (using taskset/cgroups since as soon as the process scheduler also prefers cpu0 already busy with interrupts performance suffers for sure)

          8. That’s my thoughts, too; and I’ve also come to this conclusion, that it’s good to have them anyways for real usage.

    1. Yes, correct. There’s no video output. It might still be possible to use the GPU for other things like GPGPU for example using OpenCL.

      Reply

      1. In an ideal world… Wouldn’t some future chipset carry video over USB C alt mode, so that ‘headless’ boxes didn’t need to waste space on a display output?

        [Noting your earlier comment that this sadly doesn’t even OTG]

        Reply

      1. Hi @Jean-Luc Aufranc (CNXSoft), I really appreciate the time you put into this!
        You can control packet size either with iperf’s ‘-M’ option (to set MSS), or by setting MTU at interface level for iperf client and server (https://www.cyberciti.biz/faq/how-can-i-setup-the-mtu-for-my-network-interface/). You need to set MSS to 472 or MTU to 512 for 512B packet size.
        Before testing, make sure you have two hosts (referred forward as ‘iperf client’ and ‘iperf server’) that can handle 900Mbps in direct connect with ~512B packet size (it should be enough, I would be surprised if R4S can route at that speed out fo the box). After that, configure R4S as a router, have the iperf client in the same subnet as R4S LAN interface, add the IP of R4S LAN interface as gateway for R4S WAN subnet on the iperf client, have the iperf server in the same subnet as R4S WAN interface, add the IP of R4S WAN interface as gateway for R4S LAN subnet on the iperf server. Now you can connect iperf client to R4S LAN interface, iperf server to R4S WAN interface, and should be able to run iperf. If you need additional details, you can contact me via email. I would really like to see R4S tested for it’s intended purpose (router/firewall), and I suppose I’m not the only one.

        Reply

        1. At this point in time such tests are pretty much useless since as shown above the vendor’s software offering lacks the needed optimizations (stuff like this for example)

          Without PCIe and Ethernet interrupts sent to cpu4 and cpu5 (the A72 cores clocking in at 1.8 GHz) routing performance will be a joke anyway. Maybe Active-state power management (ASPM) also needs some love…

          Reply

          1. Thomas, there seems to be lots of bugs in this script. First it seems to assume that smp_affinity uses decimal notation while it’s using hexadecimal, so values written as 16 or 32 should be written as 10 or 20. Second, some settings look completely wrong just as if the person writing them thought they were CPU numbers. I think some entries mixed smp_afffinity_list and smp_affinity, though I can’t say for sure since it takes time to review it.

          2. > there seems to be lots of bugs in this script

            Possible. Nobody at Armbian is interested in such stuff any more and it’s more or less an unmaintained mess. I only mentioned it to outline that certain tunables exist and need to be set. And both SMP and IRQ affinity on big.LITTLE designs (where cpu0 is always a little core) are key to performance with such use cases we’re talking here about.

          3. Yep. However the little cores are not necessarily the worst ones to handle network I/O. Very often the user-land work associated with networking is much more expensive than the driver counter-part, and it’s not uncommon to see better performance by binding the application to the big cores and the network layer to thelittle ones. Most of the driver’s job is just accessing memory, and that’s not worse in little cores than big ones. For the cases where crypto is involved, similarly the crypto performance will be roughly the same.

          4. In addition, for CPUs like the S922X or A311D, mixing A73 and A55, I’d bet better memory performance and latency on the A55 core than on the A73, and it could actually make the network run faster on the little core.

          5. I’m totally aware the software is not optimized for the actual purpose of the board (or for anything else) at this point. I’m not even expecting it to be. I just want to see some figures at this state of software as, with the right setting, those can be improved by 30-40% (from my experience with routing on NEO4 with various USB to Ethernet adapters). I’m just hopping the Ethernet over PCIe will generate less IRQ load than Ethernet over USB.

          6. Well, see Dim’s comments above.

            Still, I don’t think any tests or even benchmarking makes any sense unless at least reasonable SMP/IRQ affinity settings and RPS is in place. The artificial cpu0 bottleneck is a joke.

          7. For doing lots of network testing, I second this! I even refuse to waste my time reading network tests reports if the report suggests that nobody knows how affinity was done nor which modules were loaded. Just load ip_conntrack and lose 20%. Leave your IRQ on cpu0 (or forget to kill irqbalance) and randomly lose 80%. Misconfigure RPS and lose an extra 30%. Such numbers which are extremely sensitive to latency and per-packet processing time mean nothing with no precise context around.

  8. @Jean-Luc Aufranc (CNXSoft)
    I see you have the 4GB LPDDR4 version.
    Any chance you could connect a UART console and capture the DRAM init messages?
    Would like to know if they got the DRAM routing on the board “in-spec” this time.

    Reply

  9. Finally, there are nightly (21.02.0-trunk) builds from Armbian 🙂
    https://www.armbian.com/nanopi-r4s/
    Works like a charm…
    I built my own image last night and ran sbc-bench:
    http://ix.io/2KKP
    No big surprises.
    Regarding the temperature: I have the version without the case (unfortunately) and use a small 30mm fan connected to the GPIO.
    Works… until I can buy a metal case (and one for the Neo3, too) 🙂
    Thanks for the review.
    Helped me at lot

    Reply

  10. I see no one has posted a user review, on the Friendlyelec product page yet. Why so quiet?

    Reply

  11. Anybody have luck bringing up a serial console over UART with OpenWRT? I manage to get some garbage in minicom or cutecom after connecting, but can’t seem to get a login prompt.

    This is the hardware module I am using I am using (found on Amazon): IZOKEE CP2102 Module USB to TTL 5PIN Serial Converter Adapter Module Downloader for UART STC 3.3V and 5V with Jumper Wires

    Basically connected GND to GND, RX to TX, TX to RX. Not using the 3.3V or 5V wires.

    Poked around in dmesg and saw this:
    [  0.000000] Kernel command line: console=ttyS2,1500000 earlycon=uart8250,mmio32,0xff1a0000 root=PARTUUID=5452574f-02 rw rootwait

    When I connect I use that baud rate. I keep flow control off.

    Can’t rule out a a hardware problem, though I got a login prompt on a Raspberry Pi with Raspian with the CP2102.

    If anybody uses a UART to USB module they know works, I’d be happy to try that.

    I was hoping to put FreeBSD or Fedora on this in the long run, but in the short run just wanted to toy around and see things work.

    Reply

    1. Usually, garbage output on the serial console is due to one of the following:

      1. Wrong baud rate (or incorrect params like flow control, 7-bit/8-bit)
      2. Inverted Tx and Rx lines
      3. Using a board with the wrong voltage level, e.g. 3.3V vs 5V

      You seem to do everything right, so I do not have an explanation…

      The settings in minicom should be something like 1500000 8N1.
      Alternatively try bootterm: https://github.com/wtarreau/bootterm
      It’s easier to use, and the program I’m now using as well: https://www.cnx-software.com/2020/12/14/bootterm-a-developer-friendly-serial-terminal-program/

      Reply

      1. Thank you, I’ll try that and report back.

        FYI I did stick to 8-bit, and some cursory googling implies this is correct. If the lines are inverted, it’s because something is mislabeled. I’ll explore that possibility, but seems far-fetched.

        Do you use any particular TTL to USB adapter you can recommend? I’m not sure that should matter, but I hear reports….

        One other thing I forgot to mention, I turned on this setting:
        uci set system.@system[0].ttylogin=’1′

        But it didn’t make a difference so far.

        Reply

        1. CP2102 should work fine at 1.5 Mbps. Some adapters will not however (e.g. CH340 loses many characters and is unusable). Otherwise it’s often useful to buy at least one adapter made of a real FTDI chip, they’re extremely performant and adapt to about everything. Using that to confirm a port works helps quite a bit!

          Also it’s worth re-checking the pins and if you’re certain to be connecting to the correct UART. I don’t know the addresses, but it could be possible that by accident you’re using the wrong one. My M4 doesn’t respond right now, but connecting to a Neo4 (which is pretty close) shows me this in case that helps:

          Reply

          1. Thanks to Willy and Jean-Luc for the feedback, and help. Happy to report a lot of success!

            So I grabbed a DSD TECH SH-U09C5 USB to TTL UART Converter Cable with FTDI Chip Support 5V 3.3V 2.5V 1.8V TTL
            I still had problems. So I changed USB ports and now it works with software flow control. Maybe I have a bad USB port.

            I was unable to to have success with bootcom, but worked with minicom and cutecom. I had no luck figuring out the bootcom flow control settings .

            This is the command I used

            minicom -D /dev/ttyUSB1 -b 1500000

            as root

            (not sure how to change flow control from the prompt or with environmental variables, but so far I turned hardware flow control off and software flow control on. Was booted to a login screen, logged in.)

            I’ll try to do some further tests with the CP2102 and report back how it goes. Still not 100% sure what was wrong, but USB port is looking like a culprit. At least a partial culprit.

          2. Cool! Regarding dead USB ports, it happened to me a few times. I know that the DC lines on some of my machines’ ports are weak (such as the netbook I’m currently typing on), it’s probable that I damaged the power transistors used in the current regulators by trying to boot some SBCs directly off them.

Leave a Reply

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

Khadas VIM4 SBC
Khadas VIM4 SBC