Orange Pi PC2: A 64bit gremlin? // Review

(Reading time: 8 mins)

Watch "Orange Pi PC2: A 64bit gremlin? // Review" on YouTube.

YouTube video: Orange Pi PC2: A 64bit gremlin? // Review

So, yet another Orange Pi board called the PC2. It’s sporting the new 64bit quad core Allwinner H5 MCU. Is this really a good idea?

As you’ll find out in this video, things aren’t always what they seem. There’s a number of issues that have yet to be fixed and Orange Pi are relying very heavily on the community to fix them. Unfortunately, Allwinner aren’t being too helpful on the H5.

Un-boxing

So, here we have the brand spanking new Orange Pi PC2. This is one of the very few boards to be running the new Allwinner H5 SoC.

The H5 is a pretty impressive chip running a 64 bit quad core Cortex A53, with floating point unit, and also the Mali450 which is a 6 core GPU. It should leave skid marks on your desk, but as we’ll find out later there are some issues.

It has other cool stuff like an array of memory interfaces, 3 SD or MMC controllers,

high speed timers, RTC, 12 DMA channels, PWM,

temperature sensor, (which is critical these days on fast CPUs), spinlocks, crypto engines,

UARTs, SPI, I2C. Essentially everything you will need in a common garden variety small MCU these days.

So, what do we have on this Uber board from Orange Pi?

on the flip side there’s just a bunch of passives and the SD slot.

Read on for more…

Booting up

Finding the right O/S image to use is, of course, a bit hit and miss. They have a decent quick start guide, which is a little dated, but you can follow it easily enough.

I wanted to try several images out; Android, which I can actually download from Google Drive and if you spend a bit of time searching you’ll find an official Linux image that’s more recent. So I fetched Ubuntu Xenial. I also fetched Armbian, even though there isn’t an official image for it yet.

Wrote it to an SD card using Etcher and chucked it into the SD slot… spent the next 5 minutes looking for it on the floor somewhere and finally putting it in.

Then, of course there was the usual keyboard and mouse, Ethernet, HDMI, and my testing hard disk on the second USB port. Don’t be tempted to power it up using the micro USB, because you won’t be able to. Just use the DC jack and then power up.

Then you’ll see a desktop in around 30 seconds. I did have a bit of trouble getting it going with my Elgato HD60S recorder, but managed to coax it into action. When I actually tried to start using the desktop, things went downhill even further.

If you watch the video, you’ll see my trying to maneuver the mouse around trying to open up a basic terminal. Man, that’s a world record for sluggishness.

If you have no display, check your router for a DHCP IP address. Login and go through the usual Armbian configure script.

The H5 MCU has dynamic frequency scaling, which we can access from the Linux /sys interface. You have ranges from 120MHz all the way up to 1.3GHz. You also have access to the MCU temperature sensor.

The H5 is very similar to the Pine64 and we’ll find out later how it performed in comparison to that. As of this video release Armbian was running kernel version 4.10. One other nice of this kernel version is the statistics on how long the CPU spent in the various frequency speeds.

In all my tests I log as much as possible so I can correlate the data. On Armbian based O/S I use socat to redirect the output of Armbian Monitor so that I can log it from my Mac. It’s a very simple way of logging without running the risk of losing any data.

CPU frequency scaling: /sys/devices/system/cpu/cpufreq/policy0/ CPU temperature: /sys/devices/virtual/thermal/thermal_zone0/temp

socat -gx TCP-LISTEN:1234,fork,max-children=10,reuseaddr EXEC:"/usr/bin/armbianmonitor -m" &

Read on for more…

Basic GPIO tests

So, on to some basic GPIO tests. We seem to have a I2C, UART and sound device files, but no infrared or SPI. Hmmm.

There’s also the on-board LEDs and of course the keyboard LEDs work. Yup, they work OK. No surprises there.

The PC2 is almost identical to the Plus 2, but for a couple of changes. These are PD11, PC5 and PC6. I went through and double checked them all, and yup they were indeed connected.

/sys/class/leds/orangepi:green:pwr/brightness
/sys/class/leds/orangepi:red:status/brightness
/sys/class/leds/input1::capslock
/sys/class/leds/input1::numlock
/sys/class/leds/input1::scrolllock

Read on for more…

I2C tests

Next on to I2C testing. I installed the missing i2c-tools package and found one of the I2C buses, but note there should be more than one. There was only one device on this bus

which turned out to be the PMIC. So this was bus 0, but none of the other buses were there.

