36 files changed, 958 insertions, 246 deletions

diff --git a/documentation/README b/documentation/README
index 02037e0f7e..56eac7ca19 100644
--- a/documentation/README
+++ b/documentation/README
@@ -314,6 +314,16 @@ See https://stackoverflow.com/questions/27420317/restructured-text-rst-http-link
 Anchor (<#link>) links are forbidden as they are not checked by Sphinx during
 the build and may be broken without knowing about it.
 
+It is also possible to refer to another document within yocto-docs with the
+:doc: directive (c.f.
+https://www.sphinx-doc.org/en/master/usage/referencing.html#role-doc), e.g.:
+
+  For more information, read :doc:`/bsp-guide/index`.
+
+Note that only "absolute" paths (starting with a '/') are allowed. The root
+directory of that path is documentation/, that is, :doc:`/bsp-guide/index`
+points at documentation/bsp-guide/index.rst.
+
 References
 ==========
 
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index 35972f1726..09246b4ae4 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -674,21 +674,21 @@ to the kernel recipe by using a similarly named append file, which is
 located in the BSP Layer for your target device (e.g. the
 ``meta-bsp_root_name/recipes-kernel/linux`` directory).
 
-Suppose you are using the ``linux-yocto_4.4.bb`` recipe to build the
+Suppose you are using the ``linux-yocto_6.12.bb`` recipe to build the
 kernel. In other words, you have selected the kernel in your
 ``"bsp_root_name".conf`` file by adding
 :term:`PREFERRED_PROVIDER` and :term:`PREFERRED_VERSION`
 statements as follows::
 
    PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-   PREFERRED_VERSION_linux-yocto ?= "4.4%"
+   PREFERRED_VERSION_linux-yocto ?= "6.12%"
 
 .. note::
 
    When the preferred provider is assumed by default, the :term:`PREFERRED_PROVIDER`
    statement does not appear in the ``"bsp_root_name".conf`` file.
 
-You would use the ``linux-yocto_4.4.bbappend`` file to append specific
+You would use the ``linux-yocto_6.12.bbappend`` file to append specific
 BSP settings to the kernel, thus configuring the kernel for your
 particular BSP.
 
@@ -698,14 +698,19 @@ in the Yocto Project Linux Kernel Development Manual.
 
 An alternate scenario is when you create your own kernel recipe for the
 BSP. A good example of this is the Raspberry Pi BSP. If you examine the
-``recipes-kernel/linux`` directory you see the following::
+``recipes-kernel/linux`` directory in that layer you see the following
+Raspberry Pi-specific recipes and associated files::
 
+   files/
+   linux-raspberrypi_6.12.bb
+   linux-raspberrypi_6.1.bb
+   linux-raspberrypi_6.6.bb
    linux-raspberrypi-dev.bb
    linux-raspberrypi.inc
-   linux-raspberrypi_4.14.bb
-   linux-raspberrypi_4.9.bb
-
-The directory contains three kernel recipes and a common include file.
+   linux-raspberrypi-v7_6.12.bb
+   linux-raspberrypi-v7_6.1.bb
+   linux-raspberrypi-v7_6.6.bb
+   linux-raspberrypi-v7.inc
 
 Developing a Board Support Package (BSP)
 ========================================
@@ -876,7 +881,7 @@ The requirements for a released BSP that conform to the Yocto Project are:
    ``recipes-*`` subdirectories specific to the recipe's function, or
    within a subdirectory containing a set of closely-related recipes.
    The recipes themselves should follow the general guidelines for
-   recipes found in the ":doc:`../contributor-guide/recipe-style-guide`"
+   recipes found in the ":doc:`/contributor-guide/recipe-style-guide`"
    in the Yocto Project and OpenEmbedded Contributor Guide.
 
 -  *License File:* You must include a license file in the
@@ -910,7 +915,7 @@ The requirements for a released BSP that conform to the Yocto Project are:
    -  The name and contact information for the BSP layer maintainer.
       This is the person to whom patches and questions should be sent.
       For information on how to find the right person, see the
-      :doc:`../contributor-guide/submit-changes` section in the Yocto Project and
+      :doc:`/contributor-guide/submit-changes` section in the Yocto Project and
       OpenEmbedded Contributor Guide.
 
    -  Instructions on how to build the BSP using the BSP layer.
@@ -1177,7 +1182,7 @@ Use these steps to create a BSP layer:
 
 -  *Create a Kernel Recipe:* Create a kernel recipe in
    ``recipes-kernel/linux`` by either using a kernel append file or a
-   new custom kernel recipe file (e.g. ``linux-yocto_4.12.bb``). The BSP
+   new custom kernel recipe file (e.g. ``linux-yocto_6.12.bb``). The BSP
    layers mentioned in the previous step also contain different kernel
    examples. See the ":ref:`kernel-dev/common:modifying an existing recipe`"
    section in the Yocto Project Linux Kernel Development Manual for
@@ -1242,7 +1247,7 @@ located in :yocto_git:`poky/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
 
    PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 
-   MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"
+   MACHINE_EXTRA_RRECOMMENDS = "kernel-modules"
 
    EXTRA_IMAGEDEPENDS += "virtual/bootloader"
 
@@ -1258,23 +1263,21 @@ located in :yocto_git:`poky/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
    SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0 115200;ttyAMA0"
 
    PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-   PREFERRED_VERSION_linux-yocto ?= "6.1%"
+   PREFERRED_VERSION_linux-yocto ?= "6.12%"
 
    KERNEL_IMAGETYPE = "zImage"
-   KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
-   KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
+   DTB_FILES = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
+   KERNEL_DEVICETREE = '${@' '.join('ti/omap/%s' % d for d in '${DTB_FILES}'.split())}'
 
    PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
 
    SPL_BINARY = "MLO"
    UBOOT_SUFFIX = "img"
    UBOOT_MACHINE = "am335x_evm_defconfig"
-   UBOOT_ENTRYPOINT = "0x80008000"
-   UBOOT_LOADADDRESS = "0x80008000"
 
    MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
 
-   IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}"
+   IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${DTB_FILES}"
 
    # support runqemu
    EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
@@ -1328,12 +1331,12 @@ Project Reference Manual.
    needed in the root filesystem. In this case, the U-Boot recipe must
    be built for the image.
 
-   At the end of the file, we also use this setings to implement
+   At the end of the file, we also use this setting to implement
    ``runqemu`` support on the host machine.
 
 -  :term:`DEFAULTTUNE`: Machines
    use tunings to optimize machine, CPU, and application performance.
-   These features, which are collectively known as "tuning features",
+   These features --- collectively known as "tuning features" ---
    are set in the :term:`OpenEmbedded-Core (OE-Core)` layer. In this
    example, the default tuning file is :oe_git:`tune-cortexa8
    </openembedded-core/tree/meta/conf/machine/include/arm/armv7a/tune-cortexa8.inc>`.
@@ -1363,8 +1366,7 @@ Project Reference Manual.
    to create the sysroot when building a Wic image.
 
 -  :term:`SERIAL_CONSOLES`:
-   Defines a serial console (TTY) to enable using getty. In this case,
-   the baud rate is "115200" and the device name is "ttyO0".
+   Defines one or more serial consoles (TTYs) to enable using getty.
 
 -  :term:`PREFERRED_PROVIDER_virtual/kernel <PREFERRED_PROVIDER>`:
    Specifies the recipe that provides "virtual/kernel" when more than
@@ -1374,7 +1376,7 @@ Project Reference Manual.
 
 -  :term:`PREFERRED_VERSION_linux-yocto <PREFERRED_VERSION>`:
    Defines the version of the recipe used to build the kernel, which is
-   "6.1" in this case.
+   "6.12" in this case.
 
 -  :term:`KERNEL_IMAGETYPE`:
    The type of kernel to build for the device. In this case, the
@@ -1416,12 +1418,6 @@ Project Reference Manual.
       Specifies the value passed on the make command line when building
       a U-Boot image.
 
-   -  :term:`UBOOT_ENTRYPOINT`:
-      Specifies the entry point for the U-Boot image.
-
-   -  :term:`UBOOT_LOADADDRESS`:
-      Specifies the load address for the U-Boot image.
-
 -  :term:`MACHINE_FEATURES`:
    Specifies the list of hardware features the BeagleBone device is
    capable of supporting. In this case, the device supports "usbgadget
diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst
index 6d5d69d7cf..adb78fa08d 100644
--- a/documentation/contributor-guide/submit-changes.rst
+++ b/documentation/contributor-guide/submit-changes.rst
@@ -76,7 +76,7 @@ Clone the Git repository for the component to modify
 ----------------------------------------------------
 
 After identifying the component to modify as described in the
-":doc:`../contributor-guide/identify-component`" section, clone the
+":doc:`/contributor-guide/identify-component`" section, clone the
 corresponding Git repository. Here is an example for OpenEmbedded-Core::
 
   git clone https://git.openembedded.org/openembedded-core
@@ -872,7 +872,7 @@ in regards to the use of generative AI tools. See:
 https://www.linuxfoundation.org/legal/generative-ai.
 
 All of the existing guidelines in this document are expected to be followed,
-including in the :doc:`recipe-style-guide`, and contributing the changes with
+including in the :doc:`/contributor-guide/recipe-style-guide`, and contributing the changes with
 additional requirements to the items in section
 :ref:`contributor-guide/submit-changes:Implement and commit changes`.
 
diff --git a/documentation/dev-manual/building.rst b/documentation/dev-manual/building.rst
index 807c665f68..865d2e1b67 100644
--- a/documentation/dev-manual/building.rst
+++ b/documentation/dev-manual/building.rst
@@ -48,7 +48,7 @@ The following figure and list overviews the build process:
    :width: 100%
 
 #. *Set up Your Host Development System to Support Development Using the
-   Yocto Project*: See the ":doc:`start`" section for options on how to get a
+   Yocto Project*: See the ":doc:`/dev-manual/start`" section for options on how to get a
    build host ready to use the Yocto Project.
 
 #. *Initialize the Build Environment:* Initialize the build environment
@@ -113,7 +113,7 @@ The following figure and list overviews the build process:
 Building Images for Multiple Targets Using Multiple Configurations
 ==================================================================
 
-See the :doc:`multiconfig` section of the Yocto Project Development Tasks
+See the :doc:`/dev-manual/multiconfig` section of the Yocto Project Development Tasks
 Manual.
 
 Building an Initial RAM Filesystem (Initramfs) Image
diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst
index 8552b26aea..6c45ccf652 100644
--- a/documentation/dev-manual/debugging.rst
+++ b/documentation/dev-manual/debugging.rst
@@ -890,7 +890,7 @@ The build should work without issue.
 As with all solved problems, if they originated upstream, you need to
 submit the fix for the recipe in OE-Core and upstream so that the
 problem is taken care of at its source. See the
-":doc:`../contributor-guide/submit-changes`" section for more information.
+":doc:`/contributor-guide/submit-changes`" section for more information.
 
 Debugging With the GNU Project Debugger (GDB) Remotely
 ======================================================
@@ -1261,7 +1261,7 @@ Here are some other tips that you might find useful:
    :yocto_bugs:`Bugzilla <>`. For information on
    how to submit a bug against the Yocto Project, see the Yocto Project
    Bugzilla :yocto_wiki:`wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
-   and the ":doc:`../contributor-guide/report-defect`" section.
+   and the ":doc:`/contributor-guide/report-defect`" section.
 
    .. note::
 
diff --git a/documentation/dev-manual/new-recipe.rst b/documentation/dev-manual/new-recipe.rst
index 9792bd4c1f..c49881efe6 100644
--- a/documentation/dev-manual/new-recipe.rst
+++ b/documentation/dev-manual/new-recipe.rst
@@ -1401,7 +1401,7 @@ Following Recipe Style Guidelines
 =================================
 
 When writing recipes, it is good to conform to existing style guidelines.
-See the ":doc:`../contributor-guide/recipe-style-guide`" in the Yocto Project
+See the ":doc:`/contributor-guide/recipe-style-guide`" in the Yocto Project
 and OpenEmbedded Contributor Guide for reference.
 
 It is common for existing recipes to deviate a bit from this style.
diff --git a/documentation/dev-manual/sbom.rst b/documentation/dev-manual/sbom.rst
index e6806ce929..ca0fc8b9d6 100644
--- a/documentation/dev-manual/sbom.rst
+++ b/documentation/dev-manual/sbom.rst
@@ -60,6 +60,9 @@ more information in the output :term:`SPDX` data:
 -  Add a description of the source files used to generate host tools and target
    packages (:term:`SPDX_INCLUDE_SOURCES`)
 
+-  Add a description of the **compiled** source files used to generate host tools
+   and target packages (:term:`SPDX_INCLUDE_COMPILED_SOURCES`)
+
 -  Add archives of these source files themselves (:term:`SPDX_ARCHIVE_SOURCES`).
 
 Though the toplevel :term:`SPDX` output is available in
diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst
index 73548132a3..d77da04276 100644
--- a/documentation/dev-manual/start.rst
+++ b/documentation/dev-manual/start.rst
@@ -234,7 +234,7 @@ particular working environment and set of practices.
     -  The Yocto Project community encourages you to send patches to the
        project to fix bugs or add features. If you do submit patches,
        follow the project commit guidelines for writing good commit
-       messages. See the ":doc:`../contributor-guide/submit-changes`"
+       messages. See the ":doc:`/contributor-guide/submit-changes`"
        section in the Yocto Project and OpenEmbedded Contributor Guide.
 
     -  Send changes to the core sooner than later as others are likely
diff --git a/documentation/dev-manual/vulnerabilities.rst b/documentation/dev-manual/vulnerabilities.rst
index d901ff975b..5331a63991 100644
--- a/documentation/dev-manual/vulnerabilities.rst
+++ b/documentation/dev-manual/vulnerabilities.rst
@@ -22,7 +22,7 @@ issues may be impacting Poky and OE-Core. It is up to the maintainers, users,
 contributors and anyone interested in the issues to investigate and possibly fix them by
 updating software components to newer versions or by applying patches to address them.
 It is recommended to work with Poky and OE-Core upstream maintainers and submit
-patches to fix them, see ":doc:`../contributor-guide/submit-changes`" for details.
+patches to fix them, see ":doc:`/contributor-guide/submit-changes`" for details.
 
 Vulnerability check at build time
 =================================
diff --git a/documentation/migration-guides/migration-5.3.rst b/documentation/migration-guides/migration-5.3.rst
index 22653fc911..09095c7bb2 100644
--- a/documentation/migration-guides/migration-5.3.rst
+++ b/documentation/migration-guides/migration-5.3.rst
@@ -59,6 +59,48 @@ Removed classes
 
 The following classes have been removed in this release:
 
+-  ``kernel-fitimage.bbclass``: the class has been replaced by the
+   :ref:`ref-classes-kernel-fit-image` class. The new implementation resolves
+   the long-standing :yocto_bugs:`bug 12912</show_bug.cgi?id=12912>`.
+
+   If you are using the kernel FIT image support, you will need to:
+
+   #. Make sure to include ``kernel-fit-extra-artifacts`` in your :term:`KERNEL_CLASSES`
+      variable to ensure the required files are exposed to the :term:`DEPLOY_DIR_IMAGE`
+      directory::
+
+         KERNEL_CLASSES += "kernel-fit-extra-artifacts"
+
+   #. Use the specific FIT image recipe rather than the base kernel recipe.
+      For example, instead of::
+
+         bitbake linux-yocto
+
+      the FIT image is now build by::
+
+         bitbake linux-yocto-fitimage
+
+      For custom kernel recipes, creating a corresponding custom FIT image recipe
+      is usually a good approach.
+
+   #. If a FIT image is used as a replacement for the kernel image in the root
+      filesystem, add the following configuration to your 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"
+
+   See the :ref:`ref-classes-kernel-fit-image` section for more information.
+
 Removed features
 ~~~~~~~~~~~~~~~~
 
diff --git a/documentation/migration-guides/release-5.0.rst b/documentation/migration-guides/release-5.0.rst
index 3eb7349c78..b3e7a67912 100644
--- a/documentation/migration-guides/release-5.0.rst
+++ b/documentation/migration-guides/release-5.0.rst
@@ -16,3 +16,4 @@ Release 5.0 (scarthgap)
    release-notes-5.0.7
    release-notes-5.0.8
    release-notes-5.0.9
+   release-notes-5.0.10
diff --git a/documentation/migration-guides/release-notes-4.3.rst b/documentation/migration-guides/release-notes-4.3.rst
index 0103ac985e..aa3f31a2ce 100644
--- a/documentation/migration-guides/release-notes-4.3.rst
+++ b/documentation/migration-guides/release-notes-4.3.rst
@@ -272,9 +272,9 @@ New Features / Enhancements in 4.3
 
 -  Prominent documentation updates:
 
-   -  New :doc:`../contributor-guide/index` document.
+   -  New :doc:`/contributor-guide/index` document.
 
-   -  New :doc:`../dev-manual/security-subjects` chapter in the Development
+   -  New :doc:`/dev-manual/security-subjects` chapter in the Development
       Tasks Manual.
 
    -  Long overdue documentation for the :ref:`ref-classes-devicetree` class.
diff --git a/documentation/migration-guides/release-notes-5.0.10.rst b/documentation/migration-guides/release-notes-5.0.10.rst
new file mode 100644
index 0000000000..e9845aa315
--- /dev/null
+++ b/documentation/migration-guides/release-notes-5.0.10.rst
@@ -0,0 +1,208 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-5.0.10 (Scarthgap)
+------------------------------------------
+
+Security Fixes in Yocto-5.0.10
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  binutils: Fix :cve_nist:`2025-1153`, :cve_nist:`2025-1179`, :cve_nist:`2025-1180` and
+   :cve_nist:`2025-1182`
+-  connman: Fix :cve_nist:`2025-32366` and :cve_nist:`2025-32743`
+-  curl: Fix :cve_nist:`2024-11053` and :cve_nist:`2025-0167`
+-  elfutils: Fix :cve_nist:`2025-1371`
+-  ffmpeg: Fix :cve_nist:`2024-7055`, :cve_nist:`2024-32230`, :cve_nist:`2024-35366`,
+   :cve_nist:`2024-36613`, :cve_nist:`2024-36616`, :cve_nist:`2024-36617` and :cve_nist:`2024-36619`
+-  git: Fix :cve_nist:`2024-50349` and :cve_nist:`2024-52006`
+-  glib-2.0: fix :cve_nist:`2025-3360` and :cve_nist:`2025-4373`
+-  iputils: Fix :cve_nist:`2025-47268`
+-  libpam: Fix :cve_nist:`2024-10041`
+-  libsoup-2.4: Fix :cve_nist:`2024-52530`, :cve_nist:`2024-52531`, :cve_nist:`2024-52532`,
+   :cve_nist:`2025-32906`, :cve_nist:`2025-32909`, :cve_nist:`2025-32910`, :cve_nist:`2025-32911`,
+   :cve_nist:`2025-32912`, :cve_nist:`2025-32913`, :cve_nist:`2025-32914` and :cve_nist:`2025-46420`
+-  libsoup: Fix :cve_nist:`2025-4476`, :cve_nist:`2025-32906`, :cve_nist:`2025-32909`,
+   :cve_nist:`2025-32910`, :cve_nist:`2025-32911`, :cve_nist:`2025-32912`, :cve_nist:`2025-32913`,
+   :cve_nist:`2025-32914` and :cve_nist:`2025-46420`
+-  libxml2: Fix :cve_nist:`2025-32414` and :cve_nist:`2025-32415`
+-  openssh: Fix :cve_nist:`2025-32728`
+-  perl: Fix :cve_nist:`2024-56406`
+-  ppp: Fix :cve_nist:`2024-58250`
+-  python3-jinja2: Fix :cve_nist:`2024-56201`, :cve_nist:`2024-56326` and :cve_nist:`2025-27516`
+-  ruby: Fix :cve_nist:`2025-27221`
+-  sqlite3: Fix :cve_nist:`2025-3277`, :cve_nist:`2025-29087` and :cve_nist:`2025-29088`
+
+
+Fixes in Yocto-5.0.10
+~~~~~~~~~~~~~~~~~~~~~
+
+-  binutils: stable 2.42 branch updates
+-  bluez5: add missing tools to noinst-tools package
+-  bluez5: backport a patch to fix btmgmt -i
+-  bluez5: make media control a :term:`PACKAGECONFIG` option
+-  build-appliance-image: Update to scarthgap head revision
+-  buildtools-tarball: Make buildtools respects host CA certificates
+-  buildtools-tarball: add envvars into :term:`BB_ENV_PASSTHROUGH_ADDITIONS`
+-  buildtools-tarball: move setting of envvars to respective envfile
+-  contributor-guide/submit-changes: encourage patch version changelogs
+-  cve-check.bbclass: Fix symlink handling also for text files
+-  cve-update-nvd2-native: Revert "cve-update-nvd2-native: Tweak to work better with NFS DL_DIR"
+-  dev-manual/sbom.rst: fix wrong build outputs
+-  docs: Fix dead links that use the :term:`DISTRO` macro
+-  docs: conf.py: tweak SearchEnglish to be hyphen-friendly
+-  docs:conf.py: define a manpage url
+-  ffmpeg: upgrade to 6.1.2
+-  git: upgrade to 2.44.3
+-  glibc-y2038-tests: remove glibc-y2038-tests_2.39.bb recipe
+-  glibc: Add single-threaded fast path to rand()
+-  glibc: stable 2.39 branch updates
+-  initscripts: add function log_success_msg/log_failure_msg/log_warning_msg
+-  libatomic-ops: Update :term:`GITHUB_BASE_URI`
+-  manuals: remove repeated word
+-  migration-guides: add release notes for 4.0.26, 5.0.8, 5.0.9
+-  module.bbclass: add KBUILD_EXTRA_SYMBOLS to install
+-  perl: upgrade to 5.38.4
+-  perlcross: upgrade to 1.6.2
+-  poky.conf: bump version for 5.0.10
+-  poky.yaml: introduce DISTRO_LATEST_TAG
+-  python3-jinja2: upgrade to 3.1.6
+-  ref-manual/release-process: update releases.svg
+-  ref-manual/variables.rst: HOST_CC_ARCH: fix wrong SDK reference
+-  ref-manual/variables.rst: WATCHDOG_TIMEOUT: fix recipe name
+-  ref-manual/variables.rst: add manpage links for toolchain variables
+-  ref-manual/variables.rst: add missing documentation for BUILD_* variables
+-  ref-manual/variables.rst: document HOST_*_ARCH variables
+-  ref-manual/variables.rst: document :term:`INHIBIT_DEFAULT_RUST_DEPS`
+-  ref-manual/variables.rst: document :term:`INHIBIT_UPDATERCD_BBCLASS`
+-  ref-manual/variables.rst: document :term:`SSTATE_SKIP_CREATION`
+-  ref-manual/variables.rst: document :term:`WIC_CREATE_EXTRA_ARGS`
+-  ref-manual/variables.rst: document autotools class related variables
+-  ref-manual/variables.rst: document missing SDK_*_ARCH variables
+-  ref-manual/variables.rst: document the :term:`IMAGE_ROOTFS_MAXSIZE` variable
+-  ref-manual/variables.rst: document the :term:`INITRAMFS_MAXSIZE` variable
+-  ref-manual/variables.rst: improve the :term:`PKGV` documentation
+-  ref-manual/variables.rst: update :term:`ROOT_HOME` documentation
+-  ref-manual: kernel-fitimage.bbclass does not use :term:`SPL_SIGN_KEYNAME`
+-  scripts/install-buildtools: Update to 5.0.9
+-  sphinx-lint: missing space after literal
+-  sphinx-lint: trailing whitespace
+-  sphinx-lint: unbalanced inline literal markup
+-  systemd: Password agents shouldn't be optional
+-  systemd: upgrade to 255.18
+-  test-manual/intro: remove Buildbot version used
+-  tzdata/tzcode-native: upgrade 2025a -> 2025b
+-  u-boot: ensure keys are generated before assembling U-Boot FIT image
+-  util-linux: Add fix to isolate test fstab entries using CUSTOM_FSTAB
+-  wic: bootimg-efi: Support + symbol in filenames
+
+
+Known Issues in Yocto-5.0.10
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  There is an issue where the target libsoup-2.4 build may fail if apachectl is present on the build
+   host. The issue only affects test binaries which aren't actually used. The issue can be fixed by
+   disabling the tests or updating to more recent changes on the scarthgap branch which fix this.
+
+
+Contributors to Yocto-5.0.10
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Thanks to the following people who contributed to this release:
+
+-  Adrian Freihofer
+-  Aleksandar Nikolic
+-  Alexander Kanavin
+-  Alon Bar-Lev
+-  Alper Ak
+-  Andrew Kreimer
+-  Antonin Godard
+-  Archana Polampalli
+-  Ashish Sharma
+-  Changqing Li
+-  Christos Gavros
+-  Deepesh Varatharajan
+-  Divya Chellam
+-  Divyanshu Rathore
+-  Enrico Jörns
+-  Etienne Cordonnier
+-  Guðni Már Gilbert
+-  Haixiao Yan
+-  Harish Sadineni
+-  Igor Opaniuk
+-  Jeroen Hofstee
+-  Lee Chee Yang
+-  Nguyen Dat Tho
+-  Niko Mauno
+-  Peter Marko
+-  Praveen Kumar
+-  Priyal Doshi
+-  Rogerio Guerra Borin
+-  Shubham Kulkarni
+-  Soumya Sambu
+-  Steve Sakoman
+-  Sunil Dora
+-  Trevor Woerner
+-  Vijay Anusuri
+-  Virendra Thakur
+-  Vyacheslav Yurkov
+-  Yi Zhao
+-  Yogita Urade
+-  rajmohan r
+
+Repositories / Downloads for Yocto-5.0.10
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`scarthgap </poky/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.10 </poky/log/?h=yocto-5.0.10>`
+-  Git Revision: :yocto_git:`ac257900c33754957b2696529682029d997a8f28 </poky/commit/?id=ac257900c33754957b2696529682029d997a8f28>`
+-  Release Artefact: poky-ac257900c33754957b2696529682029d997a8f28
+-  sha: ddca7e54b331e78214bea65b346320d4fbcddf4b51103bfbbd9fc3960f32cdc7
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.10/poky-ac257900c33754957b2696529682029d997a8f28.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.10/poky-ac257900c33754957b2696529682029d997a8f28.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`scarthgap </openembedded-core/log/?h=scarthgap>`
+-  Tag:  :oe_git:`yocto-5.0.10 </openembedded-core/log/?h=yocto-5.0.10>`
+-  Git Revision: :oe_git:`d5342ffc570d47a723b18297d75bd2f63c2088db </openembedded-core/commit/?id=d5342ffc570d47a723b18297d75bd2f63c2088db>`
+-  Release Artefact: oecore-d5342ffc570d47a723b18297d75bd2f63c2088db
+-  sha: daa62094f2327f4b3fbcc485e8964d1b86a4722f58fb37e0d8e8e9885094a262
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.10/oecore-d5342ffc570d47a723b18297d75bd2f63c2088db.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.10/oecore-d5342ffc570d47a723b18297d75bd2f63c2088db.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`scarthgap </meta-mingw/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.10 </meta-mingw/log/?h=yocto-5.0.10>`
+-  Git Revision: :yocto_git:`bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f </meta-mingw/commit/?id=bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f>`
+-  Release Artefact: meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f
+-  sha: ab073def6487f237ac125d239b3739bf02415270959546b6b287778664f0ae65
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.10/meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.10/meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.8 </bitbake/log/?h=2.8>`
+-  Tag:  :oe_git:`yocto-5.0.10 </bitbake/log/?h=yocto-5.0.10>`
+-  Git Revision: :oe_git:`696c2c1ef095f8b11c7d2eff36fae50f58c62e5e </bitbake/commit/?id=696c2c1ef095f8b11c7d2eff36fae50f58c62e5e>`
+-  Release Artefact: bitbake-696c2c1ef095f8b11c7d2eff36fae50f58c62e5e
+-  sha: fc83f879cd6dd14b9b7eba0161fec23ecc191fed0fb00556ba729dceef6c145f
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.10/bitbake-696c2c1ef095f8b11c7d2eff36fae50f58c62e5e.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.10/bitbake-696c2c1ef095f8b11c7d2eff36fae50f58c62e5e.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`scarthgap </yocto-docs/log/?h=scarthgap>`
+-  Tag: :yocto_git:`yocto-5.0.10 </yocto-docs/log/?h=yocto-5.0.10>`
+-  Git Revision: :yocto_git:`3996388e337377bedc113d072a51fe9d68dd40c6 </yocto-docs/commit/?id=3996388e337377bedc113d072a51fe9d68dd40c6>`
+
diff --git a/documentation/migration-guides/release-notes-5.1.rst b/documentation/migration-guides/release-notes-5.1.rst
index 267934a71e..bab0c14581 100644
--- a/documentation/migration-guides/release-notes-5.1.rst
+++ b/documentation/migration-guides/release-notes-5.1.rst
@@ -377,7 +377,7 @@ New Features / Enhancements in 5.1
       :term:`SIGGEN_EXCLUDERECIPES_ABISAFE` and does not trigger a rebuild on a
       change for dependent tasks.
 
-   -  In :ref:`ref-classes-kernel-fitimage`, the existence of
+   -  In ``kernel-fitimage``, the existence of
       :term:`EXTERNAL_KERNEL_DEVICETREE` is checked more thoroughly to avoid
       false positives.
 
diff --git a/documentation/migration-guides/release-notes-5.2.rst b/documentation/migration-guides/release-notes-5.2.rst
index aad5a2eda0..5fc426c050 100644
--- a/documentation/migration-guides/release-notes-5.2.rst
+++ b/documentation/migration-guides/release-notes-5.2.rst
@@ -29,7 +29,7 @@ New Features / Enhancements in |yocto-ver|
       ``RuntimeWatchdogSec`` option in ``/etc/systemd/system.conf``.
 
    -  :term:`FIT_UBOOT_ENV` to allow including a u-boot script as a text in a
-      fit image. See the :ref:`ref-classes-kernel-fitimage` for more information.
+      fit image. See the ``kernel-fitimage`` for more information.
 
    -  :ref:`ref-classes-meson`: :term:`MESON_INSTALL_TAGS` to allow passing
       install tags (``--tags``) to the ``meson install`` command during the
@@ -684,7 +684,7 @@ New Features / Enhancements in |yocto-ver|
       command-line tool was added to the different Yocto Project and OpenEmbedded
       repositories.
 
-   -  :ref:`ref-classes-kernel-fitimage`: handle :doc:`multiconfig
+   -  ``kernel-fitimage``: handle :doc:`multiconfig
       </dev-manual/multiconfig>` dependency when
       :term:`INITRAMFS_MULTICONFIG` is set.
 
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 85dea9fe05..c9405cdd33 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -98,7 +98,7 @@ files, and how to package the compiled output.
 
 The term "package" is sometimes used to refer to recipes. However, since
 the word "package" is used for the packaged output from the OpenEmbedded
-build system (i.e. ``.ipk`` or ``.deb`` files), this document avoids
+build system (i.e. ``.ipk``, ``.deb`` or ``.rpm`` files), this document avoids
 using the term "package" when referring to recipes.
 
 Classes
@@ -256,7 +256,7 @@ development environment.
 .. note::
 
    The
-   scripts/oe-setup-builddir
+   ``scripts/oe-setup-builddir``
    script uses the
    ``$TEMPLATECONF``
    variable to determine which sample configuration files to locate.
@@ -352,7 +352,7 @@ layers the build system uses to further control the build. These layers
 provide Metadata for the software, machine, and policies.
 
 In general, there are three types of layer input. You can see them below
-the "User Configuration" box in the `general workflow
+the "User Configuration" box in the :ref:`general workflow
 figure <overview-manual/concepts:openembedded build system concepts>`:
 
 -  *Metadata (.bb + Patches):* Software layers containing
@@ -420,14 +420,14 @@ build.
 Distro Layer
 ~~~~~~~~~~~~
 
-The distribution layer provides policy configurations for your
+A distribution layer provides policy configurations for your
 distribution. Best practices dictate that you isolate these types of
 configurations into their own layer. Settings you provide in
 ``conf/distro/distro.conf`` override similar settings that BitBake finds
 in your ``conf/local.conf`` file in the :term:`Build Directory`.
 
 The following list provides some explanation and references for what you
-typically find in the distribution layer:
+typically find in a distribution layer:
 
 -  *classes:* Class files (``.bbclass``) hold common functionality that
    can be shared among recipes in the distribution. When your recipes
@@ -454,7 +454,7 @@ typically find in the distribution layer:
 BSP Layer
 ~~~~~~~~~
 
-The BSP Layer provides machine configurations that target specific
+A BSP layer provides machine configurations that target specific
 hardware. Everything in this layer is specific to the machine for which
 you are building the image or the SDK. A common structure or form is
 defined for BSP layers. You can learn more about this structure in the
@@ -465,7 +465,7 @@ defined for BSP layers. You can learn more about this structure in the
    In order for a BSP layer to be considered compliant with the Yocto
    Project, it must meet some structural requirements.
 
-The BSP Layer's configuration directory contains configuration files for
+A BSP layer's configuration directory contains configuration files for
 the machine (``conf/machine/machine.conf``) and, of course, the layer
 (``conf/layer.conf``).
 
@@ -477,18 +477,18 @@ formfactors, graphics support systems, and so forth.
 .. note::
 
    While the figure shows several
-   recipes-\*
+   ``recipes-*``
    directories, not all these directories appear in all BSP layers.
 
 Software Layer
 ~~~~~~~~~~~~~~
 
-The software layer provides the Metadata for additional software
+A software layer provides the Metadata for additional software
 packages used during the build. This layer does not include Metadata
 that is specific to the distribution or the machine, which are found in
 their respective layers.
 
-This layer contains any recipes, append files, and patches, that your
+This layer contains any recipes, append files, and patches that your
 project needs.
 
 Sources
@@ -560,9 +560,8 @@ source tree used by the group).
 
 The canonical method through which to include a local project is to use the
 :ref:`ref-classes-externalsrc` class to include that local project. You use
