runfvp: check for telnet

Check for telnet on startup to avoid mysterious failures later when
telnet isn't available.

Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>

.gitlab-ci.yml

@@ -25,7 +25,7 @@ stages:
     - mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
     # Must do this here, as it's the only way to make sure the toolchain is installed on the same builder
     - ./ci/get-binary-toolchains $DL_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
-    - sudo apt update && sudo apt install --yes telnet python3-subunit
+    - sudo apt update && sudo apt install telnet -y
 
 # Generalised fragment to do a Kas build
 .build:
@@ -35,11 +35,6 @@ stages:
     - kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
     - kas build $KASFILES
     - ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
-  artifacts:
-    name: "logs"
-    when: on_failure
-    paths:
-      - $CI_PROJECT_DIR/work/build/tmp/work*/**/temp/log.do_*.*
 
 # Workaround for Zephyr not currectly handling TESTIMAGE_AUTO
 .build_and_test:
@@ -61,6 +56,15 @@ update-repos:
   script:
     - flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos
 
+
+# What percentage of machines in the layer do we build
+machine-coverage:
+  stage: build
+  interruptible: true
+  script:
+    - ./ci/check-machine-coverage
+  coverage: '/Coverage: \d+/'
+
 #
 # Build stage, the actual build jobs
 #
@@ -70,21 +74,33 @@ update-repos:
 #  VIRT: [none, xen]
 #  TESTING: testimage
 
+# Validate layers are Yocto Project Compatible
+check-layers:
+  extends: .setup
+  coverage: '/Coverage: \d+/'
+  script:
+    - kas shell --update --force-checkout ci/base.yml:ci/meta-arm-autonomy.yml:ci/meta-openembedded.yml --command \
+      "$CI_PROJECT_DIR/ci/check-layers.py $CI_PROJECT_DIR/ci/check-layers.yml $CI_PROJECT_DIR $KAS_WORK_DIR"
+
+pending-updates:
+  extends: .setup
+  artifacts:
+    paths:
+      - update-report.html
+  script:
+    - kas shell ci/qemuarm64.yml:ci/meta-openembedded.yml -c "$CI_PROJECT_DIR/scripts/machine-summary.py -t updates.html -o $CI_PROJECT_DIR/update-report.html $($CI_PROJECT_DIR/ci/listmachines.py meta-arm meta-arm-bsp)"
+
 corstone500:
   extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-  tags:
-    - x86_64
+
+corstone700-fvp:
+  extends: .build
+
+corstone700-mps3:
+  extends: .build
 
 corstone1000-fvp:
   extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-  tags:
-    - x86_64
 
 corstone1000-mps3:
   extends: .build
@@ -102,17 +118,9 @@ fvp-base-arm32:
   parallel:
     matrix:
       - TOOLCHAINS: [gcc, external-gccarm]
-        TESTING: testimage
-  tags:
-    - x86_64
 
 fvp-baser-aemv8r64:
   extends: .build
-  parallel:
-    matrix:
-      - TESTING: testimage
-  tags:
-    - x86_64
 
 fvps:
   extends: .build
@@ -134,7 +142,6 @@ juno:
   parallel:
     matrix:
       - TOOLCHAINS: [gcc, clang]
-        FIRMWARE: [none, edk2]
 
 microbit-v1:
   extends: .build_and_test
@@ -166,13 +173,6 @@ qemu-cortex-m3:
 qemu-cortex-r5:
   extends: .build
 
-qemu-generic-arm64:
-  extends: .build
-  parallel:
-    matrix:
-      - TOOLCHAINS: [gcc, clang]
-        TESTING: testimage
-
 qemuarm64-secureboot:
   extends: .build
   parallel:
@@ -216,50 +216,3 @@ tc1:
 
 toolchains:
   extends: .build
-
-selftest:
-  extends: .setup
-  script:
-    - KASFILES=./ci/qemuarm64.yml:./ci/selftest.yml
-    - kas shell --update --force-checkout $KASFILES -c 'oe-selftest --num-processes 1 --run-tests runfvp'
-
-# Validate layers are Yocto Project Compatible
-check-layers:
-  extends: .setup
-  script:
-    - kas shell --update --force-checkout ci/base.yml:ci/meta-openembedded.yml --command \
-      "yocto-check-layer-wrapper $CI_PROJECT_DIR/$LAYER --dependency $CI_PROJECT_DIR/meta-* $KAS_WORK_DIR/meta-openembedded/meta-oe --no-auto-dependency"
-  parallel:
-    matrix:
-      - LAYER: [meta-arm, meta-arm-bsp, meta-arm-toolchain, meta-gem5]
-
-pending-updates:
-  extends: .setup
-  artifacts:
-    paths:
-      - update-report
-  script:
-    - rm -fr update-report
-    # This configuration has all of the layers we need enabled
-    - kas shell ci/gem5-arm64.yml --command \
-      "$CI_PROJECT_DIR/scripts/machine-summary.py -t report -o $CI_PROJECT_DIR/update-report $($CI_PROJECT_DIR/ci/listmachines.py meta-arm meta-arm-bsp meta-gem5)"
-  # Do this on x86 whilst the compilers are x86-only
-  tags:
-    - x86_64
-
-# What percentage of machines in the layer do we build
-machine-coverage:
-  stage: build
-  interruptible: true
-  script:
-    - ./ci/check-machine-coverage
-  coverage: '/Coverage: \d+/'
-
-metrics:
-  extends: .setup
-  artifacts:
-    reports:
-      metrics: metrics.txt
-  script:
-    - kas shell --update --force-checkout ci/base.yml --command \
-      "$CI_PROJECT_DIR/ci/patchreview $CI_PROJECT_DIR/meta-* --verbose --metrics $CI_PROJECT_DIR/metrics.txt"

ci/armgcc.yml

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

ci/base.yml

@@ -1,11 +1,11 @@
 header:
-  version: 11
+  version: 9
 
 distro: poky
 
 defaults:
   repos:
-    refspec: kirkstone
+    refspec: honister
 
 repos:
   meta-arm:
@@ -26,25 +26,20 @@ env:
 
 local_conf_header:
   base: |
-    BB_SERVER_TIMEOUT = "60"
     CONF_VERSION = "2"
-    BB_NUMBER_THREADS = "16"
-    PARALLEL_MAKE = "-j16"
-    LICENSE_FLAGS_ACCEPTED += "armcompiler Arm-FVP-EULA"
-  setup: |
     PACKAGE_CLASSES = "package_ipk"
