ARM support for Raspberry Pi

[sroze]

Hello,

Is there an ARM arch support planed? If not, how can I do that? :)

Regards, Samuel.

[carrot-garden]

Samuel:

thanks for your interest.

sure, arm support would be a great idea.

no, not plans yet, except if you become that plan ;-)

road map could be like this:

• define a target arm platform - I presume android focus
• make sure udt c++ compiles on them
• if not, submit udt c++ patches to http://www.linkedin.com/in/yunhong or to me
• develop gcc arm cross compile
• develop android testing harness

one starting point would be to take a look on how projects such as http://deadbeef.sourceforge.net/ https://play.google.com/store/apps/details?id=org.deadbeef.android&hl=en integrate native c++ jni on android

cheers,

Andrei.

[sroze]

Thanks for your reply. I may be the plan ;-)

My target is in fact Raspberry PI right now, which is based on ARM arch. I found a successful cross-compiler example: http://www.bootc.net/archives/2012/05/26/how-to-build-a-cross-compiler-for-your-raspberry-pi/

Then, what's the way to integrate arm build of udt c++ in barchart-udt4?

[carrot-garden]

I would suggest the following path:

1) produce vmware raspberry-pi image

2) raspberry-pi should be running LTS ubuntu 10.04 or later with full g++ build chain;

3) make sure the image has oracle linux arm jdk

4) now, add new arch/os/linker definition to the maven-nar-plugin aol.properties config file

5) finally, reflect new nar constants in the udt library loader enum classes

if you upload final vmware raspberry-pi to us, we will just drop it our "vmware build farm" and you will start getting your barcahrt-udt artifacts as part of the release process.

easy 5 steps, right? :-)

[He-Pin]

hi,carrot garden,can this lib be used on the android now?i think you could make an arm.so

[CCob]

I have compiled UDT on it's own with my rpi cross toolchain without issue with some slight modifications (alter Makefile to use CXX environment variable and set it to the cross compiler g++) . Haven't had chance to test it yet though.

[carrot-garden]

@CCob : do you by chance have it inside a vmware image you could share?

[CCob]

Its a VirtualBox vm, but running intel Ubuntu. Ideally a QEMU environment would be better as we would be able to compile, run and do tests for the arm platform within an emulated arm cpu guest on an intel host.

[carrot-garden]

I see. my dilemma is this: I use vmware since I could not make VirtualBox or KVM work for MacOSX.

do you by chance have MacOSX running on VirtualBox or KVM? if yes, can you share it the VM?

can you share your current VirtualBox ARM VM? does it run Oracle Linux ARM JDK?

[CCob]

My current VM is a Ubuntu Intel, with an arm cross compiler. Which means the resulting binaries produced by the compiler cannot be run on the VM itself. OSX VM's for VirtualBox and KVM are a pig to setup since there is no official support for it, usually you need to download a modified version of OSX and use tools from the OSx86 project. QEMU should work just fine with an emulated ARM Raspian image on OSX. I'll have a go at setting one up with a Hudson/Jenkins slave inside the ARM VM, I'll send it over then if it all works.

Any reason why you can't use the OpenJDK as opposed to Oracle? The main reason being is that currently the Oracle JDK does not support armhf support which is the default for the Raspbian image on the raspberry download site. Oracle currently only support software floating point which as you can imagine is not as quick at floating point calculations compared to armhf which is hardware based.

[carrot-garden]

ok, got it, thank you. OpenJDK is fine. my preference is to have fully emulated ARM VM running native ARM tool-chain and ARM JDK. no rush - unless @sroze starts begging you :-) cheers.

[sroze]

@CCob I think that a VMWare image could be simpler to integrate to the "build farm" which contains VMWare based machines, but if you already have a QEMU ARM env working, I'm interested @carrot-garden i'll try to build a VMWare ARM machine with g++ build chain the next week (with OpenJDK, right?)

[CCob]

VMware is generally a machine emulator not a CPU emulator. Guest machines within VMWare have the same CPU as the host. So on intel hardware qemu would be the only option since it emulates the cpu as well as the host.

[CCob]

Got a different plan to QEMU and should be able to do so inside a VMWare virtual machine. I am in the middle of installing Debian Wheezy inside an AMD64 VM. The plan then is to setup an armhf chroot which in turn will use qemu user mode (not machine mode) allowing arm environment inside the same machine. Not sure how quick it will be, emulating an ARM chroot inside an already emulated machine may be disastrous to speed. I guess time will tell.

[carrot-garden]

great, sounds interesting. thanks for the update.

[CCob]

