mirrors/meta-arm
1
0
Fork 0
mirror of https://git.yoctoproject.org/meta-arm synced 2026-01-11 15:00:39 +00:00
Code Issues Projects Releases Wiki Activity

arm-autonomy: Remove code from master as part of the deprecation plan

Browse Source 
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.

    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

Issue-Id: SCM-3552
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
Change-Id: I3ca58f8c13b1ecb3dbaf0d60f0f52b016292633d
Signed-off-by: Jon Mason <jon.mason@arm.com>
This commit is contained in:
Diego Sueiro
2021-10-29 14:41:31 +01:00
committed by Jon Mason
parent 8b82d1230d
commit c2ff49c4a9
100 changed files with 9 additions and 6708 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.gitlab-ci.yml
View File

@@ -89,7 +89,7 @@ check-layers:
extends: .setup
coverage: '/Coverage: \d+/'
script:
- kas shell --update --force-checkout ci/base.yml:ci/meta-arm-autonomy.yml:ci/meta-openembedded.yml --command \
- kas shell --update --force-checkout ci/base.yml:ci/meta-openembedded.yml --command \
"$CI_PROJECT_DIR/ci/check-layers.py $CI_PROJECT_DIR/ci/check-layers.yml $CI_PROJECT_DIR $KAS_WORK_DIR"
pending-updates:

6
ci/check-layers.yml
View File

@@ -3,11 +3,5 @@ layers:
- meta-arm-bsp
- meta-arm-toolchain
- meta-gem5
- meta-arm-autonomy
dependencies:
- meta-openembedded/meta-oe
- meta-openembedded/meta-networking
- meta-openembedded/meta-python
- meta-openembedded/meta-filesystems
- poky/meta-poky
- meta-virtualization

10
ci/meta-arm-autonomy.yml
View File

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

86
meta-arm-autonomy/README.md
View File

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

26
meta-arm-autonomy/classes/alternate-kernel.bbclass
View File

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

5
meta-arm-autonomy/classes/arm-autonomy-features.bbclass
View File

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

115
meta-arm-autonomy/classes/docker_extern_containers.bbclass
View File

@@ -1,115 +0,0 @@
# Docker Extern Containers
#
# This class allows docker image tarballs to be installed in the rootfs
#
# The images can be selected using the variable CONTAINER_IMAGE_FILES which
# should contain a space seperated list of absolute paths or yocto urls for
# docker images that have been exported using docker export:
# - https://docs.docker.com/engine/reference/commandline/export/
#
# src_uri_parse_var.bbclass is used to parse CONTAINER_IMAGE_FILES
#
# There are 4 supported formats for CONTAINER_IMAGE_FILES entries:
#
# - http/https url
# - CONTAINER_IMAGE_FILES = "https://[url]:[port]/alpine.tar;md5sum=..."
#
# - file:// absolute local path from root
# - CONTAINER_IMAGE_FILES = "file:///containers/alpine2.tar"
#
# - file:// path relative to FILESEXTRAPATHS
# - CONTAINER_IMAGE_FILES = "file://foo/alpine3.tar"
# FILESEXTRAPATHS .= "/containers:"
#
# - plain absolute local path from root
# - CONTAINER_IMAGE_FILES = "/containers/foo/bar/alpine4.tar"
#
# It is not recommended to use other yocto URL types, as they may result in
# undefined behaviour.
#
# A semicolon seperated list of install arguments can follow each image path:
# - conname : the name that will be attached when the image is imported
# (default: [filename, without extension])
# - contag : the tag that will be attached when the image is imported
# (default: local)
# - conkeep : Flag for whether the exported container image file should be
# kept once the import has been completed
# (default: 0)
#
# Any other arguments, for example an md5sum, will be assumed to be fetch
# arguments, and will be kept when the path is added to the SRC_URI
#
# e.g. CONTAINER_IMAGE_FILES = "\
# https://[url]:[port]/alpine.tar;md5sum=[checksum];conkeep=1 \
# file:///containers/alpine2.tar;contag=latest;conname=docker2 \
# file://foo/alpine3.tar \
# /containers/foo/bar/alpine4.tar;contag=1.0;conkeep=1 "
#
# Resulting Manifest:
# ARCHIVE NAME TAG KEEP
# alpine.tar alpine local 1
# alpine2.tar docker2 latest 0
# alpine3.tar alpine3 local 0
# alpine4.tar alpine4 1.0 1
#
# Other configurable variables:
# CONTAINERS_INSTALL_DIR : The folder underneath ${WORKDIR} where the docker
# images will be stored
# (default: "/usr/share/docker/images")
# CONTAINERS_MANIFEST : The name of the manifest file containing image
# parameters, also stored in CONTAINERS_INSTALL_DIR
# (default: "containers.manifest")
# CONTAINERS_TAG_DEFAULT : Use this to change the value that will be used as
# contag if no value is provided
# (default: "local")
# CONTAINERS_KEEP_DEFAULT : Use this to change the value that will be used for
# conkeep if no value is provided
# (default: "0")
#
inherit features_check
REQUIRED_DISTRO_FEATURES = "docker"
RDEPENDS:${PN} = "packagegroup-docker-runtime-minimal"
CONTAINER_IMAGE_FILES ??= ""
CONTAINERS_INSTALL_DIR ??= "${datadir}/docker/images"
CONTAINERS_MANIFEST ??= "containers.manifest"
CONTAINERS_TAG_DEFAULT ??= "local"
CONTAINERS_KEEP_DEFAULT ??= "0"
inherit set_src_uri_from_var
SRC_URI_FROM_VAR_NAME = "CONTAINER_IMAGE_FILES"
# Define installation params
SRC_URI_FROM_VAR_MANIFEST_PARAMS = "conname=[basename] \
contag=${CONTAINERS_TAG_DEFAULT} conkeep=${CONTAINERS_KEEP_DEFAULT}"
SRC_URI_FROM_VAR_UNPACK_DIR = "containers"
# Read manifest and install container images
do_install() {
local archive name tag keep
if [ -f "${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/manifest" ]; then
install -d "${D}${CONTAINERS_INSTALL_DIR}"
install -m 644 \
"${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/manifest" \
"${D}${CONTAINERS_INSTALL_DIR}/${CONTAINERS_MANIFEST}"
while read -r archive name tag keep _; do
[ -f "${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/${archive}" ] ||
bbfatal "${archive} does not exist"
install -m 644 \
"${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/${archive}" \
"${D}${CONTAINERS_INSTALL_DIR}/${archive}"
done < "${D}${CONTAINERS_INSTALL_DIR}/${CONTAINERS_MANIFEST}"
fi
}
do_install[vardeps] += "CONTAINER_IMAGE_FILES"
FILES:${PN} += "${CONTAINERS_INSTALL_DIR}"

169
meta-arm-autonomy/classes/image_types_xenguest.bbclass
View File

@@ -1,169 +0,0 @@
# Create a xenguest image with kernel and filesystem produced by Yocto
# This will create a .xenguest file that the xenguest-manager can use.
inherit xenguest_image
# We are creating our guest in a local subdirectory
# force the value so that we are not impacted if the user is changing it
XENGUEST_IMAGE_DEPLOY_DIR = "${WORKDIR}/tmp-xenguest"
# Name of deployed file (keep standard image name and add .xenguest)
XENGUEST_IMAGE_DEPLOY ??= "${IMAGE_NAME}"
# Add kernel XENGUEST_IMAGE_KERNEL from DEPLOY_DIR_IMAGE to image
xenguest_image_add_kernel() {
srcfile="${1:-}"
if [ -z "${srcfile}" ]; then
srcfile="${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_KERNEL}"
fi
call_xenguest_mkimage partial --xen-kernel=$srcfile
}
# Add rootfs file to the image
xenguest_image_add_rootfs() {
call_xenguest_mkimage partial \
--disk-add-file=${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${IMAGE_TYPEDEP:xenguest}:rootfs.${IMAGE_TYPEDEP:xenguest}
}
# Pack xenguest image
xenguest_image_pack() {
mkdir -p ${IMGDEPLOYDIR}
rm -f ${IMGDEPLOYDIR}/${XENGUEST_IMAGE_DEPLOY}.xenguest
call_xenguest_mkimage pack \
${IMGDEPLOYDIR}/${XENGUEST_IMAGE_DEPLOY}.xenguest
}
#
# Task finishing the bootimg
# We need this task to actually create the symlinks
#
python do_bootimg_xenguest() {
subtasks = d.getVarFlag('do_bootimg_xenguest', 'subtasks')
bb.build.exec_func('xenguest_image_clone', d)
if subtasks:
for tk in subtasks.split():
bb.build.exec_func(tk, d)
bb.build.exec_func('xenguest_image_pack', d)
bb.build.exec_func('create_symlinks', d)
}
# This is used to add sub-tasks to do_bootimg_xenguest
do_bootimg_xenguest[subtasks] = ""
# Those are required by create_symlinks to find our image
do_bootimg_xenguest[subimages] = "xenguest"
do_bootimg_xenguest[imgsuffix] = "."
do_bootimg_xenguest[depends] += "xenguest-base-image:do_deploy"
# Need to have rootfs so all recipes have deployed their content
do_bootimg_xenguest[depends] += "${PN}:do_rootfs"
# This set in python anonymous after, just set a default value here
IMAGE_TYPEDEP:xenguest ?= "tar"
# We must not be built at rootfs build time because we need the kernel
IMAGE_TYPES_MASKED += "xenguest"
IMAGE_TYPES += "xenguest"
XENGUEST_IMAGE_RECIPE = "${PN}"
XENGUEST_IMAGE_VARS += "XENGUEST_IMAGE_RECIPE"
# Merge intermediate env files from all recipes into a single file
python do_merge_xenguestenv () {
import re
# Open final merged file in DEPLOY_DIR_IMAGE for writing, or create
outdir = d.getVar('DEPLOY_DIR_IMAGE')
with open(os.path.join(outdir,'xenguest.env'), 'w') as merged_file:
# Adds vars from xenguest_image to list
merged_env = []
xenguest_vars = d.getVar('XENGUEST_IMAGE_VARS')
for var in xenguest_vars.split():
value = d.getVar(var)
if value:
merged_env.append(var + "=" + " ".join(value.split()) + "\n")
# Resolve dependencies for this task to find names of intermediate
# .xenguestenv files
taskdepdata = d.getVar('BB_TASKDEPDATA')
task_mc = d.getVar('BB_CURRENT_MC')
task_file = d.getVar('FILE')
# See runqueue.py function build_taskdepdata
DEPS_INDEX = 3
depdata_key = task_file + ":do_merge_xenguestenv"
# If in a multiconfig, need to add that to the key
if task_mc != "default":
depdata_key = "mc:" + task_mc + ":" + depdata_key
# Retrieve filename using regex
get_filename = re.compile(r'/([^/]+\.bb):do_deploy_xenguestenv$')
env_dir = d.getVar('XENGUEST_ENV_STAGING_DIR')
for task_dep in taskdepdata[depdata_key][DEPS_INDEX]:
if task_dep.endswith(":do_deploy_xenguestenv"):
filename = re.search(get_filename, task_dep).group(1) + ".xenguestenv"
bb.note("Merging: " + filename)
try:
with open(env_dir + "/" + filename, 'r') as f:
# Eliminate duplicates
merged_env = list(set(merged_env + f.readlines()))
except (FileNotFoundError, IOError):
bb.note(" " + filename + " has no extra vars")
# Sort Alphabetically and write
merged_env.sort()
merged_file.write("".join(merged_env))
}
do_merge_xenguestenv[dirs] = "${DEPLOY_DIR_IMAGE}"
do_merge_xenguestenv[vardeps] += "${XENGUEST_IMAGE_VARS}"
do_merge_xenguestenv[vardepsexclude] += "BB_TASKDEPDATA"
do_merge_xenguestenv[recrdeptask] += "do_deploy_xenguestenv"
addtask merge_xenguestenv before do_populate_lic_deploy after do_image_complete
python __anonymous() {
# Do not do anything if we are not in the want FSTYPES
if bb.utils.contains_any('IMAGE_FSTYPES', 'xenguest', '1', '0', d):
# Check the coherency of the configuration
rootfs_needed = False
rootfs_file = ''
kernel_needed = False
rootfs_file = xenguest_image_rootfs_file(d)
if rootfs_file:
rootfs_needed = True
if d.getVar('XENGUEST_IMAGE_KERNEL') and not d.getVar('INITRAMFS_IMAGE'):
# If INITRAMFS_IMAGE is set, even if INITRAMFS_IMAGE_BUNDLE is not
# set to 1 to bundle the initramfs with the kernel, kernel.bbclass
# is setting a dependency on ${PN}:do_image_complete. We cannot
# in this case depend on do_deploy as it would create a circular
# dependency:
# do_image_complete would depend on kernel:do_deploy which would
# depend on ${PN}:do_image_complete
# In the case INITRAMFS_IMAGE_BUNDLE = 1, the kernel-xenguest class
# will handle the creation of a xenguest image with the kernel.
# In the other case the kernel can be added manually to the image.
kernel_needed = True
bb.build.addtask('do_bootimg_xenguest', 'do_image_complete', None, d)
if rootfs_needed:
# tell do_bootimg_xenguest to call add_rootfs
d.appendVarFlag('do_bootimg_xenguest', 'subtasks', ' xenguest_image_add_rootfs')
# do_bootimg_xenguest will need the tar file
d.appendVarFlag('do_bootimg_xenguest', 'depends', ' %s:do_image_tar' % (d.getVar('PN')))
# set our TYPEDEP to the proper compression
d.setVar('IMAGE_TYPEDEP:xenguest', 'tar' + (rootfs_file.split('.tar', 1)[1] or ''))
if kernel_needed:
# Tell do_bootimg_xenguest to call xenguest_image_add_kernel
d.appendVarFlag('do_bootimg_xenguest', 'subtasks', ' xenguest_image_add_kernel')
# we will need kernel do_deploy
d.appendVarFlag('do_bootimg_xenguest', 'depends', ' virtual/kernel:do_deploy')
}

37
meta-arm-autonomy/classes/kernel-xenguest.bbclass
View File

@@ -1,37 +0,0 @@
# Create a xenguest image containing the kernel with initramfs when
# initramfs is activated
# This is done using kernel-fitimage as model
# To activate this, kernel-xenguest must be added to KERNEL_CLASSES
# Add a variable name to XENGUEST_IMAGE_VARS_EXTRA if you want it to
# appear in xenguest.env when the image is deployed
inherit xenguest_image
# use a local copy to pack all together
XENGUEST_IMAGE_DEPLOY_DIR = "${WORKDIR}/tmp-xenguest"
python __anonymous () {
# only if xenguest image type is present
if bb.utils.contains('IMAGE_FSTYPES', 'xenguest', '1', '0', d):
# only if initramfs bundle is activated
if d.getVar('INITRAMFS_IMAGE') and d.getVar('INITRAMFS_IMAGE_BUNDLE') == "1":
if not bb.utils.contains('KERNEL_IMAGETYPES', 'Image', '1', '0', d):
bb.fatal("xenguest image type with initramfs require Image kernel image type")
bb.build.addtask('do_assemble_xenguest_initramfs', 'do_deploy', 'do_bundle_initramfs', d)
}
do_assemble_xenguest_initramfs() {
xenguest_image_clone
call_xenguest_mkimage partial --xen-kernel=${B}/${KERNEL_OUTPUT_DIR}/Image.initramfs
rm -f ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest
call_xenguest_mkimage pack ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest
}
do_assemble_xenguest_initramfs[depends] += "${INITRAMFS_IMAGE}:do_merge_xenguestenv"
kernel_do_deploy:append() {
if [ -f "${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest" ]; then
install -m 0644 ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest "$deployDir/Image-${INITRAMFS_NAME}.xenguest"
ln -snf Image-${INITRAMFS_NAME}.xenguest $deployDir/Image-${INITRAMFS_LINK_NAME}.xenguest
fi
}

224
meta-arm-autonomy/classes/set_src_uri_from_var.bbclass
View File

@@ -1,224 +0,0 @@
# Set SRC_URI from Variable
# This class parses a variable named in SRC_URI_FROM_VAR_NAME for entries that
# should be added to the SRC_URI
#
# There are 4 supported formats for entries:
#
# - http/https url
# - Note that a checksum (md5sum or sha256sum) must be provided for http(s)
#
# - file:// absolute local path from root
# - In this case the filename will be added to SRC_URI and the path from '/'
# added to FILESEXTRAPATHS
#
# - file:// path relative to FILESEXTRAPATHS
# - In this case the filename will be added to SRC_URI and the preceding path
# added to FILESOVERRIDES, so that the full path to the file will
# be available in FILESPATH when it is generated by combining
# FILESEXTRAPATHS and FILESOVERRIDES.
#
# - plain absolute local path from root
# - This will be treated the same as an file:// path from root. Plain paths
# must be absolute, and cannot be relative to FILESEXTRAPATHS
#
# It is not recommended to use other yocto URL types, as they may result in
# undefined behaviour.
#
# These entries will be added to the SRC_URI so that the yocto fetcher can
# unpack a copy into ${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}
#
#
# A list of arguments can follow each entry in the input variable, seperated
# by semi-colons (;). Arguments may be FETCH arguments or MANIFEST arguments.
#
# FETCH arguments will be appended to the entry in SRC_URI, for example
# "downloadfilename" to specify the filename used when storing a
# downloaded file.
# Each SRC_URI entry will automatically have the arguments
# "unpack=0;subdir=${SRC_URI_FROM_VAR_UNPACK_DIR}" added to them, so do not
# attempt to set these options.
#
# MANIFEST arguments are defined in the variable
# SRC_URI_FROM_VAR_MANIFEST_PARAMS which should be a space seperated list of
# names, each optionally followed by an equals sign (=) and a default value.
#
# The values provided for the manifest arguments will be written to the manifest
# file in ${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR} as columns, in the same
# order as they appear in SRC_URI_FROM_VAR_MANIFEST_PARAMS.
#
# For entries that do not provide a value for a manifest argument, the default
# value will be used if possible.
# If no default is availale, omitting the parameter on any item will cause
# an error.
#
# "[basename]" is a special case default that will set the value to
# the filename without the path or file extension.
#
# e.g.
# SRC_URI_FROM_VAR_MANIFEST_PARAMS="conname=[basename] contag=local conkeep"
#
# Any arguments that follow an entry in SRC_URI_FROM_VAR_NAME, that are not
# named in SRC_URI_FROM_VAR_MANIFEST_PARAMS are assumed to be FETCH arguments,
# so are added to the corresponding entry in the SRC_URI.
SRC_URI_FROM_VAR_NAME ??= ""
SRC_URI_FROM_VAR_MANIFEST_PARAMS ??= ""
SRC_URI_FROM_VAR_UNPACK_DIR ??= "items"
python __anonymous() {
parse_var = d.getVar('SRC_URI_FROM_VAR_NAME')
if not parse_var:
return
parse_var_items = d.getVar(parse_var)
if parse_var_items:
for item in parse_var_items.split(' '):
if not item:
continue
if item.startswith('/'):
# If not a Yocto URL, must be an absolute path
yocto_url = "file://" + item
else:
# Otherwise assume valid Yocto URL.
# Error case is caught later
yocto_url = item
fetcher = host = path = parm = None
try:
# Attempt to parse a Yocto URL
fetcher,host,path,_,_,parm = bb.fetch.decodeurl(yocto_url)
except:
# Something invalid is in the variable!
raise bb.parse.SkipRecipe(parse_var + \
" contains an invalid entry:\n'" + \
item + "'")
# This var is space seperated list of parameter names,
# with optional default value following an equals sign
# (name=default)
item_params_str = d.getVar('SRC_URI_FROM_VAR_MANIFEST_PARAMS')
# remove directories from path
filename = os.path.basename(path)
if "downloadfilename" in parm:
filename = parm["downloadfilename"]
item_manifest_args = {"filename": filename}
if item_params_str:
# required manifest arguments have been provided
# If no default is given add "=" for map parsing
item_params_list = [ arg + "=" if '=' not in arg
else arg
for arg in item_params_str.split(' ')
]
# Generate key value pairs of argument names and
# default values
item_params_map = dict( (name.strip(), val.strip())
for name, val in (arg.split('=')
for arg in item_params_list)
)
for argname in item_params_map:
# Iterate over required manifest arguments
argvalue = parm.pop(argname, None)
if argvalue:
# a value has been provided for this item
item_manifest_args[argname] = argvalue
else:
# No value provided, process default value
default = item_params_map[argname]
if default:
# A default value is provided
if default == "[basename]":
# use the filename without extension
default = os.path.splitext(filename)[0]
# store default value in dict
item_manifest_args[argname] = default
else:
# No default provided
raise bb.fatal(parse_var + \
" entry is missing a required parameter '" + \
argname + "':\n'" + item + "'")
# Write value to var flags to ensure data structure is preserved
# Each entry of parse_var will have a varflag where the value
# is a dictionary of argument names and values
d.setVarFlags(parse_var, {item: item_manifest_args})
src_uri_entry_suffix = ';'
# HTTP(S) fetcher must provide a checksum
if fetcher.startswith('http') and not \
( 'md5sum' in parm or 'sha256sum' in parm ):
# Ensure http/https fetchers get a checksum
raise bb.parse.SkipRecipe(parse_var + \
" entry is missing a checksum:\n'" + \
item + "'")
# add remaining fetch parameters including checksum
for arg in parm:
src_uri_entry_suffix += ";" + arg + "=" + parm[arg]
# Add default and extra parameters to SRC_URI entry
src_uri_entry_suffix += ';unpack=0;subdir=' + \
d.getVar('SRC_URI_FROM_VAR_UNPACK_DIR')
if fetcher == 'file':
# Prevent local fetcher from re-creating dir structure
filedir = os.path.split(path)[0]
if filedir.startswith('/'):
# Path is from the root
d.appendVar('FILESEXTRAPATHS', filedir + ':')
else:
# Path is relative to FILESEXTRAPATHS
d.appendVar('FILESOVERRIDES', ':' + filedir)
# Add filename without path to SRC_URI
d.appendVar('SRC_URI', ' file://' + \
filename + src_uri_entry_suffix)
else:
# Add full entry to SRC_URI
d.appendVar('SRC_URI', ' ' + fetcher + \
"://" + host + path + src_uri_entry_suffix)
}
python generate_manifest() {
parse_var = d.getVar('SRC_URI_FROM_VAR_NAME')
if not parse_var:
return
target_dir = os.path.join(d.getVar('WORKDIR'),
d.getVar('SRC_URI_FROM_VAR_UNPACK_DIR'))
# Write a manifest file containing the parameters so SRC_URI
# doesn't need to be parsed by do_install
with open (target_dir + "/manifest", 'w') as manifest_file:
manifest_args = d.getVarFlags(parse_var)
parse_var_items = d.getVar(parse_var)
if parse_var_items:
for item in parse_var_items.split():
manifest_file.write(" ".join(manifest_args[item].values())+"\n")
}
do_unpack[cleandirs] += "${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}"
do_unpack[postfuncs] += "generate_manifest"
do_unpack[vardeps] += "${SRC_URI_FROM_VAR_NAME}"

251
meta-arm-autonomy/classes/xenguest_image.bbclass
View File

@@ -1,251 +0,0 @@
# This class must be used to create, extend or pack a xenguest image.
# It is using xenguest-mkimage tool to do operations
DEPENDS += "xenguest-mkimage-native"
#
# Xenguest image parameters
# All the following parameters can be modified in local.conf or on recipes
# inheriting this class
#
# Guest memory size in MB
XENGUEST_IMAGE_MEMORY_SIZE ??= "512"
# Guest number of vcpus
XENGUEST_IMAGE_NUM_VCPUS ??= "1"
# Guest auto boot during init, set to 1 to have guest started during init or
# to 0 if the guest should not be auto started
XENGUEST_IMAGE_AUTOBOOT ??= "1"
# Partition containing the root file system
# Xen will actually add root=${XENGUEST_IMAGE_ROOT} to your guest kernel
# command line
# You can let this empty if the root filesystem is specified in an other way
# and have root= option added to the command line for example or if you don't
# need a root filesystem mounted for your guest (initrd for example)
XENGUEST_IMAGE_ROOT ??= "/dev/xvda1"
# Guest kernel command line arguments
XENGUEST_IMAGE_CMDLINE ??= "earlyprintk=xenboot console=hvc0 rw"
# Extra commands to add to xenguest_image when creating the image
XENGUEST_IMAGE_EXTRA_CMD ??= ""
# Kernel binary
# This value is used by the xenguest image type but is declared here to have
# all variables in the same place
# If this value is empty no kernel will be added to the image
XENGUEST_IMAGE_KERNEL ??= "Image"
# Size of the disk to create (if 0 no disk will be created and rootfs will not
# be included in the xenguest image)
XENGUEST_IMAGE_DISK_SIZE ??= "${@ '4' if not d.getVar('INITRAMFS_IMAGE') else '0'}"
# set empty partition to be used by xenguest-manager for this image
XENGUEST_IMAGE_DISK_DEVICE ??= ""
#
# XENGUEST_IMAGE_DISK_PARTITIONS is used to describe the partitions to setup
# and their content.
# It must be set to a space separated list of entries with each entry having
# the format num:sz:[fs]:[file] where:
# - num is a partition number
# - sz is the partition size in MB or GB(default), e.g 1000M or 1[G]
# - fs is optional filesystem to use for the partition
# - file is optionally pointing to a file to use as content of the partition
# Please check image_types_xenguest.bbclass for rootfs handling of files
#
# Default value creates a partition 1 using the full disk, formated with ext4
# and containing the root filesystem produced by Yocto
XENGUEST_IMAGE_DISK_PARTITIONS ??= "1:${XENGUEST_IMAGE_DISK_SIZE}:ext4:rootfs.tar.gz"
# XENGUEST_IMAGE_NETWORK_TYPE can be set to "bridge", "nat" or "none".
# The "bridge" type will share the physical eth interface from dom0 with the
# domU. This will allow the domU to have access to the external network.
# The "nat" type will setup a virtual network between dom0 and domU and also
# configure and run the kea dhcp4 server on dom0 to serve the domU.
# The "none" type will not affect any networking setting between on dom0 and
# domU.
XENGUEST_IMAGE_NETWORK_TYPE ??= "bridge"
# Sub-directory in wich the guest is created. This is create in deploy as a
# subdirectory and must be coherent between all components using this class so
# it must only be modified from local.conf if needed
XENGUEST_IMAGE_DEPLOY_SUBDIR ?= "xenguest"
# Directory in which the xenguest should be deployed
# a sub-directory named ${XENGUEST_IMAGE_DEPLOY_SUBDIR} will be created there.
# This should be set to:
# - ${DEPLOYDIR} (default) if creating or extending the xenguest for a normal
# recipe.
# - something in ${WORKDIR} if you need to clone and manipulate an image
XENGUEST_IMAGE_DEPLOY_DIR ??= "${DEPLOYDIR}"
# These vars are used by image_types_xenguest.bbclass to generate the
# xenguest.env file. In a recipe that inherits this class and extra variables
# that should be included in xenguest.env need to be added to
# XENGUEST_IMAGE_VARS_EXTRA
XENGUEST_IMAGE_VARS ?= "\
MACHINE DISTRO DISTRO_VERSION DISTRO_FEATURES TUNE_FEATURES TARGET_FPU \
IMAGE_FEATURES INITRAMFS_IMAGE_BUNDLE INITRAMFS_IMAGE \
XENGUEST_IMAGE_MEMORY_SIZE XENGUEST_IMAGE_NUM_VCPUS XENGUEST_IMAGE_AUTOBOOT \
XENGUEST_IMAGE_ROOT XENGUEST_IMAGE_CMDLINE XENGUEST_IMAGE_EXTRA_CMD \
XENGUEST_IMAGE_KERNEL XENGUEST_IMAGE_DISK_SIZE XENGUEST_IMAGE_DISK_DEVICE \
XENGUEST_IMAGE_DISK_PARTITIONS XENGUEST_IMAGE_NETWORK_TYPE"
#
# Wrapper to call xenguest-mkimage
# It is using XENGUEST_IMAGE_DEPLOY_DIR and XENGUEST_IMAGE_DEPLOY_SUBDIR
# to find the image to operate on
#
# Usage: call_xenguest_mkimage [operation] [args]
call_xenguest_mkimage() {
local cmd="${1}"
local img="${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}"
shift
echo "xenguest-mkimage $cmd $img $@"
xenguest-mkimage $cmd $img $@
}
#
# Create an initial xenguest image.
# This is a task which must be added in a recipe inheriting deploy
# It is using XENGUEST_IMAGE_MEMORY_SIZE, XENGUEST_IMAGE_NUM_VCPUS,
# XENGUEST_IMAGE_AUTOBOOT, XENGUEST_IMAGE_ROOT, XENGUEST_IMAGE_EXTRA_CMD,
# XENGUEST_IMAGE_CMDLINE, XENGUEST_IMAGE_DISK_SIZE and
# XENGUEST_IMAGE_DISK_PARTITIONS to customize the initial guest
#
xenguest_image_create() {
if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
-z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
fi
rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
# Create the image
call_xenguest_mkimage create --xen-memory=${XENGUEST_IMAGE_MEMORY_SIZE} \
--xen-vcpus=${XENGUEST_IMAGE_NUM_VCPUS} \
--xen-root=${XENGUEST_IMAGE_ROOT} \
${XENGUEST_IMAGE_EXTRA_CMD}
# add command line
if [ -n "${XENGUEST_IMAGE_CMDLINE}" ]; then
call_xenguest_mkimage update --xen-clean-extra
for arg in ${XENGUEST_IMAGE_CMDLINE}; do
call_xenguest_mkimage update --xen-extra=$arg
done
fi
# create disk if needed
disksize="${XENGUEST_IMAGE_DISK_SIZE}"
case ${disksize:=0} in
0|0M|0G)
;;
*)
# setup disk size
call_xenguest_mkimage update --disk-reset-config --disk-size=$disksize
diskparts="${XENGUEST_IMAGE_DISK_PARTITIONS}"
if [ -n "$diskparts" ]; then
for arg in $diskparts; do
call_xenguest_mkimage update --disk-add-part=$arg
done
fi
diskdevice="${XENGUEST_IMAGE_DISK_DEVICE}"
if [ -n "$diskdevice" ]; then
call_xenguest_mkimage update --disk-device="${diskdevice}"
fi
;;
esac
if [ "${XENGUEST_IMAGE_AUTOBOOT}" = "1" ]; then
call_xenguest_mkimage update --set-param=GUEST_AUTOBOOT=1
else
call_xenguest_mkimage update --set-param=GUEST_AUTOBOOT=0
fi
if [ -n "${XENGUEST_IMAGE_NETWORK_TYPE}" ]; then
call_xenguest_mkimage update --set-param=XENGUEST_NETWORK_TYPE="${XENGUEST_IMAGE_NETWORK_TYPE}"
else
call_xenguest_mkimage update --set-param=XENGUEST_NETWORK_TYPE="none"
fi
}
XENGUEST_ENV_STAGING_DIR ??= "${STAGING_DIR}/${MACHINE}/xenguestenv"
# Create an intermediary file containing all variables used to by a
# particular recipe that inherits this class
# File will contain the values of all variables listed in:
# XENGUEST_IMAGE_VARS_EXTRA
python do_deploy_xenguestenv () {
xenguest_vars = d.getVar('XENGUEST_IMAGE_VARS_EXTRA')
if not xenguest_vars:
return
outdir = d.getVar('XENGUEST_ENV_STAGING_DIR')
# Writes file to tmp/sysroots/${MACHINE}/xenguestenv/ by default
filename = os.path.basename(d.getVar('FILE')) + '.xenguestenv'
with open(os.path.join(outdir, filename), 'w') as envf:
for var in xenguest_vars.split():
value = d.getVar(var)
if value:
# Write value only if set
envf.write('%s="%s"\n' % (var, " ".join(value.split())))
envf.close()
}
# Since the intermediary file is deleted by do_merge_xenguestenv it
# must be re-created every time
do_deploy_xenguestenv[vardeps] += "${XENGUEST_IMAGE_VARS_EXTRA}"
do_deploy_xenguestenv[dirs] = "${XENGUEST_ENV_STAGING_DIR}"
addtask deploy_xenguestenv before do_populate_sysroot
# Clone the current xenguest from deploy to manipulate it locally
# This is required if you need to change things before packing an image
# To set the local directory where to clone you must set
# XENGUEST_IMAGE_DEPLOY_DIR if you don't want to use do_deploy to modify the
# image
#
xenguest_image_clone() {
if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
-z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
fi
if [ ! -f ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}/guest.cfg ]; then
die "xenguest_image: ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR} does not contain a valid guest"
fi
rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}
cp -rf ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR} \
${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
}
# Helper function to retrieve rootfs file if present in one partition
# This can return an empty string or rootfs.tar[.COMP]
def xenguest_image_rootfs_file(d):
disksize = d.getVar('XENGUEST_IMAGE_DISK_SIZE')
# if disksize is 0, we don't create anything
if not disksize or disksize == '0':
return ""
# Find first partition with file=rootfs.tar*
partlist = d.getVar('XENGUEST_IMAGE_DISK_PARTITIONS')
if partlist:
for partdesc in partlist.split():
partelems = partdesc.split(':', 3)
if partelems[3]:
if partelems[3].startswith('rootfs.tar'):
return partelems[3]
return ""

