<?xml version='1.0' encoding='utf-8' ?>
<!-- Made with love by pretalx v2026.1.1. -->
<schedule>
    <generator name="pretalx" version="2026.1.1" />
    <version>0.3</version>
    <conference>
        <title>OpenEmbedded Workshop 2026</title>
        <acronym>openembedded-workshop-2026-2025</acronym>
        <start>2026-02-02</start>
        <end>2026-02-02</end>
        <days>1</days>
        <timeslot_duration>00:05</timeslot_duration>
        <base_url>https://pretalx.com</base_url>
        
        <time_zone_name>Europe/Brussels</time_zone_name>
        
        
    </conference>
    <day index='1' date='2026-02-02' start='2026-02-02T04:00:00+01:00' end='2026-02-03T03:59:00+01:00'>
        <room name='Atlantis' guid='1b380e71-f83a-5fa3-bbfe-d48a6784b599'>
            <event guid='c4e90ae3-15e6-5393-890b-4d6308edb904' id='85717' code='C7WNBV'>
                <room>Atlantis</room>
                <title>Looking for Space Cowboys: Space Grade Linux</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-02-02T09:30:00+01:00</date>
                <start>09:30</start>
                <duration>00:30</duration>
                <abstract>Linux is already in space. It powers the James Webb Telescope, Starlink satellites, the Ingenuity helicopter on Mars, and free-flying robots on the ISS. But here&apos;s the problem: almost every deployment is a one-off design with zero portability between missions and no cross-vendor knowledge transfer.
Space Grade Linux (SGL) is an effort under the ELISA Project to fix this. We&apos;re building a Yocto-based distribution specifically for space deployments, following the Automotive Grade Linux model. The goal: stop reinventing the wheel, reduce time to launch, and create a trusted ecosystem that can eventually serve as a baseline for certification.
This talk covers what SGL is, why it matters, and where we need help. We have a skeleton layer, CI/CD pipeline, and early hardware support (BeagleV-Fire, Raspberry Pi CM4). What we don&apos;t have is enough developers.
If you&apos;ve ever wanted to contribute to something that might actually leave the planet, this is your chance. I&apos;ll walk through the architecture decisions, the unique constraints of spacecraft environments (radiation-induced resets, unreliable comms, no sysadmin access), and the roadmap for user space layers supporting NASA cFS, F Prime, and Space ROS.

Takeaways:

* Understanding of SGL&apos;s Yocto-based architecture and design rationale
* Overview of space-specific Linux challenges (radiation, comms, deterministic boot)
* Clear paths to contribute to an open source project with NASA, Boeing, and 20+ organizations involved</abstract>
                <slug>openembedded-workshop-2026-2025-85717-looking-for-space-cowboys-space-grade-linux</slug>
                <track></track>
                
                <persons>
                    <person id='86783'>Ramon Roche</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments>
                    <attachment href="https://pretalx.com/media/openembedded-workshop-2026-2025/submissions/C7WNBV/resources/_VvS5O4R.pdf">Slides for presentation</attachment>
                </attachments>

                <url>https://pretalx.com/openembedded-workshop-2026-2025/talk/C7WNBV/</url>
                <feedback_url>https://pretalx.com/openembedded-workshop-2026-2025/talk/C7WNBV/feedback/</feedback_url>
            </event>
            <event guid='7473ef9b-0be9-5920-8254-0c1535ffb230' id='86444' code='TKXMZB'>
                <room>Atlantis</room>
                <title>Yocto Multiverse: Building a Distro That Survives Parallel Hardware Realities</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-02-02T10:00:00+01:00</date>
                <start>10:00</start>
                <duration>00:30</duration>
                <abstract>Supporting multiple hardware platforms in a single unified environment is already complex, but introducing fundamentally different architectures such as x86, Arm, and RISC pushes that complexity even further. Differences in boot flows, BSP assumptions, and kernel configuration requirements can quickly fragment a project into parallel realities that are difficult to maintain.

Life is difficult enough, so let&apos;s see what we can do to keep it simple.</abstract>
                <slug>openembedded-workshop-2026-2025-86444-yocto-multiverse-building-a-distro-that-survives-parallel-hardware-realities</slug>
                <track></track>
                
                <persons>
                    <person id='87460'>Ming</person>
                </persons>
                <language>en</language>
                <description>In the process of creating the Embedded Computing Workbench, I needed to create a single project that would give me images for a diverse set of systems and SBCs from the single core BeagleBone Black through generic x86 to the 128 core Ampere via the RISC BeagleV-Fire.

