1
0
mirror of https://git.yoctoproject.org/meta-arm synced 2026-07-18 16:37:08 +00:00

Compare commits

..

1 Commits

Author SHA1 Message Date
Denys Dmytriyenko fa9abd9a6e trusted-firmware-a: re-enable generation of packages
There is no need to inherit nopackages. Even when the output binaries are being
consumed from deploy or sysroot, and the main binary package is not meant to be
installed in the rootfs, package generation is still useful for SDK use cases
and as a way to distribute sources (e.g. src.rpm/SRPM) in Distros.

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Reviewed-by: Diego Sueiro <diego.sueiro@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2020-05-19 13:40:10 -04:00
851 changed files with 15670 additions and 66525 deletions
-1
View File
@@ -1 +0,0 @@
__pycache__
-293
View File
@@ -1,293 +0,0 @@
image: ghcr.io/siemens/kas/kas:3.2
variables:
CPU_REQUEST: ""
DEFAULT_TAG: ""
# These are needed as the k8s executor doesn't respect the container entrypoint
# by default
FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY: 0
FF_KUBERNETES_HONOR_ENTRYPOINT: 1
# The directory to use as the persistent cache (the root for DL_DIR,
# SSTATE_DIR, etc). The default is the build tree which will not be
# persistent, so this should be set in the runner.
CACHE_DIR: $CI_PROJECT_DIR
stages:
- prep
- build
# Common job fragment to get a worker ready
.setup:
tags:
- $DEFAULT_TAG
stage: build
interruptible: true
variables:
KAS_WORK_DIR: $CI_PROJECT_DIR/work
KAS_BUILD_DIR: $KAS_WORK_DIR/build
KAS_REPO_REF_DIR: ""
SSTATE_DIR: $CACHE_DIR/sstate
DL_DIR: $CACHE_DIR/downloads
BB_LOGCONFIG: $CI_PROJECT_DIR/ci/logging.yml
TOOLCHAIN_DIR: $CACHE_DIR/toolchains
IMAGE_DIR: $CI_PROJECT_DIR/work/build/tmp/deploy/images
TOOLCHAIN_LINK_DIR: $CI_PROJECT_DIR/work/build/toolchains
before_script:
- rm -rf $KAS_WORK_DIR
- mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
# Must do this here, as it's the only way to make sure the toolchain is installed on the same builder
- ./ci/get-binary-toolchains $DL_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
# Generalised fragment to do a Kas build
.build:
extends: .setup
variables:
KUBERNETES_CPU_REQUEST: $CPU_REQUEST
script:
- KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME")
- kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
- kas build $KASFILES
- ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
artifacts:
name: "logs"
when: on_failure
paths:
- $CI_PROJECT_DIR/work/build/tmp/work*/**/temp/log.do_*.*
# Workaround for Zephyr not currectly handling TESTIMAGE_AUTO
.build_and_test:
extends: .setup
script:
- KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME")
- kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
- kas build $KASFILES
- kas build $KASFILES -c testimage
- ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
#
# Prep stage, update repositories once.
# Set the CI variable CI_CLEAN_REPOS=1 to refetch the respositories from scratch
#
update-repos:
extends: .setup
stage: prep
script:
- |
exit_code=0
printenv
if [ -n "$KAS_REPO_REF_DIR" ]; then
flock --verbose --timeout 60 $KAS_REPO_REF_DIR --command ./ci/update-repos || exit_code=$?
# Exit now if that failed, unless the status was 128 (fetch failed)
test $exit_code != 0 -a $exit_code != 128 && exit 1
fi
exit $exit_code
#
# Build stage, the actual build jobs
#
# Available options for building are
# TOOLCHAINS: [gcc, clang, armgcc, external-gccarm]
# TCLIBC: [glibc, musl]
# VIRT: [none, xen]
# TESTING: testimage
corstone500:
extends: .build
parallel:
matrix:
- TESTING: testimage
tags:
- x86_64
corstone1000-fvp:
extends: .build
parallel:
matrix:
- TESTING: [testimage,tftf]
tags:
- x86_64
corstone1000-mps3:
extends: .build
fvp-base:
extends: .build
parallel:
matrix:
- TESTING: testimage
tags:
- x86_64
fvp-base-arm32:
extends: .build
parallel:
matrix:
- TOOLCHAINS: [gcc, external-gccarm]
TESTING: testimage
tags:
- x86_64
fvp-baser-aemv8r64:
extends: .build
parallel:
matrix:
- TESTING: testimage
tags:
- x86_64
fvps:
extends: .build
gem5-arm64:
extends: .build
parallel:
matrix:
- VIRT: [none, xen]
gem5-atp-arm64:
extends: .build
generic-arm64:
extends: .build
juno:
extends: .build
parallel:
matrix:
- TOOLCHAINS: [gcc, clang]
FIRMWARE: [none, edk2]
microbit-v1:
extends: .build_and_test
parallel:
matrix:
- TESTING: testimage-zephyr
musca-b1:
extends: .build
musca-s1:
extends: .build
n1sdp:
extends: .build
parallel:
matrix:
- TOOLCHAINS: [gcc, armgcc]
qemu-cortex-a53:
extends: .build
qemu-cortex-m3:
extends: .build_and_test
parallel:
matrix:
- TESTING: testimage-zephyr
qemu-cortex-r5:
extends: .build
qemu-generic-arm64:
extends: .build
parallel:
matrix:
- TOOLCHAINS: [gcc, clang]
TESTING: testimage
qemuarm64-secureboot:
extends: .build
parallel:
matrix:
- TOOLCHAINS: [gcc, clang]
TCLIBC: [glibc, musl]
TESTING: testimage
qemuarm64:
extends: .build
parallel:
matrix:
- VIRT: xen
qemuarm:
extends: .build
parallel:
matrix:
- TOOLCHAINS: [gcc, clang]
TESTING: testimage
- VIRT: xen
qemuarmv5:
extends: .build
parallel:
matrix:
- TESTING: testimage
sgi575:
extends: .build
tc0:
extends: .build
tags:
- x86_64
tc1:
extends: .build
tags:
- x86_64
toolchains:
extends: .build
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
# Only run this job for the default branch (master), or if forced with
# BUILD_FORCE_PENDING_UPDATES.
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
- if: $BUILD_FORCE_PENDING_UPDATES != null
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:
extends: .setup
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"
+16 -51
View File
@@ -1,46 +1,23 @@
Introduction
------------
This repository contains the Arm layers for OpenEmbedded.
This repository contains Arm layers for OpenEmbedded
* meta-arm
meta-arm:
This layer provides support for general recipes for the Arm
architecture. Anything that's not needed explicitly for BSPs, the IOTA
distribution, or destined to be upstreamed belongs here.
This layer contains general recipes for the Arm architecture, such as firmware, FVPs, and Arm-specific integration.
meta-arm-bsp:
This layer provides support for Arm reference platforms
* meta-arm-autonomy
meta-arm-iota:
This layer provides support for Arm's IOTA Linux Distribution
This layer is the distribution for a reference stack for autonomous systems.
meta-arm-toolchain:
This layer provides support for Arm's GNU-A toolset releases
* meta-arm-bsp
This layer contains machines for Arm reference platforms, for example FVP Base, N1SDP, and Juno.
* meta-arm-toolchain
This layer contains recipes for Arm's binary toolchains (GCC and Clang for -A and -M), and a recipe to build Arm's GCC.
* meta-atp
This layer contains recipes for the Adaptive Traffic Generation integration into meta-gem5.
* meta-gem5
This layer contains recipes and machines for gem5, a system-level and processor simulator.
Other Directories
-----------------
* ci
This directory contains gitlab continuous integration configuration files (KAS yaml files) as well as scripts needed for this
* kas
This directory contains KAS yaml files to describe builds for systems not used in CI
* scripts
This directory contains scripts used in running the CI tests
meta-arm-autonomy:
This layer provides a reference stack for autonomous systems.
Contributing
------------
@@ -48,26 +25,14 @@ Currently, we only accept patches from the meta-arm mailing list. For general
information on how to submit a patch, please read
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
E-mail meta-arm@lists.yoctoproject.org with patches created using this process. You can configure git-send-email to automatically use this address for the meta-arm repository with the following git command:
$ git config --local --add sendemail.to meta-arm@lists.yoctoproject.org
Commits and patches added should follow the OpenEmbedded patch guidelines:
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
The component being changed in the shortlog should be prefixed with the layer name (without the meta- prefix), for example:
arm-bsp/trusted-firmware-a: decrease frobbing level
arm-toolchain/gcc: enable foobar v2
E-mail meta-arm@lists.yoctoproject.org with patches created using this process
Reporting bugs
--------------
E-mail meta-arm@lists.yoctoproject.org with the error encountered and the steps
to reproduce the issue.
to reproduce the issue
Maintainer(s)
-------------
* Jon Mason <jon.mason@arm.com>
* Ross Burton <ross.burton@arm.com>
-6
View File
@@ -1,6 +0,0 @@
header:
version: 11
local_conf_header:
cc: |
GCCVERSION = "arm-11.2"
-50
View File
@@ -1,50 +0,0 @@
header:
version: 11
distro: poky
defaults:
repos:
refspec: kirkstone
repos:
meta-arm:
layers:
meta-arm:
meta-arm-bsp:
meta-arm-toolchain:
poky:
url: https://git.yoctoproject.org/poky
layers:
meta:
meta-poky:
env:
BB_LOGCONFIG: ""
TOOLCHAIN_DIR: ""
local_conf_header:
base: |
BB_SERVER_TIMEOUT = "60"
CONF_VERSION = "2"
BB_NUMBER_THREADS = "16"
PARALLEL_MAKE = "-j16"
LICENSE_FLAGS_ACCEPTED += "Arm-FVP-EULA"
setup: |
PACKAGE_CLASSES = "package_ipk"
PACKAGECONFIG:remove:pn-qemu-system-native = "gtk+ sdl"
EXTRA_IMAGE_FEATURES:append = " debug-tweaks"
PACKAGECONFIG:append:pn-perf = " coresight"
INHERIT += "rm_work"
DISTRO_FEATURES:remove = "ptest"
kvm: |
QEMU_USE_KVM = ""
perf: |
CORE_IMAGE_EXTRA_INSTALL += "perf"
sshkeys: |
CORE_IMAGE_EXTRA_INSTALL += "ssh-pregen-hostkeys"
machine: unset
target:
- core-image-base
-28
View File
@@ -1,28 +0,0 @@
#! /usr/bin/env python3
from pathlib import Path
import sys
from listmachines import list_machines
metaarm = Path.cwd()
if metaarm.name != "meta-arm":
print("Not running inside meta-arm")
sys.exit(1)
# Find all layers
layers = (p.name for p in metaarm.glob("meta-*") if p.is_dir())
# All machine configurations
machines = list_machines(layers)
# All kas files
kas = metaarm.glob("ci/*.yml")
kas = set(p.stem for p in kas)
missing = machines - kas
print(f"The following machines are missing: {', '.join(sorted(missing))}.")
covered = len(machines) - len(missing)
total = len(machines)
percent = int(covered / total * 100)
print(f"Coverage: {percent}%")
-19
View File
@@ -1,19 +0,0 @@
#! /bin/bash
# Expects the path to a log file as $1, and if this file has any content
# then display the contents and exit with an error code.
set -e -u
LOGFILE=$1
LINES=$(grep --invert-match "attempting MIRRORS if available" $LOGFILE | wc -l)
if test "$LINES" -ne 0; then
echo ==============================
echo The build had warnings/errors:
echo ==============================
cat $LOGFILE
exit 1
fi
exit 0
-10
View File
@@ -1,10 +0,0 @@
header:
version: 11
repos:
meta-clang:
url: https://github.com/kraj/meta-clang
local_conf_header:
clang: |
TOOLCHAIN = "clang"
-13
View File
@@ -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
-12
View File
@@ -1,12 +0,0 @@
header:
version: 11
includes:
- ci/corstone1000-common.yml
local_conf_header:
fvp-config: |
# Remove Dropbear SSH as it will not fit into the corstone1000 image.
IMAGE_FEATURES:remove = " ssh-server-dropbear"
INHERIT += "fvpboot"
machine: corstone1000-fvp
-6
View File
@@ -1,6 +0,0 @@
header:
version: 11
includes:
- ci/corstone1000-common.yml
machine: corstone1000-mps3
-18
View File
@@ -1,18 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
local_conf_header:
testimagefvp: |
INHERIT += "fvpboot"
IMAGE_FEATURES:remove = " ssh-server-dropbear"
perf: |
machine: corstone500
distro: poky-tiny
target:
- core-image-minimal
- perf
-9
View File
@@ -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"
-8
View File
@@ -1,8 +0,0 @@
header:
version: 11
local_conf_header:
cc: |
SKIP_RECIPE[gcc-cross-arm] = "Using external toolchain"
TCMODE = "external-arm"
EXTERNAL_TOOLCHAIN = "${TOPDIR}/toolchains/${TARGET_ARCH}"
-16
View File
@@ -1,16 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: fvp-base-arm32
local_conf_header:
testimagefvp: |
INHERIT = "fvpboot"
# This fails but we can't add to the ignorelist from meta-arm yet
# https://bugzilla.yoctoproject.org/show_bug.cgi?id=14604
TEST_SUITES:remove = "parselogs"
# Tell testimage to connect to localhost:8122, and forward that to SSH in the FVP.
TEST_TARGET_IP = "127.0.0.1:8122"
FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] = "8122=22"
-16
View File
@@ -1,16 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: fvp-base
local_conf_header:
testimagefvp: |
INHERIT += "fvpboot"
# This fails but we can't add to the ignorelist from meta-arm yet
# https://bugzilla.yoctoproject.org/show_bug.cgi?id=14604
TEST_SUITES:remove = "parselogs"
# Tell testimage to connect to localhost:8022, and forward that to SSH in the FVP.
TEST_TARGET_IP = "localhost:8022"
FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] ?= "8022=22"
-7
View File
@@ -1,7 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: fvp-baser-aemv8r64
-20
View File
@@ -1,20 +0,0 @@
# Simple target to build the FVPs that are publically available
header:
version: 11
includes:
- ci/base.yml
machine: qemuarm64
local_conf_header:
sdk: |
SDKMACHINE = "x86_64"
target:
- nativesdk-fvp-base-a-aem
- nativesdk-fvp-n1-edge
- nativesdk-fvp-sgi575
- nativesdk-fvp-corstone500
- nativesdk-fvp-corstone1000
- nativesdk-fvp-tc0
-16
View File
@@ -1,16 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
- ci/meta-openembedded.yml
repos:
meta-arm:
layers:
meta-gem5:
machine: gem5-arm64
target:
- core-image-minimal
- gem5-aarch64-native
-15
View File
@@ -1,15 +0,0 @@
header:
version: 11
includes:
- ci/gem5-arm64.yml
repos:
meta-arm:
layers:
meta-atp:
machine: gem5-atp-arm64
target:
- atp-native
- core-image-minimal
-6
View File
@@ -1,6 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: generic-arm64
-50
View File
@@ -1,50 +0,0 @@
#!/bin/bash
set -u -e
BASENAME=gcc-arm
VER=${VER:-10.3-2021.07}
HOST_ARCH=${HOST_ARCH:-$(uname -m)}
DOWNLOAD_DIR=$1
TOOLCHAIN_DIR=$2
TOOLCHAIN_LINK_DIR=$3
# These should be already created by .gitlab-ci.yml, but do here if run outside of that env
mkdir -p $DOWNLOAD_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
download() {
TRIPLE=$1
URL=https://developer.arm.com/-/media/Files/downloads/gnu-a/$VER/binrel/$BASENAME-$VER-$HOST_ARCH-$TRIPLE.tar.xz
wget -P $DOWNLOAD_DIR -nc $URL
}
if [ $HOST_ARCH = "aarch64" ]; then
# AArch64 Linux hosted cross compilers
# AArch32 target with hard float
download arm-none-linux-gnueabihf
elif [ $HOST_ARCH = "x86_64" ]; then
# x86_64 Linux hosted cross compilers
# AArch32 target with hard float
download arm-none-linux-gnueabihf
# AArch64 GNU/Linux target
download aarch64-none-linux-gnu
else
echo "ERROR - Unknown build arch of $HOST_ARCH"
exit 1
fi
for i in arm aarch64; do
if [ ! -d $TOOLCHAIN_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*/ ]; then
if [ ! -f $DOWNLOAD_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz ]; then
continue
fi
tar -C $TOOLCHAIN_DIR -axvf $DOWNLOAD_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz
fi
# Setup a link for the toolchain to use local to the building machine (e.g., not in a shared location)
ln -s $TOOLCHAIN_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu* $TOOLCHAIN_LINK_DIR/$i
done
-27
View File
@@ -1,27 +0,0 @@
#! /bin/bash
# This script is expecting an input of machine name, optionally followed by a
# colon and a list of one or more parameters separated by commas between
# brackets. For example, the following are acceptable:
# corstone500
# fvp-base: [testimage]
# qemuarm64-secureboot: [clang, glibc, testimage]
#
# Turn this list into a series of yml files separated by colons to pass to kas
set -e -u
FILES="ci/$(echo $1 | cut -d ':' -f 1).yml"
for i in $(echo $1 | cut -s -d ':' -f 2 | sed 's/[][,]//g'); do
# Given that there are no yml files for gcc or glibc, as those are the
# defaults, we can simply ignore those parameters. They are necessary
# to pass in so that matrix can correctly setup all of the permutations
# of each individual run.
if [[ $i == 'none' || $i == 'gcc' || $i == 'glibc' ]]; then
continue
fi
FILES+=":ci/$i.yml"
done
echo $FILES
-6
View File
@@ -1,6 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: juno
-29
View File
@@ -1,29 +0,0 @@
#! /usr/bin/env python3
import pathlib
import typing
import sys
"""
List all of the machines available under the listed sub-layers of meta-arm.
"""
def list_machines(layers: typing.Sequence[str]) -> typing.Set[str]:
machines = set()
# We know we're in meta-arm/scripts, so find the top-level directory
metaarm = pathlib.Path(__file__).resolve().parent.parent
if metaarm.name != "meta-arm":
raise Exception("Not running inside meta-arm")
for layer in layers:
machines |= set(p.stem for p in (metaarm / layer / "conf" / "machine").glob("*.conf"))
return machines
if __name__ == "__main__":
if len(sys.argv) > 1:
machines = list_machines(sys.argv[1:])
print(" ".join(sorted(machines)))
sys.exit(0)
else:
print("Usage:\n$ %s [layer name ...] " % sys.argv[0])
sys.exit(1)
-13
View File
@@ -1,13 +0,0 @@
# Python logging configuration to write all warnings to a separate file
version: 1
handlers:
warnings:
class: logging.FileHandler
level: WARNING
filename: warnings.log
formatter: BitBake.logfileFormatter
loggers:
BitBake:
handlers: [warnings]
-11
View File
@@ -1,11 +0,0 @@
header:
version: 11
repos:
meta-openembedded:
url: https://git.openembedded.org/meta-openembedded
layers:
meta-filesystems:
meta-networking:
meta-oe:
meta-python:
-8
View File
@@ -1,8 +0,0 @@
header:
version: 11
includes:
- ci/meta-openembedded.yml
repos:
meta-virtualization:
url: https://git.yoctoproject.org/meta-virtualization
-13
View File
@@ -1,13 +0,0 @@
header:
version: 11
includes:
- ci/meta-openembedded.yml
repos:
meta-zephyr:
url: https://git.yoctoproject.org/meta-zephyr
layers:
meta-zephyr-core:
target:
- zephyr-kernel-test-all
-7
View File
@@ -1,7 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
- ci/meta-zephyr.yml
machine: microbit-v1
-15
View File
@@ -1,15 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
- ci/meta-zephyr.yml
local_conf_header:
nonbuilding_tests: |
ZEPHYRTESTS:remove = "common sleep poll device queue"
machine: musca-b1
target:
- trusted-firmware-m
- zephyr-kernel-test-all
-15
View File
@@ -1,15 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
- ci/meta-zephyr.yml
local_conf_header:
nonbuilding_tests: |
ZEPHYRTESTS:remove = "common sleep poll device queue"
machine: musca-s1
target:
- trusted-firmware-m
- zephyr-kernel-test-all
-6
View File
@@ -1,6 +0,0 @@
header:
version: 11
local_conf_header:
libc: |
TCLIBC = "musl"
-6
View File
@@ -1,6 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: n1sdp
-286
View File
@@ -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)
-9
View File
@@ -1,9 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
- ci/meta-zephyr.yml
# FIXME - testimage fails all tests currently, but all the tests build
machine: qemu-cortex-a53
-20
View File
@@ -1,20 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
- ci/meta-zephyr.yml
repos:
meta-zephyr:
layers:
meta-zephyr-bsp:
local_conf_header:
tclibc: |
TCLIBC = "newlib"
nonbuilding_tests: |
ZEPHYRTESTS:remove = "context pending poll sleep"
qemu_opts: |
QB_OPT_APPEND = "-icount shift=3,align=off,sleep=on -rtc clock=vm"
machine: qemu-cortex-m3
-11
View File
@@ -1,11 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
- ci/meta-zephyr.yml
local_conf_header:
nonbuilding_tests: |
ZEPHYRTESTS:remove = "common poll sleep queue device"
machine: qemu-cortex-r5
-14
View File
@@ -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
-6
View File
@@ -1,6 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: qemuarm
-18
View File
@@ -1,18 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: qemuarm64-secureboot
local_conf_header:
failing_tests: |
# software IO TLB: Cannot allocate buffer
DEFAULT_TEST_SUITES:remove = "parselogs"
target:
- core-image-base
- optee-examples
- optee-test
- optee-spdevkit
- optee-os-tadevkit
-6
View File
@@ -1,6 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: qemuarm64
-6
View File
@@ -1,6 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: qemuarmv5
-7
View File
@@ -1,7 +0,0 @@
header:
version: 11
local_conf_header:
setup: |
BB_LOGCONFIG = ""
SANITY_TESTED_DISTROS = ""
-6
View File
@@ -1,6 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: sgi575
-9
View File
@@ -1,9 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: tc0
target:
- tc-artifacts-image
-9
View File
@@ -1,9 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
machine: tc1
target:
- tc-artifacts-image
-8
View File
@@ -1,8 +0,0 @@
header:
version: 11
local_conf_header:
testimage: |
IMAGE_CLASSES += "testimage"
TEST_TARGET = "QemuTargetZephyr"
TEST_SUITES = "zephyr"
-13
View File
@@ -1,13 +0,0 @@
header:
version: 11
local_conf_header:
testimage: |
IMAGE_CLASSES += "testimage"
TESTIMAGE_AUTO = "1"
slirp: |
TEST_RUNQEMUPARAMS = "slirp"
TEST_SERVER_IP = "127.0.0.1"
QEMU_USE_SLIRP = "1"
sshd: |
IMAGE_FEATURES:append = " ssh-server-dropbear"
-7
View File
@@ -1,7 +0,0 @@
header:
version: 9
local_conf_header:
tftf: |
TFA_UBOOT = "0"
TFTF_TESTS = "1"
-19
View File
@@ -1,19 +0,0 @@
header:
version: 11
includes:
- ci/base.yml
# Target is arm64 and SDK is x86-64 to ensure that we exercise both
# architectures
machine: qemuarm64
local_conf_header:
toolchains: |
SDKMACHINE = "x86_64"
target:
- gcc-aarch64-none-elf
- nativesdk-gcc-aarch64-none-elf
- gcc-arm-none-eabi
- nativesdk-gcc-arm-none-eabi
- nativesdk-androidclang
-49
View File
@@ -1,49 +0,0 @@
#! /usr/bin/env python3
# Update clones of the repositories we need in KAS_REPO_REF_DIR to speed up fetches
import sys
import os
import shutil
import subprocess
import pathlib
def repo_shortname(url):
# Taken from Kas (Repo.__getattr__) to ensure the logic is right
from urllib.parse import urlparse
url = urlparse(url)
return ('{url.netloc}{url.path}'
.format(url=url)
.replace('@', '.')
.replace(':', '.')
.replace('/', '.')
.replace('*', '.'))
repositories = (
"https://git.yoctoproject.org/poky",
"https://git.openembedded.org/meta-openembedded",
"https://git.yoctoproject.org/meta-virtualization",
"https://git.yoctoproject.org/meta-zephyr",
"https://github.com/kraj/meta-clang",
)
if __name__ == "__main__":
if "KAS_REPO_REF_DIR" not in os.environ:
print("KAS_REPO_REF_DIR needs to be set")
sys.exit(1)
base_repodir = pathlib.Path(os.environ["KAS_REPO_REF_DIR"])
for repo in repositories:
repodir = base_repodir / repo_shortname(repo)
if "CI_CLEAN_REPOS" in os.environ:
print("Cleaning %s..." % repo)
shutil.rmtree(repodir, ignore_errors=True)
if repodir.exists():
print("Updating %s..." % repo)
subprocess.run(["git", "-C", repodir, "-c", "gc.autoDetach=false", "fetch"], check=True)
else:
print("Cloning %s..." % repo)
subprocess.run(["git", "clone", "--bare", repo, repodir], check=True)
-11
View File
@@ -1,11 +0,0 @@
header:
version: 11
includes:
- ci/meta-virtualization.yml
local_conf_header:
meta-virt: |
DISTRO_FEATURES:append = " virtualization xen"
target:
- xen-image-minimal
-55
View File
@@ -1,55 +0,0 @@
# OEQA on Arm FVPs
OE-Core's [oeqa][OEQA] framework provides a method of performing runtime tests on machines using the `testimage` Yocto task. meta-arm has good support for writing test cases against [Arm FVPs][FVP], meaning the [runfvp][RUNFVP] boot configuration can be re-used.
Tests can be configured to run automatically post-build by setting the variable `TESTIMAGE_AUTO="1"`, e.g. in your Kas file or local.conf.
There are two main methods of testing, using different test "targets".
## OEFVPTarget
This runs test cases on a machine using SSH. It therefore requires that an SSH server is installed in the image.
In test cases, the primary interface with the target is, e.g:
```
(status, output) = self.target.run('uname -a')
```
which runs a single command on the target (using `ssh -c`) and returns the status code and the output. It is therefore useful for running tests in a Linux environment.
For examples of test cases, see meta/lib/oeqa/runtime/cases in OE-Core. The majority of test cases depend on `ssh.SSHTest.test_ssh`, which first validates that the SSH connection is functioning.
Example machine configuration:
```
TEST_TARGET = "OEFVPTarget"
TEST_SERVER_IP = "127.0.0.1"
TEST_TARGET_IP = "127.0.0.1:8022"
IMAGE_FEATURES:append = " ssh-server-dropbear"
FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] ?= "8022=22"
```
## OEFVPSerialTarget
This runs tests against one or more serial consoles on the FVP. It is more flexible than OEFVPTarget, but test cases written for this test target do not support the test cases in OE-core. As it does not require an SSH server, it is suitable for machines with performance or memory limitations.
Internally, this test target launches a [Pexpect][PEXPECT] instance for each entry in FVP_CONSOLES which can be used with the provided alias. The whole Pexpect API is exposed on the target, where the alias is always passed as the first argument, e.g.:
```
self.target.expect('default', r'root@.*\:~#', timeout=30)
self.assertNotIn(b'ERROR:', self.target.before('tf-a'))
```
For an example of a full test case, see meta-arm/lib/oeqa/runtime/cases/linuxboot.py This test case can be used to minimally verify that a machine boots to a Linux shell. The default timeout is 10 minutes, but this can be configured with the variable TEST_FVP_LINUX_BOOT_TIMEOUT, which expects a value in seconds.
The SSH interface described above is also available on OEFVPSerialTarget to support writing a set of hybrid test suites that use a combination of serial and SSH access. Note however that this test target does not guarantee that Linux has booted to shell prior to running any tests, so the test cases in OE-core are not supported.
Example machine configuration:
```
TEST_TARGET="OEFVPSerialTarget"
TEST_SUITES="linuxboot"
FVP_CONSOLES[default] = "terminal_0"
FVP_CONSOLES[tf-a] = "s_terminal_0"
```
[OEQA]: https://docs.yoctoproject.org/test-manual/intro.html
[FVP]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
[RUNFVP]: runfvp.md
[PEXPECT]: https://pexpect.readthedocs.io/en/stable/overview.html
-131
View File
@@ -1,131 +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_CONSOLES`
This specifies what serial ports can be used in oeqa tests, along with an alias to be used in the test cases. Note that the values have to be the FVP identifier but without the board prefix, for example:
```
FVP_CONSOLES[default] = "terminal_0"
FVP_CONSOLES[tf-a] = "s_terminal_0"
```
The 'default' console is also used when `--console` is passed to runfvp.
### `FVP_EXTRA_ARGS`
Arbitrary extra arguments that are passed directly to the FVP. For example:
```
FVP_EXTRA_ARGS = "--simlimit 60"
```
### `FVP_ENV_PASSTHROUGH`
The FVP is launched with an isolated set of environment variables. Add the name of a Bitbake variable to this list to pass it through to the FVP environment. For example:
```
FVP_ENV_PASSTHROUGH = "ARMLMD_LICENSE_FILE FM_TRACE_PLUGINS"
```
[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
-42
View File
@@ -1,42 +0,0 @@
header:
version: 11
distro: poky-tiny
defaults:
repos:
refspec: kirkstone
repos:
meta-arm:
layers:
meta-arm:
meta-arm-bsp:
meta-arm-toolchain:
poky:
url: https://git.yoctoproject.org/git/poky
layers:
meta:
meta-poky:
meta-yocto-bsp:
meta-openembedded:
url: https://git.openembedded.org/meta-openembedded
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"
machine: unset
target:
- corstone1000-image
-16
View File
@@ -1,16 +0,0 @@
header:
version: 11
includes:
- kas/corstone1000-base.yml
machine: corstone1000-fvp
local_conf_header:
fvp-config: |
# Remove Dropbear SSH as it will not fit into the corstone1000 image.
IMAGE_FEATURES:remove = " ssh-server-dropbear"
INHERIT = " ${@bb.utils.contains('BUILD_ARCH', 'x86_64', 'fvpboot', '', d)}"
LICENSE_FLAGS_ACCEPTED:append = " Arm-FVP-EULA"
target:
- corstone1000-image
-6
View File
@@ -1,6 +0,0 @@
header:
version: 11
includes:
- kas/corstone1000-base.yml
machine: corstone1000-mps3
-47
View File
@@ -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
-41
View File
@@ -1,41 +0,0 @@
header:
version: 9
distro: poky
machine: fvp-baser-aemv8r64
defaults:
repos:
refspec: master
repos:
meta-arm:
url: https://git.yoctoproject.org/git/meta-arm
path: layers/meta-arm
layers:
meta-arm:
meta-arm-bsp:
meta-arm-toolchain:
poky:
url: https://git.yoctoproject.org/git/poky
path: layers/poky
layers:
meta:
meta-poky:
env:
FVP_BASE_R_ARM_EULA_ACCEPT: "False"
local_conf_header:
base: |
CONF_VERSION = "2"
PACKAGE_CLASSES = "package_ipk"
PACKAGECONFIG:remove:pn-qemu-system-native = "gtk+ sdl"
EXTRA_IMAGE_FEATURES:append = " debug-tweaks ssh-server-openssh"
CORE_IMAGE_EXTRA_INSTALL:append = " ssh-pregen-hostkeys"
LICENSE_FLAGS_ACCEPTED:append = " ${@oe.utils.vartrue('FVP_BASE_R_ARM_EULA_ACCEPT', 'Arm-FVP-EULA', '', d)}"
IMAGE_CLASSES:append = " testimage"
target:
- core-image-minimal
-8
View File
@@ -1,8 +0,0 @@
header:
version: 9
includes:
- kas/fvp-baser-aemv8r64-bsp.yml
local_conf_header:
base-rt: |
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
-7
View File
@@ -1,7 +0,0 @@
header:
version: 9
local_conf_header:
tftf: |
TFA_UBOOT = "0"
TFTF_TESTS = "1"
+78 -9
View File
@@ -1,16 +1,84 @@
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 guests
systems.
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)
Distribution Features
---------------------
This layer is adding the following Yocto DISTRO_FEATURES:
* arm-autonomy-host: this feature activates functionalities required to build
an autonomy host system. It is doing the following:
- add 'xen' and 'ipv4' to DISTRO_FEATURES.
- add xen backend drivers to linux kernel configuration.
- To reduce the root filesystem image size the kernel image is not installed.
* arm-autonomy-guest: this feature activates functionalities to run as guest
of an autonomy system. It is doing the following:
- add 'ipv4' to DISTRO_FEATURES.
- add xen frontend drivers to linux kernel configuration.
- add console on hvc0 during init.
Bitbake variables
-----------------
Some recipes and classes in this layer are introducing variables which can be
modified by the user in local.conf.
Each recipe introducing such variables has a chapter "Bitbake parameters" in
its documentation.
Those documentation files should be checked for variables:
- [xen-devicetree](documentation/xen-devicetree.md)
- [xenguest-manager](documentation/xenguest-manager.md)
- [xenguest-network-bridge](documentation/xenguest-network-bridge.md)
BSPs
----
This layer is adding the following machines:
* arm64-autonomy-guest: this machines creates a minimal BSP suitable to be used
as an autonomy guest. It is in fact only activating ARM64 architecture and
SMP in the linux kernel and is enabling the DISTRO_FEATURE
arm-autonomy-guest.
Images
------
This layer is adding the following images:
* arm-autonomy-host-image-minimal: this image includes all elements required
to create a minimal arm-autonomy-host system. This includes xen and tools to
manage xen guests. This image depends on 'arm-autonomy-host' distribution
feature.
Recipes and classes
-------------------
This layer is adding the following recipes and classes:
* [xen-devicetree](documentation/xen-devicetree.md): this is a recipe to modify
a device tree blob to add information required to boot xen and a Dom0 linux.
* [xenguest-mkimage](documentation/xenguest-mkimage.md): this is a tool to
create and modify images to be used as Xen guests.
* [xenguest-manager](documentation/xenguest-manager.md): this is a tool to
create/remove/start/stop xen guest generated using xenguest-mkimage.
* [xenguest-network-bridge](documentation/xenguest-network-bridge.md): this
recipe add tools and init scripts to create a bridge connected to the
external network on the host and allow guests to be connected to it.
Contributing
------------
@@ -20,4 +88,5 @@ would like to contribute, please contact the maintainers
Maintainer(s)
-------------
* Diego Sueiro <diego.sueiro@arm.com>
* Bertrand Marquis <bertrand.marquis@arm.com>
* Filipe Rinaldi <filipe.rinaldi@arm.com>
@@ -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)}
@@ -0,0 +1,108 @@
# Create a xenguest image with kernel and filesystem produced by Yocto
# This will create a .xenguest file that the xenguest-manager can use.
inherit xenguest-image
# We are creating our guest in a local subdirectory
# force the value so that we are not impacted if the user is changing it
XENGUEST_IMAGE_DEPLOY_DIR = "${WORKDIR}/tmp-xenguest"
# Name of deployed file (keep standard image name and add .xenguest)
XENGUEST_IMAGE_DEPLOY ??= "${IMAGE_NAME}"
# Add kernel XENGUEST_IMAGE_KERNEL from DEPLOY_DIR_IMAGE to image
xenguest_image_add_kernel() {
srcfile="${1:-}"
if [ -z "${srcfile}" ]; then
srcfile="${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_KERNEL}"
fi
call_xenguest_mkimage partial --xen-kernel=$srcfile
}
# Add rootfs file to the image
xenguest_image_add_rootfs() {
call_xenguest_mkimage partial \
--disk-add-file=${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${IMAGE_TYPEDEP_xenguest}:rootfs.${IMAGE_TYPEDEP_xenguest}
}
# Pack xenguest image
xenguest_image_pack() {
mkdir -p ${IMGDEPLOYDIR}
rm -f ${IMGDEPLOYDIR}/${XENGUEST_IMAGE_DEPLOY}.xenguest
call_xenguest_mkimage pack \
${IMGDEPLOYDIR}/${XENGUEST_IMAGE_DEPLOY}.xenguest
}
#
# Task finishing the bootimg
# We need this task to actually create the symlinks
#
python do_bootimg_xenguest() {
subtasks = d.getVarFlag('do_bootimg_xenguest', 'subtasks')
bb.build.exec_func('xenguest_image_clone', d)
if subtasks:
for tk in subtasks.split():
bb.build.exec_func(tk, d)
bb.build.exec_func('xenguest_image_pack', d)
bb.build.exec_func('create_symlinks', d)
}
# This is used to add sub-tasks to do_bootimg_xenguest
do_bootimg_xenguest[subtasks] = ""
# Those are required by create_symlinks to find our image
do_bootimg_xenguest[subimages] = "xenguest"
do_bootimg_xenguest[imgsuffix] = "."
do_bootimg_xenguest[depends] += "xenguest-base-image:do_deploy"
# Need to have rootfs so all recipes have deployed their content
do_bootimg_xenguest[depends] += "${PN}:do_rootfs"
# This set in python anonymous after, just set a default value here
IMAGE_TYPEDEP_xenguest ?= "tar"
# We must not be built at rootfs build time because we need the kernel
IMAGE_TYPES_MASKED += "xenguest"
IMAGE_TYPES += "xenguest"
python __anonymous() {
# Do not do anything if we are not in the want FSTYPES
if bb.utils.contains_any('IMAGE_FSTYPES', 'xenguest', '1', '0', d):
# Check the coherency of the configuration
rootfs_needed = False
rootfs_file = ''
kernel_needed = False
rootfs_file = xenguest_image_rootfs_file(d)
if rootfs_file:
rootfs_needed = True
if d.getVar('XENGUEST_IMAGE_KERNEL') and not d.getVar('INITRAMFS_IMAGE'):
# If INITRAMFS_IMAGE is set, even if INITRAMFS_IMAGE_BUNDLE is not
# set to 1 to bundle the initramfs with the kernel, kernel.bbclass
# is setting a dependency on ${PN}:do_image_complete. We cannot
# in this case depend on do_deploy as it would create a circular
# dependency:
# do_image_complete would depend on kernel:do_deploy which would
# depend on ${PN}:do_image_complete
# In the case INITRAMFS_IMAGE_BUNDLE = 1, the kernel-xenguest class
# will handle the creation of a xenguest image with the kernel.
# In the other case the kernel can be added manually to the image.
kernel_needed = True
bb.build.addtask('do_bootimg_xenguest', 'do_image_complete', None, d)
if rootfs_needed:
# tell do_bootimg_xenguest to call add_rootfs
d.appendVarFlag('do_bootimg_xenguest', 'subtasks', ' xenguest_image_add_rootfs')
# do_bootimg_xenguest will need the tar file
d.appendVarFlag('do_bootimg_xenguest', 'depends', ' %s:do_image_tar' % (d.getVar('PN')))
# set our TYPEDEP to the proper compression
d.setVar('IMAGE_TYPEDEP_xenguest', 'tar' + (rootfs_file.split('.tar', 1)[1] or ''))
if kernel_needed:
# Tell do_bootimg_xenguest to call xenguest_image_add_kernel
d.appendVarFlag('do_bootimg_xenguest', 'subtasks', ' xenguest_image_add_kernel')
# we will need kernel do_deploy
d.appendVarFlag('do_bootimg_xenguest', 'depends', ' virtual/kernel:do_deploy')
}
@@ -0,0 +1,34 @@
# Create a xenguest image containing the kernel with initramfs when
# initramfs is activated
# This is done using kernel-fitimage as model
# To activate this, kernel-xenguest must be added to KERNEL_CLASSES
inherit xenguest-image
# use a local copy to pack all together
XENGUEST_IMAGE_DEPLOY_DIR = "${WORKDIR}/tmp-xenguest"
python __anonymous () {
# only if xenguest image type is present
if bb.utils.contains('IMAGE_FSTYPES', 'xenguest', '1', '0', d):
# only if initramfs bundle is activated
if d.getVar('INITRAMFS_IMAGE') and d.getVar('INITRAMFS_IMAGE_BUNDLE') == "1":
if not bb.utils.contains('KERNEL_IMAGETYPES', 'Image', '1', '0', d):
bb.fatal("xenguest image type with initramfs require Image kernel image type")
bb.build.addtask('do_assemble_xenguest_initramfs', 'do_deploy', 'do_bundle_initramfs', d)
}
do_assemble_xenguest_initramfs() {
xenguest_image_clone
call_xenguest_mkimage partial --xen-kernel=${B}/${KERNEL_OUTPUT_DIR}/Image.initramfs
rm -f ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest
call_xenguest_mkimage pack ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest
}
do_assemble_xenguest_initramfs[depends] += "${INITRAMFS_IMAGE}:do_image_complete"
kernel_do_deploy_append() {
if [ -f "${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest" ]; then
install -m 0644 ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest "$deployDir/Image-${INITRAMFS_NAME}.xenguest"
ln -snf Image-${INITRAMFS_NAME}.xenguest $deployDir/Image-${INITRAMFS_LINK_NAME}.xenguest
fi
}
@@ -0,0 +1,102 @@
# This class must be used to extend the xenguest image
# It provides variables to add init scripts, a dtb, xen files or disk files.
#
# The class is extending deploy function so you recipe must inherit deploy and
# have a do_deploy function (even if it is empty)
# Use standard xenguest-image
inherit xenguest-image
# Add a DTB file for the guest
# Only one file should be added, if this is set multiple times or in several
# recipes, the last recipe setting it will prevail.
XENGUEST_EXTRA_DTB ??= ""
# Append something to the guest xen configuration
# All files here will be merged together in the final xen configuration
# This can contain several files or be used in several recipes
XENGUEST_EXTRA_XENCONFIG ??= ""
# Add a xenguest init, init-pre or init-post script
XENGUEST_EXTRA_INIT_PRE ??= ""
XENGUEST_EXTRA_INIT ??= ""
XENGUEST_EXTRA_INIT_POST ??= ""
# Add xenguest files, (to be used in extra xen config for example)
# several files may be added, space separated, the path will be kept on the
# generated xenguest image (if dir1/file1 is added, it can be used as
# dir1/file1 file in the xen configuration).
XENGUEST_EXTRA_FILES ??= ""
# Add xenguest disk files (to be used as disk partition content)
# several files may be added, space separated, the path will be kept on the
# generated xenguest image (if dir1/file1 is added, it can be used as
# dir1/file1 file in the disk content parameters).
XENGUEST_EXTRA_DISK_FILES ??= ""
do_deploy_append() {
if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
-z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
fi
rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
if [ -n "${XENGUEST_EXTRA_DTB}" ]; then
if [ ! -f ${XENGUEST_EXTRA_DTB} ]; then
die "xenguest-image: DTB file ${XENGUEST_EXTRA_DTB} does not exist"
fi
call_xenguest_mkimage partial --xen-device-tree=${XENGUEST_EXTRA_DTB}
fi
if [ -n "${XENGUEST_EXTRA_XENCONFIG}" ]; then
for f in ${XENGUEST_EXTRA_XENCONFIG}; do
if [ ! -f $f ]; then
die "xenguest-image: Xen config $f does not exist"
fi
call_xenguest_mkimage partial --xen-append=$f
done
fi
if [ -n "${XENGUEST_EXTRA_INIT_PRE}" ]; then
if [ ! -f ${XENGUEST_EXTRA_INIT_PRE} ]; then
die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT_PRE} does not exist"
fi
call_xenguest_mkimage partial --init-pre=${XENGUEST_EXTRA_INIT_PRE}
fi
if [ -n "${XENGUEST_EXTRA_INIT}" ]; then
if [ ! -f ${XENGUEST_EXTRA_INIT} ]; then
die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT} does not exist"
fi
call_xenguest_mkimage partial --init-script=${XENGUEST_EXTRA_INIT}
fi
if [ -n "${XENGUEST_EXTRA_INIT_POST}" ]; then
if [ ! -f ${XENGUEST_EXTRA_INIT_POST} ]; then
die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT_POST} does not exist"
fi
call_xenguest_mkimage partial --init-post=${XENGUEST_EXTRA_INIT_POST}
fi
if [ -n "${XENGUEST_EXTRA_FILES}" ]; then
for f in ${XENGUEST_EXTRA_FILES}; do
if [ ! -f $f ]; then
die "xenguest-image: Xen file $f does not exist"
fi
call_xenguest_mkimage partial --xen-add-file=$f
done
fi
if [ -n "${XENGUEST_EXTRA_DISK_FILES}" ]; then
for f in ${XENGUEST_EXTRA_DISK_FILES}; do
if [ ! -f $f ]; then
die "xenguest-image: Disk file $f does not exist"
fi
call_xenguest_mkimage partial --disk-add-file=$f
done
fi
}
# Need to have xenguest-image tool
do_deploy[depends] += "xenguest-base-image:do_deploy"
@@ -0,0 +1,195 @@
# This class must be used to create, extend or pack a xenguest image.
# It is using xenguest-mkimage tool to do operations
DEPENDS += "xenguest-mkimage-native"
#
# Xenguest image parameters
# All the following parameters can be modified in local.conf or on recipes
# inheriting this class
#
# Guest memory size in MB
XENGUEST_IMAGE_MEMORY_SIZE ??= "512"
# Guest number of vcpus
XENGUEST_IMAGE_NUM_VCPUS ??= "1"
# Guest auto boot during init, set to 1 to have guest started during init or
# to 0 if the guest should not be auto started
XENGUEST_IMAGE_AUTOBOOT ??= "1"
# Partition containing the root file system
# Xen will actually add root=${XENGUEST_IMAGE_ROOT} to your guest kernel
# command line
# You can let this empty if the root filesystem is specified in an other way
# and have root= option added to the command line for example or if you don't
# need a root filesystem mounted for your guest (initrd for example)
XENGUEST_IMAGE_ROOT ??= "/dev/xvda1"
# Guest kernel command line arguments
XENGUEST_IMAGE_CMDLINE ??= "earlyprintk=xenboot console=hvc0 rw"
# Extra commands to add to xenguest-image when creating the image
XENGUEST_IMAGE_EXTRA_CMD ??= ""
# Kernel binary
# This value is used by the xenguest image type but is declared here to have
# all variables in the same place
# If this value is empty no kernel will be added to the image
XENGUEST_IMAGE_KERNEL ??= "Image"
# Size of the disk to create (if 0 no disk will be created and rootfs will not
# be included in the xenguest image)
XENGUEST_IMAGE_DISK_SIZE ??= "${@ '4' if not d.getVar('INITRAMFS_IMAGE') else '0'}"
#
# XENGUEST_IMAGE_DISK PARTITIONS is used to describe the partitions to setup
# and their content.
# It must be set to a space separated list of entries with each entry having
# the format num:sz:fs:[file] where:
# - num is a partition number
# - sz is the partition size in Gigabit
# - fs is the filesystem to use for the partition
# - file is optionally pointing to a file to use as content of the partition
# Please check image_types_xenguest.bbclass for rootfs handling of files
#
# Default value creates a partition 1 using the full disk, formated with ext4
# and containing the root filesystem produced by Yocto
XENGUEST_IMAGE_DISK_PARTITIONS ??= "1:${XENGUEST_IMAGE_DISK_SIZE}:ext4:rootfs.tar.gz"
# XENGUEST_IMAGE_NETWORK_BRIDGE can be set to 1 to have a network interface
# on the guest connected to host bridged network. This will provide the guest
# with a network interface connected directly to the external network
XENGUEST_IMAGE_NETWORK_BRIDGE ??= "1"
# Sub-directory in wich the guest is created. This is create in deploy as a
# subdirectory and must be coherent between all components using this class so
# it must only be modified from local.conf if needed
XENGUEST_IMAGE_DEPLOY_SUBDIR ?= "xenguest"
# Directory in which the xenguest should be deployed
# a sub-directory named ${XENGUEST_IMAGE_DEPLOY_SUBDIR} will be created there.
# This should be set to:
# - ${DEPLOYDIR} (default) if creating or extending the xenguest for a normal
# recipe.
# - something in ${WORKDIR} if you need to clone and manipulate an image
XENGUEST_IMAGE_DEPLOY_DIR ??= "${DEPLOYDIR}"
#
# Wrapper to call xenguest-mkimage
# It is using XENGUEST_IMAGE_DEPLOY_DIR and XENGUEST_IMAGE_DEPLOY_SUBDIR
# to find the image to operate on
#
# Usage: call_xenguest_mkimage [operation] [args]
call_xenguest_mkimage() {
local cmd="${1}"
local img="${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}"
shift
echo "xenguest-mkimage $cmd $img $@"
xenguest-mkimage $cmd $img $@
}
#
# Create an initial xenguest image.
# This is a task which must be added in a recipe inheriting deploy
# It is using XENGUEST_IMAGE_MEMORY_SIZE, XENGUEST_IMAGE_NUM_VCPUS,
# XENGUEST_IMAGE_AUTOBOOT, XENGUEST_IMAGE_ROOT, XENGUEST_IMAGE_EXTRA_CMD,
# XENGUEST_IMAGE_CMDLINE, XENGUEST_IMAGE_DISK_SIZE and
# XENGUEST_IMAGE_DISK_PARTITIONS to customize the initial guest
#
xenguest_image_create() {
if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
-z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
fi
rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
# Create the image
call_xenguest_mkimage create --xen-memory=${XENGUEST_IMAGE_MEMORY_SIZE} \
--xen-vcpus=${XENGUEST_IMAGE_NUM_VCPUS} \
--xen-root=${XENGUEST_IMAGE_ROOT} \
${XENGUEST_IMAGE_EXTRA_CMD}
# add command line
if [ -n "${XENGUEST_IMAGE_CMDLINE}" ]; then
call_xenguest_mkimage update --xen-clean-extra
for arg in ${XENGUEST_IMAGE_CMDLINE}; do
call_xenguest_mkimage update --xen-extra=$arg
done
fi
# create disk if needed
disksize="${XENGUEST_IMAGE_DISK_SIZE}"
if [ -z "$disksize" ]; then
disksize="0"
fi
if [ $disksize -gt 0 ]; then
# setup disk size
call_xenguest_mkimage update --disk-reset-config --disk-size=$disksize
diskparts="${XENGUEST_IMAGE_DISK_PARTITIONS}"
if [ -n "$diskparts" ]; then
for arg in $diskparts; do
call_xenguest_mkimage update --disk-add-part=$arg
partnum="$(expr $partnum + 1)"
done
fi
fi
if [ "${XENGUEST_IMAGE_AUTOBOOT}" = "1" ]; then
call_xenguest_mkimage update --set-param=GUEST_AUTOBOOT=1
else
call_xenguest_mkimage update --set-param=GUEST_AUTOBOOT=0
fi
if [ "${XENGUEST_IMAGE_NETWORK_BRIDGE}" = "1" ]; then
call_xenguest_mkimage update --set-param=NETWORK_BRIDGE=1
else
call_xenguest_mkimage update --set-param=NETWORK_BRIDGE=0
fi
}
#
# Clone the current xenguest from deploy to manipulate it locally
# This is required if you need to change things before packing an image
# To set the local directory where to clone you must set
# XENGUEST_IMAGE_DEPLOY_DIR if you don't want to use do_deploy to modify the
# image
#
xenguest_image_clone() {
if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
-z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
fi
if [ ! -f ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}/guest.cfg ]; then
die "xenguest-image: ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR} does not contain a valid guest"
fi
rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}
cp -rf ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR} \
${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
}
# Helper function to retrieve rootfs file if present in one partition
# This can return an empty string or rootfs.tar[.COMP]
def xenguest_image_rootfs_file(d):
disksize = d.getVar('XENGUEST_IMAGE_DISK_SIZE')
# if disksize is 0, we don't create anything
if not disksize or disksize == '0':
return ""
# Find first partition with file=rootfs.tar*
partlist = d.getVar('XENGUEST_IMAGE_DISK_PARTITIONS')
if partlist:
for partdesc in partlist.split():
partelems = partdesc.split(':', 3)
if partelems[3]:
if partelems[3].startswith('rootfs.tar'):
return partelems[3]
return ""
@@ -0,0 +1,11 @@
# This files is added when DISTRO_FEATURES contains arm-autonomy-guest
# We need to have ipv4 activated
DISTRO_FEATURES_append = " ipv4"
# Build a xenguest type image
IMAGE_CLASSES += "image_types_xenguest"
IMAGE_FSTYPES += "xenguest"
# xenguest kernel extension to handle initramfs
KERNEL_CLASSES += "kernel-xenguest"
@@ -0,0 +1,9 @@
# This files is added when DISTRO_FEATURES contains arm-autonomy-host
# We need to have xen and ipv4 activated
DISTRO_FEATURES_append = " xen ipv4"
# 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 ?= ""
+34
View File
@@ -0,0 +1,34 @@
# Add layer to BBPATH
BBPATH .= ":${LAYERDIR}"
# Add recipes-* directories to BBFILES
BBFILES += " \
${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend \
"
BBFILE_COLLECTIONS += "meta-arm-autonomy"
BBFILE_PATTERN_meta-arm-autonomy = "^${LAYERDIR}/"
BBFILE_PRIORITY_meta-arm-autonomy = "6"
LAYERDEPENDS_meta-arm-autonomy = " \
core \
yocto \
openembedded-layer \
virtualization-layer \
"
LAYERSERIES_COMPAT_meta-arm-autonomy = "dunfell"
# We don't activate virtualization feature from meta-virtualization as it
# brings in lots of stuff we don't need. We need to disable the sanity check
# otherwise the user will see a warning on each build.
SKIP_META_VIRT_SANITY_CHECK = "1"
# Directory of our distro config files
ARM_AUTONOMY_DISTRO_CFGDIR = "${LAYERDIR}/conf/distro/include/"
# Add class to handle arm-autonomy distro extensions
USER_CLASSES_append = " arm-autonomy-features"
BBFILES_DYNAMIC += " \
meta-arm-bsp:${LAYERDIR}/dynamic-layers/meta-arm-bsp/*/*/*.bbappend \
"
@@ -0,0 +1,17 @@
#@TYPE: Machine
#@NAME: Autonomy Guest ARM64 machine
#@DESCRIPTION: Machine configuration for ARM64 Autonomy Guest
TUNE_FEATURES = "aarch64"
require conf/machine/include/arm/arch-armv8a.inc
KERNEL_IMAGETYPE = "Image"
IMAGE_FSTYPES += "tar.bz2"
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "5.4%"
DISTRO_FEATURES += "arm-autonomy-guest"
@@ -0,0 +1,225 @@
arm-autonomy Quick Start
==================
This documentation is explaining how to quickly start with arm-autonomy layer
and the main features provided.
You will find in the documentation directory some more detailed documentation
for each of the functionalites provided by this layer.
What to use this layer for?
---------------------------
Using this layer, you can easily and rapidly create a system based on Xen with
one or more guests created using Yocto.
For this you will need to create at least 2 Yocto projects:
- a host project: This one will compile Xen and create a Linux system to be
used as Xen Dom0. The Linux system will contain all functionalities required
to start and manage guests.
- one or several guest projects: Those will create Linux systems with the
required Linux kernel configuration to run as Xen DomU.
Prepare your system
-------------------
First you must download the Yocto layers needed:
- [meta-openembedded](https://git.openembedded.org/meta-openembedded)
- [poky](https://git.yoctoproject.org/poky)
- [meta-virtualization](https://git.yoctoproject.org/meta-virtualization)
- [meta-arm](https://git.yoctoproject.org/meta-arm)
- all other layers you might want to use
For each of the downloaded layer make sure you checkout the release of Yocto
you want to use (for example zeus using `git checkout zeus`).
Please follow [Yocto documentation](https://www.yoctoproject.org/docs/latest/brief-yoctoprojectqs/brief-yoctoprojectqs.html)
in order to have the required dependencies.
Create a project
----------------
Here are the main steps to create an arm-autonomy project:
1. create a new Yocto project using `oe-init-build-env` in a new directory:
```
oe-init-build-env my-project
```
2. Add `meta-arm/meta-arm-autonomy` layer to the list of layers of your
project in the `conf/bblayers.conf`. Also add any other layers you
might need (for example `meta-arm/meta-arm-bsp` and `meta-arm/meta-arm` to
use Arm boards like Juno or FVP emulator). You can achieve this by using
the `bitbake-layers add-layer layerdir [layerdir ...]` command.
For example:
```
export LAYERDIR_BASE="/home/user/arm-autonomy/"
bitbake-layers add-layer $LAYERDIR_BASE/meta-poky $LAYERDIR_BASE/meta-yocto-bsp \
$LAYERDIR_BASE/meta-openembedded/meta-oe $LAYERDIR_BASE/meta-openembedded/meta-python \
$LAYERDIR_BASE/meta-openembedded/meta-filesystems $LAYERDIR_BASE/meta-openembedded/meta-networking \
$LAYERDIR_BASE/meta-virtualization $LAYERDIR_BASE/meta-arm/meta-arm-autonomy \
$LAYERDIR_BASE/meta-arm/meta-arm $LAYERDIR_BASE/meta-arm/meta-arm-bsp
```
Example of a `conf/bblayers.conf`:
```
BBLAYERS ?= " \
/home/user/arm-autonomy/poky/meta \
/home/user/arm-autonomy/poky/meta-poky \
/home/user/arm-autonomy/poky/meta-yocto-bsp \
/home/user/arm-autonomy/meta-openembedded/meta-oe \
/home/user/arm-autonomy/meta-openembedded/meta-python \
/home/user/arm-autonomy/meta-openembedded/meta-filesystems \
/home/user/arm-autonomy/meta-openembedded/meta-networking \
/home/user/arm-autonomy/meta-virtualization \
/home/user/arm-autonomy/meta-arm/meta-arm-autonomy \
/home/user/arm-autonomy/meta-arm/meta-arm \
/home/user/arm-autonomy/meta-arm/meta-arm-bsp \
"
```
Those steps will have to be done for each project you will have to create.
Host project
------------
The host project will build Xen and the Dom0 Linux. It will be the only project
that will be specific to the board (MACHINE) you will be running on.
To create a host project:
1. Follow the steps of "Create a project"
2. Add the layers in `bblayers.conf` required to build a Yocto project for the
board you want to use.
For example to use Arm FVP Base emulator, add `meta-arm/meta-arm` and
`meta-arm/meta-arm-bsp`.
3. edit conf/local.conf to add `arm-autonomy-host` to the DISTRO_FEATURES and
set MACHINE to the board you want to use.
For example, add the following lines:
```
MACHINE = "fvp-base"
DISTRO_FEATURES += "arm-autonomy-host"
```
4. build the image using `bitbake arm-autonomy-host-image-minimal`
The project will generate a Linux kernel, a root filesystem, a Xen binary and
a DTB modified to include the required entries to boot Xen and Linux as Dom0
(this DTB has the extension `-xen.dtb`).
To boot the system using an u-boot base board you will need to:
- Load the kernel (by default at 0x80080000 unless you modify
XEN_DEVICETREE_DOM0_ADDR value)
- Load the xen device tree (for example at 0x83000000)
- Load the xen-efi binary (for example at 0x84000000)
- run using `booti 0x84000000 - 0x83000000`
In this example the addresses might need to be adapted depending on your board.
Guest project
-------------
The guest projects are not target specific and will use a Yocto MACHINE defined
in meta-arm-autonomy to include only the Linux configuration required to run
a xen guest.
To create a guest project:
1. Follow the steps of "Create a project"
2. Optionaly add layers required to build the image and features you need.
3. edit conf/local.conf to add `arm-autonomy-guest` to the DISTRO_FEATURES and
set MACHINE to `arm64-autonomy-guest`:
```
MACHINE = "arm64-autonomy-guest"
DISTRO_FEATURES += "arm-autonomy-guest"
```
4. build the image you want.
For example `bitbake core-image-minimal`
The build will create a ".xenguest" image that can be use on an host project
with the xenguest-manager.
Include guests directly in the host image
-----------------------------------------
The layer provides a way to directly include in the host project one or several
images generated by guest projects.
To use this feature, you must edit your host project `local.conf` file and
add set ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS to the list of xenguest images
you want to include in your host. Each xenguest image must be given using a
full path to it.
For example:
```
ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS = "/home/user/guest-project/tmp/deploy/images/arm64-autonomy-guest/core-image-minimal-arm64-autonomy-guest.xenguest;guestname=myguest"
```
This will add the guest and name it `myguest` on the host project image and
the xenguest-manager will automatically boot it during startup.
Add support for your board
--------------------------
Most of arm-autonomy layer is board independent but some functionalities
might need to be customized for your board:
### Add the kernel configuration for the host
The layer is using KERNEL_FEATURES to add drivers required to be a Xen Dom0
system.
Depending on the kernel used by your BSP and how it is configured you might
need to add the required drivers to your kernel configuration:
- if KERNEL_FEATURES system is supported by your kernel, make sure that the
file `recipes-kernel/linux/linux-arm-autonomy.inc` from the layer is included
by your kernel recipe.
- if it is not supported, you must add the proper drivers inside your kernel
(modules are possible but they must be loaded before xenguest-manager is
started). You can find the complete list of the kernel configuration elements
required in `recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-host.cfg`.
### Define the drive and partition to use for the LVM volume
The xenguest-manager is creating disk hard drive using LVM on an empty
partition. The default value is set to use /dev/sda2.
You can change this for your board by setting XENGUEST_MANAGER_VOLUME_DEVICE.
Check `recipes-extended/xenguest/xenguest-manager.bbappend` for examples.
Please also read xenguest-manager.md.
### Define the interface to add to xenguest network bridge
xenguest-network bridge is creating a bridge on the host and adds network
interfaces to it so that guest connected to it have access to external network.
By default `eth0` is set as the list of interfaces to be added to the bridge.
Depending on your board or use case you might want to use an other interface
or use multiple interfaces.
You can change this for your board by setting XENGUEST_NETWORK_BRIDGE_MEMBERS.
Check `recipes-extended/xenguest/xenguest-network-bridge.bbappend` for
exmaples.
Please also read xenguest-network-bridge.md.
### Define the network configuration of the xenguest network bridge
xenguest network bridge is putting the host network interfaces in a bridge
and is configuring it by default to use dhcp.
If you need a different type of configuration you can set
XENGUEST_NETWORK_BRIDGE_CONFIG in a xenguest-network-bridge.bbappend to use
a different file.
The recipe will look for the file in ${WORKDIR} so you will need to add it to
SRC_URI in your bbappend.
The recipe will also substitute `###BRIDGE_NAME###` with the bridge name
configured in ${XENGUEST_NETWORK_BRIDGE_NAME}.
You can find an example configuration file in
`recipes-extended/xenguest/files/xenguest-network-bridge-dhcp.cfg.in`.
Please also read xenguest-network-bridge.md.
### Customize Dom0 and Xen boot arguments for you board
xen-devicetree is writting inside the generated DTB Xen and Linux boot
arguments as long as the address where Dom0 Linux kernel can be found.
You might need to have different values for your board or depending on your
use case.
You can find examples to customize this in
`recipes-extended/xen-devicetree/xen-devicetree.bbappend`.
Please also read xen-devicetree.md.
@@ -0,0 +1,104 @@
Xen device tree
===============
Introduction
------------
xen-devicetree recipe can be used to modify an existing Device Tree Blob,
produced by Linux kernel or another recipe, to include in it entries required
to start Xen and a Dom0 Linux on top of it.
The recipe will do the following processing:
- generate a xen.dtsi file with entries required for xen based on parameters
- turn DTBs in ${XEN_DEVICETREE_DTBS} back to dts
- include in xen.dtsi and all other dtsi from
${XEN_DEVICETREE_DTSI_MERGE} (check Bitbake parameters for more information
on this).
- use dtc to create a new DTB file
The recipe will generate new files in deploy/images and name them with the
extension "-xen.dtb".
For example **machine.dtb** will generate **machine-xen.dtb**.
Entries added to the DTBs
-------------------------
When a DTB is processed by the recipe, the following block is added:
```
chosen {
xen,dom0-bootargs = "VAL";
xen,xen-bootargs = "VAL";
modules {
#size-cells = <0x00000001>;
#address-cells = <0x00000001>;
module@0 {
reg = <VAL VAL>;
compatible = "multiboot,module";
};
};
};
```
Each occurence of **VAL** is replaced by the content of the variables listed in
this documentation.
Bitbake parameters
------------------
Several parameters are available to configure the xen-devicetree during Yocto
project compilation (those can be set in your project local.conf, for exmple).
The following parameters are available:
- XEN_DEVICETREE_DEPEND: This variable can be used to indicate which recipe
task is generating the DTBs that xen-devicetree will modify. This makes sure
the xen devicetrees are properly regenerated if the source DTBs are changed.
This variable is set by default to "virtual/kernel:do_deploy" to use DTBs
generated during the compilation of the Linux kernel. This must be changed
if the machine your are using is not using a DTB listed in KERNEL_DEVICETREE.
- XEN_DEVICETREE_DTBS: This should be set to the list of DTBs you want to be
modified by xen-devicetree. Those must be files that xen-devicetree can find
in the ${DEPLOY_DIR_IMAGE} directory using only the basename of the entries.
For example "mydir/board.dtb" will make the recipe look for
${DEPLOY_DIR_IMAGE}/board.dtb.
This variable is set by default to "${KERNEL_DEVICETREE}" to process the DTBs
generated by the Linux kernel.
- XEN_DEVICETREE_DOM0_MEM: Memory size to allocate to Dom0.
This variable is only used if XEN_DEVICETREE_XEN_BOOTARGS has a value
containing "dom0_mem=${XEN_DEVICETREE_DOM0_MEM}" as the memory assigned to
dom0 is defined using Xen boot arguments.
This variable is set by default to "1024M".
- XEN_DEVICETREE_DOM0_BOOTARGS: Boot arguments to pass to Dom0 Linux when
booting it.
This variable is set by default to "console=hvc0 earlycon=xen".
- XEN_DEVICETREE_XEN_BOOTARGS: this variable should be set with the boot
arguments to be passed to Xen on boot.
This variable is set by default to
"noreboot dom0_mem=${XEN_DEVICETREE_DOM0_MEM}".
- XEN_DEVICETREE_DOM0_ADDR: This is the address from which the Linux kernel to
be used for Dom0 will be copied. When using u-boot, this is the address at
which you will load the kernel Image before starting Xen.
This variable is set by default to "0x80080000".
- XEN_DEVICETREE_DOM0_SIZE: This is the size of the kernel loaded at
${XEN_DEVICETREE_DOM0_ADDR}. Xen will copy this amount of data inside the
guest before starting it so the size must be at least equal to the kernel
size but can be bigger. You must be careful not to have a value too big as it
could slow down boot or copy other parts with it (like the DTB).
You might need to increase this if you use a kernel with a bundled initramfs.
This variable is set by default to "0x01000000".
- XEN_DEVICETREE_DTSI_MERGE: This variable contains the list of dtsi files that
must be included inside the generated DTB file. By default the only one
include is the "xen.dtsi" generated by the recipe.
If your board or project needs to include more fixes or entries in the DTB,
this variable can be appended from a bbappend file to include other dtsi. The
files must be inside the recipe workspace during Yocto compilation.
You can check xen-devicetree.bbappend for an example.
@@ -0,0 +1,67 @@
Xenguest Manager
================
Introduction
------------
xenguest-manager is a tool to manage Xenguest images generated by
[xenguest-mkimage](xenguest-mkimage.md).
On a Xen Dom0 system it will:
- create a xen guest from a xenguest image: extract its components, create a
disk for the guest using LVM volumes.
- start/stop a xen guest (during init or using xenguest-manager directly).
- check guest status
xenguest-manager is composed of 2 shell scripts:
- xenguest-manager which can be used from command line to start/stop/check
guests and create or remove guest using xenguest images.
- xenguest-init which is called during init to automatically create and start
some guests as part of the host init process.
Usage
-----
xenguest-manager must be called like this:
`xenguest-manager OPERATION [OPTIONS]`
The following operations are available:
- create XENGUEST_IMAGE [GUESTNAME]: create a guest from a xenguest image file
as guest GUESTNAME. If GUESTNAME is not given the image file name is used
without the xenguest extension.
- remove GUESTNAME: remove the guest GUESTNAME.
- start GUESTNAME: start the guest GUESTNAME.
- stop GUESTNAME: stop the guest GUESTNAME (this is using `xl stop` which is
sending a stop signal to the running guest).
- kill GUESTNAME: force stopping the guest GUESTNAME.
- list: list the available guests.
- status [GUESTNAME]: print the current status of GUESTNAME. If GUESTNAME is
not given, print the status of all guests.
For a detailed help on available options please use:
`xenguest-manager --help`
Bitbake parameters
------------------
Several parameters are available to configure the xenguest manager during Yocto
project compilation (those can be set in your project local.conf, for example).
The following parameters are available:
- XENGUEST_MANAGER_VOLUME_DEVICE: This is the device path used by the
xenguest-manager on the device to create LVM disks when guests have a disk
configuration.
This is set by default to "/dev/sda2".
- XENGUEST_MANAGER_VOLUME_NAME: This is the LVM volume name that the
xenguest-manager will create and use to create guest LVM disks.
This is set by default to "vg-xen".
- XENGUEST_MANAGER_GUEST_DIR: This is the directory on Dom0 where the
xenguest-manager will look for xenguest images to create during init. That's
the place where xenguest images can be added to have them automatically
created during next Dom0 boot. The xenguests found there will only be created
if they were not already before (the basename of the files is used as guest
name).
This is set by default to "/usr/share/guests".
@@ -0,0 +1,119 @@
Xenguest mkimage
================
Introduction
------------
xenguest-mkimage is a tool to create and modify images to be used as Guest with
Xen. It defines a format to store completely defined guests as a file or as
a directory and provides options to create and modify those images.
A xenguest image contains all elements required to create a xen guest.
This is the base elements like a Xen configuration and a Linux kernel binary
but also some more advanced elements like init scripts or a disk definition.
The format is made to be deployable easily by storing everything in a single
file and provide tools to easily manipulate the images. It can also easily be
extended to have features like encryption or signature of images, updates or
complex configurations by providing features to have init script that will be
executed on the host embedded inside the image.
Xenguest images content
-----------------------
### params.cfg
This file contains parameters that can be used by tools to configure some
functionalities on the host. This can be used by init scripts to have
configurable parameters as it is sourced before calling init scripts.
### guest.cfg and guest.d
guest.cfg is the main xen configuration and guest.d contains optional
configuration parts. All those will be merged into one final xen configuration
before starting the guest.
### files
This directory contains files that can be used by the xen configuration, for
example the binary of the kernel referenced in xen configuration).
This is where the kernel binary, the dtb or a ramdisk will be stored.
### init.pre, init.d and init.post
These directories contain init scripts that will be executed on the host
during the guest startup. Those must be shell scripts and each directory
contains scripts called at a different time:
- init.pre: scripts executed before the guest is created. This can be used
to prepare some features required to create the guest in xen or to
generate part of the xen configuration dynamically.
- init.d: scripts executed when the guest has been created but before it is
started. This can be used to do some xenstore operations or configure the
guest behaviour using xl, for example.
- init.post: scripts executed just after starting the guest. This can be
used to configure things created by xen for the guest like network
network interfaces.
When a directory contains several scripts, those will be called in alphabetical
order.
### disk.cfg and disk-files
disk.cfg contains the guest disk description (disk size and disk partitions).
The file contains the following entries:
- `DISK_SIZE=X`: size of the disk to create in GB
- `DISK_PARTX=SIZE:FS:CONTENT`: create a partition number X (1 to 4) with a
size of SIZE GB, format it with filesystem FS (can be ext2, ext3, ext4, vfat
or swap) and extract CONTENT as initial partition content
(.tar[.gz|.xz|.bz2] file or img[.gz|.bz2] file to be dumped in the partition). FS and
CONTENT can be empty.
The disk-files contain files to be used for initializing the disk partitions
content. Those should be used to create a LVM or a physical disk and initialize
it (create partitions, format them and put the initial content).
Usage
-----
xenguest-mkimage is a shell script which must be called like this:
`xenguest-mkimage OPERATION XENGUEST [OPTIONS]`
### Operations
- create: create a xenguest image. If XENGUEST is an existing empty directory,
the image is created as a directory otherwise it will be created as a file.
- check: verify that XENGUEST is a valid xenguest image.
- update: modify a xenguest image (see --help for a list of operations).
- pack: pack a xenguest image directory into a xenguest image file. The file to
be created must be given as 3rd argument.
- extract: extract a xenguest image file into a directory. The destination
directory must be given as 3rd argument.
- dump-xenconfig: dump xenguest image xen configuration.
- dump-diskconfig: dump xenguest image disk configuration.
- dump-paramsconfig: dump xenguest image parameters configuration.
For a detailed help on available operations, please use:
`xenguest-mkimage --help`
### Options
- --kernel=FILE: add kernel FILE as guest kernel. This is both adding the file
to the image and modifying the xen configuration to use it.
- --xen-memory=SIZE: set the guest memory size in MB.
- --xen-extra: add a kernel command line argument. This can be called several
times to add several command line options.
- --xen-device-tree=FILE: add dtb FILE as device tree. This both adding the
file to the image and modifying the xen configuration to use it.
- --init-script=FILE: add guest init script. The script is embedded inside the
image file. Several script can be added and the basename of FILE is used to
distinguish them (calling the option twice with the same file will update the
script in the image with the second one).
--disk-size=SIZE: set the guest disk size to SIZE in GB. Calling this with 0
disable the guest disk.
- --disk-add-part=NUM:SIZE:FS:CONTENT: This is adding a partition to the
xenguest image disk. The partition is described with the arguments:
- NUM: partition number.
- SIZE: partition size in GB.
- FS: filesystem to format the partition with. This can be ext2, ext3, ext4,
vfat of swap. If empty the partition is not formated.
- CONTENT: tar of img file to use to initialize the partition. The file must
be added to the image using --disk-add-file=FILE:CONTENT.
For a detailed help on available options, please use:
`xenguest-mkimage OPERATION --help`
@@ -0,0 +1,49 @@
xenguest network bridge
=======================
Introduction
------------
xenguest-network-bridge is creating a network bridge to allow some guests to
have a direct connection to the external network.
To do this, a bridge is created on the host using brctl with the network
interfaces added to it so that the bridge is connected to the external network.
It is also adding a guest init script which will, for guests configured to use
it, create a virtual network interface for the guest and connect it to the
network bridge on the host.
Usage
-----
On the host the package xenguest-network-bridge must be included in your image.
On the xenguest image of your guest, the parameter NETWORK_BRIDGE must be set
to 1 (using xenguest-mkimage --set-param=NETWORK_BRIDGE=1).
Bitbake parameters
------------------
Several parameters are available to configure the xenguest network bridge
during Yocto project compilation (those can be set in your project local.conf,
for example).
The following parameters are available:
- XENGUEST_NETWORK_BRIDGE_NAME: This variable defines the name of the network
bridge that is created on the host during init.
This is set by default to "xenbr0".
- XENGUEST_NETWORK_BRIDGE_MEMBERS: This variable defines the list of network
interfaces that are added to the bridge when it is created on the host during
init.
This is set by default to "eth0".
- XENGUEST_NETWORK_BRIDGE_CONFIG: This variable defines the configuration file
to use to configure the bridge network. By default it points to have file
configuring the network using dhcp.
You can provide a different file using a bbappend and make this variable
point to it if you want to customize your network configuration.
- XENGUEST_IMAGE_NETWORK_BRIDGE: This variable can be set to 0 or 1 on guest
projects to enable or not the connection of the guest to the host bridge.
This is set by default to "1".
@@ -1,6 +1,6 @@
# Use OVERRIDES to minimize the usage of
# ${@bb.utils.contains('DISTRO_FEATURES', 'xen', ...
OVERRIDES:append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ':xen', '', d)}"
OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ':xen', '', d)}"
# Xen image to put in the image
# This should point to a file in the deploy image directory
@@ -9,21 +9,21 @@ BOOT_WRAPPER_AARCH64_XEN ??= "xen-${MACHINE}"
# Xen command line for the image
BOOT_WRAPPER_AARCH64_XEN_CMDLINE ??= "noreboot dom0_mem=256M"
BOOT_WRAPPER_AARCH64_XEN_CMDLINE:gem5-arm64 = "noreboot dom0_mem=256M console=dtuart \
BOOT_WRAPPER_AARCH64_XEN_CMDLINE_gem5-arm64 = "noreboot dom0_mem=256M console=dtuart \
dtuart=/uart@1c090000 bootscrub=0"
# Fix command line in the axf file for gem5-arm64 when Xen is present
BOOT_WRAPPER_AARCH64_CMDLINE_xen:gem5-arm64 = "console=hvc0 root=/dev/vda rw"
BOOT_WRAPPER_AARCH64_CMDLINE_xen_gem5-arm64 = "console=hvc0 root=/dev/vda rw"
# Image generated by boot wrapper when Xen is present
BOOT_WRAPPER_AARCH64_IMAGE:xen ?= "xen-system.axf"
BOOT_WRAPPER_AARCH64_IMAGE_xen ?= "xen-system.axf"
EXTRA_OECONF:append:xen = " \
EXTRA_OECONF_append_xen = " \
--with-xen=${WORKDIR}/kernel/arch/arm64/boot/Image \
--with-xen-cmdline="" \
"
EXTRA_OEMAKE:append:xen = " \
EXTRA_OEMAKE_append_xen = " \
XEN_IMAGE=${DEPLOY_DIR_IMAGE}/${BOOT_WRAPPER_AARCH64_XEN} \
XEN_CMDLINE="${BOOT_WRAPPER_AARCH64_XEN_CMDLINE}" \
"
@@ -0,0 +1,21 @@
# Use OVERRIDES to minimize the usage of
# ${@bb.utils.contains('DISTRO_FEATURES', 'xen', ...
OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ':xen', '', d)}"
FILESEXTRAPATHS_prepend_xen := "${THISDIR}/${PN}:"
DEPLOY_EXTRA_DEPS ??= ""
DEPLOY_EXTRA_DEPS_xen = "xen:do_deploy xen-devicetree:do_deploy"
do_deploy[depends] += "${DEPLOY_EXTRA_DEPS}"
do_deploy_prepend_xen() {
# To avoid dependency loop between firmware-image-juno:do_install,
# xen:do_deploy and xen-devicetree:do_deploy when
# INITRAMFS_IMAGE_BUNDLE = "1", we need to handle the xen and
# xen-devicetree binaries copying in the do_deploy task.
cp ${DEPLOY_DIR_IMAGE}/xen-${COMPATIBLE_MACHINE}.efi \
${D}/${UNPACK_DIR}/SOFTWARE/xen
cp ${DEPLOY_DIR_IMAGE}/*xen.dtb \
${D}/${UNPACK_DIR}/SOFTWARE/
}
@@ -0,0 +1,78 @@
TITLE: Versatile Express Images Configuration File
[IMAGES]
TOTALIMAGES: 11 ;Number of Images (Max: 32)
NOR0UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR0ADDRESS: 0x00000000 ;Image Flash Address
NOR0FILE: \SOFTWARE\fip.bin ;Image File Name
NOR0LOAD: 00000000 ;Image Load Address
NOR0ENTRY: 00000000 ;Image Entry Point
NOR1UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR1ADDRESS: 0x03EC0000 ;Image Flash Address
NOR1FILE: \SOFTWARE\bl1.bin ;Image File Name
NOR1LOAD: 00000000 ;Image Load Address
NOR1ENTRY: 00000000 ;Image Entry Point
NOR2UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR2ADDRESS: 0x00500000 ;Image Flash Address
NOR2FILE: \SOFTWARE\Image ;Image File Name
NOR2NAME: norkern ;Rename kernel to norkern
NOR2LOAD: 00000000 ;Image Load Address
NOR2ENTRY: 00000000 ;Image Entry Point
NOR3UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR3ADDRESS: 0x02700000 ;Image Flash Address
NOR3FILE: \SOFTWARE\juno-xen.dtb ;Image File Name
NOR3NAME: board.dtb ;Specify target filename to preserve file extension
NOR3LOAD: 00000000 ;Image Load Address
NOR3ENTRY: 00000000 ;Image Entry Point
NOR4UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR4ADDRESS: 0x01D00000 ;Image Flash Address
NOR4FILE: \SOFTWARE\xen ;Image File Name
NOR4NAME: xen
NOR4LOAD: 00000000 ;Image Load Address
NOR4ENTRY: 00000000 ;Image Entry Point
NOR5UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR5ADDRESS: 0x025C0000 ;Image Flash Address
NOR5FILE: \SOFTWARE\hdlcdclk.dat ;Image File Name
NOR5LOAD: 00000000 ;Image Load Address
NOR5ENTRY: 00000000 ;Image Entry Point
NOR6UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR6ADDRESS: 0x03E40000 ;Image Flash Address
NOR6FILE: \SOFTWARE\scp_bl1.bin ;Image File Name
NOR6LOAD: 00000000 ;Image Load Address
NOR6ENTRY: 00000000 ;Image Entry Point
NOR7UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR7ADDRESS: 0x0BF00000 ;Image Flash Address
NOR7FILE: \SOFTWARE\startup.nsh ;Image File Name
NOR7NAME: startup.nsh
NOR7LOAD: 00000000 ;Image Load Address
NOR7ENTRY: 00000000 ;Image Entry Point
NOR8UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR8ADDRESS: 0x0BFC0000 ;Image Flash Address
NOR8FILE: \SOFTWARE\blank.img ;Image File Name
NOR8NAME: BOOTENV
NOR8LOAD: 00000000 ;Image Load Address
NOR8ENTRY: 00000000 ;Image Entry Point
NOR9UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR9ADDRESS: 0x02600000 ;Image Flash Address
NOR9FILE: \SOFTWARE\selftest ;Image File Name
NOR9LOAD: 00000000 ;Image Load Address
NOR9ENTRY: 00000000 ;Image Entry Point
NOR10UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR10ADDRESS: 0x02780000 ;Image Flash Address
NOR10NAME: uEnv.txt
NOR10FILE: \SOFTWARE\uEnv.txt ;Image File Name
NOR10LOAD: 00000000 ;Image Load Address
NOR10ENTRY: 00000000 ;Image Entry Point
@@ -0,0 +1,78 @@
TITLE: Versatile Express Images Configuration File
[IMAGES]
TOTALIMAGES: 11 ;Number of Images (Max: 32)
NOR0UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR0ADDRESS: 0x00000000 ;Image Flash Address
NOR0FILE: \SOFTWARE\fip.bin ;Image File Name
NOR0LOAD: 00000000 ;Image Load Address
NOR0ENTRY: 00000000 ;Image Entry Point
NOR1UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR1ADDRESS: 0x03EC0000 ;Image Flash Address
NOR1FILE: \SOFTWARE\bl1.bin ;Image File Name
NOR1LOAD: 00000000 ;Image Load Address
NOR1ENTRY: 00000000 ;Image Entry Point
NOR2UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR2ADDRESS: 0x00500000 ;Image Flash Address
NOR2FILE: \SOFTWARE\Image ;Image File Name
NOR2NAME: norkern ;Rename kernel to norkern
NOR2LOAD: 00000000 ;Image Load Address
NOR2ENTRY: 00000000 ;Image Entry Point
NOR3UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR3ADDRESS: 0x02700000 ;Image Flash Address
NOR3FILE: \SOFTWARE\juno-r1-xen.dtb ;Image File Name
NOR3NAME: board.dtb ;Specify target filename to preserve file extension
NOR3LOAD: 00000000 ;Image Load Address
NOR3ENTRY: 00000000 ;Image Entry Point
NOR4UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR4ADDRESS: 0x01D00000 ;Image Flash Address
NOR4FILE: \SOFTWARE\xen ;Image File Name
NOR4NAME: xen
NOR4LOAD: 00000000 ;Image Load Address
NOR4ENTRY: 00000000 ;Image Entry Point
NOR5UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR5ADDRESS: 0x025C0000 ;Image Flash Address
NOR5FILE: \SOFTWARE\hdlcdclk.dat ;Image File Name
NOR5LOAD: 00000000 ;Image Load Address
NOR5ENTRY: 00000000 ;Image Entry Point
NOR6UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR6ADDRESS: 0x03E40000 ;Image Flash Address
NOR6FILE: \SOFTWARE\scp_bl1.bin ;Image File Name
NOR6LOAD: 00000000 ;Image Load Address
NOR6ENTRY: 00000000 ;Image Entry Point
NOR7UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR7ADDRESS: 0x0BF00000 ;Image Flash Address
NOR7FILE: \SOFTWARE\startup.nsh ;Image File Name
NOR7NAME: startup.nsh
NOR7LOAD: 00000000 ;Image Load Address
NOR7ENTRY: 00000000 ;Image Entry Point
NOR8UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR8ADDRESS: 0x0BFC0000 ;Image Flash Address
NOR8FILE: \SOFTWARE\blank.img ;Image File Name
NOR8NAME: BOOTENV
NOR8LOAD: 00000000 ;Image Load Address
NOR8ENTRY: 00000000 ;Image Entry Point
NOR9UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR9ADDRESS: 0x02600000 ;Image Flash Address
NOR9FILE: \SOFTWARE\selftest ;Image File Name
NOR9LOAD: 00000000 ;Image Load Address
NOR9ENTRY: 00000000 ;Image Entry Point
NOR10UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR10ADDRESS: 0x02780000 ;Image Flash Address
NOR10NAME: uEnv.txt
NOR10FILE: \SOFTWARE\uEnv.txt ;Image File Name
NOR10LOAD: 00000000 ;Image Load Address
NOR10ENTRY: 00000000 ;Image Entry Point
@@ -0,0 +1,78 @@
TITLE: Versatile Express Images Configuration File
[IMAGES]
TOTALIMAGES: 11 ;Number of Images (Max: 32)
NOR0UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR0ADDRESS: 0x00000000 ;Image Flash Address
NOR0FILE: \SOFTWARE\fip.bin ;Image File Name
NOR0LOAD: 00000000 ;Image Load Address
NOR0ENTRY: 00000000 ;Image Entry Point
NOR1UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR1ADDRESS: 0x03EC0000 ;Image Flash Address
NOR1FILE: \SOFTWARE\bl1.bin ;Image File Name
NOR1LOAD: 00000000 ;Image Load Address
NOR1ENTRY: 00000000 ;Image Entry Point
NOR2UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR2ADDRESS: 0x00500000 ;Image Flash Address
NOR2FILE: \SOFTWARE\Image ;Image File Name
NOR2NAME: norkern ;Rename kernel to norkern
NOR2LOAD: 00000000 ;Image Load Address
NOR2ENTRY: 00000000 ;Image Entry Point
NOR3UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR3ADDRESS: 0x02700000 ;Image Flash Address
NOR3FILE: \SOFTWARE\juno-r2-xen.dtb ;Image File Name
NOR3NAME: board.dtb ;Specify target filename to preserve file extension
NOR3LOAD: 00000000 ;Image Load Address
NOR3ENTRY: 00000000 ;Image Entry Point
NOR4UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR4ADDRESS: 0x01D00000 ;Image Flash Address
NOR4FILE: \SOFTWARE\xen ;Image File Name
NOR4NAME: xen
NOR4LOAD: 00000000 ;Image Load Address
NOR4ENTRY: 00000000 ;Image Entry Point
NOR5UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR5ADDRESS: 0x025C0000 ;Image Flash Address
NOR5FILE: \SOFTWARE\hdlcdclk.dat ;Image File Name
NOR5LOAD: 00000000 ;Image Load Address
NOR5ENTRY: 00000000 ;Image Entry Point
NOR6UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR6ADDRESS: 0x03E40000 ;Image Flash Address
NOR6FILE: \SOFTWARE\scp_bl1.bin ;Image File Name
NOR6LOAD: 00000000 ;Image Load Address
NOR6ENTRY: 00000000 ;Image Entry Point
NOR7UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR7ADDRESS: 0x0BF00000 ;Image Flash Address
NOR7FILE: \SOFTWARE\startup.nsh ;Image File Name
NOR7NAME: startup.nsh
NOR7LOAD: 00000000 ;Image Load Address
NOR7ENTRY: 00000000 ;Image Entry Point
NOR8UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR8ADDRESS: 0x0BFC0000 ;Image Flash Address
NOR8FILE: \SOFTWARE\blank.img ;Image File Name
NOR8NAME: BOOTENV
NOR8LOAD: 00000000 ;Image Load Address
NOR8ENTRY: 00000000 ;Image Entry Point
NOR9UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR9ADDRESS: 0x02600000 ;Image Flash Address
NOR9FILE: \SOFTWARE\selftest ;Image File Name
NOR9LOAD: 00000000 ;Image Load Address
NOR9ENTRY: 00000000 ;Image Entry Point
NOR10UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE
NOR10ADDRESS: 0x02780000 ;Image Flash Address
NOR10NAME: uEnv.txt
NOR10FILE: \SOFTWARE\uEnv.txt ;Image File Name
NOR10LOAD: 00000000 ;Image Load Address
NOR10ENTRY: 00000000 ;Image Entry Point
@@ -0,0 +1,15 @@
xen_name=xen
xen_addr=0x84000000
uenvcmd=run mybootcmd
mybootcmd=echo Loading custom boot command; \
echo Loading kernel; \
afs load ${kernel_name} ${kernel_addr} ; \
if test $? -eq 1; then echo Loading ${kernel_alt_name} instead of ${kernel_name}; afs load ${kernel_alt_name} ${kernel_addr}; fi; \
echo Loading device tree; \
afs load ${fdtfile} ${fdt_addr}; \
if test $? -eq 1; then echo Loading ${fdt_alt_name} instead of ${fdtfile}; \
afs load ${fdt_alt_name} ${fdt_addr}; fi; fdt addr ${fdt_addr}; fdt resize; \
echo Loading Xen; \
afs load ${xen_name} ${xen_addr}; \
if test $? -eq 0; then echo Booting Xen; bootefi ${xen_addr} ${fdt_addr}; fi;
@@ -0,0 +1,11 @@
/*
* Disable IOMMU on juno board when Xen is used
*/
/ {
/* turn off iommu */
iommu@2b600000 {
status = "disabled";
};
};
@@ -0,0 +1,39 @@
/*
* Modify N1SDP DTB to work properly when Xen is used
*/
/ {
/*
* pmu is using PPI interrupts which are reserved by xen
* remove pm nodes
*/
/delete-node/ pmu;
/delete-node/ spe-pmu;
/*
* disable IOMMU until we have a proper support in xen
*/
/delete-node/ iommu@4f000000;
/delete-node/ iommu@4f400000;
/*
* Set extra registers required for PCI quirks to communicate with SCP
* and remove invalid properties due to removal
*/
pcie@68000000 {
reg = <0 0x68000000 0 0x1200000>,
<0 0x06000000 0 0x80000>,
<0 0x62000000 0 0x80000>;
/delete-property/ msi-map;
/delete-property/ iommu-map;
};
pcie@70000000 {
reg = <0 0x70000000 0 0x1200000>,
<0 0x06000000 0 0x80000>,
<0 0x60000000 0 0x80000>;
/delete-property/ msi-map;
/delete-property/ iommu-map;
};
};
@@ -0,0 +1,25 @@
# Platform dependent parameters
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
# Add a dtb snippet to turn off iommu in dom0 on Juno board
SRC_URI_append_juno = " file://xen-juno.dtsi"
XEN_DEVICETREE_DTSI_MERGE_append_juno = " xen-juno.dtsi"
# Add a dtb snippet to remove pmu and iommu in dom0 on N1SDP
SRC_URI_append_n1sdp = " file://xen-n1sdp.dtsi"
XEN_DEVICETREE_DTSI_MERGE_append_n1sdp = " xen-n1sdp.dtsi"
# Board specific configs
XEN_DEVICETREE_DOM0_BOOTARGS_append_juno = " root=/dev/sda1 rootwait"
XEN_DEVICETREE_XEN_BOOTARGS_append_juno = " console=dtuart dtuart=serial0 bootscrub=0 iommu=no"
XEN_DEVICETREE_DOM0_BOOTARGS_append_n1sdp = " root=/dev/sda1 rootwait"
XEN_DEVICETREE_XEN_BOOTARGS_append_n1sdp = " console=dtuart dtuart=serial0 bootscrub=0 iommu=no"
XEN_DEVICETREE_DOM0_BOOTARGS_append_fvp-base = " root=/dev/vda2"
XEN_DEVICETREE_XEN_BOOTARGS_append_fvp-base = " console=dtuart dtuart=serial0 bootscrub=0"
XEN_DEVICETREE_DOM0_BOOTARGS_append_foundation-armv8 = " root=/dev/vda2"
XEN_DEVICETREE_XEN_BOOTARGS_append_foundation-armv8 = " console=dtuart dtuart=serial0 bootscrub=0"
@@ -0,0 +1,44 @@
From a41feccdb6c03f12bddb4fb650a0465f0ed6eeca Mon Sep 17 00:00:00 2001
From: Lukas Juenger <juenger@ice.rwth-aachen.de>
Date: Fri, 5 Apr 2019 15:54:04 +0200
Subject: [PATCH] xen/arm: Cap the number of interrupt lines for dom0
Dom0 vGIC will use the same number of interrupt lines as the hardware GIC.
While the hardware GIC can support up to 1020 interrupt lines,
the vGIC is only supporting up to 992 interrupt lines.
This means that Xen will not be able to boot on platforms where the hardware
GIC supports more than 992 interrupt lines.
While it would make sense to increase the limits in the vGICs, this is not
trivial because of the design choices.
At the moment, only models seem to report the maximum of interrupt lines.
They also do not have any interrupt wired above the 992 limit.
So it should be fine to cap the number of interrupt lines for dom0 to 992 lines.
Signed-off-by: Lukas Juenger <juenger@ice.rwth-aachen.de>
Acked-by: Julien Grall <julien.grall@arm.com>
---
xen/arch/arm/setup.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 444857a967..ccb0f181ea 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -888,7 +888,13 @@ void __init start_xen(unsigned long boot_phys_offset,
/* Create initial domain 0. */
/* The vGIC for DOM0 is exactly emulating the hardware GIC */
dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
- dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
+ /*
+ * Xen vGIC supports a maximum of 992 interrupt lines.
+ * 32 are substracted to cover local IRQs.
+ */
+ dom0_cfg.arch.nr_spis = min(gic_number_lines(), (unsigned int) 992) - 32;
+ if ( gic_number_lines() > 992 )
+ printk(XENLOG_WARNING "Maximum number of vGIC IRQs exceeded.\n");
dom0_cfg.max_vcpus = dom0_max_vcpus();
dom0 = domain_create(0, &dom0_cfg, true);
--
2.17.1
@@ -0,0 +1,73 @@
#
# Automatically generated file; DO NOT EDIT.
# Xen/arm 4.12.0 Configuration
#
CONFIG_64BIT=y
CONFIG_ARM_64=y
CONFIG_ARM=y
CONFIG_ARCH_DEFCONFIG="arch/arm/configs/arm64_defconfig"
#
# Architecture Features
#
CONFIG_NR_CPUS=128
CONFIG_GICV3=y
CONFIG_HVM=y
# CONFIG_NEW_VGIC is not set
CONFIG_SBSA_VUART_CONSOLE=y
CONFIG_ARM_SSBD=y
CONFIG_HARDEN_BRANCH_PREDICTOR=y
#
# ARM errata workaround via the alternative framework
#
CONFIG_ARM64_ERRATUM_827319=y
CONFIG_ARM64_ERRATUM_824069=y
CONFIG_ARM64_ERRATUM_819472=y
CONFIG_ARM64_ERRATUM_832075=y
CONFIG_ARM64_ERRATUM_834220=y
CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR=y
CONFIG_ALL_PLAT=y
# CONFIG_QEMU is not set
# CONFIG_RCAR3 is not set
# CONFIG_MPSOC is not set
# CONFIG_NO_PLAT is not set
CONFIG_ALL64_PLAT=y
# CONFIG_ALL32_PLAT is not set
CONFIG_MPSOC_PLATFORM=y
#
# Common Features
#
CONFIG_HAS_ALTERNATIVE=y
CONFIG_HAS_DEVICE_TREE=y
CONFIG_MEM_ACCESS=y
CONFIG_HAS_PDX=y
# CONFIG_XSM is not set
CONFIG_SCHED_CREDIT=y
CONFIG_SCHED_CREDIT2=y
CONFIG_SCHED_RTDS=y
# CONFIG_SCHED_ARINC653 is not set
CONFIG_SCHED_NULL=y
CONFIG_SCHED_DEFAULT="credit2"
# CONFIG_LIVEPATCH is not set
CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS=y
CONFIG_CMDLINE=""
CONFIG_DOM0_MEM=""
#
# Device Drivers
#
CONFIG_HAS_NS16550=y
CONFIG_HAS_CADENCE_UART=y
CONFIG_HAS_MVEBU=y
CONFIG_HAS_PL011=y
CONFIG_HAS_SCIF=y
CONFIG_HAS_PASSTHROUGH=y
CONFIG_ARM_SMMU=y
CONFIG_DEFCONFIG_LIST="arch/arm/configs/arm64_defconfig"
#
# Debugging Options
#
# CONFIG_DEBUG is not set
@@ -0,0 +1,73 @@
#
# Automatically generated file; DO NOT EDIT.
# Xen/arm 4.12.0 Configuration
#
CONFIG_64BIT=y
CONFIG_ARM_64=y
CONFIG_ARM=y
CONFIG_ARCH_DEFCONFIG="arch/arm/configs/arm64_defconfig"
#
# Architecture Features
#
CONFIG_NR_CPUS=128
CONFIG_GICV3=y
CONFIG_HVM=y
# CONFIG_NEW_VGIC is not set
CONFIG_SBSA_VUART_CONSOLE=y
CONFIG_ARM_SSBD=y
CONFIG_HARDEN_BRANCH_PREDICTOR=y
#
# ARM errata workaround via the alternative framework
#
CONFIG_ARM64_ERRATUM_827319=y
CONFIG_ARM64_ERRATUM_824069=y
CONFIG_ARM64_ERRATUM_819472=y
CONFIG_ARM64_ERRATUM_832075=y
CONFIG_ARM64_ERRATUM_834220=y
CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR=y
CONFIG_ALL_PLAT=y
# CONFIG_QEMU is not set
# CONFIG_RCAR3 is not set
# CONFIG_MPSOC is not set
# CONFIG_NO_PLAT is not set
CONFIG_ALL64_PLAT=y
# CONFIG_ALL32_PLAT is not set
CONFIG_MPSOC_PLATFORM=y
#
# Common Features
#
CONFIG_HAS_ALTERNATIVE=y
CONFIG_HAS_DEVICE_TREE=y
CONFIG_MEM_ACCESS=y
CONFIG_HAS_PDX=y
# CONFIG_XSM is not set
CONFIG_SCHED_CREDIT=y
CONFIG_SCHED_CREDIT2=y
CONFIG_SCHED_RTDS=y
# CONFIG_SCHED_ARINC653 is not set
CONFIG_SCHED_NULL=y
CONFIG_SCHED_DEFAULT="credit2"
# CONFIG_LIVEPATCH is not set
CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS=y
CONFIG_CMDLINE=""
CONFIG_DOM0_MEM=""
#
# Device Drivers
#
CONFIG_HAS_NS16550=y
CONFIG_HAS_CADENCE_UART=y
CONFIG_HAS_MVEBU=y
CONFIG_HAS_PL011=y
CONFIG_HAS_SCIF=y
CONFIG_HAS_PASSTHROUGH=y
CONFIG_ARM_SMMU=y
CONFIG_DEFCONFIG_LIST="arch/arm/configs/arm64_defconfig"
#
# Debugging Options
#
# CONFIG_DEBUG is not set
@@ -0,0 +1,100 @@
#
# Automatically generated file; DO NOT EDIT.
# Xen/arm 4.12.2 Configuration
#
CONFIG_64BIT=y
CONFIG_ARM_64=y
CONFIG_ARM=y
CONFIG_ARCH_DEFCONFIG="arch/arm/configs/arm64_defconfig"
#
# Architecture Features
#
CONFIG_NR_CPUS=128
CONFIG_ACPI=y
CONFIG_GICV3=y
CONFIG_HAS_ITS=y
CONFIG_HVM=y
# CONFIG_NEW_VGIC is not set
CONFIG_SBSA_VUART_CONSOLE=y
CONFIG_ARM_SSBD=y
CONFIG_HARDEN_BRANCH_PREDICTOR=y
#
# ARM errata workaround via the alternative framework
#
CONFIG_ARM64_ERRATUM_827319=y
CONFIG_ARM64_ERRATUM_824069=y
CONFIG_ARM64_ERRATUM_819472=y
CONFIG_ARM64_ERRATUM_832075=y
CONFIG_ARM64_ERRATUM_834220=y
CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR=y
CONFIG_ALL_PLAT=y
# CONFIG_QEMU is not set
# CONFIG_RCAR3 is not set
# CONFIG_MPSOC is not set
# CONFIG_NO_PLAT is not set
CONFIG_ALL64_PLAT=y
# CONFIG_ALL32_PLAT is not set
CONFIG_MPSOC_PLATFORM=y
#
# Common Features
#
CONFIG_HAS_ALTERNATIVE=y
CONFIG_HAS_DEVICE_TREE=y
# CONFIG_MEM_ACCESS is not set
CONFIG_HAS_PDX=y
# CONFIG_TMEM is not set
CONFIG_XSM=y
CONFIG_XSM_FLASK=y
CONFIG_XSM_FLASK_AVC_STATS=y
# CONFIG_XSM_FLASK_POLICY is not set
CONFIG_XSM_SILO=y
# CONFIG_XSM_DUMMY_DEFAULT is not set
# CONFIG_XSM_FLASK_DEFAULT is not set
CONFIG_XSM_SILO_DEFAULT=y
# CONFIG_ARGO is not set
#
# Schedulers
#
CONFIG_SCHED_CREDIT=y
CONFIG_SCHED_CREDIT2=y
CONFIG_SCHED_RTDS=y
# CONFIG_SCHED_ARINC653 is not set
CONFIG_SCHED_NULL=y
# CONFIG_SCHED_CREDIT_DEFAULT is not set
CONFIG_SCHED_CREDIT2_DEFAULT=y
# CONFIG_SCHED_RTDS_DEFAULT is not set
# CONFIG_SCHED_NULL_DEFAULT is not set
CONFIG_SCHED_DEFAULT="credit2"
# CONFIG_LIVEPATCH is not set
CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS=y
CONFIG_CMDLINE=""
CONFIG_DOM0_MEM=""
#
# Device Drivers
#
CONFIG_HAS_NS16550=y
CONFIG_HAS_CADENCE_UART=y
CONFIG_HAS_MVEBU=y
CONFIG_HAS_PL011=y
CONFIG_HAS_SCIF=y
CONFIG_HAS_PASSTHROUGH=y
CONFIG_ARM_SMMU=y
CONFIG_DEFCONFIG_LIST="arch/arm/configs/arm64_defconfig"
#
# Debugging Options
#
# CONFIG_DEBUG is not set
CONFIG_DEBUG_INFO=y
# CONFIG_FRAME_POINTER is not set
# CONFIG_COVERAGE is not set
# CONFIG_LOCK_PROFILE is not set
# CONFIG_PERF_COUNTERS is not set
CONFIG_VERBOSE_DEBUG=y
# CONFIG_DEVICE_TREE_DEBUG is not set
# CONFIG_SCRUB_DEBUG is not set
@@ -0,0 +1,32 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
# Machine specific settings
XEN_CONFIG_EARLY_PRINTK_juno = "juno"
XEN_CONFIG_EARLY_PRINTK_gem5-arm64 = "vexpress"
XEN_CONFIG_EARLY_PRINTK_fvp-base = "fastmodel"
XEN_CONFIG_EARLY_PRINTK_foundation-armv8 = "fastmodel"
XEN_CONFIG_EARLY_PRINTK_n1sdp = "pl011,0x2a400000"
# Foundation-armv8 support
COMPATIBLE_MACHINE_foundation-armv8 = "foundation-armv8"
SRC_URI_append_foundation-armv8 = " file://fvp/defconfig"
# FVP Base support
COMPATIBLE_MACHINE_fvp-base = "fvp-base"
SRC_URI_append_fvp-base = " file://fvp/defconfig"
# Juno support
COMPATIBLE_MACHINE_juno = "juno"
SRC_URI_append_juno = " file://juno/defconfig"
# Gem5 support
# Fix problem with number of interrupts on gem5
SRC_URI_append_gem5-arm64 = " file://4.12.0/0001-xen-arm-Cap-the-number-of-interrupt-lines-for-dom0.patch"
# N1SDP support
COMPATIBLE_MACHINE_n1sdp = "n1sdp"
SRC_URI_append_n1sdp = " file://n1sdp/defconfig"
@@ -0,0 +1,6 @@
# Board specific configuration for the manager
# FVP and Foundation are using vda as hard drive and partition 2 is the
# default rootfs, so use vda3 for guest lvm
XENGUEST_MANAGER_VOLUME_DEVICE_foundation-armv8 ?= "/dev/vda3"
XENGUEST_MANAGER_VOLUME_DEVICE_fvp-base ?= "/dev/vda3"
@@ -0,0 +1,2 @@
# Juno board has 2 network interfaces, add both of them to the bridge
XENGUEST_NETWORK_BRIDGE_MEMBERS_juno ?= "eth0 eth1"
@@ -0,0 +1,17 @@
FILESEXTRAPATHS_prepend := "${THISDIR}:"
#
# arm-autonomy kmeta extra
#
SRC_URI_append = " file://arm-autonomy-kmeta-extra;type=kmeta;name=arm-autonomy-kmeta-extra;destsuffix=arm-autonomy-kmeta-extra"
# We need to turn off SVE support in the Linux kernel otherwise Xen is stopping
# Linux kernel with a coredump while trying to access XEN bit of CPACR1 core
# register.
LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE = "${@bb.utils.contains_any('DISTRO_FEATURES', \
'arm-autonomy-host arm-autonomy-guest', \
' features/arm-autonomy/disable-arm64-sve.scc','',d)}"
KERNEL_FEATURES_append_gem5-arm64 = "${LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE}"
KERNEL_FEATURES_append_fvp-base = "${LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE}"
KERNEL_FEATURES_append_foundation-armv8 = "${LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE}"
@@ -0,0 +1,120 @@
# Recipe to create a minimal Arm Autonomy stack host image
DESCRIPTION = "Arm Autonomy stack host minimal image"
inherit core-image
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
# The ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS variable can be used to include in the
# image one or several xenguest images.
# The list must be space separated and each entry must have the following
# format: URL[;guestname=NAME]
# - URL can be the full path to a file or a Yocto compatible SRC_URI url
# - guestname=NAME can be used to specify the name of the guest. If not
# specified the basename of the file (without .xenguest extension) is used.
# Here are examples of values:
# /home/mydir/myguest.xenguest;guestname=guest1
# http://www.url.com/testguest.xenguest
#
# If you are using the output of an other Yocto project, you should use the
# full path syntax instead of the Yocto SRC_URI to be able to use the
# symlink version of your image (as the real file has a new name on each
# build as it includes the date). You must not use SRC_URI type file:// as
# it will try to include the symlink and not the destination file which will
# be detected by the recipe and output an error 'Guest file is a symlink'.
#
# Guests can also be added using a bbapend to this recipe by adding entries
# to SRC_URI with parameter ;guestname=NAME to specify the destination
# guestname. The parameter guestname must be present as it is used to detect
# guests to be added
ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS ??= ""
# Includes minimal set required to start and manage guest. The xen specific
# modules are not explicitly included as they are built as part of the kernel
# image for performance reasons. It doesn't include all kernel modules to
# reduce the image size. If the kernel-modules packages are needed they can
# be appended to IMAGE_INSTALL in a bbappend.
IMAGE_INSTALL += " \
packagegroup-core-boot \
packagegroup-core-ssh-openssh \
qemu-xen \
xenguest-manager \
xenguest-network-bridge \
"
# Build xen binary
EXTRA_IMAGEDEPENDS += "xen"
# Build xen-devicetree to produce a xen ready devicetree
EXTRA_IMAGEDEPENDS += "xen-devicetree"
python __anonymous() {
if bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', False, True, d):
raise bb.parse.SkipRecipe("DISTRO_FEATURES does not contain 'arm-autonomy-host'")
if bb.utils.contains('DISTRO_FEATURES', 'xen', False, True, d):
raise bb.parse.SkipRecipe("DISTRO_FEATURES does not contain 'xen'")
# Check in ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS for extra guests and add them
# to SRC_URI with xenguest parameter if not set
guestlist = d.getVar('ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS')
if guestlist:
for guest in guestlist.split():
# If the user just specified a file instead of file://FILE, add
# the file:// prefix
if guest.startswith('/'):
guestfile = ''
guestname = ''
if ';guestname=' in guest:
# user specified a guestname
guestname = guest.split(';guestname=')[1]
guestfile = guest.split(';guestname=')[0]
else:
# no guestname so use the basename
guestname = os.path.basename(guest)
guestfile = guest
# in case we have a link we need the destination
guestfile = os.path.realpath(guestfile)
# make sure the file exist to give a meaningfull error
if not os.path.exists(guestfile):
raise bb.parse.SkipRecipe("ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS entry does not exist: " + guest)
# In case the file is a symlink make sure we use the destination
d.appendVar('SRC_URI', ' file://' + guestfile + ';guestname=' + guestname)
else:
# we have a Yocto URL
try:
_, _, path, _, _, parm = bb.fetch.decodeurl(guest)
# force guestname param in if not already there
if not 'guestname' in parm:
guest += ';guestname=' + os.path.basename(path)
d.appendVar('SRC_URI', ' ' + guest)
except:
raise bb.parse.SkipRecipe("ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS contains an invalid entry: " + guest)
}
python add_extern_guests () {
# Destination directory on the rootfs
guestdir = d.getVar('IMAGE_ROOTFS') + d.getVar('datadir') + '/guests'
# Parse SRC_URI for files with ;guestname= parameter
src_uri = d.getVar('SRC_URI')
for entry in src_uri.split():
_, _, path, _, _, parm = bb.fetch.decodeurl(entry)
if 'guestname' in parm:
if os.path.islink(path):
bb.fatal("Guest file is a symlink: " + path)
bb.utils.mkdirhier(guestdir)
dstname = parm['guestname']
# Add file extension if not there
if not dstname.endswith('.xenguest'):
dstname += '.xenguest'
if not bb.utils.copyfile(path, guestdir + '/' + dstname):
bb.fatal("Fail to copy Guest file " + path)
}
IMAGE_PREPROCESS_COMMAND += "add_extern_guests; "
@@ -0,0 +1,18 @@
# Add support for interface configuration via interfaces.d directory. This
# feature can be used by other packages to add network interface
# configuration by adding network network interface configuration file under
# interfaces.d directory.
do_install_append() {
# Add scan of interfaces.d to interfaces file
cp -f ${WORKDIR}/interfaces ${WORKDIR}/interfaces.subdir
echo "source-directory ${sysconfdir}/network/interfaces.d/" \
>> ${WORKDIR}/interfaces.subdir
# Create interfaces.d script in case nobody is adding a script
# so that there is no error about non existing directory
install -d -m 755 ${D}${sysconfdir}/network/interfaces.d
# Install our file instead of the original one
install -m 644 interfaces.subdir ${D}${sysconfdir}/network/interfaces
}
@@ -0,0 +1,16 @@
# if arm-autonomy-guest is activated, we are running as a xen guest so we must
# have a console on hvc0
# This is normally done in meta-virtualization if xen is activated but here
# we don't have xen activated.
#
SYSVINIT_ADDHVC0 = "${@bb.utils.contains('DISTRO_FEATURES', \
'arm-autonomy-guest', 'true', 'false', d)}"
do_install_append() {
if ${SYSVINIT_ADDHVC0}; then
echo "" >> ${D}${sysconfdir}/inittab
echo "X0:12345:respawn:/sbin/getty 115200 hvc0" >> \
${D}${sysconfdir}/inittab
fi
}
@@ -0,0 +1,18 @@
# Use OVERRIDES to minimize the usage of
# ${@bb.utils.contains('DISTRO_FEATURES', 'xen', ...
OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ':xen', '', d)}"
# For Xen we only need the i386 binaries
QEMU_TARGETS_xen = "i386"
PACKAGECONFIG[noaudio] = "--audio-drv-list='',,"
PACKAGECONFIG_append_xen = " virtfs noaudio"
PACKAGECONFIG_remove_xen = "sdl"
# Reduce the qemu package size by splitting it into
# qemu and qemu-xen packages
PACKAGES_prepend_xen := "${PN}-xen"
RDEPENDS_${PN}_xen += "${PN}-xen"
FILES_${PN}-xen_xen = "${bindir}/qemu-system-i386"
RDEPENDS_${PN}-xen_xen += "xen-tools-libxenstore xen-tools-libxenctrl \
xen-tools-libxenguest"

Some files were not shown because too many files have changed in this diff Show More