Kernel Configuration and Custom Build

Modified: Mar. 14, 2026

Published: Jan. 31, 2026

Become Contributor Expert Support

The stock Raspberry Pi kernel includes drivers for thousands of devices you will never connect and subsystems your embedded application will never use. Every extra module increases boot time, memory usage, and attack surface. In this lesson, you will clone the official Raspberry Pi kernel source, learn how the Kconfig system organizes over 15,000 configuration options, and use menuconfig to strip the kernel down to exactly what your board needs. The result is a custom kernel image that boots in under 4 seconds, giving you a fast, lean foundation for every project in this course. #LinuxKernel #Menuconfig #EmbeddedLinux

What We Are Building

Build specifications:

Key Subsystems to Disable

  Menuconfig Decision: Built-in vs Module
  ──────────────────────────────────────────
  [*] = Built-in (compiled into kernel)
      + Available immediately at boot
      + No insmod step needed
      - Larger kernel image

  [M] = Module (separate .ko file)
      + Loaded only when needed
      + Smaller kernel image
      - Requires module load step

  [ ] = Disabled (not compiled at all)
      + Saves flash and RAM
      - Cannot be used without recompiling

  For fast boot: use [*] for essential
  drivers, [ ] for everything else.

Cloning the Kernel Source

The Raspberry Pi Foundation maintains a fork of the Linux kernel with patches and drivers specific to Broadcom SoCs. This is the kernel you should use for any Pi project, as it includes support for hardware that has not yet been merged into the mainline kernel.

  Kernel Source Tree (simplified)
  ──────────────────────────────────────────
  rpi-linux/
  ├── arch/arm64/       ARM64 platform code
  │   ├── boot/dts/     Device tree sources
  │   └── configs/      defconfig files
  ├── drivers/          All device drivers
  │   ├── gpio/
  │   ├── i2c/
  │   ├── spi/
  │   └── usb/
  ├── kernel/           Core scheduler, IPC
  ├── mm/               Memory management
  ├── net/              Networking stack
  ├── fs/               Filesystems
  ├── include/          Header files
  ├── Kconfig           Top-level config
  └── Makefile          Top-level build

Clone the repository with the rpi-6.6.y branch:

cd ~/rpi-embedded
git clone --depth 1 --branch rpi-6.6.y \
  https://github.com/raspberrypi/linux.git rpi-linux
cd rpi-linux

The --depth 1 flag creates a shallow clone, downloading only the latest commit rather than the full history. This reduces the download from several gigabytes to roughly 200 MB.

Check which branch you are on:

git branch

Expected output:

* rpi-6.6.y

The kernel source tree is organized into well-defined directories. Here are the most important ones for embedded work:

Key directories for this lesson:

• arch/arm64/configs/ contains default configuration files (defconfigs) for various ARM64 platforms.
• arch/arm64/boot/dts/broadcom/ contains device tree source files for Raspberry Pi boards.
• drivers/ contains all hardware drivers organized by subsystem.
• scripts/ contains build helper scripts, including kconfig tools.
• init/ contains the code that runs during kernel initialization, including the init process launcher.

Understanding Kconfig

The Linux kernel has over 15,000 configuration options. The system that manages them is called Kconfig, and understanding it is essential for anyone building custom kernels.

Every directory in the kernel source contains a Kconfig file that defines the configuration options for that subsystem. These files use a simple language to declare options, their types, defaults, and dependencies. For example, a simplified entry looks like:

config SPI
    bool "SPI support"
    help
      The Serial Peripheral Interface (SPI) bus is used to
      communicate with sensors, displays, and other peripherals.

The configuration system works with three key files:

The workflow is: start from a defconfig that is close to your target hardware, then customize it. For the Raspberry Pi Zero 2 W, the closest defconfig is bcm2711_defconfig:

cd ~/rpi-embedded/rpi-linux
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bcm2711_defconfig

This generates a .config file with sensible defaults for Broadcom BCM27xx boards. You can examine it:

wc -l .config

You will see roughly 8,000 to 10,000 lines, each representing a configuration choice. Lines starting with CONFIG_ set a value; lines starting with # CONFIG_ explicitly disable an option.

Look at a few entries:

grep CONFIG_SPI .config
grep CONFIG_SOUND .config
grep CONFIG_BT .config

Using menuconfig

While you could edit .config by hand, the preferred method is menuconfig, a text-based graphical interface that lets you navigate options by category, search for symbols, and see dependency information.

Install the required library:

sudo apt install -y libncurses-dev flex bison libssl-dev

Launch menuconfig:

cd ~/rpi-embedded/rpi-linux
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig

A blue-and-gray interface appears in your terminal. Here are the key controls:

The main menu is organized into top-level categories:

  General setup  --->
  Processor type and features  --->
  Power management and ACPI options  --->
  Bus options  --->
  Networking support  --->
  Device Drivers  --->
  File systems  --->
  Security options  --->
  Cryptographic API  --->
  Library routines  --->

To find a specific option, press / and type the config symbol name (without the CONFIG_ prefix). For example, searching for SOUND will show you where the sound subsystem option lives, what it depends on, and what selects it.

