meta-arm-systemready/arm-systemready-linux-distros-fedora: remove

Fedora 39 is very obsolete and has been removed from the Fedora mirrors. If someone needs this then this commit can be reverted and the recipe upgraded to the latest Fedora release. Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>
optee-os: Fix CVE-2026-33662
2026-07-18 04:27:08 +00:00 · 2026-06-18 09:46:22 -04:00 · 2026-05-21 06:00:08 -04:00 · 2026-05-21 06:00:08 -04:00 · 2025-11-05 09:35:03 -05:00 · 2025-09-08 10:00:15 -04:00
684 changed files with 28847 additions and 42410 deletions
@@ -1,2 +0,0 @@
-[b4]
-	send-series-to = meta-arm@lists.yoctoproject.org
@@ -1,4 +1,4 @@
-image: ${MIRROR_GHCR}/siemens/kas/kas:5.2
+image: ${MIRROR_GHCR}/siemens/kas/kas:4.3.2

 variables:
  # These are needed as the k8s executor doesn't respect the container
@@ -9,16 +9,18 @@ variables:
  CPU_REQUEST: ""
  # The default machine tag for the build jobs
  DEFAULT_TAG: ""
-  # The directory to use as the persistent cache (the root for DL_DIR,
-  # SSTATE_DIR, etc). The default is the build tree which will not be
-  # persistent, so this should be set in the runner.
-  CACHE_DIR: $CI_PROJECT_DIR
+  # The machine tag for the ACS test jobs
+  ACS_TAG: ""
+  # The directory to use as the persistent cache (the root for DL_DIR, SSTATE_DIR, etc)
+  CACHE_DIR: $CI_BUILDS_DIR/persist
  # The container mirror to use
  MIRROR_GHCR: ghcr.io
+  # Whether to run the SystemReady ACS tests
+  ACS_TEST: 0
  # The list of extra Kas fragments to be used when building
  EXTRA_KAS_FILES: ""
-  # Whether warnings should be fatal (0/1)
-  FATAL_WARNINGS: 0
+  # The NVD API key to use when fetching CVEs
+  NVDCVE_API_KEY: ""

 stages:
  - prep
@@ -31,22 +33,28 @@ stages:
  stage: build
  interruptible: true
  variables:
-    KUBERNETES_CPU_REQUEST: $CPU_REQUEST
    KAS_WORK_DIR: $CI_PROJECT_DIR/work
-    KAS_BUILD_DIR: $KAS_WORK_DIR/build
-    # Set this in the environment to enable local repository caches
-    KAS_REPO_REF_DIR: ""
+    KAS_REPO_REF_DIR: $CACHE_DIR/repos
    SSTATE_DIR: $CACHE_DIR/sstate
    DL_DIR: $CACHE_DIR/downloads
    BB_LOGCONFIG: $CI_PROJECT_DIR/ci/logging.yml
-    IMAGE_DIR: $KAS_BUILD_DIR/tmp/deploy/images
+    TOOLCHAIN_DIR: $CACHE_DIR/toolchains
+    IMAGE_DIR: $CI_PROJECT_DIR/work/build/tmp/deploy/images
+    TOOLCHAIN_LINK_DIR: $CI_PROJECT_DIR/work/build/toolchains
  before_script:
+    - echo KAS_WORK_DIR = $KAS_WORK_DIR
+    - echo SSTATE_DIR = $SSTATE_DIR
+    - echo DL_DIR = $DL_DIR
    - rm -rf $KAS_WORK_DIR
-    - mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_DIR
+    - mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
+    # Must do this here, as it's the only way to make sure the toolchain is installed on the same builder
+    - ./ci/get-binary-toolchains $DL_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR

 # Generalised fragment to do a Kas build
 .build:
  extends: .setup
+  variables:
+    KUBERNETES_CPU_REQUEST: $CPU_REQUEST
  rules:
    # Don't run MR pipelines
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
@@ -63,24 +71,17 @@ stages:
    # Catch all for everything else
    - if: '$KERNEL != "linux-yocto-dev"'
  script:
-    - |
-      KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME" $EXTRA_KAS_FILES):lockfile.yml
-      echo KASFILES=$KASFILES
-      kas dump --update --force-checkout --resolve-refs --resolve-env $KASFILES
-      kas build $KASFILES
-      if [ $FATAL_WARNINGS -ne 0 ]; then
-        ./ci/check-warnings $KAS_BUILD_DIR/warnings.log
-      fi
-      kas shell ci/base.yml:lockfile.yml --command "$CI_PROJECT_DIR/ci/junit.sh $KAS_WORK_DIR/build"
+    - KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME" $EXTRA_KAS_FILES):lockfile.yml
+    - echo KASFILES=$KASFILES
+    - kas dump --update --force-checkout --resolve-refs --resolve-env $KASFILES
+    - kas build $KASFILES
+    - ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
  artifacts:
    name: "logs"
-    when: on_failure
-    expire_in: 1 week
+    when: always
    paths:
-      - $KAS_BUILD_DIR/tmp*/work*/**/temp/log.do_*.*
-      - $KAS_BUILD_DIR/tmp*/work*/**/testimage/*
-    reports:
-      junit: $KAS_BUILD_DIR/tmp/log/oeqa/junit.xml
+      - $CI_PROJECT_DIR/work/build/tmp*/work*/**/temp/log.do_*.*
+      - $CI_PROJECT_DIR/work/build/tmp*/work*/**/testimage/*

 #
 # Prep stage, update repositories once.
@@ -93,44 +94,44 @@ update-repos:
    exit_codes: 128
  script:
    - |
-      exit_code=0
-
-      # Dump the environment for reference
-      printenv
-
-      # Update the reference repositories if needed
-      if [ -n "$KAS_REPO_REF_DIR" ]; then
-        flock --verbose --timeout 60 $KAS_REPO_REF_DIR --command ./ci/update-repos || exit_code=$?
-        # Exit now if that failed, unless the status was 128 (fetch failed)
-        test $exit_code != 0 -a $exit_code != 128 && exit 1
-      fi
-
+      flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos
      # Only generate if doesn't already exist, to allow feature branches to drop one in.
      if test -f lockfile.yml; then
        echo Using existing lockfile.yml
      else
        # Be sure that this is the complete list of layers being fetched
-        kas dump --lock --update ci/qemuarm64.yml:ci/meta-openembedded.yml:ci/clang.yml | tee lockfile.yml
+        kas dump --lock --update ci/qemuarm64.yml:ci/meta-openembedded.yml:ci/clang.yml:ci/meta-virtualization.yml | tee lockfile.yml
      fi
-      exit $exit_code
  artifacts:
    name: "lockfile"
-    when: always
    paths:
      - lockfile.yml

 #
 # Build stage, the actual build jobs
 #
-# Available options for building are (VIRT _must_ be last for ssh override)
-#  DISTRO: [poky, poky-altcfg, poky-tiny]
-#  KERNEL: [linux-yocto, linux-yocto-dev]
-#  TOOLCHAINS: [gcc, clang]
+# Available options for building are
+#  DISTRO: [poky, poky-tiny]
+#  KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
+#  TOOLCHAINS: [gcc, clang, external-gccarm]
 #  TCLIBC: [glibc, musl]
 #  FIRMWARE: [u-boot, edk2]
 #  TS: [none, trusted-services]
+#  VIRT: [none, xen]
 #  TESTING: testimage
-#  SECUREDEBUG: [none, secure-debug]
+
+arm-systemready-ir-acs:
+  extends: .build
+  timeout: 12h
+  parallel:
+    matrix:
+      # arm-systemready-ir-acs must be specified after fvp-base for ordering
+      # purposes for the jobs-to-kas output. It is not enough to just have it
+      # in the job name because fvp-base.yml overwrites the target.
+      - PLATFORM: fvp-base
+        ARM_SYSTEMREADY_IR_ACS: arm-systemready-ir-acs
+  tags:
+    - ${ACS_TAG}

 # Validate layers are Yocto Project Compatible
 check-layers:
@@ -150,6 +151,7 @@ corstone1000-fvp:
        TESTING: [testimage, tftf]
      - FIRMWARE: none
        TESTING: testimage
+      - SYSTEMREADY_FIRMWARE: arm-systemready-firmware

 corstone1000-mps3:
  extends: .build
@@ -158,16 +160,6 @@ corstone1000-mps3:
      - FIRMWARE: corstone1000-firmware-only
        TESTING: [none, tftf]
      - FIRMWARE: none
-        SECUREDEBUG: [none, secure-debug]
-
-corstone1000-a320-fvp:
-  extends: .build
-  parallel:
-    matrix:
-      - FIRMWARE: corstone1000-firmware-only
-        TESTING: [testimage, tftf]
-      - FIRMWARE: none
-        TESTING: testimage

 documentation:
  extends: .setup
@@ -198,13 +190,21 @@ fvp-base:
    matrix:
      - TS: [none, fvp-base-ts]
        TESTING: testimage
-      - FIRMWARE: [u-boot, edk2]
-        TESTING: testimage
-      - LTS: lts-revisions
-        TESTING: testimage
-      - KERNEL: linux-yocto-dev
-        LATEST: latest-revisions
-        TESTING: testimage
+      - FIRMWARE: edk2
+      - SYSTEMREADY_FIRMWARE: arm-systemready-firmware
+
+arm-systemready-ir-acs:
+  extends: .build
+  timeout: 12h
+  parallel:
+    matrix:
+      # arm-systemready-ir-acs must be specified after fvp-base for ordering
+      # purposes for the jobs-to-kas output. It is not enough to just have it
+      # in the job name because fvp-base.yml overwrites the target.
+      - PLATFORM: [fvp-base, corstone1000-fvp]
+        ARM_SYSTEMREADY_IR_ACS: arm-systemready-ir-acs
+  tags:
+    - ${ACS_TAG}

 fvps:
  extends: .build
@@ -247,6 +247,12 @@ musca-b1:
 musca-s1:
  extends: .build

+n1sdp:
+  extends: .build
+  parallel:
+    matrix:
+      - TESTING: [none, n1sdp-ts, n1sdp-optee, tftf]
+
 pending-updates:
  extends: .setup
  # Only run this job for the default branch (master), or if forced with
@@ -262,18 +268,19 @@ pending-updates:
    # This configuration has all of the layers we need enabled
    - kas shell --update --force-checkout ci/qemuarm64.yml:ci/meta-openembedded.yml:ci/meta-secure-core.yml:lockfile.yml --command \
      "$CI_PROJECT_DIR/scripts/machine-summary.py -t report -o $CI_PROJECT_DIR/update-report $($CI_PROJECT_DIR/ci/listmachines.py meta-arm meta-arm-bsp)"
+  # Do this on x86 whilst the compilers are x86-only
+  tags:
+    - x86_64

 qemuarm64-secureboot:
  extends: .build
  parallel:
    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        FIRMWARE: [u-boot, edk2]
+      - KERNEL: [linux-yocto, linux-yocto-rt]
+        TOOLCHAINS: [gcc, clang]
        TCLIBC: [glibc, musl]
        TS: [none, qemuarm64-secureboot-ts]
        TESTING: testimage
-      - UEFISB: [none, uefi-secureboot]
-        TESTING: testimage
      - KERNEL: linux-yocto-dev
        TESTING: testimage

@@ -281,18 +288,26 @@ qemuarm64:
  extends: .build
  parallel:
    matrix:
-      - DISTRO: poky-tiny
+      - DISTRO: poky
+        KERNEL: [linux-yocto, linux-yocto-rt]
+        TOOLCHAINS: [gcc, clang]
        FIRMWARE: [u-boot, edk2]
        TESTING: testimage
+      - DISTRO: poky-tiny
+        TESTING: testimage
+      - VIRT: xen
+      - KERNEL: linux-yocto-dev
+        TESTING: testimage

 qemuarm-secureboot:
  extends: .build
  parallel:
    matrix:
-      - TOOLCHAINS: [gcc, clang]
+      - KERNEL: [linux-yocto, linux-yocto-rt]
+        TOOLCHAINS: [gcc, clang]
        TCLIBC: [glibc, musl]
        TESTING: testimage
-      - DISTRO: [poky, poky-altcfg]
+      - TOOLCHAINS: external-gccarm
        TESTING: testimage
      - KERNEL: linux-yocto-dev
        TESTING: testimage
@@ -301,40 +316,33 @@ qemuarm:
  extends: .build
  parallel:
    matrix:
-      - TOOLCHAINS: [gcc, clang]
+      - DISTRO: poky
+        KERNEL: [linux-yocto, linux-yocto-rt]
+        TOOLCHAINS: [gcc, clang]
+        FIRMWARE: [u-boot, edk2]
        TESTING: testimage
      - DISTRO: poky-tiny
        TESTING: testimage
+      - VIRT: xen
+      - KERNEL: linux-yocto-dev
+        TESTING: testimage

 qemuarmv5:
  extends: .build
  parallel:
    matrix:
      - DISTRO: poky
-        KERNEL: [linux-yocto, linux-yocto-dev]
+        KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
        TESTING: testimage
      - DISTRO: poky-tiny
        TESTING: testimage

-rdn2:
-  extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-
-rdv2:
-  extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-
 sbsa-ref:
  extends: .build
  parallel:
    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        TESTING: testimage
-      - DISTRO: poky-altcfg
+      - KERNEL: [linux-yocto, linux-yocto-rt]
+        TOOLCHAINS: [gcc, clang]
        TESTING: testimage
      - KERNEL: linux-yocto-dev
        TESTING: testimage
@@ -345,5 +353,8 @@ selftest:
    - KASFILES=./ci/qemuarm64.yml:./ci/selftest.yml:lockfile.yml
    - kas shell --update --force-checkout $KASFILES -c 'oe-selftest --num-processes 2 --select-tag meta-arm --run-all-tests'

+sgi575:
+  extends: .build
+
 toolchains:
  extends: .build
@@ -8,7 +8,7 @@ This repository contains the Arm layers for OpenEmbedded.

 * meta-arm-bsp

-  This layer contains machines for Arm reference platforms, for example FVP Base, Corstone1000, and Juno.
+  This layer contains machines for Arm reference platforms, for example FVP Base, N1SDP, and Juno.

 * meta-arm-toolchain

@@ -19,23 +19,19 @@ Other Directories

 * ci

-  This directory contains gitlab continuous integration configuration files (KAS yaml files) as well as scripts needed for this.
-
-* documentation
-
-  This directory contains information on the files in this repository, building, and other relevant documents.
+  This directory contains gitlab continuous integration configuration files (KAS yaml files) as well as scripts needed for this

 * kas

-  This directory contains KAS yaml files to describe builds for systems not used in CI.
+  This directory contains KAS yaml files to describe builds for systems not used in CI

 * scripts

-  This directory contains scripts used in running the CI tests.
+  This directory contains scripts used in running the CI tests

 Mailing List
 ------------
-To interact with the meta-arm developer community, please email the meta-arm mailing list at <meta-arm@lists.yoctoproject.org>.
+To interact with the meta-arm developer community, please email the meta-arm mailing list at meta-arm@lists.yoctoproject.org
 Currently, it is configured to only allow emails to members from those subscribed.
 To subscribe to the meta-arm mailing list, please go to
 https://lists.yoctoproject.org/g/meta-arm
@@ -46,51 +42,32 @@ Currently, we only accept patches from the meta-arm mailing list.  For general
 information on how to submit a patch, please read
 https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

-E-mail <meta-arm@lists.yoctoproject.org> with patches created using this process. You can configure git-send-email to automatically use this address for the meta-arm repository with the following git command:
+E-mail meta-arm@lists.yoctoproject.org with patches created using this process. You can configure git-send-email to automatically use this address for the meta-arm repository with the following git command:

-`$ git config --local --add sendemail.to meta-arm@lists.yoctoproject.org`
+$ git config --local --add sendemail.to meta-arm@lists.yoctoproject.org

 Commits and patches added should follow the OpenEmbedded patch guidelines:

 https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

 The component being changed in the shortlog should be prefixed with the layer name (without the meta- prefix), for example:
->  arm-bsp/trusted-firmware-a: decrease frobbing level

->  arm-toolchain/gcc: enable foobar v2
+  arm-bsp/trusted-firmware-a: decrease frobbing level

-All contributions are under the [MIT License](/COPYING.MIT).
-
-For a quick start guide on how to build and use meta-arm, go to [quick-start.md](/documentation/quick-start.md).
-
-For information on the continuous integration done on meta-arm and how to use it, go to [continuous-integration-and-kas.md](/documentation/continuous-integration-and-kas.md).
-
-Backporting
--------------
-Backporting patches to older releases may be done upon request, but only after a version of the patch has been accepted into the master branch.  This is done by adding the branch name to email subject line.  This should be between the square brackets (e.g., "[" and "]"), and before or after the "PATCH".  For example,
-> [nanbield PATCH] arm/linux-yocto: backport patch to fix 6.5.13 networking issues
-
-Automatic backporting will be done to all branches if the "Fixes: <SHA>" wording is added to the patch commit message.  This is similar to how the Linux kernel community does their LTS kernel backporting.  For more information see the "Fixes" portion of
-https://www.kernel.org/doc/html/latest/process/submitting-patches.html#submittingpatches
+  arm-toolchain/gcc: enable foobar v2

 Releases and Release Schedule
 --------------
 We follow the Yocto Project release methodology, schedule, and stable/LTS support timelines.  For more information on these, please reference:
-* https://docs.yoctoproject.org/ref-manual/release-process.html
-* https://wiki.yoctoproject.org/wiki/Releases
-* https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS
-
-For more in-depth information on the meta-arm release and branch methodology, go to </documentation/releases.md>.
+https://docs.yoctoproject.org/ref-manual/release-process.html
+https://wiki.yoctoproject.org/wiki/Releases
+https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS

 Reporting bugs
 --------------
-E-mail <meta-arm@lists.yoctoproject.org> with the error encountered and the steps
+E-mail meta-arm@lists.yoctoproject.org with the error encountered and the steps
 to reproduce the issue.

-Security and Reporting Security Issues
--------------
-For information on the security of meta-arm and how to report issues, please consult [SECURITY.md](/SECURITY.md).
-
 Maintainer(s)
 -------------
 * Jon Mason <jon.mason@arm.com>
@@ -18,7 +18,7 @@ number), please contact the meta-arm mailing list at
 meta-arm@lists.yoctoproject.org and arm-security@arm.com.

 If you are dealing with a not-yet released or urgent issue, please send a mail
-to the maintainers \(see [README.md](/README.md)\) and arm-security@arm.com, including as much
+to the maintainers (see README.md) and arm-security@arm.com, including as much
 detail as possible.  Encrypted emails using PGP are welcome.

 For more information, please visit https://developer.arm.com/support/arm-security-updates/report-security-vulnerabilities.
@@ -27,20 +27,11 @@ For more information, please visit https://developer.arm.com/support/arm-securit
 ## Branches maintained with security fixes

 meta-arm follows the Yocto release model, so see
-[Stable release and LTS](https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS)
-for detailed info regarding the policies and maintenance of stable
+[https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS Stable release and
+LTS] for detailed info regarding the policies and maintenance of stable
 branches.

-The [Release page](https://wiki.yoctoproject.org/wiki/Releases) contains a list of all
+The [https://wiki.yoctoproject.org/wiki/Releases Release page] contains a list of all
 releases of the Yocto Project. Versions in grey are no longer actively maintained with
 security patches, but well-tested patches may still be accepted for them for
 significant issues.
-
-
-# Disclaimer
-
-Arm reference solutions are Arm public example software projects that track and
-pull upstream components, incorporating their respective security fixes
-published over time. Arm partners are responsible for ensuring that the
-components they use contain all the required security fixes, if and when they
-deploy a product derived from Arm reference solutions.
@@ -1,8 +1,6 @@
 # yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json

 header:
-  version: 14
-
-local_conf_header:
-  secure-debug: |
-    MACHINE_FEATURES += "secure-debug"
+  version: 11
+  includes:
+    - kas/arm-systemready-firmware.yml
@@ -0,0 +1,18 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 11
+  includes:
+    - kas/arm-systemready-ir-acs.yml
+
+env:
+  ACS_TEST: "0"
+
+local_conf_header:
+  testimage: |
+    TESTIMAGE_AUTO = "${ACS_TEST}"
+
+target:
+  - arm-systemready-ir-acs
+  - arm-systemready-linux-distros-debian
+  - arm-systemready-linux-distros-opensuse
@@ -7,41 +7,35 @@ distro: poky

 defaults:
  repos:
-    branch: master
+    branch: scarthgap

 repos:
-  bitbake:
-    url: https://git.openembedded.org/bitbake
-    layers:
-      bitbake: disabled
-
-  core:
-    url: https://git.openembedded.org/openembedded-core
-    layers:
-      meta:
-
-  meta-yocto:
-    url: https://git.yoctoproject.org/meta-yocto
-    layers:
-      meta-poky:
-
  meta-arm:
    layers:
      meta-arm:
      meta-arm-bsp:
      meta-arm-toolchain:

+  poky:
+    url: https://git.yoctoproject.org/poky
+    layers:
+      meta:
+      meta-poky:
+
 env:
  BB_LOGCONFIG: ""
-  BB_HASHSERVE: "auto"
+  TOOLCHAIN_DIR: ""

 local_conf_header:
  base: |
    CONF_VERSION = "2"
-    BB_SERVER_TIMEOUT = "300"
+  setup: |
+    PACKAGE_CLASSES = "package_ipk"
+    PACKAGECONFIG:remove:pn-qemu-system-native = "gtk+ sdl"
+    PACKAGECONFIG:append:pn-perf = " coresight"
    INHERIT += "rm_work"
  extrapackages: |
-    CORE_IMAGE_EXTRA_INSTALL += "perf"
+    CORE_IMAGE_EXTRA_INSTALL += "perf opencsd"
    CORE_IMAGE_EXTRA_INSTALL:append:aarch64 = " gator-daemon"

 machine: unset
@@ -3,6 +3,19 @@
 header:
  version: 14

+repos:
+  meta-clang:
+    url: https://github.com/kraj/meta-clang
+
 local_conf_header:
  toolchain: |
-    PREFERRED_TOOLCHAIN_TARGET = "clang"
+    TOOLCHAIN = "clang"
+    PREFERRED_PROVIDER_llvm = "clang"
+    PREFERRED_PROVIDER_llvm-native = "clang-native"
+    PREFERRED_PROVIDER_nativesdk-llvm = "nativesdk-clang"
+    PROVIDES:pn-clang = "llvm"
+    PROVIDES:pn-clang-native = "llvm-native"
+    PROVIDES:pn-nativesdk-clang = "nativesdk-llvm"
+    # This is needed to stop bitbake getting confused about what clang/llvm is
+    # being used, see https://github.com/kraj/meta-clang/pull/766
+    BBMASK += "/meta/recipes-devtools/llvm/llvm.*\.bb"
@@ -0,0 +1,21 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+
+local_conf_header:
+  cve: |
+    INHERIT += "cve-check"
+
+    # Allow the runner environment to provide an API key
+    NVDCVE_API_KEY = "${@d.getVar('BB_ORIGENV').getVar('NVDCVE_API_KEY') or ''}"
+
+    # Just show the warnings for our layers
+    CVE_CHECK_SHOW_WARNINGS = "0"
+    CVE_CHECK_SHOW_WARNINGS:layer-arm-toolchain = "1"
+    CVE_CHECK_SHOW_WARNINGS:layer-meta-arm = "1"
+    CVE_CHECK_SHOW_WARNINGS:layer-meta-arm-bsp = "1"
+    CVE_CHECK_SHOW_WARNINGS:layer-meta-arm-systemready = "1"
+
+    # Ignore the kernel, we sometime carry kernels in meta-arm
+    CVE_CHECK_SHOW_WARNINGS:pn-linux-yocto = "0"
@@ -5,5 +5,5 @@ header:

 # Add universally helpful features when testing boards
 local_conf_header:
-  rootlogin: |
-    EXTRA_IMAGE_FEATURES:append = " allow-empty-password empty-root-password allow-root-login"
+  debug: |
+    EXTRA_IMAGE_FEATURES:append = " debug-tweaks"
@@ -13,5 +13,7 @@ local_conf_header:
    EXTRA_IMAGEDEPENDS += "edk2-firmware"
    EFI_PROVIDER ?= "grub-efi"

-    QB_DEFAULT_BIOS ??= "QEMU_EFI.fd"
+    QB_DEFAULT_BIOS = "QEMU_EFI.fd"
    WKS_FILE ?= "efi-disk.wks.in"
+  failing_tests: |
+    TEST_SUITES:remove = "xorg"
@@ -0,0 +1,13 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+
+local_conf_header:
+  cc: |
+    SKIP_RECIPE[gcc-cross-arm] = "Using external toolchain"
+    TCMODE = "external-arm"
+    EXTERNAL_TOOLCHAIN = "${TOPDIR}/toolchains/${TARGET_ARCH}"
+    # Disable ptest as this pulls target compilers, which don't
+    # work with external toolchain currently
+    DISTRO_FEATURES:remove = "ptest"
@@ -1,27 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-  includes:
-    - ci/fvp-base-ts.yml
-    - ci/meta-secure-core.yml
-
-repos:
-  meta-secure-core:
-    layers:
-      meta-tpm2:
-
-local_conf_header:
-  remove_secureboot: |
-    BBMASK += "efi-secure-boot"
-
-  ftpm_sp_test: |
-    # Include tpm2 related packages
-    IMAGE_INSTALL:append = " tpm2-tools-tests tpm2-abrmd tpm2-tss"
-    # Use systemd as the init system, which is required for the tpm2 self-tests
-    INIT_MANAGER = "systemd"
-    IMAGE_INSTALL:append = " systemd util-linux"
-
-  ts_ftpm_sp: |
-    MACHINE_FEATURES:append = " ts-ftpm"
-    RUN_TPM2_TESTS = "1"
@@ -5,24 +5,23 @@ header:
  includes:
    - ci/fvp-base.yml
    - ci/meta-openembedded.yml
+    - ci/testimage.yml

 local_conf_header:
  trusted_services: |
    # Enable the needed test suites
-    TEST_SUITES:append = " trusted_services"
+    TEST_SUITES = " ping ssh trusted_services"
    # Include all Secure Partitions into the image
    MACHINE_FEATURES:append = " arm-ffa ts-crypto ts-storage ts-its"
    MACHINE_FEATURES:append = " ts-attestation ts-smm-gateway optee-spmc-test"
-    MACHINE_FEATURES:append = " ts-block-storage ts-fwu ts-logging"
-    MACHINE_FEATURES:append = " arm-branch-protection"
-    SMMGW_AUTH_VAR = "1"
+    MACHINE_FEATURES:append = " ts-block-storage ts-fwu"
    # Include TS demo/test tools into image
    IMAGE_INSTALL:append = " packagegroup-ts-tests"
    # Include TS PSA Arch tests into image
    IMAGE_INSTALL:append = " packagegroup-ts-tests-psa"
    CORE_IMAGE_EXTRA_INSTALL += "optee-test"
    # Set the TS environment
-    TS_ENV = "sp"
+    TS_ENV="sp"
    # Enable and configure semihosting
    FVP_CONFIG[cluster0.cpu0.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
    FVP_CONFIG[cluster0.cpu1.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
@@ -9,5 +9,5 @@ header:
 machine: fvp-base

 target:
-  - core-image-full-cmdline
+  - core-image-sato
  - boot-wrapper-aarch64
@@ -7,9 +7,8 @@ local_conf_header:
  testimagefvp: |
    LICENSE_FLAGS_ACCEPTED += "Arm-FVP-EULA"
    IMAGE_CLASSES += "fvpboot"
-  networking_failing_tests: |
-    # These tests currently fail as the wrong IP for the build host is used
-    TEST_SUITES:remove = "opkg dnf"
-
-target:
-  - core-image-base
+  failing_tests: |
+    # This fails but we can't add to the ignorelist from meta-arm yet
+    # https://bugzilla.yoctoproject.org/show_bug.cgi?id=14604
+    TEST_SUITES:remove = "parselogs"
+    TEST_SUITES:remove = "xorg"
@@ -17,33 +17,10 @@ local_conf_header:

 target:
  # Target packages to test aarch64
-  # Nativesdk to test x86-64
-
-  # Architecture Envelope Models (AEM) FVPs
  - fvp-base-a-aem
-  - nativesdk-fvp-base-a-aem
-
-  # Arm Lumex CSS (Total Compute) FVPs
-  # These are x86 only... :(
-  - nativesdk-fvp-tc3
-
-  # Automotive FVPs
-  - fvp-rd1-ae
-  - nativesdk-fvp-rd1-ae
-
-  # Infrastructure FVPs
-  - fvp-rdv3-r1
-  - nativesdk-fvp-rdv3-r1
-  - fvp-rdv2
-  - nativesdk-fvp-rdv2
-  - fvp-rdn2
-  - nativesdk-fvp-rdn2
-
-  # IoT FVPs
  - fvp-corstone1000
+  # Nativesdk to test x86-64
+  - nativesdk-fvp-base-a-aem
  - nativesdk-fvp-corstone1000
-  - fvp-corstone1000-a320
-  - nativesdk-fvp-corstone1000-a320
-
-  # Morello FVPs
-  # TBD
+  - nativesdk-fvp-n1-edge
+  - nativesdk-fvp-sgi575
@@ -3,7 +3,7 @@
 header:
  version: 14

-#NOTE: This is the default.  This is only being added for completeness/clarity
+#NOTE: This is the default for poky.  This is only being added for completeness/clarity
 local_conf_header:
  toolchain: |
-    PREFERRED_TOOLCHAIN_TARGET = "gcc"
+    TOOLCHAIN = "gcc"
@@ -6,7 +6,7 @@ header:
    - ci/base.yml

 repos:
-  meta-yocto:
+  poky:
    layers:
      meta-yocto-bsp:

@@ -14,8 +14,5 @@ local_conf_header:
  bootloader: |
    # If running genericarm64 in a qemu we need to manually build the bootloader
    EXTRA_IMAGEDEPENDS += "virtual/bootloader"
-  sshpregen: |
-    # Allow the use of the pregen keys as this is CI so safe
-    COMPATIBLE_MACHINE:pn-ssh-pregen-hostkeys:genericarm64 = "genericarm64"

 machine: genericarm64
@@ -0,0 +1,51 @@
+#!/bin/bash
+set -u -e
+
+BASENAME=arm-gnu-toolchain
+VER=${VER:-13.2.Rel1}
+HOST_ARCH=${HOST_ARCH:-$(uname -m)}
+
+# Use the standard kas container locations if nothing is passed into the script
+DOWNLOAD_DIR="${1:-/builds/persist/downloads/}"
+TOOLCHAIN_DIR="${2:-/builds/persist//toolchains/}"
+TOOLCHAIN_LINK_DIR="${3:-build/toolchains/}"
+
+# These should be already created by .gitlab-ci.yml, but do here if run outside of that env
+mkdir -p $DOWNLOAD_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
+
+download() {
+	TRIPLE=$1
+	URL=https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/$BASENAME-$VER-$HOST_ARCH-$TRIPLE.tar.xz
+	wget -P $DOWNLOAD_DIR -nc $URL
+}
+
+if [ $HOST_ARCH = "aarch64" ]; then
+	# AArch64 Linux hosted cross compilers
+
+	# AArch32 target with hard float
+	download arm-none-linux-gnueabihf
+elif [ $HOST_ARCH = "x86_64" ]; then
+	# x86_64 Linux hosted cross compilers
+
+	# AArch32 target with hard float
+	download arm-none-linux-gnueabihf
+
+	# AArch64 GNU/Linux target
+	download aarch64-none-linux-gnu
+else
+	echo "ERROR - Unknown build arch of $HOST_ARCH"
+	exit 1
+fi
+
+for i in arm aarch64; do
+	if [ ! -d $TOOLCHAIN_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*/ ]; then
+		if [ ! -f $DOWNLOAD_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz ]; then
+			continue
+		fi
+
+		tar -C $TOOLCHAIN_DIR -axvf $DOWNLOAD_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz
+	fi
+
+	# Setup a link for the toolchain to use local to the building machine (e.g., not in a shared location)
+	ln -s $TOOLCHAIN_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu* $TOOLCHAIN_LINK_DIR/$i
+done
@@ -1,15 +0,0 @@
-#! /bin/bash
-
-# $ ci/junit.sh <build directory>
-#
-# If there is a OEQA test report in JSON format present in the build directory,
-# transform it to JUnit XML using resulttool.
-
-set -e -u
-
-BUILDDIR=$1
-JSON=$BUILDDIR/tmp/log/oeqa/testresults.json
-
-if test -f $JSON; then
-    resulttool junit $JSON
-fi
@@ -1,16 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-
-local_conf_header:
-  latest_revisions: |
-    PREFERRED_VERSION_scp-firmware ?= "git"
-    PREFERRED_VERSION_trusted-firmware-a ?= "git"
-    PREFERRED_VERSION_trusted-firmware-m ?= "git"
-    PREFERRED_VERSION_optee-client ?= "git"
-    PREFERRED_VERSION_optee-examples ?= "git"
-    PREFERRED_VERSION_optee-os-tadevkit ?= "git"
-    PREFERRED_VERSION_optee-os ?= "git"
-    PREFERRED_VERSION_optee-test ?= "git"
-    PREFERRED_PROVIDER_u-boot = "u-boot:class-devupstream"
@@ -1,11 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-
-local_conf_header:
-  latest_revisions: |
-    PREFERRED_VERSION_trusted-firmware-a ?= "2.14.%"
-    PREFERRED_VERSION_tf-a-tests ?= "2.14.%"
-    PREFERRED_VERSION_trusted-firmware-m ?= "2.2.%"
-    PREFERRED_VERSION_trusted-firmware-m-scripts-native ?= "2.2.%"
@@ -0,0 +1,10 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+  includes:
+    - ci/meta-openembedded.yml
+
+repos:
+  meta-virtualization:
+    url: https://git.yoctoproject.org/meta-virtualization
@@ -6,11 +6,6 @@ header:
    - ci/base.yml
    - ci/meta-openembedded.yml

