Crosscompiling for RaspPi - Explained

General programming chat and advice for beginners

26 posts   Page 1 of 2   1, 2
by aaa801 » Fri Jun 15, 2012 2:25 pm
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_Setup#Copying_an_image_to_the_SD_Card_in_Linux_.28command_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
Posts: 427
Joined: Mon Jun 04, 2012 9:06 pm
Location: Berkshire
by chorlton » Fri Jun 15, 2012 2:57 pm
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! :)
Posts: 50
Joined: Mon Feb 06, 2012 1:57 pm
by ukscone » Fri Jun 15, 2012 3:07 pm
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
User avatar
Forum Moderator
Forum Moderator
Posts: 2811
Joined: Fri Jul 29, 2011 2:51 pm
by aaa801 » Fri Jun 15, 2012 3:12 pm
chorlton wrote: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 :D
Posts: 427
Joined: Mon Jun 04, 2012 9:06 pm
Location: Berkshire
by aaa801 » Fri Jun 15, 2012 3:16 pm
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
Posts: 427
Joined: Mon Jun 04, 2012 9:06 pm
Location: Berkshire
by abishur » Fri Jun 15, 2012 3:17 pm
aaa801 wrote:
chorlton wrote: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 :D


Did you get sound and a good frame rate off virtualBoyAdvnaced? (Would you be willing to share the binaries? :-P)
Dear forum: Play nice ;-)
User avatar
Forum Moderator
Forum Moderator
Posts: 4305
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by aaa801 » Fri Jun 15, 2012 3:19 pm
abishur wrote:
aaa801 wrote:
chorlton wrote: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 :D


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


No sound yet :(, but it runs at about 90-100% emulation speed, which is prety dam awesome, il pm you the prebuilt source tree
Posts: 427
Joined: Mon Jun 04, 2012 9:06 pm
Location: Berkshire
by jecxjo » Fri Jun 15, 2012 3:20 pm
ukscone wrote: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.php?title=HowToSetupCrossCompileEnvironment
IRC (w/ SSL Support): jecxjo.mdns.org
Blog: http://jecxjo.motd.org/code
ProjectEuler Friend: 79556084281370_44d12dd95e92b1d9453aba2bdc94101b
User avatar
Posts: 157
Joined: Sat May 19, 2012 5:22 pm
Location: Ames, IA (USA)
by aaa801 » Fri Jun 15, 2012 11:17 pm
The advantage of this is also that you also dont have to copy over files etc from and to the pi ;)
Posts: 427
Joined: Mon Jun 04, 2012 9:06 pm
Location: Berkshire
by ukscone » Fri Jun 15, 2012 11:26 pm
aaa801 wrote: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
User avatar
Forum Moderator
Forum Moderator
Posts: 2811
Joined: Fri Jul 29, 2011 2:51 pm
by KiwiKid » Mon Oct 01, 2012 11:37 pm
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.
Posts: 1
Joined: Mon Oct 01, 2012 11:19 pm
by akadata » Wed Oct 10, 2012 2:21 pm
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/xwlnu8eq7566itc/arm-chroot.tar.gz?fb=1&fb_action_ids=10151351192566461&fb_action_types=dropboxdropbox%3Aadd&fb_source=other_multiline&action_object_map=%7B%2210151351192566461%22%3A441441519224965%7D&action_type_map=%7B%2210151351192566461%22%3A%22dropboxdropbox%3Aadd%22%7D&action_ref_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.
Posts: 2
Joined: Wed Oct 10, 2012 2:17 pm
by akadata » Wed Oct 10, 2012 2:53 pm
akadata wrote: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/xwlnu8eq7566itc/arm-chroot.tar.gz?fb=1&fb_action_ids=10151351192566461&fb_action_types=dropboxdropbox%3Aadd&fb_source=other_multiline&action_object_map=%7B%2210151351192566461%22%3A441441519224965%7D&action_type_map=%7B%2210151351192566461%22%3A%22dropboxdropbox%3Aadd%22%7D&action_ref_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

Posts: 2
Joined: Wed Oct 10, 2012 2:17 pm
by diereinegier » Thu Jan 03, 2013 1:09 pm
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!
Download my repositories at https://github.com/GeorgBisseling
User avatar
Posts: 145
Joined: Sun Dec 30, 2012 5:45 pm
Location: Bonn, Germany
by kalectro » Tue Mar 05, 2013 4:10 am
it does not work on the latest Raspbian image. Any suggestions?
http://www.raspberrypi.org/phpBB3/viewtopic.php?p=298537#p298537
Posts: 15
Joined: Sun Jan 06, 2013 4:54 am
by aaa801 » Tue Mar 05, 2013 6:39 pm
kalectro wrote:it does not work on the latest Raspbian image. Any suggestions?
http://www.raspberrypi.org/phpBB3/viewtopic.php?p=298537#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
Posts: 427
Joined: Mon Jun 04, 2012 9:06 pm
Location: Berkshire
by tanders12 » Tue Mar 05, 2013 7:05 pm
kalectro wrote:it does not work on the latest Raspbian image. Any suggestions?
http://www.raspberrypi.org/phpBB3/viewtopic.php?p=298537#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.
Posts: 2
Joined: Wed Feb 13, 2013 4:03 am
by baam » Sun Mar 10, 2013 10:07 pm
is there any chance to get a workaround? would be great :)
Posts: 5
Joined: Sun Mar 10, 2013 10:04 pm
by baam » Mon Mar 11, 2013 5:43 am
Well, maybe i should have read the thread tanders posted... :roll:
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!
Posts: 5
Joined: Sun Mar 10, 2013 10:04 pm
by sikku » Wed Mar 13, 2013 2:57 am
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
Last edited by sikku on Wed Mar 13, 2013 2:59 am, edited 1 time in total.
Posts: 9
Joined: Wed Mar 06, 2013 5:39 am
Location: Bangalore
by sikku » Wed Mar 13, 2013 2:58 am
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?
Posts: 9
Joined: Wed Mar 06, 2013 5:39 am
Location: Bangalore
by baam » Wed Mar 13, 2013 9:08 am
@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.
Posts: 5
Joined: Sun Mar 10, 2013 10:04 pm
by aaa801 » Wed Mar 13, 2013 10:22 am
baam wrote:@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
Posts: 427
Joined: Mon Jun 04, 2012 9:06 pm
Location: Berkshire
by baam » Wed Mar 13, 2013 12:39 pm
already tried that.. doesnt work :?

does anyone else have the same problems?
Posts: 5
Joined: Sun Mar 10, 2013 10:04 pm
by sikku » Fri Mar 15, 2013 12:27 pm
baam wrote:@sikku: wrong thread?!



Yeah wrong thread... my mistake...
Posts: 9
Joined: Wed Mar 06, 2013 5:39 am
Location: Bangalore