-either the ``local.conf`` or a recipe's append file to override or set the
-recipe to point to the local directory on your disk to pull in the whole
-source tree.
+either ``local.conf`` or a recipe's append file to override or set the
+recipe to point to the local directory from which to fetch the source.
 
 Source Control Managers (Optional)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst
index d79173ff55..066d784314 100644
--- a/documentation/overview-manual/development-environment.rst
+++ b/documentation/overview-manual/development-environment.rst
@@ -240,7 +240,7 @@ and so forth.
 
    For information on finding out who is responsible for (maintains) a
    particular area of code in the Yocto Project, see the
-   ":doc:`../contributor-guide/identify-component`"
+   ":doc:`/contributor-guide/identify-component`"
    section of the Yocto Project and OpenEmbedded Contributor Guide.
 
 The Yocto Project ``poky`` Git repository also has an upstream
@@ -272,7 +272,7 @@ push them into the "contrib" area and subsequently request that the
 maintainer include them into an upstream branch. This process is called
 "submitting a patch" or "submitting a change." For information on
 submitting patches and changes, see the
-":doc:`../contributor-guide/submit-changes`" section in the Yocto Project
+":doc:`/contributor-guide/submit-changes`" section in the Yocto Project
 and OpenEmbedded Contributor Guide.
 
 In summary, there is a single point of entry for changes into the
