7 files changed, 268 insertions, 144 deletions

diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 54a98bf24f..f2f6e6e411 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -1732,77 +1732,158 @@ Its behavior is mainly controlled by the following variables:
 -  :term:`KERNEL_DTC_FLAGS`: flags for ``dtc``, the Device Tree Compiler
 -  :term:`KERNEL_PACKAGE_NAME`: base name of the kernel packages
 
-.. _ref-classes-kernel-fitimage:
+.. _ref-classes-kernel-fit-image:
 
-``kernel-fitimage``
-===================
+``kernel-fit-image``
+====================
 
-The :ref:`ref-classes-kernel-fitimage` class provides support to pack a kernel image,
-device trees, a U-boot script, an :term:`Initramfs` bundle and a RAM disk
-into a single FIT image. In theory, a FIT image can support any number
-of kernels, U-boot scripts, :term:`Initramfs` bundles, RAM disks and device-trees.
-However, :ref:`ref-classes-kernel-fitimage` currently only supports
+The :ref:`ref-classes-kernel-fit-image` class provides support to pack a kernel image,
+device trees, a U-boot script, and an :term:`Initramfs` into a single FIT image.
+In theory, a FIT image can support any number of kernels, U-boot scripts,
+:term:`Initramfs`, and device trees.
+However, :ref:`ref-classes-kernel-fit-image` currently only supports
 limited usecases: just one kernel image, an optional U-boot script,
