Crosscompiling for RaspPi - Explained

[aaa801]

Compiling big projects is very time-consuming on the raspberry pi. Wouldn't it be great if we could compile our files on a seperate computer and make the changes to the SD Card immediatelly?Normally we'd just mount a remote disk, and chroot into it. The problem is, that the Raspberry PI is an ARM System, and most computers are NOT. This means the binaries on the sdcard are incompactible. We can solve this using qemu, a processor emulator.

All the following procedures are done on the host system, not the raspberry pi!, you will just need the PI's SDCard, not the device itself!
I will assume that your sdcard is unmounted and is located on /dev/sdc. Your sdcard might be located somewhere else, and might be mounted. If you don't know how to umount it, or find out what the name is of your sdcard device, check out the beginners` guide on the wiki : http://elinux.org/RPi_Easy_SD_Card_Setu ... nd_line.29

Lets first mount the correct partition of the sdcard, (the one with the linux file hierarchy). to do this we will issue this command:

Code: Select all

$ sudo fdisk -l

You'll see a list of information, try to look for the section which has info about the Disk that matches your SDCard's size, and has a Linux System on one of the devices

Code: Select all

Disk /dev/sdc: 2013 MB, 2013265920 bytes
4 heads, 32 sectors/track, 30720 cylinders, total 3932160 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ee283

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048      155647       76800    c  W95 FAT32 (LBA)
/dev/sdc2          157696     3414015     1628160   83  Linux
/dev/sdc3         3416064     3807231      195584   82  Linux swap / Solaris

The device with Linux FileSystem, in my case /dev/sdc2 is the one we'll need to mount. I'll just mount it to /mnt.

Code: Select all

$ sudo mount /dev/sdc2 /mnt

Now we're going to install the stuff we will need for the processor simulation

Code: Select all

$ sudo apt-get install qemu qemu-user qemu-user-static

Now we need to copy over the file for the emulation to the sdcard

Code: Select all

$ sudo cp /usr/bin/qemu-arm-static /mnt/usr/bin

Everything should be done now!, we should be able to chroot into the pi's filesystem!

Code: Select all

$ sudo chroot /mnt

we'll be prompted with a new commandline! Yay!, lets check if it worked! BTW, we

Code: Select all

root:/# gcc -v
Using built-in specs.
Target: arm-linux-gnueabi

Yay, it worked! you can now navigate to your project on your sdcard, for example # cd /home/pi/mybigCProject

and then just run your Makefile or gcc or any ARM Build tool you need, and it will start building.

Once you're done compiling, type in this to exit the chroot

Code: Select all

# exit

and then unmount the device

Code: Select all

$ sudo unmount /dev/sdc2

Now remove the SDCard, pop it in your raspberry pi, and go try out your compiled project ^^


You won't have to copy over the qemu-arm-static file every time, just once, so next time you just do:

Code: Select all

$ sudo mount /dev/sdc2 /mnt
$ sudo chroot /mnt

and off you go!

NOTE: make sure you're using qemu 1.0 at least, older versions might glitch, no good timez. Check it with "qemu-arm-static -version"

Happy developing!

~~ Arian & AAA801

[chorlton]

This is dark voodoo.

I get how chroot works, and I get that the gcc on the mounted partition will target ARM architecture, but that gcc is an ARM binary. I wouldn't have thought it would run on an x86 host?

By copying qemu-arm-static into the /usr/bin of the chroot this will magically just work?

If it does then I'm impressed!

[ukscone]

there is another way that is pretty simple. scratchbox2 http://maemo.gitorious.org/scratchbox2 (and if you really want to sbrsh although it does complicate things a little).

scratchbox2 is pretty much idiot-proof and to prove it i've been using it almost exclusively for several years (plus aboriginal & buildroot) and had no problems. i normally use it inside a vm just for convieniance but it doesn't have to be in one. simple instructions can be found here http://pastebin.com/4Jp1WPTb

[aaa801]

This is dark voodoo.

I get how chroot works, and I get that the gcc on the mounted partition will target ARM architecture, but that gcc is an ARM binary. I wouldn't have thought it would run on an x86 host?

By copying qemu-arm-static into the /usr/bin of the chroot this will magically just work?

If it does then I'm impressed!

Yes it does
I tested it by compiling virtualBoyAdvance, (which crashs the pi when you compile on it for some reason)
And it worked out great

[aaa801]