+    LICENSE_FLAGS_WHITELIST += "armcompiler Arm-FVP-EULA"
     PACKAGECONFIG:remove:pn-qemu-system-native = "gtk+ sdl"
     EXTRA_IMAGE_FEATURES:append = " debug-tweaks"
-    PACKAGECONFIG:append:pn-perf = " coresight"
+    BB_NUMBER_THREADS = "16"
+    PARALLEL_MAKE = "-j16"
     INHERIT += "rm_work"
+    PACKAGECONFIG:append:pn-perf = " coresight"
+  noptest: |
     DISTRO_FEATURES:remove = "ptest"
-  kvm: |
-    QEMU_USE_KVM = ""
-  perf: |
-    CORE_IMAGE_EXTRA_INSTALL += "perf"
-  sshkeys: |
-    CORE_IMAGE_EXTRA_INSTALL += "ssh-pregen-hostkeys"
+
 machine: unset
 
 target:
   - core-image-base
+  - perf

ci/check-layers.py

@@ -0,0 +1,44 @@
+#! /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])
+    cli.append("--no-auto-dependency")
+
+    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)

ci/check-layers.yml

@@ -0,0 +1,13 @@
+layers:
+  - meta-arm
+  - meta-arm-bsp
+  - meta-arm-toolchain
+  - meta-gem5
+  - meta-arm-autonomy
+dependencies:
+  - meta-openembedded/meta-oe
+  - meta-openembedded/meta-networking
+  - meta-openembedded/meta-python
+  - meta-openembedded/meta-filesystems
+  - poky/meta-poky
+  - meta-virtualization

ci/clang.yml

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

ci/corstone1000-common.yml

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

ci/corstone1000-fvp.yml

@@ -1,12 +1,13 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/corstone1000-common.yml
+    - base.yml
+    - meta-openembedded.yml
 
 local_conf_header:
-    fvp-config: |
-        # Remove Dropbear SSH as it will not fit into the corstone1000 image.
-        IMAGE_FEATURES:remove = " ssh-server-dropbear"
-        INHERIT += "fvpboot"
+    custom-local-conf: |
+        INITRAMFS_IMAGE_BUNDLE = "0"
+        INITRAMFS_IMAGE:remove = "corstone1000-initramfs-image"
 
 machine: corstone1000-fvp
+

ci/corstone1000-mps3.yml

@@ -1,6 +1,12 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/corstone1000-common.yml
+    - base.yml
+    - meta-openembedded.yml
+
+local_conf_header:
+    custom-local-conf: |
+        INITRAMFS_IMAGE_BUNDLE = "0"
+        INITRAMFS_IMAGE:remove = "corstone1000-initramfs-image"
 
 machine: corstone1000-mps3

ci/corstone500.yml

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

ci/corstone700-fvp.yml

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

ci/corstone700-mps3.yml

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

ci/edk2.yml

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

ci/external-gccarm.yml

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

ci/fvp-base-arm32.yml

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

ci/fvp-base.yml

@@ -1,13 +1,13 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
+    - base.yml
 
 machine: fvp-base
 
 local_conf_header:
   testimagefvp: |
-    INHERIT += "fvpboot"
+    INHERIT = "fvpboot"
     # This fails but we can't add to the ignorelist from meta-arm yet
     # https://bugzilla.yoctoproject.org/show_bug.cgi?id=14604
     TEST_SUITES:remove = "parselogs"

ci/fvp-baser-aemv8r64.yml

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

ci/fvps.yml

@@ -1,9 +1,9 @@
 # Simple target to build the FVPs that are publically available
 
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
+    - base.yml
 
 machine: qemuarm64
 
@@ -16,5 +16,5 @@ target:
   - nativesdk-fvp-n1-edge
   - nativesdk-fvp-sgi575
   - nativesdk-fvp-corstone500
-  - nativesdk-fvp-corstone1000
+  - nativesdk-fvp-corstone700
   - nativesdk-fvp-tc0

ci/gem5-arm64.yml

@@ -1,8 +1,8 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
-    - ci/meta-openembedded.yml
+    - base.yml
+    - meta-openembedded.yml
 
 repos:
   meta-arm:
@@ -13,4 +13,5 @@ machine: gem5-arm64
 
 target:
   - core-image-minimal
+  - perf
   - gem5-aarch64-native

ci/gem5-atp-arm64.yml

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

ci/generic-arm64.yml

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

ci/get-binary-toolchains

@@ -2,7 +2,7 @@
 set -u
 
 HOST_ARCH=$(uname -m)
-VER="11.2-2022.02"
+VER="10.3-2021.07"
 
 DOWNLOAD_DIR=$1
 TOOLCHAIN_DIR=$2
@@ -15,18 +15,18 @@ if [ $HOST_ARCH = "aarch64" ]; then
 	#AArch64 Linux hosted cross compilers
 
 	#AArch32 target with hard float (arm-none-linux-gnueabihf)
-	wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz
+	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/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz
+	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/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-aarch64-none-linux-gnu.tar.xz
+	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/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-aarch64_be-none-linux-gnu.tar.xz
+	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

ci/juno.yml

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

ci/meta-arm-autonomy.yml

@@ -0,0 +1,10 @@
+header:
+  version: 9
+  includes:
+    - meta-openembedded.yml
+    - meta-virtualization.yml
+
+repos:
+  meta-arm:
+    layers:
+      meta-arm-autonomy:

ci/meta-openembedded.yml

@@ -1,5 +1,5 @@
 header:
-  version: 11
+  version: 9
 
 repos:
   meta-openembedded:

ci/meta-virtualization.yml

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

ci/meta-zephyr.yml

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

ci/microbit-v1.yml

@@ -1,11 +1,16 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
-    - ci/meta-zephyr.yml
+    - base.yml
+    - meta-zephyr.yml
 
 local_conf_header:
-  failing_tests: |
+  nonbuilding_tests: |
     ZEPHYRTESTS:remove = "common"
+  failing_tests: |
+    ZEPHYRTESTS:remove = "context early_sleep sleep"
 
 machine: microbit-v1
+
+target:
+  - zephyr-kernel-test-all

ci/musca-b1.yml

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

ci/musca-s1.yml

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

ci/musl.yml

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

ci/n1sdp.yml

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

ci/patchreview