-an optional :term:`Initramfs` bundle, an optional RAM disk, and any number of
-device trees.
-
-To create a FIT image, it is required that :term:`KERNEL_CLASSES`
-is set to include ":ref:`ref-classes-kernel-fitimage`" and one of :term:`KERNEL_IMAGETYPE`,
-:term:`KERNEL_ALT_IMAGETYPE` or :term:`KERNEL_IMAGETYPES` to include "fitImage".
-
-The options for the device tree compiler passed to ``mkimage -D``
-when creating the FIT image are specified using the
-:term:`UBOOT_MKIMAGE_DTCOPTS` variable.
-
-Only a single kernel can be added to the FIT image created by
-:ref:`ref-classes-kernel-fitimage` and the kernel image in FIT is mandatory. The
-address where the kernel image is to be loaded by U-Boot is
-specified by :term:`UBOOT_LOADADDRESS` and the entrypoint by
-:term:`UBOOT_ENTRYPOINT`. Setting :term:`FIT_ADDRESS_CELLS` to "2"
-is necessary if such addresses are 64 bit ones.
-
-Multiple device trees can be added to the FIT image created by
-:ref:`ref-classes-kernel-fitimage` and the device tree is optional.
-The address where the device tree is to be loaded by U-Boot is
-specified by :term:`UBOOT_DTBO_LOADADDRESS` for device tree overlays
-and by :term:`UBOOT_DTB_LOADADDRESS` for device tree binaries.
-
-Only a single RAM disk can be added to the FIT image created by
-:ref:`ref-classes-kernel-fitimage` and the RAM disk in FIT is optional.
-The address where the RAM disk image is to be loaded by U-Boot
-is specified by :term:`UBOOT_RD_LOADADDRESS` and the entrypoint by
-:term:`UBOOT_RD_ENTRYPOINT`. The ramdisk is added to the FIT image when
-:term:`INITRAMFS_IMAGE` is specified and requires that :term:`INITRAMFS_IMAGE_BUNDLE`
-is not set to 1.
-
-Only a single :term:`Initramfs` bundle can be added to the FIT image created by
-:ref:`ref-classes-kernel-fitimage` and the :term:`Initramfs` bundle in FIT is optional.
-In case of :term:`Initramfs`, the kernel is configured to be bundled with the root filesystem
-in the same binary (example: zImage-initramfs-:term:`MACHINE`.bin).
-When the kernel is copied to RAM and executed, it unpacks the :term:`Initramfs` root filesystem.
-The :term:`Initramfs` bundle can be enabled when :term:`INITRAMFS_IMAGE`
-is specified and requires that :term:`INITRAMFS_IMAGE_BUNDLE` is set to 1.
-The address where the :term:`Initramfs` bundle is to be loaded by U-boot is specified
-by :term:`UBOOT_LOADADDRESS` and the entrypoint by :term:`UBOOT_ENTRYPOINT`.
-
-Only a single U-boot boot script can be added to the FIT image created by
-:ref:`ref-classes-kernel-fitimage` and the boot script is optional.
-The boot script is specified in the ITS file as a text file containing
-U-boot commands. When using a boot script the user should configure the
-U-boot :ref:`ref-tasks-install` task to copy the script to sysroot.
-So the script can be included in the FIT image by the :ref:`ref-classes-kernel-fitimage`
-class. At run-time, U-boot CONFIG_BOOTCOMMAND define can be configured to
-load the boot script from the FIT image and execute it.
-
-The FIT image generated by the :ref:`ref-classes-kernel-fitimage` class is signed when the
-variables :term:`UBOOT_SIGN_ENABLE`, :term:`UBOOT_MKIMAGE_DTCOPTS`,
-:term:`UBOOT_SIGN_KEYDIR` and :term:`UBOOT_SIGN_KEYNAME` are set
-appropriately. The default values used for :term:`FIT_HASH_ALG` and
-:term:`FIT_SIGN_ALG` in :ref:`ref-classes-kernel-fitimage` are "sha256" and
-"rsa2048" respectively. The keys for signing the FIT image can be generated using
-the :ref:`ref-classes-kernel-fitimage` class when both :term:`FIT_GENERATE_KEYS` and
-:term:`UBOOT_SIGN_ENABLE` are set to "1".
-
+an optional :term:`Initramfs`, and any number of device trees.
+
+The FIT image is created by a recipe which inherits the
+:ref:`ref-classes-kernel-fit-image` class.
+One such example is the ``linux-yocto-fitimage`` recipe which creates a FIT
+image for the Linux Yocto kernel.
+Additionally, it is required that :term:`KERNEL_CLASSES` is set to include
+:ref:`ref-classes-kernel-fit-extra-artifacts`.
+The :ref:`ref-classes-kernel-fit-extra-artifacts` class exposes the required kernel
+artifacts to the :term:`DEPLOY_DIR_IMAGE` which are used by the
+:ref:`ref-classes-kernel-fit-image` class to create the FIT image.
+
+The simplest example for building a FIT image is to add::
+
+   KERNEL_CLASSES += "kernel-fit-extra-artifacts"
+
+to the machine :term:`configuration file` and to execute::
+
+   bitbake linux-yocto-fitimage
+
+This results in a ``fitImage`` file deployed to the :term:`DEPLOY_DIR_IMAGE`
+directory and a ``linux-yocto-fitimage`` package which can be installed.
+
+The same approach works for all variants of the ``linux-yocto`` kernel.
+For example, if the ``linux-yocto-rt`` kernel should be used, add the following
+lines to the machine configuration file::
+
+   KERNEL_CLASSES += "kernel-fit-extra-artifacts"
+   PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
+
+The FIT image, this time including the RT kernel, is built again by calling::
+
+   bitbake linux-yocto-fitimage
+
+For other kernels provided by other layers, the same approach would work.
+However, it is usually more intuitive to add a custom FIT image recipe next to
+the custom kernel recipe.
+For example, if a layer provides a ``linux-vanilla`` recipe, a
+``linux-vanilla-fitimage`` recipe may be added as well.
+The ``linux-vanilla-fitimage`` recipe can be created as a customized copy of
+the ``linux-yocto-fitimage`` recipe.
+
+Usually the kernel is built as a dependency of an image.
+If the FIT image should be used as a replacement for the kernel image which
+is installed in the root filesystem, then the following variables can be set
+e.g. in the machine configuration file::
+
+   # Create and deploy the vmlinux artifact which gets included into the FIT image
+   KERNEL_CLASSES += "kernel-fit-extra-artifacts"
+
+   # Do not install the kernel image package
+   RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""
+   # Install the FIT image package
+   MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "linux-yocto-fitimage"
+
+   # Configure the image.bbclass to depend on the FIT image instead of only
+   # the kernel to ensure the FIT image is built and deployed with the image
+   KERNEL_DEPLOY_DEPEND = "linux-yocto-fitimage:do_deploy"
+
+The :ref:`ref-classes-kernel-fit-image` class processes several variables that
+allow configuration:
+
+-  The options for the device tree compiler passed to ``mkimage -D``
+   when creating the FIT image are specified using the
+   :term:`UBOOT_MKIMAGE_DTCOPTS` variable.
+
+-  Only a single kernel can be added to the FIT image created by
+   :ref:`ref-classes-kernel-fit-image` and it is a mandatory component of the
+   FIT image.
+   The address where the kernel image is to be loaded by U-Boot is
+   specified by :term:`UBOOT_LOADADDRESS` and the entrypoint by
+   :term:`UBOOT_ENTRYPOINT`. Setting :term:`FIT_ADDRESS_CELLS` to "2"
+   is necessary if such addresses are 64 bit ones.
+
+-  Multiple device trees can be added to the FIT image created by
+   :ref:`ref-classes-kernel-fit-image` and the device tree is optional.
+   The address where the device tree is to be loaded by U-Boot is
+   specified by :term:`UBOOT_DTBO_LOADADDRESS` for device tree overlays
+   and by :term:`UBOOT_DTB_LOADADDRESS` for device tree binaries.
+
+-  Only a single :term:`Initramfs` can be added to the FIT image created by
+   :ref:`ref-classes-kernel-fit-image`. The :term:`Initramfs` in FIT is optional.
+   The address where the RAM disk image is to be loaded by U-Boot
+   is specified by :term:`UBOOT_RD_LOADADDRESS` and the entrypoint by
+   :term:`UBOOT_RD_ENTRYPOINT`. The :term:`Initramfs` is added to the FIT image
+   when :term:`INITRAMFS_IMAGE` is specified.
+
+-  It's recommended to add the :term:`Initramfs` and the kernel image as
+   independent image nodes to the FIT image.
+   Bundling a RAM disk image with the kernel image and including the bundle
+   (:term:`INITRAMFS_IMAGE_BUNDLE` set to "1") in the FIT image is possible.
+   However, this approach has the disadvantage that any change to the RAM
+   disk image necessitates rebuilding the kernel image.
+   This process requires the full kernel build directory, which is kind of
+   incompatible with the :term:`SSTATE_DIR` and, consequently, with SDKs.
+
+-  Only a single U-Boot boot script can be added to the FIT image created by
+   :ref:`ref-classes-kernel-fit-image`. The boot script is optional.
+   The boot script is specified in the ITS file as a text file containing
+   U-Boot commands. When using a boot script the recipe which inherits the
+   :ref:`ref-classes-kernel-fit-image` class should add the script to
+   :term:`SRC_URI` and set the :term:`FIT_UBOOT_ENV` variable to the name of the
+   file like the following::
+
+      FIT_UBOOT_ENV = "boot.txt"
+      SRC_URI += "file://${FIT_UBOOT_ENV}"
+
+   At run-time, U-boot's boot command can be configured to load the boot script
+   from the FIT image and source it.
+
+-  The FIT image generated by the :ref:`ref-classes-kernel-fit-image` class is signed when the
+   variables :term:`UBOOT_SIGN_ENABLE`, :term:`UBOOT_MKIMAGE_DTCOPTS`,
+   :term:`UBOOT_SIGN_KEYDIR` and :term:`UBOOT_SIGN_KEYNAME` are set
+   appropriately. The default values used for :term:`FIT_HASH_ALG` and
+   :term:`FIT_SIGN_ALG` in :ref:`ref-classes-kernel-fit-image` are "sha256" and
+   "rsa2048" respectively. The keys for signing the FIT image can be generated using
+   the :ref:`ref-classes-kernel-fit-image` class when both :term:`FIT_GENERATE_KEYS` and
+   :term:`UBOOT_SIGN_ENABLE` are set to "1".
+
+.. _ref-classes-kernel-fit-extra-artifacts:
+
+``kernel-fit-extra-artifacts``
+==============================
+
+The :ref:`ref-classes-kernel-fit-extra-artifacts` class exposes the required
+kernel artifacts to the :term:`DEPLOY_DIR_IMAGE` directory.
+These artifacts are used by the :ref:`ref-classes-kernel-fit-image` class to
+create a FIT image that can include the kernel, device trees, an optional
+U-Boot script, and an optional Initramfs.
+
+This class is typically included by adding it to the :term:`KERNEL_CLASSES`
+variable in your kernel recipe or machine configuration when building FIT images.
+It ensures that all necessary files are available for packaging into the FIT image,
+such as the kernel binary, device tree blobs (DTBs), and other related files.
+
+For example, to enable this class, set::
+
+   KERNEL_CLASSES += "kernel-fit-extra-artifacts"
+
+This is required when using the :ref:`ref-classes-kernel-fit-image` class to
+generate FIT images for your kernel.
 
 .. _ref-classes-kernel-grub:
 
