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.
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.
Read on for more…
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.
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.
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.
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.
socat -gx TCP-LISTEN:1234,fork,max-children=10,reuseaddr EXEC:"/usr/bin/armbianmonitor -m" &
Read on for more…
Basic GPIO tests
There’s also the on-board LEDs and of course the keyboard LEDs work. Yup, they work OK. No surprises there.
/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…
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
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
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.
However, there’s a bunch of UARTs on-board. so, I attached my logic analyzer up to it. Wrote out some appropriate text.
What about sound? Well, nope sorry, not working there either.
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.
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.
OK. I’ve had enough of this. Something has to work on this board. Let’s try the Android image.
Moving back to Armbian, I started doing some performance tests. It was doing extremely well for TCP throughput at close to the theoretical limit
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.
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.
I ran the SmallPT test again as this test pushed the temperature to the max with the Uber heat-sink.
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…
U5 / SY8008B voltage regulator / CI https://forum.armbian.com/index.php/topic/2869-armbian-for-orangepi-pc2-allwinner-h5/page-8#entry25735
Mismatch between below pin mapping and those according to schematic. http://linux-sunxi.org/Xunlong_Orange_Pi_PC_2
No hardware video accel, Mail driver, HDMI audio out.