Hubbry Logo
OpenEmbeddedOpenEmbeddedMain
Open search
OpenEmbedded
Community hub
OpenEmbedded
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
OpenEmbedded
OpenEmbedded
OpenEmbedded
View on Wikipedia
from Wikipedia
OpenEmbedded
Developer75+ developers[1]
Repository
Operating systemLinux
PlatformCross-platform
TypeBuild automation
LicenseMIT
Websitewww.openembedded.org

OpenEmbedded (OE) is a build automation framework and cross-compile environment used to create Linux distributions for embedded devices.[2] The framework is developed by the OpenEmbedded community, which was formally established in 2003. OpenEmbedded is the recommended build system of the Yocto Project, which is a Linux Foundation workgroup that assists commercial companies in the development of Linux-based systems for embedded products.

The build system is based on BitBake. A BitBake configuration file, called a recipe, specifies various information such as dependency and source code locations, how to build a package, and how to install and remove a compiled package. OpenEmbedded tools use these recipes to fetch and patch source code, compile and link binaries, produce binary packages (ipk, deb, rpm), and create bootable images.

Historically, OpenEmbedded recipes were stored in a single repository, and the metadata was structured as what is now called "OpenEmbedded-Classic". Starting in 2010, the structure was modified to better support the ever-growing number of recipes. Recipe metadata was split into multiple layers. The lowest layer, which includes platform-independent and distribution-independent meta data is called "OpenEmbedded-Core".[3] Architecture-specific, application-specific and distribution-dependent instructions are applied in appropriate target support layers that can override or complement the instructions from lower layers. Additionally, changes to the recipes at the core layer are now managed with a pull model: instead of committing their changes directly to the repository (as was previously the case), developers now send patches to a mailing list. When approved, the patches are merged (pulled) by a maintainer.[3]

The OpenEmbedded framework can be installed and automatically updated via Git.[2]

The OpenEmbedded Image Creator, called Wic, can be used to generate disk image files; generally with extension .wic.

History

[edit]

The OpenEmbedded Project, created by Chris Larson, Michael Lauer, and Holger Schurig, merged the achievements of OpenZaurus with contributions from projects like Familiar Linux and OpenSIMpad into a common codebase. OpenEmbedded superseded these projects and was used to build any of them from the same code base.

OpenEmbedded-Core (OE-Core) resulted from the merge of the Yocto Project with OpenEmbedded.[4] Since then, all package recipes are maintained through OpenEmbedded-Core.

Layer organisation

[edit]

OpenEmbedded-Core has adapted this layered structure in the merge with Yocto and new layer entries were added over time.[5][6] The Layers represent a structure which is only of declarative nature. The specific entries are stricter in the scope of deciding which entry provides which packages. Overview of layers is available in: layers.openembedded.org/layerindex/branch/master/layers/

Developer layer
The user-defined layer for custom Bitbake recipes. Embedded system software developers would place their recipe here if the software would not fit the commercial or base layer.
Commercial layer
Packages, plugins, and configurations from open source vendors go in this layer.
UI-specific layer
Layers currently present within the meta-openembedded layer:
  • meta-efl (Enlightenment window manager)
  • meta-gnome (GNOME window manager)
  • meta-gpe (GPE window manager)
  • meta-xfce (Xfce window manager)
Hardware-specific layer
Yocto layer
  • meta-yocto (Yocto Project layer[5][4])
OpenEmbedded-Core layer
  • openembedded-core
  • meta-openembedded

Distributions supported

[edit]

In OpenEmbedded-Classic, the configurations from Base- to the UI-Layer can be supplemented by various Linux distributions. The following list is available for OpenEmbedded:

Supported hardware

[edit]

Various devices are supported:[10]

Boards and processors
The BeagleBoard from Texas Instruments, and a variety of devices based on an ARM CPU are supported.
Smartphones
Smartphones like the Nokia N800 and Neo FreeRunner are supported.
Porting to new hardware
The constellation of OpenEmbedded, especially the open design, allows it to get OpenEmbedded to adapt new hardware fairly easy.[11][improper synthesis?][12][improper synthesis?]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

OpenEmbedded

View on Grokipedia
from Grokipedia
OpenEmbedded is an open-source build framework designed for creating customizable distributions targeted at embedded systems. It provides a flexible cross-compilation environment that enables developers to build complete Linux images supporting numerous hardware architectures, including tools for efficient recreation of base systems after modifications. Originating in 2003, OpenEmbedded emerged from community efforts around projects like OpenZaurus, Familiar , and OpenSIMpad, aiming to simplify the construction of embedded environments. The framework was developed as a successor to earlier build systems, incorporating contributions from the OpenZaurus community and focusing on modularity through layered metadata. Key components include BitBake, a task execution engine that parses recipes and dependencies, and OpenEmbedded-Core, which supplies the foundational metadata for building distro-agnostic images. In March 2011, OpenEmbedded was adopted as the core build system for the Yocto Project, a collaborative initiative under the Linux Foundation launched in 2010 to standardize embedded Linux development. This integration enhanced its reach, with Yocto adding reference distributions like Poky while leveraging OpenEmbedded's infrastructure for broader industry adoption. Today, it supports cross-compilation of thousands of open-source packages—such as GTK+, Qt, X Window System, Mono, and Java—and runs on any host Linux distribution, making it highly customizable for commercial and open-source embedded applications. The project remains community-driven, hosted under the OpenEmbedded organization, and encourages contributions via public mailing lists and git repositories.

