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.
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:
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
Collection naming should follow this naming scheme:
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):
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.
In some cases there will be sub-directories for each manifest file.
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:
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:
or more board specific:
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)
- Agree on layout and adjust the reference implementation (meta-mender-community) according to that