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
546 changed files with 26047 additions and 23756 deletions
@@ -1,2 +0,0 @@
-[b4]
-	send-series-to = meta-arm@lists.yoctoproject.org
@@ -1,4 +1,4 @@
-image: ${MIRROR_GHCR}/siemens/kas/kas:4.7
+image: ${MIRROR_GHCR}/siemens/kas/kas:4.3.2

 variables:
  # These are needed as the k8s executor doesn't respect the container
@@ -10,7 +10,7 @@ variables:
  # The default machine tag for the build jobs
  DEFAULT_TAG: ""
  # The machine tag for the ACS test jobs
-  ACS_TAG: "$DEFAULT_TAG"
+  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
@@ -33,24 +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
    TOOLCHAIN_DIR: $CACHE_DIR/toolchains
-    IMAGE_DIR: $KAS_BUILD_DIR/tmp/deploy/images
-    TOOLCHAIN_LINK_DIR: $KAS_BUILD_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 $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"
@@ -71,18 +75,13 @@ stages:
    - echo KASFILES=$KASFILES
    - kas dump --update --force-checkout --resolve-refs --resolve-env $KASFILES
    - kas build $KASFILES
-    - ./ci/check-warnings $KAS_BUILD_DIR/warnings.log
-    - kas shell ci/base.yml:lockfile.yml --command "$CI_PROJECT_DIR/ci/junit.sh $KAS_WORK_DIR/build"
-
+    - ./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.
@@ -95,18 +94,7 @@ 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
@@ -114,26 +102,23 @@ update-repos:
        # 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: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]
-#  TESTING: testimage
-#  SECUREDEBUG: [none, secure-debug]
 #  VIRT: [none, xen]
+#  TESTING: testimage

 arm-systemready-ir-acs:
  extends: .build
@@ -143,7 +128,7 @@ arm-systemready-ir-acs:
      # 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]
+      - PLATFORM: fvp-base
        ARM_SYSTEMREADY_IR_ACS: arm-systemready-ir-acs
  tags:
    - ${ACS_TAG}
@@ -175,7 +160,6 @@ corstone1000-mps3:
      - FIRMWARE: corstone1000-firmware-only
        TESTING: [none, tftf]
      - FIRMWARE: none
-        SECUREDEBUG: [none, secure-debug]

 documentation:
  extends: .setup
@@ -206,10 +190,22 @@ fvp-base:
    matrix:
      - TS: [none, fvp-base-ts]
        TESTING: testimage
-      - FIRMWARE: [u-boot, edk2]
-        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

@@ -251,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
@@ -266,17 +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]
+      - 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

@@ -284,18 +288,26 @@ qemuarm64:
  extends: .build
  parallel:
    matrix:
+      - 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
@@ -304,19 +316,23 @@ qemuarm:
  extends: .build
  parallel:
    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        FIRMWARE: edk2
+      - 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
@@ -325,9 +341,8 @@ 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
@@ -340,12 +355,6 @@ selftest:

 sgi575:
  extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-  # FVP binary is x86-only
-  tags:
-    - x86_64

 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.
@@ -16,4 +16,3 @@ target:
  - arm-systemready-ir-acs
  - arm-systemready-linux-distros-debian
  - arm-systemready-linux-distros-opensuse
-  - arm-systemready-linux-distros-fedora
@@ -7,31 +7,21 @@ distro: poky

 defaults:
  repos:
-    branch: whinlatter
+    branch: scarthgap

 repos:
-  bitbake:
-    url: https://git.openembedded.org/bitbake
-    branch: "2.16"
-    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: ""
  TOOLCHAIN_DIR: ""
@@ -39,10 +29,13 @@ env:
 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"
@@ -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"
@@ -15,3 +15,5 @@ local_conf_header:

    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"
@@ -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,6 +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"
+  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"
@@ -19,13 +19,8 @@ target:
  # Target packages to test aarch64
  - fvp-base-a-aem
  - fvp-corstone1000
-  - fvp-rd1-ae
-  - fvp-v3-r1
  # Nativesdk to test x86-64
  - nativesdk-fvp-base-a-aem
  - nativesdk-fvp-corstone1000
-  - nativesdk-fvp-rd1-ae
-  - nativesdk-fvp-v3-r1
-  # These are x86 only... :(
+  - nativesdk-fvp-n1-edge
  - nativesdk-fvp-sgi575
-  - nativesdk-fvp-tc3
@@ -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
@@ -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:
-  fvp-multicore: |
-    MACHINE_FEATURES += "corstone1000_fvp_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,8 +0,0 @@
-# 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"
@@ -7,4 +7,3 @@ local_conf_header:
  setup: |
    BB_LOGCONFIG = ""
    SANITY_TESTED_DISTROS = ""
-    INHERIT:remove = "rm_work"
@@ -4,11 +4,5 @@ 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:sgi575 = "sgi575"

 machine: sgi575
@@ -6,6 +6,6 @@ header:
 local_conf_header:
  sstate_mirror: |
    BB_HASHSERVE_UPSTREAM = "wss://hashserv.yoctoproject.org/ws"
-    SSTATE_MIRRORS = "file://.* http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
+    SSTATE_MIRRORS = "file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH"
    BB_HASHSERVE = "auto"
    BB_SIGNATURE_HANDLER = "OEEquivHash"
@@ -17,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,51 +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}"
-    QB_KERNEL_ROOT = ""
-    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"
@@ -23,6 +23,7 @@ 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__":
@@ -43,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
@@ -4,13 +4,10 @@ header:
  version: 14
  includes:
    - ci/meta-virtualization.yml
-    - ci/poky-altcfg.yml

 local_conf_header:
  meta-virt: |
    DISTRO_FEATURES:append = " virtualization xen"
-  sshd: |
-    IMAGE_FEATURES:append = " ssh-server-openssh"

 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.
@@ -59,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:
@@ -24,7 +24,6 @@ features for each [Secure Partition][^2] you would like to include:
 | se-proxy          | ts-se-proxy     |
 | smm-gateway       | ts-smm-gateway  |
 | spm-test[1-4]     | optee-spmc-test |
-| Logging           | ts-logging      |

 Other steps depend on your machine/platform definition:

@@ -38,11 +37,13 @@ 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.
@@ -58,18 +59,6 @@ Optionally for testing purposes you can add `packagegroup-ts-tests` into your im
  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 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 |
-

 ------
 [^1]: https://trusted-services.readthedocs.io/en/integration/overview/index.html
@@ -2,7 +2,6 @@ header:
  version: 13
  includes:
    - kas/arm-systemready-firmware.yml
-    - kas/arm-systemready-linux-distros-unattended-installation.yml

 target:
  - arm-systemready-linux-distros-debian
@@ -1,8 +0,0 @@
-header:
-  version: 16
-  includes:
-    - kas/arm-systemready-firmware.yml
-    - kas/arm-systemready-linux-distros-unattended-installation.yml
-
-target:
-  - arm-systemready-linux-distros-fedora
@@ -1,19 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-
-local_conf_header:
-  a320: |
-    MACHINE_FEATURES += "cortexa320"
-    OVERRIDES .= ":cortexa320"
-
-repos:
-  meta-ethos:
-    url: https://gitlab.arm.com/iot/meta-ethos.git
-    branch: whinlatter
-    commit: b919565c36b89af2ba61cc28024da633a9fae0da
-  meta-sca:
-    url: https://github.com/priv-kweihmann/meta-sca.git
-    branch: master
-    commit: e68f1a9d17553a2a1b5b20962749f90482112a3f
@@ -5,36 +5,25 @@ distro: poky

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

 repos:
-  bitbake:
-    url: https://git.openembedded.org/bitbake
-    commit: 0dde1a3ff852be057be40d17f233ecca19e7b389
-    layers:
-      bitbake: disabled
-
-  core:
-    url: https://git.openembedded.org/openembedded-core
-    commit: 4bd920ad7d7279020ea6e561d0584ae70f33f751
-    layers:
-      meta:
-
-  meta-yocto:
-    url: https://git.yoctoproject.org/meta-yocto
-    commit: b3b659263566c4d2f2813190e72d93f8598a4c47
-    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: fc0152e434307b98e1d16251f92ed81ac617c1db
+    commit: 6de0ab744341ad61b0661aa28d78dc6767ce0786
    layers:
      meta-oe:
      meta-python:
@@ -42,7 +31,7 @@ repos:

  meta-secure-core:
    url: https://github.com/wind-river/meta-secure-core.git
-    commit: 63209fb1500cee88d5d4d74669bce4b613c03ff7
+    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}"
@@ -14,7 +14,7 @@ machine: fvp-base

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

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

-LAYERSERIES_COMPAT_meta-arm-bsp = "walnascar whinlatter"
+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
 LAYERDEPENDS_meta-arm-bsp:append:corstone1000 = " meta-python openembedded-layer efi-secure-boot"
-LAYERDEPENDS_meta-arm-bsp:append:corstone1000:cortexa320 = " meta-ethos"
 LAYERDEPENDS_meta-arm-bsp:append:musca-b1 = " meta-python"
 LAYERDEPENDS_meta-arm-bsp:append:musca-s1 = " meta-python"

@@ -29,5 +28,3 @@ BBFILES_DYNAMIC += " \
 WARN_QA:append:layer-meta-arm-bsp = " patch-status"

 addpylib ${LAYERDIR}/lib oeqa
-
-IMAGE_ROOTFS_EXTRA_ARGS ?= ""
@@ -3,30 +3,21 @@
 #@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)}
-
-require ${@bb.utils.contains('MACHINE_FEATURES', 'cortexa320', \
-    'conf/machine/include/corstone1000-a320.inc', '', d)}
-
 TFA_TARGET_PLATFORM = "fvp"

 TFM_PLATFORM_IS_FVP = "TRUE"

-CORSTONE_1000_TYPE = "CORSTONE_1000_TYPE_CORTEX_A35_FVP"
-
 # 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"
 FVP_EXE ?= "FVP_Corstone-1000"
-FVP_EXE:cortexa320 = "FVP_Corstone-1000-A320"
 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"
@@ -49,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"
@@ -6,7 +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"
+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.
@@ -61,15 +54,12 @@ FVP_CONFIG[cluster1.stage12_tlb_size] ?= "1024"
 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"
-
-# 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)}"
-
+# 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,5 +0,0 @@
-ETHOSU_NUM_MACS ?= "256"
-
-FVP_CONFIG[host.ethosu.num_macs] = "${ETHOSU_NUM_MACS}"
-
-IMAGE_INSTALL:append = " arm-npu-ethosu"
@@ -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,23 +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.1"
+PREFERRED_VERSION_trusted-firmware-m ?= "2.0.%"

 # TF-A
 TFA_PLATFORM = "corstone1000"
-PREFERRED_VERSION_trusted-firmware-a ?= "2.13.%"
-PREFERRED_VERSION_tf-a-tests ?= "2.13.%"
+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.7.%"
-PREFERRED_VERSION_optee-client ?= "4.7.%"
+PREFERRED_VERSION_optee-os ?= "4.1.%"

 # Trusted Services
 TS_PLATFORM = "arm/corstone1000"
@@ -25,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.04%"
+# u-boot
+PREFERRED_VERSION_u-boot ?= "2023.07%"
 MACHINE_FEATURES += "efi"
 EFI_PROVIDER ?= "grub-efi"

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

 # Linux kernel
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "6.12.%"
+PREFERRED_VERSION_linux-yocto ?= "6.6.%"
 KERNEL_IMAGETYPE = "Image"
 KERNEL_IMAGETYPE:firmware = "Image.gz"
 # add FF-A support in the kernel
@@ -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"
@@ -26,21 +26,17 @@ EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boo
 SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"

 EXTRA_IMAGEDEPENDS += "edk2-firmware"
-# FIXME - Currently seeing a kernel warning for the CPU topology when bumping
-# the version past this.  The issue is being tracked in
-# https://github.com/tianocore/edk2-platforms/issues/752
-PREFERRED_VERSION_edk2-firmware ?= "202408%"

 QB_SYSTEM_NAME = "qemu-system-aarch64"
 QB_MACHINE = "-machine sbsa-ref"
 QB_CPU = "-cpu neoverse-n2"
 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,file=@DEPLOY_DIR_IMAGE@/SBSA_FLASH0.fd -drive if=pflash,format=raw,unit=1,readonly,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
@@ -7,59 +7,18 @@
 require conf/machine/include/arm/armv8-2a/tune-cortexa75.inc

 EXTRA_IMAGEDEPENDS += "virtual/control-processor-firmware"
-EXTRA_IMAGEDEPENDS += "trusted-firmware-a"

-# 2.13.0 removes support for sgi575
-PREFERRED_VERSION_trusted-firmware-a ?= "2.12.%"
+EXTRA_IMAGEDEPENDS += "trusted-firmware-a"

 KERNEL_IMAGETYPE ?= "Image"
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 SERIAL_CONSOLES = "115200;ttyAMA0"

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

 IMAGE_FSTYPES += "cpio.gz wic"
-IMAGE_NAME_SUFFIX = ""
-IMAGE_CLASSES += "fvpboot"

-WKS_FILE ?= "efi-disk.wks.in"
+WKS_FILE ?= "sgi575-efidisk.wks"
 WKS_FILE_DEPENDS:append = " ${EXTRA_IMAGEDEPENDS}"
-
-# testimage config
-TEST_TARGET = "OEFVPTarget"
-#TEST_TARGET_IP = "127.0.0.1:222"
-TEST_SUITES = "fvp_boot"
-
-# FVP Config
-FVP_PROVIDER ?= "fvp-sgi575-native"
-FVP_EXE ?= "FVP_CSS_SGI-575"
-
-# Virtio-Net 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_NAME}.wic"
-
-#FVP_CONFIG[cache_state_modelled] ?= "0"
-FVP_CONFIG[css.cmn600.mesh_config_file] = "SGI-575_cmn600.yml"
-FVP_CONFIG[css.cmn600.force_rnsam_internal] ?= "false"
-FVP_CONFIG[css.gic_distributor.ITS-device-bits] ?= "20"
-
-FVP_DATA ?= "css.scp.armcortexm7ct=scp_ramfw.bin@0x0BD80000"
-FVP_CONFIG[css.mcp.ROMloader.fname] ?= "mcp_romfw.bin"
-FVP_CONFIG[css.scp.ROMloader.fname] ?= "scp_romfw.bin"
-FVP_CONFIG[css.trustedBootROMloader.fname] ?= "bl1-sgi575.bin"
-FVP_CONFIG[board.flashloader0.fname] ?= "fip-sgi575.bin"
-
-FVP_CONSOLES[default] = "terminal_uart_ap"
-FVP_TERMINALS[css.scp.terminal_uart_aon] ?= "SCP Console"
-FVP_TERMINALS[css.mcp.terminal_uart0] ?= ""
-FVP_TERMINALS[css.mcp.terminal_uart1] ?= ""
-FVP_TERMINALS[css.terminal_uart_ap] ?= "Console"
-FVP_TERMINALS[css.terminal_uart1_ap] ?= ""
-FVP_TERMINALS[soc.terminal_s0] ?= ""
-FVP_TERMINALS[soc.terminal_s1] ?= ""
-FVP_TERMINALS[soc.terminal_mcp] ?= ""
-FVP_TERMINALS[board.terminal_0] ?= ""
-FVP_TERMINALS[board.terminal_1] ?= ""
@@ -1,5 +1,5 @@
 ..
- # Copyright (c) 2022-2026, Arm Limited.
+ # Copyright (c) 2022-2024, Arm Limited.
 #
 # SPDX-License-Identifier: MIT

@@ -10,204 +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 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     |
-+-------------------------------------------+----------------+
-| 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          |
-+-------------------------------------------+----------------+
-
-***************
-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
@@ -568,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,40 +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 - 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
 ***********************
