Cross-Compiling Embedded Linux Kernel: A Step-by-Step Guide

Hello everyone, I am the Intelligence Guy~

Recently, I have been compiling the Linux kernel and have accumulated some summarizing experiences, which I would like to share here.

Below are some commands I used to compile the kernel. Of course, the prerequisite is to set up the cross-compilation toolchain in the environment variables, ensuring that the correct cross-compiler is available in your PATH or explicitly specified through the CROSS_COMPILE variable (for example, CROSS_COMPILE=aarch64-linux-gnu-). This is usually the first step in setting up the environment, and then you can execute the following commands:

my@my-vm:~/my-stm32mp2-linux$ export OUTPUT_BUILD_DIR=../build
my@my-vm:~/my-stm32mp2-linux$ make ARCH=arm64 O="$PWD/../build" my_stm32mp257x_defconfig

// Compile the kernel and device tree
my@my-vm:~/my-stm32mp2-linux$ make ARCH=arm64 Image vmlinux dtbs LOADADDR=0xC2000040 O="$PWD/../build" -j10

// Compile kernel modules
my@my-vm:~/my-stm32mp2-linux$ make ARCH=arm64 modules O="${OUTPUT_BUILD_DIR}" -j10
my@my-vm:~/my-stm32mp2-linux$ make ARCH=arm64 INSTALL_MOD_PATH="$PWD/../build/install_artifact" \
modules_install O="$PWD/../build" -j10

Basically, the cross-compilation process for the current embedded Linux kernel is quite similar, so there is no need to be afraid. The above commands are mainly used to build the kernel for ARM64 (AArch64) SoCs like the STM32MP257x.

Now, let me explain these commands in detail:

export OUTPUT_BUILD_DIR=../build

The main purpose of this command is to set an environment variable OUTPUT_BUILD_DIR, with the value of ../build (the build folder in the parent directory of the current directory ~/my-stm32mp2-linux). This variable is used to specify where all output files generated during the kernel build process (such as .o files, configuration files, final images, etc.) should be stored.

The benefits of doing this are numerous:

1. Separation of source code and build output: Keeps the source code directory (~/my-stm32mp2-linux) clean, containing only the original code.

2. Support for multiple build configurations: Allows for different target boards, configurations, or branches to use different output directories (such as ../build-mp257x-test, ../build-mp257x-prod) under the same source code.

3. Simplification of commands: Subsequent commands can use $OUTPUT_BUILD_DIR instead of the lengthy "$PWD/../build" path.

make ARCH=arm64 O="$PWD/../build" my_stm32mp257x_defconfig

This command is mainly used to configure the kernel, where:

ARCH=arm64: Specifies the target architecture as ARM64 (AArch64). This is necessary, as your host machine (my-vm) is likely x86/x86_64 architecture, which I won’t elaborate on here~

O="$PWD/../build": Specifies the build output directory (Out-of-tree build directory). $PWD represents the current working directory (~/my-stm32mp2-linux), so "$PWD/../build" is the ../build defined in the previous step. Make will use this directory as the “working directory” for the build, where all temporary files and final outputs are placed, keeping it clean, especially when I sometimes read the source code. It is consistent with the $OUTPUT_BUILD_DIR from the first step.

my_stm32mp257x_defconfig: This is a kernel configuration target. It specifies which predefined configuration file to use to initialize the kernel’s .config file. Typically, SoC vendors provide corresponding defconfig files for specific boards (like STM32MP257x-DK) in the arch/arm64/configs/<code> directory.

Executing this command will generate a .config file in the $O (../build) directory, which contains the kernel options (drivers, subsystem support, etc.) enabled for the my_stm32mp257x board and their default configurations. This serves as the basis for subsequent compilation.

make ARCH=arm64 Image vmlinux dtbs LOADADDR=0xC2000040 O="$PWD/../build" -j10

This command is mainly for compiling the kernel image and device tree binary files (Device Tree Blobs)..

