Hi,

During the last few weeks I was interested in cross-compiling for the RPi. I have gone through many tutorials and blog posts to get the task done , so I tried to compile as many information as I can in this guide as a future reference and to help everybody else [The post is long, use CTRL+F for navigation].

Topics:

1. Getting started , setting up the cross-compilation toolchain.
2. Hello World! Building an RPi C application using shell.
3. Hello World 2! Building an RPi C application using eclipse.
4. Remote debugging the RPi with gdb on eclipse + RSE plugin.
5. Updating your kernel. RPi Kernel cross-compilation.
6. Extra: How does the bootloader work ?? 

Let’s get started with cross-compiling a Pie , there are usually 2 configurations : 

• either to build the tool chain yourself on your host machine;
• or to get a pre-compiled toolchain (the Canadian cross).

[images from free-electrons embedded training slides]

For this guide I will be using pre-built linaro toolchain(the second way),still I encourage you to try to build the toolchain yourself  for the sake of knowledge using one of those excellent tutorials :  A and B

Now, let’s download the Linaro gcc toolchain [source]


$ sudo apt-get install git rsync cmake ia32-libs

$ mkdir raspberrypi

$ cd raspberrypi

$ git clone git://github.com/raspberrypi/tools.git


Add the cross-compile to your $PATH

$ export PATH=$PATH:$HOME/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin

And finally append the very same line to the end of your ~/.bashrc file to make the change permnant

That’s it, now try

$ arm-linux-gnueabihf-gcc -v 

should give you something like this

Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/ahmed/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../libexec/gcc/arm-linux-gnueabihf/4.8.3/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: /cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/src/gcc-linaro-4.8-2014.01/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-linux-gnueabihf --prefix=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install --with-sysroot=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-languages=c,c++,fortran --disable-multilib --enable-multiarch --with-arch=armv6 --with-tune=arm1176jz-s --with-fpu=vfp --with-float=hard --with-pkgversion='crosstool-NG linaro-1.13.1-4.8-2014.01 - Linaro GCC 2013.11' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpfr=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpc=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-isl=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-cloog=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-libelf=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-plugin --enable-gold --with-local-prefix=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-c99 --enable-long-long --with-float=hard
Thread model: posix
gcc version 4.8.3 20140106 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.01 - Linaro GCC 2013.11)

Now let’s build a simple application , use your favorite editor to write helloworld.c

#include <stdio.h>
int main()
{
   printf("Hello world \n");
   return 0;
}

and compile it using the usual gcc way

$ arm-linux-gnueabihf-gcc -o helloworld helloworld.c


Copy this to your Pi with a USB flash memory or on the sd card or whatever suits you, launch it and it should work !

pi@raspberrypi:~$ ./helloworld

Hello world

pi@raspberrypi:~$


Now, Let’s add our toolchain to eclipse : 

•  install C/C++ cross-compiler support plugin;

• from the menu File >> New Project >> C-Project >> Cross-Compile project , input the name of your project and hit next;
• enter arm-linux-gnueabihf- as Tool command prefix and ~/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin as the tool command path , hit next and finish;

• Congratulations 🙂 !!

It’s important to be able to debug your code online on the RPi, so we are going to use a nice plugin called RSE to do this [source]:

You may use this source code HelloDebug.c if you wish:

#include <stdio.h>

int main()
{
	int i = 0;
	printf("Hello world \n");
	while (i < 1000)
	{
		printf("%d \n",i);
		i++;
	}
	return 0;

}

• install the RSE plugin;

• create a new project with the above source, build it in debug mode (not release);
• add a new connection to your RPi from the Remote Systems window (if you can’t see it , add it from Window >> Show View >> Others >> Remote Systems) , then hit the tiny button to add an ssh connection to your pi;

• copy the elf executable to the pi using RSE (right click to copy it and paste it on the dir you wish from the stfp menu);

• make sure to chmod+x the execultable;
• now we will add a new debug configuration , right click on the project and select Debug as >> Debug Configurations  and add a new C/C++ Remote Application configuration;
• 
• ensure that in Debugger >> Main tab the debugger is arm-linux-gnueabihf-gdb
• login to your pi using ssh to launch the gdbserver $sudo gdbserver your-linux-pc-ip:any-free-port  HelloDebug

• back to eclipse , ensure that you have the right connection parameters in Debugger >> Connection tab where you should pick the RPi IP and the port number you previously picked.
• That’s it !! click Debug and enjoy debugging 🙂

Now , there is an excellent tutorial for compiling the kernel [this is not my work,  I am just copying it here for future reference because it’s short and to the point ]also elinux wiki has a good compilation:

Create our working directory:

$ mkdir -p raspberrypi/kernel
$ cd raspberrypi/kernel

Before starting our work, install the necessary tools and source code of Raspberry Pi linux:

$ git clone https://github.com/raspberrypi/tools.git
$ git clone https://github.com/raspberrypi/linux.git

Prepare the .config file from pre-packaged config, bcmrpi_cutdown_defconfig:

$ cd linux
$ make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- bcmrpi_cutdown_defconfig

Build kernel:

$ make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-
$ mkdir ../modules
$ make modules_install ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- INSTALL_MOD_PATH=../modules/
$ cd ../tools/mkimage/
$ ./imagetool-uncompressed.py ../../linux/arch/arm/boot/Image

Now insert a Raspbian installed SD Card, and run the command:

$ sudo rm /media/<boot-partition>/kernel.img
$ sudo mv kernel.img /media/<boot-partition>/
$ sudo rm -rf /media/<rootfs-partition>/lib/modules/
$ sudo rm -rf /media/<rootfs-partition>/lib/firmware/
$ cd ../../modules/
$ sudo cp -a lib/modules/ /media/<rootfs-partition>/lib/
$ sudo cp -a lib/firmware/ /media/<rootfs-partition>/lib/
$ sync

Now you can remove the SD Card and use it to boot Raspberry Pi with the new kernel.

Finally , here is a nice answer on stackexchange about How the Pi boots and another nice reference :

1. When the Raspberry Pi is first turned on, the ARM core is off, and the GPU core is on. At this point the SDRAM is disabled.
2. The GPU starts executing the first stage bootloader, which is stored in ROM on the SoC. The first stage bootloader reads the SD card, and loads the second stage bootloader (bootcode.bin) into the L2 cache, and runs it.
3. bootcode.bin enables SDRAM, and reads the third stage bootloader (loader.bin) from the SD card into RAM, and runs it.
4. loader.bin reads the GPU firmware (start.elf).
5. start.elf reads config.txt, cmdline.txt and kernel.img

loader.bin doesn’t do much. It can handle .elf files, and so is needed to load start.elf at the top of memory (ARM uses SDRAM from address zero). There is a plan to add elf loading support to bootcode.bin, which would make loader.bin unnecessary, but it’s a low priority (I guess it might save you 100ms on boot).

Here are some quick notes that I took while studying the SRTP from the standard document , they are not meant to be complete but rather a quick overview of the protocol.

   

        0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
     |V=2|P|X|  CC   |M|     PT      |       sequence number         | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                           timestamp                           | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |           synchronization source (SSRC) identifier            | |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
     |            contributing source (CSRC) identifiers             | |
     |                               ....                            | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                   RTP extension (OPTIONAL)                    | |
   +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   | |                          payload  ...                         | |
   | |                               +-------------------------------+ |
   | |                               | RTP padding   | RTP pad count | |
   +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
   | ~                     SRTP MKI (OPTIONAL)                       ~ |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   | :                 authentication tag (RECOMMENDED)              : |
   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |                                                                   |
   +- Encrypted Portion*                      Authenticated Portion ---+

   The encryption transforms defined in SRTP map the SRTP packet index
   and secret key into a pseudo-random keystream segment.  Each
   keystream segment encrypts a single RTP packet.  The process of
   encrypting a packet consists of generating the keystream segment
   corresponding to the packet, and then bitwise exclusive-oring that
   keystream segment onto the payload of the RTP packet to produce the
   Encrypted Portion of the SRTP packet.  In case the payload size is
   not an integer multiple of n_b bits, the excess (least significant)
   bits of the keystream are simply discarded.  Decryption is done the
   same way, but swapping the roles of the plaintext and ciphertext.

   We describe the process of computing authentication tags as follows.
   The sender computes the tag of M and appends it to the packet.  The
   SRTP receiver verifies a message/authentication tag pair by computing
   a new authentication tag over M using the selected algorithm and key,
   and then compares it to the tag associated with the received message.
   If the two tags are equal, then the message/tag pair is valid;
   otherwise, it is invalid and the error audit message "AUTHENTICATION
   FAILURE" MUST be returned.

   Mainly, the encryption process is as simple as XORing the payload  
   with a keystream segment .
   The keystream segment SHALL be the concatenation of the 128-bit output
   blocks of the AES cipher in the encrypt direction, using key k = k_e,
   in which the block indices are in increasing order.  Symbolically,
   each keystream segment looks like

      E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ...

   where the 128-bit integer value IV SHALL be defined by the SSRC, the
   SRTP packet index i, and the SRTP session salting key k_s, as below.

      IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)