Agree on structure of meta-mender-community

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