@@ -2050,7 +2131,8 @@ a couple different ways:
       Not using this naming convention can lead to subtle problems
       caused by existing code that depends on that naming convention.
 
--  Create or modify a target recipe that contains the following::
+-  Or, create a :ref:`ref-classes-native` variant of any target recipe (e.g.
+   ``myrecipe.bb``) by adding the following to the recipe::
 
       BBCLASSEXTEND = "native"
 
@@ -2081,24 +2163,25 @@ couple different ways:
    inherit statement in the recipe after all other inherit statements so
    that the :ref:`ref-classes-nativesdk` class is inherited last.
 
--  Create a :ref:`ref-classes-nativesdk` variant of any recipe by adding the following::
+   .. note::
 
-       BBCLASSEXTEND = "nativesdk"
+      When creating a recipe, you must follow this naming convention::
 
-   Inside the
-   recipe, use ``:class-nativesdk`` and ``:class-target`` overrides to
-   specify any functionality specific to the respective SDK machine or
-   target case.
+              nativesdk-myrecipe.bb
 
-.. note::
 
-   When creating a recipe, you must follow this naming convention::
+      Not doing so can lead to subtle problems because there is code that
+      depends on the naming convention.
 
-           nativesdk-myrecipe.bb
+-  Or, create a :ref:`ref-classes-nativesdk` variant of any target recipe (e.g.
+   ``myrecipe.bb``) by adding the following to the recipe::
 
+       BBCLASSEXTEND = "nativesdk"
 
-   Not doing so can lead to subtle problems because there is code that
-   depends on the naming convention.
+   Inside the
+   recipe, use ``:class-nativesdk`` and ``:class-target`` overrides to
+   specify any functionality specific to the respective SDK machine or
+   target case.
 
 Although applied differently, the :ref:`ref-classes-nativesdk` class is used with both
 methods. The advantage of the second method is that you do not need to
