Pull request #186: Various small changes

Merge in ICO/coreos from various_small_changes to master

* commit 'a0910ef3ff70a53ea410ba205e36a2f5620481b3':
  chore(submodules): update third-party submodules
  feat(coreos-supportd-pkgs): create list of CoreOS supported packages
  chore(belden-coreos): move the initial timestamp to a generic file
  fix(swupdate): add libgcc as a dependency to terminate swupdate correctly
  feat(eagle40-03): strip out unused MACHINE_FEATURES for eagle40-03

.gitignore

@@ -3,4 +3,5 @@ vscode-bitbake-build/
 documentation/_build/
 documentation/oe-logs
 documentation/oe-workdir
-
+__pycache__
+.venv/

.gitmodules

@@ -2,23 +2,35 @@
 	path = bitbake
 	url = ssh://git@bitbucket.gad.local:7999/ico/bitbake.git
 	branch = 2.0
-[submodule "layers/openembedded-core"]
-	path = layers/openembedded-core
+[submodule "openembedded-core"]
+	path = external-layers/openembedded-core
 	url = ssh://git@bitbucket.gad.local:7999/ico/openembedded-core.git
 	branch = kirkstone
-[submodule "layers/meta-openembedded"]
-	path = layers/meta-openembedded
+[submodule "meta-openembedded"]
+	path = external-layers/meta-openembedded
 	url = ssh://git@bitbucket.gad.local:7999/ico/meta-openembedded.git
 	branch = kirkstone
-[submodule "layers/meta-virtualization"]
-	path = layers/meta-virtualization
+[submodule "meta-virtualization"]
+	path = external-layers/meta-virtualization
 	url = ssh://git@bitbucket.gad.local:7999/ico/meta-virtualization.git
 	branch = kirkstone
-[submodule "layers/meta-efibootguard"]
-	path = layers/meta-efibootguard
+[submodule "meta-efibootguard"]
+	path = external-layers/meta-efibootguard
 	url = ssh://git@bitbucket.gad.local:7999/ico/meta-efibootguard.git
-	branch = coreos/master
-[submodule "layers/meta-swupdate"]
-	path = layers/meta-swupdate
+	branch = master
+[submodule "meta-swupdate"]
+	path = external-layers/meta-swupdate
 	url = ssh://git@bitbucket.gad.local:7999/ico/meta-swupdate.git
 	branch = kirkstone
+[submodule "meta-arm"]
+	path = external-layers/meta-arm
+	url = ssh://git@bitbucket.gad.local:7999/ico/meta-arm.git
+	branch = kirkstone
+[submodule "meta-ti"]
+	path = external-layers/meta-ti
+	url = ssh://git@bitbucket.gad.local:7999/ico/meta-ti.git
+	branch = kirkstone
+[submodule "meta-lts-kernel-mixin"]
+	path = external-layers/meta-lts-kernel-mixin
+	url = ssh://git@bitbucket.gad.local:7999/ico/meta-lts-mixins.git
+	branch = coreos/kirkstone/kernel

.vscode/extensions.json

@@ -1,6 +1,10 @@
 {
     "recommendations": [
         "ms-vscode.makefile-tools",
-        "timonwong.shellcheck"
+        "timonwong.shellcheck",
+        "kweihmann.oelint-vscode",
+        "lextudio.restructuredtext",
+        "trond-snekvik.simple-rst",
+        "yocto-project.yocto-bitbake"
     ]
 }

.vscode/settings.json

@@ -1,8 +1,47 @@
 {
     "files.watcherExclude": {
-        "**/build/cache/**": true,
-        "**/build/downloads/**": true,
-        "**/build/sstate-cache/**": true,
-        "**/build/tmp/**": true
-    }
+        "**/build/**": true,
+        "**/_build/**": true,
+    },
+    "search.exclude": {
+        "**/build/**": true,
+        "**/_build/**": true,
+    },
+    "C_Cpp.files.exclude": {
+        "**/build": true,
+        "**/_build": true,
+    },
+    "python.analysis.exclude": [
+        "**/build/**",
+        "**/_build/**",
+    ],
+    "python.formatting.provider": "black",
+    "editor.rulers": [80,100,120],
+    "bitbake.pathToBuildFolder": "${workspaceFolder}/build",
+    "bitbake.pathToEnvScript": "${workspaceFolder}/coreos-init-build-env",
+    "bitbake.pathToBitbakeFolder": "${workspaceFolder}/bitbake",
+    "python.autoComplete.extraPaths": [
+        "${workspaceFolder}/bitbake/lib",
+        "${workspaceFolder}/meta/lib"
+    ],
+    "python.analysis.extraPaths": [
+        "${workspaceFolder}/bitbake/lib",
+        "${workspaceFolder}/meta/lib"
+    ],
+    "[python]": {
+        "diffEditor.ignoreTrimWhitespace": false,
+        "gitlens.codeLens.symbolScopes": [
+            "!Module"
+        ],
+        "editor.formatOnType": true,
+        "editor.wordBasedSuggestions": "off",
+        "files.trimTrailingWhitespace": false
+    },
+    "[shellscript]": {
+        "files.eol": "\n",
+        "files.trimTrailingWhitespace": false
+    },
+    "bitbake.sdkImage": "coreos-image-minimal",
+    "bitbake.workingDirectory": "${workspaceFolder}",
+    "task.saveBeforeRun": "always",
 }

bitbake

@@ -1 +1 @@
-Subproject commit ac576d6fad6bba0cfea931883f25264ea83747ca
+Subproject commit 40fd5f4eef7460ca67f32cfce8e229e67e1ff607

coreos-init-build-env

@@ -26,7 +26,7 @@ COREOS_ROOT=$(readlink -f "${COREOS_ROOT}")
 # Set the path to bitbake, openembedded-core and the template directory
 # All theses values can be overriden by the caller of coreos-init-build-env
 BITBAKEDIR="${BITBAKEDIR:-${COREOS_ROOT}/bitbake}"
-OEROOT="${OEROOT:-${COREOS_ROOT}/layers/openembedded-core}"
+OEROOT="${OEROOT:-${COREOS_ROOT}/external-layers/openembedded-core}"
 TEMPLATECONF="${TEMPLATECONF:-${COREOS_ROOT}/templates}"
 
 # Sanity checks
@@ -84,6 +84,11 @@ coreos_path_add "${COREOS_ROOT}/scripts"
 # Add support for ##COREOS_LAYERSDIR## inside of bblayer template
 coreos-bblayers-envsub COREOS_LAYERSDIR "${COREOS_ROOT}/layers"
 
-# Generate the ${BUILDDIR}/key directory. The scripts doesn't generate anything it
-# the directory already exist, so it's safe to call it everytime
-coreos-keygen > /dev/null 2> /dev/null
+# Add support for ##COREOS_EXTLAYERSDIR## inside of bblayer template
+coreos-bblayers-envsub COREOS_EXTLAYERSDIR "${COREOS_ROOT}/external-layers"
+
+# Generate the ${BUILDDIR}/key directory. The scripts doesn't generate anything
+# if the directory already exist so it's safe to call it everytime
+# stdout is redirected to reduce the amount of output but not stderr
+#
+#Note: if a final build is detected all the dev keys are deleted

documentation/.vscode/extensions.json

@@ -0,0 +1,7 @@
+{
+    "recommendations": [
+        "ms-vscode.makefile-tools",
+        "lextudio.restructuredtext",
+        "trond-snekvik.simple-rst"
+    ]
+}

documentation/.vscode/settings.json

@@ -0,0 +1,12 @@
+{
+    "files.watcherExclude": {
+        "**/_build/**": true,
+    },
+    "python.formatting.provider": "black",
+    "editor.rulers": [
+        80,
+        100,
+        120
+    ],
+    "esbonio.sphinx.confDir": ""
+}

documentation/_static/css/coreos.css

@@ -0,0 +1,6 @@
+
+/* Make tables more convenient by wrapping line instead of using an
+   horizontal scrollbar */
+.wy-table-responsive table td, .wy-table-responsive table th {
+    white-space: normal;
+}

documentation/best_practices/cmake.rst

@@ -0,0 +1,101 @@
+***************************
+CMake with Bitbake recipes
+***************************
+
+Example of using CMake with Bitbake recipes. 
+
+Please find the example here:
+`CMake Yocto Example <https://bitbucket.gad.local/projects/ICO/repos/coreos/browse/layers/meta-belden-coreos-demo/recipes-demo/cmake-demo/cmake-demo_0.1.bb>`_.
+
+.. warning::
+   This simple example has the code in the same repo as the recipe. However, it is recommended to have the code in a separate git repo.
+   To use remote git repo, it's necessary to have settings as follows:
+   
+   * SRC_URI = "git://github.com/<link to your repo>"
+   * S="${WORKDIR}/git
+
+
+BitBake recipe
+===============
+
+Bitbake recipe inherits the cmake class and then ``CMakeLists.txt`` file can be used for building and installing.
+``CMakeLists.txt`` is expected at top of the sources tree pointed by ``SRC_URI``. 
+Usually this file is fetched using git or by downloading a tarball (.tar.gz).
+If this file is created locally it should be placed somewhere in path (usually ``<Package Name>/files``). Files that are going to be used in 
+package need to be included using ``SRC_URI +=``, files need to be included with paths relative to files directory.
+Installation of generated files can also be done using native CMake install command (which is recommended), 
+but in case something specific is needed, developer can override CMake installation with a BitBake ``do_install`` function.
+
+.. warning::
+   When using CMake for installation of some files, and using Bitbake recipe 
+   for installing other files. Bitbake's ``do_install`` will override the CMake 
+   installation, therefore, one should use ``do_install:append``.
+
+
+
+``CMakeLists.txt`` file
+========================
+When building binaries and libraries in the same package, it's a good idea to keep ``CMakeLists.txt`` 
+files split up over all source directories with top ``CMakeLists.txt`` to keep common info:
+
+* ``cmake_minimum_required`` - Defines minimum version of CMake required for desired build. Please check what version is supported by installed Yocto.
+* ``project`` - Defines project name and version.
+* ``add_subdirectory`` - If the package uses multiple ``CMakeLists.txt`` files, their directories should be included using this command.
+
+optional: ``set(CMAKE_VERBOSE_MAKEFILE ON)`` - can be used for debugging
+
+
+
+Helloworld - Simple binary example
+===================================
+
+This method shows a simple "Hello world" program written in C, 
+that uses CMake for building and installing the binary in Yocto.
+
+Additional information about this topic can be found in official 
+documentation: :external:ref:`Yocto Project - CMake
+<ref-classes-cmake>`. 
+
+
+
+CMake file - explanation
+-------------------------
+``CMakeLists.txt`` inherits top ``CMakeLists.txt``, so only minimal information is defined in this file:
+
+* ``add_executable`` - Creating binary file
+* ``install`` - Installing binary file
+
+
+
+
+Hello service - Simple binary is started in systemd
+====================================================
+
+A simple service that starts binary on boot is created. Service 
+file is installed using Bitbake method, as using CMake can be 
+avoided in this case (no need to build).
+
+
+
+
+Libdemo - Simple library example
+=================================
+
+Demo library with one function is built and installed using CMake.
+An include file is also installed.
+
+Further information about building different types of libraries can 
+be found on official CMake page: :external:ref:`Yocto Project Library documentation 
+<dev-manual/common-tasks:working with libraries>`.
+
+
+
+CMake file - explanation
+-------------------------
+
+``CMakeLists.txt`` inherits top ``CMakeLists.txt``, but this ``CMakeLists.txt`` is somewhat different compared to Helloworld:
+
+* ``add_library`` - declare the library target.
+* ``set_target_properties`` - define different properties that are useful for creating library (e.g. defining include files)
+* ``set_target_properties`` - installing files to desired locations
+

documentation/best_practices/index.rst

@@ -0,0 +1,13 @@
+
+==============================
+Belden CoreOS Best Practices
+==============================
+
+|
+
+.. toctree::
+   :caption: Table of Contents
+   :numbered:
+
+   overview
+   cmake

documentation/best_practices/overview.rst

@@ -0,0 +1,6 @@
+************************
+Best Practices Overview
+************************
+
+To ease the support and developement of CoreOS on multiple plateform,
+some examples were made to show developers good practices when working with yocto.

documentation/boot/bootflow-generic.dot

@@ -5,6 +5,5 @@ digraph G {
     
     os [label = "Operating System";shape = rect;];
     
-    fw -> btl -> os [style = dashed;];
-    fw -> os;
+    fw -> btl -> os;
 }

documentation/boot/bootflow-uboot.dot

@@ -3,7 +3,9 @@ digraph G {
     
     uboot [label = "u-boot with EFI/EBBR support";shape = rect;];
     
+    btl [label = "EFIBootGuard";shape = rect;];
+
     kernel [label = "OS (EFI Stub + Kernel + Initramfs";shape = rect;];
     
-    rom -> uboot -> kernel;
+    rom -> uboot -> btl -> kernel;
 }

documentation/boot/index.rst

@@ -11,3 +11,4 @@ Belden CoreOS Boot Concepts
 
    overview
    uboot
+   secure-boot

documentation/boot/overview.rst

@@ -63,6 +63,11 @@ machine.
 Firmware requirements
 ---------------------
 
+.. warning::
+
+  CoreOS support at the moment only hardware that contains a block storage
+  device (SD Card, eMMC, ...) formatted with GPT. MBR disk or MTD device are
+  not supported.
 
 ARM32 / AArch32 based machine
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -70,13 +75,10 @@ ARM32 / AArch32 based machine
 The firmware for ARM32 should implement a subset of the UEFI specification, as
 defined by the EBBR Specification. As this architecure is used on old hardware,
 it's ok to use the part of the specification that are marked as deprecated or
-legacy like:
-
-- MBR partitionning instead of GPT
-- Fixed offsets to firmware data
+legacy.
 
 We require the firmware to provide a DeviceTree based system description and not
-an ACPI based table (as allowed by the specification)
+an ACPI based table (as allowed by the specification).
 
 We also require the firmware to implement the UEFI Secure Boot functionality.
 
@@ -84,15 +86,12 @@ ARM64 / AArch64 based machine
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The firmware for ARM64 should implement a subset of the UEFI specification, as
-defined by the EBBR Specification. The part of the specification marked as
-legacy or deprecated must not be used.
-
-This means:
-- Only GPT partionning disk are supported
-- No fixed offsets to firmware data
+defined by the EBBR Specification.
 
 We require the firmware to provide a DeviceTree based system description and not
-an ACPI based table (as allowed by the specification)
+an ACPI based table (as allowed by the specification). The DeviceTree provided
+by the firmware can be very minimal as it can be replaced at boot time
+by a device-tree contained inside the Operating System Image.
 
 We also require the firmware to implement the UEFI Secure Boot functionality.
 
@@ -105,38 +104,13 @@ The firmware for AMD64 should implement the UEFI specification.
 Bootloader
 ==========
 
-CoreOS only support `systemd-boot` as bootloader. The usage of the bootloader
-is optional. It's primary use case is for system that don't use a firmware
-provided by CoreOS.
+CoreOS only support `efibootguard` as bootloader. The usage of the bootloader
+is mandated.
 
 
 Operating system
 ================
 
-The operating system image is an UEFI application that contain the kernel. We
-support two method to create this image:
+The operating system image is an UEFI application that contain the kernel. It's
+a Unified Kernel Image generated by tools from the EFIBootGuard project.
 