123
meta-arm-autonomy/classes/xenguest_image_extra.bbclass
View File

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

15
meta-arm-autonomy/conf/distro/include/arm-autonomy-guest.inc
View File

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

23
meta-arm-autonomy/conf/distro/include/arm-autonomy-host.inc
View File

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

39
meta-arm-autonomy/conf/layer.conf
View File

@@ -1,39 +0,0 @@
# Add layer to BBPATH
BBPATH .= ":${LAYERDIR}"
# Add recipes-* directories to BBFILES
BBFILES += " \
${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend \
"
BBFILE_COLLECTIONS += "meta-arm-autonomy"
BBFILE_PATTERN_meta-arm-autonomy = "^${LAYERDIR}/"
BBFILE_PRIORITY_meta-arm-autonomy = "5"
LAYERDEPENDS_meta-arm-autonomy = " \
core \
yocto \
openembedded-layer \
networking-layer \
virtualization-layer \
"
LAYERSERIES_COMPAT_meta-arm-autonomy = "honister"
# We don't activate virtualization feature from meta-virtualization as it
# brings in lots of stuff we don't need. We need to disable the sanity check
# otherwise the user will see a warning on each build.
SKIP_META_VIRT_SANITY_CHECK = "1"
ARM_AUTONOMY_LAYERDIR := "${LAYERDIR}"
# Directory of our distro config files
ARM_AUTONOMY_DISTRO_CFGDIR = "${ARM_AUTONOMY_LAYERDIR}/conf/distro/include/"
# Add class to handle arm-autonomy distro extensions
USER_CLASSES:append = " arm-autonomy-features"
BBFILES_DYNAMIC += " \
meta-arm-bsp:${LAYERDIR}/dynamic-layers/meta-arm-bsp/*/*/*.bbappend \
meta-arm-bsp:${LAYERDIR}/dynamic-layers/meta-arm-bsp/*/*/*.bb \
"
# Root directory for the meta-arm-autonomy/dynamic-layers/meta-arm-bsp
ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR = "${ARM_AUTONOMY_LAYERDIR}/dynamic-layers/meta-arm-bsp"

17
meta-arm-autonomy/conf/machine/arm64-autonomy-guest.conf
View File

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

5
meta-arm-autonomy/conf/xenguest.conf
View File

@@ -1,5 +0,0 @@
# This file will be required by different xenguest recipes to provide
# common variables, which can be configured in local.conf
# Xenguest image file install location
XENGUEST_MANAGER_GUEST_DIR ?= "${datadir}/guests/"

226
meta-arm-autonomy/documentation/arm-autonomy-multiconfig.md
View File

@@ -1,226 +0,0 @@
arm-autonomy Multiconfig Build Environment Instructions
==================
This documentation explains how to simplify the process of building hosts
and guests in a single bitbake command, rather than in seperate build
folders. You can read more about multiconfig in the bitbake documentation:
- [bitbake user manual](https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html)
To achieve a multiconfig build, a number of different config files need to
be created in a single build directory.
Create a new project
----------------
Before you start, you will need to follow the instructions in
"Create a project" from the quickstart guide, to create a new project
directory with
```
oe-init-build-env my-mc-project
```
Ensure it has all the required layers in bblayers.conf as listed in
`arm-autonomy-quickstart.md`. The result should be a directory containing:
```
-- conf
| -- bblayers.conf
| -- local.conf
| -- templateconf.cfg
```
Add multiconfig
----------------
The steps required to make the project build both the host and any
number of guests as required are:
1. Create a new directory under `conf/` named `multiconfig/`
2. Create two new files in this directory:
`multiconfig/host.conf`
`multiconfig/guest.conf`
These files will contain any configurations that are specific to either the
host or the guest. The resulting directory tree should be:
```
-- conf
| -- bblayers.conf
| -- local.conf
| -- templateconf.cfg
| -- multiconfig
| -- host.conf
| -- guest.conf
```
3. In `local.conf` the following config variables must be added:
```
MACHINE ?= "fvp-base"
# ---Guest Config Start--- #
MC_GUEST = "guest"
MC_GUEST_NAME = "guest1"
MC_GUEST_IMAGERECIPE = "core-image-minimal"
MC_GUEST_MACHINE = "arm64-autonomy-guest"
MC_GUEST_INITRAMFS_IMAGE_BUNDLE ?= ""
MC_GUEST_INITRAMFS_IMAGE ?= ""
# Uncomment for initramfs
#MC_GUEST_INITRAMFS_IMAGE_BUNDLE = "1"
#MC_GUEST_INITRAMFS_IMAGE = "${MC_GUEST_IMAGERECIPE}"
# These variables are set automatically, don't override them!
MC_GUEST_FILENAME_PREFIX = "${@ 'Image-initramfs' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else '${MC_GUEST_IMAGERECIPE}' }"
MC_GUEST_FILENAME = "${MC_GUEST_FILENAME_PREFIX}-${MC_GUEST_MACHINE}.xenguest"
MC_GUEST_DEP = "${@ 'virtual/kernel:do_deploy' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else '${MC_GUEST_IMAGERECIPE}:do_merge_xenguestenv'}"
MC_DOIMAGE_MCDEPENDS += "mc:${MC_HOST}:${MC_GUEST}:${MC_GUEST_DEP} "
BBMULTICONFIG += "${MC_GUEST} "
ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS += "file://${TOPDIR}/${MC_GUEST}/deploy/images/${MC_GUEST_MACHINE}/${MC_GUEST_FILENAME};guestname=${MC_GUEST_NAME} "
# ---Guest Config End--- #
# ---Host Config Start--- #
MC_HOST = "host"
BBMULTICONFIG += "${MC_HOST} "
# ---Host Config End--- #
```
These variables will be used in both of the multiconf files. `MC_HOST` and
`MC_GUEST` should not be altered without renaming the conf files, but most
`MC_GUEST_*` variables can be customised if you desire.
4. Next set the contents of `multiconfig/guest.conf`:
```
TMPDIR = "${TOPDIR}/${MC_GUEST}"
MACHINE = "${MC_GUEST_MACHINE}"
DISTRO_FEATURES += " arm-autonomy-guest"
INITRAMFS_IMAGE_BUNDLE = "${MC_GUEST_INITRAMFS_IMAGE_BUNDLE}"
INITRAMFS_IMAGE = "${MC_GUEST_INITRAMFS_IMAGE}"
IMAGE_FSTYPES += "${@ 'cpio' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else ''}"
# ANY OTHER GUEST CONFIG
```
To modify the MACHINE or INITRAMFS variables change the equivalent
config in local.conf rather than modifying this file directly. You can also
append any other config desired for the guest after "ANY OTHER GUEST CONFIG",
for example `XENGUEST_IMAGE_DISK_SIZE`.
Make sure not to change `${DEPLOY_DIR_IMAGE}` to anything other than
`${TMPDIR}/deploy/images`, as this is assumed by local.conf.
5. Lastly set the contents of `multiconfig/host.conf`:
```
TMPDIR = "${TOPDIR}/${MC_HOST}"
DISTRO_FEATURES += " arm-autonomy-host"
# ANY OTHER HOST CONFIG
```
Building the image
----------------
To build the multiconfig image the command is:
```
bitbake mc:host:arm-autonomy-host-image-minimal
```
The first time this is run you may see a warning related to the SRC_URI:
```
Unable to get checksum for xenguest-extern-guests SRC_URI entry foo.xenguest: file could not be found
```
This is expected, and only indicates that the guest image has not yet been
generated when the host parses the SRC_URI. By the time it is needed by the
host recipe fetch task it will be present.
During the build you should see that guest tasks are also being executed in
parallel. Once the build completes the guest will already be in the rootfs of
the host thanks to `ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUEST`
The final host image including the guests will be deployed in
`host/deploy/images/`
Multiple Guests
----------------
To have multiple guests with the same config the line which appends to
`ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS` just needs to pass the argument
'guestcount=#' to install symlink copies of the xenguest file on the host.
Documentation for the guestcount parameter can be found in
documentation/arm-autonomy-quickstart.md in the section titled
'Include guests directly in the host image'. This will ensure that the guest
is still only built once, despite resulting in multiple copies on the target.
If guests are required to have different configurations, each will need its own
config file, e.g. 'netguest.conf'. Ensure that the name of the conf file does
not contain any hyphens, as this will create errors when it becomes part of a
function name. In this file the values of TMPDIR, MACHINE, DISTRO_FEATURES etc.
should be the same as above, but with the prefix "MC_GUEST_*" modified to
something different to avoid collisions (e.g. MC_GUEST_2_*).
As before, your additional config for the guest type should
follow "ANY OTHER GUEST CONFIG"
In your local.conf, everything between `---Guest Config Start---` and
`---Guest Config End---` will need to be duplicated for each desired guest type.
All copies of variables that start `MC_GUEST` must be modified with the same
prefix as in the new guest config file (e.g. `MC_GUEST_2_*`).
Each chunk of guest config in local.conf has automatic guest variables
(found after the line "These variables are set automatically...").
These should all use the same prefix as their chunk in their values,
for example:
```
MC_GUEST_2_FILENAME_PREFIX = "${@ 'Image-initramfs' if d.getVar('MC_GUEST_2_INITRAMFS_IMAGE_BUNDLE',d) else '${MC_GUEST_2_IMAGERECIPE}' }"
```
Guest with provisioned disk
----------------
To add guest rootfs partition to host wic image,
set `AUTONOMY_HOST_EXTRA_PARTITION` with proper wks partition entry, e.g:
```
AUTONOMY_HOST_EXTRA_PARTITION = "part --label provisioned-guest --source rawcopy --fstype=ext4 --ondisk sda --align 1024 \
--sourceparams=file=${TOPDIR}/${MC_GUEST}/deploy/images/${MC_GUEST_MACHINE}/${MC_GUEST_FILENAME_PREFIX}-${MC_GUEST_MACHINE}.ext4"
```
inside your host.conf file.
The rest of the configuration has to be appended to guest.conf file:
```
# ANY OTHER GUEST CONFIG
XENGUEST_IMAGE_DISK_SIZE = "0"
XENGUEST_IMAGE_SRC_URI_XEN_CONFIG = "file://\${TOPDIR}/path/to/rootdisk.cfg"
XENGUEST_IMAGE_DISK_DEVICE = "_GUEST_DISK_DEVICE_"
XENGUEST_IMAGE_ROOT = "/dev/xvda"
IMAGE_ROOTFS_SIZE = "102400"
IMAGE_FSTYPES = "ext4"
```
Example content of rootdisk.cfg:
```
disk = ["phy:_GUEST_DISK_DEVICE_,xvda,w"]
```
`_GUEST_DISK_DEVICE_` should be substituted with `/dev/sdaX`,
according to wks file.

272
meta-arm-autonomy/documentation/arm-autonomy-quickstart.md
View File

