Embedded Linux using Yocto Part 4

Learn how bitbake uses the provides list to select the correct recipe, with parsing, caching, and alternative names, and explore offline builds before diving into kernel recipes.

Demonstrate how aliases via provides let you build a recipe using an alternative name, such as my lwl, and verify builds with bitbake and clean cache.

Explore how bitbake namespaces separate build time targets from runtime packages, and learn to build a package by its recipe or add it to the image install variable.

Explore how virtual targets use provides and aliases to declare functionality and resolve dependencies with preferred providers, enabling flexible bootloader and library choices like grub, u-boot, and glibc.

Explain how preferred provider selects a recipe when multiple providers exist, using virtual kernel and machine configurations, and show overriding with local.conf to pick a specific provider.

Explore the preferred version mechanism in Yocto, using preferred_version and wildcards to select among multiple recipe versions, with practical examples like my hello 0.1 vs 0.2 in local.conf.

Learn how to use compatible_machine and compatible_host to restrict recipe builds to specific targets, ensuring a recipe like hello runs only on chemo arm and not on chemo x86.

Use compatible_machine to restrict a recipe to specific machines, such as chemo x86 or x86_64, so builds run only on supported targets and skip incompatible architectures.

Explore using compatible host to prevent building recipes for incompatible machines, and distinguish between compatible machine and compatible host in kernel recipes, with chemo arm and x86_64 Linux examples.

Perform offline builds with Yocto by populating a downloads directory, generating tarballs of sources, and using BitBake with run-only fetch to replicate builds offline.

Disable auto rev in recipes and set a fixed source hash for offline builds. Set no network to one in local conf so bitbake runs without internet.

Master Yocto kernel development by managing kernel sources, configurations, patches, and Linux kernel recipes in Poky, and verify the image kernel with preferred version and bitbake.

Compare using the Linux Yocto kernel with a fully custom kernel recipe in Yocto, and learn to set the preferred provider and version in machine files.

Create a custom kernel recipe in Yocto by specifying a kernel source URI, patches, and a dev config; inherit the kernel class, configure with dev config, and compile the kernel.

Explore the workdir of the kernel recipe, inspect the image and boot folders, review packages and modules, then build the Linux image and verify a 5.7 kernel is present.

learn to customize a linux kernel in Yocto using bitbake menuconfig, modify config_local_version, save the new defconfig with savedefconfig, and rebuild the image to persist changes.

Write a kernel recipe that pulls the mainline kernel from a git repository, uses the latest revision, and builds an image to verify it matches the tarball.

Patch the Linux kernel in a Yocto project by creating and applying a patch that prints a boot message during startup, then build the image with bitbake.

Learn how yocto linux kernel recipes manage kernel sources and configuration data across multiple platforms, using config map configuration fragments to handle diverse kernel options instead of multiple defconfigs.

Customize a Linux Yocto kernel recipe by creating an append file in your custom layer, then apply patches and adjust configuration to use the 5.2 kernel.

Learn to create and apply patches in Yocto by updating the source uri with append, using dev shell, and verifying patch success during bitbake.

Use an in-tree def config file by invoking the k build dev config for your machine to import a config from arc/configs, illustrating Raspberry Pi dev configs and config fragments.

Explore the difference between normal Linux kernel repositories and Yocto kernel repositories, highlighting two git repos: one for the kernel source code and one for kernel metadata.

learn how package groups in Yocto reduce duplication by grouping output packages from recipes into one package, adding the group to your image, how to create a package group.

Package group recipes do not compile or produce outputs. They declare dependencies that trigger the build system to process the referenced package recipes and assemble the final package group.

Learn to use package groups in the poky layer to automatically install tools like gdb, gdbserver, strace, and mtrace via image install of package group core-boot.

Inherit the package group class and list runtime dependencies to include VLC, util, lspci, and lsusb in a single package group; test with bitbake.

Explain how a simple package group recipe uses the defense variable and the recommends list to extend usability, and how to control it with no recommendations or package exclude.

Explore hard runtime dependencies, rdepends, versus soft runtime dependencies, rrecommends, in Yocto. Build success relies on rdepends; rrecommends extend functionality but are not required for building.

Demonstrate creating multiple package groups in a single recipe, list them with the packages variable, define runtime dependencies with depends and requirements, and add each group to the image install.

Create an out-of-tree module recipe using the module class, copy the external hello module, and configure kernel source paths to build and package the kernel module.

Build out of tree kernel modules in Yocto with a module class recipe, and explore how machine essential extra defense and related package groups shape rootfs loading.

Set the kernel_module_autoload variable to the module name to auto load on boot. The build system writes a hello.conf in modules-load.d, and the init script loads the module at startup.