# 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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1761597166107/3ac28e56-2635-46c2-9cda-d27ffa157808.png align="center")

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.

```bash
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:

```bash
distrobox enter yocto-box
```

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

```bash
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:

```bash
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.

```bash
# 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:

```bash
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](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](https://oliverbatista.com/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.