Skip to content

Advantech-EECC/bsp-registry

BranchesTags

Repository files navigation

Advantech BSP configurations registry

Validate KAS Configurations Docker containers validation

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

Table of Contents

1. Build System Architecture

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

1.1. Component Overview

The build system follows a layered architecture that ensures reproducibility, isolation, and maintainability:

┌─────────────────────────────────────────┐
│         BSP Registry Manager            │  # BSP management and container orchestration
├─────────────────────────────────────────┤
│         BSP Registry Configuration      │  # BSP Registry model definition
├─────────────────────────────────────────┤
│         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
└─────────────────────────────────────────┘

1.1.1. Details

Layer Purpose Key Components
BSP Registry Manager BSP management and container orchestration bsp CLI tool (bsp-registry-tools package), YAML configuration, container definitions
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

2. Supported Hardware

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.

2.1. NXP Boards Compatibility Matrix

Table describes in which combinations yocto releases could be used together with boards.

Board \ Yocto whinlatter 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

2.1.1. Alternative View

Hardware Supported Releases Status Documentation
RSB3720 whinlatter, walnascar, styhead, scarthgap 🟢 Stable Advantech RSB-3720 Product Page · User Manual
RSB3720 4G whinlatter, walnascar 🟢 Stable (Same as RSB3720, variant-specific)
RSB3720 6G whinlatter, walnascar 🟢 Stable (Same as RSB3720, variant-specific)
RSB3730 mickledore 🟡 Development Advantech RSB-3730 Product Page · RSB-3730 User Manual (PDF) · Yocto BSP Guide
ROM2620 whinlatter, walnascar, styhead, scarthgap 🟢 Stable Advantech ROM-2620 Product Page
ROM5720 whinlatter, walnascar, styhead, scarthgap 🟢 Stable Advantech ROM-5720 Product Page
ROM5721 whinlatter, walnascar, styhead, scarthgap, mickledore 🟢 Stable Advantech ROM-5721 Product Page
ROM5721 1G whinlatter, walnascar, scarthgap, mickledore 🟢 Stable (Same as ROM5721, variant-specific)
ROM5721 2G whinlatter, walnascar, scarthgap, mickledore 🟢 Stable (Same as ROM5721, variant-specific)
ROM5722 whinlatter, walnascar, styhead, scarthgap 🟢 Stable Advantech ROM-5722 Product Page
ROM2820 whinlatter, 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)

2.1.1.1. Yocto releases

This list below covers the most recent and commonly referenced Yocto releases:

The full overview of Yocto releases can be found here https://www.yoctoproject.org/development/releases/

2.2. Isar Build System Support

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.

2.2.1. Isar Overview

📖 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)

2.2.2. Isar Hardware Support

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

2.2.3. Building Isar BSPs

Isar builds require privileged container execution to support Debian package management operations. The registry handles this automatically when using Isar-enabled containers.

Example: Build QEMU ARM64 with Debian Trixie

bsp build isar-qemuarm64-debian-trixie

Example: Build QEMU ARM64 with Ubuntu Noble

bsp build isar-qemuarm64-ubuntu-noble

2.2.4. Isar Container Configuration

Isar 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"

2.2.5. Isar Resources

2.1.2. OTA Update Support

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.

2.1.2.1. Supported OTA Technologies

  • 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

2.1.2.2. OTA Support Matrix

The following boards support OTA updates with the indicated technologies and Yocto releases:

Board RAUC SWUpdate OSTree Supported Releases
RSB3720 ✅ ✅ ✅ whinlatter, walnascar, styhead, scarthgap
RSB3720-4G ✅ ✅ ❌ whinlatter, walnascar
RSB3720-6G ✅ ✅ ❌ whinlatter, walnascar
ROM2620-ED91 ✅ ✅ ✅ whinlatter, walnascar, styhead, scarthgap
ROM2820-ED93 ✅ ✅ ✅ whinlatter, walnascar, styhead, scarthgap
ROM5720-DB5901 ✅ ✅ ✅ whinlatter, walnascar, styhead, scarthgap
ROM5721-1G-DB5901 ✅ ✅ ✅ whinlatter, walnascar
ROM5721-2G-DB5901 ✅ ✅ ✅ whinlatter, walnascar
ROM5722-DB2510 ✅ ✅ ✅ whinlatter, walnascar, styhead, scarthgap