@@ -347,7 +347,7 @@ Book <https://book.git-scm.com>`__.
    this type of change, you format the patch and then send the email
    using the Git commands ``git format-patch`` and ``git send-email``.
    For information on how to use these scripts, see the
-   ":doc:`../contributor-guide/submit-changes`" section in the Yocto Project
+   ":doc:`/contributor-guide/submit-changes`" section in the Yocto Project
    and OpenEmbedded Contributor Guide.
 
 Git
diff --git a/documentation/overview-manual/yp-intro.rst b/documentation/overview-manual/yp-intro.rst
index 15dfb3a6b6..40e9693a8d 100644
--- a/documentation/overview-manual/yp-intro.rst
+++ b/documentation/overview-manual/yp-intro.rst
@@ -51,7 +51,7 @@ Here are features and advantages of the Yocto Project:
    RISC-V and other architectures. Most ODMs, OSVs, and chip vendors create and
    supply BSPs that support their hardware. If you have custom silicon, you can
    create a BSP that supports that architecture. See
-   :doc:`ref-manual/yocto-project-supported-features` for details on the level
+   :doc:`/ref-manual/yocto-project-supported-features` for details on the level
    of support for some of these architectures.
 
    Aside from broad architecture support, the Yocto Project fully
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/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/variables.rst b/documentation/ref-manual/variables.rst
index 5c18b852d1..c6ae3fb8bc 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -2576,7 +2576,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 +2790,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 +3318,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 +3337,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 +3350,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 +3374,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 +3431,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 +5075,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.
 
