doc(bootflow): adapt bootflow doc to efibootguard and swupdate

.gitignore

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

.gitmodules

@@ -2,35 +2,23 @@
 	path = bitbake
 	url = ssh://git@bitbucket.gad.local:7999/ico/bitbake.git
 	branch = 2.0
-[submodule "openembedded-core"]
+[submodule "layers/openembedded-core"]
-	path = external-layers/openembedded-core
+	path = layers/openembedded-core
 	url = ssh://git@bitbucket.gad.local:7999/ico/openembedded-core.git
 	branch = kirkstone
-[submodule "meta-openembedded"]
+[submodule "layers/meta-openembedded"]
-	path = external-layers/meta-openembedded
+	path = layers/meta-openembedded
 	url = ssh://git@bitbucket.gad.local:7999/ico/meta-openembedded.git
 	branch = kirkstone
-[submodule "meta-virtualization"]
+[submodule "layers/meta-virtualization"]
-	path = external-layers/meta-virtualization
+	path = layers/meta-virtualization
 	url = ssh://git@bitbucket.gad.local:7999/ico/meta-virtualization.git
 	branch = kirkstone
-[submodule "meta-efibootguard"]
+[submodule "layers/meta-efibootguard"]
-	path = external-layers/meta-efibootguard
+	path = layers/meta-efibootguard
 	url = ssh://git@bitbucket.gad.local:7999/ico/meta-efibootguard.git