History

Origins and Early Development

OpenEmbedded was founded in January 2003 by Chris Larson, Michael Lauer, and Holger Schurig as a merger of ROM image creation tools from the OpenZaurus project and contributions from distributions like Familiar Linux. The initiative arose from the limitations of existing build systems, such as Buildroot used in OpenZaurus—a Linux distribution for Sharp Zaurus PDAs—which struggled with flexible patching and multi-architecture support despite enabling ipk package creation, feeds, and images for multiple machines. To address these issues, the founders developed a recipe-based framework for constructing custom embedded Linux images, leveraging BitBake as the underlying task executor inspired by Gentoo's Portage system. The early development emphasized a flexible, metadata-driven approach to cross-compilation, initially porting hundreds of OpenZaurus packages to support architectures for PDAs and expanding to other targets. By December 7, 2004, Chris Larson restructured the project, separating BitBake as a standalone generic build engine from OpenEmbedded's specific metadata layer, which enhanced modularity and encouraged adoption by other initiatives. That same year, OpenEmbedded was adopted as the primary build system for a refreshed OpenZaurus distribution, enabling from-scratch image generation for devices and demonstrating its viability for embedded environments. Community contributions rapidly expanded the ecosystem, adding support for graphical environments such as GTK+-based GPE and Qt-based OPIE, which were integral to PDA applications. By the mid-2000s, the project had grown to encompass thousands of packages through ongoing upstream contributions, solidifying its role as a comprehensive platform for diverse embedded Linux builds while maintaining focus on recipe-driven customization.

Integration with Yocto Project

In 2010, the Linux Foundation announced the formation of the as an open-source collaboration to provide standardized tools for building custom embedded Linux systems, with OpenEmbedded serving as its foundational build system. This initiative built on Poky, a reference distribution originally forked from OpenEmbedded in 2006, to address fragmentation in embedded Linux development. By early 2011, the projects aligned closely, resulting in the creation of OpenEmbedded-Core (OE-Core) as a shared, streamlined base layer split from Poky to enable broader collaboration while removing excess recipes, machines, and distros from the original OpenEmbedded-Classic model. This integration was officially adopted in March 2011, positioning OpenEmbedded as the underlying metadata and build framework for , under sponsorship. The post-integration changes significantly impacted OpenEmbedded's structure, introducing a standardized layer-based with OE-Core at its core to promote modularity and prevent . This shift improved through Yocto's comprehensive resources, including manuals and migration guides, which standardized best practices for contributors. Release cycles became synchronized with Yocto versions, ensuring consistent updates and testing; for example, the Kirkstone release (version 4.0) in April 2022 and the Scarthgap release (version 5.0) in April 2024 introduced enhancements like better security fixes and branches. These developments fostered a symbiotic relationship, with Yocto consuming and contributing back to OpenEmbedded repositories, enhancing reliability for embedded systems. Recent evolution through 2025 has continued this collaboration, highlighted by community events such as the Virtual Summit in December 2024, which gathered developers to discuss advancements in build tools and ecosystem integration. The OpenEmbedded Developer Meeting (OEDEM 2025) occurred on August 24, 2025, in , focusing on core metadata improvements ahead of the Open Source Summit Europe. The Developer Day followed on August 28, 2025, also in , providing hands-on training and direct interaction with technical experts. Patch releases continued with Yocto 4.0.31 in October 2025 and 5.0.13 on November 1, 2025, delivering updates and minor enhancements. Meanwhile, the OE-Classic repository remains available for legacy users but receives no active development, with migration to OE-Core strongly encouraged to align with modern standards.

Core Components

BitBake Build Engine