@@ -8764,6 +8762,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 +10341,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 +10359,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 +10636,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 +10664,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 +10683,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/standards.md b/documentation/standards.md
index 8300d813dc..801efe3457 100644
--- a/documentation/standards.md
+++ b/documentation/standards.md
@@ -126,7 +126,16 @@ that most themes only style these two admonitions.
 
 ## ReStructured Text Syntax standards
 
-This section has not been filled yet
+### doc directive
+
+The [doc directive](https://www.sphinx-doc.org/en/master/usage/referencing.html#role-doc)
+allows to refer to another document within yocto-docs, like:
+
+    For more information, read :doc:`/bsp-guide/index`.
+
+Note that only "absolute" paths (starting with a '/') are allowed. The root
+directory of that path is documentation/, that is, :doc:`/bsp-guide/index`
+points at documentation/bsp-guide/index.rst.
 
 ## Adding screenshots
 
diff --git a/documentation/transitioning-to-a-custom-environment.rst b/documentation/transitioning-to-a-custom-environment.rst
index 6ff55e5619..a5f55c567a 100644
--- a/documentation/transitioning-to-a-custom-environment.rst
+++ b/documentation/transitioning-to-a-custom-environment.rst
@@ -8,8 +8,8 @@ Transitioning to a custom environment for systems development
 
 .. note::
 
-   So you've finished the :doc:`brief-yoctoprojectqs/index` and
-   glanced over the document :doc:`what-i-wish-id-known`, the latter contains
+   So you've finished the :doc:`/brief-yoctoprojectqs/index` and
+   glanced over the document :doc:`/what-i-wish-id-known`, the latter contains
    important information learned from other users. You're well prepared. But
    now, as you are starting your own project, it isn't exactly straightforward what
    to do. And, the documentation is daunting. We've put together a few hints to
diff --git a/documentation/what-i-wish-id-known.rst b/documentation/what-i-wish-id-known.rst
index 836097910d..ddee6ad749 100644
--- a/documentation/what-i-wish-id-known.rst
+++ b/documentation/what-i-wish-id-known.rst
@@ -49,7 +49,7 @@ contact us with other suggestions.
    their silicon. These layers have names such as "meta-intel" or "meta-ti". Try
    not to build layers from scratch. If you do have custom silicon, use one of
    these layers as a guide or template and familiarize yourself with the
-   :doc:`bsp-guide/index`.
+   :doc:`/bsp-guide/index`.
 
 #. **Do not put everything into one layer:**
    Use different layers to logically separate information in your build. As an
@@ -127,7 +127,7 @@ contact us with other suggestions.
    You can build and run a specific task for a specific package (including
    devshell) or even a single recipe. When developers first start using the
    Yocto Project, the instructions found in the
-   :doc:`brief-yoctoprojectqs/index` show how to create an image
+   :doc:`/brief-yoctoprojectqs/index` show how to create an image
    and then run or flash that image.  However, you can actually build just a
    single recipe. Thus, if some dependency or recipe isn't working, you can just
    say "bitbake foo" where "foo" is the name for a specific recipe.  As you
diff --git a/meta/classes-recipe/rust-target-config.bbclass b/meta/classes-recipe/rust-target-config.bbclass
index c04940ce54..906a5083d7 100644
--- a/meta/classes-recipe/rust-target-config.bbclass
+++ b/meta/classes-recipe/rust-target-config.bbclass
@@ -77,8 +77,33 @@ def llvm_features_from_tune(d):
         f.append("+a15")
     if 'cortexa17' in feat:
         f.append("+a17")
-    if ('riscv64' in feat) or ('riscv32' in feat):
-        f.append("+a,+c,+d,+f,+m")
+    if 'rv' in feat:
+        if 'm' in feat:
+            f.append("+m")
+        if 'a' in feat:
+            f.append("+a")
+        if 'f' in feat:
+            f.append("+f")
+        if 'd' in feat:
+            f.append("+d")
+        if 'c' in feat:
+            f.append("+c")
+        if 'v' in feat:
+            f.append("+v")
+        if 'zicbom' in feat:
+            f.append("+zicbom")
+        if 'zicsr' in feat:
+            f.append("+zicsr")
+        if 'zifencei' in feat:
+            f.append("+zifencei")
+        if 'zba' in feat:
+            f.append("+zba")
+        if 'zbb' in feat:
+            f.append("+zbb")
+        if 'zbc' in feat:
+            f.append("+zbc")
+        if 'zbs' in feat:
+            f.append("+zbs")
     return f
 llvm_features_from_tune[vardepvalue] = "${@llvm_features_from_tune(d)}"
 
@@ -236,19 +261,19 @@ TARGET_POINTER_WIDTH[powerpc64le] = "64"
 TARGET_C_INT_WIDTH[powerpc64le] = "32"
 MAX_ATOMIC_WIDTH[powerpc64le] = "64"
 
-## riscv32gc-unknown-linux-{gnu, musl}
-DATA_LAYOUT[riscv32gc] = "e-m:e-p:32:32-i64:64-n32-S128"
-TARGET_ENDIAN[riscv32gc] = "little"
-TARGET_POINTER_WIDTH[riscv32gc] = "32"
-TARGET_C_INT_WIDTH[riscv32gc] = "32"
-MAX_ATOMIC_WIDTH[riscv32gc] = "32"
+## riscv32-unknown-linux-{gnu, musl}
+DATA_LAYOUT[riscv32] = "e-m:e-p:32:32-i64:64-n32-S128"
+TARGET_ENDIAN[riscv32] = "little"
+TARGET_POINTER_WIDTH[riscv32] = "32"
+TARGET_C_INT_WIDTH[riscv32] = "32"
+MAX_ATOMIC_WIDTH[riscv32] = "32"
 
-## riscv64gc-unknown-linux-{gnu, musl}
-DATA_LAYOUT[riscv64gc] = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"
-TARGET_ENDIAN[riscv64gc] = "little"
-TARGET_POINTER_WIDTH[riscv64gc] = "64"
-TARGET_C_INT_WIDTH[riscv64gc] = "32"
-MAX_ATOMIC_WIDTH[riscv64gc] = "64"
+## riscv64-unknown-linux-{gnu, musl}
+DATA_LAYOUT[riscv64] = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"
+TARGET_ENDIAN[riscv64] = "little"
+TARGET_POINTER_WIDTH[riscv64] = "64"
+TARGET_C_INT_WIDTH[riscv64] = "32"
+MAX_ATOMIC_WIDTH[riscv64] = "64"
 
 ## loongarch64-unknown-linux-{gnu, musl}
 DATA_LAYOUT[loongarch64] = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"
@@ -271,19 +296,11 @@ def arch_to_rust_target_arch(arch):
         return "arm"
     elif arch == "powerpc64le":
         return "powerpc64"
-    elif arch == "riscv32gc":
-        return "riscv32"
-    elif arch == "riscv64gc":
-        return "riscv64"
     else:
         return arch
 
 # Convert a rust target string to a llvm-compatible triplet
 def rust_sys_to_llvm_target(sys):
-    if sys.startswith('riscv32gc-'):
-        return sys.replace('riscv32gc-', 'riscv32-', 1)
-    if sys.startswith('riscv64gc-'):
-        return sys.replace('riscv64gc-', 'riscv64-', 1)
     return sys
 
 # generates our target CPU value
@@ -380,9 +397,9 @@ def rust_gen_target(d, thing, wd, arch):
     else:
         tspec['env'] = "gnu"
     if "riscv64" in tspec['llvm-target']:
-        tspec['llvm-abiname'] = "lp64d"
+        tspec['llvm-abiname'] = d.getVar('TUNE_RISCV_ABI')
     if "riscv32" in tspec['llvm-target']:
-        tspec['llvm-abiname'] = "ilp32d"
+        tspec['llvm-abiname'] = d.getVar('TUNE_RISCV_ABI')
     if "loongarch64" in tspec['llvm-target']:
         tspec['llvm-abiname'] = "lp64d"
     tspec['vendor'] = "unknown"
diff --git a/meta/conf/machine/include/riscv/README b/meta/conf/machine/include/riscv/README
new file mode 100644
index 0000000000..beef68f523
--- /dev/null
+++ b/meta/conf/machine/include/riscv/README
@@ -0,0 +1,122 @@
+2025/06/08 - Mark Hatle <mark.hatle@amd.com>
+ - Initial Revision
+
+The RISC-V ISA is broken into two parts, a base ISA and extensions.  As
+of the writing of this document these are documented at:
+
+https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications
+
+Specifically "The RISC-V Instruction Set Manual Volume I: Unprivileged ISA"
+was used to create this implementation.
+
+Requirements
+------------
+As RISC-V is a “variable” ISA (a base isa plus numerous extensions), a
+mechanism is required to specify a series of ISA features that a user or
+tune can use to specify a specific CPU instantiation.
+
+Not all ratified or draft features should or can be implemented with the
+available resources.
+
+The implementation should work for Linux, baremetal (newlib), zephyr and
+other operating systems.  Supported extensions should be based on
+real-world examples.
+
+Linux
+-----
+Linux required base and support extensions should be available.  Linux
+requires:
+* Base: rv32ima & rv64ima
+* Optional FPU: fd
+* Optional RISCV_ISA_C: c
+* Optiona RISCV_ISA_V: v
+* Required additional: _zicsr_zifencei
+* Optional RISCV_ISA_ZBA: _zba
+* Optional RISCV_ISA_ZBB: _zbb
+* Optional RISCV_ISA_ZBC: _zbc (not supported by current QEMU design)
+
+See: https://git.yoctoproject.org/linux-yocto/tree/arch/riscv/Makefile?h=v6.12/base
+
+Baremetal
+---------
+AMD Microblaze-V FPGA support uses the following static configurations:
+Base: rv32e, rv32i, rv64i
+Extensions: m, a, f, d, c, b, zicsr, zifencei
+
+Zephyr
+------
+AMD Microblaze-V development for Zephyr is the same as Baremetal, with a
+few additional extensions: zbc, zicbom
+
+ABI
+---
+The following ABIs are supported GNU tools and some combination of systems.
+* ilp32 - Integer, long and pointer are 32-bit
+* lp64 - Long and pointer are 64-bit (integer is 32-bit)
+
+The ABI is dependent upon the core system implementation, as ilp32 can
+only used on an ‘rv32’ system, while lp64 can only be used on an ‘rv64’
+system.
+
+There are additional variations of each ABI:
+* e - used with the Reduced register extension
+* f - used when single precision floating point (but not double precision) is
+      enabled
+* d - used when both single and double precision floating point is enabled
+
+Based on the above, the ABI should be automatically determined based on
+the selected Base ISA and Extensions.
+
+Implementation
+--------------
+To make it easier to generate the RISC-V canonical arch, ISA based -march,
+and the ABI string, a few new variables are added for specific RISC-V items.
+
+TUNE_RISCV_ARCH - This contains the canonical GNU style arch, generally this
+                  will evaluate to "riscv32" or "riscv64".
+
+TUNE_RISCV_MARCH - This will contain an ISA based -march string compatible
+                   with gcc and similar toolchains.  For example:
+                   rv32imacfd_zicsr_zifencei
+
+TUNE_RISCV_ABI - This is the generated ABI that corresponds to the ARCH and
+                 MARCH/ISA values.  For riscv32, the value will be ilp32
+                 (int, long and pointer is 32-bit) with the ISA
+                 variation.  For riscv64, the value will be lp64 (long
+                 and pointer are 64-bit bit, while int is 32-bit) with the
+                 ISA variation.  The ISA affects the ABI when the 'e', 'f'
+                 and 'd' extension are used.
+
+TUNE_RISCV_PKGARCH - This is the generated PKGARCH value.
+
+The standard variables are defined as:
+
+TUNE_CCARGS = "${@ '-march=${TUNE_RISCV_MARCH} -mabi=${TUNE_RISCV_ABI}' if not d.getVar('TUNE_CCARGS:tune-${DEFAULTTUNE}') else 'TUNE_CCARGS:tune-${DEFAULTTUNE}'}"
+
+The above will allow the user to specify an implementation specific
+TUNE_CCARGS for a given processor tune if the default implementtion is
+not adequate for some reason.  It is expected that most, if not all,
+implementations will use the default behavior.
+
+TUNE_ARCH = "${TUNE_RISCV_ARCH}"
+TUNE_PKGARCH = "${TUNE_RISCV_PKGARCH}"
+
+The above two will always base their setting off the standard TUNE_FEATURES.
+
+Ratified and draft extensions should be implemented as TUNE_FEATURES in
+the arch-riscv.inc file.
+
+Vendor specific extensions and processor specific settings should go
+into a 'tune-<vendor>.inc' file, with tune-riscv.inc being reserved for
+general purpose tunes.
+
+TUNE_FEATURE Helper
+-------------------
+A special helper function has been written that will convert RISC-V ISA
+notation into TUNE_FEATURE notion, for example:
+
+rv32g -> rv 32 i m a f d zicsr zifencei
+
+The helper can be called using oe.tune.riscv_isa_to_tune("<ISA>") such as
+oe.tune.riscv_isa_to_tune("rv64gc") which would return:
+ rv 64 i m a f d c zicsr zifencei
diff --git a/meta/conf/machine/include/riscv/arch-riscv.inc b/meta/conf/machine/include/riscv/arch-riscv.inc
index b34064e78f..99bed8fde5 100644
--- a/meta/conf/machine/include/riscv/arch-riscv.inc
+++ b/meta/conf/machine/include/riscv/arch-riscv.inc
@@ -1,14 +1,140 @@
 # RISCV Architecture definition
 
-DEFAULTTUNE ?= "riscv64"
+# Based on the RISC-V Instruction Set Manual Volume I: Unprivileged ISA from May 2025
+# As well as the RISC-V options for using GCC (as of June 2025)
 
-TUNE_ARCH = "${TUNE_ARCH:tune-${DEFAULTTUNE}}"
-TUNE_PKGARCH = "${TUNE_PKGARCH:tune-${DEFAULTTUNE}}"
-TUNE_CCARGS:append = "${@bb.utils.contains('TUNE_FEATURES', 'riscv64nf', ' -mabi=lp64', ' ', d)}"
-TUNE_CCARGS:append = "${@bb.utils.contains('TUNE_FEATURES', 'riscv32nf', ' -mabi=ilp32', ' ', d)}"
+# Note: the following should be implemented in the order that GCC expects
+# -march= values to be defined in.
 
-TUNE_CCARGS:append = "${@bb.utils.contains('TUNE_FEATURES', 'riscv64nc', ' -march=rv64imafd', ' ', d)}"
+# Base ISA
+# All supported march strings must start with rv32 or rv64
+TUNEVALID[rv] = "RISC-V"
+TUNE_RISCV_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "rv", "riscv", "", d)}"
+TUNE_RISCV_MARCH = "${@bb.utils.contains("TUNE_FEATURES", "rv", "rv", "", d)}"
+TUNE_RISCV_ABI = ""
 
