The Odroid XU4 with a new OS (4)

Figure 1:  The Odroid XU4 in action, doing two big things at once.

Continued from page three of this article …

Two different classes of SoC/SBC boards are emerging in this ridiculously fast changing market.  When I purchased the C1 three years ago, it was the best performance I could find in a low power  consumption hobby-niche SoC/SBC that was also in the Pi price point target range (approximately).

What was OK then (being within my expectations at the time), now is on the fringe of my expectations.  So, I find myself relegating the older boards to less demanding applications, and using the newer boards for more demanding applications (like the desktop).  They still make a lot of the older boards (heck, they’re still making at least one of the older Pi boards, and Odroid still sells the C1+).  That’s because those older boards can still do stuff.  It’s just that the newer boards  have a better response that appeals to my brain’s inherent desire for fluidity (especially in a desktop or browser experience).  The XU4 is not a much newer board, but its price has declined to be much more in line with the previously mentioned target.  I think it may be (currently) the best board on the market, but everybody has their opinion on this.

Every time I buy a new-to-me SBC, I learn stuff.  I learn not only the nuances of the new board, but sometimes I learn external things prompted by the setup requirements (and driven by my biases or preferences) – but entirely a segue that follows from the use of the new board.  For instance, my perception of how the regular images are “not as thin” as I like – prompted me to try Gentoo on the XU4, and that is a Linux distribution that I’d never had any reason to touch previous to the board purchase.

Recently I put the Vivaldi browser on the XU4.  It works as well as it does on the AMD64 – that twenty pound beast that the XU4 has chased off of the desktop like a mouse after an elephant. On my fairly stock Gentoo installation, there were only a few emerges necessary to be made as dependencies of the new browser:

  • emerge –ask cups
  • emerge –ask x11-libs/libXScrnSaver
  • emerge –ask gconf

I used the debian package that Vivaldi built and provides for the Pi, in order to perform the installation of the browser.  A “.deb” debian package is just an AR archive, so it can be unpacked and manually installed on a system that is without a debian package tool:

wget -c -t0


  •  mkdir temp
  • mv vivaldi-stable_1.13.1008.34-1_armhf.deb temp/
  • cd temp
  • ar -x vivaldi-stable_1.13.1008.34-1_armhf.deb
  • xz -d data.tar.xz
  • tar -xvf data.tar

The contents of the data tarball include /usr and /opts directories.  The contents of these directories I then examined and carefully copied to my system’s /usr and /opt directories, while making sure I didn’t overwrite existing stuff, and that I set the permissions appropriately.

It’s not as configurable (in the more arcane, lower level) details that I like to tweak, but it’s a much prettier browser than the others.  Really, I cannot seem to detect a difference (in fluidity) when using Vivaldi on the XU4 (rather than the AMD).

In the news recently are the security issues that have been discovered with Intel chips.  Apparently, some ARM devices may also be affected, to a different extent.  It’s hard to know if everything has been discovered, since the attention focused on the Intel event causes more eyes to search out similar issues in other architectures.  But, (taking various published statements) as my input, I get that the XU4’s 4 bigger cores might be included on the list of affected devices for at least one variant of the recently discovered issue(s).  This does not worry me much, but when I’m feeling particularly paranoid, I simply turn the bigger cores off.  When running on only the four little cores, my XU4 seems fine, and is still fluid, when browsing the internet.  To turn the bigger cores off, I echo some stuff into /sys/…

  • echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    echo “0” > /sys/devices/system/cpu/cpu4/online
    echo “0” > /sys/devices/system/cpu/cpu5/online
    echo “0” > /sys/devices/system/cpu/cpu6/online
    echo “0” > /sys/devices/system/cpu/cpu7/online

I usually do this right after logging into the system, and before I launch X windows.  If one of the cpus’ is in use when the echo command is issued, it will not turn off.  Right after logging onto the system (since I don’t use a graphical logon screen) – the four big cores are normally not doing anything. Why is the XU4 still fluid when running a browser on the little cores?  One might think that the performance would drop to the level of a C1, but it doesn’t.  The XU4 has more memory, and I think better pipelines for some things, so I can not really tell the difference (with or without the big cores) – for internet.

One can check to be sure that the four big cores are indeed turned off, by this command:

  • grep “CPU part” /proc/cpuinfo

The output should be only four lines of info, like this:

  • CPU part : 0xc07   (note: 0xc07 = “little core”)
    CPU part : 0xc07
    CPU part : 0xc07
    CPU part : 0xc07

I’m (for the moment) pretty happy with the XU4, but (as I mentioned at the top of the page) – another increment in the market could affect my expectations.  I’m looking forward to the XU5 (really, I don’t know if that’s what they’ll name the next version) – and have heard some interesting rumours about it (maybe they were more wishes than real rumours) – about a device with 8GB of memory.  For the moment though, we’re getting along fine …

Read More …

Note: Gentoo is a product of the Gentoo people at, and this author and site has no affiliation with them. Odroid is a project of hardkernel at, and this author and site has no affiliation with them.