BitBake is a Python-based task execution engine that serves as the core build tool within OpenEmbedded, responsible for parsing metadata such as recipes, classes, and configuration files to generate and execute a series of interdependent tasks. It interprets these inputs to run shell scripts or embedded Python functions efficiently, enabling the construction of complex software stacks like embedded Linux distributions. As a generic scheduler, BitBake operates independently of specific project metadata while providing extensible mechanisms for dependency management and parallel processing. Among its core functions, BitBake performs variable expansion to handle dynamic references in metadata, using like ${VAR} for substitutions and operators such as := for immediate or = for deferred expansion during task execution. It resolves task dependencies by analyzing directives like addtask and variable flags such as [deptask] or [rdepends], ensuring tasks like do_fetch, do_compile, and do_install execute in the correct order while respecting both build-time and runtime interdependencies. For efficiency, BitBake supports parallel execution through multi-threading, configurable via the BB_NUMBER_THREADS variable, allowing multiple independent tasks to run concurrently on multi-core systems without violating dependency constraints. Configuration of BitBake occurs primarily through files like bitbake.conf, which defines global settings such as the BBPATH for metadata search and includes machine-specific options, and local.conf, which allows user overrides for host-specific parameters like thread counts or target machines. To optimize repeated builds, it enables incremental processing by tracking task completion via timestamps in the tmp/stamps directory and invalidating them only when input changes are detected through hash-based signatures. Additionally, the shared state (sstate) cache mechanism reuses pre-built artifacts from previous runs or shared repositories, validated by task signatures to skip redundant work and accelerate development cycles. BitBake incorporates an event handling system that allows developers to define handlers in metadata files using the addhandler directive, triggering Python functions on specific events like bb.event.BuildStarted or bb.build.TaskFailed for custom notifications and interventions. This system supports hooks through variable flags such as [prefuncs] and [postfuncs], enabling pre- and post-execution logic for tasks without altering their core definitions. For runtime debugging, BitBake integrates with the devtool command-line utility, which leverages its task execution (e.g., via devtool build) and sysroot management to facilitate cross-compilation, deployment to targets, and remote debugging sessions using tools like GDB.

Recipes and Metadata Classes

In OpenEmbedded, recipes are defined in files with the .bb extension, which serve as the primary metadata for building software packages. These files specify essential details such as the package's description, license, source locations, and build instructions. Key variables include DESCRIPTION, which provides a brief overview of the software; LICENSE, indicating the licensing terms (e.g., "GPLv2" or "MIT"); and SRC_URI, which lists the Uniform Resource Identifiers for fetching source code, patches, or configuration files (e.g., SRC_URI = "https://example.com/source-${PV}.tar.gz;sha256=abc123..."). Recipes also define tasks—units of execution handled by the BitBake engine—that cover the build lifecycle, including fetching sources with do_fetch, unpacking with do_unpack, applying patches via do_patch, configuring with do_configure, compiling via do_compile, installing to a staging directory with do_install, and packaging the results using do_package. Metadata classes, stored in .bbclass files, enable reusability by encapsulating common build logic that recipes can inherit. The base.bbclass, automatically inherited by all recipes, provides foundational task implementations for the standard build steps, including utilities like oe_runmake for invoking make commands and handling dependencies. For instance, the autotools.bbclass supports Autotools-based projects by defining do_configure to run autoreconf and the , do_compile to execute make, and do_install to perform make install with appropriate cross-compilation flags. Recipes inherit classes using the INHERIT variable, such as INHERIT += "autotools", which extends the recipe with the class's variables, functions, and task overrides without duplicating code. OpenEmbedded supports various variable types in recipes to control builds flexibly. Task variables, prefixed with do_ (e.g., do_compile), allow custom shell code to override default behaviors, such as adding compilation flags. Flags like EXTRA_OECONF pass additional options to configure scripts (e.g., EXTRA_OECONF += "--disable-static"), while files (.bbappend) enable modifications to existing s across layers without altering the originals; these files match the recipe name and version (e.g., busybox_1.36.1.bbappend) and can variables, tasks, or files in a layer's corresponding recipes subdirectory. Packaging formats include ipk, deb, and rpm, selected via the PACKAGE_CLASSES variable, with each format handled by dedicated classes like package_ipk.bbclass for generating IPK archives suitable for embedded systems. A representative example is the for , a compact implementation of common Unix utilities. The busybox.bb file includes SUMMARY = "Tiny versions of many common UNIX utilities in a single small executable", LICENSE = "GPL-2.0-only & bzip2-1.0.4", SRC_URI pointing to the upstream tarball and patches, and INHERIT += "cml1 update-alternatives". uses the cml1 class for its Kconfig-based configuration. It overrides tasks like do_install to stage binaries into /bin and /sbin, demonstrating how recipes combine variables, inheritance, and custom logic for efficient embedded builds. For simpler cases, a basic like one for a "helloworld" application might define SRC_URI = "file://helloworld.c", a minimal do_compile() { ${CC} ${LDFLAGS} helloworld.c -o helloworld; }, and do_install() { install -d ${D}${bindir}; install -m 0755 helloworld ${D}${bindir}; }, packaging it as an executable binary.

Layer System

Base and Core Layers

