Revert "arm-bsp/tc0: Enable verified u-boot"

This reverts commit 29cee51f84.
Revert "arm-bsp/u-boot: update SHA for tc0"
2026-07-18 16:37:08 +00:00 · 2021-04-22 23:27:47 +01:00 · 2021-04-22 23:24:10 +01:00 · 2021-04-22 23:23:34 +01:00 · 2021-04-22 23:23:13 +01:00 · 2021-04-22 23:22:02 +01:00
1054 changed files with 64985 additions and 30583 deletions
@@ -1,2 +0,0 @@
-__pycache__
-build
@@ -1,160 +1,83 @@
-image: ${MIRROR_GHCR}/siemens/kas/kas:4.0
-
-variables:
-  CPU_REQUEST: ""
-  DEFAULT_TAG: ""
-  CACHE_DIR: $CI_BUILDS_DIR/persist
-  MIRROR_GHCR: ghcr.io
-  # These are needed as the k8s executor doesn't respect the container entrypoint
-  # by default
-  FF_KUBERNETES_HONOR_ENTRYPOINT: 1
-  FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY: 0
-  ACS_TEST: 0
-  ACS_TAG: ""
+# Use our custom Crops-derived image
+image: $CI_REGISTRY/$CI_PROJECT_NAMESPACE/yocto-builder:master

+  # First do a common bootstrap, and then build all the targets
 stages:
-  - prep
+  - bootstrap
  - build

 # Common job fragment to get a worker ready
 .setup:
-  tags:
-    - $DEFAULT_TAG
  stage: build
-  interruptible: true
  variables:
    KAS_WORK_DIR: $CI_PROJECT_DIR/work
-    KAS_REPO_REF_DIR: $CACHE_DIR/repos
-    SSTATE_DIR: $CACHE_DIR/sstate
-    DL_DIR: $CACHE_DIR/downloads
-    BB_LOGCONFIG: $CI_PROJECT_DIR/ci/logging.yml
-    TOOLCHAIN_DIR: $CACHE_DIR/toolchains
-    IMAGE_DIR: $CI_PROJECT_DIR/work/build/tmp/deploy/images
-    TOOLCHAIN_LINK_DIR: $CI_PROJECT_DIR/work/build/toolchains
+    SSTATE_DIR: $CI_BUILDS_DIR/persist/sstate
+    DL_DIR: $CI_BUILDS_DIR/persist/downloads
+    BB_LOGCONFIG: $CI_PROJECT_DIR/kas/logging.yml
  before_script:
    - echo KAS_WORK_DIR = $KAS_WORK_DIR
    - echo SSTATE_DIR = $SSTATE_DIR
    - echo DL_DIR = $DL_DIR
-    - rm -rf $KAS_WORK_DIR
-    - mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
-    # Must do this here, as it's the only way to make sure the toolchain is installed on the same builder
-    - ./ci/get-binary-toolchains $DL_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
+    - mkdir --verbose --parents $KAS_WORK_DIR $SSTATE_DIR $DL_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"
-      when: never
-    # Don't run pipelines for tags
-    - if: $CI_COMMIT_TAG
-      when: never
-    # Don't run if BUILD_ENABLE_REGEX is set, but the job doesn't match the regex
-    - if: '$BUILD_ENABLE_REGEX != null && $CI_JOB_NAME !~ $BUILD_ENABLE_REGEX'
-      when: never
-    # Allow the dev kernels to fail and not fail the overall build
-    - if: '$KERNEL == "linux-yocto-dev"'
-      allow_failure: true
-    # Catch all for everything else
-    - if: '$KERNEL != "linux-yocto-dev"'
  script:
-    - KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME"):lockfile.yml
-    - 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: always
-    paths:
-      - $CI_PROJECT_DIR/work/build/tmp*/work*/**/temp/log.do_*.*
-      - $CI_PROJECT_DIR/work/build/tmp*/work*/**/testimage/*
+  - KASFILES=$(kas/jobs-to-kas $CI_JOB_NAME)
+  - kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
+  - kas build $KASFILES
+  - ./kas/check-warnings $KAS_WORK_DIR/build/warnings.log
+

 #
-# Prep stage, update repositories once.
-# Set the CI variable CI_CLEAN_REPOS=1 to refetch the respositories from scratch
+# First phase, bootstrap and machine coverage
 #
-update-repos:
-  extends: .setup
-  stage: prep
-  allow_failure:
-    exit_codes: 128
+
+# Build a number of native tools first to ensure the other builders don't race
+# over them
+n1sdp/bootstrap:
+  extends: .build
+  stage: bootstrap
+
+# What percentage of machines in the layer do we build
+machine-coverage:
+  stage: bootstrap
  script:
-    - |
-      flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos
-      # Only generate if doesn't already exist, to allow feature branches to drop one in.
-      if test -f lockfile.yml; then
-        echo Using existing lockfile.yml
-      else
-        # Be sure that this is the complete list of layers being fetched
-        kas dump --lock --update ci/qemuarm64.yml:ci/meta-openembedded.yml:ci/clang.yml:ci/meta-virtualization.yml | tee lockfile.yml
-      fi
-  artifacts:
-    name: "lockfile"
-    paths:
-      - lockfile.yml
+  - ./kas/check-machine-coverage
+  coverage: '/Coverage: \d+/'
+

 #
-# Build stage, the actual build jobs
+# Second phase, the actual build jobs
 #
-# Available options for building are
-#  DISTRO: [poky, poky-tiny]
-#  KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
-#  TOOLCHAINS: [gcc, clang, external-gccarm]
-#  TCLIBC: [glibc, musl]
-#  FIRMWARE: [u-boot, edk2]
-#  TS: [none, trusted-services]
-#  VIRT: [none, xen]
-#  TESTING: testimage

-corstone1000-fvp:
+corstone500:
  extends: .build
-  parallel:
-    matrix:
-      - TESTING: [testimage, tftf]

-corstone1000-mps3:
+corstone700-fvp:
  extends: .build
-  parallel:
-    matrix:
-      - TESTING: [none, tftf]

+corstone700-mps3:
+  extends: .build

 fvp-base:
  extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-      - FIRMWARE: edk2
-      - SYSTEMREADY_FIRMWARE: arm-systemready-firmware

-arm-systemready-ir-acs:
-  extends: .build
-  timeout: 12h
-  parallel:
-    matrix:
-      # arm-systemready-ir-acs must be specified after fvp-base for ordering
-      # purposes for the jobs-to-kas output. It is not enough to just have it
-      # in the job name because fvp-base.yml overwrites the target.
-      - PLATFORM: fvp-base
-        ARM_SYSTEMREADY_IR_ACS: arm-systemready-ir-acs
-  tags:
-    - ${ACS_TAG}
-
-fvps:
+fvp-base-arm32:
  extends: .build

-generic-arm64:
+fvp-base-arm32/external-gcc-arm32:
+  extends: .build
+
+gem5-arm64:
  extends: .build

 juno:
  extends: .build
-  parallel:
-    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        FIRMWARE: [u-boot, edk2]
+
+juno/clang:
+  extends: .build

 musca-b1:
  extends: .build
@@ -164,154 +87,53 @@ musca-s1:

 n1sdp:
  extends: .build
-  parallel:
-    matrix:
-      - TESTING: [none, n1sdp-ts, n1sdp-optee, tftf]

-qemu-generic-arm64:
+n1sdp/armgcc:
  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:
+qemuarm64-secureboot/clang:
  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:
+qemuarm64-secureboot/clang/musl:
  extends: .build
-  parallel:
-    matrix:
-      - KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
-        TOOLCHAINS: [gcc, clang]
-        TCLIBC: [glibc, musl]
-        TESTING: testimage
-      - TOOLCHAINS: external-gccarm
-        TESTING: testimage

-qemuarm:
+qemuarm64-secureboot/musl:
  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:
+tc0:
  extends: .build

-selftest:
+
+#
+# Utility tasks, not executed automatically
+#
+
+# Report on disk usage
+usage:
  extends: .setup
+  stage: bootstrap
+  when: manual
  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'
+  - du -h -s $DL_DIR $SSTATE_DIR

-# Validate layers are Yocto Project Compatible
-check-layers:
+# Wipe out old sstate
+prune-sstate:
  extends: .setup
+  stage: bootstrap
+  when: manual
  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"
-  parallel:
-    matrix:
-      - LAYER: [meta-arm, meta-arm-bsp, meta-arm-toolchain]
+  - find $SSTATE_DIR -type f -atime +30 -delete

-pending-updates:
+# Delete all sstate
+delete-sstate:
  extends: .setup
-  artifacts:
-    paths:
-      - update-report
+  stage: bootstrap
+  when: manual
  script:
-    - rm -fr update-report
-    # This configuration has all of the layers we need enabled
-    - kas shell --update --force-checkout ci/qemuarm64.yml:ci/meta-openembedded.yml:ci/meta-secure-core.yml:lockfile.yml --command \
-      "$CI_PROJECT_DIR/scripts/machine-summary.py -t report -o $CI_PROJECT_DIR/update-report $($CI_PROJECT_DIR/ci/listmachines.py meta-arm meta-arm-bsp)"
-  # Do this on x86 whilst the compilers are x86-only
-  tags:
-    - x86_64
-
-# What percentage of machines in the layer do we build
-machine-coverage:
-  extends: .setup
-  script:
-    - ./ci/check-machine-coverage
-  coverage: '/Coverage: \d+/'
-
-metrics:
-  extends: .setup
-  artifacts:
-    reports:
-      metrics: metrics.txt
-  script:
-    - kas shell --update --force-checkout ci/base.yml --command \
-      "$CI_PROJECT_DIR/ci/patchreview $CI_PROJECT_DIR/meta-* --verbose --metrics $CI_PROJECT_DIR/metrics.txt"
-
-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/
+  - rm -rf $SSTATE_DIR/*
@@ -1,33 +1,23 @@
 Introduction
 ------------
-This repository contains the Arm layers for OpenEmbedded.
+This repository contains Arm layers for OpenEmbedded

-* meta-arm
+meta-arm:
+	This layer provides support for general recipes for the Arm
+	architecture.  Anything that's not needed explicitly for BSPs, the IOTA
+	distribution, or destined to be upstreamed belongs here.

-  This layer contains general recipes for the Arm architecture, such as firmware, FVPs, and Arm-specific integration.
+meta-arm-bsp:
+	This layer provides support for Arm reference platforms

-* meta-arm-bsp
+meta-arm-iota:
+	This layer provides support for Arm's IOTA Linux Distribution

-  This layer contains machines for Arm reference platforms, for example FVP Base, N1SDP, and Juno.
+meta-arm-toolchain:
+	This layer provides support for Arm's GNU-A toolset releases

-* meta-arm-toolchain
-
-  This layer contains recipes for Arm's binary toolchains (GCC and Clang for -A and -M), and a recipe to build Arm's GCC.
-
-Other Directories
-----------------
-
-* ci
-
-  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
-
-* scripts
-
-  This directory contains scripts used in running the CI tests
+meta-arm-autonomy:
+    This layer provides a reference stack for autonomous systems.

 Contributing
 ------------
@@ -1,4 +0,0 @@
-header:
-  version: 11
-  includes:
-    - kas/arm-systemready-firmware.yml
@@ -1,14 +0,0 @@
-header:
-  version: 11
-  includes:
-    - kas/arm-systemready-ir-acs.yml
-
-env:
-  ACS_TEST: "0"
-
-local_conf_header:
-  testimage: |
-    TESTIMAGE_AUTO = "${ACS_TEST}"
-
-target:
-  - arm-systemready-ir-acs
@@ -1,43 +0,0 @@
-header:
-  version: 14
-
-distro: poky
-
-defaults:
-  repos:
-    branch: nanbield
-
-repos:
-  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: ""
-  TOOLCHAIN_DIR: ""
-
-local_conf_header:
-  base: |
-    CONF_VERSION = "2"
-  setup: |
-    PACKAGE_CLASSES = "package_ipk"
-    PACKAGECONFIG:remove:pn-qemu-system-native = "gtk+ sdl"
-    PACKAGECONFIG:append:pn-perf = " coresight"
-    INHERIT += "rm_work"
-    DISTRO_FEATURES:remove = "ptest"
-  extrapackages: |
-    CORE_IMAGE_EXTRA_INSTALL += "perf opencsd"
-    CORE_IMAGE_EXTRA_INSTALL:append:aarch64 = " gator-daemon"
-
-machine: unset
-
-target:
-  - core-image-sato
@@ -1,19 +0,0 @@
-header:
-  version: 14
-
-repos:
-  meta-clang:
-    url: https://github.com/kraj/meta-clang
-
-local_conf_header:
-  toolchain: |
-    TOOLCHAIN = "clang"
-    PREFERRED_PROVIDER_llvm = "clang"
-    PREFERRED_PROVIDER_llvm-native = "clang-native"
-    PREFERRED_PROVIDER_nativesdk-llvm = "nativesdk-clang"
-    PROVIDES:pn-clang = "llvm"
-    PROVIDES:pn-clang-native = "llvm-native"
-    PROVIDES:pn-nativesdk-clang = "nativesdk-llvm"
-    # This is needed to stop bitbake getting confused about what clang/llvm is
-    # being used, see https://github.com/kraj/meta-clang/pull/766
-    BBMASK += "/meta/recipes-devtools/llvm/llvm.*\.bb"
@@ -1,15 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-    - ci/meta-openembedded.yml
-    - ci/poky-tiny.yml
-    - ci/meta-secure-core.yml
-
-local_conf_header:
-    extrapackages: |
-    # Intentionally blank to prevent perf from being added to the image in base.yml
-
-target:
-  - corstone1000-image
-  - perf
@@ -1,12 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/corstone1000-common.yml
-    - ci/fvp.yml
-
-local_conf_header:
-    fvp-config: |
-        # Remove Dropbear SSH as it will not fit into the corstone1000 image.
-        IMAGE_FEATURES:remove = " ssh-server-dropbear"
-
-machine: corstone1000-fvp
@@ -1,6 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/corstone1000-common.yml
-
-machine: corstone1000-mps3
@@ -1,7 +0,0 @@
-header:
-  version: 14
-
-# Add universally helpful features when testing boards
-local_conf_header:
-  debug: |
-    EXTRA_IMAGE_FEATURES:append = " debug-tweaks"
@@ -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,17 +0,0 @@
-header:
-  version: 14
-
-local_conf_header:
-  bootfirmware: |
-    PREFERRED_PROVIDER_virtual/bootloader = "edk2-firmware"
-    MACHINE_FEATURES += "efi"
-    TFA_UBOOT = "0"
-    TFA_UEFI = "1"
-
-    EXTRA_IMAGEDEPENDS += "edk2-firmware"
-    EFI_PROVIDER ?= "grub-efi"
-
-    QB_DEFAULT_BIOS = "QEMU_EFI.fd"
-    WKS_FILE ?= "efi-disk.wks.in"
-  failing_tests: |
-    TEST_SUITES:remove = "xorg"
@@ -1,11 +0,0 @@
-header:
-  version: 14
-
-local_conf_header:
-  cc: |
-    SKIP_RECIPE[gcc-cross-arm] = "Using external toolchain"
-    TCMODE = "external-arm"
-    EXTERNAL_TOOLCHAIN = "${TOPDIR}/toolchains/${TARGET_ARCH}"
-    # Temporary workaround for a number binaries in the toolchains that are using 32bit timer API
-    # This must be done here instead of the recipe because of all the libraries in the toolchain have the issue
-    INSANE_SKIP:append = " 32bit-time"
@@ -1,7 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-    - ci/fvp.yml
-
-machine: fvp-base
@@ -1,12 +0,0 @@
-header:
-  version: 14
-
-local_conf_header:
-  testimagefvp: |
-    LICENSE_FLAGS_ACCEPTED += "Arm-FVP-EULA"
-    IMAGE_CLASSES += "fvpboot"
-  failing_tests: |
-    # This fails but we can't add to the ignorelist from meta-arm yet
-    # https://bugzilla.yoctoproject.org/show_bug.cgi?id=14604
-    TEST_SUITES:remove = "parselogs"
-    TEST_SUITES:remove = "xorg"
@@ -1,25 +0,0 @@
-# Simple target to build the FVPs that are publically available
-
-header:
-  version: 14
-  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
-  - fvp-base-a-aem
-  - fvp-corstone1000
-  # Nativesdk to test x86-64
-  - nativesdk-fvp-base-a-aem
-  - nativesdk-fvp-corstone1000
-  - nativesdk-fvp-n1-edge
-  - nativesdk-fvp-sgi575
-  - nativesdk-fvp-tc1
@@ -1,7 +0,0 @@
-header:
-  version: 14
-
-#NOTE: This is the default for poky.  This is only being added for completeness/clarity
-local_conf_header:
-  toolchain: |
-    TOOLCHAIN = "gcc"
@@ -1,6 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-
-machine: generic-arm64
@@ -1,51 +0,0 @@
-#!/bin/bash
-set -u -e
-
-BASENAME=arm-gnu-toolchain
-VER=${VER:-12.2.rel1}
-HOST_ARCH=${HOST_ARCH:-$(uname -m)}
-
-# Use the standard kas container locations if nothing is passed into the script
-DOWNLOAD_DIR="${1:-/builds/persist/downloads/}"
-TOOLCHAIN_DIR="${2:-/builds/persist//toolchains/}"
-TOOLCHAIN_LINK_DIR="${3:-build/toolchains/}"
-
-# These should be already created by .gitlab-ci.yml, but do here if run outside of that env
-mkdir -p $DOWNLOAD_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
-
-download() {
-	TRIPLE=$1
-	URL=https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/$BASENAME-$VER-$HOST_ARCH-$TRIPLE.tar.xz
-	wget -P $DOWNLOAD_DIR -nc $URL
-}
-
-if [ $HOST_ARCH = "aarch64" ]; then
-	# AArch64 Linux hosted cross compilers
-
-	# AArch32 target with hard float
-	download arm-none-linux-gnueabihf
-elif [ $HOST_ARCH = "x86_64" ]; then
-	# x86_64 Linux hosted cross compilers
-
-	# AArch32 target with hard float
-	download arm-none-linux-gnueabihf
-
-	# AArch64 GNU/Linux target
-	download aarch64-none-linux-gnu
-else
-	echo "ERROR - Unknown build arch of $HOST_ARCH"
-	exit 1
-fi
-
-for i in arm aarch64; do
-	if [ ! -d $TOOLCHAIN_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*/ ]; then
-		if [ ! -f $DOWNLOAD_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz ]; then
-			continue
-		fi
-
-		tar -C $TOOLCHAIN_DIR -axvf $DOWNLOAD_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz
-	fi
-
-	# Setup a link for the toolchain to use local to the building machine (e.g., not in a shared location)
-	ln -s $TOOLCHAIN_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu* $TOOLCHAIN_LINK_DIR/$i
-done
@@ -1,7 +0,0 @@
-header:
-  version: 14
-
-#NOTE: This is the default for poky.  This is only being added for completeness/clarity
-local_conf_header:
-  libc: |
-    TCLIBC = "glibc"
@@ -1,27 +0,0 @@
-#! /bin/bash
-
-# 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]
-#
-# Turn this list into a series of yml files separated by colons to pass to kas
-
-set -e -u
-
-FILES="ci/$(echo $1 | cut -d ':' -f 1).yml"
-
-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
-	# of each individual run.
-	if [[ $i == 'none' ]]; then
-		continue
-	fi
-	FILES+=":ci/$i.yml"
-done
-
-echo $FILES
@@ -1,6 +0,0 @@
-header:
-  version: 14
-
-local_conf_header:
-  kernel: |
-    PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
@@ -1,6 +0,0 @@
-header:
-  version: 14
-
-local_conf_header:
-  kernel: |
-    PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
@@ -1,7 +0,0 @@
-header:
-  version: 14
-
-#NOTE: This is the default for poky.  This is only being added for completeness/clarity
-local_conf_header:
-  kernel: |
-    PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
@@ -1,29 +0,0 @@
-#! /usr/bin/env python3
-
-import pathlib
-import typing
-import sys
-
-"""
-List all of the machines available under the listed sub-layers of meta-arm.
-"""
-def list_machines(layers: typing.Sequence[str]) -> typing.Set[str]:
-    machines = set()
-
-    # We know we're in meta-arm/scripts, so find the top-level directory
-    metaarm = pathlib.Path(__file__).resolve().parent.parent
-    if metaarm.name != "meta-arm":
-        raise Exception("Not running inside meta-arm")
-    
-    for layer in layers:
-        machines |= set(p.stem for p in (metaarm / layer / "conf" / "machine").glob("*.conf"))
-    return machines
-
-if __name__ == "__main__":
-    if len(sys.argv) > 1:
-        machines = list_machines(sys.argv[1:])
-        print(" ".join(sorted(machines)))
-        sys.exit(0)
-    else:
-        print("Usage:\n$ %s [layer name ...] " % sys.argv[0])
-        sys.exit(1)
@@ -1,11 +0,0 @@
-header:
-  version: 14
-
-repos:
-  meta-secure-core:
-    url: https://github.com/Wind-River/meta-secure-core.git
-    layers:
-      meta:
-      meta-signing-key:
-      meta-efi-secure-boot:
-      
@@ -1,8 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/meta-openembedded.yml
-
-repos:
-  meta-virtualization:
-    url: https://git.yoctoproject.org/meta-virtualization
@@ -1,10 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-    - ci/meta-openembedded.yml
-
-machine: musca-b1
-
-target:
-  - trusted-firmware-m
@@ -1,12 +0,0 @@
-header:
-  version: 14
-
-# Config specific for the optee-xtests
-local_conf_header:
-  optee-test: |
-    # Include ARM FFA
-    MACHINE_FEATURES:append = " arm-ffa"
-    # Include trusted services
-    TEST_SUITES:append = " trusted_services"
-    # Include Optee xtests
-    IMAGE_INSTALL:append = " optee-test"
@@ -1,14 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/meta-openembedded.yml
-
-local_conf_header:
-  trusted_services: |
-    TEST_SUITES:append = " trusted_services"
-    # Include TS Crypto, TS Protected Storage, TS Internal and Trusted Storage SPs into optee-os image
-    MACHINE_FEATURES:append = " arm-ffa ts-crypto ts-storage ts-its"
-    # Include TS demo/test tools into image
-    IMAGE_INSTALL:append = " packagegroup-ts-tests"
-    # Include TS PSA Arch tests into image
-    IMAGE_INSTALL:append = " packagegroup-ts-tests-psa"
@@ -1,10 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-
-machine: n1sdp
-
-local_conf_header:
-  unsupported_trusted_services: |
-    MACHINE_FEATURES:remove = "ts-smm-gateway"
@@ -1,286 +0,0 @@
-#! /usr/bin/env python3
-#
-# SPDX-License-Identifier: GPL-2.0-only
-#
-
-# TODO
-# - option to just list all broken files
-# - test suite
-# - validate signed-off-by
-
-import argparse
-import collections
-import json
-import os
-import re
-import subprocess
-
-status_values = (
-    "accepted",
-    "pending",
-    "inappropriate",
-    "backport",
-    "submitted",
-    "denied",
-)
-
-
-class PatchResult:
-    # Whether the patch has an Upstream-Status or not
-    missing_upstream_status = False
-    # If the Upstream-Status tag is malformed in some way (string for bad bit)
-    malformed_upstream_status = None
-    # If the Upstream-Status value is unknown (boolean)
-    unknown_upstream_status = False
-    # The upstream status value (Pending, etc)
-    upstream_status = None
-    # Whether the patch has a Signed-off-by or not
-    missing_sob = False
-    # Whether the Signed-off-by tag is malformed in some way
-    malformed_sob = False
-    # The Signed-off-by tag value
-    sob = None
-    # Whether a patch looks like a CVE but doesn't have a CVE tag
-    missing_cve = False
-
-
-class Summary:
-    total = 0
-    cve_missing = 0
-    sob_missing = 0
-    sob_malformed = 0
-    status_missing = 0
-    status_malformed = 0
-    status_pending = 0
-
-def blame_patch(patch):
-    """
-    From a patch filename, return a list of "commit summary (author name <author
-    email>)" strings representing the history.
-    """
-    return subprocess.check_output(("git", "log",
-                                    "--follow", "--find-renames", "--diff-filter=A",
-                                    "--format=%s (%aN <%aE>)",
-                                    "--", patch)).decode("utf-8").splitlines()
-
-def patchreview(patches):
-    # General pattern: start of line, optional whitespace, tag with optional
-    # hyphen or spaces, maybe a colon, some whitespace, then the value, all case
-    # insensitive.
-    sob_re = re.compile(r"^[\t ]*(Signed[-_ ]off[-_ ]by:?)[\t ]*(.+)", re.IGNORECASE | re.MULTILINE)
-    status_re = re.compile(r"^[\t ]*(Upstream[-_ ]Status:?)[\t ]*(\w*)", re.IGNORECASE | re.MULTILINE)
-    cve_tag_re = re.compile(r"^[\t ]*(CVE:)[\t ]*(.*)", re.IGNORECASE | re.MULTILINE)
-    cve_re = re.compile(r"cve-[0-9]{4}-[0-9]{4,6}", re.IGNORECASE)
-
-    results = {}
-
-    for patch in patches:
-
-        result = PatchResult()
-        results[patch] = result
-
-        content = open(patch, encoding="ascii", errors="ignore").read()
-
-        # Find the Signed-off-by tag
-        match = sob_re.search(content)
-        if match:
-            value = match.group(1)
-            if value != "Signed-off-by:":
-                result.malformed_sob = value
-            result.sob = match.group(2)
-        else:
-            result.missing_sob = True
-
-        # Find the Upstream-Status tag
-        match = status_re.search(content)
-        if match:
-            value = match.group(1)
-            if value != "Upstream-Status:":
-                result.malformed_upstream_status = value
-
-            value = match.group(2).lower()
-            # TODO: check case
-            if value not in status_values:
-                result.unknown_upstream_status = True
-            result.upstream_status = value
-        else:
-            result.missing_upstream_status = True
-
-        # Check that patches which looks like CVEs have CVE tags
-        if cve_re.search(patch) or cve_re.search(content):
-            if not cve_tag_re.search(content):
-                result.missing_cve = True
-        # TODO: extract CVE list
-
-    return results
-
-
-def analyse(results, want_blame=False, verbose=True):
-    """
-    want_blame: display blame data for each malformed patch
-    verbose: display per-file results instead of just summary
-    """
-
-    # want_blame requires verbose, so disable blame if we're not verbose
-    if want_blame and not verbose:
-        want_blame = False
-
-    summary = Summary()
-
-    for patch in sorted(results):
-        r = results[patch]
-        summary.total += 1
-        need_blame = False
-
-        # Build statistics
-        if r.missing_sob:
-            summary.sob_missing += 1
-        if r.malformed_sob:
-            summary.sob_malformed += 1
-        if r.missing_upstream_status:
-            summary.status_missing += 1
-        if r.malformed_upstream_status or r.unknown_upstream_status:
-            summary.status_malformed += 1
-            # Count patches with no status as pending
-            summary.status_pending += 1
-        if r.missing_cve:
-            summary.cve_missing += 1
-        if r.upstream_status == "pending":
-            summary.status_pending += 1
-
-        # Output warnings
-        if r.missing_sob:
-            need_blame = True
-            if verbose:
-                print("Missing Signed-off-by tag (%s)" % patch)
-        if r.malformed_sob:
-            need_blame = True
-            if verbose:
-                print("Malformed Signed-off-by '%s' (%s)" % (r.malformed_sob, patch))
-        if r.missing_cve:
-            need_blame = True
-            if verbose:
-                print("Missing CVE tag (%s)" % patch)
-        if r.missing_upstream_status:
-            need_blame = True
-            if verbose:
-                print("Missing Upstream-Status tag (%s)" % patch)
-        if r.malformed_upstream_status:
-            need_blame = True
-            if verbose:
-                print("Malformed Upstream-Status '%s' (%s)" % (r.malformed_upstream_status, patch))
-        if r.unknown_upstream_status:
-            need_blame = True
-            if verbose:
-                print("Unknown Upstream-Status value '%s' (%s)" % (r.upstream_status, patch))
-
-        if want_blame and need_blame:
-            print("\n".join(blame_patch(patch)) + "\n")
-
-    return summary
-
-
-def display_summary(summary, verbose):
-    def percent(num):
-        try:
-            return "%d (%d%%)" % (num, round(num * 100.0 / summary.total))
-        except ZeroDivisionError:
-            return "N/A"
-
-    if verbose:
-        print()
-
-    print("""Total patches found: %d
-Patches missing Signed-off-by: %s
-Patches with malformed Signed-off-by: %s
-Patches missing CVE: %s
-Patches missing Upstream-Status: %s
-Patches with malformed Upstream-Status: %s
-Patches in Pending state: %s""" % (summary.total,
-                                   percent(summary.sob_missing),
-                                   percent(summary.sob_malformed),
-                                   percent(summary.cve_missing),
-                                   percent(summary.status_missing),
-                                   percent(summary.status_malformed),
-                                   percent(summary.status_pending)))
-
-
-def generate_metrics(summary, output):
-    # https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md
-    # Summary attribute name, MetricPoint help
-    mapping = (
-        ("total", "Total patches"),
-        ("cve_missing", "Patches missing CVE tag"),
-        ("sob_malformed", "Patches with malformed Signed-off-by"),
-        ("sob_missing", "Patches with missing Signed-off-by"),
-        ("status_malformed", "Patches with malformed Upstream-Status"),
-        ("status_missing", "Patches with missing Upstream-Status"),
-        ("status_pending", "Patches with Pending Upstream-Status")
-    )
-    for attr, help in mapping:
-        metric = f"patch_check_{attr}"
-        value = getattr(summary, attr)
-        output.write(f"""
-# TYPE {metric} gauge
-# HELP {help}
-{metric} {value}
-""")
-    output.write("\n# EOF\n")
-
-def histogram(results):
-    import math
-
-    from toolz import dicttoolz, recipes
-    counts = recipes.countby(lambda r: r.upstream_status, results.values())
-    bars = dicttoolz.valmap(lambda v: "#" * int(math.ceil(float(v) / len(results) * 100)), counts)
-    for k in bars:
-        print("%-20s %s (%d)" % (k.capitalize() if k else "No status", bars[k], counts[k]))
-
-def gather_patches(directories):
-    patches = []
-    for directory in directories:
-        filenames = subprocess.check_output(("git", "-C", directory, "ls-files", "recipes-*/**/*.patch", "recipes-*/**/*.diff")).decode("utf-8").split()
-        patches += [os.path.join(directory, f) for f in filenames]
-    return patches
-
-if __name__ == "__main__":
-    args = argparse.ArgumentParser(description="Patch Review Tool")
-    args.add_argument("-b", "--blame", action="store_true", help="show blame for malformed patches")
-    args.add_argument("-v", "--verbose", action="store_true", help="show per-patch results")
-    args.add_argument("-g", "--histogram", action="store_true", help="show patch histogram")
-    args.add_argument("-j", "--json", help="update JSON")
-    args.add_argument("-m", "--metrics", type=argparse.FileType('w'), help="write OpenMetrics")
-    args.add_argument("dirs", metavar="DIRECTORY", nargs="+", help="directory to scan")
-    args = args.parse_args()
-
-    patches = gather_patches(args.dirs)
-    results = patchreview(patches)
-    summary = analyse(results, want_blame=args.blame, verbose=args.verbose)
-    display_summary(summary, verbose=args.verbose)
-
-    if args.json:
-        if os.path.isfile(args.json):
-            data = json.load(open(args.json))
-        else:
-            data = []
-
-        row = collections.Counter()
-        row["total"] = len(results)
-        row["date"] = subprocess.check_output(["git", "-C", args.dirs[0], "show", "-s", "--pretty=format:%cd", "--date=format:%s"]).decode("utf-8").strip()
-        for r in results.values():
-            if r.upstream_status in status_values:
-                row[r.upstream_status] += 1
-            if r.malformed_upstream_status or r.missing_upstream_status:
-                row["malformed-upstream-status"] += 1
-            if r.malformed_sob or r.missing_sob:
-                row["malformed-sob"] += 1
-
-        data.append(row)
-        json.dump(data, open(args.json, "w"))
-
-    if args.metrics:
-        generate_metrics(summary, args.metrics)
-
-    if args.histogram:
-        print()
-        histogram(results)
@@ -1,14 +0,0 @@
-header:
-  version: 14
-
-distro: poky-tiny
-
-local_conf_header:
-  hacking: |
-    TEST_SUITES = "_qemutiny ping"
-  extrapackages: |
-    # Intentionally blank to prevent perf from being added to the image in base.yml
-
-target:
-  - core-image-minimal
-  - perf
@@ -1,4 +0,0 @@
-header:
-  version: 14
-
-distro: poky
@@ -1,14 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/generic-arm64.yml
-
-local_conf_header:
-  failing_tests: |
-    DEFAULT_TEST_SUITES:remove = "parselogs"
-
-machine: qemu-generic-arm64
-
-target:
-  - core-image-sato
-  - sbsa-acs
@@ -1,12 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-
-machine: qemuarm-secureboot
-
-target:
-  - core-image-base
-  - optee-examples
-  - optee-test
-  - optee-os-tadevkit
@@ -1,6 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-
-machine: qemuarm
@@ -1,14 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/meta-openembedded.yml
-
-local_conf_header:
-  trusted_services: |
-    TEST_SUITES:append = " trusted_services"
-    # Include TS Crypto, TS Protected Storage, TS Internal 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
-    IMAGE_INSTALL:append = " packagegroup-ts-tests-psa"
@@ -1,6 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-
-machine: qemuarm64
@@ -1,6 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-
-machine: qemuarmv5
@@ -1,7 +0,0 @@
-header:
-  version: 14
-
-local_conf_header:
-  setup: |
-    BB_LOGCONFIG = ""
-    SANITY_TESTED_DISTROS = ""
@@ -1,11 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-    - ci/fvp.yml
-    - ci/meta-openembedded.yml
-
-machine: tc1
-
-target:
-  - core-image-minimal
@@ -1,19 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/debug.yml
-
-local_conf_header:
-  testimage: |
-    IMAGE_CLASSES += "testimage"
-    TESTIMAGE_AUTO = "1"
-  kvm: |
-    QEMU_USE_KVM = ""
-  slirp: |
-    TEST_RUNQEMUPARAMS = "slirp"
-  sshd: |
-    IMAGE_FEATURES:append = " ssh-server-dropbear"
-  sshkeys: |
-    CORE_IMAGE_EXTRA_INSTALL += "ssh-pregen-hostkeys"
-  universally_failing_tests: |
-    TEST_SUITES:remove = "opkg"
@@ -1,8 +0,0 @@
-header:
-  version: 14
-
-local_conf_header:
-  tftf: |
-    TFA_UBOOT = "0"
-    TFA_UEFI = "0"
-    TFTF_TESTS = "1"
@@ -1,20 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/base.yml
-
-# Target is arm64 and SDK is x86-64 to ensure that we exercise both
-# architectures
-
-machine: qemuarm64
-local_conf_header:
-  toolchains: |
-    SDKMACHINE = "x86_64"
-
-target:
-  - gcc-aarch64-none-elf
-  - nativesdk-gcc-aarch64-none-elf
-  - gcc-arm-none-eabi
-  - nativesdk-gcc-arm-none-eabi
-  - gcc-arm-none-eabi-11.2
-  - nativesdk-gcc-arm-none-eabi-11.2
@@ -1,8 +0,0 @@
-header:
-  version: 14
-
-local_conf_header:
-  bootfirmware: |
-    PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
-    TFA_UBOOT = "1"
-    TFA_UEFI = "0"
@@ -1,56 +0,0 @@
-#! /usr/bin/env python3
-
-# Update clones of the repositories we need in KAS_REPO_REF_DIR to speed up fetches
-
-import sys
-import os
-import shutil
-import subprocess
-import pathlib
-
-def repo_shortname(url):
-    # Taken from Kas (Repo.__getattr__) to ensure the logic is right
-    from urllib.parse import urlparse
-    url = urlparse(url)
-    return ('{url.netloc}{url.path}'
-            .format(url=url)
-            .replace('@', '.')
-            .replace(':', '.')
-            .replace('/', '.')
-            .replace('*', '.'))
-
-repositories = (
-    "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__":
-    if "KAS_REPO_REF_DIR" not in os.environ:
-        print("KAS_REPO_REF_DIR needs to be set")
-        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)
-
-        if "CI_CLEAN_REPOS" in os.environ:
-            print("Cleaning %s..." % repo)
-            shutil.rmtree(repodir, ignore_errors=True)
-
-        if repodir.exists():
-            try:
-                print("Updating %s..." % repo)
-                subprocess.run(["git", "-C", repodir, "-c", "gc.autoDetach=false", "fetch"], check=True)
-            except subprocess.CalledProcessError as e:
-                print(e)
-                failed = True
-        else:
-            print("Cloning %s..." % repo)
-            subprocess.run(["git", "clone", "--bare", repo, repodir], check=True)
-
-    if failed:
-        sys.exit(128)
@@ -1,11 +0,0 @@
-header:
-  version: 14
-  includes:
-    - ci/meta-virtualization.yml
-
-local_conf_header:
-  meta-virt: |
-    DISTRO_FEATURES:append = " virtualization xen"
-
-target:
-  - xen-image-minimal
@@ -1,49 +0,0 @@
-# OEQA on Arm FVPs
-
-OE-Core's [oeqa][OEQA] framework provides a method of performing runtime tests on machines using the `testimage` Yocto task. meta-arm has good support for writing test cases against [Arm FVPs][FVP], meaning the [runfvp][RUNFVP] boot configuration can be re-used.
-
-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"
-```
-
-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 supports two different test interfaces - SSH and pexpect.
-
-## 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:
-```
-(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.
-
-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
-
-To support firmware and baremetal testing, OEFVPTarget also allows test cases to make assertions against one or more consoles using the pexpect library.
-
-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.:
-```
-self.target.expect('default', r'root@.*\:~#', timeout=30)
-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.
-
-[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
-[PEXPECT]: https://pexpect.readthedocs.io/en/stable/overview.html
@@ -1,131 +0,0 @@
-# Running Images with a FVP
-
-The `runfvp` tool in meta-arm makes it easy to run Yocto Project disk images inside a [Fixed Virtual Platform (FVP)][FVP].  Some FVPs, such as the [Arm Architecture Models][AEM], are available free to download, but others need registration or are only available commercially.  The `fvp-base` machine in meta-arm-bsp uses one of these AEM models.
-
-## Running images with `runfvp`
-
-To build images with the FVP integration, the `fvpboot` class needs to be inherited.  If the machine does not do this explicitly it can be done in `local.conf`:
-
-```
-INHERIT += "fvpboot"
-```
-
-The class will download the correct FVP and write a `.fvpconf` configuration file when an image is built.
-
-To run an image in a FVP, pass either a machine name or a `.fvpconf` path to `runfvp`.
-
-```
-$ ./meta-arm/scripts/runfvp tmp/deploy/images/fvp-base/core-image-minimal-fvp-base.fvpconf
-```
-
-When a machine name is passed, `runfvp` will start the latest image that has been built for that machine. This requires that the BitBake environment has been initialized (using `oe-init-build-env` or similar) as it will start BitBake to determine where the images are.
-
-```
-$ ./meta-arm/scripts/runfvp fvp-base
-```
-
-Note that currently meta-arm's `scripts` directory isn't in `PATH`, so a full path needs to be used.
-
-`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 default terminal can also be configured by writing a [INI-style][INI] configuration file to `~/.config/runfvp.conf`:
-
-```
-[RunFVP]
-Terminal=tmux
-```
-
-Arbitrary options can be passed directly to the FVP by specifying them after a double dash, for example this will list all of the FVP parameters:
-
-```
-$ runfvp fvp-base -- --list-params
-```
-
-## Configuring machines with `fvpboot`
-
-To configure a machine so that it can be ran inside `runfvp`, a number of variables need to be set in the machine configuration file (such as `meta-arm-bsp/conf/machine/fvp-base.conf`).
-
-Note that at present these variables are not stable and their behaviour may be changed in the future.
-
-### `FVP_EXE`
-
-The name of the FVP binary itself, for example `fvp-base` uses `FVP_Base_RevC-2xAEMvA`.
-
-### `FVP_PROVIDER`
-
-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.
-
-If `FVP_PROVIDER` is not set then it is assumed that `FVP_EXE` is installed on the host already.
-
-### `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_DATA`
-
-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_APPLICATIONS`
-
-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"
-```
-
-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.
-
-### `FVP_TERMINALS`
-
-Map hardware serial ports to abstract names. For example the `FVP_Base_RevC-2xAEMvA` FVP exposes four serial ports, `terminal_0` to `terminal_3`.  Typically only `terminal_0` is used in the `fvp-base` machine so this can be named `"Console"` and the others `""`.  When runfvp starts terminals it will only start named serial ports, so instead of opening four windows where only one is useful, it will only open one.
-
-For example:
-```
-FVP_TERMINALS[bp.terminal_0] = "Console"
-FVP_TERMINALS[bp.terminal_1] = ""
-FVP_TERMINALS[bp.terminal_2] = ""
-FVP_TERMINALS[bp.terminal_3] = ""
-```
-
-### `FVP_CONSOLES`
-
-This specifies what serial ports can be used in oeqa tests, along with an alias to be used in the test cases. Note that the values have to be the FVP identifier but without the board prefix, for example:
-```
-FVP_CONSOLES[default] = "terminal_0"
-FVP_CONSOLES[tf-a] = "s_terminal_0"
-```
-
-The 'default' console is also used when `--console` is passed to runfvp.
-
-### `FVP_EXTRA_ARGS`
-
-Arbitrary extra arguments that are passed directly to the FVP.  For example:
-
-```
-FVP_EXTRA_ARGS = "--simlimit 60"
-```
-
-### `FVP_ENV_PASSTHROUGH`
-
-The FVP is launched with an isolated set of environment variables. Add the name of a Bitbake variable to this list to pass it through to the FVP environment. For example:
-
-```
-FVP_ENV_PASSTHROUGH = "ARMLMD_LICENSE_FILE FM_TRACE_PLUGINS"
-```
-
-
-[AEM]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms/arm-ecosystem-models
-[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
@@ -1,65 +0,0 @@
-# The Trusted Services: framework for developing root-of-trust services
-
-meta-arm layer includes recipes for [Trusted Services][^1] Secure Partitions and Normal World applications
-in `meta-arm/recipes-security/trusted-services`
-
-## Secure Partitions recipes
-
-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 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       |
-| Internal Storage  | ts-its          |
-| Protected Storage | ts-storage      |
-| se-proxy          | ts-se-proxy     |
-| smm-gateway       | ts-smm-gateway  |
-| spm-test[1-3]     | optee-spmc-test |
-
-Other steps depend on your machine/platform definition:
-
-1. For communications between Secure and Normal Words Linux kernel option `CONFIG_ARM_FFA_TRANSPORT=y`
-   is required. If your platform doesn't include it already you can add `arm-ffa` into MACHINE_FEATURES.
-   (Please see ` meta-arm/recipes-kernel/arm-ffa-tee`.)
-
-   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.
-   (Please see ` meta-arm/recipes-kernel/arm-ffa-user`.)
-
-2. optee-os might require platform specific OP-TEE build parameters (for example what SEL the SPM Core is implemented at).
-   You can find examples in `meta-arm/recipes-security/optee/optee-os_%.bbappend` for qemuarm64-secureboot machine
-   and in `meta-arm-bsp/recipes-security/optee/optee-os-n1sdp.inc` and `meta-arm-bsp/recipes-security/optee/optee-os-corstone1000-common.inc`
-   for N1SDP and Corstone1000 platforms accordingly.
-
-3. trusted-firmware-a might require platform specific TF-A build parameters (SPD and SPMC details on the platform).
-   See `meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend` for qemuarm64-secureboot machine
-   and in `meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-n1sdp.inc` and
-   `meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-corstone1000.inc` for N1SDP and Corstone1000 platforms.
-
-## Normal World applications
-
-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.
-See `ci/trusted-services.yml` for an example how to include them into an image.
-
-
------
-[^1]: https://trusted-services.readthedocs.io/en/integration/overview/index.html
-
-[^2]: https://trusted-services.readthedocs.io/en/integration/deployments/secure-partitions.html
-
-[^3]: https://trusted-services.readthedocs.io/en/integration/deployments/test-executables.html
-
-[^4]: https://optee.readthedocs.io/en/latest/building/gits/optee_test.html
@@ -1,12 +0,0 @@
-header:
-  version: 13
-
-repos:
-  meta-arm:
-    layers:
-      meta-arm-systemready:
-
-distro: nodistro
-
-target:
-  - arm-systemready-firmware
@@ -1,12 +0,0 @@
-header:
-  version: 13
-  includes:
-    - kas/arm-systemready-firmware.yml
-
-env:
-  TESTIMAGE_AUTO: "1"
-  # The full testimage run typically takes around 12-24h on fvp-base.
-  TEST_OVERALL_TIMEOUT: "${@ 24*60*60}"
-
-target:
-  - arm-systemready-ir-acs
@@ -1,7 +0,0 @@
-header:
-  version: 13
-  includes:
-    - kas/arm-systemready-firmware.yml
-
-target:
-  - arm-systemready-linux-distros-debian
@@ -1,7 +0,0 @@
-header:
-  version: 13
-  includes:
-    - kas/arm-systemready-firmware.yml
-
-target:
-  - arm-systemready-linux-distros-opensuse
@@ -0,0 +1,6 @@
+header:
+  version: 9
+
+local_conf_header:
+  cc: |
+    GCCVERSION = "arm-10.2"
@@ -0,0 +1,44 @@
+header:
+  version: 9
+
+distro: poky
+
+defaults:
+  repos:
+    refspec: master
+
+repos:
+  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: ""
+
+local_conf_header:
+  base: |
+    CONF_VERSION = "1"
+    PACKAGE_CLASSES = "package_ipk"
+    LICENSE_FLAGS_WHITELIST += "armcompiler"
+    PACKAGECONFIG_remove_pn-qemu-system-native = "gtk+ sdl"
+    BB_NUMBER_THREADS = "16"
+    PARALLEL_MAKE = "-j16"
+    INHERIT += "rm_work"
+    PACKAGECONFIG_append_pn-perf = " coresight"
+    ERROR_QA = "${WARN_QA}"
+  ptest: |
+    DISTRO_FEATURES_remove = "ptest"
+
+machine: unset
+
+target:
+  - core-image-base
+  - perf
@@ -0,0 +1,9 @@
+header:
+  version: 9
+
+target:
+  - binutils-cross-aarch64
+  - gcc-cross-aarch64
+  - python3-native
+  - opkg-native
+  - rpm-native
@@ -2,7 +2,6 @@

 from pathlib import Path
 import sys
-from listmachines import list_machines

 metaarm = Path.cwd()

@@ -10,13 +9,12 @@ if metaarm.name != "meta-arm":
    print("Not running inside meta-arm")
    sys.exit(1)

-# Find all layers
-layers = (p.name for p in metaarm.glob("meta-*") if p.is_dir())
 # All machine configurations
-machines = list_machines(layers)
+machines = metaarm.glob("meta-*/conf/machine/*.conf")
+machines = set(p.stem for p in machines)

 # All kas files
-kas = metaarm.glob("ci/*.yml")
+kas = metaarm.glob("kas/*.yml")
 kas = set(p.stem for p in kas)

 missing = machines - kas
@@ -7,8 +7,7 @@ set -e -u

 LOGFILE=$1

-LINES=$(grep --invert-match "attempting MIRRORS if available" $LOGFILE | wc -l)
-if test "$LINES" -ne 0; then
+if test -s $LOGFILE; then
    echo ==============================
    echo The build had warnings/errors:
    echo ==============================
@@ -0,0 +1,10 @@
+header:
+  version: 9
+
+repos:
+  meta-clang:
+    url: https://github.com/kraj/meta-clang
+
+local_conf_header:
+  clang: |
+    TOOLCHAIN = "clang"
@@ -1,54 +0,0 @@
-header:
-  version: 14
-
-env:
-  DISPLAY: ""
-
-distro: poky-tiny
-
-defaults:
-  repos:
-    branch: nanbield
-
-repos:
-  meta-arm:
-    layers:
-      meta-arm:
-      meta-arm-bsp:
-      meta-arm-toolchain:
-
-  poky:
-    url: https://git.yoctoproject.org/git/poky
-    commit: 2e9c2a2381105f1306bcbcb54816cbc5d8110eff
-    layers:
-      meta:
-      meta-poky:
-
-  meta-openembedded:
-    url: https://git.openembedded.org/meta-openembedded
-    commit: 1750c66ae8e4268c472c0b2b94748a59d6ef866d
-    layers:
-      meta-oe:
-      meta-python:
-      meta-perl:
-
-  meta-secure-core:
-    url: https://github.com/wind-river/meta-secure-core.git
-    commit: e29165a1031dcf601edbed1733cedd64826672a5
-    layers:
-      meta:
-      meta-signing-key:
-      meta-efi-secure-boot:
-
-local_conf_header:
-  base: |
-    CONF_VERSION = "2"
-    PACKAGE_CLASSES = "package_ipk"
-    BB_NUMBER_THREADS ?= "16"
-    PARALLEL_MAKE ?= "-j16"
-    PACKAGECONFIG:append:pn-perf = " coresight"
-
-machine: unset
-
-target:
-  - corstone1000-image
@@ -1,16 +0,0 @@
-header:
-  version: 14
-  includes:
-    - kas/corstone1000-base.yml
-    - kas/fvp-eula.yml
-
-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 += "fvpboot"
-
-target:
-  - corstone1000-image
@@ -1,6 +0,0 @@
-header:
-  version: 14
-  includes:
-    - kas/corstone1000-base.yml
-
-machine: corstone1000-mps3
@@ -0,0 +1,6 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+machine: corstone500
@@ -0,0 +1,10 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+machine: corstone700-fvp
+
+local_conf_header:
+  image: |
+    CORE_IMAGE_EXTRA_INSTALL = "corstone700-test-app"
@@ -0,0 +1,6 @@
+header:
+  version: 9
+  includes:
+    - corstone700-fvp.yml
+
+machine: corstone700-mps3
@@ -0,0 +1,8 @@
+header:
+  version: 9
+
+local_conf_header:
+  cc: |
+    PNBLACKLIST[gcc-cross-arm] = "Using external toolchain"
+    TCMODE = "external-arm"
+    EXTERNAL_TOOLCHAIN = "/usr/local/gcc-arm-10.2-2020.11-aarch64-arm-none-linux-gnueabihf"
@@ -0,0 +1,6 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+machine: fvp-base-arm32
@@ -1,43 +1,7 @@
 header:
-  version: 13
+  version: 9
  includes:
-    - kas/fvp-eula.yml
+    - base.yml

-env:
-  DISPLAY:
-  WAYLAND_DISPLAY:
-  XAUTHORITY:
-
-
-distro: poky
 machine: fvp-base

-defaults:
-  repos:
-    refspec: master
-
-repos:
-  meta-arm:
-    layers:
-      meta-arm:
-      meta-arm-bsp:
-      meta-arm-toolchain:
-
-  poky:
-    url: https://git.yoctoproject.org/git/poky
-    path: layers/poky
-    layers:
-      meta:
-      meta-poky:
-
-local_conf_header:
-  base: |
-    CONF_VERSION = "2"
-    PACKAGE_CLASSES = "package_ipk"
-    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"
-
-target:
-  - core-image-minimal
@@ -1,5 +0,0 @@
-header:
-  version: 13
-
-env:
-  ARM_FVP_EULA_ACCEPT:
@@ -0,0 +1,21 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+repos:
+  meta-arm:
+    layers:
+      meta-gem5:
+
+  meta-openembedded:
+    url: https://git.openembedded.org/meta-openembedded
+    layers:
+      meta-oe:
+
+machine: gem5-arm64
+
+target:
+  - core-image-minimal
+  - perf
+  - gem5-aarch64-native
@@ -0,0 +1,19 @@
+#! /bin/bash
+
+# Read a GitLab CI job name on $1 and transform it to a
+# list of Kas yaml files
+
+set -e -u
+
+# Read Job namne from $1 and split on /
+IFS=/ read -r -a PARTS<<<$1
+
+# Prefix each part with kas/
+PARTS=("${PARTS[@]/#/kas/}")
+
+# Suffix each part with .yml
+PARTS=("${PARTS[@]/%/.yml}")
+
+# Print colon-separated
+IFS=":"
+echo "${PARTS[*]}"
@@ -1,6 +1,6 @@
 header:
-  version: 14
+  version: 9
  includes:
-    - ci/base.yml
+    - base.yml

 machine: juno
@@ -1,12 +1,9 @@
 header:
-  version: 14
+  version: 9

 repos:
  meta-openembedded:
    url: https://git.openembedded.org/meta-openembedded
    layers:
-      meta-filesystems:
-      meta-networking:
      meta-oe:
      meta-python:
-      meta-perl:
@@ -0,0 +1,8 @@
+header:
+  version: 9
+  includes:
+    - meta-python.yml
+
+repos:
+  meta-zephyr:
+    url: https://git.yoctoproject.org/git/meta-zephyr
@@ -0,0 +1,11 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+    - meta-zephyr.yml
+
+machine: musca-b1
+
+target:
+  - trusted-firmware-m
+  - zephyr-philosophers
@@ -1,8 +1,8 @@
 header:
-  version: 14
+  version: 9
  includes:
-    - ci/base.yml
-    - ci/meta-openembedded.yml
+    - base.yml
+    - meta-python.yml

 machine: musca-s1

@@ -1,5 +1,5 @@
 header:
-  version: 14
+  version: 9

 local_conf_header:
  libc: |
@@ -0,0 +1,6 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+machine: n1sdp
@@ -1,12 +1,11 @@
 header:
-  version: 14
+  version: 9
  includes:
-    - ci/base.yml
+    - base.yml

 machine: qemuarm64-secureboot

 target:
  - core-image-base
+  - perf
  - optee-examples
-  - optee-test
-  - optee-os-tadevkit
@@ -1,6 +1,6 @@
 header:
-  version: 14
+  version: 9
  includes:
-    - ci/base.yml
+    - base.yml

 machine: sgi575
@@ -0,0 +1,6 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+machine: tc0
@@ -1,7 +0,0 @@
-header:
-  version: 9
-
-local_conf_header:
-  tftf: |
-    TFA_UBOOT = "0"
-    TFTF_TESTS = "1"
@@ -0,0 +1,92 @@
+meta-arm-autonomy Yocto Layer
+=============================
+
+Introduction
+------------
+This layer provides an hypervisor based solution (currently based on Xen) for
+autonomous system. It contains recipes and classes to build host and guests
+systems.
+
+To start using this layer, please check the
+[Quick Start Guide](documentation/arm-autonomy-quickstart.md).
+
+Dependencies
+------------
+This layer depends on several other Yocto layers:
+* meta-openembedded (https://git.openembedded.org/meta-openembedded)
+* poky (https://git.yoctoproject.org/poky)
+* meta-virtualization (https://git.yoctoproject.org/meta-virtualization)
+
+Distribution Features
+---------------------
+This layer is adding the following Yocto DISTRO_FEATURES:
+
+* arm-autonomy-host: this feature activates functionalities required to build
+  an autonomy host system. It is doing the following:
+  - add 'xen' and 'ipv4' to DISTRO_FEATURES.
+  - add xen backend drivers to linux kernel configuration.
+  - To reduce the root filesystem image size the kernel image is not installed.
+
+* arm-autonomy-guest: this feature activates functionalities to run as guest
+  of an autonomy system. It is doing the following:
+  - add 'ipv4' to DISTRO_FEATURES.
+  - add xen frontend drivers to linux kernel configuration.
+  - add console on hvc0 during init.
+
+Bitbake variables
+-----------------
+Some recipes and classes in this layer are introducing variables which can be
+modified by the user in local.conf.
+Each recipe introducing such variables has a chapter "Bitbake parameters" in
+its documentation.
+
+Those documentation files should be checked for variables:
+- [xen-devicetree](documentation/xen-devicetree.md)
+- [xenguest-manager](documentation/xenguest-manager.md)
+- [xenguest-network-bridge](documentation/xenguest-network-bridge.md)
+
+BSPs
+----
+This layer is adding the following machines:
+
+* arm64-autonomy-guest: this machines creates a minimal BSP suitable to be used
+  as an autonomy guest. It is in fact only activating ARM64 architecture and
+  SMP in the linux kernel and is enabling the DISTRO_FEATURE
+  arm-autonomy-guest.
+
+Images
+------
+This layer is adding the following images:
+
+* arm-autonomy-host-image-minimal: this image includes all elements required
+  to create a minimal arm-autonomy-host system. This includes xen and tools to
+  manage xen guests. This image depends on 'arm-autonomy-host' distribution
+  feature.
+
+Recipes and classes
+-------------------
+This layer is adding the following recipes and classes:
+
+* [xen-devicetree](documentation/xen-devicetree.md): this is a recipe to modify
+  a device tree blob to add information required to boot xen and a Dom0 linux.
+
+* [xenguest-mkimage](documentation/xenguest-mkimage.md): this is a tool to
+  create and modify images to be used as Xen guests.
+
+* [xenguest-manager](documentation/xenguest-manager.md): this is a tool to
+  create/remove/start/stop xen guest generated using xenguest-mkimage.
+
+* [xenguest-network-bridge](documentation/xenguest-network-bridge.md): this
+  recipe add tools and init scripts to create a bridge connected to the
+  external network on the host and allow guests to be connected to it.
+
+Contributing
+------------
+This project has not put in place a process for contributions currently. If you
+would like to contribute, please contact the maintainers
+
+
+Maintainer(s)
+-------------
+* Diego Sueiro <diego.sueiro@arm.com>
+* Bertrand Marquis <bertrand.marquis@arm.com>
@@ -0,0 +1,26 @@
+# This class is to be inherited by image recipes that want to build and install
+# an alternate kernel (set via PREFERRED_PROVIDER_alternate/kernel).
+#
+# It is mandatory to also set the KERNEL_PACKAGE_NAME for the alternate kernel
+# recipe via KERNEL_PACKAGE_NAME_pn-${PREFERRED_PROVIDER_alternate/kernel} and
+# its value needs to be different from "kernel" since this is the default set
+# for PREFERRED_PROVIDER_virtual/kernel.
+#
+# An example of these settings can be found at meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/n1sdp-extra-settings.inc
+#
+# When building and installing an alternate kernel, the kernel-modules packages
+# for both virtual/kernel and alternate/kernel will be installed.
+
+PREFERRED_PROVIDER_alternate/kernel ??= ""
+
+python () {
+    alternate_kernel = d.getVar('PREFERRED_PROVIDER_alternate/kernel')
+    if alternate_kernel:
+        alternate_kernel_pkg_name = d.getVar('KERNEL_PACKAGE_NAME_pn-%s' % alternate_kernel)
+        if alternate_kernel_pkg_name:
+            d.appendVar('EXTRA_IMAGEDEPENDS', ' ' + alternate_kernel)
+            d.appendVar('IMAGE_INSTALL', ' kernel-modules')
+            d.appendVar('IMAGE_INSTALL', ' ' + alternate_kernel_pkg_name + '-modules')
+        else:
+            raise bb.parse.SkipRecipe("No KERNEL_PACKAGE_NAME_pn-%s set" % alternate_kernel )
+}
@@ -0,0 +1,5 @@
+# Include arm-autonomy distro config files if the distro features are set
+
+require ${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', '${ARM_AUTONOMY_DISTRO_CFGDIR}/arm-autonomy-host.inc', '', d)}
+require ${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-guest', '${ARM_AUTONOMY_DISTRO_CFGDIR}/arm-autonomy-guest.inc', '', d)}
+
@@ -0,0 +1,108 @@
+# Create a xenguest image with kernel and filesystem produced by Yocto
+# This will create a .xenguest file that the xenguest-manager can use.
+
+inherit xenguest-image
+
+# We are creating our guest in a local subdirectory
+# force the value so that we are not impacted if the user is changing it
+XENGUEST_IMAGE_DEPLOY_DIR = "${WORKDIR}/tmp-xenguest"
+
+# Name of deployed file (keep standard image name and add .xenguest)
+XENGUEST_IMAGE_DEPLOY ??= "${IMAGE_NAME}"
+
+# Add kernel XENGUEST_IMAGE_KERNEL from DEPLOY_DIR_IMAGE to image
+xenguest_image_add_kernel() {
+    srcfile="${1:-}"
+    if [ -z "${srcfile}" ]; then
+        srcfile="${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_KERNEL}"
+    fi
+    call_xenguest_mkimage partial --xen-kernel=$srcfile
+}
+
+# Add rootfs file to the image
+xenguest_image_add_rootfs() {
+    call_xenguest_mkimage partial \
+        --disk-add-file=${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${IMAGE_TYPEDEP_xenguest}:rootfs.${IMAGE_TYPEDEP_xenguest}
+}
+
+# Pack xenguest image
+xenguest_image_pack() {
+    mkdir -p ${IMGDEPLOYDIR}
+    rm -f ${IMGDEPLOYDIR}/${XENGUEST_IMAGE_DEPLOY}.xenguest
+    call_xenguest_mkimage pack \
+        ${IMGDEPLOYDIR}/${XENGUEST_IMAGE_DEPLOY}.xenguest
+}
+
+#
+# Task finishing the bootimg
+# We need this task to actually create the symlinks
+#
+python do_bootimg_xenguest() {
+    subtasks = d.getVarFlag('do_bootimg_xenguest', 'subtasks')
+
+    bb.build.exec_func('xenguest_image_clone', d)
+    if subtasks:
+        for tk in subtasks.split():
+            bb.build.exec_func(tk, d)
+    bb.build.exec_func('xenguest_image_pack', d)
+    bb.build.exec_func('create_symlinks', d)
+}
+# This is used to add sub-tasks to do_bootimg_xenguest
+do_bootimg_xenguest[subtasks] = ""
+# Those are required by create_symlinks to find our image
+do_bootimg_xenguest[subimages] = "xenguest"
+do_bootimg_xenguest[imgsuffix] = "."
+do_bootimg_xenguest[depends] += "xenguest-base-image:do_deploy"
+# Need to have rootfs so all recipes have deployed their content
+do_bootimg_xenguest[depends] += "${PN}:do_rootfs"
+
+# This set in python anonymous after, just set a default value here
+IMAGE_TYPEDEP_xenguest ?= "tar"
+
+# We must not be built at rootfs build time because we need the kernel
+IMAGE_TYPES_MASKED += "xenguest"
+IMAGE_TYPES += "xenguest"
+
+python __anonymous() {
+    # Do not do anything if we are not in the want FSTYPES
+    if bb.utils.contains_any('IMAGE_FSTYPES', 'xenguest', '1', '0', d):
+
+        # Check the coherency of the configuration
+        rootfs_needed = False
+        rootfs_file = ''
+        kernel_needed = False
+
+        rootfs_file = xenguest_image_rootfs_file(d)
+        if rootfs_file:
+            rootfs_needed = True
+
+        if d.getVar('XENGUEST_IMAGE_KERNEL') and not d.getVar('INITRAMFS_IMAGE'):
+            # If INITRAMFS_IMAGE is set, even if INITRAMFS_IMAGE_BUNDLE is not
+            # set to 1 to bundle the initramfs with the kernel, kernel.bbclass
+            # is setting a dependency on ${PN}:do_image_complete. We cannot
+            # in this case depend on do_deploy as it would create a circular
+            # dependency:
+            # do_image_complete would depend on kernel:do_deploy which would
+            # depend on ${PN}:do_image_complete
+            # In the case INITRAMFS_IMAGE_BUNDLE = 1, the kernel-xenguest class
+            # will handle the creation of a xenguest image with the kernel.
+            # In the other case the kernel can be added manually to the image.
+            kernel_needed = True
+
+        bb.build.addtask('do_bootimg_xenguest', 'do_image_complete', None, d)
+
+        if rootfs_needed:
+            # tell do_bootimg_xenguest to call add_rootfs
+            d.appendVarFlag('do_bootimg_xenguest', 'subtasks', ' xenguest_image_add_rootfs')
+            # do_bootimg_xenguest will need the tar file
+            d.appendVarFlag('do_bootimg_xenguest', 'depends', ' %s:do_image_tar' % (d.getVar('PN')))
+            # set our TYPEDEP to the proper compression
+            d.setVar('IMAGE_TYPEDEP_xenguest', 'tar' + (rootfs_file.split('.tar', 1)[1] or ''))
+
+        if kernel_needed:
+            # Tell do_bootimg_xenguest to call xenguest_image_add_kernel
+            d.appendVarFlag('do_bootimg_xenguest', 'subtasks', ' xenguest_image_add_kernel')
+            # we will need kernel do_deploy
+            d.appendVarFlag('do_bootimg_xenguest', 'depends', ' virtual/kernel:do_deploy')
+}
+
@@ -0,0 +1,34 @@
+# Create a xenguest image containing the kernel with initramfs when
+# initramfs is activated
+# This is done using kernel-fitimage as model
+# To activate this, kernel-xenguest must be added to KERNEL_CLASSES
+
+inherit xenguest-image
+
+# use a local copy to pack all together
+XENGUEST_IMAGE_DEPLOY_DIR = "${WORKDIR}/tmp-xenguest"
+
+python __anonymous () {
+    # only if xenguest image type is present
+    if bb.utils.contains('IMAGE_FSTYPES', 'xenguest', '1', '0', d):
+        # only if initramfs bundle is activated
+        if d.getVar('INITRAMFS_IMAGE') and d.getVar('INITRAMFS_IMAGE_BUNDLE') == "1":
+            if not bb.utils.contains('KERNEL_IMAGETYPES', 'Image', '1', '0', d):
+                bb.fatal("xenguest image type with initramfs require Image kernel image type")
+            bb.build.addtask('do_assemble_xenguest_initramfs', 'do_deploy', 'do_bundle_initramfs', d)
+}
+
+do_assemble_xenguest_initramfs() {
+    xenguest_image_clone
+    call_xenguest_mkimage partial --xen-kernel=${B}/${KERNEL_OUTPUT_DIR}/Image.initramfs
+    rm -f ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest
+    call_xenguest_mkimage pack ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest
+}
+do_assemble_xenguest_initramfs[depends] += "${INITRAMFS_IMAGE}:do_image_complete"
+
+kernel_do_deploy_append() {
+    if [ -f "${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest" ]; then
+        install -m 0644 ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest "$deployDir/Image-${INITRAMFS_NAME}.xenguest"
+        ln -snf Image-${INITRAMFS_NAME}.xenguest $deployDir/Image-${INITRAMFS_LINK_NAME}.xenguest
+    fi
+}
@@ -0,0 +1,114 @@
+# This class must be used to extend the xenguest image
+# It provides variables to add init scripts, a dtb, xen files or disk files.
+#
+# The class is extending deploy function so you recipe must inherit deploy and
+# have a do_deploy function (even if it is empty)
+
+# Use standard xenguest-image
+inherit xenguest-image
+
+# Add a DTB file for the guest
+# Only one file should be added, if this is set multiple times or in several
+# recipes, the last recipe setting it will prevail.
+XENGUEST_EXTRA_DTB ??= ""
+
+# Add a ramdisk file for the guest
+# Only one file should be added, if this is set multiple times or in several
+# recipes, the last recipe setting it will prevail.
+XENGUEST_EXTRA_RAMDISK ??= ""
+
+# Append something to the guest xen configuration
+# All files here will be merged together in the final xen configuration
+# This can contain several files or be used in several recipes
+XENGUEST_EXTRA_XENCONFIG ??= ""
+
+# Add a xenguest init, init-pre or init-post script
+XENGUEST_EXTRA_INIT_PRE ??= ""
+XENGUEST_EXTRA_INIT ??= ""
+XENGUEST_EXTRA_INIT_POST ??= ""
+
+# Add xenguest files, (to be used in extra xen config for example)
+# several files may be added, space separated, the path will be kept on the
+# generated xenguest image (if dir1/file1 is added, it can be used as
+# dir1/file1 file in the xen configuration).
+XENGUEST_EXTRA_FILES ??= ""
+
+# Add xenguest disk files (to be used as disk partition content)
+# several files may be added, space separated, the path will be kept on the
+# generated xenguest image (if dir1/file1 is added, it can be used as
+# dir1/file1 file in the disk content parameters).
+XENGUEST_EXTRA_DISK_FILES ??= ""
+
+do_deploy_append() {
+    if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
+        -z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
+        die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
+    fi
+    rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+    mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+
+    if [ -n "${XENGUEST_EXTRA_DTB}" ]; then
+        if [ ! -f ${XENGUEST_EXTRA_DTB} ]; then
+            die "xenguest-image: DTB file ${XENGUEST_EXTRA_DTB} does not exist"
+        fi
+        call_xenguest_mkimage partial --xen-device-tree=${XENGUEST_EXTRA_DTB}
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_RAMDISK}" ]; then
+        if [ ! -f ${XENGUEST_EXTRA_RAMDISK} ]; then
+            die "xenguest-image: DTB file ${XENGUEST_EXTRA_RAMDISK} does not exist"
+        fi
+        call_xenguest_mkimage partial --xen-ramdisk=${XENGUEST_EXTRA_RAMDISK}
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_XENCONFIG}" ]; then
+        for f in ${XENGUEST_EXTRA_XENCONFIG}; do
+            if [ ! -f $f ]; then
+                die "xenguest-image: Xen config $f does not exist"
+            fi
+            call_xenguest_mkimage partial --xen-append=$f
+        done
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_INIT_PRE}" ]; then
+        if [ ! -f ${XENGUEST_EXTRA_INIT_PRE} ]; then
+            die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT_PRE} does not exist"
+        fi
+        call_xenguest_mkimage partial --init-pre=${XENGUEST_EXTRA_INIT_PRE}
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_INIT}" ]; then
+        if [ ! -f ${XENGUEST_EXTRA_INIT} ]; then
+            die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT} does not exist"
+        fi
+        call_xenguest_mkimage partial --init-script=${XENGUEST_EXTRA_INIT}
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_INIT_POST}" ]; then
+        if [ ! -f ${XENGUEST_EXTRA_INIT_POST} ]; then
+            die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT_POST} does not exist"
+        fi
+        call_xenguest_mkimage partial --init-post=${XENGUEST_EXTRA_INIT_POST}
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_FILES}" ]; then
+        for f in ${XENGUEST_EXTRA_FILES}; do
+            if [ ! -f $f ]; then
+                die "xenguest-image: Xen file $f does not exist"
+            fi
+            call_xenguest_mkimage partial --xen-add-file=$f
+        done
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_DISK_FILES}" ]; then
+        for f in ${XENGUEST_EXTRA_DISK_FILES}; do
+            if [ ! -f $f ]; then
+                die "xenguest-image: Disk file $f does not exist"
+            fi
+            call_xenguest_mkimage partial --disk-add-file=$f
+        done
+    fi
+}
+# Need to have xenguest-image tool
+do_deploy[depends] += "xenguest-base-image:do_deploy"
+
@@ -0,0 +1,208 @@
+# This class must be used to create, extend or pack a xenguest image.
+# It is using xenguest-mkimage tool to do operations
+
+DEPENDS += "xenguest-mkimage-native"
+
+#
+# Xenguest image parameters
+# All the following parameters can be modified in local.conf or on recipes
+# inheriting this class
+#
+
+# Guest memory size in MB
+XENGUEST_IMAGE_MEMORY_SIZE ??= "512"
+
+# Guest number of vcpus
+XENGUEST_IMAGE_NUM_VCPUS ??= "1"
+
+# Guest auto boot during init, set to 1 to have guest started during init or
+# to 0 if the guest should not be auto started
+XENGUEST_IMAGE_AUTOBOOT ??= "1"
+
+# Partition containing the root file system
+# Xen will actually add root=${XENGUEST_IMAGE_ROOT} to your guest kernel
+# command line
+# You can let this empty if the root filesystem is specified in an other way
+# and have root= option added to the command line for example or if you don't
+# need a root filesystem mounted for your guest (initrd for example)
+XENGUEST_IMAGE_ROOT ??= "/dev/xvda1"
+
+# Guest kernel command line arguments
+XENGUEST_IMAGE_CMDLINE ??= "earlyprintk=xenboot console=hvc0 rw"
+
+# Extra commands to add to xenguest-image when creating the image
+XENGUEST_IMAGE_EXTRA_CMD ??= ""
+
+# Kernel binary
+# This value is used by the xenguest image type but is declared here to have
+# all variables in the same place
+# If this value is empty no kernel will be added to the image
+XENGUEST_IMAGE_KERNEL ??= "Image"
+
+# Size of the disk to create (if 0 no disk will be created and rootfs will not
+# be included in the xenguest image)
+XENGUEST_IMAGE_DISK_SIZE ??= "${@ '4' if not d.getVar('INITRAMFS_IMAGE') else '0'}"
+
+# set empty partition to be used by xenguest-manager for this image
+XENGUEST_IMAGE_DISK_DEVICE ??= ""
+
+#
+# XENGUEST_IMAGE_DISK_PARTITIONS is used to describe the partitions to setup
+# and their content.
+# It must be set to a space separated list of entries with each entry having
+# the format num:sz:[fs]:[file] where:
+# - num is a partition number
+# - sz is the partition size in MB or GB(default), e.g 1000M or 1[G]
+# - fs is optional filesystem to use for the partition
+# - file is optionally pointing to a file to use as content of the partition
+#   Please check image_types_xenguest.bbclass for rootfs handling of files
+#
+# Default value creates a partition 1 using the full disk, formated with ext4
+# and containing the root filesystem produced by Yocto
+XENGUEST_IMAGE_DISK_PARTITIONS ??= "1:${XENGUEST_IMAGE_DISK_SIZE}:ext4:rootfs.tar.gz"
+
+# XENGUEST_IMAGE_NETWORK_TYPE can be set to "bridge", "nat" or "none".
+# The "bridge" type will share the physical eth interface from dom0 with the
+# domU. This will allow the domU to have access to the external network.
+# The "nat" type will setup a virtual network between dom0 and domU and also
+# configure and run the kea dhcp4 server on dom0 to serve the domU.
+# The "none" type will not affect any networking setting between on dom0 and
+# domU.
+XENGUEST_IMAGE_NETWORK_TYPE ??= "bridge"
+
+# Sub-directory in wich the guest is created. This is create in deploy as a
+# subdirectory and must be coherent between all components using this class so
+# it must only be modified from local.conf if needed
+XENGUEST_IMAGE_DEPLOY_SUBDIR ?= "xenguest"
+
+# Directory in which the xenguest should be deployed
+# a sub-directory named ${XENGUEST_IMAGE_DEPLOY_SUBDIR} will be created there.
+# This should be set to:
+# - ${DEPLOYDIR} (default) if creating or extending the xenguest for a normal
+#   recipe.
+# - something in ${WORKDIR} if you need to clone and manipulate an image
+XENGUEST_IMAGE_DEPLOY_DIR ??= "${DEPLOYDIR}"
+
+#
+# Wrapper to call xenguest-mkimage
+# It is using XENGUEST_IMAGE_DEPLOY_DIR and XENGUEST_IMAGE_DEPLOY_SUBDIR
+# to find the image to operate on
+#
+# Usage: call_xenguest_mkimage [operation] [args]
+call_xenguest_mkimage() {
+    local cmd="${1}"
+    local img="${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}"
+    shift
+
+    echo "xenguest-mkimage $cmd $img $@"
+    xenguest-mkimage $cmd $img $@
+}
+
+#
+# Create an initial xenguest image.
+# This is a task which must be added in a recipe inheriting deploy
+# It is using XENGUEST_IMAGE_MEMORY_SIZE, XENGUEST_IMAGE_NUM_VCPUS,
+#  XENGUEST_IMAGE_AUTOBOOT, XENGUEST_IMAGE_ROOT, XENGUEST_IMAGE_EXTRA_CMD,
+#  XENGUEST_IMAGE_CMDLINE, XENGUEST_IMAGE_DISK_SIZE and
+#  XENGUEST_IMAGE_DISK_PARTITIONS to customize the initial guest
+#
+xenguest_image_create() {
+    if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
+        -z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
+        die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
+    fi
+
+    rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+
+    mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+
+    # Create the image
+    call_xenguest_mkimage create --xen-memory=${XENGUEST_IMAGE_MEMORY_SIZE} \
+        --xen-vcpus=${XENGUEST_IMAGE_NUM_VCPUS} \
+        --xen-root=${XENGUEST_IMAGE_ROOT} \
+        ${XENGUEST_IMAGE_EXTRA_CMD}
+
+    # add command line
+    if [ -n "${XENGUEST_IMAGE_CMDLINE}" ]; then
+        call_xenguest_mkimage update --xen-clean-extra
+        for arg in ${XENGUEST_IMAGE_CMDLINE}; do
+            call_xenguest_mkimage update --xen-extra=$arg
+        done
+    fi
+
+    # create disk if needed
+    disksize="${XENGUEST_IMAGE_DISK_SIZE}"
+    case ${disksize:=0} in
+        0|0M|0G)
+            ;;
+        *)
+            # setup disk size
+            call_xenguest_mkimage update --disk-reset-config --disk-size=$disksize
+
+            diskparts="${XENGUEST_IMAGE_DISK_PARTITIONS}"
+            if [ -n "$diskparts" ]; then
+                for arg in $diskparts; do
+                    call_xenguest_mkimage update --disk-add-part=$arg
+                done
+            fi
+            diskdevice="${XENGUEST_IMAGE_DISK_DEVICE}"
+            if [ -n "$diskdevice" ]; then
+                call_xenguest_mkimage update --disk-device="${diskdevice}"
+            fi
+
+            ;;
+    esac
+
+
+    if [ "${XENGUEST_IMAGE_AUTOBOOT}" = "1" ]; then
+        call_xenguest_mkimage update --set-param=GUEST_AUTOBOOT=1
+    else
+        call_xenguest_mkimage update --set-param=GUEST_AUTOBOOT=0
+    fi
+
+    if [ -n "${XENGUEST_IMAGE_NETWORK_TYPE}" ]; then
+        call_xenguest_mkimage update --set-param=XENGUEST_NETWORK_TYPE="${XENGUEST_IMAGE_NETWORK_TYPE}"
+    else
+        call_xenguest_mkimage update --set-param=XENGUEST_NETWORK_TYPE="none"
+    fi
+}
+
+#
+# Clone the current xenguest from deploy to manipulate it locally
+# This is required if you need to change things before packing an image
+# To set the local directory where to clone you must set
+# XENGUEST_IMAGE_DEPLOY_DIR if you don't want to use do_deploy to modify the
+# image
+#
+xenguest_image_clone() {
+    if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
+        -z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
+        die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
+    fi
+
+    if [ ! -f ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}/guest.cfg ]; then
+        die "xenguest-image: ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR} does not contain a valid guest"
+    fi
+
+    rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+    mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}
+    cp -rf ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR} \
+        ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+}
+
+# Helper function to retrieve rootfs file if present in one partition
+# This can return an empty string or rootfs.tar[.COMP]
+def xenguest_image_rootfs_file(d):
+    disksize = d.getVar('XENGUEST_IMAGE_DISK_SIZE')
+    # if disksize is 0, we don't create anything
+    if not disksize or disksize == '0':
+        return ""
+    # Find first partition with file=rootfs.tar*
+    partlist = d.getVar('XENGUEST_IMAGE_DISK_PARTITIONS')
+    if partlist:
+        for partdesc in partlist.split():
+            partelems = partdesc.split(':', 3)
+            if partelems[3]:
+                if partelems[3].startswith('rootfs.tar'):
+                    return partelems[3]
+    return ""
@@ -0,0 +1,15 @@
+# This files is added when DISTRO_FEATURES contains arm-autonomy-guest
+
+# We need to have ipv4 activated
+DISTRO_FEATURES_append = " ipv4"
+
+# Build a xenguest type image
+IMAGE_CLASSES += "image_types_xenguest"
+IMAGE_FSTYPES += "xenguest"
+
+# xenguest kernel extension to handle initramfs
+KERNEL_CLASSES += "kernel-xenguest"
+
+IMAGE_INSTALL_append = "${@bb.utils.contains('DISTRO_FEATURES', 'docker', \
+                        ' packagegroup-docker-runtime-minimal', \
+                        '', d)}"
@@ -0,0 +1,21 @@
+# This files is added when DISTRO_FEATURES contains arm-autonomy-host
+
+# We need to have xen and ipv4 activated
+DISTRO_FEATURES_append = " xen ipv4"
+DISTRO_FEATURES_NATIVE_append = " arm-autonomy-host"
+
+# Don't include kernels in standard images when building arm-autonomy-host
+# If the kernel image is needed in the rootfs the following should be set from
+# a bbappend: RDEPENDS_${KERNEL_PACKAGE_NAME}-base = "${KERNEL_PACKAGE_NAME}-image"
+RDEPENDS_${KERNEL_PACKAGE_NAME}-base ?= ""
+
+# Require extra machine specific settings from meta-arm-bsp dynamic-layers only
+# if meta-arm-bsp is in the bblayers.conf
+# Directory for meta-arm-autonomy/dynamic-layers/meta-arm-bsp machine extra settings
+ARM_AUTONOMY_ARM_BSP_DYNAMIC_EXTRA_CFGDIR = "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/conf/machine"
+ARM_AUTONOMY_MACHINE_EXTRA_REQUIRE ?= \
+"${ARM_AUTONOMY_ARM_BSP_DYNAMIC_EXTRA_CFGDIR}/arm-autonomy-machine-extra-settings.inc"
+
+require ${@bb.utils.contains('BBFILE_COLLECTIONS', 'meta-arm-bsp', \
+                             '${ARM_AUTONOMY_MACHINE_EXTRA_REQUIRE}' , \
+                             '', d)}
@@ -0,0 +1,38 @@
+# Add layer to BBPATH
+BBPATH .= ":${LAYERDIR}"
+
+# Add recipes-* directories to BBFILES
+BBFILES += " \
+    ${LAYERDIR}/recipes-*/*/*.bb \
+    ${LAYERDIR}/recipes-*/*/*.bbappend \
+    "
+
+BBFILE_COLLECTIONS += "meta-arm-autonomy"
+BBFILE_PATTERN_meta-arm-autonomy = "^${LAYERDIR}/"
+BBFILE_PRIORITY_meta-arm-autonomy = "5"
+LAYERDEPENDS_meta-arm-autonomy = " \
+   core \
+   yocto \
+   openembedded-layer \
+   virtualization-layer \
+"
+LAYERSERIES_COMPAT_meta-arm-autonomy = "gatesgarth"
+
+# We don't activate virtualization feature from meta-virtualization as it
+# brings in lots of stuff we don't need. We need to disable the sanity check
+# otherwise the user will see a warning on each build.
+SKIP_META_VIRT_SANITY_CHECK = "1"
+
+ARM_AUTONOMY_LAYERDIR := "${LAYERDIR}"
+# Directory of our distro config files
+ARM_AUTONOMY_DISTRO_CFGDIR = "${ARM_AUTONOMY_LAYERDIR}/conf/distro/include/"
+
+# Add class to handle arm-autonomy distro extensions
+USER_CLASSES_append = " arm-autonomy-features"
+
+BBFILES_DYNAMIC += " \
+    meta-arm-bsp:${LAYERDIR}/dynamic-layers/meta-arm-bsp/*/*/*.bbappend \
+    meta-gem5:${LAYERDIR}/dynamic-layers/meta-gem5/*/*/*.bbappend \
+"
+# Root directory for the meta-arm-autonomy/dynamic-layers/meta-arm-bsp
+ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR = "${ARM_AUTONOMY_LAYERDIR}/dynamic-layers/meta-arm-bsp"
@@ -0,0 +1,17 @@
+#@TYPE: Machine
+#@NAME: Autonomy Guest ARM64 machine
+#@DESCRIPTION: Machine configuration for ARM64 Autonomy Guest
+
+TUNE_FEATURES = "aarch64"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+KERNEL_IMAGETYPE = "Image"
+
+IMAGE_FSTYPES += "tar.bz2"
+
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_VERSION_linux-yocto ?= "5.10%"
+
+DISTRO_FEATURES += "arm-autonomy-guest"
+
@@ -0,0 +1,195 @@
+arm-autonomy Multiconfig Build Environment Instructions
+==================
+
+This documentation explains how to simplify the process of building hosts
+and guests in a single bitbake command, rather than in seperate build
+folders. You can read more about multiconfig in the bitbake documentation:
+
+ - [bitbake user manual](https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html)
+
+To achieve a multiconfig build, a number of different config files need to
+be created in a single build directory.
+
+Create a new project
+----------------
+
+Before you start, you will need to follow the instructions in
+"Create a project" from the quickstart guide, to create a new project
+directory with
+  ```
+  oe-init-build-env my-mc-project
+  ```
+Ensure it has all the required layers in bblayers.conf as listed in
+`arm-autonomy-quickstart.md`. The result should be a directory containing:
+
+```
+-- conf
+ | -- bblayers.conf
+ | -- local.conf
+ | -- templateconf.cfg
+```
+
+Add multiconfig
+----------------
+
+Here are the steps required to make the project build both the host and any
+number of guests as required.
+
+1. Create a new directory under `conf/` named `multiconfig/`
+
+2. Create two new files in this directory:
+`multiconfig/host.conf`
+`multiconfig/guest.conf`
+These files will contain any configurations that a specific to either the
+host or the guest
+
+```
+-- conf
+ | -- bblayers.conf
+ | -- local.conf
+ | -- templateconf.cfg
+ | -- multiconfig
+    | -- host.conf
+    | -- guest.conf
+```
+
+3. In `local.conf` the following config variables must be added:
+
+```
+MACHINE ?= "fvp-base"
+
+# ---Guest Config Start--- #
+MC_GUEST = "guest"
+
+MC_GUEST_NAME = "guest1"
+
+MC_GUEST_IMAGERECIPE = "core-image-minimal"
+MC_GUEST_MACHINE = "arm64-autonomy-guest"
+
+MC_GUEST_INITRAMFS_IMAGE_BUNDLE ?= ""
+MC_GUEST_INITRAMFS_IMAGE ?= ""
+
+# Uncomment for initramfs
+#MC_GUEST_INITRAMFS_IMAGE_BUNDLE = "1"
+#MC_GUEST_INITRAMFS_IMAGE = "${MC_GUEST_IMAGERECIPE}"
+
+# These variables are set automatically, don't edit them!
+MC_GUEST_FILENAME_PREFIX = "${@ 'Image-initramfs' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else '${MC_GUEST_IMAGERECIPE}' }"
+
+MC_GUEST_FILENAME = "${MC_GUEST_FILENAME_PREFIX}-${MC_GUEST_MACHINE}.xenguest"
+
+MC_GUEST_DEP = "${@ 'virtual/kernel:do_deploy' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else '${MC_GUEST_IMAGERECIPE}:do_image_complete'}"
+
+MC_DOIMAGE_MCDEPENDS += "mc:${MC_HOST}:${MC_GUEST}:${MC_GUEST_DEP} "
+
+BBMULTICONFIG += "${MC_GUEST} "
+
+ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS += "file://${TOPDIR}/${MC_GUEST}/deploy/images/${MC_GUEST_MACHINE}/${MC_GUEST_FILENAME};guestname=${MC_GUEST_NAME} "
+# ---Guest Config End--- #
+
+# ---Host Config Start--- #
+MC_HOST = "host"
+
+BBMULTICONFIG += "${MC_HOST} "
+# ---Host Config End--- #
+```
+
+These variables will be used in both of the multiconf files. `MC_HOST` and
+`MC_GUEST` should not be altered without renaming the conf files, but most
+`MC_GUEST_*` variables can be customised if you desire.
+
+4. Next set the contents of `multiconfig/guest.conf`:
+
+```
+TMPDIR = "${TOPDIR}/${MC_GUEST}"
+
+MACHINE = "${MC_GUEST_MACHINE}"
+DISTRO_FEATURES += " arm-autonomy-guest"
+
+INITRAMFS_IMAGE_BUNDLE = "${MC_GUEST_INITRAMFS_IMAGE_BUNDLE}"
+INITRAMFS_IMAGE = "${MC_GUEST_INITRAMFS_IMAGE}"
+
+IMAGE_FSTYPES += "${@ 'cpio' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else ''}"
+
+# ANY OTHER GUEST CONFIG
+```
+
+This contents shouldn't be changed directly, rather change the equivalent
+config in local.conf. You can append any other config desired for the
+guest at this point, for example `XENGUEST_IMAGE_DISK_SIZE`
+
+Make sure not to change `${DEPLOY_DIR_IMAGE}` to anything other than
+`${TMPDIR}/deploy/images`, as this is assumed by local.conf.
+
+5. Lastly set the contents of `multiconfig/host.conf`:
+
+```
+TMPDIR = "${TOPDIR}/${MC_HOST}"
+
+DISTRO_FEATURES += " arm-autonomy-host"
+```
+
+Building the image
+----------------
+
+To build the multiconfig image the command is:
+```
+bitbake mc:host:arm-autonomy-host-image-minimal
+```
+
+You should see that this triggers guest tasks to be built in
+parallel. Once the build completes the guest will already be in the
+rootfs of the host thanks to `ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUEST`
+
+The deployed image including the guest will be in `host/deploy/images/`
+
+
+Multiple Guests
+----------------
+
+To have multiple guests with the same config the line which appends to
+`ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUEST` just needs to be duplicated with
+a different guestname.
+
+To have different config for each guest, each will need its own config
+file similar to guest.conf, ensuring TMPDIR is set to a different path,
+and everything between `---Guest Config Start---` and
+`---Guest Config End---` will need to be duplicated.
+
+Any copies of variables that start `MC_GUEST` must be altered to avoid
+collisions (e.g. `MC_GUEST_2_*`), and the name of the conf file must also
+be added to BBMULTICONFIG.
+
+
+Guest with provisioned disk
+----------------
+
+To add guest rootfs partition to host wic image,
+set `AUTONOMY_HOST_EXTRA_PARTITION` with proper wks partition entry, e.g:
+
+```
+AUTONOMY_HOST_EXTRA_PARTITION = "part --label provisioned-guest --source rawcopy --fstype=ext4 --ondisk sda --align 1024 \
+--sourceparams=file=${TOPDIR}/${MC_GUEST}/deploy/images/${MC_GUEST_MACHINE}/${MC_GUEST_FILENAME_PREFIX}-${MC_GUEST_MACHINE}.ext4"
+```
+
+inside host.conf file.
+
+The rest of the configuration has to be appended to guest.conf file:
+
+```
+XENGUEST_IMAGE_DISK_SIZE = "0"
+XENGUEST_IMAGE_SRC_URI_XEN_CONFIG = "file://\${TOPDIR}/path/to/rootdisk.cfg"
+XENGUEST_IMAGE_DISK_DEVICE = "_GUEST_DISK_DEVICE_"
+XENGUEST_IMAGE_ROOT = "/dev/xvda"
+IMAGE_ROOTFS_SIZE = "102400"
+IMAGE_FSTYPES = "ext4"
+```
+
+content of rootdisk.cfg"
+
+```
+disk = ["phy:_GUEST_DISK_DEVICE_,xvda,w"]
+```
+
+`_GUEST_DISK_DEVICE_` should be substituted with `/dev/sdaX`,
+according to wks file.
@@ -0,0 +1,232 @@
+arm-autonomy Quick Start
+==================
+
+This documentation is explaining how to quickly start with arm-autonomy layer
+and the main features provided.
+You will find in the documentation directory some more detailed documentation
+for each of the functionalites provided by this layer.
+
+What to use this layer for?
+---------------------------
+Using this layer, you can easily and rapidly create a system based on Xen with
+one or more guests created using Yocto.
+
+For this you will need to create at least 2 Yocto projects:
+- a host project: This one will compile Xen and create a Linux system to be
+  used as Xen Dom0. The Linux system will contain all functionalities required
+  to start and manage guests.
+- one or several guest projects: Those will create Linux systems with the
+  required Linux kernel configuration to run as Xen DomU.
+
+Prepare your system
+-------------------
+
+First you must download the Yocto layers needed:
+ - [meta-openembedded](https://git.openembedded.org/meta-openembedded)
+ - [poky](https://git.yoctoproject.org/poky)
+ - [meta-virtualization](https://git.yoctoproject.org/meta-virtualization)
+ - [meta-arm](https://git.yoctoproject.org/meta-arm)
+ - all other layers you might want to use
+
+For each of the downloaded layer make sure you checkout the release of Yocto
+you want to use (for example gatesgarth using `git checkout gatesgarth`).
+
+Please follow [Yocto documentation](https://www.yoctoproject.org/docs/latest/brief-yoctoprojectqs/brief-yoctoprojectqs.html)
+in order to have the required dependencies.
+
+
+Create a project
+----------------
+
+Here are the main steps to create an arm-autonomy project:
+
+1. create a new Yocto project using `oe-init-build-env` in a new directory:
+  ```
+  oe-init-build-env my-project
+  ```
+
+2. Add `meta-arm/meta-arm-autonomy` layer to the list of layers of your
+  project in the `conf/bblayers.conf`. Also add any other layers you
+  might need (for example `meta-arm/meta-arm-bsp` and `meta-arm/meta-arm` to
+  use Arm boards like Juno or FVP emulator). You can achieve this by using
+  the `bitbake-layers add-layer layerdir [layerdir ...]` command.
+  For example:
+  ```
+  export LAYERDIR_BASE="/home/user/arm-autonomy/"
+  bitbake-layers add-layer $LAYERDIR_BASE/meta-poky $LAYERDIR_BASE/meta-yocto-bsp \
+   $LAYERDIR_BASE/meta-openembedded/meta-oe $LAYERDIR_BASE/meta-openembedded/meta-python \
+   $LAYERDIR_BASE/meta-openembedded/meta-filesystems $LAYERDIR_BASE/meta-openembedded/meta-networking \
+   $LAYERDIR_BASE/meta-arm/meta-arm $LAYERDIR_BASE/meta-arm/meta-arm-toolchain \
+   $LAYERDIR_BASE/meta-arm/meta-arm-bsp $LAYERDIR_BASE/meta-arm/meta-arm-autonomy \
+  ```
+
+  Example of a `conf/bblayers.conf`:
+  ```
+  BBLAYERS ?= " \
+    /home/user/arm-autonomy/poky/meta \
+    /home/user/arm-autonomy/poky/meta-poky \
+    /home/user/arm-autonomy/poky/meta-yocto-bsp \
+    /home/user/arm-autonomy/meta-openembedded/meta-oe \
+    /home/user/arm-autonomy/meta-openembedded/meta-python \
+    /home/user/arm-autonomy/meta-openembedded/meta-filesystems \
+    /home/user/arm-autonomy/meta-openembedded/meta-networking \
+    /home/user/arm-autonomy/meta-virtualization \
+    /home/user/arm-autonomy/meta-arm/meta-arm \
+    /home/user/arm-autonomy/meta-arm/meta-arm-toolchain \
+    /home/user/arm-autonomy/meta-arm/meta-arm-bsp \
+    /home/user/arm-autonomy/meta-arm/meta-arm-autonomy \
+    "
+  ```
+
+  Be aware that changing the order may break some dependencies if editing the
+  config file manually.
+
+Those steps will have to be done for each project you will have to create.
+
+Host project
+------------
+The host project will build Xen and the Dom0 Linux. It will be the only project
+that will be specific to the board (MACHINE) you will be running on.
+
+To create a host project:
+1. Follow the steps of "Create a project"
+
+2. Add the layers in `bblayers.conf` required to build a Yocto project for the
+   board you want to use.
+   For example to use Arm FVP Base emulator, add `meta-arm/meta-arm` and
+   `meta-arm/meta-arm-bsp`.
+
+3. edit conf/local.conf to add `arm-autonomy-host` to the DISTRO_FEATURES and
+   set MACHINE to the board you want to use.
+   For example, add the following lines:
+  ```
+  MACHINE = "fvp-base"
+  DISTRO_FEATURES += "arm-autonomy-host"
+  ```
+
+4. build the image using `bitbake arm-autonomy-host-image-minimal`
+
+The project will generate a Linux kernel, a root filesystem, a Xen binary and
+a DTB modified to include the required entries to boot Xen and Linux as Dom0
+(this DTB has the extension `-xen.dtb`).
+
+To boot the system using an u-boot base board you will need to:
+- Load the kernel (by default at 0x80080000 unless you modify
+  XEN_DEVICETREE_DOM0_ADDR value)
+- Load the xen device tree (for example at 0x83000000)
+- Load the xen-efi binary (for example at 0x84000000)
+- run using `booti 0x84000000 - 0x83000000`
+
+In this example the addresses might need to be adapted depending on your board.
+
+Guest project
+-------------
+The guest projects are not target specific and will use a Yocto MACHINE defined
+in meta-arm-autonomy to include only the Linux configuration required to run
+a xen guest.
+
+To create a guest project:
+
+1. Follow the steps of "Create a project"
+
+2. Optionaly add layers required to build the image and features you need.
+
+3. edit conf/local.conf to add `arm-autonomy-guest` to the DISTRO_FEATURES and
+   set MACHINE to `arm64-autonomy-guest`:
+  ```
+  MACHINE = "arm64-autonomy-guest"
+  DISTRO_FEATURES += "arm-autonomy-guest"
+  ```
+
+4. build the image you want.
+   For example `bitbake core-image-minimal`
+
+The build will create a ".xenguest" image that can be use on an host project
+with the xenguest-manager.
+
+The guest can also be built as a 'multiconfig' sub project of the host, see
+`meta-arm-autonomy/documentation/arm-autonomy-multiconfig.md` for more information
+
+Include guests directly in the host image
+-----------------------------------------
+The layer provides a way to directly include in the host project one or several
+images generated by guest projects.
+
+To use this feature, you must edit your host project `local.conf` file and
+add set ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS to the list of xenguest images
+you want to include in your host. Each xenguest image must be given using a
+full path to it.
+For example:
+```
+ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS = "/home/user/guest-project/tmp/deploy/images/arm64-autonomy-guest/core-image-minimal-arm64-autonomy-guest.xenguest;guestname=myguest"
+```
+This will add the guest and name it `myguest` on the host project image and
+the xenguest-manager will automatically boot it during startup.
+
+Add support for your board
+--------------------------
+Most of arm-autonomy layer is board independent but some functionalities
+might need to be customized for your board:
+
+### Add the kernel configuration for the host
+The layer is using KERNEL_FEATURES to add drivers required to be a Xen Dom0
+system.
+Depending on the kernel used by your BSP and how it is configured you might
+need to add the required drivers to your kernel configuration:
+- if KERNEL_FEATURES system is supported by your kernel, make sure that the
+file `recipes-kernel/linux/linux-arm-autonomy.inc` from the layer is included
+by your kernel recipe.
+- if it is not supported, you must add the proper drivers inside your kernel
+(modules are possible but they must be loaded before xenguest-manager is
+started). You can find the complete list of the kernel configuration elements
+required in `recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-host.cfg`.
+
+### Define the drive and partition to use for the LVM volume
+The xenguest-manager is creating disk hard drive using LVM on an empty
+partition. The default value is set to use /dev/sda2.
+You can change this for your board by setting XENGUEST_MANAGER_VOLUME_DEVICE.
+
+Check `recipes-extended/xenguest/xenguest-manager.bbappend` for examples.
+
+Please also read xenguest-manager.md.
+
+### Define the interface to add to xenguest network bridge
+xenguest-network bridge is creating a bridge on the host and adds network
+interfaces to it so that guest connected to it have access to external network.
+By default `eth0` is set as the list of interfaces to be added to the bridge.
+Depending on your board or use case you might want to use an other interface
+or use multiple interfaces.
+You can change this for your board by setting XENGUEST_NETWORK_BRIDGE_MEMBERS.
+
+Check `recipes-extended/xenguest/xenguest-network-bridge.bbappend` for
+exmaples.
+
+Please also read xenguest-network-bridge.md.
+
+### Define the network configuration of the xenguest network bridge
+xenguest network bridge is putting the host network interfaces in a bridge
+and is configuring it by default to use dhcp.
+If you need a different type of configuration you can set
+XENGUEST_NETWORK_BRIDGE_CONFIG in a xenguest-network-bridge.bbappend to use
+a different file.
+The recipe will look for the file in ${WORKDIR} so you will need to add it to
+SRC_URI in your bbappend.
+The recipe will also substitute `###BRIDGE_NAME###` with the bridge name
+configured in ${XENGUEST_NETWORK_BRIDGE_NAME}.
+
+You can find an example configuration file in
+`recipes-extended/xenguest/files/xenguest-network-bridge-dhcp.cfg.in`.
+
+Please also read xenguest-network-bridge.md.
+
+### Customize Dom0 and Xen boot arguments for you board
+xen-devicetree is writting inside the generated DTB Xen and Linux boot
+arguments as long as the address where Dom0 Linux kernel can be found.
+You might need to have different values for your board or depending on your
+use case.
+
+You can find examples to customize this in
+`recipes-extended/xen-devicetree/xen-devicetree.bbappend`.
+
+Please also read xen-devicetree.md.
+
@@ -0,0 +1,34 @@
+Customizing Arm Autonomy Host image layout for N1SDP
+====================================================
+
+When buiding with `DISTRO_FEATURES += "arm-autonomy-host"` the user can
+perform a couple of customizations in the generated wic image:
+
+1. Set the guest partition size (default: 4iG) via `GUEST_PART_SIZE` and
+   `GUEST_PART_SIZE_UNIT` (M or G) variables to be set in any conf file. The
+   value of these variables should be aligned with the sum of all
+   XENGUEST_IMAGE_DISK_SIZE set for the guests. By default, LVM2 metadata is
+   1 MiB per physical volume, hence it needs to be taken into account when
+   setting GUEST_PART_SIZE.
+
+2. Set the boot partition size (default: 100M) via `BOOT_PART_SIZE` and
+   `BOOT_PART_SIZE_UNIT` (M or G) variables in any conf file. The default
+   bootimg is ~44M so 100M leaves just over 50M of free space.
+
+3. The wic image partition layout and contents with a custom wks file via
+   `ARM_AUTONOMY_WKS_FILE` variable (default:
+   arm-autonomy-n1sdp-efidisk.wks.in which is affected by GUEST_PART_SIZE,
+   GUEST_PART_SIZE_UNIT, BOOT_PART_SIZE, BOOT_PART_SIZE_UNIT and
+   GRUB_CFG_FILE variables).
+
+4. Custom grub.cfg file via `GRUB_CFG_FILE` (default:
+   arm-autonomy-n1sdp-grub.cfg) variable to be set in any conf file. The full
+   path or relative to `ARM_AUTONOMY_WKS_FILE` should be set.
+
+The `arm-autonomy-n1sdp-efidisk.wks.in` and `arm-autonomy-n1sdp-grub.cfg` files
+are located at `meta-arm-autonomy/dynamic-layers/meta-arm-bsp/wic`.
+
+Other variables can also be custmized to set what files need to be included
+in the wic image boot partition. Please refer to
+`meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/n1sdp-extra-settings.inc`
+for more details.
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Tushar Khandelwal	f90f028646	Revert "arm-bsp/tc0: Enable verified u-boot" This reverts commit `29cee51f84`.	2021-04-22 23:27:47 +01:00
Tushar Khandelwal	1cba8aee6d	Revert "arm-bsp/u-boot: update SHA for tc0" This reverts commit `70a9c4991e`.	2021-04-22 23:24:10 +01:00
Tushar Khandelwal	5262d3d174	Revert "arm-bsp/images: Add tc0-kernel-image" This reverts commit `da57312334`.	2021-04-22 23:23:34 +01:00
Tushar Khandelwal	664d2a5f6a	Revert "arm-bsp: Enable SPM build option in yocto framework" This reverts commit `86f9419b9d`.	2021-04-22 23:23:13 +01:00
Tushar Khandelwal	ebee7ce68d	Revert "tc0/spm: boot SP according to boot order specified in manifest" This reverts commit `56514201ad`.	2021-04-22 23:22:02 +01:00
Tushar Khandelwal	cc645908ef	Merge branch 'upstream' into totalcompute	2021-04-22 22:36:21 +01:00
Ben Horgan	36314f2d87	arm-bsp/tc0: Add secure partitions secure-storage and crypo-sp These are added along with the existing optee secure partition. Change-Id: I50ce8adfa264d442cf52863f4f8572e623504ca3 Signed-off-by: Ben Horgan <ben.horgan@arm.com>	2021-04-22 22:25:47 +01:00
Ben Horgan	cddb08a7a2	arm-trusted-services: Add recipes for arm trusted services Signed-off-by: Ben Horgan <ben.horgan@arm.com> Change-Id: I14ac7649ae5899578167efca45d5c19d6248cb8f	2021-04-22 22:25:47 +01:00
Arunachalam Ganapathy	5d47d3f9db	arm-bsp/linux: Add linux-trusted-services driver, FF-A ABI changes for TC0 This adds below patches: - buf driver for trusted service test applications - Fix in FFA-ABI aligning with latest SPMC (hafnium) Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com> Change-Id: I6b36a73a910f6e10748d78b2ad74603dde42c8a9	2021-04-22 22:25:47 +01:00
Arunachalam Ganapathy	9d1724c3d4	arm-bsp/tc0: Update hafnium revision and add patches - Remove PSCI patches as those changes are upstreamed - Adds Theodul, GICR changes - Reverts FFA Set and verify allocator fix - Adds fix to fetch proper vCPU for UP SP Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com> Change-Id: I26a7b31558e5bc4ce2fea61b76a3a92615f3e641	2021-04-22 22:25:47 +01:00
Arunachalam Ganapathy	29f0e5982c	arm-bsp/tc0: Add patches in optee-os for FF-A ABI changes Adds below patches: - To use FFA_SECONDARY_EP_REGISTER - To align with latest FFA_ABIs in SPMC (hafnium) Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com> Change-Id: I4ae386e2dd846e747cbc426270fc0c489ccdfe1f	2021-04-22 22:25:47 +01:00
Arunachalam Ganapathy	853f3e0565	arm-bsp/tc0: Update TF-A revision, add trusted-services support - Update TF-A revision - Add patch for trusted services support - Add patch for GICR changes to support latest tc0 model Change-Id: I3ba1fd9c1f89721fc6349db4e0270c8b42e9fcf0 Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>	2021-04-22 22:25:47 +01:00
Arunachalam Ganapathy	806bbb07ed	arm-bsp/tc0: Update SCP firmware revision and add patches Add below patches: - add clock and dvfs support for all cores - fix in CFGM base address calculation Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com> Change-Id: I2e70736070dd59f6209012dc875f3ea08d811046	2021-04-22 22:25:47 +01:00
Arunachalam Ganapathy	9bb19dd0d6	arm-bsp/tc0: add Theodul DSU support - Adds patches required to support Theodul DSU in optee-os, hafnium - Updates SHA of TF-A, SCP with revision that has Theodul DSU support Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com> Change-Id: I62f0990b7de919839be9ab0e3234914624c8afde Signed-off-by: Jon Mason <jon.mason@arm.com>	2021-04-22 22:25:47 +01:00
Arunachalam Ganapathy	88c201ca9d	arm-bsp/linux: add asymmetric AArch32 EL0 support for TC0 This adds patches for asymmetric AArch32 EL0 configuration support for android11-5.4-lts kernel. And enables CONFIG_ASYMMETRIC_AARCH32 and disables CONFIG_KVM in TC0 defconfig. Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com> Change-Id: Iab94b5c48b60aca4a71267ba1be1cb1836002d10 Signed-off-by: Jon Mason <jon.mason@arm.com>	2021-04-22 22:25:47 +01:00
Usama Arif	56514201ad	tc0/spm: boot SP according to boot order specified in manifest This is currently in review at: https://review.trustedfirmware.org/c/hafnium/hafnium/+/4997/36 Signed-off-by: Usama Arif <usama.arif@arm.com>	2020-10-27 17:35:35 +00:00
Arunachalam Ganapathy	86f9419b9d	arm-bsp: Enable SPM build option in yocto framework This patch adds: spm, tf-a-tests recipes. This builds tf-a with SPM at S-EL2 and test secure partitions at S-EL1. Change-Id: Ia2f44f4000aa0786b945bc8fb66c9edb1a0094e8 Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com> Signed-off-by: Usama Arif <usama.arif@arm.com>	2020-10-27 17:35:26 +00:00
Usama Arif	da57312334	arm-bsp/images: Add tc0-kernel-image This depends on trusted-firmware-a which is the last component to be built. Calling bitbake tc0-kernel-image will create all the required images to boot poky. Change-Id: Ia8675b048db4a127d32394f536632ce88fe20826 Signed-off-by: Usama Arif <usama.arif@arm.com>	2020-10-26 18:26:37 +00:00
Usama Arif	70a9c4991e	arm-bsp/u-boot: update SHA for tc0 Change-Id: Ideb4866df92d05bdc07b53f47346ae4f381dfc6d Signed-off-by: Usama Arif <usama.arif@arm.com>	2020-10-26 18:26:35 +00:00
Usama Arif	29cee51f84	arm-bsp/tc0: Enable verified u-boot This involes creating the fitImage which contains both the kernel and ramdisk. The fitImage is also signed. Change-Id: Iaedffd54751585a7ef6b467d63f5f8fb6e744aa7 Signed-off-by: Usama Arif <usama.arif@arm.com>	2020-10-26 18:20:22 +00:00