+# There are two primary ABIs, ilp32 and lp64
+# There are variants of both, that appears to be based on extensions above
+# For example:
+#   rv32i uses ilp32, rv32e uses ilp32e, rv32f uses ilp32f
+#   rv64i uses lp64, rv64if uses lp64f, rv64id uses lp64d
+TUNEVALID[32] = "ISA XLEN - 32-bit"
+TUNECONFLICTS[32] = "64"
+TUNE_RISCV_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "32", "32", "", d)}"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains("TUNE_FEATURES", "32", "32", "", d)}"
+TUNE_RISCV_ABI .= "${@bb.utils.contains("TUNE_FEATURES", "32", "ilp32", "", d)}"
+
+TUNEVALID[64] = "ISA XLEN - 64-bit"
+TUNECONFLICTS[64] = "32"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains("TUNE_FEATURES", "64", "64", "", d)}"
+TUNE_RISCV_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "64", "64", "", d)}"
+TUNE_RISCV_ABI .= "${@bb.utils.contains("TUNE_FEATURES", "64", "lp64", "", d)}"
+
+# The package arch starts with the canonical arch, but adds some extensions to make
+# package compatibility clear
+TUNE_RISCV_PKGARCH = "${TUNE_RISCV_ARCH}"
+
+# i, e, or g are defined by gcc, but 'g' refers to 'i' + extensions 'MAFD Zicsr Zifencei'
+# So 'g' will not be defined here as it is an abbreviation of the expanded version
+TUNEVALID[e] = "Reduced register base integer extension"
+TUNECONFLICTS[e] = "i"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains("TUNE_FEATURES", "e", "e", "", d)}"
+TUNE_RISCV_ABI .= "${@bb.utils.contains("TUNE_FEATURES", "e", "e", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "e", "e", "", d)}"
+
+TUNEVALID[i] = "Base integer extension"
+TUNECONFLICTS[i] = "e"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains("TUNE_FEATURES", "i", "i", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "i", "i", "", d)}"
+
+# Extensions
+TUNEVALID[m] = "Integer multiplication and division extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m", "m", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m", "m", "", d)}"
+
+TUNEVALID[a] = "Atomic extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains("TUNE_FEATURES", "a", "a", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "a", "a", "", d)}"
+
+TUNEVALID[f] = "Single-precision floating-point extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "f d", "f", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "f d", "f", "", d)}"
+
+TUNEVALID[d] = "Double-precision floating-point extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains("TUNE_FEATURES", "d", "d", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "d", "d", "", d)}"
+
+# Only f OR d, but just one
+TUNE_RISCV_ABI .= "${@bb.utils.contains("TUNE_FEATURES", "d", "d", bb.utils.contains("TUNE_FEATURES", "f", "f", "", d), d)}"
+
+TUNEVALID[c] = "Compressed extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains("TUNE_FEATURES", "c", "c", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "c", "c", "", d)}"
+
+TUNEVALID[b] = "Bit Manipulation extension"
+# Handled below via zba, zbb, zbs
+# This matches current Linux kernel behavior
+#TUNE_RISCV_MARCH .= "${@bb.utils.contains("TUNE_FEATURES", "b", "b", "", d)}"
+#TUNE_RISCV_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "b", "b", "", d)}"
+
+TUNEVALID[v] = "Vector operations extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains("TUNE_FEATURES", "v", "v", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "v", "v", "", d)}"
+
+# Now the special Z extensions
+TUNEVALID[zicbom] = "Cache-block management extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "zicbom", "_zicbom", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "zicbom", "_zicbom", "", d)}"
+
+TUNEVALID[zicsr] = "Control and status register access extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "zicsr f d", "_zicsr", "", d)}"
+# If zicsr (or zifencei) is in the path, OpenSBI fails to use the extensions, do to (Makefile):
+#   # Check whether the assembler and the compiler support the Zicsr and Zifencei extensions
+#   CC_SUPPORT_ZICSR_ZIFENCEI := $(shell $(CC) $(CLANG_TARGET) $(RELAX_FLAG) -nostdlib -march=rv$(OPENSBI_CC_XLEN)imafd_zicsr_zifencei -x c /dev/null -o /dev/null 2>&1 | grep -e "zicsr" -e "zifencei" > /dev/null && echo n || echo y)
+# this will match on the path containing zicsr or zifencei when an error is reported, which
+# will always happens in this check.
+#
+# Yocto Project Bugzilla 15897
+#
+#TUNE_RISCV_PKGARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "zicsr f d", "_zicsr", "", d)}"
+
+TUNEVALID[zifencei] = "Instruction-fetch fence extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains("TUNE_FEATURES", "zifencei", "_zifencei", "", d)}"
+# See above Bug 15897
+#TUNE_RISCV_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "zifencei", "_zifencei", "", d)}"
+
+TUNEVALID[zba] = "Address bit manipulation extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "b zba", "_zba", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "b zba", "_zba", "", d)}"
+
+TUNEVALID[zbb] = "Basic bit manipulation extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "b zbb", "_zbb", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "b zbb", "_zbb", "", d)}"
+
+TUNEVALID[zbc] = "Carry-less multiplication extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "zbc", "_zbc", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "zbc", "_zbc", "", d)}"
+
+TUNEVALID[zbs] = "Single-bit manipulation extension"
+TUNE_RISCV_MARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "b zbs", "_zbs", "", d)}"
+TUNE_RISCV_PKGARCH .= "${@bb.utils.contains_any("TUNE_FEATURES", "b zbs", "_zbs", "", d)}"
+
+# Construct TUNE_CCARGS
+# This should result in a CCARG similar to:
+#   -march=rv32imac -mabi=ilp32
+TUNE_CCARGS = "${@ '-march=${TUNE_RISCV_MARCH} -mabi=${TUNE_RISCV_ABI}' if not d.getVar('TUNE_CCARGS:tune-${DEFAULTTUNE}') else 'TUNE_CCARGS:tune-${DEFAULTTUNE}'}"
+
+# Construct TUNE_ARCH
+# This should result in an arch string similar to:
+#   riscv32
+TUNE_ARCH = "${TUNE_RISCV_ARCH}"
+
+# Construct TUNE_PKGARCH
+# This should result in a package are like:
+#    riscv32imac
+TUNE_PKGARCH = "${TUNE_RISCV_PKGARCH}"
+
+# Misc settings
 # Fix: ld: unrecognized option '--hash-style=sysv'
 LINKER_HASH_STYLE:libc-newlib = ""
 LINKER_HASH_STYLE:libc-picolibc = ""