@@ -3436,7 +3519,7 @@ See U-Boot's documentation for details about `verified boot
 and the `signature process
 <https://source.denx.de/u-boot/u-boot/-/blob/master/doc/uImage.FIT/signature.txt>`__.
 
-See also the description of :ref:`ref-classes-kernel-fitimage` class, which this class
+See also the description of :ref:`ref-classes-kernel-fit-image` class, which this class
 imitates.
 
 .. _ref-classes-uki:
diff --git a/documentation/ref-manual/resources.rst b/documentation/ref-manual/resources.rst
index 4eaaca942e..bcbc7ebaca 100644
--- a/documentation/ref-manual/resources.rst
+++ b/documentation/ref-manual/resources.rst
@@ -23,7 +23,7 @@ The Yocto Project gladly accepts contributions. You can submit changes
 to the project either by creating and sending pull requests, or by
 submitting patches through email. For information on how to do both as
 well as information on how to identify the maintainer for each area of
-code, see the :doc:`../contributor-guide/index`.
+code, see the :doc:`/contributor-guide/index`.
 
 .. _resources-bugtracker:
 
@@ -45,7 +45,7 @@ your expectations).
 For a general procedure and guidelines on how to use Bugzilla to submit a bug
 against the Yocto Project, see the following:
 
--  The ":doc:`../contributor-guide/report-defect`"
+-  The ":doc:`/contributor-guide/report-defect`"
    section in the Yocto Project and OpenEmbedded Contributor Guide.
 
 -  The Yocto Project :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
diff --git a/documentation/ref-manual/structure.rst b/documentation/ref-manual/structure.rst
index 2190f5b90e..d6dbb29401 100644
--- a/documentation/ref-manual/structure.rst
+++ b/documentation/ref-manual/structure.rst
@@ -611,7 +611,7 @@ example, consider ``linux-yocto-kernel-3.0`` on the machine ``qemux86``
 built within the Yocto Project. For this package, a work directory of
 ``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred
 to as the :term:`WORKDIR`, is created. Within this directory, the source is
-unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt.
+unpacked to ``sources/linux-qemux86-standard-build`` and then patched by Quilt.
 (See the ":ref:`dev-manual/quilt:using quilt in your workflow`" section in
 the Yocto Project Development Tasks Manual for more information.) Within
 the ``linux-qemux86-standard-build`` directory, standard Quilt
diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst
index b64a13320a..14b635013b 100644
--- a/documentation/ref-manual/system-requirements.rst
+++ b/documentation/ref-manual/system-requirements.rst
@@ -145,7 +145,7 @@ tested on former revisions of "&DISTRO_NAME;", but no longer are:
       interested in hearing about your experience. For information on
       how to submit a bug, see the Yocto Project
       :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
-      and the ":doc:`../contributor-guide/report-defect`"
+      and the ":doc:`/contributor-guide/report-defect`"
       section in the Yocto Project and OpenEmbedded Contributor Guide.
 
 Required Packages for the Build Host
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index d85d1151f0..e379c424d8 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -412,8 +412,7 @@ them. You can learn more by looking at the
 -------------
 
 Unpacks the source code into a working directory pointed to by
-``${``\ :term:`UNPACKDIR`\ ``}``. A legacy way to specify
-this directory is through the :term:`S` and :term:`WORKDIR` variables.
+``${``\ :term:`UNPACKDIR`\ ``}``.
 For more information on how source files are unpacked, see the
 ":ref:`overview-manual/concepts:source fetching`"
 section in the Yocto Project Overview and Concepts Manual.
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 5c18b852d1..c56418e2a2 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -265,7 +265,7 @@ system and gives an overview of their function and contents.
       build process. By default, this directory is the same as the
       :term:`S` directory, which is defined as::
 
-         S = "${WORKDIR}/${BP}"
+         S = "${UNPACKDIR}/${BP}"
 
       You can separate the (:term:`S`) directory and the directory pointed to
       by the :term:`B` variable. Most Autotools-based recipes support
@@ -560,6 +560,13 @@ system and gives an overview of their function and contents.
    :term:`BB_GENERATE_SHALLOW_TARBALLS`
       See :term:`bitbake:BB_GENERATE_SHALLOW_TARBALLS` in the BitBake manual.
 
+   :term:`BB_GIT_DEFAULT_DESTSUFFIX`
+      See :term:`bitbake:BB_GIT_DEFAULT_DESTSUFFIX` in the BitBake manual.
+
+      In :term:`OpenEmbedded-Core (OE-Core)`, this variable is set to
+      :term:`BP` by default in :oe_git:`bitbake.conf
+      </openembedded-core/tree/meta/conf/bitbake.conf>`.
+
    :term:`BB_GIT_SHALLOW`
       See :term:`bitbake:BB_GIT_SHALLOW` in the BitBake manual.
 
@@ -2576,7 +2583,7 @@ system and gives an overview of their function and contents.
       You can safely share this directory between multiple builds on the
       same development machine. For additional information on how the build
       process gets source files when working behind a firewall or proxy
