Oliver's Dev Journal

iot observing with atalaia k8s

Oliver M. Batista — Tue, 02 Dec 2025 21:42:56 GMT

xcfghu-9y[=

Fix cedilha Fedora 42 Gnome 48

Oliver M. Batista — Sun, 23 Nov 2025 14:24:22 GMT

I am Brazilian, so I am often typing in Portuguese, and in the last 15 years as a Linux user configuring keyboard and keyboard layouts in Linux to have the ability of easily typing this character was always a ritual to be performed every time I installed a fresh Linux OS.

Today is the day to face this challenge with my current OS of choice, Bluefin Project, which is not an OS… well it’s complicated. Anyway, let’s start the search with the latest Google model, Gemini 3.0.

The first suggestion is the creation of ~/.config/environment.d/cedilha.conf and adding a couple of lines to “force” use of the cedilla module. This method did not work.

Second suggestion was about editing a .XCompose file. The name of the file got me suspicious since I am running wayland it sounded like an old way of fixing but I found out that this method do work. The library that manages the keyboard on wayland still maintain support for the .XCompose from X11. On top of that we have Gnome that ignores .XCompose by deafult. So we need to force Gnome and QT to use xim (X Input Method) and then have the .XCompose setup to replace the keystrokes ’+c into ç.

Force `xim`

mkdir -p ~/.config/environment.d && printf "GTK_IM_MODULE=xim\nQT_IM_MODULE=xim\n" > ~/.config/environment.d/cedilha.conf

Config `.XCompose`

printf 'include "%%L"\n  : "ç" Ccedilla\n  : "Ç" Ccedilla\n' > ~/.XCompose

Next stes?

I guess the best would be to have my own CI/CD action building my system .iso which is how Project Bluefin operates to create the image I used to install this current system. And to my understand anyone can do the same even using their repository as base and adding on top of it.

🤔

Well, maybe a project idea for the next article. For now, I need to go back to C++<insert a version\>.

Dive back into YOCTO

Oliver M. Batista — Fri, 07 Nov 2025 23:34:02 GMT

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.

Git inside distrobox

Oliver M. Batista — Fri, 07 Nov 2025 12:19:39 GMT

I ran this command from inside a distrobox. Because of old habits I installed git inside the distrobox. This message made me wonder how to approach this situtaion. Should I config everything in the host machine and have it somehow transfered to the distrobox when needed? Or let go with doing git inside distroboxes?

Because Distrobox mounts the host's $HOME, running git config --global modifies the single, shared ~/.gitconfig file used by both the container and the host.

Ok, cool. We can move on as if we were on the same machine. What about SSH keys?

Well, we already know that the whole $HOME is passed on, so the keys at ~/.ssh are also available to the distrobox. It seems that we need to ensure that the host’s ssh-agent is running then:

Distrobox typically passes required variables automatically, including $SSH_AUTH_SOCK, when you use the distrobox enter command.

I could also write yet another post on how to deal with keys but these links below will help:

https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent
- I usually create one key per user/device instead of doing it “per service”.
- I don’t use my email to create the key, instead: ssh-keygen -t ed25519 -C "username@hostname"
https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account

OK! I created a key and will try to use it inside a distrobox now.

It just works! Out of the box, well, in this case… anyways. I only had to answer yes to add github.com to my knowhosts file and is working. Time for me to go back to the parent article of this one.

Ops, forgot to add some important configuration. For the user.name I use the same from github.com but I believe you can use anything you want. And for the user.email I recommend enabling the private email option on github.com settings page(see below) and use that @users.noreply.github.com email they provide.

git config --global user.name "aviler" && git config --global user.email "399399+aviler@users.noreply.github.com"

Yocto blueprint

Oliver M. Batista — Sun, 02 Nov 2025 15:03:07 GMT

Just some helpers/notes to start a new project with some passionate opinions.

Here's the complete setup process:

Step 1: Initial Repository Setup

mkdir meta-forte && cd meta-forte && git init -b main

Step 2: Create Directory Structure

mkdir -p layers/meta-forte/conf/{machine,distro} && mkdir -p layers/meta-forte/recipes-{kernel/linux,security/optee,core/images,apps/hello-trustzone} && mkdir -p kas docs scripts

You can check using tree command:

📦[aviler@yocto-box meta-forte]$ tree
.
├── docs
├── kas
├── layers
│   └── meta-forte
│       ├── conf
│       │   ├── distro
│       │   └── machine
│       ├── recipes-apps
│       │   └── hello-trustzone
│       ├── recipes-core
│       │   └── images
│       ├── recipes-kernel
│       │   └── linux
│       └── recipes-security
│           └── optee
└── scripts

16 directories, 0 files

Step 3: Create .gitignore

cat > .gitignore << 'EOF'
# Kas artifacts
sources/

# Build outputs
build/
downloads/
sstate-cache/
tmp/

# Editor files
*.swp
*~
.vscode/
.idea/

# Python
__pycache__/
*.pyc
EOF

Step 4: Create Main kas.yml

cat > kas.yml << 'EOF'
header:
  version: 14

machine: beagley-ai
distro: forte-distro

repos:
  poky:
    url: https://git.yoctoproject.org/git/poky
    branch: scarthgap
    layers:
      meta:
      meta-poky:

  meta-openembedded:
    url: git@github.com:openembedded/meta-openembedded.git
    branch: scarthgap
    layers:
      meta-oe:
      meta-python:
      meta-networking:

  meta-arm:
    url: https://git.yoctoproject.org/git/meta-arm
    branch: scarthgap
    layers:
      meta-arm:
      meta-arm-toolchain:

  meta-ti:
    url: git@github.com:TexasInstruments/meta-ti.git
    branch: scarthgap
    layers:
      meta-ti-bsp:
      meta-ti-extras:

  meta-forte:
    path: layers/meta-forte

bblayers_conf_header:
  forte: |
    # Forte BeagleY-AI TrustZone Build Configuration
    BBMASK += ""

local_conf_header:
  forte: |
    # Build optimizations
    BB_NUMBER_THREADS = "8"
    PARALLEL_MAKE = "-j 8"

    # Package management
    PACKAGE_CLASSES = "package_ipk"

    # Base features
    EXTRA_IMAGE_FEATURES += "ssh-server-openssh tools-debug"

    # TrustZone/OP-TEE support (CORREÇÃO: hardware-specific)
    MACHINE_FEATURES += "optee"
    PREFERRED_PROVIDER_virtual/crypt = "optee-os"
    ARM_TF_FLAGS += "TRUSTED_BOARD_BOOT=1"

    # TI AM62x specific
    MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "ti-sci-fw"

target:
  - forte-image
EOF

Updates on the kas.yml