CI: add ssh tests

Signed-off-by: Jon Mason <jon.mason@arm.com>

.gitignore

@@ -1 +0,0 @@
-__pycache__

.gitlab-ci.yml

@@ -1,56 +1,37 @@
-image: ghcr.io/siemens/kas/kas:latest-release
+image: ghcr.io/siemens/kas/kas
 
+  # First do a common bootstrap, and then build all the targets
 stages:
   - prep
+  - bootstrap
   - build
 
 # Common job fragment to get a worker ready
 .setup:
   stage: build
-  interruptible: true
   variables:
     KAS_WORK_DIR: $CI_PROJECT_DIR/work
     KAS_REPO_REF_DIR: $CI_BUILDS_DIR/persist/repos
     SSTATE_DIR: $CI_BUILDS_DIR/persist/sstate
     DL_DIR: $CI_BUILDS_DIR/persist/downloads
     BB_LOGCONFIG: $CI_PROJECT_DIR/ci/logging.yml
-    TOOLCHAIN_DIR: $CI_BUILDS_DIR/persist/toolchains
     IMAGE_DIR: $CI_PROJECT_DIR/work/build/tmp/deploy/images
-    TOOLCHAIN_LINK_DIR: $CI_PROJECT_DIR/work/build/toolchains
   before_script:
     - echo KAS_WORK_DIR = $KAS_WORK_DIR
     - echo SSTATE_DIR = $SSTATE_DIR
     - echo DL_DIR = $DL_DIR
     - rm -rf $KAS_WORK_DIR
-    - mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
+    - mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_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
-    - sudo apt update && sudo apt install --yes telnet python3-subunit
 
 # Generalised fragment to do a Kas build
 .build:
   extends: .setup
+  interruptible: true
   script:
-    - KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME")
+    - KASFILES=$(./ci/jobs-to-kas $CI_JOB_NAME)
     - kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
     - kas build $KASFILES
     - ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
-  artifacts:
-    name: "logs"
-    when: on_failure
-    paths:
-      - $CI_PROJECT_DIR/work/build/tmp/work*/**/temp/log.do_*.*
-
-# Workaround for Zephyr not currectly handling TESTIMAGE_AUTO
-.build_and_test:
-  extends: .setup
-  script:
-    - KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME")
-    - kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
-    - kas build $KASFILES
-    - kas build $KASFILES -c testimage
-    - ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
-
 
 #
 # Prep stage, update repositories once
@@ -59,207 +40,105 @@ update-repos:
   extends: .setup
   stage: prep
   script:
-    - flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos
+  - flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos
+
+
+#
+# Bootstrap stage, bootstrap and machine coverage
+#
+
+# 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:
+  - ./ci/check-machine-coverage
+  coverage: '/Coverage: \d+/'
+
 
 #
 # Build stage, the actual build jobs
 #
-# Available options for building are
-#  TOOLCHAINS: [gcc, clang, armgcc, external-gccarm]
-#  TCLIBC: [glibc, musl]
-#  VIRT: [none, xen]
-#  TESTING: testimage
 
-corstone500:
+a5ds:
   extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-  tags:
-    - x86_64
 
-corstone1000-fvp:
+foundation-armv8:
-  extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-  tags:
-    - x86_64
-
-corstone1000-mps3:
   extends: .build
 
 fvp-base:
   extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-  tags:
-    - x86_64
-
-fvp-base-arm32:
-  extends: .build
-  parallel:
-    matrix:
-      - TOOLCHAINS: [gcc, external-gccarm]
-        TESTING: testimage
-  tags:
-    - x86_64
-
-fvp-baser-aemv8r64:
-  extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-  tags:
-    - x86_64
-
-fvps:
-  extends: .build
 
 gem5-arm64:
   extends: .build
-  parallel:
-    matrix:
-      - VIRT: [none, xen]
-
-gem5-atp-arm64:
-  extends: .build
-
-generic-arm64:
-  extends: .build
 
 juno:
   extends: .build
-  parallel:
-    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        FIRMWARE: [none, edk2]
 
-microbit-v1:
+juno/musl:
-  extends: .build_and_test
-  parallel:
-    matrix:
-      - TESTING: testimage-zephyr
-
-musca-b1:
-  extends: .build
-
-musca-s1:
   extends: .build
 
 n1sdp:
   extends: .build
-  parallel:
-    matrix:
-      - TOOLCHAINS: [gcc, armgcc]
 
-qemu-cortex-a53:
+n1sdp/armgcc:
   extends: .build
 
-qemu-cortex-m3:
+qemuarm/testimage:
-  extends: .build_and_test
-  parallel:
-    matrix:
-      - TESTING: testimage-zephyr
-
-qemu-cortex-r5:
   extends: .build
 
-qemu-generic-arm64:
+qemuarmv5/testimage:
-  extends: .build
-  parallel:
-    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        TESTING: testimage
-
-qemuarm64-secureboot:
-  extends: .build
-  parallel:
-    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        TCLIBC: [glibc, musl]
-        TESTING: testimage
-
-qemuarm64:
-  extends: .build
-  parallel:
-    matrix:
-      - VIRT: xen
-
-qemuarm:
-  extends: .build
-  parallel:
-    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        TESTING: testimage
-      - VIRT: xen
-
-qemuarmv5:
-  extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-
-sgi575:
   extends: .build
 
 tc0:
   extends: .build
-  tags:
-    - x86_64
 
-tc1:
-  extends: .build
-  tags:
-    - x86_64
 
-toolchains:
+#
-  extends: .build
+# Utility tasks, not executed automatically
+#
 
-selftest:
+delete-dl-dir:
   extends: .setup
+  stage: prep
+  when: manual
   script:
-    - KASFILES=./ci/qemuarm64.yml:./ci/selftest.yml
+  - rm -rf $DL_DIR/*
-    - kas shell --update --force-checkout $KASFILES -c 'oe-selftest --num-processes 1 --run-tests runfvp'
 
-# Validate layers are Yocto Project Compatible
+delete-repo-dir:
-check-layers:
   extends: .setup
+  stage: prep
+  when: manual
   script:
-    - kas shell --update --force-checkout ci/base.yml:ci/meta-openembedded.yml --command \
+  - rm -rf $KAS_REPO_REF_DIR/*
-      "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, meta-gem5]
 
-pending-updates:
+# Delete all sstate
+delete-sstate:
   extends: .setup
-  artifacts:
+  stage: prep
-    paths:
+  when: manual
-      - update-report
   script:
-    - rm -fr update-report
+  - rm -rf $SSTATE_DIR/*
-    # This configuration has all of the layers we need enabled
-    - kas shell ci/gem5-arm64.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 meta-gem5)"
-  # Do this on x86 whilst the compilers are x86-only
-  tags:
-    - x86_64
 
-# What percentage of machines in the layer do we build
+# Wipe out old sstate
-machine-coverage:
+prune-sstate:
-  stage: build
-  interruptible: true
-  script:
-    - ./ci/check-machine-coverage
-  coverage: '/Coverage: \d+/'
-
-metrics:
   extends: .setup
-  artifacts:
+  stage: prep
-    reports:
+  when: manual
-      metrics: metrics.txt
   script:
-    - kas shell --update --force-checkout ci/base.yml --command \
+  - du -h -s $SSTATE_DIR
-      "$CI_PROJECT_DIR/ci/patchreview $CI_PROJECT_DIR/meta-* --verbose --metrics $CI_PROJECT_DIR/metrics.txt"
+  - find $SSTATE_DIR -type f -atime +30 -delete
+  - du -h -s $SSTATE_DIR
+
+# Report on disk usage
+usage:
+  extends: .setup
+  stage: prep
+  when: manual
+  script:
+  - du -h -s $DL_DIR $SSTATE_DIR $KAS_REPO_REF_DIR

README.md

@@ -1,46 +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-autonomy
+meta-arm-iota:
+	This layer provides support for Arm's IOTA Linux Distribution
 
-  This layer is the distribution for a reference stack for autonomous systems.
+meta-arm-toolchain:
+	This layer provides support for Arm's GNU-A toolset releases
 
-* meta-arm-bsp
+meta-arm-autonomy:
-
+    This layer provides a reference stack for autonomous systems.
-  This layer contains machines for Arm reference platforms, for example FVP Base, N1SDP, and Juno.
-
-* 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.
-
-* meta-atp
-
-  This layer contains recipes for the Adaptive Traffic Generation integration into meta-gem5.
-
-* meta-gem5
-
-  This layer contains recipes and machines for gem5, a system-level and processor simulator.
-
-
-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
 
 Contributing
 ------------
@@ -48,26 +25,14 @@ Currently, we only accept patches from the meta-arm mailing list.  For general
 information on how to submit a patch, please read
 https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
 
-E-mail meta-arm@lists.yoctoproject.org with patches created using this process. You can configure git-send-email to automatically use this address for the meta-arm repository with the following git command:
+E-mail meta-arm@lists.yoctoproject.org with patches created using this process
-
-$ git config --local --add sendemail.to meta-arm@lists.yoctoproject.org
-
-Commits and patches added should follow the OpenEmbedded patch guidelines:
-
-https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
-
-The component being changed in the shortlog should be prefixed with the layer name (without the meta- prefix), for example:
-
-  arm-bsp/trusted-firmware-a: decrease frobbing level
-
-  arm-toolchain/gcc: enable foobar v2
 
 Reporting bugs
 --------------
 E-mail meta-arm@lists.yoctoproject.org with the error encountered and the steps
-to reproduce the issue.
+to reproduce the issue
+
 
 Maintainer(s)
 -------------
 * Jon Mason <jon.mason@arm.com>
-* Ross Burton <ross.burton@arm.com>

ci/a5ds.yml

@@ -0,0 +1,6 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+machine: a5ds

ci/armgcc.yml

@@ -1,6 +1,6 @@
 header:
-  version: 11
+  version: 9
 
 local_conf_header:
-  cc: |
+  libc: |
-    GCCVERSION = "arm-11.2"
+    GCCVERSION = "arm-9.2"

ci/base.yml

@@ -1,11 +1,11 @@
 header:
-  version: 11
+  version: 9
 
 distro: poky
 
 defaults:
   repos:
-    refspec: kirkstone
+    refspec: dunfell
 
 repos:
   meta-arm:
@@ -20,31 +20,29 @@ repos:
       meta:
       meta-poky:
 
+  meta-openembedded:
+    url: https://git.openembedded.org/meta-openembedded
+    layers:
+      meta-oe:
+
 env:
   BB_LOGCONFIG: ""
-  TOOLCHAIN_DIR: ""
 
 local_conf_header:
   base: |
-    BB_SERVER_TIMEOUT = "60"
+    CONF_VERSION = "1"
-    CONF_VERSION = "2"
+    PACKAGE_CLASSES = "package_ipk"
+    LICENSE_FLAGS_WHITELIST += "armcompiler"
+    PACKAGECONFIG_remove_pn-qemu-system-native = "gtk+ sdl"
+    EXTRA_IMAGE_FEATURES_append = " debug-tweaks"
     BB_NUMBER_THREADS = "16"
     PARALLEL_MAKE = "-j16"
-    LICENSE_FLAGS_ACCEPTED += "armcompiler Arm-FVP-EULA"
-  setup: |
-    PACKAGE_CLASSES = "package_ipk"
-    PACKAGECONFIG:remove:pn-qemu-system-native = "gtk+ sdl"
-    EXTRA_IMAGE_FEATURES:append = " debug-tweaks"
-    PACKAGECONFIG:append:pn-perf = " coresight"
     INHERIT += "rm_work"
-    DISTRO_FEATURES:remove = "ptest"
+  ptest: |
-  kvm: |
+    DISTRO_FEATURES_remove = "ptest"
-    QEMU_USE_KVM = ""
+
-  perf: |
-    CORE_IMAGE_EXTRA_INSTALL += "perf"
-  sshkeys: |
-    CORE_IMAGE_EXTRA_INSTALL += "ssh-pregen-hostkeys"
 machine: unset
 
 target:
   - core-image-base
+#  - perf

ci/bootstrap.yml

@@ -0,0 +1,9 @@
+header:
+  version: 9
+
+target:
+  - binutils-cross-aarch64
+  - gcc-cross-aarch64
+  - python3-native
+  - opkg-native
+  - rpm-native

ci/check-machine-coverage

@@ -2,7 +2,6 @@
 
 from pathlib import Path
 import sys
-from listmachines import list_machines
 
 metaarm = Path.cwd()
 
@@ -10,16 +9,15 @@ 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
+# All ci files
-kas = metaarm.glob("ci/*.yml")
+ci = metaarm.glob("ci/*.yml")
-kas = set(p.stem for p in kas)
+ci = set(p.stem for p in ci)
 
-missing = machines - kas
+missing = machines - ci
 print(f"The following machines are missing: {', '.join(sorted(missing))}.")
 
 covered = len(machines) - len(missing)

ci/check-warnings

@@ -7,8 +7,7 @@ set -e -u
 
 LOGFILE=$1
 
-LINES=$(grep --invert-match "attempting MIRRORS if available" $LOGFILE | wc -l)
+if test -s $LOGFILE; then
-if test "$LINES" -ne 0; then
     echo ==============================
     echo The build had warnings/errors:
     echo ==============================

ci/clang.yml

@@ -1,10 +1,9 @@
 header:
-  version: 11
+  version: 9
 
 repos:
   meta-clang:
     url: https://github.com/kraj/meta-clang
-    refspec: master
 
 local_conf_header:
   clang: |

ci/corstone1000-common.yml

@@ -1,13 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-    - ci/meta-openembedded.yml
-local_conf_header:
-    perf: |
-
-distro: poky-tiny
-
-target:
-  - perf
-  - corstone1000-image

ci/corstone1000-fvp.yml

@@ -1,12 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/corstone1000-common.yml
-
-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"
-
-machine: corstone1000-fvp

ci/corstone1000-mps3.yml

@@ -1,6 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/corstone1000-common.yml
-
-machine: corstone1000-mps3

ci/corstone500.yml

@@ -1,18 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-
-local_conf_header:
-  testimagefvp: |
-    INHERIT += "fvpboot"
-    IMAGE_FEATURES:remove = " ssh-server-dropbear"
-  perf: |
-
-machine: corstone500
-
-distro: poky-tiny
-
-target:
-  - core-image-minimal
-  - perf

ci/edk2.yml

@@ -1,9 +0,0 @@
-header:
-  version: 11
-
-local_conf_header:
-  bootfirmware: |
-    PREFERRED_PROVIDER_virtual/bootloader = "edk2-firmware"
-    MACHINE_FEATURES += "efi"
-    TFA_UBOOT = "0"
-    TFA_UEFI = "1"

ci/external-gccarm.yml

@@ -1,8 +0,0 @@
-header:
-  version: 11
-
-local_conf_header:
-  cc: |
-    SKIP_RECIPE[gcc-cross-arm] = "Using external toolchain"
-    TCMODE = "external-arm"
-    EXTERNAL_TOOLCHAIN = "${TOPDIR}/toolchains/${TARGET_ARCH}"

ci/foundation-armv8.yml

@@ -0,0 +1,6 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+machine: foundation-armv8

ci/fvp-base-arm32.yml

@@ -1,16 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-
-machine: fvp-base-arm32
-
-local_conf_header:
-  testimagefvp: |
-    INHERIT = "fvpboot"
-    # This fails but we can't add to the ignorelist from meta-arm yet
-    # https://bugzilla.yoctoproject.org/show_bug.cgi?id=14604
-    TEST_SUITES:remove = "parselogs"
-    # Tell testimage to connect to localhost:8122, and forward that to SSH in the FVP.
-    TEST_TARGET_IP = "127.0.0.1:8122"
-    FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] = "8122=22"

ci/fvp-base.yml

@@ -1,16 +1,7 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
+    - base.yml
 
 machine: fvp-base
 
-local_conf_header:
-  testimagefvp: |
-    INHERIT += "fvpboot"
-    # This fails but we can't add to the ignorelist from meta-arm yet
-    # https://bugzilla.yoctoproject.org/show_bug.cgi?id=14604
-    TEST_SUITES:remove = "parselogs"
-    # Tell testimage to connect to localhost:8022, and forward that to SSH in the FVP.
-    TEST_TARGET_IP = "localhost:8022"
-    FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] ?= "8022=22"

ci/fvp-baser-aemv8r64.yml

@@ -1,7 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-
-machine: fvp-baser-aemv8r64
-

ci/fvps.yml

@@ -1,20 +0,0 @@
-# Simple target to build the FVPs that are publically available
-
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-
-machine: qemuarm64
-
-local_conf_header:
-  sdk: |
-    SDKMACHINE = "x86_64"
-
-target:
-  - nativesdk-fvp-base-a-aem
-  - nativesdk-fvp-n1-edge
-  - nativesdk-fvp-sgi575
-  - nativesdk-fvp-corstone500
-  - nativesdk-fvp-corstone1000
-  - nativesdk-fvp-tc0

ci/gem5-arm64.yml

@@ -1,13 +1,7 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
+    - base.yml
-    - ci/meta-openembedded.yml
-
-repos:
-  meta-arm:
-    layers:
-      meta-gem5:
 
 machine: gem5-arm64
 

ci/gem5-atp-arm64.yml

@@ -1,15 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/gem5-arm64.yml
-
-repos:
-  meta-arm:
-    layers:
-      meta-atp:
-
-machine: gem5-atp-arm64
-
-target:
-  - atp-native
-  - core-image-minimal

ci/generic-arm64.yml

@@ -1,6 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-
-machine: generic-arm64

ci/get-binary-toolchains

@@ -1,46 +0,0 @@
-#!/bin/bash
-set -u
-
-HOST_ARCH=$(uname -m)
-VER="11.2-2022.02"
-
-DOWNLOAD_DIR=$1
-TOOLCHAIN_DIR=$2
-TOOLCHAIN_LINK_DIR=$3
-
-# These should be already created by .gitlab-ci.yml, but do here if run outside of that env
-mkdir -p $DOWNLOAD_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
-
-if [ $HOST_ARCH = "aarch64" ]; then
-	#AArch64 Linux hosted cross compilers
-
-	#AArch32 target with hard float (arm-none-linux-gnueabihf)
-	wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz
-elif [ $HOST_ARCH = "x86_64" ]; then
-	#x86_64 Linux hosted cross compilers
-
-	#AArch32 target with hard float (arm-linux-none-gnueabihf)
-	wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz
-
-	#AArch64 GNU/Linux target (aarch64-none-linux-gnu)
-	wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-aarch64-none-linux-gnu.tar.xz
-
-	#AArch64 GNU/Linux target (aarch64_be-none-linux-gnu)
-	wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-aarch64_be-none-linux-gnu.tar.xz
-else
-	echo "ERROR - Unknown build arch of $HOST_ARCH"
-	exit 1
-fi
-
-for i in arm aarch64 aarch64_be; do
-	if [ ! -d $TOOLCHAIN_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu*/ ]; then
-		if [ ! -f $DOWNLOAD_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz ]; then
-			continue
-		fi
-
-		tar -C $TOOLCHAIN_DIR -axvf $DOWNLOAD_DIR/gcc-arm-$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/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu* $TOOLCHAIN_LINK_DIR/$i
-done

ci/jobs-to-kas

@@ -1,27 +1,19 @@
 #! /bin/bash
 
-# This script is expecting an input of machine name, optionally followed by a
+# Read a GitLab CI job name on $1 and transform it to a
-# colon and a list of one or more parameters separated by commas between
+# list of Kas yaml files
-# brackets.  For example, the following are acceptable:
-# corstone500
-# fvp-base: [testimage]
-# qemuarm64-secureboot: [clang, glibc, testimage]
-#
-# Turn this list into a series of yml files separated by colons to pass to kas
 
 set -e -u
 
-FILES="ci/$(echo $1 | cut -d ':' -f 1).yml"
+# Read Job namne from $1 and split on /
+IFS=/ read -r -a PARTS<<<$1
 
-for i in $(echo $1 | cut -s -d ':' -f 2 | sed 's/[][,]//g'); do
+# Prefix each part with ci/
-	# Given that there are no yml files for gcc or glibc, as those are the
+PARTS=("${PARTS[@]/#/ci/}")
-	# 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' || $i == 'gcc' || $i == 'glibc' ]]; then
-		continue
-	fi
-	FILES+=":ci/$i.yml"
-done
 
-echo $FILES
+# Suffix each part with .yml
+PARTS=("${PARTS[@]/%/.yml}")
+
+# Print colon-separated
+IFS=":"
+echo "${PARTS[*]}"

ci/juno.yml

@@ -1,6 +1,6 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
+    - base.yml
 
 machine: juno

ci/listmachines.py

@@ -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)

ci/meta-openembedded.yml

@@ -1,11 +0,0 @@
-header:
-  version: 11
-
-repos:
-  meta-openembedded:
-    url: https://git.openembedded.org/meta-openembedded
-    layers:
-      meta-filesystems:
-      meta-networking:
-      meta-oe:
-      meta-python:

ci/meta-virtualization.yml

@@ -1,9 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/meta-openembedded.yml
-
-repos:
-  meta-virtualization:
-    url: git://git.yoctoproject.org/meta-virtualization
-    refspec: master

ci/meta-zephyr.yml

@@ -1,13 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/meta-openembedded.yml
-
-repos:
-  meta-zephyr:
-    url: https://git.yoctoproject.org/git/meta-zephyr
-    layers:
-      meta-zephyr-core:
-
-target:
-  - zephyr-kernel-test-all

ci/microbit-v1.yml

@@ -1,11 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-    - ci/meta-zephyr.yml
-
-local_conf_header:
-  failing_tests: |
-    ZEPHYRTESTS:remove = "common"
-
-machine: microbit-v1

ci/musca-b1.yml

@@ -1,15 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-    - ci/meta-zephyr.yml
-
-local_conf_header:
-  nonbuilding_tests: |
-    ZEPHYRTESTS:remove = "common sleep poll device queue"
-
-machine: musca-b1
-
-target:
-  - trusted-firmware-m
-  - zephyr-kernel-test-all

ci/musca-s1.yml

@@ -1,15 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-    - ci/meta-zephyr.yml
-
-local_conf_header:
-  nonbuilding_tests: |
-    ZEPHYRTESTS:remove = "common sleep poll device queue"
-
-machine: musca-s1
-
-target:
-  - trusted-firmware-m
-  - zephyr-kernel-test-all

ci/musl.yml

@@ -1,5 +1,5 @@
 header:
-  version: 11
+  version: 9
 
 local_conf_header:
   libc: |

ci/n1sdp.yml

@@ -1,6 +1,6 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
+    - base.yml
 
 machine: n1sdp

ci/patchreview

@@ -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)

ci/qemu-cortex-a53.yml

@@ -1,9 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-    - ci/meta-zephyr.yml
-
-# FIXME - testimage fails all tests currently, but all the tests build
-
-machine: qemu-cortex-a53

ci/qemu-cortex-m3.yml

@@ -1,18 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-    - ci/meta-zephyr.yml
-
-repos:
-  meta-zephyr:
-    layers:
-      meta-zephyr-bsp:
-
-local_conf_header:
-  tclibc: |
-    TCLIBC = "newlib"
-  nonbuilding_tests: |
-    ZEPHYRTESTS:remove = "context pending sleep"
-
-machine: qemu-cortex-m3

ci/qemu-cortex-r5.yml

@@ -1,11 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-    - ci/meta-zephyr.yml
-
-local_conf_header:
-  nonbuilding_tests: |
-    ZEPHYRTESTS:remove = "common poll sleep queue device"
-
-machine: qemu-cortex-r5

ci/qemu-generic-arm64.yml

