The ODROID XU4 is one of the few octo-core SBCs, that’s been around for a while now, but how good is it?
ERROR:not .src - map[alt: class: control: ctx:0xc00bce7e00 height: href: id:svQr3tfsFuE inline: size: span: src: style: thumbnail: title: width: xml:]
The ODROID XU4 first hit the shelves in May 2015, and it’s only seen a couple of minor HW changes since. So, the design is pretty decent and a large fan-base has developed behind it.
I ordered the XU4Q, which is exactly the same as the XU4
, but with a fan-less heat-sink and, of course, a slower CPU clock.
So, what does this little baby give us? Starting from the right and working clock-wise:
Dual USB3.0 ports
30pin GPIO header with the usual compliment of GPIOs
An additional 12pin GPIO header, the GPIOs on this board have issues, which we’ll see later
eMMC or SD boot selector
HDMI capable of 1080p @ 60FPS
Micro SD slot
Status and power LEDs
- 5v/4A DC jack
- USB2.0 port
- PWM controlled FAN
- and GbERemoving the heatsink shows up a pretty well designed board.
- We have an RTL8153, which is a USB 3.0 to GbE bridge (U14)
- USB ESD protection IC (U13)
- a USB hub using the GL3521 (U10)
- 512Kbit SPI NOR flash (U11)
- A nice juicy PMIC, (S2MPS11B2).
- and the octo-core Samsung Exynos using the big.LITTLE architecture with 4 cores running at 2GHz and the other 4 at 1.4GHz.
- Then there’s HDMI ESD protection
- power good signal circuitry
- and current limit switches for the USB ports.On the flip side we have:
- eMMC module header
and a bunch of passives and protection ICs.
The amount of vias on this board is crazy. To reduce EMI emissions, they’ve placed a ground plane on the top and bottom layers.
The ground plane is one of the most important layers and this type of setup avoids ground loops being formed, which is a way of saying that two points on a PCB should be at zero volts, but they’re not. One may be at a slightly higher potential than the other, therefore causing current to flow in directions you don’t want it to.
So, all in all, this is a pretty well designed board, with lots of ESD protection, adequate grounding, and a crazy amount of control over voltage levels.
In terms of size, it’s roughly that of the Raspberry Pi
. Just slightly bigger.
On the documentation side, it’s one of the best documented SBCs around. They have info on RAM & CPU overclocking, booting and bootloader recovery, schematics and general hardware info. Nice.
For my tests I used the best Linux distro for this SBC, which is Armbian
From power on to network activity I saw around 22 seconds with the desktop coming in 3 seconds later. Not bad.
As of this writing, the ODROID XU4
image runs the latest kernel - 4.9.71
. Nice to see.
Which means that everything is there, CPU frequency control and remember all those PMICs I mentioned? Yup, you have access to pretty much all voltage levels on the board.
Throughout all my testing, I kept track of the current CPU loading and temperature and also logged current and voltage levels.
So far the board looks pretty good. However, when we get on to GPIO testing, things change slightly.
First of all, the GPIO header pins aren’t a standard 2.54mm pitch, but 2mm. This means that standard jumper cables will be too big to use.
Secondly, the GPIOs use a 1.8v logic level. So, you’re going to have to use logic level converters. This isn’t quite straightforward as a lot of logic level converter ICs have trouble with fast signals, such as SPI.
If you want to be able to hack around with the GPIOs on this board, then I suggest also buying the Shifter Shield PCB from HardKernel
. As this not only provides logic level converters, but pushes out a standard 40pin GPIO header.
The Samsung SoC has a huge amount of GPIOs. Far more than are pushed out on this SBC. However, HardKernel
have provided a wiringPi compatible API which you can fetch from github
and build an example.
See?! Blinky blinky.
We also have I2C and SPI available. Since I didn’t order the Shifter Shield
I had to wire up my own logic level converter.
I used an MCP9808
temperature sensor to test out I2C and just used a handy heat source to change the temperature. Yup, everything just works.
Moving on to the Phoronix tests.
I initially installed the armsoc exynos graphics driver from the Ubuntu
repos, but I soon discovered this wasn’t the best idea.
On the x11 performance tests, I was initially getting between 1/20th and 1/40th the performance of the TinkerBoard
, which is not really what it should be doing.
Doing some Googling around, apparently this is a common error.
So, I removed it and the results were more inline with my expectation.
However, this is just 2D graphics and 3D graphics was reporting software rendering. So a lot of the 3D graphics results were skewed.
So, after running tests over 4 days, what results did I see?
GLmark2 results were to be expected as I wasn’t using any 3D graphics driver.
RAMspeed benchmarks generally sat amoungst a bunch of 64bit boards, but being regularly beaten by the UDOO X86
. Except for the floating point results.
Stream tests were abysmally bad for some reason, but when it came to CacheBench it was top of the game. So, a real mixed bag of results.
Moving on to networking, iPerf showed up a pretty abysmal 570Mb/s.
And local loopback was bleagh.. and yes, that is a technical term. Actually it wasn’t too bad. Not as bleagh as the GbE tests.
The stress-ng tests showed it to be leaps and bounds better than the Rock64
, but I couldn’t find any other recent test results on openbenchmarking.org
including other SBCs.
Moving on to some computation benchmarks. I saw the XU4
to scream ahead of everything else, due mainly to it’s 8 cores.
It was unbeaten on all the tests, until it came to the small-pt tests, where it was just nudged by the UDOO X86
Moving on to compression and encryption benchmarks, it was just nudging the UDOO X86
in the Bork benchmark, but lagging behind in the parallel BZIP2 benchmark, which was pretty surprising.
So, once again a bit of a mixed bag.
When it came to compiling, the XU4
came out on top once again, due to it’s 8 cores.
The Go benchmark was, at least, screaming ahead of the Rock64
and PHP was leaving everyone else in the dust.
Moving on to power consumption.
I saw the initial boot and idle test coming up with a 3A peak current draw, with an idle of 786mA. That’s one of the largest current draws I’ve seen on all the SBCs I’ve tested so far.
During testing the average was hitting 2.4A, with a max of 3.2A. That’s also the highest average current draw compared to other SBCs.
One of the really cool things about this SBC is the very low current consumption when powered off. It has the lowest current draw out of all the SBCs I’ve seen. Only 1.26mA! Nice.
Moving over to temperature stats, the initial boot and idle test saw an average of 52C with a max of 71C. This was with an ambient room temperature of 20C.
While during testing, the average jumped to 66C with a max of 83C.
Overall the temperatures were pretty stable with some tests, like the SmallPT, OpenCL and kernel compilation raising the core temperature to the max.
So, what do I think of the ODROID XU4?
If you compare it to other 8core SBCs, it definitely comes out on top. It is one of the more mature SBCs out there, able to run mainline Linux kernel.
Documentation and support is very well entrenched with a big fan base behind it, so if you get stuck, there will be people to help you.
I was surprised at how well the CPU kept it’s temperature under control given that on other SBCs some of the tests I did, made the CPU throttle.
However, there’s a couple of downsides to this board.
The binary blobs that are required for graphics, but that can be said for a lot of other SBCs as well.
There’s also the logic level issue and networking isn’t that good compared to other SBCs with GbE.
Also, the lack of WiFi, might turn some people off.
However, if you want a decent 8core SBC that performs well with a bucket load of support, then get an XU4.