-	branch = master
+	branch = coreos/master
-[submodule "meta-swupdate"]
+[submodule "layers/meta-swupdate"]
-	path = external-layers/meta-swupdate
+	path = 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,10 +1,6 @@
 {
     "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,47 +1,8 @@
 {
     "files.watcherExclude": {
-        "**/build/**": true,
+        "**/build/cache/**": true,
-        "**/_build/**": true,
+        "**/build/downloads/**": true,
-    },
+        "**/build/sstate-cache/**": true,
-    "search.exclude": {
+        "**/build/tmp/**": true
-        "**/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 40fd5f4eef7460ca67f32cfce8e229e67e1ff607
+Subproject commit ac576d6fad6bba0cfea931883f25264ea83747ca

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}/external-layers/openembedded-core}"
+OEROOT="${OEROOT:-${COREOS_ROOT}/layers/openembedded-core}"
 TEMPLATECONF="${TEMPLATECONF:-${COREOS_ROOT}/templates}"
 
 # Sanity checks
@@ -84,11 +84,6 @@ coreos_path_add "${COREOS_ROOT}/scripts"
 # Add support for ##COREOS_LAYERSDIR## inside of bblayer template
 coreos-bblayers-envsub COREOS_LAYERSDIR "${COREOS_ROOT}/layers"
 
-# Add support for ##COREOS_EXTLAYERSDIR## inside of bblayer template
+# Generate the ${BUILDDIR}/key directory. The scripts doesn't generate anything it
-coreos-bblayers-envsub COREOS_EXTLAYERSDIR "${COREOS_ROOT}/external-layers"
+# the directory already exist, so it's safe to call it everytime
-
+coreos-keygen > /dev/null 2> /dev/null
-# 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

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

documentation/.vscode/settings.json

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

documentation/_static/css/coreos.css

@@ -1,6 +0,0 @@
-
-/* 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

@@ -1,101 +0,0 @@
-***************************
-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

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

documentation/best_practices/overview.rst

@@ -1,6 +0,0 @@
-************************
-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

@@ -1,9 +0,0 @@
-digraph G {
-    fw [label = "Firmware";shape = rect;];
-    
-    btl [label = "Bootloader";shape = rect;];
-    
-    os [label = "Operating System";shape = rect;];
-    
-    fw -> btl -> os;
-}

documentation/boot/bootflow-generic.plantuml

@@ -0,0 +1,23 @@
+@startuml
+!theme cloudscape-design
+start
+:**Firmware**;
+note right
+  Implement a subset of the UEFI specification
+  Usually implemented by u-boot
+end note
+:**Bootloader**
+efibootguard;
+note right
+  The bootloader is responsible to find and load the Operating System
+  It's an UEFI application that can be signed
+end note
+:**Operating System**
+Unified Kernel Image;
+note right
+  The Operating System is a single UEFI application that can be signed
+  This application has to call the ExitBootService UEFI protocol
+  This application contains at least the Linux Kernel
+end note
+end
+@enduml

documentation/boot/bootflow-uboot.dot

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

documentation/boot/disk.rst

@@ -0,0 +1,48 @@
+***********
+Disk Layout
+***********
+
+Standard Disk Layout
+====================
+
+
+
+Disk Layout using GPT
+======================
+
+Modern product use a GPT partionning disk with at least 5 partitions:
+
+- EFI
+- PLATFORM0
+- PLATFORM1
+- BOOT0
+- BOOT1
+
+Order and position of theses partitions doesn't matter as long as the
+right partition label, partition label and filesystem are used.
+
+.. image:: disk/disk-layout.png
+
+Partitions
+==========
+
+EFI
+---
+
+The EFI partition contains the bootloader (efibootguard).
+
+.. image:: disk/part-efi.png
+
+BOOT0 and BOOT1
+---------------
+
+The BOOT0 and BOOT1 partition contains a kernel and a configuration files.
+
+.. image:: disk/part-boot0.png
+
+PLATFORM0 and PLATFORM1
+-----------------------
+
+The PLATFORM0 and PLATFORM1 partitions contains a Linux root filesystem.
+
+.. image:: disk/part-platform0.png

documentation/boot/efibootguard.rst

@@ -0,0 +1,100 @@
+************************
+Bootloader: efibootguard
+************************
+
+Efibootguard is the default bootloader of CoreOS. It's an open source
+bootloader based on UEFI made by Siemens and released under GPLv2, that
+implement the A/B booting scheme.
+
+Efibootguard allow us to have a redondant boot partition that contain a
+configuration file for efibootguard and a signed Unified Kernel Image
+
+A/B Switch
+==========
+
+Two partition are used to store two diffrent configuration. The first partition
+is called boot0 and the second one boot1.
+
+At boot, efibootguard find the configuration file stored inside each boot
+partition and load it. Inside the configuration, the field "revision" is used
+to select the configuration to use to boot the board. It will be the one
+with the highest revision
+
+.. uml::
+
+    @startuml
+    !theme cloudscape-design
+    start
+    partition A/B selector {
+
+        :read boot0 configuration;
+        :read boot1 configuration;
+
+        if (boot0.revision > boot1.revision") then (yes)
+            :select boot0;
+        else (no)
+            :select boot1;
+        endif
+    }
+
+    end
+    @enduml
+
+State checking
+==============
+
+After having selecting the configuration to use, efibootguard will use the
+state field to determine is the configuration is already know to work or not.
+
+Theses states are possible:
+
+- ok: the configuration is known to be working
+- installed: the configuration was just updated and was never booted
+- testing: the configuration was just updated and was already booted once
+- failed: the configuration is not working
+
+.. uml::
+
+    @startuml
+    !theme cloudscape-design
+    start
+    partition state checking {
+        switch (state?)
+        case ( ok )
+            :set state to ok;
+        case ( installed ) 
+            :set state to testing;
+        case ( testing )
+            :set state to failed;
+            :set revision to 0;
+            :reboot;
+            stop
+        case ( failed )
+            :set revision to 0;
+            :reboot;
+            stop
+        endswitch
+    }
+    end
+    @enduml
+
+Image loading 
+==============
+
+The last part of the boot process just consist of reading kernel image
+from the selected boot partition and then calling the load_image EFI function
+to let the EFI firmware start the given image. The firmware will then first
+check the signature of the kernel before starting it.
+
+.. uml::
+
+    @startuml
+    !theme cloudscape-design
+    start
+    partition kernel loading {
+        : read unified kernel image from boot partition;
+        : load image to memory;
+    }
+    : call EFI load_image();
+    end
+    @enduml

documentation/boot/index.rst

@@ -11,4 +11,6 @@ Belden CoreOS Boot Concepts
 
    overview
    uboot
-   secure-boot
+   efibootguard
+   uki
+   disk

documentation/boot/overview.rst

@@ -13,8 +13,8 @@ In this document, the following terms have specific meanings:
 .. glossary::
 
     Firmware
-      Program that implement the boot and runtime services as defined by the
+      Program that implement some of the boot and runtime services defined by
-      :ext+uefi:ref:`UEFI specifications <maincontent>`.
+      the :ext+uefi:ref:`UEFI specifications <maincontent>`.
 
     Application
       Program written according to the UEFI specification that can be started 
@@ -25,17 +25,26 @@ In this document, the following terms have specific meanings:
       configuration or autodetection.
     
     Operating system
-      Application that include at least the Linux Kernel and the initial RAM
+      Application that include at least the Linux Kernel.
-      disk.
+    
+    Unified Kernel Image
+      Application that include the Linux kernel and the command line to pass to
+      the kernel and optionaly one or more device trees and a RAM disk
 
 
 Generic Boot Flow
 =================
 
-.. graphviz:: bootflow-generic.dot
+.. uml:: bootflow-generic.plantuml
+
+CoreOS use a standardized workflow based on UEFI: the firmware automatically
+start the bootloader. The bootloader is stored inside the EFI partition, under: 
+`/EFI/BOOT/BOOT<ARCH>.EFI` where `<ARCH>` is:
+
+- ARM for Arm32 CPU
+- A64 for Aarch64 CPU
+- X64 for Amd64 CPU
 
-CoreOS use a standardized workflow: the firmware can start either an
-optional bootloader or an operating system as an UEFI application.
 
 Firmware
 ========
@@ -63,11 +72,6 @@ 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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -75,10 +79,13 @@ 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.
+legacy like:
+
+- MBR partitionning instead of GPT
+- Fixed offsets to firmware data
 
 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.
 
@@ -86,12 +93,16 @@ ARM64 / AArch64 based machine
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The firmware for ARM64 should implement a subset of the UEFI specification, as
-defined by the EBBR Specification.
+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
 
 We require the firmware to provide a DeviceTree based system description and not
-an ACPI based table (as allowed by the specification). The DeviceTree provided
+an ACPI based table (as allowed by the specification)
-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.
 
@@ -104,13 +115,36 @@ The firmware for AMD64 should implement the UEFI specification.
 Bootloader
 ==========
 
-CoreOS only support `efibootguard` as bootloader. The usage of the bootloader
+CoreOS only support `efibootguard` as bootloader.
-is mandated.
 
 
 Operating system
 ================
 
-The operating system image is an UEFI application that contain the kernel. It's
+The operating system image is an UEFI application that contain the kernel.
-a Unified Kernel Image generated by tools from the EFIBootGuard project.
 
+Two ways can be used to generate this application:
+
+Kernel built with the built-in EFI stub
+---------------------------------------
+
+This method use the EFI stub provided by the kernel.
+
+
+Unified Kernel Images (UKI)
+---------------------------
+
+This is the most secure method. The UEFI entry point is provided by
+`efibootguard/stub` and the image contains the Linux Kernel with it's built-in
+EFI stub, the boot arguments of the kernel and optionaly multiple device trees
+and an initial RAM disk. 
+
+This allows to have all these part authenticated via UEFI secure boot just by
+signing the UKI.
+
+.. important::
+
+  Only the Unified Kernel Image methods is supported by the CoreOS teams. Using
+  the kernel directly should be used only for new hardware bring-up. By default
+  we only sign UKI to ensure that it's the only method used for hardware that
+  ship with secure boot enabled.

documentation/boot/secure-boot.rst

@@ -1,268 +0,0 @@
-*******************
-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.rst

@@ -1,6 +1,6 @@
-************************
+****************
-Using U-Boot as Firmware
+Firmware: U-Boot
-************************
+****************
 
 U-boot can be configured to support the EBBR specification. This can be
 enabled by enabling both `CONFIG_EFI_LOADER` and
@@ -21,10 +21,21 @@ to be changed at runtime.
 Device tree handling
 ====================
 
-As per the EBBR specification, the firmware is responsible to provide a
+As per the EBBR specification, the firmware is responsible to provide a basic
-device tree to the kernel. Not that it's OK to export the device tree used by
+device tree to the kernel.
-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.
+This means that we have to build u-boot with an embedded device tree. On a
+machine configuration, this mean settings the `UBOOT_BUILDENV_DEVICE_TREE`
+variables.
+
+The kernel can then override the built-in device-tree to use another.
+
+.. important::
+
+   The `compatible` field of the device-tree embedded inside `u-boot` has to
+   match with the one used inside the kernel. This allow us to automatically
+   load the right `device-tree` inside the unified kernel image (UKI).
+
 
 Features to implement per machine
 =================================
@@ -32,15 +43,12 @@ Features to implement per machine
 The u-boot provided by CoreOS should implement the following features for each
 supported machine:
 
-extension_board_scan
---------------------
-
-The extension_board_scan function has to be implemented. This function should
-return the list of add-ons board detected.
-
 DT Fixup
 --------
 
-U-Boot can create, modify and remove node from the device tree dynamically
+An EFI application like a UKI can overwrite the built-in device tree with a
-before starting the kernel. This can be used to pass dynamic information stored
+custom one. The DT Fixup Protocol allow an application to ask the firmware to
-inside a "board descriptor" eeprom or CPLD to the Kernel.
+some runtime fix to the new device tree, like enabling or removing node.
+
+This can be used to pass dynamic information stored inside a "board descriptor"
+eeprom or CPLD to the Kernel.

documentation/boot/uki.rst

@@ -0,0 +1,4 @@
+******************************
+OS: Unified Kernel Image (UKI)
+******************************
+

documentation/components/core/efibootguard.rst

@@ -1,104 +0,0 @@
-.. 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

@@ -1,15 +0,0 @@
-
-======================
-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

@@ -1,27 +0,0 @@
-.. 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

@@ -1,7 +0,0 @@
-.. 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

@@ -1,46 +0,0 @@
-.. 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

@@ -1,15 +0,0 @@
-
-==========================
-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

@@ -1,37 +0,0 @@
-.. 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

@@ -1,10 +0,0 @@
-.. 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

@@ -1,9 +0,0 @@
-.. 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

@@ -1,9 +0,0 @@
-.. 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

@@ -42,8 +42,8 @@ extensions = [
     'sphinx.ext.intersphinx',
     'sphinx.ext.todo',
     'sphinx.ext.graphviz',
+    'sphinxcontrib.plantuml',
 ]
-#    'sphinxcontrib.plantuml',
 
 
 # external links and substitutions
@@ -112,10 +112,6 @@ 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

@@ -1,61 +0,0 @@
-..  _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

@@ -1,126 +0,0 @@
-..  _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

@@ -1,33 +0,0 @@
-******************
-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,30 +26,12 @@ 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

@@ -1,22 +0,0 @@
-
-.. _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

@@ -1,50 +0,0 @@
-************
-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

@@ -1,64 +0,0 @@
-**********************
-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,8 +46,7 @@ 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 sbsigntool python3-click \
+      liblz4-tool bmap-tools efitools openssl sbsign
-      python3-aiohttp
 
 Use Git to clone CoreOS
 ########################
@@ -100,11 +99,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-all-features`.
+is `coreos-image-full-cmdline`.
 
 .. code-block:: sh
 
-   ~/img-build/build$ bitbake coreos-image-all-features
+   ~/img-build/build$ bitbake coreos-image-full-cmdline
 
 After a long time, the build system will return. You can list all the artifacts
 produced by `bitbake` using `ls`:
@@ -119,7 +118,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-all-features-cn9130-cf-pro.wic.xz
+   tmp/deploy/images/cn9130-cf-pro/coreos-image-full-cmdline-cn9130-cf-pro.wic.xz
 
 .. hint::
 
@@ -167,6 +166,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-all-features-cn9130-cf-pro.wic.xz /dev/<DISKNAME>
+   ~/coreos/build$ bmaptool copy tmp/deploy/images/cn9130-cf-pro/coreos-image-full-cmdline-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

@@ -6,14 +6,33 @@ This chapter document the classes that are provided by Belden CoreOS. Classes
 provided by OpenEmbedded-Core are documented in the
 :external:doc:`Yocto Reference Manual <ref-manual/classes>`.
 
+.. _ref-classes-coreos-container-image:
+.. index:: coreos-container-image.bbclass
+
+``coreos-container-image.bbclass``
+==================================
+
+The ``coreos-container-image`` class provides common definitions to create
+a container image.
+:extern:ref:`IMAGE_FEATURE <ref-features-image>`.
+
+.. _ref-classes-coreos-container-package:
+.. index:: coreos-container-package.bbclass
+
+``coreos-container-image.bbclass``
+==================================
+
+The ``coreos-container-package`` class provides common definitions to create
+a package a container image. This allow a container image to be preinstalled
+into a standard image. 
+
 .. _ref-classes-coreos-efi-secureboot:
 .. index:: coreos-efi-secureboot.bbclass
 
-
 ``coreos-efi-secureboot.bbclass``
 =================================
 
-The ``coreos-efi-secureboot`` class is a class made to be inherited in a global
+The ``coreos-efi-secureboot`` class is a class made to be ihnerited 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,14 +10,9 @@ 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 with CoreOS.
+can be used.
-
-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
 
@@ -51,7 +46,8 @@ The *cockpit* and *dev-tools* feature are special, as they will automatically
 add package based on the other image feature that are enabled.
 
 :external:ref:`IMAGE_FEATURES <ref-features-image>` defined in OpenEmbedded-Core
-are also available, but note that the
+are also available, but note that neither the
-:ref:`coreos-image <ref-classes-coreos-image>` class don't inherit from the
+:ref:`coreos-image <ref-classes-coreos-image>` class and the
+:ref:`coreos-image <ref-classes-coreos-container-image>` inherit from the
 :external:ref:`core-image <ref-classes-core-image>` class, thus `core-image`
 specific features are not available.

documentation/ref-manual/images.rst

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

documentation/testing/bats.rst

@@ -1,354 +0,0 @@
-.. 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

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

external-layers/meta-arm

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

external-layers/meta-efibootguard

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

external-layers/meta-lts-kernel-mixin

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

external-layers/meta-openembedded

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

external-layers/meta-swupdate

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

external-layers/meta-ti

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

external-layers/meta-virtualization

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

external-layers/openembedded-core

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

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

@@ -3,7 +3,7 @@
 # UEFI Secure boot configuration
 # ==============================================================================
 
-COREOS_EFI_SECUREBOOT_KEYDIR ??= "${RECIPE_SYSROOT_NATIVE}/${datadir}/keys"
+COREOS_EFI_SECUREBOOT_KEYDIR ??= "${TOPDIR}/keys"
 COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR ??= "0"
 
 # UEFI Secure boot helpers
@@ -16,19 +16,40 @@ HOSTTOOLS += "sbsign"
 
 # Ensure that the public keys are always deployed to the deploy directory
 # before running wic
-do_image_wic[depends] += "cos-certificates-and-keys-native:do_deploy"
+do_image_wic[depends] += "efi-secureboot-keys:do_deploy"
+
 
-COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR ??= "0"
 def get_coreos_secureboot_efi_boot_files(d):
     """
         Return the list of pubkey file inside deploy if 
         COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR is set or an empty string
         otherwise
     """
-    if d.getVar('COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR') == '1':
+    if d.getVar('COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR', True):
         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

@@ -1,26 +0,0 @@
-
-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,14 +5,12 @@
 MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"
 EXTRA_IMAGEDEPENDS += "virtual/bootloader"
 
-
 DEFAULTTUNE ?= "cortexa8hf-neon"
 include conf/machine/include/arm/armv7a/tune-cortexa8.inc
 
 IMAGE_FSTYPES += "wic wic.xz wic.bmap"
 WKS_FILE ?= "beaglebone-sdcard.wks.in"
-COREOS_INSTALLER_WKS_FILE ?= "beaglebone-sdcard-installer.wks"
+MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"
-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"
 
@@ -21,10 +19,10 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
 APPEND:append = " console=ttyS0,115200"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "6.6%"
+PREFERRED_VERSION_linux-yocto ?= "5.15%"
 
 KERNEL_IMAGETYPE = "zImage"
-DTB_FILES = "ti/omap/am335x-bone.dtb ti/omap/am335x-boneblack.dtb ti/omap/am335x-bonegreen.dtb"
+KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
 KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
 
 PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
@@ -37,6 +35,9 @@ UBOOT_LOADADDRESS = "0x80008000"
 
 MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
 
+IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY}"
+IMAGE_EFI_BOOT_FILES ?= "${KERNEL_DEVICETREE}"
+
 # support runqemu
 EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
 IMAGE_CLASSES += "qemuboot"
@@ -57,7 +58,5 @@ QB_TCPSERIAL_OPT = "-device virtio-serial-device -chardev socket,id=virtcon,port
 # 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
+require conf/machine/include/coreos-generic-features/legacy-mbr-disk.inc

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

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

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

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

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

@@ -0,0 +1,15 @@
+
+# MBR disk are still supported by CoreOS, but only for legacy product
+# This ensure that efibootguard / swupdate work with MBR disk
+
+# Do not include this file in a machine configuration if the machine support
+# a GPT disk instead
+COREOS_DISK_PARTLABEL_LOOKUP_DIRECTORY ?= "/dev/disk/by-label"
+
+COREOS_PLATFORM0_ROOT ?= "LABEL=platform0"
+COREOS_PLATFORM1_ROOT ?= "LABEL=platform1"
+
+# MBR disk can't use --part-type but can use system-id 
+WKS_PART_EFI ?= 'part --source efibootguard-efi --label efi --system-id 0xef'
+WKS_PART_EFIBOOTGUARD_A ?= 'part --source efibootguard-boot --label boot0  --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=kernel0-${MACHINE}.efi;KERNEL0.EFI"'
+WKS_PART_EFIBOOTGUARD_B ?=  'part --source efibootguard-boot --label boot1 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=kernel1-${MACHINE}.efi;KERNEL1.EFI"'

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

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

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

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

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

@@ -1,15 +0,0 @@
-#@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,6 +7,3 @@ 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

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

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

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

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

@@ -1,23 +1,12 @@
-# Ensure that file are found event when this file is included in another layer
-# ==============================================================================
-FILESEXTRAPATHS:prepend := "${THISDIR}/u-boot:"
-
-# U-Boot CoreOS Distro Settings
-# ==============================================================================
-
-# Enable more debug option when debug-tweaks is enabled
-SRC_URI += " \
-    ${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "file://debug-tweaks.cfg", "", d)} \
-"
-
 inherit coreos-efi-secureboot
 
-# Make sure UEFI and secure boot is enabled for every u-boot build
 SRC_URI += " \
     file://uefi.cfg \
     file://uefi-secureboot.cfg \
 "
 
+DEPENDS:append = " ${PYTHON_PN}-pyopenssl-native u-boot-tools-native"
+
 # Generate a ubootefi.var file inside the build directory
 #
 # This file can be directly linked inside the u-boot binary to provide
@@ -26,7 +15,6 @@ SRC_URI += " \
 #
 # The efivar.py is taken from u-boot-tools recipes, so that we are sure that he
 # is found and don't depend on the u-boot version being used
-DEPENDS:append = " ${PYTHON_PN}-pyopenssl-native u-boot-tools-native cos-certificates-and-keys-native"
 addtask uboot_generate_efivar after do_configure before do_compile
 do_uboot_generate_efivar() {
     # Settings OPENSSL_MODULES is needed, otherwise efivar.py fail with

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

@@ -0,0 +1,12 @@
+# 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-tools_2022.01.bbappend

@@ -5,5 +5,3 @@
 do_install:append() {
 	install -m 0755 ${S}/tools/efivar.py ${D}${bindir}/uboot-efivar
 }
-
-FILES:${PN} += "${bindir}/uboot-efivar"

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

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

layers/meta-belden-coreos-bsp/recipes-bsp/u-boot/u-boot_2022.10.bb

@@ -4,3 +4,5 @@ require recipes-bsp/u-boot/u-boot.inc
 SRCREV = "4debc57a3da6c3f4d3f89a637e99206f4cea0a96"
 DEPENDS += "bc-native dtc-native python3-setuptools-native"
 LIC_FILES_CHKSUM = "file://Licenses/README;md5=2ca5f2c35c8cc335f0a19756634782f1"
+
+require u-boot-coreos.inc

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

@@ -1,19 +0,0 @@
-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

@@ -1,13 +0,0 @@
-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

@@ -1,4 +0,0 @@
-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

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

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

@@ -1,16 +0,0 @@
-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

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

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

@@ -1,20 +1,13 @@
-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

@@ -1,14 +0,0 @@
-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

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

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

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

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

@@ -1,16 +0,0 @@
-# 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,11 +1,10 @@
 # short-description: Create an EFI disk image for genericx86*
 # long-description: Creates a partitioned EFI disk image for genericx86* machines
+${WKS_PART_EFI} --ondisk sda  --align 1024 --fixed-size 32
+${WKS_PART_ROOT_A} --ondisk sda --fixed-size 2G
+${WKS_PART_ROOT_B} --ondisk sda --fixed-size 2G
+${WKS_PART_EFIBOOTGUARD_A} --ondisk sda  --align 1024 --fixed-size 32
+${WKS_PART_EFIBOOTGUARD_B} --ondisk sda  --align 1024 --fixed-size 32
 
-${WKS_PART_EFI} --align 1024 --size ${PART_EFI_SIZE} --extra-space 0 --overhead-factor 1
+part swap --ondisk sda --size 44 --label swap1 --fstype=swap
-${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

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

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

@@ -1,8 +0,0 @@
-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

@@ -1,7 +0,0 @@
-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

@@ -1,44 +0,0 @@
-# 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

@@ -1,15 +0,0 @@
-# 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

@@ -1,17 +0,0 @@
-# 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)