-      server, see this specific question in the ":doc:`faq`"
+      server, see this specific question in the ":doc:`/ref-manual/faq`"
       chapter. You can also refer to the
       ":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
       Wiki page.
@@ -2790,7 +2797,7 @@ system and gives an overview of their function and contents.
       ``meta/classes-recipe`` to see how the variable is used.
 
    :term:`EXTERNAL_KERNEL_DEVICETREE`
-      When inheriting :ref:`ref-classes-kernel-fitimage` and a
+      When inheriting :ref:`ref-classes-kernel-fit-image` and a
       :term:`PREFERRED_PROVIDER` for ``virtual/dtb`` set to ``devicetree``, the
       variable :term:`EXTERNAL_KERNEL_DEVICETREE` can be used to specify a
       directory containing one or more compiled device tree or device tree
@@ -3318,7 +3325,7 @@ system and gives an overview of their function and contents.
       Specifies the value of the ``#address-cells`` value for the
       description of the FIT image.
 
-      The default value is set to "1" by the :ref:`ref-classes-kernel-fitimage`
+      The default value is set to "1" by the :ref:`ref-classes-kernel-fit-image`
       class, which corresponds to 32 bit addresses.
 
       For platforms that need to set 64 bit addresses, for example in
@@ -3337,11 +3344,11 @@ system and gives an overview of their function and contents.
       Specifies the default device tree binary (dtb) file for a FIT image
       when multiple ones are provided.
 
-      This variable is used in the :ref:`ref-classes-kernel-fitimage` class.
+      This variable is used in the :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_DESC`
       Specifies the description string encoded into a FIT image. The
-      default value is set by the :ref:`ref-classes-kernel-fitimage` class as
+      default value is set by the :ref:`ref-classes-kernel-fit-image` class as
       follows::
 
          FIT_DESC ?= "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}"
@@ -3350,12 +3357,12 @@ system and gives an overview of their function and contents.
       Decides whether to generate the keys for signing the FIT image if
       they don't already exist. The keys are created in
       :term:`UBOOT_SIGN_KEYDIR`. The default value is set to "0"
-      by the :ref:`ref-classes-kernel-fitimage` class.
+      by the :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_HASH_ALG`
       Specifies the hash algorithm used in creating the FIT Image.
       This variable is set by default to "sha256" by the
-      :ref:`ref-classes-kernel-fitimage` class.
+      :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_KERNEL_COMP_ALG`
       The compression algorithm to use for the kernel image inside the FIT Image.
@@ -3374,31 +3381,31 @@ system and gives an overview of their function and contents.
    :term:`FIT_KEY_GENRSA_ARGS`
       Arguments to ``openssl genrsa`` for generating a RSA private key for
       signing the FIT image. The default value is set to "-F4" by the
-      :ref:`ref-classes-kernel-fitimage` class.
+      :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_KEY_REQ_ARGS`
       Arguments to ``openssl req`` for generating a certificate for signing
       the FIT image. The default value is "-batch -new" by the
-      :ref:`ref-classes-kernel-fitimage` class, "batch" for
+      :ref:`ref-classes-kernel-fit-image` class, "batch" for
       non interactive mode and "new" for generating new keys.
 
    :term:`FIT_KEY_SIGN_PKCS`
       Format for the public key certificate used for signing the FIT image.
       The default value is set to "x509" by the
-      :ref:`ref-classes-kernel-fitimage` class.
+      :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_SIGN_ALG`
       Specifies the signature algorithm used in creating the FIT Image.
       This variable is set by default to "rsa2048" by the
-      :ref:`ref-classes-kernel-fitimage` class.
+      :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_PAD_ALG`
       Specifies the padding algorithm used in creating the FIT Image.
       The default value is set to "pkcs-1.5" by the
-      :ref:`ref-classes-kernel-fitimage` class.
+      :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_SIGN_INDIVIDUAL`
-      If set to "1", the :ref:`ref-classes-kernel-fitimage` class signs each
+      If set to "1", the :ref:`ref-classes-kernel-fit-image` class signs each
       image node individually, including the kernel, DTB, RAM disk, and any
       other image types present in the FIT image, in addition to signing the
       configuration nodes.
@@ -3431,13 +3438,13 @@ system and gives an overview of their function and contents.
    :term:`FIT_SIGN_NUMBITS`
       Size of the private key used in the FIT image, in number of bits.
       The default value for this variable is set to "2048"
-      by the :ref:`ref-classes-kernel-fitimage` class.
+      by the :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_UBOOT_ENV`
       This variable allows to add a U-Boot script as a text file to the
       FIT image. Such a script can be sourced from the U-Boot shell.
 
-      When inheriting the :ref:`ref-classes-kernel-fitimage` class a
+      When inheriting the :ref:`ref-classes-kernel-fit-image` class a
       script file should be included in the :term:`SRC_URI` of the Linux
       kernel recipe.
 
@@ -5075,9 +5082,7 @@ system and gives an overview of their function and contents.
    :term:`KERNEL_CLASSES`
       A list of classes defining kernel image types that the
       :ref:`ref-classes-kernel` class should inherit. You typically
