Details
-
Type:
Task
-
Status: Done
-
Priority:
(None)
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: Cleanup-MPPT-2018-11-07
-
Labels:
-
Epic Link:
-
Backlog:no
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