This is needed aswell to prevent problems with networking etc
after the
mount ### /mnt
mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys

[abishur]

This is dark voodoo.

I get how chroot works, and I get that the gcc on the mounted partition will target ARM architecture, but that gcc is an ARM binary. I wouldn't have thought it would run on an x86 host?

By copying qemu-arm-static into the /usr/bin of the chroot this will magically just work?

If it does then I'm impressed!

Yes it does
I tested it by compiling virtualBoyAdvance, (which crashs the pi when you compile on it for some reason)
And it worked out great

Did you get sound and a good frame rate off virtualBoyAdvnaced? (Would you be willing to share the binaries? )

[aaa801]

This is dark voodoo.

I get how chroot works, and I get that the gcc on the mounted partition will target ARM architecture, but that gcc is an ARM binary. I wouldn't have thought it would run on an x86 host?

By copying qemu-arm-static into the /usr/bin of the chroot this will magically just work?

If it does then I'm impressed!

Yes it does
I tested it by compiling virtualBoyAdvance, (which crashs the pi when you compile on it for some reason)
And it worked out great

Did you get sound and a good frame rate off virtualBoyAdvnaced? (Would you be willing to share the binaries? )

No sound yet , but it runs at about 90-100% emulation speed, which is prety dam awesome, il pm you the prebuilt source tree

[jecxjo]

there is another way that is pretty simple. scratchbox2 http://maemo.gitorious.org/scratchbox2 (and if you really want to sbrsh although it does complicate things a little).

scratchbox2 is pretty much idiot-proof and to prove it i've been using it almost exclusively for several years (plus aboriginal & buildroot) and had no problems. i normally use it inside a vm just for convieniance but it doesn't have to be in one. simple instructions can be found here http://pastebin.com/4Jp1WPTb

I use Scratchbox2 for all of my projects at work. Using a cross compiler running natively gives you better performance than running a native compiler in an emulator. Scratchbox is nice since you get execution time in the emulator (qemu) when you need it but when you compile you are using your native cross compilers. Building large projects is much faster this way.

I'm working on converting my old tutorial to the RPi wiki. But for the moment here is the link. You should be able to skip over the parts where you build the cross compilers by hand if you want to use the ones from your distro. I'll be sure to post on here once I've finished rewriting it for the Pi on the eLinux site.

http://biffengineering.com/wiki/index.p ... nvironment

[aaa801]

The advantage of this is also that you also dont have to copy over files etc from and to the pi

[ukscone]

The advantage of this is also that you also dont have to copy over files etc from and to the pi

that's what sbrsh is for. basically it mounts the target device using sshfs or nfs and uses the cross compiler host toolchain to compile but uses the target for running binaries within the building process and the resultant binary is on the target when the compile is completed

[KiwiKid]

For those wondering how this magic works: http://en.wikipedia.org/wiki/Binfmt_misc.

Basically the Linux kernel can be configured with extra executable file formats and which user space application to use to run them. These instructions have you install qemu + the appropriate setup to recognize ARM binaries and run them via QEMU transparently.

Not as fast as scratchbox in terms of performance, but a lot easier to setup; and given how fast many peoples machines are/their expectations, this incredibly simple setup is just amazing.

NOTE: I haven't confirmed if this is still true, but looking at http://wiki.debian.org/QemuUserEmulation it seems that this approach is incompatible with scratchbox/scratchbox2. Don't try setting up both on the same machine unless you're willing to manually change the binary format mappings.

[akadata]

the chroot with qemu-arm is a really nice and quick way of building and compiling for the Raspberry Pi. to this extent i have put a file in dropbox here https://www.dropbox.com/s/xwlnu8eq7566i ... map=%5B%5Dand posted a link on the Facebook Group https://www.facebook.com/groups/raspberry.pie/ with arm-chroot, a complete minimal base install of raspbian

I hope everyone finds this usefull. there are no accounts and no passwords and its just a second stage debootstraped environment.

[akadata]

the chroot with qemu-arm is a really nice and quick way of building and compiling for the Raspberry Pi. to this extent i have put a file in dropbox here https://www.dropbox.com/s/xwlnu8eq7566i ... map=%5B%5Dand posted a link on the Facebook Group https://www.facebook.com/groups/raspberry.pie/ with arm-chroot, a complete minimal base install of raspbian

I hope everyone finds this usefull. there are no accounts and no passwords and its just a second stage debootstraped environment.