This talk presents a practical solution I have built to support the full set of boards within a single Yocto-based distribution. It shows the choices, trade-offs, and patterns that make the system work so far and, hopefully, give it the best chance of remaining maintainable as new boards and architectures are added in the future.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments>
                    <attachment href="https://pretalx.com/media/openembedded-workshop-2026-2025/submissions/TKXMZB/resources/_ptL9fGg.pdf">Session Slides</attachment>
                </attachments>

                <url>https://pretalx.com/openembedded-workshop-2026-2025/talk/TKXMZB/</url>
                <feedback_url>https://pretalx.com/openembedded-workshop-2026-2025/talk/TKXMZB/feedback/</feedback_url>
            </event>
            <event guid='f9146267-f4cc-5ef2-8eae-ed7d7430f02a' id='87728' code='WAUFUQ'>
                <room>Atlantis</room>
                <title>Adding Support for New Boards</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-02-02T11:00:00+01:00</date>
                <start>11:00</start>
                <duration>00:30</duration>
                <abstract>In the course of the past months, Michael has added support for a few boards to community or project-specific layers, and proposes to share the experience here.

Many aspects of such work will be covered, such as: creating a new MACHINE and possibly SOC_FAMILY, dealing with vendor trees, getting rid of vendor layers, handling very early mainline Linux and U-Boot support, what should go into a machine versus into an image or a distro, how to use an initramfs or NFS when storage is not supported yet, dealing with board variants and including absolutely all modules in the root filesystem, rebuilding the kernel faster, and all this before losing your sanity and even more importantly before running out of coffee beans.

If you have ever stared at board vendor instructions trying to figure out how you are supposed to rebuild your system, you are very much the target audience for this talk.</abstract>
                <slug>openembedded-workshop-2026-2025-87728-adding-support-for-new-boards</slug>
                <track></track>
                
                <persons>
                    <person id='88394'>Michael Opdenacker, Root Commit</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links>
                    <link href="https://rootcommit.com/pub/conferences/2026/oe-workshop/yocto-new-boards/yocto-new-boards.pdf">PDF slides</link>
                </links>
                <attachments></attachments>

                <url>https://pretalx.com/openembedded-workshop-2026-2025/talk/WAUFUQ/</url>
                <feedback_url>https://pretalx.com/openembedded-workshop-2026-2025/talk/WAUFUQ/feedback/</feedback_url>
            </event>
            <event guid='bb37dcc0-698c-5036-a0da-f0eba35408f0' id='85202' code='NXKCXV'>
                <room>Atlantis</room>
                <title>SoM vendor OE layer long term maintenance</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-02-02T11:30:00+01:00</date>
                <start>11:30</start>
                <duration>00:30</duration>
                <abstract>This talk is a story of continued long term maintenance of SoM vendor OE layers. The main focus is on keeping the layers in good health and maintainable. The processes for component separation into layers and quality assurance tooling used to avoid pulling in sub-optimal changes are explained during the talk, including examples.</abstract>
                <slug>openembedded-workshop-2026-2025-85202-som-vendor-oe-layer-long-term-maintenance</slug>
                <track></track>
                
                <persons>
                    <person id='86353'>Marek Vasut</person>
                </persons>
                <language>en</language>
                <description>This talk is a story of continued long term maintenance of SoM vendor OE layers, which includes both BSP layers, application layers and derivative product layers. The main focus is on keeping the layers in good health and maintainable.

The first step is the correct placement of components into layers and their repository branches, the decision making process is explained, including examples.

The second step is the avoidance of side effects on other layers. The use of OVERRIDES to carefully control application of changes and asure avoidance of side effects is clarified.