No joy, user level emulation of arm chroot is not working well at all. The JVM crashes randomly during maven compile. I'm afraid it looks like full qemu system emulation only

[sroze]

Thanks @CCob ! I'll try tomorrow an ARM chroot on Ubuntu x86 with the qemu-user-static package which should works.

[CCob]

@sroze, this is what I tried today, qemu-user-static's emulation is not quite stable enough to allow the compile. I can get maven, g++, git and OpenJDK installed without issue. But when you try to compile you get various random errors and crashes.

[CCob]

I have good news and bad news.

I can now successfully compile barchart-udt-core on an emulated ARM machine using qemu. I managed to get the qemu machine running inside my native Windows host so there is only a single layer of emulation.

Now for the bad news, the emulation of the ARM CPU is VERY slow on my Core i3 2.13Gz Laptop. After all the maven dependencies are downloaded and present (this took an age), the build alone takes around 20 minutes. I am currently running the tests which I expect to take a while, but so far so good.

[CCob]

Another update.

The tests got quite far, but a few are marked with Timeout's which fail due to timeout issue. I have no doubt on a real ARM machine the tests would complete successfully, but in a qemu environment, without altering or ignoring some of the tests they wont due to slow emulation.

[carrot-garden]

great. few ideas:

1) we can exclude specific tests based on arch/os filters using: http://junit.sourceforge.net/javadoc/org/junit/Assume.html http://kentbeck.github.com/junit/javadoc/4.10/org/junit/rules/TestRule.html etc.

2) or re-write tests to not depend on time

3) what are arch/os signatures reported by java?

[CCob]

I have committed some changes to the ccob branch with the required changes.

[carrot-garden]

cool. found/merged

[CCob]

Here is the ARM QEMU image with Maven, Git, JDK and barchart-udt pre-installed and buildable.

https://dl.dropbox.com/u/12303739/2012-12-16-wheezy-raspbian.7z

@carrot-garden, what is the host machine of your automated husdson/jenkins server?

[carrot-garden]

got it, checking. host is Ubuntu 12.04.1 LTS x86_64

[CCob]

Unfortunately you will need to compile qemu since the distro version is 1.0 and you'll need 1.2 or greater (latest is 1.3) to emulate the rpi CPU successfully. Once you have done this you can start the emulated arm VM with the following command

qemu-system-arm -serial serial.txt -M versatilepb -cpu arm1176 -m 256 -kernel kernel-qemu -hda 2012-12-16-wheezy-raspbian.img -append "root=/dev/sda2 panic=1

You can get the qemu compatible 3.2 kernel image from here http://xecdesign.com/downloads/linux-qemu/kernel-qemu

[carrot-garden]

1) I have here QEMU 0.14.X, with

# qemu-system-arm --version
QEMU emulator version 1.0.50 (Debian 1.0.50-2012.03-0ubuntu2.1), Copyright (c) 2003-2008 Fabrice Bellard

2) the image starts fine

root@raspberrypi:~# mvn -version
Apache Maven 3.0.4
Maven home: /usr/share/maven
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-armhf/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "3.6.8", arch: "arm", family: "unix"

but you say I need to re-build qemu anyway?

3) the kernel http://xecdesign.com/downloads/linux-qemu/kernel-qemu has 256M hard RAM limit; I wonder if 1G RAM would help build speed? do you know of such image?

[CCob]

Well if it boots leave it well alone :) To get more than 256mb you would need to recompile the kernel with the qemu patches and 256 limit removed. I dont know of any pre compiled kernels.

[carrot-garden]

rejoice: we accomplished the incredible: arm is now part of build

build takes 10 minutes w/o tests. there has to be a better way :-)

[CCob]

If we could lie about the os.arch property on a build slave we could use an ARM cross-compiler in the aol.properties. That way compilation can be done on a fast intel host. We wouldn't be able to run tests on that host though, since it wont be able to load the ARM so.

[He-Pin]

wow~~so incredible work~!Nice and perfect!

@carrot-garden ,could just please build the SO with the NDK?then UDT can run on android.

[carrot-garden]

no, I was hoping you would do it :-)

[sroze]

Thank you very much to both of you for this work!

[carrot-garden]

please confirm it works on your target

[He-Pin]

@carrot-garden i have tested this on raspberry pi ,with openjdk,it works fine ,the speed is just like the pc,but not that smooth ,like ~~~ not ----------

[He-Pin]

@carrot-garden update,for now ,it works on armhf,not armel.need to recompile on armel.and ship to arm to armel and armhf

[fightforge]

Hi, i'm totally new on android pogramming, if i use barchart-udt-bundle-2.3.1-20160518.172720-116.jar in my android studio project, can i use it?

thanks