-Unified Kernel Images (UKI)
----------------------------
-
-This is the most secure method. The UEFI entry point is provided by
-`systemd-stub` and the image contains the Linux Kernel, the boot arguments of
-the kernel, the os-release file and an initrd ram disk.
-
-This allows to have all these part authenticated via UEFI secure boot.
-
-.. warning::
-   UKI are not supported for ARM32 target at the moment, due to a bug in objcopy.
-   See https://sourceware.org/bugzilla/show_bug.cgi?id=26218
-
-.. note::
-    UKI has the advantages to be discoverable by the bootloader without any
-    configuration file, and doesn't need a firmware that is able to set the
-    kernel command line.
-
-Kernel built with the built-in EFI sub
---------------------------------------
-
-This method use the EFI stub provided by the kernel. The initramfs image has to
-be bundled with the Kernel, using `INITRAMFS_IMAGE_BUNDLE`, as otherwise it 
-will not be authenticated by UEFI secure boot.

documentation/boot/secure-boot.rst

@@ -0,0 +1,268 @@
+*******************
+Secure Boot Concept
+*******************
+
+Currently CoreOS provide a Proof Of Concept of some of the secure boot element that we want to 
+implement a full secure-boot solution based on UEFI secure boot.
+
+The current proof of concept is structured as follows:
+
+Hardware Requirements
+=====================
+   
+   - The device must have an `eMMC`.
+   - The architecture of the device must be either `ARM32` or `AARCH64`.
+
+
+eMMC Embedded MultiMediaCard
+============================
+
+eMMC, or Embedded MultiMediaCard, represents a prevalent storage format in devices such as 
+smartphones, tablets, and other embedded systems. It encapsulates NAND flash memory and a dedicated
+controller within one package. This structure not only eases integration for device manufacturers
+but also ensures a compact, efficient storage medium.
+
+Within eMMC's architecture, distinct hardware partitions cater to diverse operational demands:
+
+.. graphviz::
+
+    digraph emmcStructure {
+        rankdir=TB;
+        node [shape=box, style=filled, fillcolor="#e6f2ff"];
+        edge [color="#0099cc", fontsize=12];
+
+        compound=true;
+
+        subgraph cluster_eMMC {
+            label="eMMC";
+            color="#0099cc";
+
+            Boot0 [label="Boot0"];
+            Boot1 [label="Boot1"];
+            RPMB [label="RPMB"];
+
+            subgraph cluster_User {
+                label="User";
+                color="#00cc99";
+                GPT [label="GPT Table"];
+
+                subgraph cluster_GPT {
+                    label="Software Partitions (GPT)";
+                    color="#99e6e6";
+
+                    SoftwarePartition1 [label="Partition 1"];
+                    SoftwarePartition2 [label="Partition 2"];
+                    SoftwarePartitionN [label="Partition N"];
+                }
+            }
+        }
+    }
+
+
+#. **Boot0 and Boot1**: The boot partitions cater to device start-up requirements, typically hosting
+   the firmware. Boot0 predominantly initiates the boot-up, while Boot1 stands as a secondary guard 
+   or backup, ensuring booting is resilient and failsafe.
+
+#. **RPMB (Replay Protected Memory Block)**: As a secure partition, RPMB shelters data against
+   potential tampering. It's tailored for sensitive information storage, such as cryptographic keys.
+   Its design counters data replays or rollbacks, fortifying against particular attack types.
+
+#. **User**: The primary storage domain, the User partition accommodates the OS, applications,
+   and user-centric data. It's reminiscent of the primary storage drive in larger computing devices.
+   Importantly, the User partition has a layered structure. Using the GPT (GUID Partition Table), it
+   is further divided into multiple software partitions, which can house diverse datasets or file
+   systems.
+
+The boot concept of CoreOS rely on the presence of an eMMC to implement the following feature:
+
+- Storage of two copy of the firmware with a way to switch from a copy to another using the eMMC
+  boot0 and boot1 hardware partition
+- Storage of keys used by the UEFI Secure Key specification inside the secure RPMB hardware
+  partition.
+- Storage of the bootloader, kernel and rootfs inside the user hardware partition using multiple
+  software partition in the GPT format.
+
+Firmware
+========
+
+The firmware of the device should implement a subset of the UEFI specification as defined in the
+ARM Base Boot Requirements (EBBR) and should implement the optional UEFI Secure Boot part of the
+EBBR specifications.
+
+This is done in CoreOS by levering the built-in EBBR and UEFI Secure Boot present into the u-boot
+project.
+
+The hardware should verify the validity of the firmware using a hardware specific way. Then the
+generic secure boot concept explained here can be used to valide all the following component of
+CoreOS.
+
+UEFI Key used by UEFI Secure Boot
+=================================
+
+
+- **PK (Platform Key)**: This top-tier key shoulders the responsibility of KEK verification and its
+  potential revocation. PK holders have the exclusive privilege to configure the KEK and the `db`
+  database. It's the gatekeeper ensuring only authorized software can touch the firmware or
+  bootloader.
+
+- **KEK (Key Exchange Key)**: As a medium for data exchange, the KEK is pivotal for signing the `db`
+  and `dbx` databases.
+  
+- **db (Allowed Database)**: This is the white list. It houses the keys or hashes of permitted
+  firmware and OS loaders. Execution is only granted to software with a signature that resonates
+  with the keys/hashes in this database.
+  
+- **dbx (Forbidden Database)**: The black sheep are here. Housing keys or hashes of known
+  unauthorized software, it ensures any associated software is prohibited from executing.
+
+Currently all theses public keys are built-in into u-boot at build time and are read only. In the
+future we will use the OP-TEE support into u-boot to use OP-TEE to manage the keys.
+
+OP-TEE and RPMB as key manager
+==============================
+
+OP-TEE, or Open Portable Trusted Execution Environment, is an open-source implementation of the
+Trusted Execution Environment (TEE) designed for ARM-powered platforms. In essence, a TEE is a
+secure enclave that provides a separated, isolated environment where specific applications and their
+data can run independently from the regular operating system, ensuring they are protected against
+potential tampering or unauthorized access.
+
+OP-TEE guarantees confidentiality, integrity, and authenticity for critical applications by
+executing them in this secure space. It offers a wide range of security features, including secure
+storage of cryptographic keys, secure boot, and hardware-backed crypto operations.
+
+In the context of UEFI secure boot, OP-TEE becomes instrumental. UEFI's secure boot mechanism
+ensures that only trusted, signed firmware, OS loaders, and OS kernels are executed during the boot
+process. To enforce this level of trust, UEFI relies on a set of cryptographic keys, including PK
+(Platform Key), KEK (Key Exchange Key), and db/dbx (allowed and forbidden signature databases).
+Safeguarding these keys is paramount to maintain the security and integrity of the boot process.
+
+By leveraging OP-TEE, these UEFI secure boot keys can be securely stored in the RPMB (Replay
+Protected Memory Block) partition of the eMMC. The RPMB is a write-protected, secure area of the
+eMMC designed to hold sensitive data and protect it against tampering and replay attacks.
+Since OP-TEE manages secure access to the RPMB partition, it ensures that the UEFI secure boot keys
+are not only safely stored but are also accessible only by authorized firmware components.
+
+eMMC User Partition
+===================
+
+The user partition of the eMMC must be structured using the GPT (GUID Partition Table) format.
+
+Within the GPT-formatted user partition, specific partitions should be established for efficient
+booting and system operation:
+
+1. **EFI**: This is the Essential Firmware Interface partition. It holds the `efibootguard`
+   os-loader binary, responsible for the boot sequence's initial steps and the kernel's selection
+   based on its configuration. This binary is signed with a key present in the `dbx` database
+
+2. **EBG0 - Efibootguard Config 0**: This partition houses the `efibootguard` configuration for the
+   first kernel option. Alongside the configuration file, it also contains a Unified Kernel Image
+   (UKI), a bundled package comprising the Linux kernel, device trees, and associated boot
+   components. The UKI is signed with a key present in the `dbx` database
+
+3. **EBG1 - Efibootguard Config 1**: Similar to EBG0, this partition carries the `efibootguard`
+   configuration for the second kernel option. It too holds a Unified Kernel Image tailored for this
+   alternate boot choice.
+
+4. **rootfs0**: This partition stores the CoreOS root filesystem designed to complement and operate
+   with the kernel embedded in the EBG0 partition. It provides the essential system files and 
+   structures required for the operating system's functioning when the kernel from EBG0 is booted. 
+   Integrety of this rootfs is assured by storing an hash of the rootfs inside the UKI image.
+
+5. **rootfs1**: Analogous to `rootfs0`, this partition houses the CoreOS root filesystem tailored
+   for the kernel within the EBG1 partition. It ensures that, should the system boot from the kernel
+   in EBG1, the appropriate file structures and system components are readily available.
+
+EFIBootGuard Configuration
+==========================
+
+Efibootguard, as a part of its design, employs a configuration system to determine the appropriate
+kernel and associated resources to boot from. This configuration is stored in distinct partitions, 
+EBG0 and EBG1, each holding its configuration file.
+
+The configuration file itself comprises several fields, but most crucially, it contains a revision
+field. This field is a numerical identifier indicating the version or update level of the contained
+kernel and resources. When the system initiates its boot sequence, Efibootguard assesses the
+revision values in both the EBG0 and EBG1 configuration files.
+
+The selection process is straightforward yet robust: Efibootguard chooses the partition with the
+higher revision value. By doing so, it inherently opts for the most recent or updated kernel version
+available. However, this system also supports failover mechanisms. In case the kernel in the
+partition with the higher revision encounters issues during boot, Efibootguard can revert to the
+other partition, ensuring resilience and continuity in system operations.
+
+Moreover, the choice isn't rigidly fixed. When the system undergoes updates, the configuration files
+can be rewritten, and the revision values adjusted, allowing for dynamic and flexible booting in
+line with system evolutions and updates. In essence, Efibootguard, with its configuration-based
+approach, ensures a blend of up-to-date system booting and built-in fail-safes for dependable
+operation.
+
+Unified Kernel Image
+====================
+
+After having choosen the right configuration file, Efibootguard takes on the responsibility of
+launching the Unified Kernel Image (UKI) linked with the active configuration. This image bundle
+together essential boot components like the Linux kernel, device trees, and the kernel command
+line. The secure initiation of this image is paramount, and Efibootguard ensures this by leveraging
+UEFI's start_image system call.
+
+The UEFI start_image system call  verifies the image's signature against the Secure Boot keys
+(PK, KEK, db, and potentially dbx). If the signature matches, indicating that the image is trusted
+and hasn't been tampered with, the image is permitted to execute. If not, the booting halts,
+preventing any unauthorized or potentially malicious code from running.
+
+Once the UKI has been securely initiated, it undertakes multiple tasks. It first extracts the
+necessary components from the bundled package, identifying and utilizing the appropriate device
+trees based on `compatible` node, by matching with the `compatible` node of the `device-tree` that
+is built into the firmware. These device trees inform the system about the hardware configuration,
+ensuring the kernel interacts correctly with the system's components. 
+
+The UKI os-launcher also has CoreOS specialized patches, enabling dynamic rootfs switching without
+requiring an initramfs by changing the `root=` part of the kernel command line at run time to
+point to the right rootfs partition.
+
+RootFS and dm-verity
+====================
+
+dm-verity is a Linux kernel feature designed to provide transparent integrity checking of block
+devices, particularly for read-only file systems. Rooted in cryptographic principles, dm-verity
+employs a hash-based approach to ensure and validate the integrity of the root filesystem (rootfs).
+
+The way dm-verity operates is by building a Merkle tree, a structure where each leaf node contains a
+hash of a block of the underlying data, while each non-leaf node is a hash of its children. The
+topmost node, the root of the Merkle tree, provides a cumulative hash representing the entirety of
+the data. This top hash, known as the root hash, serves as a concise, cryptographic representation
+of the entire filesystem's state.
+
+When integrating dm-verity with the Unified Kernel Image (UKI), an additional layer of security is
+established. By embedding the root hash into the signed UKI, any tampering or modification in the
+rootfs can be swiftly detected. When the system boots, the UKI, being signed, ensures that the
+embedded root hash is legitimate and untampered. As the OS accesses the rootfs, dm-verity
+recalculates the hash values in real-time and compares them to the values in the original Merkle
+tree, referenced by the embedded root hash.
+
+If any discrepancies are found – that is, if the recalculated hash doesn't match the stored value –
+it indicates potential tampering, and the OS can halt access or take appropriate measures. 
+
+.. graphviz::
+
+    digraph SecureBootFlow {
+        rankdir=TB;
+
+        node [shape=box, style=filled, fillcolor="#e6f2ff"];
+        edge [color="#0099cc", fontsize=12];
+
+        Hardware [label="Hardware\n(ARM32/AARCH64 with eMMC)"];
+        Firmware [label="u-boot Firmware\n(UEFI EBRR subset)"];
+        eMMCConfig [label="eMMC Configuration\n(GPT with EFI partition)"];
+        EFIBootGuard [label="EFIBootGuard\n(A/B Kernel Switching)"];
+        UnifiedKernel [label="Unified Kernel Image\n(Kernel, cmd line, DTB)"];
+        KernelAndRootFS [label="Kernel & RootFS\n(dm-verity validation)"];
+
+        Hardware -> Firmware [label="Flashed with u-boot\n+ Built-in keys"];
+        Firmware -> eMMCConfig [label="eMMC boot"];
+        eMMCConfig -> EFIBootGuard [label="Boots from EFI partition"];
+        EFIBootGuard -> UnifiedKernel [label="Selects kernel A/B"];
+        UnifiedKernel -> KernelAndRootFS [label="Kernel boot\n+ RootFS verification"];
+
+    }

documentation/boot/uboot-dts-handling.dot

@@ -1,16 +0,0 @@
-digraph G {
-    start [label = "boot";];
-    
-    mb [label = "Detect the main board name";shape = rect;];
-    
-    mbdts [label = "Load main board device tree";shape = rect;];
-    
-    ext [label = "Detect the extension module name";shape = rect;];
-    extdts [label = "Load a device tree overlay for each module";shape = rect;];
-    
-    dtsprocess [label = "Add and remove device tree node as needed (DT Fixup)";shape = rect;];
-    
-    stop [label = "Start UEFI application";];
-    
-    start -> mb -> mbdts -> ext -> extdts -> dtsprocess -> stop;
-}

documentation/boot/uboot.rst

@@ -21,13 +21,10 @@ to be changed at runtime.
 Device tree handling
 ====================
 
-As per the EBBR specification, the firmware is responsible to provide the
-device tree to the kernel.
-
-This means that loading the main device tree and all the device tree overlay are
-is the responsibility of the firmware.
-
-.. graphviz:: uboot-dts-handling.dot
+As per the EBBR specification, the firmware is responsible to provide a
+device tree to the kernel. Not that it's OK to export the device tree used by
+U-Boot internally as it will be replaced by a propper device tree at a later
+stage. This avoid the need to load the device tree from a boot partition.
 
 Features to implement per machine
 =================================
@@ -35,19 +32,11 @@ Features to implement per machine
 The u-boot provided by CoreOS should implement the following features for each
 supported machine:
 
-board_fit_config_name_match
-----------------------------
-
-This allows u-boot to select the device tree to use dynamically using board
-detection. See `README.multi-dtb-fit`
-
-
 extension_board_scan
 --------------------
 
 The extension_board_scan function has to be implemented. This function should
-return the list of add-ons board detected, with the filename of the
-correspondig device-tree overlay.
+return the list of add-ons board detected.
 
 DT Fixup
 --------
@@ -55,53 +44,3 @@ DT Fixup
 U-Boot can create, modify and remove node from the device tree dynamically
 before starting the kernel. This can be used to pass dynamic information stored
 inside a "board descriptor" eeprom or CPLD to the Kernel.
