Master Embedded Linux: From Cross‑Compilation to Bootloader and RootFS

Learning Mindset

Before tackling each step, ask yourself why you are doing it and what you are actually doing; this macro‑and‑micro approach helps you adapt to any new platform, chip, or development environment without getting lost.

Four Core Parts of Embedded Linux System Porting

Cross‑Compilation Environment

Bootloader Selection and Migration

Kernel Configuration, Compilation, and Migration

Root Filesystem Creation

1. Building the Cross‑Compilation Environment

The cross‑compilation environment lets a host PC build binaries that run on a target board (e.g., ARM, MIPS, PowerPC). It is essential because embedded boards often lack the resources to compile large projects like the Linux kernel.

Why a cross environment?

Embedded hardware typically has low CPU frequency and limited memory; compiling on the host is much faster.

Different CPU architectures and instruction sets require a cross‑compiler to generate compatible binaries.

Hardware components

Development host (PC)

Target board (development board)

Connection media: serial cable, USB cable, or Ethernet

Software tools

Serial: PuTTY or similar terminal programs

USB: vendor‑provided download utilities (e.g., DNW for Samsung chips)

Network: TFTP for fast file transfer, NFS for mounting remote rootfs, Samba for Windows‑Linux file sharing

Typical workflow: use TFTP to load bootloader, kernel, and rootfs directly into RAM for testing, avoiding repeated Flash writes.

2. Building a Cross‑Toolchain

Three common methods:

Manually compile and install each required library and source – suitable for deep learning but complex.

Use crosstool‑ng script to automate a one‑step build – recommended for most users.

Download a pre‑built toolchain – easiest but may lack flexibility and cause compatibility issues.

When using crosstool‑ng, install prerequisites:

sudo apt-get install g++ libncurses5-dev bison flex texinfo automake libtool patch gcj cvs gawk

Typical configuration steps:

Set source package path and installation prefix.

Specify target architecture (e.g., ARCH ?= arm).

Set CROSS_COMPILE to the appropriate prefix (e.g., arm-cortex_a8-linux-gnueabi-).

Adjust parallel build jobs, disable Java compiler, then build.

Add the toolchain to PATH and verify with arm‑cortex_a8-linux‑gnueabi-gcc --version.

3. Bootloader Selection and Migration

A bootloader runs before the OS kernel, initializing hardware and loading the kernel into RAM. Without it, the system cannot start.

Common bootloaders include U‑Boot (universal, supports many architectures), Das U‑Boot, and others. U‑Boot is open‑source, GPL‑licensed, and widely used in embedded Linux.

U‑Boot directory structure (key sub‑directories) board: board‑specific files (SDRAM, FLASH drivers) common: architecture‑independent code cpu: CPU‑specific files driver: generic device drivers include: header files, especially configs for board configuration net: network support (TFTP, NFS, etc.) tools: utilities for creating S‑record and binary images

Boot modes

Startup mode – normal operation, loads kernel from FLASH to SDRAM.

Download mode – used during development to transfer kernel or rootfs via serial, USB, or network.

Boot process example (S5PC100)

CPU reset, execute iROM code.

iROM decides boot source (USB or NAND) based on pin configuration.

iROM initializes USB and waits for PC download.

PC uses DNW to download SDRAM initialization code, which runs and sets up SDRAM.

iROM then downloads the bootloader into SDRAM and executes it.

After the bootloader runs, it loads the kernel, which mounts the root filesystem and starts the init process.

4. Kernel Configuration, Compilation, and Migration

Typical steps (using an ARM Cortex‑A8 board as example):

Copy the appropriate defconfig: cp arch/arm/configs/s5pc100_defconfig .config Run make menuconfig to verify and optionally adjust options; save the configuration.

Set ARCH ?= arm and CROSS_COMPILE ?= arm-cortex_a8-linux-gnueabi- in the top‑level Makefile.

Build the compressed kernel image: make zImage (produces arch/arm/boot/zImage).

Configure boot arguments for network boot, e.g.:

setenv bootcmd 'tftp 20008000 zImage; go 20008000'
setenv bootargs 'nfs nfsroot=192.168.1.199:/source/rootfs ip=192.168.1.200 init=/linuxrc ttySAC0,115200'

Save the environment, reset the board, and verify that the kernel boots from TFTP/NFS.

5. Root Filesystem Creation

In Linux, everything is a file; the root filesystem provides the hierarchical view of devices, binaries, and configuration files. For embedded systems, common filesystem types include:

Flash‑oriented: JFFS2, YAFFS, CRAMFS, ROMFS

Memory‑based: RAMDISK, tmpfs, ramfs

Network‑based: NFS, Samba

Key characteristics:

JFFS2 – log‑structured, supports compression, suitable for NOR flash.

YAFFS – optimized for NAND flash, no compression, fast mount.

CRAMFS – read‑only, high compression ratio, good for static data.

ROMFS – simple, read‑only, enables XIP execution.

RAM‑based filesystems are useful for temporary data ( /tmp, /var) and fast access, but data is lost on power‑off. tmpfs can be size‑limited and swapped, whereas ramfs grows until memory exhaustion.

Creating a rootfs typically involves populating a directory tree with required binaries, libraries, and configuration files, then packaging it (e.g., using make install into a staging directory) and deploying via NFS, TFTP, or flashing to the board.

Conclusion

By mastering the four stages—cross‑compilation environment, bootloader, kernel, and root filesystem—you can reliably port Linux to any embedded board, understand the underlying reasons for each step, and troubleshoot issues such as network configuration, toolchain mismatches, or filesystem incompatibilities.