-      append this variable to enable extended image types. An example is
-      ":ref:`ref-classes-kernel-fitimage`", which enables
-      FIT image support and resides in ``meta/classes-recipe/kernel-fitimage.bbclass``.
+      append this variable to enable extended image types.
       You can register custom kernel image types with the
       :ref:`ref-classes-kernel` class using this variable.
 
@@ -5352,6 +5357,27 @@ system and gives an overview of their function and contents.
       the :term:`KERNEL_PATH` variable. Both variables are common variables
       used by external Makefiles to point to the kernel source directory.
 
+   :term:`KERNEL_SPLIT_MODULES`
+      When inheriting the :ref:`ref-classes-kernel-module-split` class, this
+      variable controls whether kernel modules are split into separate packages
+      or bundled into a single package.
+
+      For some use cases, a monolithic kernel module package
+      :term:`KERNEL_PACKAGE_NAME` that contains all modules built from the
+      kernel sources may be preferred to speed up the installation.
+
+      By default, this variable is set to ``1``, resulting in one package per
+      module. Setting it to any other value will generate a single monolithic
+      package containing all kernel modules.
+
+      .. note::
+
+         If :term:`KERNEL_SPLIT_MODULES` is set to 0, it is still possible to
+         install all kernel modules at once by adding ``kernel-modules`` (assuming
+         :term:`KERNEL_PACKAGE_NAME` is ``kernel-modules``) to :term:`IMAGE_INSTALL`.
+         The way it works is that a placeholder "kernel-modules" package will be
+         created and will depend on every other individual kernel module packages.
+
    :term:`KERNEL_SRC`
       The location of the kernel sources. This variable is set to the value
       of the :term:`STAGING_KERNEL_DIR` within the :ref:`ref-classes-module`
@@ -8041,7 +8067,7 @@ system and gives an overview of their function and contents.
    :term:`S`
       The location in the :term:`Build Directory` where
       unpacked recipe source code resides. By default, this directory is
-      ``${``\ :term:`WORKDIR`\ ``}/${``\ :term:`BPN`\ ``}-${``\ :term:`PV`\ ``}``,
+      ``${``\ :term:`UNPACKDIR`\ ``}/${``\ :term:`BPN`\ ``}-${``\ :term:`PV`\ ``}``,
       where ``${BPN}`` is the base recipe name and ``${PV}`` is the recipe
       version. If the source tarball extracts the code to a directory named
       anything other than ``${BPN}-${PV}``, or if the source code is
@@ -8054,19 +8080,10 @@ system and gives an overview of their function and contents.
       ``poky/build``. In this case, the work directory the build system
       uses to keep the unpacked recipe for ``db`` is the following::
 
-         poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
+         poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/sources/db-5.1.19
 
       The unpacked source code resides in the ``db-5.1.19`` folder.
 
-      This next example assumes a Git repository. By default, Git
-      repositories are cloned to ``${WORKDIR}/git`` during
-      :ref:`ref-tasks-fetch`. Since this path is different
-      from the default value of :term:`S`, you must set it specifically so the
-      source can be located::
-
-         SRC_URI = "git://path/to/repo.git;branch=main"
-         S = "${WORKDIR}/git"
-
    :term:`SANITY_REQUIRED_UTILITIES`
       Specifies a list of command-line utilities that should be checked for
       during the initial sanity checking process when running BitBake. If
@@ -8441,7 +8458,6 @@ system and gives an overview of their function and contents.
       sources are fetched from a Git repository and ``setup.py`` is in a
       ``python/pythonmodule`` subdirectory, you would have this::
 
-         S = "${WORKDIR}/git"
          SETUPTOOLS_SETUP_PATH = "${S}/python/pythonmodule"
 
    :term:`SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS`
@@ -8764,6 +8780,28 @@ system and gives an overview of their function and contents.
       image), compared to just using the :ref:`ref-classes-create-spdx` class
       with no option.
 
+   :term:`SPDX_INCLUDE_COMPILED_SOURCES`
+      This option allows the same as :term:`SPDX_INCLUDE_SOURCES` but including
+      only the sources used to compile the host tools and the target packages.
+      While :term:`SPDX_INCLUDE_SOURCES` includes all files in the source
+      directory as source file descriptions, :term:`SPDX_INCLUDE_COMPILED_SOURCES`
+      includes only the sources that are used to produce the binaries delivered
+      as packages. The source files that are not used during compilation are not
+      included in the SBOM. It uses debugsource information generated during
+      ``do_package`` to filter out source files.
+
+      This enables an external tool to use the SPDX information to disregard
+      vulnerabilities that are not compiled in the packages.
+
+      Enable this option as follows::
+
+         SPDX_INCLUDE_COMPILED_SOURCES = "1"
+
+      According to our tests, building ``core-image-minimal`` for the
+      ``qemux86-64`` machine, enabling this option compared with the
+      :term:`SPDX_INCLUDE_SOURCES` reduces the size of the  ``tmp/deploy/spdx``
+      directory from 2GB to 1.6GB.
+
    :term:`SPDX_NAMESPACE_PREFIX`
       This option could be used in order to change the prefix of ``spdxDocument``
       and the prefix of ``documentNamespace``. It is set by default to