The third step is quality assurance, which includes code review, periodic CI builds, OE patchreview, Yocto Check Layer, oelint-adv, as well as CVE and SPDX list generation. Use of each tool is explained and illustrated by an example.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments>
                    <attachment href="https://pretalx.com/media/openembedded-workshop-2026-2025/submissions/NXKCXV/resources/_ZFzr9fZ.pdf">Slide deck</attachment>
                </attachments>

                <url>https://pretalx.com/openembedded-workshop-2026-2025/talk/NXKCXV/</url>
                <feedback_url>https://pretalx.com/openembedded-workshop-2026-2025/talk/NXKCXV/feedback/</feedback_url>
            </event>
            <event guid='f8fac026-b2df-5699-8327-e477c7e03f2d' id='83108' code='ZGLVF7'>
                <room>Atlantis</room>
                <title>meta-virtualization: update: cross container installation and image bundles</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-02-02T13:15:00+01:00</date>
                <start>13:15</start>
                <duration>00:30</duration>
                <abstract>Building multi-component images (a host image plus &quot;guests&quot;) has been discussed for several years, and many different types of one-off or custom solutions exist. However, for various reasons&#8212;including reproducibility, tool lock-in, licensing, root user requirements, and namespace issues&#8212;these solutions are not officially supported by meta-virtualization. Providing a solution that all container runtimes within meta-virtualization can use has been a stated goal.

Significant development on this front has occurred in meta-virtualization over the past two releases. This talk will discuss these efforts, their current status, and plans to complete and extend the work in 2026. The presentation will demonstrate how pre-built containers can be leveraged, deployed, and expanded to provide robust and complete solutions. Opportunities to create a general-purpose multi-layer image specification in OECore will also be discussed, along with image bundling options for hypervisors.</abstract>
                <slug>openembedded-workshop-2026-2025-83108-meta-virtualization-update-cross-container-installation-and-image-bundles</slug>
                <track></track>
                
                <persons>
                    <person id='84497'>Bruce Ashfield</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments>
                    <attachment href="https://pretalx.com/media/openembedded-workshop-2026-2025/submissions/ZGLVF7/resources/_0Jc2imX.pdf">slides</attachment>
                </attachments>

                <url>https://pretalx.com/openembedded-workshop-2026-2025/talk/ZGLVF7/</url>
                <feedback_url>https://pretalx.com/openembedded-workshop-2026-2025/talk/ZGLVF7/feedback/</feedback_url>
            </event>
            <event guid='6315d02d-5fc4-57f4-9409-5a490c5218ad' id='86377' code='S7HXXR'>
                <room>Atlantis</room>
                <title>OpenEmbedded at BrightSign: A tale of three classes</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-02-02T13:45:00+01:00</date>
                <start>13:45</start>
                <duration>00:30</duration>
                <abstract>BrightSign has been using OpenEmbedded for nearly fifteen years to build BrightSign OS. Developers use Bitbake every time they make a source code change in any component, including BrightSign&apos;s proprietary software. Recipes are used for every part of the release process. They are used to generate signed firmware update files for our customers as well as to generate the myriad of files required to manufacture BrightSign media players, managing all the dependencies between them. I&apos;ll talk about how we make that work by introducing three long-serving Bitbake classes written by BrightSign.</abstract>
                <slug>openembedded-workshop-2026-2025-86377-openembedded-at-brightsign-a-tale-of-three-classes</slug>
                <track></track>
                
                <persons>
                    <person id='87707'>Mike Crowe</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links>
                    <link href="https://codeberg.org/mikecrowe/openembedded-core/src/branch/mac/brightsign-oe-classes">Repository</link>
                </links>
                <attachments>
                    <attachment href="https://pretalx.com/media/openembedded-workshop-2026-2025/submissions/S7HXXR/resources/_UkNW9jR.pdf">Slides</attachment>
                </attachments>

                <url>https://pretalx.com/openembedded-workshop-2026-2025/talk/S7HXXR/</url>
                <feedback_url>https://pretalx.com/openembedded-workshop-2026-2025/talk/S7HXXR/feedback/</feedback_url>
            </event>
            <event guid='1fd97f49-d70e-5571-8185-7855f26c5e17' id='86343' code='R8KJQZ'>
                <room>Atlantis</room>
                <title>Different Ways of Building a FIT Image</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-02-02T14:15:00+01:00</date>
                <start>14:15</start>
                <duration>00:30</duration>
                <abstract>A Flat Image Tree (FIT) was introduced quite a while ago and it&apos;s a convenient way to bundle all artifacts needed to boot a system. This talk provides an overview what we need the FIT image for and an overview of how we build it with Yocto Project. The goal is to clarify when and why FIT should be used today, and to highlight the changes and improvements you can expect in the future.</abstract>
                <slug>openembedded-workshop-2026-2025-86343-different-ways-of-building-a-fit-image</slug>
                <track></track>
                
                <persons>
                    <person id='87377'>Vyacheslav Yurkov</person>
                </persons>
                <language>en</language>
                <description>There are many options to build the FIT image with with oe-core / meta-oe. Do vendor layers also use already available approaches or they rely on a custom solutions?</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments>
                    <attachment href="https://pretalx.com/media/openembedded-workshop-2026-2025/submissions/R8KJQZ/resources/_LJtpFTR.pdf">Slides</attachment>
                </attachments>

                <url>https://pretalx.com/openembedded-workshop-2026-2025/talk/R8KJQZ/</url>
                <feedback_url>https://pretalx.com/openembedded-workshop-2026-2025/talk/R8KJQZ/feedback/</feedback_url>
            </event>
            <event guid='28880e1b-3dea-56ce-b48e-395a1ac17225' id='87678' code='8BPYDZ'>
                <room>Atlantis</room>
                <title>Embedded Linux OTA Updates: Dual A/B Partitioning vs. Delta Updates</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-02-02T15:00:00+01:00</date>
                <start>15:00</start>
                <duration>00:30</duration>
                <abstract>Regular software updates continue to play a vital role in maintaining security, addressing CVEs, fixing bugs, and extending the lifespan of embedded Linux devices, especially in light of new regulatory requirements such as the EU Cyber Resilience Act (CRA). Dual A/B redundant update schemes remain widely used in industry and are supported by leading open source OTA solutions such as Mender, RAUC, and SWUpdate. However, certain use cases, including automotive systems, wearable devices and agricultural deployments in rural or remote environments, may face bandwidth limitations that make full-image updates less suitable. This session expands beyond traditional A/B systems by exploring delta update mechanisms integration in the Yocto Project and OpenEmbedded that aim to significantly reduce the amount of data transferred during each update.