@@ -280,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.*
@@ -1,10 +1,10 @@
 ..
- # Copyright (c) 2022-2026, Arm Limited.
+ # Copyright (c) 2022-2024, Arm Limited.
 #
 # SPDX-License-Identifier: MIT

 ######################
-Software Architecture
+Software architecture
 ######################


@@ -16,279 +16,137 @@ Arm Corstone-1000 is a reference solution for IoT devices. It is part of
 Total Solution for IoT which consists of hardware and software reference
 implementation.

-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_>`__.
+Corstone-1000 software plus hardware reference solution is PSA Level-2 ready
+certified (`PSA L2 Ready`_) as well as System Ready IR certified(`SRIR cert`_).
+More information on the Corstone-1000 subsystem product and design can be
+found at:
+`Arm corstone1000 Software`_ and `Arm corstone1000 Technical Overview`_.

-More information on the Corstone-1000 subsystems product and design can be
-found on `Arm Developer <arm-developer-cs1000-website_>`__.
-
-This document explicitly focuses on the software part of the solution and
+This readme 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.
+present in the user-guide document.

 ***************
 Design Overview
 ***************

 The software architecture of Corstone-1000 platform is a reference
-implementation of `Platform Security Architecture <psa-certified-website_>`__ which provides
+implementation of Platform Security Architecture (`PSA`_) which provides
 framework to build secure IoT devices.

-The base system architecture of the platform is created from three different types of subsystems:
-
-    - Secure Enclave
-    - Host System
-    - External System
-
-Each subsystem provides different functionality to the overall system on a chip (SoC).
+The base system architecture of the platform is created from three
+different types of systems: Secure Enclave, Host and External System.
+Each subsystem provides different functionality to overall SoC.


 .. image:: images/CorstoneSubsystems.png
   :width: 720
   :alt: CorstoneSubsystems

-Secure Enclave
-==============

-The Secure Enclave boots first on system power on, it provides `PSA Root of Trust (RoT) <psa-certified-website_>`__ and
-cryptographic functions. It is based on a Cortex-M0+ processor, CC312 Cryptographic Accelerator and
-peripherals such as watchdog and secure flash.
+The Secure Enclave System, provides PSA Root of Trust (RoT) and
+cryptographic functions. It is based on an Cortex-M0+ processor,
+CC312 Cryptographic Accelerator and peripherals, such as watchdog and
+secure flash. Software running on the Secure Enclave is isolated via
+hardware for enhanced security. Communication with the Secure Encalve
+is achieved using Message Handling Units (MHUs) and shared memory.
+On system power on, the Secure Enclave boots first. Its software
+comprises of a  ROM code (TF-M BL1), MCUboot BL2, and
+TrustedFirmware-M(`TF-M`_) as runtime software. The software design on
+Secure Enclave follows Firmware Framework for M class
+processor (`FF-M`_) specification.

-.. image:: images/Corstone1000SecureFlashMPS3.png
-   :width: 400
-   :alt: Corstone1000SecureFlashMPS3
+The Host System is based on ARM Cotex-A35 processor with standardized
+peripherals to allow for the booting of a Linux OS. The Cortex-A35 has
+the TrustZone technology that allows secure and non-secure security
+states in the processor. The software design in the Host System follows
+Firmware Framework for A class processor (`FF-A`_) specification.
+The boot process follows Trusted Boot Base Requirement (`TBBR`_).
+The Host Subsystem is taken out of reset by the Secure Enclave system
+during its final stages of the initialization. The Host subsystem runs
+FF-A Secure Partitions(based on `Trusted Services`_) and OPTEE-OS
+(`OPTEE-OS`_) in the secure world, and U-Boot(`U-Boot repo`_) and
+linux (`linux repo`_) in the non-secure world. The communication between
+non-secure and the secure world is performed via FF-A messages.

-.. image:: images/Corstone1000SecureFlashFVP.png
-   :width: 400
-   :alt: Corstone1000SecureFlashFVP
+An external system is intended to implement use-case specific functionality.
+The system is based on Cortex-M3 and run RTX RTOS. Communication between the
+external system and Host (Cortex-A35) can be performed using MHU as transport
+mechanism. The current software release supports switching on and off the
+external system. Support for OpenAMP-based communication is under
+development.

-Software running on the Secure Enclave is isolated via hardware for enhanced security.
-Communication with the Secure Enclave is achieved using `Message Handling Units (MHUs) <arm-developer-mhu-website_>`__
-and shared memory.
-
-Its software components comprises:
-
-    - `Trusted Firmware-M (TF-M) BL1 <trusted-firmware-m-bl1-website_>`__
-    - `MCUboot <mcuboot-website_>`__
-    - `TrustedFirmware-M <trusted-firmware-m-website_>`__ 
-
-The software design on the Secure Enclave follows `Arm Firmware Framework for M-Profile
-processor <arm-fmw-framework-m-profile-pdf_>`__ (FF-M) specification.
-
-Host System
-===========
-
-The Host System is based on ARM Cortex-A35 processor with standardized
-peripherals to allow booting a Linux-based operating system (OS). The Cortex-A35 has
-the `TrustZone <arm-trustzone-for-cortex-a-website_>`__ technology that allows Secure and Non-secure security
-states in the processor. 
-
-The boot process follows `Trusted Boot Base Requirements Client <trusted-board-boot-requirements-client-pdf_>`__.
-The Host System is taken out of reset by the Secure Enclave system during its final stages of the
-initialization.
-
-In the Secure world, the Host System runs:
-
-    - FF-A Secure Partitions (based on `Trusted Services <trusted-services-website_>`__)
-    - `OP-TEE OS <op-tee-os-repository_>`__
-
-In the Non-secure World, the Host System runs:
-
-    - `U-Boot <das-u-boot-repository_>`__
-    - `Linux kernel <linux-repository_>`__
-
-The software design in the Host System follows `Arm Firmware Framework for Arm A-profile 
-<arm-fmw-framework-a-profile-pdf_>`__ (FF-A) specification.
-The communication between Non-secure and the Secure world is performed via FF-A messages.
-
-External System
-===============
-
-The External System is intended to implement use-case specific functionality.
-
-The system is based on Cortex-M3 and runs `Keil RTX5 <keil-rtx5-website_>`__. 
-
-Communication between the external system and Host (Cortex-A35) can be performed using MHU as transport
-mechanism. The current software release supports switching the External System ON and OFF.
-
-The Corstone-1000 architecture is designed to cover a range of
-`Power, Performance, and Area (PPA) <ppa-website_>`__ applications, and enable extension
-for use-case specific applications, for example, sensors, cloud connectivity, and edge computing.
-
-**************************************
-Corstone-1000 with Cortex-A320 Variant
-**************************************
-
-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.
-
-.. image:: images/CorstoneA320Subsystems.png
-   :width: 720
-   :alt: CorstoneA320Subsystems
+Overall, the Corstone-1000 architecture is designed to cover a range
+of Power, Performance, and Area (PPA) applications, and enable extension
+for use-case specific applications, for example, sensors, cloud
+connectivitiy, and edge computing.

 *****************
 Secure Boot Chain
 *****************

 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
+software should run on the device. The Corstone-1000 boot uses a
+Secure Boot 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.
+nature and encoded into the device by the device owner before it
+is deployed into the field. In Corstone-1000, the content of the ROM
+and CC312 OTP (One Time Programmable) 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.
+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.

 .. image:: images/SecureBootChain.png
   :width: 870
   :alt: SecureBootChain

-It is a lengthy chain to boot the software on Corstone-1000.
+It is a lengthy chain to boot the software on Corstone-1000. On power on,
+the Secure Enclave starts executing BL1_1 code from the ROM which is the RoT
+of the device. The BL1_1 is the immutable bootloader of the system, it handles
+the provisioning on the first boot, hardware initialization and verification
+of the next stage.

-TF-M BL1_1
-==========
+The BL1_2 code, hashes and keys are written into the OTP during the provisioning.
+The next bootstage is the BL1_2 which is copied from the OTP into the RAM. The
+BL1_1 also compares the BL1_2 hash with the hash saved to the OTP. The BL1_2
+verifies and transfers control to the next bootstage which is the BL2. During the
+verification, the BL1_2 compares the BL2 image's computed hash with the BL2 hash in
+the OTP. The BL2 is MCUBoot in the system. BL2 can provision additional keys on the
+first boot and it authenticates the initial bootloader of the host (Host TF-A BL2)
+and TF-M by checking the signatures of the images.
+The MCUBoot handles the image verification the following way:

-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
-==========
-
-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.
-
-.. note::
-
-    The TF-M BL1 design details can be found in the `TF-M design documents <trusted-firmware-m-bl1-website_>`_.
-
-    .. important::
-
-        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
-========
-
-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:
-
-#. Load the image from non-volatile memory into RAM.
-#. 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.
+- Load image from a non-volatile memory to dynamic RAM.
+- 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 image is validated using the public key.


-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.
+The execution control is passed to TF-M after the verification. TF-M being
+the runtime executable of the Secure Enclave which initializes itself and, at the end,
+brings the host CPU out of rest.

+The TF-M BL1 design details and reasoning can be found in the `TF-M design documents
+<https://tf-m-user-guide.trustedfirmware.org/design_docs/booting/bl1.html>`_.

+The Corstone-1000 has some differences compared to this design due to memory (OTP/ROM)
+limitations:

-Host System Authentication
-==========================
+- The provisioning bundle that contains the BL1_2 code is located in the ROM.
+  This means the BL1_2 cannot be updated during provisioning time.
+- The BL1_1 handles most of the hardware initialization instead of the BL1_2. This
+  results in a bigger BL1_1 code size than needed.
+- The BL1_2 does not use the post-quantum LMS verification. The BL2 is verified by
+  comparing the computed hash to the hash which is stored in the OTP. This means the
+  BL2 is not updatable.