OE-Core serves as the minimal foundational layer in OpenEmbedded, providing the essential metadata required to bootstrap and build embedded Linux systems. It includes core recipes for critical components such as bootloaders (e.g., U-Boot and Barebox), the (e.g., linux-yocto), and fundamental utilities like the (glibc) and Bash shell, enabling the creation of a distro-less functional image without additional distribution-specific configurations. Built atop OE-Core, Poky functions as the reference distribution layer for the , incorporating OE-Core alongside the meta-poky and meta-yocto-bsp sublayers to offer sample configurations, machine support, and quick-start setups for developers. This structure allows users to generate complete reference images, such as core-image-minimal, while maintaining compatibility with OpenEmbedded's extensible architecture. Layers like OE-Core and Poky are integrated into the build environment through the bblayers.conf configuration file in the build directory, where the BBLAYERS variable specifies their paths; layer priority is managed via the BBFILE_PRIORITY setting in each layer's layer.conf file, with higher values (default 6) taking precedence for duplicate recipes to resolve conflicts. The bitbake-layers command-line tool facilitates layer management, supporting operations such as adding layers (bitbake-layers add-layer

), showing priorities (bitbake-layers show-layers), and creating new layers (bitbake-layers create-layer ). OE-Core releases are synchronized with branches to ensure stability and compatibility, with the master branch representing the latest development and named branches like nanbield corresponding to specific versions such as Yocto 4.3.

Specialized and Extension Layers

Specialized and extension layers in OpenEmbedded provide modular add-ons to the core system, enabling customization for specific use cases, hardware platforms, or software stacks without altering the base metadata. These layers contain recipes, configurations, and classes that integrate seamlessly with OE-Core, allowing developers to extend functionality for targeted applications such as multimedia processing, networking protocols, or vendor-specific board support. By stacking these layers atop the base and core ones, users can build tailored embedded distributions efficiently. A prominent example is Meta-OpenEmbedded, a curated collection of layers that supplements OE-Core with additional packages across various domains. It includes meta-oe, which offers general-purpose recipes for utilities and libraries not in the core; meta-python, focused on packaging Python modules and interpreters for scripting and application development; and meta-networking, which centralizes recipes for networking-related software like protocols and tools. Each layer within Meta-OpenEmbedded has designated maintainers to ensure quality and compatibility. Hardware vendor layers extend OpenEmbedded for specific processor architectures and devices, providing board support packages (BSPs) with kernel configurations, drivers, and firmware. The meta-intel layer delivers official support for x86 platforms, with recipes for updates and graphics drivers. Similarly, meta-raspberrypi supplies BSP metadata for boards, encompassing kernel variants and components for models like the Pi 4 and 5. For SoCs, the meta-ti layer offers dedicated support, including device trees and toolchain integrations tailored to TI's embedded processors. User interface and application-focused layers enable rich graphical environments on embedded targets. The meta-qt5 layer provides comprehensive recipes for Qt5 modules, tools, and demos, facilitating cross-platform UI development with support for features like and WebEngine. In parallel, meta-gnome delivers packages for the GNOME desktop environment, including core applications like shell and utilities for full-featured graphical systems. For advanced virtualization needs, the meta-virtualization layer includes support for hypervisors like and KVM, along with tools such as libvirt and container runtimes, to construct virtualized embedded solutions. The OpenEmbedded Layer Index serves as the primary resource for discovering these specialized layers, cataloging hundreds of options with details on repositories, dependencies, and supported branches. To ensure compatibility, extension layers must align with the branch of OE-Core being used, such as matching the "master" branch for the latest development or stable releases like "scarthgap," preventing metadata conflicts during builds. This branch-matching requirement, enforced through compatibility guidelines, allows layers to be layered atop base components reliably.

Build Process

Configuration and Task Execution

To begin using OpenEmbedded, developers must set up the build environment by cloning the necessary repositories, such as the Poky reference distribution which includes OpenEmbedded-Core, and then sourcing the oe-init-build-env script. This script initializes the environment by creating a build directory structure, setting essential environment variables like BBPATH and BUILDDIR, and preparing the configuration files for customization. Once sourced, the build environment is ready, and users navigate to the conf subdirectory to edit local.conf, where key variables such as MACHINE (specifying the target hardware, e.g., "qemux86-64" for emulation) and DISTRO (defining the distribution features, e.g., "poky") are configured to tailor the build to specific needs. The task execution in OpenEmbedded is orchestrated by BitBake, which, upon running bitbake <target> (e.g., bitbake core-image-minimal), first parses all metadata from recipes, classes, and configuration files to build an internal . It then resolves dependencies across recipes, ensuring that prerequisites are identified and ordered correctly before proceeding. The build process fetches via the do_fetch task, unpacks it with do_unpack, applies patches through do_patch, and continues with subsequent tasks like do_configure, do_compile, and do_install for each , executing them in a dependency-aware sequence to construct the target. BitBake's scheduling mechanism ensures efficient parallelism where possible, running independent tasks concurrently while respecting inter-task dependencies. OpenEmbedded incorporates optimization features to accelerate builds and reduce resource usage, notably the shared state (sstate) cache, which stores binary artifacts from previous builds in a designated directory (controlled by SSTATE_DIR). When a task is rerun, BitBake checks the sstate cache for matching pre-built outputs based on task signatures (hashes of inputs like versions and configurations); if found, it reuses them instead of rebuilding, significantly shortening build times on subsequent runs. For creating minimal images, users can prune unnecessary components by setting IMAGE_FEATURES to an empty value in local.conf or selecting a base like core-image-minimal, which excludes extras such as SSH servers or graphical interfaces, resulting in a lightweight filesystem focused on essential and runtime support. Debugging the configuration and task execution is facilitated by tools integrated into BitBake. The bitbake -g <target> command generates dependency graphs, producing files like pn-depends.dot (for recipe dependencies) and task-depends.dot (for task-level relations), which can be visualized using tools like to identify build order issues or circular dependencies. Additionally, the devtool command allows developers to modify directly in a workspace; for instance, devtool modify <recipe> extracts and edits sources while tracking changes, enabling quick iterations without altering upstream recipes.