Note there is an x86_64 static linked /usr/local/bin/qemu-arm file that i compiled on my Debian system. as it is a static binary the chroot should work on any x86_64 Linux box.
to enter the chroot with this command

"enter-chroot.sh ."

i have modified the enter chroot file to setup the arm-binfmt bits

one extra thing you may have to do to make it work on your setup is copy arm-chroot/usr/loca/bin/qemu-arm to your /usr/loca/bin . Note. Please make sure you dont overwrite your own custom qemu in /usr/local

[diereinegier]

I did not even know this was possible. Really, really cool.

I just checked this out and it still works with the current debian wheezy image. I used an Ubuntu 12.10 laptop with a 2 GHz Celeron to cross compile since it was the only machine with an SDHC reader available.

I got compile times that are worse than on a 512MB RasPi! Even when using a parallel make.

I can't say if the 2 GHz Celeron, the Kingston SDCard make the cross compile slow or if the native speed on the RasPi was improved during the last months.

As always: your mileage may vary!

[kalectro]

it does not work on the latest Raspbian image. Any suggestions?
http://www.raspberrypi.org/phpBB3/viewt ... 37#p298537

[aaa801]

it does not work on the latest Raspbian image. Any suggestions?
http://www.raspberrypi.org/phpBB3/viewt ... 37#p298537

Code: Select all
$ sudo apt-get install qemu qemu-user qemu-user-static



Now we need to copy over the file for the emulation to the sdcard

Code: Select all
$ sudo cp /usr/bin/qemu-arm-static /mnt/usr/bin

[tanders12]

it does not work on the latest Raspbian image. Any suggestions?
http://www.raspberrypi.org/phpBB3/viewt ... 37#p298537

When I was setting this up I came across the following guide:

http://xecdesign.com/qemu-emulating-ras ... -easy-way/

The note towards the top of the page indicates that qemu isn't working with the current Raspbian image. So this has been a problem for at least a few days.

[baam]

is there any chance to get a workaround? would be great

[baam]

Well, maybe i should have read the thread tanders posted...
they suggest (post from march 9th)

In order to run the latest image (2013-02-09-wheezy-raspbian.img) you need to comment out the contents of /etc/ld.so.preload.

or compile the kernel for qemu: http://xecdesign.com/compiling-a-kernel/

or compile qemu for arm: http://xecdesign.com/compiling-qemu/

i try to test it today and give you a feedback!

[sikku]

Finally I am able to login to Raspberry Pi without any monitor.
My first login was directly from my peer to peer connection.

All I did was I mounted the SD card into my PC and edited this file as follows:

Code: Select all

# mount /dev/sdc2 /mnt
# cd /mnt
# vi etc/network/interfaces

Then I made sure the following content is fed into etc/network/interfaces

Code: Select all

auto lo
iface lo inet loopback
 
auto eth0
iface eth0 inet static
address 192.168.1.3
netmask 255.255.0.0

The ip address of my PC is 192.168.1.3
I changed the ip address of my PC as follows:

Code: Select all

# ifconfig p2p1 192.168.1.2 netmask 255.255.255.0 up

Others may have to change the p2p1 with eth0. Or to know what is the name you can check by issueing the command

Code: Select all

# ifconfig -a

[sikku]

I want to get tightvnc binary file so that I can copy it to the bin directory and use vncviewer to get the GUI.

Can anybody help me in getting binary file of tightvnc?

[baam]

@sikku: wrong thread?!

b2t:
i tried their suggestion:
comment out the content from etc/ld.so.preload did work. chroot is doing fine now.

my problem is now that autoconf wont run :/
getting "you need autoconf version 2.59 or newer installed"
if i run /usr/bin/autoconf i get:
This script requires a shell more modern than all the shells that i found on your system.

installed version is 4.2.37(1)-release

i wont test the other options with compiling qemu etc.

[aaa801]

@sikku: wrong thread?!

b2t:
i tried their suggestion:
comment out the content from etc/ld.so.preload did work. chroot is doing fine now.

my problem is now that autoconf wont run :/
getting "you need autoconf version 2.59 or newer installed"
if i run /usr/bin/autoconf i get:
This script requires a shell more modern than all the shells that i found on your system.

installed version is 4.2.37(1)-release

i wont test the other options with compiling qemu etc.

try opening bash then try it

[baam]

already tried that.. doesnt work

does anyone else have the same problems?

[sikku]

@sikku: wrong thread?!

Yeah wrong thread... my mistake...