Just to confirm I hooked up my I2C based temperature sensor. Unfortunately, the I2C buses haven’t been enabled and all I was able to do was just use that pin as a normal GPIO.

So I dumped the device tree database and searched for the I2C definition, which turned out was disabled. So I enabled for both buses, saved the database and rebooted.

But no dice. Clearly there’s a lot of work still to do. It’s starting to look a lot like the Pine64.

cp /boot/dtb-4.10.0-sun50iw2/allwinner/sun50i-h5-orangepi-pc2.dtb /root/backup.dtb
 dtc -I dtb /boot/dtb-4.10.0-sun50iw2/allwinner/sun50i-h5-orangepi-pc2.dtb -O dts -o /tmp/foo.dts
 vi /tmp/foo.dts
 dtc -I dts /tmp/foo.dts -O dtb -o /boot/dtb-4.10.0-sun50iw2/allwinner/sun50i-h5-orangepi-pc2.dtb

SPI tests

The same can be said about the SPI bus. There’s one there, but that’s for the SPI flash. I tried enabling it in the device tree database, but once again… nope.

UART tests

However, there’s a bunch of UARTs on-board. so, I attached my logic analyzer up to it. Wrote out some appropriate text.

and yup. All happening there.

Sound tests

What about sound? Well, nope sorry, not working there either.

Power on/off

By the way; powering off the PC2 is a bit of hit and miss. Sometimes it does, and sometimes it doesn’t. Murphy’s law kicked in here and I never recorded the “not powering off” state. However, if it does power off successfully, you can’t power it back on again.

Read on for more…

Ubuntu Xenial

So, I think I need to try another O/S here. I tried the official image to see if it’d work any better. Seemed to boot up without issue. Going well so far, but we’re running an older kernel version, and no I2C, SPI, or infared. Man this is abysmal. However, the audio devices are there.

So does the onboard mic work? Yup, OK. Something does. Nice. We seem to also have access to all the dynamic frequency scaling on the MCU.

I tried enabling SPI in the device tree, but nope.

Android testing

OK. I’ve had enough of this. Something has to work on this board. Let’s try the Android image.

OK. So booting up was pretty quick, but not the world’s most usable O/S. Unless, of course, you are bilingual.

Network tests

Moving back to Armbian, I started doing some performance tests. It was doing extremely well for TCP throughput at close to the theoretical limit

and UDP jitter was very low as well. Nice that something works well!

Server: iperf3 -Vs -f m -i 5
Client(TCP): iperf3 -V -c 10.0.0.46 -f -n -R -t 120 -i 5
Client(UDP): iperf3 -V -c 10.0.0.46 -f -n -R -t 120 -i 5 -u

Read on for more…

Phoronix Performance Tests

So, before I start bashing this board with performance tests I need to attach my Uber heat-sink somehow. So, a bit of electrical tape and my patent pending aluminum heat transfer thingies will do the job.

There we go! Suitable for my testing but not for anything. Powering up the board showed a marked drop in temperature when idle. Moving from the 65 degree average down to around 37 degrees Celsius.

So after a couple of days of testing the results are in!

As expected the PC2 matched the Pine64 on performance fairly closely. There were a few surprising variances such as with John The Ripper and parallel bzip compression, but all in all it was a close match. Note that these tests were performed with my Uber heat-sink on the PC2, whereas the Pine64 had no heat-sink at all. So the Pine64 had some pretty decent thermal dissipation.

The PC2 is a pretty speedy board, being faster than all of the Orange Pi and Nano Pi boards.

For comparison, I wanted to see how it’d perform without the Uber heat-sink and just a small fan and copper heat-sink.

I ran the SmallPT test again as this test pushed the temperature to the max with the Uber heat-sink.

Using just that small copper heat-sink saw the test move from 811 seconds to 1031. A 27% drop in performance. So, the bigger the heat-sink the better.

You can find all this data on the openbenchmarking.org website.

I have to say, this was the most troublesome board I’ve looked at so far. Well, there’s the Pine64 but at least that had a working Android O/S. Half way through my testing I was actually thinking of just putting up an 8 minute video with the words, forget it.

I’m not even going to bother rating this one, at this stage there’s so many things that aren’t working. I have a strong feeling it’s going to go the same way as the Pine64.

The H5 is actually a pretty decent chip, but Allwinner aren’t being helpful at all with data, so it’s probably going to die a slow death. Shame really as this board could be a real doozy. Read on for more…