-
-Custom Features that are generic
-================================
-
-The u-boot provided by CoreOS should implement the following custom features:
-
-File authentication
--------------------
-
-In order to be able to authenticate device tree, device-tree overlay file or
-other file needed by the firmware, we need a command to authenticate a file that
-was previously loaded is the `load` command. 
-
-.. note::
-
-    My proposal is to use the UEFI Capsule format, to reuse theses function from
-    u-boot:
-
-    - **efi_capsule_authenticate**: Authenticate the UEFI capsule using a x509
-      certificate built into u-boot
-    - **efi_remove_auth_hdr**: Can be used to point a pointer to the start of the
-      content of an authenticated capsule.
-    
-    An UEFI Capsule is a generic container that can be signed using a x.509
-    private key. The public key is stored inside u-boot (it's not the same as
-    the keys used for UEFI secure-boot). See
-    https://u-boot.readthedocs.io/en/v2022.10/develop/uefi/uefi.html?highlight=capsule#enabling-capsule-authentication
-
-
-extension_overlay_cmd
----------------------
-
-A custom command should be made for `extension_overlay_cmd`. The extension
-subsystem use the command defined as extension_overlay_cmd to load
-the overlay `${extension_overlay_name}` into `extension_overlay_addr`
-
-This should reuse the file authentication mechanismus.
-
-.. note::
-
-    A concept on where and how to securly store device tree and overlay needed
-    by the kernel has to be written.
-    
-    My proposal is to use the UEFI Capsule format, to reuse theses function from
-    u-boot:
-
-    - **efi_capsule_authenticate**: Authenticate the UEFI capsule using a x509
-      certificate built into u-boot
-    - **efi_remove_auth_hdr**: Can be used to point a pointer to the start of the
-      content of an authenticated capsule.

documentation/components/core/efibootguard.rst

@@ -0,0 +1,104 @@
+.. index:: EFIBOOTGUARD
+
+Bootloader: EFIBootGuard
+************************
+
+CoreOS use `EFIBootGuard <https://github.com/siemens/efibootguard>`_ as a
+bootloader. EFIBootGuard is the components responsible to find and load the
+right Unified Kernel Image (UKI).
+
+Installation
+------------
+
+EFIBootGuard is an UEFI application. It's installed inside the EFI System
+Partition at:
+
+.. list-table::
+   :widths: 25 25
+   :header-rows: 1
+
+   * - Platform Architecture
+     - Path
+   * - ARM32
+     - /EFI/BOOT/bootarm.efi
+   * - ARM64
+     - /EFI/BOOT/bootaa64.efi
+   * - x86_64
+     - /EFI/BOOT/bootax64.efi
+
+Workflow
+--------
+
+Configuration lookup
+~~~~~~~~~~~~~~~~~~~~
+
+When started, EFIBootGuard will scan all vFAT partition to list all the valid 
+boot partition.
+
+A valid boot partition is a vFAT partition that contain a valid BGENV.DAT file.
+
+This file contains the following parameters:
+
+- Path to a Kernel file
+- Parameter to pass to the kernel
+- Flag for in progress update
+- Update Status (OK, INSTALLED, TESTING, FAILED)
+- Watchdog timeout
+- Revision numbers
+- User data (not used)
+
+Consistency of the configuration is guaranteed by a CRC check.
+
+.. hint::
+   CoreOS use a signed Unified Kernel Image that embed the parameters to pass
+   to the Linux Kernel. Parameters from the UKI always override parameters
+   set inside the EFIBootGuard configuration file.
+
+   This is a security measure to ensure that only a signed kernel parameters is
+   used (secure boot).
+
+Booting
+~~~~~~~
+
+EFIBootGuard will try to load a kernel using the parameters from the
+configuration with the higher revision number.
+
+Update Handling
+~~~~~~~~~~~~~~~
+
+Before booting, EFIBootGuard will check the state flags inside the configuration
+file.
+
+If it's OK it means that it's a valid configuration.
+
+If the state is INSTALLED, it's mean that a new image was flash but was never
+booted. EFIBootGuard will change the state to TESTING then boot the kernel.
+
+If the state is TESTING, it's mean that the kernel was already booted one time,
+but the running system has not marked the update as working. EFIBootGuard will
+set the status to FAILED and set the revision number to 0 and boot another 
+configuration.
+
+.. hint::
+   To mark the update as working from a running system, you can use the
+   following command::
+
+    bg_setenv --confirm
+
+   This should be done after an update to tell the bootloader that the new
+   system image is working. CoreOS doesn't do it automatically for now.
+
+Known Issues
+------------
+
+.. list-table::
+   :widths: 15 85
+   :header-rows: 1
+
+   * - Bugs
+     - Description
+   * - `#370558 <https://tp.gad.local/entity/370558>`_
+     - On machine use a Marvel CN913x CPU like the cn9130-cf-pro machine, the version
+       of U-Boot provided don't provide the UEFI api needed by EFIBootGuard to update
+       his configuration file at boot time. EFIBootGuard is not able to detect
+       a failed update.

documentation/components/core/index.rst

@@ -0,0 +1,15 @@
+
+======================
+CoreOS Core Components
+======================
+
+|
+
+.. toctree::
+   :caption: Table of Contents
+   :numbered:
+
+   Firmware: U-Boot <u-boot>
+   Bootloader: EFIBootGuard <efibootguard>
+   Kernel: Unified Kernel Image <kernel>
+   Init System: SystemD <systemd>

documentation/components/core/kernel.rst

@@ -0,0 +1,27 @@
+.. index:: UKI
+
+Kernel: Unified Kernel Image
+*****************************
+
+CoreOS use by default a `Unified Kernel Image (UKI) <https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md>`_
+generated by tools from the EFIBootGuard project.
+
+An UKI is a EFI app that load in memory multiple artifacts needed by the Linux
+Kernel before loading and booting the Linux Kernel itself:
+
+* The kernel commands line is always loaded from the UKI
+* A device-tree file: UKI can contain multiple UKI and will load the one
+  matching the device-tree file passed by the firmware. 
+
+Known Issues and unimplemented feature
+--------------------------------------
+
+.. note::
+
+   Bundling an INITRD image into the UKI is not implemented yet.
+
+.. danger::
+
+   The Unified Kernel Image is signed but CoreOS currently provide no way to
+   verify the integrity of the choosed ROOTFS partition as CoreOS doesn't
+   provide an end-to-end secure boot solution yet.

documentation/components/core/systemd.rst

@@ -0,0 +1,7 @@
+.. index:: SYSTEMD
+
+Init System: SystemD
+********************
+
+`SystemD <https://www.freedesktop.org/wiki/Software/systemd/>`_ is used as
+init system in CoreOS.

documentation/components/core/u-boot.rst

@@ -0,0 +1,46 @@
+.. index:: UBOOT
+
+Firmware: U-Boot
+****************
+
+.. hint::
+   CoreOS should work with any UEFI compliant firmware. Using U-Boot is not 
+   mandatory.
+
+`U-Boot <https://u-boot.readthedocs.io/en/latest/>`_ is built by default with
+UEFI enabled and secure boot enabled. UEFI secure boot related keys are
+installed at build time and can't be changed from the U-Boot command line.
+
+Workflow
+--------
+
+U-Boot will boot the default UEFI application from the EFI System Partition.
+
+The path to the default UEFI application is architecture dependent:
+
+.. list-table::
+   :widths: 25 25
+   :header-rows: 1
+
+   * - Platform Architecture
+     - Path
+   * - ARM32
+     - /EFI/BOOT/bootarm.efi
+   * - ARM64
+     - /EFI/BOOT/bootaa64.efi
+   * - x86_64
+     - /EFI/BOOT/bootax64.efi
+
+Known Issues
+------------
+
+.. danger::
+
+   The U-Boot configuration used by CoreOS currently was not reviewed for
+   security issue and is not safe (access to u-boot command line is allowed).
+
+.. danger::
+
+   CoreOS U-Boot configuration enable UEFI Secure Boot but the U-Boot binary
+   itself is not validated. Thus we don't provide a full end-to-end secure boot
+   solution yet.

documentation/components/optional/index.rst

@@ -0,0 +1,15 @@
+
+==========================
+CoreOS Optional Components
+==========================
+
+|
+
+.. toctree::
+   :caption: Table of Contents
+   :numbered:
+
+   Network Manager: NetworkManager <networkmanager>
+   SSH Server: OpenSSH <openssh>
+   Container: Podman <podman>
+   CoreOS Installer <installer>

documentation/components/optional/installer.rst

@@ -0,0 +1,37 @@
+.. index:: COREOS_INSTALLER
+
+CoreOS Installer
+****************
+
+The CoreOS installer is a set of scripts running on the target and a
+corresponding bitbake image that is used into the bootstrap process of CoreOS.
+
+coreos-image-installer
+======================
+
+The CoreOS image installer results in an image contairing only a single binary
+EFI file. This EFI file includes a kernel, a device tree and an initramfs with
+all (and only) the tools needed to install CoreOS.
+
+The installer image is not automatically built in parallel of a normal image.
+This can be changed by setting `COREOS_IMAGE_GENERATE_INSTALLER` to 1 in the
+image file (as it is done for example in coreos-image-all-features.bb).
+
+The installer image build by default only a single EFI binary named
+coreos-installer-MACHINE.efi. An SDCard or USB image can be generated if
+`COREOS_INSTALLER_WKS_FILE` is set to a wks file.
+
+coreos-installer
+================
+
+The coreos-installer recipe installs scripts that are used at startup to
+automatically format the internal emmc of the device. The recipe also contains
+a swupdate configuration file to setup swupdate correctly for that use case.
+
+coreos-installer-config
+=======================
+
+The coreos-installer-config recipe installs device specific configuration file
+used by the coreos-installer. This includes the partitioner config file. Distros
+and projects based on CoreOS can change the partioning scheme or partition size
+by installing their own version of this package using a `bbappend file`.

documentation/components/optional/networkmanager.rst

@@ -0,0 +1,10 @@
+.. index:: NETWORKMANAGER
+
+Network Manager: NetworkManager
+*******************************
+
+You can add `NetworkManager <https://networkmanager.dev/>`_ to an image that
+inherit from `coreos-image` by adding::
+
+    IMAGE_FEATURES += "networkmanager"
+

documentation/components/optional/openssh.rst

@@ -0,0 +1,9 @@
+.. index:: OPENSSH
+
+SSH Server: OpenSSH
+*******************
+
+You can add an `OpenSSH <https://www.openssh.com/>`_ based ssh server to an
+image that inherit from `coreos-image` by adding::
+
+    IMAGE_FEATURES += "ssh-server"

documentation/components/optional/podman.rst

@@ -0,0 +1,9 @@
+.. index:: PODMAN
+
+Container: Podman
+*****************
+
+You can add `Podman <https://podman.io/>`_ to an image that inherit from
+`coreos-image` by adding::
+
+    IMAGE_FEATURES += "podman"

documentation/conf.py

@@ -112,6 +112,10 @@ except ImportError:
 # so a file named "default.css" will overwrite the builtin "default.css".
 html_static_path = ['_static']
 
+html_css_files = [
+    'css/coreos.css',
+]
+
 # Hide 'Created using Sphinx' text
 html_show_sphinx = False
 

documentation/hardware/beaglebone.rst

@@ -0,0 +1,61 @@
+..  _beaglebone:
+
+**********
+BeagleBone
+**********
+
+.. important::
+
+    The BeagleBone target uses an old TI AM3358 ARM 32 BIT CPU. This processor
+    of the AM335x family is used in a lot of current and legacy device at 
+    Hirschmann and NetModule. Thus we only support this target to ensure
+    that our architecture is working on older architecture too.
+
+CoreOS build instruction
+========================
+
+.. code-block:: 
+
+   MACHINE=beaglebone bitbake coreos-image-all-features
+   cd tmp/deploy/images/beaglebone
+
+.. list-table:: Image artifacts for BeagleBone
+   :widths: 25 75
+   :header-rows: 1
+
+   * - Filename
+     - Description
+   * - <IMAGE>-beaglebone.swu
+     - System image bundle used by the CoreOS installer or the CoreOS updater
+   * - <IMAGE>-beaglebone.wic.xz
+     - System image for SDCard
+   * - coreos-image-installer-beaglebone.wic.xz
+     - CoreOS installer image for SD Card
+
+.. hint:: 
+
+   Only the .swu image is need if you have already a working installation of CoreOS
+   running on the board that you want to update.
+
+CoreOS Pre-installation guide
+=============================
+
+If you want to use the internal emmc storage as boot target, you will need to
+flash coreos-image-installer-beaglebone.wic.xz to your SDCard using bmaptool.
+
+If you want to use the sdcard as boot target, you will need to flash
+<IMAGE>-beaglebone.wic.xz to your SDCard using bmaptool.
+
+By default the board boot on the internal emmc storage. To boot with a SDCard
+instead, you will need to push the S2 button (boot switch) while powering up the
+board.
+
+.. image:: beaglebone/beaglebone-s2-switch.png
+
+Serial access is available on the 5-pin header. See
+`this page <https://elinux.org/Beagleboard:BeagleBone_Black_Serial>`_ for
+more info on the serial connector.
+
+Now that you have the installer running, CoreOS can be installed by following
+the :ref:`generic installation manual<Installation Manual>` using the SDCard
+mehtod.

documentation/hardware/netmodule-hw34.rst

@@ -0,0 +1,126 @@
+..  _netmodule-hw34:
+
+*******************************
+NetModule HW34 (XG900 A-Sample)
+*******************************
+
+.. important::
+
+  netmodule-hw34 support is currently only available on the features branch
+  feat/netmodule-bsp
+
+.. image:: netmodule-hw34/hw34.png
+
+CoreOS build instruction
+========================
+
+.. code-block:: 
+
+   MACHINE=netmodule-hw34 bitbake coreos-image-all-features
+   cd tmp/deploy/images/netmodule-hw34
+
+.. list-table:: Image artifacts for NetModule HW32
+   :widths: 25 75
+   :header-rows: 1
+
+   * - Filename
+     - Description
+   * - <IMAGE>-netmodule-hw34.swu
+     - System image bundle used by the CoreOS installer or the CoreOS updater
+   * - coreos-installer-netmodule-hw34.efi
+     - CoreOS installer bundled in a single EFI binary
+   * - tiboot3.bin
+     - SPL Bootloader for the wakeup domain (arm32 R5 core)
+   * - tispl.bin
+     - SPL bootloader for the main domain (aarch64 main core)
+   * - u-boot.bin
+     - Third stage bootloader the main domain (aarch64 main core)
+
+.. hint:: 
+
+   Only the .swu image is need if you have already a working installation of CoreOS
+   running on the board that you want to update.
+
+CoreOS Pre-installation guide
+=============================
+
+The CoreOS installation process expect a working EFI firmware based on u-boot
+running on the board.
+
+For board that have no firmware or a defect firmware, we can provide the firmware by
+booting over USB.
+
+First, we need to put the board in USB Boot mode by modifying the dip-switch
+on the back of the board:
+
+.. code-block::
+
+            ON
+      S500  ▄ ▀ ▄ ▀ ▄ ▄ ▄ ▄
+            1 2 3 4 5 6 7 8
+
+.. hint::
+
+  Unflashed board or board without a valid tiboot3.bin image will default to
+  USB boot mode, so settings the dip-switch may be skipped in this case.
+
+Then you need to populate the jumper X600 near the USB port:
+
+.. image:: netmodule-hw34/hw34-usb-device.png
+
+Then power-up the board by first apply 12V throug the main connector, then
+connect a USB-C cable. Console access to the board can be accessed using the
+serial port on the main connector.
+
+
+.. important:: 
+
+   When removing the power, ensure that the USB cable is removed first. Otherwise
+   the processor will not get shutdown properly
+
+
+Now you should see the board from you computer:
+
+.. code-block:: sh
+
+   lsusb | grep DFU
+   Bus 003 Device 048: ID 0451:6165 Texas Instruments, Inc. AM64x DFU
+
+Now we start downloading the bootloaders into RAM by using dfu-utils:
+
+.. code-block:: sh
+
+   dfu-util -D tiboot3.bin -a 0
+   dfu-util -D tispl.bin -a 0
+
+   # Eject and start execution of tispl
+   dfu-util -e -a 0
+   dfu-util -D u-boot.img -a 1
+
+   # Eject ans tart of u-boot.img
+   dfu-util -e -a 1
+
+.. hint::
+
+    The firmware was uploaded to the RAM, thus will not survice a reboot.
+    
+
+Now that we have a firmware running, CoreOS can be installed by following
+the :ref:`generic installation manual<Installation Manual>`.
+
+
+CoreOS Post-Installation
+========================
+
+When the installation of CoreOS is done, power down the board by first
+removing the USB-C cable then the main power.
+
+Now, put the board back in emmc boot mode:
+
+.. code-block::
+
+            ON
+      S500  ▀ ▄ ▄ ▀ ▄ ▄ ▄ ▄
+            1 2 3 4 5 6 7 8
+
+Then power-up the board again and CoreOS should boot.

