3.4.5. BSP Descriptions

BSP descriptions combine kernel types with hardware-specific features. The hardware-specific portion is typically defined independently, and then aggregated with each supported kernel type. Consider this simple BSP description that supports the "mybsp" machine:

     mybsp.scc:
        define KMACHINE mybsp
        define KTYPE standard
        define KARCH i386

        kconf mybsp.cfg
            

Every BSP description should define the KMACHINE, KTYPE, and KARCH variables. These variables allow the OpenEmbedded build system to identify the description as meeting the criteria set by the recipe being built. This simple example supports the "mybsp" machine for the "standard" kernel and the "i386" architecture.

Be aware that a hard link between the KTYPE variable and a kernel type description file does not exist. Thus, if you do not have kernel types defined in your kernel Metadata, you only need to ensure that the kernel recipe's LINUX_KERNEL_TYPE variable and the KTYPE variable in the BSP description file match.

Note

Future versions of the tooling make the specification of KTYPE in the BSP optional.

If you did want to separate your kernel policy from your hardware configuration, you could do so by specifying a kernel type, such as "standard" and including that description file in the BSP description file. See the "Kernel Types" section for more information.

You might also have multiple hardware configurations that you aggregate into a single hardware description file that you could include in the BSP description file, rather than referencing a single .cfg file. Consider the following:

     mybsp.scc:
        define KMACHINE mybsp
        define KTYPE standard
        define KARCH i386

        include standard.scc
        include mybsp-hw.scc
            

In the above example, standard.scc aggregates all the configuration fragments, patches, and features that make up your standard kernel policy whereas mybsp-hw.scc aggregates all those necessary to support the hardware available on the "mybsp" machine. For information on how to break a complete .config file into the various configuration fragments, see the "Generating Configuration Files" section.

Many real-world examples are more complex. Like any other .scc file, BSP descriptions can aggregate features. Consider the Fish River Island 2 (fri2) BSP definition from the linux-yocto-3.4 Git repository:

     fri2.scc:
        kconf hardware fri2.cfg

        include cfg/x86.scc
        include features/eg20t/eg20t.scc
        include cfg/dmaengine.scc
        include features/ericsson-3g/f5521gw.scc
        include features/power/intel.scc
        include cfg/efi.scc
        include features/usb/ehci-hcd.scc
        include features/usb/ohci-hcd.scc
        include features/iwlwifi/iwlwifi.scc
            

The fri2.scc description file includes a hardware configuration fragment (fri2.cfg) specific to the Fish River Island 2 BSP as well as several more general configuration fragments and features enabling hardware found on the machine. This description file is then included in each of the three "fri2" description files for the supported kernel types (i.e. "standard", "preempt-rt", and "tiny"). Consider the "fri2" description for the "standard" kernel type:

     fri2-standard.scc:
        define KMACHINE fri2
        define KTYPE standard
        define KARCH i386

        include ktypes/standard/standard.scc
        branch fri2

        git merge emgd-1.14

        include fri2.scc

        # Extra fri2 configs above the minimal defined in fri2.scc
        include cfg/efi-ext.scc
        include features/drm-emgd/drm-emgd.scc
        include cfg/vesafb.scc

        # default policy for standard kernels
        include cfg/usb-mass-storage.scc
            

The include command midway through the file includes the fri2.scc description that defines all hardware enablements for the BSP that is common to all kernel types. Using this command significantly reduces duplication.

This "fri2" standard description introduces a few more variables and commands that are worth further discussion. Notice the branch fri2 command, which creates a machine-specific branch into which source changes are applied. With this branch set up, the git merge command uses Git to merge in a feature branch named "emgd-1.14". You could also handle this with the patch command. However, for commonly used features such as this, feature branches are a convenient mechanism. See the "Feature Branches" section for more information.

Now consider the "fri2" description for the "tiny" kernel type:

     fri2-tiny.scc:
        define KMACHINE fri2
        define KTYPE tiny
        define KARCH i386

        include ktypes/tiny/tiny.scc
        branch fri2

        include fri2.scc
            

As you might expect, the "tiny" description includes quite a bit less. In fact, it includes only the minimal policy defined by the "tiny" kernel type and the hardware-specific configuration required for booting the machine along with the most basic functionality of the system as defined in the base "fri2" description file.

Notice again the three critical variables: KMACHINE, KTYPE, and KARCH. Of these variables, only the KTYPE has changed. It is now set to "tiny".