@@ -1,286 +0,0 @@
-#! /usr/bin/env python3
-#
-# SPDX-License-Identifier: GPL-2.0-only
-#
-
-# TODO
-# - option to just list all broken files
-# - test suite
-# - validate signed-off-by
-
-import argparse
-import collections
-import json
-import os
-import re
-import subprocess
-
-status_values = (
-    "accepted",
-    "pending",
-    "inappropriate",
-    "backport",
-    "submitted",
-    "denied",
-)
-
-
-class PatchResult:
-    # Whether the patch has an Upstream-Status or not
-    missing_upstream_status = False
-    # If the Upstream-Status tag is malformed in some way (string for bad bit)
-    malformed_upstream_status = None
-    # If the Upstream-Status value is unknown (boolean)
-    unknown_upstream_status = False
-    # The upstream status value (Pending, etc)
-    upstream_status = None
-    # Whether the patch has a Signed-off-by or not
-    missing_sob = False
-    # Whether the Signed-off-by tag is malformed in some way
-    malformed_sob = False
-    # The Signed-off-by tag value
-    sob = None
-    # Whether a patch looks like a CVE but doesn't have a CVE tag
-    missing_cve = False
-
-
-class Summary:
-    total = 0
-    cve_missing = 0
-    sob_missing = 0
-    sob_malformed = 0
-    status_missing = 0
-    status_malformed = 0
-    status_pending = 0
-
-def blame_patch(patch):
-    """
-    From a patch filename, return a list of "commit summary (author name <author
-    email>)" strings representing the history.
-    """
-    return subprocess.check_output(("git", "log",
-                                    "--follow", "--find-renames", "--diff-filter=A",
-                                    "--format=%s (%aN <%aE>)",
-                                    "--", patch)).decode("utf-8").splitlines()
-
-def patchreview(patches):
-    # General pattern: start of line, optional whitespace, tag with optional
-    # hyphen or spaces, maybe a colon, some whitespace, then the value, all case
-    # insensitive.
-    sob_re = re.compile(r"^[\t ]*(Signed[-_ ]off[-_ ]by:?)[\t ]*(.+)", re.IGNORECASE | re.MULTILINE)
-    status_re = re.compile(r"^[\t ]*(Upstream[-_ ]Status:?)[\t ]*(\w*)", re.IGNORECASE | re.MULTILINE)
-    cve_tag_re = re.compile(r"^[\t ]*(CVE:)[\t ]*(.*)", re.IGNORECASE | re.MULTILINE)
-    cve_re = re.compile(r"cve-[0-9]{4}-[0-9]{4,6}", re.IGNORECASE)
-
-    results = {}
-
-    for patch in patches:
-
-        result = PatchResult()
-        results[patch] = result
-
-        content = open(patch, encoding="ascii", errors="ignore").read()
-
-        # Find the Signed-off-by tag
-        match = sob_re.search(content)
-        if match:
-            value = match.group(1)
-            if value != "Signed-off-by:":
-                result.malformed_sob = value
-            result.sob = match.group(2)
-        else:
-            result.missing_sob = True
-
-        # Find the Upstream-Status tag
-        match = status_re.search(content)
-        if match:
-            value = match.group(1)
-            if value != "Upstream-Status:":
-                result.malformed_upstream_status = value
-
-            value = match.group(2).lower()
-            # TODO: check case
-            if value not in status_values:
-                result.unknown_upstream_status = True
-            result.upstream_status = value
-        else:
-            result.missing_upstream_status = True
-
-        # Check that patches which looks like CVEs have CVE tags
-        if cve_re.search(patch) or cve_re.search(content):
-            if not cve_tag_re.search(content):
-                result.missing_cve = True
-        # TODO: extract CVE list
-
-    return results
-
-
-def analyse(results, want_blame=False, verbose=True):
-    """
-    want_blame: display blame data for each malformed patch
-    verbose: display per-file results instead of just summary
-    """
-
-    # want_blame requires verbose, so disable blame if we're not verbose
-    if want_blame and not verbose:
-        want_blame = False
-
-    summary = Summary()
-
-    for patch in sorted(results):
-        r = results[patch]
-        summary.total += 1
-        need_blame = False
-
-        # Build statistics
-        if r.missing_sob:
-            summary.sob_missing += 1
-        if r.malformed_sob:
-            summary.sob_malformed += 1
-        if r.missing_upstream_status:
-            summary.status_missing += 1
-        if r.malformed_upstream_status or r.unknown_upstream_status:
-            summary.status_malformed += 1
-            # Count patches with no status as pending
-            summary.status_pending += 1
-        if r.missing_cve:
-            summary.cve_missing += 1
-        if r.upstream_status == "pending":
-            summary.status_pending += 1
-
-        # Output warnings
-        if r.missing_sob:
-            need_blame = True
-            if verbose:
-                print("Missing Signed-off-by tag (%s)" % patch)
-        if r.malformed_sob:
-            need_blame = True
-            if verbose:
-                print("Malformed Signed-off-by '%s' (%s)" % (r.malformed_sob, patch))
-        if r.missing_cve:
-            need_blame = True
-            if verbose:
-                print("Missing CVE tag (%s)" % patch)
-        if r.missing_upstream_status:
-            need_blame = True
-            if verbose:
-                print("Missing Upstream-Status tag (%s)" % patch)
-        if r.malformed_upstream_status:
-            need_blame = True
-            if verbose:
-                print("Malformed Upstream-Status '%s' (%s)" % (r.malformed_upstream_status, patch))
-        if r.unknown_upstream_status:
-            need_blame = True
-            if verbose:
-                print("Unknown Upstream-Status value '%s' (%s)" % (r.upstream_status, patch))
-
-        if want_blame and need_blame:
-            print("\n".join(blame_patch(patch)) + "\n")
-
-    return summary
-
-
-def display_summary(summary, verbose):
-    def percent(num):
-        try:
-            return "%d (%d%%)" % (num, round(num * 100.0 / summary.total))
-        except ZeroDivisionError:
-            return "N/A"
-
-    if verbose:
-        print()
-
-    print("""Total patches found: %d
-Patches missing Signed-off-by: %s
-Patches with malformed Signed-off-by: %s
-Patches missing CVE: %s
-Patches missing Upstream-Status: %s
-Patches with malformed Upstream-Status: %s
-Patches in Pending state: %s""" % (summary.total,
-                                   percent(summary.sob_missing),
-                                   percent(summary.sob_malformed),
-                                   percent(summary.cve_missing),
-                                   percent(summary.status_missing),
-                                   percent(summary.status_malformed),
-                                   percent(summary.status_pending)))
-
-
-def generate_metrics(summary, output):
-    # https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md
-    # Summary attribute name, MetricPoint help
-    mapping = (
-        ("total", "Total patches"),
-        ("cve_missing", "Patches missing CVE tag"),
-        ("sob_malformed", "Patches with malformed Signed-off-by"),
-        ("sob_missing", "Patches with missing Signed-off-by"),
-        ("status_malformed", "Patches with malformed Upstream-Status"),
-        ("status_missing", "Patches with missing Upstream-Status"),
-        ("status_pending", "Patches with Pending Upstream-Status")
-    )
-    for attr, help in mapping:
-        metric = f"patch_check_{attr}"
-        value = getattr(summary, attr)
-        output.write(f"""
-# TYPE {metric} gauge
-# HELP {help}
-{metric} {value}
-""")
-    output.write("\n# EOF\n")
-
-def histogram(results):
-    import math
-
-    from toolz import dicttoolz, recipes
-    counts = recipes.countby(lambda r: r.upstream_status, results.values())
-    bars = dicttoolz.valmap(lambda v: "#" * int(math.ceil(float(v) / len(results) * 100)), counts)
-    for k in bars:
-        print("%-20s %s (%d)" % (k.capitalize() if k else "No status", bars[k], counts[k]))
-
-def gather_patches(directories):
-    patches = []
-    for directory in directories:
-        filenames = subprocess.check_output(("git", "-C", directory, "ls-files", "recipes-*/**/*.patch", "recipes-*/**/*.diff")).decode("utf-8").split()
-        patches += [os.path.join(directory, f) for f in filenames]
-    return patches
-
-if __name__ == "__main__":
-    args = argparse.ArgumentParser(description="Patch Review Tool")
-    args.add_argument("-b", "--blame", action="store_true", help="show blame for malformed patches")
-    args.add_argument("-v", "--verbose", action="store_true", help="show per-patch results")
-    args.add_argument("-g", "--histogram", action="store_true", help="show patch histogram")
-    args.add_argument("-j", "--json", help="update JSON")
-    args.add_argument("-m", "--metrics", type=argparse.FileType('w'), help="write OpenMetrics")
-    args.add_argument("dirs", metavar="DIRECTORY", nargs="+", help="directory to scan")
-    args = args.parse_args()
-
-    patches = gather_patches(args.dirs)
-    results = patchreview(patches)
-    summary = analyse(results, want_blame=args.blame, verbose=args.verbose)
-    display_summary(summary, verbose=args.verbose)
-
-    if args.json:
-        if os.path.isfile(args.json):
-            data = json.load(open(args.json))
-        else:
-            data = []
-
-        row = collections.Counter()
-        row["total"] = len(results)
-        row["date"] = subprocess.check_output(["git", "-C", args.dirs[0], "show", "-s", "--pretty=format:%cd", "--date=format:%s"]).decode("utf-8").strip()
-        for r in results.values():
-            if r.upstream_status in status_values:
-                row[r.upstream_status] += 1
-            if r.malformed_upstream_status or r.missing_upstream_status:
-                row["malformed-upstream-status"] += 1
-            if r.malformed_sob or r.missing_sob:
-                row["malformed-sob"] += 1
-
-        data.append(row)
-        json.dump(data, open(args.json, "w"))
-
-    if args.metrics:
-        generate_metrics(summary, args.metrics)
-
-    if args.histogram:
-        print()
-        histogram(results)

