NanoPi R4S - router overkill?

Introduction

A few weeks ago I received the most recent board of FriendlyARM: the NanoPi R4S with 4G of memory.

With its lack of HDMI and other screen connectors this board is clearly designed for headless application like acting as a router, home server, network-attached storage (NAS), media station or everything together the same time. Paying 60$ plus shipping and tax might sound a bit much for a headless board but depending on the usage it can be well worth the money.

I have to admit I do not really know why I bought a board with dual gigabit NIC. I just knew I need to have it. Maybe I have a weakness for (powerful) headless SBCs 😄

Anyway let’s have a deeper look.

Hardware specs

The heart of this SBC is once again the Rockchip RK3399 featuring a hexa-core CPU in big.LITTLE configuration you know from my other reviews like the Station P1 and the Pinebook Pro. As a side note: Overclocking works well and can be achieved the same way as the boards mentioned before.

In any case passive cooling this SoC is recommended. A cheap heat sink made from aluminum should do the trick.
As I like go big or go home stuff I bought some heavy ones make from pure copper and glued them on with a bit of thermal adhesive. I leave a link to both sizes here (20x20 millimeters) and here (14 by 14 millimeters).
By the way the smaller ones fit nicely on Allwinner H2+, H3, H5 and H6 SoCs.

Anyway. In terms of memory here comes the first weirdness. This board is available in two configurations: 1GB DDR3 and 4GB LPDDR4. This might not sound like a big deal. Because for end-users it is not. However in terms of software support this used to be an issue.
In theory both boards would need individual device trees representing their individual memory configuration. Some hacking was needed to get both boards in the same configuration.
You can find more about that story in the Armbian pull request for initial support.

You may have noticed that I put a heat sink on the memory chip as well. Let me tell you there is really no need to do that. I just had some mentioned above leftovers laying around and brought one to good use.

Both network interfaces are 10/100/1000 speed compatible. The noticeable difference between competitor boards, especially cheaper ones, is that the second interface is connected internally via PCIe and not via USB. This should give it a slight advantage in terms of performance and responsiveness. Full disclosure here: This is just my theory about things for which I do not have any evidence. If you do have proper benchmarks for comparison please let me know.
The first NIC is obviously connected and managed natively by the SoC.

In terms of other connectivity the board comes with two USB3.0 jacks, various pin headers including debug serial, one USB2.0, a battery and a fan connector. To close the tour there is one USB-C jack that is for powering while this can be achieved using the pin header too.

You can find more information about the hardware specifications at the FriendlyARM wiki.

Software

Unfortunately at the time I received my board Armbian was still in unusable state so I had to try the images provided by the vendor (link was not broken at this time) which were

• Ubuntu Core build on top of Linux 4.19.y
• OpenWRT build on top if Linux 5.10.y

Kind of weird that they decided to provide a proper Linux distribution with mostly outdated kernel sources while they managed to create an OpenWRT image with the latest mainline.

Anyway. While I was certainly curious about OpenWRT I passed on that one since I did not have a practical usage scenario for a router application (which is - as stated at the beginning - pretty stupid on my part because the board is basically designed for that) and downloaded the Ubuntu Core based variant.
As I was used to I utilized USBimager to write the image to a microSD card and in the meantime hooked up my USB-UART serial adapter to the board.

While the board booted flawless I noticed some weirdness in terms of the OS. It seems like the microSD card was split into something like nine-ish partitions (could not remember and have not interest in testing this again) where most of them were inaccessible. So for example there seem to be no way to access the boot script or kernel binary. I tried digging through their assembly scripts but could not make heads or tails from it. If you wanna take a look I link them here.
Also the whole userspace seem to run as an overlay over the rootfs. Which is neat and weird the same time. The board could be recovered fairly easy by killing the overlay partition and start over with a clean OS. On the other hand what most users would probably do is to simply reflash the microSD card.

Armbian

Thankfully just a day or two after Armbian got their boot issues sorted out and it was now possible to create a proper image. So I got rid of the vendor stuff but that left me with a few unanswered questions: How would they properly update their boot loader and kernel package? And how to set usbstorgequirks in their closed system?
Anyway, those will probably never answered, not by myself at least. And if I think about it I do not really care anymore.

In any case Armbian does what everyone who uses it is used to: Provide a mostly clean OS with proper kernel. And I am proud to say that I was able to add my own bit to that achievement.

At this point I could start boring you with benchmarks and other numbers that under the bottom line telling nothing about real world application. However for those who are interested I leave a link to sbc-bench by Thomas Kaiser here (overclocked and active cooling). You be the judge about the results.
By the way I strongly suggest to follow Thomas around wherever he leaves comments like on cnx-software.com using the pseudonym tkaiser because while being a bit harsh and offending sometimes he is a brilliant mind and has very deep knowledge about low to lowest level software support of SBCs. No harm meant!

Just as a side note: The performance on the second network interface might not be as good as it could be yet. The reason is concerns from the OpenWRT community about using the open source driver built in mainline Linux rather than the closed one with proprietary firmware blob by Realtek. You can find more about that case here.

Custom fan hat

Thanks to my employer I got the great opportunity to play with SolidWORKS Premium. While this is not my day job learning something new is never a loss.
Once I took the basics everything is pretty straight forward and intuitive. And for everything beyond there are tons of lessons included teaching how things work.
Anyway I used that opportunity to create a custom fan hat for the NanoPi R4S. This was mostly for fun though and deepen my learnings.

Unfortunately FriendlyARM did not provide a 3D schematic for their board but 2D dxf files. I was able to import it and create a very basic 3D model only exposing the most important things like clearance holes, pin headers and the important chips by simply creating extruded bosses with height measurements I did with my caliper gauge.

Everything after was pretty straight forward. Adding openings, honings and matching holes.
While not visible in the pictures I created models from the heat sinks from scratch and picked up a generic 30x30mm fan model from GrabCAD.

Thankfully a friend was kind enough to mill this thing from his CNC so it became reality. Of course I had to mount it very properly and totally safe with fitting spacer adapter nuts and Kapton tape like every high-grade engineer would do.

The fan I simply picked up from Amazon.

Conclusion

For simple NAS or router application probably even 1GB of memory is more than enough but having 4G heavily increases the opportunities. Like managing applications in containers such as Docker or LXC or host a complex web interface for you stuff.
As for myself I am still looking for the perfect opportunity. Until then I continue testing new kernels and images and play with random stuff.

I was also thinking about how this board could be enhanced.
Well first of all in my opinion a 8GB memory model would greatly improve the board family. I mean even the RaspberryPi model 4B offering a model with that much memory while the CPU is less powerful.
In reality however the RK3399 is not capable doing that. It is limited to 4GB which is IMHO a bummer for such a neat SoC. That is why I am looking forward to the upcoming generation like the RK3588 which not only comes in octa-core configuration but also can handle up to 32G of up to LPDDR5 memory. We will see what manufacturers will come up with.

The only option to attach additional storage to this SBC is via USB3.0 or optional USB2.0 if you attach a pin header adapter. Having mPCIe exposed would be very neat to add adapter boards for m.2 NVMe or SATA connectors.
But since the RK3399 is only offering a single line of PCIe which cannot be split up easily and it is already used for the second network interface this idea also will stay a dream.

Cheaper alternatives

This post is a collaboration between @jmdawson_blog and myself. He will do a review on the Orange Pi R1 which might be a good choice if you do not need either that much processing power, memory and network throughput or do not want to spent that much money. The R1 can be picked up as low as around 16 bucks US plus shipping from Aliexpress.

You can find his article here.