@@ -1,272 +0,0 @@
arm-autonomy Quick Start
==================
This documentation explains how to quickly start with the arm-autonomy layer,
and the main features provided.
In the documentation directory you will find some more detailed documentation
for each of the functionalites provided by this layer.
What to use this layer for?
---------------------------
Using this layer, you can easily and rapidly create a system based on Xen with
one or more guests created using Yocto.
For this you will need to create at least 2 Yocto projects:
- a host project: This one will compile Xen and create a Linux system to be
used as Xen Dom0. The Linux system will contain all functionalities required
to start and manage guests.
- one or several guest projects: Those will create Linux systems with the
required Linux kernel configuration to run as Xen DomU.
Prepare your system
-------------------
First you must download the Yocto layers needed:
- [meta-openembedded](https://git.openembedded.org/meta-openembedded)
- [poky](https://git.yoctoproject.org/poky)
- [meta-virtualization](https://git.yoctoproject.org/meta-virtualization)
- [meta-arm](https://git.yoctoproject.org/meta-arm)
- all other layers you might want to use
For each of the downloaded layer make sure you checkout the release of Yocto
you want to use (for example honister using `git checkout honister`).
Please follow [Yocto documentation](https://www.yoctoproject.org/docs/latest/brief-yoctoprojectqs/brief-yoctoprojectqs.html)
in order to have the required dependencies.
Create a project
----------------
Here are the main steps to create an arm-autonomy project:
1. create a new Yocto project using `oe-init-build-env` in a new directory:
```
oe-init-build-env my-project
```
2. Add `meta-arm/meta-arm-autonomy` layer to the list of layers of your
project in the `conf/bblayers.conf`. Also add any other layers you
might need (for example `meta-arm/meta-arm-bsp` and `meta-arm/meta-arm` to
use Arm boards like Juno or FVP emulator). You can achieve this by using
the `bitbake-layers add-layer layerdir [layerdir ...]` command.
For example:
```
export LAYERDIR_BASE="/home/user/arm-autonomy/"
bitbake-layers add-layer $LAYERDIR_BASE/meta-poky $LAYERDIR_BASE/meta-yocto-bsp \
$LAYERDIR_BASE/meta-openembedded/meta-oe $LAYERDIR_BASE/meta-openembedded/meta-python \
$LAYERDIR_BASE/meta-openembedded/meta-filesystems $LAYERDIR_BASE/meta-openembedded/meta-networking \
$LAYERDIR_BASE/meta-arm/meta-arm $LAYERDIR_BASE/meta-arm/meta-arm-toolchain \
$LAYERDIR_BASE/meta-arm/meta-arm-bsp $LAYERDIR_BASE/meta-arm/meta-arm-autonomy \
```
Example of a `conf/bblayers.conf`:
```
BBLAYERS ?= " \
/home/user/arm-autonomy/poky/meta \
/home/user/arm-autonomy/poky/meta-poky \
/home/user/arm-autonomy/poky/meta-yocto-bsp \
/home/user/arm-autonomy/meta-openembedded/meta-oe \
/home/user/arm-autonomy/meta-openembedded/meta-python \
/home/user/arm-autonomy/meta-openembedded/meta-filesystems \
/home/user/arm-autonomy/meta-openembedded/meta-networking \
/home/user/arm-autonomy/meta-virtualization \
/home/user/arm-autonomy/meta-arm/meta-arm \
/home/user/arm-autonomy/meta-arm/meta-arm-toolchain \
/home/user/arm-autonomy/meta-arm/meta-arm-bsp \
/home/user/arm-autonomy/meta-arm/meta-arm-autonomy \
"
```
Be aware that changing the order may break some dependencies if editing the
config file manually.
Those steps will have to be done for each project you will have to create.
Host project
------------
The host project will build Xen and the Dom0 Linux. It will be the only project
that will be specific to the board (MACHINE) you will be running on.
To create a host project:
1. Follow the steps of "Create a project"
2. Add the layers in `bblayers.conf` required to build a Yocto project for the
board you want to use.
For example to use Arm FVP Base emulator, add `meta-arm/meta-arm` and
`meta-arm/meta-arm-bsp`.
3. edit conf/local.conf to add `arm-autonomy-host` to the DISTRO_FEATURES and
set MACHINE to the board you want to use.
For example, add the following lines:
```
MACHINE = "fvp-base"
DISTRO_FEATURES += "arm-autonomy-host"
```
4. build the image using `bitbake arm-autonomy-host-image-minimal`
The project will generate a Linux kernel, a root filesystem, a Xen binary and
a DTB modified to include the required entries to boot Xen and Linux as Dom0
(this DTB has the extension `-xen.dtb`).
To boot the system using a u-boot base board for machines other than FVP-Base
you will need to:
- Load the kernel (by default at 0x80080000 unless you modify
XEN_DEVICETREE_DOM0_ADDR value)
- Load the xen device tree (for example at 0x83000000)
- Load the xen-efi binary (for example at 0x84000000)
- run using `booti 0x84000000 - 0x83000000`
In this example the addresses might need to be adapted depending on your board.
For arm-autonomy host on FVP-Base, u-boot has been modified such that
`booti 0x84000000 - 0x83000000` is the default boot command. If FVP-Base is your
MACHINE target there should be no need to interfere with u-boot.
Guest project
-------------
The guest projects are not target specific and will instead use a Yocto MACHINE
defined in meta-arm-autonomy to include only the Linux configuration required to
run a xen guest.
To create a guest project:
1. Follow the steps of "Create a project"
2. Optionally add layers required to build the guest image, and any features you
need.
3. Edit conf/local.conf to add `arm-autonomy-guest` to the DISTRO_FEATURES and
set MACHINE to `arm64-autonomy-guest`:
```
MACHINE = "arm64-autonomy-guest"
DISTRO_FEATURES += "arm-autonomy-guest"
```
4. Build the image you want.
For example `bitbake core-image-minimal`
The build will create a ".xenguest" image that can be use on an host project
with the xenguest-manager, as well as a file "xenguest.env" containing the
variables used to configure and generate the guest image.
The guest can also be built as a 'multiconfig' sub project of the host, see
`meta-arm-autonomy/documentation/arm-autonomy-multiconfig.md` for more
information
Include guests directly in the host image
-----------------------------------------
The layer provides a way to directly include one or more images generated by
guest projects in the host project.
To use this feature, you must edit your host project `local.conf` file and
add set the value of 'ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS' to the list of
paths to xenguest images you want to include in your host.
There are 4 supported formats for ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS
entries:
- http/https url
- "https://[url]:[port]/foo.xenguest;md5sum=..."
- file:// absolute local path from root
- "file:///xenguests/bar.xenguest"
- file:// path relative to FILESEXTRAPATHS
- "file://relative/baz.xenguest"
- plain absolute local path from root
- "/xenguests/absolute/xyzzy.xenguest"
It is not recommended to use other bitbake URL types, as they may result in
undefined behaviour.
A semicolon seperated list of install arguments can follow each image path:
- guestname : the name that will be attached when the image is imported
(default: [filename, without extension])
- guestcount : the number of copies of the guest to install, with
incrementing numbers appended to the name
(default: 1)
Any other arguments, for example an md5sum, will be assumed to be fetch
arguments, and will be appended to the path in the SRC_URI.
For example:
```
ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS = "\
https://[url]:[port]/base.xenguest;md5sum=[checksum];guestname=http \
file:///guests/base.xenguest;guestname=file_abs \
file://foo/base.xenguest;guestname=file_rel;guestcount=2 \
/guests/foo/bar/base.xenguest;guestname=no_fetcher \ "
```
Documentation for setting up a multiconfig build can be found in:
meta-arm-autonomy/documentation/arm-autonomy-multiconfig.md
Add support for your board
--------------------------
Most of arm-autonomy layer is board independent but some functionalities
might need to be customized for your board:
### Add the kernel configuration for the host
The layer is using KERNEL_FEATURES to add drivers required to be a Xen Dom0
system.
Depending on the kernel used by your BSP and how it is configured you might
need to add the required drivers to your kernel configuration:
- if KERNEL_FEATURES system is supported by your kernel, make sure that the
file `recipes-kernel/linux/linux-arm-autonomy.inc` from the layer is included
by your kernel recipe.
- if it is not supported, you must add the proper drivers inside your kernel
(modules are possible but they must be loaded before xenguest-manager is
started). You can find the complete list of the kernel configuration elements
required in `recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-host.cfg`.
### Define the drive and partition to use for the LVM volume
The xenguest-manager creates guest storage drives using LVM on an empty
partition. The default value is set to use /dev/sda2.
You can change this for your board by setting XENGUEST_MANAGER_VOLUME_DEVICE.
Check `recipes-extended/xenguest/xenguest-manager.bbappend` for examples.
Please also read xenguest-manager.md.
### Define the interface to add to xenguest network bridge
xenguest-network bridge creates a bridge on the host and adds network
interfaces to it so that guests connected to it have access to external network.
By default `eth0` is set as the list of interfaces to be added to the bridge.
Depending on your board or use case you might want to use an other interface
or use multiple interfaces.
You can change this for your board by setting XENGUEST_NETWORK_BRIDGE_MEMBERS.
Check `recipes-extended/xenguest/xenguest-network.bbappend` for
exmaples.
Please also read xenguest-network-bridge.md.
### Define the network configuration of the xenguest network bridge
xenguest-network puts the host network interfaces in a bridge and configures it
by default to use dhcp.
If you need a different type of configuration you can set
XENGUEST_NETWORK_BRIDGE_CONFIG in your xenguest-network-bridge.bbappend to use
a different file.
The recipe will look for the file in ${WORKDIR}, so you will need to add it to
the SRC_URI in your bbappend.
The recipe will also substitute `###BRIDGE_NAME###` with the bridge name
configured in ${XENGUEST_NETWORK_BRIDGE_NAME} when the config file is installed.
You can find an example configuration file in
`recipes-extended/xenguest/files/xenguest-network-bridge-dhcp.cfg.in`.
Please also read xenguest-network.md.
### Customize Dom0 and Xen boot arguments for you board
xen-devicetree modifies the generated DTB Xen and Linux boot arguments,
as long as the address where Dom0 Linux kernel can be found.
You might need to have different values for your board or depending on your
use case.
You can find examples to customize this in
`recipes-extended/xen-devicetree/xen-devicetree.bbappend`.
Please also read xen-devicetree.md.

34
meta-arm-autonomy/documentation/n1sdp-image-customization.md
View File

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

110
meta-arm-autonomy/documentation/xen-devicetree.md
View File

@@ -1,110 +0,0 @@
Xen device tree
===============
Introduction
------------
xen-devicetree recipe can be used to modify an existing Device Tree Blob,
produced by Linux kernel or another recipe, to include in it entries required
to start Xen and a Dom0 Linux on top of it.
The recipe will do the following processing:
- generate a xen.dtsi file with entries required for xen based on parameters
- turn DTBs in ${XEN_DEVICETREE_DTBS} back to dts
- include in xen.dtsi and all other dtsi from
${XEN_DEVICETREE_DTSI_MERGE} (check Bitbake parameters for more information
on this).
- use dtc to create a new DTB file
The recipe will generate new files in deploy/images and name them with the
extension "-xen.dtb".
For example **machine.dtb** will generate **machine-xen.dtb**.
Entries added to the DTBs
-------------------------
When a DTB is processed by the recipe, the following block is added:
```
chosen {
xen,dom0-bootargs = "VAL";
xen,xen-bootargs = "VAL";
modules {
#size-cells = <0x00000001>;
#address-cells = <0x00000001>;
module@0 {
reg = <VAL VAL>;
compatible = "multiboot,module";
};
};
};
```
Each occurence of **VAL** is replaced by the content of the variables listed in
this documentation.
Bitbake parameters
------------------
Several parameters are available to configure the xen-devicetree during Yocto
project compilation (those can be set in your project local.conf, for exmple).
The following parameters are available:
- XEN_DEVICETREE_DEPEND: This variable can be used to indicate which recipe
task is generating the DTBs that xen-devicetree will modify. This makes sure
the xen devicetrees are properly regenerated if the source DTBs are changed.
This variable is set by default to "virtual/kernel:do_deploy" to use DTBs
generated during the compilation of the Linux kernel. This must be changed
if the machine you are using is not using a DTB listed in
KERNEL_DEVICETREE.
- XEN_DEVICETREE_DTBS: This should be set to the list of DTBs you want to be
modified by xen-devicetree. Those must be files that xen-devicetree can find
in the ${DEPLOY_DIR_IMAGE} directory using only the basename of the entries.
For example "mydir/board.dtb" will make the recipe look for
${DEPLOY_DIR_IMAGE}/board.dtb.
This variable is set by default to "${KERNEL_DEVICETREE}" to process the DTBs
generated by the Linux kernel.
- XEN_DEVICETREE_DOM0_MEM: Memory size to allocate to Dom0.
This variable is only used if XEN_DEVICETREE_XEN_BOOTARGS has a value
containing "dom0_mem=${XEN_DEVICETREE_DOM0_MEM}" as the memory assigned to
dom0 is defined using Xen boot arguments.
This variable is set by default to "1024M,max:1024", and cannot be empty.
The value can simply specify a size, e.g. "1024M", but best practice is to
also provide a max, documented here:
https://wiki.xenproject.org/wiki/Xen_Project_Best_Practices
- XEN_DEVICETREE_DOM0_BOOTARGS: Boot arguments to pass to Dom0 Linux when
booting it.
This variable is set by default to "console=hvc0 earlycon=xen".
- XEN_DEVICETREE_XEN_BOOTARGS: this variable should be set with the boot
arguments to be passed to Xen on boot.
This variable is set by default to
"noreboot dom0_mem=${XEN_DEVICETREE_DOM0_MEM}".
- XEN_DEVICETREE_DOM0_ADDR: This is the address from which the Linux kernel to
be used for Dom0 will be copied. When using u-boot, this is the address at
which you will load the kernel Image before starting Xen.
This variable is set by default to "0x80080000", and cannot be empty.
Values for this variable can be in hex (prefixed with '0x') or in decimal.
- XEN_DEVICETREE_DOM0_SIZE: This is the size of the kernel loaded at
${XEN_DEVICETREE_DOM0_ADDR}. Xen will copy this amount of data inside the
guest before starting it so the size must be at least equal to the kernel
size but can be bigger. You must be careful not to have a value too big as it
could slow down boot or copy other parts with it (like the DTB).
You might need to increase this if you use a kernel with a bundled initramfs.
This variable is set by default to "0x01000000" and cannot be empty.
Values for this variable can be in hex (prefixed with '0x') or in decimal.
- XEN_DEVICETREE_DTSI_MERGE: This variable contains the list of dtsi files that
must be included inside the generated DTB file. By default the only one
include is the "xen.dtsi" generated by the recipe.
If your board or project needs to include more fixes or entries in the DTB,
this variable can be appended from a bbappend file to include other dtsi. The
files must be inside the recipe workspace during Yocto compilation.
You can check xen-devicetree.bbappend for an example.

144
meta-arm-autonomy/documentation/xenguest-manager.md
View File

@@ -1,144 +0,0 @@
Xenguest Manager
================
Introduction
------------
xenguest-manager is a tool to manage Xenguest images generated by
[xenguest-mkimage](xenguest-mkimage.md).
On a Xen Dom0 system it can:
- create a xen guest from a xenguest image: extract its components, create a
disk for the guest using LVM volumes.
- start/stop a xen guest (during init or using xenguest-manager directly).
- check guest status
xenguest-manager is composed of 2 shell scripts:
- xenguest-manager which can be used from command line to start/stop/check
guests and create or remove guest using xenguest images.
- xenguest-init which is called during init to automatically create and start
some guests as part of the host init process.
Usage
-----
xenguest-manager must be called like this:
`xenguest-manager [-v(v)] OPERATION [OPTIONS]`
The following operations are available:
- create XENGUEST_IMAGE [GUESTNAME]: create a guest from a xenguest image file
as guest GUESTNAME. If GUESTNAME is not given the image file name is used
without the xenguest extension.
- remove GUESTNAME: remove the guest GUESTNAME.
- start GUESTNAME: start the guest GUESTNAME.
- stop GUESTNAME: stop the guest GUESTNAME (this is using `xl stop` which is
sending a stop signal to the running guest).
- kill GUESTNAME: force stopping the guest GUESTNAME.
- list: list the available guests.
- status [GUESTNAME]: print the current status of GUESTNAME. If GUESTNAME is
not given, print the status of all guests.
Passing -v or -vv will increase the logging written to the logfile.
The terminal will always show only error messages, regardless of the logfile.
For a detailed help on available options please use:
`xenguest-manager --help`
Bitbake parameters
------------------
Several parameters are available to configure the xenguest manager during Yocto
project compilation (those can be set in your project local.conf, for example).
This config will be written to a file xenguest-manager.conf in /etc/xenguest/.
The following parameters are available:
- XENGUEST_MANAGER_VOLUME_DEVICE: This is the device path used by the
xenguest-manager on the device to create LVM disks when guests have a disk
configuration.
This is set by default to "/dev/sda2".
- XENGUEST_MANAGER_VOLUME_NAME: This is the LVM volume name that the
xenguest-manager will create and use to create guest LVM disks.
This is set by default to "vg-xen".
- XENGUEST_MANAGER_GUEST_DIR: This is the directory on Dom0 where the
xenguest-manager will look for xenguest images to create during init. That's
the place where xenguest images can be added to have them automatically
created during next Dom0 boot. The xenguests found there will only be created
if they were not already before (the basename of the files is used as guest
name).
This is set by default to "/usr/share/guests".
- XENGUEST_MANAGER_LOG_LEVEL: Set the default log level for xenguest manager.
Must be one of ERROR, INFO, VERBOSE (default: ERROR). The logs will be
written to /var/log/xenguest.
If a verbosity argument (-v or -vv) is passed to xenguest-manager directly, it
will override the setting in xenguest-manager.conf
Since /var/log is by default a volatile location, extra configuration is
required if logs are desired to be kept between reboots:
VOLATILE_LOG_DIR="no"
Read more here: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-VOLATILE_LOG_DIR
When this is enabled, logrotate will monitor the file to ensure it does not
grow excessively large. See recipes-extended/xenguest/files/logrotate-xenguest
Init scripts
------------
Shell scripts can be executed on the host when a guest is started. Depending on
when the script should be executed it should be installed in a different
directory on the target:
- /etc/xenguest/init.pre : Executed first, prior to guest creation
- /etc/xenguest/init.d : Executed after guest creation, but before it is started
- /etc/xenguest/init.post : Executed after starting the guest
Inside the directory, scripts will be executed in alphabetical order.
Since these scripts are sourced by xenguest-manager, they can acccess functions
and variables from the parent file's scope, including:
- ${guestname} : The name of the guest being created
- ${guestdir} : The path to the guest directory
- ${guestcfgfile} : The name of the config file for the starting guest
- log() : Used to write a log to the logfile, default level INFO.
Takes an optional log level and a message body
e.g. log ERROR "blah"
Options for log level: ERROR, INFO, VERBOSE,
and FATAL which will call exit 1 immediately after logging
the message at level ERROR.
- log_command() : Used to call a shell command and log that it has been
called, as well as capturing both stdout and stderr.
By default the command output is dumped to the logfile as an
error if the command returns a status > 0, or as a verbose
message if the whole script is running in verbose mode.
An optional log level can be passed to alter the level the
log should be if the command returns a status >0, which may
be useful if the command is expected to return a non-zero
result.
e.g. log_command INFO "ls -lh ~"
Options for log level: ERROR, INFO, and VERBOSE
Attempting to call any other functions from xenguest_manager in an init script
may result in a fatal error, from which cleanup is not guarenteed.
Init scripts also have access to config variables defined in params.cfg.
An example of how to create the directory and install an init shell script can
be found in:
recipes-extended/xenguest/xenguest-network.bb
Where network-bridge.sh is installed from network-bridge.sh.in

128
meta-arm-autonomy/documentation/xenguest-mkimage.md
View File

@@ -1,128 +0,0 @@
Xenguest mkimage
================
Introduction
------------
xenguest-mkimage is a tool to create and modify images to be used as a Guest
with Xen. It defines a format to store completely defined guests as a file or as
a directory, and provides options to create and modify those images.
A xenguest image contains all elements required to create a xen guest.
This is the base elements like a Xen configuration and a Linux kernel binary
but also some more advanced elements like init scripts or a disk definition.
The format is made to be deployable easily by storing everything in a single
file and provide tools to easily manipulate the images. It can also easily be
extended to have features like encryption or signature of images, updates or
complex configurations by providing the ability to have init scripts embedded
inside the image that will be executed on the host when the guest is started.
Xenguest images content
-----------------------
### params.cfg
This file contains parameters that can be used by tools to configure some
functionalities on the host. This can be used by init scripts to have
configurable parameters as it is sourced before calling init scripts.
### guest.cfg and guest.d
guest.cfg is the main xen configuration and guest.d contains optional
configuration parts. All those will be merged into one final xen configuration
before starting the guest.
### files
This directory contains files that can be used by the xen configuration, for
example the kernel image referenced in xen configuration.
This is where the kernel binary, the dtb or a ramdisk will be stored.
### init.pre, init.d and init.post
These directories contain init scripts that will be executed on the host
during the guest startup. Those must be shell scripts and each directory
contains scripts called at a different time:
- init.pre: scripts executed before the guest is created. This can be used
to prepare some features required to create the guest in xen or to
generate part of the xen configuration dynamically.
- init.d: scripts executed when the guest has been created but before it is
started. This can be used to do some xenstore operations or configure the
guest behaviour, using xl for example.
- init.post: scripts executed just after starting the guest. This can be
used to configure things created by xen for the guest like network
network interfaces.
When a directory contains several scripts, those will be called in alphabetical
order.
### disk.cfg and disk-files
disk.cfg contains the guest disk description (disk size and disk partitions).
The file contains the following entries:
- `DISK_SIZE=X`: size of the disk to create in MB or GB(default),
e.g. 1000M or 4[G]
- `DISK_PARTX=SIZE:FS:CONTENT`: create a partition number X (1 to 4) with a
size of SIZE MB or GB(default), e.g 1000M or 2[G].
Format it with filesystem FS (can be ext2, ext3, ext4, vfat or swap)
and extract CONTENT as initial partition content (.tar[.gz|.xz|.bz2] file
or img[.gz|.bz2] file to be dumped in the partition).
FS and CONTENT can be empty.
- `DISK_DEVICE=X`: disk or partition to be used by lvm. Setting this option
allows to bind guest disk with any partition or disk available on host,
e.g. /dev/sda3 or /dev/sdb.
This variable is not set by default, but if set, it overrides disk settings
inside xenguest-manager.conf - 'XENGUEST_VOLUME_DEVICE'.
The disk-files contain files to be used for initializing the disk partitions
content. Those should be used to create a LVM or a physical disk and initialize
it (create partitions, format them and put the initial content).
Usage
-----
xenguest-mkimage is a shell script which must be called like this:
`xenguest-mkimage OPERATION XENGUEST [OPTIONS]`
### Operations
- create: create a xenguest image. If XENGUEST is an existing empty directory,
the image is created as a directory otherwise it will be created as a file.
- check: verify that XENGUEST is a valid xenguest image.
- update: modify a xenguest image (see --help for a list of operations).
- pack: pack a xenguest image directory into a xenguest image file. The file to
be created must be given as 3rd argument.
- extract: extract a xenguest image file into a directory. The destination
directory must be given as 3rd argument.
- dump-xenconfig: dump xenguest image xen configuration.
- dump-diskconfig: dump xenguest image disk configuration.
- dump-paramsconfig: dump xenguest image parameters configuration.
For a detailed help on available operations, please use:
`xenguest-mkimage --help`
### Options
- --kernel=FILE: add kernel FILE as guest kernel. This is both adding the file
to the image and modifying the xen configuration to use it.
- --xen-memory=SIZE: set the guest memory size in MB.
- --xen-extra: add a kernel command line argument. This can be called several
times to add several command line options.
- --xen-device-tree=FILE: add dtb FILE as device tree. This both adding the
file to the image and modifying the xen configuration to use it.
- --xen-ramdisk=FILE: add ramdisk FILE as guest ramdisk. This both adding the
file to the image and modifying the xen configuration to use it.
- --init-script=FILE: add guest init script. The script is embedded inside the
image file. Several script can be added and the basename of FILE is used to
distinguish them (calling the option twice with the same file will update the
script in the image with the second one).
--disk-size=SIZE: set the guest disk size to SIZE in MB or GB(default),
e.g 1000M or 2[G]. Calling this with 0 disable the guest disk.
- --disk-add-part=NUM:SIZE:FS:CONTENT: This is adding a partition to the
xenguest image disk. The partition is described with the arguments:
- NUM: partition number.
- SIZE: partition size in MB or GB(default), e.g 1000M or 2[G].
- FS: filesystem to format the partition with. This can be ext2, ext3, ext4,
vfat of swap. If empty the partition is not formated.
- CONTENT: tar of img file to use to initialize the partition. The file must
be added to the image using --disk-add-file=FILE:CONTENT.
For a detailed help on available options, please use:
`xenguest-mkimage OPERATION --help`

80
meta-arm-autonomy/documentation/xenguest-network.md
View File

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

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

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

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

@@ -1,39 +0,0 @@
# Extra machine settings for fvp-base
# FVP uses vda as hard drive and partition 1 is the
# default rootfs, so use vda2 for guest lvm
XENGUEST_MANAGER_VOLUME_DEVICE ?= "/dev/vda2"
# We need to extend the wks search path to be able to find the wks file set in
# ARM_AUTONOMY_WKS_FILE.
WKS_SEARCH_PATH:prepend := "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic:"
ARM_AUTONOMY_WKS_FILE ?= "arm-autonomy-fvp-base-disk.wks.in"
# set wks file only if INITRAMFS_IMAGE_BUNDLE is not set
WKS_FILE = "${@bb.utils.contains('INITRAMFS_IMAGE_BUNDLE', '1', '',\
'${ARM_AUTONOMY_WKS_FILE}', d)}"
XEN_FILE ?= "xen-fvp-base"
DTB_FILE ?= "${@ get_xen_dtb_filename(d)}"
XEN_ADDR ?= "0x84000000"
DTB_ADDR ?= "0x83000000"
FVP_DATA += "cluster0.cpu0=${DEPLOY_DIR_IMAGE}/${XEN_FILE}@${XEN_ADDR} \
cluster0.cpu0=${DEPLOY_DIR_IMAGE}/${DTB_FILE}@${DTB_ADDR}"
# Set the wks guest partition size and unit. It must be aligned with the sum of
# all XENGUEST_IMAGE_DISK_SIZE set for the guests. By default, LVM2 metadata is
# 1 MiB per physical volume, hence it needs to be taken into account when
# setting GUEST_PART_SIZE. The XENGUEST_IMAGE_DISK_SIZE default value is 4GiB.
GUEST_PART_SIZE ?= "4097"
GUEST_PART_SIZE_UNIT ?= "M"
XENGUEST_NETWORK_BRIDGE_MEMBERS ?= "eth0"
# This function uses the "KERNEL_DEVICETREE" variable and manipulates it to
# return the xen kernel device tree file name.
def get_xen_dtb_filename(d):
kernel_dtb_filename = d.getVar('KERNEL_DEVICETREE',d)
xen_dtb_filename = os.path.splitext(os.path.basename(kernel_dtb_filename))[0] + '-xen.dtb'
return xen_dtb_filename

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

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

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

@@ -1,94 +0,0 @@
# Extra machine settings for n1sdp
# We need to extent the wks search path to be able to find the wks file set in
# ARM_AUTONOMY_WKS_FILE.
WKS_SEARCH_PATH:prepend := "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic:"
ARM_AUTONOMY_WKS_FILE ?= "arm-autonomy-n1sdp-efidisk.wks.in"
WKS_FILE = "${ARM_AUTONOMY_WKS_FILE}"
# Set the wks guest partition size and unit. It must be aligned with the sum of
# all XENGUEST_IMAGE_DISK_SIZE set for the guests. By default, LVM2 metadata is
# 1 MiB per physical volume, hence it needs to be taken into account when
# setting GUEST_PART_SIZE. The XENGUEST_IMAGE_DISK_SIZE default value is 4GiB.
GUEST_PART_SIZE ?= "4097"
GUEST_PART_SIZE_UNIT ?= "M"
# Set default boot partition size and unit
BOOT_PART_SIZE ?= "100"
BOOT_PART_SIZE_UNIT ?= "M"
# The GRUB_CFG_FILE affects arm-autonomy-n1sdp-efidisk.wks.in file
#
# When alternate-kernel DISTRO_FEATURE is present we set the
# arm-autonomy-n1sdp-rt-grub.cfg by default. This GRUB config file has
# additional entries for booting with the PREEMPT_RT kernel.
GRUB_CFG_FILE ?= "${@bb.utils.contains('DISTRO_FEATURES','alternate-kernel', \
'${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic/arm-autonomy-n1sdp-rt-grub.cfg', \
'${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic/arm-autonomy-n1sdp-grub.cfg' \
, d)}"
# From arm-autonomy-n1sdp-efidisk.wks.in, the /boot partition is /dev/sda1, and
# the "/" partition is /dev/sda2.
XENGUEST_MANAGER_VOLUME_DEVICE ?= "/dev/sda3"
XENGUEST_NETWORK_BRIDGE_MEMBERS ?= "eth0"
# The XEN_DEVICETREE_DEPEND and XEN_DEVICETREE_DTBS variables aftect the
# xen-devicetree.bb recipe
XEN_DEVICETREE_DEPEND = "virtual/trusted-firmware-a:do_deploy"
XEN_DEVICETREE_DTBS ?= "n1sdp-single-chip.dtb"
# XEN_MOD_DEVICETREE_DTBS are the generated devicetrees for Xen. By default the
# xen-devicetree.bb recipe adds '-xen' suffix to it
XEN_MOD_DEVICETREE_DTBS ?= "n1sdp-single-chip-xen.dtb"
# When generating the wic image we need to have the xen deployed
do_image_wic[depends] += "xen:do_deploy"
# Select the extra files to be included in the boot partition
IMAGE_EFI_BOOT_FILES += "xen-n1sdp.efi;xen.efi"
IMAGE_EFI_BOOT_FILES += "${XEN_MOD_DEVICETREE_DTBS}"
# When alternate-kernel DISTRO_FEATURE is present we set the linux-yocto-rt
# by default
PREFERRED_PROVIDER_alternate/kernel ?= "\
${@bb.utils.contains('DISTRO_FEATURES', 'alternate-kernel', \
'linux-yocto-rt', '', d)}"
KERNEL_PACKAGE_NAME_alternate/kernel ?= "kernel-rt"
# When alternate-kernel DISTRO_FEATURE is present we set the kernel-rt by
# default
KERNEL_PACKAGE_NAME:pn-linux-yocto-rt = "\
${@ d.getVar('KERNEL_PACKAGE_NAME_alternate/kernel') \
if bb.utils.contains('DISTRO_FEATURES', 'alternate-kernel', True, False, d) \
else 'kernel' }"
# Relative path from DEPLOY_DIR_IMAGE of the Kernel PREEMPT_RT deployed Image
KERNEL_RT_IMAGE ?= "kernel-rt/Image-n1sdp.bin;Image-preempt-rt"
# Only include the Kernel PREEMPT_RT Image if we are building with
# alternate-kernel DISTRO_FEATURE
IMAGE_EFI_BOOT_FILES += "\
${@ d.getVar('KERNEL_RT_IMAGE',d) or '' \
if bb.utils.contains('DISTRO_FEATURES', 'alternate-kernel', True, False, d) and \
d.getVar('PREFERRED_PROVIDER_alternate/kernel') else ''}"
EFIDIR ?= "/EFI/BOOT"
GRUB_CFG_EXTRA_FILE ?= "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic/arm-autonomy-n1sdp-grub.cfg;.${EFIDIR}}"
# When alternate-kernel DISTRO_FEATURE is present we set the
# arm-autonomy-n1sdp-rt-grub.cfg by default. This GRUB config file has
# additional entries for booting with the PREEMPT_RT kernel and also includes
# the main GRUB config file set by GRUB_CFG_EXTRA_FILE.
IMAGE_EFI_BOOT_FILES += "\
${@ d.getVar('GRUB_CFG_EXTRA_FILE',d) or '' \
if bb.utils.contains('DISTRO_FEATURES', 'alternate-kernel', True, False, d) and \
d.getVar('PREFERRED_PROVIDER_alternate/kernel') else ''}"
# Additionnal kernel modules are necessary for n1sdp to be able to mount FAT
# filesystems using CP437.
MACHINE_ESSENTIAL_EXTRA_RDEPENDS:append = " kernel-module-nls-cp437 kernel-module-nls-iso8859-1"
# '-mcpu=' and '-march=' conflicts for xen build
# lets not set '-march=' and let xen to overwrite '-mcpu='
TUNE_CCARGS:remove:pn-xen = "${TUNE_CCARGS_MARCH}${TUNE_CCARGS_MARCH_OPTS}"

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

@@ -1,50 +0,0 @@
# Use OVERRIDES to minimize the usage of
# ${@bb.utils.contains('DISTRO_FEATURES', 'autonomy-host', ...
OVERRIDES:append = "${ARM_AUTONOMY_HOST_OVERRIDES}"
FILESEXTRAPATHS:prepend:autonomy-host := "${THISDIR}/${PN}:"
DEPENDS:append:autonomy-host = " dos2unix-native"
SRC_URI:append:autonomy-host = " file://add-xen-support.patch;patchdir=../"
do_install:append:autonomy-host() {
mv -v ${D}/${UNPACK_DIR}/SOFTWARE/uEnv.txt \
${D}/${UNPACK_DIR}/SOFTWARE/uenvfile
for dir in $(ls ${D}/${UNPACK_DIR}/SITE1/)
do
unix2dos ${D}/${UNPACK_DIR}/SITE1/${dir}/images.txt
done
}
DEPLOY_EXTRA_DEPS ??= ""
DEPLOY_EXTRA_DEPS:autonomy-host = "xen:do_deploy xen-devicetree:do_deploy"
do_deploy[depends] += "${DEPLOY_EXTRA_DEPS}"
do_deploy:prepend:autonomy-host() {
# To avoid dependency loop between firmware-image-juno:do_install,
# xen:do_deploy and xen-devicetree:do_deploy when
# INITRAMFS_IMAGE_BUNDLE = "1", we need to handle the xen and
# xen-devicetree binaries copying in the do_deploy task.
mkdir -p ${D}/${UNPACK_DIR}/SOFTWARE/XEN
cp -v ${DEPLOY_DIR_IMAGE}/xen-${COMPATIBLE_MACHINE}.efi \
${D}/${UNPACK_DIR}/SOFTWARE/XEN/xen
for dtb in $(basename -s .dtb ${KERNEL_DEVICETREE})
do
cp -v ${DEPLOY_DIR_IMAGE}/${dtb}-xen.dtb \
${D}/${UNPACK_DIR}/SOFTWARE/XEN/${dtb}.dtb
done
bbnote "Xen binaries added under SOFTWARE/XEN directory"
if [ "${INITRAMFS_IMAGE_BUNDLE}" != "1" -a "${KERNEL_ALT_IMAGETYPE}" = "Image.lzma" ]; then
# KERNEL_ALT_IMAGETYPE is expected to be Image.lzma,
# however NOR flash filesystem is DOS compatible with 8.3 naming,
# so we need to replace ".lzma" with ".lzm"
cp -L -f ${DEPLOY_DIR_IMAGE}/${KERNEL_ALT_IMAGETYPE} \
${D}/${UNPACK_DIR}/SOFTWARE/Image.lzm
fi
}

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

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

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

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

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

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

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

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

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

@@ -1,41 +0,0 @@
/*
* Modify N1SDP DTB to work properly when Xen is used
*/
/ {
/*
* pmu is using PPI interrupts which are reserved by xen
* remove pm nodes
*/
/delete-node/ pmu;
/delete-node/ spe-pmu;
soc {
/*
* disable IOMMU until we have a proper support in xen
*/
/delete-node/ iommu@4f000000;
/delete-node/ iommu@4f400000;
/*
* Set extra registers required for PCI quirks to communicate with SCP
* and remove invalid properties due to removal
*/
pcie@68000000 {
reg = <0 0x68000000 0 0x1200000>,
<0 0x06000000 0 0x80000>,
<0 0x62000000 0 0x80000>;
/delete-property/ msi-map;
/delete-property/ iommu-map;
};
pcie@70000000 {
reg = <0 0x70000000 0 0x1200000>,
<0 0x06000000 0 0x80000>,
<0 0x60000000 0 0x80000>;
/delete-property/ msi-map;
/delete-property/ iommu-map;
};
};
};

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

36
meta-arm-autonomy/recipes-containers/import-docker-containers/import-docker-containers.bb
View File

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

19
meta-arm-autonomy/recipes-containers/packagegroups/packagegroup-docker-runtime-minimal.bb
View File

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

1
meta-arm-autonomy/recipes-core/busybox/busybox/feature_tar_long_options.cfg
View File

@@ -1 +0,0 @@
CONFIG_FEATURE_TAR_LONG_OPTIONS=y

8
meta-arm-autonomy/recipes-core/busybox/busybox_%.bbappend
View File

@@ -1,8 +0,0 @@
# Use OVERRIDES to minimize the usage of
# ${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', ...
OVERRIDES:append = "${ARM_AUTONOMY_HOST_OVERRIDES}"
FILESEXTRAPATHS:prepend:autonomy-host := "${THISDIR}/${PN}:"
# The --exclude flag in Busybox tar is required by xenguest-mkimage
SRC_URI:append:autonomy-host = " file://feature_tar_long_options.cfg"

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

@@ -1,35 +0,0 @@
# Recipe to create a minimal Arm Autonomy reference stack host image
DESCRIPTION = "Arm Autonomy stack host minimal image"
# When alternate-kernel DISTRO_FEATURE is present we will build
# and install the alternate kernel
inherit ${@bb.utils.filter('DISTRO_FEATURES', 'alternate-kernel', d)}
inherit core-image features_check
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
# Includes minimal set required to start and manage guest. The xen specific
# modules are not explicitly included as they are built as part of the kernel
# image for performance reasons. It doesn't include all kernel modules to
# reduce the image size. If the kernel-modules packages are needed they can
# be appended to IMAGE_INSTALL in a bbappend.
IMAGE_INSTALL += " \
packagegroup-core-boot \
packagegroup-core-ssh-openssh \
qemu-system-i386 \
xenguest-extern-guests \
xenguest-manager \
xenguest-network \
"
# Build xen binary
EXTRA_IMAGEDEPENDS += "xen"
# Build xen-devicetree to produce a xen ready devicetree
EXTRA_IMAGEDEPENDS += "xen-devicetree"
REQUIRED_DISTRO_FEATURES += 'arm-autonomy-host'
REQUIRED_DISTRO_FEATURES += 'xen'

20
meta-arm-autonomy/recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend
View File

@@ -1,20 +0,0 @@
# Add support for interface configuration via interfaces.d directory. This
# feature can be used by other packages to add network interface
# configuration by adding network network interface configuration file under
# interfaces.d directory.
OVERRIDES:append = "${ARM_AUTONOMY_HOST_OVERRIDES}"
do_install:append:autonomy-host() {
# 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
}

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

@@ -1,20 +0,0 @@
# if arm-autonomy-host or arm-autonomy-guest are activated, we need to install
# the getty-wrapper to spawn the login console on /dev/hvc0.
# This is normally done in meta-virtualization if virtualization and xen
# DISTRO_FEATURES are activated.
# In both arm-autonomy-host and arm-autonomy-guest we don't have virtualization
# in DISTRO_FEATURE. Hence, manually include sysvinit-inittab_virtualization.inc
# to install the getty-wrapper.
require ${@bb.utils.contains_any('DISTRO_FEATURES', \
'arm-autonomy-host arm-autonomy-guest', \
'recipes-core/sysvinit/sysvinit-inittab_virtualization.inc', \
'', d)}
# For arm-autonomy-guest we don't have xen in DISTRO_FEATURES. Hence, manually
# include sysvinit-inittab_xen.inc to append the getty-wrapper entry to
# /etc/inittab.
require ${@bb.utils.contains('DISTRO_FEATURES', \
'arm-autonomy-guest', \
'recipes-core/sysvinit/sysvinit-inittab_xen.inc', \
'', d)}

8
meta-arm-autonomy/recipes-devtools/qemu/qemu-autonomy-host.inc
View File

@@ -1,8 +0,0 @@
# For Xen we only need the i386 binaries
QEMU_TARGETS = "i386"
PACKAGECONFIG[noaudio] = "--audio-drv-list='',,"
PACKAGECONFIG:append = " noaudio"
PACKAGECONFIG:remove = "fdt sdl kvm"
require recipes-devtools/qemu/qemu-package-split.inc

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

@@ -1,3 +0,0 @@
require ${@bb.utils.contains('DISTRO_FEATURES', \
'arm-autonomy-host', \
'qemu-autonomy-host.inc', '', d)}

17
meta-arm-autonomy/recipes-extended/xen-devicetree/files/xen.dtsi.in
View File

@@ -1,17 +0,0 @@
/ {
chosen {
xen,dom0-bootargs = "###XEN_DOM0_BOOTARGS###";
xen,xen-bootargs = "###XEN_XEN_BOOTARGS###";
modules {
#size-cells = <0x00000001>;
#address-cells = <0x00000001>;
module@0 {
reg = <###XEN_DOM0_ADDR### ###XEN_DOM0_SIZE###>;
compatible = "multiboot,module";
};
};
};
};

130
meta-arm-autonomy/recipes-extended/xen-devicetree/xen-devicetree.bb
View File

@@ -1,130 +0,0 @@
# This recipe can be used to modify one or several DTBS to add
# entries required to declare and boot Linux as Dom0 from Xen
SRC_URI = "file://xen.dtsi.in"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "\
file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \
"
S = "${WORKDIR}"
DESCRIPTION = "Add entries in DTB for Xen and Dom0"
# Please refer to documentation/xen-devicetree.md for documentation on these
# customizable parameters
# kernel size is passed to xen via xen.dtb so we need to add
# 'virtual/kernel:do_deploy' as a dependency
XEN_DEVICETREE_DEPEND:append = " virtual/kernel:do_deploy"
XEN_DEVICETREE_DTBS ?= "${KERNEL_DEVICETREE}"
XEN_DEVICETREE_XEN_BOOTARGS ?= "noreboot dom0_mem=${XEN_DEVICETREE_DOM0_MEM}"
XEN_DEVICETREE_DOM0_MEM ?= "1024M,max:1024M"
XEN_DEVICETREE_DOM0_BOOTARGS ?= "console=hvc0 earlycon=xen"
XEN_DEVICETREE_DOM0_ADDR ?= "0x80080000"
XEN_DEVICETREE_DOM0_SIZE ?= "0x01000000"
XEN_DEVICETREE_DTSI_MERGE ?= "xen.dtsi"
# Our package does not generate any packages for the rootfs, but instead
# contributes to deploy
inherit nopackages deploy
DEPENDS += "dtc-native"
PACKAGE_ARCH = "${MACHINE_ARCH}"
do_configure[noexec] = "1"
do_compile[noexec] = "1"
do_install[noexec] = "1"
# Validate xen devicetree variables
python __anonymous() {
# Compare values of a list of variables to a regex pattern
def validate_type(pattern, var_list):
for varname in var_list:
if d.getVar(varname):
if not pattern.match(d.getVar(varname)):
raise bb.parse.SkipRecipe(d.getVar(varname) + "' is not a valid value for " + varname + "!")
else:
raise bb.parse.SkipRecipe('Required variable ' + varname + ' is empty!')
import re
num_vars_to_check = ['XEN_DEVICETREE_DOM0_ADDR', 'XEN_DEVICETREE_DOM0_SIZE']
size_vars_to_check = ['XEN_DEVICETREE_DOM0_MEM']
num_pattern = re.compile(r'((0x[0-9a-fA-F]+)|[0-9]+)$')
size_pattern = re.compile(r'[0-9]+[MG](,max:[0-9]+[MG])?$')
validate_type(num_pattern, num_vars_to_check)
validate_type(size_pattern, size_vars_to_check)
}
do_deploy() {
if [ ! -f ${WORKDIR}/xen.dtsi.in ]; then
die "xen.dtsi.in does not exist"
fi
cat ${WORKDIR}/xen.dtsi.in \
| sed -e "s?###XEN_DOM0_BOOTARGS###?${XEN_DEVICETREE_DOM0_BOOTARGS}?" \
| sed -e "s?###XEN_XEN_BOOTARGS###?${XEN_DEVICETREE_XEN_BOOTARGS}?" \
| sed -e "s?###XEN_DOM0_ADDR###?${XEN_DEVICETREE_DOM0_ADDR}?" \
| sed -e "s?###XEN_DOM0_SIZE###?${XEN_DEVICETREE_DOM0_SIZE}?" \
> ${WORKDIR}/xen.dtsi
# Generate final dtbs
for dtbf in ${XEN_DEVICETREE_DTBS}; do
rdtb=`basename $dtbf`
if [ ! -f ${DEPLOY_DIR_IMAGE}/$rdtb ]; then
die "Wrong file in XEN_DEVICETREE_DTBS: ${DEPLOY_DIR_IMAGE}/$rdtb does not exist"
fi
dtc -I dtb -O dts -o ${WORKDIR}/dom0-linux.dts ${DEPLOY_DIR_IMAGE}/$rdtb
# Add external includes
for inc in ${XEN_DEVICETREE_DTSI_MERGE}; do
if [ ! -f ${WORKDIR}/${inc} ]; then
die "Wrong file in XEN_DEVICETREE_DTSI_MERGE: ${WORKDIR}/${inc} does not exist"
fi
echo "/include/ \"$inc\"" >> ${WORKDIR}/dom0-linux.dts
done
rdtbnoextn=`basename $dtbf ".dtb"`
dtc -I dts -O dtb \
-o ${WORKDIR}/${rdtbnoextn}-xen.dtb ${WORKDIR}/dom0-linux.dts
install -m 644 ${rdtbnoextn}-xen.dtb ${DEPLOYDIR}/.
done
}
do_deploy[depends] += "${XEN_DEVICETREE_DEPEND}"
do_deploy[prefuncs] += "calc_xen_dtb_dom0_size"
addtask deploy after do_install
python calc_xen_dtb_dom0_size() {
from math import ceil
size = 0
if d.getVar('KERNEL_IMAGE_MAXSIZE'):
bb.note('size calculation based on KERNEL_IMAGE_MAXSIZE')
size = int(d.getVar('KERNEL_IMAGE_MAXSIZE')) * 1024
else:
kernel = os.path.realpath(d.getVar('DEPLOY_DIR_IMAGE') + '/' +\
d.getVar('KERNEL_IMAGETYPE'))
size = os.stat(kernel).st_size
bb.note('size calculation based on kernel Image file: %s' % kernel)
bb.note('size in bytes: %d' % size)
# Ceil to MiB
size_required = ceil(size / (2 ** 20)) * (2 ** 20)
xen_devicetree_dom0_size = d.getVar('XEN_DEVICETREE_DOM0_SIZE')
if xen_devicetree_dom0_size[:2] == "0x":
size_defined = int(xen_devicetree_dom0_size, 16)
else:
size_defined = int(xen_devicetree_dom0_size)
if size_required > size_defined:
bb.note ("Wrong kernel size setting inside xen dtb!\n"\
"Required:\t%(req)d (%(req)#010X)\n"\
"Requested:\t%(def)d (%(def)#010X)"\
% {"req": size_required, "def": size_defined})
bb.note ("Overriding XEN_DEVICETREE_DOM0_SIZE with "\
"%(req)d (%(req)#010X)" % {"req": size_required})
d.setVar('XEN_DEVICETREE_DOM0_SIZE', hex(size_required))
}

51
meta-arm-autonomy/recipes-extended/xen/xen-4.14/0001-xen-arm-Throw-messages-for-unknown-FP-SIMD-implement.patch
View File

@@ -1,51 +0,0 @@
From f4c1a541fa351e4f613471bbf397931f9e1ddd27 Mon Sep 17 00:00:00 2001
Message-Id: <f4c1a541fa351e4f613471bbf397931f9e1ddd27.1602683707.git.diego.sueiro@arm.com>
From: Wei Chen <wei.chen@arm.com>
Date: Fri, 28 Aug 2020 02:34:04 +0000
Subject: [PATCH] xen/arm: Throw messages for unknown FP/SIMD implement ID
Arm ID_AA64PFR0_EL1 register provides two fields to describe CPU
FP/SIMD implementations. Currently, we exactly know the meaning of
0x0, 0x1 and 0xf of these fields. Xen treats value < 8 as FP/SIMD
features presented. If there is a value 0x2 bumped in the future,
Xen behaviors for value <= 0x1 can also take effect. But what Xen
done for value <= 0x1 may not always cover new value 0x2 required.
We throw these messages to break the silence when Xen detected
unknown FP/SIMD IDs to notice user to check.
Signed-off-by: Wei Chen <wei.chen@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Upstream-Status: Backport
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
---
xen/arch/arm/setup.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7968cee..f16b33f 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -133,6 +133,18 @@ static void __init processor_id(void)
cpu_has_simd ? " AdvancedSIMD" : "",
cpu_has_gicv3 ? " GICv3-SysReg" : "");
+ /* Warn user if we find unknown floating-point features */
+ if ( cpu_has_fp && (boot_cpu_feature64(fp) >= 2) )
+ printk(XENLOG_WARNING "WARNING: Unknown Floating-point ID:%d, "
+ "this may result in corruption on the platform\n",
+ boot_cpu_feature64(fp));
+
+ /* Warn user if we find unknown AdvancedSIMD features */
+ if ( cpu_has_simd && (boot_cpu_feature64(simd) >= 2) )
+ printk(XENLOG_WARNING "WARNING: Unknown AdvancedSIMD ID:%d, "
+ "this may result in corruption on the platform\n",
+ boot_cpu_feature64(simd));
+
printk(" Debug Features: %016"PRIx64" %016"PRIx64"\n",
boot_cpu_data.dbg64.bits[0], boot_cpu_data.dbg64.bits[1]);
printk(" Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
--
2.7.4

34
meta-arm-autonomy/recipes-extended/xen/xen-tools-4.14/0001-vif-nat-fix-hostname.patch
View File

@@ -1,34 +0,0 @@
Upstream-Status: Backport
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
Signed-off-by: Kamil Dziezyk <kamil.dziezyk@arm.com>
From 5499e0fc8082024bf7e2d0facd5c976e82105070 Mon Sep 17 00:00:00 2001
From: Diego Sueiro <diego.sueiro@arm.com>
Date: Thu, 20 Aug 2020 11:58:20 +0100
Subject: [PATCH] tools/hotplug: Fix hostname setting in vif-nat
Setting the hostname is failing because the "$XENBUS_PATH/domain"
doesn't exist anymore. To fix this we set it to dom$domid
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Wei Liu <wl@xen.org>
---
tools/hotplug/Linux/vif-nat | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hotplug/Linux/vif-nat b/tools/hotplug/Linux/vif-nat
index a76d9c784b..26144350b3 100644
--- a/tools/hotplug/Linux/vif-nat
+++ b/tools/hotplug/Linux/vif-nat
@@ -85,7 +85,7 @@ router_ip=$(routing_ip "$ip")
# Split the given IP/bits pair.
vif_ip=`echo ${ip} | awk -F/ '{print $1}'`
-hostname=$(xenstore_read "$XENBUS_PATH/domain" | tr -- '_.:/+' '-----')
+hostname=dom$domid
if [ "$vifid" != "1" ]
then
hostname="$hostname-$vifid"
--
2.17.1

4
meta-arm-autonomy/recipes-extended/xen/xen-tools_%.bbappend
View File

@@ -1,4 +0,0 @@
PACKAGECONFIG:remove = "\
${@bb.utils.contains('DISTRO_FEATURES', \
'arm-autonomy-host', \
'sdl', '', d)}"

7
meta-arm-autonomy/recipes-extended/xen/xen-tools_4.14.bbappend
View File

@@ -1,7 +0,0 @@
# Use OVERRIDES to minimize the usage of
# ${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', ...
OVERRIDES:append = "${ARM_AUTONOMY_HOST_OVERRIDES}"
FILESEXTRAPATHS:prepend:autonomy-host := "${THISDIR}/${PN}-4.14:"
SRC_URI:append:autonomy-host = " file://0001-vif-nat-fix-hostname.patch"

10
meta-arm-autonomy/recipes-extended/xen/xen_%.bbappend
View File

@@ -1,10 +0,0 @@
# Use OVERRIDES to minimize the usage of
# ${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', ...
OVERRIDES:append = "${ARM_AUTONOMY_HOST_OVERRIDES}"
# Make Xen machine specific
# This ensures that sstate is properly handled and that each machine can have
# its own configuration
PACKAGE_ARCH:autonomy-host = "${MACHINE_ARCH}"
PACKAGECONFIG:remove:autonomy-host = "sdl"

9
meta-arm-autonomy/recipes-extended/xen/xen_4.14.bbappend
View File

@@ -1,9 +0,0 @@
# Use OVERRIDES to minimize the usage of
# ${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', ...
OVERRIDES:append = "${ARM_AUTONOMY_HOST_OVERRIDES}"
FILESEXTRAPATHS:prepend:autonomy-host := "${THISDIR}/${PN}-4.14:"
SRC_URI:append:autonomy-host = " \
file://0001-xen-arm-Throw-messages-for-unknown-FP-SIMD-implement.patch \
"

138
meta-arm-autonomy/recipes-extended/xenguest/files/00-vif-xenguest.hook
View File

@@ -1,138 +0,0 @@
#============================================================================
# ${XEN_SCRIPT_DIR}/vif-post.d/00-vif-xenguest.hook
#
# Script for performing local configuration of a vif.
# This script will be sourced by, e.g., vif-bridge after the hotplugging
# system calls vif-bridge. The script is here and not simply executed as
# a udev rule because this allows simple access to several environment
# variables set by the calling vif-* script.
#
# Environment vars:
# command (add|remove|online|offline)
# dev vif interface name (required).
# main_ip IP address of Dom0
# ip list of IP networks for the vif, space-separated
# XENBUS_PATH path to this device's details in the XenStore (required).
#============================================================================
domid=$(xenstore_read "${XENBUS_PATH}/frontend-id")
guestname=$(xenstore_read "/local/domain/${domid}/name")
bridge=$(xenstore_read "${XENBUS_PATH}/bridge")
mac=$(xenstore_read "$XENBUS_PATH/mac")
kea_conf_file="/etc/kea/kea-dhcp4.conf"
if [ ! -f /etc/xenguest/guests/${guestname}/params.cfg ]; then
log debug "No /etc/xenguest/guests/${guestname}/params.cfg. Exiting."
return
fi
# Source the params file to get the choosen XENGUEST_NETWORK_TYPE
. /etc/xenguest/guests/${guestname}/params.cfg
# We need to get the xenguest subnet prefix to set the subnet and
# the fixed ip to assing to the guest.
get_subnet_prefix() {
# ${vif_ip} is set in the vif-nat script
echo ${vif_ip} | awk -F. '{print $1"."$2"."$3}'
}
subnetprefix=$(get_subnet_prefix)
kea_remove_conf_entry()
{
log debug "kea_remove_conf_entry"
claim_lock "vif-nat-kea"
# Remove the the xenguest kea config file inclusion in the kea main config
sed -i "/${kea_guest_config//'/'/'\/'}/d" "${kea_conf_file}"
# Remove interface entry 1st case: [ "dev1", "dev_to_remove" ]
sed -i "s/,\ \"$dev\"//" "${kea_conf_file}"
# Remove interface entry 2nd case: [ "dev_to_remove", "dev1" ]
sed -i "s/\"$dev\",\ //" "${kea_conf_file}"
# Remove interface entry 3rd case: [ "dev_to_remove" ]
sed -i "s/\[\ \"$dev\"\ \]/\[\ \]/" "${kea_conf_file}"
# Remove the generated the xenguest kea subnet conf file
rm ${XENGUEST_KEA_SUBNET_CONFIG}
keactrl reload
release_lock "vif-nat-kea"
}
kea_add_conf_entries()
{
log debug "kea_add_conf_entries"
claim_lock "vif-nat-kea"
# Include vif in the interfaces 1st case - no other entries:
search_for='\"interfaces\": \[ '
sed -i "/${search_for}\"*\"\ */ s/\ \]/,\ \"${dev}\"\ \]/g" "${kea_conf_file}"
sed -i "s/${search_for}]/${search_for}\"${dev}\"\ \]/g" "${kea_conf_file}"
# Include the xenguest kea subnet conf file in the kea main config
search_for='\"subnet4\": \['
sed -i "/$search_for/a $kea_guest_config" "${kea_conf_file}"
# Generate the xenguest kea subnet conf file
echo -e "$(eval "echo -e \"$(cat ${XENGUEST_KEA_SUBNET_TEMPLATE})\"")" \
> "${XENGUEST_KEA_SUBNET_CONFIG}"
release_lock "vif-nat-kea"
}
call_extra_hooks() {
for f in /etc/xenguest/guests/${guestname}/files/*.hook; do
if [ -x "$f" ]; then
log info "Executing $f"
. "$f"
if [ $? -ne 0 ]; then
log err "$f failed."
fi
else
log info "$f is not executable. Skipping."
fi
done
}
case "${XENGUEST_NETWORK_TYPE}" in
nat)
XENGUEST_KEA_SUBNET_TEMPLATE=${XENGUEST_KEA_SUBNET_TEMPLATE:-"/etc/xenguest/guests/${guestname}/files/kea-subnet4.json"}
if [ ! -f ${XENGUEST_KEA_SUBNET_TEMPLATE} ]; then
log debug "No ${XENGUEST_KEA_SUBNET_TEMPLATE} file. Aborting"
return
fi
XENGUEST_KEA_SUBNET_CONFIG="/etc/kea/kea-subnet4.dom$domid.json"
if [ ! -d "$(dirname ${XENGUEST_KEA_SUBNET_CONFIG})" ]; then
log debug "No kea configuration directory. Aborting"
return
fi
kea_guest_config="\ \ \ \ <?include \"${XENGUEST_KEA_SUBNET_CONFIG}\"?>"
case "$command" in
online)
kea_add_conf_entries
# Enable ip forwarding and NAT for the ${bridge} interface
sysctl -w net.ipv4.ip_forward=1
iptables_w -t nat -A POSTROUTING -o ${bridge} -j MASQUERADE -m comment --comment "dom${domid}"
;;
offline)
kea_remove_conf_entry
# Remove the NAT iptables rules created for the dom${domid}
guest_ipt_rule=$(iptables_w -t nat -vL POSTROUTING -n --line-number | grep -w dom${domid} | awk '{print $1}' | tac)
for rule in ${guest_ipt_rule}; do iptables_w -t nat --delete POSTROUTING ${rule}; done
# If there is no more NAT iptables rules we disable ip forwarding
ipt_nat_rules=$(iptables_w -t nat -vL POSTROUTING -n --line-number | grep MASQUERADE | awk '{print $1}')
[ -z "${ipt_nat_rules##*[!0-9]*}" ] && sysctl -w net.ipv4.ip_forward=0
;;
esac
# We might have extra configs to be applied (e.g.: NAT port forward).
call_extra_hooks
;;
esac

48
meta-arm-autonomy/recipes-extended/xenguest/files/00-xenguest-nat-port-forward.hook
View File

@@ -1,48 +0,0 @@
#============================================================================
# /etc/xenguest/guests/${guestname}/files/00-xenguest-nat-port-forward.hook
#
# Script for performing local configuration related to NAT port forwarding of
# a vif.
# This script will be sourced by
# /etc/xen/scripts/vif-post.d/00-vif-xenguest.hook when
# XENGUEST_IMAGE_NETWORK_TYPE="nat".
# The ${bridge} and ${domid} are set in the 00-vif-xenguest.hook context,
# and ${vip_if} in the vif-nat script context.
#
# Environment vars:
# command (add|remove|online|offline)
# dev vif interface name (required).
# main_ip IP address of Dom0
# ip list of IP networks for the vif, space-separated
# XENBUS_PATH path to this device's details in the XenStore (required).
#============================================================================
host_port="###HOST_PORT###"
guest_port="###GUEST_PORT###"
port_num_check() {
if [ ${host_port} -gt 65535 -o ${guest_port} -gt 65535 ]; then
log error "host_port=${host_port} or guest_port=${guest_port} greater than 65535."
return 1
fi
return 0
}
case "${command}" in
online)
port_num_check
if [ $? -eq 0 ]; then
iptables_w -t nat -A PREROUTING -i ${bridge} -p tcp \
--dport ${host_port} -j DNAT \
--to-destination ${vif_ip}:${guest_port} \
-m comment --comment "dom${domid}"
fi
;;
offline)
# Remove the NAT iptables rules created for the dom${domid}
guest_ipt_rule=$(iptables_w -t nat -vL PREROUTING -n --line-number \
| grep -w dom${domid} | awk '{print $1}' | tac)
for rule in ${guest_ipt_rule}; \
do iptables_w -t nat --delete PREROUTING ${rule}; done
;;
esac

30
meta-arm-autonomy/recipes-extended/xenguest/files/kea-dhcp4.conf
View File

@@ -1,30 +0,0 @@
# This file holds the minimal kea dhcp4 server configuration.
# It replaces existing kea dhcp configuration file via
# "/etc/init.d/kea-restore-default-config" on every system boot.
# The "/etc/xen/scripts/vif-post.d/00-vif-xenguest.hook" called in the end of
# the vif-nat script will append each xenguest configuration to this file,
# to generate the final dhcp configuration.
# This file can be replaced with xenguest-network.bbappend.
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ ]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"subnet4": [
{
"subnet": "192.0.2.0/24"
}
],
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [ { "output": "/var/log/kea-dhcp4.log" } ],
"severity": "INFO"
}
]
}
}

29
meta-arm-autonomy/recipes-extended/xenguest/files/kea-restore-default-config
View File

@@ -1,29 +0,0 @@
#!/bin/sh
#
# Xenguest Restore default kea dhcp4 configuration
# This script restores a dhcp4 server configuration, to prevent
# kea startup failures after random board hangs or powercuts.
#
case "$1" in
start)
ret=$(keactrl status | grep -i "dhcpv4 server" | cut -d ' ' -f 3)
if [ "$ret" = "active" ]; then
echo "WARNING: cowardly refusing to replace dhcp4 configuration"
echo "kea dhcp4 server is up and running!"
else
echo "Resetting kea dhcp4 configuration."
cp -f /etc/kea/kea-dhcp4.conf.original /etc/kea/kea-dhcp4.conf
fi
;;
status|stop|reload|force-reload|restart)
true
;;
*)
# do not advertise unreasonable commands that there is no reason
# to use with this device
echo "Usage: $0 {start|stop|status|restart|force-reload}"
exit 1
esac
exit $?

35
meta-arm-autonomy/recipes-extended/xenguest/files/kea-subnet4.json
View File

@@ -1,35 +0,0 @@
# This file holds the guest kea dhcp4 server options running on Dom0.
# The "/etc/xen/scripts/vif-post.d/00-vif-xenguest.hook" called in the end of
# the vif-nat script will use this file to generate the final dhcp
# configuration.
# This file is added in the xenguest image and installed in dom0 under
# /etc/xenguest/guests/${guestname}/files/kea-subnet4.json when the guest
# image is created.
# Any customizations to it should be performed by replacing it via a bbappend.
# The \${vif_ip} and \${router_ip} variables are set in
# the vif-nat script context. The \${subnetprefix} and \${mac} variable are set in the
# 00-vif-xenguest.hook script context.
# The "subnet" configuration node is mandatory in order to have the dhcp
# properly running.
{
\"subnet\": \"${subnetprefix}.0/24\",
\"option-data\": [
{
\"name\": \"routers\",
\"data\": \"${router_ip}\"
},
{
\"name\": \"domain-name-servers\",
\"data\": \"8.8.8.8, 8.8.4.4\"
}
],
\"reservations\": [
{
\"hw-address\": \"${mac}\",
\"ip-address\": \"${vif_ip}\"
}
]
},

6
meta-arm-autonomy/recipes-extended/xenguest/files/logrotate-xenguest
View File

@@ -1,6 +0,0 @@
/var/log/xenguest {
missingok
size 10k
copytruncate
rotate 2
}

26
meta-arm-autonomy/recipes-extended/xenguest/files/network-bridge.sh.in
View File

@@ -1,26 +0,0 @@
#!/bin/sh
# This script is setting up a virtual network interface connected to the
# xenguest-network-bridge if NETWORK_BRIDGE is set to 1 in the guest params
#
# Since this script is sourced by xenguest-manager, it can access variables
# such as ${guestname} from the parent file's scope, as well as those in
# params.cfg, for example XENGUEST_NETWORK_TYPE
BRIDGE_NAME="###BRIDGE_NAME###"
case "${XENGUEST_NETWORK_TYPE:=}" in
nat)
echo "vif = ['script=vif-nat']" >> "${guestcfgfile:?}"
log info "Network type is NAT"
;;
bridge)
echo "vif = ['script=vif-bridge,bridge=${BRIDGE_NAME}']" >> "${guestcfgfile:?}"
log info "Network type is bridge: ${BRIDGE_NAME}"
;;
none)
log info "Network type is none"
;;
*)
log error "XENGUEST_NETWORK_TYPE=$XENGUEST_NETWORK_TYPE invalid"
;;
esac

90
meta-arm-autonomy/recipes-extended/xenguest/files/xenguest-init
View File

@@ -1,90 +0,0 @@
#!/bin/bash
#
# xenguest Init Script to start and stop xenguests during boot
#
XENGUEST_CONF_BASE="/etc/xenguest"
if [ ! -f ${XENGUEST_CONF_BASE}/xenguest-manager.conf ]; then
echo "No xenguest manager configuration !!"
exit 1
fi
source ${XENGUEST_CONF_BASE}/xenguest-manager.conf
# Make sure we properly initialized the Dom0
/usr/bin/xenguest-manager check-xen || exit $?
# Create guest list
guestlist=$(/usr/bin/xenguest-manager list)
# Unconfigured guests
case "$1" in
start)
echo "Starting xenguest"
# Create unconfigured guests
if [ -d "${XENGUEST_GUEST_DIR}" ]; then
shopt -s nullglob
for path in "${XENGUEST_GUEST_DIR}"/*.xenguest; do
f=$(basename "${path}" .xenguest)
if [ ! -f "${XENGUEST_CONF_BASE}/guests/${f}/guest.cfg" ]; then
# Check if this guest should be auto booted
autoboot=$(/usr/bin/xenguest-mkimage dump-paramsconfig \
"${path}" | \
grep GUEST_AUTOBOOT | sed -e "s,.*=,," | tr -d '"')
if [ "$autoboot" = "0" ]; then
echo "Do not create $f, autoboot disabled"
else
/usr/bin/xenguest-manager create "${path}"
# Update guestlist
if [ $? -eq 0 ]; then
guestlist="${guestlist} ${f}"
fi
fi
fi
done
fi
if [ -n "${guestlist}" ]; then
for f in ${guestlist}; do
GUEST_AUTOBOOT="1"
if [ -f "${XENGUEST_CONF_BASE}/guests/${f}/params.cfg" ]; then
source "${XENGUEST_CONF_BASE}/guests/${f}/params.cfg"
fi
if [ "${GUEST_AUTOBOOT}" = "1" ]; then
/usr/bin/xenguest-manager start "${f}"
fi
done
else
echo "No guest configured"
fi
;;
status)
true
;;
stop)
echo "Stopping xenguest"
# update guest list
guestlist=$(xenguest-manager status | grep Running | cut -d " " -f1)
for f in ${guestlist}; do
xenguest-manager shutdown "${f}" --kill
done
;;
reload)
echo >&2 'Reload not available; use force-reload'; exit 1
;;
force-reload|restart)
echo "Restarting xenguest"
$0 stop
$0 start
;;
*)
# do not advertise unreasonable commands that there is no reason
# to use with this device
echo $"Usage: $0 {start|stop|status|restart|force-reload}"
exit 1
esac
exit $?

1139
meta-arm-autonomy/recipes-extended/xenguest/files/xenguest-manager
View File

File diff suppressed because it is too large Load Diff

938
meta-arm-autonomy/recipes-extended/xenguest/files/xenguest-mkimage
View File

@@ -1,938 +0,0 @@
#!/bin/bash
# This script must be used to manipulate xenguest images
#
# xenguest image topology:
# params.cfg: guest global configuration file. Only edited using this script.
# guest.cfg: xen main configuration file. Only edited using this script.
# guest.d: directory contains files with custom xen configuration entries
# which are appended to guest.cfg before starting the guest
# files: directory where files used by xen configuration are stored
# disk.cfg: guest disk configuration file. Only edited using this script.
# (dtb, kernel image, etc)
# disk: directory where files for disk creation are stored
# init.[pre,d,post]: directories containing init pre, base and post scripts
set -u
set -e
this="$0"
IMAGE_TMPDIR=""
usage() {
cat <<EOF
Usage $this ACTION XENGUEST [ARGS]
Where XENGUEST is a xenguest image file or a xenguest directory.
The following actions are supported:
help Display this help
create Create a xenguest image
update Update/modify a xenguest image
partial Create partial xenguest image in a directory
pack Pack a xenguest directory into an image
check Check a xenguest image
dump-paramsconfig Display the guest configuration of a xenguest image
dump-xenconfig Display the xen configuration of a xenguest image
dump-diskconfig Display the disk configuration of a xenguest image
dump-init Display init scripts of a xenguest image
extract Extract a xenguest image content
extract-config Extract the guest configuration from a xenguest image
extract-disk-file Extract a disk file from a xenguest image
Use $this ACTION --help to have help on a specific action and its arguments.
EOF
}
usage-check() {
cat <<EOF
Usage $this check XENGUEST
Check a xenguest image or a xenguest directory.
EOF
}
usage-update-create() {
cat <<EOF
All arguments are handled in order.
Global configuration for the guest
--guest-config-reset reset guest global configuration
--set-param=PARAM disable parameter PARAM in guest global configuration
--set-param=PARAM=VAL set parameter PARAM to value VAL in guest global
configuration.
Example of parameters supported are:
GUEST_AUTOBOOT: if set to 1 (default), guest will be
automatically created and started during host init.
Xen configuration for the guest
--xen-reset-config reset xen guest configuration to default
--xen-name= disable name parameter in xen configuration
--xen-name=NAME set guest name in xen configuration
--xen-kernel= disable guest kernel parameter in xen configuration
--xen-kernel=FILE set guest kernel to FILE (file is added and xen
configuration is set to use it)
--xen-memory set guest memory size (in MB)
--xen-vcpus set guest number of virtual cpus
--xen-clean-extra set guest command line (extra) to an empty string
--xen-extra=ARG append ARG to the guest command line (with space)
use this several time to set command line.
To set the command line to "console=ttyS0 rw" do
--xen-extra=console=ttyS0 --xen-extra=rw
--xen-root= disable root parameter in xen configuration
--xen-root=ROOT set guest root in xen configuration
--xen-device-tree= disable device tree parameter in xen configuration
--xen-device-tree=FILE set guest device tree in xen configuration and add
file to xen files
--xen-ramdisk= disable ramdisk parameter in xen configuration
--xen-ramdisk=FILE set guest ramdisk in xen configuration and add
file to xen files
--xen-disk= disable disk parameter in xen configuration
--xen-disk=DEV set guest disk to device DEV (phy:DEV,xvda,w is set)
--xen-append=FILE append FILE content to xen configuration
Xen files
--xen-add-file=SRC:DST add file SRC as file DST in the xenguest image.
If DST already exist in the image, it is overwritten.
DST must be the same as arguments passed to other
options (like --xen-kernel)
--xen-rm-file=DST remove file DST from the xenguest image.
Init configuration
This can be used to add init scripts for the guest. There are 3 possible init
scripts which are called at different time. The pre scripts are called first,
then the xen guest is created in pause and standard init scripts are called.
Finally the xen guest is started then the post init scripts are called.
Each script is called with the name of the guest as first argument and
multiple scripts can be added (they must have different names).
--init-script=FILE add FILE as init script
--init-pre=FILE add FILE as pre init script
--init-post=FILE add FILE as post init script
Disk configuration
--disk-reset-config reset disk guest configuration to default (no disk)
--disk-size=SZ set guest disk size in MB or GB(default),
e.g 1000M or 2[G].
--disk-device=DEV set device to be used to create the guest disk
if unset or set to an empty string, the volume will be
create in the default manager volume group.
--disk-add-part=DEF add a partition to the guest disk with definition DEF
a partition definition must have the following format:
ID:SIZE:FORMAT:CONTENT where:
- ID is the partition numeric ID (1 to 4)
- FORMAT is the filesystem format (supported formats
are none, vfat, swap, ext2, ext3 and ext4) or can be
left empty to not format
- CONTENT can be used to point to a file added using
--disk-add-file to be used as partition initial
content (tar file or img file)
--disk-rm-part=ID remove partition ID from the guest disk
--disk-add-file=SRC:DST add file SRC as disk file DST in the xenguest image.
DST can then be used as a partition CONTENT.
--disk-rm-file=DST remove disk file DST from the xenguest image.
EOF
}
usage-create() {
cat <<EOF
Usage $this create XENGUEST [ARGS]
Create a xenguest image as XENGUEST file.
EOF
usage-update-create
}
usage-update() {
cat <<EOF
Usage $this update XENGUEST [ARGS]
Update or modify a xenguest image or a xenguest directory.
EOF
usage-update-create
}
usage-pack() {
cat <<EOF
Usage $this pack XENGUEST DESTFILE
Pack a xenguest directory in XENGUEST to create a xenguest image DESTFILE.
EOF
}
usage-partial() {
cat <<EOF
Usage $this partial XENGUEST [ARGS]
Update or modify a partial xenguest image.
EOF
usage-update-create
}
usage-dump-paramsconfig() {
cat <<EOF
Usage $this dump-paramsconfig XENGUEST
Dump the guest parameters of a xenguest image or directory
EOF
}
usage-dump-xenconfig() {
cat <<EOF
Usage $this dump-xenconfig XENGUEST
Dump the xen configuration of a xenguest image or directory
EOF
}
usage-dump-diskconfig() {
cat <<EOF
Usage $this dump-diskconfig XENGUEST
Dump the disk configuration of a xenguest image or directory
EOF
}
usage-extract() {
cat <<EOF
Usage $this extract XENGUEST DESTDIR
Extract guest to DESTDIR
EOF
}
usage-extract-config() {
cat <<EOF
Usage $this extract-config XENGUEST DESTDIR
Extract guest configuration to DESTDIR
EOF
}
usage-extract-disk-file() {
cat <<EOF
Usage $this extract-disk-file XENGUEST DISKFILE
Extract disk file DISKFILE to stdout.
EOF
}
check_image() {
local tstfile=${1}
if [ ! -e ${tstfile} -o ! -w ${tstfile} ]; then
echo "Error: File ${tstfile} does not exist or is not writeable"
exit 1
fi
if [ -f ${tstfile} ]; then
# This is a xenguest file
local res=$(tar -tvf ${tstfile} ./guest.cfg ./disk.cfg \
./params.cfg > /dev/null 2>&1 || echo "error")
if [ -n "${res}" ]; then
echo "Error: File ${tstfile} is not a valid xenguest"
exit 1
fi
elif [ -d ${tstfile} ]; then
if [ ! -f ${tstfile}/guest.cfg -o ! -f ${tstfile}/disk.cfg -o \
! ${tstfile}/params.cfg ]; then
echo "Error: Directory ${tstfile} is not a valid xenguest"
exit 1
fi
fi
}
params_config_reset() {
cat <<EOF > ${IMAGE_TMPDIR}/params.cfg
# Xenguest-image guest global configuration
#
# !! This file must not be modified manually !!
#
# You can use xenguest-image to modify parameters.
#
# Guest auto boot during Dom0 init
GUEST_AUTOBOOT="1"
EOF
}
params_config_setparam() {
param="${1}"
shift
value="$@"
if [ -z "$value" ]; then
sed -i "/.*${param}=.*/d" ${IMAGE_TMPDIR}/params.cfg
elif grep -e "^${param}=" ${IMAGE_TMPDIR}/params.cfg > /dev/null; then
sed -i "s/${param}=\".*\"/${param}=\"${value}\"/" \
${IMAGE_TMPDIR}/params.cfg
else
echo "${param}=\"${value}\"" >> ${IMAGE_TMPDIR}/params.cfg
fi
}
xen_config_reset() {
cat <<EOF > ${IMAGE_TMPDIR}/guest.cfg
# Xenguest-image main configuraiton
#
# !! This file must not be modified manually !!
#
# You can use xenguest-image to modify parameters.
#
# You can add custom entries to configuration in the guest.d directory.
# Guest name (set by manager when guest is created)
# name = ""
# Guest memory size in MB
memory = 1024
# Number of VCPUS
vcpus = 1
# Guest command line
extra = "earlyprintk=xenboot console=hvc0 rw"
# Guest root filesystem device (from guest point of view)
# root = "/dev/xvda2"
# Disk that will be used by the guest (set by manager when guest is created)
# disk = ['phy:/dev/vg-xen/guestname,xvda,w']
EOF
}
get_param_file() {
param="${1}"
if grep ${param} ${IMAGE_TMPDIR}/guest.cfg > /dev/null 2>&1; then
echo "${IMAGE_TMPDIR}/guest.cfg"
else
if [ ! -f ${IMAGE_TMPDIR}/guest.d/${param}.cfg ]; then
mkdir -p ${IMAGE_TMPDIR}/guest.d
echo "# ${param} = \"\"" > ${IMAGE_TMPDIR}/guest.d/${param}.cfg
fi
echo "${IMAGE_TMPDIR}/guest.d/${param}.cfg"
fi
}
xen_config_disable_param() {
param="${1}"
dst=$(get_param_file ${param})
sed -i "s@.*\(${param} = .*\)\$@# \1@" ${dst}
}
xen_config_set_number() {
param="${1}"
shift
value="$@"
dst=$(get_param_file ${param})
sed -i "s@.*${param} = .*@${param} = ${value}@" ${dst}
}
xen_config_set_string() {
param="${1}"
shift
value="$@"
dst=$(get_param_file ${param})
sed -i "s@.*${param} = .*@${param} = \"${value}\"@" ${dst}
}
xen_config_append_string() {
param="${1}"
shift
value="$@"
dst=$(get_param_file ${param})
sed -i "s@.*${param} = \"\([^\"]*\)\"@${param} = \"\1 ${value}\"@" ${dst}
}
xen_config_set_list() {
param="${1}"
shift
value=$(echo $@ | tr " " ",")
dst=$(get_param_file ${param})
sed -i "s@.*${param} = .*@${param} = ['${value}']@" ${dst}
}
disk_config_reset() {
echo "DISK_SIZE=\"0\"" > ${IMAGE_TMPDIR}/disk.cfg
echo "DISK_DEVICE=\"\"" >> ${IMAGE_TMPDIR}/disk.cfg
}
disk_config_rm_part() {
partid=$1
sed -i "/DISK_PART${partid}=.*/d" ${IMAGE_TMPDIR}/disk.cfg
}
is_integer() {
if ! [[ "${1}" =~ ^[0-9]+$ ]]; then
>&2 echo "error: invalid number '${1}'"; exit 1
fi
}
# check size and convert it to MB, e.g '1[G]' => '1000M'
check_size() {
local disksize="${1}"
[ -n "${disksize}" ] || disksize="invalid"
# disksize may have appended M or G suffix, let's extract it
# ${var:offset:length}, where #var is var length
local lastchar="${disksize:${#disksize}-1}"
case "${lastchar}" in
[0-9])
# backwards compatibility
is_integer "${disksize}"
echo -e "$((${disksize} * 1000))M"
return
;;
G|M)
if [ "${#disksize}" -gt "1" ]; then
local size="${disksize::${#disksize}-1}"
is_integer "${size}"
# convert GB to MB
[ "${lastchar}" = "M" ] || size=$((${size} * 1000))
echo -e "${size}M"
return
fi
;;
*)
;;
esac
>&2 echo -e "Invalid size format '${1}'" \
"\n\tSupported size format is e.g 1000M or 2[G]"
exit 1
}
disk_config_get_size() {
disksize=$(echo -e "$( . ${IMAGE_TMPDIR}/disk.cfg && echo $DISK_SIZE)")
check_size "${disksize}"
}
disk_config_get_parts() {
echo -e "$( . ${IMAGE_TMPDIR}/disk.cfg && \
typeset -p | awk '$3 ~ /^DISK_PART/ { print $3 }')"
}
disk_config_get_free_space() {
disk_usage="0"
for partinfo in $(disk_config_get_parts)
do
partsize=$(echo "${partinfo}" | cut -d '"' -f2 | sed -e "s/:.*//")
sizeMB=$(check_size "${partsize}")
[ -n "${sizeMB}" ] || exit 1
disk_usage=$((${sizeMB::${#sizeMB}-1} + $disk_usage))
done
disk_size=$(disk_config_get_size)
echo -e "$((${disk_size::${#disk_size}-1} - ${disk_usage}))M"
}
disk_check_partition_format() {
local partformat="${1}"
# if partformat is not defined let's skip this check
[ -n "${partformat}" ] || return 0
case "${partformat}" in
vfat|ext2|ext3|ext4|swap)
;;
*)
# invalid/unknown fstype
echo "Invalid file fstype ${partformat}"
exit 1
;;
esac
}
disk_check_partition_content() {
local partcontent="${1}"
# if partcontent is not defined let's skip this check
[ -n "${partcontent}" ] || return 0
case "${partcontent}" in
*.img*)
case "${partcontent}" in
*.img.gz|*.img.bz2|*.img)
;;
*)
# invalid/unknown compression type
echo "Invalid file format in disk ${partcontent}"
exit 1
;;
esac
;;
*.tar*)
case "${partcontent}" in
*.tar.gz|*.tar.bz2|*.tar.xz|*.tar)
;;
*)
# invalid/unknown tar type
echo "Invalid file format in disk ${partcontent}"
exit 1
;;
esac
;;
*)
#invalid content type
echo "Unsupported content type ${partcontent}!"
exit 1
;;
esac
# do not allow to create multiple partitions the same content
if grep ":${partcontent}\"" <<< "$(disk_config_get_parts)"; then
echo "Error ${partcontent} is already inside guest image"
exit 1
fi
}
disk_config_add_part() {
partconf="${1}"
partid=$(echo ${partconf} | sed -e "s/:.*//")
partinfo=$(echo ${partconf} | sed -e "s/[^:]*://")
partsize=$(echo ${partinfo} | cut -d ":" -f1)
partformat=$(echo ${partinfo} | cut -d ":" -f2)
partcontent=$(echo ${partinfo} | cut -d ":" -f3)
# check size "ID:*SIZE*:FORMAT:CONTENT"
partsizeMB=$(check_size "${partsize}")
# Make sure we don't add the same partition twice
disk_config_rm_part "${partid}"
# check available disk space
freespace=$(disk_config_get_free_space)
if ((${partsizeMB::${#partsizeMB}-1} > ${freespace::${#freespace}-1}))
then
echo -e "Not enough free disk space(${freespace}) for partition "\
"'${partconf}'!"\
"\tTo adjust disk size use '--disk-size' parameter"\
"\tor shrink the partition with '--disk-add-part' parameter"
exit 1
fi
# check format "ID:SIZE:*FORMAT*:CONTENT"
disk_check_partition_format "${partformat}"
# check content "ID:SIZE:FORMAT:*CONTENT*"
disk_check_partition_content "${partcontent}"
echo "DISK_PART${partid}=\"${partinfo}\"" >> \
${IMAGE_TMPDIR}/disk.cfg
}
# We need an action as first argument
action="${1:-}"
if [ -z "${action}" ]; then
echo "Error: No ACTION provided"
usage
exit 1
fi
# Only help does not require a xenguest argument so treat this first
# while there we also check that user is asking for a supported action
case $action in
help|--help|-h|-?)
usage
exit 0
;;
check|create|update|pack|partial)
;;
dump-xenconfig|dump-diskconfig|dump-init|dump-paramsconfig)
;;
extract|extract-config|extract-disk-file)
;;
*)
echo "Error: Invalid action $action"
exit 1
;;
esac
# Second argument should be the file name or directory
guestfile="${2:-}"
# Handle user asking for help on a specific action
case $guestfile in
help|--help|-h|-?)
usage-${action}
exit 0
;;
esac
if [ -z "${guestfile}" ]; then
echo "Error: no GUESTFILE provided"
usage
exit 1
fi
shift 2
case ${action} in
check)
check_image ${guestfile}
echo "Image is OK"
exit 0
;;
dump-paramsconfig)
check_image ${guestfile}
echo "Guest configuration:"
if [ -f ${guestfile} ]; then
tar -xOf ${guestfile} ./params.cfg
else
cat ${guestfile}/params.cfg
fi
exit 0
;;
dump-xenconfig)
check_image ${guestfile}
echo "Xen configuration:"
if [ -f ${guestfile} ]; then
tar -xOf ${guestfile} ./guest.cfg
tar -xOf ${guestfile} ./guest.d 2> /dev/null || true
else
cat ${guestfile}/guest.cfg
cat ${guestfile}/guest.d/* 2> /dev/null || true
fi
echo
exit 0
;;
dump-diskconfig)
check_image ${guestfile}
echo "Disk configuration:"
if [ -f ${guestfile} ]; then
tar -xOf ${guestfile} ./disk.cfg
else
cat ${guestfile}/disk.cfg
fi
echo
exit 0
;;
dump-init)
check_image ${guestfile}
for init in init.d init-pre init-post; do
echo "=== ${init} ==="
if [ -f ${guestfile} ]; then
tar -xOf ${guestfile} ./${init} 2> /dev/null || \
echo "No ${init} scripts."
else
cat ${guestfile}/${init}/* 2> /dev/null || \
echo "No ${init} scripts."
fi
echo "==============="
echo
done
exit 0
;;
pack)
check_image ${guestfile}
if [ ! -d ${guestfile} ]; then
echo "Error: Pack can only be done on a xenguest directory"
exit 1
fi
if [ -z "${1:-}" ] || [ -f ${1} ]; then
echo "Error: No destination file or already existing file"
exit 1
fi
tar -C ${guestfile} -cf ${1} .
exit 0
;;
extract)
check_image ${guestfile}
if [ -d ${guestfile} ]; then
echo "Error: Cannot extract config from xenguest directory"
exit 1
fi
if [ -z "${1:-}" ] || [ ! -d ${1} ]; then
echo "Error: No destination directory for image extract"
exit 1
fi
tar -C ${1} -xf ${guestfile}
exit 0
;;
extract-config)
check_image ${guestfile}
if [ -d ${guestfile} ]; then
echo "Error: Cannot extract config from xenguest directory"
exit 1
fi
if [ -z "${1:-}" ] || [ ! -d ${1} ]; then
echo "Error: No destination directory for config extract"
exit 1
fi
#extract all but disk files
tar -C ${1} --exclude='./disk' -xf ${guestfile}
exit 0
;;
extract-disk-file)
check_image ${guestfile}
if [ -d ${guestfile} ]; then
echo "Error: Cannot extract disk file from xenguest directory" >&2
exit 1
fi
if [ -z "${1:-}" ]; then
echo "Error: No file to extract" >&2
exit 1
fi
tar -xOf ${guestfile} ./disk/${1}
exit 0
;;
create)
if [ -f ${guestfile} ]; then
echo "Error: File ${guestfile} already exist"
exit 1
elif [ -d ${guestfile} ]; then
if [ -n "$(ls -A ${guestfile})" ]; then
echo "Error: Directory ${guestfile} is not empty"
exit 1
fi
IMAGE_TMPDIR=$(realpath -m ${guestfile})
else
IMAGE_TMPDIR=$(mktemp -d)
fi
# Create initial content
params_config_reset
xen_config_reset
disk_config_reset
;;
update)
check_image ${guestfile}
if [ -f ${guestfile} ]; then
# Extract the image to update it
IMAGE_TMPDIR=$(mktemp -d)
tar -C ${IMAGE_TMPDIR} -xf ${guestfile}
else
IMAGE_TMPDIR=$(realpath -m ${guestfile})
fi
;;
partial)
if [ -e ${guestfile} -a ! -d ${guestfile} ]; then
echo "Error: Invalid partial output directory"
exit 1
fi
mkdir -p ${guestfile}
IMAGE_TMPDIR=$(realpath -m ${guestfile})
;;
*)
echo "Invalid action ${action}"
usage
exit 1
;;
esac
# Process command line arguments
for arg in "${@}"; do
case ${arg} in
--*=*)
optarg=$(echo ${arg} | sed -e "s/[^=]*=//")
;;
*)
optarg=""
;;
esac
case ${arg} in
--guest-reset-config)
params_config_reset
;;
--set-param=*=*)
param_name=$(echo $optarg | sed -e "s/=.*//")
param_value=$(echo $optarg | sed -e "s/[^=]*=//")
params_config_setparam "$param_name" "$param_value"
;;
--set-param=*)
params_config_setparam "$optarg"
;;
--xen-reset-config)
xen_config_create
;;
--xen-name=*)
if [ -z "${optarg}" ]; then
xen_config_disable_param "name"
else
xen_config_set_string "name" "${optarg}"
fi
;;
--xen-kernel=*)
if [ -z "${optarg}" ]; then
xen_config_disable_param "kernel"
rm -f ${IMAGE_TMPDIR}/files/kernel
else
if [ ! -f ${optarg} ]; then
echo "Error: invalid kernel file ${optarg}"
exit 1
fi
xen_config_set_string "kernel" "files/kernel"
mkdir -p ${IMAGE_TMPDIR}/files
install -m 644 ${optarg} ${IMAGE_TMPDIR}/files/kernel
fi
;;
--xen-memory=*)
xen_config_set_number "memory" ${optarg}
;;
--xen-vcpus=*)
xen_config_set_number "vcpus" ${optarg}
;;
--xen-clean-extra)
xen_config_set_string "extra" ""
;;
--xen-extra=*)
xen_config_append_string "extra" ${optarg}
;;
--xen-root=*)
if [ -z "${optarg}" ]; then
xen_config_disable_param "root"
else
xen_config_set_string "root" "${optarg}"
fi
;;
--xen-device-tree=*)
if [ -z "${optarg}" ]; then
xen_config_disable_param "device_tree"
rm -f ${IMAGE_TMPDIR}/files/guest.dtb
else
if [ ! -f ${optarg} ]; then
echo "Error: invalid dtb file ${optarg}"
exit 1
fi
xen_config_set_string "device_tree" "files/guest.dtb"
mkdir -p ${IMAGE_TMPDIR}/files
install -m 644 ${optarg} ${IMAGE_TMPDIR}/files/guest.dtb
fi
;;
--xen-ramdisk=*)
if [ -z "${optarg}" ]; then
xen_config_disable_param "ramdisk"
rm -f ${IMAGE_TMPDIR}/files/ramdisk.img
else
if [ ! -f ${optarg} ]; then
echo "Error: invalid ramdisk file ${optarg}"
exit 1
fi
xen_config_set_string "ramdisk" "files/ramdisk.img"
mkdir -p ${IMAGE_TMPDIR}/files
install -m 644 ${optarg} ${IMAGE_TMPDIR}/files/ramdisk.img
fi
;;
--xen-disk=*)
if [ -z "${optarg}" ]; then
xen_config_disable_param "disk"
else
xen_config_set_list "disk" "phy:${optarg}" "xvda" "w"
fi
;;
--xen-append=*)
if [ ! -f ${optarg} ]; then
echo "Error: invalid xen append file ${optarg}"
exit 1
fi
mkdir -p ${IMAGE_TMPDIR}/guest.d
install -m 755 ${optarg} ${IMAGE_TMPDIR}/guest.d/.
;;
--xen-add-file=*)
src=$(echo "${optarg}" | sed -e "s/:.*//")
dst=$(echo "${optarg}" | sed -e "s/.*://")
if [ ! -f ${src} ]; then
echo "Error: Invalid file: ${src}"
rm -rf ${IMAGE_TMPDIR}
exit 1
fi
if [ -z "${dst}" ]; then
dst=$(basename ${src})
fi
mkdir -p ${IMAGE_TMPDIR}/files/$(dirname ${dst})
cp -f ${src} ${IMAGE_TMPDIR}/files/${dst}
;;
--xen-rm-file=*)
rm -f ${IMAGE_TMPDIR}/files/${optarg}
;;
--init-script=*|--init-pre=*|--init-post=*)
dst=""
case $arg in
--init-script=*)
dst="init.d"
;;
--init-pre=*)
dst="init.pre"
;;
--init-post=*)
dst="init.post"
;;
esac
if [ ! -f ${optarg} ]; then
echo "${optarg} does not point to a valid file"
exit 1
else
mkdir -p ${IMAGE_TMPDIR}/${dst}
install -m 755 ${optarg} ${IMAGE_TMPDIR}/${dst}/.
fi
;;
--disk-reset-config)
disk_config_reset
;;
--disk-size=*)
size=$(check_size "${optarg}")
[ -n "size" ] || exit 1
sed -i "s/DISK_SIZE=.*/DISK_SIZE=\"${size}\"/" \
${IMAGE_TMPDIR}/disk.cfg
;;
--disk-device=*)
sed -i "s@DISK_DEVICE=.*@DISK_DEVICE=\"${optarg}\"@" \
${IMAGE_TMPDIR}/disk.cfg
;;
--disk-add-part=*)
disk_config_add_part ${optarg}
;;
--disk-rm-part=*)
disk_config_rm_part ${optarg}
;;
--disk-add-file=*)
src=$(echo "${optarg}" | sed -e "s/:.*//")
dst=$(echo "${optarg}" | sed -e "s/.*://")
if [ ! -f ${src} ]; then
echo "Error: Invalid disk file: ${src}"
rm -rf ${IMAGE_TMPDIR}
exit 1
fi
if [ -z "${dst}" ]; then
dst=$(basename ${src})
fi
mkdir -p ${IMAGE_TMPDIR}/disk/$(dirname ${dst})
cp -f ${src} ${IMAGE_TMPDIR}/disk/${dst}
;;
--disk-rm-file=*)
rm -f ${IMAGE_TMPDIR}/disk/${optarg}
;;
*)
echo "Unsupported command: ${arg}"
exit 1
;;
esac
done
if [ ! -d ${guestfile} ]; then
# If the original guest was in a file we need to repack the file
# with the changes we did on it in the IMAGE_TMPDIR
rm -f ${guestfile}
tar -C ${IMAGE_TMPDIR} -cf ${guestfile} .
rm -rf ${IMAGE_TMPDIR}
fi