Image Generation and Packaging

In OpenEmbedded, image recipes are BitBake files that specify the contents of a target filesystem , including the packages to include, root filesystem size considerations, and optional features. For instance, the core-image-minimal.bb recipe creates the smallest bootable by setting IMAGE_INSTALL to essential packages like the and basic utilities, while IMAGE_FEATURES allows enabling additional capabilities such as SSH server support (ssh-server) or development tools (dev-pkgs) without manually listing every package. These recipes inherit from the image class, which orchestrates the assembly process, and can be customized to control rootfs size through variables like IMAGE_ROOTFS_SIZE or by excluding non-essential components. The root filesystem (rootfs) is populated during the do_rootfs task, which installs packages from the previously built package feeds into a temporary directory using the configured packaging format. OpenEmbedded supports RPM, Debian (DEB), and IPK formats via the PACKAGE_CLASSES variable, with the rootfs constructed accordingly—for example, using package_rpm to populate with RPM packages and handle dependencies. Kernel modules are included automatically if specified in the kernel recipe or via IMAGE_INSTALL, and bootloader configuration, such as for U-Boot, is integrated by embedding the bootloader binary into the image structure during this phase. Following rootfs creation, the do_image tasks generate the final image files based on IMAGE_FSTYPES, such as ext4 or tar.bz2, ensuring all components like the kernel image and modules are properly incorporated. For more complex deployment scenarios, the Wic tool creates partitioned disk images from existing OpenEmbedded artifacts, supporting formats like HDDIMG for hard drives, images (e.g., sdimage-bootpart), and others such as qcow2 for emulation. Usage involves commands like wic create my-image.wks, where .wks (OpenEmbedded Kickstart) files define partitions, filesystems, and alignments; for example, a .wks can specify a boot partition with U-Boot and a rootfs partition. Wic plugins handle bootloader installation, such as embedding U-Boot into the (MBR), and incorporate kernel modules from the build's deploy/images/machine/ directory, requiring prior execution of bitbake wic-tools to enable the tool. Customization of image generation is facilitated by classes like image_types.bbclass, which processes IMAGE_FSTYPES to produce multiple output formats and applies compression or conversion as needed. Deployment options include direct flashing of generated images to devices using tools like bmaptool for efficient block-map-based writing, or testing via emulation by booting architecture-specific images (e.g., qemux86-64) without physical hardware. This process ensures images are ready for target deployment while leveraging the modularity of OpenEmbedded's build artifacts.

Supported Platforms

Target Distributions

OpenEmbedded enables the configuration of various Linux distributions tailored for embedded systems, supporting both pre-defined reference distributions and highly customizable ones through its metadata-driven approach. Reference distributions provide ready-to-use configurations that serve as starting points for development, incorporating core OpenEmbedded components like recipes and classes to produce functional images. These distributions emphasize modularity, allowing developers to build lightweight systems suitable for resource-constrained devices while maintaining compatibility with upstream Linux components. Key reference distributions include Poky, the default distribution for the , which combines OpenEmbedded-Core and BitBake with additional metadata to form a complete reference build environment focused on reliability and extensibility for embedded Linux. Another prominent example is Ångström, a flexible distribution optimized for embedded devices such as handhelds and set-top boxes, with an emphasis on web-focused applications and user-friendly interfaces through its dedicated meta-angstrom layer. These reference setups, such as Poky and Ångström, demonstrate OpenEmbedded's versatility in supporting diverse embedded use cases without requiring extensive initial customization. Custom target distributions are created by defining a specific DISTRO value in the build configuration file, such as local.conf, which loads the corresponding distro policy file to set defaults for features, packages, and behaviors. The DISTRO_FEATURES variable further refines these distributions by enabling or disabling optional capabilities; for instance, adding "x11" activates support, "wayland" includes the Wayland compositor protocol for modern graphics, while "systemd" or "sysvinit" selects the preferred init system, with providing advanced service management and sysvinit offering traditional script-based initialization. This configuration allows seamless adaptation for specific requirements, such as graphical user interfaces or minimal boot processes, ensuring the resulting distribution aligns with project goals. OpenEmbedded accommodates multiple package management systems via the PACKAGE_CLASSES variable, supporting RPM for Red Hat-based ecosystems, Debian packages (deb) for APT compatibility, and OPKG (ipk) for lightweight embedded deployments, which allows generation of package feeds in formats compatible with systems like (deb) or (RPM), facilitating use in embedded variants of those distributions. These options facilitate runtime package installation and updates on target devices, enhancing maintainability without altering the core build process. Target distributions evolve with releases for ongoing compatibility; the Scarthgap 5.0 release, for example, aligns with 6.6, incorporating updates for enhanced security and performance in modern embedded environments. Image recipes for these distributions can be further customized to include specific packages during generation.