ci/qemu-cortex-a53.yml

@@ -1,9 +1,14 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
-    - ci/meta-zephyr.yml
+    - base.yml
+    - meta-zephyr.yml
 
-# FIXME - testimage fails all tests currently, but all the tests build
+local_conf_header:
+  nonbuilding_tests: |
+    ZEPHYRTESTS:remove += "common device poll queue sleep"
 
 machine: qemu-cortex-a53
+
+target:
+  - zephyr-kernel-test-all

ci/qemu-cortex-m3.yml

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

ci/qemu-cortex-r5.yml

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

ci/qemu-generic-arm64.yml

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

ci/qemuarm.yml

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

ci/qemuarm64-sbsa.yml

@@ -0,0 +1,11 @@
+header:
+  version: 9
+  includes:
+    - base.yml
+
+machine: qemuarm64-sbsa
+
+target:
+  - core-image-base
+  - perf
+  - sbsa-acs

ci/qemuarm64-secureboot.yml

@@ -1,18 +1,19 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
+    - base.yml
 
 machine: qemuarm64-secureboot
 
 local_conf_header:
-  failing_tests: |
-    # software IO TLB: Cannot allocate buffer
-    DEFAULT_TEST_SUITES:remove = "parselogs"
+  bugs: |
+    # Only ping until errors can be resolved
+    TEST_SUITES = "ping"
 
 target:
   - core-image-base
+  - perf
   - optee-examples
   - optee-test
   - optee-spdevkit
-  - optee-os-tadevkit
+  - optee-os-tadevkit

ci/qemuarm64.yml

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

ci/qemuarmv5.yml

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

ci/selftest.yml

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

ci/sgi575.yml

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

ci/tc0.yml

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

ci/tc1.yml

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

ci/testimage-zephyr.yml

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

ci/testimage.yml

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

ci/toolchains.yml

@@ -1,7 +1,7 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/base.yml
+    - base.yml
 
 # Target is arm64 and SDK is x86-64 to ensure that we exercise both
 # architectures
@@ -18,4 +18,3 @@ target:
   - nativesdk-gcc-aarch64-none-elf
   - gcc-arm-none-eabi
   - nativesdk-gcc-arm-none-eabi
-  - nativesdk-androidclang

ci/xen.yml

@@ -1,7 +1,7 @@
 header:
-  version: 11
+  version: 9
   includes:
-    - ci/meta-virtualization.yml
+    - meta-virtualization.yml
 
 local_conf_header:
   meta-virt: |

documentation/runfvp.md