3
meta-arm-autonomy/recipes-extended/xenguest/files/xenguest-network-bridge-dhcp.cfg.in
View File

@@ -1,3 +0,0 @@
# Xenguest Network Bridge interface configuration
auto ###BRIDGE_NAME###
iface ###BRIDGE_NAME### inet dhcp

44
meta-arm-autonomy/recipes-extended/xenguest/files/xenguest-network-bridge.in
View File

@@ -1,44 +0,0 @@
#!/bin/sh
#
# Xenguest Network Bridge init
# This script creates a network bridge and add host interfaces to it
# It will then be used by xen guests to connect to the external nework
#
INTFS="###BRIDGE_MEMBERS###"
BR_INTF="###BRIDGE_NAME###"
case "$1" in
start)
echo "Starting $BR_INTF"
brctl addbr $BR_INTF
for intf in $INTFS; do
echo "Adding $intf to $BR_INTF"
brctl addif $BR_INTF $intf
done
;;
status)
true
;;
stop)
echo "Stopping $BR_INTF"
ifdown $BR_INTF
brctl delbr $BR_INTF
;;
reload)
echo >&2 'Reload not available; use force-reload'; exit 1
;;
force-reload|restart)
echo "Restarting host-bridge"
$0 stop
$0 start
;;
*)
# do not advertise unreasonable commands that there is no reason
# to use with this device
echo "Usage: $0 {start|stop|status|restart|force-reload}"
exit 1
esac
exit $?

