corstone700: add initial recipes

Add need configuration and recipes to support the corstone700 in meta-arm. Change-Id: I5df7e224f4079e6d46fdd1051975772952f52ba9 Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
arm: trusted-firmware-a: fix the upstream revision
2026-07-18 16:37:08 +00:00 · 2019-09-23 13:46:26 +01:00 · 2019-09-19 11:02:15 +01:00 · 2019-09-16 10:58:18 +01:00 · 2019-09-02 15:50:40 +01:00 · 2019-09-02 15:50:40 +01:00
646 changed files with 1107 additions and 45113 deletions
@@ -1,128 +0,0 @@
-# Use our custom Crops-derived image
-image: $CI_REGISTRY/$CI_PROJECT_NAMESPACE/yocto-builder:master
-
-  # First do a common bootstrap, and then build all the targets
-stages:
-  - bootstrap
-  - build
-
-# Common job fragment to get a worker ready
-.setup:
-  stage: build
-  variables:
-    KAS_WORK_DIR: $CI_PROJECT_DIR/work
-    SSTATE_DIR: $CI_BUILDS_DIR/persist/sstate
-    DL_DIR: $CI_BUILDS_DIR/persist/downloads
-    BB_LOGCONFIG: $CI_PROJECT_DIR/kas/logging.yml
-  before_script:
-    - echo KAS_WORK_DIR = $KAS_WORK_DIR
-    - echo SSTATE_DIR = $SSTATE_DIR
-    - echo DL_DIR = $DL_DIR
-    - mkdir --verbose --parents $KAS_WORK_DIR $SSTATE_DIR $DL_DIR
-
-# Generalised fragment to do a Kas build
-.build:
-  extends: .setup
-  script:
-  - KASFILES=$(kas/jobs-to-kas $CI_JOB_NAME)
-  - kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
-  - kas build $KASFILES
-  - ./kas/check-warnings $KAS_WORK_DIR/build/warnings.log
-
-
-#
-# First phase, bootstrap and machine coverage
-#
-
-# Build a number of native tools first to ensure the other builders don't race
-# over them
-n1sdp/bootstrap:
-  extends: .build
-  stage: bootstrap
-
-# What percentage of machines in the layer do we build
-machine-coverage:
-  stage: bootstrap
-  script:
-  - ./kas/check-machine-coverage
-  coverage: '/Coverage: \d+/'
-
-
-#
-# Second phase, 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
-
-gem5-arm64:
-  extends: .build
-
-juno:
-  extends: .build
-
-juno/clang:
-  extends: .build
-
-musca-b1:
-  extends: .build
-
-musca-s1:
-  extends: .build
-
-n1sdp:
-  extends: .build
-
-qemuarm64-secureboot:
-  extends: .build
-
-qemuarm64-secureboot/clang:
-  extends: .build
-
-qemuarm64-secureboot/clang/musl:
-  extends: .build
-
-qemuarm64-secureboot/musl:
-  extends: .build
-
-sgi575:
-  extends: .build
-
-tc0:
-  extends: .build
-
-
-#
-# Utility tasks, not executed automatically
-#
-
-# Report on disk usage
-usage:
-  extends: .setup
-  stage: bootstrap
-  when: manual
-  script:
-  - du -h -s $DL_DIR $SSTATE_DIR
-
-# Wipe out old sstate
-prune-sstate:
-  extends: .setup
-  stage: bootstrap
-  when: manual
-  script:
-  - find $SSTATE_DIR -type f -atime +30 -delete
@@ -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.
@@ -1,50 +0,0 @@
-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>
@@ -0,0 +1,15 @@
+# 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}"
@@ -0,0 +1,21 @@
+# 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"
@@ -0,0 +1,18 @@
+# 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"
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: MIT
+#
+# Copyright (c) 2019 Arm Limited
+#
+
+TUNE_FEATURES = "aarch32"
+
+require conf/machine/include/arm/arch-armv8a.inc
@@ -0,0 +1,11 @@
+# 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"
@@ -0,0 +1,61 @@
+# 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
+}
@@ -0,0 +1,30 @@
+# 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}
+}
@@ -0,0 +1,23 @@
+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}
+}
@@ -0,0 +1,36 @@
+# 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"
@@ -0,0 +1,10 @@
+# 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"
@@ -0,0 +1,35 @@
+# 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"
@@ -0,0 +1,8 @@
+# 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
@@ -1,6 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: a5ds
@@ -1,44 +0,0 @@
-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: ""
-
-local_conf_header:
-  base: |
-    CONF_VERSION = "1"
-    PACKAGE_CLASSES = "package_ipk"
-    LICENSE_FLAGS_WHITELIST += "armcompiler"
-    PACKAGECONFIG_remove_pn-qemu-system-native = "gtk+ sdl"
-    BB_NUMBER_THREADS = "16"
-    PARALLEL_MAKE = "-j16"
-    INHERIT += "rm_work"
-    PACKAGECONFIG_append_pn-perf = " coresight"
-    ERROR_QA = "${WARN_QA}"
-  ptest: |
-    DISTRO_FEATURES_remove = "ptest"
-
-machine: unset
-
-target:
-  - core-image-base
-  - perf
@@ -1,9 +0,0 @@
-header:
-  version: 9
-
-target:
-  - binutils-cross-aarch64
-  - gcc-cross-aarch64
-  - python3-native
-  - opkg-native
-  - rpm-native
@@ -1,26 +0,0 @@
-#! /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 kas files
-kas = metaarm.glob("kas/*.yml")
-kas = set(p.stem for p in kas)
-
-missing = machines - kas
-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}%")
@@ -1,18 +0,0 @@
-#! /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
-
-if test -s $LOGFILE; then
-    echo ==============================
-    echo The build had warnings/errors:
-    echo ==============================
-    cat $LOGFILE
-    exit 1
-fi
-
-exit 0
@@ -1,11 +0,0 @@
-header:
-  version: 9
-
-repos:
-  meta-clang:
-    url: https://github.com/kraj/meta-clang
-    refspec: gatesgarth
-
-local_conf_header:
-  clang: |
-    TOOLCHAIN = "clang"
@@ -1,10 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: corstone700-fvp
-
-local_conf_header:
-  image: |
-    CORE_IMAGE_EXTRA_INSTALL = "corstone700-test-app"
@@ -1,6 +0,0 @@
-header:
-  version: 9
-  includes:
-    - corstone700-fvp.yml
-
-machine: corstone700-mps3
@@ -1,6 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: foundation-armv8
@@ -1,6 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: fvp-base-arm32
@@ -1,7 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: fvp-base
-
@@ -1,21 +0,0 @@
-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
@@ -1,19 +0,0 @@
-#! /bin/bash
-
-# Read a GitLab CI job name on $1 and transform it to a
-# list of Kas yaml files
-
-set -e -u
-
-# Read Job namne from $1 and split on /
-IFS=/ read -r -a PARTS<<<$1
-
-# Prefix each part with kas/
-PARTS=("${PARTS[@]/#/kas/}")
-
-# Suffix each part with .yml
-PARTS=("${PARTS[@]/%/.yml}")
-
-# Print colon-separated
-IFS=":"
-echo "${PARTS[*]}"
@@ -1,6 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: juno
@@ -1,13 +0,0 @@
-# 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]
@@ -1,9 +0,0 @@
-header:
-  version: 9
-
-repos:
-  meta-openembedded:
-    url: https://git.openembedded.org/meta-openembedded
-    layers:
-      meta-oe:
-      meta-python:
@@ -1,8 +0,0 @@
-header:
-  version: 9
-  includes:
-    - meta-python.yml
-
-repos:
-  meta-zephyr:
-    url: https://git.yoctoproject.org/git/meta-zephyr
@@ -1,11 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-    - meta-zephyr.yml
-
-machine: musca-b1
-
-target:
-  - trusted-firmware-m
-  - zephyr-philosophers
@@ -1,10 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-    - meta-python.yml
-
-machine: musca-s1
-
-target:
-  - trusted-firmware-m
@@ -1,6 +0,0 @@
-header:
-  version: 9
-
-local_conf_header:
-  libc: |
-    TCLIBC = "musl"
@@ -1,6 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: n1sdp
@@ -1,11 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: qemuarm64-secureboot
-
-target:
-  - core-image-base
-  - perf
-  - optee-examples
@@ -1,6 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: sgi575
@@ -1,6 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: tc0
@@ -1,92 +0,0 @@
-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>
@@ -1,5 +0,0 @@
-# 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)}
-
@@ -1,108 +0,0 @@
-# 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')
-}
-
@@ -1,34 +0,0 @@
-# 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
-}
@@ -1,114 +0,0 @@
-# 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"
-
@@ -1,199 +0,0 @@
-# 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 ""
@@ -1,15 +0,0 @@
-# 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)}"
@@ -1,21 +0,0 @@
-# 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)}
@@ -1,39 +0,0 @@
-# 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"
@@ -1,17 +0,0 @@
-#@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"
-
@@ -1,195 +0,0 @@
-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.
@@ -1,236 +0,0 @@
-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.
-
@@ -1,29 +0,0 @@
-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.
@@ -1,104 +0,0 @@
-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.
-
@@ -1,101 +0,0 @@
-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
@@ -1,121 +0,0 @@
-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`
-
@@ -1,80 +0,0 @@
-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.
@@ -1,7 +0,0 @@
-# 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}
@@ -1,7 +0,0 @@
-# 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"
@@ -1,26 +0,0 @@
-# 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)}"
@@ -1,40 +0,0 @@
-# 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}"
-
@@ -1,50 +0,0 @@
-# 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
-}
@@ -1,173 +0,0 @@
-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;
-
@@ -1,11 +0,0 @@
-/*
- * Disable IOMMU on juno board when Xen is used
- */
-
-/ {
-
-	/* turn off iommu */
-	iommu@2b600000 {
-		status = "disabled";
-	};
-};
@@ -1,41 +0,0 @@
-/*
- * 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;
-        };
-    };
-};
@@ -1,23 +0,0 @@
-# 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"
@@ -1,2 +0,0 @@
-CONFIG_DEBUG=y
-CONFIG_EARLY_PRINTK_FASTMODEL=y
@@ -1,2 +0,0 @@
-CONFIG_DEBUG=y
-CONFIG_EARLY_PRINTK_JUNO=y
@@ -1,3 +0,0 @@
-CONFIG_DEBUG=y
-CONFIG_EARLY_UART_CHOICE_PL011=y
-CONFIG_EARLY_UART_BASE_ADDRESS=0x2a400000
@@ -1,5 +0,0 @@
-CONFIG_EXPERT=y
-# Enable ACPI support
-CONFIG_ACPI=y
-# Enable ARM Interrupt Translation Service (ITS) emulation
-CONFIG_HAS_ITS=y
@@ -1,15 +0,0 @@
-# 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"
@@ -1,4 +0,0 @@
-# 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
@@ -1,3 +0,0 @@
-define KFEATURE_DESCRIPTION "Disable SVE support"
-
-kconf non-hardware disable-arm64-sve.cfg
@@ -1,15 +0,0 @@
-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}"
@@ -1,14 +0,0 @@
-# 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
@@ -1,17 +0,0 @@
-# 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}"
@@ -1,28 +0,0 @@
-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
-}
@@ -1,32 +0,0 @@
-# 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)}"
@@ -1,7 +0,0 @@
-# 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)}"
@@ -1,2 +0,0 @@
-CONFIG_DEBUG=y
-CONFIG_EARLY_PRINTK_VEXPRESS=y
@@ -1,4 +0,0 @@
-# gem5-arm64 support
-COMPATIBLE_MACHINE_gem5-arm64 = "gem5-arm64"
-FILESEXTRAPATHS_prepend_gem5-arm64 := "${THISDIR}/files:"
-SRC_URI_append_gem5-arm64 = " file://early-printk.cfg"
@@ -1 +0,0 @@
-XENGUEST_NETWORK_BRIDGE_MEMBERS_gem5-arm64 ?= "eth0"
@@ -1,4 +0,0 @@
-# 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
@@ -1,3 +0,0 @@
-define KFEATURE_DESCRIPTION "Disable SVE support"
-
-kconf non-hardware disable-arm64-sve.cfg
@@ -1,15 +0,0 @@
-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}"
@@ -1 +0,0 @@
-GRUB_BUILDIN += "${@bb.utils.contains('DISTRO_FEATURES', 'xen', 'xen_boot', '', d)}"
@@ -1,16 +0,0 @@
-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"		\
@@ -1,9 +0,0 @@
-# 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)}"
@@ -1,19 +0,0 @@
-# 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 \
-   "
@@ -1,145 +0,0 @@
-# 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; "
-
@@ -1,18 +0,0 @@
-# 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
-}
@@ -1,16 +0,0 @@
-# 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
-}
@@ -1,12 +0,0 @@
-# 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)}
@@ -1,17 +0,0 @@
-/ {
-    chosen {
-        xen,dom0-bootargs = "###XEN_DOM0_BOOTARGS###";
-        xen,xen-bootargs = "###XEN_XEN_BOOTARGS###";
-
-        modules {
-            #size-cells = <0x00000001>;
-            #address-cells = <0x00000001>;
-
-            module@0 {
-                reg = <###XEN_DOM0_ADDR### ###XEN_DOM0_SIZE###>;
-                compatible = "multiboot,module";
-            };
-        };
-    };
-};
-
@@ -1,101 +0,0 @@
-# This recipe can be used to modify one or several DTBS to add
-# entries required to declare and boot Linux as Dom0 from Xen
-
-SRC_URI = "file://xen.dtsi.in"
-
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "\
-    file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \
-    "
-
-S = "${WORKDIR}"
-
-DESCRIPTION = "Add entries in DTB for Xen and Dom0"
-
-# Please refer to documentation/xen-devicetree.md for documentation on those
-# parameters
-# kernel size is passed to xen via xen.dtb so wee need to add
-# 'virtual/kernel:do_deploy' as a dependency
-XEN_DEVICETREE_DEPEND_append = " virtual/kernel:do_deploy"
-XEN_DEVICETREE_DTBS ?= "${KERNEL_DEVICETREE}"
-XEN_DEVICETREE_XEN_BOOTARGS ?= "noreboot dom0_mem=${XEN_DEVICETREE_DOM0_MEM}"
-XEN_DEVICETREE_DOM0_MEM ?= "1024M"
-XEN_DEVICETREE_DOM0_BOOTARGS ?= "console=hvc0 earlycon=xen"
-XEN_DEVICETREE_DOM0_ADDR ?= "0x80080000"
-XEN_DEVICETREE_DOM0_SIZE ?= "0x01000000"
-XEN_DEVICETREE_DTSI_MERGE ?= "xen.dtsi"
-
-# Our package does not generate any package for the rootfs but contributes to
-# deploy
-inherit nopackages deploy
-
-DEPENDS += "dtc-native"
-
-do_configure[noexec] = "1"
-do_compile[noexec] = "1"
-do_install[noexec] = "1"
-
-do_deploy() {
-    if [ ! -f ${WORKDIR}/xen.dtsi.in ]; then
-        die "xen.dtsi.in does not exist"
-    fi
-    cat ${WORKDIR}/xen.dtsi.in \
-        | sed -e "s?###XEN_DOM0_BOOTARGS###?${XEN_DEVICETREE_DOM0_BOOTARGS}?" \
-        | sed -e "s?###XEN_XEN_BOOTARGS###?${XEN_DEVICETREE_XEN_BOOTARGS}?" \
-        | sed -e "s?###XEN_DOM0_ADDR###?${XEN_DEVICETREE_DOM0_ADDR}?" \
-        | sed -e "s?###XEN_DOM0_SIZE###?${XEN_DEVICETREE_DOM0_SIZE}?" \
-        > ${WORKDIR}/xen.dtsi
-
-    # Generate final dtbs
-    for dtbf in ${XEN_DEVICETREE_DTBS}; do
-        rdtb=`basename $dtbf`
-        if [ ! -f ${DEPLOY_DIR_IMAGE}/$rdtb ]; then
-            die "Wrong file in XEN_DEVICETREE_DTBS: ${DEPLOY_DIR_IMAGE}/$rdtb does not exist"
-        fi
-        dtc -I dtb -O dts -o ${WORKDIR}/dom0-linux.dts ${DEPLOY_DIR_IMAGE}/$rdtb
-
-        # Add external includes
-        for inc in ${XEN_DEVICETREE_DTSI_MERGE}; do
-            if [ ! -f ${WORKDIR}/${inc} ]; then
-                die "Wrong file in XEN_DEVICETREE_DTSI_MERGE: ${WORKDIR}/${inc} does not exist"
-            fi
-            echo "/include/ \"$inc\"" >> ${WORKDIR}/dom0-linux.dts
-        done
-
-        rdtbnoextn=`basename $dtbf ".dtb"`
-        dtc -I dts -O dtb \
-            -o ${WORKDIR}/${rdtbnoextn}-xen.dtb ${WORKDIR}/dom0-linux.dts
-        install -m 644 ${rdtbnoextn}-xen.dtb ${DEPLOYDIR}/.
-    done
-}
-do_deploy[depends] += "${XEN_DEVICETREE_DEPEND}"
-do_deploy[prefuncs] += "calc_xen_dtb_dom0_size"
-
-addtask deploy after do_install
-
-python calc_xen_dtb_dom0_size() {
-    from math import ceil
-    size = 0
-    if d.getVar('KERNEL_IMAGE_MAXSIZE'):
-        bb.note('size calculation based on KERNEL_IMAGE_MAXSIZE')
-        size = int(d.getVar('KERNEL_IMAGE_MAXSIZE')) * 1024
-    else:
-        kernel = os.path.realpath(d.getVar('DEPLOY_DIR_IMAGE') + '/' +\
-                 d.getVar('KERNEL_IMAGETYPE'))
-        size = os.stat(kernel).st_size
-        bb.note('size calculation based on kernel Image file: %s' % kernel)
-
-    bb.note('size in bytes: %d' % size)
-    # Ceil to MiB
-    size_required = ceil(size / (2 ** 20)) * (2 ** 20)
-    size_defined = int(d.getVar('XEN_DEVICETREE_DOM0_SIZE'), 16)
-
-    if size_required > size_defined:
-        bb.warn ("Wrong kernel size setting inside xen dtb!\n"\
-                 "Required:\t%(req)d (%(req)#010X)\n"\
-                 "Requested:\t%(def)d (%(def)#010X)"\
-                 % {"req": size_required, "def": size_defined})
-        bb.warn ("Overriding XEN_DEVICETREE_DOM0_SIZE with "\
-                 "%(req)d (%(req)#010X)" % {"req": size_required})
-        d.setVar('XEN_DEVICETREE_DOM0_SIZE', hex(size_required))
-}
@@ -1,51 +0,0 @@
-From f4c1a541fa351e4f613471bbf397931f9e1ddd27 Mon Sep 17 00:00:00 2001
-Message-Id: <f4c1a541fa351e4f613471bbf397931f9e1ddd27.1602683707.git.diego.sueiro@arm.com>
-From: Wei Chen <wei.chen@arm.com>
-Date: Fri, 28 Aug 2020 02:34:04 +0000
-Subject: [PATCH] xen/arm: Throw messages for unknown FP/SIMD implement ID
-
-Arm ID_AA64PFR0_EL1 register provides two fields to describe CPU
-FP/SIMD implementations. Currently, we exactly know the meaning of
-0x0, 0x1 and 0xf of these fields. Xen treats value < 8 as FP/SIMD
-features presented. If there is a value 0x2 bumped in the future,
-Xen behaviors for value <= 0x1 can also take effect. But what Xen
-done for value <= 0x1 may not always cover new value 0x2 required.
-We throw these messages to break the silence when Xen detected
-unknown FP/SIMD IDs to notice user to check.
-
-Signed-off-by: Wei Chen <wei.chen@arm.com>
-Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
-Acked-by: Julien Grall <jgrall@amazon.com>
-
-Upstream-Status: Backport
-Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
---
- xen/arch/arm/setup.c | 12 ++++++++++++
- 1 file changed, 12 insertions(+)
-
-diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
-index 7968cee..f16b33f 100644
--- a/xen/arch/arm/setup.c
-+++ b/xen/arch/arm/setup.c
-@@ -133,6 +133,18 @@ static void __init processor_id(void)
-            cpu_has_simd ? " AdvancedSIMD" : "",
-            cpu_has_gicv3 ? " GICv3-SysReg" : "");
- 
-+    /* Warn user if we find unknown floating-point features */
-+    if ( cpu_has_fp && (boot_cpu_feature64(fp) >= 2) )
-+        printk(XENLOG_WARNING "WARNING: Unknown Floating-point ID:%d, "
-+               "this may result in corruption on the platform\n",
-+               boot_cpu_feature64(fp));
-+
-+    /* Warn user if we find unknown AdvancedSIMD features */
-+    if ( cpu_has_simd && (boot_cpu_feature64(simd) >= 2) )
-+        printk(XENLOG_WARNING "WARNING: Unknown AdvancedSIMD ID:%d, "
-+               "this may result in corruption on the platform\n",
-+               boot_cpu_feature64(simd));
-+
-     printk("  Debug Features: %016"PRIx64" %016"PRIx64"\n",
-            boot_cpu_data.dbg64.bits[0], boot_cpu_data.dbg64.bits[1]);
-     printk("  Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
-- 
-2.7.4
-
@@ -1,34 +0,0 @@
-Upstream-Status: Backport
-Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
-Signed-off-by: Kamil Dziezyk <kamil.dziezyk@arm.com>
-
-From 5499e0fc8082024bf7e2d0facd5c976e82105070 Mon Sep 17 00:00:00 2001
-From: Diego Sueiro <diego.sueiro@arm.com>
-Date: Thu, 20 Aug 2020 11:58:20 +0100
-Subject: [PATCH] tools/hotplug: Fix hostname setting in vif-nat
-
-Setting the hostname is failing because the "$XENBUS_PATH/domain"
-doesn't exist anymore. To fix this we set it to dom$domid
-
-Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
-Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
-Acked-by: Wei Liu <wl@xen.org>
---
- tools/hotplug/Linux/vif-nat | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/tools/hotplug/Linux/vif-nat b/tools/hotplug/Linux/vif-nat
-index a76d9c784b..26144350b3 100644
--- a/tools/hotplug/Linux/vif-nat
-+++ b/tools/hotplug/Linux/vif-nat
-@@ -85,7 +85,7 @@ router_ip=$(routing_ip "$ip")
- # Split the given IP/bits pair.
- vif_ip=`echo ${ip} | awk -F/ '{print $1}'`
- 
-hostname=$(xenstore_read "$XENBUS_PATH/domain" | tr -- '_.:/+' '-----')
-+hostname=dom$domid
- if [ "$vifid" != "1" ]
- then
-   hostname="$hostname-$vifid"
-- 
-2.17.1
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-SRC_URI += "file://0001-vif-nat-fix-hostname.patch \
-           "
-
-PACKAGECONFIG_remove = "\
-    ${@bb.utils.contains('DISTRO_FEATURES', \
-                         'arm-autonomy-host', \
-                         'sdl', '', d)}"
@@ -1,9 +0,0 @@
-# Make Xen machine specific
-# This ensures that sstate is properly handled and that each machine can have
-# its own configuration
-PACKAGE_ARCH = "${MACHINE_ARCH}"
-
-PACKAGECONFIG_remove = "\
-    ${@bb.utils.contains('DISTRO_FEATURES', \
-                         'arm-autonomy-host', \
-                         'sdl', '', d)}"
@@ -1,5 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-4.14:"
-
-SRC_URI += " \
-    file://0001-xen-arm-Throw-messages-for-unknown-FP-SIMD-implement.patch \
-    "
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Rui Miguel Silva	3f7eec27c3	corstone700: add initial recipes Add need configuration and recipes to support the corstone700 in meta-arm. Change-Id: I5df7e224f4079e6d46fdd1051975772952f52ba9 Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>	2019-09-23 13:46:26 +01:00
Tushar Khandelwal	44d3f88ed9	arm: trusted-firmware-a: fix the upstream revision Signed-off-by: Tushar Khandelwal <tushar.khandelwal@arm.com>	2019-09-19 11:02:15 +01:00
Rui Miguel Silva	1fee2e71d8	arm: trusted-firmware-a: fix compilation order Swap the compile order and make the fip to build at the end when there is all the needed targets compiled. Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>	2019-09-16 10:58:18 +01:00
Tushar Khandelwal	912967dcd7	iota: use custom kernel instead of the one from poky tiny Change-Id: I6cf83071d8dfde2d41d4ea3d8ad006ba4bbabda5 Signed-off-by: Tushar Khandelwal <tushar.khandelwal@arm.com>	2019-09-02 15:50:40 +01:00
Rui Miguel Silva	f43c35f07c	arm: add cramfs class and recipes Add cramfs-xip to image types and cramfs tools. Change-Id: I801788c8c73fe354aa526032ae20927a48672cac Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>	2019-09-02 15:50:40 +01:00
Rui Miguel Silva	ebb261e64b	iota: add distro related cofiguration Add distro configuration and images recipes for tiny and core image for iota distribution. Change-Id: I31df5009dbd67b03016150833cc1a6905caa9ca2 Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>	2019-09-02 15:50:40 +01:00
Rui Miguel Silva	f815620455	designstart: add support to a5ds Add first configuration, layers and recipes to support build of a5ds images. Change-Id: Ie6273d0e3feb55471cfc784e62168ce3e2e1f1b6 Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>	2019-09-02 15:50:40 +01:00
Rui Miguel Silva	9f34cbb321	arm: add arm gcc 7.3.1 native support Add native gcc version 7.3.1 to support build of boot-firmware. Change-Id: I0c64c6217f88e667f24155e1a587badfcc097917 Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>	2019-09-02 15:50:40 +01:00
Rui Miguel Silva	7e362ece84	arm: add kernel common recipes add kernel and dtc tool append recipes. Change-Id: Ie29a4e086de83140f09e7a17b5a6278090c610b0 Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>	2019-09-02 15:50:40 +01:00
Rui Miguel Silva	96137096b8	arm: add bsp recipes to common layer Add recipes for common layer for the bsp area, includes trustedfirmware-a, boot-firmware and u-boot recipe append. Change-Id: I447a52750afb02cc170f38d5148fa4b5f5777abc Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>	2019-09-02 15:50:40 +01:00
Rui Miguel Silva	0d2da45a4f	arm: add configuration for common layer Add initial configuration for arm common layerj Change-Id: I59cd6b5d4a1fa31eec4472900dbb0fc52f18c4c4 Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>	2019-09-02 15:50:40 +01:00
Tushar Khandelwal	eafd591407	add license file Signed-off-by: Tushar Khandelwal <tushar.khandelwal@arm.com>	2019-09-02 15:50:40 +01:00
Rui Miguel Silva	cc3c00065b	Initial commit	2019-05-14 14:52:01 +01:00
				`@@ -1 +0,0 @@`
				`XENGUEST_NETWORK_BRIDGE_MEMBERS_gem5-arm64 ?= "eth0"`
				`@@ -1 +0,0 @@`
				`GRUB_BUILDIN += "${@bb.utils.contains('DISTRO_FEATURES', 'xen', 'xen_boot', '', d)}"`