@@ -1,120 +0,0 @@
-# Running Images with a FVP
-
-The `runfvp` tool in meta-arm makes it easy to run Yocto Project disk images inside a [Fixed Virtual Platform (FVP)][FVP].  Some FVPs, such as the [Arm Architecture Models][AEM], are available free to download, but others need registration or are only available commercially.  The `fvp-base` machine in meta-arm-bsp uses one of these AEM models.
-
-## Running images with `runfvp`
-
-To build images with the FVP integration, the `fvpboot` class needs to be inherited.  If the machine does not do this explicitly it can be done in `local.conf`:
-
-```
-INHERIT += "fvpboot"
-```
-
-The class will download the correct FVP and write a `.fvpconf` configuration file when an image is built.
-
-To run an image in a FVP, pass either a machine name or a `.fvpconf` path to `runfvp`.
-
-```
-$ ./meta-arm/scripts/runfvp tmp/deploy/images/fvp-base/core-image-minimal-fvp-base.fvpconf
-```
-
-When a machine name is passed, `runfvp` will start the latest image that has been built for that machine. This requires that the BitBake environment has been initialized (using `oe-init-build-env` or similar) as it will start BitBake to determine where the images are.
-
-```
-$ ./meta-arm/scripts/runfvp fvp-base
-```
-
-Note that currently meta-arm's `scripts` directory isn't in `PATH`, so a full path needs to be used.
-
-`runfvp` will automatically start terminals connected to each of the serial ports that the machine specifies.  This can be controlled by using the `--terminals` option, for example `--terminals=none` will mean no terminals are started, and `--terminals=tmux` will start the terminals in [`tmux`][tmux] sessions.  Alternatively, passing `--console` will connect the serial port directly to the current session, without needing to open further windows.
-
-The default terminal can also be configured by writing a [INI-style][INI] configuration file to `~/.config/runfvp.conf`:
-
-```
-[RunFVP]
-Terminal=tmux
-```
-
-Arbitrary options can be passed directly to the FVP by specifying them after a double dash, for example this will list all of the FVP parameters:
-
-```
-$ runfvp fvp-base -- --list-params
-```
-
-## Configuring machines with `fvpboot`
-
-To configure a machine so that it can be ran inside `runfvp`, a number of variables need to be set in the machine configuration file (such as `meta-arm-bsp/conf/machine/fvp-base.conf`).
-
-Note that at present these variables are not stable and their behaviour may be changed in the future.
-
-### `FVP_EXE`
-
-The name of the FVP binary itself, for example `fvp-base` uses `FVP_Base_RevC-2xAEMvA`.
-
-### `FVP_PROVIDER`
-
-The name of the recipe that provides the FVP executable set in `FVP_EXE`, for example `fvp-base` uses `fvp-base-a-aem-native`.  This *must* be a `-native` recipe as the binary will be executed on the build host.
-
-There are recipes for common FVPs in meta-arm already, and writing new recipes is trivial.  For FVPs which are free to download `fvp-base-a-aem.bb` is a good example. Some FVPs must be downloaded separately as they need an account on Arm's website, `fvp-base-r-aem.bb` is a good example of those.
-
-If `FVP_PROVIDER` is not set then it is assumed that `FVP_EXE` is installed on the host already.
-
-### `FVP_CONFIG`
-
-Parameters passed to the FVP with the `--parameter`/`-C` option.  These are expressed as variable flags so individual parameters can be altered easily. For example:
-
-```
-FVP_CONFIG[bp.flashloader0.fname] = "${DEPLOY_DIR_IMAGE}/fip-fvp.bin"
-```
-
-### `FVP_DATA`
-
-Specify raw data to load at the specified address, passed to the FVP with the `--data` option.  This is a space-separated list of parameters in the format `[INST=]FILE@[MEMSPACE:]ADDRESS`. For example:
-
-```
-FVP_DATA = "cluster0.cpu0=${DEPLOY_DIR_IMAGE}/Image@0x80080000 \
-            cluster0.cpu0=${DEPLOY_DIR_IMAGE}/fvp-base-revc.dtb@0x83000000"
-```
-
-### `FVP_APPLICATIONS`
-
-Applications to load on the cores, passed to the FVP with the `--application` option.  These are expressed as variable flags with the flag name being the instance and flag value the filename, for example:
-
-```
-FVP_APPLICATIONS[cluster0] = "${DEPLOY_DIR_IMAGE}/linux-system.axf"
-```
-
-Note that symbols are not allowed in flag names, so if you need to use a wildcard in the instance then you'll need to use `FVP_EXTRA_ARGS` and `--application` directly.
-
-### `FVP_TERMINALS`
-
-Map hardware serial ports to abstract names. For example the `FVP_Base_RevC-2xAEMvA` FVP exposes four serial ports, `terminal_0` to `terminal_3`.  Typically only `terminal_0` is used in the `fvp-base` machine so this can be named `"Console"` and the others `""`.  When runfvp starts terminals it will only start named serial ports, so instead of opening four windows where only one is useful, it will only open one.
-
-For example:
-```
-FVP_TERMINALS[bp.terminal_0] = "Console"
-FVP_TERMINALS[bp.terminal_1] = ""
-FVP_TERMINALS[bp.terminal_2] = ""
-FVP_TERMINALS[bp.terminal_3] = ""
-```
-
-### `FVP_CONSOLE`
-
-This specifies what serial port is used when `--console` is passed to runfvp. Note that this has to be the FVP identifier but without the board prefix, for example:
-```
-FVP_CONSOLE = "terminal_0"
-```
-
-### `FVP_EXTRA_ARGS`
-
-Arbitrary extra arguments that are passed directly to the FVP.  For example:
-
-```
-FVP_EXTRA_ARGS = "--simlimit 60"
-```
-
-
-[AEM]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms/arm-ecosystem-models
-[FVP]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
-[tmux]: https://tmux.github.io/
-[INI]: https://docs.python.org/3/library/configparser.html

kas/corstone1000-base.yml

@@ -5,7 +5,7 @@ distro: poky-tiny
 
 defaults:
   repos:
-    refspec: master
+    refspec: honister
 
 repos:
   meta-arm:
@@ -16,7 +16,7 @@ repos:
 
   poky:
     url: https://git.yoctoproject.org/git/poky
-    refspec: master
+    refspec: b6b0af0889de9da0e4128cef8c9069b770b7d5a0
     layers:
       meta:
       meta-poky:
@@ -24,20 +24,20 @@ repos:
 
   meta-openembedded:
     url: https://git.openembedded.org/meta-openembedded
-    refspec: master
+    refspec: ad52a41de8b4b7d619d1376d0a0090ebcfff56da
     layers:
       meta-oe:
       meta-python:
 
   meta-arm-image:
      url: https://git.gitlab.arm.com/arm-reference-solutions/meta-arm-image.git
-     refspec: 9f611833ef58394b707836d69356c4e27d0265fc 
+     refspec: 9f611833ef58394b707836d69356c4e27d0265fc
 
 local_conf_header:
   base: |
     CONF_VERSION = "2"
     PACKAGE_CLASSES = "package_ipk"