documentation/hardware/overview.rst

@@ -0,0 +1,33 @@
+******************
+Supported Hardware
+******************
+
+..  _Hardware Overview:
+.. list-table:: Supported BitBake MACHINE
+   :widths: 25 75 25
+   :header-rows: 1
+
+   * - BitBake MACHINE
+     - Compatible hardware
+     - Documentation
+   * - cn9131-bldn-mbv
+     - Falcon A3 Sample
+     - 
+   * - netmodule-hw34
+     - NetModule HW34 (XG900 Sample)
+     - :ref:`🔗 links <netmodule-hw34>`
+   * - cn9130-cf-pro
+     - Solidrun cn9130-cf-pro
+     - 
+   * - beaglebone
+     - Beaglebone, Beaglebone Black, Beaglebone Green
+     - :ref:`🔗 links <beaglebone>`
+   * - vm-x64
+     - Virtual Machine
+     - 
+
+.. hint:: 
+
+   Please contact the CoreOS team when starting a new project based on CoreOS
+   or want to contribute the hardware support for an existing Hardware.
+

documentation/index.rst

@@ -26,12 +26,30 @@ same structures.
    Setting up a CoreOS based distro <using-coreos>
    Building and using a Container Image <using-container>
 
+.. toctree::
+   :maxdepth: 1
+   :caption: Supported Hardware
+
+   Overview <hardware/overview>
+   NetModule HW34 (XG900 Sample) <hardware/netmodule-hw34>
+   BeagleBone <hardware/beaglebone>
+
 .. toctree::
    :maxdepth: 1
    :caption: Manuals
 
+   Installation Manual <installation/index>
    Reference Manual <ref-manual/index>
+   Testing Manual <testing/index>
    Boot Concepts <boot/index>
+   Best Practices <best_practices/index>
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Software Components
+
+   Core Components <components/core/index>
+   Optional Components <components/optional/index>
 
 .. toctree::
    :maxdepth: 1

documentation/installation/index.rst

@@ -0,0 +1,22 @@
+
+.. _Installation Manual:
+
+======================================
+Belden CoreOS EMMC Installation Manual
+======================================
+
+.. important:: 
+
+    This manual expect that the board you want to install CoreOS on have a
+    running UEFI firmware based on u-boot. Information about how to get console
+    access and a running firmware can be found for your hardware in the
+    :ref:`Hardware Overview <Hardware Overview>`
+
+|
+
+.. toctree::
+   :caption: Table of Contents
+   :numbered:
+
+   starting
+   partitionning

documentation/installation/partitionning.rst

@@ -0,0 +1,50 @@
+************
+Installation
+************
+
+The installer automatically creates all the needed partitions when starting up.
+
+Now you have to upload the .swu file to start the flashing process.
+
+Choose one of these methods to upload the system image to the installer:
+
+Upload the .swu file over the network using a browser
+=====================================================
+
+
+Now you can install the desired CoreOS version by uploading the desired
+.swu file to the board using a browser, by going to http://<TARGET_IP>:8080
+
+Upload the .swu file over the network using devtool
+===================================================
+
+If you have a working build environement, you can upload the image using
+the devtool command:
+
+.. code-block::
+
+    MACHINE=<MACHINE> devtool swupdate-www-push <IMAGE> <TARGET_IP>
+
+
+.. hint:: 
+    Replace <IMAGE> with the image recipe name, eg: coreos-image-all-features
+    Replace <MACHINE> by the machine name (if not set in local.conf)
+    Replace <TARGET_IP> by the IP adress of the board
+
+Upload the .swu file over the network using coreos-device
+=========================================================
+
+If you don't have a working build environement, you can upload the image using
+the coreos-device python script:
+
+.. code-block::
+
+    ./coreos-device swupdate-www-push <SWU_PATH> <TARGET_IP>
+
+.. hint:: 
+    Replace <SWU_PATH> with the the path to the SWU, eg: ./coreos-image-all-features-<MACHINE>.swu
+    Replace <TARGET_IP> by the IP adress of the board
+
+.. hint::
+    You will find the coreos-device script under the scripts directory inside
+    the CoreOS repository.

documentation/installation/starting.rst

@@ -0,0 +1,64 @@
+**********************
+Starting the installer
+**********************
+
+Choose one of these methods to start the bootloader:
+
+Starting the installer over the network with TFTP
+=================================================
+
+Put the coreos-installer EFI bundle (coreos-installer-<MACHINE>.efi) into an
+accessible TFTP server, then enter the following command into u-boot:
+
+.. code-block::
+
+   setenv ipaddr <TARGET_IP>; setenv serverip <SERVER_IP>;
+   tftp $loadaddr coreos-installer-<MACHINE>.efi
+   bootefi $loadaddr
+
+.. hint:: 
+
+    Replace <TARGET_IP> by a valid IP adress for the target, eg: 192.168.1.1
+    Replace <SERVER_IP> by the IP adress of the server, eg: 192.168.1.254
+    Replace <MACHINE> by the name of the machine set in bitbake
+
+Starting the installer over the network with DHCP/BOOTP/TFTP
+============================================================
+
+Use a DHCP/BOOTP/TFTP server to configure automatically the device. You can
+use dnsmasq for this task.
+
+
+.. code-block: ini
+
+    interface=<INTERFACE>
+    
+    dhcp-range=<INTERFACE>,10.237.30.2,10.237.30.100,4h
+    dhcp-range=<INTERFACE>,10.237.40.2,10.237.40.100,4h
+    
+    enable-tftp
+    dhcp-boot=tag:<INTERFACE>,coreos-installer-<MACHINE>.efi
+    tftp-root=/var/lib/tftpboot
+
+.. hint:: 
+
+    Replace <INTERFACE> by the name of the network interface that is connected
+    to the target. Eg: enp3s0
+    Replace <MACHINE> by the name of the machine set in bitbake
+
+Put the coreos-installer EFI bundle (coreos-installer-<MACHINE>.efi) into the
+/var/lib/tftpboot folder then enter the following command into u-boot:
+
+.. code-block::
+
+   setenv autoload yes
+   setenv autostart no
+   dhcp
+   bootefi $loadaddr
+
+Starting the installer using an SD Card
+=======================================
+
+Flash the coreos-image-installer.wic.xz into an SDCard and put the board
+in SDCard boot mode. Insert the SDCard and power up the board. The CoreOS
+installer should start automatically.

documentation/quick-build.rst

@@ -46,7 +46,8 @@ Theses packages are needed on your build machine:
       chrpath socat cpio python3 python3-pip python3-pexpect xz-utils \
       debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa \
       libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev zstd \
-      liblz4-tool bmap-tools efitools openssl sbsign
+      liblz4-tool bmap-tools efitools openssl sbsigntool python3-click \
+      python3-aiohttp
 
 Use Git to clone CoreOS
 ########################
@@ -99,11 +100,11 @@ the machine is set to `cn9130-cf-pro` but you can use any other MACHINE listed i
     occurrences of `cn9130-cf-pro` to your machine when executing a command.
 
 For an image that contains a lot of developer tools, the best image to build
-is `coreos-image-full-cmdline`.
+is `coreos-image-all-features`.
 
 .. code-block:: sh
 
-   ~/img-build/build$ bitbake coreos-image-full-cmdline
+   ~/img-build/build$ bitbake coreos-image-all-features
 
 After a long time, the build system will return. You can list all the artifacts
 produced by `bitbake` using `ls`:
@@ -118,7 +119,7 @@ be found with this command:
 .. code-block:: sh
 
    ~/coreos/build$ find tmp/deploy/images/${MACHINE} -type l -name "*.wic.xz"
-   tmp/deploy/images/cn9130-cf-pro/coreos-image-full-cmdline-cn9130-cf-pro.wic.xz
+   tmp/deploy/images/cn9130-cf-pro/coreos-image-all-features-cn9130-cf-pro.wic.xz
 
 .. hint::
 
@@ -166,6 +167,6 @@ Now, flash the image file to the your card:
 
 .. code-block:: sh
 
-   ~/coreos/build$ bmaptool copy tmp/deploy/images/cn9130-cf-pro/coreos-image-full-cmdline-cn9130-cf-pro.wic.xz /dev/<DISKNAME>
+   ~/coreos/build$ bmaptool copy tmp/deploy/images/cn9130-cf-pro/coreos-image-all-features-cn9130-cf-pro.wic.xz /dev/<DISKNAME>
 
 You have to replace `<DISKNAME>` by the name of your SD Card device.

documentation/ref-manual/classes.rst

@@ -13,7 +13,7 @@ provided by OpenEmbedded-Core are documented in the
 ``coreos-efi-secureboot.bbclass``
 =================================
 
-The ``coreos-efi-secureboot`` class is a class made to be ihnerited in a global
+The ``coreos-efi-secureboot`` class is a class made to be inherited in a global
 configuration file. On the CoreOS distribution, this class is inherited inside
 the CoreOS distrubtion configuration file.
 

documentation/ref-manual/features.rst

@@ -10,9 +10,14 @@ to Belden CoreOS.
 Machine Features
 ================
 
-CoreOS doesn't define any custom machine feature for now, but the 
 :external:ref:`MACHINE_FEATURES <ref-features-machine>` of OpenEmbedded-Core
-can be used.
+can be used with CoreOS.
+
+In addition, those CoreOS specific MACHINE_FEATURES can be used too:
+
+-  *sdcard:* the machine as an internal SD Card or MicroSD Slot. 
+-  *emmc:* the machine as an internal emmc based storage
+
 
 .. index:: DISTRO_FEATURES
 

documentation/ref-manual/images.rst

@@ -4,12 +4,20 @@ Images
 
 The CoreOS build system provides several examples image:
 
-.. index:: coreos-image-full-cmdline
+.. index:: coreos-image-all-features
 
-``coreos-image-full-cmdline``
+``coreos-image-all-features``
 =============================
 
