ci: make get-binary-toolchain run per build

In a distributed, non-homogeneous CI setup, the binary-toolchain setup
script might not run on the machine that needs the toolchains.  Make
this per-build and it will always be there, at the expense of running on
builds that might not need it (though it still should be fast).

Also, there is an issue with the directory where the binary toolchain is
located being global, and racing against other systems using, setting up,
and tearing down.  Link this to a local directory to avoid any races.

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

.gitlab-ci.yml

@@ -0,0 +1,193 @@
+# We need 2.6.3 as this is the latest container with an old enough distro
+image: ghcr.io/siemens/kas/kas:2.6.3
+
+  # 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
+    # Must do this here, as it's the only way to make sure the toolchain is installed on the same builder
+    - ./ci/get-binary-toolchains $DL_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
+
+# Generalised fragment to do a Kas build
+.build:
+  extends: .setup
+  script:
+    - 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
+
+#
+# Prep stage, update repositories once
+#
+update-repos:
+  extends: .setup
+  stage: prep
+  script:
+  - 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
+  interruptible: true
+  script:
+  - ./ci/check-machine-coverage
+  coverage: '/Coverage: \d+/'
+
+
+#
+# Build stage, the actual build jobs
+#
+
+a5ds:
+  extends: .build
+
+corstone700-fvp:
+  extends: .build
+
+corstone700-mps3:
+  extends: .build
+
+foundation-armv8:
+  extends: .build
+
+fvp-base:
+  extends: .build
+
+fvp-base-arm32:
+  extends: .build
+
+fvp-base-arm32/external-gccarm:
+  extends: .build
+
+gem5-arm64:
+  extends: .build
+
+juno:
+  extends: .build
+
+juno/clang:
+  extends: .build
+
+musca-b1:
+  extends: .build
+
+musca-s1:
+  extends: .build
+
+n1sdp:
+  extends: .build
+
+# This job currently fails when building gcc-runtime:
+# cc1: error: switch '-mcpu=armv8.2-a' conflicts with '-march=armv8-a' switch [-Werror]
+# Mark as manual so it doesn't get executed automatically
+n1sdp/armgcc:
+  extends: .build
+  when: manual
+
+qemuarm/testimage:
+  extends: .build
+
+qemuarm64-secureboot/testimage:
+  extends: .build
+
+qemuarm64-secureboot/clang/testimage:
+  extends: .build
+
+qemuarm64-secureboot/clang/musl/testimage:
+  extends: .build
+
+qemuarm64-secureboot/musl/testimage:
+  extends: .build
+
+qemuarmv5/testimage:
+  extends: .build
+
+sgi575:
+  extends: .build
+
+tc0:
+  extends: .build
+
+
+#
+# Utility tasks, not executed automatically
+#
+
+delete-dl-dir:
+  extends: .setup
+  stage: prep
+  when: manual
+  script:
+  - rm -rf $DL_DIR/*
+
+delete-repo-dir:
+  extends: .setup
+  stage: prep
+  when: manual
+  script:
+  - rm -rf $KAS_REPO_REF_DIR/*
+
+# Delete all sstate
+delete-sstate:
+  extends: .setup
+  stage: prep
+  when: manual
+  script:
+  - rm -rf $SSTATE_DIR/*
+
+delete-toolchains:
+  extends: .setup
+  stage: prep
+  when: manual
+  script:
+  - rm -rf $TOOLCHAIN_DIR/*
+
+# Wipe out old sstate
+prune-sstate:
+  extends: .setup
+  stage: prep
+  when: manual
+  script:
+  - du -h -s $SSTATE_DIR
+  - 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 $TOOLCHAIN_DIR

COPYING.MIT

@@ -1,17 +1,17 @@
-Permission is hereby granted, free of charge, to any person obtaining a copy 
-of this software and associated documentation files (the "Software"), to deal 
-in the Software without restriction, including without limitation the rights 
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 
-copies of the Software, and to permit persons to whom the Software is 
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 
-The above copyright notice and this permission notice shall be included in 
+The above copyright notice and this permission notice shall be included in
 all copies or substantial portions of the Software.
 
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
 THE SOFTWARE.

README.md

@@ -0,0 +1,50 @@
+Introduction
+------------
+This repository contains Arm layers for OpenEmbedded
+
+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.
+
+meta-arm-bsp:
+	This layer provides support for Arm reference platforms
+
+meta-arm-iota:
+	This layer provides support for Arm's IOTA Linux Distribution
+
+meta-arm-toolchain:
+	This layer provides support for Arm's GNU-A toolset releases
+
+meta-arm-autonomy:
+    This layer provides a reference stack for autonomous systems.
+
+Contributing
+------------
+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:
+
+$ 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.
+
+Maintainer(s)
+-------------
+* Jon Mason <jon.mason@arm.com>
+* Ross Burton <ross.burton@arm.com>

arm/classes/cramfs-xip.bbclass

@@ -1,15 +0,0 @@
-# SPDX-License-Identifier: MIT
-#
-# Copyright (c) 2019 Arm Limited
-#
-SUMMARY = "Cramfs XIP image type"
-DESCRIPTION = "Cramfs XIP type image to add to IMAGE_TYPES"
-LICENSE = "MIT"
-
-inherit image_types
-
-do_image_cramfs_xip[depends] += "cramfs-tools-native:do_populate_sysroot"
-
-IMAGE_TYPES += " cramfs-xip"
-
-IMAGE_CMD_cramfs-xip = "mkcramfs -n ${IMAGE_NAME} -X ${IMAGE_ROOTFS} ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cramfs-xip ${EXTRA_IMAGECMD}"

arm/conf/layer.conf

@@ -1,21 +0,0 @@
-# SPDX-License-Identifier: MIT
-#
-# Copyright (c) 2019 Arm Limited
-#
-
-# arm has a conf and classes directory, add to BBPATH
-BBPATH	 .= ":${LAYERDIR}"
-
-BBFILES += " \
-		${LAYERDIR}/recipes-*/*/*.bb \
-		${LAYERDIR}/recipes-*/*/*.bbappend"
-
-BBFILES += "${@' '.join('${LAYERDIR}/%s/recipes*/*/*.bbappend' % layer \
-	     for layer in BBFILE_COLLECTIONS.split())}"
-
-BBFILE_COLLECTIONS += "arm"
-BBFILE_PATTERN_arm := "^${LAYERDIR}/"
-BBFILE_PRIORITY_arm = "10"
-LAYERSERIES_COMPAT_arm = "warrior"
-
-LAYERDEPENDS_arm = "core"

arm/conf/machine/include/arm-common-configuration.inc

@@ -1,18 +0,0 @@
-# SPDX-License-Identifier: MIT
-#
-# Copyright (c) 2019 Arm Limited
-#
-
-IMAGE_FSTYPES += "tar.bz2 wic cpio.gz"
-
-EXTRA_IMAGEDEPENDS_append = " trusted-firmware-a"
-
-PREFERRED_PROVIDER_u-boot ?= "u-boot"
-PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
-
-UBOOT_SUFFIX ?= "bin"
-UBOOT_MACHINE ?= "vexpress_aemv8a_aarch32_defconfig"
-
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-arm"
-
-SERIAL_CONSOLES = "115200;ttyAMA0"

arm/conf/machine/include/cortex-a32.inc

@@ -1,8 +0,0 @@
-# SPDX-License-Identifier: MIT
-#
-# Copyright (c) 2019 Arm Limited
-#
-
-TUNE_FEATURES = "aarch32"
-
-require conf/machine/include/arm/arch-armv8a.inc

arm/conf/machine/include/cortex-a5.inc

@@ -1,11 +0,0 @@
-# SPDX-License-Identifier: MIT
-#
-# Copyright (c) 2019 Arm Limited
-#
-
-DEFAULTTUNE="cortexa5"
-
-require conf/machine/include/tune-cortexa5.inc
-
-TF-A_EXTRA_OPTIONS = "ARM_ARCH_MAJOR=7 ARM_CORTEX_A5=yes \
-		     ARM_XLAT_TABLES_LIB_V1=1"

arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a.bb

@@ -1,61 +0,0 @@
-# SPDX-License-Identifier: MIT
-#
-# Copyright (c) 2019 Arm Limited
-#
-
-SUMMARY = "Trusted Firmware for Cortex-A"
-DESCRIPTION = "Trusted Firmware-A"
-HOMEPAGE = "https://github.com/ARM-software/arm-trusted-firmware"
-LICENSE = "BSD-3-Clause"
-
-TF-A_DEPENDS ?= ""
-
-DEPENDS += " dtc-native coreutils-native"
-DEPENDS += " ${TF-A_DEPENDS} "
-
-LIC_FILES_CHKSUM = "file://license.rst;md5=90153916317c204fade8b8df15739cde"
-
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-SRCREV = "${AUTOREV}"
-
-SRC_URI = "\
-  git://github.com/ARM-software/arm-trusted-firmware;protocol=https;nobranch=1 \
-  "
-
-S = "${WORKDIR}/git"
-B = "${WORKDIR}/build"
-
-COMPATIBLE_MACHINE = "(vexpress-a5|vexpress-a32|corstone700|a5ds)"
-
-LDFLAGS[unexport] = "1"
-
-TF-A_PLATFORM ?= "fvp"
-TF-A_ARCH ?= "aarch32"
-TF-A_DEBUG ?= "1"
-TF-A_AARCH32_SP ?= "sp_min"
-TF-A_BL33 ?= ""
-
-TF-A_TARGET_IMAGES ?= "all fip"
-TF-A_EXTRA_OPTIONS ?= ""
-
-do_compile() {
-    mkdir -p ${B}
-
-    oe_runmake -C ${S} BUILD_BASE=${B} \
-      BUILD_PLAT=${B}/${TF-A_PLATFORM}/ \
-      PLAT=${TF-A_PLATFORM} \
-      DEBUG=${TF-A_DEBUG} \
-      ARCH=${TF-A_ARCH} \
-      CROSS_COMPILE=${TARGET_PREFIX} \
-      AARCH32_SP=${TF-A_AARCH32_SP} \
-      BL33=${TF-A_BL33} \
-      ${TF-A_EXTRA_OPTIONS} \
-      ${TF-A_TARGET_IMAGES}
-}
-
-do_install() {
-	[ -f ${B}/${TF-A_PLATFORM}/bl1.bin ] && install -D -p -m 0644 ${B}/${TF-A_PLATFORM}/bl1.bin ${DEPLOY_DIR_IMAGE}/bl1.bin
-	[ -f ${B}/${TF-A_PLATFORM}/bl1/bl1.elf ] && install -D -p -m 0644 ${B}/${TF-A_PLATFORM}/bl1/bl1.elf ${DEPLOY_DIR_IMAGE}/bl1.elf
-	install -D -p -m 0644 ${B}/${TF-A_PLATFORM}/fip.bin ${DEPLOY_DIR_IMAGE}/${TF-A_PLATFORM}.fip
-}

arm/recipes-bsp/u-boot/u-boot_%.bbappend

@@ -1,30 +0,0 @@
-# SPDX-License-Identifier: MIT
-#
-# Copyright (c) 2019 Arm Limited
-#
-
-SRCREV = "9bed08a2ed8d4915e694e5b4a030bd361b829a52"
-
-LIC_FILES_CHKSUM = "file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
-
-SRC_URI = "\
-  git://git.linaro.org/landing-teams/working/arm/u-boot;protocol=https;nobranch=1 \
-  "
-
-S = "${WORKDIR}/git"
-B = "${WORKDIR}/build"
-
-U-BOOT_PLATFORM = "fvp_ve"
-
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-COMPATIBLE_MACHINE = "(vexpress-a5|vexpress-a32|a5ds)"
-
-do_compile() {
-    mkdir -p ${B}
-
-    oe_runmake -C ${S} BUILD_BASE=${B} \
-      BUILD_PLAT=${B}/${PLATFORM}/ \
-      SUPPORT_ARCH_TIMER=no \
-      O=${B}
-}

arm/recipes-core/cramfs-tools/cramfs-tools.bb

@@ -1,23 +0,0 @@
-SUMMARY = "Cramfs tools"
-DESCRIPTION = "Cramfs tools to create cramfs images with support to XIP"
-HOMEPAGE = "https://github.com/npitre/cramfs-tools"
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-
-SRC_URI = "git://github.com/npitre/cramfs-tools;protocol=https;nobranch=1"
-
-SRCREV = "23d032e6e0a973810c6aedf165441592641b60f4"
-
-BBCLASSEXTEND = "native"
-
-S = "${WORKDIR}/git"
-
-do_compile () {
-      oe_runmake
-}
-
-do_install() {
-    install -d ${D}${bindir}
-    install ${S}/mkcramfs ${D}${bindir}
-    install ${S}/cramfsck ${D}${bindir}
-}

arm/recipes-devtools/gcc-arm-none-eabi-native_7.3.1/gcc-arm-none-eabi-native_7.3.1.bb

@@ -1,36 +0,0 @@
-# SPDX-License-Identifier: MIT
-#
-# Copyright (c) 2019 Arm Limited
-#
-
-# Recipe for fetching and installing the prebuilt gcc-arm toolchain for
-# bare-metal targets.
-# Recipe based on the meta-ti layer:
-# http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti/devtools/gcc-arm-none-eabi-native_4.9.2015q3.bb?h=master
-#
-# Whilst most of the tools built in relies on the linaro-provided
-# toolchain, some recipes require the baremetal Arm GCC toolchain. The baremetal
-# Arm GCC toolchain is distributed as precompiled binaries. This recipe fetches
-# the toolchain and installs it in sysroot.
-# Recipes may then 'DEPENDS' on this recipe to fetch the toolchain, making the
-# toolchain available in the staging directory of the depending recipe.
-
-GCC_ARM_VERSION = "gcc-arm-none-eabi-7-2018-q2-update"
-LICENSE="GPLv3"
-LIC_FILES_CHKSUM = "file://share/doc/gcc-arm-none-eabi/license.txt;md5=f77466c63f5787f4bd669c402aabe061"
-
-inherit native
-
-SRC_URI = "https://developer.arm.com/-/media/Files/downloads/gnu-rm/7-2018q2/${GCC_ARM_VERSION}-linux.tar.bz2;name=tc32"
-SRC_URI[tc32.md5sum] = "299ebd3f1c2c90930d28ab82e5d8d6c0"
-
-S = "${WORKDIR}/${GCC_ARM_VERSION}"
-
-do_install() {
-    install -d ${D}${INSTALL_GCC_ARM_NONE_EABI}
-    cp -r ${S}/. ${D}${INSTALL_GCC_ARM_NONE_EABI}
-}
-
-FILES_${PN} = "${INSTALL_GCC_ARM_NONE_EABI}/"
-
-INSANE_SKIP_${PN} = "already-stripped"

arm/recipes-kernel/dtc/dtc_%.bbappend

@@ -1,10 +0,0 @@
-# SPDX-License-Identifier: MIT
-#
-# Copyright (c) 2019 Arm Limited
-#
-
-SRC_URI = "git://git.kernel.org/pub/scm/utils/dtc/dtc.git"
-
-SRCREV = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf"
-
-LIC_FILES_CHKSUM = "file://GPL;md5=94d55d512a9ba36caa9b7df079bae19f"

arm/recipes-kernel/linux/linux-arm-common.inc

@@ -1,35 +0,0 @@
-# SPDX-License-Identifier: MIT
-#
-# Copyright (c) 2019 Arm Limited
-#
-
-DESCRIPTION = "Linux Kernel provided and supported by Arm and Linaro with \
-focus on vexpress and other Arm models and hardware. Trying to be as much \
-as possible close to upstream tree."
-SECTION = "kernel"
-LICENSE = "GPLv2"
-SRCREV_FORMAT = "kernel"
-
-require recipes-kernel/linux/linux-yocto.inc
-
-KERNEL_VERSION_SANITY_SKIP = "1"
-
-S = "${WORKDIR}/git"
-
-COMPATIBLE_MACHINE = "(vexpress-a5|vexpress-a32|corstone700|a5ds)"
-
-# Override do_kernel_configme to avoid kernel being assembled into a linux-yocto style kernel
-# https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#ref-tasks-kernel_configme
-do_kernel_configme() {
-}
-
-KBRANCH = ""
-LINUX_VERSION ?= "5.2"
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
-
-SRC_URI = "\
-	  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux;protocol=https;nobranch=1 \
-	"
-
-SRCREV = "v5.2"

arm/recipes-kernel/linux/linux-arm.bb

@@ -1,8 +0,0 @@
-# SPDX-License-Identifier: MIT
-#
-# Copyright (c) 2019 Arm Limited
-#
-
-SUMMARY = "Linux Kernel provided and supported by Arm/Linaro"
-
-require recipes-kernel/linux/linux-arm-common.inc

ci/a5ds.yml

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

ci/armgcc.yml

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

ci/base.yml

@@ -0,0 +1,45 @@
+header:
+  version: 9
+
+distro: poky
+
+defaults:
+  repos:
+    refspec: gatesgarth
+
+repos:
+  meta-arm:
+    layers:
+      meta-arm:
+      meta-arm-bsp:
+      meta-arm-toolchain:
+
+  poky:
+    url: https://git.yoctoproject.org/git/poky
+    layers:
+      meta:
+      meta-poky:
+
+env:
+  BB_LOGCONFIG: ""
+  TOOLCHAIN_DIR: ""
+
+local_conf_header:
+  base: |
+    CONF_VERSION = "1"
+    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"
+    INHERIT += "rm_work"
+    PACKAGECONFIG_append_pn-perf = " coresight"
+  ptest: |
+    DISTRO_FEATURES_remove = "ptest"
+
+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

@@ -0,0 +1,26 @@
+#! /usr/bin/env python3
+
+from pathlib import Path
+import sys
+
+metaarm = Path.cwd()
+
+if metaarm.name != "meta-arm":
+    print("Not running inside meta-arm")
+    sys.exit(1)
+
+# All machine configurations
+machines = metaarm.glob("meta-*/conf/machine/*.conf")
+machines = set(p.stem for p in machines)
+
+# All ci files
+ci = metaarm.glob("ci/*.yml")
+ci = set(p.stem for p in ci)
+
+missing = machines - ci
+print(f"The following machines are missing: {', '.join(sorted(missing))}.")
+
+covered = len(machines) - len(missing)
+total = len(machines)
+percent = int(covered / total * 100)
+print(f"Coverage: {percent}%")

ci/check-warnings

@@ -0,0 +1,19 @@
+#! /bin/bash
+
+# Expects the path to a log file as $1, and if this file has any content
+# then display the contents and exit with an error code.
+
+set -e -u
+
+LOGFILE=$1
+
+LINES=$(grep --invert-match "attempting MIRRORS if available" $LOGFILE | wc -l)
+if test "$LINES" -ne 0; then
+    echo ==============================
+    echo The build had warnings/errors:
+    echo ==============================
+    cat $LOGFILE
+    exit 1
+fi
+
+exit 0

ci/clang.yml

@@ -0,0 +1,11 @@
+header:
+  version: 9
+
+repos:
+  meta-clang:
+    url: https://github.com/kraj/meta-clang
+    refspec: gatesgarth
+
+local_conf_header:
+  clang: |
+    TOOLCHAIN = "clang"

ci/corstone700-fvp.yml

@@ -0,0 +1,10 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+machine: corstone700-fvp
+
+local_conf_header:
+  image: |
+    CORE_IMAGE_EXTRA_INSTALL = "corstone700-test-app"

ci/corstone700-mps3.yml

@@ -0,0 +1,6 @@
+header:
+  version: 9
+  includes:
+    - corstone700-fvp.yml
+
+machine: corstone700-mps3

ci/external-gccarm.yml

@@ -0,0 +1,8 @@
+header:
+  version: 9
+
+local_conf_header:
+  cc: |
+    PNBLACKLIST[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

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

ci/fvp-base.yml

@@ -0,0 +1,7 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+machine: fvp-base
+

ci/gem5-arm64.yml

@@ -0,0 +1,21 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+repos:
+  meta-arm:
+    layers:
+      meta-gem5:
+
+  meta-openembedded:
+    url: https://git.openembedded.org/meta-openembedded
+    layers:
+      meta-oe:
+
+machine: gem5-arm64
+
+target:
+  - core-image-minimal
+  - perf
+  - gem5-aarch64-native

ci/get-binary-toolchains

@@ -0,0 +1,46 @@
+#!/bin/bash
+set -u
+
+HOST_ARCH=$(uname -m)
+VER="10.2-2020.11"
+
+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-a/$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-a/$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-a/$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-a/$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

@@ -0,0 +1,19 @@
+#! /bin/bash
+
+# Read a GitLab CI job name on $1 and transform it to a
+# list of Kas yaml files
+
+set -e -u
+
+# Read Job namne from $1 and split on /
+IFS=/ read -r -a PARTS<<<$1
+
+# Prefix each part with ci/
+PARTS=("${PARTS[@]/#/ci/}")
+
+# Suffix each part with .yml
+PARTS=("${PARTS[@]/%/.yml}")
+
+# Print colon-separated
+IFS=":"
+echo "${PARTS[*]}"

ci/juno.yml

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

ci/logging.yml

@@ -0,0 +1,13 @@
+# Python logging configuration to write all warnings to a separate file
+version: 1
+
+handlers:
+  warnings:
+    class: logging.FileHandler
+    level: WARNING
+    filename: warnings.log
+    formatter: BitBake.logfileFormatter
+
+loggers:
+  BitBake:
+    handlers: [warnings]

ci/meta-python.yml

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

ci/meta-zephyr.yml

@@ -0,0 +1,8 @@
+header:
+  version: 9
+  includes:
+    - meta-python.yml
+
+repos:
+  meta-zephyr:
+    url: https://git.yoctoproject.org/git/meta-zephyr

ci/musca-b1.yml

@@ -0,0 +1,11 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+    - meta-zephyr.yml
+
+machine: musca-b1
+
+target:
+  - trusted-firmware-m
+  - zephyr-philosophers

ci/musca-s1.yml

@@ -0,0 +1,10 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+    - meta-python.yml
+
+machine: musca-s1
+
+target:
+  - trusted-firmware-m

ci/musl.yml

@@ -0,0 +1,6 @@
+header:
+  version: 9
+
+local_conf_header:
+  libc: |
+    TCLIBC = "musl"

ci/n1sdp.yml

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

ci/qemuarm.yml

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

ci/qemuarm64-secureboot.yml

@@ -0,0 +1,16 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+machine: qemuarm64-secureboot
+
+local_conf_header:
+  bugs: |
+    # Only ping until errors can be resolved
+    TEST_SUITES = "ping"
+
+target:
+  - core-image-base
+  - perf
+  - optee-examples

ci/qemuarmv5.yml

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

ci/sgi575.yml

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

ci/tc0.yml

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

ci/testimage.yml

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

ci/update-repos

@@ -0,0 +1,41 @@
+#! /usr/bin/env python3
+
+# Update clones of the repositories we need in KAS_REPO_REF_DIR to speed up fetches
+
+import sys
+import os
+import subprocess
+import pathlib
+
+def repo_shortname(url):
+    # Taken from Kas (Repo.__getattr__) to ensure the logic is right
+    from urllib.parse import urlparse
+    url = urlparse(url)
+    return ('{url.netloc}{url.path}'
+            .format(url=url)
+            .replace('@', '.')
+            .replace(':', '.')
+            .replace('/', '.')
+            .replace('*', '.'))
+
+repositories = (
+    "https://git.yoctoproject.org/git/poky",
+    "https://git.openembedded.org/meta-openembedded",
+    "https://git.yoctoproject.org/git/meta-virtualization",
+    "https://git.yoctoproject.org/git/meta-zephyr",
+    "https://github.com/kraj/meta-clang",
+)
+
+if __name__ == "__main__":
+    if "KAS_REPO_REF_DIR" not in os.environ:
+        print("KAS_REPO_REF_DIR needs to be set")
+        sys.exit(1)
+
+    base_repodir = pathlib.Path(os.environ["KAS_REPO_REF_DIR"])
+
+    for repo in repositories:
+        repodir = base_repodir / repo_shortname(repo)
+        if repodir.exists():
+            subprocess.run(["git", "-C", repodir, "fetch"], check=True)
+        else:
+            subprocess.run(["git", "clone", "--bare", repo, repodir], check=True)

meta-arm-autonomy/README.md

@@ -0,0 +1,92 @@
+meta-arm-autonomy Yocto Layer
+=============================
+
+Introduction
+------------
+This layer provides an hypervisor based solution (currently based on Xen) for
+autonomous system. It contains recipes and classes to build host and guests
+systems.
+
+To start using this layer, please check the
+[Quick Start Guide](documentation/arm-autonomy-quickstart.md).
+
+Dependencies
+------------
+This layer depends on several other Yocto layers:
+* meta-openembedded (https://git.openembedded.org/meta-openembedded)
+* poky (https://git.yoctoproject.org/poky)
+* meta-virtualization (https://git.yoctoproject.org/meta-virtualization)
+
+Distribution Features
+---------------------
+This layer is adding the following Yocto DISTRO_FEATURES:
+
+* arm-autonomy-host: this feature activates functionalities required to build
+  an autonomy host system. It is doing the following:
+  - add 'xen' and 'ipv4' to DISTRO_FEATURES.
+  - add xen backend drivers to linux kernel configuration.
+  - To reduce the root filesystem image size the kernel image is not installed.
+
+* arm-autonomy-guest: this feature activates functionalities to run as guest
+  of an autonomy system. It is doing the following:
+  - add 'ipv4' to DISTRO_FEATURES.
+  - add xen frontend drivers to linux kernel configuration.
+  - add console on hvc0 during init.
+
+Bitbake variables
+-----------------
+Some recipes and classes in this layer are introducing variables which can be
+modified by the user in local.conf.
+Each recipe introducing such variables has a chapter "Bitbake parameters" in
+its documentation.
+
+Those documentation files should be checked for variables:
+- [xen-devicetree](documentation/xen-devicetree.md)
+- [xenguest-manager](documentation/xenguest-manager.md)
+- [xenguest-network-bridge](documentation/xenguest-network-bridge.md)
+
+BSPs
+----
+This layer is adding the following machines:
+
+* arm64-autonomy-guest: this machines creates a minimal BSP suitable to be used
+  as an autonomy guest. It is in fact only activating ARM64 architecture and
+  SMP in the linux kernel and is enabling the DISTRO_FEATURE
+  arm-autonomy-guest.
+
+Images
+------
+This layer is adding the following images:
+
+* arm-autonomy-host-image-minimal: this image includes all elements required
+  to create a minimal arm-autonomy-host system. This includes xen and tools to
+  manage xen guests. This image depends on 'arm-autonomy-host' distribution
+  feature.
+
+Recipes and classes
+-------------------
+This layer is adding the following recipes and classes:
+
+* [xen-devicetree](documentation/xen-devicetree.md): this is a recipe to modify
+  a device tree blob to add information required to boot xen and a Dom0 linux.
+
+* [xenguest-mkimage](documentation/xenguest-mkimage.md): this is a tool to
+  create and modify images to be used as Xen guests.
+
+* [xenguest-manager](documentation/xenguest-manager.md): this is a tool to
+  create/remove/start/stop xen guest generated using xenguest-mkimage.
+
+* [xenguest-network-bridge](documentation/xenguest-network-bridge.md): this
+  recipe add tools and init scripts to create a bridge connected to the
+  external network on the host and allow guests to be connected to it.
+
+Contributing
+------------
+This project has not put in place a process for contributions currently. If you
+would like to contribute, please contact the maintainers
+
+
+Maintainer(s)
+-------------
+* Diego Sueiro <diego.sueiro@arm.com>
+* Bertrand Marquis <bertrand.marquis@arm.com>

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,114 @@
+# This class must be used to extend the xenguest image
+# It provides variables to add init scripts, a dtb, xen files or disk files.
+#
+# The class is extending deploy function so you recipe must inherit deploy and
+# have a do_deploy function (even if it is empty)
+
+# Use standard xenguest-image
+inherit xenguest-image
+
+# Add a DTB file for the guest
+# Only one file should be added, if this is set multiple times or in several
+# recipes, the last recipe setting it will prevail.
+XENGUEST_EXTRA_DTB ??= ""
+
+# Add a ramdisk file for the guest
+# Only one file should be added, if this is set multiple times or in several
+# recipes, the last recipe setting it will prevail.
+XENGUEST_EXTRA_RAMDISK ??= ""
+
+# Append something to the guest xen configuration
+# All files here will be merged together in the final xen configuration
+# This can contain several files or be used in several recipes
+XENGUEST_EXTRA_XENCONFIG ??= ""
+
+# Add a xenguest init, init-pre or init-post script
+XENGUEST_EXTRA_INIT_PRE ??= ""
+XENGUEST_EXTRA_INIT ??= ""
+XENGUEST_EXTRA_INIT_POST ??= ""
+
+# Add xenguest files, (to be used in extra xen config for example)
+# several files may be added, space separated, the path will be kept on the
+# generated xenguest image (if dir1/file1 is added, it can be used as
+# dir1/file1 file in the xen configuration).
+XENGUEST_EXTRA_FILES ??= ""
+
+# Add xenguest disk files (to be used as disk partition content)
+# several files may be added, space separated, the path will be kept on the
+# generated xenguest image (if dir1/file1 is added, it can be used as
+# dir1/file1 file in the disk content parameters).
+XENGUEST_EXTRA_DISK_FILES ??= ""
+
+do_deploy_append() {
+    if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
+        -z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
+        die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
+    fi
+    rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+    mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+
+    if [ -n "${XENGUEST_EXTRA_DTB}" ]; then
+        if [ ! -f ${XENGUEST_EXTRA_DTB} ]; then
+            die "xenguest-image: DTB file ${XENGUEST_EXTRA_DTB} does not exist"
+        fi
+        call_xenguest_mkimage partial --xen-device-tree=${XENGUEST_EXTRA_DTB}
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_RAMDISK}" ]; then
+        if [ ! -f ${XENGUEST_EXTRA_RAMDISK} ]; then
+            die "xenguest-image: DTB file ${XENGUEST_EXTRA_RAMDISK} does not exist"
+        fi
+        call_xenguest_mkimage partial --xen-ramdisk=${XENGUEST_EXTRA_RAMDISK}
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_XENCONFIG}" ]; then
+        for f in ${XENGUEST_EXTRA_XENCONFIG}; do
+            if [ ! -f $f ]; then
+                die "xenguest-image: Xen config $f does not exist"
+            fi
+            call_xenguest_mkimage partial --xen-append=$f
+        done
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_INIT_PRE}" ]; then
+        if [ ! -f ${XENGUEST_EXTRA_INIT_PRE} ]; then
+            die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT_PRE} does not exist"
+        fi
+        call_xenguest_mkimage partial --init-pre=${XENGUEST_EXTRA_INIT_PRE}
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_INIT}" ]; then
+        if [ ! -f ${XENGUEST_EXTRA_INIT} ]; then
+            die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT} does not exist"
+        fi
+        call_xenguest_mkimage partial --init-script=${XENGUEST_EXTRA_INIT}
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_INIT_POST}" ]; then
+        if [ ! -f ${XENGUEST_EXTRA_INIT_POST} ]; then
+            die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT_POST} does not exist"
+        fi
+        call_xenguest_mkimage partial --init-post=${XENGUEST_EXTRA_INIT_POST}
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_FILES}" ]; then
+        for f in ${XENGUEST_EXTRA_FILES}; do
+            if [ ! -f $f ]; then
+                die "xenguest-image: Xen file $f does not exist"
+            fi
+            call_xenguest_mkimage partial --xen-add-file=$f
+        done
+    fi
+
+    if [ -n "${XENGUEST_EXTRA_DISK_FILES}" ]; then
+        for f in ${XENGUEST_EXTRA_DISK_FILES}; do
+            if [ ! -f $f ]; then
+                die "xenguest-image: Disk file $f does not exist"
+            fi
+            call_xenguest_mkimage partial --disk-add-file=$f
+        done
+    fi
+}
+# Need to have xenguest-image tool
+do_deploy[depends] += "xenguest-base-image:do_deploy"
+

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

@@ -0,0 +1,199 @@
+# 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_TYPE can be set to "bridge", "nat" or "none".
+# The "bridge" type will share the physical eth interface from dom0 with the
+# domU. This will allow the domU to have access to the external network.
+# The "nat" type will setup a virtual network between dom0 and domU and also
+# configure and run the kea dhcp4 server on dom0 to serve the domU.
+# The "none" type will not affect any networking setting between on dom0 and
+# domU.
+XENGUEST_IMAGE_NETWORK_TYPE ??= "bridge"
+
+# Sub-directory in wich the guest is created. This is create in deploy as a
+# subdirectory and must be coherent between all components using this class so
+# it must only be modified from local.conf if needed
+XENGUEST_IMAGE_DEPLOY_SUBDIR ?= "xenguest"
+
+# Directory in which the xenguest should be deployed
+# a sub-directory named ${XENGUEST_IMAGE_DEPLOY_SUBDIR} will be created there.
+# This should be set to:
+# - ${DEPLOYDIR} (default) if creating or extending the xenguest for a normal
+#   recipe.
+# - something in ${WORKDIR} if you need to clone and manipulate an image
+XENGUEST_IMAGE_DEPLOY_DIR ??= "${DEPLOYDIR}"
+
+#
+# Wrapper to call xenguest-mkimage
+# It is using XENGUEST_IMAGE_DEPLOY_DIR and XENGUEST_IMAGE_DEPLOY_SUBDIR
+# to find the image to operate on
+#
+# Usage: call_xenguest_mkimage [operation] [args]
+call_xenguest_mkimage() {
+    local cmd="${1}"
+    local img="${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}"
+    shift
+
+    echo "xenguest-mkimage $cmd $img $@"
+    xenguest-mkimage $cmd $img $@
+}
+
+#
+# Create an initial xenguest image.
+# This is a task which must be added in a recipe inheriting deploy
+# It is using XENGUEST_IMAGE_MEMORY_SIZE, XENGUEST_IMAGE_NUM_VCPUS,
+#  XENGUEST_IMAGE_AUTOBOOT, XENGUEST_IMAGE_ROOT, XENGUEST_IMAGE_EXTRA_CMD,
+#  XENGUEST_IMAGE_CMDLINE, XENGUEST_IMAGE_DISK_SIZE and
+#  XENGUEST_IMAGE_DISK_PARTITIONS to customize the initial guest
+#
+xenguest_image_create() {
+    if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
+        -z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
+        die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
+    fi
+
+    rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+
+    mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+
+    # Create the image
+    call_xenguest_mkimage create --xen-memory=${XENGUEST_IMAGE_MEMORY_SIZE} \
+        --xen-vcpus=${XENGUEST_IMAGE_NUM_VCPUS} \
+        --xen-root=${XENGUEST_IMAGE_ROOT} \
+        ${XENGUEST_IMAGE_EXTRA_CMD}
+
+    # add command line
+    if [ -n "${XENGUEST_IMAGE_CMDLINE}" ]; then
+        call_xenguest_mkimage update --xen-clean-extra
+        for arg in ${XENGUEST_IMAGE_CMDLINE}; do
+            call_xenguest_mkimage update --xen-extra=$arg
+        done
+    fi
+
+    # create disk if needed
+    disksize="${XENGUEST_IMAGE_DISK_SIZE}"
+    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 [ -n "${XENGUEST_IMAGE_NETWORK_TYPE}" ]; then
+        call_xenguest_mkimage update --set-param=XENGUEST_NETWORK_TYPE="${XENGUEST_IMAGE_NETWORK_TYPE}"
+    else
+        call_xenguest_mkimage update --set-param=XENGUEST_NETWORK_TYPE="none"
+    fi
+}
+
+#
+# Clone the current xenguest from deploy to manipulate it locally
+# This is required if you need to change things before packing an image
+# To set the local directory where to clone you must set
+# XENGUEST_IMAGE_DEPLOY_DIR if you don't want to use do_deploy to modify the
+# image
+#
+xenguest_image_clone() {
+    if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
+        -z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
+        die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
+    fi
+
+    if [ ! -f ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}/guest.cfg ]; then
+        die "xenguest-image: ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR} does not contain a valid guest"
+    fi
+
+    rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+    mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}
+    cp -rf ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR} \
+        ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
+}
+
+# Helper function to retrieve rootfs file if present in one partition
+# This can return an empty string or rootfs.tar[.COMP]
+def xenguest_image_rootfs_file(d):
+    disksize = d.getVar('XENGUEST_IMAGE_DISK_SIZE')
+    # if disksize is 0, we don't create anything
+    if not disksize or disksize == '0':
+        return ""
+    # Find first partition with file=rootfs.tar*
+    partlist = d.getVar('XENGUEST_IMAGE_DISK_PARTITIONS')
+    if partlist:
+        for partdesc in partlist.split():
+            partelems = partdesc.split(':', 3)
+            if partelems[3]:
+                if partelems[3].startswith('rootfs.tar'):
+                    return partelems[3]
+    return ""

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

@@ -0,0 +1,15 @@
+# This files is added when DISTRO_FEATURES contains arm-autonomy-guest
+
+# We need to have ipv4 activated
+DISTRO_FEATURES_append = " ipv4"
+
+# Build a xenguest type image
+IMAGE_CLASSES += "image_types_xenguest"
+IMAGE_FSTYPES += "xenguest"
+
+# xenguest kernel extension to handle initramfs
+KERNEL_CLASSES += "kernel-xenguest"
+
+IMAGE_INSTALL_append = "${@bb.utils.contains('DISTRO_FEATURES', 'docker', \
+                        ' packagegroup-docker-runtime-minimal', \
+                        '', d)}"

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

@@ -0,0 +1,21 @@
+# This files is added when DISTRO_FEATURES contains arm-autonomy-host
+
+# We need to have xen and ipv4 activated
+DISTRO_FEATURES_append = " xen ipv4"
+DISTRO_FEATURES_NATIVE_append = " arm-autonomy-host"
+
+# Don't include kernels in standard images when building arm-autonomy-host
+# If the kernel image is needed in the rootfs the following should be set from
+# a bbappend: RDEPENDS_${KERNEL_PACKAGE_NAME}-base = "${KERNEL_PACKAGE_NAME}-image"
+RDEPENDS_${KERNEL_PACKAGE_NAME}-base ?= ""
+
+# Require extra machine specific settings from meta-arm-bsp dynamic-layers only
+# if meta-arm-bsp is in the bblayers.conf
+# Directory for meta-arm-autonomy/dynamic-layers/meta-arm-bsp machine extra settings
+ARM_AUTONOMY_ARM_BSP_DYNAMIC_EXTRA_CFGDIR = "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/conf/machine"
+ARM_AUTONOMY_MACHINE_EXTRA_REQUIRE ?= \
+"${ARM_AUTONOMY_ARM_BSP_DYNAMIC_EXTRA_CFGDIR}/arm-autonomy-machine-extra-settings.inc"
+
+require ${@bb.utils.contains('BBFILE_COLLECTIONS', 'meta-arm-bsp', \
+                             '${ARM_AUTONOMY_MACHINE_EXTRA_REQUIRE}' , \
+                             '', d)}

meta-arm-autonomy/conf/layer.conf

@@ -0,0 +1,39 @@
+# 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 = "gatesgarth"
+
+# We don't activate virtualization feature from meta-virtualization as it
+# brings in lots of stuff we don't need. We need to disable the sanity check
+# otherwise the user will see a warning on each build.
+SKIP_META_VIRT_SANITY_CHECK = "1"
+
+ARM_AUTONOMY_LAYERDIR := "${LAYERDIR}"
+# Directory of our distro config files
+ARM_AUTONOMY_DISTRO_CFGDIR = "${ARM_AUTONOMY_LAYERDIR}/conf/distro/include/"
+
+# Add class to handle arm-autonomy distro extensions
+USER_CLASSES_append = " arm-autonomy-features"
+
+BBFILES_DYNAMIC += " \
+    meta-arm-bsp:${LAYERDIR}/dynamic-layers/meta-arm-bsp/*/*/*.bbappend \
+    meta-gem5:${LAYERDIR}/dynamic-layers/meta-gem5/*/*/*.bbappend \
+"
+# Root directory for the meta-arm-autonomy/dynamic-layers/meta-arm-bsp
+ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR = "${ARM_AUTONOMY_LAYERDIR}/dynamic-layers/meta-arm-bsp"

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-multiconfig.md

@@ -0,0 +1,195 @@
+arm-autonomy Multiconfig Build Environment Instructions
+==================
+
+This documentation explains how to simplify the process of building hosts
+and guests in a single bitbake command, rather than in seperate build
+folders. You can read more about multiconfig in the bitbake documentation:
+
+ - [bitbake user manual](https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html)
+
+To achieve a multiconfig build, a number of different config files need to
+be created in a single build directory.
+
+Create a new project
+----------------
+
+Before you start, you will need to follow the instructions in
+"Create a project" from the quickstart guide, to create a new project
+directory with
+  ```
+  oe-init-build-env my-mc-project
+  ```
+Ensure it has all the required layers in bblayers.conf as listed in
+`arm-autonomy-quickstart.md`. The result should be a directory containing:
+
+```
+-- conf
+ | -- bblayers.conf
+ | -- local.conf
+ | -- templateconf.cfg
+```
+
+Add multiconfig
+----------------
+
+Here are the steps required to make the project build both the host and any
+number of guests as required.
+
+1. Create a new directory under `conf/` named `multiconfig/`
+
+2. Create two new files in this directory:
+`multiconfig/host.conf`
+`multiconfig/guest.conf`
+These files will contain any configurations that a specific to either the
+host or the guest
+
+```
+-- conf
+ | -- bblayers.conf
+ | -- local.conf
+ | -- templateconf.cfg
+ | -- multiconfig
+    | -- host.conf
+    | -- guest.conf
+```
+
+3. In `local.conf` the following config variables must be added:
+
+```
+MACHINE ?= "fvp-base"
+
+# ---Guest Config Start--- #
+MC_GUEST = "guest"
+
+MC_GUEST_NAME = "guest1"
+
+MC_GUEST_IMAGERECIPE = "core-image-minimal"
+MC_GUEST_MACHINE = "arm64-autonomy-guest"
+
+MC_GUEST_INITRAMFS_IMAGE_BUNDLE ?= ""
+MC_GUEST_INITRAMFS_IMAGE ?= ""
+
+# Uncomment for initramfs
+#MC_GUEST_INITRAMFS_IMAGE_BUNDLE = "1"
+#MC_GUEST_INITRAMFS_IMAGE = "${MC_GUEST_IMAGERECIPE}"
+
+# These variables are set automatically, don't edit them!
+MC_GUEST_FILENAME_PREFIX = "${@ 'Image-initramfs' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else '${MC_GUEST_IMAGERECIPE}' }"
+
+MC_GUEST_FILENAME = "${MC_GUEST_FILENAME_PREFIX}-${MC_GUEST_MACHINE}.xenguest"
+
+MC_GUEST_DEP = "${@ 'virtual/kernel:do_deploy' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else '${MC_GUEST_IMAGERECIPE}:do_image_complete'}"
+
+MC_DOIMAGE_MCDEPENDS += "mc:${MC_HOST}:${MC_GUEST}:${MC_GUEST_DEP} "
+
+BBMULTICONFIG += "${MC_GUEST} "
+
+ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS += "file://${TOPDIR}/${MC_GUEST}/deploy/images/${MC_GUEST_MACHINE}/${MC_GUEST_FILENAME};guestname=${MC_GUEST_NAME} "
+# ---Guest Config End--- #
+
+# ---Host Config Start--- #
+MC_HOST = "host"
+
+BBMULTICONFIG += "${MC_HOST} "
+# ---Host Config End--- #
+```
+
+These variables will be used in both of the multiconf files. `MC_HOST` and
+`MC_GUEST` should not be altered without renaming the conf files, but most
+`MC_GUEST_*` variables can be customised if you desire.
+
+4. Next set the contents of `multiconfig/guest.conf`:
+
+```
+TMPDIR = "${TOPDIR}/${MC_GUEST}"
+
+MACHINE = "${MC_GUEST_MACHINE}"
+DISTRO_FEATURES += " arm-autonomy-guest"
+
+INITRAMFS_IMAGE_BUNDLE = "${MC_GUEST_INITRAMFS_IMAGE_BUNDLE}"
+INITRAMFS_IMAGE = "${MC_GUEST_INITRAMFS_IMAGE}"
+
+IMAGE_FSTYPES += "${@ 'cpio' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else ''}"
+
+# ANY OTHER GUEST CONFIG
+```
+
+This contents shouldn't be changed directly, rather change the equivalent
+config in local.conf. You can append any other config desired for the
+guest at this point, for example `XENGUEST_IMAGE_DISK_SIZE`
+
+Make sure not to change `${DEPLOY_DIR_IMAGE}` to anything other than
+`${TMPDIR}/deploy/images`, as this is assumed by local.conf.
+
+5. Lastly set the contents of `multiconfig/host.conf`:
+
+```
+TMPDIR = "${TOPDIR}/${MC_HOST}"
+
+DISTRO_FEATURES += " arm-autonomy-host"
+```
+
+Building the image
+----------------
+
+To build the multiconfig image the command is:
+```
+bitbake mc:host:arm-autonomy-host-image-minimal
+```
+
+You should see that this triggers guest tasks to be built in
+parallel. Once the build completes the guest will already be in the
+rootfs of the host thanks to `ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUEST`
+
+The deployed image including the guest will be in `host/deploy/images/`
+
+
+Multiple Guests
+----------------
+
+To have multiple guests with the same config the line which appends to
+`ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUEST` just needs to be duplicated with
+a different guestname.
+
+To have different config for each guest, each will need its own config
+file similar to guest.conf, ensuring TMPDIR is set to a different path,
+and everything between `---Guest Config Start---` and
+`---Guest Config End---` will need to be duplicated.
+
+Any copies of variables that start `MC_GUEST` must be altered to avoid
+collisions (e.g. `MC_GUEST_2_*`), and the name of the conf file must also
+be added to BBMULTICONFIG.
+
+
+Guest with provisioned disk
+----------------
+
+To add guest rootfs partition to host wic image,
+set `AUTONOMY_HOST_EXTRA_PARTITION` with proper wks partition entry, e.g:
+
+```
+AUTONOMY_HOST_EXTRA_PARTITION = "part --label provisioned-guest --source rawcopy --fstype=ext4 --ondisk sda --align 1024 \
+--sourceparams=file=${TOPDIR}/${MC_GUEST}/deploy/images/${MC_GUEST_MACHINE}/${MC_GUEST_FILENAME_PREFIX}-${MC_GUEST_MACHINE}.ext4"
+```
+
+inside host.conf file.
+
+The rest of the configuration has to be appended to guest.conf file:
+
+```
+XENGUEST_IMAGE_DISK_SIZE = "0"
+XENGUEST_IMAGE_SRC_URI_XEN_CONFIG = "file://\${TOPDIR}/path/to/rootdisk.cfg"
+XENGUEST_IMAGE_DISK_DEVICE = "_GUEST_DISK_DEVICE_"
+XENGUEST_IMAGE_ROOT = "/dev/xvda"
+IMAGE_ROOTFS_SIZE = "102400"
+IMAGE_FSTYPES = "ext4"
+```
+
+content of rootdisk.cfg"
+
+```
+disk = ["phy:_GUEST_DISK_DEVICE_,xvda,w"]
+```
+
+`_GUEST_DISK_DEVICE_` should be substituted with `/dev/sdaX`,
+according to wks file.

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

@@ -0,0 +1,236 @@
+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-arm/meta-arm $LAYERDIR_BASE/meta-arm/meta-arm-toolchain \
+   $LAYERDIR_BASE/meta-arm/meta-arm-bsp $LAYERDIR_BASE/meta-arm/meta-arm-autonomy \
+  ```
+
+  Example of a `conf/bblayers.conf`:
+  ```
+  BBLAYERS ?= " \
+    /home/user/arm-autonomy/poky/meta \
+    /home/user/arm-autonomy/poky/meta-poky \
+    /home/user/arm-autonomy/poky/meta-yocto-bsp \
+    /home/user/arm-autonomy/meta-openembedded/meta-oe \
+    /home/user/arm-autonomy/meta-openembedded/meta-python \
+    /home/user/arm-autonomy/meta-openembedded/meta-filesystems \
+    /home/user/arm-autonomy/meta-openembedded/meta-networking \
+    /home/user/arm-autonomy/meta-virtualization \
+    /home/user/arm-autonomy/meta-arm/meta-arm \
+    /home/user/arm-autonomy/meta-arm/meta-arm-toolchain \
+    /home/user/arm-autonomy/meta-arm/meta-arm-bsp \
+    /home/user/arm-autonomy/meta-arm/meta-arm-autonomy \
+    "
+  ```
+
+  Be aware that changing the order may break some dependencies if editing the
+  config file manually.
+
+Those steps will have to be done for each project you will have to create.
+
+Host project
+------------
+The host project will build Xen and the Dom0 Linux. It will be the only project
+that will be specific to the board (MACHINE) you will be running on.
+
+To create a host project:
+1. Follow the steps of "Create a project"
+
+2. Add the layers in `bblayers.conf` required to build a Yocto project for the
+   board you want to use.
+   For example to use Arm FVP Base emulator, add `meta-arm/meta-arm` and
+   `meta-arm/meta-arm-bsp`.
+
+3. edit conf/local.conf to add `arm-autonomy-host` to the DISTRO_FEATURES and
+   set MACHINE to the board you want to use.
+   For example, add the following lines:
+  ```
+  MACHINE = "fvp-base"
+  DISTRO_FEATURES += "arm-autonomy-host"
+  ```
+
+4. build the image using `bitbake arm-autonomy-host-image-minimal`
+
+The project will generate a Linux kernel, a root filesystem, a Xen binary and
+a DTB modified to include the required entries to boot Xen and Linux as Dom0
+(this DTB has the extension `-xen.dtb`).
+
+To boot the system using an u-boot base board you will need to:
+- Load the kernel (by default at 0x80080000 unless you modify
+  XEN_DEVICETREE_DOM0_ADDR value)
+- Load the xen device tree (for example at 0x83000000)
+- Load the xen-efi binary (for example at 0x84000000)
+- run using `booti 0x84000000 - 0x83000000`
+
+In this example the addresses might need to be adapted depending on your board.
+
+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.
+
+The guest can also be built as a 'multiconfig' sub project of the host, see
+`meta-arm-autonomy/documentation/arm-autonomy-multiconfig.md` for more information
+
+Include guests directly in the host image
+-----------------------------------------
+The layer provides a way to directly include in the host project one or several
+images generated by guest projects.
+
+To use this feature, you must edit your host project `local.conf` file and
+add set ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS to the list of xenguest images
+you want to include in your host. Each xenguest image must be given using a
+full path to it.
+For example:
+```
+ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS = "/home/user/guest-project/tmp/deploy/images/arm64-autonomy-guest/core-image-minimal-arm64-autonomy-guest.xenguest;guestname=myguest"
+```
+This will add the guest and name it `myguest` on the host project image and
+the xenguest-manager will automatically boot it during startup.
+
+Add support for your board
+--------------------------
+Most of arm-autonomy layer is board independent but some functionalities
+might need to be customized for your board:
+
+### Add the kernel configuration for the host
+The layer is using KERNEL_FEATURES to add drivers required to be a Xen Dom0
+system.
+Depending on the kernel used by your BSP and how it is configured you might
+need to add the required drivers to your kernel configuration:
+- if KERNEL_FEATURES system is supported by your kernel, make sure that the
+file `recipes-kernel/linux/linux-arm-autonomy.inc` from the layer is included
+by your kernel recipe.
+- if it is not supported, you must add the proper drivers inside your kernel
+(modules are possible but they must be loaded before xenguest-manager is
+started). You can find the complete list of the kernel configuration elements
+required in `recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-host.cfg`.
+
+### Define the drive and partition to use for the LVM volume
+The xenguest-manager is creating disk hard drive using LVM on an empty
+partition. The default value is set to use /dev/sda2.
+You can change this for your board by setting XENGUEST_MANAGER_VOLUME_DEVICE.
+
+Check `recipes-extended/xenguest/xenguest-manager.bbappend` for examples.
+
+Please also read xenguest-manager.md.
+
+### Define the interface to add to xenguest network bridge
+xenguest-network bridge is creating a bridge on the host and adds network
+interfaces to it so that guest connected to it have access to external network.
+By default `eth0` is set as the list of interfaces to be added to the bridge.
+Depending on your board or use case you might want to use an other interface
+or use multiple interfaces.
+You can change this for your board by setting XENGUEST_NETWORK_BRIDGE_MEMBERS.
+
+Check `recipes-extended/xenguest/xenguest-network-bridge.bbappend` for
+exmaples.
+
+Please also read xenguest-network-bridge.md.
+
+### Define the network configuration of the xenguest network bridge
+xenguest network bridge is putting the host network interfaces in a bridge
+and is configuring it by default to use dhcp.
+If you need a different type of configuration you can set
+XENGUEST_NETWORK_BRIDGE_CONFIG in a xenguest-network-bridge.bbappend to use
+a different file.
+The recipe will look for the file in ${WORKDIR} so you will need to add it to
+SRC_URI in your bbappend.
+The recipe will also substitute `###BRIDGE_NAME###` with the bridge name
+configured in ${XENGUEST_NETWORK_BRIDGE_NAME}.
+
+You can find an example configuration file in
+`recipes-extended/xenguest/files/xenguest-network-bridge-dhcp.cfg.in`.
+
+Please also read xenguest-network-bridge.md.
+
+### Customize Dom0 and Xen boot arguments for you board
+xen-devicetree is writting inside the generated DTB Xen and Linux boot
+arguments as long as the address where Dom0 Linux kernel can be found.
+You might need to have different values for your board or depending on your
+use case.
+
+You can find examples to customize this in
+`recipes-extended/xen-devicetree/xen-devicetree.bbappend`.
+
+Please also read xen-devicetree.md.
+

meta-arm-autonomy/documentation/n1sdp-image-customization.md

@@ -0,0 +1,29 @@
+Customizing Arm Autonomy Host image layout for N1SDP
+====================================================
+
+When buiding with `DISTRO_FEATURES += "arm-autonomy-host"` the user can
+perform a couple of customizations in the generated wic image:
+
+1. Set the guest partition size (default: 4iG) via `GUEST_PART_SIZE` and
+   `GUEST_PART_SIZE_UNIT` (M or G) variables to be set in any conf file. The
+   value of these variables should be aligned with the sum of all
+   XENGUEST_IMAGE_DISK_SIZE set for the guests. By default, LVM2 metadata is
+   1 MiB per physical volume, hence it needs to be taken into account when
+   setting GUEST_PART_SIZE.
+
+2. The wic image partition layout and contents with a custom wks file via
+   `ARM_AUTONOMY_WKS_FILE` variable (default:
+   arm-autonomy-n1sdp-efidisk.wks.in which is affected by GUEST_PART_SIZE,
+   GUEST_PART_SIZE_UNIT and GRUB_CFG_FILE variables).
+
+3. Custom grub.cfg file via `GRUB_CFG_FILE` (default:
+   arm-autonomy-n1sdp-grub.cfg) variable to be set in any conf file. The full
+   path or relative to `ARM_AUTONOMY_WKS_FILE` should be set.
+
+The `arm-autonomy-n1sdp-efidisk.wks.in` and `arm-autonomy-n1sdp-grub.cfg` files
+are located at `meta-arm-autonomy/dynamic-layers/meta-arm-bsp/wic`.
+
+Other variables can also be custmized to set what files need to be included
+in the wic image boot partition. Please refer to
+`meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/n1sdp-extra-settings.inc`
+for more details.

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,101 @@
+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".
+
+Init scripts
+------------
+
+Shell scripts can be executed on the host when a guest is started. Depending on
+when the script should be executed it should be installed in a different
+directory on the target:
+
+- /etc/xenguest/init.pre  : Executed first, prior to guest creation
+
+- /etc/xenguest/init.d    : Executed after guest creation, but before it is started
+
+- /etc/xenguest/init.post : Executed after starting the guest
+
+Inside the directory, scripts will be executed in alphabetical order.
+
+Since these scripts are sourced by xenguest-manager they can acccess functions
+and variables from the parent file's scope, including:
+
+- ${guestname}    : The name of the guest being created
+
+- ${guestdir}     : The path to the guest directory
+
+- ${guestcfgfile} : The name of the config file for the starting guest
+
+- ${LOGFILE}      : The file to append any logging to, e.g.
+                     echo "Hello, World" >> ${LOGFILE}
+
+Sourcing also allows the script to access params.cfg.
+
+
+An example of how to create the directory and install an init shell script can
+be found in:
+  recipes-extended/xenguest/xenguest-network.bb
+Where network-bridge.sh is installed from network-bridge.sh.in

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

@@ -0,0 +1,121 @@
+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.
+- --xen-ramdisk=FILE: add ramdisk FILE as guest ramdisk. 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.md

@@ -0,0 +1,80 @@
+Xenguest Network
+================
+
+Introduction
+------------
+
+The xenguest-network package is primarly creating a network bridge to share
+the host eth physical interfaces with the guests virtual interfaces (vif).
+This way the guests can have access to the external network.
+
+At the moment 3 types of network arrangements are provided:
+
+- Bridge: where the guest vif is added to the created bridge interface;
+
+- NAT: where a private subnet is created for the guest,
+  a kea dhcp4 server is started on the host to serve the guest
+  and the proper iptables rules are created
+  to allow the guest to access the external network;
+
+- None: the guest vif is not connected to the bridge.
+
+Usage
+-----
+
+On the host project the package xenguest-network must be included in your
+image, and on the guest project the XENGUEST_NETWORK_TYPE needs to be set to
+"bridge", "nat" or "none".
+
+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
+or xenguest-network.bbappend, 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 the
+  physical network interfaces that are added to the bridge when it is created
+  on the host during init.
+  By default no physical interfaces are added.
+
+- 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_TYPE: This variable can be set to "bridge" (default),
+  "nat" or "none".
+  The **bridge** type will add the domU vif interface to a bridge which also
+  contains the dom0 physical interface giving the guest direct access to the
+  external network.
+  The **nat** type will setup a private network between dom0 and domU, setup
+  the appropriate routing table, configure and run the kea dhcp4 server
+  on dom0 to serve the domU and apply the iptables rules to allow the guest
+  to acess the external network. The kea dhcp4 server configuration for
+  the guest can be customised by replacing the
+  "meta-arm-autonomy/recipes-extended/xenguest/files/kea-subnet4.json" file
+  in a xenguest-network.bbappend. The kea-subnet4.json file is installed in
+  the xenguest image and copied to
+  "/etc/xenguest/guests/${guestname}/files/kea-subnet4.json" when the guest
+  image is created. It will be consumed by the
+  "/etc/xen/scripts/vif-post.d/00-vif-xenguest.hook" script which is called by
+  "/etc/xen/scripts/vif-nat" script when starting/stopping the xenguest.
+  After guest start, "/etc/xenguest/init.post/xenguest-network-init-post.sh"
+  script is called to reload kea dhcp4 server with updated configuration,
+  after virtual network interface is ready.
+  In the guest project, the NAT port forward can be customised by changing
+  the XENGUEST_IMAGE_HOST_PORT (default: "1000 + ${domid}") and
+  XENGUEST_IMAGE_GUEST_PORT (default: "22") variables in local.conf or
+  xenguest-base-image.bbappend. This configuration is implemented and installed
+  in "/etc/xenguest/guests/${guestname}/files/00-xenguest-nat-port-forward.hook"
+  script which is called by "/etc/xen/scripts/vif-post.d/00-vif-xenguest.hook".
+  The **none** type will not affect any networking setting between on dom0 and
+  domU.

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/arm-autonomy-machine-extra-settings.inc

@@ -0,0 +1,7 @@
+# Require extra machine specific settings
+ARM_BSP_DYN_MACHINE_EXTRA_REQUIRE ?= ""
+ARM_BSP_DYN_MACHINE_EXTRA_REQUIRE_n1sdp = "n1sdp-extra-settings.inc"
+ARM_BSP_DYN_MACHINE_EXTRA_REQUIRE_fvp-base = "fvp-base-extra-settings.inc"
+ARM_BSP_DYN_MACHINE_EXTRA_REQUIRE_juno = "juno-extra-settings.inc"
+
+require ${ARM_BSP_DYN_MACHINE_EXTRA_REQUIRE}

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/fvp-base-extra-settings.inc

@@ -0,0 +1,7 @@
+# Extra machine settings for fvp-base
+
+# FVP uses vda as hard drive and partition 2 is the
+# default rootfs, so use vda3 for guest lvm
+XENGUEST_MANAGER_VOLUME_DEVICE ?= "/dev/vda3"
+
+XENGUEST_NETWORK_BRIDGE_MEMBERS ?= "eth0"

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/juno-extra-settings.inc

@@ -0,0 +1,26 @@
+# Extra machine settings for juno
+KERNEL_ALT_IMAGETYPE = "Image.lzma"
+
+# Juno board has 2 network interfaces, add both of them to the bridge
+XENGUEST_NETWORK_BRIDGE_MEMBERS ?= "eth0 eth1"
+XEN_DEVICETREE_DOM0_SIZE ?= "0x02400000"
+
+# We need to extend the wks search path to be able to find the wks file set in
+# ARM_AUTONOMY_WKS_FILE.
+WKS_SEARCH_PATH_prepend := "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic:"
+
+ARM_AUTONOMY_WKS_FILE ?= "arm-autonomy-juno-disk.wks.in"
+# set wks file only if INITRAMFS_IMAGE_BUNDLE is not set
+WKS_FILE = "${@bb.utils.contains('INITRAMFS_IMAGE_BUNDLE', '1', '',\
+                                 '${ARM_AUTONOMY_WKS_FILE}', d)}"
+
+# Set the wks guest partition size and unit. It must be aligned with the sum of
+# all XENGUEST_IMAGE_DISK_SIZE set for the guests. By default, LVM2 metadata is
+# 1 MiB per physical volume, hence it needs to be taken into account when
+# setting GUEST_PART_SIZE. The XENGUEST_IMAGE_DISK_SIZE default value is 4GiB.
+GUEST_PART_SIZE ?= "4097"
+GUEST_PART_SIZE_UNIT ?= "M"
+
+# set wic image type only if INITRAMFS_IMAGE_BUNDLE is not set
+IMAGE_FSTYPES += "${@bb.utils.contains('INITRAMFS_IMAGE_BUNDLE', '1', '',\
+                                       'wic wic.gz wic.bmap', d)}"

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/n1sdp-extra-settings.inc

@@ -0,0 +1,40 @@
+# Extra machine settings for n1sdp
+
+# We need to extent the wks search path to be able to find the wks file set in
+# ARM_AUTONOMY_WKS_FILE.
+WKS_SEARCH_PATH_prepend := "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic:"
+
+ARM_AUTONOMY_WKS_FILE ?= "arm-autonomy-n1sdp-efidisk.wks.in"
+WKS_FILE = "${ARM_AUTONOMY_WKS_FILE}"
+
+# Set the wks guest partition size and unit. It must be aligned with the sum of
+# all XENGUEST_IMAGE_DISK_SIZE set for the guests. By default, LVM2 metadata is
+# 1 MiB per physical volume, hence it needs to be taken into account when
+# setting GUEST_PART_SIZE. The XENGUEST_IMAGE_DISK_SIZE default value is 4GiB.
+GUEST_PART_SIZE ?= "4097"
+GUEST_PART_SIZE_UNIT ?= "M"
+
+# The GRUB_CFG_FILE affects arm-autonomy-n1sdp-efidisk.wks.in file
+GRUB_CFG_FILE ?= "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic/arm-autonomy-n1sdp-grub.cfg"
+
+# From arm-autonomy-n1sdp-efidisk.wks.in, the /boot partition is /dev/sda1, and
+# the "/" partition is /dev/sda2.
+XENGUEST_MANAGER_VOLUME_DEVICE ?= "/dev/sda3"
+
+XENGUEST_NETWORK_BRIDGE_MEMBERS ?= "eth0"
+
+# The XEN_DEVICETREE_DEPEND and XEN_DEVICETREE_DTBS variables aftect the
+# xen-devicetree.bb recipe
+XEN_DEVICETREE_DEPEND = "virtual/trusted-firmware-a:do_deploy"
+XEN_DEVICETREE_DTBS ?= "n1sdp-single-chip.dtb"
+# XEN_MOD_DEVICETREE_DTBS are the generated devicetrees for Xen. By default the
+# xen-devicetree.bb recipe adds '-xen' suffix to it
+XEN_MOD_DEVICETREE_DTBS ?= "n1sdp-single-chip-xen.dtb"
+
+# When generating the wic image we need to have the xen deployed
+do_image_wic[depends] += "xen:do_deploy"
+
+# Select the extra files to be included in the boot partition
+IMAGE_EFI_BOOT_FILES += "xen-n1sdp.efi;xen.efi"
+IMAGE_EFI_BOOT_FILES += "${XEN_MOD_DEVICETREE_DTBS}"
+

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

@@ -0,0 +1,50 @@
+# 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}:"
+
+DEPENDS_append_xen = " dos2unix-native"
+
+SRC_URI_append_xen = " file://add-xen-support.patch;patchdir=../"
+
+do_install_append_xen() {
+    mv -v ${D}/${UNPACK_DIR}/SOFTWARE/uEnv.txt \
+          ${D}/${UNPACK_DIR}/SOFTWARE/uenvfile
+    for dir in $(ls ${D}/${UNPACK_DIR}/SITE1/)
+    do
+        unix2dos ${D}/${UNPACK_DIR}/SITE1/${dir}/images.txt
+    done
+}
+
+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.
+
+    mkdir -p ${D}/${UNPACK_DIR}/SOFTWARE/XEN
+    cp  -v ${DEPLOY_DIR_IMAGE}/xen-${COMPATIBLE_MACHINE}.efi \
+        ${D}/${UNPACK_DIR}/SOFTWARE/XEN/xen
+
+    for dtb in $(basename -s .dtb ${KERNEL_DEVICETREE})
+    do
+        cp -v ${DEPLOY_DIR_IMAGE}/${dtb}-xen.dtb \
+            ${D}/${UNPACK_DIR}/SOFTWARE/XEN/${dtb}.dtb
+    done
+
+    bbnote "Xen binaries added under SOFTWARE/XEN directory"
+
+    if [ "${INITRAMFS_IMAGE_BUNDLE}" != "1" -a "${KERNEL_ALT_IMAGETYPE}" = "Image.lzma" ]; then
+        # KERNEL_ALT_IMAGETYPE is expected to be Image.lzma,
+        # however NOR flash filesystem is DOS compatible with 8.3 naming,
+        # so we need to replace ".lzma" with ".lzm"
+        cp -L -f ${DEPLOY_DIR_IMAGE}/${KERNEL_ALT_IMAGETYPE} \
+                 ${D}/${UNPACK_DIR}/SOFTWARE/Image.lzm
+    fi
+}

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-bsp/images/firmware-image-juno/add-xen-support.patch

@@ -0,0 +1,173 @@
+arm-bsp/firmware-image-juno: add xen support
+
+This patch adds xen and dtbs binaries entries to images-r[012].txt files.
+These images-r[012].txt files contain NOR filesystem entries details,
+like file offset, name, path etc.
+
+It also adds customization for uEnv.txt file, that allows to autoboot xen.
+
+Upstream-Status: Inappropriate [configuration]
+Signed-off-by: Kamil Dziezyk <kamil.dziezyk@arm.com>
+
+diff -u a/images-r0.txt b/images-r0.txt
+--- a/images-r0.txt	2020-11-25 20:25:38.677687712 +0100
++++ b/images-r0.txt	2020-11-25 20:36:55.482194294 +0100
+@@ -1,7 +1,7 @@
+ TITLE: Versatile Express Images Configuration File
+ 
+ [IMAGES]
+-TOTALIMAGES: 10                  ;Number of Images (Max: 32)
++TOTALIMAGES: 11                  ;Number of Images (Max: 32)
+ 
+ NOR0UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR0ADDRESS: 0x00000000          ;Image Flash Address
+@@ -17,14 +17,14 @@
+ 
+ NOR2UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR2ADDRESS: 0x00500000          ;Image Flash Address
+-NOR2FILE: \SOFTWARE\Image        ;Image File Name
+-NOR2NAME: norkern                ;Rename kernel to norkern
++NOR2FILE: \SOFTWARE\Image.lzm    ;Image File Name
++NOR2NAME: norkern.lzm            ;Rename kernel to norkern.lzm
+ NOR2LOAD: 00000000               ;Image Load Address
+ NOR2ENTRY: 00000000              ;Image Entry Point
+ 
+ NOR3UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR3ADDRESS: 0x02900000          ;Image Flash Address
+-NOR3FILE: \SOFTWARE\juno.dtb     ;Image File Name
++NOR3FILE: \SOFTWARE\XEN\juno.dtb ;Image File Name
+ NOR3NAME: board.dtb              ;Specify target filename to preserve file extension
+ NOR3LOAD: 00000000               ;Image Load Address
+ NOR3ENTRY: 00000000              ;Image Entry Point
+@@ -64,8 +64,13 @@
+ NOR9UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR9ADDRESS: 0x02A80000          ;Image Flash Address
+ NOR9NAME: uEnv.txt
+-NOR9FILE: \SOFTWARE\uEnv.txt     ;Image File Name
++NOR9FILE: \SOFTWARE\uenvfile     ;Image File Name
+ NOR9LOAD: 00000000               ;Image Load Address
+ NOR9ENTRY: 00000000              ;Image Entry Point
+ 
+-
++NOR10UPDATE: AUTO                ;Image Update:NONE/AUTO/FORCE
++NOR10ADDRESS: 0x03000000         ;Image Flash Address
++NOR10FILE: \SOFTWARE\XEN\xen     ;Image File Name
++NOR10NAME: xen
++NOR10LOAD: 00000000              ;Image Load Address
++NOR10ENTRY: 00000000             ;Image Entry Point
+diff -u a/images-r1.txt b/images-r1.txt
+--- a/images-r1.txt	2020-11-25 20:40:19.005177152 +0100
++++ b/images-r1.txt	2020-11-25 20:41:17.500886263 +0100
+@@ -1,7 +1,7 @@
+ TITLE: Versatile Express Images Configuration File
+ 
+ [IMAGES]
+-TOTALIMAGES: 10                  ;Number of Images (Max: 32)
++TOTALIMAGES: 11                  ;Number of Images (Max: 32)
+ 
+ NOR0UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR0ADDRESS: 0x00000000          ;Image Flash Address
+@@ -17,14 +17,14 @@
+ 
+ NOR2UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR2ADDRESS: 0x00500000          ;Image Flash Address
+-NOR2FILE: \SOFTWARE\Image        ;Image File Name
+-NOR2NAME: norkern                ;Rename kernel to norkern
++NOR2FILE: \SOFTWARE\Image.lzm    ;Image File Name
++NOR2NAME: norkern.lzm            ;Rename kernel to norkern.lzm
+ NOR2LOAD: 00000000               ;Image Load Address
+ NOR2ENTRY: 00000000              ;Image Entry Point
+ 
+ NOR3UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR3ADDRESS: 0x02900000          ;Image Flash Address
+-NOR3FILE: \SOFTWARE\juno-r1.dtb  ;Image File Name
++NOR3FILE: \SOFTWARE\XEN\juno-r1.dtb ;Image File Name
+ NOR3NAME: board.dtb              ;Specify target filename to preserve file extension
+ NOR3LOAD: 00000000               ;Image Load Address
+ NOR3ENTRY: 00000000              ;Image Entry Point
+@@ -64,8 +64,13 @@
+ NOR9UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR9ADDRESS: 0x02A80000          ;Image Flash Address
+ NOR9NAME: uEnv.txt
+-NOR9FILE: \SOFTWARE\uEnv.txt     ;Image File Name
++NOR9FILE: \SOFTWARE\uenvfile     ;Image File Name
+ NOR9LOAD: 00000000               ;Image Load Address
+ NOR9ENTRY: 00000000              ;Image Entry Point
+ 
+-
++NOR10UPDATE: AUTO                ;Image Update:NONE/AUTO/FORCE
++NOR10ADDRESS: 0x03000000         ;Image Flash Address
++NOR10FILE: \SOFTWARE\XEN\xen     ;Image File Name
++NOR10NAME: xen
++NOR10LOAD: 00000000              ;Image Load Address
++NOR10ENTRY: 00000000             ;Image Entry Point
+diff -u a/images-r2.txt b/images-r2.txt
+--- a/images-r2.txt	2020-11-25 20:40:30.625119321 +0100
++++ b/images-r2.txt	2020-11-25 20:41:30.720820597 +0100
+@@ -1,7 +1,7 @@
+ TITLE: Versatile Express Images Configuration File
+ 
+ [IMAGES]
+-TOTALIMAGES: 10                  ;Number of Images (Max: 32)
++TOTALIMAGES: 11                  ;Number of Images (Max: 32)
+ 
+ NOR0UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR0ADDRESS: 0x00000000          ;Image Flash Address
+@@ -17,14 +17,14 @@
+ 
+ NOR2UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR2ADDRESS: 0x00500000          ;Image Flash Address
+-NOR2FILE: \SOFTWARE\Image        ;Image File Name
+-NOR2NAME: norkern                ;Rename kernel to norkern
++NOR2FILE: \SOFTWARE\Image.lzm    ;Image File Name
++NOR2NAME: norkern.lzm            ;Rename kernel to norkern.lzm
+ NOR2LOAD: 00000000               ;Image Load Address
+ NOR2ENTRY: 00000000              ;Image Entry Point
+ 
+ NOR3UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR3ADDRESS: 0x02900000          ;Image Flash Address
+-NOR3FILE: \SOFTWARE\juno-r2.dtb  ;Image File Name
++NOR3FILE: \SOFTWARE\XEN\juno-r2.dtb ;Image File Name
+ NOR3NAME: board.dtb              ;Specify target filename to preserve file extension
+ NOR3LOAD: 00000000               ;Image Load Address
+ NOR3ENTRY: 00000000              ;Image Entry Point
+@@ -64,8 +64,13 @@
+ NOR9UPDATE: AUTO                 ;Image Update:NONE/AUTO/FORCE
+ NOR9ADDRESS: 0x02A80000          ;Image Flash Address
+ NOR9NAME: uEnv.txt
+-NOR9FILE: \SOFTWARE\uEnv.txt     ;Image File Name
++NOR9FILE: \SOFTWARE\uenvfile     ;Image File Name
+ NOR9LOAD: 00000000               ;Image Load Address
+ NOR9ENTRY: 00000000              ;Image Entry Point
+ 
+-
++NOR10UPDATE: AUTO                ;Image Update:NONE/AUTO/FORCE
++NOR10ADDRESS: 0x03000000         ;Image Flash Address
++NOR10FILE: \SOFTWARE\XEN\xen     ;Image File Name
++NOR10NAME: xen
++NOR10LOAD: 00000000              ;Image Load Address
++NOR10ENTRY: 00000000             ;Image Entry Point
+diff -u a/uEnv.txt b/uEnv.txt
+--- a/uEnv.txt	2020-11-20 13:48:31.845078690 +0100
++++ b/uEnv.txt	2020-11-25 20:30:00.572306675 +0100
+@@ -1,11 +1,16 @@
++xen_name=xen
++xen_addr=0x84000000
+ uenvcmd=run mybootcmd
++kernel_alt_name=norkern.lzm
++kernel_comp_addr_r=0x88080000
+ mybootcmd=echo Loading custom boot command; \
+ echo Loading kernel; \
+ afs load ${kernel_name} ${kernel_addr_r} ; \
+-if test $? -eq 1; then echo Loading ${kernel_alt_name} instead of ${kernel_name}; afs load ${kernel_alt_name} ${kernel_addr_r}; fi; \
++if test $? -eq 1; then echo Loading ${kernel_alt_name} instead of ${kernel_name}; afs load ${kernel_alt_name} ${kernel_comp_addr_r}; lzmadec ${kernel_comp_addr_r} ${kernel_addr_r}; fi; \
+ echo Loading device tree; \
+ afs load  ${fdtfile} ${fdt_addr_r}; \
+ if test $? -eq 1; then echo Loading ${fdt_alt_name} instead of ${fdtfile}; \
+ afs load ${fdt_alt_name} ${fdt_addr_r}; fi; fdt addr ${fdt_addr_r}; fdt resize; \
+-booti ${kernel_addr_r} - ${fdt_addr_r};
+-
++echo Loading Xen; \
++afs load  ${xen_name} ${xen_addr}; \
++if test $? -eq 0; then echo Booting Xen; bootefi ${xen_addr} ${fdt_addr_r}; fi;
+

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,41 @@
+/*
+ * 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;
+
+    soc {
+        /*
+         * 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,23 @@
+# 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"
+# For N1SDP, the XEN_DEVICETREE_DEPEND and XEN_DEVICETREE_DTBS variables are
+# being set in meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/n1sdp-extra-settings.inc
+
+# 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/sda2 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"

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xen/files/fvp-base/early-printk.cfg

@@ -0,0 +1,2 @@
+CONFIG_DEBUG=y
+CONFIG_EARLY_PRINTK_FASTMODEL=y

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xen/files/juno/early-printk.cfg

@@ -0,0 +1,2 @@
+CONFIG_DEBUG=y
+CONFIG_EARLY_PRINTK_JUNO=y

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-extended/xen/files/n1sdp/early-printk.cfg

@@ -0,0 +1,3 @@
+CONFIG_DEBUG=y
+CONFIG_EARLY_UART_CHOICE_PL011=y
+CONFIG_EARLY_UART_BASE_ADDRESS=0x2a400000

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

@@ -0,0 +1,5 @@
+CONFIG_EXPERT=y
+# Enable ACPI support
+CONFIG_ACPI=y
+# Enable ARM Interrupt Translation Service (ITS) emulation
+CONFIG_HAS_ITS=y

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

@@ -0,0 +1,15 @@
+# FVP Base support
+COMPATIBLE_MACHINE_fvp-base = "fvp-base"
+FILESEXTRAPATHS_prepend_fvp-base := "${THISDIR}/files:"
+SRC_URI_append_fvp-base = " file://early-printk.cfg"
+
+# Juno support
+COMPATIBLE_MACHINE_juno = "juno"
+FILESEXTRAPATHS_prepend_juno := "${THISDIR}/files:"
+SRC_URI_append_juno = " file://early-printk.cfg"
+
+# N1SDP support
+COMPATIBLE_MACHINE_n1sdp = "n1sdp"
+FILESEXTRAPATHS_prepend_n1sdp := "${THISDIR}/files:"
+SRC_URI_append_n1sdp = " file://n1sdp.cfg \
+                         file://early-printk.cfg"

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-kernel/linux/arm-autonomy-kmeta-extra/features/arm-autonomy/disable-arm64-sve.cfg

@@ -0,0 +1,4 @@
+# We need to turn off SVE support in the Linux kernel otherwise Xen is stopping
+# Linux kernel with a coredump while trying to access ZEN bit of CPACR1 core
+# register.
+# CONFIG_ARM64_SVE is not set

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-kernel/linux/arm-autonomy-kmeta-extra/features/arm-autonomy/disable-arm64-sve.scc

@@ -0,0 +1,3 @@
+define KFEATURE_DESCRIPTION "Disable SVE support"
+
+kconf non-hardware disable-arm64-sve.cfg

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

@@ -0,0 +1,15 @@
+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_fvp-base = "${LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE}"

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/wic/arm-autonomy-juno-disk.wks.in

@@ -0,0 +1,14 @@
+# short-description: Create a disk image
+# long-description: Creates a partitioned disk image that the user
+# can directly dd to boot media.
+
+# For Juno first partition is rootfs normally populated as /dev/sda1
+part / --source rootfs --ondisk sda --fstype=ext4 --label root --align 1024
+
+# Second partition to accomodate guests images normally populated as /dev/sda2 (used by XENGUEST_MANAGER_VOLUME_DEVICE)
+part --label guests --source empty --ondisk sda --size="${GUEST_PART_SIZE}${GUEST_PART_SIZE_UNIT}" --system-id 8e --align 1024
+
+# Third partition is user defined entry normally populated as /dev/sda3
+${AUTONOMY_HOST_EXTRA_PARTITION}
+
+bootloader --ptable msdos

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/wic/arm-autonomy-n1sdp-efidisk.wks.in

@@ -0,0 +1,17 @@
+# short-description: Create an EFI disk image
+# long-description: Creates a partitioned EFI disk image that the user
+# can directly dd to boot media. Uses a custom grub.cfg file to configure the boot.
+
+# First boot partition normally populated as /dev/sda1
+part /boot --source bootimg-efi --sourceparams="loader=grub-efi" --ondisk sda --label msdos --active --align 1024
+
+# Second rootfs partition normally populated as /dev/sda2
+part / --source rootfs --ondisk sda --fstype=ext4 --label root --align 1024
+
+# Third partition to accomodate guests images normally populated as /dev/sda3 (used by XENGUEST_MANAGER_VOLUME_DEVICE)
+part --label guests --source empty --ondisk sda --size="${GUEST_PART_SIZE}${GUEST_PART_SIZE_UNIT}" --system-id 8e --align 1024
+
+# Fourth partition is user defined entry normally populated as /dev/sda4
+${AUTONOMY_HOST_EXTRA_PARTITION}
+
+bootloader --ptable msdos --configfile="${GRUB_CFG_FILE}"

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/wic/arm-autonomy-n1sdp-grub.cfg

@@ -0,0 +1,28 @@
+set term="vt100"
+set default="3"
+set timeout="5"
+
+set kernel_cmdline="earlycon=pl011,0x2A400000 console=ttyAMA0,115200 root=/dev/sda2 rootwait"
+
+menuentry 'N1SDP ACPI Boot' {
+    linux /Image $kernel_cmdline acpi=force
+}
+
+menuentry 'N1SDP Single-Chip Boot (Device Tree)' {
+    devicetree /n1sdp-single-chip.dtb
+    linux /Image $kernel_cmdline
+}
+
+menuentry 'N1SDP Multi-Chip Boot (Device Tree)' {
+    devicetree /n1sdp-multi-chip.dtb
+    linux /Image $kernel_cmdline
+}
+
+menuentry 'N1SDP Arm Autonomy (Xen) Single-Chip Boot (Device Tree)' {
+    # no_argumants under here is a workaround for a bug
+    # also any kernel or dom0 cmdline arguments has to be passed via dtb
+    # because any arguments put here will be ignored by xen
+    xen_hypervisor /xen.efi no_arguments=use_dtb_for_xen_or_kernel_cmdline
+    xen_module /Image
+    devicetree /n1sdp-single-chip-xen.dtb
+}

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

@@ -0,0 +1,32 @@
+# Use OVERRIDES to minimize the usage of
+# ${@bb.utils.contains('DISTRO_FEATURES', 'xen', ...
+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
+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 \
+    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"
+
+# Image generated by boot wrapper when Xen is present
+BOOT_WRAPPER_AARCH64_IMAGE_xen ?= "xen-system.axf"
+
+EXTRA_OECONF_append_xen = " \
+--with-xen=${WORKDIR}/kernel/arch/arm64/boot/Image \
+--with-xen-cmdline="" \
+"
+
+EXTRA_OEMAKE_append_xen = " \
+XEN_IMAGE=${DEPLOY_DIR_IMAGE}/${BOOT_WRAPPER_AARCH64_XEN} \
+XEN_CMDLINE="${BOOT_WRAPPER_AARCH64_XEN_CMDLINE}" \
+"
+
+# We need xen if it is activated
+do_deploy[depends] += "${@bb.utils.contains('DISTRO_FEATURES', 'xen', 'xen:do_deploy', '', d)}"

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

@@ -0,0 +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 = " \
+${@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-gem5/recipes-extended/xen/files/gem5-arm64/early-printk.cfg

@@ -0,0 +1,2 @@
+CONFIG_DEBUG=y
+CONFIG_EARLY_PRINTK_VEXPRESS=y

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

@@ -0,0 +1,4 @@
+# gem5-arm64 support
+COMPATIBLE_MACHINE_gem5-arm64 = "gem5-arm64"
+FILESEXTRAPATHS_prepend_gem5-arm64 := "${THISDIR}/files:"
+SRC_URI_append_gem5-arm64 = " file://early-printk.cfg"

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

@@ -0,0 +1 @@
+XENGUEST_NETWORK_BRIDGE_MEMBERS_gem5-arm64 ?= "eth0"

meta-arm-autonomy/dynamic-layers/meta-gem5/recipes-kernel/linux/arm-autonomy-kmeta-extra-gem5/features/arm-autonomy/disable-arm64-sve.cfg

@@ -0,0 +1,4 @@
+# We need to turn off SVE support in the Linux kernel otherwise Xen is stopping
+# Linux kernel with a coredump while trying to access ZEN bit of CPACR1 core
+# register.
+# CONFIG_ARM64_SVE is not set

meta-arm-autonomy/dynamic-layers/meta-gem5/recipes-kernel/linux/arm-autonomy-kmeta-extra-gem5/features/arm-autonomy/disable-arm64-sve.scc

@@ -0,0 +1,3 @@
+define KFEATURE_DESCRIPTION "Disable SVE support"
+
+kconf non-hardware disable-arm64-sve.cfg

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

@@ -0,0 +1,15 @@
+FILESEXTRAPATHS_prepend_gem5-arm64 := "${THISDIR}:"
+
+#
+# arm-autonomy kmeta extra
+#
+SRC_URI_append_gem5-arm64 = " file://arm-autonomy-kmeta-extra-gem5;type=kmeta;name=arm-autonomy-kmeta-extra-gem5;destsuffix=arm-autonomy-kmeta-extra-gem5"
+
+# 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_gem5-arm64 = "${@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}"

meta-arm-autonomy/recipes-bsp/grub/grub-efi_%.bbappend

@@ -0,0 +1 @@
+GRUB_BUILDIN += "${@bb.utils.contains('DISTRO_FEATURES', 'xen', 'xen_boot', '', d)}"

meta-arm-autonomy/recipes-bsp/u-boot/u-boot-2020.07/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.07.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-containers/packagegroups/packagegroup-docker-runtime-minimal.bb

@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: MIT
+#
+# Copyright (c) 2020 Arm Limited
+#
+
+SUMMARY = "Docker runtime minimal requirements"
+DESCRIPTION = "The minimal set of packages required for running Docker"
+
+inherit packagegroup
+
+RDEPENDS_${PN} = "\
+    docker-ce \
+    docker-ce-contrib \
+    kernel-module-xt-nat \
+    kernel-module-xt-masquerade \
+    kernel-module-xt-addrtype \
+    kernel-module-xt-conntrack \
+    kernel-module-xt-ipvs \
+   "

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

@@ -0,0 +1,145 @@
+# 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-system-i386 \
+    xenguest-manager \
+    xenguest-network \
+    "
+
+# Build xen binary
+EXTRA_IMAGEDEPENDS += "xen"
+
+# Build xen-devicetree to produce a xen ready devicetree
+EXTRA_IMAGEDEPENDS += "xen-devicetree"
+
+# Documentation for setting up a multiconfig build can be found in:
+# meta-arm-autonomy/documentation/arm-autonomy-multiconfig.md
+
+# In a multiconfig build this variable will hold a dependency string, which differs based
+# on whether the guest has initramfs or not.
+# It may have a space seperated list of dependency strings if mulitple guest types are
+# configured
+MC_DOIMAGE_MCDEPENDS ?= ""
+# Example value: mc:host:guest:core-image-minimal:do_image_complete
+
+# In a multiconfig build the host task 'do_image' has a dependency on multiconfig guest.
+# This ensures that the guest image file already exists when it is needed by the host
+DO_IMAGE_MCDEPENDS := "${@ '${MC_DOIMAGE_MCDEPENDS}' if d.getVar('BBMULTICONFIG') else ''}"
+
+# Apply mc dependency. Empty string if multiconfig not enabled
+do_image[mcdepends] += "${DO_IMAGE_MCDEPENDS}"
+
+
+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):
+                realpath = os.path.realpath(path)
+
+                if not os.path.exists(realpath):
+                    bb.fatal("ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS link does not resolve: " + path)
+
+                bb.note("Guest file is a symlink:\n " + path + "\nResolved to:\n " + realpath)
+                path = realpath
+
+            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
+}

meta-arm-autonomy/recipes-core/sysvinit/sysvinit-inittab_2.%.bbappend

@@ -0,0 +1,16 @@
+# if arm-autonomy-guest is activated, we are running as a xen guest so we must
+# have a console on hvc0
+# This is normally done in meta-virtualization if xen is activated but here
+# we don't have xen activated.
+#
+
+SYSVINIT_ADDHVC0 = "${@bb.utils.contains('DISTRO_FEATURES', \
+    'arm-autonomy-guest', 'true', 'false', d)}"
+
+do_install_append() {
+    if ${SYSVINIT_ADDHVC0}; then
+        echo "" >> ${D}${sysconfdir}/inittab
+        echo "X0:12345:respawn:/sbin/getty 115200 hvc0" >> \
+            ${D}${sysconfdir}/inittab
+    fi
+}

meta-arm-autonomy/recipes-devtools/qemu/qemu_%.bbappend

@@ -0,0 +1,12 @@
+# Use OVERRIDES to minimize the usage of
+# ${@bb.utils.contains('DISTRO_FEATURES', 'xen', ...
+OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ':xen', '', d)}"
+
+# For Xen we only need the i386 binaries
+QEMU_TARGETS_xen = "i386"
+
+PACKAGECONFIG[noaudio] = "--audio-drv-list='',,"
+PACKAGECONFIG_append_xen = " noaudio"
+PACKAGECONFIG_remove_xen = "fdt sdl kvm"
+
+require ${@bb.utils.contains('DISTRO_FEATURES', 'xen', 'recipes-devtools/qemu/${BPN}-package-split.inc', '', d)}