arm-bsp/n1sdp: Enable OP-TEE cache in N1SDP

This change enables N1SDP cache to improve performance by removing this patch: HACK-disable-instruction-cache-and-data-cache.patch Signed-off-by: Mariam Elshakfy <mariam.elshakfy@arm.com>
arm-bsp/n1sdp: Move OP-TEE to DDR4
2026-07-18 16:37:08 +00:00 · 2023-10-19 21:14:39 -05:00 · 2023-10-19 21:14:39 -05:00 · 2023-10-19 21:14:39 -05:00 · 2023-10-16 09:28:49 -04:00 · 2023-10-06 09:23:53 -04:00
957 changed files with 66825 additions and 43414 deletions
@@ -1,2 +0,0 @@
-[b4]
-	send-series-to = meta-arm@lists.yoctoproject.org
@@ -1,24 +1,13 @@
-image: ${MIRROR_GHCR}/siemens/kas/kas:4.7
+image: ghcr.io/siemens/kas/kas:3.2.3

 variables:
-  # These are needed as the k8s executor doesn't respect the container
-  # entrypoint by default
+  CPU_REQUEST: ""
+  DEFAULT_TAG: ""
+  CACHE_DIR: $CI_BUILDS_DIR/persist
+  # 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 directory to use as the persistent cache (the root for DL_DIR,
-  # SSTATE_DIR, etc). The default is the build tree which will not be
-  # persistent, so this should be set in the runner.
-  CACHE_DIR: $CI_PROJECT_DIR
-  # The container mirror to use
-  MIRROR_GHCR: ghcr.io
-  # The list of extra Kas fragments to be used when building
-  EXTRA_KAS_FILES: ""
-  # Whether warnings should be fatal (0/1)
-  FATAL_WARNINGS: 0

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

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

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

 #
 # Build stage, the actual build jobs
 #
-# Available options for building are (VIRT _must_ be last for ssh override)
-#  DISTRO: [poky, poky-altcfg, poky-tiny]
-#  KERNEL: [linux-yocto, linux-yocto-dev]
-#  TOOLCHAINS: [gcc, clang]
+# Available options for building are
+#  DISTRO: [poky, poky-tiny]
+#  KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
+#  TOOLCHAINS: [gcc, clang, armgcc, external-gccarm]
 #  TCLIBC: [glibc, musl]
 #  FIRMWARE: [u-boot, edk2]
 #  TS: [none, trusted-services]
+#  VIRT: [none, xen]
 #  TESTING: testimage
-#  SECUREDEBUG: [none, secure-debug]

-# Validate layers are Yocto Project Compatible
-check-layers:
-  extends: .setup
-  script:
-    - kas shell --update --force-checkout ci/base.yml:ci/meta-openembedded.yml:lockfile.yml --command \
-      "yocto-check-layer-wrapper $CI_PROJECT_DIR/$LAYER --dependency $CI_PROJECT_DIR/meta-* $KAS_WORK_DIR/meta-openembedded/meta-oe --no-auto-dependency"
+corstone500:
+  extends: .build
  parallel:
    matrix:
-      - LAYER: [meta-arm, meta-arm-bsp, meta-arm-toolchain]
+      - TESTING: testimage
+  tags:
+    - x86_64

 corstone1000-fvp:
  extends: .build
  parallel:
    matrix:
-      - FIRMWARE: corstone1000-firmware-only
-        TESTING: [testimage, tftf]
-      - FIRMWARE: none
-        TESTING: testimage
+      - TESTING: [testimage, tftf]
+  tags:
+    - x86_64

 corstone1000-mps3:
  extends: .build
