NanoPi NEO4: Smallest RK3399 SBC. What is real, NEO? // Review

(Reading time: 10 mins)

Watch "NanoPi NEO4: Smallest RK3399 SBC. What is real, NEO? // Review" on YouTube.

YouTube video: NanoPi NEO4: Smallest RK3399 SBC. What is real, NEO? // Review

The NanoPi NEO4 is probably the smallest RK3399 based SBC on the market currently. Does it have enough to take on the competition? Find out in this video.

Unboxing

The NanoPi NEO4 is currently the smallest RK3399 based SBC on the market. As you’ll soon see, it’ll keep that title for a while yet.

Topside

So, what have FriendlyARM crammed into this tiny 60 by 45 mm board?

NanoPi NEO4 (Hover over items for more info.)

I2S header
GbE
RTC battery header
USB2.0 and USB3.0
and an additional USB2.0 header
debug UART
eMMC socket
HDMI capable of 4K @ 60Hz
USB Type C, which is the best way of getting juice to this board
Power LED
Status LED
external antenna header
MIPI-CSI
and a 40 pin header with the first 26 pins Pi compatible with 3.3v tolerant logic levels and the second half providing a PCIe interface.
The unfortunate thing about this header is that it has 1mm pitch pins and there’s no adaptor board yet selling on FriendlyARM. So you’re out of luck using a typical breadboard with this SBC.

Semi-conductors

On the semi side, we have.

6 Channel ESD protection for USB Type C - TPD4E05U06

Programmable USB Type C controller accessible over I2C, which is also used on the NanoPC-T4 & Khadas Edge - FUSB302B

There’s a heck of a lot of 0201 components on this board. They had to given the size of the thing.

24MHz crystal driving the RK3399 SoC and WiFi module based on the AP6212.

There’s a crazy amount of 0201 components. These are .6mm lengthwise. Tiny!

Dual channel LDO regulator supplying 3.3v from a 5.5v input at up to 300mA each channel - RT9011-CMPJ6

MoSFETs for controlling power to the SoC.

DC to DC converter for the GPU accessible over I2C - SYR838PKC

The underside

Moving to the underside we have…

SD slot

LDO regulator providing 1.8v to the SoC from a 3.3v supply at up to 500mA - RT9041B-10GE

High efficiency PWM step-down DC converter providing 0.9v from the 5v DC supply - RT8010GQW

An unknown component.

25MHz crystal for the …

GbE transceiver, (RTL8211E), and more of these 6 Channel ESD protection ICs, (TPD4E05U06).

One half of the 1G RAM.

And the unavoidable RK808 PMIC, which is present on almost all RK3399 based SBCs.

2A slew controlled load switch, which operates within a 2.7 to 5.5v DC supply and controls USB voltage output - RT9724GQW.

Oh and look! More 6 Channel ESD protection ICs, (TPD4E05U06)!

But I wasn’t able to figure out what this one was, let me know in the comments below if you find out.

DC buck converter providing 3.3v at up to 3A from a 5v input, which is interesting as the manufacturer has declared this part obsolete - MP2143DJ.

and… even more ESD protection… what else.

and also the RK3399 SoC, which is underneath for a change.

The FriendlyARM design

One thing I’ve been noticing with FriendlyARM is that there are a heck of a lot of common parts across all their SBCs and every part has it’s own unique label.

So, for example U28 on the NEO4, which is the ESD protection IC for the USB Type C port is identical on the NanoPC-T4.

Or U8, which is the PMIC, is… yup the same.

Comparing the size of this SBC to several others, you can see FriendlyARM have packed a lot into such a little space.

FriendlyARM provide a pretty chunky milled heat-sink, which has a fair amount of thermal mass to it.

They also provide their blue spongy heat-sink goop which frankly is not that good.

Well, it’s good enough, but if you want to really avoid thermal throttling issues, then a better fitting heat-sink with thermal paste would be ideal. I actually prefer having the SoC underneath. This makes it a more sturdy setup overall but I know some of you don’t like this.

While I was screwing the heat-sink in, I did hear some small cracks from the PCB. Like a lot of mass produced PCBs, they make them as thin as possible and this one comes in at 1.2mm, but it didn’t seem to affect anything.

I also purchased an eMMC module along with SD card adaptor, so I could test out eMMC booting.

The power pack is pretty chunky. 5v at 4A is a fair amount of juice to be pushing down some thin cables. I would have preferred to see a 12v DC supply as the lower voltage and higher current causes all sorts of issues with connectors.

As in all my reviews, I log both voltage and current using a power logger.

eMMC Booting

So first of all I tried the default FriendlyARM image running on eMMC.

Both demo videos played back without any jitter, which is nice to see that we’re seeing some work being done on getting graphics speeds up to par.

Armbian Booting

Instead of dwelling on the default FriendlyARM image I moved over to an Armbian image, just to see how things were progressing there.

However, one of the annoying things about this SBC is the placement of the SD card slot. It really is quite difficult to get access to it once everything is plugged in.

Even unplugged, it’s a tight fit.

Once booted from SD card, login to run through the final configuration and the desktop should start up in a couple of seconds.

Idle performance

I left it on idle for around 30 minutes to establish a baseline.

The temperature sat around the 53 C mark, with a variance of only + or - 2C.

Max: 55.6 C
Average: 53 C
Min: 49.4 C
The external heat-sink temperature had a maximum of 43.8 C next to the SoC and 39.5 C on the other side. This was with an ambient room temperature of 32.1 C.
The average load during this time was around 500 mA with a peak of 1.757 Aand the board shuts down to around 2 mA quiescent current, which is what I’ve seen on most RK3399 based SBCs so far.
Max: 1.757 A
Average: 500 mA
Min: 2.1 mA
I then ran it through some basic benchmarks to see how much the temperature would rise when under load. Igor Pavlov’s 7-Zip compression benchmark raised the core temperature to 70.6 C. A bit of a rise in a short length of time.