-local_conf_header:
-  version_for_ci: |
-    # For better CI coverage, use the LTS version of tf-m
-    PREFERRED_VERSION_trusted-firmware-m ?= "2.2.%"
-
 machine: musca-s1

 target:
@@ -0,0 +1,14 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+
+# Config specific for the optee-xtests
+local_conf_header:
+  optee-test: |
+    # Include ARM FFA
+    MACHINE_FEATURES:append = " arm-ffa"
+    # Include trusted services
+    TEST_SUITES:append = " trusted_services"
+    # Include Optee xtests
+    IMAGE_INSTALL:append = " optee-test"
@@ -0,0 +1,16 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+  includes:
+    - ci/meta-openembedded.yml
+
+local_conf_header:
+  trusted_services: |
+    TEST_SUITES:append = " trusted_services"
+    # Include TS Crypto, TS Protected Storage, TS Internal and Trusted Storage SPs into optee-os image
+    MACHINE_FEATURES:append = " arm-ffa ts-crypto ts-storage ts-its"
+    # Include TS demo/test tools into image
+    IMAGE_INSTALL:append = " packagegroup-ts-tests"
+    # Include TS PSA Arch tests into image
+    IMAGE_INSTALL:append = " packagegroup-ts-tests-psa"
@@ -2,7 +2,11 @@

 header:
  version: 14
+  includes:
+    - ci/base.yml
+
+machine: n1sdp

 local_conf_header:
-  multicore: |
-    MACHINE_FEATURES += "corstone1000_smp"
+  unsupported_trusted_services: |
+    MACHINE_FEATURES:remove = "ts-smm-gateway"
@@ -1,4 +0,0 @@
-header:
-  version: 14
-
-distro: poky-altcfg
@@ -8,9 +8,8 @@ header:
 local_conf_header:
  trusted_services: |
    TEST_SUITES:append = " trusted_services"
-    # Include TS Crypto, TS Protected Storage, and TS Internal Trusted Storage and SPs into optee-os image
-    # FIXME - remove TS SMM Gateway due to QEMU v9.0.0 test failures
-    MACHINE_FEATURES:append = " arm-ffa ts-crypto ts-storage ts-its"
+    # Include TS Crypto, TS Protected Storage, TS Internal Trusted Storage and SMM-Gateway SPs into optee-os image
+    MACHINE_FEATURES:append = " arm-ffa ts-crypto ts-storage ts-its ts-smm-gateway"
    # Include TS demo/test tools into image
    IMAGE_INSTALL:append = " packagegroup-ts-tests"
    # Include TS PSA Arch tests into image
@@ -9,7 +9,6 @@ machine: qemuarm64-secureboot

 target:
  - core-image-base
-  - hafnium

 local_conf_header:
  optee: |
@@ -1,14 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-    - ci/fvp.yml
-
-local_conf_header:
-  sshpregen: |
-    # Allow the use of the pregen keys as this is CI so safe
-    COMPATIBLE_MACHINE:pn-ssh-pregen-hostkeys:rdn2 = "rdn2"
-
-machine: rdn2
@@ -1,14 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-    - ci/fvp.yml
-
-local_conf_header:
-  sshpregen: |
-    # Allow the use of the pregen keys as this is CI so safe
-    COMPATIBLE_MACHINE:pn-ssh-pregen-hostkeys:rdv2 = "rdv2"
-
-machine: rdv2
@@ -7,4 +7,3 @@ local_conf_header:
  setup: |
    BB_LOGCONFIG = ""
    SANITY_TESTED_DISTROS = ""
-    INHERIT:remove = "rm_work"
@@ -3,6 +3,6 @@
 header:
  version: 14
  includes:
-    - ci/corstone1000-fvp.yml
+    - ci/base.yml

-machine: corstone1000-a320-fvp
+machine: sgi575
@@ -5,5 +5,7 @@ header:

 local_conf_header:
  sstate_mirror: |
+    BB_HASHSERVE_UPSTREAM = "wss://hashserv.yoctoproject.org/ws"
+    SSTATE_MIRRORS = "file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH"
+    BB_HASHSERVE = "auto"
    BB_SIGNATURE_HANDLER = "OEEquivHash"
-    OE_FRAGMENTS += "core/yocto/sstate-mirror-cdn"
@@ -9,8 +9,6 @@ local_conf_header:
  testimage: |
    IMAGE_CLASSES += "testimage"
    TESTIMAGE_AUTO = "1"
-    # Don't testimage initramfs
-    TESTIMAGE_AUTO:pn-core-image-initramfs-boot = "0"
  kvm: |
    QEMU_USE_KVM = ""
  slirp: |
@@ -19,3 +17,5 @@ local_conf_header:
    IMAGE_FEATURES += "ssh-server-dropbear"
  sshkeys: |
    CORE_IMAGE_EXTRA_INSTALL += "ssh-pregen-hostkeys"
+  universally_failing_tests: |
+    TEST_SUITES:remove = "opkg"
@@ -1,50 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-# UEFI Secure Boot: A mechanism to ensure that only trusted software is executed
-# during the boot process.
-
-header:
-  version: 14
-  includes:
-    - ci/meta-openembedded.yml
-    - ci/meta-secure-core.yml
-
-local_conf_header:
-  uefi_secureboot: |
-    SBSIGN_KEYS_DIR = "${TOPDIR}/sbkeys"
-    BB_ENV_PASSTHROUGH_ADDITIONS = "SBSIGN_KEYS_DIR"
-
-    # Detected by passing kernel parameter
-    QB_KERNEL_ROOT = ""
-
-    # kernel is in the image, should not be loaded separately
-    QB_DEFAULT_KERNEL = "none"
-
-    WKS_FILE = "efi-disk.wks.in"
-    KERNEL_IMAGETYPE = "Image"
-
-    MACHINE_FEATURES:append = " efi uefi-secureboot uefi-http-boot uefi-capsule-updates"
-
-    EFI_PROVIDER = "systemd-boot"
-
-    # Use systemd as the init system
-    INIT_MANAGER = "systemd"
-
-    IMAGE_INSTALL:append = " systemd systemd-boot util-linux coreutils"
-
-    TEST_SUITES:append = " uefi_secureboot uki"
-
-    IMAGE_CLASSES += "uki"
-
-    IMAGE_CLASSES += "sbsign"
-    UKI_SB_KEY = "${SBSIGN_KEY}"
-    UKI_SB_CERT = "${SBSIGN_CERT}"
-    IMAGE_BOOT_FILES:remove = "Image"
-
-    INITRAMFS_IMAGE = "core-image-initramfs-boot"
-    # not for initramfs image recipe
-    IMAGE_CLASSES:remove:pn-core-image-initramfs-boot = "uki"
-    IMAGE_CLASSES:remove:pn-core-image-initramfs-boot = "sbsign"
-    IMAGE_CLASSES:remove:pn-core-image-initramfs-boot = "testimage"
-    IMAGE_FEATURES:remove:pn-core-image-initramfs-boot = "ssh-server-dropbear"
-    CORE_IMAGE_EXTRA_INSTALL:remove:pn-core-image-initramfs-boot = "ssh-pregen-hostkeys"
@@ -22,6 +22,8 @@ def repo_shortname(url):
 repositories = (
    "https://git.yoctoproject.org/poky",
    "https://git.openembedded.org/meta-openembedded",
+    "https://git.yoctoproject.org/meta-virtualization",
+    "https://github.com/kraj/meta-clang",
 )

 if __name__ == "__main__":
