Uploaded image for project: 'Mender'
  1. Mender
  2. MEN-2075

Agree on structure of meta-mender-community



    • Type: Task
    • Status: Done
    • Priority: (None)
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Cleanup-MPPT-2018-11-07
    • Labels:


      The initial structure is pretty much already implemented in meta-mender-community and ready for feedback and review.

      But will do a walk trough of the structure here with some additional details (very detailed ). Intention is to re-use below text in documentation.

      meta-mender-community is a top level layer which is not actually a layer it self but contains several layers. This is similar to how meta-mender works and another example is meta-openembbeded. An acceptable approach within the Yocto community.


      $ tree -L 1
      ├── LICENSE
      ├── meta-mender-freescale
      ├── meta-mender-renesas
      ├── meta-mender-rockchip
      ├── meta-mender-sunxi
      └── README.md

      They layers are separated by manufacturer family and the names are based official upstream BSP layer naming (meta-freescale, meta-renesas, meta-rockchip and meta-sunxi).

      System on Modules usually provide their own BSP layer that builds on top of the upstream one, one example is meta-toradex-nxp which depends on meta-freecale and in that case integration patches should still go under meta-mender-freescale.

      Example manufacturer/SoM layer:

      $ tree -L 1
      ├── conf
      ├── README.md
      ├── recipes-bsp
      ├── scripts
      └── templates


      Optional directory. If they layer is not providing any modifications (when auto-patching and u-boot/grub/uefi are used) but only scripts and templates then there is no reason to actually provide a layer.conf and bitbake will produce a warning if an "empty" layer is included.

      "Standard" Yocto directory containing 'layer.conf'.

      Example from meta-mender-rockchip/conf/layer.conf

      # Copyright 2018 Northern.tech AS
      # We have a conf and classes directory, add to BBPATH
      BBPATH .= ":${LAYERDIR}"
      # We have recipes-* directories, add to BBFILES
      BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
      BBFILE_COLLECTIONS += "mender-rockchip"
      BBFILE_PATTERN_mender-rockchip = "^${LAYERDIR}/"
      BBFILE_PRIORITY_mender-rockchip = "10"

      Collection naming should follow this naming scheme:

      "mender-<manufacturer name>"

      Exceptions are accepted.

      The BBFILE_PRIORITY should be set to have a higher priority then the upstream BSP layer which we are "appending".


      Repo manifest files. There will typically be one manifest file for each manufacturer and one for each SoM provider and in some cases one for specific boards.

      Example (meta-mender-freescale, not implemented yet though):

      $ tree -L 1 scripts/
      ├── manifest-freescale.xml
      ├── manifest-toradex.xml
      └── manifest-variscite.xml

      The manifest files should be based on upstream configuration if provided, otherwise one of the existing ones can be used as reference to create a new one. This really simplifies the build environment setup!


      Contains local.conf and bblayers.conf template files.

      Example (meta-mender-rockchip):

      ├── bblayers.conf.sample
      └── local.conf.sample

      In some cases there will be sub-directories for each manifest file.

      Example (meta-mender-freescale):

      $ tree -L 2 templates/
      ├── freescale
      │   ├── bblayers.conf.sample
      │   └── local.conf.sample
      ├── toradex
      │   ├── bblayers.conf.sample
      │   └── local.conf.sample
      └── variscite
          ├── bblayers.conf.sample
          └── local.conf.sample

      NOTE! The templates files are "full copies" of original files, meaning that the local.conf.sample is a copy of the local.conf.sample found in poky with some additions for Mender integration. An optimization in this case would be to provide "smarter" approach working with local.conf.sample fragments only providing the addition changes needed and the original local.conf.sample from poky can be used.

      Above results in the following commands to setup a build environment and start baking:

      Download the source:

          $ mkdir mender-rockchip
          $ cd mender-rockchip
          $ repo init \
                 -u https://github.com/mirzak/meta-mender-community \
                 -m meta-mender-rockchip/scripts/manifest-rockchip.xml \
                 -b rocko

      Setup environment

          $ export MENDER_LAYER=${PWD}/sources/meta-mender-community/meta-mender-rockchip
          $ export TEMPLATECONF=${MENDER_LAYER}/templates/
          $ . sources/poky/oe-init-build-env build


      $ bitbake core-image-base

      The sequence of commands is the same for every board, and you only adjust path to manifest file and path to templates. This is "scriptable" and could be reduced to the following:

      $ source init.sh rockchip

      or more board specific:

      $ source init.sh rk3288-tinkerboard

      Unsure if it is a optimization we want to do at the start. Above is not something "new" and is mainly inspired by AGL and GENIVI which manages large pool of layers and various boards and features (AGL only).

      Example on how to setup and start AGL build (for reference and insperation)

      $ repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo && repo sync
      $  source meta-agl/scripts/aglsetup.sh \
        -m intel-corei7-64 \
        -b build \
        agl-devel agl-demo agl-appfw-smack agl-netboot agl-audio-4a-framework
      $ bitbake agl-demo-platform

      Acceptance criteria:

      • Agree on layout and adjust the reference implementation (meta-mender-community) according to that




            mirzak Mirza Krak
            mirzak Mirza Krak
            0 Vote for this issue
            2 Start watching this issue