Mistake on this page? Email us

Overview of MBL Yocto layers

The MBL workspace contains Yocto community and MBL layers needed to build MBL images. The Yocto project classifies layers into one of three types:

  • BSP layers, which contain the machine configuration file for a target platform, or metadata relating to target-specific board support packages (for example, meta-raspberrypi).
  • Distro layers, which contain the configuration file (mbl.conf) for the distribution (for example, meta-mbl-distro).
  • General purpose layers, which contain metadata and recipes for applications (for example, meta-mbl-apps).

MBL introduces the additional staging layer. The staging layer provides a logical place where MBL-originated .bb and .bbappend recipes relating to a community layer can be stored prior to upstreaming, or if the metadata cannot be upstreamed, maintained for the MBL distribution.

To introduce the community and MBL layers used in MBL, the next section offers a concrete example of layers used in the raspberrypi3-mbl workspace. It briefly mentions the distribution and general purpose layers and describes the BSP layers in more detail.

The subsequent sections describe the BSP layers used in the remaining target platforms: imx7d-pico-mbl, imx7s-warp-mbl and imx8mmevk-mbl. For all three platforms, the distribution and general purpose layers are the same as raspberrypi3-mbl.

Layers for raspberrypi3-mbl

After you've created an MBL workspace and initialized the environment, you can list the bblayers*.conf configured layers using bitbake-layers show-layers.

Table 3.2.1 shows the command output for MACHINE=raspberrypi3-mbl:

Layer Path Priority
meta-mbl-distro /layers/meta-mbl/meta-mbl-distro 10
meta-mbl-apps /layers/meta-mbl/meta-mbl-apps 7
meta-filesystems /layers/meta-openembedded/meta-filesystems 6
meta-networking /layers/meta-openembedded/meta-networking 5
meta-oe /layers/meta-openembedded/meta-oe 6
meta-python /layers/meta-openembedded/meta-python 7
meta-virtualization-mbl /layers/meta-mbl/meta-virtualization-mbl 9
meta-virtualization /layers/meta-virtualization 8
meta-mbl-bsp-common /layers/meta-mbl/meta-mbl-bsp-common 10
meta-raspberrypi-mbl /layers/meta-mbl/meta-raspberrypi-mbl 11
meta-raspberrypi /layers/meta-raspberrypi 9
meta-optee /layers/meta-mbl/meta-linaro-mbl/meta-optee 9
meta-optee /layers/meta-linaro/meta-optee 8
meta /layers/meta-mbl/openembedded-core-mbl/meta 6
meta /layers/openembedded-core/meta 5

Table 3.2.1: Output of bitbake-layers show-layers for MACHINE=raspberrypi3-mbl in table form.

Note that the command output has been slightly modified for presentation purposes (for example, the full path to the MBL workspace path has been shortened to <ws>).

  • The first column shows the layer name, which is also the name of the workspace directory containing the layer.
  • The second column shows the path to the layer. The layout of the layers is more clearly explained by the directory hierarchy shown in Figure 3.2.
  • The third column shows the priority of the layer, which controls the BitBake layer processing order. Layers with a higher priority number are processed after lower numbers, so the settings in the higher priority number layer take precedence.

