%poky; ] > In addition to configuration fragments and patches, the Yocto Project kernel tools support rich metadata that you can use to define complex policies and BSP support. The purpose of the metadata and the tools to manage it, known as the kern-tools (kern-tools-native_git.bb), is to assist in managing the complexity of the configuration and sources in support of multiple Board Support Packages (BSPs) and Linux kernel types. In particular, the kernel tools allow you to specify only what you must, and nothing more. Where a complete Linux kernel .config includes all the automatically selected CONFIG options, the configuration fragments only need to contain the highest level visible CONFIG options as presented by the Linux kernel menuconfig system. This reduces your maintenance effort and allows you to further separate your configuration in ways that make sense for your project. A common split is policy and hardware. For example, all your kernels might support the proc and sys filesystems, but only specific boards will require sound, USB, or specific drivers. Specifying these individually allows you to aggregate them together as needed, but maintain them in only one place. Similar logic applies to source changes. Original Text: In addition to configuration fragments and patches, the Yocto Project kernel tools support rich metadata which you can use to define complex policies and BSP support. The purpose of the metadata and the tools to manage it, known as the kern-tools (kern-tools-native_git.bb), is to assist in managing the complexity of the configuration and sources in support of multiple BSPs and Linux kernel types. In particular, the kernel tools allow you to specify only what you must, and nothing more. Where a complete Linux kernel .config includes all the automatically selected CONFIG options, the configuration fragments only need to contain the highest level visible CONFIG options as presented by the Linux kernel menuconfig system. This reduces your maintenance effort and allows you to further separate your configuration in ways that make sense for your project. A common split is policy and hardware. For example, all your kernels may support the proc and sys filesystems, but only specific boards will require sound, usb, or specific drivers. Specifying these individually allows you to aggregate them together as needed, but maintain them in only one place. Similar logic applies to source changes.

