update tags for Corstone-700 2020.02.10 release

Signed-off-by: Avinash Mehta <avinash.mehta@arm.com>
add changes to fetch latest code upstream
2026-07-18 16:37:08 +00:00 · 2020-03-04 10:11:33 +00:00 · 2020-02-05 11:09:38 +00:00 · 2020-01-24 13:52:58 +00:00 · 2020-01-24 13:52:58 +00:00 · 2020-01-24 13:52:58 +00:00
643 changed files with 1209 additions and 52922 deletions
@@ -1,216 +0,0 @@
-image: ghcr.io/siemens/kas/kas
-
-  # First do a common bootstrap, and then build all the targets
-stages:
-  - prep
-  - bootstrap
-  - build
-
-# Common job fragment to get a worker ready
-.setup:
-  stage: build
-  interruptible: true
-  variables:
-    KAS_WORK_DIR: $CI_PROJECT_DIR/work
-    KAS_REPO_REF_DIR: $CI_BUILDS_DIR/persist/repos
-    SSTATE_DIR: $CI_BUILDS_DIR/persist/sstate
-    DL_DIR: $CI_BUILDS_DIR/persist/downloads
-    BB_LOGCONFIG: $CI_PROJECT_DIR/ci/logging.yml
-    TOOLCHAIN_DIR: $CI_BUILDS_DIR/persist/toolchains
-    IMAGE_DIR: $CI_PROJECT_DIR/work/build/tmp/deploy/images
-  before_script:
-    - echo KAS_WORK_DIR = $KAS_WORK_DIR
-    - echo SSTATE_DIR = $SSTATE_DIR
-    - echo DL_DIR = $DL_DIR
-    - rm -rf $KAS_WORK_DIR
-    - mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_DIR $TOOLCHAIN_DIR
-
-# Generalised fragment to do a Kas build
-.build:
-  extends: .setup
-  script:
-    - KASFILES=$(./ci/jobs-to-kas $CI_JOB_NAME)
-    - kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
-    - kas build $KASFILES
-    - ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
-
-#
-# Prep stage, update repositories once
-#
-update-repos:
-  extends: .setup
-  stage: prep
-  script:
-  - flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos
-
-get-binary-toolchains:
-  extends: .setup
-  stage: prep
-  script:
-    - ./ci/get-binary-toolchains $DL_DIR $TOOLCHAIN_DIR
-
-
-#
-# Bootstrap stage, bootstrap and machine coverage
-#
-
-# Build a number of native tools first to ensure the other builders don't race
-# over them
-n1sdp/bootstrap:
-  extends: .build
-  stage: bootstrap
-
-# What percentage of machines in the layer do we build
-machine-coverage:
-  stage: bootstrap
-  interruptible: true
-  script:
-  - ./ci/check-machine-coverage
-  coverage: '/Coverage: \d+/'
-
-
-#
-# Build stage, the actual build jobs
-#
-
-# Validate layers are Yocto Project Compatible
-check-layers:
-  extends: .setup
-  coverage: '/Coverage: \d+/'
-  script:
-  - kas shell --update --force-checkout ci/base.yml:ci/meta-python.yml --command \
-    "$CI_PROJECT_DIR/ci/check-layers.py $CI_PROJECT_DIR/ci/check-layers.yml $CI_PROJECT_DIR $KAS_WORK_DIR"
-
-corstone500:
-  extends: .build
-
-corstone700-fvp:
-  extends: .build
-
-corstone700-mps3:
-  extends: .build
-
-fvp-base:
-  extends: .build
-
-fvp-base-arm32:
-  extends: .build
-
-fvp-base-arm32/external-gccarm:
-  extends: .build
-
-fvp-baser-aemv8r64:
-  extends: .build
-
-gem5-arm64:
-  extends: .build
-
-gem5-arm64-xen:
-  extends: .build
-
-gem5-atp-arm64:
-  extends: .build
-
-generic-arm64:
-  extends: .build
-
-juno:
-  extends: .build
-
-juno/clang:
-  extends: .build
-
-microbit-v1:
-  extends: .build
-
-musca-b1:
-  extends: .build
-
-musca-s1:
-  extends: .build
-
-n1sdp:
-  extends: .build
-
-n1sdp/armgcc:
-  extends: .build
-
-qemu-cortex-a53:
-  extends: .build
-
-qemuarm/testimage:
-  extends: .build
-
-qemuarm64-sbsa:
-  extends: .build
-
-qemuarm64-secureboot/testimage:
-  extends: .build
-
-qemuarm64-secureboot/clang/testimage:
-  extends: .build
-
-qemuarm64-secureboot/clang/musl/testimage:
-  extends: .build
-
-qemuarm64-secureboot/musl/testimage:
-  extends: .build
-
-qemuarmv5/testimage:
-  extends: .build
-
-sgi575:
-  extends: .build
-
-tc0:
-  extends: .build
-
-
-#
-# Utility tasks, not executed automatically
-#
-
-delete-dl-dir:
-  extends: .setup
-  stage: prep
-  when: manual
-  script:
-  - rm -rf $DL_DIR/*
-
-delete-repo-dir:
-  extends: .setup
-  stage: prep
-  when: manual
-  script:
-  - rm -rf $KAS_REPO_REF_DIR/*
-
-# Delete all sstate
-delete-sstate:
-  extends: .setup
-  stage: prep
-  when: manual
-  script:
-  - rm -rf $SSTATE_DIR/*
-
-delete-toolchains:
-  extends: .setup
-  stage: prep
-  when: manual
-  script:
-  - rm -rf $TOOLCHAIN_DIR/*
-
-# Wipe out old sstate
-prune-sstate:
-  extends: .setup
-  stage: prep
-  when: manual
-  script:
-  - find $SSTATE_DIR -type f -atime +30 -delete
-
-# Report on disk usage
-usage:
-  extends: .setup
-  stage: prep
-  when: manual
-  script:
-  - du -h -s $DL_DIR $SSTATE_DIR $KAS_REPO_REF_DIR $TOOLCHAIN_DIR
@@ -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=1dd070c98a281d18d9eefd938729b031"
+
+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
-
-local_conf_header:
-  cc: |
-    GCCVERSION = "arm-10.2"
@@ -1,45 +0,0 @@
-header:
-  version: 9
-
-distro: poky
-
-defaults:
-  repos:
-    refspec: hardknott
-
-repos:
-  meta-arm:
-    layers:
-      meta-arm:
-      meta-arm-bsp:
-      meta-arm-toolchain:
-
-  poky:
-    url: https://git.yoctoproject.org/git/poky
-    layers:
-      meta:
-      meta-poky:
-
-env:
-  BB_LOGCONFIG: ""
-  TOOLCHAIN_DIR: ""
-
-local_conf_header:
-  base: |
-    CONF_VERSION = "1"
-    PACKAGE_CLASSES = "package_ipk"
-    LICENSE_FLAGS_WHITELIST += "armcompiler"
-    PACKAGECONFIG_remove_pn-qemu-system-native = "gtk+ sdl"
-    EXTRA_IMAGE_FEATURES_append = " debug-tweaks"
-    BB_NUMBER_THREADS = "16"
-    PARALLEL_MAKE = "-j16"
-    INHERIT += "rm_work"
-    PACKAGECONFIG_append_pn-perf = " coresight"
-  noptest: |
-    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,43 +0,0 @@
-#! /usr/bin/env python3
-
-import argparse
-import pathlib
-import re
-import subprocess
-import sys
-
-import yaml
-
-if __name__ == "__main__":
-    parser = argparse.ArgumentParser()
-    parser.add_argument("config", type=argparse.FileType())
-    parser.add_argument("metaarm", type=pathlib.Path, help="Path to meta-arm")
-    parser.add_argument("others", type=pathlib.Path, help="Path to parent of dependencies")
-    args = parser.parse_args()
-
-    config = yaml.safe_load(args.config)
-    layers = config["layers"]
-    dependencies = config["dependencies"]
-
-    found_layers = [p for p in args.metaarm.glob("meta-*") if p.is_dir()]
-    print(f"Testing {len(layers)} layers: {', '.join(layers)}.")
-    print(f"Found {len(found_layers)} layers in meta-arm.")
-    print()
-
-    cli = ["yocto-check-layer-wrapper",]
-    cli.extend([args.metaarm / layer for layer in layers])
-    cli.append("--dependency")
-    cli.extend([args.others / layer for layer in dependencies])
-
-    passed = 0
-    process = subprocess.Popen(cli, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, universal_newlines=True)
-    while True:
-        line = process.stdout.readline()
-        if process.poll() is not None:
-            break
-        print(line.strip())
-        if re.search(r"meta-.+ PASS", line):
-            passed += 1
-
-    print(f"Coverage: {int(passed / len(found_layers) * 100)}%")
-    sys.exit(process.returncode)
@@ -1,7 +0,0 @@
-layers:
-  - meta-arm
-  - meta-arm-bsp
-  - meta-arm-toolchain
-  - meta-gem5
-dependencies:
-  - meta-openembedded/meta-oe
@@ -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("ci/*.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,19 +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
-
-LINES=$(grep --invert-match "attempting MIRRORS if available" $LOGFILE | wc -l)
-if test "$LINES" -ne 0; then
-    echo ==============================
-    echo The build had warnings/errors:
-    echo ==============================
-    cat $LOGFILE
-    exit 1
-fi
-
-exit 0
@@ -1,10 +0,0 @@
-header:
-  version: 9
-
-repos:
-  meta-clang:
-    url: https://github.com/kraj/meta-clang
-
-local_conf_header:
-  clang: |
-    TOOLCHAIN = "clang"
@@ -1,6 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: corstone500
@@ -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,8 +0,0 @@
-header:
-  version: 9
-
-local_conf_header:
-  cc: |
-    PNBLACKLIST[gcc-cross-arm] = "Using external toolchain"
-    TCMODE = "external-arm"
-    EXTERNAL_TOOLCHAIN = "${TOOLCHAIN_DIR}/${TARGET_ARCH}"
@@ -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,7 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: fvp-baser-aemv8r64
-
@@ -1,28 +0,0 @@
-
-header:
-  version: 9
-  includes:
-    - base.yml
-    - meta-python.yml
-
-repos:
-  meta-arm:
-    layers:
-      meta-gem5:
-  meta-openembedded:
-    url: https://git.openembedded.org/meta-openembedded
-    layers:
-      meta-oe:
-      meta-filesystems:
-      meta-networking:
-  meta-virtualization:
-    url: git://git.yoctoproject.org/meta-virtualization
-
-machine: gem5-arm64
-
-local_conf_header:
-  meta-virt:
-    DISTRO_FEATURES_append = " virtualization xen"
-
-target:
-  - xen-image-minimal
@@ -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,15 +0,0 @@
-header:
-  version: 9
-  includes:
-    - gem5-arm64.yml
-
-repos:
-  meta-arm:
-    layers:
-      meta-atp:
-
-machine: gem5-atp-arm64
-
-target:
-  - atp-native
-  - core-image-minimal
@@ -1,6 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: generic-arm64
@@ -1,52 +0,0 @@
-#!/bin/bash
-set -u
-
-HOST_ARCH=$(uname -m)
-VER="10.2-2020.11"
-
-DOWNLOAD_DIR=$1
-TOOLCHAIN_DIR=$2
-
-# These should be already created by .bitlab-ci.yml, but do here if run outside of that env
-mkdir -p $DOWNLOAD_DIR $TOOLCHAIN_DIR
-
-if [ $HOST_ARCH = "aarch64" ]; then
-	#AArch64 Linux hosted cross compilers
-
-	#AArch32 target with hard float (arm-none-linux-gnueabihf)
-	wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu-a/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz
-elif [ $HOST_ARCH = "x86_64" ]; then
-	#x86_64 Linux hosted cross compilers
-
-	#AArch32 target with hard float (arm-linux-none-gnueabihf)
-	wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu-a/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz
-
-	#AArch64 GNU/Linux target (aarch64-none-linux-gnu)
-	wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu-a/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-aarch64-none-linux-gnu.tar.xz
-
-	#AArch64 GNU/Linux target (aarch64_be-none-linux-gnu)
-	wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu-a/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-aarch64_be-none-linux-gnu.tar.xz
-else
-	echo "ERROR - Unknown build arch of $HOST_ARCH"
-	exit 1
-fi
-
-for i in arm aarch64 aarch64_be; do
-	if [ ! -f $DOWNLOAD_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz ]; then
-		continue
-	fi
-
-	if [ -d $TOOLCHAIN_DIR/$i ]; then
-		echo "$TOOLCHAIN_DIR/$i EXISTS!"
-		MANIFEST=$(ls $TOOLCHAIN_DIR/$i | grep txt)
-		if [[ $MANIFEST != $VER-$HOST_ARCH-$i-none-linux-gnu*.txt ]]; then
-			echo "Removing old $MANIFEST for $VER-$HOST_ARCH-$i-*.txt toolchain"
-			rm -rf $TOOLCHAIN_DIR/$i
-		fi
-	fi
-
-	if [ ! -d $TOOLCHAIN_DIR/$i ]; then
-		tar -C $TOOLCHAIN_DIR -axvf $DOWNLOAD_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz
-		mv $TOOLCHAIN_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu*/ $TOOLCHAIN_DIR/$i
-	fi
-done
@@ -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 ci/
-PARTS=("${PARTS[@]/#/ci/}")
-
-# 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,10 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-    - meta-zephyr.yml
-
-machine: microbit-v1
-
-target:
-  - zephyr-philosophers
@@ -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,10 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-    - meta-zephyr.yml
-
-machine: qemu-cortex-a53
-
-target:
-  - zephyr-philosophers
@@ -1,6 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: qemuarm
@@ -1,11 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: qemuarm64-sbsa
-
-target:
-  - core-image-base
-  - perf
-  - sbsa-acs
@@ -1,16 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: qemuarm64-secureboot
-
-local_conf_header:
-  bugs: |
-    # Only ping until errors can be resolved
-    TEST_SUITES = "ping"
-
-target:
-  - core-image-base
-  - perf
-  - optee-examples
@@ -1,11 +0,0 @@
-header:
-  version: 9
-  includes:
-    - base.yml
-
-machine: qemuarmv5
-
-local_conf_header:
-  bugs: |
-    # Remove parselogs until errors can be resolved
-    TEST_SUITES_remove = "parselogs"
@@ -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,17 +0,0 @@
-header:
-  version: 9
-
-local_conf_header:
-  testimage: |
-    IMAGE_CLASSES += "testimage"
-    TESTIMAGE_AUTO = "1"
-  slirp: |
-    TEST_RUNQEMUPARAMS = "slirp"
-    TEST_SERVER_IP = "127.0.0.1"
-    QEMU_USE_SLIRP = "1"
-  packages: |
-    IMAGE_FEATURES_append = " ssh-server-dropbear"
-
-# Multiple targets are available, put it down to just one
-target:
-  - core-image-base
@@ -1,43 +0,0 @@
-#! /usr/bin/env python3
-
-# Update clones of the repositories we need in KAS_REPO_REF_DIR to speed up fetches
-
-import sys
-import os
-import subprocess
-import pathlib
-
-def repo_shortname(url):
-    # Taken from Kas (Repo.__getattr__) to ensure the logic is right
-    from urllib.parse import urlparse
-    url = urlparse(url)
-    return ('{url.netloc}{url.path}'
-            .format(url=url)
-            .replace('@', '.')
-            .replace(':', '.')
-            .replace('/', '.')
-            .replace('*', '.'))
-
-repositories = (
-    "https://git.yoctoproject.org/git/poky",
-    "https://git.openembedded.org/meta-openembedded",
-    "https://git.yoctoproject.org/git/meta-virtualization",
-    "https://git.yoctoproject.org/git/meta-zephyr",
-    "https://github.com/kraj/meta-clang",
-)
-
-if __name__ == "__main__":
-    if "KAS_REPO_REF_DIR" not in os.environ:
-        print("KAS_REPO_REF_DIR needs to be set")
-        sys.exit(1)
-
-    base_repodir = pathlib.Path(os.environ["KAS_REPO_REF_DIR"])
-
-    for repo in repositories:
-        repodir = base_repodir / repo_shortname(repo)
-        if repodir.exists():
-            print("Updating %s..." % repo)
-            subprocess.run(["git", "-C", repodir, "fetch"], check=True)
-        else:
-            print("Cloning %s..." % repo)
-            subprocess.run(["git", "clone", "--bare", repo, repodir], check=True)
@@ -1,32 +0,0 @@
-header:
-  version: 9
-
-distro: poky
-machine: fvp-baser-aemv8r64
-
-defaults:
-  repos:
-    refspec: hardknott
-
-repos:
-  meta-arm:
-    layers:
-      meta-arm:
-      meta-arm-bsp:
-      meta-arm-toolchain:
-
-  poky:
-    url: https://git.yoctoproject.org/git/poky
-    layers:
-      meta:
-      meta-poky:
-
-local_conf_header:
-  base: |
-    CONF_VERSION = "1"
-    PACKAGE_CLASSES = "package_ipk"
-    PACKAGECONFIG_remove_pn-qemu-system-native = "gtk+ sdl"
-    EXTRA_IMAGE_FEATURES_append = " debug-tweaks"
-
-target:
-  - core-image-minimal
@@ -1,93 +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 guest
-images.
-
-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)
-* meta-networking (git://git.openembedded.org/meta-openembedded)
-
-Distribution Features
---------------------
-This layer adds the following Yocto DISTRO_FEATURES:
-
-* arm-autonomy-host: this feature activates functionalities required to build
-  an autonomy host system. It has the following effects:
-  - 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](documentation/xenguest-network.md)
-
-BSPs
----
-This layer adds the following machine:
-
-* arm64-autonomy-guest: This machine 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 and xenguest images. This image depends on
- 'arm-autonomy-host' distribution feature.
-
-Recipes and classes
-------------------
-This layer adds 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 used to
-  create and modify images to be used as Xen guests.
-
-* [xenguest-manager](documentation/xenguest-manager.md): This is a tool used to
-  create/remove/start/stop xen guest generated using xenguest-mkimage.
-
-* [xenguest-network](documentation/xenguest-network.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,26 +0,0 @@
-# This class is to be inherited by image recipes that want to build and install
-# an alternate kernel (set via PREFERRED_PROVIDER_alternate/kernel).
-#
-# It is mandatory to also set the KERNEL_PACKAGE_NAME for the alternate kernel
-# recipe via KERNEL_PACKAGE_NAME_pn-${PREFERRED_PROVIDER_alternate/kernel} and
-# its value needs to be different from "kernel" since this is the default set
-# for PREFERRED_PROVIDER_virtual/kernel.
-#
-# An example of these settings can be found at meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/n1sdp-extra-settings.inc
-#
-# When building and installing an alternate kernel, the kernel-modules packages
-# for both virtual/kernel and alternate/kernel will be installed.
-
-PREFERRED_PROVIDER_alternate/kernel ??= ""
-
-python () {
-    alternate_kernel = d.getVar('PREFERRED_PROVIDER_alternate/kernel')
-    if alternate_kernel:
-        alternate_kernel_pkg_name = d.getVar('KERNEL_PACKAGE_NAME_pn-%s' % alternate_kernel)
-        if alternate_kernel_pkg_name:
-            d.appendVar('EXTRA_IMAGEDEPENDS', ' ' + alternate_kernel)
-            d.appendVar('IMAGE_INSTALL', ' kernel-modules')
-            d.appendVar('IMAGE_INSTALL', ' ' + alternate_kernel_pkg_name + '-modules')
-        else:
-            raise bb.parse.SkipRecipe("No KERNEL_PACKAGE_NAME_pn-%s set" % alternate_kernel )
-}
@@ -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,115 +0,0 @@
-# Docker Extern Containers
-#
-# This class allows docker image tarballs to be installed in the rootfs
-#
-# The images can be selected using the variable CONTAINER_IMAGE_FILES which
-# should contain a space seperated list of absolute paths or yocto urls for
-# docker images that have been exported using docker export:
-# - https://docs.docker.com/engine/reference/commandline/export/
-#
-# src_uri_parse_var.bbclass is used to parse CONTAINER_IMAGE_FILES
-#
-# There are 4 supported formats for CONTAINER_IMAGE_FILES entries:
-#
-# - http/https url
-#   - CONTAINER_IMAGE_FILES = "https://[url]:[port]/alpine.tar;md5sum=..."
-#
-# - file:// absolute local path from root
-#   - CONTAINER_IMAGE_FILES = "file:///containers/alpine2.tar"
-#
-# - file:// path relative to FILESEXTRAPATHS
-#   - CONTAINER_IMAGE_FILES = "file://foo/alpine3.tar"
-#     FILESEXTRAPATHS .= "/containers:"
-#
-# - plain absolute local path from root
-#   - CONTAINER_IMAGE_FILES = "/containers/foo/bar/alpine4.tar"
-#
-# It is not recommended to use other yocto URL types, as they may result in
-# undefined behaviour.
-#
-# A semicolon seperated list of install arguments can follow each image path:
-# - conname : the name that will be attached when the image is imported
-#             (default: [filename, without extension])
-# - contag  : the tag that will be attached when the image is imported
-#             (default: local)
-# - conkeep : Flag for whether the exported container image file should be
-#             kept once the import has been completed
-#             (default: 0)
-#
-# Any other arguments, for example an md5sum, will be assumed to be fetch
-# arguments, and will be kept when the path is added to the SRC_URI
-#
-# e.g.  CONTAINER_IMAGE_FILES = "\
-# https://[url]:[port]/alpine.tar;md5sum=[checksum];conkeep=1 \
-# file:///containers/alpine2.tar;contag=latest;conname=docker2 \
-# file://foo/alpine3.tar \
-# /containers/foo/bar/alpine4.tar;contag=1.0;conkeep=1 "
-#
-# Resulting Manifest:
-# ARCHIVE     NAME    TAG    KEEP
-# alpine.tar  alpine  local  1
-# alpine2.tar docker2 latest 0
-# alpine3.tar alpine3 local  0
-# alpine4.tar alpine4 1.0    1
-#
-# Other configurable variables:
-# CONTAINERS_INSTALL_DIR  : The folder underneath ${WORKDIR} where the docker
-#                           images will be stored
-#                           (default: "/usr/share/docker/images")
-# CONTAINERS_MANIFEST     : The name of the manifest file containing image
-#                           parameters, also stored in CONTAINERS_INSTALL_DIR
-#                           (default: "containers.manifest")
-# CONTAINERS_TAG_DEFAULT  : Use this to change the value that will be used as
-#                           contag if no value is provided
-#                           (default: "local")
-# CONTAINERS_KEEP_DEFAULT : Use this to change the value that will be used for
-#                           conkeep if no value is provided
-#                           (default: "0")
-#
-
-inherit features_check
-
-REQUIRED_DISTRO_FEATURES = "docker"
-
-RDEPENDS_${PN} = "packagegroup-docker-runtime-minimal"
-
-CONTAINER_IMAGE_FILES ??= ""
-CONTAINERS_INSTALL_DIR ??= "${datadir}/docker/images"
-CONTAINERS_MANIFEST ??= "containers.manifest"
-CONTAINERS_TAG_DEFAULT ??= "local"
-CONTAINERS_KEEP_DEFAULT ??= "0"
-
-inherit set_src_uri_from_var
-
-SRC_URI_FROM_VAR_NAME = "CONTAINER_IMAGE_FILES"
-# Define installation params
-SRC_URI_FROM_VAR_MANIFEST_PARAMS = "conname=[basename] \
-contag=${CONTAINERS_TAG_DEFAULT} conkeep=${CONTAINERS_KEEP_DEFAULT}"
-
-SRC_URI_FROM_VAR_UNPACK_DIR = "containers"
-
-# Read manifest and install container images
-do_install() {
-    local archive name tag keep
-
-    if [ -f "${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/manifest" ]; then
-
-        install -d "${D}${CONTAINERS_INSTALL_DIR}"
-        install -m 644 \
-            "${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/manifest" \
-            "${D}${CONTAINERS_INSTALL_DIR}/${CONTAINERS_MANIFEST}"
-
-        while read -r archive name tag keep _; do
-            [ -f "${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/${archive}" ] ||
-                bbfatal "${archive} does not exist"
-
-            install -m 644 \
-                "${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/${archive}" \
-                "${D}${CONTAINERS_INSTALL_DIR}/${archive}"
-        done < "${D}${CONTAINERS_INSTALL_DIR}/${CONTAINERS_MANIFEST}"
-    fi
-}
-
-do_install[vardeps] += "CONTAINER_IMAGE_FILES"
-
-FILES_${PN} += "${CONTAINERS_INSTALL_DIR}"
@@ -1,169 +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"
-
-XENGUEST_IMAGE_RECIPE = "${PN}"
-XENGUEST_IMAGE_VARS += "XENGUEST_IMAGE_RECIPE"
-
-# Merge intermediate env files from all recipes into a single file
-python do_merge_xenguestenv () {
-
-    import re
-
-    # Open final merged file in DEPLOY_DIR_IMAGE for writing, or create
-    outdir = d.getVar('DEPLOY_DIR_IMAGE')
-    with open(os.path.join(outdir,'xenguest.env'), 'w') as merged_file:
-
-        # Adds vars from xenguest_image to list
-        merged_env = []
-        xenguest_vars = d.getVar('XENGUEST_IMAGE_VARS')
-        for var in xenguest_vars.split():
-            value = d.getVar(var)
-            if value:
-                merged_env.append(var + "=" + " ".join(value.split()) + "\n")
-
-        # Resolve dependencies for this task to find names of intermediate
-        # .xenguestenv files
-        taskdepdata = d.getVar('BB_TASKDEPDATA')
-        task_mc = d.getVar('BB_CURRENT_MC')
-        task_file = d.getVar('FILE')
-
-        # See runqueue.py function build_taskdepdata
-        DEPS_INDEX = 3
-
-        depdata_key = task_file + ":do_merge_xenguestenv"
-
-        # If in a multiconfig, need to add that to the key
-        if task_mc != "default":
-            depdata_key = "mc:" + task_mc + ":" + depdata_key
-
-        # Retrieve filename using regex
-        get_filename = re.compile(r'/([^/]+\.bb):do_deploy_xenguestenv$')
-        env_dir = d.getVar('XENGUEST_ENV_STAGING_DIR')
-
-        for task_dep in taskdepdata[depdata_key][DEPS_INDEX]:
-            if task_dep.endswith(":do_deploy_xenguestenv"):
-                filename = re.search(get_filename, task_dep).group(1) + ".xenguestenv"
-                bb.note("Merging: " + filename)
-                try:
-                    with open(env_dir + "/" + filename, 'r') as f:
-                        # Eliminate duplicates
-                        merged_env = list(set(merged_env + f.readlines()))
-                except (FileNotFoundError, IOError):
-                    bb.note(" " + filename + " has no extra vars")
-
-        # Sort Alphabetically and write
-        merged_env.sort()
-        merged_file.write("".join(merged_env))
-}
-do_merge_xenguestenv[dirs] = "${DEPLOY_DIR_IMAGE}"
-do_merge_xenguestenv[vardeps] += "${XENGUEST_IMAGE_VARS}"
-do_merge_xenguestenv[vardepsexclude] += "BB_TASKDEPDATA"
-do_merge_xenguestenv[recrdeptask] += "do_deploy_xenguestenv"
-
-addtask merge_xenguestenv before do_populate_lic_deploy after do_image_complete
-
-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,37 +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
-
-# Add a variable name to XENGUEST_IMAGE_VARS_EXTRA if you want it to
-# appear in xenguest.env when the image is deployed
-
-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_merge_xenguestenv"
-
-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,224 +0,0 @@
-# Set SRC_URI from Variable
-
-# This class parses a variable named in SRC_URI_FROM_VAR_NAME for entries that
-# should be added to the SRC_URI
-#
-# There are 4 supported formats for entries:
-#
-# - http/https url
-#   - Note that a checksum (md5sum or sha256sum) must be provided for http(s)
-#
-# - file:// absolute local path from root
-#   - In this case the filename will be added to SRC_URI and the path from '/'
-#   added to FILESEXTRAPATHS
-#
-# - file:// path relative to FILESEXTRAPATHS
-#   - In this case the filename will be added to SRC_URI and the preceding path
-#   added to FILESOVERRIDES, so that the full path to the file will
-#   be available in FILESPATH when it is generated by combining
-#   FILESEXTRAPATHS and FILESOVERRIDES.
-#
-# - plain absolute local path from root
-#   - This will be treated the same as an file:// path from root. Plain paths
-#   must be absolute, and cannot be relative to FILESEXTRAPATHS
-#
-# It is not recommended to use other yocto URL types, as they may result in
-# undefined behaviour.
-#
-# These entries will be added to the SRC_URI so that the yocto fetcher can
-# unpack a copy into ${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}
-#
-#
-# A list of arguments can follow each entry in the input variable, seperated
-# by semi-colons (;). Arguments may be FETCH arguments or MANIFEST arguments.
-#
-# FETCH arguments will be appended to the entry in SRC_URI, for example
-# "downloadfilename" to specify the filename used when storing a
-# downloaded file.
-# Each SRC_URI entry will automatically have the arguments
-# "unpack=0;subdir=${SRC_URI_FROM_VAR_UNPACK_DIR}" added to them, so do not
-# attempt to set these options.
-#
-# MANIFEST arguments are defined in the variable
-# SRC_URI_FROM_VAR_MANIFEST_PARAMS which should be a space seperated list of
-# names, each optionally followed by an equals sign (=) and a default value.
-#
-# The values provided for the manifest arguments will be written to the manifest
-# file in ${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR} as columns, in the same
-# order as they appear in SRC_URI_FROM_VAR_MANIFEST_PARAMS.
-#
-# For entries that do not provide a value for a manifest argument, the default
-# value will be used if possible.
-# If no default is availale, omitting the parameter on any item will cause
-# an error.
-#
-# "[basename]" is a special case default that will set the value to
-# the filename without the path or file extension.
-#
-# e.g.
-# SRC_URI_FROM_VAR_MANIFEST_PARAMS="conname=[basename] contag=local conkeep"
-#
-# Any arguments that follow an entry in SRC_URI_FROM_VAR_NAME, that are not
-# named in SRC_URI_FROM_VAR_MANIFEST_PARAMS are assumed to be FETCH arguments,
-# so are added to the corresponding entry in the SRC_URI.
-
-SRC_URI_FROM_VAR_NAME ??= ""
-SRC_URI_FROM_VAR_MANIFEST_PARAMS ??= ""
-SRC_URI_FROM_VAR_UNPACK_DIR ??= "items"
-
-python __anonymous() {
-
-    parse_var = d.getVar('SRC_URI_FROM_VAR_NAME')
-
-    if not parse_var:
-        return
-
-    parse_var_items = d.getVar(parse_var)
-
-    if parse_var_items:
-        for item in parse_var_items.split(' '):
-            if not item:
-                continue
-
-            if item.startswith('/'):
-                # If not a Yocto URL, must be an absolute path
-                yocto_url = "file://" + item
-            else:
-                # Otherwise assume valid Yocto URL.
-                # Error case is caught later
-                yocto_url = item
-
-            fetcher = host = path = parm = None
-            try:
-                # Attempt to parse a Yocto URL
-                fetcher,host,path,_,_,parm = bb.fetch.decodeurl(yocto_url)
-            except:
-                # Something invalid is in the variable!
-                raise bb.parse.SkipRecipe(parse_var + \
-                                          " contains an invalid entry:\n'" + \
-                                          item + "'")
-
-            # This var is space seperated list of parameter names,
-            # with optional default value following an equals sign
-            # (name=default)
-            item_params_str = d.getVar('SRC_URI_FROM_VAR_MANIFEST_PARAMS')
-
-            # remove directories from path
-            filename = os.path.basename(path)
-
-            if "downloadfilename" in parm:
-                filename = parm["downloadfilename"]
-
-            item_manifest_args = {"filename": filename}
-
-            if item_params_str:
-                # required manifest arguments have been provided
-
-                # If no default is given add "=" for map parsing
-                item_params_list = [ arg + "=" if '=' not in arg
-                                     else arg
-                                     for arg in item_params_str.split(' ')
-                                   ]
-
-                # Generate key value pairs of argument names and
-                # default values
-                item_params_map = dict( (name.strip(), val.strip())
-                                        for name, val in (arg.split('=')
-                                        for arg in item_params_list)
-                                      )
-
-                for argname in item_params_map:
-                    # Iterate over required manifest arguments
-
-                    argvalue = parm.pop(argname, None)
-                    if argvalue:
-                        # a value has been provided for this item
-                        item_manifest_args[argname] = argvalue
-
-                    else:
-                        # No value provided, process default value
-                        default = item_params_map[argname]
-                        if default:
-                            # A default value is provided
-                            if default == "[basename]":
-                                # use the filename without extension
-                                default = os.path.splitext(filename)[0]
-
-                            # store default value in dict
-                            item_manifest_args[argname] = default
-
-                        else:
-                            # No default provided
-                            raise bb.fatal(parse_var + \
-                              " entry is missing a required parameter '" + \
-                              argname + "':\n'" + item + "'")
-
-            # Write value to var flags to ensure data structure is preserved
-            # Each entry of parse_var will have a varflag  where the value
-            # is a dictionary of argument names and values
-            d.setVarFlags(parse_var, {item: item_manifest_args})
-
-            src_uri_entry_suffix = ';'
-
-            # HTTP(S) fetcher must provide a checksum
-            if fetcher.startswith('http') and not \
-            ( 'md5sum' in parm or 'sha256sum' in parm ):
-                # Ensure http/https fetchers get a checksum
-                raise bb.parse.SkipRecipe(parse_var + \
-                                          " entry is missing a checksum:\n'" + \
-                                          item + "'")
-
-            # add remaining fetch parameters including checksum
-            for arg in parm:
-                src_uri_entry_suffix += ";" + arg + "=" + parm[arg]
-
-            # Add default and extra parameters to SRC_URI entry
-            src_uri_entry_suffix += ';unpack=0;subdir=' + \
-                                    d.getVar('SRC_URI_FROM_VAR_UNPACK_DIR')
-
-            if fetcher == 'file':
-                # Prevent local fetcher from re-creating dir structure
-                filedir = os.path.split(path)[0]
-                if filedir.startswith('/'):
-                    # Path is from the root
-                    d.appendVar('FILESEXTRAPATHS', filedir + ':')
-                else:
-                    # Path is relative to FILESEXTRAPATHS
-                    d.appendVar('FILESOVERRIDES', ':' + filedir)
-
-                # Add filename without path to SRC_URI
-                d.appendVar('SRC_URI', ' file://' + \
-                                        filename + src_uri_entry_suffix)
-            else:
-                # Add full entry to SRC_URI
-                d.appendVar('SRC_URI', ' ' + fetcher + \
-                            "://" + host + path + src_uri_entry_suffix)
-}
-
-python generate_manifest() {
-
-    parse_var = d.getVar('SRC_URI_FROM_VAR_NAME')
-
-    if not parse_var:
-        return
-
-    target_dir = os.path.join(d.getVar('WORKDIR'),
-                              d.getVar('SRC_URI_FROM_VAR_UNPACK_DIR'))
-
-    # Write a manifest file containing the parameters so SRC_URI
-    # doesn't need to be parsed by do_install
-    with open (target_dir + "/manifest", 'w') as manifest_file:
-        manifest_args = d.getVarFlags(parse_var)
-
-        parse_var_items = d.getVar(parse_var)
-
-        if parse_var_items:
-            for item in parse_var_items.split():
-
-                manifest_file.write(" ".join(manifest_args[item].values())+"\n")
-
-}
-
-do_unpack[cleandirs] += "${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}"
-do_unpack[postfuncs] += "generate_manifest"
-do_unpack[vardeps] += "${SRC_URI_FROM_VAR_NAME}"
@@ -1,251 +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'}"
-
-# set empty partition to be used by xenguest-manager for this image
-XENGUEST_IMAGE_DISK_DEVICE ??= ""
-
-#
-# XENGUEST_IMAGE_DISK_PARTITIONS is used to describe the partitions to setup
-# and their content.
-# It must be set to a space separated list of entries with each entry having
-# the format num:sz:[fs]:[file] where:
-# - num is a partition number
-# - sz is the partition size in MB or GB(default), e.g 1000M or 1[G]
-# - fs is optional filesystem to use for the partition
-# - file is optionally pointing to a file to use as content of the partition
-#   Please check image_types_xenguest.bbclass for rootfs handling of files
-#
-# Default value creates a partition 1 using the full disk, formated with ext4
-# and containing the root filesystem produced by Yocto
-XENGUEST_IMAGE_DISK_PARTITIONS ??= "1:${XENGUEST_IMAGE_DISK_SIZE}:ext4:rootfs.tar.gz"
-
-# XENGUEST_IMAGE_NETWORK_TYPE can be set to "bridge", "nat" or "none".
-# The "bridge" type will share the physical eth interface from dom0 with the
-# domU. This will allow the domU to have access to the external network.
-# The "nat" type will setup a virtual network between dom0 and domU and also
-# configure and run the kea dhcp4 server on dom0 to serve the domU.
-# The "none" type will not affect any networking setting between on dom0 and
-# domU.
-XENGUEST_IMAGE_NETWORK_TYPE ??= "bridge"
-
-# Sub-directory in wich the guest is created. This is create in deploy as a
-# subdirectory and must be coherent between all components using this class so
-# it must only be modified from local.conf if needed
-XENGUEST_IMAGE_DEPLOY_SUBDIR ?= "xenguest"
-
-# Directory in which the xenguest should be deployed
-# a sub-directory named ${XENGUEST_IMAGE_DEPLOY_SUBDIR} will be created there.
-# This should be set to:
-# - ${DEPLOYDIR} (default) if creating or extending the xenguest for a normal
-#   recipe.
-# - something in ${WORKDIR} if you need to clone and manipulate an image
-XENGUEST_IMAGE_DEPLOY_DIR ??= "${DEPLOYDIR}"
-
-# These vars are used by image_types_xenguest.bbclass to generate the
-# xenguest.env file. In a recipe that inherits this class and extra variables
-# that should be included in xenguest.env need to be added to
-# XENGUEST_IMAGE_VARS_EXTRA
-XENGUEST_IMAGE_VARS ?= "\
- MACHINE DISTRO DISTRO_VERSION DISTRO_FEATURES TUNE_FEATURES TARGET_FPU \
- IMAGE_FEATURES INITRAMFS_IMAGE_BUNDLE INITRAMFS_IMAGE \
- XENGUEST_IMAGE_MEMORY_SIZE XENGUEST_IMAGE_NUM_VCPUS XENGUEST_IMAGE_AUTOBOOT \
- XENGUEST_IMAGE_ROOT XENGUEST_IMAGE_CMDLINE XENGUEST_IMAGE_EXTRA_CMD \
- XENGUEST_IMAGE_KERNEL XENGUEST_IMAGE_DISK_SIZE XENGUEST_IMAGE_DISK_DEVICE \
- XENGUEST_IMAGE_DISK_PARTITIONS XENGUEST_IMAGE_NETWORK_TYPE"
-
-#
-# Wrapper to call xenguest-mkimage
-# It is using XENGUEST_IMAGE_DEPLOY_DIR and XENGUEST_IMAGE_DEPLOY_SUBDIR
-# to find the image to operate on
-#
-# Usage: call_xenguest_mkimage [operation] [args]
-call_xenguest_mkimage() {
-    local cmd="${1}"
-    local img="${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}"
-    shift
-
-    echo "xenguest-mkimage $cmd $img $@"
-    xenguest-mkimage $cmd $img $@
-}
-
-#
-# Create an initial xenguest image.
-# This is a task which must be added in a recipe inheriting deploy
-# It is using XENGUEST_IMAGE_MEMORY_SIZE, XENGUEST_IMAGE_NUM_VCPUS,
-#  XENGUEST_IMAGE_AUTOBOOT, XENGUEST_IMAGE_ROOT, XENGUEST_IMAGE_EXTRA_CMD,
-#  XENGUEST_IMAGE_CMDLINE, XENGUEST_IMAGE_DISK_SIZE and
-#  XENGUEST_IMAGE_DISK_PARTITIONS to customize the initial guest
-#
-xenguest_image_create() {
-    if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
-        -z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
-        die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
-    fi
-
-    rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
-
-    mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
-
-    # Create the image
-    call_xenguest_mkimage create --xen-memory=${XENGUEST_IMAGE_MEMORY_SIZE} \
-        --xen-vcpus=${XENGUEST_IMAGE_NUM_VCPUS} \
-        --xen-root=${XENGUEST_IMAGE_ROOT} \
-        ${XENGUEST_IMAGE_EXTRA_CMD}
-
-    # add command line
-    if [ -n "${XENGUEST_IMAGE_CMDLINE}" ]; then
-        call_xenguest_mkimage update --xen-clean-extra
-        for arg in ${XENGUEST_IMAGE_CMDLINE}; do
-            call_xenguest_mkimage update --xen-extra=$arg
-        done
-    fi
-
-    # create disk if needed
-    disksize="${XENGUEST_IMAGE_DISK_SIZE}"
-    case ${disksize:=0} in
-        0|0M|0G)
-            ;;
-        *)
-            # setup disk size
-            call_xenguest_mkimage update --disk-reset-config --disk-size=$disksize
-
-            diskparts="${XENGUEST_IMAGE_DISK_PARTITIONS}"
-            if [ -n "$diskparts" ]; then
-                for arg in $diskparts; do
-                    call_xenguest_mkimage update --disk-add-part=$arg
-                done
-            fi
-            diskdevice="${XENGUEST_IMAGE_DISK_DEVICE}"
-            if [ -n "$diskdevice" ]; then
-                call_xenguest_mkimage update --disk-device="${diskdevice}"
-            fi
-
-            ;;
-    esac
-
-
-    if [ "${XENGUEST_IMAGE_AUTOBOOT}" = "1" ]; then
-        call_xenguest_mkimage update --set-param=GUEST_AUTOBOOT=1
-    else
-        call_xenguest_mkimage update --set-param=GUEST_AUTOBOOT=0
-    fi
-
-    if [ -n "${XENGUEST_IMAGE_NETWORK_TYPE}" ]; then
-        call_xenguest_mkimage update --set-param=XENGUEST_NETWORK_TYPE="${XENGUEST_IMAGE_NETWORK_TYPE}"
-    else
-        call_xenguest_mkimage update --set-param=XENGUEST_NETWORK_TYPE="none"
-    fi
-}
-
-XENGUEST_ENV_STAGING_DIR ??= "${STAGING_DIR}/${MACHINE}/xenguestenv"
-
-# Create an intermediary file containing all variables used to by a
-# particular recipe that inherits this class
-
-# File will contain the values of all variables listed in:
-#   XENGUEST_IMAGE_VARS_EXTRA
-python do_deploy_xenguestenv () {
-    xenguest_vars = d.getVar('XENGUEST_IMAGE_VARS_EXTRA')
-    if not xenguest_vars:
-        return
-
-    outdir = d.getVar('XENGUEST_ENV_STAGING_DIR')
-
-    # Writes file to tmp/sysroots/${MACHINE}/xenguestenv/ by default
-    filename = os.path.basename(d.getVar('FILE')) + '.xenguestenv'
-    with open(os.path.join(outdir, filename), 'w') as envf:
-        for var in xenguest_vars.split():
-            value = d.getVar(var)
-            if value:
-                # Write value only if set
-                envf.write('%s="%s"\n' % (var, " ".join(value.split())))
-        envf.close()
-}
-
-# Since the intermediary file is deleted by do_merge_xenguestenv it
-# must be re-created every time
-do_deploy_xenguestenv[vardeps] += "${XENGUEST_IMAGE_VARS_EXTRA}"
-do_deploy_xenguestenv[dirs] = "${XENGUEST_ENV_STAGING_DIR}"
-
-addtask deploy_xenguestenv before do_populate_sysroot
-
-# 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,123 +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)
-
-# Add a variable name to XENGUEST_IMAGE_VARS_EXTRA if you want it to
-# appear in xenguest.env when the image is deployed
-
-# 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 ??= ""
-
-# Extra vars to be written to xenguest.env
-XENGUEST_IMAGE_VARS_EXTRA += "\
- XENGUEST_EXTRA_DTB XENGUEST_EXTRA_RAMDISK XENGUEST_EXTRA_XENCONFIG \
- XENGUEST_EXTRA_INIT_PRE XENGUEST_EXTRA_INIT XENGUEST_EXTRA_INIT_POST \
- XENGUEST_EXTRA_FILES 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,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,26 +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"
-
-# Since meta-virtualization master branch bumped to 4.15+stable we need to
-# force the 4.14+stable selection until we validate the new version
-PREFERRED_VERSION_xen = "4.14+stable%"
-PREFERRED_VERSION_xen-tools = "4.14+stable%"
-
-# 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 = "5"
-LAYERDEPENDS_meta-arm-autonomy = " \
-   core \
-   yocto \
-   openembedded-layer \
-   networking-layer \
-   virtualization-layer \
-"
-LAYERSERIES_COMPAT_meta-arm-autonomy = "hardknott"
-
-# 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-arm-bsp:${LAYERDIR}/dynamic-layers/meta-arm-bsp/*/*/*.bb \
-"
-# 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.10%"
-
-DISTRO_FEATURES += "arm-autonomy-guest"
-
@@ -1,5 +0,0 @@
-# This file will be required by different xenguest recipes to provide
-# common variables, which can be configured in local.conf
-
-# Xenguest image file install location
-XENGUEST_MANAGER_GUEST_DIR ?= "${datadir}/guests/"
@@ -1,226 +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
----------------
-
-The steps required to make the project build both the host and any
-number of guests as required are:
-
-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 are specific to either the
-host or the guest. The resulting directory tree should be:
-
-```
-- 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 override 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_merge_xenguestenv'}"
-
-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
-```
-
-To modify the MACHINE or INITRAMFS variables change the equivalent
-config in local.conf rather than modifying this file directly. You can also
-append any other config desired for the guest after "ANY OTHER GUEST CONFIG",
-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"
-
-# ANY OTHER HOST CONFIG
-```
-
-Building the image
----------------
-
-To build the multiconfig image the command is:
-```
-bitbake mc:host:arm-autonomy-host-image-minimal
-```
-
-The first time this is run you may see a warning related to the SRC_URI:
-```
-Unable to get checksum for xenguest-extern-guests SRC_URI entry foo.xenguest: file could not be found
-```
-
-This is expected, and only indicates that the guest image has not yet been
-generated when the host parses the SRC_URI. By the time it is needed by the
-host recipe fetch task it will be present.
-
-During the build you should see that guest tasks are also being executed 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 final host image including the guests will be deployed in
-`host/deploy/images/`
-
-
-Multiple Guests
----------------
-
-To have multiple guests with the same config the line which appends to
-`ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS` just needs to pass the argument
-'guestcount=#' to install symlink copies of the xenguest file on the host.
-Documentation for the guestcount parameter can be found in
-documentation/arm-autonomy-quickstart.md in the section titled
-'Include guests directly in the host image'. This will ensure that the guest
-is still only built once, despite resulting in multiple copies on the target.
-
-If guests are required to have different configurations, each will need its own
-config file, e.g. 'netguest.conf'. Ensure that the name of the conf file does
-not contain any hyphens, as this will create errors when it becomes part of a
-function name. In this file the values of TMPDIR, MACHINE, DISTRO_FEATURES etc.
-should be the same as above, but with the prefix "MC_GUEST_*" modified to
-something different to avoid collisions (e.g. MC_GUEST_2_*).
-
-As before, your additional config for the guest type should
-follow "ANY OTHER GUEST CONFIG"
-
-In your local.conf, everything between `---Guest Config Start---` and
-`---Guest Config End---` will need to be duplicated for each desired guest type.
-All copies of variables that start `MC_GUEST` must be modified with the same
-prefix as in the new guest config file (e.g. `MC_GUEST_2_*`).
-
-Each chunk of guest config in local.conf has automatic guest variables
-(found after the line "These variables are set automatically...").
-These should all use the same prefix as their chunk in their values,
-for example:
-```
-MC_GUEST_2_FILENAME_PREFIX = "${@ 'Image-initramfs' if d.getVar('MC_GUEST_2_INITRAMFS_IMAGE_BUNDLE',d) else '${MC_GUEST_2_IMAGERECIPE}' }"
-```
-
-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 your host.conf file.
-
-The rest of the configuration has to be appended to guest.conf file:
-
-```
-# ANY OTHER GUEST CONFIG
-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"
-```
-
-Example 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,272 +0,0 @@
-arm-autonomy Quick Start
-==================
-
-This documentation explains how to quickly start with the arm-autonomy layer,
-and the main features provided.
-In the documentation directory you will find 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 hardknott using `git checkout hardknott`).
-
-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 a u-boot base board for machines other than FVP-Base
-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 instead 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. Optionally add layers required to build the guest image, and any 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, as well as a file "xenguest.env" containing the
-variables used to configure and generate the guest image.
-
-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 one or more images generated by
-guest projects in the host project.
-
-To use this feature, you must edit your host project `local.conf` file and
-add set the value of 'ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS' to the list of
-paths to xenguest images you want to include in your host.
-
-There are 4 supported formats for ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS
-entries:
-
- http/https url
-  - "https://[url]:[port]/foo.xenguest;md5sum=..."
-
- file:// absolute local path from root
-  - "file:///xenguests/bar.xenguest"
-
- file:// path relative to FILESEXTRAPATHS
- - "file://relative/baz.xenguest"
-
- plain absolute local path from root
-  - "/xenguests/absolute/xyzzy.xenguest"
-
-It is not recommended to use other bitbake URL types, as they may result in
-undefined behaviour.
-
-A semicolon seperated list of install arguments can follow each image path:
- guestname  : the name that will be attached when the image is imported
-               (default: [filename, without extension])
- guestcount : the number of copies of the guest to install, with
-               incrementing numbers appended to the name
-               (default: 1)
-
-Any other arguments, for example an md5sum, will be assumed to be fetch
-arguments, and will be appended to the path in the SRC_URI.
-For example:
-```
-ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS = "\
-https://[url]:[port]/base.xenguest;md5sum=[checksum];guestname=http \
-file:///guests/base.xenguest;guestname=file_abs \
-file://foo/base.xenguest;guestname=file_rel;guestcount=2 \
-/guests/foo/bar/base.xenguest;guestname=no_fetcher \ "
-```
-
-Documentation for setting up a multiconfig build can be found in:
-meta-arm-autonomy/documentation/arm-autonomy-multiconfig.md
-
-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 creates guest storage drives 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 creates a bridge on the host and adds network
-interfaces to it so that guests 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.bbappend` for
-exmaples.
-
-Please also read xenguest-network-bridge.md.
-
-### Define the network configuration of the xenguest network bridge
-xenguest-network puts the host network interfaces in a bridge and configures it
-by default to use dhcp.
-If you need a different type of configuration you can set
-XENGUEST_NETWORK_BRIDGE_CONFIG in your 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
-the SRC_URI in your bbappend.
-The recipe will also substitute `###BRIDGE_NAME###` with the bridge name
-configured in ${XENGUEST_NETWORK_BRIDGE_NAME} when the config file is installed.
-
-You can find an example configuration file in
-`recipes-extended/xenguest/files/xenguest-network-bridge-dhcp.cfg.in`.
-
-Please also read xenguest-network.md.
-
-### Customize Dom0 and Xen boot arguments for you board
-xen-devicetree modifies 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,34 +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. Set the boot partition size (default: 100M) via `BOOT_PART_SIZE` and
-   `BOOT_PART_SIZE_UNIT` (M or G) variables in any conf file. The default
-   bootimg is ~44M so 100M leaves just over 50M of free space.
-
-3. The wic image partition layout and contents with a custom wks file via
-   `ARM_AUTONOMY_WKS_FILE` variable (default:
-   arm-autonomy-n1sdp-efidisk.wks.in which is affected by GUEST_PART_SIZE,
-   GUEST_PART_SIZE_UNIT, BOOT_PART_SIZE, BOOT_PART_SIZE_UNIT and
-   GRUB_CFG_FILE variables).
-
-4. Custom grub.cfg file via `GRUB_CFG_FILE` (default:
-   arm-autonomy-n1sdp-grub.cfg) variable to be set in any conf file. The full
-   path or relative to `ARM_AUTONOMY_WKS_FILE` should be set.
-
-The `arm-autonomy-n1sdp-efidisk.wks.in` and `arm-autonomy-n1sdp-grub.cfg` files
-are located at `meta-arm-autonomy/dynamic-layers/meta-arm-bsp/wic`.
-
-Other variables can also be customized 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,110 +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 you 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,max:1024", and cannot be empty.
-  The value can simply specify a size, e.g. "1024M", but best practice is to
-  also provide a max, documented here:
-  https://wiki.xenproject.org/wiki/Xen_Project_Best_Practices
-
- 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", and cannot be empty.
-  Values for this variable can be in hex (prefixed with '0x') or in decimal.
-
- 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" and cannot be empty.
-  Values for this variable can be in hex (prefixed with '0x') or in decimal.
-
- 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,144 +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 can:
- 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 [-v(v)] 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.
-
-Passing -v or -vv will increase the logging written to the logfile.
-The terminal will always show only error messages, regardless of the logfile.
-
-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).
-This config will be written to a file xenguest-manager.conf in /etc/xenguest/.
-
-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".
-
- XENGUEST_MANAGER_LOG_LEVEL: Set the default log level for xenguest manager.
-  Must be one of ERROR, INFO, VERBOSE (default: ERROR). The logs will be
-  written to /var/log/xenguest.
-
-  If a verbosity argument (-v or -vv) is passed to xenguest-manager directly, it
-  will override the setting in xenguest-manager.conf
-
-  Since /var/log is by default a volatile location, extra configuration is
-  required if logs are desired to be kept between reboots:
-    VOLATILE_LOG_DIR="no"
-
-  Read more here: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-VOLATILE_LOG_DIR
-
-  When this is enabled, logrotate will monitor the file to ensure it does not
-  grow excessively large. See recipes-extended/xenguest/files/logrotate-xenguest
-
-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
-
- log()           : Used to write a log to the logfile, default level INFO.
-                    Takes an optional log level and a message body
-                    e.g. log ERROR "blah"
-
-                    Options for log level: ERROR, INFO, VERBOSE,
-                    and FATAL which will call exit 1 immediately after logging
-                    the message at level ERROR.
-
- log_command()   : Used to call a shell command and log that it has been
-                    called, as well as capturing both stdout and stderr.
-
-                    By default the command output is dumped to the logfile as an
-                    error if the command returns a status > 0, or as a verbose
-                    message if the whole script is running in verbose mode.
-
-                    An optional log level can be passed to alter the level the
-                    log should be if the command returns a status >0, which may
-                    be useful if the command is expected to return a non-zero
-                    result.
-                    e.g. log_command INFO "ls -lh ~"
-
-                    Options for log level: ERROR, INFO, and VERBOSE
-
-Attempting to call any other functions from xenguest_manager in an init script
-may result in a fatal error, from which cleanup is not guarenteed.
-
-
-Init scripts also have access to config variables defined in 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,128 +0,0 @@
-Xenguest mkimage
-================
-
-Introduction
------------
-
-xenguest-mkimage is a tool to create and modify images to be used as a 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 the ability to have init scripts embedded
-inside the image that will be executed on the host when the guest is started.
-
-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 kernel image 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 MB or GB(default),
-   e.g. 1000M or 4[G]
- `DISK_PARTX=SIZE:FS:CONTENT`: create a partition number X (1 to 4) with a
-  size of SIZE MB or GB(default), e.g 1000M or 2[G].
-  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.
- `DISK_DEVICE=X`: disk or partition to be used by lvm. Setting this option
-  allows to bind guest disk with any partition or disk available on host,
-  e.g. /dev/sda3 or /dev/sdb.
-  This variable is not set by default, but if set, it overrides disk settings
-  inside xenguest-manager.conf - 'XENGUEST_VOLUME_DEVICE'.
-
-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 MB or GB(default),
-   e.g 1000M or 2[G]. 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 MB or GB(default), e.g 1000M or 2[G].
-  - 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,39 +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"
-
-# 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-fvp-base-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)}"
-
-XEN_FILE ?= "xen-fvp-base"
-DTB_FILE ?= "${@ get_xen_dtb_filename(d)}"
-XEN_ADDR ?= "0x84000000"
-DTB_ADDR ?= "0x83000000"
-
-FVP_DATA    += "cluster0.cpu0=${DEPLOY_DIR_IMAGE}/${XEN_FILE}@${XEN_ADDR} \
-                cluster0.cpu0=${DEPLOY_DIR_IMAGE}/${DTB_FILE}@${DTB_ADDR}"
-
-# 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"
-
-XENGUEST_NETWORK_BRIDGE_MEMBERS ?= "eth0"
-
-# This function uses the "KERNEL_DEVICETREE" variable and manipulates it to
-# return the xen kernel device tree file name.
-def get_xen_dtb_filename(d):
-    kernel_dtb_filename = d.getVar('KERNEL_DEVICETREE',d)
-    xen_dtb_filename = os.path.splitext(os.path.basename(kernel_dtb_filename))[0] + '-xen.dtb'
-    return xen_dtb_filename
-
@@ -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,90 +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"
-
-# Set default boot partition size and unit
-BOOT_PART_SIZE ?= "100"
-BOOT_PART_SIZE_UNIT ?= "M"
-
-# The GRUB_CFG_FILE affects arm-autonomy-n1sdp-efidisk.wks.in file
-#
-# When alternate-kernel DISTRO_FEATURE is present we set the
-# arm-autonomy-n1sdp-rt-grub.cfg by default. This GRUB config file has
-# additional entries for booting with the PREEMPT_RT kernel.
-GRUB_CFG_FILE ?= "${@bb.utils.contains('DISTRO_FEATURES','alternate-kernel', \
-                     '${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic/arm-autonomy-n1sdp-rt-grub.cfg', \
-                     '${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic/arm-autonomy-n1sdp-grub.cfg' \
-                     , d)}"
-
-# 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}"
-
-# When alternate-kernel DISTRO_FEATURE is present we set the linux-yocto-rt
-# by default
-PREFERRED_PROVIDER_alternate/kernel ?= "\
-${@bb.utils.contains('DISTRO_FEATURES', 'alternate-kernel', \
-'linux-yocto-rt', '', d)}"
-
-KERNEL_PACKAGE_NAME_alternate/kernel ?= "kernel-rt"
-# When alternate-kernel DISTRO_FEATURE is present we set the kernel-rt by
-# default
-KERNEL_PACKAGE_NAME_pn-linux-yocto-rt = "\
-${@ d.getVar('KERNEL_PACKAGE_NAME_alternate/kernel') \
-if bb.utils.contains('DISTRO_FEATURES', 'alternate-kernel', True, False, d) \
-else 'kernel' }"
-
-# Relative path from DEPLOY_DIR_IMAGE of the Kernel PREEMPT_RT deployed Image
-KERNEL_RT_IMAGE ?= "kernel-rt/Image-n1sdp.bin;Image-preempt-rt"
-# Only include the Kernel PREEMPT_RT Image if we are building with
-# alternate-kernel DISTRO_FEATURE
-IMAGE_EFI_BOOT_FILES += "\
-${@ d.getVar('KERNEL_RT_IMAGE',d) or '' \
-if bb.utils.contains('DISTRO_FEATURES', 'alternate-kernel', True, False, d) and \
-d.getVar('PREFERRED_PROVIDER_alternate/kernel') else ''}"
-
-
-EFIDIR ?= "/EFI/BOOT"
-GRUB_CFG_EXTRA_FILE ?= "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic/arm-autonomy-n1sdp-grub.cfg;.${EFIDIR}}"
-
-# When alternate-kernel DISTRO_FEATURE is present we set the
-# arm-autonomy-n1sdp-rt-grub.cfg by default. This GRUB config file has
-# additional entries for booting with the PREEMPT_RT kernel and also includes
-# the main GRUB config file set by GRUB_CFG_EXTRA_FILE.
-IMAGE_EFI_BOOT_FILES += "\
-${@ d.getVar('GRUB_CFG_EXTRA_FILE',d) or '' \
-if bb.utils.contains('DISTRO_FEATURES', 'alternate-kernel', True, False, d) and \
-d.getVar('PREFERRED_PROVIDER_alternate/kernel') else ''}"
-
-# Additionnal kernel modules are necessary for n1sdp to be able to mount FAT
-# filesystems using CP437.
-MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = " kernel-module-nls-cp437 kernel-module-nls-iso8859-1"
@@ -1,50 +0,0 @@
-# Use OVERRIDES to minimize the usage of
-# ${@bb.utils.contains('DISTRO_FEATURES', 'autonomy-host', ...
-OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', ':autonomy-host', '', d)}"
-
-FILESEXTRAPATHS_prepend_autonomy-host := "${THISDIR}/${PN}:"
-
-DEPENDS_append_autonomy-host = " dos2unix-native"
-
-SRC_URI_append_autonomy-host = " file://add-xen-support.patch;patchdir=../"
-
-do_install_append_autonomy-host() {
-    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_autonomy-host = "xen:do_deploy xen-devicetree:do_deploy"
-
-do_deploy[depends] += "${DEPLOY_EXTRA_DEPS}"
-
-do_deploy_prepend_autonomy-host() {
-    # 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,6 +0,0 @@
-define KMACHINE n1sdp
-define KTYPE preempt-rt
-define KARCH arm64
-
-kconf non-hardware ktypes/developer/developer.cfg
-kconf non-hardware ktypes/preempt-rt/preempt-rt.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,7 +0,0 @@
-# Yocto kernel-cache sets CONFIG_NLS_CODEPAGE_437=m for LINUX_KERNEL_TYPR=preempt-rt
-CONFIG_NLS_CODEPAGE_437=y
-# Yocto kernel-cache sets CONFIG_NLS_ISO8859_1=m for LINUX_KERNEL_TYPR=preempt-rt
-CONFIG_NLS_ISO8859_1=y
-
-# Set the timer interrupt run at 1000 Hz to have a fast response
-CONFIG_HZ_1000=y
@@ -1,3 +0,0 @@
-define KFEATURE_DESCRIPTION "Extra kernel configs when building with PREEMPT_RT"
-
-kconf non-hardware preempt-rt-extras.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,17 +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 FVP Base first partition is empty to keep compatibility with disk.img
-part --label empty --source empty --ondisk sda --size="1M" --system-id 8e --align 1024
-
-# Second partition is rootfs normally populated as /dev/vda2
-part / --source rootfs --ondisk sda --fstype=ext4 --label root --align 1024
-
-# Third partition to accomodate guests images normally populated as /dev/vda3 (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/vda4
-${AUTONOMY_HOST_EXTRA_PARTITION}
-
-bootloader --ptable msdos
@@ -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 --size="${BOOT_PART_SIZE}${BOOT_PART_SIZE_UNIT}" --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}"
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Avinash Mehta	2d0b681d3d	update tags for Corstone-700 2020.02.10 release Signed-off-by: Avinash Mehta <avinash.mehta@arm.com>	2020-03-04 10:11:33 +00:00
Tushar Khandelwal	75cf9e84fe	add changes to fetch latest code upstream Signed-off-by: Tushar Khandelwal <tushar.khandelwal@arm.com>	2020-02-05 11:09:38 +00:00
Vishnu Banavath	3da5ef2795	a5ds: update trusted-firmware-a to new git hash Changes that we were holding as a patch are upstreamed to trusted-firmware-a master branch. Following are the links to the changes. https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2916/ https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2915/ https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2823/ https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2822/ https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2821/ This change is to update the git hash and to remove patching of trusted-firmware-a by yocto Change-Id: Id708a5d02950773524aa3b4e13bb5b31ca34c7c2 Signed-off-by: Vishnu Banavath <vishnu.banavath@arm.com>	2020-01-24 13:52:58 +00:00
Rui Miguel Silva	d26a2b7171	corstone700: change rootfs to cramfs-xip Use cramfs xip image in wic Change-Id: I2470ae1c4afa4fe275ad081881604fcb66fafee6 Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>	2020-01-24 13:52:58 +00:00
Rui Miguel Silva	a531de2323	corstone700: add cramfs-xip as image type Add cramfs xip class and filesystem to tiny image. Change-Id: I5bba11ef04b7bc54323901c90156484126af87dd Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>	2020-01-24 13:52:58 +00:00
Vishnu Banavath	ab33651a8a	a5ds: update TF-A and uboot patches To align FPGA with FVP, it is required to make changes in A5DS. Previous changes are melded into new changes and created a new patches so as to reduce the number of patches we carry. Change-Id: Idc7212edeada80bd1780aee932ddcd565d4ed2f9 Signed-off-by: Vishnu Banavath <vishnu.banavath@arm.com>	2020-01-24 13:52:58 +00:00
Vishnu Banavath	e841380aa4	corstone700.conf: set DTB address to use DDR This change is to use DDR address for DTB instead of shared RAM. Change-Id: I191eeb96bbcf062ea9ec21a42b22b2b38ac5003b Signed-off-by: Vishnu Banavath <vishnu.banavath@arm.com>	2020-01-07 17:29:33 +00:00
Avinash Mehta	85ef030d8b	Update the trusted-firmware-a md5 LIC_FILES_CHKSUM Change-Id: Ie4914551a79da7d4b0735d66824603b70e2f1b28 Signed-off-by: Avinash Mehta <avinash.mehta@arm.com>	2020-01-07 17:29:33 +00:00
Vishnu Banavath	8b402b3d6e	corstone700: reduce rootfs size to 2MB Because of memory constraint, reducing rootfs to 2MB Change-Id: I853fc4322372456ea3df2b7a0e1e5f8b08677e40	2020-01-07 17:29:33 +00:00
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