The MBL workspace directory structure in Figure 3.2 shows:

  • The community often stores multiple layers in a single repository. For example, the meta-openembedded repository contains the layers meta-filesystems, meta-networking, meta-oe and meta-python. In this case, the meta-openembedded repository name appears as a subdirectory of layers, and the layers are subdirectories of meta-openembedded.

    The point to observe here is that if a repository provides multiple layers, then both the repository name and the layer name are preserved in the workspace (other examples include meta-linaro/meta-optee and openembedded-core/meta). Otherwise, the layer appears directly under layers (for example, meta-raspberrypi and meta-virtualization).

  • Like the community, MBL stores multiple layers in the meta-mbl repository. The workspace layers/meta-mbl directory stores multiple layers.

  • The meta-mbl repository stores new layers, for example, meta-mbl-apps, meta-mbl-bsp-common and meta-mbl-distro. The new MBL layers are reusable components of related metadata. A third-party distribution can use MBL secure boot by reusing meta-mbl-bsp-common.

  • New MBL layers have meta-mbl at the start of the layer name.

  • The meta-mbl repository stores staging layers for customizations of community recipes (such as .bbappend recipes).

  • Staging layers follow the naming convention of appending -mbl to the community repository. For example, meta-linaro-mbl/meta-optee, openembedded-core-mbl/meta, meta-raspberrypi-mbl, and meta-virtualization-mbl.

  • In the staging layers configuration file (layers.conf), the BBFILE_COLLECTIONS variable should append -mbl to the upstream layer original value. For example:

    • For meta-linaro-mbl/meta-optee/conf/layer.conf: BBFILE_COLLECTIONS = "meta-optee-mbl"
    • For openembedded-core-mbl/meta/conf/layer.conf: BBFILE_COLLECTIONS = "core-mbl"
    • For meta-raspberrypi-mbl/conf/layer.conf: BBFILE_COLLECTIONS = "raspberrypi-mbl"
    • For meta-virtualization-mbl/conf/layer.conf: BBFILE_COLLECTIONS = "virtualization-layer-mbl"

    <mbl_workspace_root_path>
    └── layers                                  // Directory containing layers at leaf nodes.
        ├── meta-linaro                         // Community repo name holding multiple layers.
        │   └── meta-optee                      // Community layer for Trusted Exec. Env.
        ├── meta-mbl                            // MBL repo name holding multiple layers.
        │   ├── meta-linaro-mbl                 // MBL staging directory for meta-linaro.
        │   │   └── meta-optee                  // MBL staging layer for meta-optee customizations.
        │   ├── meta-mbl-apps                   // MBL layer for MBL applications.
        │   ├── meta-mbl-bsp-common             // MBL layer for common BSP recipes and metadata.
        │   ├── meta-mbl-distro                 // MBL distribution layer.
        │   ├── meta-raspberrypi-mbl            // MBL staging layer for meta-raspberrypi `*.bbappend`.
        │   ├── meta-virtualization-mbl         // MBL staging layer for meta-virtualization `*.bbappend`.
        │   └── openembedded-core-mbl           // MBL staging directory for openembedded-core.
        │       └── meta                        // MBL staging layer for openembedded-core/meta
        ├── meta-openembedded                   // Community repo name holding multiple layers.
        │   ├── meta-filesystems                // Community layer for file systems.
        │   ├── meta-networking                 // Community layer for networking.
        │   ├── meta-oe                         // Community layer for Open Embedded.
        │   └── meta-python                     // Community layer for Python.
        ├── meta-raspberrypi                    // Community layer for Raspberry Pi BSP.
        ├── meta-virtualization                 // Community layer for virtualization.
        └── openembedded-core                   // Community repo name holding multiple layers.
            └── meta                            // Community layer for building Linux distributions.

Figure 3.2: Workspace layer directory hierarchy representation showing raspberrypi3-mbl layers.

For the community layer meta-raspberrypi, the meta-mbl repository contains the MBL staging layer meta-raspberrypi-mbl for .bbappend customizations of meta-raspberrypi *.bb recipes. Because meta-raspberrypi-mbl contains the raspberrypi3-mbl.conf machine configuration file, it is also a BSP layer. raspberrypi3-mbl.conf cannot be upstreamed to meta-raspberrypi and therefore has to be maintained independently.

Table 3.2.2 summarizes the layers that appear in the MBL workspace.

Layer Type Source Description
openembedded-core/meta General Community Openembedded core recipe library support for building images.
openmebedded-core-mbl/meta General MBL MBL staging layer for openembedded-core/meta customizations.
meta-filesystems General Community File system subsystems layer.
meta-freescale BSP Community Freescale NXP-maintained BSP layer for i.MX8 target containing imx8mmevk.conf.
meta-freescale-mbl BSP MBL MBL BSP staging layer containing imx8mmevk-mbl.conf, u-boot*.bbappend and linux*.bbappend recipe customizations.
meta-freescale-3rdparty BSP Community The Freescale NXP community has established this low-friction alternative for upstreaming third party originated recipes. i.MX7 targets including imx7s-warp.conf and imx7d-pico.conf are hosted in this layer.
meta-freescale-3rdparty-mbl BSP MBL MBL BSP staging layer containing imx7*-mbl.conf, u-boot*.bbappend and linux*.bbappend recipe customizations.
meta-fsl-bsp-release-mbl/imx/meta-bsp BSP MBL MBL BSP staging layer containing Qualcomm qca9377 firmware installation script and imx8 firmware blobs recipe customization.
meta-fsl-bsp-release/imx/meta-bsp BSP Community BSP layer containing Qualcomm qca9377 firmware and kernel module recipes and imx8 firmware blobs used by some NXP targets and qcom qca9377 firmware and kernel modules.
meta-linaro/meta-optee BSP Community Linaro-provided layer for OP-TEE
meta-linaro-mbl/meta-optee BSP MBL MBL staging layer for meta-optee customizations or related meta-data.
meta-mbl-apps General MBL MBL applications such as mbl-cloud-client.
meta-mbl-bsp-common BSP MBL MBL layer for BSP meta-data commonly used by more than one target BSP.
meta-mbl-distro Distro MBL MBL distribution layer containing mbl.conf, mbl-image*.bb recipes, mbl-partitions.bbclass and mbl.wks.in.
meta-networking General Community Networking subsystems layer.
meta-oe General Community Open Embedded layer for distribution tools and applications.
meta-python General Community Layer to build the Python runtime for the target.
meta-raspberrypi BSP Community Raspberry Pi provided BSP layer containing raspberrypi3.conf.
meta-raspberrypi-mbl BSP MBL MBL staging layer for meta-raspberrypi customizations.
meta-virtualization General Community Layer to provide support for constructing OE-based virtualized solutions.
meta-virtualization-mbl General MBL MBL staging layer for Docker virtualization customizations.

