Wednesday, November 21, 2012

Comparing performance of Raspberry Pi and BeagleBone

Synopsis: ARM v6 CPUs (such as the Raspberry Pi) are significantly slower than ARMv7 CPUs (such as in the BeagleBone) at the same clock speed, at least when running Debian (armhf) on them.

I know it's a rather naive benchmark, but I tried running Perl and Scala programs to find all the prime numbers under 100,000 on both the Raspberry Pi and the BeagleBone.

They're both 700 MHz ARM CPUs, but the Raspberry runs on the older v6 spec CPU.

Surprisingly, this seems to make a huge difference to performance.

Perl primes to 100k:

  • My desktop (3GHz i7) - 3.3 seconds
  • BeagleBone (720 MHz ARMv7)- 68 seconds
  • Raspberry Pi (700 MHz ARMv6) - 125 seconds

I thought I'd try it quickly in Scala, but it seems the JVM isn't very well optimised on ARM yet. I cancelled the tests after five minutes, and re-ran them only calculating up to 10k.

Scala primes to 10k:

  • Desktop - 0.33 s
  • Beagle - 19 s (zero) / 34 s (jamvm)
  • Raspberry - 58 s (jamvm) / 79 s (zero)

It's curious to note that the best JVM varies between the architectures; Zero was a lot faster than JamVM on the Beagle, but it was a lot slower on Raspberry Pi. (At least for this naive test)
Zero is the default on both, at least on Debian.

Wednesday, August 15, 2012

v4 Linaro armhf image for mk802

Just a quick post - I've updated my Linaro/ALIP/armhf image for the MK802 device.

Compared to the first version, this one is based on Linaro 12.07 instead of 12.06; has a Mali X11 driver; has various filesystem optimisations that improve performance a bit; has more drivers for stuff compiled into the kernel.

Compared to the second and third versions, it has more drivers for stuff, and some X11 problems were fixed.

Download from:

Thursday, July 19, 2012

Working Mali X11 driver on MK802 (A10)

I've managed to get the Mali X11 driver working on my AllWinner A10 MK802 device in Linux.

I'm using Linaro's 12.06 armhf build as a base image, and then using the linux-allwinner kernel sources, and some info from Rhombus Tech, combined with a bit of hacking around myself.

I've put the details here:

They're a bit long-winded at the moment, but once I've evened things out, I'll make a fresh SD card image.

Tuesday, July 10, 2012

MK802 image with armhf Linaro 12.06 and custom kernel