Stripping the Kernel

Now comes the most impactful part of this lesson: disabling subsystems that your embedded project does not need. Each disabled subsystem means less code to compile, a smaller kernel image, less memory usage, and faster boot time.

Navigate through menuconfig and disable the following. For each one, the location in the menu tree and the config symbol are provided.

Sound (CONFIG_SOUND)

Device Drivers  --->
  <*> Sound card support  --->

Press N on “Sound card support” to disable the entire sound subsystem. The Pi Zero 2 W has no onboard audio codec, and our embedded application does not play audio.

Bluetooth (CONFIG_BT)

Networking support  --->
  Bluetooth subsystem support  --->

Press N on “Bluetooth subsystem support”. Although the Zero 2 W has Bluetooth hardware, we are not using it in this project. You can re-enable it later.

USB Gadget (CONFIG_USB_GADGET)

Device Drivers  --->
  USB support  --->
    USB Gadget Support  --->

Press N on “USB Gadget Support”. USB Gadget mode lets the Pi act as a USB device (like a serial port or Ethernet adapter when connected to a host). We are using the Pi as a standalone embedded system, so this is not needed.

Network Filesystems (CONFIG_NETWORK_FILESYSTEMS)

File systems  --->
  Network File Systems  --->

Press N on “Network File Systems” to disable NFS, CIFS/SMB, and other network-mounted filesystems. Our root filesystem is on the SD card.

Virtualization (CONFIG_VIRTUALIZATION)

Virtualization  --->

Press N on the top-level “Virtualization” entry. KVM and other hypervisor support is irrelevant for a 512 MB embedded board.

Multimedia / V4L2 (CONFIG_MEDIA_SUPPORT)

Device Drivers  --->
  Multimedia support  --->

Press N on “Multimedia support”. This disables the entire Video4Linux2 framework, camera drivers, and TV tuner support.

Wireless (CONFIG_WLAN)

Device Drivers  --->
  Network device support  --->
    Wireless LAN  --->

Press N on “Wireless LAN”. We will re-enable this in a later lesson when we configure WiFi. For now, a serial-only system boots faster without wireless drivers.

Additional options to disable

You can also turn off these to further reduce size:

# In menuconfig, search (/) for each symbol and disable:
# CONFIG_STAGING        - experimental drivers
# CONFIG_DRM            - Direct Rendering Manager (GPU/display)
# CONFIG_INPUT_TOUCHSCREEN - touchscreen drivers
# CONFIG_INPUT_JOYSTICK - joystick support
# CONFIG_HID            - Human Interface Device (USB keyboards, mice)

After making all these changes, save and exit menuconfig.

You can verify your changes by comparing against the original defconfig:

scripts/diffconfig .config.backup .config

This shows a concise list of what changed. You should see dozens of options switching from y or m to n.

Module vs Built-in

Every kernel option that represents a driver or feature can typically be set to one of three states:

For an embedded system focused on fast boot times, the decision is straightforward:

Boot-critical drivers should be built-in (y). The SD card driver (CONFIG_MMC), the filesystem driver (CONFIG_EXT4_FS), and the serial console driver (CONFIG_SERIAL_AMBA_PL011) must all be built-in. If these are modules, the kernel cannot mount the root filesystem or print to the console during early boot, because the module files live on the root filesystem that has not been mounted yet.

Optional drivers can be modules (m). If you plan to occasionally use a USB Ethernet adapter, compile its driver as a module. It only takes up space on disk, not in RAM, and you load it only when needed.

Unused drivers should be disabled (n). This is where the biggest gains come from. Every disabled driver is code that does not need to be compiled, loaded, or initialized.

For this lesson, set the following to built-in:

# These should be y (built-in), not m
# Search for each in menuconfig and set to *
CONFIG_MMC=y
CONFIG_MMC_BCM2835=y
CONFIG_EXT4_FS=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_I2C=y
CONFIG_I2C_BCM2835=y
CONFIG_SPI=y
CONFIG_SPI_BCM2835=y
CONFIG_GPIO_BCM_VIRT=y
CONFIG_GPIOLIB=y

You can also set these directly in .config if you prefer not to navigate menuconfig again, but always run make olddefconfig afterward to resolve any dependency issues:

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- olddefconfig

This command reads .config, applies Kconfig dependency rules, and resolves any conflicts by choosing default values for newly required options.

Building the Kernel

With the configuration finalized, it is time to compile. The build process produces several artifacts: the kernel image, loadable modules, and device tree blobs.

Set up environment variables for convenience:

export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
export KERNEL_SRC=~/rpi-embedded/rpi-linux

Start the build:

cd $KERNEL_SRC
make -j$(nproc) Image.gz modules dtbs

The -j$(nproc) flag runs as many parallel compiler processes as your host has CPU cores. On a modern 8-core machine, the full kernel build takes roughly 5 to 15 minutes, depending on how much you disabled.

Let us break down what each target produces:

Verify the build succeeded:

ls -lh arch/arm64/boot/Image.gz
ls -lh arch/arm64/boot/Image

