Understanding Yocto/OE Layers and Their Roles
- What is a layer?
A layer is a Git repository containing metadata, recipes, and configurations supporting embedded Linux builds. Each layer typically follows Yocto Project release branches for version control consistency and compatibility with Yocto/OE tools (layerindex/toaster). The layer repository should maintain strict naming conventions, especially themeta-*prefix, to ensure clarity and compatibility. Mixing nonstandard names leads to maintenance and community recognition problems, and your layers to show up as git ”Untracked files:” (see poky/.gitignore)
- Layer Types and Roles
- Base layers: Mostly from Official Yocto or OpenEmbedded (e.g.,
openembedded-coreakametain poky,meta-oe), providing core metadata and recipes. - BSP layers: Hardware-specific support like machine configs and kernel recipes, has at least one conf/machine/.conf file.
- Distro layers: Define distribution policies, global configuration, and image definitions, has at least one conf/distro/.conf file.
NOTE: Combining BSP and DISTRO layer is invalid, i.e. will not passyocto-check-layer - Software/Application layers: Additional middleware and packages, generally hardware-agnostic.
- Misuse of container or miscellaneous layers is rare and discouraged; mainly leave these out unless specific edge use cases.
- Base layers: Mostly from Official Yocto or OpenEmbedded (e.g.,
- Best Practices for Layers
- Enforce the
meta-*naming convention strictly. - Do not mix BSP, distro, and software in one layer to preserve modularity and reusability.
- Use
LAYERDEPENDSandBBFILE_PRIORITYinlayer.confto specify dependencies and control precedence. - Run
yocto-check-layerto ensure compatibility with Yocto Project standards and prevent mixing incompatible layer types.
- Enforce the
- Maintainability
- Each layer should be an independently versioned Git repository with clear branch tracking of Yocto releases, maximizing parallel development and upstream sync.
Organizing Yocto Layers on Disk: Layouts and Tooling
- Layer Placement and Source Directory
- Official Yocto BKM, states layers should be cloned alongside poky inside the ”Source Directory” (commonly the
poky/directory). This means your layers live inside the poky directory as siblings of other meta layers (e.g.,poky/meta-my-bsp/,poky/meta-my-distro/).
- Official Yocto BKM, states layers should be cloned alongside poky inside the ”Source Directory” (commonly the
-
- This is the simplest and recommended approach for standard use cases.
- Deviation to layouts like
src/with siblings poky/meta-… is a common misconception; not recommended or BKM.
- Git and Version Control Impact
- Each layer is a separate Git repository, enabling independent branching, versioning, and update management. The poky repository itself is separate from layer repositories.
.gitignorein poky is set to ignoremeta-*directories to avoid polluting poky’s own version control, not to discourage placing layers inside poky.
- BitBake Layer Tools Behavior
bitbake-layerscommands (create-layer, add-layer, layerindex-fetch) expect layers inside poky by default for easy integration and compatibility.layerindex-fetchautomates cloning layers and their dependencies into the Source Directory.
- Common Misconceptions
- It is still BKM to clone layers inside poky, other layouts are mostly user preferences or corporate adaptations but not recommended way of working according to the official documentation.
- ????? Warning about introducing complexity or tool incompatibility by scattering layers arbitrarily.
Scalable Yocto Workflows: Multi-Project Builds, Bootstrap Layers, and Layer Indexes
- Handling Multiple Projects or Products
- Use separate build directories (e.g.,
build-project_one/,build-project_two/) for different builds, each with its ownconf/local.confandconf/bblayers.conf. - Reuse the shared layers inside poky across projects without duplicating them. This cleanly separates build configurations from layers.
- Use separate build directories (e.g.,
- Bootstrap Layers and TEMPLATECONF
- Define bootstrap layers as minimal layers managing product or project-specific configuration templates.
- Use
bitbake-layers create-layer meta-bootstrapto initialize such layers. - Use
bitbake-layers save-build-confto generate configuration templates, then deploy withTEMPLATECONFenvironment variable for reproducible builds.
- Layer Index and Automation
- Introduce the OpenEmbedded Layer Index and its REST API for discovery, dependency tracking, and automation.
NOTE: Description to be written here! - Explain benefits of running a company-specific Layer Index for internal control, consistency, access management, and CI/CD integration.
NOTE: Description to be written here!
- Introduce the OpenEmbedded Layer Index and its REST API for discovery, dependency tracking, and automation.
- Company & Automation Best Practices
- Centralize layers inside poky.
- Automate builds and layer management using layer index tooling and bootstrap layers.
- Enforce strict naming conventions and use yocto-check-layer gating for quality.