Other parts are quite similar, but the key points are:

1)Image: This is a key target for ARM64 architecture. It compiles and generates an uncompressed kernel image file suitable for U-Boot’s booti command (usually located at $O/arch/arm64/boot/Image).

2)vmlinux: This is the compiled ELF format executable kernel file (uncompressed and unbundled), containing all symbol information. It is mainly used for debugging (e.g., with gdb), and the file is large (located at $O/vmlinux). Typically, in actual deployment, the Image (or compressed version Image.gz) is used instead of vmlinux.

3)dtbs: The compilation target for Device Tree Blobs. The device tree (.dts source files) describes the hardware information of specific development boards (memory layout, peripherals, GPIO, clocks, etc.).dtbs command compiles the .dts files into a binary format .dtb file that can be recognized by bootloaders (like U-Boot) and the kernel.

4)LOADADDR=0xC2000040: This value specifies the expected loading address of the kernel image Image in the target board’s physical memory (0xC2000040). This address must be consistent with your bootloader (U-Boot) settings and the board’s memory layout.

For the STM32MP25x platform, 0xC2000040 is a typical loading address for the kernel image. This value originates from the ARM Image Header specification (usually TEXT_OFFSET = 0x40) and platform-specific memory mapping. When compiling other similar kernels, this value is generally different, so you need to refer to the target board documentation or the configuration provided by the vendor.

Similarly, O="$PWD/../build": Specifies the build output directory, which must be consistent with the directory used in the configuration step (defconfig), otherwise Make will not find the .config file.

-j10: Enables parallel compilation, using 10 worker threads (jobs). The number 10 is typically set to 1-2 times the number of CPU cores on the host machine (depending on memory and I/O speed) to speed up the compilation (e.g., -j$(nproc)).

make ARCH=arm64 modules O="${OUTPUT_BUILD_DIR}" -j10 Finally, this command is basically for compiling loadable kernel modules. Mainly used in the file system:

modules: Compilation target. Components marked as M (Module) in the kernel configuration (most drivers, certain file systems, protocol stacks, etc.) will be compiled into .ko (Kernel Object) files. These modules can be dynamically loaded and unloaded after the kernel starts.

Similarly, O="${OUTPUT_BUILD_DIR}": Specifies the build output directory. Here, the environment variable OUTPUT_BUILD_DIR defined in the first step is used, which has the value of ../build. It is essential to ensure that the same output directory is used as in the previous steps.

make ARCH=arm64 INSTALL_MOD_PATH="$PWD/../build/install_artifact" modules_install O="$PWD/../build" -j10 This is the final step to install the compiled kernel modules into the specified directory structure.

INSTALL_MOD_PATH="$PWD/../build/install_artifact": Specifies the base path for module installation.

$PWD/../build/install_artifact: This means installing in a subdirectory named install_artifact under the output directory (../build). After executing this command, make will copy the compiled .ko files from the $O directory to the path specified by INSTALL_MOD_PATH, following the standard directory structure for kernel modules (mainly lib/modules/<kernel_version>). The final installation path will be:$PWD/../build/install_artifact/lib/modules/<kernel_version>/kernel/...

modules_install: Installation target.O="$PWD/../build", tells make where to find the compiled .ko files and kernel version information).

Finally

I have collected some embedded learning materials. Reply with 【1024】 in the public account to find the download link!

Recommended good articles, click the blue text to jump
☞ Collection | Comprehensive Linux Application Programming
☞ Collection | Learn Some Networking Knowledge
☞ Collection | Handwritten C Language

☞ Collection | Handwritten C++ Language
☞ Collection | Experience Sharing
☞ Collection | From Microcontrollers to Linux
☞ Collection | Power Control Technology
☞ Collection | Essential Mathematics for Embedded Systems
☞ Collection | MCU Advanced Collection

Finally

Leave a Comment Cancel reply