diff --git a/meta/conf/machine/include/riscv/tune-riscv.inc b/meta/conf/machine/include/riscv/tune-riscv.inc
index 804712077e..12c1125c8b 100644
--- a/meta/conf/machine/include/riscv/tune-riscv.inc
+++ b/meta/conf/machine/include/riscv/tune-riscv.inc
@@ -1,41 +1,23 @@
 require conf/machine/include/riscv/arch-riscv.inc
 
-TUNEVALID[riscv64] = "Enable 64-bit RISC-V optimizations"
-TUNEVALID[riscv32] = "Enable 32-bit RISC-V optimizations"
-
-TUNEVALID[riscv64nf] = "Enable 64-bit RISC-V optimizations no floating point"
-TUNEVALID[riscv32nf] = "Enable 32-bit RISC-V optimizations no floating point"
-
-TUNEVALID[riscv64nc] = "Enable 64-bit RISC-V optimizations without compressed instructions"
-
-TUNEVALID[bigendian] = "Big endian mode"
+DEFAULTTUNE ?= "riscv64"
 
 AVAILTUNES += "riscv64 riscv32 riscv64nc riscv64nf riscv32nf"
 
 # Default
-TUNE_FEATURES:tune-riscv64 = "riscv64"
-TUNE_ARCH:tune-riscv64 = "riscv64"
-TUNE_PKGARCH:tune-riscv64 = "riscv64"
-PACKAGE_EXTRA_ARCHS:tune-riscv64 = "riscv64"
+TUNE_FEATURES:tune-riscv64 := "${@oe.tune.riscv_isa_to_tune("rv64gc")}"
+PACKAGE_EXTRA_ARCHS:tune-riscv64 = "${TUNE_RISCV_PKGARCH}"
 
