NanoPi R6S RK3588S mini PC & router review – Part 2: Ubuntu 22.04

NanoPi R6S is both a mini PC and a router based on Rockchip RK3588S processor. I received some samples in November and started the NanoPi R6S review with OpenWrt/FriendlyWrt quickly testing the 2.5GbE interfaces and routing with iperf3, and it worked pretty well. But using a system with an octa-core Cortex-A76/A55 processor and 8GB RAM as an OpenWrt router only feels like a waste of resources, so I wanted to install a more versatile operating system – Ubuntu 22.04 – for further testing.

My struggles installing Ubuntu 22.04 on NanoPi R6S

FriendlyELEC provides various images on the Wiki either booting from an SD card, installing from a MicroSD to the eMMC flash (aka eFlasher imagers), or flashing through USB with Windows tools. I like the eFlasher images since the OS runs from the internal eMMC flash and no special tools are needed. I had just used the FriendlyWrt eFlasher image, so I thought switching to the Ubuntu 22.04 eFlasher imager image would be a breeze.

But something was wrong. The eFlasher utility would run, but the update progress was way too fast. I tried other eFlasher images and they all failed, but going back to FriendlyWrt would always work. I also tried to boot from a MicroSD image and the Windows USB utility but none of those methods would allow me to install Ubuntu 22.04 successfully to the NanoPi R6S.

I eventually connected a serial debug board to my NanoPi R6S and could see some partition and file system errors when booting the problematic images. I told FriendlyElec the FriendlyElec worked fine on my two samples, but looking at the logs and USB utility issue, they still suspected an eMMC flash issue and sent me another unit that was supposed to be preloaded with Ubuntu 22.04, but eventually came with the same FriendlyWrt image.

So I went through the same method to update the board and same issue… I tried various Debian and Ubuntu images, and going back to the FriendlyWrt would always work… The important part that I have not mentioned s ofar is that I’ve been using USBImager ever since I discovered the lightweight utility in 2020. I never had a problem until now, but it turns out it was the culprit… FriendlyElec shares their images compressed with GZIP, and if I uncompress the image with gzip before I flash it with USBImager, the eFlasher image installs Ubuntu 22.04 or Debian 11 just fine, and the OS can boot from the eMMC flash.

USBImager is supposed to support flashing compressed images, so I opened an issue on GitLab and the developer pointed out to me that the GZIP file format specification (RFC 1952) limits the size to 4GB because it is only stored in a 32-bit field. Indeed, if I open one of the gz files in Ubuntu, it will incorrectly show the size is 3.5GB, instead of 7.8 GB… gzip (mostly) ignores the reported size and uncompresses the entire file just to get the uncompressed size. That explains why the smaller FriendlyWrt image would work, but not the desktop OSes… The issue has not been resolved in USBImager just yet, but the important point is to uncompress any gz file before flashing it with USBImager, and board manufacturers should probably avoid compressing their files with gzip and use a more modern format…

It took me well over 10 hours to find out, but at least we can carry on with the review…

Ubuntu 22.04 system information

Let’s go through the usual system information:

Ubuntu 22.04.2 with Linux 5.10.110 kernel on a system with around 8GB RAM and a 25GB root filesystem partition

People interested in the Linux boot log can check it on pastebin.

NanoPi R6S benchmarks in Ubuntu 22.04

Let’s run some benchmarks starting with sbc-bench.sh:

No throttling occurred and the maximum temperature was 64.7°C during CPU miner in a room with an ambient temperature of around 27°C, so passive cooling works well. What’s less good are the results for 7-zip at around 14,500 against 16,200 to 16,400 rating MIPS on Khadas Edge2 and Rock 5B SBCs. The Cortex-A76 cores are clocked at 2316 and 2244 MHz (measured), so that’s not the problem, and we’ll explain what’s going on further below in this review.

The other results are pretty much the same as the other RK3588(S) platforms, and much faster than on Raspberry Pi 4.

Speedometer 2.0 was really disappointing in the Chromium browser:

The results are pretty consistent between runs and I repeated the test later and got 17.1 runs per minute…

Firefox is typically slower in this benchmark, but somehow not on the NanoPi R6S with Ubuntu 22.04 as Speedometer 2.0 was rendered at 41.3 runs per minute on Firefox 110.

There must be some issues with the Chromium configuration. In the Khadas Edge2 board with the same Rockchip RK3588S, I got 80.7 in Chromium and 53.12 in Firefox.

