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.
RASPBERRY PI 5 / YOCTO WORKBENCH
Choose the drivers you need. Understand the tradeoffs. Take a readable kernel fragment into your existing Scarthgap build.
Start configuringA 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
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
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
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.
Add the layer to BBLAYERS. Inspect show-recipes, show-appends and bitbake -e virtual/kernel. Stop if your actual provider, revision or machine differs.
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.
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.
These commands are for a supported Linux Yocto host, not Windows PowerShell. Read the steps before running anything.
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.
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 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.