2.1.2.3. Building Images with OTA Support

To build a BSP image with OTA support, use the bsp command:

# List all available OTA configurations
bsp list | grep rauc

# Build RSB3720 6G variant with RAUC support
bsp build modular-bsp-rauc-rsb3720-walnascar

# Build RSB3720 6G variant with SWUpdate support
bsp build modular-bsp-swupdate-rsb3720-styhead

2.1.3. Secure Boot Support

NXP-based Advantech Europe boards support cryptographic boot-image signing via HAB (High Assurance Boot, i.MX8 family) and AHAB (Advanced High Assurance Boot, i.MX9 / i.MX95 family).

📖 See docs/secure-boot.md for full instructions including:

  • Obtaining and configuring the NXP Code Signing Tool (CST)
  • Generating SRK keys and certificates
  • Required environment variables
  • Board fusing / provisioning procedures
  • CI / Azure Pipelines integration

2.1.3.1. Secure Boot Support Matrix

Board SoC Family Secure Boot Yocto Releases
ROM-2620 (ed91) i.MX8 HAB kirkstone, scarthgap, styhead, walnascar, whinlatter
ROM-5720 (db5901) i.MX8 HAB scarthgap, styhead, walnascar, whinlatter
ROM-5721 (db5901) i.MX8 HAB scarthgap, styhead, walnascar, whinlatter
ROM-5721 1G i.MX8 HAB scarthgap, walnascar, whinlatter
ROM-5721 2G i.MX8 HAB scarthgap, walnascar, whinlatter
ROM-5722 (db2510) i.MX8 HAB scarthgap, styhead, walnascar, whinlatter
RSB-3720 i.MX8 HAB scarthgap, styhead, walnascar, whinlatter
RSB-3720 4G i.MX8 HAB walnascar, whinlatter
RSB-3720 6G i.MX8 HAB walnascar, whinlatter
ROM-2820 (ed93) i.MX9 AHAB scarthgap, styhead, walnascar, whinlatter
AOM-5521 (db2510) i.MX95 AHAB scarthgap, walnascar

2.1.3.2. Building Images with Secure Boot

# Export signing environment variables before building
export CST_TOOL_PATH=/opt/cst

# Build a signed image (example: ROM-5721, Walnascar release)
bsp build  modular-bsp-rom5721-2g-db5901-secureboot-walnascar

2.3. MediaTek Boards Compatibility Matrix [preview]

The 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

2.3.1. Building MediaTek BSPs

# List available MediaTek BSPs
bsp list | grep -i mediatek

# Build MediaTek Genio 1200 EVK (scarthgap)
bsp build mediatek-genio-1200-evk-scarthgap

# Build Advantech RSB-3810 (scarthgap)
bsp build modular-bsp-rsb3810-scarthgap

2.4. Qualcomm Boards Compatibility Matrix

The 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

2.4.1. Building Qualcomm BSPs

# List available Qualcomm BSPs
bsp list | grep -i qcs

# Build Qualcomm QCS6490 RB3gen2 EVK (scarthgap)
bsp build qcs6490-rb3gen2-vision-kit-scarthgap

3. BSP Registry Manager

The BSP Registry Manager is provided by the bsp-registry-tools Python package. It offers a command-line interface (bsp) 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.

3.1. Overview

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

3.2. Installation

The BSP Registry Manager requires Python 3.7+ and is installed via pip. A virtual environment is recommended to avoid conflicts with system packages:

# Optional: create and activate a virtual environment
python3 -m venv venv
source venv/bin/activate

# Install bsp-registry-tools
pip3 install bsp-registry-tools

3.3. Basic Usage

# List available BSPs in the registry
bsp list

# Checkout and validate a BSP configuration without building (fast)
bsp build <bsp_name> --checkout

# Build a specific BSP
bsp build <bsp_name>

# Enter interactive shell for a BSP
bsp shell <bsp_name>

# Export BSP configuration
bsp export <bsp_name>

3.6. Command Reference

Command Description Example
list List all available BSPs bsp list
tree Show all available BSPs as a tree bsp tree
build <bsp_name> Build a specific BSP bsp build imx8mpevk
build <bsp_name> --checkout Checkout and validate BSP configuration without building (fast) bsp build imx8mpevk --checkout
shell <bsp_name> Enter interactive shell bsp shell imx8mpevk
export <bsp_name> Export KAS configuration bsp export imx8mpevk
containers List available containers bsp containers

3.6.1. Checkout and Validation

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:

  1. Validates BSP configuration files and dependencies
  2. Skips Docker image build (uses native KAS installation)
  3. Runs kas checkout to verify repository configurations
  4. Validates that all required source repositories can be cloned
  5. Confirms build configuration is valid without performing actual compilation

Example:

# Checkout and validate configuration for RSB3720 6G board
bsp build modular-bsp-rsb3720-6g-walnascar --checkout

4. HowTo Assemble BSPs

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

4.1. Host System dependencies

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
  • pip package manager is available
  • Docker
  • Git

The build have been tested on the following host systems: Ubuntu 22.04, Ubuntu 24.04

4.1.1. Setup Python virtual environment

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 venv

To activate virtual environment use following command:

source venv/bin/activate
4.1.1.1. Advanced Tools for Managing Multiple Python Environments

While venv and virtualenv cover most basic needs, advanced tools provide additional functionality for dependency management, reproducibility, and handling multiple Python versions.

4.1.1.2. Install Python packages dependencies

Install the bsp-registry-tools package to get the bsp CLI tool:

pip3 install bsp-registry-tools

4.1.2. Setting up Docker engine

The 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 $USER

and reboot or re-login the system for the changes to take affect.

4.1.2.1. Docker buildx

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

4.2. Building BSP

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.

4.3. HowTo build a BSP using KAS

To 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
export KAS_CONTAINER_ENGINE=docker
export KAS_CONTAINER_IMAGE=advantech/bsp-registry/ubuntu:22.04
export GITCONFIG_FILE=$HOME/.gitconfig
export DL_DIR=$HOME/cache/downloads/
export SSTATE_DIR=$HOME/cache/sstate/
 

# run the build
# kas build <path-to-kas-yaml-file>
kas build kas-configuration.yaml

4.3.1. Building a BSP image using KAS in a container

Define 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.04

Container 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 kas-configuration.yaml

4.3.2. Bitbake development shell

Using pure kas it is possible to enter bitbake shell via command:

kas shell kas-configuration.yaml

or in a docker container using following command:

kas-container shell kas-configuration.yaml

4.4. HowTo build a BSP using Repo Tool

For 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

5. Advanced Topics

This chapter provides overview of advanced topics working with KAS build configurations.

5.1. Export KAS configuration

kas tool can dump final configuration in standart output with kas dump command

kas dump kas-configuration-file.yaml > final.yaml

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

5.2. Lock KAS configuration

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

5.3. Reusing BSP Registry configurations

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-whinlatter-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-%.bbappend

where 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"

6. Patches

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, Walnascar, and Whinlatter 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.

7. Links

About

Board support package configuration registry

Topics

yocto bsp kas modularbsp

Resources

Readme

License

Apache-2.0 license
Activity
Custom properties

Stars

1 star

Watchers

0 watching

Forks

1 fork
Report repository

Releases

No releases published

Packages

 
 
 

Contributors

Languages