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 Minnow BSP definition from the linux-yocto-3.19 Git repository:

     minnow.scc:
        include cfg/x86.scc
        include features/eg20t/eg20t.scc
        include cfg/dmaengine.scc
        include features/power/intel.scc
        include cfg/efi.scc
        include features/usb/ehci-hcd.scc
        include features/usb/ohci-hcd.scc
        include features/usb/usb-gadgets.scc
        include features/usb/touchscreen-composite.scc
        include cfg/timer/hpet.scc
        include cfg/timer/rtc.scc
        include features/leds/leds.scc
        include features/spi/spidev.scc
        include features/i2c/i2cdev.scc

        # Earlyprintk and port debug requires 8250
        kconf hardware cfg/8250.cfg

        kconf hardware minnow.cfg
        kconf hardware minnow-dev.cfg
            

The minnow.scc description file includes a hardware configuration fragment (minnow.cfg) specific to the Minnow 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 "minnow" description files for the supported kernel types (i.e. "standard", "preempt-rt", and "tiny"). Consider the "minnow" description for the "standard" kernel type:

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

        include ktypes/standard

        include minnow.scc

        # Extra minnow configs above the minimal defined in minnow.scc
        include cfg/efi-ext.scc
        include features/media/media-all.scc
        include features/sound/snd_hda_intel.scc

        # The following should really be in standard.scc
        # USB live-image support
        include cfg/usb-mass-storage.scc
        include cfg/boot-live.scc

        # Basic profiling
        include features/latencytop/latencytop.scc
        include features/profiling/profiling.scc

        # Requested drivers that don't have an existing scc
        kconf hardware minnow-drivers-extra.cfg
            

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

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

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

        include ktypes/tiny

        include minnow.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 "minnow" 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".