@@ -1,14 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/generic-arm64.yml
-
-local_conf_header:
-  failing_tests: |
-    DEFAULT_TEST_SUITES:remove = "parselogs"
-
-machine: qemu-generic-arm64
-
-target:
-  - core-image-base
-  - sbsa-acs

ci/qemuarm.yml

@@ -1,6 +1,6 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
+    - base.yml
 
 machine: qemuarm

ci/qemuarm64-secureboot.yml

@@ -1,18 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-
-machine: qemuarm64-secureboot
-
-local_conf_header:
-  failing_tests: |
-    # software IO TLB: Cannot allocate buffer
-    DEFAULT_TEST_SUITES:remove = "parselogs"
-
-target:
-  - core-image-base
-  - optee-examples
-  - optee-test
-  - optee-spdevkit
-  - optee-os-tadevkit

ci/qemuarm64.yml

@@ -1,6 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-
-machine: qemuarm64

ci/qemuarmv5.yml

@@ -1,6 +1,11 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
+    - base.yml
 
 machine: qemuarmv5
+
+local_conf_header:
+  bugs: |
+    # Remove parselogs until errors can be resolved
+    TEST_SUITES_remove = "parselogs"

ci/selftest.yml

@@ -1,7 +0,0 @@
-header:
-  version: 11
-
-local_conf_header:
-  setup: |
-    BB_LOGCONFIG = ""
-    SANITY_TESTED_DISTROS = ""

ci/sgi575.yml

@@ -1,6 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-
-machine: sgi575

ci/tc0.yml

@@ -1,9 +1,6 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
+    - base.yml
 
 machine: tc0
-
-target:
-  - tc-artifacts-image

ci/tc1.yml

@@ -1,9 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/base.yml
-
-machine: tc1
-
-target:
-  - tc-artifacts-image

ci/testimage-zephyr.yml

@@ -1,8 +0,0 @@
-header:
-  version: 11
-
-local_conf_header:
-  testimage: |
-    IMAGE_CLASSES += "testimage"
-    TEST_TARGET = "QemuTargetZephyr"
-    TEST_SUITES = "zephyr"

ci/testimage.yml

@@ -1,5 +1,5 @@
 header:
-  version: 11
+  version: 9
 
 local_conf_header:
   testimage: |
@@ -9,5 +9,9 @@ local_conf_header:
     TEST_RUNQEMUPARAMS = "slirp"
     TEST_SERVER_IP = "127.0.0.1"
     QEMU_USE_SLIRP = "1"
-  sshd: |
+  packages: |
-    IMAGE_FEATURES:append = " ssh-server-dropbear"
+    IMAGE_FEATURES_append = " ssh-server-dropbear"
+
+# Multiple targets are available, put it down to just one
+target:
+  - core-image-base

ci/toolchains.yml

@@ -1,21 +0,0 @@
-header:
-  version: 11
-  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"
-
-# No target armcompiler as currently there is no arm64 build
-target:
-  - nativesdk-armcompiler
-  - gcc-aarch64-none-elf
-  - nativesdk-gcc-aarch64-none-elf
-  - gcc-arm-none-eabi
-  - nativesdk-gcc-arm-none-eabi
-  - nativesdk-androidclang

ci/update-repos

@@ -36,8 +36,6 @@ if __name__ == "__main__":
     for repo in repositories:
         repodir = base_repodir / repo_shortname(repo)
         if repodir.exists():
-            print("Updating %s..." % repo)
             subprocess.run(["git", "-C", repodir, "fetch"], check=True)
         else:
-            print("Cloning %s..." % repo)
             subprocess.run(["git", "clone", "--bare", repo, repodir], check=True)

ci/xen.yml

@@ -1,11 +0,0 @@
-header:
-  version: 11
-  includes:
-    - ci/meta-virtualization.yml
-
-local_conf_header:
-  meta-virt: |
-    DISTRO_FEATURES:append = " virtualization xen"
-
-target:
-  - xen-image-minimal

documentation/runfvp.md

