Cross-compiling the kernel

• When you compile a Linux kernel for another CPU architecture
  • Much faster than compiling natively, when the target system is much slower than your GNU/Linux workstation.
  • Much easier as development tools for your GNU/Linux workstation are much easier to find.
  • To make the difference with a native compiler, cross-compiler executables are prefixed by the name of the target system, architecture and sometimes library. Examples: mips-linux-gcc, the prefix is mips-linux-arm-linux-gnueabi-gcc, the prefix is arm-linux-gnueabi-

Specifying cross-compilation

The CPU architecture and cross-compiler prefix are defined through the ARCH and CROSS_COMPILE variables in the toplevel Makefile.

• ARCH is the name of the architecture. It is defined by the name of the subdirectory in arch/ in the kernel sources
  • Example: arm if you want to compile a kernel for the arm architecture.
• CROSS_COMPILE is the prefix of the cross compilation tools
  • Example: arm-linux- if your compiler is arm-linux-gcc

Two solutions to define ARCH and CROSS_COMPILE:

• Pass ARCH and CROSS_COMPILE on the make command line:

make ARCH=arm CROSS_COMPILE=arm-linux- ...

Drawback: it is easy to forget to pass these variables when you run any make command, causing your build and configuration to be screwed up.

• Define ARCH and CROSS_COMPILE as environment variables: export ARCH=arm export CROSS_COMPILE=arm-linux-

Drawback: it only works inside the current shell or terminal. You could put these settings in a file that you source every time you start working on the project. If you only work on a single architecture with always the same toolchain, you could even put these settings in your ~/.bashrc file to make them permanent and visible from any terminal.

Predefined configuration files

• Default configuration files available, per board or per-CPU family
  • They are stored in arch//configs/, and are just minimal .config files
  • This is the most common way of configuring a kernel for embedded platforms
• Run make help to find if one is available for your platform
• To load a default configuration file, just run make acme_defconfig
  • This will overwrite your existing .config file!
• To create your own default configuration file
  • make savedefconfig, to create a minimal configuration file
  • mv defconfig arch//configs/myown_defconfig

Configuring the kernel

• After loading a default configuration file, you can adjust the configuration to your needs with the normal xconfig, gconfig or menuconfig interfaces

• As the architecture is different from your host architecture

  • Some options will be different from the native configuration (processor and architecture specific options, specific drivers, etc.)
  • Many options will be identical (filesystems, network protocols, architecture-independent drivers, etc.)

Device Tree

• Many embedded architectures have a lot of non-discoverable hardware.
• Depending on the architecture, such hardware is either described using C code directly within the kernel, or using a special hardware description language in a Device Tree.
• ARM, PowerPC, OpenRISC, ARC, Microblaze are examples of architectures using the Device Tree.
• A Device Tree Source, written by kernel developers, is compiled into a binary Device Tree Blob, passed at boot time to the kernel.
  • There is one different Device Tree for each board/platform supported by the kernel, available in arch/arm/boot/dts/.dtb.
• The bootloader must load both the kernel image and the Device Tree Blob in memory before starting the kernel.

Customize your board device tree

Often needed for embedded board users:

• To describe external devices attached to non-discoverable busses (such as I2C) and configure them.
• To configure pin muxing: choosing what SoC signals are made available on the board external connectors.
• To configure some system parameters: flash partitions, kernel command line (other ways exist)
• Useful reference: Device Tree for Dummies, Thomas Petazzoni (Apr. 2014): http://j.mp/1jQU6NR