Table 3.2.2: All the layers in the MBL workspace.

Note that an MBL workspace contains all of the layers listed in Table 3.2.2, but the bblayers*.conf files configure BitBake to only use the layers needed for the current target and ignore the rest. This is achieved by:

  • bblayers.conf only specifying the layers common to all targets.
  • bblayers.conf including a target-specific file bblayers_${MACHINE}.conf, which specifies the target-specific layers.

BSP layers for imx7d-pico-mbl

Table 3.3.1 shows the BSP layers for imx7d-pico-mbl configured in bblayers_imx7d-pico-mbl.conf. The full set of layers imx7d-pico-mbl uses is the set of layers obtained by replacing the meta-raspberrypi* BSP layers in Table 3.2.1 with the BSP layers in Table 3.3.1 below.

Refer to Layers for raspberrypi3-mbl for details of the layers.

Layer Path Priority
meta-freescale-mbl /layers/meta-mbl/meta-freescale-mbl 11
meta-freescale /layers/meta-freescale 5
meta-freescale-3rdparty-mbl /layers/meta-mbl/meta-freescale-3rdparty-mbl 11
meta-freescale-3rdparty /layers/meta-freescale-3rdparty 4
meta-bsp /layers/meta-mbl/meta-fsl-bsp-release-mbl/imx/meta-bsp 9
meta-bsp /layers/meta-fsl-bsp-release/imx/meta-bsp 8

Table 3.3.1: The BSP layers output from bitbake-layers show-layers for MACHINE=imx7d-pico-mbl in table form.

BSP layers for imx7s-warp-mbl

Table 3.4.1 shows the BSP layers for imx7s-warp-mbl configured in bblayers_imx7s-warp-mbl.conf. The full set of layers used by imx7s-warp-mbl is the set of layers obtained by replacing the meta-raspberrypi* BSP layers in Table 3.2.1 with the BSP layers in Table 3.4.1 below.

Refer to Layers for raspberrypi3-mbl for details of the layers.

Layer Path Priority
meta-freescale-mbl /layers/meta-mbl/meta-freescale-mbl 11
meta-freescale /layers/meta-freescale 5
meta-freescale-3rdparty-mbl /layers/meta-mbl/meta-freescale-3rdparty-mbl 11
meta-freescale-3rdparty /layers/meta-freescale-3rdparty 4

Table 3.4.1: The BSP layers output from bitbake-layers show-layers for MACHINE=imx7s-warp-mbl in table form.

BSP layers for imx8mmevk-mbl

Table 3.5.1 shows the BSP layers for imx8mmevk-mbl configured in bblayers_imx8mmevk-mbl.conf. The full set of layers used by imx8mmevk-mbl is the set of layers obtained by replacing the meta-raspberrypi* BSP layers in Table 3.2.1 with those in Table 3.5.1 below.

Refer to Layers for raspberrypi3-mbll for details of the layers.

Layer Path Priority
meta-freescale-mbl /layers/meta-mbl/meta-freescale-mbl 11
meta-freescale /layers/meta-freescale 5
meta-bsp /layers/meta-mbl/meta-fsl-bsp-release-mbl/imx/meta-bsp 9
meta-bsp /layers/meta-fsl-bsp-release/imx/meta-bsp 8

Table 3.5.1: The BSP layers output from bitbake-layers show-layers for MACHINE=imx8mmevk-mbl in table form.

Example machine configuration files

In this document, BSP layers are often referred to as meta-[soc-vendor] and meta-[soc-vendor]-mbl, respectively, when the discussion is applicable to all targets. Specific layer reference examples are:

  • meta-raspberrypi and meta-raspberrypi-mbl, BSP layers for Raspberry Pi.
  • meta-freescale and meta-freescale-mbl, BSP layers for the Freescale NXP i.MX8 Mini.