@@ -1,120 +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, `fvp-base-r-aem.bb` is a good example of those.
-
-If `FVP_PROVIDER` is not set then it is assumed that `FVP_EXE` is installed on the host already.
-
-### `FVP_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] = "${DEPLOY_DIR_IMAGE}/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=${DEPLOY_DIR_IMAGE}/Image@0x80080000 \
-            cluster0.cpu0=${DEPLOY_DIR_IMAGE}/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] = "${DEPLOY_DIR_IMAGE}/linux-system.axf"
-```
-
-Note that symbols are not allowed in flag names, so if you need to use a wildcard in the instance then you'll need to use `FVP_EXTRA_ARGS` and `--application` directly.
-
-### `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_CONSOLE`
-
-This specifies what serial port is used when `--console` is passed to runfvp. Note that this has to be the FVP identifier but without the board prefix, for example:
-```
-FVP_CONSOLE = "terminal_0"
-```
-
-### `FVP_EXTRA_ARGS`
-
-Arbitrary extra arguments that are passed directly to the FVP.  For example:
-
-```
-FVP_EXTRA_ARGS = "--simlimit 60"
-```
-
-
-[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

kas/corstone1000-base.yml

@@ -1,48 +0,0 @@
-header:
-  version: 11
-
-distro: poky-tiny
-
-defaults:
-  repos:
-    refspec: master
-
-repos:
-  meta-arm:
-    layers:
-      meta-arm:
-      meta-arm-bsp:
-      meta-arm-toolchain:
-
-  poky:
-    url: https://git.yoctoproject.org/git/poky
-    refspec: master
-    layers:
-      meta:
-      meta-poky:
-      meta-yocto-bsp:
-
-  meta-openembedded:
-    url: https://git.openembedded.org/meta-openembedded
-    refspec: master
-    layers:
-      meta-oe:
-      meta-python:
-
-  meta-arm-image:
-     url: https://git.gitlab.arm.com/arm-reference-solutions/meta-arm-image.git
-     refspec: 9f611833ef58394b707836d69356c4e27d0265fc 
-
-local_conf_header:
-  base: |
-    CONF_VERSION = "2"
-    PACKAGE_CLASSES = "package_ipk"
-    LICENSE_FLAGS_ACCEPTED += "armcompiler"
-    BB_NUMBER_THREADS ?= "16"
-    PARALLEL_MAKE ?= "-j16"
-    PACKAGECONFIG:append:pn-perf = " coresight"
-
-machine: unset
-
-target:
-  - corstone1000-image

kas/corstone1000-fvp.yml

@@ -1,23 +0,0 @@
-header:
-  version: 11
-  includes:
-    - kas/corstone1000-base.yml
-
-repos:
-  run-scripts:
-     url: https://git.gitlab.arm.com/arm-reference-solutions/model-scripts.git
-     refspec: b40b4227fe6b6fc8e4b688db8928f4be76e94eb7
-     layers:
-      .: 'excluded'
-
-machine: corstone1000-fvp
-
-local_conf_header:
-    fvp-config: |
-        # Remove Dropbear SSH as it will not fit into the corstone1000 image.
-        IMAGE_FEATURES:remove = " ssh-server-dropbear"
-        INHERIT = " ${@bb.utils.contains('BUILD_ARCH', 'x86_64', 'fvpboot', '', d)}"
-        LICENSE_FLAGS_ACCEPTED:append = " Arm-FVP-EULA"
-
-target:
-  - corstone1000-image

kas/corstone1000-mps3.yml

@@ -1,6 +0,0 @@
-header:
-  version: 11
-  includes:
-    - kas/corstone1000-base.yml
-
-machine: corstone1000-mps3

kas/corstone500.yml

@@ -1,47 +0,0 @@
-header:
-  version: 11
-
-distro: poky-tiny
-
-defaults:
-  repos:
-    refspec: master
-
-repos:
-  meta-arm:
-    layers:
-      meta-arm:
-      meta-arm-bsp:
-      meta-arm-toolchain:
-
-  poky:
-    url: https://git.yoctoproject.org/git/poky
-    refspec: master
-    layers:
-      meta:
-      meta-poky:
-      meta-yocto-bsp:
-
-  meta-openembedded:
-    url: https://git.openembedded.org/meta-openembedded
-    refspec: master
-    layers:
-      meta-oe:
-      meta-python:
-
-local_conf_header:
-  base: |
-    CONF_VERSION = "2"
-    PACKAGE_CLASSES = "package_ipk"
-    LICENSE_FLAGS_ACCEPTED += "armcompiler"
-    BB_NUMBER_THREADS ?= "16"
-    PARALLEL_MAKE ?= "-j16"
-    PACKAGECONFIG:append:pn-perf = " coresight"
-  fvp-config: |
-    IMAGE_CLASSES:append = " ${@bb.utils.contains('BUILD_ARCH', 'x86_64', 'fvpboot', '', d)}"
-    LICENSE_FLAGS_ACCEPTED:append = " Arm-FVP-EULA"
-
-machine: corstone500
-
-target:
-  - core-image-minimal

kas/fvp-baser-aemv8r64-bsp.yml

@@ -1,41 +0,0 @@
-header:
-  version: 9
-
-distro: poky
-machine: fvp-baser-aemv8r64
-
-defaults:
-  repos:
-    refspec: master
-
-repos:
-  meta-arm:
-    url: https://git.yoctoproject.org/git/meta-arm
-    path: layers/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:
-
-env:
-  FVP_BASE_R_ARM_EULA_ACCEPT: "False"
-
-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"
-    LICENSE_FLAGS_ACCEPTED:append = " ${@oe.utils.vartrue('FVP_BASE_R_ARM_EULA_ACCEPT', 'Arm-FVP-EULA', '', d)}"
-    IMAGE_CLASSES:append = " testimage"
-
-target:
-  - core-image-minimal

kas/fvp-baser-aemv8r64-rt-bsp.yml

@@ -1,8 +0,0 @@
-header:
-  version: 9
-  includes:
-    - kas/fvp-baser-aemv8r64-bsp.yml
-
-local_conf_header:
-  base-rt: |
-    PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"

meta-arm-autonomy/README.md

@@ -1,16 +1,84 @@
 meta-arm-autonomy Yocto Layer
 =============================
 
-The meta-arm-autonomy layer is being deprecated from master, with bug fixes
+Introduction
-only being applied to the following branches. Additionally, all support and
+------------
-maintenance of meta-arm-autonomy will stop as per the schedule below.
+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.
 
-    honister: End-of-life scheduled to June 2022
+To start using this layer, please check the
-    hardknot: End-of-life scheduled to December 2021
+[Quick Start Guide](documentation/arm-autonomy-quickstart.md).
-    gatesgarth: End-of-life scheduled to October 2021
-    dunfell: End-of-life scheduled to October 2021
-    master: End-of-life scheduled to October 2021 and code removed
 
+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
 ------------
@@ -20,4 +88,5 @@ would like to contribute, please contact the maintainers
 
 Maintainer(s)
 -------------
-* Diego Sueiro <diego.sueiro@arm.com>
+* Bertrand Marquis <bertrand.marquis@arm.com>
+* Filipe Rinaldi <filipe.rinaldi@arm.com>

meta-arm-autonomy/classes/arm-autonomy-features.bbclass

@@ -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)}
+

meta-arm-autonomy/classes/image_types_xenguest.bbclass

@@ -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')
+}
+

meta-arm-autonomy/classes/kernel-xenguest.bbclass

@@ -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
+}

meta-arm-autonomy/classes/xenguest-image-extra.bbclass

@@ -0,0 +1,102 @@
+# 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 ??= ""
+
+# 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_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"
+

meta-arm-autonomy/classes/xenguest-image.bbclass

@@ -0,0 +1,195 @@
+# 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'}"
+
+#
+# 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 Gigabit
+# - fs is the 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_BRIDGE can be set to 1 to have a network interface
+# on the guest connected to host bridged network. This will provide the guest
+# with a network interface connected directly to the external network
+XENGUEST_IMAGE_NETWORK_BRIDGE ??= "1"
+
+# 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}"
+    if [ -z "$disksize" ]; then
+        disksize="0"
+    fi
+    if [ $disksize -gt 0 ]; then
+        # 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
+                partnum="$(expr $partnum + 1)"
+            done
+        fi
+    fi
+
+    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 [ "${XENGUEST_IMAGE_NETWORK_BRIDGE}" = "1" ]; then
+        call_xenguest_mkimage update --set-param=NETWORK_BRIDGE=1
+    else
+        call_xenguest_mkimage update --set-param=NETWORK_BRIDGE=0
+    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 ""

meta-arm-autonomy/conf/distro/include/arm-autonomy-guest.inc

@@ -0,0 +1,11 @@
+# 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"

meta-arm-autonomy/conf/distro/include/arm-autonomy-host.inc

@@ -0,0 +1,10 @@
+# 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 ?= ""

meta-arm-autonomy/conf/layer.conf

@@ -0,0 +1,35 @@
+# 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 = "6"
+LAYERDEPENDS_meta-arm-autonomy = " \
+   core \
+   yocto \
+   openembedded-layer \
+   networking-layer \
+   virtualization-layer \
+"
+LAYERSERIES_COMPAT_meta-arm-autonomy = "dunfell"
+
+# 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"
+
+# Directory of our distro config files
+ARM_AUTONOMY_DISTRO_CFGDIR = "${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-arm-autonomy/conf/machine/arm64-autonomy-guest.conf

@@ -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.4%"
+
+DISTRO_FEATURES += "arm-autonomy-guest"
+

meta-arm-autonomy/documentation/arm-autonomy-quickstart.md

@@ -0,0 +1,229 @@
+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 zeus using `git checkout zeus`).
+
+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-virtualization $LAYERDIR_BASE/meta-arm/meta-arm-autonomy \
+   $LAYERDIR_BASE/meta-arm/meta-arm $LAYERDIR_BASE/meta-arm/meta-arm-bsp
+  ```
+
+  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-autonomy \
+    /home/user/arm-autonomy/meta-arm/meta-arm \
+    /home/user/arm-autonomy/meta-arm/meta-arm-bsp \
+    "
+  ```
+
+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.
+
+For arm-autonomy host on FVP-Base u-boot has been modified such that
+`booti 0x84000000 - 0x83000000` is the default boot command. If FVP-Base is your
+MACHINE target there should be no need to interfere with u-boot.
+
+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.
+
+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.
+

meta-arm-autonomy/documentation/xen-devicetree.md

@@ -0,0 +1,104 @@
+Xen device tree
+===============
+
+Introduction
+------------
+
+xen-devicetree recipe can be used to modify an existing Device Tree Blob,
+produced by Linux kernel or another recipe, to include in it entries required
+to start Xen and a Dom0 Linux on top of it.
+
+The recipe will do the following processing:
+- generate a xen.dtsi file with entries required for xen based on parameters
+- turn DTBs in ${XEN_DEVICETREE_DTBS} back to dts
+- include in xen.dtsi and all other dtsi from
+  ${XEN_DEVICETREE_DTSI_MERGE} (check Bitbake parameters for more information
+  on this).
+- use dtc to create a new DTB file
+
+The recipe will generate new files in deploy/images and name them with the
+extension "-xen.dtb".
+For example **machine.dtb** will generate **machine-xen.dtb**.
+
+Entries added to the DTBs
+-------------------------
+
+When a DTB is processed by the recipe, the following block is added:
+```
+    chosen {
+        xen,dom0-bootargs = "VAL";
+        xen,xen-bootargs = "VAL";
+
+        modules {
+            #size-cells = <0x00000001>;
+            #address-cells = <0x00000001>;
+
+            module@0 {
+                reg = <VAL VAL>;
+                compatible = "multiboot,module";
+            };
+        };
+    };
+```
+Each occurence of **VAL** is replaced by the content of the variables listed in
+this documentation.
+
+Bitbake parameters
+------------------
+
+Several parameters are available to configure the xen-devicetree during Yocto
+project compilation (those can be set in your project local.conf, for exmple).
+
+The following parameters are available:
+
+- XEN_DEVICETREE_DEPEND: This variable can be used to indicate which recipe
+  task is generating the DTBs that xen-devicetree will modify. This makes sure
+  the xen devicetrees are properly regenerated if the source DTBs are changed.
+  This variable is set by default to "virtual/kernel:do_deploy" to use DTBs
+  generated during the compilation of the Linux kernel. This must be changed
+  if the machine your are using is not using a DTB listed in KERNEL_DEVICETREE.
+
+- XEN_DEVICETREE_DTBS: This should be set to the list of DTBs you want to be
+  modified by xen-devicetree. Those must be files that xen-devicetree can find
+  in the ${DEPLOY_DIR_IMAGE} directory using only the basename of the entries.
+  For example "mydir/board.dtb" will make the recipe look for
+  ${DEPLOY_DIR_IMAGE}/board.dtb.
+  This variable is set by default to "${KERNEL_DEVICETREE}" to process the DTBs
+  generated by the Linux kernel.
+
+- XEN_DEVICETREE_DOM0_MEM: Memory size to allocate to Dom0.
+  This variable is only used if XEN_DEVICETREE_XEN_BOOTARGS has a value
+  containing "dom0_mem=${XEN_DEVICETREE_DOM0_MEM}" as the memory assigned to
+  dom0 is defined using Xen boot arguments.
+  This variable is set by default to "1024M".
+
+- XEN_DEVICETREE_DOM0_BOOTARGS: Boot arguments to pass to Dom0 Linux when
+  booting it.
+  This variable is set by default to "console=hvc0 earlycon=xen".
+
+- XEN_DEVICETREE_XEN_BOOTARGS: this variable should be set with the boot
+  arguments to be passed to Xen on boot.
+  This variable is set by default to
+  "noreboot dom0_mem=${XEN_DEVICETREE_DOM0_MEM}".
+
+- XEN_DEVICETREE_DOM0_ADDR: This is the address from which the Linux kernel to
+  be used for Dom0 will be copied. When using u-boot, this is the address at
+  which you will load the kernel Image before starting Xen.
+  This variable is set by default to "0x80080000".
+
+- XEN_DEVICETREE_DOM0_SIZE: This is the size of the kernel loaded at
+  ${XEN_DEVICETREE_DOM0_ADDR}. Xen will copy this amount of data inside the
+  guest before starting it so the size must be at least equal to the kernel
+  size but can be bigger. You must be careful not to have a value too big as it
+  could slow down boot or copy other parts with it (like the DTB).
+  You might need to increase this if you use a kernel with a bundled initramfs.
+  This variable is set by default to "0x01000000".
+
+- XEN_DEVICETREE_DTSI_MERGE: This variable contains the list of dtsi files that
+  must be included inside the generated DTB file. By default the only one
+  include is the "xen.dtsi" generated by the recipe.
+  If your board or project needs to include more fixes or entries in the DTB,
+  this variable can be appended from a bbappend file to include other dtsi. The
+  files must be inside the recipe workspace during Yocto compilation.
+  You can check xen-devicetree.bbappend for an example.
+

meta-arm-autonomy/documentation/xenguest-manager.md

@@ -0,0 +1,67 @@
+Xenguest Manager
+================
+
+Introduction
+------------
+
+xenguest-manager is a tool to manage Xenguest images generated by
+[xenguest-mkimage](xenguest-mkimage.md).
+
+On a Xen Dom0 system it will:
+- create a xen guest from a xenguest image: extract its components, create a
+  disk for the guest using LVM volumes.
+- start/stop a xen guest (during init or using xenguest-manager directly).
+- check guest status
+
+xenguest-manager is composed of 2 shell scripts:
+- xenguest-manager which can be used from command line to start/stop/check
+guests and create or remove guest using xenguest images.
+- xenguest-init which is called during init to automatically create and start
+some guests as part of the host init process.
+
+Usage
+-----
+
+xenguest-manager must be called like this:
+`xenguest-manager OPERATION [OPTIONS]`
+The following operations are available:
+- create XENGUEST_IMAGE [GUESTNAME]: create a guest from a xenguest image file
+  as guest GUESTNAME. If GUESTNAME is not given the image file name is used
+  without the xenguest extension.
+- remove GUESTNAME: remove the guest GUESTNAME.
+- start GUESTNAME: start the guest GUESTNAME.
+- stop GUESTNAME: stop the guest GUESTNAME (this is using `xl stop` which is
+  sending a stop signal to the running guest).
+- kill GUESTNAME: force stopping the guest GUESTNAME.
+- list: list the available guests.
+- status [GUESTNAME]: print the current status of GUESTNAME. If GUESTNAME is
+  not given, print the status of all guests.
+
+For a detailed help on available options please use:
+`xenguest-manager --help`
+
+Bitbake parameters
+------------------
+
+Several parameters are available to configure the xenguest manager during Yocto
+project compilation (those can be set in your project local.conf, for example).
+
+The following parameters are available:
+
+- XENGUEST_MANAGER_VOLUME_DEVICE: This is the device path used by the 
+  xenguest-manager on the device to create LVM disks when guests have a disk
+  configuration.
+  This is set by default to "/dev/sda2".
+
+- XENGUEST_MANAGER_VOLUME_NAME: This is the LVM volume name that the 
+  xenguest-manager will create and use to create guest LVM disks.
+  This is set by default to "vg-xen".
+
+- XENGUEST_MANAGER_GUEST_DIR: This is the directory on Dom0 where the 
+  xenguest-manager will look for xenguest images to create during init. That's
+  the place where xenguest images can be added to have them automatically
+  created during next Dom0 boot. The xenguests found there will only be created
+  if they were not already before (the basename of the files is used as guest
+  name).
+  This is set by default to "/usr/share/guests".
+

meta-arm-autonomy/documentation/xenguest-mkimage.md

@@ -0,0 +1,119 @@
+Xenguest mkimage
+================
+
+Introduction
+------------
+
+xenguest-mkimage is a tool to create and modify images to be used as Guest with
+Xen. It defines a format to store completely defined guests as a file or as
+a directory and provides options to create and modify those images.
+
+A xenguest image contains all elements required to create a xen guest.
+This is the base elements like a Xen configuration and a Linux kernel binary
+but also some more advanced elements like init scripts or a disk definition.
+
+The format is made to be deployable easily by storing everything in a single
+file and provide tools to easily manipulate the images. It can also easily be
+extended to have features like encryption or signature of images, updates or
+complex configurations by providing features to have init script that will be
+executed on the host embedded inside the image.
+
+Xenguest images content
+-----------------------
+
+### params.cfg
+
+This file contains parameters that can be used by tools to configure some
+functionalities on the host. This can be used by init scripts to have
+configurable parameters as it is sourced before calling init scripts.
+
+### guest.cfg and guest.d
+
+guest.cfg is the main xen configuration and guest.d contains optional
+configuration parts. All those will be merged into one final xen configuration
+before starting the guest.
+
+### files
+This directory contains files that can be used by the xen configuration, for
+example the binary of the kernel referenced in xen configuration).
+This is where the kernel binary, the dtb or a ramdisk will be stored.
+
+### init.pre, init.d and init.post
+These directories contain init scripts that will be executed on the host
+during the guest startup. Those must be shell scripts and each directory
+contains scripts called at a different time:
+ - init.pre: scripts executed before the guest is created. This can be used
+     to prepare some features required to create the guest in xen or to
+     generate part of the xen configuration dynamically.
+ - init.d: scripts executed when the guest has been created but before it is
+     started. This can be used to do some xenstore operations or configure the
+     guest behaviour using xl, for example.
+ - init.post: scripts executed just after starting the guest. This can be
+     used to configure things created by xen for the guest like network
+     network interfaces.
+
+When a directory contains several scripts, those will be called in alphabetical
+order.
+
+### disk.cfg and disk-files
+disk.cfg contains the guest disk description (disk size and disk partitions).
+The file contains the following entries:
+- `DISK_SIZE=X`: size of the disk to create in GB
+- `DISK_PARTX=SIZE:FS:CONTENT`: create a partition number X (1 to 4) with a
+  size of SIZE GB, format it with filesystem FS (can be ext2, ext3, ext4, vfat
+  or swap) and extract CONTENT as initial partition content
+  (.tar[.gz|.xz|.bz2] file or img[.gz|.bz2] file to be dumped in the partition). FS and
+  CONTENT can be empty.
+
+The disk-files contain files to be used for initializing the disk partitions
+content. Those should be used to create a LVM or a physical disk and initialize
+it (create partitions, format them and put the initial content).
+
+Usage
+-----
+
+xenguest-mkimage is a shell script which must be called like this:
+`xenguest-mkimage OPERATION XENGUEST [OPTIONS]`
+
+### Operations
+- create: create a xenguest image. If XENGUEST is an existing empty directory,
+  the image is created as a directory otherwise it will be created as a file.
+- check: verify that XENGUEST is a valid xenguest image.
+- update: modify a xenguest image (see --help for a list of operations).
+- pack: pack a xenguest image directory into a xenguest image file. The file to
+  be created must be given as 3rd argument.
+- extract: extract a xenguest image file into a directory. The destination
+  directory must be given as 3rd argument.
+- dump-xenconfig: dump xenguest image xen configuration.
+- dump-diskconfig: dump xenguest image disk configuration.
+- dump-paramsconfig: dump xenguest image parameters configuration.
+
+For a detailed help on available operations, please use:
+`xenguest-mkimage --help`
+
+### Options
+- --kernel=FILE: add kernel FILE as guest kernel. This is both adding the file
+  to the image and modifying the xen configuration to use it.
+- --xen-memory=SIZE: set the guest memory size in MB.
+- --xen-extra: add a kernel command line argument. This can be called several
+  times to add several command line options.
+- --xen-device-tree=FILE: add dtb FILE as device tree. This both adding the
+  file to the image and modifying the xen configuration to use it.
+- --init-script=FILE: add guest init script. The script is embedded inside the
+  image file. Several script can be added and the basename of FILE is used to
+  distinguish them (calling the option twice with the same file will update the
+  script in the image with the second one).
+ --disk-size=SIZE: set the guest disk size to SIZE in GB. Calling this with 0
+  disable the guest disk.
+- --disk-add-part=NUM:SIZE:FS:CONTENT: This is adding a partition to the
+  xenguest image disk. The partition is described with the arguments:
+  - NUM: partition number.
+  - SIZE: partition size in GB.
+  - FS: filesystem to format the partition with. This can be ext2, ext3, ext4,
+    vfat of swap. If empty the partition is not formated.
+  - CONTENT: tar of img file to use to initialize the partition. The file must
+    be added to the image using --disk-add-file=FILE:CONTENT.
+
+For a detailed help on available options, please use:
+`xenguest-mkimage OPERATION --help`
+

meta-arm-autonomy/documentation/xenguest-network-bridge.md

@@ -0,0 +1,49 @@
+xenguest network bridge
+=======================
+
+Introduction
+------------
+
+xenguest-network-bridge is creating a network bridge to allow some guests to
+have a direct connection to the external network.
+To do this, a bridge is created on the host using brctl with the network
+interfaces added to it so that the bridge is connected to the external network.
+It is also adding a guest init script which will, for guests configured to use
+it, create a virtual network interface for the guest and connect it to the
+network bridge on the host.
+
+Usage
+-----
+
+On the host the package xenguest-network-bridge must be included in your image.
+
+On the xenguest image of your guest, the parameter NETWORK_BRIDGE must be set
+to 1 (using xenguest-mkimage --set-param=NETWORK_BRIDGE=1).
+
+Bitbake parameters
+------------------
+Several parameters are available to configure the xenguest network bridge
+during Yocto project compilation (those can be set in your project local.conf,
+for example).
+
+The following parameters are available:
+
+- XENGUEST_NETWORK_BRIDGE_NAME: This variable defines the name of the network
+  bridge that is created on the host during init.
+  This is set by default to "xenbr0".
+
+- XENGUEST_NETWORK_BRIDGE_MEMBERS: This variable defines the list of network
+  interfaces that are added to the bridge when it is created on the host during
+  init.
+  This is set by default to "eth0".
+
+- XENGUEST_NETWORK_BRIDGE_CONFIG: This variable defines the configuration file
+  to use to configure the bridge network. By default it points to have file
+  configuring the network using dhcp.
+  You can provide a different file using a bbappend and make this variable
+  point to it if you want to customize your network configuration.
+
+- XENGUEST_IMAGE_NETWORK_BRIDGE: This variable can be set to 0 or 1 on guest
+  projects to enable or not the connection of the guest to the host bridge.
+  This is set by default to "1".
+

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-bsp/boot-wrapper-aaarch64/boot-wrapper-aarch64_%.bbappend

@@ -1,6 +1,6 @@
 # Use OVERRIDES to minimize the usage of
 # ${@bb.utils.contains('DISTRO_FEATURES', 'xen', ...
-OVERRIDES:append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ':xen', '', d)}"
+OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ':xen', '', d)}"
 
 # Xen image to put in the image
 # This should point to a file in the deploy image directory
@@ -9,21 +9,21 @@ BOOT_WRAPPER_AARCH64_XEN ??= "xen-${MACHINE}"
 # Xen command line for the image
 BOOT_WRAPPER_AARCH64_XEN_CMDLINE ??= "noreboot dom0_mem=256M"
 
-BOOT_WRAPPER_AARCH64_XEN_CMDLINE:gem5-arm64 = "noreboot dom0_mem=256M console=dtuart \
+BOOT_WRAPPER_AARCH64_XEN_CMDLINE_gem5-arm64 = "noreboot dom0_mem=256M console=dtuart \
     dtuart=/uart@1c090000 bootscrub=0"
 
 # Fix command line in the axf file for gem5-arm64 when Xen is present
-BOOT_WRAPPER_AARCH64_CMDLINE_xen:gem5-arm64 = "console=hvc0 root=/dev/vda rw"
+BOOT_WRAPPER_AARCH64_CMDLINE_xen_gem5-arm64 = "console=hvc0 root=/dev/vda rw"
 
 # Image generated by boot wrapper when Xen is present
-BOOT_WRAPPER_AARCH64_IMAGE:xen ?= "xen-system.axf"
+BOOT_WRAPPER_AARCH64_IMAGE_xen ?= "xen-system.axf"
 
-EXTRA_OECONF:append:xen = " \
+EXTRA_OECONF_append_xen = " \
 --with-xen=${WORKDIR}/kernel/arch/arm64/boot/Image \
 --with-xen-cmdline="" \
 "
 
-EXTRA_OEMAKE:append:xen = " \
+EXTRA_OEMAKE_append_xen = " \
 XEN_IMAGE=${DEPLOY_DIR_IMAGE}/${BOOT_WRAPPER_AARCH64_XEN} \
 XEN_CMDLINE="${BOOT_WRAPPER_AARCH64_XEN_CMDLINE}" \
 "

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-bsp/images/firmware-image-juno.bbappend

@@ -0,0 +1,21 @@
+# Use OVERRIDES to minimize the usage of
+# ${@bb.utils.contains('DISTRO_FEATURES', 'xen', ...
+OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ':xen', '', d)}"
+
+FILESEXTRAPATHS_prepend_xen := "${THISDIR}/${PN}:"
+
+DEPLOY_EXTRA_DEPS ??= ""
+DEPLOY_EXTRA_DEPS_xen = "xen:do_deploy xen-devicetree:do_deploy"
+
+do_deploy[depends] += "${DEPLOY_EXTRA_DEPS}"
+
+do_deploy_prepend_xen() {
+    # To avoid dependency loop between firmware-image-juno:do_install,
+    # xen:do_deploy and xen-devicetree:do_deploy when
+    # INITRAMFS_IMAGE_BUNDLE = "1", we need to handle the xen and
+    # xen-devicetree binaries copying in the do_deploy task.
+    cp  ${DEPLOY_DIR_IMAGE}/xen-${COMPATIBLE_MACHINE}.efi \
+        ${D}/${UNPACK_DIR}/SOFTWARE/xen
+    cp ${DEPLOY_DIR_IMAGE}/*xen.dtb \
+        ${D}/${UNPACK_DIR}/SOFTWARE/
+}

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-bsp/images/firmware-image-juno/images-r0.txt

@@ -0,0 +1,78 @@
+TITLE: Versatile Express Images Configuration File
+
+[IMAGES]
+TOTALIMAGES: 11                  ;Number of Images (Max: 32)
+
+NOR0UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR0ADDRESS: 0x00000000          ;Image Flash Address
+NOR0FILE: \SOFTWARE\fip.bin      ;Image File Name
+NOR0LOAD: 00000000               ;Image Load Address
+NOR0ENTRY: 00000000              ;Image Entry Point
+
+NOR1UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR1ADDRESS: 0x03EC0000          ;Image Flash Address
+NOR1FILE: \SOFTWARE\bl1.bin      ;Image File Name
+NOR1LOAD: 00000000               ;Image Load Address
+NOR1ENTRY: 00000000              ;Image Entry Point
+
+NOR2UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR2ADDRESS: 0x00500000          ;Image Flash Address
+NOR2FILE: \SOFTWARE\Image        ;Image File Name
+NOR2NAME: norkern                ;Rename kernel to norkern
+NOR2LOAD: 00000000               ;Image Load Address
+NOR2ENTRY: 00000000              ;Image Entry Point
+
+NOR3UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR3ADDRESS: 0x02700000          ;Image Flash Address
+NOR3FILE: \SOFTWARE\juno-xen.dtb ;Image File Name
+NOR3NAME: board.dtb              ;Specify target filename to preserve file extension
+NOR3LOAD: 00000000               ;Image Load Address
+NOR3ENTRY: 00000000              ;Image Entry Point
+
+NOR4UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR4ADDRESS: 0x01D00000          ;Image Flash Address
+NOR4FILE: \SOFTWARE\xen          ;Image File Name
+NOR4NAME: xen
+NOR4LOAD: 00000000               ;Image Load Address
+NOR4ENTRY: 00000000              ;Image Entry Point
+
+NOR5UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR5ADDRESS: 0x025C0000          ;Image Flash Address
+NOR5FILE: \SOFTWARE\hdlcdclk.dat ;Image File Name
+NOR5LOAD: 00000000               ;Image Load Address
+NOR5ENTRY: 00000000              ;Image Entry Point
+
+NOR6UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR6ADDRESS: 0x03E40000          ;Image Flash Address
+NOR6FILE: \SOFTWARE\scp_bl1.bin  ;Image File Name
+NOR6LOAD: 00000000               ;Image Load Address
+NOR6ENTRY: 00000000              ;Image Entry Point
+
+NOR7UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR7ADDRESS: 0x0BF00000          ;Image Flash Address
+NOR7FILE: \SOFTWARE\startup.nsh  ;Image File Name
+NOR7NAME: startup.nsh
+NOR7LOAD: 00000000               ;Image Load Address
+NOR7ENTRY: 00000000              ;Image Entry Point
+
+NOR8UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR8ADDRESS: 0x0BFC0000          ;Image Flash Address
+NOR8FILE: \SOFTWARE\blank.img    ;Image File Name
+NOR8NAME: BOOTENV
+NOR8LOAD: 00000000               ;Image Load Address
+NOR8ENTRY: 00000000              ;Image Entry Point
+
+NOR9UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR9ADDRESS: 0x02600000          ;Image Flash Address
+NOR9FILE: \SOFTWARE\selftest     ;Image File Name
+NOR9LOAD: 00000000               ;Image Load Address
+NOR9ENTRY: 00000000              ;Image Entry Point
+
+NOR10UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR10ADDRESS: 0x02780000          ;Image Flash Address
+NOR10NAME: uEnv.txt
+NOR10FILE: \SOFTWARE\uEnv.txt     ;Image File Name
+NOR10LOAD: 00000000               ;Image Load Address
+NOR10ENTRY: 00000000              ;Image Entry Point
+
+

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-bsp/images/firmware-image-juno/images-r1.txt

@@ -0,0 +1,78 @@
+TITLE: Versatile Express Images Configuration File
+
+[IMAGES]
+TOTALIMAGES: 11                  ;Number of Images (Max: 32)
+
+NOR0UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR0ADDRESS: 0x00000000          ;Image Flash Address
+NOR0FILE: \SOFTWARE\fip.bin      ;Image File Name
+NOR0LOAD: 00000000               ;Image Load Address
+NOR0ENTRY: 00000000              ;Image Entry Point
+
+NOR1UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR1ADDRESS: 0x03EC0000          ;Image Flash Address
+NOR1FILE: \SOFTWARE\bl1.bin      ;Image File Name
+NOR1LOAD: 00000000               ;Image Load Address
+NOR1ENTRY: 00000000              ;Image Entry Point
+
+NOR2UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR2ADDRESS: 0x00500000          ;Image Flash Address
+NOR2FILE: \SOFTWARE\Image        ;Image File Name
+NOR2NAME: norkern                ;Rename kernel to norkern
+NOR2LOAD: 00000000               ;Image Load Address
+NOR2ENTRY: 00000000              ;Image Entry Point
+
+NOR3UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR3ADDRESS: 0x02700000          ;Image Flash Address
+NOR3FILE: \SOFTWARE\juno-r1-xen.dtb  ;Image File Name
+NOR3NAME: board.dtb              ;Specify target filename to preserve file extension
+NOR3LOAD: 00000000               ;Image Load Address
+NOR3ENTRY: 00000000              ;Image Entry Point
+
+NOR4UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR4ADDRESS: 0x01D00000          ;Image Flash Address
+NOR4FILE: \SOFTWARE\xen          ;Image File Name
+NOR4NAME: xen
+NOR4LOAD: 00000000               ;Image Load Address
+NOR4ENTRY: 00000000              ;Image Entry Point
+
+NOR5UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR5ADDRESS: 0x025C0000          ;Image Flash Address
+NOR5FILE: \SOFTWARE\hdlcdclk.dat ;Image File Name
+NOR5LOAD: 00000000               ;Image Load Address
+NOR5ENTRY: 00000000              ;Image Entry Point
+
+NOR6UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR6ADDRESS: 0x03E40000          ;Image Flash Address
+NOR6FILE: \SOFTWARE\scp_bl1.bin  ;Image File Name
+NOR6LOAD: 00000000               ;Image Load Address
+NOR6ENTRY: 00000000              ;Image Entry Point
+
+NOR7UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR7ADDRESS: 0x0BF00000          ;Image Flash Address
+NOR7FILE: \SOFTWARE\startup.nsh  ;Image File Name
+NOR7NAME: startup.nsh
+NOR7LOAD: 00000000               ;Image Load Address
+NOR7ENTRY: 00000000              ;Image Entry Point
+
+NOR8UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR8ADDRESS: 0x0BFC0000          ;Image Flash Address
+NOR8FILE: \SOFTWARE\blank.img    ;Image File Name
+NOR8NAME: BOOTENV
+NOR8LOAD: 00000000               ;Image Load Address
+NOR8ENTRY: 00000000              ;Image Entry Point
+
+NOR9UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR9ADDRESS: 0x02600000          ;Image Flash Address
+NOR9FILE: \SOFTWARE\selftest     ;Image File Name
+NOR9LOAD: 00000000               ;Image Load Address
+NOR9ENTRY: 00000000              ;Image Entry Point
+
+NOR10UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR10ADDRESS: 0x02780000          ;Image Flash Address
+NOR10NAME: uEnv.txt
+NOR10FILE: \SOFTWARE\uEnv.txt     ;Image File Name
+NOR10LOAD: 00000000               ;Image Load Address
+NOR10ENTRY: 00000000              ;Image Entry Point
+
+

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-bsp/images/firmware-image-juno/images-r2.txt

@@ -0,0 +1,78 @@
+TITLE: Versatile Express Images Configuration File
+
+[IMAGES]
+TOTALIMAGES: 11                  ;Number of Images (Max: 32)
+
+NOR0UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR0ADDRESS: 0x00000000          ;Image Flash Address
+NOR0FILE: \SOFTWARE\fip.bin      ;Image File Name
+NOR0LOAD: 00000000               ;Image Load Address
+NOR0ENTRY: 00000000              ;Image Entry Point
+
+NOR1UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR1ADDRESS: 0x03EC0000          ;Image Flash Address
+NOR1FILE: \SOFTWARE\bl1.bin      ;Image File Name
+NOR1LOAD: 00000000               ;Image Load Address
+NOR1ENTRY: 00000000              ;Image Entry Point
+
+NOR2UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR2ADDRESS: 0x00500000          ;Image Flash Address
+NOR2FILE: \SOFTWARE\Image        ;Image File Name
+NOR2NAME: norkern                ;Rename kernel to norkern
+NOR2LOAD: 00000000               ;Image Load Address
+NOR2ENTRY: 00000000              ;Image Entry Point
+
+NOR3UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR3ADDRESS: 0x02700000          ;Image Flash Address
+NOR3FILE: \SOFTWARE\juno-r2-xen.dtb  ;Image File Name
+NOR3NAME: board.dtb              ;Specify target filename to preserve file extension
+NOR3LOAD: 00000000               ;Image Load Address
+NOR3ENTRY: 00000000              ;Image Entry Point
+
+NOR4UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR4ADDRESS: 0x01D00000          ;Image Flash Address
+NOR4FILE: \SOFTWARE\xen          ;Image File Name
+NOR4NAME: xen
+NOR4LOAD: 00000000               ;Image Load Address
+NOR4ENTRY: 00000000              ;Image Entry Point
+
+NOR5UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR5ADDRESS: 0x025C0000          ;Image Flash Address
+NOR5FILE: \SOFTWARE\hdlcdclk.dat ;Image File Name
+NOR5LOAD: 00000000               ;Image Load Address
+NOR5ENTRY: 00000000              ;Image Entry Point
+
+NOR6UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR6ADDRESS: 0x03E40000          ;Image Flash Address
+NOR6FILE: \SOFTWARE\scp_bl1.bin  ;Image File Name
+NOR6LOAD: 00000000               ;Image Load Address
+NOR6ENTRY: 00000000              ;Image Entry Point
+
+NOR7UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR7ADDRESS: 0x0BF00000          ;Image Flash Address
+NOR7FILE: \SOFTWARE\startup.nsh  ;Image File Name
+NOR7NAME: startup.nsh
+NOR7LOAD: 00000000               ;Image Load Address
+NOR7ENTRY: 00000000              ;Image Entry Point
+
+NOR8UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR8ADDRESS: 0x0BFC0000          ;Image Flash Address
+NOR8FILE: \SOFTWARE\blank.img    ;Image File Name
+NOR8NAME: BOOTENV
+NOR8LOAD: 00000000               ;Image Load Address
+NOR8ENTRY: 00000000              ;Image Entry Point
+
+NOR9UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR9ADDRESS: 0x02600000          ;Image Flash Address
+NOR9FILE: \SOFTWARE\selftest     ;Image File Name
+NOR9LOAD: 00000000               ;Image Load Address
+NOR9ENTRY: 00000000              ;Image Entry Point
+
+NOR10UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+NOR10ADDRESS: 0x02780000          ;Image Flash Address
+NOR10NAME: uEnv.txt
+NOR10FILE: \SOFTWARE\uEnv.txt     ;Image File Name
+NOR10LOAD: 00000000               ;Image Load Address
+NOR10ENTRY: 00000000              ;Image Entry Point
+
+

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-bsp/images/firmware-image-juno/uEnv.txt

@@ -0,0 +1,15 @@
+xen_name=xen
+xen_addr=0x84000000
+uenvcmd=run mybootcmd
+mybootcmd=echo Loading custom boot command; \
+echo Loading kernel; \
+afs load ${kernel_name} ${kernel_addr} ; \
+if test $? -eq 1; then echo Loading ${kernel_alt_name} instead of ${kernel_name}; afs load ${kernel_alt_name} ${kernel_addr}; fi; \
+echo Loading device tree; \
+afs load  ${fdtfile} ${fdt_addr}; \
+if test $? -eq 1; then echo Loading ${fdt_alt_name} instead of ${fdtfile}; \
+afs load ${fdt_alt_name} ${fdt_addr}; fi; fdt addr ${fdt_addr}; fdt resize; \
+echo Loading Xen; \
+afs load  ${xen_name} ${xen_addr}; \
+if test $? -eq 0; then echo Booting Xen; bootefi ${xen_addr} ${fdt_addr}; fi;
+

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-devtools/gem5/gem5-aarch64-native_20.bbappend

@@ -1,7 +1,7 @@
 # When booting gem5-arm64 with Xen we need to set the cpu as Cortex A53 and
 # remove support for pointer authentification
-GEM5_RUN_EXTRA:append = " \
+GEM5_RUN_EXTRA_append = " \
-${@bb.utils.contains('DISTRO_FEATURES_NATIVE', 'xen', \
+${@bb.utils.contains('DISTRO_FEATURES_NATIVE', 'arm-autonomy-host', \
 '--param=system.cpu_cluster[0].cpus[0].isa[0].midr=0x410fd030 \
 --param=system.cpu_cluster[0].cpus[0].isa[0].id_aa64isar1_el1=0x0', \
 '', d)}"

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xen-devicetree/files/xen-juno.dtsi

@@ -0,0 +1,11 @@
+/*
+ * Disable IOMMU on juno board when Xen is used
+ */
+
+/ {
+
+	/* turn off iommu */
+	iommu@2b600000 {
+		status = "disabled";
+	};
+};

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xen-devicetree/files/xen-n1sdp.dtsi

@@ -0,0 +1,39 @@
+/*
+ * Modify N1SDP DTB to work properly when Xen is used
+ */
+
+/ {
+
+    /*
+     * pmu is using PPI interrupts which are reserved by xen
+     * remove pm nodes
+     */
+    /delete-node/ pmu;
+    /delete-node/ spe-pmu;
+
+    /*
+     * disable IOMMU until we have a proper support in xen
+     */
+    /delete-node/ iommu@4f000000;
+    /delete-node/ iommu@4f400000;
+
+    /*
+     * Set extra registers required for PCI quirks to communicate with SCP
+     * and remove invalid properties due to removal
+     */
+    pcie@68000000 {
+        reg = <0 0x68000000 0 0x1200000>,
+                <0 0x06000000 0 0x80000>,
+                <0 0x62000000 0 0x80000>;
+        /delete-property/ msi-map;
+        /delete-property/ iommu-map;
+    };
+
+    pcie@70000000 {
+        reg = <0 0x70000000 0 0x1200000>,
+                <0 0x06000000 0 0x80000>,
+                <0 0x60000000 0 0x80000>;
+        /delete-property/ msi-map;
+        /delete-property/ iommu-map;
+    };
+};

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xen-devicetree/xen-devicetree.bbappend

@@ -0,0 +1,25 @@
+# Platform dependent parameters
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+# Add a dtb snippet to turn off iommu in dom0 on Juno board
+SRC_URI_append_juno = " file://xen-juno.dtsi"
+XEN_DEVICETREE_DTSI_MERGE_append_juno = " xen-juno.dtsi"
+
+# Add a dtb snippet to remove pmu and iommu in dom0 on N1SDP
+SRC_URI_append_n1sdp = " file://xen-n1sdp.dtsi"
+XEN_DEVICETREE_DTSI_MERGE_append_n1sdp = " xen-n1sdp.dtsi"
+
+# Board specific configs
+XEN_DEVICETREE_DOM0_BOOTARGS_append_juno = " root=/dev/sda1 rootwait"
+XEN_DEVICETREE_XEN_BOOTARGS_append_juno = " console=dtuart dtuart=serial0 bootscrub=0 iommu=no"
+
+XEN_DEVICETREE_DOM0_BOOTARGS_append_n1sdp = " root=/dev/sda1 rootwait"
+XEN_DEVICETREE_XEN_BOOTARGS_append_n1sdp = " console=dtuart dtuart=serial0 bootscrub=0 iommu=no"
+
+XEN_DEVICETREE_DOM0_BOOTARGS_append_fvp-base = " root=/dev/vda2"
+XEN_DEVICETREE_XEN_BOOTARGS_append_fvp-base = " console=dtuart dtuart=serial0 bootscrub=0"
+
+XEN_DEVICETREE_DOM0_BOOTARGS_append_foundation-armv8 = " root=/dev/vda2"
+XEN_DEVICETREE_XEN_BOOTARGS_append_foundation-armv8 = " console=dtuart dtuart=serial0 bootscrub=0"
+

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xen/files/4.12.0/0001-xen-arm-Cap-the-number-of-interrupt-lines-for-dom0.patch

@@ -0,0 +1,44 @@
+From a41feccdb6c03f12bddb4fb650a0465f0ed6eeca Mon Sep 17 00:00:00 2001
+From: Lukas Juenger <juenger@ice.rwth-aachen.de>
+Date: Fri, 5 Apr 2019 15:54:04 +0200
+Subject: [PATCH] xen/arm: Cap the number of interrupt lines for dom0
+
+Dom0 vGIC will use the same number of interrupt lines as the hardware GIC.
+While the hardware GIC can support up to 1020 interrupt lines,
+the vGIC is only supporting up to 992 interrupt lines.
+This means that Xen will not be able to boot on platforms where the hardware
+GIC supports more than 992 interrupt lines.
+While it would make sense to increase the limits in the vGICs, this is not
+trivial because of the design choices.
+At the moment, only models seem to report the maximum of interrupt lines.
+They also do not have any interrupt wired above the 992 limit.
+So it should be fine to cap the number of interrupt lines for dom0 to 992 lines.
+
+Signed-off-by: Lukas Juenger <juenger@ice.rwth-aachen.de>
+Acked-by: Julien Grall <julien.grall@arm.com>
+---
+ xen/arch/arm/setup.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
+index 444857a967..ccb0f181ea 100644
+--- a/xen/arch/arm/setup.c
++++ b/xen/arch/arm/setup.c
+@@ -888,7 +888,13 @@ void __init start_xen(unsigned long boot_phys_offset,
+     /* Create initial domain 0. */
+     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
+     dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
+-    dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
++    /*
++     * Xen vGIC supports a maximum of 992 interrupt lines.
++     * 32 are substracted to cover local IRQs.
++     */
++    dom0_cfg.arch.nr_spis = min(gic_number_lines(), (unsigned int) 992) - 32;
++    if ( gic_number_lines() > 992 )
++        printk(XENLOG_WARNING "Maximum number of vGIC IRQs exceeded.\n");
+     dom0_cfg.max_vcpus = dom0_max_vcpus();
+ 
+     dom0 = domain_create(0, &dom0_cfg, true);
+-- 
+2.17.1
+

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xen/files/fvp/defconfig

@@ -0,0 +1,73 @@
+#
+# Automatically generated file; DO NOT EDIT.
+# Xen/arm 4.12.0 Configuration
+#
+CONFIG_64BIT=y
+CONFIG_ARM_64=y
+CONFIG_ARM=y
+CONFIG_ARCH_DEFCONFIG="arch/arm/configs/arm64_defconfig"
+
+#
+# Architecture Features
+#
+CONFIG_NR_CPUS=128
+CONFIG_GICV3=y
+CONFIG_HVM=y
+# CONFIG_NEW_VGIC is not set
+CONFIG_SBSA_VUART_CONSOLE=y
+CONFIG_ARM_SSBD=y
+CONFIG_HARDEN_BRANCH_PREDICTOR=y
+
+#
+# ARM errata workaround via the alternative framework
+#
+CONFIG_ARM64_ERRATUM_827319=y
+CONFIG_ARM64_ERRATUM_824069=y
+CONFIG_ARM64_ERRATUM_819472=y
+CONFIG_ARM64_ERRATUM_832075=y
+CONFIG_ARM64_ERRATUM_834220=y
+CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR=y
+CONFIG_ALL_PLAT=y
+# CONFIG_QEMU is not set
+# CONFIG_RCAR3 is not set
+# CONFIG_MPSOC is not set
+# CONFIG_NO_PLAT is not set
+CONFIG_ALL64_PLAT=y
+# CONFIG_ALL32_PLAT is not set
+CONFIG_MPSOC_PLATFORM=y
+
+#
+# Common Features
+#
+CONFIG_HAS_ALTERNATIVE=y
+CONFIG_HAS_DEVICE_TREE=y
+CONFIG_MEM_ACCESS=y
+CONFIG_HAS_PDX=y
+# CONFIG_XSM is not set
+CONFIG_SCHED_CREDIT=y
+CONFIG_SCHED_CREDIT2=y
+CONFIG_SCHED_RTDS=y
+# CONFIG_SCHED_ARINC653 is not set
+CONFIG_SCHED_NULL=y
+CONFIG_SCHED_DEFAULT="credit2"
+# CONFIG_LIVEPATCH is not set
+CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS=y
+CONFIG_CMDLINE=""
+CONFIG_DOM0_MEM=""
+
+#
+# Device Drivers
+#
+CONFIG_HAS_NS16550=y
+CONFIG_HAS_CADENCE_UART=y
+CONFIG_HAS_MVEBU=y
+CONFIG_HAS_PL011=y
+CONFIG_HAS_SCIF=y
+CONFIG_HAS_PASSTHROUGH=y
+CONFIG_ARM_SMMU=y
+CONFIG_DEFCONFIG_LIST="arch/arm/configs/arm64_defconfig"
+
+#
+# Debugging Options
+#
+# CONFIG_DEBUG is not set

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xen/files/juno/defconfig

@@ -0,0 +1,73 @@
+#
+# Automatically generated file; DO NOT EDIT.
+# Xen/arm 4.12.0 Configuration
+#
+CONFIG_64BIT=y
+CONFIG_ARM_64=y
+CONFIG_ARM=y
+CONFIG_ARCH_DEFCONFIG="arch/arm/configs/arm64_defconfig"
+
+#
+# Architecture Features
+#
+CONFIG_NR_CPUS=128
+CONFIG_GICV3=y
+CONFIG_HVM=y
+# CONFIG_NEW_VGIC is not set
+CONFIG_SBSA_VUART_CONSOLE=y
+CONFIG_ARM_SSBD=y
+CONFIG_HARDEN_BRANCH_PREDICTOR=y
+
+#
+# ARM errata workaround via the alternative framework
+#
+CONFIG_ARM64_ERRATUM_827319=y
+CONFIG_ARM64_ERRATUM_824069=y
+CONFIG_ARM64_ERRATUM_819472=y
+CONFIG_ARM64_ERRATUM_832075=y
+CONFIG_ARM64_ERRATUM_834220=y
+CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR=y
+CONFIG_ALL_PLAT=y
+# CONFIG_QEMU is not set
+# CONFIG_RCAR3 is not set
+# CONFIG_MPSOC is not set
+# CONFIG_NO_PLAT is not set
+CONFIG_ALL64_PLAT=y
+# CONFIG_ALL32_PLAT is not set
+CONFIG_MPSOC_PLATFORM=y
+
+#
+# Common Features
+#
+CONFIG_HAS_ALTERNATIVE=y
+CONFIG_HAS_DEVICE_TREE=y
+CONFIG_MEM_ACCESS=y
+CONFIG_HAS_PDX=y
+# CONFIG_XSM is not set
+CONFIG_SCHED_CREDIT=y
+CONFIG_SCHED_CREDIT2=y
+CONFIG_SCHED_RTDS=y
+# CONFIG_SCHED_ARINC653 is not set
+CONFIG_SCHED_NULL=y
+CONFIG_SCHED_DEFAULT="credit2"
+# CONFIG_LIVEPATCH is not set
+CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS=y
+CONFIG_CMDLINE=""
+CONFIG_DOM0_MEM=""
+
+#
+# Device Drivers
+#
+CONFIG_HAS_NS16550=y
+CONFIG_HAS_CADENCE_UART=y
+CONFIG_HAS_MVEBU=y
+CONFIG_HAS_PL011=y
+CONFIG_HAS_SCIF=y
+CONFIG_HAS_PASSTHROUGH=y
+CONFIG_ARM_SMMU=y
+CONFIG_DEFCONFIG_LIST="arch/arm/configs/arm64_defconfig"
+
+#
+# Debugging Options
+#
+# CONFIG_DEBUG is not set

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xen/files/n1sdp/defconfig

@@ -0,0 +1,100 @@
+#
+# Automatically generated file; DO NOT EDIT.
+# Xen/arm 4.12.2 Configuration
+#
+CONFIG_64BIT=y
+CONFIG_ARM_64=y
+CONFIG_ARM=y
+CONFIG_ARCH_DEFCONFIG="arch/arm/configs/arm64_defconfig"
+
+#
+# Architecture Features
+#
+CONFIG_NR_CPUS=128
+CONFIG_ACPI=y
+CONFIG_GICV3=y
+CONFIG_HAS_ITS=y
+CONFIG_HVM=y
+# CONFIG_NEW_VGIC is not set
+CONFIG_SBSA_VUART_CONSOLE=y
+CONFIG_ARM_SSBD=y
+CONFIG_HARDEN_BRANCH_PREDICTOR=y
+
+#
+# ARM errata workaround via the alternative framework
+#
+CONFIG_ARM64_ERRATUM_827319=y
+CONFIG_ARM64_ERRATUM_824069=y
+CONFIG_ARM64_ERRATUM_819472=y
+CONFIG_ARM64_ERRATUM_832075=y
+CONFIG_ARM64_ERRATUM_834220=y
+CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR=y
+CONFIG_ALL_PLAT=y
+# CONFIG_QEMU is not set
+# CONFIG_RCAR3 is not set
+# CONFIG_MPSOC is not set
+# CONFIG_NO_PLAT is not set
+CONFIG_ALL64_PLAT=y
+# CONFIG_ALL32_PLAT is not set
+CONFIG_MPSOC_PLATFORM=y
+
+#
+# Common Features
+#
+CONFIG_HAS_ALTERNATIVE=y
+CONFIG_HAS_DEVICE_TREE=y
+# CONFIG_MEM_ACCESS is not set
+CONFIG_HAS_PDX=y
+# CONFIG_TMEM is not set
+CONFIG_XSM=y
+CONFIG_XSM_FLASK=y
+CONFIG_XSM_FLASK_AVC_STATS=y
+# CONFIG_XSM_FLASK_POLICY is not set
+CONFIG_XSM_SILO=y
+# CONFIG_XSM_DUMMY_DEFAULT is not set
+# CONFIG_XSM_FLASK_DEFAULT is not set
+CONFIG_XSM_SILO_DEFAULT=y
+# CONFIG_ARGO is not set
+
+#
+# Schedulers
+#
+CONFIG_SCHED_CREDIT=y
+CONFIG_SCHED_CREDIT2=y
+CONFIG_SCHED_RTDS=y
+# CONFIG_SCHED_ARINC653 is not set
+CONFIG_SCHED_NULL=y
+# CONFIG_SCHED_CREDIT_DEFAULT is not set
+CONFIG_SCHED_CREDIT2_DEFAULT=y
+# CONFIG_SCHED_RTDS_DEFAULT is not set
+# CONFIG_SCHED_NULL_DEFAULT is not set
+CONFIG_SCHED_DEFAULT="credit2"
+# CONFIG_LIVEPATCH is not set
+CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS=y
+CONFIG_CMDLINE=""
+CONFIG_DOM0_MEM=""
+
+#
+# Device Drivers
+#
+CONFIG_HAS_NS16550=y
+CONFIG_HAS_CADENCE_UART=y
+CONFIG_HAS_MVEBU=y
+CONFIG_HAS_PL011=y
+CONFIG_HAS_SCIF=y
+CONFIG_HAS_PASSTHROUGH=y
+CONFIG_ARM_SMMU=y
+CONFIG_DEFCONFIG_LIST="arch/arm/configs/arm64_defconfig"
+
+#
+# Debugging Options
+#
+# CONFIG_DEBUG is not set
+CONFIG_DEBUG_INFO=y
+# CONFIG_FRAME_POINTER is not set
+# CONFIG_COVERAGE is not set
+# CONFIG_LOCK_PROFILE is not set
+# CONFIG_PERF_COUNTERS is not set
+CONFIG_VERBOSE_DEBUG=y
+# CONFIG_DEVICE_TREE_DEBUG is not set
+# CONFIG_SCRUB_DEBUG is not set

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xen/xen_%.bbappend

@@ -0,0 +1,32 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+# Machine specific settings
+XEN_CONFIG_EARLY_PRINTK_juno = "juno"
+XEN_CONFIG_EARLY_PRINTK_gem5-arm64 = "vexpress"
+XEN_CONFIG_EARLY_PRINTK_fvp-base = "fastmodel"
+XEN_CONFIG_EARLY_PRINTK_foundation-armv8 = "fastmodel"
+XEN_CONFIG_EARLY_PRINTK_n1sdp = "pl011,0x2a400000"
+
+# Foundation-armv8 support
+COMPATIBLE_MACHINE_foundation-armv8 = "foundation-armv8"
+
+SRC_URI_append_foundation-armv8 = " file://fvp/defconfig"
+
+# FVP Base support
+COMPATIBLE_MACHINE_fvp-base = "fvp-base"
+
+SRC_URI_append_fvp-base = " file://fvp/defconfig"
+
+# Juno support
+COMPATIBLE_MACHINE_juno = "juno"
+
+SRC_URI_append_juno = " file://juno/defconfig"
+
+# Gem5 support
+# Fix problem with number of interrupts on gem5
+SRC_URI_append_gem5-arm64 = " file://4.12.0/0001-xen-arm-Cap-the-number-of-interrupt-lines-for-dom0.patch"
+
+# N1SDP support
+COMPATIBLE_MACHINE_n1sdp = "n1sdp"
+
+SRC_URI_append_n1sdp = " file://n1sdp/defconfig"

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xenguest/xenguest-manager.bbappend

@@ -0,0 +1,6 @@
+# Board specific configuration for the manager
+
+# FVP and Foundation are using vda as hard drive and partition 2 is the
+# default rootfs, so use vda3 for guest lvm
+XENGUEST_MANAGER_VOLUME_DEVICE_foundation-armv8 ?= "/dev/vda3"
+XENGUEST_MANAGER_VOLUME_DEVICE_fvp-base ?= "/dev/vda3"

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xenguest/xenguest-network-bridge.bbappend

@@ -0,0 +1,10 @@
+XENGUEST_NETWORK_BRIDGE_MEMBERS_n1sdp ?= "eth0"
+
+XENGUEST_NETWORK_BRIDGE_MEMBERS_fvp-base ?= "eth0"
+
+XENGUEST_NETWORK_BRIDGE_MEMBERS_foundation-armv8 ?= "eth0"
+
+XENGUEST_NETWORK_BRIDGE_MEMBERS_gem5-arm64 ?= "eth0"
+
+# Juno board has 2 network interfaces, add both of them to the bridge
+XENGUEST_NETWORK_BRIDGE_MEMBERS_juno ?= "eth0 eth1"

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-kernel/linux/linux-%.bbappend

@@ -0,0 +1,17 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}:"
+
+#
+# arm-autonomy kmeta extra
+#
+SRC_URI_append = " file://arm-autonomy-kmeta-extra;type=kmeta;name=arm-autonomy-kmeta-extra;destsuffix=arm-autonomy-kmeta-extra"
+
+# We need to turn off SVE support in the Linux kernel otherwise Xen is stopping
+# Linux kernel with a coredump while trying to access XEN bit of CPACR1 core
+# register.
+LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE = "${@bb.utils.contains_any('DISTRO_FEATURES', \
+                                         'arm-autonomy-host arm-autonomy-guest', \
+                                         ' features/arm-autonomy/disable-arm64-sve.scc','',d)}"
+
+KERNEL_FEATURES_append_gem5-arm64 = "${LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE}"
+KERNEL_FEATURES_append_fvp-base = "${LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE}"
+KERNEL_FEATURES_append_foundation-armv8 = "${LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE}"

meta-arm-autonomy/recipes-bsp/u-boot/u-boot-2020.01/fvp-base/xen_u-boot_kernel_addr.patch

@@ -0,0 +1,16 @@
+Upstream Status: Inappropriate [meta-arm-autonomy specifc u-boot config]
+Signed-off-by: Nathan Dunne <nathan.dunne@arm.com>
+
+diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h
+index e63c335f85..9ee050a4a6 100644
+--- a/include/configs/vexpress_aemv8a.h
++++ b/include/configs/vexpress_aemv8a.h
+@@ -162,7 +162,7 @@
+ #elif CONFIG_TARGET_VEXPRESS64_BASE_FVP
+ #define CONFIG_EXTRA_ENV_SETTINGS	\
+ 				"kernel_name=Image\0"		\
+-				"kernel_addr=0x80080000\0"	\
++				"kernel_addr=0x84000000\0"	\
+ 				"initrd_name=ramdisk.img\0"	\
+ 				"initrd_addr=0x88000000\0"	\
+ 				"fdtfile=devtree.dtb\0"		\

meta-arm-autonomy/recipes-bsp/u-boot/u-boot_2020.01.bbappend

@@ -0,0 +1,9 @@
+# Machine specific u-boot
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/${BP}:"
+
+#
+# FVP BASE
+#
+
+SRC_URI_append_fvp-base = "${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', ' file://xen_u-boot_kernel_addr.patch', '', d)}"

meta-arm-autonomy/recipes-core/images/arm-autonomy-host-image-minimal.bb

@@ -0,0 +1,120 @@
+# Recipe to create a minimal Arm Autonomy stack host image
+
+DESCRIPTION = "Arm Autonomy stack host minimal image"
+
+inherit core-image
+
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+# The ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS variable can be used to include in the
+# image one or several xenguest images.
+# The list must be space separated and each entry must have the following
+# format: URL[;guestname=NAME]
+#  - URL can be the full path to a file or a Yocto compatible SRC_URI url
+#  - guestname=NAME can be used to specify the name of the guest. If not
+#    specified the basename of the file (without .xenguest extension) is used.
+#  Here are examples of values:
+#  /home/mydir/myguest.xenguest;guestname=guest1
+#  http://www.url.com/testguest.xenguest
+#
+#  If you are using the output of an other Yocto project, you should use the
+#  full path syntax instead of the Yocto SRC_URI to be able to use the
+#  symlink version of your image (as the real file has a new name on each
+#  build as it includes the date). You must not use SRC_URI type file:// as
+#  it will try to include the symlink and not the destination file which will
+#  be detected by the recipe and output an error 'Guest file is a symlink'.
+#
+#  Guests can also be added using a bbapend to this recipe by adding entries
+#  to SRC_URI with parameter ;guestname=NAME to specify the destination
+#  guestname. The parameter guestname must be present as it is used to detect
+#  guests to be added
+ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS ??= ""
+
+# Includes minimal set required to start and manage guest. The xen specific
+# modules are not explicitly included as they are built as part of the kernel
+# image for performance reasons. It doesn't include all kernel modules to
+# reduce the image size. If the kernel-modules packages are needed they can
+# be appended to IMAGE_INSTALL in a bbappend.
+IMAGE_INSTALL += " \
+    packagegroup-core-boot \
+    packagegroup-core-ssh-openssh \
+    qemu-xen \
+    xenguest-manager \
+    xenguest-network-bridge \
+    "
+
+# Build xen binary
+EXTRA_IMAGEDEPENDS += "xen"
+
+# Build xen-devicetree to produce a xen ready devicetree
+EXTRA_IMAGEDEPENDS += "xen-devicetree"
+
+python __anonymous() {
+    if bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', False, True, d):
+        raise bb.parse.SkipRecipe("DISTRO_FEATURES does not contain 'arm-autonomy-host'")
+
+    if bb.utils.contains('DISTRO_FEATURES', 'xen', False, True, d):
+        raise bb.parse.SkipRecipe("DISTRO_FEATURES does not contain 'xen'")
+
+    # Check in ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS for extra guests and add them
+    # to SRC_URI with xenguest parameter if not set
+    guestlist = d.getVar('ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS')
+    if guestlist:
+        for guest in guestlist.split():
+            # If the user just specified a file instead of file://FILE, add
+            # the file:// prefix
+            if guest.startswith('/'):
+                guestfile = ''
+                guestname = ''
+                if ';guestname=' in guest:
+                    # user specified a guestname
+                    guestname = guest.split(';guestname=')[1]
+                    guestfile = guest.split(';guestname=')[0]
+                else:
+                    # no guestname so use the basename
+                    guestname = os.path.basename(guest)
+                    guestfile = guest
+                # in case we have a link we need the destination
+                guestfile = os.path.realpath(guestfile)
+
+                # make sure the file exist to give a meaningfull error
+                if not os.path.exists(guestfile):
+                    raise bb.parse.SkipRecipe("ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS entry does not exist: " + guest)
+
+                # In case the file is a symlink make sure we use the destination
+                d.appendVar('SRC_URI',  ' file://' + guestfile + ';guestname=' + guestname)
+            else:
+                # we have a Yocto URL
+                try:
+                    _, _, path, _, _, parm = bb.fetch.decodeurl(guest)
+                    # force guestname param in if not already there
+                    if not 'guestname' in parm:
+                        guest  += ';guestname=' + os.path.basename(path)
+                    d.appendVar('SRC_URI', ' ' + guest)
+                except:
+                    raise bb.parse.SkipRecipe("ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS contains an invalid entry: " + guest)
+}
+
+python add_extern_guests () {
+    # Destination directory on the rootfs
+    guestdir = d.getVar('IMAGE_ROOTFS') + d.getVar('datadir') + '/guests'
+
+    # Parse SRC_URI for files with ;guestname= parameter
+    src_uri = d.getVar('SRC_URI')
+    for entry in src_uri.split():
+        _, _, path, _, _, parm = bb.fetch.decodeurl(entry)
+        if 'guestname' in parm:
+            if os.path.islink(path):
+                bb.fatal("Guest file is a symlink: " + path)
+            bb.utils.mkdirhier(guestdir)
+            dstname = parm['guestname']
+            # Add file extension if not there
+            if not dstname.endswith('.xenguest'):
+                dstname += '.xenguest'
+            if not bb.utils.copyfile(path, guestdir + '/' + dstname):
+                bb.fatal("Fail to copy Guest file " + path)
+}
+
+IMAGE_PREPROCESS_COMMAND += "add_extern_guests; "
+

meta-arm-autonomy/recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend

@@ -0,0 +1,18 @@
+# Add support for interface configuration via interfaces.d directory. This
+# feature can be used by other packages to add network interface
+# configuration by adding network network interface configuration file under
+# interfaces.d directory.
+
+do_install_append() {
+    # Add scan of interfaces.d to interfaces file
+    cp -f ${WORKDIR}/interfaces ${WORKDIR}/interfaces.subdir
+    echo "source-directory ${sysconfdir}/network/interfaces.d/" \
+        >> ${WORKDIR}/interfaces.subdir
+
+    # Create interfaces.d script in case nobody is adding a script
+    # so that there is no error about non existing directory
+    install -d -m 755 ${D}${sysconfdir}/network/interfaces.d
+
+    # Install our file instead of the original one
+    install -m 644 interfaces.subdir ${D}${sysconfdir}/network/interfaces
+}