NanoPC-T4: No room for anything else. // Review

YouTube video: NanoPC-T4: No room for anything else. // Review

In this article I’ll be taking a look at the newly released NanoPC-T4 from the friendliest SBC makers on the market. I’ll be running through the usual lineup of tests that I do, but I reckon this board deserves two articles. So, this is Part 1.

ERROR:not .src - map[alt: class: control: ctx:0xc004d4b400 height: href: id:i2TUYN5y-ps inline: size: span: src: style: thumbnail: title: width: xml:]


The NanoPC-T4 is yet another SBC based on the RockChip RK3399 SoC.

In the past we’ve seen the AllWinner A80, Samsung S5P6818, HiSilicon Kirin960 and others, but they are all suffering from the lack of Linux driver support, especially when it comes to graphics. However, the RK3399 is one of the better supported 8-core SoCs around.

So, what does the new NanoPC-T4 give you? Starting from the top right working clockwise, we have …

  • A DisplayPort output
  • PWM controlled fan output
  • Boot & recovery buttons
  • 2x USB2.0 host ports
  • HDMI 2.0 out
  • MIC
  • Audio Out
  • USB 3.0
  • GbE
  • 12v 3A DC jack
  • Reset button
  • USB TypeC that provides another DisplayPort out, but you can’t power the board from it
  • RTC battery header
  • Console UART
  • A second MIPI-CSI1
  • As well as a MIPI-CSI2 header
  • Power button
  • LEDs for power and status
  • WiFI & Bluetooth external antennas
  • Micro SD slot
  • An almost compatible Raspberry Pi GPIO header
  • And some extra ADC header pins thrown in. When I say “almost compatible” this is due to the fact that the last 14 pins have GPIOs that work on 1.8v logic levels.
    Also, even though power and ground pins match up to the Pi, the GPIO functions don’t quite match up. So, forget using most of the Pi hats on the market.

In terms of semis on the board, we have …

  • U19 - RTL8211E - GbE transceiver.
  • U30 - AP6356S - WiFi/Bluetooth module.
  • U12/U40/U41 - RT9724GQW - MoSFET switch.
  • U29 - ALC5651 - Audio CODEC.
  • U8 - RK808 - PMIC
  • U10/U11 - RT8010GQW - RT8010/A is a high efficiency PWM step-down DC/DC converter.
  • U15 - NB680GD - 26v to 3.3v/8A DC buck converter.
  • U16 - NB679GD - 26v to 5v/8A DC buck converter.
  • U2 - RT9193 - Battery optimized 1.8v LDO.
  • U38 - SYR838PKC - DC to DC converter.
  • U28 - FUSB302MPX - USB TypeC controller.
  • U94 - TXS0102DCU - I2C logic level converter.
  • U27/U31 - TPD4E05U06 - ESD protection.
  • eMMC flash
    On the flip side we have an M.2 key slot and other semis like a USB TypeC controller, I2C logic level converters and ESD protection.

This board is a pretty decent design. There’s an adequate amount of ESD protection and all the required PMIC control for the RockChip SoC is there. It’s so densely packed, I doubt you’d be able to fit anything else on.


Several years back the FriendlyARM guys weren’t that good on documentation, but they have improved a huge amount since. Their wiki website has pretty much everything you need to get started and hack around with this SBC.

For my tests I will be trying out several Linux distro images as well as Android, but for this video I used the official Ubuntu desktop image.
There’s several ways of loading up the eMMC flash with an image. I chose to use the RockChip loaded tool, which uses the USB TypeC port.
If you’re running a 64bit O/S, then you may need to install the required 32bit libraries.
Once installed properly, extract the boot image files.
Next connect up the USB TypeC port to your PC and DC jack. Then you’ll need to hold down the Recovery button and press the power button.
This will put it into recovery mode, and you should see it appear on your PC like this.
You’ll need to burn the image files in the correct order using these commands.

upgrade_tool ul friendlydesktop-arm64/MiniLoaderAll.bin
upgrade_tool di -p friendlydesktop-arm64/parameter.txt
upgrade_tool di uboot friendlydesktop-arm64/uboot.img
upgrade_tool di trust friendlydesktop-arm64/trust.img
upgrade_tool di resource friendlydesktop-arm64/resource.img
upgrade_tool di kernel friendlydesktop-arm64/kernel.img
upgrade_tool di boot friendlydesktop-arm64/boot.img
upgrade_tool di rootfs friendlydesktop-arm64/rootfs.img
upgrade_tool RD

Then power off and connect up HDMI, keyboard/mouse and Ethernet. Then press the power button.
I reached a fully working desktop in around 10 seconds. Pretty good going so far.

So, checking out a few things first…

I2C yup. Alas no SPI, and GPIO access is there with 159 GPIOs available on the SoC, but only a handful available to the user.
Thermal zones and frequency scaling - check.
And you have full PMIC access to control voltages around the board.
So, on to testing. For this initial test, I used the default heatsink, which isn’t really adequate enough.
And connected up WiFi and Bluetooth antennas. I also used my handy power logger to track power usage during testing.
The wall-wart that comes with the NanoPC-T4 has a pretty long cable. About a meter long and the wires themselves aren’t that thick, so there would be a fair amount of voltage drop over that length. However, I didn’t see any power issues during testing. So, they seem to have that under control.

