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,15 +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 "meta-efibootguard"]
+	path = external-layers/meta-efibootguard
+	url = ssh://git@bitbucket.gad.local:7999/ico/meta-efibootguard.git
+	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/ref-manual/machines.rst

@@ -16,7 +16,7 @@ x64
 ---
 
 The x64 suffix is used for machine that generate code that can run on any modern
-AMD64 computer. This need at least a Core2 Duo processor.
+AMD64 computer. This need at least to be a Core2 Duo processor.
 
 arm32
 -----
@@ -28,8 +28,8 @@ and VFPv3-D32 extension set.
 arm64
 -----
 
-The arm64 suffis is used to generate cade that is compatible with any ARM
-provessor that is compatible with the AArch64 architecture.
+The arm64 suffix is used to generate code that is compatible with any ARM
+processor that is compatible with the AArch64 architecture.
 
 .. _ref-machine-vm:
 

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

documentation/using-container.rst

@@ -25,7 +25,7 @@ for AMD64 machine with the following command:
 
 .. code-block:: sh
 
-    $ MACHINE=container-x64 bitbake core-image-minimal
+    $ MACHINE=container-x64 bitbake coreos-image-minimal
 
 
 This will generate a container tarball in the tar.gz format.
@@ -57,7 +57,7 @@ To run an interactive shell, you can use:
     / # 
 
 The `<IMAGE_ID>` should be copied from the output of `podman import`. In this
-exemple, it was
+example, it was
 `051856498a59e0ae6349492539efaf915a33dd73e7a54ce9683b0414d1481fae`.
 
 You are now inside the container, try the following command:
@@ -75,7 +75,7 @@ You are now inside the container, try the following command:
 .. note::
 
     Image generated using any container machines doesn't include the Linux
-    kernel neither many system componant that are usually not used on a container
+    kernel neither many system component that are usually not used on a container
     like SystemD or udev. This is done inside the machine configuration by
     settings all the `VIRTUAL_RUNTIME_<component>` to an empty string.
 

documentation/using-coreos.rst