-The Host system follows the boot standard defined in the `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.
-
-.. image:: images/FIPDiagram.png
-   :alt: FIPDiagram
-
-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.
-
-
-.. important::
-
-    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
-------------------------
-
-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
-------------------------
-
-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
----------------------------
+The host follows the boot standard defined in the `TBBR`_ to authenticate the
+secure and non-secure software.

 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
@@ -298,140 +156,79 @@ specification before executing them.
 Secure Services
 ***************

-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.
+Corstone-1000 is unique in providing a secure environment to run a secure
+workload. The platform has TrustZone technology in the Host subsystem but
+it also has hardware isolated Secure Enclave environment to run such secure
+workloads. In Corstone-1000, known Secure Services such as Crypto, Protected
+Storage, Internal Trusted Storage and Attestation are available via PSA
+Functional APIs in TF-M. There is no difference for a user communicating to
+these services which are running on a Secure Enclave instead of the
+secure world of the host subsystem. The below diagram presents the data
+flow path for such calls.


 .. image:: images/SecureServices.png
   :width: 930
   :alt: SecureServices

-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.
+The SE Proxy SP (Secure Enclave Proxy Secure Partition) is a proxy partition
+managed by OPTEE which forwards such calls to the Secure Enclave. The
+solution relies on the `RSE communication protocol
+<https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html>`_
+which is a lightweight serialization of the psa_call() API. It can use shared
+memory and MHU interrupts as a doorbell for communication between two cores
+but currently the whole message is forwarded through the MHU channels in Corstone-1000.
+Corstone-1000 implements isolation level 2. Cortex-M0+ MPU (Memory Protection
+Unit) is used to implement isolation level 2.
+
+For a user to define its own secure service, both the options of the host
+secure world or secure encalve are available. It's a trade-off between
+lower latency vs higher security. Services running on a Secure Enclave are
+secure by real hardware isolation but have a higher latency path. In the
+second scenario, the services running on the secure world of the host
+subsystem have lower latency but virtual hardware isolation created by
+TrustZone technology.


-**************************
-PSA Secure Firmware Update
-**************************
+**********************
+Secure Firmware Update
+**********************

-The Arm 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 both the Fixed Virtual Platform (FVP) and the Field Programmable Gate Array (FPGA)
-targets, providing consistent behavior across simulation and silicon-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.
+Apart from always booting the authorized images, it is also essential that
+the device only accepts the authorized (signed) images in the firmware update
+process. Corstone-1000 supports OTA (Over the Air) firmware updates and
+follows Platform Security Firmware Update specification (`FWU`_).

-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.
-
-
-.. image:: images/SystemArchitecturePSAFirmwareUpdate.png
-   :width: 690
-   :alt: SystemArchitecturePSAFirmwareUpdate
-
-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.
+As standardized into `FWU`_, the external flash is divided into two
+banks of which one bank has currently running images and the other bank is
+used for staging new images.  There are four updatable units, i.e. Secure
+Enclave's BL2 and TF-M, and Host's FIP (Firmware Image Package) and Kernel
+Image (the initramfs bundle). The new images are accepted in the form of a UEFI capsule.


 .. image:: images/ExternalFlash.png
   :width: 690
   :alt: ExternalFlash

-When a FWU is initiated on Corstone-1000, the following sequence of operations takes place:
-
-#. **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.
-
-#. **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.
-
-#. **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.
-
-#. **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.
-
-#. **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.
-
-#. **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.
+When Firmware update is triggered, U-Boot verifies the capsule by checking the
+capsule signature, version number and size. Then it signals the Secure Enclave
+that can start writing UEFI capsule into the flash. Once this operation finishes
+,Secure Enclave resets the entire system.
+The Metadata Block in the flash has the below firmware update state machine.
+TF-M runs an OTA service that is responsible for accepting and updating the
+images in the flash. The communication between the UEFI Capsule update
+subsystem and the OTA service follows the same data path explained above.
+The OTA service writes the new images to the passive bank after successful
+capsule verification. It changes the state of the system to trial state and
+triggers the reset. Boot loaders in Secure Enclave and Host read the Metadata
+block to get the information on the boot bank. In the successful trial stage,
+the acknowledgment from the host moves the state of the system from trial to
+regular. Any failure in the trial stage or system hangs leads to a system
+reset. This is made sure by the use of watchdog hardware. The Secure Enclave's
+BL1 has the logic to identify multiple resets and eventually switch back to the
+previous good bank. The ability to revert to the previous bank is crucial to
+guarantee the availability of the device.


 .. image:: images/SecureFirmwareUpdate.png
@@ -444,15 +241,13 @@ When a FWU is initiated on Corstone-1000, the following sequence of operations t
 UEFI Runtime Support in U-Boot
 ******************************

-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.
+Implementation of UEFI boottime and runtime APIs require variable storage.
+In Corstone-1000, these UEFI variables are stored in the Protected Storage
+service. The below diagram presents the data flow to store UEFI variables.
+The U-Boot implementation of the UEFI subsystem uses the U-Boot FF-A driver to
+communicate with the SMM Service in the secure world. The backend of the
+SMM service uses the proxy PS from the SE Proxy SP. From there on, the PS
+calls are forwarded to the Secure Enclave as explained above.


 .. image:: images/UEFISupport.png
@@ -460,43 +255,30 @@ These PS calls are forwarded to the Secure Enclave, following the communication
   :alt: UEFISupport


-**********
+***************
 References
-**********
-* `Arm Developer <arm-developer-cs1000-search_>`__
-* `Arm Security Architectures <arm-architecture-security-features-platform-security_>`_
+***************
+`ARM corstone1000 Search`_
+
+`Arm security features`_

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

-*Copyright (c) 2022-2026, Arm Limited. All rights reserved.*
+*Copyright (c) 2022-2023, Arm Limited. All rights reserved.*

-.. _arm-developer-cs1000-website: https://developer.arm.com/Tools%20and%20Software/Corstone-1000%20Software
-.. _arm-developer-cs1000-search: https://developer.arm.com/search#q=corstone-1000
-.. _arm-developer-mhu-website: https://developer.arm.com/documentation/ka005129/latest/#:~:text=An%20MHU%20is%20a%20device,that%20a%20message%20is%20available
-.. _arm-developer-secureboot-website: https://developer.arm.com/documentation/PRD29-GENC-009492/c/TrustZone-Software-Architecture/Booting-a-secure-system/Secure-boot
-.. _arm-architecture-security-features-platform-security: https://www.arm.com/architecture/security-features/platform-security
-.. _linux-repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
-.. _arm-trustzone-for-cortex-a-website: https://www.arm.com/technologies/trustzone-for-cortex-a
-.. _arm-fmw-framework-a-profile-pdf: https://developer.arm.com/documentation/den0077/latest
-.. _arm-fmw-framework-m-profile-pdf: https://developer.arm.com/architectures/Firmware%20Framework%20for%20M-Profile
-.. _platform-security-fwu-for-a-profile-pdf: https://developer.arm.com/documentation/den0118/a/
-.. _psa-firmware-update-ihi-0093-api-reference-website: https://arm-software.github.io/psa-api/fwu/1.0/api/api.html
-.. _edk2-capsule-generation-tool-repository: https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/Capsule/GenerateCapsule.py
-.. _psa-fwu-den0018-specification-website: https://developer.arm.com/documentation/den0118/latest/
-.. _ts-psa-fwu-service-website: https://trusted-services.readthedocs.io/en/stable/services/fwu/psa-fwu-m.html
-.. _tfm-shim-layer-website: https://trustedfirmware-m.readthedocs.io/en/latest/design_docs/services/tfm_fwu_service.html#shim-layer-between-fwu-and-bootloader
-.. _op-tee-os-repository: https://github.com/OP-TEE/optee_os
-.. _psa-certified-website: https://www.psacertified.org/
-.. _psa_l2-ready: https://www.psacertified.org/products/corstone-1000/
-.. _systemready-ir-certification: https://armkeil.blob.core.windows.net/developer/Files/pdf/certificate-list/arm-systemready-ve-arm-neoverse.pdf
-.. _trusted-board-boot-requirements-client-pdf: https://developer.arm.com/documentation/den0006/latest
-.. _trusted-firmware-m-website: https://www.trustedfirmware.org/projects/tf-m/
-.. _trusted-firmware-m-bl1-website: https://trustedfirmware-m.readthedocs.io/en/latest/design_docs/booting/bl1.html
-.. _trusted-firmware-a-bl2-website: https://developer.arm.com/documentation/108028/0000/RD-TC22-software/Software-components/AP-firmware/Trusted-firmware-A-BL2
-.. _trusted-firmware-a-fip-guide: https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html#firmware-image-package-fip
-.. _trusted-services-website: https://www.trustedfirmware.org/projects/trusted-services/
-.. _trusted-services-uefi-smm-website: https://trusted-services.readthedocs.io/en/integration/services/uefi-smm-services.html#
-.. _das-u-boot-repository: https://github.com/u-boot/u-boot.git
-.. _keil-rtx5-website: https://developer.arm.com/Tools%20and%20Software/Keil%20MDK/RTX5%20RTOS
-.. _ppa-website: https://developer.arm.com/documentation/102738/0100/Power--performance--and-area-analysis
-.. _mcuboot-website: https://docs.mcuboot.com/
+.. _Arm corstone1000 Technical Overview: https://developer.arm.com/documentation/102360/0000
+.. _Arm corstone1000 Software: https://developer.arm.com/Tools%20and%20Software/Corstone-1000%20Software
+.. _Arm corstone1000 Search: https://developer.arm.com/search#q=corstone-1000
+.. _Arm security features: https://www.arm.com/architecture/security-features/platform-security
+.. _linux repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
+.. _FF-A: https://developer.arm.com/documentation/den0077/latest
+.. _FF-M: https://developer.arm.com/architectures/Firmware%20Framework%20for%20M-Profile
+.. _FWU: https://developer.arm.com/documentation/den0118/a/
+.. _OPTEE-OS: https://github.com/OP-TEE/optee_os
+.. _PSA: https://www.psacertified.org/
+.. _PSA L2 Ready: https://www.psacertified.org/products/corstone-1000/
+.. _SRIR cert: https://armkeil.blob.core.windows.net/developer/Files/pdf/certificate-list/arm-systemready-ir-certification-arm-corstone-1000.pdf
+.. _TBBR: https://developer.arm.com/documentation/den0006/latest
+.. _TF-M: https://www.trustedfirmware.org/projects/tf-m/
+.. _Trusted Services: https://www.trustedfirmware.org/projects/trusted-services/
+.. _U-Boot repo: https://github.com/u-boot/u-boot.git
@@ -0,0 +1,78 @@
+# N1SDP Development Platform Support in meta-arm-bsp
+
+## Overview
+The N1SDP provides access to the Arm Neoverse N1 SoC. The N1SDP enables software development for key enterprise technology
+and general Arm software development. The N1SDP consists of the N1 board containing the N1 SoC.
+The N1 SoC contains two dual-core Arm Neoverse N1 processor clusters.
+
+The system demonstrates Arm technology in the context of Cache-Coherent Interconnect for Accelerators (CCIX) protocol by:
+
+- Running coherent traffic between the N1 SoC and an accelerator card.
+- Coherent communication between two N1 SoCs.
+- Enabling development of CCIX-enabled FPGA accelerators.
+
+Further information on N1SDP can be found at
+https://community.arm.com/developer/tools-software/oss-platforms/w/docs/458/neoverse-n1-sdp
+
+## Configuration:
+In the local.conf file, MACHINE should be set as follow:
+MACHINE ?= "n1sdp"
+
+## Building
+```bash$ bitbake core-image-minimal```
+
+## Running
+
+# Update Firmware on SD card:
+
+(*) To use n1sdp board in single chip mode, flash:
+    n1sdp-board-firmware_primary.tar.gz firmware.
+
+(*) To use n1sdp board in multi chip mode, flash:
+    n1sdp-board-firmware_primary.tar.gz firmware to primary board,
+    n1sdp-board-firmware_secondary.tar.gz firmware to secondary board.
+
+The SD card content is generated during the build here:
+  tmp/deploy/images/n1sdp/n1sdp-board-firmware_primary.tar.gz
+  tmp/deploy/images/n1sdp/n1sdp-board-firmware_secondary.tar.gz
+
+
+Its content must be written on the N1SDP firmware SD card.
+To do this:
+- insert the sdcard of the N1SDP in an SD card reader and mount it:
+```bash$ sudo mount /dev/sdx1 /mnt```
+(replace sdx by the device of the SD card)
+
+- erase its content and put the new one:
+```bash$ sudo rm -rf /mnt/*```
+```bash$ sudo tar --no-same-owner -xzf tmp/deploy/images/n1sdp/n1sdp-board-firmware_primary.tar.gz -C /mnt/```
+```bash$ sudo umount /mnt```
+
+- reinsert the SD card in the N1SDP board
+
+Firmware tarball contains iofpga configuration files, scp and uefi binaries.
+
+**NOTE**:
+If the N1SDP board was manufactured after November 2019 (Serial Number greater
+than 36253xxx), a different PMIC firmware image must be used to prevent
+potential damage to the board. More details can be found in [1].
+The `MB/HBI0316A/io_v123f.txt` file located in the microSD needs to be updated.
+To update it, set the PMIC image (300k_8c2.bin) to be used in the newer models
+by running the following commands on your host PC:
+
+    $ sudo umount /dev/sdx1
+    $ sudo mount /dev/sdx1 /mnt
+    $ sudo sed -i '/^MBPMIC: pms_0V85.bin/s/^/;/g' /mnt/MB/HBI0316A/io_v123f.txt
+    $ sudo sed -i '/^;MBPMIC: 300k_8c2.bin/s/^;//g' /mnt/MB/HBI0316A/io_v123f.txt
+    $ sudo umount /mnt
+
+# Prepare an USB hard drive:
+
+Grub boot partition is placed on first partition of the *.wic image,
+Linux root file system is placed on the second partition of the *.wic image:
+  tmp/deploy/images/n1sdp/core-image-minimal-n1sdp.wic
+
+This *.wic image should be copied to USB stick with simple dd call.
+
+
+[1]: https://community.arm.com/developer/tools-software/oss-platforms/w/docs/604/notice-potential-damage-to-n1sdp-boards-if-using-latest-firmware-release
@@ -1,4 +1,4 @@
-# Copyright (c) 2022-2024, Arm Limited.
+# Copyright (c) 2022, Arm Limited.
 #
 # SPDX-License-Identifier: MIT

@@ -6,6 +6,6 @@
 jinja2==3.1.1

 # Required to build the documentation
-sphinx==7.1.2
-sphinx_rtd_theme~=3.0.0
-docutils~=0.18.1
+sphinx~=5.0
+sphinx_rtd_theme~=2.0.0
+docutils==0.17.1
@@ -16,4 +16,4 @@

 *A summary of how to deploy or execute the image*

-*For example, an overview of FVP arguments*
+*For example, an overview of the N1SDP SD structure, or FVP arguments*
@@ -1,2 +1,2 @@
-FILESEXTRAPATHS:prepend := "${THISDIR}/files/${MACHINE}:"
+FILESEXTRAPATHS:append := "${THISDIR}/files/${MACHINE}:"
 SRC_URI:append = " file://report.txt"
@@ -1,8 +0,0 @@
-psci: failed to boot CPU1 (-95)
-CPU1: failed to boot: -95
-psci: failed to boot CPU2 (-95)
-CPU2: failed to boot: -95
-psci: failed to boot CPU3 (-95)
-CPU3: failed to boot: -95
-ARM FF-A: Notification setup failed -95, not enabled
-ARM FF-A: Failed to register driver sched callback -95
@@ -1 +0,0 @@
-basic-mmio-gpio: Failed to locate of_node [id: -2]
@@ -3,6 +3,3 @@ NUMA: Failed to initialise from firmware

 # TODO: we should be using bochsdrm over efifb?
 efifb: cannot reserve video memory at 0x80000000
-
-# TODO: debug why this sometimes happens
-failed to find screen to remove
@@ -3,7 +3,7 @@ DESCRIPTION = "Firmware to be loaded and run in External System Harness in\
               support to the main application CPU."
 HOMEPAGE = "https://git.linaro.org/landing-teams/working/arm/external-system.git"
 DEPENDS = "gcc-arm-none-eabi-native"
-INHIBIT_DEFAULT_DEPS = "1"
+INHIBIT_DEFAULT_DEPS="1"
 LICENSE = "BSD-3-Clause & Apache-2.0"
 LIC_FILES_CHKSUM = "file://license.md;md5=e44b2531cd6ffe9dece394dbe988d9a0 \
                    file://cmsis/LICENSE.txt;md5=e3fc50a88d0a364313df4b21ef20c29e"
@@ -19,6 +19,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 # PRODUCT is passed to the Makefile to specify the platform to be used.
 PRODUCT = "corstone-1000"

+S = "${WORKDIR}/git"
 B = "${WORKDIR}/build"

 # remove once arm-none-eabi-gcc updates to 13 or newer like poky
@@ -1,5 +1,6 @@
 # Machine specific configurations

 MACHINE_HAFNIUM_REQUIRE ?= ""
+MACHINE_HAFNIUM_REQUIRE:tc = "hafnium-tc.inc"

 require ${MACHINE_HAFNIUM_REQUIRE}
@@ -2,10 +2,7 @@ COMPATIBLE_MACHINE = "corstone1000"

 FIRMWARE_BINARIES = "corstone1000-flash-firmware-image-${MACHINE}.wic \
                     bl1.bin \
-                     ${@bb.utils.contains('MACHINE_FEATURES', \
-                                          'corstone1000-extsys', \
-                                          'es_flashfw.bin', \
-                                          '', d)} \
+                     es_flashfw.bin \
                     ${CAPSULE_NAME}.${CAPSULE_EXTENSION} \
                     corstone1000_capsule_cert.crt \
                     corstone1000_capsule_key.key \
@@ -14,8 +14,7 @@ inherit tfm_sign_image
 inherit uefi_capsule
 inherit deploy

-DEPENDS += "${@bb.utils.contains('MACHINE_FEATURES', 'corstone1000-extsys', \
-                                 'external-system', '', d)} \
+DEPENDS += "external-system \
            trusted-firmware-a \
            trusted-firmware-m \
            u-boot \
@@ -26,133 +25,21 @@ IMAGE_LINGUAS = ""

 PACKAGE_INSTALL = ""

+# The generated ${MACHINE}_image.nopt is used instead of the default wic image
+# for the capsule generation. The uefi.capsule image type doesn't have to
+# depend on the wic because of this.
+#
 # The corstone1000_capsule_cert.crt and corstone1000_capsule_key.key are installed
 # by the U-Boot recipe so this recipe has to depend on that.
-
 CAPSULE_IMGTYPE = ""
-CAPSULE_IMG_LOCATION = "${DEPLOY_DIR_IMAGE}"
-
-# User-configurable common capsule settings
-CAPSULE_EXTENSION ?= "uefi.capsule"
-CAPSULE_VERSION ?= "6"
-CAPSULE_LOWEST_SUPPORTED_VERSION ?= "6"
-CAPSULE_NAME ?= "${MACHINE}-v${CAPSULE_VERSION}"
-CAPSULE_SELECTED_COMPONENTS ?= "BL2 TFM_S FIP INITRAMFS"
-CAPSULE_EXTRA_ARGS ?= "--capflag PersistAcrossReset"
-
-# Non-configurable common payloads settings
-PAYLOAD_CERTIFICATE_PATH = "${DEPLOY_DIR_IMAGE}/corstone1000_capsule_cert.crt"
-PAYLOAD_HARDWARE_INSTANCE = "1"
-PAYLOAD_MONOTONIC_COUNT = "1"
-PAYLOAD_PRIVATE_KEY_PATH = "${DEPLOY_DIR_IMAGE}/corstone1000_capsule_key.key"
-CAPSULE_SELECTED_COMPONENTS += " DUMMY_START DUMMY_END"
-
-# All capsule fields are reset and initialized with DUMMY_START since it is the first payload
-# DUMMY_START
-PAYLOAD_DUMMY_START_INDEX ?= "5"
-PAYLOAD_DUMMY_START_VERSION ?= "${CAPSULE_VERSION}"
-PAYLOAD_DUMMY_START_LOWEST_SUPPORTED_VERSION ?= "${CAPSULE_LOWEST_SUPPORTED_VERSION}"
-PAYLOAD_DUMMY_START_GUID ?=  "6f784cbf-7938-5c23-8d6e-24d2f1410fa9"
-
-CAPSULE_ALL_COMPONENTS = "DUMMY_START "
-CAPSULE_CERTIFICATE_PATHS = "${PAYLOAD_CERTIFICATE_PATH} "
-CAPSULE_GUIDS = "${PAYLOAD_DUMMY_START_GUID} "
-CAPSULE_INDEXES = "${PAYLOAD_DUMMY_START_INDEX} "
-CAPSULE_HARDWARE_INSTANCES = "${PAYLOAD_HARDWARE_INSTANCE} "
-CAPSULE_MONOTONIC_COUNTS = "${PAYLOAD_MONOTONIC_COUNT} "
-CAPSULE_PRIVATE_KEY_PATHS = "${PAYLOAD_PRIVATE_KEY_PATH} "
-UEFI_FIRMWARE_BINARIES = "${B}/dummy.bin "
-CAPSULE_FW_VERSIONS = "${PAYLOAD_DUMMY_START_VERSION} "
-CAPSULE_LOWEST_SUPPORTED_VERSIONS = "${PAYLOAD_DUMMY_START_LOWEST_SUPPORTED_VERSION} "
-
-# BL2
-PAYLOAD_BL2_INDEX ?= "1"
-PAYLOAD_BL2_VERSION ?= "${CAPSULE_VERSION}"
-PAYLOAD_BL2_LOWEST_SUPPORTED_VERSION ?= "${CAPSULE_LOWEST_SUPPORTED_VERSION}"
-PAYLOAD_BL2_GUID:corstone1000-fvp ?= "f1d883f9-dfeb-5363-98d8-686ee3b69f4f"
-PAYLOAD_BL2_GUID:corstone1000-mps3 ?= "fbfbefaa-0a56-50d5-b651-74091d3d62cf"
-
-CAPSULE_ALL_COMPONENTS += "BL2 "
-CAPSULE_CERTIFICATE_PATHS += "${PAYLOAD_CERTIFICATE_PATH} "
-CAPSULE_GUIDS += "${PAYLOAD_BL2_GUID} "
-CAPSULE_INDEXES += "${PAYLOAD_BL2_INDEX} "
-CAPSULE_HARDWARE_INSTANCES += "${PAYLOAD_HARDWARE_INSTANCE} "
-CAPSULE_MONOTONIC_COUNTS += "${PAYLOAD_MONOTONIC_COUNT} "
-CAPSULE_PRIVATE_KEY_PATHS += "${PAYLOAD_PRIVATE_KEY_PATH} "
-UEFI_FIRMWARE_BINARIES += "${DEPLOY_DIR_IMAGE}/bl2_signed.bin "
-CAPSULE_FW_VERSIONS += "${PAYLOAD_BL2_VERSION} "
-CAPSULE_LOWEST_SUPPORTED_VERSIONS += "${PAYLOAD_BL2_LOWEST_SUPPORTED_VERSION} "
-
-# TFM_S
-PAYLOAD_TFM_S_INDEX ?= "2"
-PAYLOAD_TFM_S_VERSION ?= "${CAPSULE_VERSION}"
-PAYLOAD_TFM_S_LOWEST_SUPPORTED_VERSION ?= "${CAPSULE_LOWEST_SUPPORTED_VERSION}"
-PAYLOAD_TFM_S_GUID:corstone1000-fvp ?= "7fad470e-5ec5-5c03-a2c1-4756b495de61"
-PAYLOAD_TFM_S_GUID:corstone1000-mps3 ?= "af4cc7ad-ee2e-5a39-aad5-fac8a1e6173c"
-
-CAPSULE_ALL_COMPONENTS += "TFM_S "
-CAPSULE_CERTIFICATE_PATHS += "${PAYLOAD_CERTIFICATE_PATH} "
-CAPSULE_GUIDS += "${PAYLOAD_TFM_S_GUID} "
-CAPSULE_INDEXES += "${PAYLOAD_TFM_S_INDEX} "
-CAPSULE_HARDWARE_INSTANCES += "${PAYLOAD_HARDWARE_INSTANCE} "
-CAPSULE_MONOTONIC_COUNTS += "${PAYLOAD_MONOTONIC_COUNT} "
-CAPSULE_PRIVATE_KEY_PATHS += "${PAYLOAD_PRIVATE_KEY_PATH} "
-UEFI_FIRMWARE_BINARIES += "${DEPLOY_DIR_IMAGE}/tfm_s_signed.bin "
-CAPSULE_FW_VERSIONS += "${PAYLOAD_TFM_S_VERSION} "
-CAPSULE_LOWEST_SUPPORTED_VERSIONS += "${PAYLOAD_TFM_S_LOWEST_SUPPORTED_VERSION} "
-
-# FIP
-PAYLOAD_FIP_INDEX ?= "3"
-PAYLOAD_FIP_VERSION ?= "${CAPSULE_VERSION}"
-PAYLOAD_FIP_LOWEST_SUPPORTED_VERSION ?= "${CAPSULE_LOWEST_SUPPORTED_VERSION}"
-PAYLOAD_FIP_GUID:corstone1000-fvp ?= "f1933675-5a8c-5b6d-9ef4-846739e89bc8"
-PAYLOAD_FIP_GUID:corstone1000-mps3 ?= "55302f96-c4f0-5cf9-8624-e7cc388f2b68"
-
-CAPSULE_ALL_COMPONENTS += "FIP "
-CAPSULE_CERTIFICATE_PATHS += "${PAYLOAD_CERTIFICATE_PATH} "
-CAPSULE_GUIDS += "${PAYLOAD_FIP_GUID} "
-CAPSULE_INDEXES += "${PAYLOAD_FIP_INDEX} "
-CAPSULE_HARDWARE_INSTANCES += "${PAYLOAD_HARDWARE_INSTANCE} "
-CAPSULE_MONOTONIC_COUNTS += "${PAYLOAD_MONOTONIC_COUNT} "
-CAPSULE_PRIVATE_KEY_PATHS += "${PAYLOAD_PRIVATE_KEY_PATH} "
-UEFI_FIRMWARE_BINARIES += "${DEPLOY_DIR_IMAGE}/signed_fip-corstone1000.bin "
-CAPSULE_FW_VERSIONS += "${PAYLOAD_FIP_VERSION} "
-CAPSULE_LOWEST_SUPPORTED_VERSIONS += "${PAYLOAD_FIP_LOWEST_SUPPORTED_VERSION} "
-
-# INITRAMFS
-PAYLOAD_INITRAMFS_INDEX ?= "4"
-PAYLOAD_INITRAMFS_VERSION ?= "${CAPSULE_VERSION}"
-PAYLOAD_INITRAMFS_LOWEST_SUPPORTED_VERSION ?= "${CAPSULE_LOWEST_SUPPORTED_VERSION}"
-PAYLOAD_INITRAMFS_GUID:corstone1000-fvp ?= "f771aff9-c7e9-5f99-9eda-2369dd694f61"
-PAYLOAD_INITRAMFS_GUID:corstone1000-mps3 ?= "3e8ac972-c33c-5cc9-90a0-cdd3159683ea"
-
-CAPSULE_ALL_COMPONENTS += "INITRAMFS "
-CAPSULE_CERTIFICATE_PATHS += "${PAYLOAD_CERTIFICATE_PATH} "
-CAPSULE_GUIDS += "${PAYLOAD_INITRAMFS_GUID} "
-CAPSULE_INDEXES += "${PAYLOAD_INITRAMFS_INDEX} "
-CAPSULE_HARDWARE_INSTANCES += "${PAYLOAD_HARDWARE_INSTANCE} "
-CAPSULE_MONOTONIC_COUNTS += "${PAYLOAD_MONOTONIC_COUNT} "
-CAPSULE_PRIVATE_KEY_PATHS += "${PAYLOAD_PRIVATE_KEY_PATH} "
-UEFI_FIRMWARE_BINARIES += "${DEPLOY_DIR_IMAGE}/Image.gz-initramfs-${MACHINE}.bin "
-CAPSULE_FW_VERSIONS += "${PAYLOAD_INITRAMFS_VERSION} "
-CAPSULE_LOWEST_SUPPORTED_VERSIONS += "${PAYLOAD_INITRAMFS_LOWEST_SUPPORTED_VERSION} "
-
-# DUMMY_END
-PAYLOAD_DUMMY_END_INDEX ?= "6"
-PAYLOAD_DUMMY_END_VERSION ?= "${CAPSULE_VERSION}"
-PAYLOAD_DUMMY_END_LOWEST_SUPPORTED_VERSION ?= "${CAPSULE_LOWEST_SUPPORTED_VERSION}"
-PAYLOAD_DUMMY_END_GUID ?= "b57e432b-a250-5c73-93e3-90205e64baba"
-
-CAPSULE_ALL_COMPONENTS += "DUMMY_END"
-CAPSULE_CERTIFICATE_PATHS += "${PAYLOAD_CERTIFICATE_PATH}"
-CAPSULE_GUIDS += "${PAYLOAD_DUMMY_END_GUID}"
-CAPSULE_INDEXES += "${PAYLOAD_DUMMY_END_INDEX}"
-CAPSULE_HARDWARE_INSTANCES += "${PAYLOAD_HARDWARE_INSTANCE}"
-CAPSULE_MONOTONIC_COUNTS += "${PAYLOAD_MONOTONIC_COUNT}"
-CAPSULE_PRIVATE_KEY_PATHS += "${PAYLOAD_PRIVATE_KEY_PATH}"
-UEFI_FIRMWARE_BINARIES += "${B}/dummy.bin"
-CAPSULE_FW_VERSIONS += "${PAYLOAD_DUMMY_END_VERSION}"
-CAPSULE_LOWEST_SUPPORTED_VERSIONS += "${PAYLOAD_DUMMY_END_LOWEST_SUPPORTED_VERSION}"
+CAPSULE_CERTIFICATE_PATH = "${DEPLOY_DIR_IMAGE}/corstone1000_capsule_cert.crt"
+CAPSULE_GUID:corstone1000-fvp ?= "989f3a4e-46e0-4cd0-9877-a25c70c01329"
+CAPSULE_GUID:corstone1000-mps3 ?= "df1865d1-90fb-4d59-9c38-c9f2c1bba8cc"
+CAPSULE_IMGLOCATION = "${DEPLOY_DIR_IMAGE}"
+CAPSULE_INDEX = "1"
+CAPSULE_MONOTONIC_COUNT = "1"
+CAPSULE_PRIVATE_KEY_PATH = "${DEPLOY_DIR_IMAGE}/corstone1000_capsule_key.key"
+UEFI_FIRMWARE_BINARY = "${B}/${MACHINE}_image.nopt"

 # TF-A settings for signing host images
 TFA_BL2_BINARY = "bl2-corstone1000.bin"
@@ -162,9 +49,14 @@ TFA_BL2_RE_SIGN_BIN_SIZE = "0x2d000"
 TFA_FIP_RE_IMAGE_LOAD_ADDRESS = "0x68130000"
 TFA_FIP_RE_SIGN_BIN_SIZE = "0x00200000"
 RE_LAYOUT_WRAPPER_VERSION = "0.0.7"
-TFM_SIGN_PRIVATE_KEY = "${libdir}/tfm-scripts/root-EC-P256_1.pem"
+TFM_SIGN_PRIVATE_KEY = "${libdir}/tfm-scripts/root-RSA-3072_1.pem"
 RE_IMAGE_OFFSET = "0x1000"

+# Offsets for the .nopt image generation
+TFM_OFFSET = "102400"
+FIP_OFFSET = "479232"
+KERNEL_OFFSET = "2576384"
+
 do_sign_images() {
    # Sign TF-A BL2
    sign_host_image ${RECIPE_SYSROOT}/firmware/${TFA_BL2_BINARY} \
@@ -184,11 +76,21 @@ do_sign_images[depends] = "\
    fiptool-native:do_populate_sysroot \
    "

-# Create an empty dummy payload file required for capsule generation
-create_dummy_image() {
-    touch  ${B}/dummy.bin
+# This .nopt image is not the same as the one which is generated by meta-arm/meta-arm/classes/wic_nopt.bbclass.
+# The meta-arm/meta-arm/classes/wic_nopt.bbclass removes the partition table from the wic image, but keeps the
+# second bank. This function creates a no-partition image with only the first bank.
+create_nopt_image() {
+    dd conv=notrunc bs=1 if=${DEPLOY_DIR_IMAGE}/bl2_signed.bin of=${B}/${MACHINE}_image.nopt
+    dd conv=notrunc bs=1 if=${DEPLOY_DIR_IMAGE}/tfm_s_signed.bin of=${B}/${MACHINE}_image.nopt seek=${TFM_OFFSET}
+    dd conv=notrunc bs=1 if=${DEPLOY_DIR_IMAGE}/signed_fip-corstone1000.bin of=${B}/${MACHINE}_image.nopt seek=${FIP_OFFSET}
+    dd conv=notrunc bs=1 if=${DEPLOY_DIR_IMAGE}/Image.gz-initramfs-${MACHINE}.bin of=${B}/${MACHINE}_image.nopt seek=${KERNEL_OFFSET}
+}
+do_image_uefi_capsule[depends] += " linux-yocto:do_deploy"
+do_image_uefi_capsule[mcdepends] += " ${@bb.utils.contains('BBMULTICONFIG', 'firmware', 'mc::firmware:linux-yocto:do_deploy', '', d)}"
+do_image_uefi_capsule[prefuncs] += "create_nopt_image"
+
+do_deploy() {
+    install -m 0755 ${B}/${MACHINE}_image.nopt  ${DEPLOYDIR}
 }

-do_image_uefi_capsule[depends] += " linux-yocto:do_deploy corstone1000-flash-firmware-image:do_sign_images"
-do_image_uefi_capsule[mcdepends] += " ${@bb.utils.contains('BBMULTICONFIG', 'firmware', 'mc::firmware:linux-yocto:do_deploy mc::firmware:corstone1000-flash-firmware-image:do_sign_images', '', d)}"
-do_image_uefi_capsule[prefuncs] += "create_dummy_image"
+addtask deploy after do_image_uefi_capsule
@@ -14,7 +14,7 @@ COMPATIBLE_MACHINE = "juno"

 LINARO_RELEASE = "19.06"

-SRC_URI = "http://releases.linaro.org/members/arm/platforms/${LINARO_RELEASE}/juno-latest-oe-uboot.zip;subdir=${S} \
+SRC_URI = "http://releases.linaro.org/members/arm/platforms/${LINARO_RELEASE}/juno-latest-oe-uboot.zip;subdir=${UNPACK_DIR} \
    file://images-r0.txt \
    file://images-r1.txt \
    file://images-r2.txt \
@@ -23,8 +23,7 @@ SRC_URI = "http://releases.linaro.org/members/arm/platforms/${LINARO_RELEASE}/ju
 SRC_URI[md5sum] = "01b662b81fa409d55ff298238ad24003"
 SRC_URI[sha256sum] = "b8a3909bb3bc4350a8771b863193a3e33b358e2a727624a77c9ecf13516cec82"

-FIRMWARE_DIR = "juno-firmware-${LINARO_RELEASE}"
-S = "${UNPACKDIR}/${FIRMWARE_DIR}"
+UNPACK_DIR = "juno-firmware-${LINARO_RELEASE}"

 inherit deploy nopackages

@@ -34,23 +33,23 @@ do_compile[noexec] = "1"
 # The ${D} is used as a temporary directory and we don't generate any
 # packages for this recipe.
 do_install() {
-    cp -a ${S} ${D}/
+    cp -a ${WORKDIR}/${UNPACK_DIR} ${D}
    cp -f ${RECIPE_SYSROOT}/firmware/bl1-juno.bin \
-        ${D}/${FIRMWARE_DIR}/SOFTWARE/bl1.bin
+        ${D}/${UNPACK_DIR}/SOFTWARE/bl1.bin

    cp -f ${RECIPE_SYSROOT}/firmware/fip-juno.bin \
-        ${D}/${FIRMWARE_DIR}/SOFTWARE/fip.bin
+        ${D}/${UNPACK_DIR}/SOFTWARE/fip.bin

    cp -f ${RECIPE_SYSROOT}/firmware/scp_romfw_bypass.bin \
-        ${D}/${FIRMWARE_DIR}/SOFTWARE/scp_bl1.bin
+        ${D}/${UNPACK_DIR}/SOFTWARE/scp_bl1.bin

    # u-boot environment file
-    cp -f ${UNPACKDIR}/uEnv.txt ${D}/${FIRMWARE_DIR}/SOFTWARE/
+    cp -f ${WORKDIR}/uEnv.txt ${D}/${UNPACK_DIR}/SOFTWARE/

    # Juno images list file
-    cp -f ${UNPACKDIR}/images-r0.txt ${D}/${FIRMWARE_DIR}/SITE1/HBI0262B/images.txt
-    cp -f ${UNPACKDIR}/images-r1.txt ${D}/${FIRMWARE_DIR}/SITE1/HBI0262C/images.txt
-    cp -f ${UNPACKDIR}/images-r2.txt ${D}/${FIRMWARE_DIR}/SITE1/HBI0262D/images.txt
+    cp -f ${WORKDIR}/images-r0.txt ${D}/${UNPACK_DIR}/SITE1/HBI0262B/images.txt
+    cp -f ${WORKDIR}/images-r1.txt ${D}/${UNPACK_DIR}/SITE1/HBI0262C/images.txt
+    cp -f ${WORKDIR}/images-r2.txt ${D}/${UNPACK_DIR}/SITE1/HBI0262D/images.txt
 }

 do_deploy() {
@@ -60,18 +59,18 @@ do_deploy() {
    # task.
    for f in ${KERNEL_DEVICETREE}; do
        install -m 755 -c ${DEPLOY_DIR_IMAGE}/$(basename $f) \
-            ${D}/${FIRMWARE_DIR}/SOFTWARE/
+            ${D}/${UNPACK_DIR}/SOFTWARE/.
    done

    if [ "${INITRAMFS_IMAGE_BUNDLE}" -eq 1 ]; then
        cp -L -f ${DEPLOY_DIR_IMAGE}/Image.gz-initramfs-juno.bin \
-            ${D}/${FIRMWARE_DIR}/SOFTWARE/Image
+            ${D}/${UNPACK_DIR}/SOFTWARE/Image
    else
-        cp -L -f ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE} ${D}/${FIRMWARE_DIR}/SOFTWARE/
+        cp -L -f ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE} ${D}/${UNPACK_DIR}/SOFTWARE/
    fi

    # Compress the files
-    tar -C ${D}/${FIRMWARE_DIR} -zcvf ${WORKDIR}/${PN}.tar.gz ./
+    tar -C ${D}/${UNPACK_DIR} -zcvf ${WORKDIR}/${PN}.tar.gz ./

    # Deploy the compressed archive to the deploy folder
    install -D -p -m0644 ${WORKDIR}/${PN}.tar.gz ${DEPLOYDIR}/${PN}.tar.gz
@@ -0,0 +1,37 @@
+SUMMARY = "Board Firmware binaries for N1SDP"
+SECTION = "firmware"
+
+LICENSE = "STM-SLA0044-Rev5"
+LIC_FILES_CHKSUM = "file://LICENSES/MB/STM.TXT;md5=1b74d8c842307d03c116f2d71cbf868a"
+
+inherit deploy
+
+INHIBIT_DEFAULT_DEPS = "1"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+COMPATIBLE_MACHINE = "n1sdp"
+
+SRC_URI = "git://git.gitlab.arm.com/arm-reference-solutions/board-firmware.git;protocol=https;branch=n1sdp"
+
+SRCREV = "70ba494265eee76747faff38264860c19e214540"
+PV .= "+git"
+
+S = "${WORKDIR}/git"
+
+INSTALL_DIR = "/n1sdp-board-firmware_source"
+
+do_install() {
+    rm -rf ${S}/SOFTWARE
+    install -d ${D}${INSTALL_DIR}
+    cp -Rp --no-preserve=ownership ${S}/* ${D}${INSTALL_DIR}
+}
+
+FILES:${PN}-staticdev += " ${INSTALL_DIR}/LIB/sensor.a"
+FILES:${PN} = "${INSTALL_DIR}"
+SYSROOT_DIRS += "${INSTALL_DIR}"
+
+do_deploy() {
+    install -d ${DEPLOYDIR}${INSTALL_DIR}
+    cp -Rp --no-preserve=ownership ${S}/* ${DEPLOYDIR}${INSTALL_DIR}
+}
+addtask deploy after do_install before do_build
@@ -0,0 +1,85 @@
+SUMMARY = "Firmware image recipe for generating SD-Card artifacts."
+
+inherit deploy nopackages
+
+DEPENDS = "trusted-firmware-a \
+           virtual/control-processor-firmware \
+           n1sdp-board-firmware"
+
+LICENSE = "MIT"
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+COMPATIBLE_MACHINE = "n1sdp"
+RM_WORK_EXCLUDE += "${PN}"
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+do_install[noexec] = "1"
+
+FIRMWARE_DIR = "n1sdp-board-firmware_source"
+PRIMARY_DIR = "${WORKDIR}/n1sdp-board-firmware_primary"
+SECONDARY_DIR = "${WORKDIR}/n1sdp-board-firmware_secondary"
+
+SOC_BINARIES = "mcp_fw.bin scp_fw.bin mcp_rom.bin scp_rom.bin"
+
+prepare_package() {
+    cd ${WORKDIR}
+
+    # Master/Primary
+    cp -av ${RECIPE_SYSROOT}/${FIRMWARE_DIR}/* ${PRIMARY_DIR}
+    mkdir -p ${PRIMARY_DIR}/SOFTWARE/
+
+    # Copy FIP binary
+    cp -v ${RECIPE_SYSROOT}/firmware/fip.bin ${PRIMARY_DIR}/SOFTWARE/
+
+    # Copy SOC binaries
+    for f in ${SOC_BINARIES}; do
+        cp -v ${RECIPE_SYSROOT}/firmware/${f} ${PRIMARY_DIR}/SOFTWARE/
+    done
+
+    sed -i -e 's|^C2C_ENABLE.*|C2C_ENABLE: TRUE            ;C2C enable TRUE/FALSE|' \
+        ${PRIMARY_DIR}/MB/HBI0316A/io_v123f.txt
+    sed -i -e 's|^C2C_SIDE.*|C2C_SIDE: MASTER            ;C2C side SLAVE/MASTER|' \
+        ${PRIMARY_DIR}/MB/HBI0316A/io_v123f.txt
+    sed -i -e 's|.*SOCCON: 0x1170.*PLATFORM_CTRL.*|SOCCON: 0x1170 0x00000100   ;SoC SCC PLATFORM_CTRL|' \
+        ${PRIMARY_DIR}/MB/HBI0316A/io_v123f.txt
+
+    # Update load address for trusted boot
+    sed -i -e '/^IMAGE4ADDRESS:/ s|0x60200000|0x64200000|' ${PRIMARY_DIR}/MB/HBI0316A/images.txt
+    sed -i -e '/^IMAGE4UPDATE:/ s|FORCE   |SCP_AUTO|' ${PRIMARY_DIR}/MB/HBI0316A/images.txt
+    sed -i -e '/^IMAGE4FILE: \\SOFTWARE\\/s|uefi.bin|fip.bin |' ${PRIMARY_DIR}/MB/HBI0316A/images.txt
+
+    # Slave/Secondary
+    cp -av ${RECIPE_SYSROOT}/${FIRMWARE_DIR}/* ${SECONDARY_DIR}
+    mkdir -p ${SECONDARY_DIR}/SOFTWARE/
+
+    # Copy SOC binaries
+    for f in ${SOC_BINARIES}; do
+        cp -v ${RECIPE_SYSROOT}/firmware/${f} ${SECONDARY_DIR}/SOFTWARE/
+    done
+
+    sed -i -e 's|^C2C_ENABLE.*|C2C_ENABLE: TRUE            ;C2C enable TRUE/FALSE|' \
+        ${SECONDARY_DIR}/MB/HBI0316A/io_v123f.txt
+    sed -i -e 's|^C2C_SIDE.*|C2C_SIDE: SLAVE             ;C2C side SLAVE/MASTER|' \
+        ${SECONDARY_DIR}/MB/HBI0316A/io_v123f.txt
+    sed -i -e 's|.*SOCCON: 0x1170.*PLATFORM_CTRL.*|SOCCON: 0x1170 0x00000101   ;SoC SCC PLATFORM_CTRL|' \
+        ${SECONDARY_DIR}/MB/HBI0316A/io_v123f.txt
+    sed -i -e '/^TOTALIMAGES:/ s|5|4|' ${SECONDARY_DIR}/MB/HBI0316A/images.txt
+    sed -i -e 's|^IMAGE4|;&|' ${SECONDARY_DIR}/MB/HBI0316A/images.txt
+}
+
+do_deploy() {
+    # prepare Master & Slave packages
+    prepare_package
+
+    for dir in ${PRIMARY_DIR} ${SECONDARY_DIR}; do
+        dir_name=$(basename ${dir})
+        mkdir -p ${D}/${dir_name}
+        cp -av ${dir} ${D}
+
+        # Compress the files
+        tar -C ${D}/${dir_name} -zcvf ${DEPLOYDIR}/${dir_name}.tar.gz ./
+    done
+}
+do_deploy[dirs] += "${PRIMARY_DIR} ${SECONDARY_DIR}"
+do_deploy[cleandirs] += "${PRIMARY_DIR} ${SECONDARY_DIR}"
+do_deploy[umask] = "022"
+addtask deploy after do_prepare_recipe_sysroot
@@ -0,0 +1,35 @@
+# N1SDP specific SCP configurations and build instructions
+
+COMPATIBLE_MACHINE:n1sdp = "n1sdp"
+
+SCP_LOG_LEVEL = "INFO"
+
+DEPENDS += "fiptool-native"
+DEPENDS += "trusted-firmware-a"
+DEPENDS += "n1sdp-board-firmware"
+
+# The n1sdp sensor library is needed for building SCP N1SDP Platform
+# https://github.com/ARM-software/SCP-firmware/tree/master/product/n1sdp
+EXTRA_OECMAKE:append = " \
+    -DSCP_N1SDP_SENSOR_LIB_PATH=${RECIPE_SYSROOT}/n1sdp-board-firmware_source/LIB/sensor.a \
+"
+
+do_install:append() {
+   fiptool \
+       create \
+       --scp-fw "${D}/firmware/scp_ramfw.bin" \
+       --blob uuid=cfacc2c4-15e8-4668-82be-430a38fad705,file="${RECIPE_SYSROOT}/firmware/bl1.bin" \
+       "scp_fw.bin"
+
+   # This UUID is FIP_UUID_MCP_BL2 in SCP-Firmware.
+   fiptool \
+       create \
+       --blob uuid=54464222-a4cf-4bf8-b1b6-cee7dade539e,file="${D}/firmware/mcp_ramfw.bin" \
+       "mcp_fw.bin"
+
+   install "scp_fw.bin" "${D}/firmware/scp_fw.bin"
+   install "mcp_fw.bin" "${D}/firmware/mcp_fw.bin"
+
+   ln -sf "scp_romfw.bin" "${D}/firmware/scp_rom.bin"
+   ln -sf "mcp_romfw.bin" "${D}/firmware/mcp_rom.bin"
+}
@@ -3,6 +3,8 @@
 MACHINE_SCP_REQUIRE ?= ""

 MACHINE_SCP_REQUIRE:juno = "scp-firmware-juno.inc"
+MACHINE_SCP_REQUIRE:n1sdp = "scp-firmware-n1sdp.inc"
 MACHINE_SCP_REQUIRE:sgi575 = "scp-firmware-sgi575.inc"
+MACHINE_SCP_REQUIRE:tc = "scp-firmware-tc.inc"

 require ${MACHINE_SCP_REQUIRE}
@@ -0,0 +1,32 @@
+From d70a07562d3b0a7b4441922fd3ce136565927d04 Mon Sep 17 00:00:00 2001
+From: Emekcan Aras <Emekcan.Aras@arm.com>
+Date: Wed, 21 Feb 2024 07:57:36 +0000
+Subject: [PATCH] fix(corstone1000): pass spsr value explicitly
+
+Passes spsr value for BL32 (OPTEE) explicitly between different boot
+stages.
+
+Upstream-Status: Pending
+Signed-off-by: Emekcan Aras <Emekcan.Aras@arm.com>
+---
+ .../corstone1000/common/corstone1000_bl2_mem_params_desc.c     | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/plat/arm/board/corstone1000/common/corstone1000_bl2_mem_params_desc.c b/plat/arm/board/corstone1000/common/corstone1000_bl2_mem_params_desc.c
+index fe521a9fa..2cc096f38 100644
+--- a/plat/arm/board/corstone1000/common/corstone1000_bl2_mem_params_desc.c
+++ b/plat/arm/board/corstone1000/common/corstone1000_bl2_mem_params_desc.c
+@@ -72,7 +72,8 @@ static bl_mem_params_node_t bl2_mem_params_descs[] = {
+ 		SET_STATIC_PARAM_HEAD(ep_info, PARAM_EP,
+ 			VERSION_2, entry_point_info_t, NON_SECURE | EXECUTABLE),
+ 		.ep_info.pc = BL33_BASE,
+-
+		.ep_info.spsr = SPSR_64(MODE_EL2, MODE_SP_ELX,
+				       DISABLE_ALL_EXCEPTIONS),
+ 		SET_STATIC_PARAM_HEAD(image_info, PARAM_EP,
+ 			VERSION_2, image_info_t, 0),
+ 		.image_info.image_base = BL33_BASE,
+-- 
+2.25.1
+
+
@@ -1,241 +0,0 @@
-From 977f06e10e549d01a641a62a1d4850a06d6f0df4 Mon Sep 17 00:00:00 2001
-From: Harsimran Singh Tungal <harsimransingh.tungal@arm.com>
-Date: Thu, 7 Aug 2025 10:05:02 +0000
-Subject: [PATCH] plat: corstone1000: add Cortex-A320 support
-
-Introduce `CORSTONE1000_CORTEX_A320` to enable Cortex-A320 on
-Corstone-1000 while keeping Cortex-A35 as the default. When the
-define is enabled, the build switches from `cortex_a35.S` to
-`cortex_a320.S`, maintaining compatibility with existing A35-based
-designs.
-
-Also add Normal-World mappings for the Ethos-U85 NPU and its SRAM
-on Cortex-A320 platforms so U-Boot and other non-secure software
-can safely access these regions:
-
-* **Ethos-U85 registers**: base `0x1A050000`, size `0x00004000` (16 KB),
-  attrs `MT_DEVICE | MT_RW | MT_NS`
-* **Non-secure SRAM**: base `0x02400000`, size `0x00400000` (4 MB),
-  attrs `MT_MEMORY | MT_RW | MT_NS`
-
-Enable GICv3 with GIC-600 when building for Cortex-A320 (retain
-GICv2/GIC-400 for Cortex-A35):
-
-* Update `plat_my_core_pos()` and `plat_arm_calc_core_pos()` to use
-  the Cortex-A320 MPIDR_EL1 affinity layout.
-* Add an A320-specific core-position routine in assembly guarded by
-  `CORSTONE1000_CORTEX_A320`.
-* Switch to the GICv3 driver with GIC-600 extensions: update GIC base
-  addresses, use GICv3 APIs, and set `USE_GIC_DRIVER=3`,
-  `GICV3_SUPPORT_GIC600=1`, `GIC_ENABLE_V4_EXTN=1`.
-
-These changes prepare the platform for Cortex-A320 integration and
-ensure correct GIC configuration and secondary-core bring-up, while
-preserving A35 behavior.
-
-Upstream-Status: Submitted (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/45729)
-Signed-off-by: Harsimran Singh Tungal <harsimransingh.tungal@arm.com>
-Signed-off-by: Frazer Carsley <frazer.carsley@arm.com>
-Signed-off-by: Michael Safwat <michael.safwat@arm.com>
---
- .../common/corstone1000_helpers.S             | 35 ++++++++++++++++++-
- .../corstone1000/common/corstone1000_plat.c   |  4 +++
- .../corstone1000/common/corstone1000_pm.c     |  8 +++++
- .../common/include/platform_def.h             | 28 ++++++++++++++-
- plat/arm/board/corstone1000/platform.mk       | 11 ++++++
- 5 files changed, 84 insertions(+), 2 deletions(-)
-
-diff --git a/plat/arm/board/corstone1000/common/corstone1000_helpers.S b/plat/arm/board/corstone1000/common/corstone1000_helpers.S
-index a4ca9fe98..665dbc61a 100644
--- a/plat/arm/board/corstone1000/common/corstone1000_helpers.S
-+++ b/plat/arm/board/corstone1000/common/corstone1000_helpers.S
-@@ -1,5 +1,5 @@
- /*
- * Copyright (c) 2021-2024 Arm Limited and Contributors. All rights reserved.
-+ * Copyright (c) 2021-2025 Arm Limited and Contributors. All rights reserved.
-  *
-  * SPDX-License-Identifier: BSD-3-Clause
-  */
-@@ -13,6 +13,39 @@
- 	.globl	plat_is_my_cpu_primary
- 	.globl	plat_arm_calc_core_pos
- 
-+#ifdef CORSTONE1000_CORTEX_A320
-+	.globl	plat_my_core_pos
-+
-+func plat_my_core_pos
-+	mrs	x0, mpidr_el1
-+	b	plat_arm_calc_core_pos
-+endfunc plat_my_core_pos
-+
-+func plat_arm_calc_core_pos
-+	/* Aff0 is always 0 for Cortex-A320
-+	MPIDR format: https://developer.arm.com/documentation/109551/0001/AArch64-registers/AArch64-Identification-registers-summary/MPIDR-EL1--Multiprocessor-Affinity-Register?lang=en
-+	*/
-+	/* Extract Aff1 (core ID) */
-+	ubfx    x1, x0, #MPIDR_AFF1_SHIFT, #MPIDR_AFFINITY_BITS
-+
-+	/* Extract Aff2 (cluster lower bits) */
-+	ubfx    x2, x0, #MPIDR_AFF2_SHIFT, #MPIDR_AFFINITY_BITS
-+
-+	/* Extract Aff3 (cluster upper bits) */
-+	ubfx    x3, x0, #MPIDR_AFF3_SHIFT, #MPIDR_AFFINITY_BITS
-+
-+	/* cluster_id = (Aff3 << 8) | Aff2 */
-+	lsl     x3, x3, #MPIDR_AFFINITY_BITS
-+	orr     x3, x3, x2
-+
-+	/* core_pos = core_id + (cluster_id * FVP_MAX_CPUS_PER_CLUSTER) */
-+	mov	x4, #CORSTONE1000_MAX_CPUS_PER_CLUSTER
-+	madd	x0, x3, x4, x1
-+
-+	ret
-+endfunc plat_arm_calc_core_pos
-+#endif
-+
- 	/* --------------------------------------------------------------------
- 	 * void plat_secondary_cold_boot_setup (void);
- 	 *
-diff --git a/plat/arm/board/corstone1000/common/corstone1000_plat.c b/plat/arm/board/corstone1000/common/corstone1000_plat.c
-index e388c82f3..d34e80b29 100644
--- a/plat/arm/board/corstone1000/common/corstone1000_plat.c
-+++ b/plat/arm/board/corstone1000/common/corstone1000_plat.c
-@@ -26,6 +26,10 @@ const mmap_region_t plat_arm_mmap[] = {
- 	ARM_MAP_NS_DRAM1,
- 	CORSTONE1000_MAP_DEVICE,
- 	CORSTONE1000_EXTERNAL_FLASH,
-+#ifdef CORSTONE1000_CORTEX_A320
-+	ARM_MAP_ETHOS_U85,
-+	ARM_MAP_NONSECURE_SRAM,
-+#endif
- 	{0}
- };
- 
-diff --git a/plat/arm/board/corstone1000/common/corstone1000_pm.c b/plat/arm/board/corstone1000/common/corstone1000_pm.c
-index ac808873b..a87697e97 100644
--- a/plat/arm/board/corstone1000/common/corstone1000_pm.c
-+++ b/plat/arm/board/corstone1000/common/corstone1000_pm.c
-@@ -8,7 +8,11 @@
- #include <plat/arm/common/plat_arm.h>
- #include <platform_def.h>
- #include <plat/common/platform.h>
-+#ifdef CORSTONE1000_CORTEX_A320
-+#include <drivers/arm/gicv3.h>
-+#else
- #include <drivers/arm/gicv2.h>
-+#endif
- /*******************************************************************************
-  * Export the platform handlers via plat_arm_psci_pm_ops. The ARM Standard
-  * platform layer will take care of registering the handlers with PSCI.
-@@ -24,7 +28,11 @@ static void corstone1000_system_reset(void)
- 	 * Disable GIC CPU interface to prevent pending interrupt
- 	 * from waking up the AP from WFI.
- 	 */
-+#ifdef CORSTONE1000_CORTEX_A320
-+	gicv3_cpuif_disable(plat_my_core_pos());
-+#else
- 	gicv2_cpuif_disable();
-+#endif
- 
- 	/* Flush and invalidate data cache */
- 	dcsw_op_all(DCCISW);
-diff --git a/plat/arm/board/corstone1000/common/include/platform_def.h b/plat/arm/board/corstone1000/common/include/platform_def.h
-index caf3d462f..ee0babbf8 100644
--- a/plat/arm/board/corstone1000/common/include/platform_def.h
-+++ b/plat/arm/board/corstone1000/common/include/platform_def.h
-@@ -1,5 +1,5 @@
- /*
- * Copyright (c) 2021-2024, Arm Limited and Contributors. All rights reserved.
-+ * Copyright (c) 2021-2025, Arm Limited and Contributors. All rights reserved.
-  *
-  * SPDX-License-Identifier: BSD-3-Clause
-  */
-@@ -112,12 +112,19 @@
- #define ARM_SHARED_RAM_SIZE	(SZ_8K)  /* 8 KB */
- #define ARM_SHARED_RAM_BASE	ARM_TRUSTED_SRAM_BASE
- 
-+#ifdef CORSTONE1000_CORTEX_A320
-+#define TOTAL_SECURE_SRAM_SIZE		(SZ_4M)
-+#define TOTAL_NONSECURE_SRAM_SIZE	(SZ_4M)
-+#define PLAT_ARM_TRUSTED_SRAM_SIZE	(TOTAL_SECURE_SRAM_SIZE - \
-+					 ARM_SHARED_RAM_SIZE)
-+#else
- /* The remaining Trusted SRAM is used to load the BL images */
- #define TOTAL_SRAM_SIZE		(SZ_4M)  /* 4 MB */
- 
- 
- #define PLAT_ARM_TRUSTED_SRAM_SIZE	(TOTAL_SRAM_SIZE - \
- 					 ARM_SHARED_RAM_SIZE)
-+#endif
- 
- #define PLAT_ARM_MAX_BL2_SIZE	(180 * SZ_1K)  /* 180 KB */
- 
-@@ -209,8 +216,13 @@
- #define MAX_IO_BLOCK_DEVICES	1
- 
- /* GIC related constants */
-+#ifdef CORSTONE1000_CORTEX_A320
-+#define PLAT_ARM_GICD_BASE	0x1C000000
-+#define PLAT_ARM_GICR_BASE	0x1C040000
-+#else
- #define PLAT_ARM_GICD_BASE	0x1C010000
- #define PLAT_ARM_GICC_BASE	0x1C02F000
-+#endif
- 
- /* MHUv2 Secure Channel receiver and sender */
- #define PLAT_SDK700_MHU0_SEND	0x1B800000
-@@ -335,6 +347,20 @@
- 					CORSTONE1000_DEVICE_BASE, \
- 					CORSTONE1000_DEVICE_SIZE, \
- 					MT_DEVICE | MT_RW | MT_SECURE)
-+#ifdef CORSTONE1000_CORTEX_A320
-+#define ARM_ETHOS_U85_BASE		UL(0x1A050000)
-+#define ARM_ETHOS_U85_SIZE		UL(0x4000)
-+#define ARM_MAP_ETHOS_U85		MAP_REGION_FLAT( \
-+					ARM_ETHOS_U85_BASE, \
-+					ARM_ETHOS_U85_SIZE, \
-+					MT_DEVICE | MT_RW | MT_NS)
-+
-+#define ARM_NONSECURE_SRAM_BASE		(ARM_TRUSTED_SRAM_BASE + TOTAL_SECURE_SRAM_SIZE)
-+#define ARM_MAP_NONSECURE_SRAM		MAP_REGION_FLAT( \
-+					ARM_NONSECURE_SRAM_BASE, \
-+					TOTAL_NONSECURE_SRAM_SIZE, \
-+					MT_MEMORY | MT_RW | MT_NS)
-+#endif
- 
- #define ARM_IRQ_SEC_PHY_TIMER	29
- 
-diff --git a/plat/arm/board/corstone1000/platform.mk b/plat/arm/board/corstone1000/platform.mk
-index 65be9c1f5..fe3e94865 100644
--- a/plat/arm/board/corstone1000/platform.mk
-+++ b/plat/arm/board/corstone1000/platform.mk
-@@ -9,7 +9,14 @@ ifeq ($(filter ${TARGET_PLATFORM}, fpga fvp),)
-         $(error TARGET_PLATFORM must be fpga or fvp)
- endif
- 
-+ifdef CORSTONE1000_CORTEX_A320
-+CORSTONE1000_CPU_LIBS	+=lib/cpus/aarch64/cortex_a320.S
-+$(eval $(call add_define,CORSTONE1000_CORTEX_A320))
-+GIC_ENABLE_V4_EXTN		:= 1
-+GICV3_SUPPORT_GIC600		:= 1
-+else
- CORSTONE1000_CPU_LIBS	+=lib/cpus/aarch64/cortex_a35.S
-+endif
- 
- PLAT_INCLUDES		:=	-Iplat/arm/board/corstone1000/common/include	\
- 				-Iplat/arm/board/corstone1000/include		\
-@@ -43,7 +50,11 @@ $(eval $(call add_define,CORSTONE1000_FVP_MULTICORE))
- endif
- endif
- 
-+ifdef CORSTONE1000_CORTEX_A320
-+USE_GIC_DRIVER			:=	3
-+else
- USE_GIC_DRIVER			:=	2
-+endif
- 
- BL2_SOURCES		+=	plat/arm/board/corstone1000/common/corstone1000_security.c		\
- 				plat/arm/board/corstone1000/common/corstone1000_err.c		\
-- 
-2.50.1
-
@@ -0,0 +1,54 @@
+From 684b8f88238f522b52eb102485762e02e6b1671a Mon Sep 17 00:00:00 2001
+From: Emekcan Aras <Emekcan.Aras@arm.com>
+Date: Fri, 23 Feb 2024 13:17:59 +0000
+Subject: [PATCH] fix(spmd): remove EL3 interrupt registration
+
+This configuration should not be done for corstone1000 and similar
+platforms. GICv2 systems only support EL3 interrupts and can have SEL1 component
+as SPMC.
+
+Signed-off-by: Emekcan Aras <Emekcan.Aras@arm.com>
+Upstream-Status: Inappropriate [Discussions of fixing this in a better way is ongoing in upstream]
+---
+ services/std_svc/spmd/spmd_main.c | 24 ------------------------
+ 1 file changed, 24 deletions(-)
+
+diff --git a/services/std_svc/spmd/spmd_main.c b/services/std_svc/spmd/spmd_main.c
+index 066571e9b..313f05bf3 100644
+--- a/services/std_svc/spmd/spmd_main.c
+++ b/services/std_svc/spmd/spmd_main.c
+@@ -580,30 +580,6 @@ static int spmd_spmc_init(void *pm_addr)
+ 		panic();
+ 	}
+ 
+-	/*
+-	 * Permit configurations where the SPM resides at S-EL1/2 and upon a
+-	 * Group0 interrupt triggering while the normal world runs, the
+-	 * interrupt is routed either through the EHF or directly to the SPMD:
+-	 *
+-	 * EL3_EXCEPTION_HANDLING=0: the Group0 interrupt is routed to the SPMD
+-	 *                   for handling by spmd_group0_interrupt_handler_nwd.
+-	 *
+-	 * EL3_EXCEPTION_HANDLING=1: the Group0 interrupt is routed to the EHF.
+-	 *
+-	 */
+-#if (EL3_EXCEPTION_HANDLING == 0)
+-	/*
+-	 * Register an interrupt handler routing Group0 interrupts to SPMD
+-	 * while the NWd is running.
+-	 */
+-	rc = register_interrupt_type_handler(INTR_TYPE_EL3,
+-					     spmd_group0_interrupt_handler_nwd,
+-					     flags);
+-	if (rc != 0) {
+-		panic();
+-	}
+-#endif
+-
+ 	return 0;
+ }
+ 
+-- 
+2.25.1
+
+
@@ -0,0 +1,92 @@
+From 19600e6718e1a5b2ac8ec27d471acdafce0e433e Mon Sep 17 00:00:00 2001
+From: Emekcan Aras <Emekcan.Aras@arm.com>
+Date: Thu, 25 Apr 2024 11:30:58 +0100
+Subject: [PATCH] fix(corstone1000): remove unused NS_SHARED_RAM region
+
+After enabling additional features in Trusted Services, the size of BL32 image
+(OP-TEE + Trusted Services SPs) is larger now. To create more space in secure RAM 
+for BL32 image, this patch removes NS_SHARED_RAM region which is not currently used by
+corstone1000 platform.
+
+Signed-off-by: Emekcan Aras <Emekcan.Aras@arm.com>
+Upstream-Status: Pending
+---
+ .../corstone1000/common/corstone1000_plat.c   |  1 -
+ .../common/include/platform_def.h             | 19 +------------------
+ 2 files changed, 1 insertion(+), 19 deletions(-)
+
+diff --git a/plat/arm/board/corstone1000/common/corstone1000_plat.c b/plat/arm/board/corstone1000/common/corstone1000_plat.c
+index ed3801caa..a9475859a 100644
+--- a/plat/arm/board/corstone1000/common/corstone1000_plat.c
+++ b/plat/arm/board/corstone1000/common/corstone1000_plat.c
+@@ -23,7 +23,6 @@
+ 
+ const mmap_region_t plat_arm_mmap[] = {
+ 	ARM_MAP_SHARED_RAM,
+-	ARM_MAP_NS_SHARED_RAM,
+ 	ARM_MAP_NS_DRAM1,
+ 	CORSTONE1000_MAP_DEVICE,
+ 	CORSTONE1000_EXTERNAL_FLASH,
+diff --git a/plat/arm/board/corstone1000/common/include/platform_def.h b/plat/arm/board/corstone1000/common/include/platform_def.h
+index 442d187f0..18fce4486 100644
+--- a/plat/arm/board/corstone1000/common/include/platform_def.h
+++ b/plat/arm/board/corstone1000/common/include/platform_def.h
+@@ -90,9 +90,6 @@
+  *	partition size: 176 KB
+  *	content: BL2
+  *
+- * <ARM_NS_SHARED_RAM_BASE> = <ARM_TRUSTED_SRAM_BASE> + 1 MB
+- *	partition size: 512 KB
+- *	content: BL33 (u-boot)
+  */
+ 
+ /* DDR memory */
+@@ -117,11 +114,7 @@
+ /* The remaining Trusted SRAM is used to load the BL images */
+ #define TOTAL_SRAM_SIZE		(SZ_4M)  /* 4 MB */
+ 
+-/* Last 512KB of CVM is allocated for shared RAM as an example openAMP */
+-#define ARM_NS_SHARED_RAM_SIZE	(512 * SZ_1K)
+-
+ #define PLAT_ARM_TRUSTED_SRAM_SIZE	(TOTAL_SRAM_SIZE - \
+-					 ARM_NS_SHARED_RAM_SIZE - \
+ 					 ARM_SHARED_RAM_SIZE)
+ 
+ #define PLAT_ARM_MAX_BL2_SIZE	(180 * SZ_1K)  /* 180 KB */
+@@ -160,11 +153,6 @@
+ 
+ /* NS memory */
+ 
+-/* The last 512KB of the SRAM is allocated as shared memory */
+-#define ARM_NS_SHARED_RAM_BASE	(ARM_TRUSTED_SRAM_BASE + TOTAL_SRAM_SIZE - \
+-				 (PLAT_ARM_MAX_BL31_SIZE + \
+-				  PLAT_ARM_MAX_BL32_SIZE))
+-
+ #define BL33_BASE		ARM_DRAM1_BASE
+ #define PLAT_ARM_MAX_BL33_SIZE	(12 * SZ_1M)  /* 12 MB*/
+ #define BL33_LIMIT		(ARM_DRAM1_BASE + PLAT_ARM_MAX_BL33_SIZE)
+@@ -266,7 +254,7 @@
+ #define PLAT_ARM_TRUSTED_MAILBOX_BASE	ARM_TRUSTED_SRAM_BASE
+ #define PLAT_ARM_NSTIMER_FRAME_ID	U(1)
+ 
+-#define PLAT_ARM_NS_IMAGE_BASE		(ARM_NS_SHARED_RAM_BASE)
+#define PLAT_ARM_NS_IMAGE_BASE		(BL33_BASE)
+
+ #define PLAT_PHY_ADDR_SPACE_SIZE	(1ULL << 32)
+ #define PLAT_VIRT_ADDR_SPACE_SIZE	(1ULL << 32)
+@@ -295,11 +283,6 @@
+ 				ARM_SHARED_RAM_SIZE, \
+ 				MT_MEMORY | MT_RW | MT_SECURE)
+ 
+-#define ARM_MAP_NS_SHARED_RAM	MAP_REGION_FLAT( \
+-				ARM_NS_SHARED_RAM_BASE, \
+-				ARM_NS_SHARED_RAM_SIZE, \
+-				MT_MEMORY | MT_RW | MT_NS)
+-
+ #define ARM_MAP_NS_DRAM1	MAP_REGION_FLAT( \
+ 				ARM_NS_DRAM1_BASE, \
+ 				ARM_NS_DRAM1_SIZE, \
+-- 
+2.25.1
+
+
@@ -0,0 +1,46 @@
+From 37f92eeb4361626072e690adb3b0bb20db7c2fca Mon Sep 17 00:00:00 2001
+From: Emekcan Aras <Emekcan.Aras@arm.com>
+Date: Wed, 15 May 2024 13:54:51 +0100
+Subject: [PATCH] fix(corstone1000): clean the cache and disable interrupt
+ before system reset
+
+Corstone1000 does not properly clean the cache and disable gic interrupts
+before the reset. This causes a race condition especially in FVP after reset.
+This adds proper sequence before resetting the platform.
+
+Signed-off-by: Emekcan Aras <Emekcan.Aras@arm.com>
+Upstream-Status: Pending
+---
+ plat/arm/board/corstone1000/common/corstone1000_pm.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+diff --git a/plat/arm/board/corstone1000/common/corstone1000_pm.c b/plat/arm/board/corstone1000/common/corstone1000_pm.c
+index 4b0a791e7..a52e945bf 100644
+--- a/plat/arm/board/corstone1000/common/corstone1000_pm.c
+++ b/plat/arm/board/corstone1000/common/corstone1000_pm.c
+@@ -7,6 +7,7 @@
+ #include <lib/psci/psci.h>
+ #include <plat/arm/common/plat_arm.h>
+ #include <platform_def.h>
+#include <drivers/arm/gicv2.h>
+ /*******************************************************************************
+  * Export the platform handlers via plat_arm_psci_pm_ops. The ARM Standard
+  * platform layer will take care of registering the handlers with PSCI.
+@@ -18,6 +19,14 @@ static void __dead2 corstone1000_system_reset(void)
+ 	uint32_t volatile * const watchdog_ctrl_reg = (uint32_t *) SECURE_WATCHDOG_ADDR_CTRL_REG;
+ 	uint32_t volatile * const watchdog_val_reg = (uint32_t *) SECURE_WATCHDOG_ADDR_VAL_REG;
+ 
+	/* Flush and invalidate data cache */
+	dcsw_op_all(DCCISW);
+	/*
+	 * Disable GIC CPU interface to prevent pending interrupt
+	 * from waking up the AP from WFI.
+	 */
+	gicv2_cpuif_disable();
+
+ 	*(watchdog_val_reg) = SECURE_WATCHDOG_COUNTDOWN_VAL;
+ 	*watchdog_ctrl_reg = SECURE_WATCHDOG_MASK_ENABLE;
+ 	while (1) {
+-- 
+2.25.1
+
@@ -1,33 +0,0 @@
-From 328bfd8cd95bb0973e4966dcb4e3efa05d62f3f9 Mon Sep 17 00:00:00 2001
-From: Christophe Thiblot <christophe.thiblot@arm.com>
-Date: Wed, 2 Jul 2025 15:03:55 +0000
-Subject: [PATCH] fix: exclude Boot requirement tests for Corstone-1000
-
-A test compares the value of the Generic Timer register CNTFRQ visible in
-two frames CNTBaseN and CNTCTLBase that are linked in Armv8-A and reflect
-the same value.
-    
-An issue in Corstone-1000 (errata 2142118) makes the CNTFRQ views
-inconsistents and the then test fails. There is no workaround and
-the test is skipped.
-    
-Errata: https://developer.arm.com/documentation/sden2142076/0002/?lang=en
-
-Signed-off-by: Christophe Thiblot <christophe.thiblot@arm.com>
-Upstream-Status: Submitted [https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/40810]
---
- plat/arm/corstone1000/tests_to_skip.txt | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/plat/arm/corstone1000/tests_to_skip.txt b/plat/arm/corstone1000/tests_to_skip.txt
-index d937e42..afa3992 100644
--- a/plat/arm/corstone1000/tests_to_skip.txt
-+++ b/plat/arm/corstone1000/tests_to_skip.txt
-@@ -16,3 +16,4 @@ PSCI CPU Suspend in OSI mode
- PSCI STAT/for valid composite state CPU suspend
- FF-A Setup and Discovery/FF-A RXTX remap unmapped region success
- FF-A Memory Sharing/Normal World VM retrieve request into SPMC
-+Boot requirement tests
-- 
-2.43.0
-
@@ -1,163 +0,0 @@
-From 82ca3fcf5c323aec4ce8191c349fd7e00a840e02 Mon Sep 17 00:00:00 2001
-From: Michael Safwat <michael.safwat@arm.com>
-Date: Tue, 26 Aug 2025 11:20:01 +0000
-Subject: [PATCH] plat: corstone1000: Add Cortex-A320 support
-
-Switch platform to GICv3 (GIC-600) for Corstone-1000 with Cortex-A320
-depending on CORSTONE1000_CORTEX_A320:
-    - Define GICD and GICR bases.
-    - Update the platform sources to include the GIC-V3 files.
-
-Move the NVM offset to prevent overlap with the TFTF firmware,
-which starts at 0x80000000 (TFTF_BASE).
-
-Introduce a new skip file tests_to_skip_cortex_a320 to be used when building
-TF-A-Tests with CORSTONE1000_CORTEX_A320=1. This ensures that tests which
-are not supported or cause traps on Corstone-1000 with Cortex-A320 are
-consistently skipped during execution.
-
-Skipped entries:
-    CPU extensions/AMUv1 suspend/resume
-    CPU extensions/Use trace buffer control Registers
-
-Signed-off-by: Michael Safwat <michael.safwat@arm.com>
-Signed-off-by: Harsimran Singh Tungal <harsimransingh.tungal@arm.com>
-Upstream-Status: Submitted (https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/42352)
---
- plat/arm/corstone1000/corstone1000_def.h      | 12 +++++++++-
- plat/arm/corstone1000/include/platform_def.h  | 11 +++++----
- plat/arm/corstone1000/platform.mk             | 23 +++++++++++++++++++
- .../tests_to_skip_cortex_a320.txt             | 21 +++++++++++++++++
- 4 files changed, 61 insertions(+), 6 deletions(-)
- create mode 100644 plat/arm/corstone1000/tests_to_skip_cortex_a320.txt
-
-diff --git a/plat/arm/corstone1000/corstone1000_def.h b/plat/arm/corstone1000/corstone1000_def.h
-index 3e6f036a..c4fa9a3b 100644
--- a/plat/arm/corstone1000/corstone1000_def.h
-+++ b/plat/arm/corstone1000/corstone1000_def.h
-@@ -26,13 +26,23 @@
-  * GIC-400 & interrupt handling related constants
-  ******************************************************************************/
- /* GIC memory map */
-+#ifdef CORSTONE1000_CORTEX_A320
-+#define GICD_BASE	0x1C000000
-+#define GICR_BASE	0x1C040000
-+
-+/* GIC re-distributor doesn't exits on gic-600, but we still need to
-+ * provide GICC_BASE as the gic driver needs it
-+ */
-+#define GICC_BASE		0x0
-+#else
-+
- #define GICD_BASE		0x1C010000
- #define GICC_BASE		0x1C02F000
- /* GIC re-distributor doesn't exits on gic-400, but we still need to
-  * provide GICR_BASE as the gic driver needs it
-  */
- #define GICR_BASE		0x0
-
-+#endif
- /*******************************************************************************
-  * PL011 related constants
-  ******************************************************************************/
-diff --git a/plat/arm/corstone1000/include/platform_def.h b/plat/arm/corstone1000/include/platform_def.h
-index a0d6f7b3..1fc505d0 100644
--- a/plat/arm/corstone1000/include/platform_def.h
-+++ b/plat/arm/corstone1000/include/platform_def.h
-@@ -98,12 +98,13 @@
- #endif
- 
- /*
- * USE 0x200000 DRAM offset to store TFTF data
- *
- * Please note that this won't be suitable for all test scenarios and
- * for this reason some tests will be disabled in this configuration.
-+ * When USE_NVM = 0, TFTF_NVM_OFFSET marks the DRAM region
-+ * used as NVM. This region must not overlap the memory where
-+ * the TFTF image is loaded. The load address is given by
-+ * the TFTF_BASE macro. Set TFTF_NVM_OFFSET to leave enough
-+ * space for the TFTF image.
-  */
-#define TFTF_NVM_OFFSET		0x40000
-+#define TFTF_NVM_OFFSET		0x80000
- #define TFTF_NVM_SIZE		(128 * SZ_1M)	/* 128 MB */
- 
- /*******************************************************************************
-diff --git a/plat/arm/corstone1000/platform.mk b/plat/arm/corstone1000/platform.mk
-index a5a011d5..fd98724a 100644
--- a/plat/arm/corstone1000/platform.mk
-+++ b/plat/arm/corstone1000/platform.mk
-@@ -6,6 +6,19 @@
- 
- PLAT_INCLUDES	:=	-Iplat/arm/corstone1000/include/
- 
-+CORSTONE1000_CORTEX_A320   :=      0
-+ifeq (${CORSTONE1000_CORTEX_A320},1)
-+PLAT_SOURCES   :=   drivers/arm/gic/arm_gic_v2v3.c                  \
-+            drivers/arm/gic/gic_v2.c                        \
-+            drivers/arm/gic/gic_v3.c                        \
-+            drivers/arm/timer/private_timer.c               \
-+            drivers/arm/timer/system_timer.c                \
-+            plat/arm/corstone1000/plat_helpers.S            \
-+            plat/arm/corstone1000/corstone1000_pwr_state.c  \
-+            plat/arm/corstone1000/corstone1000_topology.c   \
-+            plat/arm/corstone1000/corstone1000_mem_prot.c   \
-+            plat/arm/corstone1000/plat_setup.c
-+else
- PLAT_SOURCES	:=	drivers/arm/gic/arm_gic_v2.c			\
- 			drivers/arm/gic/gic_v2.c			\
- 			drivers/arm/timer/private_timer.c		\
-@@ -15,6 +28,7 @@ PLAT_SOURCES	:=	drivers/arm/gic/arm_gic_v2.c			\
- 			plat/arm/corstone1000/corstone1000_topology.c	\
- 			plat/arm/corstone1000/corstone1000_mem_prot.c	\
- 			plat/arm/corstone1000/plat_setup.c
-+endif
- 
- PLAT_SUPPORTS_NS_RESET	:=	1
- 
-@@ -23,6 +37,15 @@ $(eval $(call assert_boolean,PLAT_SUPPORTS_NS_RESET))
- $(eval $(call add_define,TFTF_DEFINES,PLAT_SUPPORTS_NS_RESET))
- 
- FIRMWARE_UPDATE := 0
-+
-+ifeq ($(CORSTONE1000_CORTEX_A320),1)
-+$(eval $(call add_define,TFTF_DEFINES,CORSTONE1000_CORTEX_A320))
-+endif
-+
-+ifeq (${CORSTONE1000_CORTEX_A320},1)
-+PLAT_TESTS_SKIP_LIST    :=      plat/arm/corstone1000/tests_to_skip_cortex_a320.txt
-+else
- PLAT_TESTS_SKIP_LIST    :=      plat/arm/corstone1000/tests_to_skip.txt
-+endif
- 
- include plat/arm/common/arm_common.mk
-diff --git a/plat/arm/corstone1000/tests_to_skip_cortex_a320.txt b/plat/arm/corstone1000/tests_to_skip_cortex_a320.txt
-new file mode 100644
-index 00000000..87b9241d
--- /dev/null
-+++ b/plat/arm/corstone1000/tests_to_skip_cortex_a320.txt
-@@ -0,0 +1,21 @@
-+Realm payload tests
-+Realm payload boot
-+Realm payload multi CPU request
-+Realm payload Delegate and Undelegate
-+Multi CPU Realm payload Delegate and Undelegate
-+Testing delegation fails
-+Realm testing with SPM tests
-+PSCI System Suspend Validation
-+PSCI STAT/Stats test cases after system suspend
-+IRQ support in TSP/Resume preempted STD SMC after PSCI SYSTEM SUSPEND
-+PSCI SYSTEM SUSPEND stress tests
-+Timer framework Validation/Verify the timer interrupt generation
-+CPU Hotplug/CPU hotplug
-+PSCI CPU Suspend
-+PSCI CPU Suspend in OSI mode
-+PSCI STAT/for valid composite state CPU suspend
-+FF-A Setup and Discovery/FF-A RXTX remap unmapped region success
-+FF-A Memory Sharing/Normal World VM retrieve request into SPMC
-+Boot requirement tests
-+CPU extensions/AMUv1 suspend/resume
-+CPU extensions/Use trace buffer control Registers
-- 
-2.43.0
-
@@ -0,0 +1,64 @@
+From b79d3cf319cc5698311ef83247110c93d3c2de2c Mon Sep 17 00:00:00 2001
+Message-Id: <b79d3cf319cc5698311ef83247110c93d3c2de2c.1695834344.git.diego.sueiro@arm.com>
+From: Diego Sueiro <diego.sueiro@arm.com>
+Date: Wed, 27 Sep 2023 18:05:26 +0100
+Subject: [PATCH] fdts/fvp-base: Add stdout-path and virtio net and rng nodes
+
+Upstream-Status: Pending
+Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
+---
+ fdts/fvp-base-psci-common.dtsi |  8 ++++++--
+ fdts/rtsm_ve-motherboard.dtsi  | 12 ++++++++++++
+ 2 files changed, 18 insertions(+), 2 deletions(-)
+
+diff --git a/fdts/fvp-base-psci-common.dtsi b/fdts/fvp-base-psci-common.dtsi
+index 79cf37d3b0..b1ba5ce703 100644
+--- a/fdts/fvp-base-psci-common.dtsi
+++ b/fdts/fvp-base-psci-common.dtsi
+@@ -30,7 +30,9 @@
+ #if (ENABLE_RME == 1)
+ 	chosen { bootargs = "console=ttyAMA0 earlycon=pl011,0x1c090000 root=/dev/vda ip=on";};
+ #else
+-	chosen {};
+	chosen {
+		stdout-path = &v2m_serial0;
+	};
+ #endif
+ 
+ 	aliases {
+@@ -243,6 +245,8 @@
+ 				<0 0 39 &gic 0 GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+ 				<0 0 40 &gic 0 GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ 				<0 0 41 &gic 0 GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+-				<0 0 42 &gic 0 GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+				<0 0 42 &gic 0 GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 44 &gic 0 GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 46 &gic 0 GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+ 	};
+ };
+diff --git a/fdts/rtsm_ve-motherboard.dtsi b/fdts/rtsm_ve-motherboard.dtsi
+index 0a824b349a..21a083a51a 100644
+--- a/fdts/rtsm_ve-motherboard.dtsi
+++ b/fdts/rtsm_ve-motherboard.dtsi
+@@ -230,6 +230,18 @@
+ 					interrupts = <42>;
+ 				};
+ 
+				virtio@150000 {
+					compatible = "virtio,mmio";
+					reg = <0x150000 0x200>;
+					interrupts = <44>;
+				};
+
+				virtio@200000 {
+					compatible = "virtio,mmio";
+					reg = <0x200000 0x200>;
+					interrupts = <46>;
+				};
+
+ 				rtc@170000 {
+ 					compatible = "arm,pl031", "arm,primecell";
+ 					reg = <0x170000 0x1000>;
+-- 
+2.39.1
+
@@ -0,0 +1,42 @@
+From 2d305094f8f500362079e9e7637d46129bf980e4 Mon Sep 17 00:00:00 2001
+From: Adam Johnston <adam.johnston@arm.com>
+Date: Tue, 25 Jul 2023 16:05:51 +0000
+Subject: [PATCH] n1sdp: Reserve OP-TEE memory from NWd
+
+The physical memory which is used to run OP-TEE on the N1SDP is known
+to the secure world via TOS_FW_CONFIG, but it may not be known to the
+normal world.
+
+As a precaution, explicitly reserve this memory via NT_FW_CONFIG to
+prevent the normal world from using it. This is not required on most
+platforms as the Trusted OS is run from secure RAM.
+
+Upstream-Status: Pending (not yet submitted to upstream)
+Signed-off-by: Adam Johnston <adam.johnston@arm.com>
+Signed-off-by: Mariam Elshakfy <mariam.elshakfy@arm.com>
+---
+ plat/arm/board/n1sdp/fdts/n1sdp_nt_fw_config.dts | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+diff --git a/plat/arm/board/n1sdp/fdts/n1sdp_nt_fw_config.dts b/plat/arm/board/n1sdp/fdts/n1sdp_nt_fw_config.dts
+index da5e04ddb6..b7e2d4e86f 100644
+--- a/plat/arm/board/n1sdp/fdts/n1sdp_nt_fw_config.dts
+++ b/plat/arm/board/n1sdp/fdts/n1sdp_nt_fw_config.dts
+@@ -20,4 +20,16 @@
+ 		local-ddr-size = <0x0>;
+ 		remote-ddr-size = <0x0>;
+ 	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		optee@0xDE000000 {
+			compatible = "removed-dma-pool";
+			reg = <0x0 0xDE000000 0x0 0x02000000>;
+			no-map;
+		};
+	};
+ };
+\ No newline at end of file
@@ -0,0 +1,46 @@
+From cc0153b56d634aa80b740be5afed15bedb94a2c9 Mon Sep 17 00:00:00 2001
+From: Harsimran Singh Tungal <harsimransingh.tungal@arm.com>
+Date: Tue, 23 Jan 2024 14:19:39 +0000
+Subject: [PATCH] n1sdp patch tests to skip
+
+Upstream-Status: Pending
+Signed-off-by: Harsimran Singh Tungal <harsimransingh.tungal@arm.com>
+---
+ plat/arm/n1sdp/tests_to_skip.txt | 15 ++++++++++-----
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+diff --git a/plat/arm/n1sdp/tests_to_skip.txt b/plat/arm/n1sdp/tests_to_skip.txt
+index b6e87bf..1848408 100644
+--- a/plat/arm/n1sdp/tests_to_skip.txt
+++ b/plat/arm/n1sdp/tests_to_skip.txt
+@@ -11,7 +11,7 @@ SMMUv3 tests
+ PSCI CPU Suspend in OSI mode
+ 
+ # PSCI is enabled but not tested
+-PSCI STAT/Stats test cases after system suspend
+PSCI STAT
+ PSCI System Suspend Validation
+ 
+ # Disable FF-A Interrupt tests as TWDOG is not supported by TC platform
+@@ -25,9 +25,14 @@ FF-A Interrupt
+ # files in TFTF, since the port was done purely to test the spectre workaround
+ # performance impact. Once that was done no further work was done on the port.
+ 
+-Timer framework Validation/Target timer to a power down cpu
+-Timer framework Validation/Test scenario where multiple CPUs call same timeout
+-Timer framework Validation/Stress test the timer framework
+Timer framework Validation
+ PSCI Affinity Info/Affinity info level0 powerdown
+ PSCI CPU Suspend
+-PSCI STAT/for valid composite state CPU suspend
+Framework Validation/NVM serialisation
+Framework Validation/Events API
+Boot requirement tests
+CPU Hotplug
+ARM_ARCH_SVC/SMCCC_ARCH_WORKAROUND_1 test
+ARM_ARCH_SVC/SMCCC_ARCH_WORKAROUND_2 test
+ARM_ARCH_SVC/SMCCC_ARCH_WORKAROUND_3 test
+FF-A Power management
+-- 
+2.34.1
+
@@ -0,0 +1,30 @@
+From 15dab90c3cb8e7677c4f953c2269e8ee1afa01b0 Mon Oct 2 13:45:43 2023
+From: Mariam Elshakfy <mariam.elshakfy@arm.com>
+Date: Mon, 2 Oct 2023 13:45:43 +0000
+Subject: [PATCH] Modify BL32 Location to DDR4
+
+Since OP-TEE start address is changed to run
+from DDR4, this patch changes BL32 entrypoint
+to the correct one.
+
+Upstream-Status: Pending (not yet submitted to upstream)
+Signed-off-by: Mariam Elshakfy <mariam.elshakfy@arm.com>
+---
+ plat/arm/board/n1sdp/fdts/n1sdp_optee_spmc_manifest.dts | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/plat/arm/board/n1sdp/fdts/n1sdp_optee_spmc_manifest.dts b/plat/arm/board/n1sdp/fdts/n1sdp_optee_spmc_manifest.dts
+index ed870803c..797dfe3a4 100644
+--- a/plat/arm/board/n1sdp/fdts/n1sdp_optee_spmc_manifest.dts
+++ b/plat/arm/board/n1sdp/fdts/n1sdp_optee_spmc_manifest.dts
+@@ -22,8 +22,8 @@
+ 		maj_ver = <0x1>;
+ 		min_ver = <0x0>;
+ 		exec_state = <0x0>;
+-		load_address = <0x0 0x08000000>;
+-		entrypoint = <0x0 0x08000000>;
+		load_address = <0x0 0xDE000000>;
+		entrypoint = <0x0 0xDE000000>;
+ 		binary_size = <0x2000000>;
+ 	};
+ 
@@ -0,0 +1,28 @@
+From 9a1d11b9fbadf740c73aee6dca4fd0370b38e4a8 Tue Oct 3 13:49:13 2023
+From: Mariam Elshakfy <mariam.elshakfy@arm.com>
+Date: Tue, 3 Oct 2023 13:49:13 +0000
+Subject: [PATCH] Modify SPMC Base to DDR4
+
+Since OP-TEE start address is changed to run
+from DDR4, this patch changes SPMC base to 
+the correct one.
+
+Upstream-Status: Pending (not yet submitted to upstream)
+Signed-off-by: Mariam Elshakfy <mariam.elshakfy@arm.com>
+---
+ plat/arm/board/n1sdp/include/platform_def.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/arm/board/n1sdp/include/platform_def.h b/plat/arm/board/n1sdp/include/platform_def.h
+index b3799a7b2..b12c61b61 100644
+--- a/plat/arm/board/n1sdp/include/platform_def.h
+++ b/plat/arm/board/n1sdp/include/platform_def.h
+@@ -118,7 +118,7 @@
+ 
+ #define PLAT_ARM_MAX_BL31_SIZE		UL(0x40000)
+ 
+-#define PLAT_ARM_SPMC_BASE		U(0x08000000)
+#define PLAT_ARM_SPMC_BASE		U(0xDE000000)
+ #define PLAT_ARM_SPMC_SIZE		UL(0x02000000)  /* 32 MB */
+ 
+ 
@@ -0,0 +1,45 @@
+From 051c723a6463a579b05dcaa81f204516737a3645 Mon Sep 17 00:00:00 2001
+From: Ross Burton <ross.burton@arm.com>
+Date: Wed, 9 Aug 2023 15:56:03 -0400
+Subject: [PATCH] Binutils 2.39 now warns when a segment has RXW
+ permissions[1]:
+
+aarch64-none-elf-ld.bfd: warning: bl31.elf has a LOAD segment with RWX
+permissions
+
+However, TF-A passes --fatal-warnings to LD, so this is a build failure.
+
+There is a ticket filed upstream[2], so until that is resolved just
+remove --fatal-warnings.
+
+[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107
+[2] https://developer.trustedfirmware.org/T996
+
+Upstream-Status: Inappropriate
+Signed-off-by: Ross Burton <ross.burton@arm.com>
+---
+ Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 1ddb7b84417d..9eae30c923ec 100644
+--- a/Makefile
+++ b/Makefile
+@@ -425,7 +425,7 @@ TF_LDFLAGS		+=	$(TF_LDFLAGS_$(ARCH))
+ # LD = gcc (used when GCC LTO is enabled)
+ else ifneq ($(findstring gcc,$(notdir $(LD))),)
+ # Pass ld options with Wl or Xlinker switches
+-TF_LDFLAGS		+=	-Wl,--fatal-warnings -O1
+TF_LDFLAGS		+=	-O1
+ TF_LDFLAGS		+=	-Wl,--gc-sections
+ ifeq ($(ENABLE_LTO),1)
+ 	ifeq (${ARCH},aarch64)
+@@ -442,7 +442,7 @@ TF_LDFLAGS		+=	$(subst --,-Xlinker --,$(TF_LDFLAGS_$(ARCH)))
+ 
+ # LD = gcc-ld (ld) or llvm-ld (ld.lld) or other
+ else
+-TF_LDFLAGS		+=	--fatal-warnings -O1
+TF_LDFLAGS		+=	-O1
+ TF_LDFLAGS		+=	--gc-sections
+ # ld.lld doesn't recognize the errata flags,
+ # therefore don't add those in that case
@@ -0,0 +1,33 @@
+From 6635341615a5bcb36ce71479ee30dae1599081e2 Mon Sep 17 00:00:00 2001
+From: Anton Antonov <anrton.antonov@arm.com>
+Date: Wed, 9 Aug 2023 15:56:03 -0400
+Subject: [PATCH] Binutils 2.39 now warns when a segment has RXW
+ permissions[1]:
+
+aarch64-poky-linux-musl-ld: tftf.elf has a LOAD segment with RWX permissions
+
+There is a ticket filed upstream[2], so until that is resolved just
+disable the warning
+
+[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107
+[2] https://developer.trustedfirmware.org/T996
+
+Upstream-Status: Inappropriate
+Signed-off-by: Anton Antonov <anrton.antonov@arm.com>
+---
+ Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile b/Makefile
+index 286a47c7d454..3481187b62cf 100644
+--- a/Makefile
+++ b/Makefile
+@@ -246,7 +246,7 @@ TFTF_SOURCES		:= ${FRAMEWORK_SOURCES}	${TESTS_SOURCES} ${PLAT_SOURCES} ${LIBC_SR
+ TFTF_INCLUDES		+= ${PLAT_INCLUDES}
+ TFTF_CFLAGS		+= ${COMMON_CFLAGS}
+ TFTF_ASFLAGS		+= ${COMMON_ASFLAGS}
+-TFTF_LDFLAGS		+= ${COMMON_LDFLAGS}
+TFTF_LDFLAGS		+= ${COMMON_LDFLAGS} --no-warn-rwx-segments
+ TFTF_EXTRA_OBJS 	:=
+ 
+ ifneq (${BP_OPTION},none)
@@ -5,13 +5,13 @@
 DESCRIPTION = "fiptool - Trusted Firmware tool for packaging"
 LICENSE = "BSD-3-Clause"

-SRC_URI_TRUSTED_FIRMWARE_A ?= "git://review.trustedfirmware.org/TF-A/trusted-firmware-a;protocol=https"
+SRC_URI_TRUSTED_FIRMWARE_A ?= "git://git.trustedfirmware.org/TF-A/trusted-firmware-a.git;protocol=https"
 SRC_URI = "${SRC_URI_TRUSTED_FIRMWARE_A};destsuffix=fiptool-${PV};branch=${SRCBRANCH}"
-LIC_FILES_CHKSUM = "file://docs/license.rst;md5=1118e32884721c0be33267bd7ae11130"
+LIC_FILES_CHKSUM = "file://docs/license.rst;md5=b2c740efedc159745b9b31f88ff03dde"

-# Use fiptool from  TF-A v2.13.0
-SRCREV = "c17351450c8a513ca3f30f936e26a71db693a145"
-SRCBRANCH = "master"
+# Use fiptool from TF-A v2.8.6
+SRCREV = "ff0bd5f9bb2ba2f31fb9cec96df917747af9e92d"
+SRCBRANCH = "lts-v2.8"

 DEPENDS += "openssl-native"

@@ -22,7 +22,7 @@ EXTRA_OEMAKE = "V=1 HOSTCC='${BUILD_CC}' OPENSSL_DIR=${STAGING_DIR_NATIVE}/${pre
 do_compile () {
    # This is still needed to have the native fiptool executing properly by
    # setting the RPATH
-    sed -i '/^LDOPTS/ s,$, \$\{BUILD_LDFLAGS},' ${S}/tools/fiptool/Makefile
+    sed -i '/^LDLIBS/ s,$, \$\{BUILD_LDFLAGS},' ${S}/tools/fiptool/Makefile
    sed -i '/^INCLUDE_PATHS/ s,$, \$\{BUILD_CFLAGS},' ${S}/tools/fiptool/Makefile

    oe_runmake fiptool
@@ -1,20 +1,16 @@
 # Machine specific TFAs

+FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
+
 COMPATIBLE_MACHINE:corstone1000 = "corstone1000"
 EXTRA_OEMAKE:append:corstone1000 = " DEBUG=0"
 EXTRA_OEMAKE:append:corstone1000 = " LOG_LEVEL=30"
-
-# Add Cortex-A320 specific configurations
-EXTRA_OEMAKE:append:cortexa320 = " \
-        CORSTONE1000_CORTEX_A320=1 \
-        "
 TFTF_MODE:corstone1000 = "release"

-FILESEXTRAPATHS:prepend:corstone1000 := "${THISDIR}/files/corstone1000/tf-a-tests:"
-SRC_URI:append:corstone1000 = " \
-        file://0001-fix-exclude-Boot-requirement-tests-for-Corstone-1000.patch \
-        "
-
-SRC_URI:append:corstone1000 = " \
-        file://0002-plat-corstone1000-Add-Cortex-A320-support.patch \
-        "
+COMPATIBLE_MACHINE:n1sdp = "n1sdp"
+EXTRA_OEMAKE:append:n1sdp = " DEBUG=1"
+EXTRA_OEMAKE:append:n1sdp = " LOG_LEVEL=50"
+TFTF_MODE:n1sdp = "debug"
+SRC_URI:append:n1sdp = " \
+			file://0001-n1sdp-tftf-tests-to-skip.patch \
+			"
--- a/Show More
+++ b/Show More
				`@@ -1 +0,0 @@`
				`basic-mmio-gpio: Failed to locate of_node [id: -2]`