45
meta-arm-autonomy/recipes-extended/xenguest/files/xenguest-network-init-post.sh
View File

@@ -1,45 +0,0 @@
#!/bin/sh
# This script is to reload kea dhcp4 server when guest interface will be ready
# include locking functions
. /etc/xen/scripts/locking.sh
set +u
# $1 is vif name, e.g. "vif/15/0"
# returns 0 on success,
# 1 otherwize
#
check_if_vif_is_ready() {
ret=$(xl network-list "${guestname:?}" | grep "${1}" \
| tr -s ' ' | cut -d' ' -f5)
# ${ret} is network interface status value
# 1 means vif is not ready
# 4 means vif is ready
[ "${ret}" = "4" ] && return 0
return 1
}
case "${XENGUEST_NETWORK_TYPE:-}" in
nat)
vif_name="$(xl network-list "${guestname:?}" | grep -o "vif.*")"
for try in $(seq 20)
do
if check_if_vif_is_ready "${vif_name}"; then
claim_lock "vif-nat-kea"
keactrl reload
release_lock "vif-nat-kea"
exit 0
fi
log info "Waiting for ${vif_name} - network interface is not ready..."
log info "try #${try}"
sleep 1
done
log error "Failed to get ${vif_name}. network interface ready!"
exit 1
;;
*)
log verbose "No action needed"
;;
esac