Compare the sizes. Image.gz is typically 5 to 8 MB for a stripped kernel, while Image might be 15 to 25 MB. We use Image.gz to save space on the boot partition and reduce SD card read time.

Check the device tree blob for the Zero 2 W:

ls -lh arch/arm64/boot/dts/broadcom/bcm2710-rpi-zero-2-w.dtb

If you configured any options as modules, you need to collect them:

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
  INSTALL_MOD_PATH=~/rpi-embedded/modules_out modules_install

This installs modules into ~/rpi-embedded/modules_out/lib/modules/<kernel-version>/.

Deploying to the SD Card

Insert the SD card you prepared in Lesson 1 and mount both partitions:

sudo mount /dev/sdX1 /mnt/boot
sudo mount /dev/sdX2 /mnt/rootfs

Replace the stock kernel with your custom build:

1. Back up the existing kernel

   sudo cp /mnt/boot/kernel8.img /mnt/boot/kernel8.img.stock

2. Copy the new kernel image

   sudo cp $KERNEL_SRC/arch/arm64/boot/Image.gz /mnt/boot/kernel8.img

   We copy Image.gz as kernel8.img because that is the filename specified in config.txt. The GPU firmware does not care about the actual format; it detects whether the file is compressed or not.

3. Copy the device tree blob

   sudo cp $KERNEL_SRC/arch/arm64/boot/dts/broadcom/bcm2710-rpi-zero-2-w.dtb /mnt/boot/

4. Copy device tree overlays

   sudo cp $KERNEL_SRC/arch/arm64/boot/dts/overlays/*.dtb* /mnt/boot/overlays/

5. Install kernel modules (if any)

   sudo cp -a ~/rpi-embedded/modules_out/lib/modules/* /mnt/rootfs/lib/modules/

   If you built everything as built-in, this directory may be nearly empty, which is expected.

6. Unmount and sync

   sudo umount /mnt/boot
   sudo umount /mnt/rootfs
   sync

Measuring Boot Time

One of the most satisfying parts of building a custom kernel is seeing the boot time improvement. To measure it accurately, you need timestamps on every kernel log message.

Edit cmdline.txt on the boot partition to add the printk.time=1 parameter. Your full cmdline.txt should look like:

console=serial0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait init=/sbin/init printk.time=1

Boot the Pi and capture the serial output. In picocom, you can log to a file:

picocom -b 115200 --logfile boot_log.txt /dev/ttyUSB0

After the boot completes, exit picocom (press Ctrl+A then Ctrl+X) and examine the log. Each line now has a timestamp in seconds:

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 6.6.x ...
...
[    0.512345] mmc0: SDHCI controller on fe340000.mmc ...
[    1.023456] mmc0: new high speed SDHC card at address 0001
[    1.034567] mmcblk0: mmc0:0001 SD 14.8 GiB
...
[    1.890123] EXT4-fs (mmcblk0p2): mounted filesystem ...
[    1.900000] VFS: Mounted root (ext4 filesystem) ...
...
[    2.100000] Run /sbin/init as init process

The timestamp on the “Run /sbin/init” line tells you the kernel boot time. For a stripped kernel, you should see this well under 3 seconds, compared to 5 or more seconds with the stock kernel.

To analyze the boot time more systematically, run dmesg on the Pi after boot:

dmesg | head -5
dmesg | tail -10

You can also extract the total kernel initialization time:

dmesg | grep "Run /sbin/init"

For a more detailed breakdown, you can identify the slowest subsystems:

# Show the 10 largest time gaps between consecutive messages
dmesg | awk '{print $1}' | tr -d '[]' | awk 'NR>1{printf "%.6f %s\n", $1-prev, $1} {prev=$1}' | sort -rn | head -10

This helps you identify which driver or subsystem is consuming the most time during boot. If a particular driver takes 500 ms to initialize and you do not need it, that is a strong candidate for disabling.

Kernel Command Line Parameters

The kernel command line (stored in cmdline.txt on the Raspberry Pi) controls kernel behavior at boot time. Understanding these parameters gives you fine-grained control over how the system starts.

Here are the most important parameters for embedded Linux work:

You can combine parameters for different scenarios:

console=serial0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait init=/sbin/init printk.time=1 loglevel=7

console=serial0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait init=/sbin/init quiet loglevel=3

console=serial0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait init=/bin/hello_linux quiet loglevel=0

Saving Your Configuration

After investing time in a carefully tuned kernel configuration, you should save it in a reproducible format. The .config file contains thousands of lines, many of which are just defaults. A defconfig is a minimal representation that only stores the options you explicitly set.

Save your configuration as a defconfig:

cd $KERNEL_SRC
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig

This creates a file called defconfig in the kernel build root. Rename and save it:

cp defconfig arch/arm64/configs/rpi_zero2w_minimal_defconfig

Now anyone (including your future self) can reproduce your exact configuration:

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- rpi_zero2w_minimal_defconfig

This is the standard practice in embedded Linux teams: check your defconfig into version control and rebuild from it on any machine.

Exercises