Just a quick update on my MK802 hacking..
I've created an easy-to-install image which is based on Linaro's 12.06 "internet appliance" base, and has then added my 3.0.36+ kernel (based on Amery's linux-allwinner repo), containing lots of extra drivers for things like bluetooth, USB drives, gamepads, webcams, and so forth.

You can download it here: linaro-alip-armhf.7z (204 M. kindly hosted by Miniand)

You'll need to use 7-zip to extract the image from the archive, then dd or imagewriter to splat the entire image onto an SD card. (eg. dd if=linaro-alip-armhf.img of=/dev/sdb conv=fsync)

This image should fit on a 4G card. If you have a larger card, splat it on, then eject and reinsert the disk, then resize the second partition and filesystem with parted, resize2fs, etc.

There's still no support for the Mali GPU, unfortunately; however see Compile X11 driver for A10 for info on where to start hacking..

Thursday, June 28, 2012

MK802: Adding bluetooth, 1080p, custom kernels

A quick update on the MK802.

I've succeeded in getting it to boot a kernel I've compiled, which means I can add Bluetooth support, among other things, and you saw in my earlier post that I'd enabled 1920x1080p resolution via modifying evb.bin. Another user, Suzuke, was able to extend the memory to use closer to the full 1GB.

Unfortunately, this was only on the 3.0.8+ "lichee" kernel, not the latest branch of Amery's linux-allwinner. But it's a step closer.
We still really need to get onto the latest Linux kernels to fix some bugs, and get the Mali GPU working, hopefully.

In the meantime, my modified kernel is here, along with the config used to build it:
(Also mirrored by Eric Betts at )

The modified evb.bin:

Suzuke's modified uboot for more memory:

Tuesday, June 19, 2012

MK802 PC-onna-stick - first impressions and enabling 1080P

I received my MK802 in the mail today, and have been playing with in, both in Android and Ubuntu.

Initial impressions are that the firmware isn't quite there yet.. The Android build mostly worked well, but the resolution is locked at 1280x720, despite claims that it can do 1920x1080, and even up to 2160P!
It also seemed a bit slower than I was hoping, given the claims of being a 1.5 GHz Cortex A8 clone. (For comparison, my old Samsung Galaxy S was a 1 GHz A8, and it really flew! Whereas the MK802 couldn't even play Angry Birds smoothly..)

The Ubuntu port is very early days as well -- It only supports 512 Mb of the 1Gb of ram, and it's running in a simple framebuffer X mode, rather than using the Mali GPU properly. It was limited to 1280x720 as well :(
It's using the Android kernel rather than a proper Ubuntu one :/
However apart from that, it worked reasonably well as long as you didn't hit swap..

After all this, I read up on the mk802 forums, discovered the sunxi-tools for hacking around with the booting binaries, and messed around a bit, and managed a little world-first.. I managed to get 1920x1080 working at 50 Hz in Ubuntu, and it looks like that'll get ported into the Android version soon enough too. Hurrah!

I'm extremely dubious about claims the device can do up to 2160P.. It seems like it can barely do 1920x1080 at 50 Hz -- I tried 60 Hz, and there was a lot of tearing and glitches. But.. maybe with the Mali GPU being used it'd be OK?

Time will tell -- and for the moment, it's still a nifty device. It's amazing that they didn't bother putting Bluetooth into it though! You can put a bluetooth dongle on it, but then you need to use a hub too, so you can also plug in a mouse to let you configure the bluetooth pairing. :/

Monday, May 21, 2012

An SSD1306 LCD controller in Perl for the BeagleBone

I've been hacking away on the BeagleBone some more, and I've come up with a controller for the common SSD1306 LCD controller, using the SPI interface. This controller is behind a bunch of the available small graphical LCD panels out there.

I've also written supporting libraries to display both text and PNG files, although don't expect too much from a 128x32 monochrome image!

I've uploaded my notes and libraries here:

Coding it is as simple as:

my $lcd = BeagleBone::SSD1306::Text->new(
  rst_pin => 'P9_15',
  dc_pin => 'P9_16',
  # remainder of pins must be connected to SPI pins
$lcd->display_string("Hello world!");

Wednesday, May 16, 2012

First steps with Perl on the BeagleBone

Today I received a BeagleBone A5, which is a very small board containing a 720 MHz ARM CPU and 256 MB of RAM, among other things.

The first step was to start flashing the built-in LEDs via a Perl script..
I found a script on another site ( but it's not "modern" Perl, and was working in an inefficient way. (Opening and closing the LED filehandles continually).
Here's my updated version:

use strict;
use warnings;
use autodie;
use Fcntl qw(:DEFAULT);

unless (-w "/sys/class/leds/beaglebone::usr0/brightness") {
    die "I think you need to run this as root..\n";

my @leds = map {
    my $tmp;
    sysopen($tmp, "/sys/class/leds/beaglebone::usr$_/brightness", O_WRONLY);
} (0..3);

print "Hit Ctrl-C to exit..\n";
while (1) {

sub led {
    my @vals = @_;
    for my $i (0..3) {
        syswrite($leds[$i], "$vals[$i]", 1);
    select(undef, undef, undef, 0.05);

Thursday, January 19, 2012

Using NFSv4 under OpenVZ

It is possible to use NFS v3 and NFS v4 under OpenVZ-based virtual hosts.

Firstly, you have to enable FEATURES="nfs" on the VM definition.. That was the easy bit.

NFS now appears to work on the surface, but locks, stats, and id mapping seems to be bust.
Looking at verbose logs, it turns out that certain files are missing from /proc/net/rpc/ on the VMs.

The key to making things work is to edit /etc/default/nfs-common on the host server(s) and set


And then run /etc/init.d/nfs-common restart

Now remount your NFS shares in the guest machines, and you'll discover the idmapping and stuff is working..

The downside to all this is that the username-to-UID mapping is done on the host server, not the guests -- which is essentially useless :(