-TUNE_FEATURES:tune-riscv32 = "riscv32"
-TUNE_ARCH:tune-riscv32 = "riscv32"
-TUNE_PKGARCH:tune-riscv32 = "riscv32"
-PACKAGE_EXTRA_ARCHS:tune-riscv32 = "riscv32"
+TUNE_FEATURES:tune-riscv32 := "${@oe.tune.riscv_isa_to_tune("rv32gc")}"
+PACKAGE_EXTRA_ARCHS:tune-riscv32 = "${TUNE_RISCV_PKGARCH}"
 
 # No float
-TUNE_FEATURES:tune-riscv64nf = "${TUNE_FEATURES:tune-riscv64} riscv64nf"
-TUNE_ARCH:tune-riscv64nf = "riscv64"
-TUNE_PKGARCH:tune-riscv64nf = "riscv64nf"
-PACKAGE_EXTRA_ARCHS:tune-riscv64nf = "riscv64nf"
+TUNE_FEATURES:tune-riscv64nf := "${@oe.tune.riscv_isa_to_tune("rv64imac_zicsr_zifencei")}"
+PACKAGE_EXTRA_ARCHS:tune-riscv64nf = "${TUNE_RISCV_PKGARCH}"
 
-TUNE_FEATURES:tune-riscv32nf = "${TUNE_FEATURES:tune-riscv32} riscv32nf"
-TUNE_ARCH:tune-riscv32nf = "riscv32"
-TUNE_PKGARCH:tune-riscv32nf = "riscv32nf"
-PACKAGE_EXTRA_ARCHS:tune-riscv32nf = "riscv32nf"
+TUNE_FEATURES:tune-riscv32nf := "${@oe.tune.riscv_isa_to_tune("rv32imac_zicsr_zifencei")}"
+PACKAGE_EXTRA_ARCHS:tune-riscv32nf = "${TUNE_RISCV_PKGARCH}"
 
 # no compressed