157
meta-arm-autonomy/recipes-extended/xenguest/xenguest-base-image.bb
View File

@@ -1,157 +0,0 @@
# Create a xenguest base image
#
# This recipe creates a base image that is then extended by other recipes
# through xenguest_image class.
# xenguest image type uses this recipe as a base to add a kernel and a disk
# image to create a guest
#
# The recipe also adds files in those directories to the xenguest image:
# - ${WORKDIR}/extend/disk-files: all files in this directory will be added to
# the guest disk files (using --disk-add-file)
# - ${WORKDIR}/extend/files: all files in this directory will be added to the
# guest xen files (using --xen-add-file)
# - ${WORKDIR}/extend/guest.d: all files in this directory will be added to
# the xen append configuration files (using --xen-append)
# - ${WORKDIR}/extend/init.[pre|post|d]: all files in those directories will
# be added to the corresponding init scripts (using --init-[pre|post|script])
# You can bbappend this recipe and put files in ${WORKDIR}/extend to add
# elements to the image.
#
DESCRIPTION = "Xenguest Base Image"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
# When XENGUEST_IMAGE_NETWORK_TYPE="nat", the "00-xenguest-nat-port-forward.hook"
# is called by "/etc/xen/scripts/vif-post.d/00-vif-xenguest.hook" to apply NAT
# port forwarding. Both dom0 and domU ports can be be set by changing the
# XENGUEST_IMAGE_HOST_PORT and XENGUEST_IMAGE_GUEST_PORT variables in local.conf
# or xenguest-base-image.bbappend. The XENGUEST_IMAGE_NAT_PORT_FORWARD_SCRIPT
# can also be replaced in a xenguest-base-image.bbappend
XENGUEST_IMAGE_HOST_PORT ?= "\$( expr 1000 + \${domid} )"
XENGUEST_IMAGE_GUEST_PORT ?= "22"
XENGUEST_IMAGE_NAT_PORT_FORWARD_SCRIPT ?= "00-xenguest-nat-port-forward.hook"
#
# The following variables can contain SRC_URI compatible entries to add
# files to the xenguest image.
# You can set those variable in local.conf to add one or several files
# For example to add a boot.tar.gz file that has to be downloaded to the file
# useable for disk partition initialisation:
# XENGUEST_IMAGE_SRC_URI_DISK_FILES += "https://www.test.com/files/boot.tar.gz"
# Add disk files
XENGUEST_IMAGE_SRC_URI_DISK_FILES ??= ""
# Add xen files
# Any extrafiles files to be added to XENGUEST_IMAGE_SRC_URI_XEN_FILES should
# be performed via XENGUEST_IMAGE_SRC_URI_XEN_FILES:append.
# The kea-subnet4.json holds the kea dhcp4 subnet configuration for Dom0.
# And it is used when XENGUEST_IMAGE_NETWORK_TYPE="nat".
# Any customizations to it should be performed by replacing it
# via a xenguest-network.bbappend.
# The XENGUEST_IMAGE_NAT_PORT_FORWARD_SCRIPT file is only added if the
# variable is set.
XENGUEST_IMAGE_SRC_URI_XEN_FILES = "file://kea-subnet4.json \
${@ "file://" + d.getVar('XENGUEST_IMAGE_NAT_PORT_FORWARD_SCRIPT') \
if d.getVar('XENGUEST_IMAGE_NAT_PORT_FORWARD_SCRIPT') else "" } \
"
# Add xen configuration elements
XENGUEST_IMAGE_SRC_URI_XEN_CONFIG ??= ""
# Add pre init script
XENGUEST_IMAGE_SRC_URI_INIT_PRE ??= ""
# Add init script
XENGUEST_IMAGE_SRC_URI_INIT ??= ""
# Add post init script
XENGUEST_IMAGE_SRC_URI_INIT_POST ??= ""
S = "${WORKDIR}"
# Extra vars to add to xenguest.env
XENGUEST_IMAGE_VARS_EXTRA += "\
XENGUEST_IMAGE_HOST_PORT XENGUEST_IMAGE_GUEST_PORT \
XENGUEST_IMAGE_NAT_PORT_FORWARD_SCRIPT XENGUEST_IMAGE_SRC_URI_DISK_FILES \
XENGUEST_IMAGE_SRC_URI_XEN_FILES XENGUEST_IMAGE_SRC_URI_XEN_CONFIG \
XENGUEST_IMAGE_SRC_URI_INIT_PRE XENGUEST_IMAGE_SRC_URI_INIT \
XENGUEST_IMAGE_SRC_URI_INIT_POST"
inherit deploy xenguest_image
# parse XENGUEST_IMAGE_SRC_URI_ variables and add them to SRC_URI
python __anonymous() {
def parse_extend_variable(d, varname, destdir):
list = d.getVar(varname)
if list:
for entry in list.split():
#Check the URL
try:
decode = bb.fetch.decodeurl(entry)
d.appendVar('SRC_URI', ' ' + entry + ';unpack=0;subdir=extend/' + destdir)
except:
bb.fatal("%s: %s contains an invalid URL: %s" \
% (d.getVar('PF'), varname, entry))
parse_extend_variable(d, 'XENGUEST_IMAGE_SRC_URI_DISK_FILES', 'disk-files')
parse_extend_variable(d, 'XENGUEST_IMAGE_SRC_URI_XEN_FILES', 'files')
parse_extend_variable(d, 'XENGUEST_IMAGE_SRC_URI_XEN_CONFIG', 'guest.d')
parse_extend_variable(d, 'XENGUEST_IMAGE_SRC_URI_INIT_PRE', 'init.pre')
parse_extend_variable(d, 'XENGUEST_IMAGE_SRC_URI_INIT', 'init.d')
parse_extend_variable(d, 'XENGUEST_IMAGE_SRC_URI_INIT_POST', 'init.post')
}
# Make sure we are removing old files before redoing a fetch
do_fetch[cleandirs] += "${WORKDIR}/extend"
do_fetch[vardeps] += "XENGUEST_IMAGE_HOST_PORT XENGUEST_IMAGE_GUEST_PORT"
do_compile[noexec] = "1"
do_install[noexec] = "1"
add_extend_files() {
local subdir="$1"
local cmd="$2"
local stripdest="${3:-n}"
if [ -d ${WORKDIR}/extend/$subdir ]; then
filelist=$(find ${WORKDIR}/extend/$subdir -type f)
if [ -n "$filelist" ]; then
for f in $filelist; do
if [ "$stripdest" = "y" ]; then
call_xenguest_mkimage update --$cmd=$f:$(basename $f)
else
call_xenguest_mkimage update --$cmd=$f
fi
done
fi
fi
}
do_configure() {
if [ -f ${WORKDIR}/extend/files/${XENGUEST_IMAGE_NAT_PORT_FORWARD_SCRIPT} ]; then
sed -i "s,###HOST_PORT###,${XENGUEST_IMAGE_HOST_PORT}," \
${WORKDIR}/extend/files/${XENGUEST_IMAGE_NAT_PORT_FORWARD_SCRIPT}
sed -i "s,###GUEST_PORT###,${XENGUEST_IMAGE_GUEST_PORT}," \
${WORKDIR}/extend/files/${XENGUEST_IMAGE_NAT_PORT_FORWARD_SCRIPT}
fi
}
do_deploy() {
# Create a new image
xenguest_image_create
# Add our extra files if any
add_extend_files "disk-files" "disk-add-file" "y"
add_extend_files "files" "xen-add-file" "y"
add_extend_files "guest.d" "xen-append"
add_extend_files "init.pre" "init-pre"
add_extend_files "init.d" "init-script"
add_extend_files "init.post" "init-post"
}
addtask deploy after do_install before do_build