- A console-only image with more full-featured Linux system functionality installed.
+ An image with most of the optional feature of CoreOS.
+
+ .. index:: coreos-image-demo
+
+``coreos-image-demo``
+=============================
+
+ An image based on `coreos-image-all-features`` that has additional demo
+ features activated.
 
 .. index:: coreos-image-minimal
 

documentation/testing/bats.rst

@@ -0,0 +1,354 @@
+.. index:: BATS
+
+************************************
+BATS - Bash Automated Testing System
+************************************
+
+The CoreOS distribution supports writing tests using shell syntax by providing the `bats` command.
+
+If you want to use `bats`, you will need the following CoreOS packages:
+
+- bats
+- bats-file
+- bats-assert
+
+Overview of BATS
+================
+
+A BATS test can be as simple as a single .bats file. For example:
+
+.. code-block:: bash
+
+    #!/usr/bin/env bats
+   
+    bats_load_library bats-support
+    bats_load_library bats-assert
+
+    @test "can output to stdout" {
+        run echo hello
+        assert_output 'hello'
+    }
+
+You can run it using the command `bats <filename>.bats`
+
+This will give you the following output:
+
+.. code-block:: bash
+
+    sam@SAVE:~/Projects/tests$ bats <filename>.bats 
+    <filename>.bats
+    ✓ can output to stdout
+
+    1 test, 0 failures
+
+The run command
+================
+
+In shell tests, you often need to run commands and capture their output, exit
+status, and error messages. The run command provided by `bats` allows you to
+execute commands within your test cases and collect this information for later
+assertion and validation.
+
+The run command will make the following variables available:
+
+- `${status}`: exit code of the command run by `run`
+- `${output}`: combined content of `stdout` and `stderr`
+- `${lines[@]}`: array of lines of the output
+- `${BATS_RUN_COMMAND}`: command run by the `run` command
+
+.. code-block:: bash
+
+    @test "invoking foo with a nonexistent file prints an error" {
+        run foo nonexistent_filename
+        [ "$status" -eq 1 ]
+        [ "$output" = "foo: no such file 'nonexistent_filename'" ]
+        [ "$BATS_RUN_COMMAND" = "foo nonexistent_filename" ]
+
+    }
+
+The `run` command accepts some parameters:
+
+- `-N`: Expect N as exit status and fail otherwise
+- `-!`: Expect non-zero exit status and fail if the command succeeds.
+- `--keep-empty-lines`: don't remove empty lines from `${lines}`
+- `--separate-stderr`: Use separate variables for stderr `${stderr}` and `${stderr_lines[@]}`
+
+.. code-block:: bash
+
+    @test "invoking foo without arguments prints usage" {
+        run -1 foo
+        [ "${lines[0]}" = "usage: foo <filename>" ]
+    }
+
+The bats-assert helper
+======================
+
+The `bats-assert` helper provides some functions to create more readable tests.
+These assertions use the variables created by the `run` command and can be used
+as follows:
+
+.. code-block:: bash
+
+    @test 'assert_output()' {
+        run echo 'have'
+        assert_output 'want'
+    }
+
+The following functions are provided:
+
+- `assert` and `refute`: Assert that a given expression evaluates to true or false.
+- `assert_equal`: Assert that two parameters are equal.
+- `assert_not_equal`: Assert that two parameters are not equal.
+- `assert_success` and `assert_failure`: Assert that the exit status is 0 or 1.
+- `assert_output` and `refute_output`: Assert that the output does (or does not) contain the given content.
+- `assert_line` and `refute_line`: Assert that a specific line of the output does (or does not) contain the given content.
+- `assert_regex` and `refute_regex`: Assert that a parameter matches (or does not match) the given pattern.
+
+The bats-file helper
+====================
+
+The `bats-file` helper provides functions to help work with files in tests:
+
+**Test File Types:**
+
+- `assert_exists` and `assert_not_exists`: Check if a file or directory exists.
+- `assert_file_exists` and `assert_file_not_exists`: Check if a file exists.
+- `assert_dir_exists` and `assert_dir_not_exists`: Check if a directory exists.
+- `assert_link_exists` and `assert_link_not_exists`: Check if a link exists.
+- `assert_block_exists` and `assert_block_not_exists`: Check if a block special file exists.
+- `assert_character_exists` and `assert_character_not_exists`: Check if a character special file exists.
+- `assert_socket_exists` and `assert_socket_not_exists`: Check if a socket exists.
+- `assert_fifo_exists` and `assert_fifo_not_exists`: Check if a fifo special file exists.
+
+**Test File Attributes:**
+
+- `assert_file_executable` and `assert_file_not_executable`
+- `assert_file_owner` and `assert_file_not_owner`
+- `assert_file_permission` and `assert_not_file_permission`
+- `assert_file_size_equals`
+- `assert_size_zero` and `assert_size_not_zero`
+- `assert_file_group_id_set` and `assert_file_not_group_id_set`
+- `assert_file_user_id_set` and `assert_file_not_user_id_set`
+- `assert_sticky_bit` and `assert_no_sticky_bit`
+
+**Test File Content:**
+
+- `assert_file_empty` and `assert_file_not_empty`
+- `assert_file_contains` and `assert_file_not_contains`
+- `assert_symlink_to` and `assert_not_symlink_to`
+
+**Working with a temporary directory:**
+
+- `temp_make` and `temp_del`
+
+Pre- and Post-test case hooks
+==============================
+
+In some cases, it's useful to have a function that runs before or after each test
+case in a bats file.
+
+A function named `setup` will run before each test case, and a function
+named `teardown` will run after each test case.
+
+This example creates a directory in the setup function but lacks a teardown
+that removes the directory. The second time the setup function is run, the
+setup will fail as the directory already exists:
+
+.. code-block:: bash
+
+    #!/usr/bin/env bats
+
+    bats_load_library bats-support
+    bats_load_library bats-assert
+    bats_load_library bats-file
+
+    setup() {
+        mkdir tmp
+        echo 'a' >> ./tmp/test
+    }
+
+    @test "test contains a single a I" {
+        assert_file_contains ./tmp/test '^a$'
+    }
+
+    @test "test contains a single a II" {
+        assert_file_contains ./tmp/test '^a$'
+    }
+
+.. code-block:: bash
+
+    sam@SAVE:~/Projects/tests$ bats test.bats 
+    test.bats
+    ✓ test contains a single a I
+    ✗ test contains a single a II
+    (from function `setup' in test file test.bats, line 8)
+        `mkdir tmp' failed
+    mkdir: cannot create directory ‘tmp’: File exists
+
+    2 tests, 1 failure
+
+This can be easily fixed by adding a teardown function:
+
+.. code-block:: bash
+
+    #!/usr/bin/env bats
+
+    bats_load_library bats-support
+    bats_load_library bats-assert
+    bats_load_library bats-file
+
+    setup() {
+        mkdir tmp
+        echo 'a' >> ./tmp/test
+    }
+
+    teardown() {
+        rm -rf ./tmp
+    }
+
+
+
+    @test "test contains a single a I" {
+        assert_file_contains ./tmp/test '^a$'
+    }
+
+    @test "test contains a single a II" {
+        assert_file_contains ./tmp/test '^a$'
+    }
+
+.. code-block:: bash
+
+    sam@SAVE:~/Projects/tests$ bats test.bats 
+    test.bats
+     ✓ test contains a single a I
+     ✓ test contains a single a II
+
+    2 tests, 0 failures
+
+Pre- and Post-test file hooks
+=============================
+
+To run some code before executing a test file or after executing it, the
+functions `setup_file` and `teardown_file` can be used.
+
+The last example could be refactored to only create the tmp directory once:
+
+.. code-block:: bash
+
+    #!/usr/bin/env bats
+
+    bats_load_library bats-support
+    bats_load_library bats-assert
+    bats_load_library bats-file
+
+    setup_file() {
+        export DIR="./tmp"
+        export FILE="${DIR}/test"
+        mkdir "${DIR}"
+    }
+
+    teardown_file() {
+        rm -rf "${DIR}"
+    }
+
+    setup() {
+        echo 'a' >> "${FILE}"
+    }
+
+    teardown() {
+        rm "${FILE}"
+    }
+
+    @test "test contains a single a I" {
+        assert_file_contains "${FILE}" '^a$'
+    }
+
+    @test "test contains a single a II" {
+        assert_file_contains "${FILE}" '^a$'
+    }
+
+Multiple files
+==============
+
+With `bats`, a file is a test suite. If you have multiple `bats` files in a
+directory and you provide the directory in the `bats` command line, `bats`
+will execute all the test suites.
+
+Example: `bats .` 
+
+.. code-block:: bash
+
+    sam@SAVE:~/Projects/tests$ bats .
+    ./first.bats
+    ✓ can run our script
+    ✗ second test
+    (in test file ./first.bats, line 27)
+        `false' failed
+    ./second.bats
+    ✓ multi file
+    ./test.bats
+    ✓ test contains a single a I
+    ✓ test contains a single a II
+
+    5 tests, 1 failure
+
+Pre- and Post-suite hooks
+=========================
+
+If you want to execute the same function before each test suite or after
+each test suite, create a file named `setup_suite.bash`. In this file,
+create a function named `setup_suite()` and another named `teardown_suite()`.
+
+Exporting the test results
+==========================
+
+Test results can be exported using the JUnit XML format. This can then be
+used in other tools and merged with other JUnit XML formats to generate a final
+test report.
+
+Example:
+
+.. code-block:: bash
+
+    sam@SAVE:~/Projects/tests$ bats . -F junit
+
+This will produce the following XML content on stdout:
+
+.. code-block:: xml
+
+    <?xml version="1.0" encoding="UTF-8"?>
+    <testsuites time="0.048">
+    <testsuite name="./first.bats" tests="2" failures="1" errors="0" skipped="0" time="0.025" timestamp="2023-08-16T14:22:15" hostname="SAVE">
+        <testcase classname="./first.bats" name="can run our script" time="0.013" />
+        <testcase classname="./first.bats" name="second test" time="0.012">
+            <failure type="failure">(in test file ./first.bats, line 27)
+    `false&#39; failed</failure>
+        </testcase>
+
+    </testsuite>
+    <testsuite name="./second.bats" tests="1" failures="0" errors="0" skipped="0" time="0.008" timestamp="2023-08-16T14:22:15" hostname="SAVE">
+        <testcase classname="./second.bats" name="multi file" time="0.008" />
+
+    </testsuite>
+    <testsuite name="./test.bats" tests="2" failures="0" errors="0" skipped="0" time="0.015" timestamp="2023-08-16T14:22:15" hostname="SAVE">
+        <testcase classname="./test.bats" name="test contains a single a I" time="0.008" />
+        <testcase classname="./test.bats" name="test contains a single a II" time="0.007" />
+
+    </testsuite>
+    </testsuites>
+
+Going further
+=============
+
+`bats` scripts can be checked with shellcheck for common mistakes.
+
+The `bats-assert` add-on provides many helper functions to perform
+assertions with a more readable syntax than the shell's built-in syntax.
+
+See https://github.com/bats-core/bats-assert
+
+The `bats-file` add-on provides helper functions to check for files. See
+https://github.com/bats-core/bats-file/
+
+You can find a list of projects using `bats` on this page:
+https://github.com/bats-core/bats-core/wiki/Projects-Using-Bats

documentation/testing/index.rst

@@ -0,0 +1,15 @@
+
+==============================
+Belden CoreOS Testing Manual
+==============================
+
+This manual is a work on progress on how to test and how to write test for
+CoreOS or CoreOS based distribution.
+
+|
+
+.. toctree::
+   :caption: Table of Contents
+   :numbered:
+
+   bats

external-layers/meta-arm

@@ -0,0 +1 @@
+Subproject commit d7b7b6fb6c7c5545e718e44f38853d1718ce5446

external-layers/meta-efibootguard

@@ -0,0 +1 @@
+Subproject commit e3581b11d30d91d0363acb48a6aee47043b7e0bc

external-layers/meta-lts-kernel-mixin

@@ -0,0 +1 @@
+Subproject commit 09d2f9391813674627ec53cb222da6c7a51221e6

external-layers/meta-openembedded

@@ -0,0 +1 @@
+Subproject commit 8bb16533532b6abc2eded7d9961ab2a108fd7a5b

external-layers/meta-swupdate

@@ -0,0 +1 @@
+Subproject commit 3d12b2788a45d86efcb1ad3e01f209558c54795c

external-layers/meta-ti

@@ -0,0 +1 @@
+Subproject commit bae3658ac0bc1c9adac7a882439cabb385cae720

external-layers/meta-virtualization

@@ -0,0 +1 @@
+Subproject commit cb2bc17e96552cdfc141d27bd9f4dbd95a872846

external-layers/openembedded-core

@@ -0,0 +1 @@
+Subproject commit 1b5405955c7c2579ed1f52522e2e177d0281fa33

layers/meta-belden-coreos-bsp/classes/coreos-efi-secureboot.bbclass

@@ -3,7 +3,7 @@
 # UEFI Secure boot configuration
 # ==============================================================================
 
-COREOS_EFI_SECUREBOOT_KEYDIR ??= "${TOPDIR}/keys"
+COREOS_EFI_SECUREBOOT_KEYDIR ??= "${RECIPE_SYSROOT_NATIVE}/${datadir}/keys"
 COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR ??= "0"
 
 # UEFI Secure boot helpers
@@ -16,40 +16,19 @@ HOSTTOOLS += "sbsign"
 
 # Ensure that the public keys are always deployed to the deploy directory
 # before running wic
-do_image_wic[depends] += "efi-secureboot-keys:do_deploy"
-
+do_image_wic[depends] += "cos-certificates-and-keys-native:do_deploy"
 
+COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR ??= "0"
 def get_coreos_secureboot_efi_boot_files(d):
     """
         Return the list of pubkey file inside deploy if
         COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR is set or an empty string
         otherwise
     """
-    if d.getVar('COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR', True):
+    if d.getVar('COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR') == '1':
         return "db.auth KEK.auth PK.auth db.esl KEK.esl PK.esl db.crt KEK.crt PK.crt db.der KEK.der PK.der"
     return ""
 
 IMAGE_EFI_BOOT_FILES:append = " ${@get_coreos_secureboot_efi_boot_files(d)}"
 
-def get_coreos_secureboot_keydir_hash(d):
-    """
-        Generate a space separate list, with a value for each file inside of 
-        keydir. Fromat: <filename>:md5:<md5sum>
-    """
-    import hashlib
 
-    keydir = d.getVar('COREOS_EFI_SECUREBOOT_KEYDIR')
-    value = ""
-    
-    for filepath in os.listdir(keydir):
-        if os.path.isfile(filepath): 
-            md5 = bb.utils.md5_file(filepath)
-            value += f"{filepath}:md5:{md5} "
-
-    return value
-
-# The build system should detect if someone change one of the key inside
-# COREOS_EFI_SECUREBOOT_KEYDIR and rebuild all the recipes and artifacts that
-# depends on this directory
-COREOS_EFI_SECUREBOOT_KEYDIR_HASH = "${@get_coreos_secureboot_keydir_hash(d)}"
-COREOS_EFI_SECUREBOOT_KEYDIR[vardeps] += "COREOS_EFI_SECUREBOOT_KEYDIR_HASH"

layers/meta-belden-coreos-bsp/classes/coreos-image-swupdate-beaglebone.bbclass

@@ -0,0 +1,26 @@
+
+SWUPDATE_IMAGES += "MLO"
+SWUPDATE_IMAGES += "u-boot-beaglebone"
+SWUPDATE_IMAGES_FSTYPES[MLO] = ""
+SWUPDATE_IMAGES_FSTYPES[u-boot-beaglebone] = ".img"
+
+COREOS_SWUPDATE_EXTENDS_FOR:append = "beaglebone"
+
+def coreos_swupdate_extends_images_for_beaglebone(d,s):
+    mlo = {
+        "filename" : "MLO",
+        "installed-directly" : "true",
+        "device" : "/dev/disk/by-partlabel/mlo",
+        "type" : "raw",
+        "sha256" : swupdate_get_sha256(d, s, "MLO"),
+    }
+
+    uboot = {
+        "filename" : "u-boot-beaglebone.img",
+        "installed-directly" : "true",
+        "device" : "/dev/disk/by-partlabel/uboot",
+        "type" : "raw",
+        "sha256" : swupdate_get_sha256(d, s, "u-boot-beaglebone.img"),
+    }
+
+    return [mlo, uboot]

layers/meta-belden-coreos-bsp/conf/machine/beaglebone.conf

@@ -5,12 +5,14 @@
 MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"
 EXTRA_IMAGEDEPENDS += "virtual/bootloader"
 
+
 DEFAULTTUNE ?= "cortexa8hf-neon"
 include conf/machine/include/arm/armv7a/tune-cortexa8.inc
 
 IMAGE_FSTYPES += "wic wic.xz wic.bmap"
 WKS_FILE ?= "beaglebone-sdcard.wks.in"
-MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"
+COREOS_INSTALLER_WKS_FILE ?= "beaglebone-sdcard-installer.wks"
+MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image"
 do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot gptfdisk-native:do_populate_sysroot virtual/bootloader:do_deploy"
 do_image_wic[recrdeptask] += "do_bootimg"
 
@@ -19,10 +21,10 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
 APPEND:append = " console=ttyS0,115200"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "5.15%"
+PREFERRED_VERSION_linux-yocto ?= "6.6%"
 
 KERNEL_IMAGETYPE = "zImage"
-KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
+DTB_FILES = "ti/omap/am335x-bone.dtb ti/omap/am335x-boneblack.dtb ti/omap/am335x-bonegreen.dtb"
 KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
 
 PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
@@ -35,9 +37,6 @@ UBOOT_LOADADDRESS = "0x80008000"
 
 MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
 
-IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY}"
-IMAGE_EFI_BOOT_FILES ?= "${KERNEL_DEVICETREE}"
-
 # support runqemu
 EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
 IMAGE_CLASSES += "qemuboot"
@@ -58,11 +57,7 @@ QB_TCPSERIAL_OPT = "-device virtio-serial-device -chardev socket,id=virtcon,port
 # No watchdog available yet
 EFIBOOTGUARD_TIMEOUT ?= "0"
 
-# MBR disk can't select the root device by partition label as MBR doesn't have
-# a partition label. Using filesystem label only work with an initramfs and we
-# don't support it yet.
-COREOS_PLATFORM0_ROOT ?= "/dev/mmcblk0p3"
-COREOS_PLATFORM1_ROOT ?= "/dev/mmcblk0p4"
+COREOS_IMAGE_SWUPDATE_EXTRACLASSES += "coreos-image-swupdate-beaglebone"
 
 require conf/machine/include/coreos-generic-features/efi.inc
-require conf/machine/include/coreos-generic-features/legacy-mbr-disk.inc
+require conf/machine/include/coreos-generic-features/partitions.inc

layers/meta-belden-coreos-bsp/conf/machine/eagle40-03.conf

@@ -0,0 +1,39 @@
+#@TYPE: Machine
+#@NAME: eagle40-03
+#@DESCRIPTION: Machine support for EAGLE40-03
+#
+
+require include/coreos-generic-arch/x64.inc
+
+MACHINE_FEATURES += "pci usbhost x86 serial efi"
+
+# Kernel configuration
+# ******************************************************************************
+
+PREFERRED_VERSION_linux-yocto ?= "6.6%"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+
+KERNEL_IMAGETYPE = "bzImage"
+
+#  getty configuration
+# ******************************************************************************
+
+SERIAL_CONSOLES = "115200;ttyS0"
+SERIAL_CONSOLES_CHECK = "ttyS0"
+APPEND += "console=ttyS0,115200"
+
+# Image generation
+# ******************************************************************************
+
+# Ensure that both flash-image.bin and boot.scr are generated as they are needed
+# for a wic image
+WKS_FILE = "generic-uefi.wks.in"
+COREOS_INSTALLER_WKS_FILE ?= "generic-uefi-usb-installer.wks"
+IMAGE_FSTYPES += "wic.xz wic.bmap"
+
+MACHINE_ESSENTIAL_EXTRA_RDEPENDS += " kernel-modules"
+
+# No watchdog available yet
+EFIBOOTGUARD_TIMEOUT ?= "0"
+require conf/machine/include/coreos-generic-features/efi.inc
+require conf/machine/include/coreos-generic-features/partitions.inc

layers/meta-belden-coreos-bsp/conf/machine/include/coreos-generic-features/efi.inc

@@ -2,15 +2,5 @@
 # ==============================================================================
 
 MACHINE_FEATURES:append = " efi"
-EFI_PROVIDER = "efibootguard"
-EFIBOOTGUARD_TIMEOUT ?= "60"
 
 do_image_wic[depends] += "efibootguard-native:do_populate_sysroot efibootguard:do_deploy"
-
-# Variable used in WKS file
-
-WKS_PART_EFI ??= 'part --source efibootguard-efi --label efi --align 1024 --part-type=EF00'
-WKS_PART_ROOT_A ??= 'part / --source rootfs --fstype=ext4 --label platform0 --align 1024'
-WKS_PART_ROOT_B ??= 'part --fstype=ext4 --label platform1 --align 1024'
-WKS_PART_EFIBOOTGUARD_A ??= 'part --source efibootguard-boot --label boot0 --align 1024 --part-type=0700 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=kernel0-${MACHINE}.efi;KERNEL0.EFI"'
-WKS_PART_EFIBOOTGUARD_B ??= 'part --source efibootguard-boot --label boot1 --align 1024 --part-type=0700 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=kernel1-${MACHINE}.efi;KERNEL1.EFI"'

layers/meta-belden-coreos-bsp/conf/machine/include/coreos-generic-features/legacy-mbr-disk.inc

@@ -1,19 +0,0 @@
-
-# MBR disk are still supported by CoreOS, but only for legacy product
-# This ensure that efibootguard / swupdate work with MBR disk
-
-# Do not include this file in a machine configuration if the machine support
-# a GPT disk instead
-COREOS_DISK_PARTLABEL_LOOKUP_DIRECTORY ?= "/dev/disk/by-label"
-
-# MBR can't disk can't use partition label, but may use filesystem label
-# This will only work with an initramfs. If no initramfs is used, this will
-# have to be set to the right disk device inside the machine configuration
-# like that COREOS_PLATFORMx_ROOT = "/dev/mmcblk<DISK>p<PART>"
-COREOS_PLATFORM0_ROOT ?= "LABEL=platform0"
-COREOS_PLATFORM1_ROOT ?= "LABEL=platform1"
-
-# MBR disk can't use --part-type but can use system-id 
-WKS_PART_EFI ?= 'part --source efibootguard-efi --label efi --system-id 0xef'
-WKS_PART_EFIBOOTGUARD_A ?= 'part --source efibootguard-boot --label boot0  --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=kernel0-${MACHINE}.efi;KERNEL0.EFI"'
-WKS_PART_EFIBOOTGUARD_B ?=  'part --source efibootguard-boot --label boot1 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=kernel1-${MACHINE}.efi;KERNEL1.EFI"'

layers/meta-belden-coreos-bsp/conf/machine/include/coreos-generic-features/partitions.inc

@@ -0,0 +1,20 @@
+# Variables used in WKS file
+WKS_PART_EFI ??= 'part --source efibootguard-efi --label efi --part-type=EF00'
+WKS_PART_EFIBOOTGUARD_A ??= 'part --source efibootguard-boot --label ebg0 --part-type=0700 --sourceparams "args=coreos.root=rootfs0,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI"'
+WKS_PART_EFIBOOTGUARD_B ??= 'part --source efibootguard-boot --label ebg1 --part-type=0700 --sourceparams "args=coreos.root=rootfs1,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI"'
+WKS_PART_ROOT_A ??= 'part / --source rootfs --fstype=ext4 --label rootfs0'
+WKS_PART_ROOT_B ??= 'part --fstype=ext4 --label rootfs1'
+WKS_PART_USERDATA ??= 'part /usr/local/data --fstype=btrfs --label userdata'
+
+PART_EFI_SIZE ??= '64M'
+PART_ROOT_SIZE ??= '1G'
+PART_EFIBG_SIZE ??= '128M'
+PART_USERDATA_SIZE ??= '1G'
+
+# Variables used in SFDISK file
+SFDISK_PART_EFI ??= 'type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, name="efi"'
+SFDISK_PART_EFIBOOTGUARD_A ??= 'type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, name="ebg0"'
+SFDISK_PART_EFIBOOTGUARD_B ??= 'type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, name="ebg1"'
+SFDISK_PART_ROOT_A ??= 'type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="rootfs0"'
+SFDISK_PART_ROOT_B ??= 'type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="rootfs1"'
+SFDISK_PART_USERDATA ??= 'type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="userdata"'

layers/meta-belden-coreos-bsp/conf/machine/include/coreos-generic-machine/container.inc

@@ -2,8 +2,10 @@
 IMAGE_FSTYPES += "container oci"
 IMGCLASSES:append = " image-oci"
 
-# Add an override that work for all container image
-MACHINEOVERRIDES =. "container:"
-
 # Containers don't need a kernel
 PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"
+
+# When using coreos-image instead of coreos-container-image, we should skip
+# swu image generation and unified kernel image generation
+COREOS_IMAGE_GENERATE_UKI = "0"
+COREOS_IMAGE_GENERATE_SWU = "0"

layers/meta-belden-coreos-bsp/conf/machine/include/coreos-generic-machine/vm.inc

@@ -6,12 +6,12 @@ MACHINE_FEATURES += "wifi efi"
 # Add an override that work for all pc image
 MACHINEOVERRIDES =. "vm:"
 
-PREFERRED_VERSION_linux-yocto ?= "5.15%"
+PREFERRED_VERSION_linux-yocto ?= "6.6%"
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 
 MACHINE_EXTRA_RRECOMMENDS += "kernel-modules linux-firmware"
 
-IMAGE_FSTYPES += "ext4 wic wic.xz wic.bmap wic.vmdk"
+IMAGE_FSTYPES += "ext4 wic wic.xz wic.bmap wic.vmdk wic.vhdx"
 
 WKS_FILE ?= "generic-uefi.wks.in"
 do_image_wic[depends] += "gptfdisk-native:do_populate_sysroot"
@@ -22,3 +22,4 @@ do_image_wic[recrdeptask] += "do_bootimg"
 COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR = "1"
 
 require conf/machine/include/coreos-generic-features/efi.inc
+require conf/machine/include/coreos-generic-features/partitions.inc

layers/meta-belden-coreos-bsp/conf/machine/qemu-coreos-arm64.conf

@@ -0,0 +1,15 @@
+#@TYPE: Machine
+#@NAME: qemu-generic-arm64
+#@DESCRIPTION: Generic Arm64 machine for typical SystemReady platforms, which
+#have working firmware and boot via EFI.
+
+require conf/machine/qemu-generic-arm64.conf
+MACHINEOVERRIDES =. "qemu-generic-arm64:"
+
+COREOS_IMAGE_GENERATE_INSTALLER = "0"
+
+WKS_FILE = "qemu-efi-coreos-generic.wks.in"
+
+EFIBOOTGUARD_TIMEOUT ?= "0"
+require conf/machine/include/coreos-generic-features/efi.inc
+require conf/machine/include/coreos-generic-features/partitions.inc

layers/meta-belden-coreos-bsp/conf/machine/vm-x64.conf

@@ -7,3 +7,6 @@ require include/coreos-generic-machine/vm.inc
 
 SERIAL_CONSOLES_CHECK = "ttyS0"
 QB_SYSTEM_NAME = "qemu-system-x86_64"
+
+# Currently we don't support the watchdog
+EFIBOOTGUARD_TIMEOUT ?= "0"

layers/meta-belden-coreos-bsp/recipes-bsp/efi/efi-secureboot-keys.bb

@@ -1,33 +0,0 @@
-SUMMARY = "A recipe to deploy UEFI public keys update files"
-LICENSE = "CLOSED"
-
-
-INHIBIT_DEFAULT_DEPS = "1"
-inherit nopackages
-
-inherit deploy
-inherit coreos-efi-secureboot
-
-# Public key needed by firmware very depending on the implementation
-# So we copy all type of public key (*.auth, *.esl, *.crt, *der)
-addtask deploy after do_compile
-do_deploy() {
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.auth ${DEPLOYDIR}/KEK.auth
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.auth ${DEPLOYDIR}/db.auth
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.auth ${DEPLOYDIR}/PK.auth
-    
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.esl ${DEPLOYDIR}/KEK.esl
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.esl ${DEPLOYDIR}/db.esl
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.esl ${DEPLOYDIR}/PK.esl
-
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.crt ${DEPLOYDIR}/KEK.crt
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.crt ${DEPLOYDIR}/db.crt
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.crt ${DEPLOYDIR}/PK.crt
-
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.der ${DEPLOYDIR}/KEK.der
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.der ${DEPLOYDIR}/db.der
-    install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.der ${DEPLOYDIR}/PK.der
-
-    # !SECURITY WARNING! 
-    # .key file are not copied to DEPLOYDIR, as they contains the PRIVATE keys
-}

layers/meta-belden-coreos-bsp/recipes-bsp/efibootguard/efibootguard_%.bbappend

@@ -1,11 +0,0 @@
-# Add signature support
-
-inherit coreos-efi-sbsign
-require conf/image-uefi.conf
-
-do_deploy:append() {
-
-    if [ -f "${DEPLOYDIR}/efibootguard${EFI_ARCH}.efi" ]; then
-        coreos_efi_secureboot_sign_app "${DEPLOYDIR}/efibootguard${EFI_ARCH}.efi"
-    fi
-}

layers/meta-belden-coreos-bsp/recipes-bsp/u-boot/u-boot-coreos.inc

@@ -1,12 +0,0 @@
-# Ensure that file are found event when this file is included in another layer
-# ==============================================================================
-FILESEXTRAPATHS:prepend := "${THISDIR}/u-boot:"
-
-# Main include file for u-boot to ensure CoreOS compatibility
-# ==============================================================================
-
-SRC_URI += " \
-    ${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "file://debug-tweaks.cfg", "", d)} \
-"
-
-require u-boot-coreos-efi.inc

layers/meta-belden-coreos-bsp/recipes-bsp/u-boot/u-boot_2022.01.bbappend

@@ -1,2 +0,0 @@
-FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
-require u-boot-coreos.inc

layers/meta-belden-coreos-bsp/recipes-coreos/coreos-installer/coreos-installer-config/beaglebone_1.0.sfdisk

@@ -0,0 +1,19 @@
+label: gpt
+device: /dev/mmcblk1
+unit: sectors
+first-lba: 34
+last-lba: 7471070
+sector-size: 512
+
+# EBBR 2.1.0 section 4.1.1 mandate the use of an unused type UUID and to set
+# the RequiredPartition label for part of the firmware stored in the main disk
+# https://arm-software.github.io/ebbr/#section-gpt-parts
+# next two type were generated
+/dev/mmcblk1p1 : start=         256, size=         512, type=4DA6E9DA-C803-4BE4-BAC4-8192717C5EB0, name="mlo", attrs="RequiredPartition"
+/dev/mmcblk1p2 : start=         768, size=        8192, type=5B97345D-B7A1-47D3-A491-ED40F4841639, name="uboot", attrs="RequiredPartition"
+
+/dev/mmcblk1p3 : size= ${PART_EFI_SIZE}, ${SFDISK_PART_EFI}
+/dev/mmcblk1p4 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_A}
+/dev/mmcblk1p5 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_B}
+/dev/mmcblk1p6 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_A}
+/dev/mmcblk1p7 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_B}

layers/meta-belden-coreos-bsp/recipes-coreos/coreos-installer/coreos-installer-config/eagle40-03_1.0.sfdisk

@@ -0,0 +1,13 @@
+label: gpt
+device: /dev/mmcblk2
+unit: sectors
+first-lba: 34
+last-lba: 7471070
+sector-size: 512
+
+/dev/mmcblk2p1 : start= 256, size= ${PART_EFI_SIZE}, ${SFDISK_PART_EFI}
+/dev/mmcblk2p2 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_A}
+/dev/mmcblk2p3 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_B}
+/dev/mmcblk2p4 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_A}
+/dev/mmcblk2p5 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_B}
+/dev/mmcblk2p6 : size= ${PART_USERDATA_SIZE}, ${SFDISK_PART_USERDATA}

layers/meta-belden-coreos-bsp/recipes-coreos/coreos-installer/coreos-installer-config_%.bbappend

@@ -0,0 +1,4 @@
+FILESEXTRAPATHS:prepend := "${THISDIR}/coreos-installer-config:"
+
+SRC_URI:append:beaglebone = " file://beaglebone_1.0.sfdisk"
+SRC_URI:append:eagle40-03 = " file://eagle40-03_1.0.sfdisk"

layers/meta-belden-coreos-bsp/recipes-kernel/linux/files/eagle40-03.cfg

@@ -0,0 +1,2 @@
+CONFIG_F71808E_WDT=y
+CONFIG_WATCHDOG_SYSFS=y

layers/meta-belden-coreos-bsp/recipes-kernel/linux/files/hyperv.cfg

@@ -0,0 +1,16 @@
+CONFIG_HYPERVISOR_GUEST=y
+CONFIG_PARAVIRT=y
+CONFIG_PARAVIRT_SPINLOCKS=y
+CONFIG_CONNECTOR=y
+CONFIG_SCSI_FC_ATTRS=y
+CONFIG_HYPERV=y
+CONFIG_HYPERV_UTILS=y
+CONFIG_HYPERV_BALLOON=y
+CONFIG_HYPERV_STORAGE=y
+CONFIG_HYPERV_NET=y
+CONFIG_HYPERV_KEYBOARD=y
+CONFIG_FB_HYPERV=y
+CONFIG_HID_HYPERV_MOUSE=y
+CONFIG_PCI_HYPERV=y
+CONFIG_VSOCKETS=y
+CONFIG_HYPERV_VSOCKETS=y

layers/meta-belden-coreos-bsp/recipes-kernel/linux/linux-yocto-coreos-efi.inc

@@ -1,23 +0,0 @@
-
-inherit coreos-efi-sbsign
-require conf/image-uefi.conf
-
-# Ensure EFI STUB is enabled
-KERNEL_FEATURES:append = " cfg/efi.scc cfg/efi-ext.scc"
-
-# By default we use a Unified Kernel Image that contain the kernel, the
-# kernel command line and some device tree, so we don't need to sign the output
-# of the kernel recipes
-COREOS_KERNEL_EFI_SIGNED ??= "0"
-
-# Extend the kernel_do_deploy function from kernel.bbclass to sign the kernel
-kernel_do_deploy:append() {
-    if [ "${COREOS_KERNEL_EFI_SIGNED}" == "1" ]; then
-      deployDir="${DEPLOYDIR}"
-      for imageType in ${KERNEL_IMAGETYPES} ; do
-        baseName="$imageType-${KERNEL_IMAGE_NAME}"
-        coreos_efi_secureboot_sign_app "$deployDir/$baseName${KERNEL_IMAGE_BIN_EXT}"
-      done
-    fi
-}
-

layers/meta-belden-coreos-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend

@@ -1,13 +1,20 @@
+FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
 KMACHINE:vm-x64 ?= "common-pc-64"
 COMPATIBLE_MACHINE:vm-x64 = "vm-x64"
 
 # Enable some kernel features related to virtualiuzation
 KERNEL_FEATURES:append:vm-x64=" cfg/virtio.scc cfg/paravirt_kvm.scc"
+SRC_URI:append:vm-x64 = " file://hyperv.cfg"
+
+KMACHINE:eagle40-03 ?= "common-pc-64"
+KBRANCH:eagle40-03 = "v5.15/standard/base"
+SRCREV_machine:eagle40-03 ?= "3baf1c5c0e6084b3f4a1d2d805168d657f872e60"
+COMPATIBLE_MACHINE:eagle40-03 = "eagle40-03"
+LINUX_VERSION:eagle40-03 = "5.15.134"
+
 
 KBRANCH:beaglebone = "v5.15/standard/beaglebone"
 KMACHINE:beaglebone ?= "beaglebone"
 SRCREV_machine:beaglebone ?= "9aabbaa89fcb21af7028e814c1f5b61171314d5a"
 COMPATIBLE_MACHINE:beaglebone = "beaglebone"
 LINUX_VERSION:beaglebone = "5.15.54"
-
-require linux-yocto-coreos-efi.inc

layers/meta-belden-coreos-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend

@@ -0,0 +1,14 @@
+FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
+
+KMACHINE:eagle40-03 ?= "common-pc-64"
+COMPATIBLE_MACHINE:eagle40-03 = "eagle40-03"
+
+KMACHINE:beaglebone ?= "beaglebone"
+COMPATIBLE_MACHINE:beaglebone = "beaglebone"
+
+KMACHINE:vm-x64 ?= "common-pc-64"
+COMPATIBLE_MACHINE:vm-x64 = "vm-x64"
+KERNEL_FEATURES:append:vm-x64=" cfg/virtio.scc cfg/paravirt_kvm.scc"
+SRC_URI:append:vm-x64 = " file://hyperv.cfg"
+
+SRC_URI += " file://eagle40-03.cfg"

layers/meta-belden-coreos-bsp/wic/beaglebone-sdcard-installer.wks

@@ -0,0 +1,20 @@
+# short-description: Create SD card image for Beaglebone
+# long-description: Creates a partitioned SD card image for Beaglebone.
+
+# offset 1S => 1 sector (1x512 byte)
+# The bootloader can be at 4 different position in raw mode: 0S, 256S, 512S, 768S
+# MBR disk use only the sector 0, so 1S is free
+# GPT disk use sector 0-33S, so first free slot is 256S
+# Offset are from the BBB default settings
+
+# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+# Don't name partition in the installer disk image, otherwise the installer may not work as it rely on partition label!
+# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+part --offset 256S --source rawcopy --sourceparams="file=MLO" --ondisk mmcblk0 --fixed-size 256K
+part --offset 768S --source rawcopy --sourceparams="file=u-boot.img" --ondisk mmcblk0 --fixed-size 4M
+
+# Let's define a 4MiB maximum size for the bootloader
+# 4MiB => 4*1024*1024/512=8192S | 768S + 8192S => 8960S
+part --source bootimg-partition --part-type=EF00 --ondisk mmcblk0 --offset 8960S --fixed-size 125M
+bootloader --ptable gpt

layers/meta-belden-coreos-bsp/wic/beaglebone-sdcard.wks.in

@@ -1,11 +1,20 @@
 # short-description: Create SD card image for Beaglebone
 # long-description: Creates a partitioned SD card image for Beaglebone.
-# Boot files are located in the first vfat partition.
 
-part --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 4 --fixed-size 32
-${WKS_PART_EFI} --ondisk mmcblk0 --align 1024 --fixed-size 32
-${WKS_PART_ROOT_A} --ondisk mmcblk0 --fixed-size 2G
-${WKS_PART_ROOT_B} --ondisk mmcblk0 --fixed-size 2G
-${WKS_PART_EFIBOOTGUARD_A} --ondisk mmcblk0 --align 1024 --fixed-size 32
-${WKS_PART_EFIBOOTGUARD_B} --ondisk mmcblk0 --align 1024 --fixed-size 32
-bootloader --ptable msdos
+# offset 1S => 1 sector (1x512 byte)
+# The bootloader can be at 4 different position in raw mode: 0S, 256S, 512S, 768S
+# MBR disk use only the sector 0, so 1S is free
+# GPT disk use sector 0-33S, so first free slot is 256S
+# Offset are from the BBB default settings
+part --offset 256S --source rawcopy --sourceparams="file=MLO" --ondisk mmcblk0 --fixed-size 256K --part-name "mlo"
+part --offset 768S --source rawcopy --sourceparams="file=u-boot.img" --ondisk mmcblk0 --fixed-size 4M --part-name "uboot"
+
+
+# Let's define a 4MiB maximum size for the bootloader
+# 4MiB => 4*1024*1024/512=8192S | 768S + 8192S => 8960S
+${WKS_PART_EFI} --ondisk mmcblk0 --offset 8960S --fixed-size 32M
+${WKS_PART_EFIBOOTGUARD_A} --ondisk mmcblk0 --fixed-size ${PART_EFIBG_SIZE}
+${WKS_PART_EFIBOOTGUARD_B} --ondisk mmcblk0 --fixed-size ${PART_EFIBG_SIZE}
+${WKS_PART_ROOT_A} --ondisk mmcblk0 --fixed-size ${PART_ROOT_SIZE}
+${WKS_PART_ROOT_B} --ondisk mmcblk0 --fixed-size ${PART_ROOT_SIZE}
+bootloader --ptable gpt

layers/meta-belden-coreos-bsp/wic/generic-uefi-usb-installer.wks

@@ -0,0 +1,16 @@
+# short-description: Create USB image for Eagle 40-03
+# long-description: Creates a partitioned USB image for Eagle 40-03.
+
+# offset 1S => 1 sector (1x512 byte)
+# The bootloader can be at 4 different position in raw mode: 0S, 256S, 512S, 768S
+# MBR disk use only the sector 0, so 1S is free
+# GPT disk use sector 0-33S, so first free slot is 256S
+# Offset are from the BBB default settings
+
+# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+# Don't name partition in the installer disk image, otherwise the installer may not work as it rely on partition label!
+# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+part --offset 256S --source bootimg-partition --part-type=EF00 --ondisk mmcblk0
+part --fixed-size 3G --fstype=vfat --label=image
+bootloader --ptable gpt

layers/meta-belden-coreos-bsp/wic/generic-uefi.wks.in

@@ -1,10 +1,11 @@
 # short-description: Create an EFI disk image for genericx86*
 # long-description: Creates a partitioned EFI disk image for genericx86* machines
-${WKS_PART_EFI} --ondisk sda  --align 1024 --fixed-size 32
-${WKS_PART_ROOT_A} --ondisk sda --fixed-size 2G
-${WKS_PART_ROOT_B} --ondisk sda --fixed-size 2G
-${WKS_PART_EFIBOOTGUARD_A} --ondisk sda  --align 1024 --fixed-size 32
-${WKS_PART_EFIBOOTGUARD_B} --ondisk sda  --align 1024 --fixed-size 32
 
-part swap --ondisk sda --size 44 --label swap1 --fstype=swap
+${WKS_PART_EFI} --align 1024 --size ${PART_EFI_SIZE} --extra-space 0 --overhead-factor 1
+${WKS_PART_ROOT_A} --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
+${WKS_PART_ROOT_B} --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
+${WKS_PART_EFIBOOTGUARD_A} --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
+${WKS_PART_EFIBOOTGUARD_B} --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
+${WKS_PART_USERDATA} --size ${PART_USERDATA_SIZE} --extra-space 0 --overhead-factor 1
+
 bootloader --ptable gpt

layers/meta-belden-coreos-bsp/wic/qemu-efi-coreos-generic.wks.in

@@ -0,0 +1,12 @@
+# short-description: Create an EFI disk image
+# long-description: Creates a partitioned EFI disk image that the user
+# can directly dd to boot media.
+
+part --source efibootguard-efi --label efi --part-type=EF00 --use-uuid --offset 20480S --size ${PART_EFI_SIZE} --extra-space 0 --overhead-factor 1
+part / --source rootfs --fstype=ext4 --label rootfs0 --use-uuid --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
+part --fstype=ext4 --label rootfs1 --use-uuid --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
+part --source efibootguard-boot --label ebg0 --part-type=0700 --sourceparams "args=coreos.root=rootfs0,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI" --use-uuid --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
+part --source efibootguard-boot --label ebg1 --part-type=0700 --sourceparams "args=coreos.root=rootfs1,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI" --use-uuid --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
+${WKS_PART_USERDATA} --use-uuid --size ${PART_USERDATA_SIZE} --extra-space 0 --overhead-factor 1
+
+bootloader --ptable gpt

layers/meta-belden-coreos-demo/recipes-core/images/coreos-image-demo-k3s.bb

@@ -0,0 +1,8 @@
+DESCRIPTION = "An image that includes k3s-agent"
+
+require recipes-core/images/coreos-image-all-features.bb
+
+IMAGE_INSTALL += "k3s-agent"
+
+# To use this image, please add k3s to DISTRO_FEATURE inside your
+# local.conf config file.

layers/meta-belden-coreos-demo/recipes-core/images/coreos-image-demo.bb

@@ -0,0 +1,7 @@
+DESCRIPTION = "An image that come with most of the feature available in CoreOS"
+
+inherit coreos-image
+require recipes-core/images/coreos-image-all-features.bb
+
+# demos
+IMAGE_INSTALL:append = " systemd-services-demo cmake-demo"

layers/meta-belden-coreos-demo/recipes-demo/containers/coreos-container-image-lighttpd.bb

@@ -2,6 +2,12 @@ SUMMARY = "A lighttpd container image"
 
 inherit coreos-container-image
 
+# Install systemd in the container
+IMAGE_FEATURES += "systemd" 
+
+# Allow to log using systemd without password
+IMAGE_FEATURES += "empty-root-password"
+
 IMAGE_INSTALL:append = " \
     busybox \
     lighttpd \

layers/meta-belden-coreos-demo/recipes-demo/containers/coreos-container-lighttpd.bb

@@ -3,5 +3,4 @@ SUMMARY = "A lighttpd container package"
 inherit coreos-container-package
 
 CONTAINER_IMAGE = "coreos-container-image-lighttpd"
-PODMAN_RUN_OPTIONS = "-p 80:80 --entrypoint /usr/sbin/lighttpd"
-PODMAN_RUN_CMD = "-D -f /etc/lighttpd/lighttpd.conf"
+PODMAN_RUN_OPTIONS = "-p 80:80"

layers/meta-belden-coreos-demo/recipes-demo/systemd-services-demo/files/demo_service_1.sh

@@ -0,0 +1,15 @@
+#!/bin/sh
+
+# This is a simple example for systemd start
+PIPE="/tmp/bar"
+if [ ! -p "$PIPE" ]; then
+        mkfifo $PIPE
+fi
+
+COUNTER=0
+
+while : ; do
+        COUNTER=$((COUNTER + 1))
+        echo "Hello Service 1: ${COUNTER}" > /tmp/bar
+        sleep 10
+done

layers/meta-belden-coreos-demo/recipes-demo/systemd-services-demo/files/demo_service_2.sh

@@ -0,0 +1,18 @@
+#!/bin/sh
+
+# This is a simple example for systemd start
+
+PIPE="/tmp/baz"
+if [ ! -p "$PIPE" ]; then
+        mkfifo $PIPE
+fi
+
+COUNTER=0
+
+while : ; do
+        COUNTER=$((COUNTER + 1))
+        echo "Hello Service 2: ${COUNTER}" > /tmp/baz
+        sleep 10
+done
+
+

layers/meta-belden-coreos-demo/recipes-demo/systemd-services-demo/files/demo_service_3.sh

@@ -0,0 +1,28 @@
+#!/bin/sh
+
+# This is an example for systemd-notify
+# You can see the status with systemctl status demoservice3.service
+
+
+PIPE="/tmp/foo"
+if [ ! -p "$PIPE" ]; then
+        mkfifo  -m 666 $PIPE
+fi
+
+sleep 10  # Assume we are doing some time consuming initialization
+
+# Notify systemd that we are ready
+systemd-notify --ready --status="Waiting for data ..."
+
+while : ; do
+        read a < /tmp/foo
+        # Tell systemd your current status
+        systemd-notify --status="Processing $a"
+
+        # Do something with $a …
+        sleep 10
+
+        systemd-notify --status="Waiting for data ..."
+done
+
+

layers/meta-belden-coreos-demo/recipes-demo/systemd-services-demo/files/demoservice1.service

@@ -0,0 +1,10 @@
+[Unit]
+Description=systemd demo
+After=demoservice3.service
+Wants=demoservice3.service
+
+[Service]
+ExecStart=/usr/bin/demo_service_1.sh
+
+[Install]
+WantedBy=multi-user.target

layers/meta-belden-coreos-demo/recipes-demo/systemd-services-demo/files/demoservice2.service

@@ -0,0 +1,10 @@
+[Unit]
+Description=systemd demo for showing dependencies
+After=demoservice3.service
+Requires=demoservice3.service
+
+[Service]
+ExecStart=/usr/bin/demo_service_2.sh
+
+[Install]
+WantedBy=multi-user.target

layers/meta-belden-coreos-demo/recipes-demo/systemd-services-demo/files/demoservice3.service

@@ -0,0 +1,9 @@
+[Unit]
+Description=systemd demo for showing notifications
+
+[Service]
+Type=notify
+ExecStart=/usr/bin/demo_service_3.sh
+
+[Install]
+WantedBy=multi-user.target

layers/meta-belden-coreos-demo/recipes-demo/systemd-services-demo/systemd-services-demo.bb

@@ -0,0 +1,34 @@
+DESCRIPTION = "Example that shows how services can be started by using systemd unit files"
+SECTION = "examples"
+DEPENDS = ""
+LICENSE = "CLOSED"
+
+FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
+
+SRC_URI = " file://demo_service_1.sh \
+            file://demoservice1.service  \
+            file://demo_service_2.sh \
+            file://demoservice2.service  \
+            file://demo_service_3.sh \
+            file://demoservice3.service  \
+"
+
+inherit systemd
+
+SYSTEMD_SERVICE:${PN} += "demoservice1.service"
+SYSTEMD_SERVICE:${PN} += "demoservice2.service"
+SYSTEMD_SERVICE:${PN} += "demoservice3.service"
+SYSTEMD_AUTO_ENABLE = "enable"
+
+do_install(){
+    install -d ${D}${bindir}
+    install -m 0777 ${WORKDIR}/demo_service_1.sh ${D}${bindir}
+    install -m 0777 ${WORKDIR}/demo_service_2.sh ${D}${bindir}
+    install -m 0777 ${WORKDIR}/demo_service_3.sh ${D}${bindir}
+    install -d ${D}${systemd_unitdir}/system
+    install -m 0644 ${WORKDIR}/demoservice1.service ${D}${systemd_unitdir}/system
+    install -m 0644 ${WORKDIR}/demoservice2.service ${D}${systemd_unitdir}/system
+    install -m 0644 ${WORKDIR}/demoservice3.service ${D}${systemd_unitdir}/system
+}
+
+FILES:${PN} += " ${systemd_unitdir}/system/demoservice*.service ${bindir}/demo_service_*.sh"

layers/meta-belden-coreos-demo/recipes-kernel/linux/files/k3s_kernel_adaptions.cfg

@@ -0,0 +1,8 @@
+#this file contains the necssary kernel adaption that k3s an containerd require
+#Reference
+#k3s config check: https://raw.githubusercontent.com/k3s-io/k3s/master/contrib/util/check-config.sh
+#container config check: https://raw.githubusercontent.com/moby/moby/master/contrib/check-config.sh
+#these scripts are provided by moby and rancher
+CONFIG_OABI_COMPAT=n
+CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
+CONFIG_SECCOMP_FILTER=y

layers/meta-belden-coreos-demo/recipes-kernel/linux/linux-yocto_%.bbappend

@@ -0,0 +1 @@
+FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

layers/meta-belden-coreos/classes/bats-library.bbclass

@@ -0,0 +1,19 @@
+# Library to share code needed to install most available bats library
+
+# Bats library are shell scripts, so they are arch independant
+inherit allarch
+
+RDEPENDS:${PN} += "bats"
+
+# Bats can find library in this folder by default
+BATS_LIB_PATH ?= "${libdir}/bats"
+
+# By default the library will have the same name as the recipe
+BATS_INSTALL_DIR ?= "${BATS_LIB_PATH}/${PN}"
+FILES:${PN} += "${BATS_INSTALL_DIR}"
+
+do_install() {
+    install -d ${D}${BATS_INSTALL_DIR}
+    cp -r ${S}/src ${D}${BATS_INSTALL_DIR}/
+    install ${S}/load.bash ${D}${BATS_INSTALL_DIR}/
+}

layers/meta-belden-coreos/classes/coreos-container-image.bbclass

@@ -9,25 +9,31 @@ NO_RECOMMENDATIONS = "1"
 # the host, thus we can't use linux-dummy has the default kernel provider.
 IMAGE_CONTAINER_NO_DUMMY = "1"
 
-
-# Only install a reduced set of packages in a container. This correspond to
-# a subset of packagegroup-core-boot
-COREOS_CONTAINER_IMAGE_BASE_INSTALL = '\
-    base-files \
-    base-passwd \
-    netbase \
-    os-release \
-    '
+COREOS_CONTAINER_IMAGE_BASE_INSTALL = "\
+    packagegroup-coreos-container \
+"
 
 COREOS_CONTAINER_IMAGE_EXTRA_INSTALL ?= ""
 IMAGE_INSTALL ?= "${COREOS_CONTAINER_IMAGE_BASE_INSTALL} ${COREOS_CONTAINER_IMAGE_EXTRA_INSTALL}"
 
-# Images features for containers
+# OCI Parameters
 # ==============================================================================
 
+OCI_IMAGE_ENTRYPOINT ?= "${@bb.utils.contains('IMAGE_FEATURES', 'systemd', '/usr/sbin/init', '/usr/bin/sh', d)}"
+
 inherit image
 inherit image-oci
 
+# Images features for containers
+# ==============================================================================
+
+# Install systemd inside the container
+FEATURE_PACKAGES_systemd = "systemd"
+
+
+# Image Post processings
+# ==============================================================================
+
 IMAGE_CMD:oci:append() {
     # meta-virtualization default IMAGE_CMD doesn't create a symlink on kirkstone
     image_link_name="${IMAGE_LINK_NAME}${IMAGE_NAME_SUFFIX}-oci"
@@ -41,13 +47,27 @@ IMAGE_CMD:oci:append() {
 
 # Workaround /var/volatile for now
 # See layers/meta-virtualization/recipes-extended/images/container-base.bb
-ROOTFS_POSTPROCESS_COMMAND += "${@bb.utils.contains('IMAGE_FEATURES', 'init-manager', '', 'rootfs_fixup_var_volatile ; ', d)}"
+ROOTFS_POSTPROCESS_COMMAND += "rootfs_fixup_var_volatile ; "
 rootfs_fixup_var_volatile () {
     install -m 1777 -d ${IMAGE_ROOTFS}/${localstatedir}/volatile/tmp
     install -m 755 -d ${IMAGE_ROOTFS}/${localstatedir}/volatile/log
 
-    # When using systemd, systemd is responsible to link /var/{log,tmp} to /var/volutile/{log,tmp}
-    # As container doesn't normally use systemd, we create the link by ourself here
+    # in rootfs-postcommands.bbclass, when using initscripts theses link
+    # are created by running ${IMAGE_ROOTFS}/etc/init.d/populate-volatile.sh
+    # When the distro is configured to systemd, this is not done, so we need to
+    # do it here manually (As systemd is not always included in the container)
     ln -sf ${localstatedir}/volatile/tmp ${IMAGE_ROOTFS}/${localstatedir}/tmp
     ln -sf ${localstatedir}/volatile/log ${IMAGE_ROOTFS}/${localstatedir}/log
 }
+
+ROOTFS_POSTPROCESS_COMMAND += "${@bb.utils.contains('IMAGE_FEATURES', 'systemd', 'rootfs_fixup_systemd ; ', '', d)}"
+rootfs_fixup_systemd () {
+    # Mask systemd services that are not needed/doesn't work in a container
+    # This ensure that the container doesn't boot in systemd emergency mode
+    systemctl --root=${IMAGE_ROOTFS} mask systemd-remount-fs.service
+    systemctl --root=${IMAGE_ROOTFS} mask var-volatile.mount
+}
+
+# Add support for plugin classes like in coreos-image.bbclass
+COREOS_IMAGE_EXTRACLASSES ?= ""
+inherit ${COREOS_IMAGE_EXTRACLASSES}

layers/meta-belden-coreos/classes/coreos-image-ci.bbclass

@@ -0,0 +1,99 @@
+# This class should only be used when running in the CI environment of CoreOS
+# On the CI, this class is ihnerited by adding
+# > COREOS_IMAGE_EXTRACLASSES += "coreos-image-ci"
+# in auto.conf (or local.conf)
+
+inherit kernel-artifact-names
+
+def get_coreos_ci_artifacts(d):
+    artifacts = []
+
+    # common variable
+    machine = d.getVar('MACHINE')
+
+    # Container handling
+    # ==========================================================================
+
+    if bb.utils.contains('IMAGE_FSTYPES', 'oci', True, False, d):
+
+        artifacts.append(d.getVar('IMAGE_LINK_NAME') + '.rootfs-oci.tar')
+
+        # Special case for container, we just need the OCI tarball
+        return " ".join(artifacts)
+
+    # SDCard image and Swupdate image
+    # ==========================================================================
+
+    if bb.utils.contains('IMAGE_FSTYPES', 'wic.xz', True, False, d):
+        artifacts.append(d.getVar('IMAGE_LINK_NAME') + '.wic.xz')
+
+    if bb.utils.contains('IMAGE_FSTYPES', 'wic.bmap', True, False, d):
+        artifacts.append(d.getVar('IMAGE_LINK_NAME') + '.wic.bmap')
+
+    # This is used for qemu-coreos-arm64
+    if bb.utils.contains('IMAGE_FSTYPES', 'wic.qcow2', True, False, d):
+        artifacts.append(d.getVar('IMAGE_LINK_NAME') + '.wic.qcow2')
+
+    if d.getVar('COREOS_IMAGE_GENERATE_SWU') == '1':
+        artifacts.append(d.getVar('IMAGE_LINK_NAME') + '.swu')
+
+    # CoreOS Installer
+    # ==========================================================================
+
+    if d.getVar('COREOS_IMAGE_GENERATE_INSTALLER') == '1':
+        artifacts.append('coreos-installer-' + d.getVar('MACHINE') + '.efi')
+
+    # Kernel
+    # ==========================================================================
+
+    kernel_imagetype = d.getVar('KERNEL_IMAGETYPE', None)
+    kernel_image_bin_ext = d.getVar('KERNEL_IMAGE_BIN_EXT') or ''
+    artifacts.append(kernel_imagetype + '-' + machine + kernel_image_bin_ext)
+
+    if d.getVar('COREOS_IMAGE_GENERATE_UKI') == '1':
+        artifacts.append(d.getVar('COREOS_KERNEL_FILENAME'))
+
+    # Bootloaders
+    # ==========================================================================
+    if 'efi' in d.getVar('MACHINE_FEATURES', ''):
+        if d.getVar('EFI_PROVIDER', "") == 'efibootguard':
+            efi_arch = d.getVar('EFI_ARCH')
+            artifacts.append('efibootguard' + efi_arch + '.efi')
+
+    # Machine specific files
+    # ==========================================================================
+    # Add file from IMAGE_BOOT_FILES IMAGE_EFI_BOOT_FILES
+    # More machine spefic file can be added inside the machine configuration
+    # file using:
+    # > COREOS_CI_DEPLOY_ARTIFACTS += "filename"
+
+    def remove_suffix(f):
+        # IMAGE_BOOT_FILES and IMAGE_EFI_BOOT_FILES support to have ; in the
+        # name to rename the file inside the boot partition, so we need
+        # to remove this suffis
+        return f.split(";", 1)[0]
+
+    image_boot_files = d.getVar('IMAGE_BOOT_FILES') or ''
+    artifacts += map(remove_suffix, image_boot_files.split(' '))
+
+    image_efi_boot_files = d.getVar('IMAGE_EFI_BOOT_FILES') or ''
+    artifacts += map(remove_suffix, image_efi_boot_files.split(' '))
+
+    return " ".join(artifacts)
+
+# Using a variable to store the list of file allow machine configuration to add
+# machine specific item before generating the file. This also allow the use of
+# :remove to remove an element from the list
+COREOS_CI_DEPLOY_ARTIFACTS += "${@get_coreos_ci_artifacts(d)}"
+
+do_deploy_ci() {
+    # Create the .ci-artifacts file inside the deploy directory
+    cd "${DEPLOY_DIR_IMAGE}"
+    output="${IMAGE_LINK_NAME}.ci-artifacts"
+
+    rm -f "${output}"
+    for file in ${COREOS_CI_DEPLOY_ARTIFACTS}; do
+        echo $file >> $output
+    done
+}
+addtask deploy_ci after do_image before do_build

layers/meta-belden-coreos/classes/coreos-image-installer.bbclass

@@ -0,0 +1,41 @@
+# Class used to generate image based on Belden CoreOS
+
+export IMAGE_BASENAME = "${MLPREFIX}${PN}"
+IMAGE_NAME_SUFFIX ?= ""
+IMAGE_LINGUAS = ""
+
+LICENSE = "MIT"
+
+IMAGE_FSTYPES = "cpio.gz"
+
+# Support for generating a SDCard or USB installer is optional
+COREOS_INSTALLER_WKS_FILE ??= ""
+WKS_FILE = "${COREOS_INSTALLER_WKS_FILE}"
+IMAGE_FSTYPES += "${@'wic.xz wic.bmap' if d.getVar('COREOS_INSTALLER_WKS_FILE') else ''}"
+IMAGE_BOOT_FILES =  "${COREOS_KERNEL_FILENAME};EFI/BOOT/${EFI_BOOT_IMAGE}"
+
+COREOS_IMAGE_GENERATE_UKI = "1"
+
+# IMGDEPLOYDIR has to be used instead of DEPLOY_DIR_IMAGE here, because it will
+# run during image generation
+COREOS_UKI_PART_INITRAMFS = "${IMGDEPLOYDIR}/${IMAGE_BASENAME}-${MACHINE}.cpio.gz"
+COREOS_IMAGE_GENERATE_SWU = "0"
+
+# Change generated UKI filename and reset the bundled command line to "APPEND"
+# to ensure that root is not set in the kernel command line
+COREOS_KERNEL_NAME ?= "coreos-installer-${MACHINE}"
+COREOS_KERNEL_CMDLINE ?= "${APPEND}"
+
+inherit coreos-image
+
+# Only install a reduced set of package and feature to keep image size small
+IMAGE_INSTALL = "packagegroup-coreos-boot coreos-installer coreos-installer-unattended util-linux-sfdisk util-linux-fdisk util-linux-cfdisk efibootguard efibootguard-tools"
+IMAGE_FEATURES = "debug-tweaks swupdate"
+NO_RECOMMENDATIONS = "1"
+
+IMAGE_ROOTFS_SIZE = "8192"
+INITRAMFS_MAXSIZE = "976562"
+IMAGE_ROOTFS_EXTRA_SPACE = "0"
+
+# Use the same restriction as initramfs-module-install
+COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'

layers/meta-belden-coreos/classes/coreos-image-swupdate.bbclass

@@ -7,9 +7,6 @@
 # Swupdate image generation
 # ==============================================================================
 
-# Machine using MBR override this value, see legacy-mbr-disk.inc
-COREOS_DISK_PARTLABEL_LOOKUP_DIRECTORY ??= "/dev/disk/by-partlabel"
-
 IMAGE_FSTYPES:append = " ext4.zst"
 python () {
     image = d.getVar('IMAGE_BASENAME')
@@ -19,16 +16,64 @@ python () {
 inherit swupdate-image
 
 # Ensure than variable used in the sw-description files are watched for change
-do_swuimage[vardeps] += "COREOS_KERNEL0_FILENAME COREOS_KERNEL1_FILENAME EFIBOOTGUARD_TIMEOUT COREOS_DISK_PARTLABEL_LOOKUP_DIRECTORY APPEND"
+do_swuimage[vardeps] += "COREOS_KERNEL_FILENAME EFIBOOTGUARD_TIMEOUT EFIDIR EFI_BOOT_IMAGE COREOS_EFIBOOTGUARD_FILENAME"
 do_swuimage[deptask] += "do_bundle_uki"
-SWUPDATE_IMAGES += "${COREOS_KERNEL0_NAME} ${COREOS_KERNEL1_NAME}"
+
+COREOS_EFIBOOTGUARD_NAME ?= "efibootguard${EFI_ARCH}"
+COREOS_EFIBOOTGUARD_EXT ?= ".efi"
+COREOS_EFIBOOTGUARD_FILENAME = "${COREOS_EFIBOOTGUARD_NAME}${COREOS_EFIBOOTGUARD_EXT}"
+
+SWUPDATE_IMAGES += "${COREOS_KERNEL_NAME} ${COREOS_EFIBOOTGUARD_NAME}"
 
 python () {
-    kernel0 = d.getVar('COREOS_KERNEL0_NAME')
-    kernel1 = d.getVar('COREOS_KERNEL1_NAME')
+    kernel = d.getVar('COREOS_KERNEL_NAME')
     kernelext = d.getVar('COREOS_KERNEL_EXT')
-    d.setVarFlag("SWUPDATE_IMAGES_FSTYPES", kernel0, kernelext)
-    d.setVarFlag("SWUPDATE_IMAGES_FSTYPES", kernel1, kernelext)
+    d.setVarFlag("SWUPDATE_IMAGES_FSTYPES", kernel, kernelext)
+
+    efibootguard = d.getVar('COREOS_EFIBOOTGUARD_NAME')
+    efibootguardext = d.getVar('COREOS_EFIBOOTGUARD_EXT')
+    d.setVarFlag("SWUPDATE_IMAGES_FSTYPES", efibootguard, efibootguardext)
 }
 
 FILESEXTRAPATHS:append := ":${COREOS_ROOT}/layers/meta-belden-coreos/files"
+
+# Space seperated list of extension points
+COREOS_SWUPDATE_EXTENDS_FOR ??= ""
+
+def coreos_swupdate_extends(d, s, key):
+    """
+    Extends the swupdate for each extension points defined by COREOS_SWUPDATE_EXTENDS_FOR
+    """
+    extends_for = d.getVar('COREOS_SWUPDATE_EXTENDS_FOR', True).replace("-", "_").split()
+
+    def kv_to_sw_description(kv):
+        swdescr = ",{\n"
+        for key, value in kv.items():
+            swdescr += f'{key} = "{value}";\n'
+        swdescr += "}\n"
+        return swdescr
+
+    text = ""
+
+    # BSP and Distro can extends the swupdate by implementing some python 
+    # function that return a list of dictionary.
+    for extension_point in extends_for:
+        try:
+            kv_list = globals()[f"coreos_swupdate_extends_{key}_for_{extension_point}"](d,s)
+        except KeyError:
+            # Don't fail if the extension is not implemented
+            pass
+        else:
+            for kv in kv_list:
+                text += kv_to_sw_description(kv)
+
+    return text
+
+# Signature support
+inherit coreos-efi-secureboot
+SWUPDATE_SIGNING = "CMS"
+SWUPDATE_CMS_KEY  = "${COREOS_EFI_SECUREBOOT_KEYDIR}/swupdate.key"
+SWUPDATE_CMS_CERT = "${COREOS_EFI_SECUREBOOT_KEYDIR}/swupdate.crt"
+
+COREOS_IMAGE_SWUPDATE_EXTRACLASSES ?= ""
+inherit ${COREOS_IMAGE_SWUPDATE_EXTRACLASSES}