Dive back into YOCTO

Don’t think, just type.

I am starting fresh with the journey to create a YOCTO development environment, building a linux to run on my BealgeY-AI board with the layers to try out the Arm Truezone feature. Next, I would like to have RAUC, hardened security, and monitoring, but let’s start with the distrobox.

I run Project Bluefin (Fedora 42, GNOME 48) and it comes with everything to play around with distrobox and this is what I am going to use to create a separate environment from my host. From what I have seen so far the Ubuntu 22.04 LTS is the most used and recommended as base distro for running YOCTO tools and all it needs.

distrobox create --name yocto-box --image ubuntu:22.04

It will probably ask if you want to pull the image now. It shows [Y/n], Y is capitalized meaning it is the default, just hit ENTER. And then:

distrobox enter yocto-box

It will take a bit of time, but you’ll see this:

Starting container...                        [ OK ]
Installing basic packages...                 [ OK ]
Setting up devpts mounts...                  [ OK ]
Setting up read-only mounts...               [ OK ]
Setting up read-write mounts...              [ OK ]
Setting up host's sockets integration...     [ OK ]
Integrating host's themes, icons, fonts...     [ OK ]
Setting up distrobox profile...              [ OK ]
Setting up sudo...                           [ OK ]
Setting up user's group list...              [ OK ]

Container Setup Complete!
📦[aviler@yocto-box Code]$

After container is setup it will “login” us in. I am user aviler at the distrobox just created named yocto-box. The Code you see there is the current folder I am at in the disk, which is the equivalent of ~/Code/.

Let’s install the packages we need for YOCTO, first required packages:

sudo apt update && sudo apt upgrade -y && sudo apt install -y gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev xterm python3-subunit mesa-common-dev zstd liblz4-tool python3-distutils python3-git python3-jinja2 python3-pexpect

Before cloning poky getting all files in place and starting bitbaking let’s do a recap.

What is YOCTO?

The Yocto Project is not a Linux distribution - it's a framework for creating custom Linux distributions for embedded devices. Think of it as a "Linux distro factory" rather than a pre-made distro itself

At its core, Yocto Project provides:

• Build System: OpenEmbedded-Core + BitBake engine

• Metadata: Recipes, configurations, and layers that define what to build

• Tools: For cross-compilation, packaging, and system generation

• Methodology: A collaborative, standards-based approach to embedded Linux yoctoproject

The project follows a Layer Model. Each layer adds specific capabilities without modifying others. This is critical for maintainability and future-proofing. Most of the layers starts with “meta-” on their name, with the exception of “poky”, also a layer but no “meta-poky”.

Layers (everything starting with "meta-"):

• meta-arm - Arm architecture support

• meta-ti - TI processor support (includes BeagleY-AI)

• meta-beagle - BeagleBoard specific configurations

• meta-forte - Our custom layer for TrustZone

Recipes in the project:

• Recipes in the folder are instructions that build on components from the layers you added

• You can create .bbappend files to extend existing recipes from other layers

• You can create new .bb files that use components from the added layers

So the meta-forte layer would contain:

• recipes-bsp/trusted-firmware-a/ - Extends TF-A from meta-arm

• recipes-security/optee/ - Extends OP-TEE from meta-arm

• conf/machine/beagley-ai.conf - Your machine configuration

Recipes don't replace the upstream ones - they customize them for your TrustZone implementation.

Using Kas

After struggling with west tool for no reason, I crossed with kas. The kas tool is the way to go. No git submodules, YAML file that can also pass down custom configs, simple and CI/CD friendly.

# without kas
git submodule init
git submodule update
source oe-init-build-env
bitbake image

# with kas
kas build kas-project.yml

Folder structure

After some “wasted” time researching about it, I settled for this blueprint:

meta-forte/                       (GitHub repository)
├── README.md                     (documents ENTIRE process)
├── .gitignore
├── kas.yml                       (main config)
├── kas/
│   ├── dev.yml                   (build with debug)
│   ├── prod.yml                  (optimized build)
│   └── sdk.yml                   (generates SDK)
├── layers/
│   └── meta-forte/               (your custom layer)
│       ├── conf/
│       │   ├── layer.conf
│       │   ├── machine/
│       │   │   └── beagley-ai.conf  (if customization needed)
│       │   └── distro/
│       │       └── forte-distro.conf (your custom distro)
│       ├── recipes-kernel/
│       │   └── linux/            (kernel patches)
│       ├── recipes-security/
│       │   └── optee/            (TrustZone/OP-TEE recipes)
│       ├── recipes-core/
│       │   └── images/
│       │       └── forte-image.bb
│       ├── recipes-apps/
│       │   └── hello-trustzone/  (example app)
│       └── README.md
├── sources/                      (cloned by Kas - NOT versioned)
│   ├── poky/
│   ├── meta-openembedded/
│   ├── meta-arm/
│   ├── meta-ti/
│   └── meta-beagle/
├── build/                        (created by Kas - NOT versioned)
│   ├── conf/
│   └── tmp/
├── docs/                         
│   ├── 01-setup.md
│   ├── 02-build-process.md
│   ├── 03-trustzone-integration.md
│   └── architecture.png
└── scripts/                      (optional automation)
    ├── setup.sh
    └── flash-image.sh

The comments on the structure above say it all but I want to point out to things I like in it. The kas structure is very straightforward and again great when it comes to CI/CD tasks. Our layer is separated from the sources directory. The layer is considering having a trustzone hello-world example app, which is a next step for this project here.

From now on I will only make references and point it to files in the repo. I will make a separate article just for this base blueprint creation with steps and line commands. Here’s the link https://oliverbatista.com/yocto-blueprint.

TODO: start the git project using the Yocto Blueprint.

Update: kas is ok but I am going through the fixing dependencies, misplace comments and other things. Will return to it tomorrow.

Update2

Finally came back to write in this article. The yocto blueprint is building 🎉 I need to get the git repository setup and with all the changes I made to have the yocto procjet working.