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

Agree on structure of meta-mender-community

    XMLWordPrintable

    Details

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

      Description

      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.

      Example:

      $ 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
      

      conf

      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 \
      	${LAYERDIR}/recipes-*/*/*.bbappend"
      
      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".


      scripts

      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/
      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!


      templates

      Contains local.conf and bblayers.conf template files.

      Example (meta-mender-rockchip):

      templates/
      ├── 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/
      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
      

      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

        Attachments

          Activity

            People

            • Assignee:
              mirzak Mirza Krak
              Reporter:
              mirzak Mirza Krak
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Summary Panel