-  parallel:
-    matrix:
-      - FIRMWARE: corstone1000-firmware-only
-        TESTING: [none, tftf]
-      - FIRMWARE: none
-        SECUREDEBUG: [none, secure-debug]
-
-corstone1000-a320-fvp:
-  extends: .build
-  parallel:
-    matrix:
-      - FIRMWARE: corstone1000-firmware-only
-        TESTING: [testimage, tftf]
-      - FIRMWARE: none
-        TESTING: testimage
-
-documentation:
-  extends: .setup
-  script:
-    - |
-      # This can be removed when the kas container has python3-venv installed
-      sudo apt-get update && sudo apt-get install --yes python3-venv
-
-      python3 -m venv venv
-      . ./venv/bin/activate
-
-      pip3 install -r meta-arm-bsp/documentation/requirements.txt
-
-      for CONF in meta-*/documentation/*/conf.py ; do
-        echo Building $CONF...
-        SOURCE_DIR=$(dirname $CONF)
-        MACHINE=$(basename $SOURCE_DIR)
-        sphinx-build -vW $SOURCE_DIR build-docs/$MACHINE
-      done
-      test -d build-docs/
-  artifacts:
-    paths:
-      - build-docs/

 fvp-base:
  extends: .build
  parallel:
    matrix:
-      - TS: [none, fvp-base-ts]
-        TESTING: testimage
-      - FIRMWARE: [u-boot, edk2]
-        TESTING: testimage
-      - LTS: lts-revisions
-        TESTING: testimage
-      - KERNEL: linux-yocto-dev
-        LATEST: latest-revisions
-        TESTING: testimage
+      - TESTING: testimage
+      - FIRMWARE: edk2
+
+fvp-baser-aemv8r64:
+  extends: .build
+  parallel:
+    matrix:
+      - TESTING: testimage
+  tags:
+    - x86_64

 fvps:
  extends: .build

-genericarm64:
+generic-arm64:
  extends: .build
-  parallel:
-    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        TESTING: testimage
-      - KERNEL: linux-yocto-dev
-        TESTING: testimage

 juno:
  extends: .build
@@ -225,6 +139,125 @@ juno:
      - TOOLCHAINS: [gcc, clang]
        FIRMWARE: [u-boot, edk2]

+musca-b1:
+  extends: .build
+
+musca-s1:
+  extends: .build
+
+n1sdp:
+  extends: .build
+  parallel:
+    matrix:
+      - TOOLCHAINS: [gcc, armgcc]
+        TS: [none, n1sdp-ts]
+
+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, 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
+  tags:
+    - x86_64
+
+toolchains:
+  extends: .build
+
+selftest:
+  extends: .setup
+  script:
+    - KASFILES=./ci/qemuarm64.yml:./ci/selftest.yml
+    - kas shell --update --force-checkout $KASFILES -c 'oe-selftest --num-processes 1 --run-tests runfvp'
+
+# Validate layers are Yocto Project Compatible
+check-layers:
+  extends: .setup
+  script:
+    - kas shell --update --force-checkout ci/base.yml:ci/meta-openembedded.yml --command \
+      "yocto-check-layer-wrapper $CI_PROJECT_DIR/$LAYER --dependency $CI_PROJECT_DIR/meta-* $KAS_WORK_DIR/meta-openembedded/meta-oe --no-auto-dependency"
+  parallel:
+    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 --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
+
 # What percentage of machines in the layer do we build
 machine-coverage:
  extends: .setup
@@ -241,109 +274,17 @@ metrics:
    - 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:
+documentation:
  extends: .setup
-  # Only run this job for the default branch (master), or if forced with
-  # BUILD_FORCE_PENDING_UPDATES.
-  rules:
-    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
-    - if: $BUILD_FORCE_PENDING_UPDATES != null
+  script:
+    - |
+      sudo pip3 install -r meta-arm-bsp/documentation/requirements.txt
+      for CONF in meta-*/documentation/*/conf.py ; do
+        SOURCE_DIR=$(dirname $CONF)
+        MACHINE=$(basename $SOURCE_DIR)
+        sphinx-build -vW $SOURCE_DIR build-docs/$MACHINE
+      done
+      test -d build-docs/
  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:
-      - TOOLCHAINS: [gcc, clang]
-        FIRMWARE: [u-boot, edk2]
-        TCLIBC: [glibc, musl]
-        TS: [none, qemuarm64-secureboot-ts]
-        TESTING: testimage
-      - UEFISB: [none, uefi-secureboot]
-        TESTING: testimage
-      - KERNEL: linux-yocto-dev
-        TESTING: testimage
-
-qemuarm64:
-  extends: .build
-  parallel:
-    matrix:
-      - DISTRO: poky-tiny
-        FIRMWARE: [u-boot, edk2]
-        TESTING: testimage
-
-qemuarm-secureboot:
-  extends: .build
-  parallel:
-    matrix:
-      - 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:
-      - TOOLCHAINS: [gcc, clang]
-        TESTING: testimage
-      - DISTRO: poky-tiny
-        TESTING: testimage
-
-qemuarmv5:
-  extends: .build
-  parallel:
-    matrix:
-      - DISTRO: poky
-        KERNEL: [linux-yocto, linux-yocto-dev]
-        TESTING: testimage
-      - DISTRO: poky-tiny
-        TESTING: testimage
-
-rdn2:
-  extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-
-rdv2:
-  extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-
-sbsa-ref:
-  extends: .build
-  parallel:
-    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        TESTING: testimage
-      - DISTRO: poky-altcfg
-        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'
-
-toolchains:
-  extends: .build
+      - build-docs/
@@ -8,7 +8,7 @@ This repository contains the Arm layers for OpenEmbedded.

 * meta-arm-bsp

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

 * meta-arm-toolchain

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

 * ci

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

 * kas

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

 * scripts

-  This directory contains scripts used in running the CI tests.
-
-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
+  This directory contains scripts used in running the CI tests

 Contributing
 ------------
@@ -46,51 +35,25 @@ Currently, we only accept patches from the meta-arm mailing list.  For general
 information on how to submit a patch, please read
 https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

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

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

 Commits and patches added should follow the OpenEmbedded patch guidelines:

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

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

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

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

 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>
@@ -1,46 +0,0 @@
-# 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 @@
+header:
+  version: 11
+
+local_conf_header:
+  cc: |
+    GCCVERSION = "arm-12.2"
@@ -1,48 +1,42 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11

 distro: poky

 defaults:
  repos:
-    branch: wrynose
+    refspec: mickledore

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

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

 local_conf_header:
  base: |
    CONF_VERSION = "2"
-    BB_SERVER_TIMEOUT = "300"
+    LICENSE_FLAGS_ACCEPTED += "Arm-FVP-EULA"
+  setup: |
+    PACKAGE_CLASSES = "package_ipk"
+    PACKAGECONFIG:remove:pn-qemu-system-native = "gtk+ sdl"
+    EXTRA_IMAGE_FEATURES:append = " debug-tweaks"
+    PACKAGECONFIG:append:pn-perf = " coresight"
    INHERIT += "rm_work"
+    DISTRO_FEATURES:remove = "ptest"
  extrapackages: |
-    CORE_IMAGE_EXTRA_INSTALL += "perf"
+    CORE_IMAGE_EXTRA_INSTALL += "perf opencsd"
    CORE_IMAGE_EXTRA_INSTALL:append:aarch64 = " gator-daemon"

 machine: unset
@@ -1,8 +1,13 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
+
+repos:
+  meta-clang:
+    url: https://github.com/kraj/meta-clang

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

 target:
-  - core-image-minimal
+  - corstone1000-image
  - perf
@@ -1,10 +0,0 @@
-# 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,9 +1,12 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  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,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/corstone1000-common.yml

@@ -0,0 +1,12 @@
+header:
+  version: 11
+  includes:
+    - ci/base.yml
+    - ci/fvp.yml
+    - ci/poky-tiny.yml
+
+local_conf_header:
+  fvp-config: |
+    IMAGE_FEATURES:remove = " ssh-server-dropbear"
+
+machine: corstone500
@@ -1,9 +0,0 @@
-# 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:
-  rootlogin: |
-    EXTRA_IMAGE_FEATURES:append = " allow-empty-password empty-root-password allow-root-login"
@@ -1,31 +0,0 @@
-#! /usr/bin/env python3
-
-"""
-Download the lockfile.yml produced by a CI pipeline, specified by the GitLab
-server, full name of the meta-arm project, and the refspec that was executed.
-
-For example,
-$ ./download-lockfile.py https://gitlab.com/ rossburton/meta-arm master
-
-SPDX-FileCopyrightText: Copyright 2023 Arm Limited and Contributors
-SPDX-License-Identifier: GPL-2.0-only
-"""
-
-import argparse
-import gitlab
-import io
-import zipfile
-
-parser = argparse.ArgumentParser()
-parser.add_argument("server", help="GitLab server name")
-parser.add_argument("project", help="meta-arm project name")
-parser.add_argument("refspec", help="Branch/commit")
-args = parser.parse_args()
-
-gl = gitlab.Gitlab(args.server)
-project = gl.projects.get(args.project)
-artefact = project.artifacts.download(ref_name=args.refspec, job="update-repos")
-
-z = zipfile.ZipFile(io.BytesIO(artefact))
-z.extract("lockfile.yml")
-print("Fetched lockfile.yml")
@@ -1,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11

 local_conf_header:
  bootfirmware: |
@@ -13,5 +11,7 @@ local_conf_header:
    EXTRA_IMAGEDEPENDS += "edk2-firmware"
    EFI_PROVIDER ?= "grub-efi"

-    QB_DEFAULT_BIOS ??= "QEMU_EFI.fd"
+    QB_DEFAULT_BIOS = "QEMU_EFI.fd"
    WKS_FILE ?= "efi-disk.wks.in"
+  failing_tests: |
+    TEST_SUITES:remove = "xorg"
@@ -0,0 +1,8 @@
+header:
+  version: 11
+
+local_conf_header:
+  cc: |
+    SKIP_RECIPE[gcc-cross-arm] = "Using external toolchain"
+    TCMODE = "external-arm"
+    EXTERNAL_TOOLCHAIN = "${TOPDIR}/toolchains/${TARGET_ARCH}"
@@ -1,27 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-  includes:
-    - ci/fvp-base-ts.yml
-    - ci/meta-secure-core.yml
-
-repos:
-  meta-secure-core:
-    layers:
-      meta-tpm2:
-
-local_conf_header:
-  remove_secureboot: |
-    BBMASK += "efi-secure-boot"
-
-  ftpm_sp_test: |
-    # Include tpm2 related packages
-    IMAGE_INSTALL:append = " tpm2-tools-tests tpm2-abrmd tpm2-tss"
-    # Use systemd as the init system, which is required for the tpm2 self-tests
-    INIT_MANAGER = "systemd"
-    IMAGE_INSTALL:append = " systemd util-linux"
-
-  ts_ftpm_sp: |
-    MACHINE_FEATURES:append = " ts-ftpm"
-    RUN_TPM2_TESTS = "1"
@@ -1,35 +0,0 @@
-# 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
-
-local_conf_header:
-  trusted_services: |
-    # Enable the needed test suites
-    TEST_SUITES:append = " trusted_services"
-    # Include all Secure Partitions into the image
-    MACHINE_FEATURES:append = " arm-ffa ts-crypto ts-storage ts-its"
-    MACHINE_FEATURES:append = " ts-attestation ts-smm-gateway optee-spmc-test"
-    MACHINE_FEATURES:append = " ts-block-storage ts-fwu ts-logging"
-    MACHINE_FEATURES:append = " arm-branch-protection"
-    SMMGW_AUTH_VAR = "1"
-    # 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,13 +1,7 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/base.yml
    - ci/fvp.yml

 machine: fvp-base
-
-target:
-  - core-image-full-cmdline
-  - boot-wrapper-aarch64
@@ -0,0 +1,7 @@
+header:
+  version: 11
+  includes:
+    - ci/base.yml
+
+machine: fvp-baser-aemv8r64
+
@@ -1,15 +1,11 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11

 local_conf_header:
  testimagefvp: |
-    LICENSE_FLAGS_ACCEPTED += "Arm-FVP-EULA"
-    IMAGE_CLASSES += "fvpboot"
-  networking_failing_tests: |
-    # These tests currently fail as the wrong IP for the build host is used
-    TEST_SUITES:remove = "opkg dnf"
-
-target:
-  - core-image-base
+    INHERIT += "fvpboot"
+    # 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"
+  failing_tests: |
+    TEST_SUITES:remove = "xorg"
@@ -1,49 +1,20 @@
-# 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:
-  version: 14
+  version: 11
  includes:
    - ci/base.yml

 machine: qemuarm64

 local_conf_header:
-  license: |
-    LICENSE_FLAGS_ACCEPTED += "Arm-FVP-EULA"
  sdk: |
    SDKMACHINE = "x86_64"

 target:
-  # Target packages to test aarch64
-  # Nativesdk to test x86-64
-
-  # Architecture Envelope Models (AEM) FVPs
-  - fvp-base-a-aem
  - nativesdk-fvp-base-a-aem
-
-  # Arm Lumex CSS (Total Compute) FVPs
-  # These are x86 only... :(
-  - nativesdk-fvp-tc3
-
-  # Automotive FVPs
-  - fvp-rd1-ae
-  - nativesdk-fvp-rd1-ae
-
-  # Infrastructure FVPs
-  - fvp-rdv3-r1
-  - nativesdk-fvp-rdv3-r1
-  - fvp-rdv2
-  - nativesdk-fvp-rdv2
-  - fvp-rdn2
-  - nativesdk-fvp-rdn2
-
-  # IoT FVPs
-  - fvp-corstone1000
+  - nativesdk-fvp-corstone500
  - nativesdk-fvp-corstone1000
-  - fvp-corstone1000-a320
-  - nativesdk-fvp-corstone1000-a320
-
-  # Morello FVPs
-  # TBD
+  - nativesdk-fvp-n1-edge
+  - nativesdk-fvp-sgi575
+  - nativesdk-fvp-tc1
@@ -1,9 +1,7 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11

-#NOTE: This is the default.  This is only being added for completeness/clarity
+#NOTE: This is the default for poky.  This is only being added for completeness/clarity
 local_conf_header:
  toolchain: |
-    PREFERRED_TOOLCHAIN_TARGET = "gcc"
+    TOOLCHAIN = "gcc"
@@ -0,0 +1,6 @@
+header:
+  version: 11
+  includes:
+    - ci/base.yml
+
+machine: generic-arm64
@@ -1,21 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-
-repos:
-  meta-yocto:
-    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
@@ -0,0 +1,50 @@
+#!/bin/bash
+set -u -e
+
+BASENAME=arm-gnu-toolchain
+VER=${VER:-12.2.rel1}
+HOST_ARCH=${HOST_ARCH:-$(uname -m)}
+
+DOWNLOAD_DIR=$1
+TOOLCHAIN_DIR=$2
+TOOLCHAIN_LINK_DIR=$3
+
+# 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,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11

 #NOTE: This is the default for poky.  This is only being added for completeness/clarity
 local_conf_header:
@@ -3,28 +3,17 @@
 # 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]
-# 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.
+# corstone500
+# fvp-base: [testimage]
+# qemuarm64-secureboot: [clang, glibc, testimage]
 #
 # Turn this list into a series of yml files separated by colons to pass to kas

 set -e -u

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

-# 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
+for i in $(echo $1 | 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
@@ -35,9 +24,4 @@ for i in $(echo $JOBNAME | 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
@@ -1,15 +0,0 @@
-#! /bin/bash
-
-# $ ci/junit.sh <build directory>
-#
-# If there is a OEQA test report in JSON format present in the build directory,
-# transform it to JUnit XML using resulttool.
-
-set -e -u
-
-BUILDDIR=$1
-JSON=$BUILDDIR/tmp/log/oeqa/testresults.json
-
-if test -f $JSON; then
-    resulttool junit $JSON
-fi
@@ -1,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/base.yml

@@ -1,16 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-
-local_conf_header:
-  latest_revisions: |
-    PREFERRED_VERSION_scp-firmware ?= "git"
-    PREFERRED_VERSION_trusted-firmware-a ?= "git"
-    PREFERRED_VERSION_trusted-firmware-m ?= "git"
-    PREFERRED_VERSION_optee-client ?= "git"
-    PREFERRED_VERSION_optee-examples ?= "git"
-    PREFERRED_VERSION_optee-os-tadevkit ?= "git"
-    PREFERRED_VERSION_optee-os ?= "git"
-    PREFERRED_VERSION_optee-test ?= "git"
-    PREFERRED_PROVIDER_u-boot = "u-boot:class-devupstream"
@@ -1,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 9

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

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

 #NOTE: This is the default for poky.  This is only being added for completeness/clarity
 local_conf_header:
@@ -1,10 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-
-local_conf_header:
-  latest_revisions: |
-    PREFERRED_VERSION_trusted-firmware-a ?= "2.10.%"
-    PREFERRED_VERSION_tf-a-tests ?= "2.10.%"
-    PREFERRED_VERSION_trusted-firmware-m ?= "2.1.%"
@@ -1,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11

 repos:
  meta-openembedded:
@@ -11,4 +9,3 @@ repos:
      meta-networking:
      meta-oe:
      meta-python:
-      meta-perl:
@@ -1,13 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-
-repos:
-  meta-secure-core:
-    url: https://github.com/Wind-River/meta-secure-core.git
-    layers:
-      meta-secure-core-common:
-      meta-signing-key:
-      meta-efi-secure-boot:
-      
@@ -0,0 +1,8 @@
+header:
+  version: 11
+  includes:
+    - ci/meta-openembedded.yml
+
+repos:
+  meta-virtualization:
+    url: git://git.yoctoproject.org/meta-virtualization
@@ -1,16 +1,9 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/base.yml
    - ci/meta-openembedded.yml

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

 target:
@@ -1,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/base.yml
    - ci/meta-openembedded.yml
@@ -1,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11

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

 distro: poky-tiny

 local_conf_header:
  hacking: |
-    TEST_SUITES = "_qemutiny ping"
+    TEST_SUITES = "ping"
  extrapackages: |
    # Intentionally blank to prevent perf from being added to the image in base.yml

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

 distro: poky
@@ -0,0 +1,14 @@
+header:
+  version: 11
+  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,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/base.yml

@@ -9,8 +7,6 @@ machine: qemuarm-secureboot

 target:
  - core-image-base
-
-local_conf_header:
-  optee: |
-    IMAGE_INSTALL:append = " optee-test optee-client optee-os-ta"
-    TEST_SUITES:append = " optee ftpm"
+  - optee-examples
+  - optee-test
+  - optee-os-tadevkit
@@ -1,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/base.yml

@@ -1,16 +1,13 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/meta-openembedded.yml

 local_conf_header:
  trusted_services: |
    TEST_SUITES:append = " trusted_services"
-    # Include TS Crypto, TS Protected Storage, and TS Internal Trusted Storage and SPs into optee-os image
-    # FIXME - remove TS SMM Gateway due to QEMU v9.0.0 test failures
-    MACHINE_FEATURES:append = " arm-ffa ts-crypto ts-storage ts-its"
+    # Include TS Crypto, TS Protected Storage, TS Internal Trusted Storage and SMM-Gateway SPs into optee-os image
+    MACHINE_FEATURES:append = " arm-ffa ts-crypto ts-storage ts-its ts-smm-gateway"
    # Include TS demo/test tools into image
    IMAGE_INSTALL:append = " packagegroup-ts-tests"
    # Include TS PSA Arch tests into image
@@ -1,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/base.yml

@@ -9,9 +7,6 @@ machine: qemuarm64-secureboot

 target:
  - core-image-base
-  - hafnium
-
-local_conf_header:
-  optee: |
-    IMAGE_INSTALL:append = " optee-test optee-client optee-os-ta"
-    TEST_SUITES:append = " optee ftpm"
+  - optee-examples
+  - optee-test
+  - optee-os-tadevkit
@@ -1,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/base.yml

@@ -1,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/base.yml

@@ -1,14 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-    - ci/fvp.yml
-
-local_conf_header:
-  sshpregen: |
-    # Allow the use of the pregen keys as this is CI so safe
-    COMPATIBLE_MACHINE:pn-ssh-pregen-hostkeys:rdn2 = "rdn2"
-
-machine: rdn2
@@ -1,14 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-    - ci/fvp.yml
-
-local_conf_header:
-  sshpregen: |
-    # Allow the use of the pregen keys as this is CI so safe
-    COMPATIBLE_MACHINE:pn-ssh-pregen-hostkeys:rdv2 = "rdv2"
-
-machine: rdv2
@@ -1,12 +0,0 @@
-# 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
@@ -1,8 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-
-local_conf_header:
-  secure-debug: |
-    MACHINE_FEATURES += "secure-debug"
@@ -1,10 +1,7 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11

 local_conf_header:
  setup: |
    BB_LOGCONFIG = ""
    SANITY_TESTED_DISTROS = ""
-    INHERIT:remove = "rm_work"
@@ -0,0 +1,6 @@
+header:
+  version: 11
+  includes:
+    - ci/base.yml
+
+machine: sgi575
@@ -1,11 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-
-local_conf_header:
-  sstate_mirror: |
-    BB_HASHSERVE_UPSTREAM = "wss://hashserv.yoctoproject.org/ws"
-    SSTATE_MIRRORS = "file://.* http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
-    BB_HASHSERVE = "auto"
-    BB_SIGNATURE_HANDLER = "OEEquivHash"
@@ -0,0 +1,12 @@
+header:
+  version: 11
+  includes:
+    - ci/base.yml
+    - ci/fvp.yml
+    - ci/meta-openembedded.yml
+
+machine: tc1
+
+target:
+  - core-image-minimal
+  - trusted-firmware-m
@@ -1,21 +1,19 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
-  includes:
-    - ci/debug.yml
+  version: 11

 local_conf_header:
  testimage: |
    IMAGE_CLASSES += "testimage"
    TESTIMAGE_AUTO = "1"
-    # Don't testimage initramfs
-    TESTIMAGE_AUTO:pn-core-image-initramfs-boot = "0"
  kvm: |
    QEMU_USE_KVM = ""
  slirp: |
    TEST_RUNQEMUPARAMS = "slirp"
+    TEST_SERVER_IP = "127.0.0.1"
+    QEMU_USE_SLIRP = "1"
  sshd: |
-    IMAGE_FEATURES += "ssh-server-dropbear"
+    IMAGE_FEATURES:append = " ssh-server-dropbear"
  sshkeys: |
    CORE_IMAGE_EXTRA_INSTALL += "ssh-pregen-hostkeys"
+  universally_failing_tests: |
+    TEST_SUITES:remove = "opkg"
@@ -1,10 +1,7 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 9

 local_conf_header:
  tftf: |
    TFA_UBOOT = "0"
-    TFA_UEFI = "0"
    TFTF_TESTS = "1"
@@ -1,7 +1,5 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
 header:
-  version: 14
+  version: 11
  includes:
    - ci/base.yml

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

 local_conf_header:
  bootfirmware: |
@@ -1,50 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-# UEFI Secure Boot: A mechanism to ensure that only trusted software is executed
-# during the boot process.
-
-header:
-  version: 14
-  includes:
-    - ci/meta-openembedded.yml
-    - ci/meta-secure-core.yml
-
-local_conf_header:
-  uefi_secureboot: |
-    SBSIGN_KEYS_DIR = "${TOPDIR}/sbkeys"
-    BB_ENV_PASSTHROUGH_ADDITIONS = "SBSIGN_KEYS_DIR"
-
-    # Detected by passing kernel parameter
-    QB_KERNEL_ROOT = ""
-
-    # kernel is in the image, should not be loaded separately
-    QB_DEFAULT_KERNEL = "none"
-
-    WKS_FILE = "efi-disk.wks.in"
-    KERNEL_IMAGETYPE = "Image"
-
-    MACHINE_FEATURES:append = " efi uefi-secureboot uefi-http-boot uefi-capsule-updates"
-
-    EFI_PROVIDER = "systemd-boot"
-
-    # Use systemd as the init system
-    INIT_MANAGER = "systemd"
-
-    IMAGE_INSTALL:append = " systemd systemd-boot util-linux coreutils"
-
-    TEST_SUITES:append = " uefi_secureboot uki"
-
-    IMAGE_CLASSES += "uki"
-
-    IMAGE_CLASSES += "sbsign"
-    UKI_SB_KEY = "${SBSIGN_KEY}"
-    UKI_SB_CERT = "${SBSIGN_CERT}"
-    IMAGE_BOOT_FILES:remove = "Image"
-
-    INITRAMFS_IMAGE = "core-image-initramfs-boot"
-    # not for initramfs image recipe
-    IMAGE_CLASSES:remove:pn-core-image-initramfs-boot = "uki"
-    IMAGE_CLASSES:remove:pn-core-image-initramfs-boot = "sbsign"
-    IMAGE_CLASSES:remove:pn-core-image-initramfs-boot = "testimage"
-    IMAGE_FEATURES:remove:pn-core-image-initramfs-boot = "ssh-server-dropbear"
-    CORE_IMAGE_EXTRA_INSTALL:remove:pn-core-image-initramfs-boot = "ssh-pregen-hostkeys"
@@ -20,8 +20,10 @@ def repo_shortname(url):
            .replace('*', '.'))

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

 if __name__ == "__main__":
@@ -30,7 +32,6 @@ if __name__ == "__main__":
        sys.exit(1)

    base_repodir = pathlib.Path(os.environ["KAS_REPO_REF_DIR"])
-    failed = False

    for repo in repositories:
        repodir = base_repodir / repo_shortname(repo)
@@ -40,15 +41,8 @@ if __name__ == "__main__":
            shutil.rmtree(repodir, ignore_errors=True)

        if repodir.exists():
-            try:
-                print("Updating %s..." % repo)
-                subprocess.run(["git", "-C", repodir, "-c", "gc.autoDetach=false", "fetch", repo], check=True)
-            except subprocess.CalledProcessError as e:
-                print(e)
-                failed = True
+            print("Updating %s..." % repo)
+            subprocess.run(["git", "-C", repodir, "-c", "gc.autoDetach=false", "fetch"], check=True)
        else:
            print("Cloning %s..." % repo)
            subprocess.run(["git", "clone", "--bare", repo, repodir], check=True)
-
-    if failed:
-        sys.exit(128)
@@ -0,0 +1,11 @@
+header:
+  version: 11
+  includes:
+    - ci/meta-virtualization.yml
+
+local_conf_header:
+  meta-virt: |
+    DISTRO_FEATURES:append = " virtualization xen"
+
+target:
+  - xen-image-minimal
@@ -1,67 +0,0 @@
-# **CI for Yocto Project and meta-arm**
-# **CI for Yocto Project**
-The Yocto Project has an autobuilder that performs nightly builds and image tests on all of the defined QEMU machines, including qemuarm and qemuarm64  Also, it currently runs builds on the hardware reference platforms including genericarm64 and meta-arm mahines fvp-base and sbsa-ref.  More information on the autobuilder can be found at <https://autobuilder.yoctoproject.org/>.
-
-More information on the image tests can be found at <https://wiki.yoctoproject.org/wiki/Image_tests>.
-
-The Yocto Project also has the ability to have individual package tests, ptests.  For more information on those, go to <https://wiki.yoctoproject.org/wiki/Ptest>.
-# **CI for meta-arm**
-meta-arm is using the Gitlab CI infrastructure.  This is currently being done internal to Arm, but an external version can be seen at <https://gitlab.com/jonmason00/meta-arm/-/pipelines>.
-
-This CI is constantly being expanded to provide increased coverage of the software and hardware supported in meta-arm.  All platforms are required to add a kas file and `.gitlab-ci.yml` entry as part of the initial patch series.  More information on kas can be found at <https://github.com/siemens/kas>.
-
-To this end, it would be wise to run kas locally to verify everything works prior to pushing to the CI build system.
-## **Running kas locally**
-### **Install kas**
-kas can be installed with pip, for example:
-```
-$ pip3 install --user kas
-```
-
-See <https://kas.readthedocs.io/en/latest/userguide/getting-started.html> for information on the dependencies and more.
-
-This assumes that the kas path ($HOME/.local/bin) is in $PATH.  If not, the user will need to manually add this or the kas command will not be found.
-
-### **Run kas locally**
-```
-$ cd ~/meta-arm/
-$ kas build kas/juno.yml
-```
-
-By default kas will create a build directory under meta-arm to contain the checked out layers, build directory, and downloads.  You can change this by setting environment variables.  DL\_DIR and SSTATE\_DIR are respected so these can point at existing directories, and setting KAS\_WORK\_DIR to the directory where repositories are already cloned will save having to re-fetch.  This can look something like:
-```
-$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/qemuarm64.yml:ci/testimage.yml
-```
-
-See the [quick start guide](/documentation/quick-start.md) for more information on how to set this up.
-
-## **Locked Revisions in CI with lockfiles**
-The CI in meta-arm will generate a kas "lock file" when it starts to ensure that all of the builds checkout the same revision of the various different layers that are used. If this isn't done then there's a chance that a layer will be modified upstream during the CI, which results in some builds failing and some builds passing.
-
-This lock file is saved as an artefact of the update-repos job by the CI, and only generated if it doesn't already exist in the repository.  This can be used to force specific revisions of layers to be used instead of HEAD, which can be useful if upstream changes are causing problems in development.
-
-The lockfile.yml can be downloaded manually, but there's a script in meta-arm to fetch the lock file for the latest successful build of the specified branch:
-
-```
-$ ./ci/download-lockfile.py --help
-usage: download-lockfile.py [-h] server project refspec
-
-positional arguments:
-  server      GitLab server name
-  project     meta-arm project name
-  refspec     Branch/commit
-
-$ ./ci/download-lockfile.py https://gitlab.com/jonmason00/meta-arm master
-Fetched lockfile.yml
-Commit this lockfile.yml to the top-level of the meta-arm repository and the CI will use it automatically.
-```
-# **Relevant Links for kas, CI, and testing**
-<https://github.com/siemens/kas.git>
-
-<https://wiki.yoctoproject.org/wiki/Oe-selftest>
-
-<https://wiki.yoctoproject.org/wiki/Image_tests>
-
-<https://wiki.yoctoproject.org/wiki/Ptest>
-
-<https://wiki.yoctoproject.org/wiki/BSP_Test_Plan>
@@ -4,36 +4,32 @@ OE-Core's [oeqa][OEQA] framework provides a method of performing runtime tests o

 Tests can be configured to run automatically post-build by setting the variable `TESTIMAGE_AUTO="1"`, e.g. in your Kas file or local.conf.

-meta-arm provides the OEFVPTarget which must be set up in the machine configuration:
-```
-TEST_TARGET = "OEFVPTarget"
-TEST_SERVER_IP = "127.0.0.1"
-TEST_TARGET_IP = "127.0.0.1:2222"
-IMAGE_FEATURES:append = " ssh-server-dropbear"
-FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] ?= "2222=22"
-FVP_CONSOLES[default] = "terminal_0"
-FVP_CONSOLES[tf-a] = "s_terminal_0"
-```
+There are two main methods of testing, using different test "targets". Both test targets generate an additional log file with the prefix 'fvp_log' in the image recipe's `${WORKDIR}/testimage` containing the FVP's stdout.

-The test target also generates a log file with the prefix 'fvp_log' in the image recipe's `${WORKDIR}/testimage` containing the FVP's stdout.
+## OEFVPTarget

-OEFVPTarget supports two different test interfaces - SSH and pexpect.
+This runs test cases on a machine using SSH. It therefore requires that an SSH server is installed in the image.

-## SSH
-
-As in OEQA in OE-core, tests cases can run commands on the machine using SSH. It therefore requires that an SSH server is installed in the image.
-
-This uses the `run` method on the target, e.g:
+In test cases, the primary interface with the target is, e.g:
 ```
 (status, output) = self.target.run('uname -a')
 ```
-which executes a single command on the target (using `ssh -c`) and returns the status code and the output. It is therefore useful for running tests in a Linux environment.
+which runs a single command on the target (using `ssh -c`) and returns the status code and the output. It is therefore useful for running tests in a Linux environment.

 For examples of test cases, see meta/lib/oeqa/runtime/cases in OE-Core. The majority of test cases depend on `ssh.SSHTest.test_ssh`, which first validates that the SSH connection is functioning.

-## pexpect
+Example machine configuration:
+```
+TEST_TARGET = "OEFVPTarget"
+TEST_SERVER_IP = "127.0.0.1"
+TEST_TARGET_IP = "127.0.0.1:8022"
+IMAGE_FEATURES:append = " ssh-server-dropbear"
+FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] ?= "8022=22"
+```

-To support firmware and baremetal testing, OEFVPTarget also allows test cases to make assertions against one or more consoles using the pexpect library.
+## OEFVPSerialTarget
+
+This runs tests against one or more serial consoles on the FVP. It is more flexible than OEFVPTarget, but test cases written for this test target do not support the test cases in OE-core. As it does not require an SSH server, it is suitable for machines with performance or memory limitations.

 Internally, this test target launches a [Pexpect][PEXPECT] instance for each entry in FVP_CONSOLES which can be used with the provided alias. The whole Pexpect API is exposed on the target, where the alias is always passed as the first argument, e.g.:
 ```
@@ -43,6 +39,16 @@ self.assertNotIn(b'ERROR:', self.target.before('tf-a'))

 For an example of a full test case, see meta-arm/lib/oeqa/runtime/cases/linuxboot.py This test case can be used to minimally verify that a machine boots to a Linux shell. The default timeout is 10 minutes, but this can be configured with the variable TEST_FVP_LINUX_BOOT_TIMEOUT, which expects a value in seconds.

+The SSH interface described above is also available on OEFVPSerialTarget to support writing a set of hybrid test suites that use a combination of serial and SSH access. Note however that this test target does not guarantee that Linux has booted to shell prior to running any tests, so the test cases in OE-core are not supported.
+
+Example machine configuration:
+```
+TEST_TARGET="OEFVPSerialTarget"
+TEST_SUITES="linuxboot"
+FVP_CONSOLES[default] = "terminal_0"
+FVP_CONSOLES[tf-a] = "s_terminal_0"
+```
+
 [OEQA]: https://docs.yoctoproject.org/test-manual/intro.html
 [FVP]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
 [RUNFVP]: runfvp.md
@@ -1,105 +0,0 @@
-# **Yocto Project quick start for Arm system software developers**
-If you want to read the The Yocto Project official quick start documentation, go to <https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html>
-
-If that looks like too much reading, then here is how to do it even faster!
-# **Step 0: Install build deps and kas**
-```
-$ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev python3-subunit mesa-common-dev zstd liblz4-tool file locales libacl1
-
-$ pip install kas
-```
-OR, if you prefer to use a docker will all that stuff already installed:
-
-```
-$ sudo docker run -it --name kas-test --volume /mnt/yocto/:/builds/persist ghcr.io/siemens/kas/kas /bin/bash
-```
-
-> **_NOTE:_**
-> the “--volume” is the directory where your persistent stuff (like downloads and build artifacts) will go to help speed up your builds and can be sharable amongst your builds/containers.  If you want to go completely clean-room, feel free to remove it
-# **Step 1: clone meta-arm and build meta-arm**
-```
-$ git clone https://git.yoctoproject.org/meta-arm
-$ cd meta-arm/
-$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/fvp-base.yml:ci/testimage.yml
-```
-> **_NOTE:_**
-> “ci/testimage.yml” will cause the build to run some basic system tests.  If you don’t care about verifying basic functionality, then remove it and it should be faster (a few less programs will be added to the system image and the 2-3mins that it takes to run the test will not happen).
-
-> **_NOTE:_**
-> You may wish to add the Yocto Project SSTATE Mirror (especially the first time) to speed up the build by downloading the build fragments (built by the Yocto Project autobuilder) from the internet.  This can be done by adding "ci/sstate-mirror.yml" in kas or adding the relevant lines to your local.conf.  Using the above example:
-
-```
-$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/fvp-base.yml:ci/sstate-mirror.yml
-```
-
-> **_NOTE:_**
-> This only fetches the parts necessary for your build and may take several minutes depending on your internet connection speed.  Also, it only fetches what is available.  There may still be a need to build things depending on your configuration.
-
-For more information on kas and various commands, please reference <https://kas.readthedocs.io/en/latest/>.
-
-Depending on what software you are building, fvp-base might not be the machine you want to build for.
-The following website provides an EXTREMELY rough way to tell what software is in what machines, and what versions are being run:
-<https://gitlab.com/jonmason00/meta-arm/-/jobs/artifacts/master/file/update-report/index.html?job=pending-updates>
-
-If, as an example, we’re wanting to develop trusted-firmware-a; then fvp-base will work for us. 
-
-### **Okay, you are done!  VICTORY!**
-### **Oh, you actually wanted to mess around with the system software source code?**
-# **Step 2: use devtool to get your source**
-Setup your environment via the (non-kas) Yocto Project tools
-
-```
-$ source poky/oe-init-build-env
-```
-
-Use devtool to checkout the version of software being used on the machine above (in the above example, this will be trusted-firmware-a for fvp-base).
-
-```
-$ devtool modify trusted-firmware-a
-```
-
-This will download the source, hopefully in git (depending on how the Yocto Project recipe was written), and should print a path at the end where the source code was checked out.  In the trusted-firmware-a example, I got:
-
-> /builder/meta-arm/build/workspace/sources/trusted-firmware-a
-
-Inside of that directory, you should see the relevant source code.  In this example, it is a standard git tree.  So, you can add remotes, checkout different SHAs, etc
-
-Ok, so you are set with your changes and want to build them.
-
-```
-$ devtool build trusted-firmware-a
-```
-
-This should build the software in question, but it is not yet integrated into a system image.  To do that, run:
-
-```
-$ devtool build-image core-image-sato
-```
-
-The image should match the image being used on your machine above.  Most of them in meta-arm are set to core-image-sato.  
-
-Also, if you used testimage above, it will run testimage now
-### **Okay, you are done!  VICTORY!**
-# **Step 3.  Testing your patches outside of devtool**
-At this point I will assume you have a patch and want to add it to the base recipe.  Using the above example, in the devtool directory:
-```
-$ git format-patch -1
-0001-example.patch
-$ mv 0001-example.patch ~/meta-arm/meta-arm/recipes-bsp/trusted-firmware-a/files/
-$ cd ~/meta-arm
-$ devtool reset trusted-firmware-a
-$ echo ‘SRC_URI:append = " file://0001-example.patch" >> meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.10.3.bb
-```
-
-> **_NOTE:_**
-> there is a space before the “file” and yes it matters very much
-
-At this point, you can go back using kas and verify that the patch works in a clean-ish tree.
-
-```
-$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/fvp-base.yml:ci/testimage.yml
-```
-
-There is obviously much more that can be done and other ways to do similar things.
-
-## **If there are issues or questions then please ask them on the #meta-arm irc channel on libera.chat**
@@ -1,43 +0,0 @@
-# **meta-arm Releases and Branching**
-## **Release and Branching background**
-The Yocto Project releases twice a year (April and October): "stable" releases are made every six months and have a lifetime of seven months to allow for migration, while "long term support" (LTS) releases are picked every two years starting from Dunfell in April 2020. The standard practice for all Yocto Compatible layers is to create a "named" branch consistent with the code name of that release. For example, the “dunfell” release of the Yocto Project will have a branch named “dunfell” in the official git repository, and layers compatible with dunfell will have a branch named “dunfell”. Thus, a customer can easily organize a collection of appropriate layers to make a product.
-
-In the Yocto Project, these named branches are “stable”, and only take bug fixes or security-critical upgrades. Active development occurs on the master branch. However, this methodology can be problematic if mimicked with the compatible layers. Companies, like Arm, may not wish to release a snapshot of the relevant “master” branches under active development, due to the amount of testing, fixing, and hardening necessary to make a product from a non-stable release. Also, changes to keep the master branch of a layer working with the upstream master branch of the Yocto Project may result in that branch no longer being compatible with named branches (e.g., it might not be possible to mix and match master and dunfell). So, a decision must be made on the branching policy of meta-arm.
-
-## **Adding new Hardware or Software features**
-There are many different ways to resolve this issue. After some discussion, the best solution for us is to allow new hardware enablement (and relevant software features) to be included in LTS named branches (not just bug fixes). This will allow for a more stable software platform for software to be developed, tested, and released. Also, the single branch allows for focused testing (limiting the amount of resources needed for CI/CD), lessens/eliminates code diverging on various branches, and lessens confusion on which branch to use. The risk of making this choice is a potentially non-stable branch which will require more frequent testing to lessen the risk, and not following the “stable” methodology of the core Yocto Project layers (though it is not uncommon for BSP layers to behave this way).
-
-## **Process**
-The process for patches intended on being integrated into only the master branch is the normal internal process of pushing for code review and CI, approval and integration into upstream meta-arm master branch. 
-For patches intended on being included in an LTS named branch, the preferred process is to upstream via the master branch, rebase the patch (or series against the intended LTS branch) and send email with the release name in the subject line after the "PATCH" (e.g., "[PATCH dunfell] Add foo to bar").
-
-If there is a time crunch and the preferred way above cannot be completed in time, upstreaming via the LTS branch can occur. This follows the normal process above but without the master integration step.  However, any patches upstreamed in this manner must be pushed to master in a timely fashion (after the time crunch). Nagging emails will be sent and managers will be involved as the time grows.
-
-## **Testing**
-See [continuous-integration-and-kas.md](/documentation/continuous-integration-and-kas.md) for information how the layer is tested and what tests are run. It is presumed that all code will be compiled as part of the CI process of the gerrit code review. Also, testing on virtual platforms and code conformity checks will be run when enabled in the process.
-
-## **Branching strategy and releases**
-Named branches for meta-arm will be released as close as possible to the release of the YP LTS release. Meta-arm named branches will be created from the meta-arm master branch.
-
-To minimize the additional work of maintaining multiple branches it is assumed that there will only be two active development branches at any given time: master and the most recent Long Term Stable (LTS) as the named branch. All previous named LTS branches will be EOLed when a new LTS has been released. Any branches that are EOLed will still exist in the meta-arm, but bug fix patches will be accepted. Limited to no testing will occur on EOL’ed branches. Exceptions to this can be made, but must be sized appropriately and agreed to by the relevant parties.
-
-Named branch release will coincide with Yocto Project releases. These non-LTS branches will be bug fix only and will be EOLed on the next release (similar to the YP branching behavior).
-
-### **Branch transitions**
-When YP is approaching release, meta-arm will attempt to stabilize master so that the releases can coincide. 
-* T-6 weeks - Email is sent to meta-arm mailing list notifying of upcoming code freeze of features to meta-arm
-* T-4 weeks - Code freeze to meta-arm. Only bug fixes are taken at this point.
-* T-0 - Official upstream release occurs. With no outstanding critical bugs, a new named branch is created based on the current meta-arm master branch. Previous named branches are now frozen and will not accept new patches (but will continue to be present for reference and legacy usage).
-
-## **Tagging**
-### **Branch Tagging**
-When each branch is released, a git tag with the Yocto Project version number will be added.  For example, `4.3`.  Also, this tag version number will be prepended with "yocto" in a duplicate tag (e.g., "yocto-4.3").
-
-Conciding with the Yocto Project release schedule, every branch which has one or more changes added to it in the previous 6 months will get a minor versioned tag (e.g., "4.3.1" and "yocto-4.3.1").
-
-### **BSP Release Tagging**
-BSP releases for those boards supported in meta-arm-bsp maybe have an additional tag to denote their software releases.  The tag will consist of the board name (in all capital letters), year, and month.  For example, "CORSTONE1000-2023.11".
-The release schedule for this is outside the standard Yocto Project release candence, but is generally encouraged to be as close to these releases as possible.  Similarily, it is recommended the BSP releases be based on the latest LTS branch.
-
-# **Relevant Links**
-<https://wiki.yoctoproject.org/wiki/Releases>
@@ -4,10 +4,10 @@ The `runfvp` tool in meta-arm makes it easy to run Yocto Project disk images ins

 ## Running images with `runfvp`

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

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

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

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

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

 ```
@@ -62,26 +55,16 @@ The name of the FVP binary itself, for example `fvp-base` uses `FVP_Base_RevC-2x

 The name of the recipe that provides the FVP executable set in `FVP_EXE`, for example `fvp-base` uses `fvp-base-a-aem-native`.  This *must* be a `-native` recipe as the binary will be executed on the build host.

-There are recipes for common FVPs in meta-arm already, and writing new recipes is trivial.  For FVPs which are free to download `fvp-base-a-aem.bb` is a good example. Some FVPs must be downloaded separately as they need an account on Arm's website.
+There are recipes for common FVPs in meta-arm already, and writing new recipes is trivial.  For FVPs which are free to download `fvp-base-a-aem.bb` is a good example. Some FVPs must be downloaded separately as they need an account on Arm's website, `fvp-base-r-aem.bb` is a good example of those.

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

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

 Parameters passed to the FVP with the `--parameter`/`-C` option.  These are expressed as variable flags so individual parameters can be altered easily. For example:

 ```
-FVP_CONFIG[bp.flashloader0.fname] = "fip-fvp.bin"
+FVP_CONFIG[bp.flashloader0.fname] = "${DEPLOY_DIR_IMAGE}/fip-fvp.bin"
 ```

 ### `FVP_DATA`
@@ -89,8 +72,8 @@ FVP_CONFIG[bp.flashloader0.fname] = "fip-fvp.bin"
 Specify raw data to load at the specified address, passed to the FVP with the `--data` option.  This is a space-separated list of parameters in the format `[INST=]FILE@[MEMSPACE:]ADDRESS`. For example:

 ```
-FVP_DATA = "cluster0.cpu0=Image@0x80080000 \
-            cluster0.cpu0=fvp-base-revc.dtb@0x83000000"
+FVP_DATA = "cluster0.cpu0=${DEPLOY_DIR_IMAGE}/Image@0x80080000 \
+            cluster0.cpu0=${DEPLOY_DIR_IMAGE}/fvp-base-revc.dtb@0x83000000"
 ```

 ### `FVP_APPLICATIONS`
@@ -98,7 +81,7 @@ FVP_DATA = "cluster0.cpu0=Image@0x80080000 \
 Applications to load on the cores, passed to the FVP with the `--application` option.  These are expressed as variable flags with the flag name being the instance and flag value the filename, for example:

 ```
-FVP_APPLICATIONS[cluster0] = "linux-system.axf"
+FVP_APPLICATIONS[cluster0] = "${DEPLOY_DIR_IMAGE}/linux-system.axf"
 ```

 Note that symbols are not allowed in flag names, so if you need to use a wildcard in the instance then you'll need to use `FVP_EXTRA_ARGS` and `--application` directly.
@@ -146,4 +129,3 @@ FVP_ENV_PASSTHROUGH = "ARMLMD_LICENSE_FILE FM_TRACE_PLUGINS"
 [FVP]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
 [tmux]: https://tmux.github.io/
 [INI]: https://docs.python.org/3/library/configparser.html
-[screen]: https://www.gnu.org/software/screen/
@@ -5,37 +5,30 @@ in `meta-arm/recipes-security/trusted-services`

 ## Secure Partitions recipes

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

 ### How to include TS SPs

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

 | Secure Partition  | MACHINE_FEATURE |
 | ----------------- | --------------- |
 | Attestation       | ts-attesation   |
 | Crypto            | ts-crypto       |
-| Firmware Update   | ts-fwu          |
-| fTPM              | ts-ftpm         |
 | Internal Storage  | ts-its          |
-| Logging           | ts-logging      |
 | Protected Storage | ts-storage      |
 | se-proxy          | ts-se-proxy     |
 | smm-gateway       | ts-smm-gateway  |
-| spm-test[1-4]     | optee-spmc-test |
+| spm-test[1-3]     | 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-tstee`.)
+   (Please see ` meta-arm/recipes-kernel/arm-ffa-tee`.)

   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.
@@ -43,93 +36,24 @@ Other steps depend on your machine/platform definition:

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

 3. trusted-firmware-a might require platform specific TF-A build parameters (SPD and SPMC details on the platform).
   See `meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend` for qemuarm64-secureboot machine
-   and in `meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-corstone1000.inc` for theCorstone1000 platform.
-
-4. Trusted Services supports an SPMC agonistic binary format. To build SPs to this format the `TS_ENV` variable is to be
-   set to `sp`. The resulting SP binaries should be able to boot under any FF-A v1.1 compliant SPMC implementation.
-
-### Example configurations
-
-The `meta-arm/ci` directory contains various TS focused [KAS][^7] configuration files:
-
-| File name | Description |
-|-----------|-------------|
-| ci/fvp-base-ts-ftpm.yml        |Enabling the fTPM SP on the fvp-base machine|
-| ci/fvp-base-ts.yml             |TS config for the fvp-base machine|
-| ci/qemuarm64-secureboot-ts.yml |TS config for quemuarm64-secureboot machine|
+   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.

 ## 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

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

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

 ------
 [^1]: https://trusted-services.readthedocs.io/en/integration/overview/index.html
@@ -138,10 +62,4 @@ development purposes. A more appropriate and comprehensive test suite should be

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

-[^4]: https://optee.readthedocs.io/en/latest/building/gits/optee_test.html
-
-[^5]: https://trusted-services.readthedocs.io/en/integration/services/tpm-service-description.html
-
-[^6]: https://optee.readthedocs.io/en/latest/architecture/spmc.html
-
-[^7]: https://kas.readthedocs.io
+[^4]: https://optee.readthedocs.io/en/latest/building/gits/optee_test.html
@@ -1,22 +0,0 @@
-header:
-  version: 14
-  includes:
-    - kas/corstone1000-base.yml
-    - kas/corstone1000-image-configuration.yml
-    - kas/corstone1000-firmware-only.yml
-    - kas/fvp-eula.yml
-
-env:
-  DISPLAY:
-  WAYLAND_DISPLAY:
-  XAUTHORITY:
-
-local_conf_header:
-  testimagefvp: |
-    IMAGE_CLASSES += "fvpboot"
-
-  mass-storage: |
-    # Ensure the Mass Storage device is absent
-    FVP_CONFIG[board.msd_mmc.p_mmc_file] = "invalid.dat"
-
-machine: corstone1000-a320-fvp
@@ -1,60 +1,39 @@
 header:
-  version: 14
+  version: 11

-distro: poky
+distro: poky-tiny

 defaults:
  repos:
-    branch: wrynose
+    refspec: mickledore

 repos:
-  bitbake:
-    url: https://git.openembedded.org/bitbake
-    branch: "2.18"
-    commit: 22021758e66737bcf68dfd2b74adc6a0cb1d42d9
-    layers:
-      bitbake: disabled
-
-  core:
-    url: https://git.openembedded.org/openembedded-core
-    commit: 06dd66e6220e5ce4ed4b9af4d8231ae5f0a8ce80
-    layers:
-      meta:
-
-  meta-yocto:
-    url: https://git.yoctoproject.org/meta-yocto
-    commit: 8251bdad5fda780a000fb41e6eda82eadf0fa39e
-    layers:
-      meta-poky:
-
  meta-arm:
    layers:
      meta-arm:
      meta-arm-bsp:
      meta-arm-toolchain:

+  poky:
+    url: https://git.yoctoproject.org/git/poky
+    refspec: 31dd418207f6c95ef0aad589cd03cd2a4c9a8bf2
+    layers:
+      meta:
+      meta-poky:
+      meta-yocto-bsp:
+
  meta-openembedded:
    url: https://git.openembedded.org/meta-openembedded
-    commit: 9af4488d46cb4fd4c0d2d64820c86225ebd6ac71
+    refspec: 5a01ab461c9bcabcbb2298236602373948f8f073
    layers:
      meta-oe:
      meta-python:
-      meta-perl:
-
-  meta-secure-core:
-    url: https://github.com/wind-river/meta-secure-core.git
-    commit: 07a99ae241acd488a2feda1ededf87dc70dfde80
-    layers:
-      meta-secure-core-common:
-      meta-signing-key:
-      meta-efi-secure-boot:

 local_conf_header:
  base: |
    CONF_VERSION = "2"
-
-  setup: |
    PACKAGE_CLASSES = "package_ipk"
+    LICENSE_FLAGS_ACCEPTED += "armcompiler"
    BB_NUMBER_THREADS ?= "16"
    PARALLEL_MAKE ?= "-j16"
    PACKAGECONFIG:append:pn-perf = " coresight"
@@ -62,4 +41,4 @@ local_conf_header:
 machine: unset

 target:
-  - corstone1000-flash-firmware-image
+  - corstone1000-image
@@ -1,9 +0,0 @@
-header:
-  version: 14
-
-local_conf_header:
-  extsys: |
-    MACHINE_FEATURES += "corstone1000-extsys"
-
-    # external system firmware
-    CORE_IMAGE_EXTRA_INSTALL:firmware += "external-system-elf"
@@ -1,23 +0,0 @@
---
-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"
@@ -1,22 +1,16 @@
 header:
-  version: 14
+  version: 11
  includes:
    - kas/corstone1000-base.yml
-    - kas/corstone1000-image-configuration.yml
-    - kas/corstone1000-firmware-only.yml
-    - kas/fvp-eula.yml
-
-env:
-  DISPLAY:
-  WAYLAND_DISPLAY:
-  XAUTHORITY:
-
-local_conf_header:
-  testimagefvp: |
-    IMAGE_CLASSES += "fvpboot"
-
-  mass-storage: |
-    # Ensure the Mass Storage device is absent
-    FVP_CONFIG[board.msd_mmc.p_mmc_file] = "invalid.dat"

 machine: corstone1000-fvp
+
+local_conf_header:
+    fvp-config: |
+        # Remove Dropbear SSH as it will not fit into the corstone1000 image.
+        IMAGE_FEATURES:remove = " ssh-server-dropbear"
+        INHERIT = " ${@bb.utils.contains('BUILD_ARCH', 'x86_64', 'fvpboot', '', d)}"
+        LICENSE_FLAGS_ACCEPTED:append = " Arm-FVP-EULA"
+
+target:
+  - corstone1000-image
@@ -1,52 +0,0 @@
-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"
-
-    # This guarantees module auto-loading support at boot
-    # by adding /etc/init.d/modutils.sh and /etc/rcS.d/ files
-    CORE_IMAGE_EXTRA_INSTALL:append = " modutils-initscripts"
-    DISTRO_FEATURES:append = " sysvinit"
-
-    # prevent the kernel image from being included in the intramfs rootfs
-    PACKAGE_EXCLUDE:firmware += "kernel-image-*"
-
-    # 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"
-
-  capsule: |
-    # These variables are set here since they are not defined in the arm-systemready-firmware recipe or under multiconfig mode.
-    CAPSULE_EXTENSION = "uefi.capsule"
-    CAPSULE_VERSION = "6"
-    CAPSULE_NAME = "${MACHINE}-v${CAPSULE_VERSION}"
@@ -1,8 +1,6 @@
 header:
-  version: 14
+  version: 11
  includes:
    - kas/corstone1000-base.yml
-    - kas/corstone1000-image-configuration.yml
-    - kas/corstone1000-firmware-only.yml

 machine: corstone1000-mps3
@@ -1,8 +0,0 @@
-# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
-
-header:
-  version: 14
-
-local_conf_header:
-  multicore: |
-    MACHINE_FEATURES += "corstone1000_smp"
@@ -1,13 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/debug.yml
-
-local_conf_header:
-  sshd: |
-    IMAGE_FEATURES += "ssh-server-dropbear"
-  fvp_sshkeys: |
-    CORE_IMAGE_EXTRA_INSTALL:append = " ssh-pregen-hostkeys"
-
-target:
-  - core-image-minimal
@@ -0,0 +1,47 @@
+header:
+  version: 11
+
+distro: poky-tiny
+
+defaults:
+  repos:
+    refspec: master
+
+repos:
+  meta-arm:
+    layers:
+      meta-arm:
+      meta-arm-bsp:
+      meta-arm-toolchain:
+
+  poky:
+    url: https://git.yoctoproject.org/git/poky
+    refspec: master
+    layers:
+      meta:
+      meta-poky:
+      meta-yocto-bsp:
+
+  meta-openembedded:
+    url: https://git.openembedded.org/meta-openembedded
+    refspec: master
+    layers:
+      meta-oe:
+      meta-python:
+
+local_conf_header:
+  base: |
+    CONF_VERSION = "2"
+    PACKAGE_CLASSES = "package_ipk"
+    LICENSE_FLAGS_ACCEPTED += "armcompiler"
+    BB_NUMBER_THREADS ?= "16"
+    PARALLEL_MAKE ?= "-j16"
+    PACKAGECONFIG:append:pn-perf = " coresight"
+  fvp-config: |
+    IMAGE_CLASSES:append = " ${@bb.utils.contains('BUILD_ARCH', 'x86_64', 'fvpboot', '', d)}"
+    LICENSE_FLAGS_ACCEPTED:append = " Arm-FVP-EULA"
+
+machine: corstone500
+
+target:
+  - core-image-minimal
@@ -1,16 +1,8 @@
 header:
-  version: 13
-  includes:
-    - kas/fvp-eula.yml
-
-env:
-  DISPLAY:
-  WAYLAND_DISPLAY:
-  XAUTHORITY:
-
+  version: 9

 distro: poky
-machine: fvp-base
+machine: fvp-baser-aemv8r64

 defaults:
  repos:
@@ -18,6 +10,8 @@ defaults:

 repos:
  meta-arm:
+    url: https://git.yoctoproject.org/git/meta-arm
+    path: layers/meta-arm
    layers:
      meta-arm:
      meta-arm-bsp:
@@ -30,6 +24,9 @@ repos:
      meta:
      meta-poky:

+env:
+  FVP_BASE_R_ARM_EULA_ACCEPT: "False"
+
 local_conf_header:
  base: |
    CONF_VERSION = "2"
@@ -37,7 +34,8 @@ local_conf_header:
    PACKAGECONFIG:remove:pn-qemu-system-native = "gtk+ sdl"
    EXTRA_IMAGE_FEATURES:append = " debug-tweaks ssh-server-openssh"
    CORE_IMAGE_EXTRA_INSTALL:append = " ssh-pregen-hostkeys"
-    IMAGE_CLASSES:append = " testimage fvpboot"
+    LICENSE_FLAGS_ACCEPTED:append = " ${@oe.utils.vartrue('FVP_BASE_R_ARM_EULA_ACCEPT', 'Arm-FVP-EULA', '', d)}"
+    IMAGE_CLASSES:append = " testimage"

 target:
  - core-image-minimal
@@ -0,0 +1,8 @@
+header:
+  version: 9
+  includes:
+    - kas/fvp-baser-aemv8r64-bsp.yml
+
+local_conf_header:
+  base-rt: |
+    PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
@@ -1,5 +0,0 @@
-header:
-  version: 13
-
-env:
-  ARM_FVP_EULA_ACCEPT:
@@ -9,19 +9,13 @@ BBFILE_COLLECTIONS += "meta-arm-bsp"
 BBFILE_PATTERN_meta-arm-bsp = "^${LAYERDIR}/"
 BBFILE_PRIORITY_meta-arm-bsp = "5"

-LAYERSERIES_COMPAT_meta-arm-bsp = "wrynose"
+LAYERSERIES_COMPAT_meta-arm-bsp = "mickledore"

 LAYERDEPENDS_meta-arm-bsp = "core meta-arm"
 # This won't be used by layerindex-fetch, but works everywhere else
-LAYERDEPENDS_meta-arm-bsp:append:corstone1000 = " meta-python openembedded-layer efi-secure-boot"
+LAYERDEPENDS_meta-arm-bsp:append:corstone1000 = " meta-python openembedded-layer"
 LAYERDEPENDS_meta-arm-bsp:append:musca-b1 = " meta-python"
 LAYERDEPENDS_meta-arm-bsp:append:musca-s1 = " meta-python"

 # Additional license directories.
 LICENSE_PATH += "${LAYERDIR}/custom-licenses"
-
-WARN_QA:append:layer-meta-arm-bsp = " patch-status"
-
-addpylib ${LAYERDIR}/lib oeqa
-
-IMAGE_ROOTFS_EXTRA_ARGS ?= ""
@@ -1,17 +0,0 @@
-#@TYPE: Machine
-#@NAME: corstone1000-a320-fvp machine
-#@DESCRIPTION: Machine configuration for Corstone1000 64-bit FVP with A320 CPU
-
-require conf/machine/include/corstone1000-a320.inc
-require conf/machine/corstone1000-fvp.conf
-
-# Ethos-U85 FVP configuration
-ETHOSU_NUM_MACS ?= "256"
-FVP_CONFIG[host.ethosu.num_macs] = "${ETHOSU_NUM_MACS}"
-
-# Reuse FVP recipe overrides
-MACHINEOVERRIDES .= ":corstone1000-fvp"
-
-# Override FVP executable provider and executable name.
-FVP_PROVIDER:corstone1000-a320-fvp ??= "fvp-corstone1000-a320-native"
-FVP_EXE:corstone1000-a320-fvp = "FVP_Corstone-1000-A320"
@@ -3,41 +3,28 @@
 #@DESCRIPTION: Machine configuration for Corstone1000 64-bit FVP
 require conf/machine/include/corstone1000.inc

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

 TFM_PLATFORM_IS_FVP = "TRUE"

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

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

 # FVP Parameters
-FVP_CONFIG[se.trustedBootROMloader.fname] ?= "trusted-firmware-m/bl1.bin"
+FVP_CONFIG[se.trustedBootROMloader.fname] ?= "${DEPLOY_DIR_IMAGE}/bl1.bin"
 FVP_CONFIG[board.xnvm_size] ?= "64"
 FVP_CONFIG[se.trustedSRAM_config] ?= "6"
 FVP_CONFIG[se.BootROM_config] ?= "3"
 FVP_CONFIG[board.hostbridge.interfaceName] ?= "tap0"
 FVP_CONFIG[board.smsc_91c111.enabled] ?= "1"
 FVP_CONFIG[board.hostbridge.userNetworking] ?= "true"
-FVP_CONFIG[board.hostbridge.userNetPorts] ?= "5555=5555,8080=80,2222=22"
+FVP_CONFIG[board.hostbridge.userNetPorts] ?= "5555=5555,8080=80,8022=22"
 FVP_CONFIG[board.se_flash_size] ?= "8192"
 FVP_CONFIG[diagnostics] ?= "4"
 FVP_CONFIG[disable_visualisation] ?= "true"
@@ -45,35 +32,20 @@ FVP_CONFIG[se.nvm.update_raw_image] ?= "0"
 FVP_CONFIG[se.cryptocell.USER_OTP_FILTERING_DISABLE] ?= "1"

 # Boot image
-FVP_DATA ?= "board.flash0=corstone1000-flash-firmware-image-${MACHINE}.wic@0x68000000"
+FVP_DATA ?= "board.flash0=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.wic@0x68000000"

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

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

 # MMC card configuration
 FVP_CONFIG[board.msd_mmc.card_type] ?= "SDHC"
 FVP_CONFIG[board.msd_mmc.p_fast_access] ?= "0"
-FVP_CONFIG[board.msd_mmc.diagnostics] ?= "0"
+FVP_CONFIG[board.msd_mmc.diagnostics] ?= "2"
 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] ?= "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_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"
@@ -6,9 +6,4 @@ require conf/machine/include/corstone1000.inc

 TFA_TARGET_PLATFORM = "fpga"

-# Unlike the FVP, MPS3 supports CoreSight
-MACHINE_FEATURES += "coresight"
-
-CORSTONE_1000_TYPE = "CORSTONE_1000_TYPE_CORTEX_A35_MPS3"
-
-WKS_FILE:firmware ?= "corstone1000-flash-firmware-mps3.wks.in"
+PLATFORM_IS_FVP = "FALSE"
@@ -0,0 +1,48 @@
+#@TYPE: Machine
+#@NAME: Corstone-500 machine
+#@DESCRIPTION: Machine configuration for the Corstone-500 platform
+
+require conf/machine/include/arm/armv7a/tune-cortexa5.inc
+
+# Corstone-500 is built against poky-tiny distro.
+# poky-tiny sets PREFERRED_PROVIDER_virtual/kernel to linux-yocto-tiny.
+# Since distro config is evaluated after the machine config, we need to
+# use the strongest override possible (forcevariable) so the
+# PREFERRED_PROVIDER_virtual/kernel specified in the machine config will
+# apply.
+#
+PREFERRED_PROVIDER_virtual/kernel:forcevariable = "linux-yocto"
+PREFERRED_VERSION_linux-yocto ?= "6.1%"
+
+EXTRA_IMAGEDEPENDS += "trusted-firmware-a u-boot"
+
+IMAGE_CLASSES += "wic_nopt"
+IMAGE_FEATURES += "debug-tweaks"
+IMAGE_FSTYPES:forcevariable = "cpio.gz squashfs wic wic.nopt"
+
+SERIAL_CONSOLES = "115200;ttyAMA0"
+
+# Corstone-500 u-boot configuration
+UBOOT_MACHINE = "corstone500_defconfig"
+UBOOT_IMAGE_ENTRYPOINT = "0x84000000"
+UBOOT_IMAGE_LOADADDRESS = "0x84000000"
+PREFERRED_VERSION_u-boot ?= "2023.01"
+
+# making sure EXTRA_IMAGEDEPENDS will be used while creating the image
+WKS_FILE_DEPENDS:append = " ${EXTRA_IMAGEDEPENDS}"
+
+WKS_FILE ?= "core-image-minimal.corstone500.wks"
+
+TEST_TARGET = "OEFVPSerialTarget"
+TEST_SUITES = "linuxboot"
+
+FVP_PROVIDER ?= "fvp-corstone500-native"
+FVP_EXE ?= "FVP_Corstone-500"
+FVP_CONFIG[board.flashloader0.fname] ?= "${DEPLOY_DIR_IMAGE}/bl1.bin"
+FVP_DATA ?= "css.cluster.cpu0=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.wic.nopt@0x80000000"
+FVP_CONSOLE ?= "terminal_0"
+FVP_TERMINALS[css.terminal_0] ?= "console"
+FVP_TERMINALS[css.terminal_1] ?= ""
+
+# Disable openssl in kmod to shink the initramfs size
+PACKAGECONFIG:remove:pn-kmod = "openssl"
@@ -4,72 +4,16 @@
 #@NAME: Armv8-A Base Platform FVP machine
 #@DESCRIPTION: Machine configuration for Armv8-A Base Platform FVP model

-require conf/machine/include/arm/arch-armv8-5a.inc
+require conf/machine/include/fvp-common.inc
+require conf/machine/include/arm/arch-armv8a.inc

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

-ARM_SYSTEMREADY_FIRMWARE = "trusted-firmware-a:do_deploy"
-ARM_SYSTEMREADY_ACS_CONSOLE = "default"
-EXTRA_IMAGEDEPENDS = "${ARM_SYSTEMREADY_FIRMWARE}"
-
-MACHINE_FEATURES = "efi vfat"
-
-IMAGE_NAME_SUFFIX = ""
-IMAGE_FSTYPES += "wic"
-WKS_FILE ?= "efi-disk.wks.in"
-
-SERIAL_CONSOLES = "115200;ttyAMA0"
-
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-KERNEL_DTB_NAME = "fvp-base-revc.dtb"
-KERNEL_DEVICETREE = "arm/${KERNEL_DTB_NAME}"
-KERNEL_IMAGETYPE = "Image"
-
-EXTRA_IMAGEDEPENDS += "trusted-firmware-a"
+PREFERRED_VERSION_u-boot ?= "2023.01"

 # FVP u-boot configuration
-UBOOT_MACHINE = "vexpress_fvp_defconfig"
+UBOOT_MACHINE = "vexpress_aemv8a_semi_defconfig"

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

-# As this is a virtual target that will not be used in the real world there is
-# no need for real SSH keys.
-MACHINE_EXTRA_RRECOMMENDS += "ssh-pregen-hostkeys"
-
-TEST_TARGET = "OEFVPTarget"
-TEST_TARGET_IP = "127.0.0.1:2222"
-DEFAULT_TEST_SUITES:append = " fvp_boot fvp_devices"
-TEST_FVP_DEVICES ?= "rtc watchdog networking virtiorng cpu_hotplug"
-
-FVP_PROVIDER ?= "fvp-base-a-aem-native"
-FVP_EXE ?= "FVP_Base_RevC-2xAEMvA"
-FVP_CONFIG[bp.ve_sysregs.exit_on_shutdown] ?= "1"
-FVP_CONFIG[bp.virtio_net.enabled] ?= "1"
-FVP_CONFIG[bp.virtio_net.hostbridge.userNetworking] ?= "1"
-# Tell testimage to connect to localhost:2222, and forward that to SSH in the FVP.
-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] ?= "trusted-firmware-a/bl1.bin"
-FVP_CONFIG[bp.flashloader0.fname] ?= "trusted-firmware-a/fip.bin"
-FVP_CONFIG[bp.virtioblockdevice.image_path] ?= "${IMAGE_NAME}.wic"
-
-# FVP Base default is 8.0, so there is no has_arm_v8-0 for it.  However, this is needed for every version after.  So set this accordingly
-FVP_EXTRA_ARGS = "--parameter cluster0.has_arm_v${ARM_ISA_MAJOR}-${ARM_ISA_MINOR}=1 --parameter cluster1.has_arm_v${ARM_ISA_MAJOR}-${ARM_ISA_MINOR}=1"
-FVP_EXTRA_ARGS += "${@bb.utils.contains('TUNE_FEATURES', 'sve', '--parameter cluster0.has_sve=1 --parameter cluster1.has_sve=1', '', d)}"
-FVP_EXTRA_ARGS += "${@bb.utils.contains('TUNE_FEATURES', 'sve2', '--parameter cluster0.sve.has_sve2=1 --parameter cluster1.sve.has_sve2=1', '', d)}"
-
-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"
@@ -0,0 +1,63 @@
+# Configuration for Fixed Virtual Platform BaseR AEMv8r64 Machine
+
+#@TYPE: Machine
+#@NAME: FVP BaseR AEMv8r64 Machine
+#@DESCRIPTION: Machine configuration for FVP BaseR AEMv8r64
+
+require conf/machine/include/arm/armv8r/arch-armv8r64.inc
+
+EXTRA_IMAGEDEPENDS += "boot-wrapper-aarch64"
+
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_VERSION_u-boot ?= "2022.10"
+
+KERNEL_IMAGETYPE = "Image"
+KERNEL_DEVICETREE = "arm/fvp-baser-aemv8r64.dtb"
+
+UBOOT_MACHINE ?= "vexpress_aemv8r_defconfig"
+
+SERIAL_CONSOLES = "115200;ttyAMA0"
+
+IMAGE_CLASSES:append = " fvpboot"
+IMAGE_FSTYPES += "wic"
+WKS_FILE ?= "efi-disk.wks.in"
+EFI_PROVIDER ?= "grub-efi"
+MACHINE_FEATURES:append = " efi"
+
+# As this is a virtual target that will not be used in the real world there is
+# no need for real SSH keys.
+MACHINE_EXTRA_RRECOMMENDS += "ssh-pregen-hostkeys"
+
+# testimage configuration
+TEST_TARGET = "OEFVPSerialTarget"
+TEST_SUITES = "linuxboot"
+TEST_TARGET_IP ?= "127.0.0.1:8022"
+TEST_SERVER_IP ?= "127.0.1.1"
+
+FVP_EXTRA_ARGS = "-a cluster0*=${DEPLOY_DIR_IMAGE}/linux-system.axf"
+FVP_PROVIDER ?= "fvp-base-r-aem-native"
+FVP_EXE ?= "FVP_BaseR_AEMv8R"
+FVP_CONSOLE ?= "terminal_0"
+
+# FVP parameters
+FVP_CONFIG[bp.exclusive_monitor.monitor_access_level] ?= "2"
+FVP_CONFIG[bp.refcounter.non_arch_start_at_default] ?= "1"
+FVP_CONFIG[bp.refcounter.use_real_time] ?= "1"
+FVP_CONFIG[bp.ve_sysregs.exit_on_shutdown] ?= "1"
+FVP_CONFIG[bp.virtio_net.enabled] ?= "1"
+FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] ?= "8022=22"
+FVP_CONFIG[bp.virtio_net.hostbridge.userNetworking] ?= "1"
+FVP_CONFIG[bp.virtio_net.secure_accesses] = "1"
+FVP_CONFIG[bp.virtio_rng.enabled] ?= "1"
+FVP_CONFIG[bp.virtio_rng.secure_accesses] = "1"
+FVP_CONFIG[bp.virtioblockdevice.image_path] ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.wic"
+FVP_CONFIG[bp.virtioblockdevice.secure_accesses] = "1"
+FVP_CONFIG[cache_state_modelled] ?= "0"
+FVP_CONFIG[cci400.force_on_from_start] = "1"
+FVP_CONFIG[cluster0.gicv3.cpuintf-mmap-access-level] ?= "2"
+FVP_CONFIG[cluster0.gicv3.extended-interrupt-range-support] ?= "1"
+FVP_CONFIG[cluster0.gicv3.SRE-EL2-enable-RAO] ?= "1"
+FVP_CONFIG[cluster0.gicv3.SRE-enable-action-on-mmap] ?= "2"
+FVP_CONFIG[cluster0.has_aarch64] ?= "1"
+FVP_CONFIG[gic_distributor.GICD_CTLR-DS-1-means-secure-only] ?= "1"
+FVP_CONFIG[gic_distributor.has-two-security-states] ?= "0"
@@ -0,0 +1,10 @@
+require conf/machine/include/arm/arch-armv8r.inc
+
+TUNE_FEATURES:tune-armv8r            =+ "aarch64"
+PACKAGE_EXTRA_ARCHS:tune-armv8r      =+ "aarch64"
+BASE_LIB:tune-armv8r                 = "lib64"
+BASE_LIB:tune-armv8r-crc             = "lib64"
+BASE_LIB:tune-armv8r-crypto          = "lib64"
+BASE_LIB:tune-armv8r-simd            = "lib64"
+BASE_LIB:tune-armv8r-crc-simd        = "lib64"
+BASE_LIB:tune-armv8r-crc-crypto-simd = "lib64"
@@ -1,4 +0,0 @@
-# Cortex-A320 variant of the Corstone-1000 platform.
-MACHINEOVERRIDES =. "corstone1000-a320:"
-MACHINE_FEATURES += "cortexa320"
-OVERRIDES .= ":cortexa320"
@@ -1,6 +0,0 @@
-
-FVP_CONSOLES[extsys] = "extsys_terminal"
-
-FVP_CONFIG[extsys_harness0.extsys_flashloader.fname] = "es_flashfw.bin"
-
-FVP_TERMINALS[extsys0.extsys_terminal] = "Cortex M3"
@@ -1,75 +1,79 @@
-TUNE_FILE = "conf/machine/include/arm/armv8a/tune-cortexa35.inc"
-TUNE_FILE:cortexa320 = "conf/machine/include/arm/arch-armv9-2a.inc"
-require ${TUNE_FILE}
+require conf/machine/include/arm/armv8a/tune-cortexa35.inc

 MACHINEOVERRIDES =. "corstone1000:"

-# TF-M
-PREFERRED_VERSION_trusted-firmware-m ?= "2.2.%"
-
 # TF-A
 TFA_PLATFORM = "corstone1000"
-PREFERRED_VERSION_trusted-firmware-a ?= "2.14.%"
-PREFERRED_VERSION_tf-a-tests ?= "2.14.%"
+EXTRA_IMAGEDEPENDS += "trusted-firmware-a"

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

-# optee
-PREFERRED_VERSION_optee-os ?= "4.9.%"
-PREFERRED_VERSION_optee-client ?= "4.9.%"
+# TF-M
+EXTRA_IMAGEDEPENDS += "virtual/trusted-firmware-m"
+
+# 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"
+
+# u-boot
+PREFERRED_VERSION_u-boot ?= "2023.01"
+EXTRA_IMAGEDEPENDS += "u-boot"
+
+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.20.%"
+PREFERRED_VERSION_optee-client ?= "3.18.%"
+EXTRA_IMAGEDEPENDS += "optee-os"
+OPTEE_ARCH = "arm64"
+OPTEE_BINARY = "tee-pager_v2.bin"

-# 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"
+TS_PLATFORM = "arm/corstone1000"
+TS_SP_SE_PROXY_CONFIG = "corstone1000"

-# U-Boot
-PREFERRED_VERSION_u-boot ?= "2025.10"
-MACHINE_FEATURES += "efi"
-EFI_PROVIDER ?= "grub-efi"
-
-# Grub
-LINUX_KERNEL_ARGS ?= "earlycon=pl011,0x1a510000 console=ttyAMA0,115200"
-GRUB_LINUX_APPEND ?= "${LINUX_KERNEL_ARGS}"
-IMAGE_CMD:wic[vardeps] += "GRUB_LINUX_APPEND"
+# External System(Cortex-M3)
+EXTRA_IMAGEDEPENDS += "external-system"

 # Linux kernel
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "6.19%"
-KERNEL_IMAGETYPE = "Image"
-KERNEL_IMAGETYPE:firmware = "Image.gz"
+PREFERRED_PROVIDER_virtual/kernel:forcevariable = "linux-yocto"
+PREFERRED_VERSION_linux-yocto = "6.1%"
+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"
+
 # 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"
-
 # making sure EXTRA_IMAGEDEPENDS will be used while creating the image
 WKS_FILE_DEPENDS:append = " ${EXTRA_IMAGEDEPENDS}"

-# 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}"
+WKS_FILE ?= "corstone1000-image.corstone1000.wks"

-ARM_SYSTEMREADY_FIRMWARE = "${FIRMWARE_DEPLOYMENT}:do_deploy \
-                            corstone1000-esp-image:do_image_complete \
-                           "
-ARM_SYSTEMREADY_ACS_CONSOLE ?= "default"
-
-# Workaround IMAGE_ROOTFS_EXTRA_SPACE being ignored when images are repacked
-IMAGE_ROOTFS_EXTRA_ARGS += "--extra-filesystem-space ${@${IMAGE_ROOTFS_EXTRA_SPACE}}K"
-
-# Enable Authenticated variable support in SmmGW
-SMMGW_AUTH_VAR = "1"
-# Use MbedTLS build into SmmGW for authentication related crypto operations.
-SMMGW_INTERNAL_CRYPTO = "1"
+# Disable openssl in kmod to shink the initramfs size
+PACKAGECONFIG:remove:pn-kmod = "openssl"
@@ -0,0 +1,48 @@
+# FVP common parameters
+
+#
+# Capturing FVP common configurations (Armv8-A Base Platform FVP,
+# Armv8-A Foundation Platform and Armv7-A Base Platform FVP).
+#
+
+MACHINE_FEATURES = "optee"
+
+IMAGE_FSTYPES += "wic"
+WKS_FILE ?= "fvp-base.wks"
+
+SERIAL_CONSOLES = "115200;ttyAMA0"
+
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+
+KERNEL_DEVICETREE = "arm/fvp-base-revc.dtb"
+
+EXTRA_IMAGEDEPENDS += "trusted-firmware-a"
+
+# As this is a virtual target that will not be used in the real world there is
+# no need for real SSH keys.
+MACHINE_EXTRA_RRECOMMENDS += "ssh-pregen-hostkeys"
+
+TEST_TARGET = "OEFVPTarget"
+TEST_TARGET_IP = "127.0.0.1:8022"
+
+FVP_PROVIDER ?= "fvp-base-a-aem-native"
+FVP_EXE ?= "FVP_Base_RevC-2xAEMvA"
+FVP_CONFIG[bp.ve_sysregs.exit_on_shutdown] ?= "1"
+FVP_CONFIG[bp.virtio_net.enabled] ?= "1"
+FVP_CONFIG[bp.virtio_net.hostbridge.userNetworking] ?= "1"
+# Tell testimage to connect to localhost:8022, and forward that to SSH in the FVP.
+FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] = "8022=22"
+FVP_CONFIG[cache_state_modelled] ?= "0"
+FVP_CONFIG[bp.secureflashloader.fname] ?= "${DEPLOY_DIR_IMAGE}/bl1-fvp.bin"
+FVP_CONFIG[bp.flashloader0.fname] ?= "${DEPLOY_DIR_IMAGE}/fip-fvp.bin"
+FVP_CONFIG[bp.virtioblockdevice.image_path] ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.wic"
+# Set the baseline to ARMv8.4, as the default is 8.0.
+FVP_CONFIG[cluster0.has_arm_v8-4] = "1"
+FVP_CONFIG[cluster1.has_arm_v8-4] = "1"
+FVP_CONSOLE ?= "terminal_0"
+FVP_DATA ?= "cluster0.cpu0=${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}@0x80080000 \
+             cluster0.cpu0=${DEPLOY_DIR_IMAGE}/fvp-base-revc.dtb@0x8fc00000"
+FVP_TERMINALS[bp.terminal_0] ?= "Console"
+FVP_TERMINALS[bp.terminal_1] ?= ""
+FVP_TERMINALS[bp.terminal_2] ?= ""
+FVP_TERMINALS[bp.terminal_3] ?= ""
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Mariam Elshakfy	9bcc166bd5	arm-bsp/n1sdp: Enable OP-TEE cache in N1SDP This change enables N1SDP cache to improve performance by removing this patch: HACK-disable-instruction-cache-and-data-cache.patch Signed-off-by: Mariam Elshakfy <mariam.elshakfy@arm.com>	2023-10-19 21:14:39 -05:00
Mariam Elshakfy	0e35e4b951	arm-bsp/n1sdp: Move OP-TEE to DDR4 Since the original location of OP-TEE in DDR3 observes a HW issue when cache is enabled, this change moves OP-TEE to run from DDR4. Patches are added to TF-A to reflect that change and the used region is also reserved in UEFI (EDK2) to protect against allocations by UEFI applications. OP-TEE size is modified for consistency across all patches to be 32 MB (0x02000000) instead of (0x02008000). Signed-off-by: Mariam Elshakfy <mariam.elshakfy@arm.com>	2023-10-19 21:14:39 -05:00
Jon Mason	bbe2d63100	arm/linux-yocto: remove defconfig patch Mikko Rapeli upstreamed the patch for the Nuvoton defconfig issue and it has been pulled back the 6.1 kernel. So, it is no longer needed here. Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-10-19 21:14:39 -05:00
Vikas Katariya	2b57548b36	arm-bsp/corstone1000: Fix RSA key generation issue This support is for Cassini distro using Corstone-1000 platform. When running parsec test, it reports an error `PSA_ERROR_DATA_INVALID (-153)`. This is related to `ITS_MAX_ASSET_SIZE` configuration which is been set to 512 on the secure enclave (TF-M), which defines the max asset size and it overflows when running the parsec tests. The key is generated, but when it is asked to store via `psa_its_set` it returns `PSA_ERROR_INVALID_ARGUMENT (-135)`, which then propagates to `PSA_ERROR_DATA_INVALID (-153)` Increasing the `ITS_MAX_ASSET_SIZE` to 2048 solves this issue. Signed-off-by: Vikas Katariya <vikas.katariya@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-10-16 09:28:49 -04:00
Jon Mason	c6380674f5	arm/trusted-services: add SRCREV_FORMAT SRCREV_FORMAT is now required. Add that to address the build breakage. Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-10-06 09:23:53 -04:00
Jon Mason	6e199b354e	README: remove reference to meta-arm-autonomy Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-10-01 16:01:33 -04:00
Abdellatif El Khlifi	7c67197694	arm-bsp/trusted-firmware-a: corstone1000: enable ERRATA_A35_855472 enable errata 855472 for Cortex-A35 in Corstone-1000 Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-09-29 11:35:27 -04:00
Robbie Cao	85b0e80e7d	arm/recipes-kernel: Add preempt-rt support for generic-arm64 Add kernel configuration necessary to build an image with preempt-rt support for generic-arm64. And tweak kernel configuration for preempt-rt kernel. Signed-off-by: Robbie Cao <robbie.cao@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-08-14 10:26:48 -04:00
Jon Mason	821fa15a73	arm/linux-yocto: move 6.1 patches to a unique bbappend Move the 3 patches only needed by the 6.1 kernel into a unique bbappend The defconfig changes cannot be moved into a config fragment because they only exist in the defconfig file (because the patches that integrated their functionality into the kernel were not merged). Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-08-14 10:25:36 -04:00
Jon Mason	18edb7bcff	CI: remove master refspec for meta-virtualization yml file Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-08-14 09:54:23 -04:00
Adam Johnston	10c355b9c7	arm-bsp/trusted-firmware-a: Reserve OP-TEE memory from NWd on N1SDP The physical memory which is used to run OP-TEE on the N1SDP is known to the secure world via TOS_FW_CONFIG, but it may not be known to the normal world. As a precaution, explicitly reserve this memory via NT_FW_CONFIG to prevent the normal world from using it. This is not required on most platforms as the Trusted OS is run from secure RAM. Signed-off-by: Adam Johnston <adam.johnston@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-07-27 09:44:10 -04:00
Abdellatif El Khlifi	1a15a5b052	kas: set the SHAs for 2023.06 release set poky and meta-openembedded SHAs Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-07-06 13:35:20 -04:00
Abdellatif El Khlifi	0bf2afab93	arm-bsp/documentation: corstone1000: update user guide Adding extra details to corstone1000 user guide. Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Signed-off-by: Emekcan Aras <Emekcan.Aras@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-07-06 13:34:54 -04:00
Abdellatif El Khlifi	c1201c0c3a	arm-bsp/documentation: corstone1000: update the release note Updates the release note copyright. Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Signed-off-by: Emekcan Aras <Emekcan.Aras@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-07-06 13:34:54 -04:00
Abdellatif El Khlifi	fd7cb4d462	arm-bsp/doc: corstone1000: Update the software architecture document Align the document with the current design. Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>	2023-06-27 09:28:42 +01:00
Abdellatif El Khlifi	7d4cc90156	arm-bsp/documentation: corstone1000: Update change log Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>	2023-06-27 09:28:42 +01:00
Tomás González	1bfb03f9a6	arm-bsp/documentation: corstone1000: Update the release notes Update the release notes with Known Issues and Limitations. Signed-off-by: Tomás González <tomasagustin.gonzalezorlando@arm.com>	2023-06-27 09:28:42 +01:00
Tomás González	bef3c42e38	arm-bsp/documentation: corstone1000: Update the user guide Signed-off-by: Tomás González <tomasagustin.gonzalezorlando@arm.com> Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>	2023-06-27 09:28:42 +01:00
Emekcan Aras	779594c5d8	arm-bsp/trusted-services: corstone1000: Fix Capsule Update Adds missing update service definitions for using stateless platform services and initializes the capsule udpate provider in se-proxy-sp for corstone1000. Signed-off-by: Emekcan Aras <emekcan.aras@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-22 09:33:11 -04:00
Emekcan Aras	bd0c162e37	arm-bsp/trusted-services: corstone1000: Fix PSA_RAW_KEY agreement test Adds missing compilation option to fix psa_raw_key_aggrement test for corstone1000. Signed-off-by: Emekcan Aras <emekcan.aras@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-22 09:33:11 -04:00
Emekcan Aras	4a946ac8de	arm-bsp/u-boot: corstone1000: Fix u-boot compilation warnings From: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> Signed-off-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-22 09:33:11 -04:00
Emekcan Aras	d0b423c63c	arm-bsp/optee-os:corstone1000: Drop SPMC non secure interrupt patches From: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> These 2 patches causes the secure world to enter into an infinite loop when the PSA arch tests are triggered. This is a temporary fix and the issue needs to be investigated before the patches can be enabled. Signed-off-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-22 09:33:11 -04:00
Emekcan Aras	5024b767e3	arm-bsp/trusted-services: corstone1000: GetNextVariableName Fix This patch is required to handle one of the corner cases of the GetNextVariableName EFI service as specified in the UEFI spec. Signed-off-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-22 09:33:11 -04:00
Emekcan Aras	00bff355e5	arm-bsp/u-boot: corstone1000: Enable EFI set/get time services From: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> This patch adds the required configs to the corstone1000 u-boot defconfig to enable the EFI services. This is done to fix the SCT failure reported by the SetTime_Conf and SetTime_Func. Signed-off-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-22 09:33:11 -04:00
Emekcan Aras	4a7198a135	arm-bsp/u-boot: corstone1000: Fix EFI multiple protocol install failure From: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> The patch fixes the ACS InstallMultipleProtocolInterfaces_Conf failures in corstone1000 platform by dropping a workaround u-boot patch. The NVMXIP initialization had some issues during u-boot boot stage which led to the workaround patch. Upstream-Status: Pending [Not submitted to upstream yet] Signed-off-by: Emekcan Aras <emekcan.aras@arm.com> Signed-off-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-22 09:33:11 -04:00
Denys Dmytriyenko	7bd239d4f3	optee-os: do not explicitly set CFG_MAP_EXT_DT_SECURE=y CFG_MAP_EXT_DT_SECURE=y should be set per platform, as it requires CFG_DT=y to also be set, which is not the case for all the platforms out there using optee-os. Moreover CFG_MAP_EXT_DT_SECURE is already being set conditionally in optee-os-ts. Signed-off-by: Denys Dmytriyenko <denys@konsulko.com> Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:47 -04:00
Adam Johnston	b1a9fd76be	CI: Platform specific Trusted Services config Split trusted-services.xml into qemuarm64-secureboot-ts.yml and n1sdp-ts.yml as collection of Trusted Services which can be tested on each platform has diverged. Signed-off-by: Adam Johnston <adam.johnston@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Rui Miguel Silva	58a97781d5	arm-bps/corstone1000: setup trusted service proxy configuration Make sure we setup the new variable for the configuration of the SE-Proxy service for our machine. This will trigger the right configuration building trusted services and all psa-arch test pass as before. Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Gyorgy Szing	e995c42311	optee-os: unblock NWd interrupts Update Trusted Services and backport an OP-TEE update which allows interrupting the SPs by NWd interrupts. This solves the kernel stall problems which are due to long cryptographic operations being executed in the SWd. Signed-off-by: Gyorgy Szing <Gyorgy.Szing@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Gyorgy Szing	5e05b281f4	arm/trusted-services: fix nanopb build error The nanopb build step randomly fails in the yocto CI due to a race condition. This change adds a patch file to disable parallel build for nanopb. This is a temporary workaround and a proper fix will be up-streamed int he future. Signed-off-by: Gyorgy Szing <Gyorgy.Szing@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Rui Miguel Silva	cb811a559b	arm-bsp/trusted-services: remove merged patches for corstone1000 Patch related with the changes to support the in/out_vec modifications in TF-M v1.7 was merged in upstream trusted-services integration branch. So, drop this 3 out of tree patches not needed to be applied any more. Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Gyorgy Szing	0d7ee992c1	arm/trusted-services: disable psa-iat on qemuarm64-secureboot TF-A v2.8 does not support measured boot and FF-A which is mandatory for PSA Initial Attestation SP to work correctly. Signed-off-by: Gyorgy Szing <Gyorgy.Szing@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Gyorgy Szing	45206b21b9	trusted-services: update documentation Add information related to SPMC tests and fix stale links. Signed-off-by: Gyorgy Szing <Gyorgy.Szing@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Rui Miguel Silva	5c19e4a87a	arm-bsp/trusted-services:corstone1000: remove already merged patches Remove already merged patches in trusted services integration branch to avoid clash during apply patch stage and rebase the remaining patches. Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Gyorgy Szing	065e86ab5f	arm/oeqa: enable OP-TEE SPMC tests Run the ffa_spmc test group of xtest if the optee-spmc-test machine feature is enabled. Signed-off-by: Anton Antonov <Anton.Antonov@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Gyorgy Szing	b3c96e3fc3	optee-os: enable SPMC test Add ta-devkit and optee-test. Change configuration to enable building and deploying OP-TEE SPMC tests. Signed-off-by: Gyorgy Szing <Gyorgy.Szing@arm.com> Signed-off-by: Anton Antonov <Anton.Antonov@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Gyorgy Szing	48abf0167d	optee-test: backport SWd ABI compatibility changes The ABI used by the arm-ffa-user driver to call into the SWd changed. The change was driven by the MM over FF-A ABI implementation which is used by SmmGW SP and uefi-test. uefi-test uses the same arm-ffa-user driver as xtest hence xtest needs to be updated to use the new driver. This xtest change is already merged up-stream but after v3.20, which is used here. This change adds backported xtest changes as carried patches. Signed-off-by: Gyorgy Szing <Gyorgy.Szing@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Gyorgy Szing	adea344855	arm/trusted-firmware-a: Add TOS_FW_CONFIG handling for quemu This change: - cherry-picks TF-A changes from master which implement passing TOS_FW_CONFIG DTB from the FIP package to the trusted OS. - add an OP-TEE SPMC specific SPMC manifest file - configures TF-A to build the manifest, add it to the FIP package and pass it to OP-TEE as a boot argument. This functionality needs matching changes in OPTEE (OP-TEE v3.21 or v3.20 + carried patches.) Signed-off-by: Gyorgy Szing <Gyorgy.Szing@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Gyorgy Szing	809d2b43f9	optee-os: Add support for TOS_FW_CONFIG on qemu OP-TEE SPMC v3.20 and TF-A v2.8 is incompatible on qemu, and OP-TEE panics during boot because having an SPMC manifest passed to the SPMC is mandatory since v3.20. TF-A and OP-TEE upstream already fixed this issue by modifying the ABI between the SPMD and SPMC. Moreover qemu support in TF-A has been extended to allow building an SPMC manifest DTS file, and loading it from the FIP package. This change adds the needed OP-TEE fixes as carried patches. The TF-A change will be added in the next commit. Signed-off-by: Gyorgy Szing <Gyorgy.Szing@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Anton Antonov	15d6b7c4e9	arm/oeqa: Make ts-service-test config match selected SPs Split tests to groups, and enable groups based on machine features set. This allows limiting tests to testing deployed SPs only. Signed-off-by: Anton Antonov <Anton.Antonov@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Gyorgy Szing	2ffe50d4b5	optee-os: remove v3.18 pin of OP-TEE on qemuarm64-secureboot To enable up-to date version of Trusted Services op-tee v3.20 or newer is needed. Signed-off-by: Gyorgy Szing <Gyorgy.Szing@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Gyorgy Szing	b25e1ef90d	arm/trusted-services: update TS version This change updates to latest available version of Trusted Services. List of changes: - adapt SP recipes to file structure changes and support for "configurations". In TS each SP can be built in various different setups to allow adapting to platform and integration specific differences. - MbedTLS dependency has been updated to v3.3.0. - This needs new python dependencies are required in the build environment. - psa-acs was updated to a matching version. - do_patch() has been updated to support the MbedTLS patch added in TS. - Update TS dependency patching method to use git instead of patch. - Downgrade nanopb to match up-stream dependency version. Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by: Gyorgy Szing <Gyorgy.Szing@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-14 09:17:32 -04:00
Abdellatif El Khlifi	8db460fa5d	arm-bsp/u-boot: corstone1000: upgrade NVMXIP support The patchset has been merged in U-Boot master (https://github.com/u-boot/u-boot/commit/c9c2c95d4cd27fe0cd41fe13a863899d268f973c) This commit upgrades the NVMXIP patches with the merged ones. Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-13 10:08:53 -04:00
Emekcan Aras	36f77ab664	arm-bsp/u-boot: corstone1000: enable PSCI reset Even though corstone1000 platform does not support the entire PSCI APIs, it relys on PSCI reset interface for system reset. The name of this config changed in the new version of u-boot. This enables PSCI reset, so the system can be resetted in u-boot again. Signed-off-by: Emekcan Aras <emekcan.aras@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-06-06 11:00:23 -04:00
Abdellatif El Khlifi	6850977577	kas: corstone1000: set branches to mickledore point poky/meta-openembedded to mickledore Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-05-16 13:00:10 -04:00
Emekcan Aras	91b504e686	arm-bsp/wic: corstone1000: Fix and limit the partition size for corstone1000 It fixes and limits the partition size to fix capsule update feature after the GPT changes. The partitions in the second bank needs to have correct size and the partitions in first bank should have a fixed size since corstone1000 does not support partial update and has a limited flash to support variable size. Signed-off-by: Emekcan Aras <emekcan.aras@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-05-15 13:00:16 -04:00
Emekcan Aras	50624c6f2f	arm-bsp/trusted-firmware-m: Align Capsule Update with GPT changes This patch aligns capsule update feature in tfm with GPT/BL1 changes. Adjusts BL2 flash and data size and adds missing CRC checks. Signed-off-by: Emekcan Aras <emekcan.aras@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>	2023-05-15 13:00:16 -04:00