A delta OTA update is a method that calculates and transfers only the differences between the currently installed software version and the new version, rather than downloading the entire image. The open source project libostree (previously known as OSTree) provides a Git-like, content-addressed filesystem and deployment mechanism that enables atomic, versioned and incremental system updates. It is used in Torizon OS in combination with Aktualizr, a C++ implementation of the Uptane OTA update client. Uptane is a secure software update framework designed for automobiles. Developers who want the security benefits of TUF but without the full complexity of Uptane may consider using Aktualizr-Lite, a streamlined build variant of the Aktualizr project used in the Linux microPlatform.

An alternative to delta updates that offers the same benefit of transferring only the necessary binary data is the concept of adaptive updates. Delta updates include the information required to move from one specific version to another, while adaptive updates do not rely on a particular starting version. Building on top of the classical A/B update scheme, RAUC provides advanced capabilities for HTTP streaming and adaptive updates, allowing the RAUC client on the embedded Linux device to download only the parts of an update bundle that are actually needed.

The talk will compared the advantages and disadvantages of the different open source source solutions while also cover integration considerations for the Yocto Project and OpenEmbedded. Attendees will gain a clear understanding of the technical differences between full A/B redundancy, delta updates and adaptive streaming updates. The goal is to provide engineers and developers with the insight needed to select an update strategy that aligns with the bandwidth constraints, storage limitations, security requirements and long-term support expectations of their embedded Linux devices.</abstract>
                <slug>openembedded-workshop-2026-2025-87678-embedded-linux-ota-updates-dual-a-b-partitioning-vs-delta-updates</slug>
                <track></track>
                
                <persons>
                    <person id='88357'>Leon Anavi</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments>
                    <attachment href="https://pretalx.com/media/openembedded-workshop-2026-2025/submissions/8BPYDZ/resources/_gJxF8TQ.pdf">Slides</attachment>
                </attachments>

                <url>https://pretalx.com/openembedded-workshop-2026-2025/talk/8BPYDZ/</url>
                <feedback_url>https://pretalx.com/openembedded-workshop-2026-2025/talk/8BPYDZ/feedback/</feedback_url>
            </event>
            <event guid='fcb5099a-ad68-5806-ae9a-c7c3d35e1adb' id='86961' code='ZFSG7G'>
                <room>Atlantis</room>
                <title>Embedded Software, OpenEmbedded, and Sustainable Electronics</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-02-02T15:30:00+01:00</date>
                <start>15:30</start>
                <duration>00:30</duration>
                <abstract>The lifetime of electronic products is no longer defined by hardware alone&#8212;embedded software design has become a decisive factor. Choices such as build reproducibility, dependency control, update strategy, and security configuration directly affect reliability, maintainability, and long-term usability, and can either extend or prematurely end a product&#8217;s life.

