This guide uses a Raspberry Pi Zero 2W as an example, but could easily be used with any other Raspberry Pi device that is supported by the meta-raspberrypi layer. It can also be used with other devices, but would need the device-specific board support package instead of meta-raspberrypi then.
The resulting project repository of this guide is also available in the branch examples/yocto-project-create of my Yocto examples repository.
Repository Structure
Let's start with an overview on possible repository structures for a Yocto project based on the reference distribution Poky. Creating an own distribution instead of using Poky is highly recommended for productive environments, but not explicitly covered in this guide.
Inside of Poky
The simplest way to get started with a Yocto project, is to clone the Poky repository and add the Yocto layers you need to the resulting directory as described in the Quick Build chapter of the Yocto documentation. This approach, however, has the disadvantage that the layers selection, for example, cannot be put under version control and the steps for adding the necessary layers for a project would need to be done manually each time.
The structure of such a project could look like this:
|
| | | | | |
|
The custom layers that are created as part of the project, can be versioned in separate git repositories and need to be added to the project the same way as all the other layers are added.
Git Submodules
Alternatively, a git repository could be created for the Yocto project and the layers - including Poky - could be added as git submodules in this repository. With the structure then looking like this:
|
| | | | | |
|
The used layers and their versions are versioned in the project git repository now together with the content of the custom layers of the project. The bblayers.conf
which defines which layers are used and the local.conf
which defines the machine and the distribution, however, still need to be managed manually after cloning the project repository.
Kas
This is where kas, the setup tool for bitbake based projects, comes into play. It allows to define the layer dependencies and things like the machine, the distro or the target in a project file and automatically clones the dependencies and generates the configuration within the build directory. The repository structure looks very similar to the git submodules approach:
|
| | | | | |
|
|
|
|
|
|
The layers that the project depends on are no longer added as git submodules, but are defined in the project.yml
and then automatically cloned by kas. The configuration in the build directory does not need to be adapted manually anymore and is generated by kas instead.
This approach with kas is used for the rest of this guide.
Project Setup
Make sure that you have kas installed, as described in its Getting Started Guide.
The first step of the project setup is to create or clone a git repository for your project. As soon, as you have this done you can continue the setup within the directory of this repository.
Kas Project Configuration
Create a project.yml
like the following in the project directory:
# Every file needs to contain a header, that provides kas with information
# about the context of this file.
header:
# The `version` entry in the header describes for which configuration
# format version this file was created for. It is used by kas to figure
# out if it is compatible with this file. The version is an integer that
# is increased on every format change.
version: 18
# The machine as it is written into the `local.conf` of bitbake.
machine: raspberrypi0-2w-64
# The distro name as it is written into the `local.conf` of bitbake.
distro: poky
# The bitbake target to be built for this project.
target: core-image-base
repos:
# This entry includes the repository where the config file is located
# to the bblayers.conf. It also contains all project layers that are not
# versioned in separate git repositories.
meta-custom:
# The layers of Poky to be included in the bblayers.conf.
poky:
url: https://git.yoctoproject.org/git/poky
commit: df5c19f5d143b161bc5b8d42c24cc1a278ed2417
layers:
meta:
meta-poky:
meta-yocto-bsp:
# The layers of Open Embedded to be included in the bblayers.conf.
meta-openembedded:
url: https://git.openembedded.org/meta-openembedded
commit: dda0d53326017d6758ec6bdfdaf2f484c089d13f
layers:
meta-networking:
meta-oe:
meta-python:
# The board support package for the Raspberry Pi.
meta-raspberrypi:
url: https://github.com/agherzan/meta-raspberrypi.git
commit: 6df7e028a2b7b2d8cab0745dc0ed2eebc3742a17
The commit hashes should be adapted to the versions of the layers that you want to use.
Create a .gitignore
file with the following content, so that the build directory and the dependencies are excluded from the repository:
Checkout the dependencies via kas:
Instead of checkout
you can also use the build
parameter to checkout the dependencies and directly build them.
Project Layer
Create an empty file conf/layer.conf
first. Otherwise, the creation of the project layer would fail. This file can be deleted after the layer creation, but it also won't hurt to keep it. Just make sure to only adapt the layer.conf
within your layer later on.
After the file was created, you can create your project layer as also described in Creating Your Own General Layer in the Yocto documentation:
You do not need to add your layer with bitbake-layers add-layer meta-project
. Add it to the project.yml
file instead as kas is taking care of the bblayers.conf
file. The layer needs to be at the meta-custom
section withing the repos
configuration:
...
repos:
meta-custom:
layers:
meta-project:
...
Add an exemption for the directory of your layer to the .gitignore
file:
!
Image Baking
You can then bake the image with the following command that is called from the main project directory:
Be aware that the build will fail, unless you allow an additional license flag in the configuration at least for the Raspberry Pi Zero 2W, but probably for other variants as well. Add the following line to meta-project/conf/layer.conf
:
In case, that you need to run bitbake commands for your project, you can always source the environment as usual and execute bitbake directly:
The image can then be found in build/tmp/deploy/images/raspberrypi0-2w-64/
.
Antworte auf diesen Post auf Mastodon.