-TUNE_FEATURES:tune-riscv64nc = "${TUNE_FEATURES:tune-riscv64} riscv64nc"
-TUNE_ARCH:tune-riscv64nc = "riscv64"
-TUNE_PKGARCH:tune-riscv64nc = "riscv64nc"
-PACKAGE_EXTRA_ARCHS:tune-riscv64nc = "riscv64nc"
+TUNE_FEATURES:tune-riscv64nc := "${@oe.tune.riscv_isa_to_tune("rv64imafd_zicsr_zifencei")}"
+PACKAGE_EXTRA_ARCHS:tune-riscv64nc = "${TUNE_RISCV_PKGARCH}"
diff --git a/meta/conf/machine/qemuriscv32.conf b/meta/conf/machine/qemuriscv32.conf
index d3858dc051..aff36c28a5 100644
--- a/meta/conf/machine/qemuriscv32.conf
+++ b/meta/conf/machine/qemuriscv32.conf
@@ -2,9 +2,9 @@
 #@NAME: generic riscv32 machine
 #@DESCRIPTION: Machine configuration for running a generic riscv32
 
-require conf/machine/include/riscv/qemuriscv.inc
+DEFAULTTUNE ?= "riscv32"
 
-DEFAULTTUNE = "riscv32"
+require conf/machine/include/riscv/qemuriscv.inc
 
 PREFERRED_VERSION_openocd-native = "riscv"
 PREFERRED_VERSION_openocd = "riscv"
diff --git a/meta/lib/oe/__init__.py b/meta/lib/oe/__init__.py
index dd094a874a..73de774266 100644
--- a/meta/lib/oe/__init__.py
+++ b/meta/lib/oe/__init__.py
@@ -12,4 +12,4 @@ __path__ = extend_path(__path__, __name__)
 BBIMPORTS = ["qa", "data", "path", "utils", "types", "package", "packagedata", \
              "packagegroup", "sstatesig", "lsb", "cachedpath", "license", "qemu", \
              "reproducible", "rust", "buildcfg", "go", "spdx30_tasks", "spdx_common", \
-             "cve_check"]
+             "cve_check", "tune"]
diff --git a/meta/lib/oe/rust.py b/meta/lib/oe/rust.py
index 185553eeeb..1dc9cf150d 100644
--- a/meta/lib/oe/rust.py
+++ b/meta/lib/oe/rust.py
@@ -8,6 +8,4 @@
 def arch_to_rust_arch(arch):
     if arch == "ppc64le":
         return "powerpc64le"
-    if arch in ('riscv32', 'riscv64'):
-        return arch + 'gc'
     return arch
diff --git a/meta/lib/oe/tune.py b/meta/lib/oe/tune.py
new file mode 100644
index 0000000000..7fda19430d
--- /dev/null
+++ b/meta/lib/oe/tune.py
@@ -0,0 +1,81 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+# riscv_isa_to_tune(isa)
+#
+# Automatically translate a RISC-V ISA string to TUNE_FEATURES
+#
+# Abbreviations, such as rv32g -> rv32imaffd_zicsr_zifencei are supported.
+#
+# Profiles, such as rva22u64, are NOT supported, you must use ISA strings.
+#
+def riscv_isa_to_tune(isa):
+    _isa = isa.lower()
+
+    feature = []
+    iter = 0
+
+    # rv or riscv
+    if _isa[iter:].startswith('rv'):
+        feature.append('rv')
+        iter = iter + 2
+    elif _isa[iter:].startswith('riscv'):
+        feature.append('rv')
+        iter = iter + 5
+    else:
+        # Not a risc-v ISA!
+        return _isa
+
+    while (_isa[iter:]):
+        # Skip _ and whitespace
+        if _isa[iter] == '_' or _isa[iter].isspace():
+            iter = iter + 1
+            continue
+
+        # Length, just capture numbers here
+        if _isa[iter].isdigit():
+            iter_end = iter
+            while iter_end < len(_isa) and _isa[iter_end].isdigit():
+                iter_end = iter_end + 1
+
+            feature.append(_isa[iter:iter_end])
+            iter = iter_end
+            continue
+
+        # Typically i, e or g is next, followed by extensions.
+        # Extensions are single character, except for Z, Ss, Sh, Sm, Sv, and X
+
+        # If the extension starts with 'Z', 'S' or 'X' use the name until the next _, whitespace or end
+        if _isa[iter] in ['z', 's', 'x']:
+            ext_type = _isa[iter]
+            iter_end = iter + 1
+
+            # Multicharacter extension, these are supposed to have a _ before the next multicharacter extension
+            # See 37.4 and 37.5:
+            # 37.4: Underscores "_" may be used to separate ISA extensions...
+            # 37.5: All multi-letter extensions ... must be separated from other multi-letter extensions by an underscore...
+            # Some extensions permit only alphabetic characters, while others allow alphanumeric chartacters
+            while iter_end < len(_isa) and _isa[iter_end] != "_" and not _isa[iter_end].isspace():
+                iter_end = iter_end + 1
+
+            feature.append(_isa[iter:iter_end])
+            iter = iter_end
+            continue
+
+        # 'g' is special, it's an abbreviation for imafd_zicsr_zifencei
+        # When expanding the abbreviation, any additional letters must appear before the _z* extensions
+        if _isa[iter] == 'g':
+            _isa = 'imafd' + _isa[iter+1:] + '_zicsr_zifencei'
+            iter = 0
+            continue
+
+        feature.append(_isa[iter])
+        iter = iter + 1
+        continue
+
+    # Eliminate duplicates, but preserve the order
+    feature = list(dict.fromkeys(feature))
+    return ' '.join(feature)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index 2a47f90e32..b60a6e6c38 100644
--- a/meta/lib/oeqa/utils/commands.py
+++ b/meta/lib/oeqa/utils/commands.py
@@ -285,7 +285,20 @@ def get_bb_vars(variables=None, target=None, postconfig=None):
     return values
 
 def get_bb_var(var, target=None, postconfig=None):
-    return get_bb_vars([var], target, postconfig)[var]
+    if postconfig:
+        return bitbake("-e %s" % target or "", postconfig=postconfig).output
+    else:
+        # Fast-path for the non-postconfig case
+        cmd = ["bitbake-getvar", "--quiet", "--value", var]
+        if target:
+            cmd.extend(["--recipe", target])
+        try:
+            return subprocess.run(cmd, check=True, text=True, stdout=subprocess.PIPE).stdout.strip()
+        except subprocess.CalledProcessError as e:
+            # We need to return None not the empty string if the variable hasn't been set.
+            if e.returncode == 1:
+                return None
+            raise
 
 def get_test_layer(bblayers=None):
     if bblayers is None:
diff --git a/meta/recipes-devtools/go/go-binary-native_1.24.4.bb b/meta/recipes-devtools/go/go-binary-native_1.24.4.bb
index 9f788536c4..a5324d0f06 100644
--- a/meta/recipes-devtools/go/go-binary-native_1.24.4.bb
+++ b/meta/recipes-devtools/go/go-binary-native_1.24.4.bb
@@ -17,6 +17,7 @@ UPSTREAM_CHECK_URI = "https://golang.org/dl/"
 UPSTREAM_CHECK_REGEX = "go(?P<pver>\d+(\.\d+)+)\.linux"
 
 CVE_PRODUCT = "golang:go"
+CVE_STATUS[CVE-2024-3566] = "not-applicable-platform: Issue only applies on Windows"
 
 S = "${WORKDIR}/go"
 
diff --git a/meta/recipes-devtools/go/go-common.inc b/meta/recipes-devtools/go/go-common.inc
index ca8469dbd9..a79c90faf8 100644
--- a/meta/recipes-devtools/go/go-common.inc
+++ b/meta/recipes-devtools/go/go-common.inc
@@ -21,6 +21,7 @@ UPSTREAM_CHECK_REGEX = "(?P<pver>\d+(\.\d+)+)\.src\.tar"
 
 # all recipe variants are created from the same product
 CVE_PRODUCT = "golang:go"
+CVE_STATUS[CVE-2024-3566] = "not-applicable-platform: Issue only applies on Windows"
 
 INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
 SSTATE_SCAN_CMD = "true"