-    LICENSE_FLAGS_ACCEPTED += "armcompiler"
+    LICENSE_FLAGS_WHITELIST += "armcompiler"
     BB_NUMBER_THREADS ?= "16"
     PARALLEL_MAKE ?= "-j16"
     PACKAGECONFIG:append:pn-perf = " coresight"

kas/corstone1000-fvp.yml

@@ -17,7 +17,7 @@ local_conf_header:
         # Remove Dropbear SSH as it will not fit into the corstone1000 image.
         IMAGE_FEATURES:remove = " ssh-server-dropbear"
         INHERIT = " ${@bb.utils.contains('BUILD_ARCH', 'x86_64', 'fvpboot', '', d)}"
-        LICENSE_FLAGS_ACCEPTED:append = " Arm-FVP-EULA"
+        LICENSE_FLAGS_WHITELIST:append = " Arm-FVP-EULA"
 
 target:
   - corstone1000-image

kas/corstone500.yml

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

kas/fvp-baser-aemv8r64-bsp.yml

@@ -6,7 +6,7 @@ machine: fvp-baser-aemv8r64
 
 defaults:
   repos:
-    refspec: master
+    refspec: honister
 
 repos:
   meta-arm:
@@ -25,6 +25,7 @@ repos:
       meta-poky:
 
 env:
+  FVP_BASE_R_AEM_TARBALL_URI: ""
   FVP_BASE_R_ARM_EULA_ACCEPT: "False"
 
 local_conf_header:
@@ -33,9 +34,9 @@ local_conf_header:
     PACKAGE_CLASSES = "package_ipk"
     PACKAGECONFIG:remove:pn-qemu-system-native = "gtk+ sdl"
     EXTRA_IMAGE_FEATURES:append = " debug-tweaks ssh-server-openssh"
-    CORE_IMAGE_EXTRA_INSTALL:append = " ssh-pregen-hostkeys"
-    LICENSE_FLAGS_ACCEPTED:append = " ${@oe.utils.vartrue('FVP_BASE_R_ARM_EULA_ACCEPT', 'Arm-FVP-EULA', '', d)}"
-    IMAGE_CLASSES:append = " testimage"
+    FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] ?= "8022=22"
+    IMAGE_CLASSES:append = " ${@oe.utils.ifelse(d.getVar('FVP_BASE_R_AEM_TARBALL_URI'), 'fvpboot', '')}"
+    LICENSE_FLAGS_WHITELIST:append = " ${@oe.utils.vartrue('FVP_BASE_R_ARM_EULA_ACCEPT', 'Arm-FVP-EULA', '', d)}"
 
 target:
   - core-image-minimal

meta-arm-autonomy/README.md

@@ -1,16 +1,85 @@
 meta-arm-autonomy Yocto Layer
 =============================
 
-The meta-arm-autonomy layer is being deprecated from master, with bug fixes
-only being applied to the following branches. Additionally, all support and
-maintenance of meta-arm-autonomy will stop as per the schedule below.
+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.
 
-    honister: End-of-life scheduled to June 2022
-    hardknot: End-of-life scheduled to December 2021
-    gatesgarth: End-of-life scheduled to October 2021
-    dunfell: End-of-life scheduled to October 2021
-    master: End-of-life scheduled to October 2021 and code removed
+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
 ------------
@@ -21,3 +90,4 @@ would like to contribute, please contact the maintainers
 Maintainer(s)
 -------------
 * Diego Sueiro <diego.sueiro@arm.com>
+* Bertrand Marquis <bertrand.marquis@arm.com>

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

@@ -0,0 +1,26 @@
+# This class is to be inherited by image recipes that want to build and install
+# an alternate kernel (set via PREFERRED_PROVIDER_alternate/kernel).
+#
+# It is mandatory to also set the KERNEL_PACKAGE_NAME for the alternate kernel
+# recipe via KERNEL_PACKAGE_NAME:pn-${PREFERRED_PROVIDER_alternate/kernel} and
+# its value needs to be different from "kernel" since this is the default set
+# for PREFERRED_PROVIDER_virtual/kernel.
+#
+# An example of these settings can be found at meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/n1sdp-extra-settings.inc
+#
+# When building and installing an alternate kernel, the kernel-modules packages
+# for both virtual/kernel and alternate/kernel will be installed.
+
+PREFERRED_PROVIDER_alternate/kernel ??= ""
+
+python () {
+    alternate_kernel = d.getVar('PREFERRED_PROVIDER_alternate/kernel')
+    if alternate_kernel:
+        alternate_kernel_pkg_name = d.getVar('KERNEL_PACKAGE_NAME:pn-%s' % alternate_kernel)
+        if alternate_kernel_pkg_name:
+            d.appendVar('EXTRA_IMAGEDEPENDS', ' ' + alternate_kernel)
+            d.appendVar('IMAGE_INSTALL', ' kernel-modules')
+            d.appendVar('IMAGE_INSTALL', ' ' + alternate_kernel_pkg_name + '-modules')
+        else:
+            raise bb.parse.SkipRecipe("No KERNEL_PACKAGE_NAME:pn-%s set" % alternate_kernel )
+}

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

@@ -0,0 +1,5 @@
+# Include arm-autonomy distro config files if the distro features are set
+
+require ${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', '${ARM_AUTONOMY_DISTRO_CFGDIR}/arm-autonomy-host.inc', '', d)}
+require ${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-guest', '${ARM_AUTONOMY_DISTRO_CFGDIR}/arm-autonomy-guest.inc', '', d)}
+

meta-arm-autonomy/classes/docker_extern_containers.bbclass

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

meta-arm-autonomy/classes/image_types_xenguest.bbclass

@@ -0,0 +1,169 @@
+# 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')
+}
+

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

@@ -0,0 +1,37 @@
+# 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
+}

meta-arm-autonomy/classes/set_src_uri_from_var.bbclass

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

meta-arm-autonomy/classes/xenguest_image.bbclass

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

meta-arm-autonomy/classes/xenguest_image_extra.bbclass

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

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

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

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

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

meta-arm-autonomy/conf/layer.conf

@@ -0,0 +1,39 @@
+# Add layer to BBPATH
+BBPATH .= ":${LAYERDIR}"
+
+# Add recipes-* directories to BBFILES
+BBFILES += " \
+    ${LAYERDIR}/recipes-*/*/*.bb \
+    ${LAYERDIR}/recipes-*/*/*.bbappend \
+    "
+
+BBFILE_COLLECTIONS += "meta-arm-autonomy"
+BBFILE_PATTERN_meta-arm-autonomy = "^${LAYERDIR}/"
+BBFILE_PRIORITY_meta-arm-autonomy = "5"
+LAYERDEPENDS_meta-arm-autonomy = " \
+   core \
+   yocto \
+   openembedded-layer \
+   networking-layer \
+   virtualization-layer \
+"
+LAYERSERIES_COMPAT_meta-arm-autonomy = "honister"
+
+# 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"