Hardware Architectures and Devices

OpenEmbedded supports a range of core CPU architectures, enabling the creation of tailored distributions for diverse embedded hardware. The primary architectures include (both 32-bit and 64-bit variants, such as AArch32 and ), x86 (32-bit), and , which undergo regular testing via the project's Autobuilder system. Secondary support extends to PowerPC (32-bit) and (both 32-bit and 64-bit), while MIPS and PowerPC (64-bit) are classified as untested but functional through community contributions. This multi-architecture portability is achieved through architecture-specific tuning in the build configuration, where variables like MACHINE_FEATURES allow developers to enable or disable hardware capabilities such as GPU acceleration, modules, or support without altering core recipes. Board Support Packages (BSPs) in OpenEmbedded are implemented as dedicated layers that provide machine-specific configurations, kernel patches, and adaptations for target devices. For instance, the meta-beagleboard layer supports BeagleBone series boards by defining machine configurations in conf/machine/*.conf files, which specify bootloaders like U-Boot and kernel devices trees tailored to the TI AM335x processor. Similarly, meta-riscv offers BSPs for SiFive HiFive boards, integrating RISC-V-specific toolchains and firmware like OpenSBI for supervisor mode execution. The meta-xilinx layer targets FPGA-based systems, such as Zynq UltraScale+ devices, by incorporating tools for programmable logic integration and petalinux compatibility. These BSP layers ensure hardware-specific adaptations, such as peripheral drivers and memory mappings, are seamlessly incorporated into the build process. Representative example devices span consumer, industrial, and historical embedded platforms, demonstrating OpenEmbedded's versatility. The series, supported via the meta-raspberrypi layer, leverages SoCs with configurations for GPIO, , and camera interfaces, making it a staple for hobbyist and educational projects. Intel NUC mini-PCs benefit from the meta-intel layer, which tunes builds for integrated graphics and networking features on Atom and Core processors. Historical devices like the internet tablet (ARM-based) and the Neo FreeRunner smartphone (also ARM) were adapted through early OE layers, using conf/machine/*.conf to handle Maemo-like environments and hardware specifics. These adaptations involve defining kernel parameters, device tree overlays, and package selections to match the device's and peripherals. As of 2025, OpenEmbedded continues to expand hardware support, particularly for emerging platforms and AI accelerators, driven by layers and partnerships. In June 2025, International joined as a platinum member of the , promoting further upstream integration and support for platforms. The meta-riscv layer provides production-ready BSPs for boards such as the HiFive Unleashed and BeagleV-Ahead, including support for vector extensions (RVV). Support for AI accelerators is available through extension layers, enabling edge AI applications on and targets. This growth aligns with International's platinum membership in the , fostering upstream contributions for cyber-resilient embedded systems.

Community and Ecosystem

Development and Contributions

The OpenEmbedded project is governed by a non-profit corporation registered in , established as of 2015 following its prior incarnation as a German e.V. association. The governance structure includes a , responsible for overall direction and membership decisions, and a Technical Steering Committee (TSC) that oversees technical decisions, such as release planning and core development priorities. Membership in the , currently numbering over 120 individuals, is open to active contributors and requires nomination and voting approval, providing voting rights on key matters like board elections. Community communication occurs primarily through mailing lists hosted at lists.openembedded.org, with [email protected] serving as the main forum for discussions and patch submissions related to the OE-Core layer, while [email protected] handles contributions for other meta-layers. Real-time discussions take place on the IRC channel #oe at irc., where participants must register a to join and reduce spam; logs and an infobot are available for reference. The project adheres to a that promotes respectful interactions, prohibiting discriminatory or offensive behavior at events and online, and defers enforcement to the TSC for consistency. Contributions to OpenEmbedded follow a patch-based using repositories, primarily hosted at git.openembedded.org and mirrored on under the openembedded . Developers prepare changes in feature branches, commit with descriptive messages including Upstream-Status tags, and submit patches via send-email to the appropriate , such as openembedded-core for core changes. Patches undergo review through the system at patchwork.yoctoproject.org, where maintainers provide feedback, test results via tools like Patchtest, and approve or request revisions before merging. The release process involves periodic major releases aligned with cycles, such as the Scarthgap branch (Yocto 5.0), and the latest as of November 2025 being the Walnascar branch (Yocto 5.2), with stable branches maintained for 7 months post-release for standard releases and up to 4 years for LTS releases to incorporate critical fixes while avoiding major feature backports. The community organizes events to foster collaboration, including annual workshops immediately following , such as the OpenEmbedded Workshop 2025 held on February 3 in , , featuring talks on build optimizations and layer integration. Developer meetings, like the OpenEmbedded Developer Meeting (OEDEM) in on August 24, 2025, provide opportunities for in-person planning and issue resolution. Tools like the OpenEmbedded Layer Index at layers.openembedded.org assist in contribution by cataloging over 180 layers, validating compatibility through metadata checks, and enabling easy discovery of dependencies for testing and integration. Maintenance is distributed across layer-specific maintainers, who review patches, triage bugs, and ensure compatibility; for example, the meta-openembedded layer, which supplements OE-Core with additional packages, is maintained by a team including Armin Kuster. Bugs, particularly for OE-Core, are tracked via the Bugzilla at bugzilla.yoctoproject.org, where issues are filed with detailed reproduction steps and assigned to relevant maintainers; other layers may use alternative systems specified in their files. The serves as the primary framework utilizing OpenEmbedded as its core build engine, enabling the creation of tailored distributions for embedded systems through standardized layers and recipes. It offers comprehensive for OpenEmbedded integration, conducts compatibility testing via its Compatible Layers program to validate third-party extensions, and includes tools like , a web-based interface that provides visualization and management of build processes, including layer browsing from the OpenEmbedded Layer Index. Several distributions derive from OpenEmbedded, including the Ångström Distribution, which relies on OpenEmbedded-Core to deliver a lightweight, user-friendly environment optimized for devices such as handhelds and set-top boxes. Similarly, the Toradex Easy Installer uses the meta-toradex-tezi layer to generate bootable installation images for Toradex system-on-modules, streamlining OS deployment on ARM-based hardware. Containerization support is provided by the meta-virtualization layer, which enables the integration of virtualization technologies like KVM, , Docker, and Podman into OpenEmbedded builds, facilitating container-orchestrated embedded solutions without requiring external daemons in some cases. Key complementary tools enhance OpenEmbedded workflows: Kas automates the setup of reproducible build environments by managing layer repositories, configurations, and dependencies for BitBake projects. The wic utility creates partitioned disk images from existing build artifacts, supporting complex partitioning schemes for various storage media. Devtool offers a for modifying recipes, extracting sources, building, testing, and deploying software packages directly within the OpenEmbedded ecosystem. OpenEmbedded's ecosystem includes specialized layers for emerging applications, such as meta-tensorflow, which incorporates for workloads on resource-constrained devices, aligning with 2025 trends in edge AI integration. In the automotive sector, Automotive Grade (AGL) builds upon OpenEmbedded via meta-agl layers to construct compliant software stacks for vehicle infotainment and advanced driver-assistance systems. Compatibility across these extensions is tracked through the OpenEmbedded Layer Index and Yocto Project's official lists, promoting seamless adoption and updates as of 2025.

References

  1. https://www.openembedded.org/wiki/Main_Page
  2. https://2net.co.uk/embedded-history
  3. https://www.openembedded.org/wiki/OpenEmbedded_and_The_Yocto_Project
  4. https://github.com/openembedded/openembedded-core
  5. https://aosabook.org/en/v2/yocto.html
  6. https://dominion.thruhere.net/koen/OE/OE-usermanual.html
  7. https://www.linuxjournal.com/article/7866
  8. https://www.openembedded.org/pipermail/openembedded-issues/2007-September.txt
  9. https://www.linuxfoundation.org/press/press-release/yocto-project-aligns-technology-with-openembedded-and-gains-corporate-collaborators
  10. https://www.openembedded.org/wiki/OpenEmbedded-Core
  11. https://wiki.yoctoproject.org/wiki/Releases
  12. https://docs.yoctoproject.org/
  13. https://www.yoctoproject.org/event/2024-12/
  14. https://www.openembedded.org/wiki/OEDEM2025
  15. https://www.yoctoproject.org/event/yocto-project-developer-day-2025/
  16. https://lists.yoctoproject.org/g/yocto-announce/topic/announcement_yocto_project/116285728
  17. https://lists.yoctoproject.org/g/yocto-announce/topic/announcement_yocto_project/116062599
  18. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-intro.html
  19. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#variable-expansion
  20. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#dependencies-internal-to-the-bb-file
  21. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-execution.html#the-task-list
  22. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-execution.html#parsing-the-base-configuration-metadata
  23. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-execution.html#setscene
  24. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#events
  25. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#variable-flags
  26. https://docs.yoctoproject.org/dev-manual/devtool.html
  27. https://docs.yoctoproject.org/dev-manual/new-recipe.html
  28. https://docs.yoctoproject.org/ref-manual/tasks.html
  29. https://docs.yoctoproject.org/ref-manual/classes.html
  30. https://docs.yoctoproject.org/ref-manual/classes.html#autotools
  31. https://docs.yoctoproject.org/ref-manual/variables.html
  32. https://docs.yoctoproject.org/dev-manual/layers.html
  33. https://layers.openembedded.org/layerindex/recipe/349990/
  34. https://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/
  35. https://docs.yoctoproject.org/5.1/ref-manual/structure.html
  36. https://docs.yoctoproject.org/dev/dev-manual/layers.html
  37. https://git.yoctoproject.org/poky
  38. https://layers.openembedded.org/
  39. https://github.com/openembedded/meta-openembedded
  40. https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/
  41. https://layers.openembedded.org/layerindex/branch/master/layer/meta-python/
  42. https://layers.openembedded.org/layerindex/branch/master/layer/meta-networking/
  43. https://layers.openembedded.org/layerindex/branch/master/layer/meta-intel/
  44. https://layers.openembedded.org/layerindex/branch/master/layer/meta-raspberrypi/
  45. https://layers.openembedded.org/layerindex/branch/master/layer/meta-ti/
  46. https://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/
  47. https://layers.openembedded.org/layerindex/branch/master/layer/meta-gnome/
  48. https://layers.openembedded.org/layerindex/branch/master/layer/meta-virtualization/
  49. https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html
  50. https://docs.yoctoproject.org/ref-manual/structure.html
  51. https://docs.yoctoproject.org/1.5/yocto-project-qs/yocto-project-qs.html
  52. https://docs.yoctoproject.org/overview-manual/concepts.html
  53. https://docs.yoctoproject.org/2.2.2/ref-manual/ref-manual.html
  54. https://docs.yoctoproject.org/dev-manual/disk-space.html
  55. https://docs.yoctoproject.org/dev-manual/customizing-images.html
  56. https://docs.yoctoproject.org/bitbake/2.6/bitbake-user-manual/bitbake-user-manual-intro.html
  57. https://docs.yoctoproject.org/5.2.4/dev-manual/devtool.html
  58. https://docs.yoctoproject.org/ref-manual/images.html
  59. https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_FEATURES
  60. https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_INSTALL
  61. https://docs.yoctoproject.org/ref-manual/variables.html#term-PACKAGE_CLASSES
  62. https://docs.yoctoproject.org/overview-manual/concepts.html#image-generation
  63. https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_FSTYPES
  64. https://docs.yoctoproject.org/dev/dev-manual/wic.html
  65. https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-image-types
  66. https://docs.yoctoproject.org/dev-manual/qemu.html
  67. https://layers.openembedded.org/layerindex/branch/master/layer/meta-angstrom/
  68. https://docs.yoctoproject.org/ref-manual/variables.html#var-DISTRO
  69. https://docs.yoctoproject.org/ref-manual/variables.html#var-DISTRO_FEATURES
  70. https://docs.yoctoproject.org/ref-manual/variables.html#var-PACKAGE_CLASSES
  71. https://docs.yoctoproject.org/dev/dev-manual/packages.html
  72. https://docs.yoctoproject.org/migration-guides/release-notes-5.0.html
  73. https://docs.yoctoproject.org/dev/ref-manual/yocto-project-supported-features.html
  74. https://layers.openembedded.org/layerindex/branch/master/layer/meta-riscv/
  75. https://www.linuxfoundation.org/press/yocto-project-welcomes-risc-v-international-as-new-platinum-member-expands-global-ecosystem-and-leads-with-cyber-resilience-act-preparedness
  76. https://github.com/riscv/meta-riscv
  77. https://www.openembedded.org/wiki/Organization
  78. https://www.openembedded.org/wiki/Mailing_lists
  79. https://www.openembedded.org/wiki/IRC
  80. https://www.openembedded.org/wiki/Code_of_Conduct
  81. https://patchwork.yoctoproject.org/project/oe-core/list/
  82. https://docs.yoctoproject.org/dev/ref-manual/release-process.html
  83. https://pretalx.com/openembedded-workshop-2025/
  84. https://www.openembedded.org/wiki/Bug_tracking
  85. https://docs.yoctoproject.org/overview-manual/yp-intro.html
  86. https://www.yoctoproject.org/development/yocto-project-compatible-layers/
  87. https://docs.yoctoproject.org/toaster-manual/intro.html
  88. https://github.com/toradex/meta-toradex-tezi
  89. https://layers.openembedded.org/layerindex/branch/master/layer/meta-tensorflow/
  90. https://layers.openembedded.org/layerindex/branch/master/layer/meta-agl/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.