Pi Kernel Lab GitHub ↗

RASPBERRY PI 5 / YOCTO WORKBENCH

A smaller kernel.
A clearer starting point.

Choose the drivers you need. Understand the tradeoffs. Take a readable kernel fragment into your existing Scarthgap build.

Start configuring

A fragment is a request, not a resolved kernel. Kconfig dependencies can change your choices. Normalize and compare the final .config in BitBake before building. Nothing runs on or detects your board.

01 / MAKE YOUR CHOICES

Your kernel, thoughtfully configured

Keep default Omit the symbol. Preserve the build's existing policy.

Built-in · y Compile into the kernel. Available before modules load.

Module · m Compile a loadable module. Package and load it separately.

Disabled · n Request “not set”. Dependencies may re-enable it.

03 / CHECK WHAT SURVIVED

Compare with the real result

After BitBake normalization, choose the full B/.config from your build. The file stays in this browser. This checks requested values only, including the automatic MODULES=y; it does not validate pins, solve Kconfig or prove a bootable image.

No final .config loaded.

“Absent” is not accepted as n: an unknown or invisible symbol may disappear. Resolve all mismatches in your real build.

04 / FROM FRAGMENT TO IMAGE

Know the next step, not just the next checkbox

01

Start from a working image

Use the pinned Pi 5 Scarthgap setup. Keep recovery media and a known-good image. This is not Raspberry Pi OS, Ubuntu's kernel settings, or a generic linux-yocto guide.

02

Integrate, then inspect

Add the layer to BBLAYERS. Inspect show-recipes, show-appends and bitbake -e virtual/kernel. Stop if your actual provider, revision or machine differs.

03

Let Kconfig decide

Inspect listtasks. For this provider use kernel_configme and kernel_configcheck; review logs and compare the final .config. A checkbox cannot resolve selects, conflicts or modular parent limits.

04

Build a coherent image

Rebuild the kernel and image. Include the modules and needed firmware, userspace and overlays. Keep kernel, modules and device trees matched. Test on real hardware; this app never flashes storage.

Full beginner integration guide & copyable commands

These commands are for a supported Linux Yocto host, not Windows PowerShell. Read the steps before running anything.

What y, m and n cannot do

A built-in driver is part of the kernel. A module is a separate file that must be installed in the image and loaded when needed. A bool symbol is an on/off subfeature and cannot be m. Neither choice installs firmware, accepts a license, changes a device tree, enables a bus in config.txt, or adds BlueZ/ALSA tools.

Full .config ≠ defconfig ≠ fragment

A full .config is the normalized result of many inputs. A defconfig is a starting configuration; this BSP uses bcm2712_defconfig. Your small .cfg fragment requests only changes. Keep default means no request, not “disable”. Do not rename a full .config to .cfg and assume it is a safe minimal fragment.

REPRODUCIBLE INPUTS / HONEST BOUNDARIES

The source is the contract

The 12 curated symbol names and bool/tristate types were checked against the pinned Raspberry Pi downstream tree. The default recipe uses that tree plus Yocto kernel-cache features and BSP fragments, not vanilla upstream Linux. The inspected recipe/include contain no additional .patch URIs; other layers can add patches.

Outside scope: 6.1/6.12 recipes, linux-yocto, other BSP revisions, boards other than Pi 5, arbitrary symbols, dependency solving and live hardware detection. No full BitBake build, image validation or physical Pi boot is claimed. See the repository for exactly which source and browser checks were run.