85
meta-arm-autonomy/recipes-extended/xenguest/xenguest-extern-guests.bb
View File

@@ -1,85 +0,0 @@
# Xenguest Extern Guests
#
# This recipe installs the extern guest files specified in
# ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS into the host image, They are installed
# to the directory XENGUEST_MANAGER_GUEST_DIR
#
# src_uri_parse_var.bbclass is used to parse
# ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS and add the guest paths to the SRC_URI
# to be fetched and unpacked to ${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}
#
# Further documentation can be found in documentation/arm-autonomy-quickstart.md,
# in the section named "Include guests directly in the host image"
DESCRIPTION = "Xenguest Extern Guests"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
# Global value of XENGUEST_MANAGER_GUEST_DIR set here
require conf/xenguest.conf
ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS ??= ""
# Parse the variable ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS for xenguest files,
# unpack them to SRC_URI_FROM_VAR_UNPACK_DIR and create a manifest file
# containing each of SRC_URI_FROM_VAR_MANIFEST_PARAMS for each entry
inherit set_src_uri_from_var
SRC_URI_FROM_VAR_NAME = "ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS"
SRC_URI_FROM_VAR_MANIFEST_PARAMS= "guestname=[basename] guestcount=1"
SRC_URI_FROM_VAR_UNPACK_DIR = "xenguests"
# Unnecessary tasks
do_compile[noexec] = "1"
do_configure[noexec] = "1"
do_patch[noexec] = "1"
# Install guest files to XENGUEST_MANAGER_GUEST_DIR
do_install() {
local guestfile guestname guestcount
if [ -f "${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/manifest" ]; then
install -d "${D}${XENGUEST_MANAGER_GUEST_DIR}"
# Iterate over manifest file containing parameters
while read -r guestfile guestname guestcount _; do
[ -f "${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/${guestfile}" ] ||
bbfatal "${guestfile} does not exist"
install -m 644 \
"${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/${guestfile}" \
"${D}${XENGUEST_MANAGER_GUEST_DIR}/${guestname}.xenguest"
# Create symlinks for duplicate guests, appending numbers to
# guestname
for i in `seq 2 $guestcount`
do
ln -s -r \
"${D}${XENGUEST_MANAGER_GUEST_DIR}/${guestname}.xenguest" \
"${D}${XENGUEST_MANAGER_GUEST_DIR}/${guestname}$i.xenguest"
done
done < "${WORKDIR}/${SRC_URI_FROM_VAR_UNPACK_DIR}/manifest"
fi
}
do_install[vardeps] += "ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS"
FILES:${PN} += "${XENGUEST_MANAGER_GUEST_DIR}"
# In a multiconfig build this variable will hold a dependency string, which
# differs based on whether the guest has initramfs or not. It may have a space
# seperated list of dependency strings if mulitple guest types are configured
MC_DOIMAGE_MCDEPENDS ?= ""
# Example value: mc:host:guest:core-image-minimal:do_merge_xenguestenv
# In a multiconfig build the host task 'do_image' has a dependency on
# multiconfig guest. This ensures that the guest image file already exists
# when it is needed by the host
DO_IMAGE_MCDEPENDS := "${@ '${MC_DOIMAGE_MCDEPENDS}' \
if d.getVar('BBMULTICONFIG') else ''}"
# Apply mc dependency. Empty string if multiconfig not enabled
do_fetch[mcdepends] += "${DO_IMAGE_MCDEPENDS}"

63
meta-arm-autonomy/recipes-extended/xenguest/xenguest-manager.bb
View File

@@ -1,63 +0,0 @@
# Xenguest manager recipe
#
# xenguest-manager is a tool to control xen guests (e.g. create, start, stop)
#
# Usage documentation for the xenguest-manager tool can be found in
# meta-arm-autonomy/documentation/xenguest-manager.md including the
# customizable bitbake variables.
DESCRIPTION = "Xen Guest Manager"
LICENSE = "MIT"
SRC_URI = " \
file://xenguest-manager \
file://xenguest-init \
file://logrotate-xenguest \
"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
S = "${WORKDIR}"
XENGUEST_MANAGER_VOLUME_DEVICE ?= "/dev/sda2"
XENGUEST_MANAGER_VOLUME_NAME ?= "vg-xen-$(basename ${XENGUEST_MANAGER_VOLUME_DEVICE})"
XENGUEST_MANAGER_LOG_LEVEL ?= "ERROR"
#XENGUEST_MANAGER_GUEST_DIR set in xenguest.conf
require conf/xenguest.conf
# We add an init script to create and start guests automatically
# run start script after xen-tools and run stop script before xen-tools
INITSCRIPT_NAME = "xenguest"
INITSCRIPT_PARAMS = "start 90 2 3 4 5 . stop 79 0 1 6 ."
inherit allarch update-rc.d
do_compile() {
echo "XENGUEST_VOLUME_DEVICE=\"${XENGUEST_MANAGER_VOLUME_DEVICE}\"" > \
xenguest-manager.conf
echo "XENGUEST_VOLUME_NAME=\"${XENGUEST_MANAGER_VOLUME_NAME}\"" >> \
xenguest-manager.conf
echo "XENGUEST_GUEST_DIR=\"${XENGUEST_MANAGER_GUEST_DIR}\"" >> \
xenguest-manager.conf
echo "XENGUEST_LOG_LEVEL=\"${XENGUEST_MANAGER_LOG_LEVEL}\"" >> \
xenguest-manager.conf
}
do_install() {
install -d -m 755 ${D}${bindir}
install -m 755 xenguest-manager ${D}${bindir}/.
install -d -m 755 ${D}${sysconfdir}/xenguest
install -m 644 xenguest-manager.conf ${D}${sysconfdir}/xenguest/.
install -d -m 755 ${D}${sysconfdir}/init.d
install -m 755 xenguest-init ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
install -d -m 755 ${D}${XENGUEST_GUEST_DIR}
install -d -m 755 ${D}${sysconfdir}/logrotate.d
install -m 644 logrotate-xenguest ${D}${sysconfdir}/logrotate.d/xenguest
}
# Things that we need on the target
RDEPENDS:${PN} += "bash xenguest-mkimage lvm2 xen-tools parted e2fsprogs \
dosfstools logrotate"
FILES:${PN} += "${bindir}/xenguest-manager \
${sysconfdir}/xenguest"

36
meta-arm-autonomy/recipes-extended/xenguest/xenguest-mkimage.bb
View File

@@ -1,36 +0,0 @@
# Xenguest mkimage recipe
#
# xenguest-mkimage is a tool to create/modify images to be used as xen guests
# Produced images contains a xen configuration and several optional components
# (kernel, device-tree, disk definition and files, and init scripts) which all
# together fully define a xen guest image
#
# Usage documentation for the xenguest-mkimage tool can be found in
# meta-arm-autonomy/documentation/xenguest-mkimage.md
DESCRIPTION = "Xenguest mkimage tool"
LICENSE = "MIT"
SRC_URI = "file://xenguest-mkimage"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
S = "${WORKDIR}"
# Can be built native also to produce xenguest images during Yocto build
BBCLASSEXTEND = "native"
inherit allarch
do_configure[noexec] = "1"
do_compile[noexec] = "1"
do_install() {
install -d -m 755 ${D}${bindir}
install -m 755 xenguest-mkimage ${D}${bindir}/.
}
# We need bash
RDEPENDS:${PN} = "bash"
FILES:${PN} = "${bindir}/xenguest-mkimage"

96
meta-arm-autonomy/recipes-extended/xenguest/xenguest-network.bb
View File