Storage testing and benchmarks

Let’s test the eMMC performance with iozone3:

The performance is rather good with 296 MB/s sequential read speed and 200MB/s sequential write speed and random I/Os look fine too.

In order to test the USB 3.0 (5Gbps) port, I connected the ORICO M234C3-U4 enclosure with an NVMe SSD as well:

340MB/s read and 400+ MB/s write speeds are rough as expected on a 5 Gbps USB port, although the read speed could be slightly improved.

Networking (2.5GbE)

I already tested 2.5GbE in OpenWrt, so I’ve only tested the WAN port with iperf3 in Ubuntu 22.04 to make sure there’s nothing odd going on:

• Download:

• Upload:

• Full duplex:

That’s pretty excellent except for some retries in full duplex mode.

SBC bench “review” mode

Thomas Kaiser has created a new “review” mode for SBC Bench in other to detect and/or fix some common issues and list key features of the hardware and software:

We can’t see it from the log above, but the warnings are shown in red:

In this case, the script switched from “ondemand” governors for the CPU, GPU, NPU, and RAM to “performance” governors for all. Note that it should deliver the best benchmarks, but it may not provide the ideal settings for all depending on whether you care about power consumption and/or battery life for your specific use case.

Once we see the lines with the time and CPU frequencies, we can run some of the benchmarks we’ve tried previously to see any differences. Let’s start with 7-zip:

We can see the MIPS rating “Total” is 16385 and the same as for Rock 5B and Edge2 SBC. Thomas told me it was because of the RAM configuration, and the ondemand governor at 528 MHz by default does have an impact on 7-zip performance.

I also checked the eMMC flash again:

Slightly faster indeed, but nothing dramatic.

Next up let’s test USB storage as well:

The write and read speeds were slightly lower somehow, and I could reproduce that with several runs.

While we are on it, I test full duplex iperf3 on the WAN port again:

No retries at all in the first run, but a few in the second like with default settings:

That speed was 2.35 Gbps in both directions. It could be luck, or because the PCIe ASPM (Active State Power Management) was set to “performance”.

Thomas mostly focused on headless use cases, but I also ran Speedometer 2.0 in Firefox to see if the new settings had any significant effects.

57 points is about 38 percent faster compared to the 41.3 points from my first run with the default settings. It’s now faster than the Khadas Edge2 (with default settings). There’s also an improvement with Chromium since it reached 21.8 points. It’s still 75% slower than on the Edge2 so no miracle here…

The review mode can also detect whether you have any issues with your storage device such as fake SD cards, worn-out drives, and so on. So at some point, I inserted a known fake micro SD card that had some issues and it was detected as a “Definite counterfeit APPSD” HD SD card and the script also pointed to errors in dmesg:

Note that the changes made by the review mode are not permanent, so if you reboot everything is back to normal, and that’s the way it should be.

3D graphics acceleration on NanoPi R6S

I could confirm the Arm Mali driver was loaded and operational:

The Mali driver is detected with the message “eglInitialize failed” which I also encountered with the Khadas Edge2 board, but it did not prevent me from running glmark2-es2-wayland, so let’s try it on the NanoPi R6S as well…

It does work well enough. Here’s the output from the terminal:

That’s 4525 points on NanoPi R6S compared to 4005 points on the Khadas Edge2. Note that SBC bench optimizations were still running, and I also switched the GPU governor to “performance” before running the graphics benchmark on the Edge2 board.

I installed SuperTuxKart on the board and the game was playable in windowed mode, but it’s unclear whether it ma does not seem to make use of the GPU at all:

llvmpipe should mean software renderer. So I set the graphics to full screen and 1920×1080 resolution, and it was indeed unplayable at probably 1 or 2 fps confirming the GPU is not involved here. SuperTuxKart is supposed to work on OpenGL ES hardware, but I don’t know how to fix this.

The wiki says graphics acceleration is enabled in Chromium… We can double-check that by typing chrome://gpu in the address bar.

WebGL and WebGL2 are indeed enabled.

And Arm “Mali-LODX” driver appears to be in use, so let’s check the WebGL aquarium demo.

The demo renders smoothly with 1000 fish at 60 fps, and it’s still good with 5,000 fish at around 30 fps.

If I go boost the number of fish to 10,000 fish and over, I can start to see some rendering issues with the fish only showing from time to time, and the frame rate is going down. But at least we can confirm 3D graphics acceleration is working in the Ubuntu 22.04 image, even in Chromium.