This talk explores how sustainable embedded software practices can reduce electronic waste by enabling long-lived systems. Using the Yocto Project and OpenEmbedded as demonstration platforms, it presents practical examples of reproducible builds, high-quality layer design, modular BSPs, CI/CD integration, and secure update mechanisms. The session also introduces a practical Embedded Linux sustainability checklist that helps engineers assess whether their software architecture supports reliability, repairability, reuse, and long-term maintenance.

Designing for longevity is a shared responsibility between hardware and software engineering&#8212;and the Yocto Project and OpenEmbedded provide the tools and structure to make sustainable embedded systems achievable in practice.</abstract>
                <slug>openembedded-workshop-2026-2025-86961-embedded-software-openembedded-and-sustainable-electronics</slug>
                <track></track>
                
                <persons>
                    <person id='87854'>Lenka Koskov&#225; T&#345;&#237;skov&#225;</person>
                </persons>
                <language>en</language>
                <description>Embedded software has become a key driver of product lifetime. Unmaintainable code, unreproducible builds, or missing update strategies often lead to premature hardware replacement and unnecessary electronic waste.

This session bridges sustainability research and real-world embedded Linux development. It demonstrates how best practices in the Yocto Project and OpenEmbedded&#8212;such as disciplined layer management, reproducible build workflows, modular BSP design, and automated validation&#8212;support long-term reliability and maintainability.

Based on research carried out within the EECONE project, the talk introduces an Embedded Linux / OpenEmbedded sustainability checklist that translates high-level sustainability goals into concrete, actionable design questions. Rather than focusing only on energy efficiency, the checklist emphasizes long-term support, repairability, reuse, and secure updates as essential enablers of sustainable electronics.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments>
                    <attachment href="https://pretalx.com/media/openembedded-workshop-2026-2025/submissions/ZFSG7G/resources/_4ESIuyD.pdf">The Presentation Slides</attachment>
                </attachments>

                <url>https://pretalx.com/openembedded-workshop-2026-2025/talk/ZFSG7G/</url>
                <feedback_url>https://pretalx.com/openembedded-workshop-2026-2025/talk/ZFSG7G/feedback/</feedback_url>
            </event>
            <event guid='8ed2fa63-0e55-5590-bb64-17c9ba0e6683' id='87694' code='BGLXWD'>
                <room>Atlantis</room>
                <title>CRA readiness for Open Embedded-based products - what is left to do?</title>
                <subtitle></subtitle>
                <type>Talk with discussion</type>
                <date>2026-02-02T16:00:00+01:00</date>
                <start>16:00</start>
                <duration>00:45</duration>
                <abstract>OpenEmbedded and the Yocto Project offer a number of features in line with the Cyber Resilience Act (CRA) requirements, like the SBOM generation. Even if the Project itself does not fall under the CRA requirements, products that use it do, some may be even in the important or even critical category.

What elements will vendors of those products need? Are elements already in place? What will they need to implement on their own?

This presentation will get outside of the CVE checking and SBOM generation space and explore other elements from the CRA requirements.</abstract>
                <slug>openembedded-workshop-2026-2025-87694-cra-readiness-for-open-embedded-based-products-what-is-left-to-do</slug>
                <track></track>
                
                <persons>
                    <person id='88372'>Marta RYBCZYNSKA, Ygreky</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://pretalx.com/openembedded-workshop-2026-2025/talk/BGLXWD/</url>
                <feedback_url>https://pretalx.com/openembedded-workshop-2026-2025/talk/BGLXWD/feedback/</feedback_url>
            </event>
            
        </room>
        
    </day>
    
</schedule>