@@ -1,96 +0,0 @@
# Recipe to handle xenguest network configuration
DESCRIPTION = "Xenguest Network"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
S = "${WORKDIR}"
# Please refer to documentation/xenguest-network-bridge.md for documentation on
# the parameters available for customization
XENGUEST_NETWORK_BRIDGE_NAME ?= "xenbr0"
# The XENGUEST_NETWORK_BRIDGE_MEMBERS should be set in a machine.conf
# or bbappend file.
#XENGUEST_NETWORK_BRIDGE_MEMBERS ?= "eth0"
XENGUEST_NETWORK_BRIDGE_CONFIG ?= "xenguest-network-bridge-dhcp.cfg.in"
SRC_URI = " \
file://xenguest-network-bridge.in \
file://xenguest-network-bridge-dhcp.cfg.in \
file://network-bridge.sh.in \
file://00-vif-xenguest.hook \
file://xenguest-network-init-post.sh \
file://kea-dhcp4.conf \
file://kea-restore-default-config \
"
PACKAGES =+ "${PN}-kea-dhcp4"
# Bridge configurator needs to run before S01networking init script
# Prefix with a_ to make sure it is executed in runlevel 01 before others
# run start script before ifupdown and run stop script after ifupdown
INITSCRIPT_PACKAGES = "${PN} ${PN}-kea-dhcp4"
INITSCRIPT_NAME:${PN} = "a_xenguest-network-bridge"
INITSCRIPT_PARAMS:${PN} = "start 01 2 3 4 5 . stop 81 0 1 6 ."
# Kea configuration needs to be restored before kea init scripts:
# Kea dhcp4 server is 30, so lets use 20, to have higher priority
INITSCRIPT_NAME:${PN}-kea-dhcp4 = "kea-restore-default-config"
INITSCRIPT_PARAMS:${PN}-kea-dhcp4 = "defaults 20"
inherit allarch update-rc.d
do_install() {
cat ${WORKDIR}/xenguest-network-bridge.in \
| sed -e "s,###BRIDGE_MEMBERS###,${XENGUEST_NETWORK_BRIDGE_MEMBERS}," \
| sed -e "s,###BRIDGE_NAME###,${XENGUEST_NETWORK_BRIDGE_NAME}," \
> ${WORKDIR}/xenguest-network-bridge
cat ${WORKDIR}/${XENGUEST_NETWORK_BRIDGE_CONFIG} \
| sed -e "s,###BRIDGE_NAME###,${XENGUEST_NETWORK_BRIDGE_NAME}," \
> ${WORKDIR}/xenguest-network-bridge.cfg
cat ${WORKDIR}/network-bridge.sh.in \
| sed -e "s,###BRIDGE_NAME###,${XENGUEST_NETWORK_BRIDGE_NAME}," \
> ${WORKDIR}/network-bridge.sh
install -d -m 755 ${D}${sysconfdir}/init.d
install -m 755 ${WORKDIR}/xenguest-network-bridge \
${D}${sysconfdir}/init.d/${INITSCRIPT_NAME:${PN}}
install -d -m 755 ${D}${sysconfdir}/network/interfaces.d
install -m 755 ${WORKDIR}/xenguest-network-bridge.cfg \
${D}${sysconfdir}/network/interfaces.d/.
install -d -m 755 ${D}${sysconfdir}/xenguest/init.pre
install -m 755 ${WORKDIR}/network-bridge.sh \
${D}${sysconfdir}/xenguest/init.pre/.
install -d ${D}${sysconfdir}/xen/scripts/vif-post.d
install -m 755 ${WORKDIR}/00-vif-xenguest.hook \
${D}${sysconfdir}/xen/scripts/vif-post.d/.
install -d -m 755 ${D}${sysconfdir}/xenguest/init.post
install -m 755 ${WORKDIR}/xenguest-network-init-post.sh \
${D}${sysconfdir}/xenguest/init.post/.
install -m 755 ${WORKDIR}/kea-restore-default-config \
${D}${sysconfdir}/init.d/.
install -d -m 755 ${D}${sysconfdir}/kea/
install -m 755 ${WORKDIR}/kea-dhcp4.conf \
${D}${sysconfdir}/kea/kea-dhcp4.conf.original
}
RDEPENDS:${PN} += "bridge-utils \
iptables \
kea \
${PN}-kea-dhcp4 \
kernel-module-xt-tcpudp \
kernel-module-xt-physdev \
kernel-module-xt-comment \
kernel-module-xt-nat \
kernel-module-xt-masquerade \
"
FILES:${PN} += "${sysconfdir}/network/interfaces.d/xenguest-network-bridge.cfg"
FILES:${PN} += "${sysconfdir}/xenguest/init.pre/network-bridge.sh"
FILES:${PN} += "${sysconfdir}/xen/scripts/vif-post.d/00-vif-xenguest.hook"
FILES:${PN}-kea-dhcp4 = "${sysconfdir}/kea/kea-dhcp4.conf.original"
FILES:${PN}-kea-dhcp4 += "${sysconfdir}/init.d/${INITSCRIPT_NAME:${PN}-kea-dhcp4}"
FILES:${PN}-kea-dhcp4 += "${sysconfdir}/xenguest/init.post/xenguest-network-init-post.sh"

38
meta-arm-autonomy/recipes-extended/xenguest/xenguest-nodisk-image.bb
View File

@@ -1,38 +0,0 @@
# Create a xenguest image with kernel but no rootfs or an external rootfs
DESCRIPTION = "Xenguest No Disk Image"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
S = "${WORKDIR}"
inherit deploy xenguest_image
# Name of the file we create in deploy
XENGUEST_IMAGE_NODISK_DEPLOY = "xenguest-nodisk-image.xenguest"
# use a local copy to pack all together
XENGUEST_IMAGE_DEPLOY_DIR = "${WORKDIR}/tmp-xenguest"
do_configure[noexec] = "1"
do_compile[noexec] = "1"
do_install[noexec] = "1"
do_deploy() {
xenguest_image_clone
# Add kernel to the image
if [ -n "${XENGUEST_IMAGE_KERNEL}" ]; then
call_xenguest_mkimage partial \
--xen-kernel=${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_KERNEL}
fi
# Pack and deploy the final image
rm -f ${DEPLOYDIR}/${XENGUEST_IMAGE_NODISK_DEPLOY}
call_xenguest_mkimage pack ${DEPLOYDIR}/${XENGUEST_IMAGE_NODISK_DEPLOY}
}
do_deploy[depends] += "virtual/kernel:do_deploy"
do_deploy[depends] += "xenguest-base-image:do_deploy"
addtask deploy before do_build after do_install

5
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/bsp/arm-autonomy/arm64-autonomy-guest-standard.scc
View File

@@ -1,5 +0,0 @@
define KMACHINE arm64-autonomy-guest
define KTYPE standard
define KARCH arm64
include arm64-autonomy-guest.scc

2
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/bsp/arm-autonomy/arm64-autonomy-guest.cfg
View File

@@ -1,2 +0,0 @@
CONFIG_ARM64=y
CONFIG_SMP=y

6
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/bsp/arm-autonomy/arm64-autonomy-guest.scc
View File

@@ -1,6 +0,0 @@
include ktypes/standard/standard.scc
include features/input/input.scc
include features/net/net.scc
include cfg/timer/no_hz.scc
kconf hardware arm64-autonomy-guest.cfg

27
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/docker-minimal.cfg
View File

@@ -1,27 +0,0 @@
CONFIG_OVERLAY_FS=y
CONFIG_NAMESPACES=y
CONFIG_NET_NS=y
CONFIG_PID_NS=y
CONFIG_IPC_NS=y
CONFIG_UTS_NS=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_SCHED=y
CONFIG_CPUSETS=y
CONFIG_MEMCG=y
CONFIG_KEYS=y
CONFIG_POSIX_MQUEUE=y
CONFIG_VETH=y
CONFIG_IPV6=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_NETFILTER=y
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_NAT=m
CONFIG_NF_NAT=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_IP_VS=y
CONFIG_NETFILTER_XT_MATCH_IPVS=m

5
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/docker-minimal.scc
View File

@@ -1,5 +0,0 @@
define KFEATURE_DESCRIPTION "Minimal Kernel configs for Docker runtime"
include features/netfilter/netfilter.scc
kconf non-hardware docker-minimal.cfg

2
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/netfilter-extra.cfg
View File

@@ -1,2 +0,0 @@
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m

31
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-common.cfg
View File

@@ -1,31 +0,0 @@
CONFIG_PARAVIRT=y
CONFIG_XEN=y
CONFIG_BLOCK=y
CONFIG_SCSI=y
CONFIG_NET=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_WATCHDOG=y
CONFIG_XEN_WDT=y
CONFIG_XEN_BALLOON=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_GRANT_DEV_ALLOC=y
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_EFI=y
CONFIG_XEN_AUTO_XLATE=y

3
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-common.scc
View File

@@ -1,3 +0,0 @@
define KFEATURE_DESCRIPTION "Common XEN (Host and Guest) configs and patches on autonomy systems"
kconf non-hardware xen-common.cfg

28
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-guest.cfg
View File

@@ -1,28 +0,0 @@
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_XEN_SCSI_FRONTEND=y
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_INPUT=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_DRM=y
CONFIG_DRM_XEN=y
CONFIG_DRM_XEN_FRONTEND=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_XEN_FRONTEND=y

3
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-guest.scc
View File

@@ -1,3 +0,0 @@
define KFEATURE_DESCRIPTION "Enable XEN Guest Frontend Drivers"
kconf non-hardware xen-guest.cfg

10
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-host-iptables.scc
View File

@@ -1,10 +0,0 @@
#
# Not directly sourced via a kernel type but via an external bb
#
define KFEATURE_DESCRIPTION "Enable netfilter + conn tracking + extras"
define KFEATURE_COMPATIBILITY all
include cfg/net/bridge.scc
include features/netfilter/netfilter.scc
kconf non-hardware netfilter-extra.cfg

10
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-host.cfg
View File

@@ -1,10 +0,0 @@
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_TARGET_CORE=y
CONFIG_XEN_SCSI_BACKEND=y
CONFIG_XEN_NETDEV_BACKEND=y
# For LVM2 we need Multiple Devices and Device Mapper support
CONFIG_MD=y
CONFIG_BLK_DEV_DM=y

3
meta-arm-autonomy/recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-host.scc
View File

@@ -1,3 +0,0 @@
define KFEATURE_DESCRIPTION "Enable XEN Host Drivers on autonomy systems"
kconf non-hardware xen-host.cfg

147
meta-arm-autonomy/recipes-kernel/linux/files/0001-arm-arm64-xen-Fix-to-convert-percpu-address-to-gfn-c.patch
View File

@@ -1,147 +0,0 @@
From 5a0677110b73dd3e1766f89159701bfe8ac06808 Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu <mhiramat@kernel.org>
Date: Tue, 6 Oct 2020 15:49:31 +0900
Subject: [PATCH] arm/arm64: xen: Fix to convert percpu address to gfn
correctly
Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
address conversion.
In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
to gfn by virt_to_gfn() macro. However, since the virt_to_gfn(v)
assumes the given virtual address is in linear mapped kernel memory
area, it can not convert the per-cpu memory if it is allocated on
vmalloc area.
This depends on CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK.
If it is enabled, the first chunk of percpu memory is linear mapped.
In the other case, that is allocated from vmalloc area. Moreover,
if the first chunk of percpu has run out until allocating
xen_vcpu_info, it will be allocated on the 2nd chunk, which is
based on kernel memory or vmalloc memory (depends on
CONFIG_NEED_PER_CPU_KM).
Without this fix and kernel configured to use vmalloc area for
the percpu memory, the Dom0 kernel will fail to boot with following
errors.
[ 0.466172] Xen: initializing cpu0
[ 0.469601] ------------[ cut here ]------------
[ 0.474295] WARNING: CPU: 0 PID: 1 at arch/arm64/xen/../../arm/xen/enlighten.c:153 xen_starting_cpu+0x160/0x180
[ 0.484435] Modules linked in:
[ 0.487565] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4+ #4
[ 0.493895] Hardware name: Socionext Developer Box (DT)
[ 0.499194] pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--)
[ 0.504836] pc : xen_starting_cpu+0x160/0x180
[ 0.509263] lr : xen_starting_cpu+0xb0/0x180
[ 0.513599] sp : ffff8000116cbb60
[ 0.516984] x29: ffff8000116cbb60 x28: ffff80000abec000
[ 0.522366] x27: 0000000000000000 x26: 0000000000000000
[ 0.527754] x25: ffff80001156c000 x24: fffffdffbfcdb600
[ 0.533129] x23: 0000000000000000 x22: 0000000000000000
[ 0.538511] x21: ffff8000113a99c8 x20: ffff800010fe4f68
[ 0.543892] x19: ffff8000113a9988 x18: 0000000000000010
[ 0.549274] x17: 0000000094fe0f81 x16: 00000000deadbeef
[ 0.554655] x15: ffffffffffffffff x14: 0720072007200720
[ 0.560037] x13: 0720072007200720 x12: 0720072007200720
[ 0.565418] x11: 0720072007200720 x10: 0720072007200720
[ 0.570801] x9 : ffff8000100fbdc0 x8 : ffff800010715208
[ 0.576182] x7 : 0000000000000054 x6 : ffff00001b790f00
[ 0.581564] x5 : ffff800010bbf880 x4 : 0000000000000000
[ 0.586945] x3 : 0000000000000000 x2 : ffff80000abec000
[ 0.592327] x1 : 000000000000002f x0 : 0000800000000000
[ 0.597716] Call trace:
[ 0.600232] xen_starting_cpu+0x160/0x180
[ 0.604309] cpuhp_invoke_callback+0xac/0x640
[ 0.608736] cpuhp_issue_call+0xf4/0x150
[ 0.612728] __cpuhp_setup_state_cpuslocked+0x128/0x2c8
[ 0.618030] __cpuhp_setup_state+0x84/0xf8
[ 0.622192] xen_guest_init+0x324/0x364
[ 0.626097] do_one_initcall+0x54/0x250
[ 0.630003] kernel_init_freeable+0x12c/0x2c8
[ 0.634428] kernel_init+0x1c/0x128
[ 0.637988] ret_from_fork+0x10/0x18
[ 0.641635] ---[ end trace d95b5309a33f8b27 ]---
[ 0.646337] ------------[ cut here ]------------
[ 0.651005] kernel BUG at arch/arm64/xen/../../arm/xen/enlighten.c:158!
[ 0.657697] Internal error: Oops - BUG: 0 [#1] SMP
[ 0.662548] Modules linked in:
[ 0.665676] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 5.9.0-rc4+ #4
[ 0.673398] Hardware name: Socionext Developer Box (DT)
[ 0.678695] pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--)
[ 0.684338] pc : xen_starting_cpu+0x178/0x180
[ 0.688765] lr : xen_starting_cpu+0x144/0x180
[ 0.693188] sp : ffff8000116cbb60
[ 0.696573] x29: ffff8000116cbb60 x28: ffff80000abec000
[ 0.701955] x27: 0000000000000000 x26: 0000000000000000
[ 0.707344] x25: ffff80001156c000 x24: fffffdffbfcdb600
[ 0.712718] x23: 0000000000000000 x22: 0000000000000000
[ 0.718107] x21: ffff8000113a99c8 x20: ffff800010fe4f68
[ 0.723481] x19: ffff8000113a9988 x18: 0000000000000010
[ 0.728863] x17: 0000000094fe0f81 x16: 00000000deadbeef
[ 0.734245] x15: ffffffffffffffff x14: 0720072007200720
[ 0.739626] x13: 0720072007200720 x12: 0720072007200720
[ 0.745008] x11: 0720072007200720 x10: 0720072007200720
[ 0.750390] x9 : ffff8000100fbdc0 x8 : ffff800010715208
[ 0.755771] x7 : 0000000000000054 x6 : ffff00001b790f00
[ 0.761153] x5 : ffff800010bbf880 x4 : 0000000000000000
[ 0.766534] x3 : 0000000000000000 x2 : 00000000deadbeef
[ 0.771916] x1 : 00000000deadbeef x0 : ffffffffffffffea
[ 0.777304] Call trace:
[ 0.779819] xen_starting_cpu+0x178/0x180
[ 0.783898] cpuhp_invoke_callback+0xac/0x640
[ 0.788325] cpuhp_issue_call+0xf4/0x150
[ 0.792317] __cpuhp_setup_state_cpuslocked+0x128/0x2c8
[ 0.797619] __cpuhp_setup_state+0x84/0xf8
[ 0.801779] xen_guest_init+0x324/0x364
[ 0.805683] do_one_initcall+0x54/0x250
[ 0.809590] kernel_init_freeable+0x12c/0x2c8
[ 0.814016] kernel_init+0x1c/0x128
[ 0.817583] ret_from_fork+0x10/0x18
[ 0.821226] Code: d0006980 f9427c00 cb000300 17ffffea (d4210000)
[ 0.827415] ---[ end trace d95b5309a33f8b28 ]---
[ 0.832076] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 0.839815] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Link: https://lore.kernel.org/r/160196697165.60224.17470743378683334995.stgit@devnote2
Signed-off-by: Juergen Gross <jgross@suse.com>
Upstream-Status: Backport
Signed-off-by: Richard Neill <richard.neill@arm.com>
---
arch/arm/xen/enlighten.c | 2 +-
include/xen/arm/page.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index e93145d72c26..a6ab3689b2f4 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -150,7 +150,7 @@ static int xen_starting_cpu(unsigned int cpu)
pr_info("Xen: initializing cpu%d\n", cpu);
vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
- info.mfn = virt_to_gfn(vcpup);
+ info.mfn = percpu_to_gfn(vcpup);
info.offset = xen_offset_in_page(vcpup);
err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, xen_vcpu_nr(cpu),
diff --git a/include/xen/arm/page.h b/include/xen/arm/page.h
index 39df751d0dc4..ac1b65470563 100644
--- a/include/xen/arm/page.h
+++ b/include/xen/arm/page.h
@@ -83,6 +83,9 @@ static inline unsigned long bfn_to_pfn(unsigned long bfn)
})
#define gfn_to_virt(m) (__va(gfn_to_pfn(m) << XEN_PAGE_SHIFT))
+#define percpu_to_gfn(v) \
+ (pfn_to_gfn(per_cpu_ptr_to_phys(v) >> XEN_PAGE_SHIFT))
+
/* Only used in PV code. But ARM guests are always HVM. */
static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
{
--
2.25.1

83
meta-arm-autonomy/recipes-kernel/linux/files/0001-xen-arm-do-not-setup-the-runstate-info-page-if-kpti-.patch
View File

@@ -1,83 +0,0 @@
From f88af7229f6f22ce7313c11a0bbb9c88317b7c5e Mon Sep 17 00:00:00 2001
Message-Id: <f88af7229f6f22ce7313c11a0bbb9c88317b7c5e.1602759709.git.diego.sueiro@arm.com>
From: Stefano Stabellini <stefano.stabellini@xilinx.com>
Date: Thu, 24 Sep 2020 16:49:55 -0700
Subject: [PATCH] xen/arm: do not setup the runstate info page if kpti is
enabled
The VCPUOP_register_runstate_memory_area hypercall takes a virtual
address of a buffer as a parameter. The semantics of the hypercall are
such that the virtual address should always be valid.
When KPTI is enabled and we are running userspace code, the virtual
address is not valid, thus, Linux is violating the semantics of
VCPUOP_register_runstate_memory_area.
Do not call VCPUOP_register_runstate_memory_area when KPTI is enabled.
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
CC: Bertrand Marquis <Bertrand.Marquis@arm.com>
CC: boris.ostrovsky@oracle.com
CC: jgross@suse.com
Link: https://lore.kernel.org/r/20200924234955.15455-1-sstabellini@kernel.org
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Upstream-Status: Backport
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
---
arch/arm/include/asm/xen/page.h | 5 +++++
arch/arm/xen/enlighten.c | 6 ++++--
arch/arm64/include/asm/xen/page.h | 6 ++++++
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 31bbc80..dc7f6e9 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1 +1,6 @@
#include <xen/arm/page.h>
+
+static inline bool xen_kernel_unmapped_at_usr(void)
+{
+ return false;
+}
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index e93145d..ea76562 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -158,7 +158,8 @@ static int xen_starting_cpu(unsigned int cpu)
BUG_ON(err);
per_cpu(xen_vcpu, cpu) = vcpup;
- xen_setup_runstate_info(cpu);
+ if (!xen_kernel_unmapped_at_usr())
+ xen_setup_runstate_info(cpu);
after_register_vcpu_info:
enable_percpu_irq(xen_events_irq, 0);
@@ -387,7 +388,8 @@ static int __init xen_guest_init(void)
return -EINVAL;
}
- xen_time_setup_guest();
+ if (!xen_kernel_unmapped_at_usr())
+ xen_time_setup_guest();
if (xen_initial_domain())
pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
diff --git a/arch/arm64/include/asm/xen/page.h b/arch/arm64/include/asm/xen/page.h
index 31bbc80..dffdc77 100644
--- a/arch/arm64/include/asm/xen/page.h
+++ b/arch/arm64/include/asm/xen/page.h
@@ -1 +1,7 @@
#include <xen/arm/page.h>
+#include <asm/mmu.h>
+
+static inline bool xen_kernel_unmapped_at_usr(void)
+{
+ return arm64_kernel_unmapped_at_el0();
+}
--
2.7.4

5
meta-arm-autonomy/recipes-kernel/linux/linux-%.bbappend
View File

@@ -1,5 +0,0 @@
# Add arm-autonomy kernel support
require ${@bb.utils.contains_any('DISTRO_FEATURES', \
'arm-autonomy-host arm-autonomy-guest', \
'linux-arm-autonomy.inc', \
'', d)}

51
meta-arm-autonomy/recipes-kernel/linux/linux-arm-autonomy.inc
View File

@@ -1,51 +0,0 @@
# Add arm-autonomy specific features to the kernel
FILESEXTRAPATHS:prepend := "${THISDIR}:"
#
# arm-autonomy kmeta
#
SRC_URI:append = " file://arm-autonomy-kmeta;type=kmeta;name=arm-autonomy-kmeta;destsuffix=arm-autonomy-kmeta"
# Add common Xen (host and guest) configs and patches
KERNEL_FEATURES += "${@bb.utils.contains_any('DISTRO_FEATURES', \
'arm-autonomy-host arm-autonomy-guest', \
'features/arm-autonomy/xen-common.scc', '', d)}"
# Add xen host drivers to kernel if arm-autonomy-host is activated
KERNEL_FEATURES += "${@bb.utils.contains('DISTRO_FEATURES', \
'arm-autonomy-host', \
'features/arm-autonomy/xen-host.scc \
features/arm-autonomy/xen-host-iptables.scc', \
'', d)}"
# Add xen guest drivers to kernel if arm-autonomy-guest is activated
KERNEL_FEATURES += "${@bb.utils.contains('DISTRO_FEATURES', \
'arm-autonomy-guest', 'features/arm-autonomy/xen-guest.scc', '', d)}"
# Add support for arm64-autonomy-guest machine
COMPATIBLE_MACHINE:arm64-autonomy-guest = "arm64-autonomy-guest"
KMACHINE:arm64-autonomy-guest = "arm64-autonomy-guest"
# Add Minimal Kernel Configs for Docker runtime
KERNEL_FEATURES += "${@bb.utils.contains('DISTRO_FEATURES', \
'docker', 'features/arm-autonomy/docker-minimal.scc', '', d)}"
python() {
from distutils.version import LooseVersion
kernelVersion = d.getVar('LINUX_VERSION')
pn = d.getVar('PN')
if kernelVersion and pn != 'linux-libc-headers' \
and oe.utils.any_distro_features(d, "arm-autonomy-host arm-autonomy-guest"):
if LooseVersion(kernelVersion) < '5.9':
d.appendVar('SRC_URI', ' file://files/0001-arm-arm64-xen-Fix-to-convert-percpu-address-to-gfn-c.patch' )
if kernelVersion and LooseVersion(kernelVersion) < '5.10':
if oe.utils.any_distro_features(d, "arm-autonomy-host arm-autonomy-guest"):
d.appendVar('SRC_URI', ' file://files/0001-xen-arm-do-not-setup-the-runstate-info-page-if-kpti-.patch' )
}