A Board Support Package (BSP) build configuration registry defines environment variables, build systems and configurations to build BSP images. It ensures that the BSP can be consistently built and customized, providing a structured way to manage hardware features, initialization routines, and software components required for embedded systems. This registry allows reproducible builds across different environments and makes it easier to tailor BSPs for unique hardware platforms while maintaining compatibility with the broader OS stack.
The registry supports two build systems:
- Yocto Project: For building custom embedded Linux distributions with full control over the software stack
- Isar: For building Debian-based embedded systems using native Debian packaging tools
- Advantech BSP configurations registry
- Table of Contents
- 1. Build System Architecture
- 2. Supported Hardware
- 3. BSP Registry Manager
Build System Architecture defines the structure and workflow of how source code, configurations, and dependencies are transformed into deployable artifacts. The registry supports two build systems: Yocto Project (for custom embedded Linux distributions) and Isar (for Debian-based embedded systems).
The build system follows a layered architecture that ensures reproducibility, isolation, and maintainability:
┌─────────────────────────────────────────┐
│ BSP Registry Manager │ # BSP management and container orchestration
├─────────────────────────────────────────┤
│ Justfile Recipes │ # User-facing commands
├─────────────────────────────────────────┤
│ KAS Configuration Files │ # Build definitions
├─────────────────────────────────────────┤
│ Docker Container Engine │ # Isolated build environment
├─────────────────────────────────────────┤
│ Yocto Project / Isar Build System │ # Core build systems
├─────────────────────────────────────────┤
│ Source Layers / Debian Packages │ # BSP components
└─────────────────────────────────────────┘| Layer | Purpose | Key Components |
|---|---|---|
| BSP Registry Manager | BSP management and container orchestration | bsp.py script, YAML configuration, container definitions |
| Justfile Recipes | User-friendly command interface | just bsp, just mbsp, just ota-mbsp commands |
| KAS Configuration Files | Build definitions and dependencies | YAML configs for boards, distros, and features |
| Docker Container Engine | Isolated build environment | Consistent toolchains, isolated dependencies |
| Yocto Project / Isar Build System | Core build systems | Yocto: BitBake, OpenEmbedded, meta-layers; Isar: apt, dpkg, Debian packages |
| Source Layers / Debian Packages | BSP components | Yocto: Machine configs, recipes, kernel; Isar: Debian packages, system configuration |
The BSP build system is designed to support a wide range of hardware platforms, including reference boards, evaluation kits, and custom embedded devices. Each supported target is defined through configuration files that specify processor architecture, memory layout, peripherals, and drivers, ensuring that builds are tailored to the unique requirements of the hardware.
Table describes in which combinations yocto releases could be used together with boards.
| Board \ Yocto | walnascar | styhead | scarthgap | mickledore | langdale | kirkstone | Status |
|---|---|---|---|---|---|---|---|
| RSB3720 | ✅ | ✅ | ✅ | ❌ | ❌ | 🟡 | 🟢 Stable |
| RSB3720 4G | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | 🟢 Stable |
| RSB3720 6G | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | 🟢 Stable |
| RSB3730 | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | 🟡 Development |
| ROM2620 | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | 🟢 Stable |
| ROM5720 | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | 🟢 Stable |
| ROM5721 | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | 🟢 Stable |
| ROM5721 1G | ✅ | ❌ | ✅ | ✅ | ❌ | ❌ | 🟢 Stable |
| ROM5721 2G | ✅ | ❌ | ✅ | ✅ | ❌ | ❌ | 🟢 Stable |
| ROM5722 | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | 🟢 Stable |
| ROM2820 | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | 🟢 Stable |
| AOM5521 A1 | 🟡 | ❌ | ✅ | ❌ | ❌ | ❌ | 🟢 Stable |
| AOM5521 A2 | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | 🟢 Stable |
Status Legend:
- 🟢 Stable: Production-ready, fully tested and supported
- 🟡 Development: Under active development, may have limitations
- 🔴 EOL: End of Life, not recommended for new projects
| Hardware | Supported Releases | Status | Documentation |
|---|---|---|---|
| RSB3720 | walnascar, styhead, scarthgap | 🟢 Stable | Advantech RSB-3720 Product Page · User Manual |
| RSB3720 4G | walnascar | 🟢 Stable | (Same as RSB3720, variant-specific) |
| RSB3720 6G | walnascar | 🟢 Stable | (Same as RSB3720, variant-specific) |
| RSB3730 | mickledore | 🟡 Development | Advantech RSB-3730 Product Page · RSB-3730 User Manual (PDF) · Yocto BSP Guide |
| ROM2620 | walnascar, styhead, scarthgap | 🟢 Stable | Advantech ROM-2620 Product Page |
| ROM5720 | walnascar, styhead, scarthgap | 🟢 Stable | Advantech ROM-5720 Product Page |
| ROM5721 | walnascar, styhead, scarthgap, mickledore | 🟢 Stable | Advantech ROM-5721 Product Page |
| ROM5721 1G | walnascar, scarthgap, mickledore | 🟢 Stable | (Same as ROM5721, variant-specific) |
| ROM5721 2G | walnascar, scarthgap, mickledore | 🟢 Stable | (Same as ROM5721, variant-specific) |
| ROM5722 | walnascar, styhead, scarthgap | 🟢 Stable | Advantech ROM-5722 Product Page |
| ROM2820 | walnascar, styhead, scarthgap | 🟢 Stable | Advantech ROM-2820 Product Page |
| AOM5521 A1 | scarthgap | 🟢 Stable | Advantech AOM-5521 Product Page |
| AOM5521 A1 | walnascar | 🟡 Development | (Same as above) |
| AOM5521 A2 | walnascar | 🟢 Stable | (Same as above) |
This list below covers the most recent and commonly referenced Yocto releases:
- Walnascar (Yocto 5.2)
- Styhead (Yocto 5.1)
- Scarthgap (Yocto 5.0 LTS)
- Mickledore (Yocto 4.2)
- Kirkstone (Yocto 4.0 LTS)
The full overview of Yocto releases can be found here https://www.yoctoproject.org/development/releases/
In addition to Yocto-based BSPs, this registry supports Isar (Integration System for Automated Root filesystem generation), a build system specifically designed for creating Debian-based embedded Linux systems. Isar uses Debian's native packaging tools (apt, dpkg) rather than BitBake, providing a more familiar environment for developers experienced with Debian/Ubuntu systems.
📖 For detailed information, see the Isar Directory README which includes comprehensive documentation on configuration, build architecture, and ASCII diagrams of the image generation process.
Key Features:
- Native Debian package management (apt/dpkg)
- Supports multiple Debian-based distributions (Debian, Ubuntu)
- Faster build times for Debian-familiar developers
- Direct access to Debian package ecosystem
- Cross-compilation support for ARM, ARM64, x86, and x86-64 architectures
Supported Distributions:
- Debian (Bookworm, Bullseye, Buster, Trixie, Sid)
- Ubuntu (Focal, Jammy, Noble)
The registry includes Isar-based BSP configurations for the following targets:
| Hardware | Distribution | Status | BSP Name |
|---|---|---|---|
| RSB3720 | Debian Trixie | 🟡 Development | adv-mbsp-isar-debian-rsb3720 |
| QEMU ARM64 | Debian Trixie | ✅ Ready | isar-qemuarm64-debian-trixie |
| QEMU ARM64 | Ubuntu Noble | ✅ Ready | isar-qemuarm64-ubuntu-noble |
| QEMU ARM | Debian Trixie | ✅ Ready | isar-qemuarm-debian-trixie |
Status Legend:
- ✅ Ready: Functional and available for testing/development
- 🟡 Development: Under active development
Isar builds require privileged container execution to support Debian package management operations. The registry handles this automatically when using Isar-enabled containers.
Example: Build RSB3720 with Debian Trixie
python bsp.py build adv-mbsp-isar-debian-rsb3720Example: Build QEMU ARM64 with Debian Trixie
python bsp.py build isar-qemuarm64-debian-trixieExample: Build QEMU ARM64 with Ubuntu Noble
python bsp.py build isar-qemuarm64-ubuntu-nobleIsar builds use the isar-debian-13 container, which is automatically configured with:
- Privileged mode for package management operations
- Based on official kas-isar container images
- KAS version 5.0
- Debian Trixie base distribution
The container definition in bsp-registry.yml:
- isar-debian-13:
file: Dockerfile.isar.debian
image: "advantech/bsp-registry/isar/debian-13/kas:5.2"
privileged: true
args:
- name: "KAS_VERSION"
value: "5.2"
- name: "DISTRO"
value: "debian-trixie"- Isar Directory README - Comprehensive guide to Isar configuration, build process diagrams, and advanced topics
- Isar Documentation
- Isar GitHub Repository
- Advantech Isar Modular BSP
The BSP registry includes Over-The-Air (OTA) update configurations for supported boards. OTA updates enable remote software updates without physical access to devices, critical for production deployments.
- RAUC (Robust Auto-Update Controller): A safe and reliable software update framework that supports atomic updates with rollback capabilities
- SWUpdate: A software update framework designed for embedded systems with support for multiple update strategies
- OSTree: An upgrade system for Linux-based operating systems that performs atomic upgrades of complete filesystem trees
The following boards support OTA updates with the indicated technologies and Yocto releases:
| Board | RAUC | SWUpdate | OSTree | Supported Releases |
|---|---|---|---|---|
| RSB3720 | ✅ | ✅ | ✅ | walnascar, styhead, scarthgap |
| RSB3720-4G | ✅ | ✅ | ❌ | walnascar |
| RSB3720-6G | ✅ | ✅ | ❌ | walnascar |
| ROM2620-ED91 | ✅ | ✅ | ✅ | walnascar, styhead, scarthgap |
| ROM2820-ED93 | ✅ | ✅ | ✅ | walnascar, styhead, scarthgap |
| ROM5720-DB5901 | ✅ | ✅ | ✅ | walnascar, styhead, scarthgap |
| ROM5721-1G-DB5901 | ✅ | ✅ | ✅ | walnascar |
| ROM5721-2G-DB5901 | ✅ | ✅ | ✅ | walnascar |
| ROM5722-DB2510 | ✅ | ✅ | ✅ | walnascar, styhead, scarthgap |
To build a BSP image with OTA support, use the just ota-mbsp command:
# Build with RAUC OTA support
just ota-mbsp rsb3720 rauc walnascar
# Build with RAUC OTA support for RSB3720 4G variant
just ota-mbsp rsb3720-4g rauc walnascar
# Build with SWUpdate OTA support
just ota-mbsp rsb3720 swupdate scarthgap
# Build with OSTree OTA support
just ota-mbsp rom5722-db2510 ostree styheadAlternatively, you can use the bsp.py tool directly:
# List all available OTA configurations
python bsp.py list | grep ota
# Build a specific OTA configuration
python bsp.py build adv-ota-mbsp-oenxp-rauc-walnascar-rsb3720-6g
# Build RSB3720 4G variant with RAUC OTA support
python bsp.py build adv-ota-mbsp-oenxp-rauc-walnascar-rsb3720-4gThe BSP registry supports MediaTek-based boards through the MediaTek AIoT Rity BSP stack. The current integration targets the Yocto Scarthgap release and uses the upstream Rity v25.0 layer set. For detailed configuration, see the MediaTek vendor README and the Advantech MediaTek overlay README.
| Board \ Yocto | scarthgap | Status |
|---|---|---|
| Genio 1200 EVK | ✅ | 🟡 Development |
| RSB-3810 | ✅ | 🟡 Development |
Status Legend:
- 🟢 Stable: Production-ready, fully tested and supported
- 🟡 Development: Under active development, may have limitations
| Hardware | Supported Releases | Status | Documentation |
|---|---|---|---|
| Genio 1200 EVK | scarthgap | 🟡 Development | MediaTek Genio 1200 EVK |
| RSB-3810 | scarthgap | 🟡 Development | Advantech RSB-3810 |
# List available MediaTek BSPs
python bsp.py list | grep -i oemtk
# Build MediaTek Genio 1200 EVK (scarthgap)
python bsp.py build oemtk-scarthgap-genio-1200-evk
# Build Advantech RSB-3810 (scarthgap)
python bsp.py build adv-mbsp-oemtk-scarthgap-rsb3810
# Or use the Justfile shortcut for RSB-3810
just mtk-bsp rsb3810 scarthgapThe BSP registry supports Qualcomm-based boards through the Qualcomm Linux (QLI) BSP stack. The current integration targets the Yocto Scarthgap release and uses the QLI v1.5 Ver.1.1 layer set. For detailed configuration, see the Qualcomm vendor README and the Advantech Qualcomm overlay README.
| Board \ Yocto | scarthgap | Status |
|---|---|---|
| QCS6490 RB3gen2 | ✅ | 🟡 Development |
| AOM-2721 | ✅ | 🟡 Development |
Status Legend:
- 🟢 Stable: Production-ready, fully tested and supported
- 🟡 Development: Under active development, may have limitations
| Hardware | Supported Releases | Status | Documentation |
|---|---|---|---|
| QCS6490 RB3gen2 | scarthgap | 🟡 Development | Qualcomm RB3gen2 Vision Kit |
| AOM-2721 | scarthgap | 🟡 Development | Advantech AOM-2721 Product Page |
# List available Qualcomm BSPs
python bsp.py list | grep -i qcom
# Build Qualcomm QCS6490 RB3gen2 EVK (scarthgap)
python bsp.py build bsp-oeqcom-scarthgap-qcs6490-evk
# Or use the Justfile shortcut
just qcom-bsp qcs6490-rb3gen2-vision-kit scarthgapThe BSP Registry Manager (bsp.py) is a comprehensive Python script that provides a command-line interface for managing and building Yocto-based BSPs using the KAS build system. It features Docker container management, cached builds, and sophisticated configuration management for embedded Linux development.
The BSP Registry Manager supports:
- BSP registry management via YAML configuration files
- Docker container building and management for reproducible builds
- KAS build system integration for Yocto-based builds
- Interactive shell access to build environments
- Comprehensive error handling and configuration validation
- Advanced cache management for faster incremental builds
- Environment variable configuration management with expansion support
- KAS configuration export functionality
The BSP Registry Manager requires Python 3.7+ and can be installed using the provided requirements:
# Create and activate virtual environment
python3 -m venv venv
source venv/bin/activate
# Install dependencies
pip install -r requirements.txt
# Install bsp manager
pip install -e .# List available BSPs in the registry
python bsp.py list
# Checkout and validate a BSP configuration without building (fast)
python bsp.py build <bsp_name> --checkout
# Build a specific BSP
python bsp.py build <bsp_name>
# Enter interactive shell for a BSP
python bsp.py shell <bsp_name>
# Export BSP configuration
python bsp.py export <bsp_name>
# List available container definitions
python bsp.py containersThe BSP Registry Manager supports container definitions that can be shared across multiple BSPs:
# List all available containers
python bsp.py containers
# Example output:
# Available Containers:
# - ubuntu-20.04:
# Image: advantech/bsp-registry/ubuntu-20.04/kas:4.7
# File: Dockerfile.ubuntu
# Args: DISTRO=ubuntu:20.04, KAS_VERSION=4.7
# - ubuntu-22.04:
# Image: advantech/bsp-registry/ubuntu-22.04/kas:5.2
# File: Dockerfile.ubuntu
# Args: DISTRO=ubuntu:22.04, KAS_VERSION=5.0The BSP registry uses a YAML configuration file (default: bsp-registry.yml) with the following structure:
specification:
version: '1.0'
# Global environment variables (supports $ENV{VAR} expansion)
environment:
- name: "DL_DIR"
value: "$ENV{HOME}/yocto-cache/downloads"
- name: "SSTATE_DIR"
value: "$ENV{HOME}/yocto-cache/sstate-cache"
# Container definitions (reusable across BSPs)
containers:
- ubuntu-20.04:
file: Dockerfile.ubuntu
image: "advantech/bsp-registry/ubuntu-20.04/kas:4.7"
args:
- name: "DISTRO"
value: "ubuntu:20.04"
- name: "KAS_VERSION"
value: "4.7"
- ubuntu-22.04:
file: Dockerfile.ubuntu
image: "advantech/bsp-registry/ubuntu-22.04/kas:5.2"
args:
- name: "DISTRO"
value: "ubuntu:22.04"
- name: "KAS_VERSION"
value: "5.2"
# BSP definitions
registry:
bsp:
- name: "imx8mpevk"
description: "i.MX8MP EVK Board"
os:
name: "linux"
build_system: "yocto"
version: "scarthgap"
build:
path: "build/imx8mpevk"
copy:
- scripts/helper.sh: build/ # Copies into <build path>/build/
environment:
container: "ubuntu-22.04" # Reference to container definition
runtime_args: "--device=/dev/net/tun --cap-add=NET_ADMIN" # Optional kas-container args (e.g. for QEMU networking)
docker: "docker"
configuration:
- "conf/imx8mpevk.yml"
- "conf/scarthgap.yml"| Command | Description | Example |
|---|---|---|
list |
List all available BSPs | python bsp.py list |
build <bsp_name> |
Build a specific BSP | python bsp.py build imx8mpevk |
build <bsp_name> --checkout |
Checkout and validate BSP configuration without building (fast) | python bsp.py build imx8mpevk --checkout |
shell <bsp_name> |
Enter interactive shell | python bsp.py shell imx8mpevk |
export <bsp_name> |
Export KAS configuration | python bsp.py export imx8mpevk |
containers |
List available containers | python bsp.py containers |
The --checkout flag provides a fast way to checkout and validate BSP configurations without performing time-consuming Docker builds and Yocto compilations. This follows the KAS command naming convention (kas checkout). It is particularly useful for:
- CI/CD pipelines: Quickly verify configuration validity before committing resources to a full build
- Development iteration: Test configuration changes without waiting for complete builds
- Pre-build checks: Ensure all required files and repositories are accessible before starting a build
How it works:
- Validates BSP configuration files and dependencies
- Skips Docker image build (uses native KAS installation)
- Runs
kas checkoutto verify repository configurations - Validates that all required source repositories can be cloned
- Confirms build configuration is valid without performing actual compilation
Example:
# Checkout and validate configuration for RSB3720 6G board
python bsp.py build adv-mbsp-oenxp-walnascar-rsb3720-6g --checkout
# Checkout and validate configuration for RSB3720 4G board
python bsp.py build adv-mbsp-oenxp-walnascar-rsb3720-4g --checkout
# If validation passes, proceed with full build
python bsp.py build adv-mbsp-oenxp-walnascar-rsb3720-6gThis chapter explains how to assemble modular BSPs using KAS configuration files. It provides step‑by‑step instructions for setting up prerequisites, selecting the right configuration, and running builds to generate reproducible BSP images tailored to specific hardware platforms.
The host system must provide essential tools and libraries required for building BSPs, including compilers, version control systems, and scripting environments. Ensuring these dependencies are installed and up to date guarantees a stable build process and consistent results across different development environments.
Host system initial setup must include:
- Python 3.x
- Including python virtual environment module
pippackage manager is available- Docker
- Git
- Just
The build have been tested on the following host systems: Ubuntu 22.04, Ubuntu 24.04
It is recommended to install python based tools and packages in a separate python virtual envronment, which could be created using python virtualenv package.
python3 -m venv venvTo activate virtual environment use following command:
source venv/bin/activateWhile venv and virtualenv cover most basic needs, advanced tools provide additional functionality for dependency management, reproducibility, and handling multiple Python versions.
BSP registry repository contains requirements.txt file with the list of python modules required to run configuration and build.
pip3 install -r requirements.txtThe BSP images build would run in a docker container, meaning host system should have docker installed. If your host system is Ubuntu, check official docker installation guide at https://docs.docker.com/engine/install/ubuntu/.
To run docker from a non root user (which is required) please follow instructions from the official docker documentation https://docs.docker.com/engine/install/linux-postinstall/. But, in most cases, one command have to be executed
sudo usermod -aG docker $USERand reboot or re-login the system for the changes to take affect.
Docker buildx extends the standard Docker build command with advanced capabilities powered by BuildKit. It enables developers to build multi‑platform images, leverage efficient caching, and run builds in parallel, ensuring faster and more consistent results across diverse environments.
To download buildx binary for your host system use link below:
https://github.com/docker/buildx?tab=readme-ov-file#manual-download
Building a Board Support Package (BSP) combining Yocto, KAS, and Docker. Yocto provides the framework for creating custom Linux distributions tailored to specific hardware platforms. KAS simplifies the process by managing layered build configurations through YAML files, ensuring reproducibility and modularity. Docker adds portability by encapsulating the build environment, eliminating host system inconsistencies and making it easy to run builds across different machines.
Together, these tools enable developers to assemble BSP images in a consistent, automated, and scalable way. By defining configurations in KAS, leveraging Yocto recipes, and running builds inside Docker containers, teams can ensure reliable results while reducing setup complexity and dependency issues.
To prepare build environment for the KAS build tool, Just scripts use .env file in the root directory of current repository. .env file contains a set of typical environment variables used by kas tool.
Example .env file:
KAS_WORKDIR=<path-to>/modular-bsp-build
KAS_CONTAINER_ENGINE=docker
KAS_CONTAINER_IMAGE=advantech/bsp-registry/ubuntu:20.04
GITCONFIG_FILE=<path-to>/.gitconfig
DL_DIR=<path-to>/data/cache/downloads/
SSTATE_DIR=<path-to>/data/cache/sstate/is populated automatically by just env rule.
Path to the .gitconfig file can be adjusted
GITCONFIG_FILE=<absolute-path>/.gitconfigand paths to the yocto cache
DL_DIR=<absolute-path>/cache/downloads/
SSTATE_DIR=<absolute-path>/cache/sstate/ in the Justfile.
Available recipes:
help # Print available commands
[docker]
env distro="debian:12" # Populate .env file
docker-debian distro="debian:12" # Build official KAS Docker image based on Debian Linux
docker-ubuntu distro="ubuntu:20.04" kas="4.7" # Build KAS Docker image based on Ubuntu Linux
[yocto]
yocto action="build" bsp="mbsp" machine="rsb3720" version="walnascar" docker="ubuntu:22.04" kas="5.0" args="" # Build a Yocto BSP for a specified machine
walnascar bsp="mbsp" machine="rsb3720" # Build Yocto Walnascar BSP for a specified machine
styhead bsp="mbsp" machine="rsb3720" # Build Yocto Styhead BSP for a specified machine
scarthgap bsp="mbsp" machine="rsb3720" # Build Yocto Scathgap BSP for a specified machine
mickledore bsp="bsp" machine="rsb3730" # Build Yocto Mickledore BSP for a specified machine
kirkstone bsp="bsp" machine="rsb3720" # Build Yocto Kirkstone BSP for a specified machine
[bsp]
bsp machine="rsb3720" yocto="scarthgap" docker="ubuntu:22.04" kas="5.0" # Build BSP for a specified machine
bsp-shell machine="rsb3720" yocto="scarthgap" docker="ubuntu:22.04" kas="5.0" # Enter a BSP build environment shell for a machine
[mbsp]
mbsp machine="rsb3720" yocto="walnascar" # Build Modular BSP for a specified machine
mbsp-shell machine="rsb3720" yocto="walnascar" # Enter a "Modular BSP" build environment shell for a machine
[ota]
ota-mbsp machine="rsb3720" ota="rauc" yocto="walnascar" # Build Modular BSP with OTA support for a specified machine
ota-shell machine="rsb3720" ota="rauc" yocto="walnascar" # Enter a "Modular BSP" build environment shell with OTA support for a machine
[ros]
ros-mbsp machine="rsb3720" ros="humble" yocto="walnascar" # Enter a "Modular BSP" build environment shell for a machine
ros-shell machine="rsb3720" ros="humble" yocto="walnascar" # Enter a "Modular BSP" build environment shell with ROS support for a machine
[mtk]
mtk-bsp machine="rsb3810" yocto="scarthgap" docker="ubuntu:22.04" kas="5.2" # Build Mediatek BSP for a specified machineUse command below to build basic BSP image
# just bsp {{board name}} {{yocto release}}
just bsp rsb3720 scarthgapBSP registry repository contains a Justfile with shortcuts to simplify assembling of BSP images. To build a BSP image for a specific Yocto release use command below:
# just mbsp {{board name}} {{yocto release}}
just mbsp rsb3720 scarthgapUse command below to build i.MX images with OTA support
# just ota-mbsp {{board name}} {{ota}} {{yocto release}}
just ota-mbsp rsb3720 rauc scarthgapUse command below to build i.MX images with ROS2 support
# just ros-mbsp {{board name}} {{ros}} {{yocto release}}
just ros-mbsp rsb3720 humble scarthgapTo enter a docker container shell initialized with yocto bitbake environment run a just shortcut:
# just mbsp {{board name}} {{yocto release}}
just mbsp-shell rsb3720 scarthgapTo assemble BSP images using KAS tool following commands can be used
# activate python virtual environment
source venv/bin/activate
# add proper KAS configuration variables to your environment
source .env
# run the build
# kas build <path-to-kas-yaml-file>
kas build adv-mbsp-oenxp-walnascar-rsb3720-6g.yaml
# Build RSB3720 4G variant
kas build adv-mbsp-oenxp-walnascar-rsb3720-4g.yamlDefine environment variables KAS_CONTAINER_ENGINE and KAS_CONTAINER_IMAGE.
For example:
export KAS_CONTAINER_ENGINE=docker
export KAS_CONTAINER_IMAGE=advantech/bsp-registry/ubuntu:22.04Container image should have kas tool installed inside and use scripts/kas/container-entrypoint script. Check Dockerfile.ubuntu for reference.
To run build inside a docker container use kas-container tool
kas-container build adv-mbsp-oenxp-walnascar-rsb3720-6g.yaml
# Build RSB3720 4G variant
kas-container build adv-mbsp-oenxp-walnascar-rsb3720-4g.yamlUsing pure kas it is possible to enter bitbake shell via command:
kas shell adv-mbsp-oenxp-walnascar-rsb3720-6g.yaml
# Or for RSB3720 4G variant
kas shell adv-mbsp-oenxp-walnascar-rsb3720-4g.yamlor in a docker container using following command:
kas-container shell adv-mbsp-oenxp-walnascar-rsb3720-6g.yaml
# Or for RSB3720 4G variant
kas-container shell adv-mbsp-oenxp-walnascar-rsb3720-4g.yamlFor users who prefer the traditional Yocto workflow using the repo tool and standard BitBake commands, we provide comprehensive documentation in a separate guide.
The repo-based workflow is ideal for:
- Developers familiar with standard Yocto Project workflows
- Integration with NXP i.MX reference documentation
- Projects requiring fine-grained control over layer management
- Direct use of BitBake without container abstraction
📖 See the complete guide: Building Modular BSP using Repo Tool
This guide covers:
- Installing and configuring the repo tool
- Downloading BSP sources from the imx-manifest repository
- Setting up the build environment
- Building images for Advantech boards (RSB3720, ROM2620, ROM5722, etc.)
- Troubleshooting common issues
This chapter provides overview of advanced topics working with KAS build configurations.
kas tool can dump final configuration in standart output with kas dump command
kas dump adv-mbsp-oenxp-walnascar-rsb3720-6g.yaml > final.yaml
# Or for RSB3720 4G variant
kas dump adv-mbsp-oenxp-walnascar-rsb3720-4g.yaml > final.yamlFor details check https://kas.readthedocs.io/en/latest/userguide/plugins.html#module-kas.plugins.dump
final.yaml would contain all the included yaml configuration files and can be reused later.
Similar to kas dump there is a kas lock command, it would generate a yaml file with all layer revisions.
For datailed overview check official kas documentation https://kas.readthedocs.io/en/latest/userguide/plugins.html#module-kas.plugins.lock
It is possible to include BSP registry YAML configurations in your images (provided your project uses kas to assemble OS images). An example KAS configuration
To extend an existing BSP with a custom Yocto layer create a following kas config:
header:
version: 19
includes:
- repo: bsp-registry
file: adv-mbsp-oenxp-walnascar-rsb3720-6g.yaml
repos:
this:
layers:
meta-custom:
bsp-registry:
url: "https://github.com/Advantech-EECC/modular-bsp-build"
branch: "main"
layers:
.: "disabled"where meta-custom repository scructure looks like:
(venv) ➜ meta-custom
.
├── .config.yaml
└── meta-custom
├── conf
│ └── layer.conf
└── recipes-core
└── imx-image-%.bbappendwhere imx-image-%.bbappend recipes contains:
CORE_IMAGE_EXTRA_INSTALL += "mpv"
LICENSE_FLAGS_ACCEPTED += "commercial"and layer configuration:
# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"
# We have recipes-* directories, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "custom"
BBFILE_PATTERN_custom = "^${LAYERDIR}/"
BBFILE_PRIORITY_custom = "10"
LAYERVERSION_custom = "0.1"
LAYERSERIES_COMPAT_custom = "scarthgap"
LAYERDEPENDS_custom = "eecc-nxp"The BSP registry uses patches to fix build issues, add hardware support, and ensure compatibility across different Yocto releases. Patches are organized by vendor and Yocto version to maintain stability and reproducibility.
The repository contains 16 patches organized into:
- NXP vendor patches (12 patches): Address build failures, dependency corrections, and hardware-specific configurations for NXP i.MX platforms
- OTA feature patches (2 patches): Enable OSTree-based over-the-air updates for Styhead and Walnascar releases
- MediaTek vendor patches (2 patches): Fix recipe and git checkout issues specific to the MediaTek Rity Scarthgap BSP
All patches are documented with:
- Purpose and rationale
- Affected layers and recipes
- Yocto release compatibility
For detailed information about each patch, including what they fix and which components they affect, see the Patches Documentation.
- Building Modular BSP using Repo Tool - Alternative build method using Google's repo tool
- KAS Container
- KAS