The metadata provided with any linux-yocto style Linux kernel sources must define a BSP that corresponds to the definition laid out in the recipe. A BSP consists of an aggregation of kernel policy and hardware specific feature enablement. This can be influenced from within the recipe. Every linux-yocto style recipe must define the following variable: KMACHINE KMACHINE is typically set to the same value as used within the recipe-space BSP definition, such as "routerstationpro" or "fri2". However, multiple BSPs can reuse the same KMACHINE name if they are built using the same BSP description. See section 3.3.5 for more information. The meta-intel "fri2" and "fri2-noemgd" are good examples of such a situation where each specifies KMACHINE as "fri2". They may optionally define the following variables: KBRANCH KERNEL_FEATURES KBRANCH_DEFAULT LINUX_KERNEL_TYPE KBRANCH_DEFAULT defines the default source branch within the Linux kernel source repository to be used to build the Linux kernel. It is used as the default value for KBRANCH which may define an alternate branch, typically with a machine override, such as: KBRANCH_fri2 = "standard/fri2" Unless you specify otherwise, KBRANCH_DEFAULT is initialized to "master". LINUX_KERNEL_TYPE defines the kernel type to be used in assembling the configuration and defaults to "standard" if you do not specify otherwise. Together with KMACHINE, this defines the search arguments used by the Yocto Project Linux kernel tools to find the appropriate description within the metadata with which to build out the sources and configuration. The linux-yocto recipes define "standard", "tiny", and "preempt-rt" kernel types. See section 3.3.4 for more inforation on kernel types. During the build, the kern-tools will search for the BSP description file that most closely matches the KMACHINE and LINUX_KERNEL_TYPE passed in from the recipe. It will use the first BSP description it finds matching both variables. Failing that it will issue a warning such as the following: WARNING: Can't find any BSP hardware or required configuration fragments. WARNING: Looked at meta/cfg/broken/fri2-broken/hdw_frags.txt and meta/cfg/broken/fri2-broken/required_frags.txt in directory: meta/cfg/broken/fri2-broken In this example, KMACHINE was set to "fri2-broken" and LINUX_KERNEL_TYPE was set to "broken". It will then search first for the KMACHINE and then for the LINUX_KERNEL_TYPE. If it cannot find a partial match, it will use the sources from the KBRANCH and any configuration specified in the SRC_URI. KERNEL_FEATURES can be used to include features (configuration fragments, patches, or both) that are not already included by the KMACHINE and LINUX_KERNEL_TYPE combination. To include a feature specified as "features/netfilter.scc" for example, specify: KERNEL_FEATURES += "features/netfilter.scc" To include a feature called "cfg/sound.scc" just for the qemux86 machine, specify: KERNEL_FEATURES_append_qemux86 = "cfg/sound.scc" The value of the entries in KERNEL_FEATURES are dependent on their location within the metadata itself. The examples here are taken from the linux-yocto-3.4 repository where "features" and "cfg" are subdirectories of the metadata directory. For details, see section 3.3. The processing of the these variables has evolved some between the 0.9 and 1.3 releases of the Yocto Project and associated kern-tools sources. The descriptions in this section are accurate for 1.3 and later releases of the Yocto Project. Original Text. The metadata provided with any linux-yocto style Linux kernel sources must define a BSP that corresponds to the definition laid out in the recipe. A BSP consists of an aggregation of kernel policy and hardware specific feature enablement. This can be influenced from within the recipe. Every linux-yocto style recipe must define the following variables: KMACHINE KMACHINE is typically set to the same value as used within the recipe-space BSP definition, such as "routerstationpro" or "fri2". However, multiple BSPs can reuse the same KMACHINE name if they are built using the same BSP description (see 3.3.5). The meta-intel "fri2" and "fri2-noemgd" are good examples of such a situation where each specifies KMACHINE as "fri2". They may optionally define the following variables: KBRANCH KERNEL_FEATURES KBRANCH_DEFAULT LINUX_KERNEL_TYPE KBRANCH_DEFAULT defines the default source branch within the Linux kernel source repository to be used to build the Linux kernel. It is used as the default value for KBRANCH which may define an alternate branch, typically with a machine override, such as: KBRANCH_fri2 = "standard/fri2" Unless you specify otherwise, KBRANCH_DEFAULT is initialized to "master". LINUX_KERNEL_TYPE defines the kernel type to be used in assembling the configuration and defaults to "standard" if you do not specify otherwise. Together with KMACHINE, this defines the search arguments used by the Yocto Project Linux kernel tools to find the appropriate description within the metadata with which to build out the sources and configuration. The linux-yocto recipes define "standard", "tiny", and "preempt-rt" kernel types. See 3.3.4 for more inforation on kernel types. During the build, the kern-tools will search for the BSP description file that most closely matches the KMACHINE and LINUX_KERNEL_TYPE passed in from the recipe. It will use the first BSP description it finds matching both variables. Failing that it will issue a warning such as the following: WARNING: Can't find any BSP hardware or required configuration fragments. WARNING: Looked at meta/cfg/broken/fri2-broken/hdw_frags.txt and meta/cfg/broken/fri2-broken/required_frags.txt in directory: meta/cfg/broken/fri2-broken In this example KMACHINE was set to "fri2-broken" and LINUX_KERNEL_TYPE was set to "broken". It will then search first for the KMACHINE and then for the LINUX_KERNEL_TYPE. If it cannot find a partial match, it will use the sources from the KBRANCH and any configuration specified in the SRC_URI. KERNEL_FEATURES can be used to include features (configuration fragments, patches, or both) that are not already included by the KMACHINE and LINUX_KERNEL_TYPE combination. To include a feature specified as "features/netfilter.scc" for example, specify: KERNEL_FEATURES += "features/netfilter.scc" To include a feature called "cfg/sound.scc" just for the qemux86 machine, specify: KERNEL_FEATURES_append_qemux86 = "cfg/sound.scc" The value of the entries in KERNEL_FEATURES are dependent on their location within the metadata itself. The examples here are taken from the linux-yocto-3.4 repository where "features" and "cfg" are subdirectories of the metadata directory. For details, see 3.3. Note: The processing of the these variables has evolved some between the 0.9 and 1.3 releases of the Yocto Project and associated kern-tools sources. The above is accurate for 1.3 and later releases of the Yocto Project.