GPIO tests

Moving on to GPIO tests.

Yup, my basic LED flashy thing worked without issue, but it was a little tricky mapping out all the GPIO pins on the header. If you want to know this mapping, check out my website.
For I2C tests, this time I used a TSL2561 Lux sensor, which of course worked OK.

The RK3399 does support parallel RGB output, but not all the signals are pushed out to headers. So, unfortunately I couldn’t test my PiProjector with it.

Quick tests

Before I launched into the full on testing I ran a couple of simple tests just to see what to expect.

For the M.2 speed tests, I used a run-of-the-mill 256GB SSD.
Alas, the NanoPC-T4 doesn’t support half length cards.
Then I formatted the SSD with the ext4 filesystem directly, without making any partitions.
Running the Armbian 7-zip test on the SoC, came up with a fairly respectable result.
While the GbE showed up a real-world 700Mbps throughput on TCP and a pretty low UDP jitter.
And WiFi saw 8Mbps on TCP and 12mS jitter.
Subjective desktop tests were OK, keeping up with a full 1080p YouTube video stream. Playback of one of my H264 encoded videos was very sluggish and of course, playing back a full 4K video was as slow as a wet week.

However, playing back the demo video that came with the FriendlyARM distro was fine.

Checking out the Armbian forums, it turns out that someone has managed to get full 4K video playback going without issue. So, I’ll need to follow this up in the next video.
Before moving on to the full tests. I noticed that the GbE would drop out occasionally. This usually happened when saturating the NIC with data.

So, there’s a few things that still need to be sorted out on the software side.

Phoronix tests

So after running a battery of Phoronix tests over a week, what results did I see? You can check these results out on over here and here. With a huge side-by-side comparison here and here.


GLmark2 was roughly 27 times faster than an ODROID-XU4. I couldn’t find any ARM based OpenCV tests for comparison, but the NanoPC-T4 is around 4 times slower than the nearest high-end desktop.


Memory speed tests showed it out-performing everything else on CacheBench reads, but slowing down on writes.

The NanoPC-T4 was always at the top on RAMspeed tests, occasionally being pipped by the UDOO X86.

Which the Stream benchmark showed up a similar result.

As well as the Tinymembench test, being pipped by the Jetson boards.


System tests like the Apache benchmark showed it to out-perform at least the ODROID-XU4 and was regularly beating all other SBCs except the Jetson boards.

While the Stress-NG tests showed the ODROID-XU4 coming out way on top for certain results. I really wouldn’t want to use the T4 as a desktop replacement, because it regularly appeared to be 1/10th the performance of a mid-range desktop.


Computation tests had a mixed bag of results. Mostly coming out on top, but the slow cache write speeds seem to let things down.


I was surprised with the kernel compilation results. Having 4 more cores than the Raspberry Pi should have made it much faster.


Moving on to language benchmarks, the T4 was outperfoming everything again on GoLang, especially on the all-important garbage collection test.

Perl had the same result as well as PHP and Python.


Video decoding benchmarks puts the T4 on par with the ODROID-XU4 at least.


And database benchmarks puts the T4, once again, back on top, being beaten by the Jetson SBCs.

Overall the NanoPC-T4 out-performed every SBC except for the Jetson boards. The 8cores are great to have, but we saw that the RK3399 SoC was being let down by cache write performance. So, on to power consumption.

Power usage

On the power side of things, I saw a max current draw of 1.12A with an average of 514mA during testing, with an idle of 417mA.

Bear in mind that this is at 12v, so it’s a bit on the high side, even for idling.

The SoC temperature rose to 91.7C with an average of 64 and an idle of 51C.

So, clearly the SoC needed a much better heat-sink.

In fact, I should have put the board on something else, as it damaged my desktop due to the heat.

  • PhoronixRun2Power (current) Max: 1120.4 Average: 417 Min: 0
  • PhoronixRun2 (temperature) Max: 91.7 Average: 64 Min: 50
  • PhoronixRun3 (temperature) Max: 70.6 Average: 57 Min: 51.1
  • PhoronixRun4 (temperature) Max: 75 Average: 65 Min: 53.9
  • PhoronixRun4Power (current) Max: 930.7 Average: 514 Min: 300.6
  • Combined (temperature) Max: 91.7 Average: 64 Min: 50


So, the NanoPC-T4 looks like a pretty decent SBC. A little pricey, but you’re getting a fair amount of features for your money and most of the time it beats all the other SBCs out there.

On the downside:

  • It’ll be a while before we see some decent stock graphics drivers, especially 3D related.
  • FriendlyARM should really have given the option of powering the board from USB TypeC.
  • The lack of support for smaller M.2 cards might be an issue for some. So, that wraps up Part 1 of this review. Stay tuned for Part 2.


Mick Hellstrom avatar
About Mick Hellstrom
Hacker. Maker. YouTuber.

MickMake forums