Temperature

Max: 70.6 C
Average: 52 C
Min: 38.8 C

Current

Max: 2.173 A
Average: 532 mA
Min: 2.1 mA

Interestingly, changing the frequency scaling to performance mode saw it rise by 3 C as compared to the on-demand mode.

Heat-sink issues?

This heat-sink does have a lot of thermal mass to it and it does get toasty.

Like anything in engineering a heat-sink isn’t just a heat-sink and there are a lot of factors you need to take into account, like thermal resistance, fin efficiency, spreading resistance, interface materials… It’s not just a matter of chucking a huge lump of copper onto silicon and hope for the best.

However, the problem with this heat-sink is, I suspect, poor fin efficiency. It would be great if FriendlyARM made a similar profile heat-sink with inbuilt fan.

So, I have one of my handy dandy fans that I ripped of something, somewhere. It’s not elegant, but I was getting a much better airflow over those NEO4 heat-sink fins.

So, the heat-sink near the SoC dropped to 36.1 C and on the other side 33.3 C.

Nice. That was just a couple of degrees above room temperature. This drop also reflected on the SoC, where it went down to 39.4 C on idle.

For my regular viewers, you’d know that where I live things get a bit toasty in the summer. So, “room temperature” is around 30 C to 35 C. This last week we saw temperatures hit 49.5 C.

Just warm enough to take off my jacket.

Graphics Tests

So on to some graphics tests.

When I was reviewing the NanoPC-T4 and Khadas Edge SBCs one of the problems I ran into was the poor graphics performance.

So, has the RK3399 graphics driver improved since then?If you’re running Armbian, which I strongly suggest, there’s a forum post linking to a script that provides full VPU acceleration. Which means that you should be able to run 4K video at 60Hz among other things.

I saw a pretty decent video playback of plain 1080P H.264 encoded video, which was great even for a non RKMPP version.

The RKMPP playback will, of course, not use X windows as slightly faster.

However, when we move to a 4K 60FPS video, things get a little shaky with frames being dropped constantly. I suspect that was because I was pulling data from eMMC and down-sampling to 1080p. So still pretty decent for what it was doing.

4K Video Tests

So, I needed to test on a 4K display. Fortunately my son had just bought one, but it was a cheap one and didn’t respond properly to EDID requests. This is a fairly easy thing to fix.

Search for the right mode-line entry in the /var/log/Xorg.log file and copy that. Then using xrandr, create a new mode:

xrandr --newmode "3840x2160"x0.0 297.00 3840 4016 4104 4400 2160 2168 2178 2250 +hsync +vsync

which should show up in the available modes.

Add it to the HDMI-1 interface…

xrandr --addmode HDMI-1 "3840x2160x0.0"

and make it active…

xrandr --output HDMI-1 --mode "3840x2160x0.0"

So, I’m still seeing dropped frames on a 4K video.

Switching to another video I saw the same issue, and yes, before you mention it…

I did have composite disabled, but…

it seemed that I had to fully disable it in the xorg config file and restart.

Once I changed that a 4K video played back at 1080p saw no dropped frames. Although the video was a little noisy for some reason.

Moving to full 4K playback saw a similarly smooth but noisy video.

Of course, playing a video within an X desktop window was still… bleargh. Apart from that, full screen 4K video playback is looking pretty good.

Phoronix Tests

Next on to Phoronix tests. I didn’t run a huge amount of tests this time, because really the NEO4 SBC design is pretty similar to the NanoPC-T4.

So, I ran a couple of benchmarks for graphics, languages and CPU load.

GLmark2, OpenCV.
GoLang, Perl, Python, PHP.
SmallPT CPU & GPU.

… and what did I find out?

Well, I had some pretty interesting results.

First of all GLmark2 ended up being on par with the ODROID-XU4, but I would have expected to have been a lot better.

While OpenCV was slightly better than the Rock64.

The SmallPT GPU benchmark showed a fairly similar result to the NanoPC-T4, which was expected.

But, the language benchmarks made the NEO4 shine again,

with GoLang tests coming in just behind the LattePanda Alpha.

The interesting thing about these benchmarks is that the default NanoPC-T4 heat-sink does a pretty bad job of keeping the SoC cool. I would have expected it to be almost on par with the NEO4.

All the other benchmarks were identical to the NanoPC-T4. You can check them out on the Open Benchmarkiing website.

One thing is for sure. If you’re running PHP, the NEO4 is the best SBC to be running. So another tick for a pocket server.

During all these benchmarks, I saw a fairly predictable SoC temperature and current draw.

Temperature

Max: 65 C
Average: 45 C
Min: 36.2 C

Current

Max: 2.521 A
Average: 933 mA
Min: 464 mA

GPIO

This time around I didn’t do any GPIO tests, but will save that for a comparison video across several SBCs. So stay tuned for that.

Summary

So, what do I think of the smallest RK3399 SBC?

Like all FriendlyARM SBCs, you’re getting some decent quality for the price and since they are listening to Makers' comments on what to do right, they are one of the better SBC companies around.

The size is great, but that 1mm pitch GPIO header is a bit of a bugger. However, with a small adaptor PCB breaking out the PCIe signals this would be a great pocket server.

That heat-sink is a little too chunky and needs a fan, but apart from that it’s a well designed PCB.

There really is no room left to add any more components.