@@ -42,7 +44,7 @@ if __name__ == "__main__":
        if repodir.exists():
            try:
                print("Updating %s..." % repo)
-                subprocess.run(["git", "-C", repodir, "-c", "gc.autoDetach=false", "fetch", repo], check=True)
+                subprocess.run(["git", "-C", repodir, "-c", "gc.autoDetach=false", "fetch"], check=True)
            except subprocess.CalledProcessError as e:
                print(e)
                failed = True
@@ -0,0 +1,13 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+  includes:
+    - ci/meta-virtualization.yml
+
+local_conf_header:
+  meta-virt: |
+    DISTRO_FEATURES:append = " virtualization xen"
+
+target:
+  - xen-image-minimal
@@ -1,67 +0,0 @@
-# **CI for Yocto Project and meta-arm**
-# **CI for Yocto Project**
-The Yocto Project has an autobuilder that performs nightly builds and image tests on all of the defined QEMU machines, including qemuarm and qemuarm64  Also, it currently runs builds on the hardware reference platforms including genericarm64 and meta-arm mahines fvp-base and sbsa-ref.  More information on the autobuilder can be found at <https://autobuilder.yoctoproject.org/>.
-
-More information on the image tests can be found at <https://wiki.yoctoproject.org/wiki/Image_tests>.
-
-The Yocto Project also has the ability to have individual package tests, ptests.  For more information on those, go to <https://wiki.yoctoproject.org/wiki/Ptest>.
-# **CI for meta-arm**
-meta-arm is using the Gitlab CI infrastructure.  This is currently being done internal to Arm, but an external version can be seen at <https://gitlab.com/jonmason00/meta-arm/-/pipelines>.
-
-This CI is constantly being expanded to provide increased coverage of the software and hardware supported in meta-arm.  All platforms are required to add a kas file and `.gitlab-ci.yml` entry as part of the initial patch series.  More information on kas can be found at <https://github.com/siemens/kas>.
-
-To this end, it would be wise to run kas locally to verify everything works prior to pushing to the CI build system.
-## **Running kas locally**
-### **Install kas**
-kas can be installed with pip, for example:
-```
-$ pip3 install --user kas
-```
-
-See <https://kas.readthedocs.io/en/latest/userguide/getting-started.html> for information on the dependencies and more.
-
-This assumes that the kas path ($HOME/.local/bin) is in $PATH.  If not, the user will need to manually add this or the kas command will not be found.
-
-### **Run kas locally**
-```
-$ cd ~/meta-arm/
-$ kas build kas/juno.yml
-```
-
-By default kas will create a build directory under meta-arm to contain the checked out layers, build directory, and downloads.  You can change this by setting environment variables.  DL\_DIR and SSTATE\_DIR are respected so these can point at existing directories, and setting KAS\_WORK\_DIR to the directory where repositories are already cloned will save having to re-fetch.  This can look something like:
-```
-$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/qemuarm64.yml:ci/testimage.yml
-```
-
-See the [quick start guide](/documentation/quick-start.md) for more information on how to set this up.
-
-## **Locked Revisions in CI with lockfiles**
-The CI in meta-arm will generate a kas "lock file" when it starts to ensure that all of the builds checkout the same revision of the various different layers that are used. If this isn't done then there's a chance that a layer will be modified upstream during the CI, which results in some builds failing and some builds passing.
-
-This lock file is saved as an artefact of the update-repos job by the CI, and only generated if it doesn't already exist in the repository.  This can be used to force specific revisions of layers to be used instead of HEAD, which can be useful if upstream changes are causing problems in development.
-
-The lockfile.yml can be downloaded manually, but there's a script in meta-arm to fetch the lock file for the latest successful build of the specified branch:
-
-```
-$ ./ci/download-lockfile.py --help
-usage: download-lockfile.py [-h] server project refspec
-
-positional arguments:
-  server      GitLab server name
-  project     meta-arm project name
-  refspec     Branch/commit
-
-$ ./ci/download-lockfile.py https://gitlab.com/jonmason00/meta-arm master
-Fetched lockfile.yml
-Commit this lockfile.yml to the top-level of the meta-arm repository and the CI will use it automatically.
-```
-# **Relevant Links for kas, CI, and testing**
-<https://github.com/siemens/kas.git>
-
-<https://wiki.yoctoproject.org/wiki/Oe-selftest>
-
-<https://wiki.yoctoproject.org/wiki/Image_tests>
-
-<https://wiki.yoctoproject.org/wiki/Ptest>
-
-<https://wiki.yoctoproject.org/wiki/BSP_Test_Plan>
@@ -1,105 +0,0 @@
-# **Yocto Project quick start for Arm system software developers**
-If you want to read the The Yocto Project official quick start documentation, go to <https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html>
-
-If that looks like too much reading, then here is how to do it even faster!
-# **Step 0: Install build deps and kas**
-```
-$ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev python3-subunit mesa-common-dev zstd liblz4-tool file locales libacl1
-
-$ pip install kas
-```
-OR, if you prefer to use a docker will all that stuff already installed:
-
-```
-$ sudo docker run -it --name kas-test --volume /mnt/yocto/:/builds/persist ghcr.io/siemens/kas/kas /bin/bash
-```
-
-> **_NOTE:_**
-> the “--volume” is the directory where your persistent stuff (like downloads and build artifacts) will go to help speed up your builds and can be sharable amongst your builds/containers.  If you want to go completely clean-room, feel free to remove it
-# **Step 1: clone meta-arm and build meta-arm**
-```
-$ git clone https://git.yoctoproject.org/meta-arm
-$ cd meta-arm/
-$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/fvp-base.yml:ci/testimage.yml
-```
-> **_NOTE:_**
-> “ci/testimage.yml” will cause the build to run some basic system tests.  If you don’t care about verifying basic functionality, then remove it and it should be faster (a few less programs will be added to the system image and the 2-3mins that it takes to run the test will not happen).
-
-> **_NOTE:_**
-> You may wish to add the Yocto Project SSTATE Mirror (especially the first time) to speed up the build by downloading the build fragments (built by the Yocto Project autobuilder) from the internet.  This can be done by adding "ci/sstate-mirror.yml" in kas or adding the relevant lines to your local.conf.  Using the above example:
-
-```
-$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/fvp-base.yml:ci/sstate-mirror.yml
-```
-
-> **_NOTE:_**
-> This only fetches the parts necessary for your build and may take several minutes depending on your internet connection speed.  Also, it only fetches what is available.  There may still be a need to build things depending on your configuration.
-
-For more information on kas and various commands, please reference <https://kas.readthedocs.io/en/latest/>.
-
-Depending on what software you are building, fvp-base might not be the machine you want to build for.
-The following website provides an EXTREMELY rough way to tell what software is in what machines, and what versions are being run:
-<https://gitlab.com/jonmason00/meta-arm/-/jobs/artifacts/master/file/update-report/index.html?job=pending-updates>
-
-If, as an example, we’re wanting to develop trusted-firmware-a; then fvp-base will work for us. 
-
-### **Okay, you are done!  VICTORY!**
-### **Oh, you actually wanted to mess around with the system software source code?**
-# **Step 2: use devtool to get your source**
-Setup your environment via the (non-kas) Yocto Project tools
-
-```
-$ source poky/oe-init-build-env
-```
-
-Use devtool to checkout the version of software being used on the machine above (in the above example, this will be trusted-firmware-a for fvp-base).
-
-```
-$ devtool modify trusted-firmware-a
-```
-
-This will download the source, hopefully in git (depending on how the Yocto Project recipe was written), and should print a path at the end where the source code was checked out.  In the trusted-firmware-a example, I got:
-
-> /builder/meta-arm/build/workspace/sources/trusted-firmware-a
-
-Inside of that directory, you should see the relevant source code.  In this example, it is a standard git tree.  So, you can add remotes, checkout different SHAs, etc
-
-Ok, so you are set with your changes and want to build them.
-
-```
-$ devtool build trusted-firmware-a
-```
-
-This should build the software in question, but it is not yet integrated into a system image.  To do that, run:
-
-```
-$ devtool build-image core-image-sato
-```
-
-The image should match the image being used on your machine above.  Most of them in meta-arm are set to core-image-sato.  
-
-Also, if you used testimage above, it will run testimage now
-### **Okay, you are done!  VICTORY!**
-# **Step 3.  Testing your patches outside of devtool**
-At this point I will assume you have a patch and want to add it to the base recipe.  Using the above example, in the devtool directory:
-```
-$ git format-patch -1
-0001-example.patch
-$ mv 0001-example.patch ~/meta-arm/meta-arm/recipes-bsp/trusted-firmware-a/files/
-$ cd ~/meta-arm
-$ devtool reset trusted-firmware-a
-$ echo ‘SRC_URI:append = " file://0001-example.patch" >> meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.10.3.bb
-```
-
-> **_NOTE:_**
-> there is a space before the “file” and yes it matters very much
-
-At this point, you can go back using kas and verify that the patch works in a clean-ish tree.
-
-```
-$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/fvp-base.yml:ci/testimage.yml
-```
-
-There is obviously much more that can be done and other ways to do similar things.
-
-## **If there are issues or questions then please ask them on the #meta-arm irc channel on libera.chat**
@@ -1,43 +0,0 @@
-# **meta-arm Releases and Branching**
-## **Release and Branching background**
-The Yocto Project releases twice a year (April and October): "stable" releases are made every six months and have a lifetime of seven months to allow for migration, while "long term support" (LTS) releases are picked every two years starting from Dunfell in April 2020. The standard practice for all Yocto Compatible layers is to create a "named" branch consistent with the code name of that release. For example, the “dunfell” release of the Yocto Project will have a branch named “dunfell” in the official git repository, and layers compatible with dunfell will have a branch named “dunfell”. Thus, a customer can easily organize a collection of appropriate layers to make a product.
-
-In the Yocto Project, these named branches are “stable”, and only take bug fixes or security-critical upgrades. Active development occurs on the master branch. However, this methodology can be problematic if mimicked with the compatible layers. Companies, like Arm, may not wish to release a snapshot of the relevant “master” branches under active development, due to the amount of testing, fixing, and hardening necessary to make a product from a non-stable release. Also, changes to keep the master branch of a layer working with the upstream master branch of the Yocto Project may result in that branch no longer being compatible with named branches (e.g., it might not be possible to mix and match master and dunfell). So, a decision must be made on the branching policy of meta-arm.
-
-## **Adding new Hardware or Software features**
-There are many different ways to resolve this issue. After some discussion, the best solution for us is to allow new hardware enablement (and relevant software features) to be included in LTS named branches (not just bug fixes). This will allow for a more stable software platform for software to be developed, tested, and released. Also, the single branch allows for focused testing (limiting the amount of resources needed for CI/CD), lessens/eliminates code diverging on various branches, and lessens confusion on which branch to use. The risk of making this choice is a potentially non-stable branch which will require more frequent testing to lessen the risk, and not following the “stable” methodology of the core Yocto Project layers (though it is not uncommon for BSP layers to behave this way).
-
-## **Process**
-The process for patches intended on being integrated into only the master branch is the normal internal process of pushing for code review and CI, approval and integration into upstream meta-arm master branch. 
-For patches intended on being included in an LTS named branch, the preferred process is to upstream via the master branch, rebase the patch (or series against the intended LTS branch) and send email with the release name in the subject line after the "PATCH" (e.g., "[PATCH dunfell] Add foo to bar").
-
-If there is a time crunch and the preferred way above cannot be completed in time, upstreaming via the LTS branch can occur. This follows the normal process above but without the master integration step.  However, any patches upstreamed in this manner must be pushed to master in a timely fashion (after the time crunch). Nagging emails will be sent and managers will be involved as the time grows.
-
-## **Testing**
-See [continuous-integration-and-kas.md](/documentation/continuous-integration-and-kas.md) for information how the layer is tested and what tests are run. It is presumed that all code will be compiled as part of the CI process of the gerrit code review. Also, testing on virtual platforms and code conformity checks will be run when enabled in the process.
-
-## **Branching strategy and releases**
-Named branches for meta-arm will be released as close as possible to the release of the YP LTS release. Meta-arm named branches will be created from the meta-arm master branch.
-
-To minimize the additional work of maintaining multiple branches it is assumed that there will only be two active development branches at any given time: master and the most recent Long Term Stable (LTS) as the named branch. All previous named LTS branches will be EOLed when a new LTS has been released. Any branches that are EOLed will still exist in the meta-arm, but bug fix patches will be accepted. Limited to no testing will occur on EOL’ed branches. Exceptions to this can be made, but must be sized appropriately and agreed to by the relevant parties.
-
-Named branch release will coincide with Yocto Project releases. These non-LTS branches will be bug fix only and will be EOLed on the next release (similar to the YP branching behavior).
-
-### **Branch transitions**
-When YP is approaching release, meta-arm will attempt to stabilize master so that the releases can coincide. 
-* T-6 weeks - Email is sent to meta-arm mailing list notifying of upcoming code freeze of features to meta-arm
-* T-4 weeks - Code freeze to meta-arm. Only bug fixes are taken at this point.
-* T-0 - Official upstream release occurs. With no outstanding critical bugs, a new named branch is created based on the current meta-arm master branch. Previous named branches are now frozen and will not accept new patches (but will continue to be present for reference and legacy usage).
-
-## **Tagging**
-### **Branch Tagging**
-When each branch is released, a git tag with the Yocto Project version number will be added.  For example, `4.3`.  Also, this tag version number will be prepended with "yocto" in a duplicate tag (e.g., "yocto-4.3").
-
-Conciding with the Yocto Project release schedule, every branch which has one or more changes added to it in the previous 6 months will get a minor versioned tag (e.g., "4.3.1" and "yocto-4.3.1").
-
-### **BSP Release Tagging**
-BSP releases for those boards supported in meta-arm-bsp maybe have an additional tag to denote their software releases.  The tag will consist of the board name (in all capital letters), year, and month.  For example, "CORSTONE1000-2023.11".
-The release schedule for this is outside the standard Yocto Project release candence, but is generally encouraged to be as close to these releases as possible.  Similarily, it is recommended the BSP releases be based on the latest LTS branch.
-
-# **Relevant Links**
-<https://wiki.yoctoproject.org/wiki/Releases>
@@ -4,10 +4,10 @@ The `runfvp` tool in meta-arm makes it easy to run Yocto Project disk images ins

 ## Running images with `runfvp`

-To build images with the FVP integration, the `fvpboot` image class needs to be inherited.  If the machine does not do this explicitly it can be done in `local.conf`:
+To build images with the FVP integration, the `fvpboot` class needs to be inherited.  If the machine does not do this explicitly it can be done in `local.conf`:

 ```
-IMAGE_CLASSES += "fvpboot"
+INHERIT += "fvpboot"
 ```

 The class will download the correct FVP and write a `.fvpconf` configuration file when an image is built.
@@ -28,13 +28,6 @@ Note that currently meta-arm's `scripts` directory isn't in `PATH`, so a full pa

 `runfvp` will automatically start terminals connected to each of the serial ports that the machine specifies.  This can be controlled by using the `--terminals` option, for example `--terminals=none` will mean no terminals are started, and `--terminals=tmux` will start the terminals in [`tmux`][tmux] sessions.  Alternatively, passing `--console` will connect the serial port directly to the current session, without needing to open further windows.