@@ -10321,13 +10359,13 @@ system and gives an overview of their function and contents.
    :term:`UBOOT_DTB_LOADADDRESS`
       Specifies the load address for the dtb image used by U-Boot. During FIT
       image creation, the :term:`UBOOT_DTB_LOADADDRESS` variable is used in
-      :ref:`ref-classes-kernel-fitimage` class to specify the load address to be
+      :ref:`ref-classes-kernel-fit-image` class to specify the load address to be
       used in creating the dtb sections of Image Tree Source for the FIT image.
 
    :term:`UBOOT_DTBO_LOADADDRESS`
       Specifies the load address for the dtbo image used by U-Boot.  During FIT
       image creation, the :term:`UBOOT_DTBO_LOADADDRESS` variable is used in
-      :ref:`ref-classes-kernel-fitimage` class to specify the load address to be
+      :ref:`ref-classes-kernel-fit-image` class to specify the load address to be
       used in creating the dtbo sections of Image Tree Source for the FIT image.
 
    :term:`UBOOT_ENTRYPOINT`
@@ -10339,7 +10377,7 @@ system and gives an overview of their function and contents.
       -  The :term:`FIT_ADDRESS_CELLS` variable for FIT image creation.
       -  The :term:`UBOOT_FIT_ADDRESS_CELLS` variable for U-Boot FIT image creation.
 
-      This variable is used by the :ref:`ref-classes-kernel-fitimage`,
+      This variable is used by the :ref:`ref-classes-kernel-fit-image`,
       :ref:`ref-classes-kernel-uimage`, :ref:`ref-classes-kernel`,
       :ref:`ref-classes-uboot-config` and :ref:`ref-classes-uboot-sign`
       classes.
@@ -10616,7 +10654,7 @@ system and gives an overview of their function and contents.
       -  The :term:`FIT_ADDRESS_CELLS` variable for FIT image creation.
       -  The :term:`UBOOT_FIT_ADDRESS_CELLS` variable for U-Boot FIT image creation.
 
-      This variable is used by the :ref:`ref-classes-kernel-fitimage`,
+      This variable is used by the :ref:`ref-classes-kernel-fit-image`,
       :ref:`ref-classes-kernel-uimage`, :ref:`ref-classes-kernel`,
       :ref:`ref-classes-uboot-config` and :ref:`ref-classes-uboot-sign`
       classes.
@@ -10644,15 +10682,15 @@ system and gives an overview of their function and contents.
 
    :term:`UBOOT_MKIMAGE`
       Specifies the name of the mkimage command as used by the
-      :ref:`ref-classes-kernel-fitimage` class to assemble
+      :ref:`ref-classes-kernel-fit-image` class to assemble
       the FIT image. This can be used to substitute an alternative command, wrapper
       script or function if desired. The default is "uboot-mkimage".
 
    :term:`UBOOT_MKIMAGE_DTCOPTS`
       Options for the device tree compiler passed to ``mkimage -D`` feature
-      while creating a FIT image with the :ref:`ref-classes-kernel-fitimage`
+      while creating a FIT image with the :ref:`ref-classes-kernel-fit-image`
       class. If :term:`UBOOT_MKIMAGE_DTCOPTS` is not set then the
-      :ref:`ref-classes-kernel-fitimage` class will not pass the ``-D`` option
+      :ref:`ref-classes-kernel-fit-image` class will not pass the ``-D`` option
       to ``mkimage``.
 
       This variable is also used by the :ref:`ref-classes-uboot-sign` class.
@@ -10663,42 +10701,42 @@ system and gives an overview of their function and contents.
 
    :term:`UBOOT_MKIMAGE_SIGN`
       Specifies the name of the mkimage command as used by the
-      :ref:`ref-classes-kernel-fitimage` class to sign
+      :ref:`ref-classes-kernel-fit-image` class to sign
       the FIT image after it has been assembled (if enabled). This can be used
       to substitute an alternative command, wrapper script or function if
       desired. The default is "${:term:`UBOOT_MKIMAGE`}".
 
    :term:`UBOOT_MKIMAGE_SIGN_ARGS`
       Optionally specifies additional arguments for the
-      :ref:`ref-classes-kernel-fitimage` class to pass to the
+      :ref:`ref-classes-kernel-fit-image` class to pass to the
       mkimage command when signing the FIT image.
 
    :term:`UBOOT_RD_ENTRYPOINT`
       Specifies the entrypoint for the RAM disk image. During FIT image
       creation, the :term:`UBOOT_RD_ENTRYPOINT` variable is used in
-      :ref:`ref-classes-kernel-fitimage` class to specify the entrypoint to be
+      :ref:`ref-classes-kernel-fit-image` class to specify the entrypoint to be
       used in creating the Image Tree Source for the FIT image.
 
    :term:`UBOOT_RD_LOADADDRESS`
       Specifies the load address for the RAM disk image. During FIT image
       creation, the :term:`UBOOT_RD_LOADADDRESS` variable is used in