meta-arm-autonomy/conf/machine/arm64-autonomy-guest.conf

@@ -0,0 +1,17 @@
+#@TYPE: Machine
+#@NAME: Autonomy Guest ARM64 machine
+#@DESCRIPTION: Machine configuration for ARM64 Autonomy Guest
+
+TUNE_FEATURES = "aarch64"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+KERNEL_IMAGETYPE = "Image"
+
+IMAGE_FSTYPES:append = " tar.bz2"
+
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_VERSION_linux-yocto ?= "5.10%"
+
+DISTRO_FEATURES += "arm-autonomy-guest"
+

meta-arm-autonomy/conf/xenguest.conf

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

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

@@ -0,0 +1,226 @@
+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.

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

@@ -0,0 +1,272 @@
+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 honister using `git checkout honister`).
+
+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.
+

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

@@ -0,0 +1,34 @@
+Customizing Arm Autonomy Host image layout for N1SDP
+====================================================
+
+When buiding with `DISTRO_FEATURES += "arm-autonomy-host"` the user can
+perform a couple of customizations in the generated wic image:
+
+1. Set the guest partition size (default: 4iG) via `GUEST_PART_SIZE` and
+   `GUEST_PART_SIZE_UNIT` (M or G) variables to be set in any conf file. The
+   value of these variables should be aligned with the sum of all
+   XENGUEST_IMAGE_DISK_SIZE set for the guests. By default, LVM2 metadata is
+   1 MiB per physical volume, hence it needs to be taken into account when
+   setting GUEST_PART_SIZE.
+
+2. Set the boot partition size (default: 100M) via `BOOT_PART_SIZE` and
+   `BOOT_PART_SIZE_UNIT` (M or G) variables in any conf file. The default
+   bootimg is ~44M so 100M leaves just over 50M of free space.
+
+3. The wic image partition layout and contents with a custom wks file via
+   `ARM_AUTONOMY_WKS_FILE` variable (default:
+   arm-autonomy-n1sdp-efidisk.wks.in which is affected by GUEST_PART_SIZE,
+   GUEST_PART_SIZE_UNIT, BOOT_PART_SIZE, BOOT_PART_SIZE_UNIT and
+   GRUB_CFG_FILE variables).
+
+4. Custom grub.cfg file via `GRUB_CFG_FILE` (default:
+   arm-autonomy-n1sdp-grub.cfg) variable to be set in any conf file. The full
+   path or relative to `ARM_AUTONOMY_WKS_FILE` should be set.
+
+The `arm-autonomy-n1sdp-efidisk.wks.in` and `arm-autonomy-n1sdp-grub.cfg` files
+are located at `meta-arm-autonomy/dynamic-layers/meta-arm-bsp/wic`.
+
+Other variables can also be 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.

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

@@ -0,0 +1,110 @@
+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.
+

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

@@ -0,0 +1,144 @@
+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

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

