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
- They are stored in arch/
- 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.
- There is one different Device Tree for each board/platform supported by the kernel, available in arch/arm/boot/dts/
- 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