Table 3.6 shows the relationship between the target machine configuration files and the containing layers:

  • The first column defines the MACHINE identifier.

  • The second column provides the name of the ${MACHINE}.conf file contained in the meta-[soc-vendor]-mbl MBL staging layer.

  • The third column provides the name of the ${machine}.conf file contained in the meta-[soc-vendor] community layer.

  • The fourth column provides the layers that hold the machine configuration files. meta-freescale(-3rdparty)(-mbl) denotes four layers:

    • meta-freescale, meta-[soc-vendor] community layer.
    • meta-freescale-mbl, MBL staging layer.
    • meta-freescale-3rdparty, meta-[soc-vendor] community layer.
    • meta-freescale-3rdparty-mbl, MBL staging layer.

MACHINE ${MACHINE}.conf ${machine}.conf Layer(s)
imx7s-warp-mbl imx7s-warp-mbl.conf imx7s-warp.conf meta-freescale(-3rdparty)(-mbl)
imx8mmevk-mbl imx8mmevk-mbl.conf imx8mmevk.conf meta-freescale(-mbl)
raspberrypi3-mbl raspberrypi3-mbl.conf raspberrypi3.conf meta-raspberrypi(-mbl)
imx7d-pico-mbl imx7d-pico-mbl.conf imx7d-pico.conf meta-freescale(-3rdparty)(-mbl)

Table 3.6: ${MACHINE}.conf, ${machine}.conf and the associated layers.

Yocto BSP recipe software architecture

This section gives a top-down overview of the MBL Yocto layers and the relationships between recipes and configuration files.

figure-3.7Figure 3.7: The Yocto layers relevant for BSP development. meta-mbl repo entities are shown in blue, meta-[soc-vendor] in green, meta-optee in orange and openembedded-core in yellow.

The MBL development workspace is composed of the Yocto layers related to BSP development as shown in the figure above.

Each layer is shown horizontally, containing a number of recipe packages and configuration files. Beginning with the top layer and moving downward:

  • meta-mbl-distro. The distribution layer provides:
    • The parameterized WIC kickstart image layout file mbl.wks.in.
    • mbl-partitions.bbclass, a class to process the parameters used in mbl.wks.in.
  • meta-[soc-vendor]-mbl. The MBL staging layer provides:
    • The BSP customization for specific target platforms by defining ${MACHINE}.conf files.
    • The MBL u-boot*.bbappend customization recipes to build U-Boot.
    • The MBL linux*.bbappend customization recipes to build Linux.
    • The atf-${MACHINE}.bb recipe to build ATF. This includes atf.inc from the meta-mbl-bsp-common layer.
  • meta-[soc-vendor]. The community layer provides:
    • The BSP support for specific target platforms. That is, it defines ${machine}.conf files.
    • The u-boot*.bb base recipes and customizations using the u-boot*.bbappend recipes.
    • The linux*.bb base recipes and customizations using thelinux*.bbappend recipes.
  • meta-mbl-bsp-common. This MBL layer contains the generic ATF recipe support atf.inc which is used by the target-specific atf-${MACHINE}.bb recipe.
  • meta-linaro-mbl/meta-optee. This MBL staging layer provides the optee*.bbappend customization recipes.
  • meta-optee. The community layer provides:
    • optee-os.bb for building the OP-TEE OS.
    • optee-client.bb for building the trusted execution client library for the Linux kernel.
    • optee-test.bb for building the OP-TEE test framework and tests.
  • openembedded-core-mbl/meta. This MBL staging layer provides:
    • mbl-fitimage.bbclass, a reusable class used to generate the kernel FIT packaging. See linux* for details.
  • openembedded-core. This layer contains a library of recipes and classes supporting the creation of Linux distributions:
    • u-boot.inc.. This include file contains the bulk of the symbol definitions and recipe functions for building the U-Boot bootloader. It's included into the u-boot_${PV}.bb recipe.

    • u-boot-sign.bbclass. The class that orchestrates verified boot signing of FIT images.

    • u-boot_${PV}.bb. The top level boilerplate recipe for building the U-Boot bootloader. The package version variable ${PV} expands to give u-boot_2018.11.bb, for example.

    • u-boot-tools_${PV}.bb. A recipe for building the U-Boot mkimage tool, which can, for example, create and sign FIT images.

      You can use the recipe to build either mkimage host or target versions:

      • u-boot-fw_utils_{PV}.bb. A recipe for building the U-Boot fw_printenv/fw_setenv/etc firmware tools for managing the U-Boot environment.

      The recipe can build either host or target binaries:

      • u-boot-common_${PV}.inc. This include file contains common symbol definitions used by multiple u-boot* recipes. It is included in the u-boot_${PV}.bb recipe.
      • kernel-fitimage.bbclass. See linux* for details.
      • kernel-devicetree.bbclass. See linux* for details.
      • kernel-uimage.bbclass. See linux* for details.
      • kernel-module-split.bbclass. See linux* for details.
      • kernel-uboot.bbclass. See linux* for details.
Important Information for this Arm website

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.