@@ -0,0 +1,128 @@
+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`
+

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

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

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

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

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

@@ -0,0 +1,39 @@
+# Extra machine settings for fvp-base
+
+# FVP uses vda as hard drive and partition 1 is the
+# default rootfs, so use vda2 for guest lvm
+XENGUEST_MANAGER_VOLUME_DEVICE ?= "/dev/vda2"
+
+# 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
+

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

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

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

@@ -0,0 +1,94 @@
+# 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"
+
+# '-mcpu=' and '-march=' conflicts for xen build
+# lets not set '-march=' and let xen to overwrite '-mcpu='
+TUNE_CCARGS:remove:pn-xen = "${TUNE_CCARGS_MARCH}${TUNE_CCARGS_MARCH_OPTS}"

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

@@ -0,0 +1,50 @@
+# Use OVERRIDES to minimize the usage of
+# ${@bb.utils.contains('DISTRO_FEATURES', 'autonomy-host', ...
+OVERRIDES:append = "${ARM_AUTONOMY_HOST_OVERRIDES}"
+
+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
+}

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

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

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

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

meta-arm-autonomy/dynamic-layers/meta-arm-bsp/recipes-bsp/u-boot/u-boot_%.bbappend

@@ -0,0 +1,10 @@
+# Use OVERRIDES to minimize the usage of
+# ${@bb.utils.contains('DISTRO_FEATURES', 'autonomy-host', ...
+OVERRIDES:append = "${ARM_AUTONOMY_HOST_OVERRIDES}"
+
+FILESEXTRAPATHS:prepend:autonomy-host:fvp-base := "${THISDIR}/${PN}:"
+
+#
+# FVP BASE
+#
+SRC_URI:append:autonomy-host:fvp-base = " file://xen_u-boot_kernel_addr.patch"

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

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

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

@@ -0,0 +1,51 @@
+/*
+ * 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;
+        };
+    };
+
+    /*
+     * Delete module node for Dom0, #size-cells and #address-cells because Grub2
+     * is responsible to create them
+     */
+    chosen {
+        /delete-property/ #size-cells;
+        /delete-property/ #address-cells;
+        /delete-node/ module@0;
+    };
+};

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

@@ -0,0 +1,23 @@
+# Platform dependent parameters
+
+FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
+
+# Add a dtb snippet to turn off iommu in dom0 on Juno board
+SRC_URI:append:juno = " file://xen-juno.dtsi"
+XEN_DEVICETREE_DTSI_MERGE:append:juno = " xen-juno.dtsi"
+
+# Add a dtb snippet to remove pmu and iommu in dom0 on N1SDP
+SRC_URI:append:n1sdp = " file://xen-n1sdp.dtsi"
+XEN_DEVICETREE_DTSI_MERGE:append:n1sdp = " xen-n1sdp.dtsi"
+# For N1SDP, the XEN_DEVICETREE_DEPEND and XEN_DEVICETREE_DTBS variables are
+# being set in meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/n1sdp-extra-settings.inc
+
+# Board specific configs
+XEN_DEVICETREE_DOM0_BOOTARGS:append:juno = " root=/dev/sda1 rootwait"
+XEN_DEVICETREE_XEN_BOOTARGS:append:juno = " console=dtuart dtuart=serial0 bootscrub=0 iommu=no"
+
+XEN_DEVICETREE_DOM0_BOOTARGS:append:n1sdp = " root=/dev/sda2 rootwait"
+XEN_DEVICETREE_XEN_BOOTARGS:append:n1sdp = " console=dtuart dtuart=serial0 bootscrub=0 iommu=no"
+
+XEN_DEVICETREE_DOM0_BOOTARGS:append:fvp-base = " root=/dev/vda1"
+XEN_DEVICETREE_XEN_BOOTARGS:append:fvp-base = " console=dtuart dtuart=serial0 bootscrub=0"

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

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

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

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

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

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

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

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

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

@@ -0,0 +1,15 @@
+# FVP Base support
+COMPATIBLE_MACHINE:fvp-base = "fvp-base"
+FILESEXTRAPATHS:prepend:fvp-base := "${THISDIR}/files:"
+SRC_URI:append:fvp-base = " file://early-printk.cfg"
+
+# Juno support
+COMPATIBLE_MACHINE:juno = "juno"
+FILESEXTRAPATHS:prepend:juno := "${THISDIR}/files:"
+SRC_URI:append:juno = " file://early-printk.cfg"
+
+# N1SDP support
+COMPATIBLE_MACHINE:n1sdp = "n1sdp"
+FILESEXTRAPATHS:prepend:n1sdp := "${THISDIR}/files:"
+SRC_URI:append:n1sdp = " file://n1sdp.cfg \
+                         file://early-printk.cfg"

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

@@ -0,0 +1,14 @@
+# short-description: Create a disk image
+# long-description: Creates a partitioned disk image that the user
+# can directly dd to boot media.
+
+# For FVP Base first partition is rootfs normally populated as /dev/vda1
+part / --source rootfs --ondisk sda --fstype=ext4 --label root --align 1024
+
+# Second partition to accomodate guests images normally populated as /dev/vda2 (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/vda3
+${AUTONOMY_HOST_EXTRA_PARTITION}
+
+bootloader --ptable msdos

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

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

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

@@ -0,0 +1,17 @@
+# short-description: Create an EFI disk image
+# long-description: Creates a partitioned EFI disk image that the user
+# can directly dd to boot media. Uses a custom grub.cfg file to configure the boot.
+
+# First boot partition normally populated as /dev/sda1
+part /boot --source bootimg-efi --sourceparams="loader=grub-efi" --ondisk sda --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}"

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

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

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

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

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

@@ -0,0 +1,3 @@
+OVERRIDES:append = "${ARM_AUTONOMY_HOST_OVERRIDES}"
+
+GRUB_BUILDIN:append:autonomy-host = " xen_boot"

meta-arm-autonomy/recipes-containers/import-docker-containers/files/import_containers.sh

@@ -0,0 +1,70 @@
+#!/bin/sh
+
+INSTALL_DIR="###CONTAINERS_INSTALL_DIR###"
+MANIFEST="${INSTALL_DIR}/###CONTAINERS_MANIFEST###"
+
+INIT_DIR="/etc/init.d"
+DOCKER_INIT="docker.init"
+
+find_docker_init() {
+    if [ -f "$INIT_DIR/$DOCKER_INIT" ]; then
+         $INIT_DIR/$DOCKER_INIT "start"
+    else
+        echo "ERROR: Couldn't find docker init script! ($INIT_DIR/$DOCKER_INIT)"
+        exit 1
+    fi
+}
+
+is_docker_started() {
+    if ! docker info > /dev/null 2>&1; then
+        find_docker_init
+    fi
+}
+
+check_manifest() {
+    if [ ! -f ${MANIFEST} ]; then
+        echo "No manifest found!"
+        exit 1
+    fi
+}
+
+has_docker_image() {
+    docker image inspect "$1" >/dev/null 2>&1
+}
+
+start() {
+    check_manifest
+    is_docker_started
+
+    while read -r archive name tag keep _; do
+
+        CONTAINER_IMAGE_NAME_AND_TAG="${name}:${tag}"
+
+        # Image does not exist and image file exists: Import the image.
+        if ! has_docker_image "${CONTAINER_IMAGE_NAME_AND_TAG}" && \
+           [ -f "${INSTALL_DIR}/${archive}" ]; then
+            echo "Importing ${CONTAINER_IMAGE_NAME_AND_TAG} container image..."
+            docker import "${INSTALL_DIR}/${archive}" \
+                   "${CONTAINER_IMAGE_NAME_AND_TAG}" 2>&1 || {
+                echo "Import ${CONTAINER_IMAGE_NAME_AND_TAG} container image: Failed."
+                exit $?
+            }
+            echo "Import ${CONTAINER_IMAGE_NAME_AND_TAG} container image: Done."
+
+            if [ "${keep}" != "1" ]; then
+                rm "${INSTALL_DIR}/${archive}"
+            fi
+        fi
+    done < ${MANIFEST}
+}
+
+case "$1" in
+    start)
+        start && exit 0
+        ;;
+    *)
+        echo "Usage: $0 {start}"
+        exit 2
+esac
+
+exit $?

meta-arm-autonomy/recipes-containers/import-docker-containers/import-docker-containers.bb

@@ -0,0 +1,36 @@
+#
+# This recipe adds an init script to import the containers added by
+# docker_extern_containers.bbclass at boot time
+# Notes:
+# docker_extern_containers.bbclass creates a manifest file which contains
+# the columns:   archive   name   tag   keep
+# for each container. This file is read by the import_containers
+# script to determine the parameters of the import
+#
+# Since the script needs knowledge of the values of $CONTAINERS_INSTALL_DIR
+# and $CONTAINERS_MANIFEST these are substituted for placeholder strings when
+# the script is installed.
+
+DESCRIPTION = "Add init script to import docker images at boot"
+LICENSE = "MIT"
+
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+inherit docker_extern_containers
+
+SRC_URI = "file://import_containers.sh"
+
+inherit update-rc.d
+INITSCRIPT_PARAMS = "start 30 2 3 4 5 ."
+INITSCRIPT_NAME = "import_containers.sh"
+
+S = "${WORKDIR}"
+do_install:append() {
+    install -d ${D}${sysconfdir}/init.d
+    install -m 755 import_containers.sh ${D}${sysconfdir}/init.d
+
+    sed -i "s,###CONTAINERS_INSTALL_DIR###,${CONTAINERS_INSTALL_DIR}," \
+           ${D}${sysconfdir}/init.d/import_containers.sh
+    sed -i "s,###CONTAINERS_MANIFEST###,${CONTAINERS_MANIFEST}," \
+           ${D}${sysconfdir}/init.d/import_containers.sh
+}