-      :ref:`ref-classes-kernel-fitimage` class to specify the load address to
+      :ref:`ref-classes-kernel-fit-image` class to specify the load address to
       be used in creating the Image Tree Source for the FIT image.
 
    :term:`UBOOT_SIGN_ENABLE`
       Enable signing of FIT image. The default value is "0".
 
-      This variable is used by the :ref:`ref-classes-kernel-fitimage`,
+      This variable is used by the :ref:`ref-classes-kernel-fit-image`,
       :ref:`ref-classes-uboot-config` and :ref:`ref-classes-uboot-sign`
       classes.
 
    :term:`UBOOT_SIGN_KEYDIR`
       Location of the directory containing the RSA key and certificate used for
-      signing FIT image, used by the :ref:`ref-classes-kernel-fitimage` and
+      signing FIT image, used by the :ref:`ref-classes-kernel-fit-image` and
       :ref:`ref-classes-uboot-sign` classes.
 
    :term:`UBOOT_SIGN_KEYNAME`
-      The name of keys used by the :ref:`ref-classes-kernel-fitimage` class
+      The name of keys used by the :ref:`ref-classes-kernel-fit-image` class
       for signing U-Boot FIT image stored in the :term:`UBOOT_SIGN_KEYDIR`
       directory. If we have for example a ``dev.key`` key and a ``dev.crt``
       certificate stored in the :term:`UBOOT_SIGN_KEYDIR` directory, you will
diff --git a/documentation/ref-manual/yocto-project-supported-features.rst b/documentation/ref-manual/yocto-project-supported-features.rst
index 345280d67d..283c79d4cc 100644
--- a/documentation/ref-manual/yocto-project-supported-features.rst
+++ b/documentation/ref-manual/yocto-project-supported-features.rst
@@ -92,10 +92,10 @@ Below is a list of primary tested features, their maintainer(s) and builder(s):
      - meta-exein layer testing
      - TBD
      - meta-exein
-   * - `meta-virtualization <https://git.yoctoproject.org/meta-virtualization/>`__
-     - meta-virtualization layer testing
+   * - `meta-webosose <https://github.com/webosose/meta-webosose>`__
+     - meta-webosose layer testing
      - TBD
-     - meta-virt
+     - meta-webosose
    * - :ref:`Multilib <dev-manual/libraries:Combining Multiple Versions of Library Files into One Image>`
      - Multilib feature testing
      - Collective effort
@@ -114,7 +114,7 @@ Below is a list of primary tested features, their maintainer(s) and builder(s):
      - pkgman-non-rpm (other builders use RPM by default)
    * - :ref:`Patchtest <contributor-guide/submit-changes:Validating Patches with Patchtest>`
      - Patchtest tool selftests
-     - TBD
+     - Collective effort
      - patchtest-selftest
    * - :wikipedia:`RISC-V (64-bit) <RISC-V>`
      - RISC-V architecture testing (64-bit)
@@ -209,25 +209,25 @@ builder(s):
      - Builder(s)
    * - :wikipedia:`PowerPC (32-bit) <PowerPC>`
      - PowerPC architecture testing (32-bit)
-     - TBD
+     - Peter Marko,
+       Adrian Freihofer
      - qemuppc,
-       qemuppc-alt,
        qemuppc-tc
    * - :oe_git:`meta-openembedded </meta-openembedded>`
      - meta-openembedded layer testing
-     - TBD
+     - Collective effort / openembedded-devel mailing list <openebedded-devel@lists.openembedded.org>
      - meta-oe
    * - `meta-mingw <https://git.yoctoproject.org/meta-mingw>`__
      - mingw based SDKs testing
      - TBD
      - meta-mingw
-   * - `meta-webosose <https://github.com/webosose/meta-webosose>`__
-     - meta-webosose layer testing
-     - TBD
-     - meta-webosose
+   * - `meta-virtualization <https://git.yoctoproject.org/meta-virtualization/>`__
+     - meta-virtualization layer testing
+     - meta-virtualization mailing list <meta-virtualization@lists.yoctoproject.org>
+     - meta-virt
    * - :wikipedia:`RISC-V (32-bit) <RISC-V>`
      - RISC-V architecture testing (32-bit)
-     - Collective effort
+     - TBD
      - qemuriscv32,
        qemuriscv32,
        qemuriscv32-tc
@@ -256,6 +256,10 @@ it is on a best effort only basis.
        qemumips-alt,
        qemumips-tc,
        qemumips64-tc
+   * - :wikipedia:`PowerPC (32-bit) <PowerPC>` Systemd
+     - PowerPC architecture testing (32-bit) with systemd
+     - No maintainers
+     - qemuppc-alt
    * - :wikipedia:`PowerPC (64-bit) <PowerPC>`
      - PowerPC architecture testing (64-bit)
      - No maintainers