arm-bsp/trusted-services: corstone1000: Align PSA crypto structs with TF-M

The TF-M was upgraded to v2.1.1 for the Corstone-1000. The TS had to be aligned with it, to keep the Secure Enclave Proxy Secure Partition compatible with TF-M. Signed-off-by: Ali Can Ozaslan <ali.oezaslan@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>
CI: use walnascar branches
2026-07-18 16:37:08 +00:00 · 2025-05-07 14:00:17 -04:00 · 2025-04-15 16:46:23 +01:00 · 2025-04-11 09:37:38 -04:00 · 2025-04-11 09:37:38 -04:00 · 2025-04-11 09:37:38 -04:00
589 changed files with 15022 additions and 14345 deletions
@@ -0,0 +1,2 @@
+[b4]
+	send-series-to = meta-arm@lists.yoctoproject.org
@@ -1,14 +1,26 @@
-image: ${MIRROR_GHCR}/siemens/kas/kas:4.0
+image: ${MIRROR_GHCR}/siemens/kas/kas:4.4

 variables:
-  CPU_REQUEST: ""
-  DEFAULT_TAG: ""
-  CACHE_DIR: $CI_BUILDS_DIR/persist
-  MIRROR_GHCR: ghcr.io
-  # These are needed as the k8s executor doesn't respect the container entrypoint
-  # by default
+  # These are needed as the k8s executor doesn't respect the container
+  # entrypoint by default
  FF_KUBERNETES_HONOR_ENTRYPOINT: 1
  FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY: 0
+  # The default value for KUBERNETES_CPU_REQUEST
+  CPU_REQUEST: ""
+  # The default machine tag for the build jobs
+  DEFAULT_TAG: ""
+  # The machine tag for the ACS test jobs
+  ACS_TAG: "$DEFAULT_TAG"
+  # The directory to use as the persistent cache (the root for DL_DIR, SSTATE_DIR, etc)
+  CACHE_DIR: $CI_BUILDS_DIR/persist
+  # The container mirror to use
+  MIRROR_GHCR: ghcr.io
+  # Whether to run the SystemReady ACS tests
+  ACS_TEST: 0
+  # The list of extra Kas fragments to be used when building
+  EXTRA_KAS_FILES: ""
+  # The NVD API key to use when fetching CVEs
+  NVDCVE_API_KEY: ""

 stages:
  - prep
@@ -21,28 +33,24 @@ stages:
  stage: build
  interruptible: true
  variables:
+    KUBERNETES_CPU_REQUEST: $CPU_REQUEST
    KAS_WORK_DIR: $CI_PROJECT_DIR/work
-    KAS_REPO_REF_DIR: $CACHE_DIR/repos
+    KAS_BUILD_DIR: $KAS_WORK_DIR/build
+    # Set this in the environment to enable local repository caches
+    KAS_REPO_REF_DIR: ""
    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: $CI_PROJECT_DIR/work/build/tmp/deploy/images
-    TOOLCHAIN_LINK_DIR: $CI_PROJECT_DIR/work/build/toolchains
+    IMAGE_DIR: $KAS_BUILD_DIR/tmp/deploy/images
+    TOOLCHAIN_LINK_DIR: $KAS_BUILD_DIR/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"
@@ -59,16 +67,21 @@ stages:
    # Catch all for everything else
    - if: '$KERNEL != "linux-yocto-dev"'
  script:
-    - KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME"):lockfile.yml
+    - KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME" $EXTRA_KAS_FILES):lockfile.yml
+    - echo KASFILES=$KASFILES
    - kas dump --update --force-checkout --resolve-refs --resolve-env $KASFILES
    - kas build $KASFILES
-    - ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
+    - ./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"
+
  artifacts:
    name: "logs"
    when: always
    paths:
-      - $CI_PROJECT_DIR/work/build/tmp/work*/**/temp/log.do_*.*
-      - $CI_PROJECT_DIR/work/build/tmp/work*/**/testimage/*
+      - $KAS_BUILD_DIR/tmp*/work*/**/temp/log.do_*.*
+      - $KAS_BUILD_DIR/tmp*/work*/**/testimage/*
+    reports:
+      junit: $KAS_BUILD_DIR/tmp/log/oeqa/junit.xml

 #
 # Prep stage, update repositories once.
@@ -81,7 +94,18 @@ update-repos:
    exit_codes: 128
  script:
    - |
-      flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos
+      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
+
      # 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
@@ -89,153 +113,39 @@ 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
-#  DISTRO: [poky, poky-tiny]
+# Available options for building are (VIRT _must_ be last for ssh override)
+#  DISTRO: [poky, poky-altcfg, poky-tiny]
 #  KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
-#  TOOLCHAINS: [gcc, clang, external-gccarm]
+#  TOOLCHAINS: [gcc, clang]
 #  TCLIBC: [glibc, musl]
 #  FIRMWARE: [u-boot, edk2]
 #  TS: [none, trusted-services]
-#  VIRT: [none, xen]
 #  TESTING: testimage
+#  SECUREDEBUG: [none, secure-debug]
+#  VIRT: [none, xen]

-corstone1000-fvp:
+arm-systemready-ir-acs:
  extends: .build
+  timeout: 12h
  parallel:
    matrix:
-      - TESTING: [testimage, tftf]
-
-corstone1000-mps3:
-  extends: .build
-  parallel:
-    matrix:
-      - TESTING: [none, tftf]
-
-
-fvp-base:
-  extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-      - FIRMWARE: edk2
-
-fvps:
-  extends: .build
-
-generic-arm64:
-  extends: .build
-
-juno:
-  extends: .build
-  parallel:
-    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        FIRMWARE: [u-boot, edk2]
-
-musca-b1:
-  extends: .build
-
-musca-s1:
-  extends: .build
-
-n1sdp:
-  extends: .build
-  parallel:
-    matrix:
-      - TESTING: [none, n1sdp-ts, n1sdp-optee, tftf]
-
-qemu-generic-arm64:
-  extends: .build
-  parallel:
-    matrix:
-      - KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
-        TOOLCHAINS: [gcc, clang]
-        TESTING: testimage
-
-qemuarm64-secureboot:
-  extends: .build
-  parallel:
-    matrix:
-      - KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
-        TOOLCHAINS: [gcc, clang]
-        TCLIBC: [glibc, musl]
-        TS: [none, qemuarm64-secureboot-ts]
-        TESTING: testimage
-
-qemuarm64:
-  extends: .build
-  parallel:
-    matrix:
-      - DISTRO: poky
-        KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
-        TOOLCHAINS: [gcc, clang]
-        FIRMWARE: [u-boot, edk2]
-        TESTING: testimage
-      - DISTRO: poky-tiny
-        TESTING: testimage
-      - VIRT: xen
-
-qemuarm-secureboot:
-  extends: .build
-  parallel:
-    matrix:
-      - KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
-        TOOLCHAINS: [gcc, clang]
-        TCLIBC: [glibc, musl]
-        TESTING: testimage
-      - TOOLCHAINS: external-gccarm
-        TESTING: testimage
-
-qemuarm:
-  extends: .build
-  parallel:
-    matrix:
-      - DISTRO: poky
-        KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
-        TOOLCHAINS: [gcc, clang]
-        FIRMWARE: [u-boot, edk2]
-        TESTING: testimage
-      - DISTRO: poky-tiny
-        TESTING: testimage
-      - VIRT: xen
-
-qemuarmv5:
-  extends: .build
-  parallel:
-    matrix:
-      - DISTRO: poky
-        KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
-        TESTING: testimage
-      - DISTRO: poky-tiny
-        TESTING: testimage
-
-sgi575:
-  extends: .build
-
-tc1:
-  extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
+      # 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:
-    - x86_64
-
-toolchains:
-  extends: .build
-
-selftest:
-  extends: .setup
-  script:
-    - KASFILES=./ci/qemuarm64.yml:./ci/selftest.yml:lockfile.yml
-    - kas shell --update --force-checkout $KASFILES -c 'oe-selftest --num-processes 2 --select-tag meta-arm --run-all-tests'
+    - ${ACS_TAG}

 # Validate layers are Yocto Project Compatible
 check-layers:
@@ -247,35 +157,24 @@ check-layers:
    matrix:
      - LAYER: [meta-arm, meta-arm-bsp, meta-arm-toolchain]

-pending-updates:
-  extends: .setup
-  artifacts:
-    paths:
-      - update-report
-  script:
-    - rm -fr update-report
-    # 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
+corstone1000-fvp:
+  extends: .build
+  parallel:
+    matrix:
+      - FIRMWARE: corstone1000-firmware-only
+        TESTING: [testimage, tftf]
+      - FIRMWARE: none
+        TESTING: testimage
+      - SYSTEMREADY_FIRMWARE: arm-systemready-firmware

-# What percentage of machines in the layer do we build
-machine-coverage:
-  extends: .setup
-  script:
-    - ./ci/check-machine-coverage
-  coverage: '/Coverage: \d+/'
-
-metrics:
-  extends: .setup
-  artifacts:
-    reports:
-      metrics: metrics.txt
-  script:
-    - kas shell --update --force-checkout ci/base.yml --command \
-      "$CI_PROJECT_DIR/ci/patchreview $CI_PROJECT_DIR/meta-* --verbose --metrics $CI_PROJECT_DIR/metrics.txt"
+corstone1000-mps3:
+  extends: .build
+  parallel:
+    matrix:
+      - FIRMWARE: corstone1000-firmware-only
+        TESTING: [none, tftf]
+      - FIRMWARE: none
+        SECUREDEBUG: [none, secure-debug]

 documentation:
  extends: .setup
@@ -299,3 +198,164 @@ documentation:
  artifacts:
    paths:
      - build-docs/
+
+fvp-base:
+  extends: .build
+  parallel:
+    matrix:
+      - TS: [none, fvp-base-ts]
+        TESTING: testimage
+      - FIRMWARE: [u-boot, edk2]
+        TESTING: testimage
+      - SYSTEMREADY_FIRMWARE: arm-systemready-firmware
+
+fvps:
+  extends: .build
+
+genericarm64:
+  extends: .build
+  parallel:
+    matrix:
+      - TOOLCHAINS: [gcc, clang]
+        TESTING: testimage
+      - KERNEL: linux-yocto-dev
+        TESTING: testimage
+
+juno:
+  extends: .build
+  parallel:
+    matrix:
+      - TOOLCHAINS: [gcc, clang]
+        FIRMWARE: [u-boot, edk2]
+
+# What percentage of machines in the layer do we build
+machine-coverage:
+  extends: .setup
+  script:
+    - ./ci/check-machine-coverage
+  coverage: '/Coverage: \d+/'
+
+metrics:
+  extends: .setup
+  artifacts:
+    reports:
+      metrics: metrics.txt
+  script:
+    - kas shell --update --force-checkout ci/base.yml --command \
+      "$CI_PROJECT_DIR/ci/patchreview $CI_PROJECT_DIR/meta-* --verbose --metrics $CI_PROJECT_DIR/metrics.txt"
+
+musca-b1:
+  extends: .build
+
+musca-s1:
+  extends: .build
+
+pending-updates:
+  extends: .setup
+  artifacts:
+    paths:
+      - update-report
+  script:
+    - rm -fr update-report
+    # 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)"
+
+qemuarm64-secureboot:
+  extends: .build
+  parallel:
+    matrix:
+      - KERNEL: [linux-yocto, linux-yocto-rt]
+        TOOLCHAINS: [gcc, clang]
+        TCLIBC: [glibc, musl]
+        TS: [none, qemuarm64-secureboot-ts]
+        TESTING: testimage
+      - TOOLCHAINS: [gcc, clang]
+        TS: [none, qemuarm64-secureboot-ts]
+        UEFISB: [none, uefi-secureboot]
+        TESTING: testimage
+      - KERNEL: linux-yocto-dev
+        TESTING: testimage
+
+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:
+      - KERNEL: [linux-yocto, linux-yocto-rt]
+        TOOLCHAINS: [gcc, clang]
+        TCLIBC: [glibc, musl]
+        TESTING: testimage
+      - DISTRO: [poky, poky-altcfg]
+        TESTING: testimage
+      - KERNEL: linux-yocto-dev
+        TESTING: testimage
+
+qemuarm:
+  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
+
+qemuarmv5:
+  extends: .build
+  parallel:
+    matrix:
+      - DISTRO: poky
+        KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
+        TESTING: testimage
+      - DISTRO: poky-tiny
+        TESTING: testimage
+
+sbsa-ref:
+  extends: .build
+  parallel:
+    matrix:
+      - KERNEL: [linux-yocto, linux-yocto-rt]
+        TOOLCHAINS: [gcc, clang]
+        TESTING: testimage
+      - DISTRO: poky-altcfg
+        TESTING: testimage
+      - KERNEL: linux-yocto-dev
+        TESTING: testimage
+
+selftest:
+  extends: .setup
+  script:
+    - KASFILES=./ci/qemuarm64.yml:./ci/selftest.yml:lockfile.yml
+    - kas shell --update --force-checkout $KASFILES -c 'oe-selftest --num-processes 2 --select-tag meta-arm --run-all-tests'
+
+sgi575:
+  extends: .build
+  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, N1SDP, and Juno.
+  This layer contains machines for Arm reference platforms, for example FVP Base, Corstone1000, and Juno.

 * meta-arm-toolchain

@@ -19,15 +19,26 @@ Other Directories

 * ci

-  This directory contains gitlab continuous integration configuration files (KAS yaml files) as well as scripts needed for this
+  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.

 * 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>.
+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

 Contributing
 ------------
@@ -35,25 +46,51 @@ 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-bsp/trusted-firmware-a: decrease frobbing level
+>  arm-toolchain/gcc: enable foobar v2

-  arm-toolchain/gcc: enable foobar v2
+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
+
+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>.

 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>
@@ -0,0 +1,46 @@
+# Reporting vulnerabilities
+
+Arm takes security issues seriously and welcomes feedback from researchers and
+the security community in order to improve the security of its products and
+services. We operate a coordinated disclosure policy for disclosing
+vulnerabilities and other security issues.
+
+Security issues can be complex and one single timescale doesn't fit all
+circumstances. We will make best endeavours to inform you when we expect
+security notifications and fixes to be available and facilitate coordinated
+disclosure when notifications and patches/mitigations are available.
+
+
+## How to Report a Potential Vulnerability?
+
+If you would like to report a public issue (for example, one with a released CVE
+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
+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.
+
+
+## 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
+branches.
+
+The [Release page](https://wiki.yoctoproject.org/wiki/Releases) 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.
@@ -0,0 +1,6 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 11
+  includes:
+    - kas/arm-systemready-firmware.yml
@@ -0,0 +1,19 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 11
+  includes:
+    - kas/arm-systemready-ir-acs.yml
+
+env:
+  ACS_TEST: "0"
+
+local_conf_header:
+  testimage: |
+    TESTIMAGE_AUTO = "${ACS_TEST}"
+
+target:
+  - arm-systemready-ir-acs
+  - arm-systemready-linux-distros-debian
+  - arm-systemready-linux-distros-opensuse
+  - arm-systemready-linux-distros-fedora
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -5,7 +7,7 @@ distro: poky

 defaults:
  repos:
-    branch: nanbield
+    branch: walnascar

 repos:
  meta-arm:
@@ -15,7 +17,7 @@ repos:
      meta-arm-toolchain:

  poky:
-    url: https://git.yoctoproject.org/git/poky
+    url: https://git.yoctoproject.org/poky
    layers:
      meta:
      meta-poky:
@@ -27,12 +29,12 @@ 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"
-    DISTRO_FEATURES:remove = "ptest"
  extrapackages: |
    CORE_IMAGE_EXTRA_INSTALL += "perf opencsd"
    CORE_IMAGE_EXTRA_INSTALL:append:aarch64 = " gator-daemon"
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -8,12 +10,3 @@ repos:
 local_conf_header:
  toolchain: |
    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"
@@ -1,15 +1,13 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
    - ci/base.yml
    - ci/meta-openembedded.yml
-    - ci/poky-tiny.yml
    - ci/meta-secure-core.yml
-
-local_conf_header:
-    extrapackages: |
-    # Intentionally blank to prevent perf from being added to the image in base.yml
+    - kas/corstone1000-image-configuration.yml

 target:
-  - corstone1000-image
+  - core-image-minimal
  - perf
@@ -0,0 +1,10 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+  includes:
+    - kas/corstone1000-firmware-only.yml
+
+target:
+  - corstone1000-flash-firmware-image
+  - perf
@@ -1,12 +1,9 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
    - ci/corstone1000-common.yml
    - ci/fvp.yml

-local_conf_header:
-    fvp-config: |
-        # Remove Dropbear SSH as it will not fit into the corstone1000 image.
-        IMAGE_FEATURES:remove = " ssh-server-dropbear"
-
 machine: corstone1000-fvp
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -0,0 +1,21 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+
+local_conf_header:
+  cve: |
+    INHERIT += "cve-check"
+
+    # Allow the runner environment to provide an API key
+    NVDCVE_API_KEY = "${@d.getVar('BB_ORIGENV').getVar('NVDCVE_API_KEY') or ''}"
+
+    # Just show the warnings for our layers
+    CVE_CHECK_SHOW_WARNINGS = "0"
+    CVE_CHECK_SHOW_WARNINGS:layer-arm-toolchain = "1"
+    CVE_CHECK_SHOW_WARNINGS:layer-meta-arm = "1"
+    CVE_CHECK_SHOW_WARNINGS:layer-meta-arm-bsp = "1"
+    CVE_CHECK_SHOW_WARNINGS:layer-meta-arm-systemready = "1"
+
+    # Ignore the kernel, we sometime carry kernels in meta-arm
+    CVE_CHECK_SHOW_WARNINGS:pn-linux-yocto = "0"
@@ -1,7 +1,9 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

 # Add universally helpful features when testing boards
 local_conf_header:
-  debug: |
-    EXTRA_IMAGE_FEATURES:append = " debug-tweaks"
+  rootlogin: |
+    EXTRA_IMAGE_FEATURES:append = " allow-empty-password empty-root-password allow-root-login"
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -13,5 +15,3 @@ local_conf_header:

    QB_DEFAULT_BIOS = "QEMU_EFI.fd"
    WKS_FILE ?= "efi-disk.wks.in"
-  failing_tests: |
-    TEST_SUITES:remove = "xorg"
@@ -1,11 +0,0 @@
-header:
-  version: 14
-
-local_conf_header:
-  cc: |
-    SKIP_RECIPE[gcc-cross-arm] = "Using external toolchain"
-    TCMODE = "external-arm"
-    EXTERNAL_TOOLCHAIN = "${TOPDIR}/toolchains/${TARGET_ARCH}"
-    # Temporary workaround for a number binaries in the toolchains that are using 32bit timer API
-    # This must be done here instead of the recipe because of all the libraries in the toolchain have the issue
-    INSANE_SKIP:append = " 32bit-time"
@@ -0,0 +1,34 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+  includes:
+    - ci/fvp-base.yml
+    - ci/meta-openembedded.yml
+    - ci/testimage.yml
+
+local_conf_header:
+  trusted_services: |
+    # Enable the needed test suites
+    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"
+    # 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"
+    # Enable and configure semihosting
+    FVP_CONFIG[cluster0.cpu0.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
+    FVP_CONFIG[cluster0.cpu1.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
+    FVP_CONFIG[cluster0.cpu2.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
+    FVP_CONFIG[cluster0.cpu3.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
+    FVP_CONFIG[cluster1.cpu0.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
+    FVP_CONFIG[cluster1.cpu1.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
+    FVP_CONFIG[cluster1.cpu2.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
+    FVP_CONFIG[cluster1.cpu3.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
+    FVP_CONFIG[semihosting-enable] = "True"
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -5,3 +7,7 @@ header:
    - ci/fvp.yml

 machine: fvp-base
+
+target:
+  - core-image-full-cmdline
+  - boot-wrapper-aarch64
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -5,8 +7,3 @@ local_conf_header:
  testimagefvp: |
    LICENSE_FLAGS_ACCEPTED += "Arm-FVP-EULA"
    IMAGE_CLASSES += "fvpboot"
-  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"
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 # Simple target to build the FVPs that are publically available

 header:
@@ -17,9 +19,13 @@ 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-n1-edge
+  - nativesdk-fvp-rd1-ae
+  - nativesdk-fvp-v3-r1
+  # These are x86 only... :(
  - nativesdk-fvp-sgi575
-  - nativesdk-fvp-tc1
+  - nativesdk-fvp-tc3
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -1,6 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-
-machine: generic-arm64
@@ -0,0 +1,21 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+  includes:
+    - ci/base.yml
+
+repos:
+  poky:
+    layers:
+      meta-yocto-bsp:
+
+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
@@ -1,51 +0,0 @@
-#!/bin/bash
-set -u -e
-
-BASENAME=arm-gnu-toolchain
-VER=${VER:-12.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,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -3,17 +3,28 @@
 # This script is expecting an input of machine name, optionally followed by a
 # colon and a list of one or more parameters separated by commas between
 # brackets.  For example, the following are acceptable:
-# corstone1000-mps3
-# fvp-base: [testimage]
-# qemuarm64-secureboot: [clang, glibc, testimage]
+#   corstone1000-mps3
+#   fvp-base: [testimage]
+#   qemuarm64-secureboot: [clang, glibc, testimage]
+# This argument should be quoted to avoid expansion and to be handled
+# as a single value.
+#
+# Any further arguments will be handled as further yml file basenames.
 #
 # Turn this list into a series of yml files separated by colons to pass to kas

 set -e -u

-FILES="ci/$(echo $1 | cut -d ':' -f 1).yml"
+# First, parse the GitLab CI job name (CI_JOB_NAME via $1) and accumulate a list
+# of Kas files.
+JOBNAME="$1"
+shift

-for i in $(echo $1 | cut -s -d ':' -f 2 | sed 's/[][,]//g'); do
+# The base name of the job
+FILES="ci/$(echo $JOBNAME | cut -d ':' -f 1).yml"
+
+# The list of matrix variations
+for i in $(echo $JOBNAME | cut -s -d ':' -f 2 | sed 's/[][,]//g'); do
 	# Given that there are no yml files for gcc or glibc, as those are the
 	# defaults, we can simply ignore those parameters.  They are necessary
 	# to pass in so that matrix can correctly setup all of the permutations
@@ -24,4 +35,9 @@ for i in $(echo $1 | cut -s -d ':' -f 2 | sed 's/[][,]//g'); do
 	FILES+=":ci/$i.yml"
 done

+# Now pick up any further names
+for i in $*; do
+	FILES+=":ci/$i.yml"
+done
+
 echo $FILES
@@ -0,0 +1,15 @@
+#! /bin/bash
+
+# $ ci/junit.sh <build directory>
+#
+# If there is a OEQA test report in JSON format present in the build directory,
+# transform it to JUnit XML using resulttool.
+
+set -e -u
+
+BUILDDIR=$1
+JSON=$BUILDDIR/tmp/log/oeqa/testresults.json
+
+if test -f $JSON; then
+    resulttool junit $JSON
+fi
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -5,7 +7,7 @@ repos:
  meta-secure-core:
    url: https://github.com/Wind-River/meta-secure-core.git
    layers:
-      meta:
+      meta-secure-core-common:
      meta-signing-key:
      meta-efi-secure-boot:
      
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -5,4 +7,5 @@ header:

 repos:
  meta-virtualization:
-    url: git://git.yoctoproject.org/meta-virtualization
+    url: https://git.yoctoproject.org/meta-virtualization
+    branch: master
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -1,12 +0,0 @@
-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"
@@ -1,14 +0,0 @@
-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"
@@ -1,10 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-
-machine: n1sdp
-
-local_conf_header:
-  unsupported_trusted_services: |
-    MACHINE_FEATURES:remove = "ts-smm-gateway"
@@ -0,0 +1,4 @@
+header:
+  version: 14
+
+distro: poky-altcfg
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -1,14 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/generic-arm64.yml
-
-local_conf_header:
-  failing_tests: |
-    DEFAULT_TEST_SUITES:remove = "parselogs"
-
-machine: qemu-generic-arm64
-
-target:
-  - core-image-sato
-  - sbsa-acs
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -7,6 +9,8 @@ machine: qemuarm-secureboot

 target:
  - core-image-base
-  - optee-examples
-  - optee-test
-  - optee-os-tadevkit
+
+local_conf_header:
+  optee: |
+    IMAGE_INSTALL:append = " optee-test optee-client optee-os-ta"
+    TEST_SUITES:append = " optee ftpm"
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -6,8 +8,9 @@ header:
 local_conf_header:
  trusted_services: |
    TEST_SUITES:append = " trusted_services"
-    # 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 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 demo/test tools into image
    IMAGE_INSTALL:append = " packagegroup-ts-tests"
    # Include TS PSA Arch tests into image
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -7,6 +9,8 @@ machine: qemuarm64-secureboot

 target:
  - core-image-base
-  - optee-examples
-  - optee-test
-  - optee-os-tadevkit
+
+local_conf_header:
+  optee: |
+    IMAGE_INSTALL:append = " optee-test optee-client optee-os-ta"
+    TEST_SUITES:append = " optee ftpm"
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -0,0 +1,12 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+  includes:
+    - ci/base.yml
+
+machine: sbsa-ref
+
+target:
+  - core-image-sato
+  - sbsa-acs
@@ -0,0 +1,8 @@
+# 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"
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -1,6 +1,14 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
    - ci/base.yml
+    - ci/fvp.yml
+
+local_conf_header:
+  sshpregen: |
+    # Allow the use of the pregen keys as this is CI so safe
+    COMPATIBLE_MACHINE:pn-ssh-pregen-hostkeys:sgi575 = "sgi575"

 machine: sgi575
@@ -0,0 +1,11 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+
+local_conf_header:
+  sstate_mirror: |
+    BB_HASHSERVE_UPSTREAM = "wss://hashserv.yoctoproject.org/ws"
+    SSTATE_MIRRORS = "file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH"
+    BB_HASHSERVE = "auto"
+    BB_SIGNATURE_HANDLER = "OEEquivHash"
@@ -1,11 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-    - ci/fvp.yml
-    - ci/meta-openembedded.yml
-
-machine: tc1
-
-target:
-  - core-image-minimal
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -12,7 +14,7 @@ local_conf_header:
  slirp: |
    TEST_RUNQEMUPARAMS = "slirp"
  sshd: |
-    IMAGE_FEATURES:append = " ssh-server-dropbear"
+    IMAGE_FEATURES += "ssh-server-dropbear"
  sshkeys: |
    CORE_IMAGE_EXTRA_INSTALL += "ssh-pregen-hostkeys"
  universally_failing_tests: |
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14
  includes:
@@ -16,5 +18,3 @@ target:
  - nativesdk-gcc-aarch64-none-elf
  - gcc-arm-none-eabi
  - nativesdk-gcc-arm-none-eabi
-  - gcc-arm-none-eabi-11.2
-  - nativesdk-gcc-arm-none-eabi-11.2
@@ -1,3 +1,5 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 header:
  version: 14

@@ -0,0 +1,51 @@
+# 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"
@@ -20,9 +20,9 @@ def repo_shortname(url):
            .replace('*', '.'))

 repositories = (
-    "https://git.yoctoproject.org/git/poky",
+    "https://git.yoctoproject.org/poky",
    "https://git.openembedded.org/meta-openembedded",
-    "https://git.yoctoproject.org/git/meta-virtualization",
+    "https://git.yoctoproject.org/meta-virtualization",
    "https://github.com/kraj/meta-clang",
 )

@@ -44,7 +44,7 @@ if __name__ == "__main__":
        if repodir.exists():
            try:
                print("Updating %s..." % repo)
-                subprocess.run(["git", "-C", repodir, "-c", "gc.autoDetach=false", "fetch"], check=True)
+                subprocess.run(["git", "-C", repodir, "-c", "gc.autoDetach=false", "fetch", repo], check=True)
            except subprocess.CalledProcessError as e:
                print(e)
                failed = True
@@ -1,11 +1,16 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
 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
@@ -0,0 +1,67 @@
+# **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>
@@ -0,0 +1,105 @@
+# **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**
@@ -0,0 +1,43 @@
+# **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` 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` image class needs to be inherited.  If the machine does not do this explicitly it can be done in `local.conf`:

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

 The class will download the correct FVP and write a `.fvpconf` configuration file when an image is built.
@@ -18,17 +18,18 @@ features for each [Secure Partition][^2] you would like to include:
 | ----------------- | --------------- |
 | Attestation       | ts-attesation   |
 | Crypto            | ts-crypto       |
+| Firmware Update   | ts-fwu
 | Internal Storage  | ts-its          |
 | Protected Storage | ts-storage      |
 | se-proxy          | ts-se-proxy     |
 | smm-gateway       | ts-smm-gateway  |
-| spm-test[1-3]     | optee-spmc-test |
+| spm-test[1-4]     | optee-spmc-test |

 Other steps depend on your machine/platform definition:

 1. For communications between Secure and Normal Words Linux kernel option `CONFIG_ARM_FFA_TRANSPORT=y`
   is required. If your platform doesn't include it already you can add `arm-ffa` into MACHINE_FEATURES.
-   (Please see ` meta-arm/recipes-kernel/arm-ffa-tee`.)
+   (Please see ` meta-arm/recipes-kernel/arm-tstee`.)

   For running the `uefi-test` or the `xtest -t ffa_spmc` tests under Linux the `arm-ffa-user` drivel is required. This is
   enabled if the `ts-smm-gateway` and/or the `optee-spmc-test` machine features are enabled.
@@ -36,17 +37,19 @@ 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-n1sdp.inc` and `meta-arm-bsp/recipes-security/optee/optee-os-corstone1000-common.inc`
-   for N1SDP and Corstone1000 platforms accordingly.
+   and in `meta-arm-bsp/recipes-security/optee/optee-os-corstone1000-common.inc` for the Corstone1000 platform.

 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-n1sdp.inc` and
-   `meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-corstone1000.inc` for N1SDP and Corstone1000 platforms.
+   and in `meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-corstone1000.inc` for theCorstone1000 platform.
+
+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.
+

 ## Normal World applications

-Optionally for testing purposes you can add `packagegroup-ts-tests` into your image. It includes 
+Optionally for testing purposes you can add `packagegroup-ts-tests` into your image. It includes
 [Trusted Services test and demo tools][^3] and [xtest][^4] configured to include the `ffa_spmc` tests.

 ## OEQA Trusted Services tests
@@ -62,4 +65,4 @@ See `ci/trusted-services.yml` for an example how to include them into an image.

 [^3]: https://trusted-services.readthedocs.io/en/integration/deployments/test-executables.html

-[^4]: https://optee.readthedocs.io/en/latest/building/gits/optee_test.html
+[^4]: https://optee.readthedocs.io/en/latest/building/gits/optee_test.html
@@ -8,10 +8,5 @@ env:
  # The full testimage run typically takes around 12-24h on fvp-base.
  TEST_OVERALL_TIMEOUT: "${@ 24*60*60}"

-local_conf_header:
-  systemready-ir-acs: |
-    IMAGE_CLASSES:append = " testimage"
-
-
 target:
  - arm-systemready-ir-acs
@@ -2,6 +2,7 @@ header:
  version: 13
  includes:
    - kas/arm-systemready-firmware.yml
+    - kas/arm-systemready-linux-distros-unattended-installation.yml

 target:
  - arm-systemready-linux-distros-debian
@@ -0,0 +1,8 @@
+header:
+  version: 16
+  includes:
+    - kas/arm-systemready-firmware.yml
+    - kas/arm-systemready-linux-distros-unattended-installation.yml
+
+target:
+  - arm-systemready-linux-distros-fedora
@@ -2,6 +2,7 @@ header:
  version: 13
  includes:
    - kas/arm-systemready-firmware.yml
+    - kas/arm-systemready-linux-distros-unattended-installation.yml

 target:
  - arm-systemready-linux-distros-opensuse
@@ -0,0 +1,11 @@
+header:
+  version: 16
+
+env:
+  DISTRO_UNATTENDED_INST_TESTS:
+  # The full testimage run typically takes around 12-24h on fvp-base.
+  TEST_OVERALL_TIMEOUT: "${@ 24*60*60}"
+  
+local_conf_header:
+  systemready-unattended-inst: |
+    TESTIMAGE_AUTO = "${@oe.utils.vartrue("DISTRO_UNATTENDED_INST_TESTS", "1", "", d)}"
@@ -1,14 +1,11 @@
 header:
-  version: 11
+  version: 14

-env:
-  DISPLAY: ""
-
-distro: poky-tiny
+distro: poky

 defaults:
  repos:
-    refspec: master
+    branch: master

 repos:
  meta-arm:
@@ -19,29 +16,32 @@ repos:

  poky:
    url: https://git.yoctoproject.org/git/poky
-    refspec: 31dd418207f6c95ef0aad589cd03cd2a4c9a8bf2
+    # commit: 5465094be9a61a1639e1dab6d2b4ebea2bee7440
    layers:
      meta:
      meta-poky:
-      meta-yocto-bsp:

  meta-openembedded:
    url: https://git.openembedded.org/meta-openembedded
-    refspec: 5a01ab461c9bcabcbb2298236602373948f8f073
+    # commit: 461d85a1831318747af5abe86da193bcde3fd9b4
    layers:
      meta-oe:
      meta-python:
+      meta-perl:

  meta-secure-core:
    url: https://github.com/wind-river/meta-secure-core.git
+    # commit: 59d7e90542947c342098863b9998693ac79352b0
    layers:
-      meta:
+      meta-secure-core-common:
      meta-signing-key:
      meta-efi-secure-boot:

 local_conf_header:
  base: |
    CONF_VERSION = "2"
+
+  setup: |
    PACKAGE_CLASSES = "package_ipk"
    BB_NUMBER_THREADS ?= "16"
    PARALLEL_MAKE ?= "-j16"
@@ -50,4 +50,4 @@ local_conf_header:
 machine: unset

 target:
-  - corstone1000-image
+  - corstone1000-flash-firmware-image
@@ -0,0 +1,6 @@
+header:
+  version: 14
+
+local_conf_header:
+  extsys: |
+    MACHINE_FEATURES += "corstone1000-extsys"
@@ -0,0 +1,23 @@
+---
+header:
+  version: 14
+
+local_conf_header:
+  firmwarebuild: |
+    BBMULTICONFIG:remove = "firmware"
+
+    # Need to ensure the rescue linux options are selected
+    OVERRIDES .= ":firmware"
+
+    # Need to ensure we build with a small libc
+    TCLIBC="musl"
+
+  mass-storage: |
+    # Ensure the Mass Storage device is absent
+    FVP_CONFIG[board.msd_mmc.p_mmc_file] = "invalid.dat"
+
+  test-configuration: |
+    TEST_SUITES = "_qemutiny ping"
+    # Remove Dropbear SSH as it will not fit into the corstone1000 image.
+    IMAGE_FEATURES:remove = "ssh-server-dropbear"
+    CORE_IMAGE_EXTRA_INSTALL:remove = "ssh-pregen-hostkeys"
@@ -0,0 +1,8 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
+
+header:
+  version: 14
+
+local_conf_header:
+  fvp-multicore: |
+    MACHINE_FEATURES += "corstone1000_fvp_smp"
@@ -1,16 +1,22 @@
 header:
-  version: 11
+  version: 14
  includes:
    - kas/corstone1000-base.yml
+    - kas/corstone1000-image-configuration.yml
+    - kas/corstone1000-firmware-only.yml
    - kas/fvp-eula.yml

-machine: corstone1000-fvp
+env:
+  DISPLAY:
+  WAYLAND_DISPLAY:
+  XAUTHORITY:

 local_conf_header:
-    fvp-config: |
-        # Remove Dropbear SSH as it will not fit into the corstone1000 image.
-        IMAGE_FEATURES:remove = " ssh-server-dropbear"
-        INHERIT += "fvpboot"
+  testimagefvp: |
+    IMAGE_CLASSES += "fvpboot"

-target:
-  - corstone1000-image
+  mass-storage: |
+    # Ensure the Mass Storage device is absent
+    FVP_CONFIG[board.msd_mmc.p_mmc_file] = "invalid.dat"
+
+machine: corstone1000-fvp
@@ -0,0 +1,49 @@
+header:
+  version: 14
+
+local_conf_header:
+  extrapackages: |
+    # Intentionally blank to prevent perf from being added to the image in base.yml
+
+  firmwarebuild: |
+    # Only needed as kas doesn't add it automatically unless you have 2 targets in seperate configs
+    BBMULTICONFIG ?= "firmware"
+
+  distrosetup: |
+    DISTRO_FEATURES = "usbhost ipv4"
+
+  initramfsetup: |
+    # Telling the build system which image is responsible of the generation of the initramfs rootfs
+    INITRAMFS_IMAGE_BUNDLE:firmware = "1"
+    INITRAMFS_IMAGE:firmware ?= "corstone1000-recovery-image"
+    IMAGE_FSTYPES:firmware:pn-corstone1000-recovery-image = "${INITRAMFS_FSTYPES}"
+    IMAGE_NAME_SUFFIX:firmware = ""
+
+    # enable mdev/busybox for init
+    INIT_MANAGER:firmware = "mdev-busybox"
+    VIRTUAL-RUNTIME_init_manager:firmware = "busybox"
+
+    # prevent the kernel image from being included in the intramfs rootfs
+    PACKAGE_EXCLUDE:firmware += "kernel-image-*"
+
+    # Disable openssl in kmod to shrink the initramfs size
+    PACKAGECONFIG:remove:firmware:pn-kmod = "openssl"
+
+  imageextras: |
+    # Don't include kernel binary in rootfs /boot path
+    RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""
+
+    # all optee packages
+    CORE_IMAGE_EXTRA_INSTALL += "optee-client"
+
+    # TS PSA API tests commands for crypto, its, ps and iat
+    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: |
+    CAPSULE_EXTENSION = "uefi.capsule"
+    CAPSULE_FW_VERSION = "6"
+    CAPSULE_NAME = "${MACHINE}-v${CAPSULE_FW_VERSION}"
@@ -1,6 +1,8 @@
 header:
-  version: 11
+  version: 14
  includes:
    - kas/corstone1000-base.yml
+    - kas/corstone1000-image-configuration.yml
+    - kas/corstone1000-firmware-only.yml

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

-LAYERSERIES_COMPAT_meta-arm-bsp = "nanbield"
+LAYERSERIES_COMPAT_meta-arm-bsp = "styhead walnascar"

 LAYERDEPENDS_meta-arm-bsp = "core meta-arm"
 # This won't be used by layerindex-fetch, but works everywhere else
@@ -24,3 +24,9 @@ BBFILES_DYNAMIC += " \
    meta-arm-systemready:${LAYERDIR}/dynamic-layers/meta-arm-systemready/*/*/*.bb \
    meta-arm-systemready:${LAYERDIR}/dynamic-layers/meta-arm-systemready/*/*/*.bbappend \
 "
+
+WARN_QA:append:layer-meta-arm-bsp = " patch-status"
+
+addpylib ${LAYERDIR}/lib oeqa
+
+IMAGE_ROOTFS_EXTRA_ARGS ?= ""
@@ -9,12 +9,19 @@ TFM_PLATFORM_IS_FVP = "TRUE"

 # testimage config
 TEST_TARGET = "OEFVPTarget"
-TEST_SUITES = "fvp_boot"
+TEST_TARGET_IP = "127.0.0.1:2222"
+DEFAULT_TEST_SUITES:append = " fvp_boot fvp_devices"

 # FVP Config
 FVP_PROVIDER ?= "fvp-corstone1000-native"
 FVP_EXE ?= "FVP_Corstone-1000"
-FVP_CONSOLE ?= "host_terminal_0"
+FVP_CONSOLES[default] = "host_terminal_0"
+FVP_CONSOLES[tf-a] = "host_terminal_1"
+FVP_CONSOLES[se] = "secenc_terminal"
+FVP_CONSOLES[extsys] = "extsys_terminal"
+
+#Disable Time Annotation
+FASTSIM_DISABLE_TA = "0"

 # FVP Parameters
 FVP_CONFIG[se.trustedBootROMloader.fname] ?= "bl1.bin"
@@ -32,7 +39,7 @@ FVP_CONFIG[se.nvm.update_raw_image] ?= "0"
 FVP_CONFIG[se.cryptocell.USER_OTP_FILTERING_DISABLE] ?= "1"

 # Boot image
-FVP_DATA ?= "board.flash0=${IMAGE_NAME}.wic@0x68000000"
+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"
@@ -46,13 +53,24 @@ FVP_TERMINALS[extsys0.extsys_terminal] ?= "Cortex M3"
 # MMC card configuration
 FVP_CONFIG[board.msd_mmc.card_type] ?= "SDHC"
 FVP_CONFIG[board.msd_mmc.p_fast_access] ?= "0"
-FVP_CONFIG[board.msd_mmc.diagnostics] ?= "2"
+FVP_CONFIG[board.msd_mmc.diagnostics] ?= "0"
 FVP_CONFIG[board.msd_mmc.p_max_block_count] ?= "0xFFFF"
 FVP_CONFIG[board.msd_config.pl180_fifo_depth] ?= "16"
+FVP_CONFIG[board.msd_mmc.support_unpadded_images] ?= "true"
+FVP_CONFIG[board.msd_mmc.p_mmc_file] ?= "${IMAGE_NAME}.wic"

 # MMC2 card configuration
 FVP_CONFIG[board.msd_mmc_2.card_type] ?= "SDHC"
 FVP_CONFIG[board.msd_mmc_2.p_fast_access] ?= "0"
-FVP_CONFIG[board.msd_mmc_2.diagnostics] ?= "2"
+FVP_CONFIG[board.msd_mmc_2.diagnostics] ?= "0"
 FVP_CONFIG[board.msd_mmc_2.p_max_block_count] ?= "0xFFFF"
-FVP_CONFIG[board.msd_config_2.pl180_fifo_depth] ?= "16"
+FVP_CONFIG[board.msd_config_2.pl180_fifo_depth] ?= "16"
+FVP_CONFIG[board.msd_mmc_2.support_unpadded_images] ?= "true"
+FVP_CONFIG[board.msd_mmc_2.p_mmc_file] ?= "corstone1000-esp-image-${MACHINE}.wic"
+
+# Virtio-Net configuration
+FVP_CONFIG[board.virtio_net.enabled] ?= "1"
+FVP_CONFIG[board.virtio_net.hostbridge.interfaceName] ?= "eth1"
+FVP_CONFIG[board.virtio_net.hostbridge.userNetworking] ?= "true"
+FVP_CONFIG[board.virtio_net.hostbridge.userNetPorts] ?= "5555=5555,8080=80,2222=22"
+FVP_CONFIG[board.virtio_net.transport] ?= "legacy"
@@ -4,24 +4,25 @@
 #@NAME: Armv8-A Base Platform FVP machine
 #@DESCRIPTION: Machine configuration for Armv8-A Base Platform FVP model

-require conf/machine/include/arm/arch-armv8a.inc
-
-TUNE_FEATURES = "aarch64"
+require conf/machine/include/arm/arch-armv8-5a.inc

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

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

 IMAGE_NAME_SUFFIX = ""
 IMAGE_FSTYPES += "wic"
 WKS_FILE ?= "efi-disk.wks.in"

 SERIAL_CONSOLES = "115200;ttyAMA0"
+# FIXME -  This is being upstreamed.  Remove once that has occurred.
+KERNEL_CONSOLE ?= "${@','.join(d.getVar('SERIAL_CONSOLES').split(' ')[0].split(';')[::-1]) or 'ttyS0'}"

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

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

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

 # As this is a virtual target that will not be used in the real world there is
 # no need for real SSH keys.
@@ -49,14 +50,19 @@ FVP_CONFIG[bp.virtio_net.hostbridge.userNetworking] ?= "1"
 FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] = "2222=22"
 FVP_CONFIG[bp.virtio_rng.enabled] ?= "1"
 FVP_CONFIG[cache_state_modelled] ?= "0"
+FVP_CONFIG[cluster0.check_memory_attributes] ?= "0"
+FVP_CONFIG[cluster1.check_memory_attributes] ?= "0"
+FVP_CONFIG[cluster0.stage12_tlb_size] ?= "1024"
+FVP_CONFIG[cluster1.stage12_tlb_size] ?= "1024"
 FVP_CONFIG[bp.secureflashloader.fname] ?= "bl1-fvp.bin"
 FVP_CONFIG[bp.flashloader0.fname] ?= "fip-fvp.bin"
 FVP_CONFIG[bp.virtioblockdevice.image_path] ?= "${IMAGE_NAME}.wic"
-# Set the baseline to ARMv8.4, as the default is 8.0.
-FVP_CONFIG[cluster0.has_arm_v8-4] = "1"
-FVP_CONFIG[cluster1.has_arm_v8-4] = "1"
+# Set the baseline to ARMv8.5, as the default is 8.0.
+FVP_CONFIG[cluster0.has_arm_v8-5] = "1"
+FVP_CONFIG[cluster1.has_arm_v8-5] = "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"
@@ -2,81 +2,68 @@ require conf/machine/include/arm/armv8a/tune-cortexa35.inc

 MACHINEOVERRIDES =. "corstone1000:"

+# TF-M
+PREFERRED_VERSION_trusted-firmware-m ?= "2.1.%"
+
 # TF-A
 TFA_PLATFORM = "corstone1000"
-EXTRA_IMAGEDEPENDS += "trusted-firmware-a"
-PREFERRED_VERSION_trusted-firmware-a ?= "2.9.%"
-PREFERRED_VERSION_tf-a-tests ?= "2.8.%"
+PREFERRED_VERSION_trusted-firmware-a ?= "2.11.%"
+PREFERRED_VERSION_tf-a-tests ?= "2.10.%"

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

-# TF-M
-EXTRA_IMAGEDEPENDS += "virtual/trusted-firmware-m"
+# optee
+PREFERRED_VERSION_optee-os ?= "4.4.%"
+PREFERRED_VERSION_optee-client ?= "4.4.%"

-# TF-M settings for signing host images
-TFA_BL2_RE_IMAGE_LOAD_ADDRESS = "0x62353000"
-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-RSA-3072_1.pem"
-RE_IMAGE_OFFSET = "0x1000"
+# Trusted Services
+TS_PLATFORM = "arm/corstone1000"
+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 ?= "2023.07%"
-EXTRA_IMAGEDEPENDS += "u-boot"
+MACHINE_FEATURES += "efi"
+EFI_PROVIDER ?= "grub-efi"

-UBOOT_CONFIG ??= "EFI"
-UBOOT_CONFIG[EFI] = "corstone1000_defconfig"
-UBOOT_ENTRYPOINT  = "0x80000000"
-UBOOT_LOADADDRESS = "0x80000000"
-UBOOT_BOOTARGS = "earlycon=pl011,0x1a510000 console=ttyAMA0 loglevel=9"
-UBOOT_ARCH = "arm"
-UBOOT_EXTLINUX = "0"
-
-#optee
-PREFERRED_VERSION_optee-os ?= "3.22%"
-PREFERRED_VERSION_optee-client ?= "3.22%"
-EXTRA_IMAGEDEPENDS += "optee-os"
-OPTEE_ARCH = "arm64"
-OPTEE_BINARY = "tee-pager_v2.bin"
-
-# Include smm-gateway and se-proxy SPs into optee-os binary
-MACHINE_FEATURES += "ts-smm-gateway ts-se-proxy"
-TS_PLATFORM = "arm/corstone1000"
-TS_SP_SE_PROXY_CONFIG = "corstone1000"
-
-# External System(Cortex-M3)
-EXTRA_IMAGEDEPENDS += "external-system"
+# Grub
+LINUX_KERNEL_ARGS ?= "earlycon=pl011,0x1a510000 console=ttyAMA0,115200"
+GRUB_LINUX_APPEND ?= "${LINUX_KERNEL_ARGS}"
+IMAGE_CMD:wic[vardeps] += "GRUB_LINUX_APPEND"

 # Linux kernel
-PREFERRED_PROVIDER_virtual/kernel:forcevariable = "linux-yocto"
-PREFERRED_VERSION_linux-yocto = "6.5%"
-KERNEL_IMAGETYPE = "Image.gz"
-
-INITRAMFS_IMAGE_BUNDLE ?= "1"
-
-#telling the build system which image is responsible of the generation of the initramfs rootfs
-INITRAMFS_IMAGE = "corstone1000-initramfs-image"
-IMAGE_NAME_SUFFIX = ""
-
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_VERSION_linux-yocto ?= "6.12.%"
+KERNEL_IMAGETYPE = "Image"
+KERNEL_IMAGETYPE:firmware = "Image.gz"
 # add FF-A support in the kernel
 MACHINE_FEATURES += "arm-ffa"
-
-# prevent the kernel image from being included in the intramfs rootfs
-PACKAGE_EXCLUDE = "kernel-image-*"
-
 # enable this feature for kernel debugging
 # MACHINE_FEATURES += "corstone1000_kernel_debug"

 # login terminal serial port settings
 SERIAL_CONSOLES ?= "115200;ttyAMA0"

+IMAGE_FSTYPES += "wic"
+# Need to clear the suffix so TESTIMAGE_AUTO works
+IMAGE_NAME_SUFFIX = ""
+WKS_FILE ?= "efi-disk-no-swap.wks.in"
+WKS_FILE:firmware ?= "corstone1000-flash-firmware.wks.in"
+
 # making sure EXTRA_IMAGEDEPENDS will be used while creating the image
 WKS_FILE_DEPENDS:append = " ${EXTRA_IMAGEDEPENDS}"

-WKS_FILE ?= "corstone1000-image.corstone1000.wks"
+# If not building under the firmware multiconf we need to build the actual firmware
+FIRMWARE_DEPLOYMENT ?= "firmware-deploy-image"
+FIRMWARE_DEPLOYMENT:firmware ?= ""
+EXTRA_IMAGEDEPENDS += "${FIRMWARE_DEPLOYMENT}"

-# Disable openssl in kmod to shink the initramfs size
-PACKAGECONFIG:remove:pn-kmod = "openssl"
+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-space ${@${IMAGE_ROOTFS_EXTRA_SPACE}}K"
@@ -1,36 +0,0 @@
-TUNE_FEATURES = "aarch64"
-
-require conf/machine/include/arm/arch-armv8a.inc
-
-MACHINEOVERRIDES =. "tc:"
-
-# Das U-boot
-UBOOT_MACHINE ?= "total_compute_defconfig"
-UBOOT_RD_LOADADDRESS = "0x88000000"
-UBOOT_RD_ENTRYPOINT = "0x88000000"
-UBOOT_LOADADDRESS = "0x80080000"
-UBOOT_ENTRYPOINT = "0x80080000"
-
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-
-# OP-TEE
-PREFERRED_VERSION_optee-os ?= "3.20%"
-PREFERRED_VERSION_optee-client ?= "3.20%"
-PREFERRED_VERSION_optee-test ?= "3.20%"
-
-# Cannot use the default zImage on arm64
-KERNEL_IMAGETYPE = "Image"
-KERNEL_IMAGETYPES += "fitImage"
-KERNEL_CLASSES = " kernel-fitimage "
-
-IMAGE_FSTYPES += "cpio.gz"
-INITRAMFS_IMAGE ?= "core-image-minimal"
-IMAGE_NAME_SUFFIX = ""
-
-SERIAL_CONSOLES = "115200;ttyAMA0"
-
-EXTRA_IMAGEDEPENDS += "trusted-firmware-a optee-os"
-PREFERRED_VERSION_trusted-firmware-a ?= "2.8.%"
-# FIXME - there is signed image dependency/race with testimage.
-# This should be fixed in oe-core
-TESTIMAGEDEPENDS:append = " virtual/kernel:do_deploy"
@@ -1,46 +0,0 @@
-# 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.5%"
-
-# 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"
-
-# SCP
-EXTRA_IMAGEDEPENDS += "virtual/control-processor-firmware"
-
-#UEFI EDK2 firmware
-EXTRA_IMAGEDEPENDS += "edk2-firmware"
-PREFERRED_VERSION_edk2-firmware ?= "202305"
-
-#optee
-PREFERRED_VERSION_optee-os ?= "3.22.%"
-
-#grub-efi
-EFI_PROVIDER ?= "grub-efi"
-MACHINE_FEATURES += "efi"
-
-# SD-Card firmware
-EXTRA_IMAGEDEPENDS += "sdcard-image-n1sdp"
@@ -1,14 +1,17 @@
 #@TYPE: Machine
-#@NAME: qemu-generic-arm64
-#@DESCRIPTION: Generic Arm64 machine for typical SystemReady platforms, which
-#have working firmware and boot via EFI.
+#@NAME: sbsa-ref
+#@DESCRIPTION: Reference SBSA machine in qemu-system-aarch64 on Neoverse N2

-MACHINEOVERRIDES =. "generic-arm64:"
-
-require conf/machine/generic-arm64.conf
+require conf/machine/include/arm/armv9a/tune-neoversen2.inc
 require conf/machine/include/qemu.inc

-EXTRA_IMAGEDEPENDS += "edk2-firmware"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+KERNEL_IMAGETYPE = "Image"
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
+
+MACHINE_FEATURES = " alsa bluetooth efi qemu-usermode rtc screen usbhost vfat wifi"
+
+IMAGE_FSTYPES += "wic.qcow2"

 # This unique WIC file is necessary because kernel boot args cannot be passed
 # because there is no default kernel (see below).  There is no default kernel
@@ -17,17 +20,27 @@ EXTRA_IMAGEDEPENDS += "edk2-firmware"
 # boot arg (which we need for testimage), we have to have a WIC file unique to
 # this platform.
 WKS_FILE = "qemu-efi-disk.wks.in"
-IMAGE_FSTYPES += "wic.qcow2"
+
+EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boot", "grub-efi", d)}"
+
+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 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 qemu-xhci -device usb-tablet -device usb-kbd -pflash @DEPLOY_DIR_IMAGE@/SBSA_FLASH0.fd -pflash @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,18 +7,56 @@
 require conf/machine/include/arm/armv8-2a/tune-cortexa75.inc

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

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

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

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

-WKS_FILE ?= "sgi575-efidisk.wks"
+WKS_FILE ?= "efi-disk.wks.in"
 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,31 +0,0 @@
-# Configuration for TC1
-
-#@TYPE: Machine
-#@NAME: TC1
-#@DESCRIPTION: Machine configuration for TC1
-
-require conf/machine/include/tc.inc
-
-TEST_TARGET = "OEFVPTarget"
-TEST_SUITES = "fvp_boot"
-
-# FVP Config
-FVP_PROVIDER ?= "fvp-tc1-native"
-FVP_EXE ?= "FVP_TC1"
-
-# FVP Parameters
-FVP_CONFIG[css.scp.ROMloader.fname] ?= "scp_romfw.bin"
-FVP_CONFIG[css.trustedBootROMloader.fname] ?= "bl1-tc.bin"
-FVP_CONFIG[board.flashloader0.fname] ?= "fip_gpt-tc.bin"
-
-#FVP_CONFIG[board.hostbridge.userNetworking] ?= "true"
-#FVP_CONFIG[board.hostbridge.userNetPorts] ?= "2222=22"
-#smsc ethernet takes a very long time to come up.  disable now to prevent testimage timeout
-#FVP_CONFIG[board.smsc_91c111.enabled] ?= "1"
-
-FVP_CONSOLE = "terminal_s1"
-FVP_TERMINALS[soc.terminal_s0] ?= "Secure Console"
-FVP_TERMINALS[soc.terminal_s1] ?= "Console"
-
-# Boot image
-FVP_DATA ?= "board.dram=fitImage-core-image-minimal-tc1-tc1@0x20000000"
@@ -0,0 +1,12 @@
+version: 2
+build:
+  os: "ubuntu-22.04"
+  tools:
+    python: "3.9"
+sphinx:
+  configuration: meta-arm-bsp/documentation/corstone1000/conf.py
+formats:
+  - pdf
+python:
+  install:
+    - requirements: meta-arm-bsp/documentation/requirements.txt
@@ -1,5 +1,5 @@
 ..
- # Copyright (c) 2022-2023, Arm Limited.
+ # Copyright (c) 2022-2024, Arm Limited.
 #
 # SPDX-License-Identifier: MIT

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

+
+***************
+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
+***************
+
+Changes
+=======
+
+- Re-enabling support for the External System using linux remoteproc (only supporting switching on and off the External System)
+- UEFI Secure Boot and Authenticated Variable support
+- RSE Comms replaces OpenAMP
+- The EFI System partition image is now created by the meta-arm build system.
+  This image is mounted on the second MMC card by default in the FVP.
+- The capsule generation script is now part of the meta-arm build system.
+  Corstone1000-flash-firmware-image recipe generates a capsule binary using the U-Boot capsule generation tool that includes
+  all the firmware binaries and recovery kernel image.
+- SW components upgrades
+- Bug fixes
+
+
+Corstone-1000 components versions
+=================================
+
+-------------------------------------------+-----------------------------------------------------+
+| arm-tstee                                 |                   2.0.0                             |
+-------------------------------------------+-----------------------------------------------------+
+| linux-yocto                               |                   6.6.23                            |
+-------------------------------------------+-----------------------------------------------------+
+| u-boot                                    |                   2023.07.02                        |
+-------------------------------------------+-----------------------------------------------------+
+| external-system                           |                   0.1.0                             |
+-------------------------------------------+-----------------------------------------------------+
+| optee-client                              |                   4.1.0                             |
+-------------------------------------------+-----------------------------------------------------+
+| optee-os                                  |                   4.1.0                             |
+-------------------------------------------+-----------------------------------------------------+
+| trusted-firmware-a                        |                   2.10.4                            |
+-------------------------------------------+-----------------------------------------------------+
+| trusted-firmware-m                        |                   2.0.0                             |
+-------------------------------------------+-----------------------------------------------------+
+| libts                                     |                   602be60719                        |
+-------------------------------------------+-----------------------------------------------------+
+| ts-newlib                                 |                   4.1.0                             |
+-------------------------------------------+-----------------------------------------------------+
+| ts-psa-{crypto, iat, its. ps}-api-test    |                   602be60719                        |
+-------------------------------------------+-----------------------------------------------------+
+| ts-sp-{se-proxy, smm-gateway}             |                   602be60719                        |
+-------------------------------------------+-----------------------------------------------------+
+
+Yocto distribution components versions
+======================================
+
+-------------------------------------------+------------------------------+
+| meta-arm                                  | scarthgap                    |
+-------------------------------------------+------------------------------+
+| poky                                      | scarthgap                    |
+-------------------------------------------+------------------------------+
+| meta-openembedded                         | scarthgap                    |
+-------------------------------------------+------------------------------+
+| meta-secure-core                          | scarthgap                    |
+-------------------------------------------+------------------------------+
+| busybox                                   |                   1.36.1     |
+-------------------------------------------+------------------------------+
+| musl                                      |                   1.2.4      |
+-------------------------------------------+------------------------------+
+| gcc-arm-none-eabi                         |          13.2.Rel1           |
+-------------------------------------------+------------------------------+
+| gcc-cross-aarch64                         |                   13.2.0     |
+-------------------------------------------+------------------------------+
+| openssl                                   |                   3.2.1      |
+-------------------------------------------+------------------------------+
+
+***************
+Version 2023.11
+***************
+
+Changes
+=======
+
+- Making Corstone-1000  SystemReady IR 2.0 certifiable
+- Allow booting Debian & OpenSUSE on FVP
+- Add support for two MMC cards for the FVP
+- Add signed capsule update support
+- Enable on-disk capsule update
+- Add the feature of purging specific DT nodes in U-Boot before Linux
+- Add Ethernet over VirtIO support in U-Boot
+- Add support for unaligned MMC card images
+- Reducing the out-of-tree patches by upstreaming them to the corresponding open-source projects
+- SW components upgrades
+- Bug fixes
+
+Corstone-1000 components versions
+=================================
+
+-------------------------------------------+-----------------------------------------------------+
+| arm-ffa-tee                               |                   1.1.2-r0                          |
+-------------------------------------------+-----------------------------------------------------+
+| linux-yocto                               |                   6.5.7                             |
+-------------------------------------------+-----------------------------------------------------+
+| u-boot                                    |                   2023.07                           |
+-------------------------------------------+-----------------------------------------------------+
+| external-system                           |    0.1.0+gitAUTOINC+8c9dca74b1-r0                   |
+-------------------------------------------+-----------------------------------------------------+
+| optee-client                              |                   3.22.0                            |
+-------------------------------------------+-----------------------------------------------------+
+| optee-os                                  |                   3.22.0                            |
+-------------------------------------------+-----------------------------------------------------+
+| trusted-firmware-a                        |                   2.9.0                             |
+-------------------------------------------+-----------------------------------------------------+
+| trusted-firmware-m                        |                   1.8.1                             |
+-------------------------------------------+-----------------------------------------------------+
+| libts                                     |                       08b3d39471                    |
+-------------------------------------------+-----------------------------------------------------+
+| ts-newlib                                 |                   4.1.0                             |
+-------------------------------------------+-----------------------------------------------------+
+| ts-psa-{crypto, iat, its. ps}-api-test    |                   38cb53a4d9                        |
+-------------------------------------------+-----------------------------------------------------+
+| ts-sp-{se-proxy, smm-gateway}             |                   08b3d39471                        |
+-------------------------------------------+-----------------------------------------------------+
+
+Yocto distribution components versions
+======================================
+
+-------------------------------------------+------------------------------+
+| meta-arm                                  | nanbield                     |
+-------------------------------------------+------------------------------+
+| poky                                      | nanbield                     |
+-------------------------------------------+------------------------------+
+| meta-openembedded                         | nanbield                     |
+-------------------------------------------+------------------------------+
+| meta-secure-core                          | nanbield                     |
+-------------------------------------------+------------------------------+
+| busybox                                   |                   1.36.1     |
+-------------------------------------------+------------------------------+
+| musl                                      |                   1.2.4      |
+-------------------------------------------+------------------------------+
+| gcc-arm-none-eabi                         |          11.2-2022.02        |
+-------------------------------------------+------------------------------+
+| gcc-cross-aarch64                         |                   13.2.0     |
+-------------------------------------------+------------------------------+
+| openssl                                   |                   3.1.3      |
+-------------------------------------------+------------------------------+
+
 ***************
 Version 2023.06
 ***************
@@ -227,4 +433,4 @@ Changes

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

-*Copyright (c) 2022-2023, Arm Limited. All rights reserved.*
+*Copyright (c) 2022-2024, Arm Limited. All rights reserved.*
@@ -1,3 +1,8 @@
+# SPDX-FileCopyrightText: <text>Copyright 2020-2024 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
@@ -10,15 +15,19 @@
 # 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 = 'corstone1000'
-copyright = '2020-2022, Arm Limited'
+copyright = '2020-2024, Arm Limited'
 author = 'Arm Limited'


@@ -28,6 +37,7 @@ 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.
@@ -45,6 +55,19 @@ 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,11 +1,21 @@
 ..
- # Copyright (c) 2022, Arm Limited.
+ # Copyright (c) 2022, 2024, Arm Limited.
 #
 # SPDX-License-Identifier: MIT

-################
-ARM Corstone1000
-################
+#################
+Arm Corstone-1000
+#################
+
+*************************
+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.

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

@@ -19,6 +19,62 @@ 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 - 2024.11
+***********************
+
+The same notes as the 2024.06 release still apply.
+
+***********************
+Release notes - 2024.06
+***********************
+
+Known Issues or Limitations
+---------------------------
+
+ - Use Ethernet over VirtIO due to lan91c111 Ethernet driver support dropped from U-Boot.
+ - Due to the performance uplimit of MPS3 FPGA and FVP, some Linux distros like Fedora Rawhide can not boot on Corstone-1000 (i.e. user may experience timeouts or boot hang).
+ - Corstone-1000 SoC on FVP doesn't have a secure debug peripheral. It does on the MPS3.
+ - See previous release notes for the known limitations regarding ACS tests.
+
+Platform Support
+-----------------
+ - This software release is tested on Corstone-1000 FPGA version AN550_v2
+   https://developer.arm.com/downloads/-/download-fpga-images
+ - This software release is tested on Corstone-1000 Fast Model platform (FVP) version 11.23_25
+   https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
+
+SystemReady IR v2.0 Certification Milestone
+-------------------------------------------
+
+As of this release, Corstone-1000 has achieved `SystemReady IR v2.0 certification <https://www.arm.com/architecture/system-architectures/systemready-certification-program/ve>`__.
+This milestone confirms compliance with the SystemReady IR requirements, ensuring broader compatibility and reliability for deployment.
+
+Applied patch `313ad2a0e600 <https://git.yoctoproject.org/meta-arm/commit/?h=scarthgap&id=313ad2a0e600655d9bfbe53646e356372ff02644>`__ to address compatibility requirements for SystemReady IR v2.0.
+
+This update is included in tag `CORSTONE1000-2024.06-systemready-ir-v2.0 <https://git.yoctoproject.org/meta-arm/tag/?h=CORSTONE1000-2024.06-systemready-ir-v2.0>`__ and builds on the `CORSTONE1000-2024.06` release.
+
+***********************
+Release notes - 2023.11
+***********************
+
+Known Issues or Limitations
+---------------------------
+
+ - Use Ethernet over VirtIO due to lan91c111 Ethernet driver support dropped from U-Boot.
+ - Temporally removing the External system support in Linux due to it using multiple custom devicetree bindings that caused problems with SystemReady IR 2.0 certification. For External system support please refer to the version 2023.06. We are aiming to restore it in a more standardised manner in our next release.
+ - Due to the performance uplimit of MPS3 FPGA and FVP, some Linux distros like Fedora Rawhide can not boot on Corstone-1000 (i.e. user may experience timeouts or boot hang).
+ - PSA Crypto tests (psa-crypto-api-test command) approximately take 30 minutes to complete for FVP and MPS3.
+ - Corstone-1000 SoC on FVP doesn't have a secure debug peripheral. It does on the MPS3.
+ - See previous release notes for the known limitations regarding ACS tests.
+
+Platform Support
+-----------------
+ - This software release is tested on Corstone-1000 FPGA version AN550_v2
+   https://developer.arm.com/downloads/-/download-fpga-images
+ - This software release is tested on Corstone-1000 Fast Model platform (FVP) version 11.23_25
+   https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
+
 ***********************
 Release notes - 2023.06
 ***********************
@@ -192,7 +248,7 @@ Support
 -------
 For technical support email: support-subsystem-iot@arm.com

-For all security issues, contact Arm by email at arm-security@arm.com.
+For all security issues, contact Arm by email at psirt@arm.com.

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

@@ -1,10 +1,10 @@
 ..
- # Copyright (c) 2022-2023, Arm Limited.
+ # Copyright (c) 2022-2025, Arm Limited.
 #
 # SPDX-License-Identifier: MIT

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


@@ -20,7 +20,7 @@ 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`_.
+`Arm Corstone-1000 Software`_ and `Arm Corstone-1000 Technical Overview`_.

 This readme explicitly focuses on the software part of the solution and
 provides internal details on the software components. The reference
@@ -46,22 +46,22 @@ Each subsystem provides different functionality to overall SoC.


 The Secure Enclave System, provides PSA Root of Trust (RoT) and
-cryptographic functions. It is based on an Cortex-M0+ processor,
+cryptographic functions. It is based on a 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 
+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.

-The Host System is based on ARM Cotex-A35 processor with standardized
+The Host System is based on ARM Cortex-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 procseeor (`FF-A`_) specification.
+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
@@ -70,15 +70,17 @@ FF-A Secure Partitions(based on `Trusted Services`_) and OPTEE-OS
 linux (`linux repo`_) in the non-secure world. The communication between
 non-secure and the secure world is performed via FF-A messages.

-An external system is intended to implement use-case specific
-functionality. The system is based on Cortex-M3 and run RTX RTOS.
-Communictaion between external system and Host(cortex-A35) is performed
-using MHU as transport mechanism and rpmsg messaging system.
+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.

 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.
+connectivity, and edge computing.

 *****************
 Secure Boot Chain
@@ -91,30 +93,107 @@ 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 owner before it
-is deployed into the field. In Corstone-1000, the BL1 image of the secure
-enclave and content of the CC312 OTP (One Time Programmable) memory
-forms the RoT. The BL1 image exists in ROM (Read Only Memory).
+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.

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

 It is a lengthy chain to boot the software on Corstone-1000. On power on,
-the secure enclave starts executing BL1 code from the ROM which is the RoT
-of the device. Authentication of an image involves the steps listed below:
+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.

- Load image from flash to dynamic RAM.
+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 Trusted Firmware-A BL2)
+and TF-M by checking the signatures of the images.
+The MCUBoot handles the image verification the following way:
+
+- 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.

-In the secure enclave, BL1 authenticates the BL2 and passes the execution
-control. BL2 authenticates the initial boot loader of the host (Host TF-A BL2)
-and TF-M. The execution control is now passed to TF-M. TF-M being the run
-time executable of secure enclave which initializes itself and, at the end,
-brings the host CPU out of rest. The host follows the boot standard defined
-in the `TBBR`_ to authenticate the secure and non-secure software.
+
+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:
+
+- 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.
+
+Host Level Authentication
+=========================
+
+The host follows the boot standard defined in the `TBBR`_ to authenticate the
+secure and non-secure software.
+
+The Firmware Image Package (FIP) packs bootloader images and other payloads into a
+single archive. The FIP for Corstone-1000 contains:
+
+- Trusted Boot Firmware BL2
+- EL3 Runtime Firmware BL31
+- Secure Payload BL32 (Trusted OS)
+- Non-Trusted Firmware BL33,
+- TOS_FW_CONFIG
+- key & content certificates
+
+TF-M does not check the FIP signature, it only checks the Trsuted Firmware-A (TF-A) BL2's signature
+in the FIP. The TF-M BL2 (MCUBoot) gets the offset for the TF-A BL2 by parsing the
+GUID Partition Table (GPT) to find the FIP offset, then parsing the FIP to get the offset for the
+TF-A BL2. Finally, MCUBoot loads and validates the TF-A BL2 image.
+
+The implicitly trusted components are:
+
+- A SHA-256 hash of the Root of Trust Public Key (ROTPK). A development ROTPK
+  is used and its hash embedded into the TF-A BL2 image (only for development purposes).
+  This public key is provided by TF-A source-code.
+- In case of Corstone-1000, the TF-A BL2 image, can be trusted because it has been verified
+  by the secure enclave's BL2 (MCUBoot) before starting TF-A.
+
+
+The remaining components in the Chain of Trust (CoT) are either certificates or bootloader images.
+
+BL images authentication using the FIP certificates:
+
+- The certificates are categorized as "Key" and "Content" certificates.
+  The key certificates are used to verify public keys which have been used to sign
+  content certificates. The content certificates are used to store the hash of a
+  boot loader image. An image can be authenticated by calculating its hash and
+  matching it with the hash extracted from the content certificate.
+
+Verification of the certificates:
+
+- 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.
+
+For UEFI Secure Boot, authenticated variables can be accessed from the secure flash.
+The feature has been integrated in U-Boot, which authenticates the images as per the UEFI
+specification before executing them.

 ***************
 Secure Services
@@ -122,11 +201,11 @@ Secure Services

 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
+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
+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.

@@ -137,15 +216,18 @@ flow path for such calls.


 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 OpenAMP which uses shared memory and MHU interrupts as
-a doorbell for communication between two cores. Corstone-1000 implements
-isolation level 2. Cortex-M0+ MPU (Memory Protection Unit) is used to implement
-isolation level 2.
+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
+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
@@ -157,9 +239,9 @@ Secure Firmware Update
 **********************

 Apart from always booting the authorized images, it is also essential that
-the device only accepts the authorized images in the firmware update
+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 sepcification (`FWU`_).
+follows Platform Security Firmware Update specification (`FWU`_).

 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
@@ -172,14 +254,20 @@ Image (the initramfs bundle). The new images are accepted in the form of a UEFI
   :width: 690
   :alt: ExternalFlash

+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
+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
@@ -205,7 +293,7 @@ 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.
+calls are forwarded to the Secure Enclave as explained above.


 .. image:: images/UEFISupport.png
@@ -216,21 +304,21 @@ calls are forwarded to the secure enclave as explained above.
 ***************
 References
 ***************
-`ARM corstone1000 Search`_
+`ARM Corstone-1000 Search`_

 `Arm security features`_

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

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

-.. _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 Corstone-1000 Technical Overview: https://developer.arm.com/documentation/102360/0000
+.. _Arm Corstone-1000 Software: https://developer.arm.com/Tools%20and%20Software/Corstone-1000%20Software
+.. _Arm Corstone-1000 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/-/media/Files/pdf/PlatformSecurityArchitecture/Architect/DEN0063-PSA_Firmware_Framework-1.0.0-2.pdf?revision=2d1429fa-4b5b-461a-a60e-4ef3d8f7f4b4&hash=3BFD6F3E687F324672F18E5BE9F08EDC48087C93
+.. _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/
@@ -1,78 +0,0 @@
-# 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
--- a/Show More
+++ b/Show More