@@ -199,6 +199,22 @@ Create the file `product/layers/meta-product/classes/product_metadata_scm.bbclas
 and copy the content of the coreos_metadata_scm.bbclass file. Replacing all
 reference to COREOS by PRODUCT should works.
 
+... start fast and easy development
+***********************************
+
+By adding `debug-tweaks` to `EXTRA_IMAGE_FEATURES` the image is made suitable
+for development. This allows for example root login with no password.
+For a complete list of the functionality that is added or removed by using
+`debug-tweaks` have a look at the official documentation.
+
+Following CoreOS specific functionality was added to `debug-tweaks`:
+
+* disables the read-only filesystem.
+
+.. warning::
+
+    This is for development only and must not be used for production images.
+
 ... set a root password
 ***********************
 

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-bsp-config.bbclass

@@ -1,44 +0,0 @@
-# This class is ihnerited globally in the CoreOS distro
-# ==============================================================================
-#
-# This class change the default of variables that are usually set in the machine
-# configuration
-
-# EFI Configuration
-# ==============================================================================
-
-# EFI is a requirement for CoreOS
-MACHINE_FEATURES:append = "efi"
-MACHINE_FEATURES:remove:container = "efi"
-
-# If a bootloader is used, it should be systemd-boot and not grub-efi as set
-# in packagegroup-core-boot by default.
-EFI_PROVIDER ?= "systemd-boot"
-
-# Variables used in *.wks.in files
-# ==============================================================================
-
-# Partition type UUIDs
-# ==============================================================================
-
-# See https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
-WKS_GPT_PART_UUID_ROOT:arm = "69DAD710-2CE4-4E3C-B16C-21A1D49ABED3"
-WKS_GPT_PART_UUID_ROOT:aarch64 = "B921B045-1DF0-41C3-AF44-4C6F280D3FAE"
-WKS_GPT_PART_UUID_ROOT:x86-64 = "4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709"
-
-WKS_GPT_PART_UUID_EFI = "C12A7328-F81F-11D2-BA4B-00A0C93EC93B"
-
-# For MBR disk, the EFI partition should use --system-id 0xef
-
-# For GPT disk
-WKS_MBR_PART_EFI ??= 'part /boot --source bootimg-efi --sourceparams="loader=${EFI_PROVIDER}" --align 1024 --label EFI --system-id 0xef'
-WKS_GPT_PART_EFI ??= 'part /boot --source bootimg-efi --sourceparams="loader=${EFI_PROVIDER}" --align 1024 --label EFI --part-type "${WKS_GPT_PART_UUID_EFI}"'
-
-WKS_MBR_PART_ROOT ??= 'part / --source rootfs --fstype=ext4 --label root --align 1024 --use-uuid'
-WKS_GPT_PART_ROOT ??= 'part / --source rootfs --fstype=ext4 --label root --align 1024 --use-uuid --part-type ${WKS_GPT_PART_UUID_ROOT}'
-
-
-WKS_KERNEL_ARGS_EXTRA ??= "console=ttyS0,115200 console=tty0"
-WKS_KERNEL_ARGS ??= "rootfstype=ext4 rootwait ${WKS_KERNEL_ARGS_EXTRA}"
-
-WKS_BOOTLOADER_ARGS ??= '--timeout=5 --append="${WKS_KERNEL_ARGS}"'

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 
+        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,23 +5,26 @@
 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.wks.in"
-MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"
+WKS_FILE ?= "beaglebone-sdcard.wks.in"
+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"
 
 SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0 115200;ttyAMA0"
 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"
@@ -32,18 +35,14 @@ UBOOT_MACHINE = "am335x_evm_defconfig"
 UBOOT_ENTRYPOINT = "0x80008000"
 UBOOT_LOADADDRESS = "0x80008000"
 
-MACHINE_FEATURES = "usbgadget usbhost vfat alsa efi"
-
-IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY}"
-# ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}
-IMAGE_EFI_BOOT_FILES ?= "${KERNEL_DEVICETREE}"
+MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
 
 # support runqemu
 EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
 IMAGE_CLASSES += "qemuboot"
 QB_DEFAULT_FSTYPE = "wic"
 QB_FSINFO = "wic:no-kernel-in-fs"
-QB_KERNEL_ROOT = "/dev/vda2"
+QB_KERNEL_ROOT = "/dev/vda3"
 QB_SYSTEM_NAME = "qemu-system-arm"
 QB_MACHINE = "-machine virt"
 QB_CPU = "-cpu cortex-a15"
@@ -54,3 +53,11 @@ QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
 QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"
 QB_SERIAL_OPT = ""
 QB_TCPSERIAL_OPT = "-device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon"
+
+# No watchdog available yet
+EFIBOOTGUARD_TIMEOUT ?= "0"
+
+COREOS_IMAGE_SWUPDATE_EXTRACLASSES += "coreos-image-swupdate-beaglebone"
+
+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/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

@@ -0,0 +1,6 @@
+# EFI Configuration
+# ==============================================================================
+
+MACHINE_FEATURES:append = " efi"
+
+do_image_wic[depends] += "efibootguard-native:do_populate_sysroot efibootguard:do_deploy"

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,19 +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"
 
-# Containers normaly don't need systemd or any of the VIRTUAL_RUNTIME.
-# One ways to remove it is to make a custome base image for container that don't
-# install any of the virtual runtime, the other ways is to use the same image
-# as for non-container machine and just set all the VIRTUAL_RUNTIME variables
-# to an empty string here:
-VIRTUAL-RUNTIME_dev_manager = ""
-VIRTUAL-RUNTIME_login_manager = ""
-VIRTUAL-RUNTIME_init_manager = ""
-VIRTUAL-RUNTIME_initscripts = ""
-VIRTUAL-RUNTIME_keymaps = ""
+# 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"
@@ -19,4 +19,7 @@ do_image_wic[recrdeptask] += "do_bootimg"
 
 # CoreOS Specific Machine settings
 # ==============================================================================
-COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR = "1"
+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/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-core/systemd/systemd-boot_250.5.bbappend

@@ -1,11 +0,0 @@
-# Add signature support
-
-inherit coreos-efi-sbsign
-
-do_install:append() {
-    coreos_efi_secureboot_sign_app "${D}${EFI_FILES_PATH}/${SYSTEMD_BOOT_IMAGE}"
-}
-
-do_deploy:append() {
-    coreos_efi_secureboot_sign_app ${DEPLOYDIR}/systemd-${SYSTEMD_BOOT_IMAGE}
-}

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,14 +0,0 @@
-
-inherit coreos-efi-sbsign
-
-# Ensure EFI STUB is enabled
-KERNEL_FEATURES:append = " cfg/efi.scc cfg/efi-ext.scc"
-
-# Extend the kernel_do_deploy function from kernel.bbclass to sign the kernel
-kernel_do_deploy:append() {
-    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
-}

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

@@ -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
+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/beaglebone.wks.in

@@ -1,8 +0,0 @@
-# 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_MBR_PART_EFI} --ondisk mmcblk0
-${WKS_MBR_PART_ROOT} --ondisk mmcblk0
-bootloader ${WKS_BOOTLOADER_ARGS}

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,6 +1,11 @@
 # short-description: Create an EFI disk image for genericx86*
 # long-description: Creates a partitioned EFI disk image for genericx86* machines
-${WKS_GPT_PART_EFI} --ondisk sda
-${WKS_GPT_PART_ROOT} --ondisk sda
-part swap --ondisk sda --size 44 --label swap1 --fstype=swap
-bootloader --ptable gpt ${WKS_BOOTLOADER_ARGS}
+
+${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/conf/layer.conf

@@ -0,0 +1,13 @@
+# We have a conf and classes directory, add to BBPATH
+BBPATH .= ":${LAYERDIR}"
+
+# We have recipes-* directories, add to BBFILES
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
+            ${LAYERDIR}/recipes-*/*/*.bbappend"
+
+BBFILE_COLLECTIONS += "meta-belden-coreos-demo"
+BBFILE_PATTERN_meta-belden-coreos-demo = "^${LAYERDIR}/"
+BBFILE_PRIORITY_meta-belden-coreos-demo = "6"
+
+LAYERDEPENDS_meta-belden-coreos-demo = "meta-belden-coreos meta-belden-coreos-bsp"
+LAYERSERIES_COMPAT_meta-belden-coreos-demo = "kirkstone"

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

@@ -0,0 +1,6 @@
+DESCRIPTION = "A image that run the lighttpd webserver inside a contasiner"
+
+inherit coreos-image
+
+IMAGE_FEATURES += "ssh-server podman dev-tools cockpit networkmanager"
+IMAGE_INSTALL:append = " packagegroup-core-full-cmdline coreos-container-lighttpd"

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/cmake-demo/cmake-demo_0.1.bb

@@ -0,0 +1,44 @@
+# Example how to make a recipe that uses CMake for building
+# Please note that this is a recipe to build the package. For package to be added to an Image, another recipe needs to be changed.
+# Example: This package is added to be part of coreos-image-full-cmdline image.
+# A new line: IMAGE_INSTALL += "cmake-demo" is added to layers/meta-belden-coreos/recipes-core/images/coreos-image-full-cmdline.bb
+
+DESCRIPTION = "Simple helloworld cmake application"
+
+# Recipe must include a licence
+LICENSE = "CLOSED"
+
+# Revision of this recipe (optional)
+PR = "r1"
+
+# Systemd file
+SYSTEMD_SERVICE_${PN} = "hello.service"
+
+# Recipe needs to know where the needed files are
+SRC_URI += "file://CMakeLists.txt\
+		file://lib/CMakeLists.txt \
+		file://src/CMakeLists.txt \
+		file://src/helloworld.c \
+		file://src/hello.service \
+		file://lib/lib-demo.c \
+		file://lib/lib-demo.h"
+
+# List of files and directories that are placed in a package
+FILES:${PN} += "${systemd_unitdir}/system/hello.service"
+
+# Temporary work directory for each recipe where extracted source files are kept
+S="${WORKDIR}"
+
+# CMake will do most of the work, so it needs to be inherited
+inherit cmake systemd
+
+# Passing any needed configure options to CMake
+EXTRA_OECMAKE = ""
+
+# Systemd service is being installed using this function (this is an example). Other files are installed using CMake
+do_install:append() {
+  install -d ${D}/${systemd_unitdir}/system
+  install -m 0644 ${WORKDIR}/src/hello.service ${D}/${systemd_unitdir}/system
+}
+
+

layers/meta-belden-coreos-demo/recipes-demo/cmake-demo/files/CMakeLists.txt

@@ -0,0 +1,15 @@
+# Top CMakeLists.txt file
+
+# Firstly a minimum required version of CMake is specified
+cmake_minimum_required(VERSION 3.22)
+
+# Name the project, and give a version
+project(cmake_demo VERSION 0.0.1)
+
+# Setting build logs to verbose (usefull for debugging)
+set(CMAKE_VERBOSE_MAKEFILE ON)
+
+# Adding subdirectories that contain CMakeLists.txt
+add_subdirectory(lib)
+add_subdirectory(src)
+

layers/meta-belden-coreos-demo/recipes-demo/cmake-demo/files/lib/CMakeLists.txt

@@ -0,0 +1,17 @@
+# CMakeLists.txt file is gets some info from top CMakeLists.txt file (Minimum required version, Project name), so its not needed to redefine it here
+
+
+# Declare the library target.
+add_library(${PROJECT_NAME} SHARED lib-demo.c)
+
+# Set the version property.
+set_target_properties(${PROJECT_NAME} PROPERTIES VERSION ${PROJECT_VERSION})
+
+# Set the shared object version property to the project's major version.
+set_target_properties(${PROJECT_NAME} PROPERTIES SOVERSION ${PROJECT_VERSION_MAJOR})
+
+# Set the public header property to the one with the actual API.
+set_target_properties(${PROJECT_NAME} PROPERTIES PUBLIC_HEADER lib-demo.h)
+
+# Install library and dependency file
+install (TARGETS ${PROJECT_NAME} LIBRARY DESTINATION lib PUBLIC_HEADER DESTINATION include)

layers/meta-belden-coreos-demo/recipes-demo/cmake-demo/files/lib/lib-demo.c

@@ -0,0 +1,12 @@
+/* 
+*  Simple C library to be used for demonstration
+*  Bitbake recipe calls CMake to buld and install
+*
+*/
+#include <stdio.h>
+#include "lib-demo.h"
+
+void demo_print(){
+	
+	printf("Print from demo lib\n");
+}

layers/meta-belden-coreos-demo/recipes-demo/cmake-demo/files/lib/lib-demo.h

@@ -0,0 +1,4 @@
+/*
+*  Library dependency file
+*/
+void demo_print();

layers/meta-belden-coreos-demo/recipes-demo/cmake-demo/files/src/CMakeLists.txt

@@ -0,0 +1,7 @@
+# CMakeLists.txt file is gets some info from top CMakeLists.txt file (Minimum required version, Project name), so its not needed to redefine it here
+
+# Create binary
+add_executable(helloworld helloworld.c)
+
+# Install binary
+install(TARGETS helloworld RUNTIME DESTINATION bin)

layers/meta-belden-coreos-demo/recipes-demo/cmake-demo/files/src/hello.service

@@ -0,0 +1,10 @@
+# Systemd service file
+
+[Unit]
+Description=GNU Hello World startup script for KOAN training course
+
+[Service]
+ExecStart=/usr/bin/helloworld
+
+[Install]
+WantedBy=multi-user.target

layers/meta-belden-coreos-demo/recipes-demo/cmake-demo/files/src/helloworld.c

@@ -0,0 +1,13 @@
+/*
+*  Simple C code (binary is used for demonstration)
+*/
+
+#include <stdio.h>
+
+int main() {
+
+   printf("Hello, World!");
+   
+   return 0;
+   
+}

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

@@ -0,0 +1,16 @@
+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 \
+    lighttpd-module-access \
+    lighttpd-module-accesslog \ 
+"

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

@@ -0,0 +1,6 @@
+SUMMARY = "A lighttpd container package"
+
+inherit coreos-container-package
+
+CONTAINER_IMAGE = "coreos-container-image-lighttpd"
+PODMAN_RUN_OPTIONS = "-p 80:80"