-The tool attempts to automatically select a suitable terminal type. To see which terminal type is selected by default in your environment, run `runfvp --help`.
-
-`runfvp` determines availability by checking for required executables in your PATH as well as environment variables specific to each terminal type. If any of these checks fail, the corresponding terminal type is disabled.
-The --help output also lists all currently available terminal types.
-
-When using `-terminals=screen`, `runfvp` must be launched from within an existing [`screen`][screen] session. Normally, screen sets the `STY` environment variable to reference the current session. However, if the session is renamed or if `kas` is started from within the screen session, this value may become invalid or be lost. In such cases, `STY` must be set manually. Use `screen -ls` to view the list of currently attached sessions.
-
 The default terminal can also be configured by writing a [INI-style][INI] configuration file to `~/.config/runfvp.conf`:

 ```
@@ -66,16 +59,6 @@ There are recipes for common FVPs in meta-arm already, and writing new recipes i

 If `FVP_PROVIDER` is not set then it is assumed that `FVP_EXE` is installed on the host already.

-### `FVP_BINDIR`
-
-Optional parameter to configure the path of the FVP binary. For example, `fvp-base` uses path from the build host by default. This path can be customized by configuring like below.
-
-```
-FVP_BINDIR ?= "utilities/fvp/usr/bin"
-```
-
-Potential use case for this parameter configuration is to execute `runfvp` script without the need for bitbake environment initialization.
-
 ### `FVP_CONFIG`

 Parameters passed to the FVP with the `--parameter`/`-C` option.  These are expressed as variable flags so individual parameters can be altered easily. For example:
@@ -146,4 +129,3 @@ FVP_ENV_PASSTHROUGH = "ARMLMD_LICENSE_FILE FM_TRACE_PLUGINS"
 [FVP]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
 [tmux]: https://tmux.github.io/
 [INI]: https://docs.python.org/3/library/configparser.html
-[screen]: https://www.gnu.org/software/screen/
@@ -5,27 +5,21 @@ in `meta-arm/recipes-security/trusted-services`

 ## Secure Partitions recipes

-We define dedicated recipes for all supported Trusted Services (TS) Secure Partitions, which produce executables and
-manifest binaries (DT files) for SPs.
-
-The Secure Partitions are compatible with any SPMC implementation that complies with the FF-A specification. Meta-arm
-currently supports OP-TEE SPMC, and when enabled, the Secure Partition binaries are automatically included in the
-optee-os image based on the defined MACHINE_FEATURES. For more details bout OP-TEE SPMC please refer to the
-[OP-TEE documentation][^6].
+We define dedicated recipes for all supported Trusted Services (TS) Secure Partitions.
+These recipes produce ELF and DTB files for SPs.
+These files are automatically included into optee-os image accordingly to defined MACHINE_FEATURES.

 ### How to include TS SPs

-To include TS SPs into the firmware image add the corresponding feature flags to the MACHINE_FEATURES variable for each
-[Secure Partition][^2] you would like to include :
+To include TS SPs into optee-os image you need to add into MACHINE_FEATURES
+features for each [Secure Partition][^2] you would like to include:

 | Secure Partition  | MACHINE_FEATURE |
 | ----------------- | --------------- |
 | Attestation       | ts-attesation   |
 | Crypto            | ts-crypto       |
-| Firmware Update   | ts-fwu          |
-| fTPM              | ts-ftpm         |
+| Firmware Update   | ts-fwu
 | Internal Storage  | ts-its          |
-| Logging           | ts-logging      |
 | Protected Storage | ts-storage      |
 | se-proxy          | ts-se-proxy     |
 | smm-gateway       | ts-smm-gateway  |
@@ -43,24 +37,17 @@ Other steps depend on your machine/platform definition:

 2. optee-os might require platform specific OP-TEE build parameters (for example what SEL the SPM Core is implemented at).
   You can find examples in `meta-arm/recipes-security/optee/optee-os_%.bbappend` for qemuarm64-secureboot machine
-   and in `meta-arm-bsp/recipes-security/optee/optee-os-corstone1000-common.inc` for the Corstone1000 platform.
+   and in `meta-arm-bsp/recipes-security/optee/optee-os-n1sdp.inc` and `meta-arm-bsp/recipes-security/optee/optee-os-corstone1000-common.inc`
+   for N1SDP and Corstone1000 platforms accordingly.

 3. trusted-firmware-a might require platform specific TF-A build parameters (SPD and SPMC details on the platform).
   See `meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend` for qemuarm64-secureboot machine
-   and in `meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-corstone1000.inc` for theCorstone1000 platform.
+   and in `meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-n1sdp.inc` and
+   `meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-corstone1000.inc` for N1SDP and Corstone1000 platforms.

 4. Trusted Services supports an SPMC agonistic binary format. To build SPs to this format the `TS_ENV` variable is to be
   set to `sp`. The resulting SP binaries should be able to boot under any FF-A v1.1 compliant SPMC implementation.

-### Example configurations
-
-The `meta-arm/ci` directory contains various TS focused [KAS][^7] configuration files:
-
-| File name | Description |
-|-----------|-------------|
-| ci/fvp-base-ts-ftpm.yml        |Enabling the fTPM SP on the fvp-base machine|
-| ci/fvp-base-ts.yml             |TS config for the fvp-base machine|
-| ci/qemuarm64-secureboot-ts.yml |TS config for quemuarm64-secureboot machine|

 ## Normal World applications

@@ -69,67 +56,9 @@ Optionally for testing purposes you can add `packagegroup-ts-tests` into your im

 ## OEQA Trusted Services tests

-meta-arm also includes Trusted Service OEQA tests which can be used for automated testing.
+  meta-arm also includes Trusted Service OEQA tests which can be used for automated testing.
 See `ci/trusted-services.yml` for an example how to include them into an image.

-## Configuration options
-
-Some TS recipes support yocto variables to set build configuration. These variables can be set in .conf files (machine
-specific or local.conf), or .bbappend files. 
-
-### SmmGW SP
-
-The recipe supports the following configuration variables
-
-| Variable name         | Type | Description                                                                                            |
-|-----------------------|------|--------------------------------------------------------------------------------------------------------|
-| SMMGW_AUTH_VAR        | Bool | Enable Authenticated variable support                                                                  |
-| SMMGW_INTERNAL_CRYPTO | Bool | Use MbedTLS build into SmmGW for authentication related crypto operations. Depends on SMMGW_AUTH_VAR=1 |
-
-fTPM tests are supported by OEQA but are disabled by default due to their lengthy execution time. To enable them, set the RUN_TPM2_TESTS
-variable e.g. in local.conf.
-
-The list of supported test cases can be found in the `tests` array in the `meta-arm/recipes-tpm/tpm2-tools/files/tpm2-test-all` script.
-These can be ran one-by-one, but currently running all of them by calling `tpm2-test-all` results in a failure of the `tpm2-abmrd` tool.
-
-The tests not supported are listed in the same script under the `Failing tests:` line.
-
-This script was created to meet the needs of the Trusted Services project, but in the future it should be updated to be configurable to
-support generic usage. The aforementioned issue shall also be solved, so the supported tests could run together.
-
-### fTPM SP
-
-The fTPM SP is an experimental feature. Please refer to the [TS documentation][^5] for details on limitations. 
-
-The current integration enables the fTPM Secure Partition and supports running tpm2-tools tests to verify correct
-functionality. Secure Boot and other features that leverage TPM capabilities are not enabled currently.
-
-Configuration variables of the recipe:
-
-| Variable name         | Type | Description                                                                                            |
-|-----------------------|------|--------------------------------------------------------------------------------------------------------|
-| RUN_TPM2_TESTS        | Bool | Enable automatic execution of TPM tests from OEQA to verify the TS fTPM SP                             |
-
-The current integration targeting the fvp-base machine enables fTPM SP and allows running the tests. To reproduce the
-build please use `ci/fvp-base-ts-ftpm.yml`. This configuration:
-
-   - deploys the SP in the SWd
-   - amends the Linux kernel configuration:
-      - enables the tpm-crb driver
-      - add a patch to allow DTB based discovery
-   - deploys user-space components (tpm2-tss, tpm2-abrmd, tmp2-tools)
-   - configures the initialization system to start tpm2-abrmd.
-
-The configuration leverages tpm2 components form meta-secure-core layer. 
-
-Validation can be performed by running the script located at `meta-arm/recipes-tpm/tpm2-tools/files/tpm2-test-all`. This
-script runs a subset of tpm2 tests. While all tpm2 test pass when executed individually, executing the entire test suite
-in a sequence leads to a failure of the `tpm2-abmrd` tool. As a workaround some test cases are disabled in the script.
-You can find the list of disabled tests marked under the `Failing tests` section of the script.
-
-Note: tpm2 tests was designed to validate the tpm2 reference stack. Its use for verifying the fTPM SP is not fully
-aligned with this intent. As such, the current validation approach is considered “best effort” and is suitable for
-development purposes. A more appropriate and comprehensive test suite should be selected for future validation.

 ------
 [^1]: https://trusted-services.readthedocs.io/en/integration/overview/index.html
@@ -139,9 +68,3 @@ development purposes. A more appropriate and comprehensive test suite should be
 [^3]: https://trusted-services.readthedocs.io/en/integration/deployments/test-executables.html

 [^4]: https://optee.readthedocs.io/en/latest/building/gits/optee_test.html
-
-[^5]: https://trusted-services.readthedocs.io/en/integration/services/tpm-service-description.html
-
-[^6]: https://optee.readthedocs.io/en/latest/architecture/spmc.html
-
-[^7]: https://kas.readthedocs.io
@@ -0,0 +1,12 @@
+header:
+  version: 13
+
+repos:
+  meta-arm:
+    layers:
+      meta-arm-systemready:
+
+distro: nodistro
+
+target:
+  - arm-systemready-firmware
@@ -0,0 +1,12 @@
+header:
+  version: 13
+  includes:
+    - kas/arm-systemready-firmware.yml
+
+env:
+  TESTIMAGE_AUTO: "1"
+  # The full testimage run typically takes around 12-24h on fvp-base.
+  TEST_OVERALL_TIMEOUT: "${@ 24*60*60}"
+
+target:
+  - arm-systemready-ir-acs
@@ -0,0 +1,7 @@
+header:
+  version: 13
+  includes:
+    - kas/arm-systemready-firmware.yml
+
+target:
+  - arm-systemready-linux-distros-debian
@@ -0,0 +1,8 @@
+header:
+  version: 13
+  includes:
+    - kas/arm-systemready-firmware.yml
+    - kas/arm-systemready-linux-distros-unattended-installation.yml
+
+target:
+  - arm-systemready-linux-distros-opensuse
@@ -0,0 +1,11 @@
+header:
+  version: 16
+
+env:
+  DISTRO_UNATTENDED_INST_TESTS:
+  # The full testimage run typically takes around 12-24h on fvp-base.
+  TEST_OVERALL_TIMEOUT: "${@ 24*60*60}"
+  
+local_conf_header:
+  systemready-unattended-inst: |
+    TESTIMAGE_AUTO = "${@oe.utils.vartrue("DISTRO_UNATTENDED_INST_TESTS", "1", "", d)}"
@@ -1,22 +0,0 @@
-header:
-  version: 14
-  includes:
-    - kas/corstone1000-base.yml
-    - kas/corstone1000-image-configuration.yml
-    - kas/corstone1000-firmware-only.yml
-    - kas/fvp-eula.yml
-
-env:
-  DISPLAY:
-  WAYLAND_DISPLAY:
-  XAUTHORITY:
-
-local_conf_header:
-  testimagefvp: |
-    IMAGE_CLASSES += "fvpboot"
-
-  mass-storage: |
-    # Ensure the Mass Storage device is absent
-    FVP_CONFIG[board.msd_mmc.p_mmc_file] = "invalid.dat"
-
-machine: corstone1000-a320-fvp
@@ -5,33 +5,25 @@ distro: poky

 defaults:
  repos:
-    branch: master
+    branch: scarthgap

 repos:
-  bitbake:
-    url: https://git.openembedded.org/bitbake
-    layers:
-      bitbake: disabled
-
-  core:
-    url: https://git.openembedded.org/openembedded-core
-    layers:
-      meta:
-
-  meta-yocto:
-    url: https://git.yoctoproject.org/meta-yocto
-    layers:
-      meta-poky:
-
  meta-arm:
    layers:
      meta-arm:
      meta-arm-bsp:
      meta-arm-toolchain:

+  poky:
+    url: https://git.yoctoproject.org/git/poky
+    commit: c5df9c829a549ca002c36afd6bdf23639831502e
+    layers:
+      meta:
+      meta-poky:
+
  meta-openembedded:
    url: https://git.openembedded.org/meta-openembedded
-    # commit: 461d85a1831318747af5abe86da193bcde3fd9b4
+    commit: 6de0ab744341ad61b0661aa28d78dc6767ce0786
    layers:
      meta-oe:
      meta-python:
@@ -39,7 +31,7 @@ repos:

  meta-secure-core:
    url: https://github.com/wind-river/meta-secure-core.git
-    # commit: 59d7e90542947c342098863b9998693ac79352b0
+    commit: 13cb4867fb1245581c80da3b94b72c4b4f15d67e
    layers:
      meta-secure-core-common:
      meta-signing-key:
@@ -4,6 +4,3 @@ header:
 local_conf_header:
  extsys: |
    MACHINE_FEATURES += "corstone1000-extsys"
-
-    # external system firmware
-    CORE_IMAGE_EXTRA_INSTALL:firmware += "external-system-elf"
@@ -10,7 +10,7 @@ local_conf_header:
    OVERRIDES .= ":firmware"

    # Need to ensure we build with a small libc
-    TCLIBC = "musl"
+    TCLIBC="musl"

  mass-storage: |
    # Ensure the Mass Storage device is absent
@@ -23,11 +23,6 @@ local_conf_header:
    INIT_MANAGER:firmware = "mdev-busybox"
    VIRTUAL-RUNTIME_init_manager:firmware = "busybox"

-    # This guarantees module auto-loading support at boot
-    # by adding /etc/init.d/modutils.sh and /etc/rcS.d/ files
-    CORE_IMAGE_EXTRA_INSTALL:append = " modutils-initscripts"
-    DISTRO_FEATURES:append = " sysvinit"
-
    # prevent the kernel image from being included in the intramfs rootfs
    PACKAGE_EXCLUDE:firmware += "kernel-image-*"

@@ -45,8 +40,10 @@ local_conf_header:
    CORE_IMAGE_EXTRA_INSTALL += "packagegroup-ts-tests-psa"
    CORE_IMAGE_EXTRA_INSTALL:firmware += "packagegroup-ts-tests-psa"

+    # external system firmware
+    CORE_IMAGE_EXTRA_INSTALL:firmware += "external-system-elf"
+
  capsule: |
-    # These variables are set here since they are not defined in the arm-systemready-firmware recipe or under multiconfig mode.
    CAPSULE_EXTENSION = "uefi.capsule"
-    CAPSULE_VERSION = "6"
-    CAPSULE_NAME = "${MACHINE}-v${CAPSULE_VERSION}"
+    CAPSULE_FW_VERSION = "6"
+    CAPSULE_NAME = "${MACHINE}-v${CAPSULE_FW_VERSION}"
@@ -1,13 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/debug.yml
-
-local_conf_header:
-  sshd: |
-    IMAGE_FEATURES += "ssh-server-dropbear"
-  fvp_sshkeys: |
-    CORE_IMAGE_EXTRA_INSTALL:append = " ssh-pregen-hostkeys"
-
-target:
-  - core-image-minimal
@@ -14,7 +14,7 @@ machine: fvp-base

 defaults:
  repos:
-    refspec: master
+    refspec: scarthgap

 repos:
  meta-arm:
@@ -9,7 +9,7 @@ BBFILE_COLLECTIONS += "meta-arm-bsp"
 BBFILE_PATTERN_meta-arm-bsp = "^${LAYERDIR}/"
 BBFILE_PRIORITY_meta-arm-bsp = "5"

-LAYERSERIES_COMPAT_meta-arm-bsp = "wrynose"
+LAYERSERIES_COMPAT_meta-arm-bsp = "nanbield scarthgap"

 LAYERDEPENDS_meta-arm-bsp = "core meta-arm"
 # This won't be used by layerindex-fetch, but works everywhere else
@@ -20,8 +20,11 @@ LAYERDEPENDS_meta-arm-bsp:append:musca-s1 = " meta-python"
 # Additional license directories.
 LICENSE_PATH += "${LAYERDIR}/custom-licenses"

+BBFILES_DYNAMIC += " \
+    meta-arm-systemready:${LAYERDIR}/dynamic-layers/meta-arm-systemready/*/*/*.bb \
+    meta-arm-systemready:${LAYERDIR}/dynamic-layers/meta-arm-systemready/*/*/*.bbappend \
+"
+
 WARN_QA:append:layer-meta-arm-bsp = " patch-status"

 addpylib ${LAYERDIR}/lib oeqa
-
-IMAGE_ROOTFS_EXTRA_ARGS ?= ""
@@ -1,17 +0,0 @@
-#@TYPE: Machine
-#@NAME: corstone1000-a320-fvp machine
-#@DESCRIPTION: Machine configuration for Corstone1000 64-bit FVP with A320 CPU
-
-require conf/machine/include/corstone1000-a320.inc
-require conf/machine/corstone1000-fvp.conf
-
-# Ethos-U85 FVP configuration
-ETHOSU_NUM_MACS ?= "256"
-FVP_CONFIG[host.ethosu.num_macs] = "${ETHOSU_NUM_MACS}"
-
-# Reuse FVP recipe overrides
-MACHINEOVERRIDES .= ":corstone1000-fvp"
-
-# Override FVP executable provider and executable name.
-FVP_PROVIDER:corstone1000-a320-fvp ??= "fvp-corstone1000-a320-native"
-FVP_EXE:corstone1000-a320-fvp = "FVP_Corstone-1000-A320"
@@ -3,21 +3,13 @@
 #@DESCRIPTION: Machine configuration for Corstone1000 64-bit FVP
 require conf/machine/include/corstone1000.inc

-require ${@bb.utils.contains('MACHINE_FEATURES', 'corstone1000-extsys', \
-    'conf/machine/include/corstone1000-extsys.inc', '', d)}
-
 TFA_TARGET_PLATFORM = "fvp"

 TFM_PLATFORM_IS_FVP = "TRUE"

-CORSTONE_1000_TYPE = "CORSTONE_1000_TYPE_CORTEX_A35_FVP"
-
-WKS_FILE:firmware ?= "corstone1000-flash-firmware-fvp.wks.in"
-
 # testimage config
 TEST_TARGET = "OEFVPTarget"
-TEST_TARGET_IP = "127.0.0.1:2222"
-DEFAULT_TEST_SUITES:append = " fvp_boot fvp_devices"
+TEST_SUITES = "fvp_boot"

 # FVP Config
 FVP_PROVIDER ?= "fvp-corstone1000-native"
@@ -25,12 +17,13 @@ FVP_EXE ?= "FVP_Corstone-1000"
 FVP_CONSOLES[default] = "host_terminal_0"
 FVP_CONSOLES[tf-a] = "host_terminal_1"
 FVP_CONSOLES[se] = "secenc_terminal"
+FVP_CONSOLES[extsys] = "extsys_terminal"

 #Disable Time Annotation
 FASTSIM_DISABLE_TA = "0"

 # FVP Parameters
-FVP_CONFIG[se.trustedBootROMloader.fname] ?= "trusted-firmware-m/bl1.bin"
+FVP_CONFIG[se.trustedBootROMloader.fname] ?= "bl1.bin"
 FVP_CONFIG[board.xnvm_size] ?= "64"
 FVP_CONFIG[se.trustedSRAM_config] ?= "6"
 FVP_CONFIG[se.BootROM_config] ?= "3"
@@ -47,11 +40,14 @@ FVP_CONFIG[se.cryptocell.USER_OTP_FILTERING_DISABLE] ?= "1"
 # Boot image
 FVP_DATA ?= "board.flash0=corstone1000-flash-firmware-image-${MACHINE}.wic@0x68000000"

+# External system (cortex-M3)
+FVP_CONFIG[extsys_harness0.extsys_flashloader.fname] ?= "es_flashfw.bin"

 # FVP Terminals
 FVP_TERMINALS[host.host_terminal_0] ?= "Normal World Console"
 FVP_TERMINALS[host.host_terminal_1] ?= "Secure World Console"
 FVP_TERMINALS[se.secenc_terminal] ?= "Secure Enclave Console"
+FVP_TERMINALS[extsys0.extsys_terminal] ?= "Cortex M3"

 # MMC card configuration
 FVP_CONFIG[board.msd_mmc.card_type] ?= "SDHC"
@@ -60,7 +56,7 @@ FVP_CONFIG[board.msd_mmc.diagnostics] ?= "0"
 FVP_CONFIG[board.msd_mmc.p_max_block_count] ?= "0xFFFF"
 FVP_CONFIG[board.msd_config.pl180_fifo_depth] ?= "16"
 FVP_CONFIG[board.msd_mmc.support_unpadded_images] ?= "true"
-FVP_CONFIG[board.msd_mmc.p_mmc_file] ?= "${IMAGE_LINK_NAME}.wic"
+FVP_CONFIG[board.msd_mmc.p_mmc_file] ?= "${IMAGE_NAME}.wic"

 # MMC2 card configuration
 FVP_CONFIG[board.msd_mmc_2.card_type] ?= "SDHC"
@@ -6,9 +6,4 @@ require conf/machine/include/corstone1000.inc

 TFA_TARGET_PLATFORM = "fpga"

-# Unlike the FVP, MPS3 supports CoreSight
-MACHINE_FEATURES += "coresight"
-
-CORSTONE_1000_TYPE = "CORSTONE_1000_TYPE_CORTEX_A35_MPS3"
-
-WKS_FILE:firmware ?= "corstone1000-flash-firmware-mps3.wks.in"
+PLATFORM_IS_FVP = "FALSE"
@@ -4,19 +4,13 @@
 #@NAME: Armv8-A Base Platform FVP machine
 #@DESCRIPTION: Machine configuration for Armv8-A Base Platform FVP model

-require conf/machine/include/arm/arch-armv8-5a.inc
-
-# Set variables here to make it easier to change Instruction Set Architectures
-# on the FVP Base machine, which should make it easier to test both the tunes
-# and the virtual hardware.  These variables are set via the DEFAULT_TUNE
-ARM_ISA_MAJOR = "${@int(d.getVar('ARMPKGARCH').split('v')[1][0])}"
-ARM_ISA_MINOR = "${@int(d.getVar('ARMPKGARCH')[d.getVar('ARMPKGARCH').find('-')+1]) if '-' in d.getVar('ARMPKGARCH') else 0 }"
+require conf/machine/include/arm/arch-armv8-4a.inc

 ARM_SYSTEMREADY_FIRMWARE = "trusted-firmware-a:do_deploy"
 ARM_SYSTEMREADY_ACS_CONSOLE = "default"
 EXTRA_IMAGEDEPENDS = "${ARM_SYSTEMREADY_FIRMWARE}"

-MACHINE_FEATURES = "efi vfat"
+MACHINE_FEATURES = "efi"

 IMAGE_NAME_SUFFIX = ""
 IMAGE_FSTYPES += "wic"
@@ -25,8 +19,7 @@ WKS_FILE ?= "efi-disk.wks.in"
 SERIAL_CONSOLES = "115200;ttyAMA0"

 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-KERNEL_DTB_NAME = "fvp-base-revc.dtb"
-KERNEL_DEVICETREE = "arm/${KERNEL_DTB_NAME}"
+KERNEL_DEVICETREE = "arm/fvp-base-revc.dtb"
 KERNEL_IMAGETYPE = "Image"

 EXTRA_IMAGEDEPENDS += "trusted-firmware-a"
@@ -34,7 +27,7 @@ EXTRA_IMAGEDEPENDS += "trusted-firmware-a"
 # FVP u-boot configuration
 UBOOT_MACHINE = "vexpress_fvp_defconfig"

-EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boot", "grub-efi", d)}"
+EFI_PROVIDER ?= "grub-efi"

 # As this is a virtual target that will not be used in the real world there is
 # no need for real SSH keys.
@@ -58,18 +51,15 @@ FVP_CONFIG[cluster0.check_memory_attributes] ?= "0"
 FVP_CONFIG[cluster1.check_memory_attributes] ?= "0"
 FVP_CONFIG[cluster0.stage12_tlb_size] ?= "1024"
 FVP_CONFIG[cluster1.stage12_tlb_size] ?= "1024"
-FVP_CONFIG[bp.secureflashloader.fname] ?= "trusted-firmware-a/bl1.bin"
-FVP_CONFIG[bp.flashloader0.fname] ?= "trusted-firmware-a/fip.bin"
-FVP_CONFIG[bp.virtioblockdevice.image_path] ?= "${IMAGE_LINK_NAME}.wic"
-
-# FVP Base default is 8.0, so there is no has_arm_v8-0 for it.  However, this is needed for every version after.  So set this accordingly
-FVP_EXTRA_ARGS = "--parameter cluster0.has_arm_v${ARM_ISA_MAJOR}-${ARM_ISA_MINOR}=1 --parameter cluster1.has_arm_v${ARM_ISA_MAJOR}-${ARM_ISA_MINOR}=1"
-FVP_EXTRA_ARGS += "${@bb.utils.contains('TUNE_FEATURES', 'sve', '--parameter cluster0.has_sve=1 --parameter cluster1.has_sve=1', '', d)}"
-FVP_EXTRA_ARGS += "${@bb.utils.contains('TUNE_FEATURES', 'sve2', '--parameter cluster0.sve.has_sve2=1 --parameter cluster1.sve.has_sve2=1', '', d)}"
-
+FVP_CONFIG[bp.secureflashloader.fname] ?= "bl1-fvp.bin"
+FVP_CONFIG[bp.flashloader0.fname] ?= "fip-fvp.bin"
+FVP_CONFIG[bp.virtioblockdevice.image_path] ?= "${IMAGE_NAME}.wic"
+# Set the baseline to ARMv8.4, as the default is 8.0.
+FVP_CONFIG[cluster0.has_arm_v8-4] = "1"
+FVP_CONFIG[cluster1.has_arm_v8-4] = "1"
 FVP_CONSOLES[default] = "terminal_0"
 FVP_TERMINALS[bp.terminal_0] ?= "Console"
 FVP_TERMINALS[bp.terminal_1] ?= ""
 FVP_TERMINALS[bp.terminal_2] ?= ""
 FVP_TERMINALS[bp.terminal_3] ?= ""
-FVP_CONFIG[bp.secure_memory] ?= "1"
+FVP_CONFIG[bp.secure_memory] ?= "1"
@@ -1,4 +0,0 @@
-# Cortex-A320 variant of the Corstone-1000 platform.
-MACHINEOVERRIDES =. "corstone1000-a320:"
-MACHINE_FEATURES += "cortexa320"
-OVERRIDES .= ":cortexa320"
@@ -1,6 +0,0 @@
-
-FVP_CONSOLES[extsys] = "extsys_terminal"
-
-FVP_CONFIG[extsys_harness0.extsys_flashloader.fname] = "es_flashfw.bin"
-
-FVP_TERMINALS[extsys0.extsys_terminal] = "Cortex M3"
@@ -1,24 +1,20 @@
-TUNE_FILE = "conf/machine/include/arm/armv8a/tune-cortexa35.inc"
-TUNE_FILE:cortexa320 = "conf/machine/include/arm/arch-armv9-2a.inc"
-require ${TUNE_FILE}
+require conf/machine/include/arm/armv8a/tune-cortexa35.inc

 MACHINEOVERRIDES =. "corstone1000:"

 # TF-M
-PREFERRED_VERSION_trusted-firmware-m ?= "2.2.%"
-PREFERRED_VERSION_trusted-firmware-m-scripts-native ?= "2.2.%"
+PREFERRED_VERSION_trusted-firmware-m ?= "2.0.%"

 # TF-A
 TFA_PLATFORM = "corstone1000"
-PREFERRED_VERSION_trusted-firmware-a ?= "2.14.%"
-PREFERRED_VERSION_tf-a-tests ?= "2.14.%"
+PREFERRED_VERSION_trusted-firmware-a ?= "2.10.%"
+PREFERRED_VERSION_tf-a-tests ?= "2.10.%"

 TFA_BL2_BINARY = "bl2-corstone1000.bin"
 TFA_FIP_BINARY = "fip-corstone1000.bin"

 # optee
-PREFERRED_VERSION_optee-os ?= "4.9.%"
-PREFERRED_VERSION_optee-client ?= "4.9.%"
+PREFERRED_VERSION_optee-os ?= "4.1.%"

 # Trusted Services
 TS_PLATFORM = "arm/corstone1000"
@@ -26,8 +22,8 @@ TS_SP_SE_PROXY_CONFIG = "corstone1000"
 # Include smm-gateway and se-proxy SPs into optee-os binary
 MACHINE_FEATURES += "ts-smm-gateway ts-se-proxy"

-# U-Boot
-PREFERRED_VERSION_u-boot ?= "2025.10"
+# u-boot
+PREFERRED_VERSION_u-boot ?= "2023.07%"
 MACHINE_FEATURES += "efi"
 EFI_PROVIDER ?= "grub-efi"

@@ -38,7 +34,7 @@ IMAGE_CMD:wic[vardeps] += "GRUB_LINUX_APPEND"

 # Linux kernel
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "6.19%"
+PREFERRED_VERSION_linux-yocto ?= "6.6.%"
 KERNEL_IMAGETYPE = "Image"
 KERNEL_IMAGETYPE:firmware = "Image.gz"
 # add FF-A support in the kernel
@@ -53,6 +49,7 @@ IMAGE_FSTYPES += "wic"
 # Need to clear the suffix so TESTIMAGE_AUTO works
 IMAGE_NAME_SUFFIX = ""
 WKS_FILE ?= "efi-disk-no-swap.wks.in"
+WKS_FILE:firmware ?= "corstone1000-flash-firmware.wks.in"

 # making sure EXTRA_IMAGEDEPENDS will be used while creating the image
 WKS_FILE_DEPENDS:append = " ${EXTRA_IMAGEDEPENDS}"
@@ -66,11 +63,3 @@ ARM_SYSTEMREADY_FIRMWARE = "${FIRMWARE_DEPLOYMENT}:do_deploy \
                            corstone1000-esp-image:do_image_complete \
                           "
 ARM_SYSTEMREADY_ACS_CONSOLE ?= "default"
-
-# Workaround IMAGE_ROOTFS_EXTRA_SPACE being ignored when images are repacked
-IMAGE_ROOTFS_EXTRA_ARGS += "--extra-filesystem-space ${@${IMAGE_ROOTFS_EXTRA_SPACE}}K"
-
-# Enable Authenticated variable support in SmmGW
-SMMGW_AUTH_VAR = "1"
-# Use MbedTLS build into SmmGW for authentication related crypto operations.
-SMMGW_INTERNAL_CRYPTO = "1"
@@ -8,7 +8,7 @@ TUNE_FEATURES = "aarch64"

 require conf/machine/include/arm/arch-armv8a.inc

-MACHINE_FEATURES = "usbhost usbgadget alsa screen wifi bluetooth optee pci coresight"
+MACHINE_FEATURES = "usbhost usbgadget alsa screen wifi bluetooth optee pci"

 KERNEL_IMAGETYPE = "Image.gz"
 KERNEL_DEVICETREE = "arm/juno.dtb arm/juno-r1.dtb arm/juno-r2.dtb"
@@ -0,0 +1,51 @@
+# Configuration for Arm N1SDP development board
+
+#@TYPE: Machine
+#@NAME: N1SDP machine
+#@DESCRIPTION: Machine configuration for N1SDP
+
+require conf/machine/include/arm/armv8-2a/tune-neoversen1.inc
+
+KERNEL_IMAGETYPE = "Image"
+
+IMAGE_FSTYPES += "wic wic.gz wic.bmap tar.bz2 ext4"
+
+SERIAL_CONSOLES = "115200;ttyAMA0"
+
+# Set default WKS
+WKS_FILE ?= "n1sdp-efidisk.wks"
+IMAGE_EFI_BOOT_FILES ?= "n1sdp-multi-chip.dtb n1sdp-single-chip.dtb"
+WKS_FILE_DEPENDS:append = " ${EXTRA_IMAGEDEPENDS}"
+
+# Use kernel provided by yocto
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_VERSION_linux-yocto ?= "6.6%"
+
+# RTL8168E Gigabit Ethernet Controller is attached to the PCIe interface
+MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "linux-firmware-rtl8168"
+
+# TF-A
+EXTRA_IMAGEDEPENDS += "trusted-firmware-a"
+TFA_PLATFORM = "n1sdp"
+PREFERRED_VERSION_trusted-firmware-a ?= "2.10.%"
+PREFERRED_VERSION_tf-a-tests ?= "2.10.%"
+
+# SCP
+EXTRA_IMAGEDEPENDS += "virtual/control-processor-firmware"
+
+#UEFI EDK2 firmware
+EXTRA_IMAGEDEPENDS += "edk2-firmware"
+PREFERRED_VERSION_edk2-firmware ?= "202311"
+
+#optee
+PREFERRED_VERSION_optee-os ?= "4.1.%"
+PREFERRED_VERSION_optee-os-tadevkit ?= "4.1.%"
+PREFERRED_VERSION_optee-test ?= "4.1.%"
+PREFERRED_VERSION_optee-client ?= "4.1.%"
+
+#grub-efi
+EFI_PROVIDER ?= "grub-efi"
+MACHINE_FEATURES += "efi"
+
+# SD-Card firmware
+EXTRA_IMAGEDEPENDS += "sdcard-image-n1sdp"
@@ -1,63 +0,0 @@
-# Configuration for Arm Neoverse N2 Reference Design development board
-
-#@TYPE: Machine
-#@NAME: RD N2
-#@DESCRIPTION: Machine configuration for RD N2
-
-require conf/machine/include/arm/armv9a/tune-neoversen2.inc
-
-EXTRA_IMAGEDEPENDS += "virtual/control-processor-firmware"
-EXTRA_IMAGEDEPENDS += "trusted-firmware-a"
-
-KERNEL_IMAGETYPE ?= "Image"
-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
-SERIAL_CONSOLES = "115200;ttyAMA2"
-EXTRA_IMAGEDEPENDS += "edk2-firmware"
-
-EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boot", "grub-efi", d)}"
-MACHINE_FEATURES += "efi"
-
-IMAGE_FSTYPES:forcevariable = "cpio.gz wic"
-IMAGE_NAME_SUFFIX = ""
-IMAGE_CLASSES += "fvpboot"
-
-WKS_FILE ?= "efi-disk.wks.in"
-WKS_FILE_DEPENDS:append = " ${EXTRA_IMAGEDEPENDS}"
-
-# testimage config
-TEST_TARGET = "OEFVPTarget"
-TEST_TARGET_IP = "127.0.0.1:2222"
-DEFAULT_TEST_SUITES:append = " fvp_boot fvp_devices"
-TEST_FVP_DEVICES ?= "watchdog networking"
-
-# FVP Config
-FVP_PROVIDER ?= "fvp-rdn2-native"
-FVP_EXE ?= "FVP_RD_N2"
-
-FVP_DATA ?= "css.scp.armcortexm7ct=scp-firmware/scp_ramfw.bin@0x0BD80000 \
-             css.mcp.armcortexm7ct=scp-firmware/mcp_ramfw.bin@0x0BF80000"
-
-FVP_CONFIG[css.gic_distributor.ITS-device-bits] ?= "20"
-FVP_CONFIG[css.mcp.ROMloader.fname] ?= "scp-firmware/mcp_romfw.bin"
-FVP_CONFIG[css.scp.ROMloader.fname] ?= "scp-firmware/scp_romfw.bin"
-FVP_CONFIG[css.trustedBootROMloader.fname] ?= "trusted-firmware-a/bl1.bin"
-FVP_CONFIG[board.flashloader0.fname] ?= "trusted-firmware-a/fip.bin"
-
-FVP_CONFIG[board.dram_size] ?= "0x200000000"
-
-# Virtio configuration
-FVP_CONFIG[board.virtio_net.enabled] ?= "1"
-FVP_CONFIG[board.virtio_net.hostbridge.userNetworking] ?= "1"
-FVP_CONFIG[board.virtio_net.hostbridge.userNetPorts] = "2222=22"
-FVP_CONFIG[board.virtioblockdevice.image_path] ?= "${IMAGE_LINK_NAME}.wic"
-
-FVP_CONSOLES[default] = "terminal_ns_uart_ap"
-FVP_TERMINALS[css.scp.terminal_uart_scp] ?= "SCP Console"
-FVP_TERMINALS[css.mcp.terminal_uart_mcp] ?= "MCP Console"
-FVP_TERMINALS[css.terminal_ns_uart_ap] ?= "NS Console"
-FVP_TERMINALS[css.terminal_s_uart_ap] ?= "S Console"
-
-# Seeing intermittent test timeout errors in CI where the boot is almost
-# complete.  Lengthen the timeout to allow for more opportunity to
-# complete successfully.
-TEST_FVP_LINUX_BOOT_TIMEOUT = "900"
@@ -1,65 +0,0 @@
-# Configuration for Arm Neoverse V2 Reference Design development board
-
-#@TYPE: Machine
-#@NAME: RD V2
-#@DESCRIPTION: Machine configuration for RD V2
-
-#FIXME - doesn't boot with armv9 tunes
-#require conf/machine/include/arm/arch-armv9a.inc
-require conf/machine/include/arm/arch-armv8a.inc
-
-EXTRA_IMAGEDEPENDS += "virtual/control-processor-firmware"
-EXTRA_IMAGEDEPENDS += "trusted-firmware-a"
-
-KERNEL_IMAGETYPE ?= "Image"
-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
-SERIAL_CONSOLES = "115200;ttyAMA2"
-EXTRA_IMAGEDEPENDS += "edk2-firmware"
-
-EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boot", "grub-efi", d)}"
-MACHINE_FEATURES += "efi"
-
-IMAGE_FSTYPES:forcevariable = "cpio.gz wic"
-IMAGE_NAME_SUFFIX = ""
-IMAGE_CLASSES += "fvpboot"
-
-WKS_FILE ?= "efi-disk.wks.in"
-WKS_FILE_DEPENDS:append = " ${EXTRA_IMAGEDEPENDS}"
-
-# testimage config
-TEST_TARGET = "OEFVPTarget"
-TEST_TARGET_IP = "127.0.0.1:2222"
-DEFAULT_TEST_SUITES:append = " fvp_boot fvp_devices"
-TEST_FVP_DEVICES ?= "watchdog networking"
-
-# FVP Config
-FVP_PROVIDER ?= "fvp-rdv2-native"
-FVP_EXE ?= "FVP_RD_V2"
-
-FVP_DATA ?= "css.scp.armcortexm7ct=scp-firmware/scp_ramfw.bin@0x0BD80000 \
-             css.mcp.armcortexm7ct=scp-firmware/mcp_ramfw.bin@0x0BF80000"
-
-FVP_CONFIG[css.gic_distributor.ITS-device-bits] ?= "20"
-FVP_CONFIG[css.mcp.ROMloader.fname] ?= "scp-firmware/mcp_romfw.bin"
-FVP_CONFIG[css.scp.ROMloader.fname] ?= "scp-firmware/scp_romfw.bin"
-FVP_CONFIG[css.trustedBootROMloader.fname] ?= "trusted-firmware-a/bl1.bin"
-FVP_CONFIG[board.flashloader0.fname] ?= "trusted-firmware-a/fip.bin"
-
-FVP_CONFIG[board.dram_size] ?= "0x200000000"
-
-# Virtio configuration
-FVP_CONFIG[board.virtio_net.enabled] ?= "1"
-FVP_CONFIG[board.virtio_net.hostbridge.userNetworking] ?= "1"
-FVP_CONFIG[board.virtio_net.hostbridge.userNetPorts] = "2222=22"
-FVP_CONFIG[board.virtioblockdevice.image_path] ?= "${IMAGE_LINK_NAME}.wic"
-
-FVP_CONSOLES[default] = "terminal_ns_uart_ap"
-FVP_TERMINALS[css.scp.terminal_uart_scp] ?= "SCP Console"
-FVP_TERMINALS[css.mcp.terminal_uart_mcp] ?= "MCP Console"
-FVP_TERMINALS[css.terminal_ns_uart_ap] ?= "NS Console"
-FVP_TERMINALS[css.terminal_s_uart_ap] ?= "S Console"
-
-# Seeing intermittent test timeout errors in CI where the boot is almost
-# complete.  Lengthen the timeout to allow for more opportunity to
-# complete successfully.
-TEST_FVP_LINUX_BOOT_TIMEOUT = "900"
@@ -26,20 +26,17 @@ EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boo
 SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"

 EXTRA_IMAGEDEPENDS += "edk2-firmware"
-#FIXME - in 2.15.0, new logic for pen hold the SMP cores was added, which breaks this platform.  Hold this back until it can be resolved.
-PREFERRED_VERSION_trusted-firmware-a ?= "2.14.%"

 QB_SYSTEM_NAME = "qemu-system-aarch64"
 QB_MACHINE = "-machine sbsa-ref"
 QB_CPU = "-cpu neoverse-n2"
-QB_SMP = "-smp 4"
 QB_MEM = "-m 1024"
 QB_DEFAULT_FSTYPE = "wic.qcow2"
-QB_NETWORK_DEVICE = "-device e1000e,netdev=net0,mac=@MAC@"
+QB_NETWORK_DEVICE = "-device virtio-net-pci,netdev=net0,mac=@MAC@"
 QB_DRIVE_TYPE = "/dev/hd"
 QB_ROOTFS_OPT = "-drive file=@ROOTFS@,if=ide,format=qcow2"
 QB_DEFAULT_KERNEL = "none"
-QB_OPT_APPEND = "-device usb-tablet -device usb-kbd -drive if=pflash,format=raw,unit=0,readonly=on,file=@DEPLOY_DIR_IMAGE@/SBSA_FLASH0.fd -drive if=pflash,format=raw,unit=1,readonly=on,file=@DEPLOY_DIR_IMAGE@/SBSA_FLASH1.fd"
+QB_OPT_APPEND = "-device usb-tablet -device usb-kbd -pflash @DEPLOY_DIR_IMAGE@/SBSA_FLASH0.fd -pflash @DEPLOY_DIR_IMAGE@/SBSA_FLASH1.fd"
 QB_SERIAL_OPT = "-device virtio-serial-pci -chardev null,id=virtcon -device virtconsole,chardev=virtcon"
 QB_TCPSERIAL_OPT = "-device virtio-serial-pci -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon"
 # sbsa-ref is a true virtual machine so can't use KVM
@@ -0,0 +1,24 @@
+# Configuration for Arm SGI575 development board
+
+#@TYPE: Machine
+#@NAME: SGI575
+#@DESCRIPTION: Machine configuration for SGI575
+
+require conf/machine/include/arm/armv8-2a/tune-cortexa75.inc
+
+EXTRA_IMAGEDEPENDS += "virtual/control-processor-firmware"
+
+EXTRA_IMAGEDEPENDS += "trusted-firmware-a"
+
+KERNEL_IMAGETYPE ?= "Image"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+SERIAL_CONSOLES = "115200;ttyAMA0"
+
+#grub-efi
+EFI_PROVIDER ?= "grub-efi"
+MACHINE_FEATURES += "efi"
+
+IMAGE_FSTYPES += "cpio.gz wic"
+
+WKS_FILE ?= "sgi575-efidisk.wks"
+WKS_FILE_DEPENDS:append = " ${EXTRA_IMAGEDEPENDS}"
@@ -1,12 +0,0 @@
-version: 2
-build:
-  os: "ubuntu-22.04"
-  tools:
-    python: "3.9"
-sphinx:
-  configuration: meta-arm-bsp/documentation/corstone1000-a320/conf.py
-formats:
-  - pdf
-python:
-  install:
-    - requirements: meta-arm-bsp/documentation/requirements.txt
@@ -1,117 +0,0 @@
-# SPDX-FileCopyrightText: <text>Copyright 2026 Arm Limited and/or its
-# affiliates <open-source-office@arm.com></text>
-#
-# SPDX-License-Identifier: MIT
-
-# Configuration file for the Sphinx documentation builder.
-#
-# This file only contains a selection of the most common options. For a full
-# list see the documentation:
-# https://www.sphinx-doc.org/en/master/usage/configuration.html
-
-# -- Path setup --------------------------------------------------------------
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-#
-# sys.path.insert(0, os.path.abspath('.'))
-
-import os
-import re
-import sys
-
-import yaml
-
-# Append the documentation directory to the path, so we can import variables
-sys.path.append(os.path.dirname(__file__))
-
-_metadata_path = os.path.join(os.path.dirname(__file__), 'corstone-a320_metadata.yaml')
-with open(_metadata_path, encoding='utf-8') as metadata_file:
-    _metadata = yaml.safe_load(metadata_file) or {}
-
-_metadata_variables = {
-    item['name']: item['value']
-    for item in _metadata.get('variables', [])
-    if item.get('name') and item.get('value')
-}
-
-
-# -- Project information -----------------------------------------------------
-
-project = 'Corstone-1000 Armv9-A Edge-AI'
-copyright = '2026, Arm Limited'
-author = 'Arm Limited'
-
-
-# -- General configuration ---------------------------------------------------
-
-# Add any Sphinx extension module names here, as strings. They can be
-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
-# ones.
-extensions = [
-    'myst_parser',
-    'sphinx_rtd_theme',
-]
-
-source_suffix = {
-    '.rst': 'restructuredtext',
-    '.md': 'markdown',
-}
-
-myst_enable_extensions = [
-    'colon_fence',
-]
-
-# Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
-
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-# This pattern also affects html_static_path and html_extra_path.
-exclude_patterns = [
-    '_build',
-    'Thumbs.db',
-    '.DS_Store',
-    'docs/infra',
-    'corstone-a320_map.md',
-    'corstone-a320_metadata.yaml',
-]
-
-
-# -- Options for HTML output -------------------------------------------------
-
-# The theme to use for HTML and HTML Help pages.  See the documentation for
-# a list of builtin themes.
-#
-html_theme = 'sphinx_rtd_theme'
-html_theme_options = {
-    'flyout_display': 'attached',
-}
-
-# Define the canonical URL if you are using a custom domain on Read the Docs
-html_baseurl = os.environ.get("READTHEDOCS_CANONICAL_URL", "")
-
-# Tell Jinja2 templates the build is running on Read the Docs
-if os.environ.get("READTHEDOCS", "") == "True":
-    if "html_context" not in globals():
-        html_context = {}
-    html_context["READTHEDOCS"] = True
-
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-#html_static_path = ['_static']
-
-
-def _replace_metadata_variables(app, docname, source):
-    source[0] = re.sub(
-        r'\$([A-Za-z0-9_]+)',
-        lambda match: _metadata_variables.get(match.group(1), match.group(0)),
-        source[0],
-    )
-
-
-def setup(app):
-    app.connect('source-read', _replace_metadata_variables)
@@ -1,6 +0,0 @@
- topics/introducing.md
- topics/software-architecture.md
- topics/user-guide.md
- topics/tests.md
- topics/release-notes.md
- topics/change-log.md
@@ -1,106 +0,0 @@
---
-title: Corstone-1000 with Cortex-A320
-subtitle: ""
-abstract: Arm Corstone-1000 with Cortex-A320 is a reference solution for IoT devices. It is part of Total Solution for IoT which consists of hardware and software reference implementation.
-author: Arm
-status: REL
-keywords: [IoT, software]
-bookpartno: 112000
-product: Corstone-1000 with Cortex-A320
-product_type: Open Source Projects
-product_revision:
-  - prefix: Version
-    version: "0101"
-    version_label: "2026.02"
-output_type: "software"
-conformance_notice: "true"
-content_type: User Guide
-audience:
-  - Software Developers
-categories:
-  - IoT
-themes:
-  - IoT
-intended_audience: Software Developers
-terminology_review: new
-releases:
- - revision: 0100-01
-   date: 2026-05-01
-   change_summary: Update
-   permissions: nonconfidential
-
-variables:
- name: arm_developer_cs1000_website
-  value: 'https://developer.arm.com/Tools%20and%20Software/Corstone-1000%20Software'
- name: arm_developer_cs1000_search
-  value: 'https://developer.arm.com/search#q=corstone-1000'
- name: arm_developer_mhu_website
-  value: 'https://developer.arm.com/documentation/ka005129/latest/#:~:text=An%20MHU%20is%20a%20device,that%20a%20message%20is%20available'
- name: arm_developer_secureboot_website
-  value: 'https://developer.arm.com/documentation/PRD29-GENC-009492/c/TrustZone-Software-Architecture/Booting-a-secure-system/Secure-boot'
- name: arm_architecture_security_features_platform_security
-  value: 'https://www.arm.com/architecture/security-features/platform-security'
- name: linux_repository
-  value: 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/'
- name: arm_trustzone_for_cortex_a_website
-  value: 'https://www.arm.com/technologies/trustzone-for-cortex-a'
- name: arm_fmw_framework_a_profile_pdf
-  value: 'https://developer.arm.com/documentation/den0077/latest'
- name: arm_fmw_framework_m_profile_pdf
-  value: 'https://developer.arm.com/architectures/Firmware%20Framework%20for%20M-Profile'
- name: platform_security_fwu_for_a_profile_pdf
-  value: 'https://developer.arm.com/documentation/den0118/a/'
- name: psa_firmware_update_ihi_0093_api_reference_website
-  value: 'https://arm-software.github.io/psa-api/fwu/1.0/api/api.html'
- name: edk2_capsule_generation_tool_repository
-  value: 'https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/Capsule/GenerateCapsule.py'
- name: psa_fwu_den0018_specification_website
-  value: 'https://developer.arm.com/documentation/den0118/latest/'
- name: ts_psa_fwu_service_website
-  value: 'https://trusted-services.readthedocs.io/en/stable/services/fwu/psa-fwu-m.html'
- name: tfm_shim_layer_website
-  value: 'https://trustedfirmware-m.readthedocs.io/en/latest/design_docs/services/tfm_fwu_service.html#shim-layer-between-fwu-and-bootloader'
- name: op_tee_os_repository
-  value: 'https://github.com/OP-TEE/optee_os'
- name: psa_certified_website
-  value: 'https://www.psacertified.org/'
- name: psa_l2_ready
-  value: 'https://www.psacertified.org/products/corstone-1000/'
- name: systemready_ir_certification
-  value: 'https://armkeil.blob.core.windows.net/developer/Files/pdf/certificate-list/arm-systemready-ve-arm-neoverse.pdf'
- name: trusted_board_boot_requirements_client_pdf
-  value: 'https://developer.arm.com/documentation/den0006/latest'
- name: trusted_firmware_m_website
-  value: 'https://www.trustedfirmware.org/projects/tf-m/'
- name: trusted_firmware_m_bl1_website
-  value: 'https://trustedfirmware-m.readthedocs.io/en/latest/design_docs/booting/bl1.html'
- name: trusted_firmware_a_bl2_website
-  value: 'https://developer.arm.com/documentation/108028/0000/RD-TC22-software/Software-components/AP-firmware/Trusted-firmware-A-BL2'
- name: trusted_firmware_a_fip_guide
-  value: 'https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html#firmware-image-package-fip'
- name: trusted_services_website
-  value: 'https://www.trustedfirmware.org/projects/trusted-services/'
- name: trusted_services_uefi_smm_website
-  value: 'https://trusted-services.readthedocs.io/en/integration/services/uefi-smm-services.html#'
- name: das_u_boot_repository
-  value: 'https://github.com/u-boot/u-boot.git'
- name: keil_rtx5_website
-  value: 'https://developer.arm.com/Tools%20and%20Software/Keil%20MDK/RTX5%20RTOS'
- name: ppa_website
-  value: 'https://developer.arm.com/documentation/102738/0100/Power--performance--and-area-analysis'
- name: mcuboot_website
-  value: 'https://docs.mcuboot.com/'
- name: arm_developer_fvp
-  value: 'https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps'
- name: secure_debug_manager_repo_readme
-  value: 'https://github.com/ARM-software/secure-debug-manager/tree/master?tab=readme-ov-file#secure-debug-manager-psa-adac--sdc-600'
- name: secure_debug_manager_armds_integration
-  value: 'https://github.com/ARM-software/secure-debug-manager?tab=readme-ov-file#arm-development-studio-integration'
- name: meta_arm_repository_release_branch
-  value: 'https://docs.yoctoproject.org/next/migration-guides/migration-6.0.html'
- name: arm_ulink_pro_website
-  value: 'https://www.arm.com/products/development-tools/debug-probes/ulink-pro'
- name: arm_ds_website
-  value: 'https://www.arm.com/products/development-tools/embedded-and-software/arm-development-studio'
- name: edk2_repository
-  value: 'https://github.com/tianocore/edk2'
@@ -1,12 +0,0 @@
-# Corstone-1000 Armv9-A Edge-AI
-
-```{toctree}
-:maxdepth: 2
-
-topics/introducing
-topics/software-architecture
-topics/user-guide
-topics/tests
-topics/release-notes
-topics/change-log
-```
@@ -1,150 +0,0 @@
-# Change log {.chapter permissions=non-confidential}
-
-This document contains a summary of the new features, changes and fixes in each release of the Corstone-1000 with Cortex-A320 software stack.
-
-## Version 2026.05 {.reference}
-
-The following changes are present in this release:
-
- Continued Corstone-1000 with Cortex-A320 enablement across U-Boot, TF-A, TF-M, OP-TEE, and Linux with the split A320 device tree, GIC-700 support, Ethos-U85 DT alignment, and NPU reset via the external-system controller.
- Enabled and documented FVP SMP builds and platform-agnostic multicore support, including the errata override fixes for Corstone-1000 with Cortex-A320 and removal of the reboot workaround note.
- Split Corstone-1000 with Cortex-A320 FVP support into a dedicated machine configuration and standalone documentation.
-
-### Corstone-1000 with Cortex-A320 components versions {.reference}
-
-The following component versions are available:
-
-Table: Corstone-1000 with Cortex-A320 component versions
-
-+----------------------------------------+-----------------------------------+
-| Component                              | Version                           |
-+========================================+===================================+
-| linux-yocto                            | 6.19                              |
-+----------------------------------------+-----------------------------------+
-| u-boot                                 | 2025.10                           |
-+----------------------------------------+-----------------------------------+
-| external-system                        | 0.1.0                             |
-+----------------------------------------+-----------------------------------+
-| optee-client                           | 4.9.0                             |
-+----------------------------------------+-----------------------------------+
-| optee-os                               | 4.9.0                             |
-+----------------------------------------+-----------------------------------+
-| trusted-firmware-a                     | 2.14.1                            |
-+----------------------------------------+-----------------------------------+
-| trusted-firmware-m                     | 2.2.2                             |
-+----------------------------------------+-----------------------------------+
-| libts                                  | v1.3.0                            |
-+----------------------------------------+-----------------------------------+
-| ts-sp-{se-proxy, smm-gateway}          | v1.3.0                            |
-+----------------------------------------+-----------------------------------+
-| ts-psa-{crypto, iat, its. ps}-api-test | 74dc6646ff                        |
-+----------------------------------------+-----------------------------------+
-
-### Yocto distribution components versions {.reference}
-
-The following Yocto distribution components versions are available:
-
-Table: Yocto distribution component versions
-
-+-------------------+------------+
-| Component         | Version    |
-+===================+============+
-| meta-arm          | wrynose    |
-+-------------------+------------+
-| bitbake           | 22021758e6 |
-+-------------------+------------+
-| meta-openembedded | 9af4488d46 |
-+-------------------+------------+
-| openembedded-core | 06dd66e622 |
-+-------------------+------------+
-| meta-yocto        | 8251bdad5f |
-+-------------------+------------+
-| meta-secure-core  | 07a99ae241 |
-+-------------------+------------+
-| busybox           | 1.37.0     |
-+-------------------+------------+
-| musl              | 1.2.6      |
-+-------------------+------------+
-| gcc-arm-none-eabi | 15.2.rel1  |
-+-------------------+------------+
-| gcc-cross-aarch64 | 15.2.0     |
-+-------------------+------------+
-| openssl           | 3.5.6      |
-+-------------------+------------+
-
-## Version 2025.12 {.reference}
-
-The following changes are present in this release:
-
- Delivered end-to-end Cortex-A320 enablement across U-Boot, TF-A, TF-M, OP-TEE, Yocto machine layers, and documentation, including device-tree updates, MPIDR handling, and FVP model renaming.
- Rolled out the PSA Firmware Update (DEN0118) pipeline: U-Boot capsule parsing, Bootloader Abstraction Layer in TF-M, ESRT exposure, and Trusted Services IPC bridges replacing legacy capsule code.
- Hardened the new firmware update flow with EFI self-tests, metadata restructuring for partial and multi-image acceptance, and RSE-COMMS gating refinements.
- Upgraded key firmware components (TF-A 2.13.0, TF-M 2.2.1, Trusted Services 1.2.0, OP-TEE OS 4.7.0) and introduced targeted test skips plus integer-only build modes to keep validation green.
- Cleaned and renumbered downstream patch series across Trusted Services and TF-M while removing obsolete integrations to align with upstream baselines.
- Refreshed release material and architecture guides to describe the A320 profile, PSA FWU behavior, and updated software stack.
- Added KAS profiles, machine includes, and automated FVP selection logic to streamline developer workflows for the refreshed platform configuration.
-
-### Corstone-1000 with Cortex-A320 components versions {.reference}
-
-The following component versions are available:
-
-Table: Corstone-1000 with Cortex-A320 component versions
-
-+----------------------------------------+-----------------------------------+
-| Component                              | Version                           |
-+========================================+===================================+
-| linux-yocto                            | 6.12.60                           |
-+----------------------------------------+-----------------------------------+
-| u-boot                                 | 2025.04                           |
-+----------------------------------------+-----------------------------------+
-| optee-client                           | 4.7.0                             |
-+----------------------------------------+-----------------------------------+
-| optee-os                               | 4.7.0                             |
-+----------------------------------------+-----------------------------------+
-| trusted-firmware-a                     | 2.13.0                            |
-+----------------------------------------+-----------------------------------+
-| trusted-firmware-m                     | 2.2.1                             |
-+----------------------------------------+-----------------------------------+
-| libts                                  | v1.2.0                            |
-+----------------------------------------+-----------------------------------+
-| ts-sp-{se-proxy, smm-gateway}          | v1.2.0                            |
-+----------------------------------------+-----------------------------------+
-| ts-psa-{crypto, iat, its. ps}-api-test | 74dc6646ff                        |
-+----------------------------------------+-----------------------------------+
-
-### Yocto distribution components versions {.reference}
-
-The following Yocto distribution components versions are available:
-
-
-Table: Yocto distribution component versions
-
-+-------------------+------------+
-| Component         | Version    |
-+===================+============+
-| meta-arm          | whinlatter |
-+-------------------+------------+
-| bitbake           | 0dde1a3ff8 |
-+-------------------+------------+
-| meta-openembedded | fc0152e434 |
-+-------------------+------------+
-| openembedded-core | 4bd920ad7d |
-+-------------------+------------+
-| meta-yocto        | b3b6592635 |
-+-------------------+------------+
-| meta-secure-core  | 63209fb150 |
-+-------------------+------------+
-| meta-ethos        | aa2504a32f |
-+-------------------+------------+
-| meta-sca          | e68f1a9d17 |
-+-------------------+------------+
-| busybox           | 1.37.0     |
-+-------------------+------------+
-| musl              | 1.2.5      |
-+-------------------+------------+
-| gcc-arm-none-eabi | 13.3.rel1  |
-+-------------------+------------+
-| gcc-cross-aarch64 | 15.2.0     |
-+-------------------+------------+
-| openssl           | 3.5.4      |
-+-------------------+------------+
@@ -1,14 +0,0 @@
-# Introduction {.chapter permissions=non-confidential}
-
-Arm Corstone-1000 with Cortex-A320 is a reference solution for IoT devices
-based on Arm Corstone-1000, but with Cortex-A320 CPU, Ethos-U85 NPU and
-GIC700 (Generic Interrupt Controller). It is part of Total Solution
-for IoT which consists of hardware and software reference implementations.
-
-## Disclaimer {.reference}
-
-Arm reference solutions are Arm public example software projects that track and
-pull upstream components, incorporating their respective security fixes
-published over time. Arm partners are responsible for ensuring that the
-components they use contain all the required security fixes, if and when they
-deploy a product derived from Arm reference solutions.
@@ -1,40 +0,0 @@
-# Release notes {.chapter permissions=non-confidential}
-
-You expressly assume all liabilities and risks relating to your use or operation
-of your software and hardware designed or modified using the Arm Tools,
-including without limitation, your software or hardware designed or
-intended for safety-critical applications. Should your software or hardware
-prove defective, you assume the entire cost of all necessary servicing, repair
-or correction.
-
-## Release notes - 2026.05 {.reference}
-
-The following knowns issues and limitations are present in this release:
-
- Crypto isolation is not supported in the Secure world of Corstone-1000. Additionally, clients in
-  the Normal world are not isolated from one another. Therefore, if an end user wants to add a new
-  Secure Partition (SP) (such as a software TPM) that accesses the Crypto service via the SE-Proxy,
-  they are responsible for implementing their own isolation mechanisms to ensure proper security boundaries.
- DSTREAM debug probe may experience unreliable USB connectivity when used with Arm DS for secure debug.
-  This issue is under active investigation, and we are working to identify and resolve compatibility issues in a future update.
-  As a more stable alternative, the ULINKpro debug probe is recommended for use with Corstone-1000 in secure debug scenarios.
-
-## Release notes - 2025.12 {.reference}
-
-The following knowns issues and limitations are present in this release:
-
- Corstone-1000 with Cortex-A320 FVP does not currently support Symmetric Multiprocessing
- Corstone-1000 with Cortex-A320 FVP becomes unresponsive when the Linux kernel driver for the Ethos-U85 NPU loads automatically after a software reboot.
- Crypto isolation is not supported in the Secure world of Corstone-1000. Additionally, clients in
-  the Normal world are not isolated from one another. Therefore, if an end user wants to add a new
-  Secure Partition (SP) (such as a software TPM) that accesses the Crypto service via the SE-Proxy,
-  they are responsible for implementing their own isolation mechanisms to ensure proper security boundaries.
- DSTREAM debug probe may experience unreliable USB connectivity when used with Arm DS for secure debug.
-  This issue is under active investigation, and we are working to identify and resolve compatibility issues in a future update.
-  As a more stable alternative, the ULINKpro debug probe is recommended for use with Corstone-1000 in secure debug scenarios.
-
-## Support {.reference}
-
-For technical support, email [Arm subsystem support](mailto:support-subsystem-iot@arm.com).
-
-For security issues, contact [Arm Security](mailto:psirt@arm.com).
@@ -1,311 +0,0 @@
-# Software architecture {.chapter permissions=non-confidential}
-
-The combination of Corstone-1000 software and hardware reference solution is [PSA Level-2 ready certified]($psa_l2_ready) as well as [Arm SystemReady Devicetree certified]($systemready_ir_certification). Please rely on the Corstone-1000 platform for certification needs.
-
-More information on the Corstone-1000 subsystems product(s), variants and design can be
-found on [Arm Developer]($arm_developer_cs1000_website).
-
-This document explicitly focuses on the software part of the solution and
-provides internal details on the software components. The reference
-software package of the platform can be retrieved following instructions
-present in the user guide document.
-
-## Design overview {.reference}
-
-This variant of the Corstone-1000 platform replaces the Host System's Cortex-A35
-processor with a Cortex-A320. In this configuration, the optional External System
-(previously a Cortex-M3) is replaced by an Arm Ethos-U85 Neural Processing Unit (NPU).
-The Ethos-U85 runs in the direct drive configuration, where the Host System is
-responsible for managing the NPU directly.
-
-![Cortex-A320 subsystems](../images/CorstoneA320Subsystems.png)
-
-## Secure boot chain {.reference}
-
-For the security of a device, it is essential that only authorized
-software should run on the device.
-
-The Corstone-1000 boot uses a [Secure boot]($arm_developer_secureboot_website) chain process
-where an already authenticated image verifies and loads the following software in the chain.
-
-For the boot chain process to work, the start of the chain should be trusted, forming the
-Root of Trust (RoT) of the device. The RoT of the device is immutable in
-nature and encoded into the device by the device manufacturer before it
-is deployed into the field.
-In Corstone-1000, the content of the ROM and CC312 One Time Programmable (OTP) memory forms the RoT.
-
-Verification of an image can happen either by comparing the computed and stored hashes, or by
-checking the signature of the image if the image is signed.
-
-![Secure boot chain](../images/SecureBootChain.png)
-
-It is a lengthy chain to boot the software on Corstone-1000.
-
-### TF-M BL1\_1 {.reference}
-
-On power-up, the Secure Enclave begins execution from TF-M BL1\_1, which resides in ROM and serves as
-the Root of Trust (RoT) for the device.
-
-TF-M BL1\_1 is the immutable bootloader and is responsible for:
-
- Provisioning the device during the first boot
- Performing hardware initialization
- Verifying the integrity and authenticity of the next stage in the boot chain
-
-At boot time, TF-M BL1\_1:
-
- Copies the TF-M BL1\_2 image from OTP to RAM.
- Verifies the integrity of BL1\_2 by comparing its computed hash with the hash stored in OTP.
-
-### TF-M BL1\_2 {.reference}
-
-During provisioning, the TF-M BL1\_2 binary, along with its hashes and cryptographic keys, is stored
-in One-Time Programmable (OTP) memory.
-
-Once verified, TF-M BL1\_2:
-
- Takes control and verifies the next stage in the boot chain, which is TF-M BL2.
- Computes the hash of the BL2 image and compares it with the BL2 hash stored in OTP to ensure
-  integrity before transferring execution to BL2.
-
-The TF-M BL1 design details can be found in the [TF-M design documents]($trusted_firmware_m_bl1_website).
-
-:::note
-Corstone-1000 has some differences compared to this design due to memory (OTP/ROM) limitations:
-
- BL1\_1 code size is larger than needed because it handles most of the hardware initialization instead of the BL1\_2.
- BL1\_2 cannot be updated during provisioning time because the provisioning bundle that contains its code is located in the ROM.
- BL1\_2 does not use the post-quantum LMS verification.
- BL2 cannot be updated because it is verified by comparing the computed hash to the hash stored in the OTP.
-
-:::
-
-### TF-M BL2 {.reference}
-
-In this system, TF-M BL2 refers to MCUBoot.
-
-On the first boot, MCUBoot can provision additional cryptographic keys. It is responsible for authenticating both:
-
- TF-M (Trusted Firmware-M), and
- The initial bootloader of the Host system, [Trusted Firmware-A (TF-A) BL2]($trusted_firmware_a_bl2_website)
-
-This authentication is done by verifying the digital signatures of the respective images.
-
-MCUBoot performs image verification in the following steps:
-
-1. Load the image from non-volatile memory into RAM.
-2. Validate the image's signature using the corresponding public key.
-
-:::note
-The public key present in the image header is validated by comparing with the hash. Depending on the image, the hash of the public key is either stored in the OTP or part of the software which is being already verified in the previous stages.
-:::
-
-The execution control is passed to TF-M after the verification.
-As the runtime executable of the Secure Enclave, TF-M initializes itself before
-bringing the Host system out of reset.
-
-### Host system authentication {.reference}
-
-The Host system follows the boot standard defined in [Trusted Board Boot Requirements Client]($trusted_board_boot_requirements_client_pdf)
-to authenticate the Secure and Non-secure software.
-
-The [Firmware Image Package (FIP)]($trusted_firmware_a_fip_guide) packs bootloader images and
-other payloads into a single archive.
-
-![FIPDiagram](../images/FIPDiagram.png)
-
-The FIP for Corstone-1000 contains:
-
- Trusted firmware-A BL2
- AP EL3 Runtime firmware, BL31 image
- AP Secure Payload, BL32 image
- AP Normal world firmware -U-boot, BL33 image
- Trusted OS Firmware configuration file used by Trusted OS (BL32), TOS_FW_CONFIG
- Key certificates
- Content certificates
-
-To load and validate TF-A BL2, TF-M BL2 first parses the GUID Partition Table (GPT)
-to locate the FIP. It then determines the offset of TF-A BL2 within the FIP.
-
-:::note
-TF-M does not check the FIP signature, it only checks the TF-A BL2's signature in the FIP.
-:::
-
-The implicitly trusted components are:
-
- A SHA-256 hash of the Root of Trust Public Key (ROTPK.) For development purposes, a development ROTPK is used and its hash embedded into the TF-A BL2 image. This public key is provided by the TF-A source code.
- TF-A BL2 image - it can be trusted because it has been verified by TF-M BL2 before starting TF-A.
-
-The remaining components in the Chain of Trust (CoT) are either certificates or bootloader images.
-
-#### Bootloader authentication {.reference}
-
-The FIP contains two types of certificates:
-
- Content Certificates used to store the hash of a bootloader image.
- Key Certificates used to verify public keys used to sign Content Certificates.
-
-The Host system bootloader images are authenticated by computing their hash and comparing it to the corresponding hash found in the Content Certificate.
-
-#### Certificates verification {.reference}
-
-The public keys defined in the Trusted Key Certificate are used to verify the later certificates in
-the CoT process. The Trusted Key Certificate is verified with the Root of Trust Public Key.
-
-#### UEFI authenticated variables {.reference}
-
-For UEFI Secure Boot, authenticated variables can be accessed from the secure flash.
-The feature has been integrated in U-Boot, which authenticates the images as per the UEFI
-specification before executing them.
-
-## Secure services {.reference}
-
-Corstone-1000 is unique in offering a secure environment for running trusted workloads.
-While the Host system includes TrustZone technology, the platform also features a hardware-isolated
-Secure Enclave, specifically designed to execute these secure workloads.
-
-In Corstone-1000, essential Secure Services—such as Cryptography, Protected Storage,
-Internal Trusted Storage, and Attestation—are provided through PSA Functional APIs implemented in TF-M.
-
-From the user's perspective, there is no difference when communicating with these services,
-whether they run in the Secure Enclave or in the Secure world of the Host system.
-The diagram below illustrates the data flow for such calls.
-
-![Secure services](../images/SecureServices.png)
-
-The Secure Enclave Proxy Secure Partition (SE Proxy SP) is a proxy managed by OP-TEE that forwards
-Secure Service calls to the Secure Enclave. This communication uses the
-[RSE communication protocol](https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html).
-While the protocol supports shared memory and MHU interrupts as a doorbell mechanism between cores,
-in Corstone-1000, the entire message is currently transmitted through the MHU channels.
-Corstone-1000 implements Isolation Level 2 using the Cortex-M0+ Memory Protection Unit (MPU).
-
-Users can define their own secure services to run either in the Host system's Secure World or in
-the Secure Enclave. This choice involves a trade-off between latency and security.
-Services running in the Secure Enclave benefit from strong, hardware-enforced isolation,
-offering higher security but at the cost of increased latency. In contrast, services running in the
-Host Secure World experience lower latency, but rely on TrustZone technology for virtualized isolation,
-which offers comparatively less robust security.
-
-## PSA secure firmware update {.reference}
-
-The Corstone-1000 platform necessitates a robust, secure, and flexible firmware update mechanism
-including partial capsule update to ensure fielded devices can receive critical patches, feature enhancements,
-and security fixes without compromising system integrity. To meet these requirements, we have implemented the
-Platform Security Architecture (PSA) Firmware Update (FWU) framework on Corstone-1000, leveraging Trusted Firmware-M (TF-M)
-for the Secure Enclave, U-Boot as the host-side client on Cortex-A, and the UEFI capsule update mechanism for payload
-encapsulation. This design supports the Fixed Virtual Platform (FVP) target, providing consistent behavior across
-simulation-based deployments. The Corstone-1000 supports FWU
-which complies with the
-[Platform Security Firmware Update for the A-profile Arm Architecture]($platform_security_fwu_for_a_profile_pdf)
-and [PSA Firmware Update IHI 0093]($psa_firmware_update_ihi_0093_api_reference_website)
-specifications.
-
-To standardize and streamline capsule creation with multiple FMP payloads, the
-[EDK2 capsule generation tool]($edk2_capsule_generation_tool_repository)
-tool has been integrated into the meta-arm Yocto layer for Corstone-1000. This integration involves defining
-build rules for generating UEFI capsules as part of the firmware image build process. Configuration parameters
-exposed in the recipe allow developers to specify the number of FMP payloads, target image GUIDs, version numbers etc.
-This capsule ensures that all update payloads conform to the UEFI FMP specification and are ready for
-validation and delivery by U‑Boot.
-
-The FWU solution for Corstone-1000 is composed of three primary domains:
-
- Host System
- Trusted Services intermediary
- Secure Enclave
-
-Each domain has distinct responsibilities and communicates through standardized interfaces.
-
-![System architecture PSA firmware update](../images/SystemArchitecturePSAFirmwareUpdate.png)
-
-On the host side, U-Boot functions as the FWU client and orchestrates the update process from capsule retrieval to
-payload delivery based on [PSA FWU DEN0018 specification]($psa_fwu_den0018_specification_website)
-via Arm FF-A framework. The Trusted-Services SE Proxy secure partition serves as a gateway between the non-secure host
-environment and the Secure Enclave. The [PSA FWU service]($ts_psa_fwu_service_website) running in the Trusted Services
-implementation forwards the data to the Secure Enclave via MHU-based PSA calls. Within the Secure Enclave, the PSA FWU
-Agent, conforming to [PSA Firmware Update IHI 0093]($psa_firmware_update_ihi_0093_api_reference_website) specification,
-orchestrates the actual flash programming, metadata management, and rollback protection mechanisms. The agent relies on a
-bespoke [shim layer]($tfm_shim_layer_website) to abstract hardware‑specific flash operations and bootloader interactions.
-
-As defined in the specification, the external flash is divided into two banks: one bank holds the
-currently running images, while the other is used to stage new images.
-
-There are four updatable components: **BL2**, **TF-M**, **the FIP** and **the Kernel Image** (the initramfs bundle).
-New images are delivered and accepted in the form of UEFI capsules.
-
-![External flash](../images/ExternalFlash.png)
-
-When a FWU is initiated on Corstone-1000, the following sequence of operations takes place:
-
-1. Capsule Retrieval and Preparation
-
-   U-Boot on the host system retrieves the firmware capsule.
-   It validates the capsule header and parses the FMP (Firmware Management Protocol) descriptor list to identify the payloads to be updated.
-
-   For each FMP descriptor, U-Boot:
-
-   Splits the firmware payload into 4 KiB chunks.
-   Invokes the PSA_FWU_Update API for each chunk, transmitting the buffer address via the FF-A (Firmware Framework for Arm) shared memory interface.
-
-2. Secure Transmission and Forwarding
-
-   The PSA Firmware Update (FWU) service, running as part of Trusted Services, receives the chunks through Secure Partition Client (SPC) calls.
-   It forwards these chunks to the Secure Enclave using MHU-based PSA calls.
-
-3. Flashing Within the Secure Enclave
-
-   Inside the Secure Enclave, the PSA FWU Agent dispatches each chunk to the shim layer.
-
-   The shim layer:
-
-   Erases the corresponding sectors in the non-active flash bank.
-   Writes the received firmware chunks at the correct offsets.
-   During partial updates, it also copies static partitions from the active bank to the non-active one to maintain consistency.
-
-4. Finalization and Boot Preparation
-
-   After all chunks are successfully written:
-
-   The shim updates the firmware manifest and the EFI System Resource Table (ESRT) entries to reflect the new image version.
-   This step enables the bootloader to recognize the new firmware for a trial boot.
-   The platform then performs an automatic reset, booting into the non-active bank in trial mode.
-
-5. Trial Boot and Confirmation
-
-   In trial mode, U-Boot evaluates the new firmware and issues either an accept or reject command using the PSA FWU ABI.
-   These commands are sent to the Secure Enclave, instructing the shim to update the firmware metadata accordingly.
-
-6. Recovery and Fallback Mechanism
-
-   If the trial boot is successful, the host sends an acknowledgment, transitioning the firmware state from 'trial' to 'regular'.
-
-   If the system fails or becomes unresponsive:
-
-   A watchdog timer triggers a system reset.
-   The BL1 firmware in the Secure Enclave detects repeated failures and reverts to the previously known-good flash bank.
-   This rollback mechanism ensures the device remains operational and recoverable, even after a failed update.
-
-![Secure firmware update](../images/SecureFirmwareUpdate.png)
-
-## UEFI runtime support in U-Boot {.reference}
-
-The implementation of UEFI boot-time and runtime APIs requires persistent variable storage. In
-Corstone-1000, UEFI variables are stored using the Protected Storage (PS) service.
-
-The diagram below illustrates the data flow for storing UEFI variables. U-Boot's UEFI subsystem
-communicates with the Secure World using the U-Boot FF-A driver, which interfaces with the
-[UEFI System Management Mode (SMM) service]($trusted_services_uefi_smm_website).
-
-The SMM service provides support for the UEFI System Management Mode. This support is implemented by the SMM Gateway secure partition.
-The SMM service then uses the Proxy Protected Storage (PS) provided by the SE Proxy SP.
-These PS calls are forwarded to the Secure Enclave, following the communication path described earlier.
-
-![UEFI runtime support flow](../images/UEFISupport.png)
-
-## References {.reference}
-
-For more information, see:
-
- [Arm Developer]($arm_developer_cs1000_search)
- [Arm Security Architectures]($arm_architecture_security_features_platform_security)
@@ -1,265 +0,0 @@
-# Build, flash and run {.chapter permissions=non-confidential}
-
-The Arm Corstone-1000 with Cortex-A320 software stack uses the Yocto Project to build a tiny Linux distribution suitable for the Arm Corstone-1000 with Cortex-A320 platform (kernel and initramfs filesystem less than 6 MB on the flash).
-
-The Corstone-1000 with Cortex-A320 software stack can be run on [Arm Corstone-1000 with Cortex-A320 FVP (Fixed Virtual Platform)](https://developer.arm.com/downloads/-/arm-ecosystem-fvps) and is built on top of Yocto Project's [Wrynose release]($meta_arm_repository_release_branch).
-
-The Yocto Project relies on the [BitBake](https://docs.yoctoproject.org/bitbake.html#bitbake-documentation) tool as its build tool. Please see the [Yocto Project documentation](https://docs.yoctoproject.org/) for more information.
-
-## Prerequisites {.reference}
-
-This guide assumes that your host machine is running Ubuntu 24.04 LTS (with `sudo` rights), with at least
-32GB of free disk space and 16GB of RAM as minimum requirement.
-
-The following prerequisites must be available on the host system:
-
- Git 2.39.2 or greater.
- Python 3.11.2 or greater.
- GNU Tar 1.34 or greater.
- GNU Compiler Collection 12.2 or greater.
- GNU Make 4.3 or greater.
- tmux 3.3 or greater.
-
-Please follow the steps described in the Yocto mega manual:
-
- [Compatible Linux Distribution](https://docs.yoctoproject.org/singleindex.html#compatible-linux-distribution)
- [Build Host Packages](https://docs.yoctoproject.org/singleindex.html#build-host-packages)
-
-## Software components {.reference}
-
-Within the Yocto Project, each component included in the Corstone-1000 with Cortex-A320 software stack is specified as
-a [BitBake recipe](https://docs.yoctoproject.org/bitbake/2.2/bitbake-user-manual/bitbake-user-manual-intro.html#recipes).
-The recipes specific to the Corstone-1000 with Cortex-A320 BSP are located at:
-`${WORKSPACE}/meta-arm/meta-arm-bsp/`.
-
-`${WORKSPACE}` refers to the absolute path to your workspace where the `meta-arm` repository will be cloned. Consider exporting it (e.g., `export WORKSPACE=$(realpath .)`) if you're already in the workspace directory,
-so you can copy and paste the commands from this guide verbatim.
-
-The Yocto machine config files are at:
-
- `${WORKSPACE}/meta-arm/meta-arm-bsp/conf/machine/include/corstone1000-a320.inc`
- `${WORKSPACE}/meta-arm/meta-arm-bsp/conf/machine/corstone1000-a320-fvp.conf`
-
-:::note
-All the paths stated in this document are absolute paths.
-:::
-
-### Host processor components {.reference}
-
-This section describes the components used in the host processor.
-
-#### Trusted Firmware-A {.reference}
-
-The following [Trusted Firmware-A](https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git) components are used:
-
-Table: Trusted Firmware-A components
-
-| Type      | Path                                                                                                             |
-| --------- | ---------------------------------------------------------------------------------------------------------------- |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend`                |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.14.1.bb`                     |
-
-#### Trusted Services {.reference}
-
-The following [Trusted Services](https://trusted-services.readthedocs.io/en/latest/index.html) components are used:
-
-Table: Trusted Services components
-
-| Type      | Path                                                                                                             |
-| --------- | ---------------------------------------------------------------------------------------------------------------- |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/libts_%.bbappend`                          |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-crypto-api-test_%.bbappend`        |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-iat-api-test_%.bbappend`           |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-its-api-test_%.bbappend`           |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-ps-api-test_%.bbappend`            |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-sp-se-proxy_%.bbappend`                |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-sp-smm-gateway_%.bbappend`             |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/libts_git.bb`                                  |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-crypto-api-test_git.bb`                |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-iat-api-test_git.bb`                   |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-its-api-test_git.bb`                   |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-ps-api-test_git.bb`                    |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-sp-smm-gateway_git.bb`                     |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-sp-se-proxy_git.bb`                        |
-
-#### OP-TEE {.reference}
-
-The following [OP-TEE](https://git.trustedfirmware.org/OP-TEE/optee_os.git) components are used:
-
-Table: OP-TEE components
-
-| Type      | Path                                                                                                             |
-| --------- | ---------------------------------------------------------------------------------------------------------------- |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/optee/optee-os_%.bbappend`                                 |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/optee/optee-os_4.9.0.bb`                                       |
-
-#### U-Boot {.reference}
-
-The following [U-Boot](https://github.com/u-boot/u-boot.git) components are used:
-
-Table: U-Boot components
-
-| Type      | Path                                                                                                             |
-| --------- | ---------------------------------------------------------------------------------------------------------------- |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/u-boot/u-boot_%.bbappend`                                           |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_%.bbappend`                                       |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_2025.10.bb`                                       |
-
-#### Linux {.reference}
-
-The distribution is based on the [Poky](https://docs.yoctoproject.org/ref-manual/terms.html#term-Poky)
-distribution which is a Linux distribution stripped down to a minimal configuration.
-
-The provided distribution is based on [BusyBox](https://www.busybox.net/) and built using [musl libc](https://musl.libc.org/).
-
-The following Linux components are used:
-
-Table: Linux components
-
-| Type      | Path                                                                                                             |
-| --------- | ---------------------------------------------------------------------------------------------------------------- |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-kernel/linux/linux-yocto_%.bbappend`                                |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-kernel/linux/linux-yocto_6.19.bb`                                   |
-| defconfig | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-kernel/linux/files/corstone1000/defconfig`                          |
-
-### Secure enclave components {.reference}
-
-This section describes the secure enclave components.
-
-#### Trusted Firmware-M {.reference}
-
-The following [Trusted Firmware-M](https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git) are used:
-
-Table: Trusted Firmware-M secure enclave components
-
-| Type      | Path                                                                                                             |
-| --------- | ---------------------------------------------------------------------------------------------------------------- |
-| bbappend  | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-m/trusted-firmware-m_%.bbappend`                |
-| Recipe    | `${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_2.2.2.bb`                     |
-
-## Build {.reference}
-
-To build the software stack, do the following:
-
-:::note
-Building binaries natively on Windows and AArch64 Linux is not supported. Use an Intel or AMD 64-bit architecture Linux based development machine to build the software stack and transfer the binaries to run the software stack on an FVP in Windows or AArch64 Linux if required.
-:::
-
-1. Create a new folder that will be your workspace:
-
-   ```
-   mkdir ${WORKSPACE}
-   cd ${WORKSPACE}
-   ```
-
-2. Install kas version 4.4 with `sudo` rights:
-
-   ```
-   sudo pip3 install kas==4.4
-   ```
-
-   Ensure the kas installation directory is visible on the `$PATH` environment variable.
-
-3. Clone the `meta-arm` Yocto layer in the workspace `${WORKSPACE}`.
-
-   ```
-   cd ${WORKSPACE}
-   git clone https://git.yoctoproject.org/git/meta-arm -b CORSTONE1000-2026.05
-   ```
-
-4. Accept the EULA on the [Arm Developer](https://developer.arm.com/downloads/-/arm-ecosystem-fvps/eula) site to build a Corstone-1000 with Cortex-A320 image for FVP as follows:
-
-   ```
-   export ARM_FVP_EULA_ACCEPT="True"
-   ```
-
-5. Build a Corstone-1000 with Cortex-A320 image:
-
-   ```
-   kas build meta-arm/kas/corstone1000-a320-fvp.yml:meta-arm/ci/debug.yml
-   ```
-
-A clean build takes a significant amount of time given that all of the development machine utilities are also
-built along with the target images. Those development machine utilities include executables (Python,
-CMake, etc.) and the required toolchains.
-
-Once the build succeeds, all output binaries will be placed in `${WORKSPACE}/build/tmp/deploy/images/corstone1000-a320-fvp/`.
-
-Everything apart from the Secure Enclave ROM firmware is bundled into a single binary, the
-`corstone1000-flash-firmware-image-corstone1000-a320-fvp.wic` file.
-
-The output binaries run in the Corstone-1000 with Cortex-A320 platform are the following:
-
- The Secure Enclave ROM firmware: `${WORKSPACE}/build/tmp/deploy/images/corstone1000-a320-fvp/trusted-firmware-m/bl1.bin`
- The internal firmware flash image: `${WORKSPACE}/build/tmp/deploy/images/corstone1000-a320-fvp/corstone1000-flash-firmware-image-corstone1000-a320-fvp.wic`
-
-## Build with SSH {.reference}
-
-The `meta-arm/kas/corstone1000-a320-fvp.yml` build produces an image for booting from flash.
-
-To build a bootable mass storage OS image with Dropbear SSH enabled, run:
-
-```
-kas build meta-arm/ci/corstone1000-a320-fvp.yml:meta-arm/kas/corstone1000-ssh.yml
-```
-
-The mass storage OS image can be found at `${WORKSPACE}/build/tmp/deploy/images/corstone1000-a320-fvp/core-image-minimal-corstone1000-a320-fvp.wic`
-
-:::note
-The generated `core-image-minimal-corstone1000-a320-fvp.fvpconf` attaches the mass storage OS image to `board.msd_mmc.p_mmc_file`.
-:::
-
-
-## Run {.reference}
-
-Once the platform is turned ON, the Secure Enclave will start to boot, wherein the relevant memory contents of the `*.wic`
-file are copied to their respective memory locations. Firewall policies are enforced
-on memories and peripherals before bringing the Host Processor out of reset.
-
-The Host Processor will boot TrustedFirmware-A, OP-TEE, U-Boot and then Linux before presenting a login prompt.
-
-A Fixed Virtual Platform (FVP) model of the Corstone-1000 with Cortex-A320 platform must be available to run the
-Corstone-1000 with Cortex-A320 FVP software image.
-
-A Yocto recipe is provided to download the latest supported FVP version.
-
-The recipe is located at `${WORKSPACE}/meta-arm/meta-arm/recipes-devtools/fvp/fvp-corstone1000-a320.bb`.
-
-The latest FVP version is `11.31.cs1000_a320_2` for Corstone-1000 with Cortex-A320, and the model is automatically downloaded and installed when using the `runfvp` command as follows:
-
-```
-kas shell meta-arm/kas/corstone1000-a320-fvp.yml:meta-arm/ci/debug.yml \
-c "../meta-arm/scripts/runfvp -- --version"
-```
-
-The FVP can also be manually downloaded from [Arm Developer](https://developer.arm.com/downloads/-/arm-ecosystem-fvps) to download the Corstone-1000 with Cortex-A320 FVP package.
-
-To set up the FVP:
-
-1. Run `tmux`:
-
-   ```
-   cd ${WORKSPACE} && tmux
-   ```
-
-2. Run the FVP within `tmux`:
-
-   ```
-   kas shell meta-arm/kas/corstone1000-a320-fvp.yml:meta-arm/ci/debug.yml \
-   -c "../meta-arm/scripts/runfvp --terminals=tmux"
-   ```
-
-   When the script is executed, three terminal instances will be launched:
-
-   - one for the Secure Enclave processing element
-   - two for the Host processor processing element.
-
-   ```
-   corstone1000-a320-fvp login:
-   ```
-
-3. Log in using the `root` username.
-
-## Security issue reporting {.reference}
-
-To report any security issues identified with Corstone-1000 with Cortex-A320, please send an email to [psirt@arm.com](mailto:psirt@arm.com).
@@ -1,5 +1,5 @@
 ..
- # Copyright (c) 2022-2026, Arm Limited.
+ # Copyright (c) 2022-2024, Arm Limited.
 #
 # SPDX-License-Identifier: MIT

@@ -10,265 +10,6 @@ Change Log
 This document contains a summary of the new features, changes and
 fixes in each release of Corstone-1000 software stack.

-***************
-Version 2026.05
-***************
-
-Changes
-=======
-
- Upgraded key Corstone-1000 components to U-Boot 2025.10, TF-A 2.14.1, TF-M 2.2.2, OP-TEE 4.9.0, Trusted Services 1.3.0, and Linux 6.19.
- Added GPT support in TF-M and updated MCUboot to use the GPT library for firmware-update partitions.
- Extended the TF-M firmware update flow with GPT fixes, partition create/remove/duplicate operations, metadata-only handling, flash erase protection, stale partition cleanup, and better handling of older images during PSA FWU.
- Added SSH-enabled build overlay for FVP mass-storage images.
- Removed GRUB from the initramfs boot package set.
-
-Corstone-1000 components versions
-=================================
-
-+-------------------------------------------+-------------------+
-| linux-yocto                               | 6.19              |
-+-------------------------------------------+-------------------+
-| u-boot                                    | 2025.10           |
-+-------------------------------------------+-------------------+
-| external-system                           | 0.1.0             |
-+-------------------------------------------+-------------------+
-| optee-client                              | 4.9.0             |
-+-------------------------------------------+-------------------+
-| optee-os                                  | 4.9.0             |
-+-------------------------------------------+-------------------+
-| trusted-firmware-a                        | 2.14.1            |
-+-------------------------------------------+-------------------+
-| trusted-firmware-m                        | 2.2.2             |
-+-------------------------------------------+-------------------+
-| libts                                     | v1.3.0            |
-+-------------------------------------------+-------------------+
-| ts-sp-{se-proxy, smm-gateway}             | v1.3.0            |
-+-------------------------------------------+-------------------+
-| ts-psa-{crypto, iat, its. ps}-api-test    | 74dc6646ff        |
-+-------------------------------------------+-------------------+
-
-Yocto distribution components versions
-======================================
-
-+-------------------------------------------+----------------+
-| meta-arm                                  | wrynose        |
-+-------------------------------------------+----------------+
-| bitbake                                   | 22021758e6     |
-+-------------------------------------------+----------------+
-| meta-openembedded                         | 9af4488d46     |
-+-------------------------------------------+----------------+
-| openembedded-core                         | 06dd66e622     |
-+-------------------------------------------+----------------+
-| meta-yocto                                | 8251bdad5f     |
-+-------------------------------------------+----------------+
-| meta-secure-core                          | 07a99ae241     |
-+-------------------------------------------+----------------+
-| busybox                                   | 1.37.0         |
-+-------------------------------------------+----------------+
-| musl                                      | 1.2.6          |
-+-------------------------------------------+----------------+
-| gcc-arm-none-eabi                         | 15.2.rel1      |
-+-------------------------------------------+----------------+
-| gcc-cross-aarch64                         | 15.2.0         |
-+-------------------------------------------+----------------+
-| openssl                                   | 3.5.6          |
-+-------------------------------------------+----------------+
-
-***************
-Version 2025.12
-***************
-
-Changes
-=======
-
- Delivered end-to-end Cortex-A320 enablement across U-Boot, TF-A, TF-M, OP-TEE, Yocto machine layers, and documentation, including device-tree updates, MPIDR handling, and FVP model renaming.
- Rolled out the PSA Firmware Update (DEN0118) pipeline: U-Boot capsule parsing, Bootloader Abstraction Layer in TF-M, ESRT exposure, and Trusted Services IPC bridges replacing legacy capsule code.
- Hardened the new firmware update flow with EFI self-tests, metadata restructuring for partial and multi-image acceptance, and RSE-COMMS gating refinements.
- Upgraded key firmware components (TF-A 2.13.0, TF-M 2.2.1, Trusted Services 1.2.0, OP-TEE OS 4.7.0) and introduced targeted test skips plus integer-only build modes to keep validation green.
- Cleaned and renumbered downstream patch series across Trusted Services and TF-M while removing obsolete integrations to align with upstream baselines.
- Refreshed release material and architecture guides to describe the A320 profile, PSA FWU behavior, and updated software stack.
- Added KAS profiles, machine includes, and automated FVP selection logic to streamline developer workflows for the refreshed platform configuration.
-
-Corstone-1000 components versions
-=================================
-
-+-------------------------------------------+-------------------+
-| linux-yocto                               | 6.12.60           |
-+-------------------------------------------+-------------------+
-| u-boot                                    | 2025.04           |
-+-------------------------------------------+-------------------+
-| external-system                           | 0.1.0             |
-+-------------------------------------------+-------------------+
-| optee-client                              | 4.7.0             |
-+-------------------------------------------+-------------------+
-| optee-os                                  | 4.7.0             |
-+-------------------------------------------+-------------------+
-| trusted-firmware-a                        | 2.13.0            |
-+-------------------------------------------+-------------------+
-| trusted-firmware-m                        | 2.2.1             |
-+-------------------------------------------+-------------------+
-| libts                                     | v1.2.0            |
-+-------------------------------------------+-------------------+
-| ts-sp-{se-proxy, smm-gateway}             | v1.2.0            |
-+-------------------------------------------+-------------------+
-| ts-psa-{crypto, iat, its. ps}-api-test    | 74dc6646ff        |
-+-------------------------------------------+-------------------+
-
-Yocto distribution components versions
-======================================
-
-+-------------------------------------------+----------------+
-| meta-arm                                  | whinlatter     |
-+-------------------------------------------+----------------+
-| bitbake                                   | 0dde1a3ff8     |
-+-------------------------------------------+----------------+
-| meta-openembedded                         | fc0152e434     |
-+-------------------------------------------+----------------+
-| openembedded-core                         | 4bd920ad7d     |
-+-------------------------------------------+----------------+
-| meta-yocto                                | b3b6592635     |
-+-------------------------------------------+----------------+
-| meta-secure-core                          | 63209fb150     |
-+-------------------------------------------+----------------+
-| busybox                                   | 1.37.0         |
-+-------------------------------------------+----------------+
-| musl                                      | 1.2.5          |
-+-------------------------------------------+----------------+
-| gcc-arm-none-eabi                         | 13.3.rel1      |
-+-------------------------------------------+----------------+
-| gcc-cross-aarch64                         | 15.2.0         |
-+-------------------------------------------+----------------+
-| openssl                                   | 3.5.4          |
-+-------------------------------------------+----------------+
-
-***************
-Version 2025.05
-***************
-
-Changes
-=======
-
- OP-TEE OS: Added support for v4.4
- Trusted Services: PSA-Crypto structures aligned with TF-M, added protobuf interface to crypto-sp
- Documentation: fixed typos, added host-level authentication section, enabled fly-out sidebar menu
- Das U-Boot: Reserved memory for RSS communication-pointer access protocol
- Linux Kernel: Upgraded kernel to v6.12, updated Upstream-Status notes for remoteproc patches
- Corstone-1000 image: Implemented IMAGE_ROOTFS_EXTRA_SPACE workaround
-
-Corstone-1000 components versions
-=================================
-
-+-------------------------------------------+-------------------+
-| linux-yocto                               | 6.12.30           |
-+-------------------------------------------+-------------------+
-| u-boot                                    | 2023.07.02        |
-+-------------------------------------------+-------------------+
-| external-system                           | 0.1.0             |
-+-------------------------------------------+-------------------+
-| optee-client                              | 4.4.0             |
-+-------------------------------------------+-------------------+
-| optee-os                                  | 4.4.0             |
-+-------------------------------------------+-------------------+
-| trusted-firmware-a                        | 2.11.0            |
-+-------------------------------------------+-------------------+
-| trusted-firmware-m                        | 2.1.1             |
-+-------------------------------------------+-------------------+
-| libts                                     | 602be60719        |
-+-------------------------------------------+-------------------+
-| ts-newlib                                 | 4.1.0             |
-+-------------------------------------------+-------------------+
-| ts-psa-{crypto, iat, its. ps}-api-test    | 74dc6646ff        |
-+-------------------------------------------+-------------------+
-| ts-sp-{se-proxy, smm-gateway}             | 602be60719        |
-+-------------------------------------------+-------------------+
-
-Yocto distribution components versions
-======================================
-
-+-------------------------------------------+----------------+
-| meta-arm                                  | walnascar      |
-+-------------------------------------------+----------------+
-| poky                                      | ee0d8d8a61     |
-+-------------------------------------------+----------------+
-| meta-openembedded                         | 2169c9afcc     |
-+-------------------------------------------+----------------+
-| meta-secure-core                          | 423bc85b05     |
-+-------------------------------------------+----------------+
-| busybox                                   | 1.37.0         |
-+-------------------------------------------+----------------+
-| musl                                      | 1.2.5          |
-+-------------------------------------------+----------------+
-| gcc-arm-none-eabi                         | 13.3.rel1      |
-+-------------------------------------------+----------------+
-| gcc-cross-aarch64                         | 14.2.0         |
-+-------------------------------------------+----------------+
-| openssl                                   | 3.4.1          |
-+-------------------------------------------+----------------+
-
-
-***************
-Version 2024.11
-***************
-
-Changes
-=======
-
- Implementation of a replication strategy for FWU metadata in TF-M according to the FWU specification.
- Upgrade to metadata version 2 in TF-M.
- Increase the ITS and PS memory size in Secure Flash for TF-M.
- SW components upgrades.
- Bug fixes.
-
-Corstone-1000 components versions
-=================================
-
-+-------------------------------------------+-----------------------------------------------------+
-| linux-yocto                               |                   6.10.14                           |
-+-------------------------------------------+-----------------------------------------------------+
-| u-boot                                    |                   2023.07.02                        |
-+-------------------------------------------+-----------------------------------------------------+
-| external-system                           |                   0.1.0                             |
-+-------------------------------------------+-----------------------------------------------------+
-| optee-client                              |                   4.2.0                             |
-+-------------------------------------------+-----------------------------------------------------+
-| optee-os                                  |                   4.2.0                             |
-+-------------------------------------------+-----------------------------------------------------+
-| trusted-firmware-a                        |                   2.11.0                            |
-+-------------------------------------------+-----------------------------------------------------+
-| trusted-firmware-m                        |                   2.1.0                             |
-+-------------------------------------------+-----------------------------------------------------+
-| libts                                     |                   602be60719                        |
-+-------------------------------------------+-----------------------------------------------------+
-| ts-newlib                                 |                   4.1.0                             |
-+-------------------------------------------+-----------------------------------------------------+
-| ts-psa-{crypto, iat, its. ps}-api-test    |                   74dc6646ff                        |
-+-------------------------------------------+-----------------------------------------------------+
-| ts-sp-{se-proxy, smm-gateway}             |                   602be60719                        |
-+-------------------------------------------+-----------------------------------------------------+
-
-Yocto distribution components versions
-======================================
-
-+-------------------------------------------+------------------------------+
-| meta-arm                                  | styhead                      |
-+-------------------------------------------+------------------------------+
-| poky                                      | 5465094be9                   |
-+-------------------------------------------+------------------------------+
-| meta-openembedded                         | 461d85a183                   |
-+-------------------------------------------+------------------------------+
-| meta-secure-core                          | 59d7e90542                   |
-+-------------------------------------------+------------------------------+
-| busybox                                   |                   1.36.1     |
-+-------------------------------------------+------------------------------+
-| musl                                      |                   1.2.5      |
-+-------------------------------------------+------------------------------+
-| gcc-arm-none-eabi                         |          13.3.rel1           |
-+-------------------------------------------+------------------------------+
-| gcc-cross-aarch64                         |                   14.2.0     |
-+-------------------------------------------+------------------------------+
-| openssl                                   |                   3.3.1      |
-+-------------------------------------------+------------------------------+

 ***************
 Version 2024.06
@@ -629,4 +370,4 @@ Changes

 --------------

-*Copyright (c) 2022-2026, Arm Limited. All rights reserved.*
+*Copyright (c) 2022-2024, Arm Limited. All rights reserved.*
@@ -1,8 +1,3 @@
-# SPDX-FileCopyrightText: <text>Copyright 2020-2024, 2026 Arm Limited and/or its
-# affiliates <open-source-office@arm.com></text>
-#
-# SPDX-License-Identifier: MIT
-
 # Configuration file for the Sphinx documentation builder.
 #
 # This file only contains a selection of the most common options. For a full
@@ -15,19 +10,15 @@
 # add these directories to sys.path here. If the directory is relative to the
 # documentation root, use os.path.abspath to make it absolute, like shown here.
 #
+# import os
+# import sys
 # sys.path.insert(0, os.path.abspath('.'))

-import os
-import sys
-
-# Append the documentation directory to the path, so we can import variables
-sys.path.append(os.path.dirname(__file__))
-

 # -- Project information -----------------------------------------------------

-project = 'Corstone-1000'
-copyright = '2020-2026, Arm Limited'
+project = 'corstone1000'
+copyright = '2020-2022, Arm Limited'
 author = 'Arm Limited'


@@ -37,7 +28,6 @@ author = 'Arm Limited'
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
 extensions = [
-    'sphinx_rtd_theme',
 ]

 # Add any paths that contain templates here, relative to this directory.
@@ -55,19 +45,6 @@ exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store', 'docs/infra']
 # a list of builtin themes.
 #
 html_theme = 'sphinx_rtd_theme'
-html_theme_options = {
-    'flyout_display': 'attached',
-}
-
-# Define the canonical URL if you are using a custom domain on Read the Docs
-html_baseurl = os.environ.get("READTHEDOCS_CANONICAL_URL", "")
-
-# Tell Jinja2 templates the build is running on Read the Docs
-if os.environ.get("READTHEDOCS", "") == "True":
-    if "html_context" not in globals():
-        html_context = {}
-    html_context["READTHEDOCS"] = True
-

 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
@@ -1,5 +1,5 @@
 ..
- # Copyright (c) 2022, 2024, 2026 Arm Limited.
+ # Copyright (c) 2022, 2024, Arm Limited.
 #
 # SPDX-License-Identifier: MIT

@@ -1,5 +1,5 @@
 ..
- # Copyright (c) 2022-2026, Arm Limited.
+ # Copyright (c) 2022-2024, Arm Limited.
 #
 # SPDX-License-Identifier: MIT

@@ -19,46 +19,6 @@ intended for safety-critical applications. Should Your Software or Your Hardware
 prove defective, you assume the entire cost of all necessary servicing, repair
 or correction.

-***********************
-Release notes - 2026.05
-***********************
-
-The same notes as the 2025.05 release still apply.
-
-***********************
-Release notes - 2025.12
-***********************
-
-The same notes as the 2025.05 release still apply.
-
-Known Issues or Limitations
---------------------------
-
- Corstone-1000 with Cortex-A320 FVP does not currently support Symmetric Multiprocessing
- Corstone-1000 with Cortex-A320 FVP becomes unresponsive when the Linux kernel driver for the Ethos-U85 NPU loads automatically after a software reboot.
-
-***********************
-Release notes - 2025.05
-***********************
-
-Known Issues or Limitations
---------------------------
-
- - Crypto isolation is not supported in the Secure world of Corstone-1000. Additionally, clients in
-   the Normal world are not isolated from one another.Therefore, if an end user wants to add a new
-   Secure Partition (SP) (such as a software TPM) that accesses the Crypto service via the SE-Proxy,
-   they are responsible for implementing their own isolation mechanisms to ensure proper security boundaries.
- - DSTREAM debug probe may experience unreliable USB connectivity when used with Arm DS for secure debug.
-   This issue is under active investigation, and we are working to identify and resolve compatibility issues in a future update.
-   As a more stable alternative, the ULINKpro debug probe is recommended for use with Corstone-1000 in secure debug scenarios.
-
-
-***********************
-Release notes - 2024.11
-***********************
-
-The same notes as the 2024.06 release still apply.
-
 ***********************
 Release notes - 2024.06
 ***********************
@@ -286,4 +246,4 @@ For all security issues, contact Arm by email at psirt@arm.com.

 --------------

-*Copyright (c) 2022-2026, Arm Limited. All rights reserved.*
+*Copyright (c) 2022-2023, Arm Limited. All rights reserved.*
--- a/Show More
+++ b/Show More