Video Playback

I did not have a lot of luck with video playback on Linux in my previous Rockchip RK3588(S) hardware reviews, but there has been some good progress. First, you may have noticed in the Chromium “GPU” screenshot above that “Video Decode” is enabled, and if we scroll down we can see Video Acceleration is supported for HEVC, H.264, VP9, and VP9 up to 3840×2160 resolution.

Let’s try a 4K video at 1080p60 first…

It plays well with no dropped frames, but how do we know it’s using hardware video decoding? The first clue is the power consumption: around 5.4W, while my power meter would typically fluctuate between 8 and 10W+ with software video decoding on other RK3588 platforms.

The wiki also explains we can use fuser while the video is playing to check whether the hardware video decoder is active:

If there is no content output from the fuser command, it means software decoding, but here there’s a value so VP9 hardware video decoding is enabled. If I close the YouTube page, nothing is returned:

Switching to 4K resolution (in YouTube) on the same display set to 1080p60 was no issue either.

So I felt confident, and decided to try a local 8K AV1 video from the command line:

It did not go well with audio cuts, plenty of dropped frames, and a choppy video. So I switch to a more traditional 4K H.264 video @ 30 fps:

No problem here. But the system can not handle 4K H.265 at 60 fps either:

FriendlyElec says Kodi is preinstalled and supports hardware video decoding. So let’s try so videos in Kodi 19.4 instead.

The info window appears to have changed, but the results are the same with the H.264 30 fps video playing fine, and the H.265 60 fps being unwatchable will too many dropped frames.

I’m happy to see progress has been made, but video playback still needs more work in Linux. As a side note, my wireless keyboard was not always responsive once I connected a USB hard drive to play the local videos. If I remove the hard drive, the keyboard works fine.

Power consumption

I’ve also taken some power consumption numbers. The NanoPi R6S is connected to an HDMI display, 2.5GbE networking, as well as two RF dongles for the keyboard and mouse.

Here are the numbers I got from the board with default settings:

• Power off – 0.9 Watt (That’s rather high and remains at this value even if I disconnect everything from the NanoPi R6S barring the power cable. If I do remove the USB power cable, the power meter shows 0.4W so it looks like the NanoPi R6S draws 0.5W while it is powered off)
• Ilde – 4.6 Watts
• 4K YouTube Video in Firefox (full screen – SW decode) – 9.7 to 11.3 Watts
• 4K YouTube Video in Chromium (full screen – HW decode) – 5.3 to 7.3 Watts
• Stress test on all 8 cores (stress -c 8) – 10.9 Watts

I also wanted to check to what degree setting everything to “performance” would impact the power consumption, so I repeated the measurements with sbc-bench.sh script running in review mode.

• Ilde – 5.4 Watts
• 4K YouTube Video in Firefox (full screen – SW decode) – 9.9 to 11.6 Watts
• 4K YouTube Video in Chromium (full screen – HW decode) – 6.6 to 8.6 Watts
• Stress test on all 8 cores (stress -c 8) – 11.4 Watts
• CPU Miner (part of sbc-bench.sh review mode) – 11.2 Watts

So there’s a cost to enabling performance modes of 0.3W to 1.2 Watts depending on the load, and whether it matters depends on your use case.

Summary

After a frustrating start unrelated to FriendylElec support, I finally managed to install Ubuntu 22.04 on the NanoPi R6S. The system works reasonably well and is stable as I had a 5+ days uptime at some point. Performance is excellent as on other Rockchip RK3588(S) platforms, and software support has further improved, but we are not to the point where we install Ubuntu and expect everything to work out of the box like on (most) x86 platforms.

3D graphics acceleration and video hardware decoding are implemented, but they may not work on all programs. It was nice to have VP9 hardware video decoding in YouTube and WebGL demos working smoothly on Chromium. I did not have issues with 2.5GbE networking and the internal eMMC flash is fast making the system fast to boot and responsive. The metal enclosure is good enough to cool the fanless system under all loads I tested. Some of the issues include Chromium reporting an unusually low score with Speedometer 2.0, and the power consumption looks higher than on other systems.

I’d like to thank FriendlyElec for sending NanoPi R6S samples for review. The model reviewed here sells for $139 plus shipping on the company’s store, but you’ll also find it on Amazon and Aliexpress from resellers.

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