mirror of
https://git.yoctoproject.org/meta-arm
synced 2026-07-18 16:37:08 +00:00
Compare commits
5 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Tushar Khandelwal
|
43b6449601 | ||
|
Tushar Khandelwal
|
95cfe5ad83 | ||
|
Tushar Khandelwal
|
c1a92ede20 | ||
 Rui Silva
|
c4057679c8 | ||
|
Tushar Khandelwal
|
3d59929e06 |
-196
@@ -1,196 +0,0 @@
|
||||
image: ghcr.io/siemens/kas/kas
|
||||
|
||||
# First do a common bootstrap, and then build all the targets
|
||||
stages:
|
||||
- prep
|
||||
- bootstrap
|
||||
- build
|
||||
|
||||
# Common job fragment to get a worker ready
|
||||
.setup:
|
||||
stage: build
|
||||
interruptible: true
|
||||
variables:
|
||||
KAS_WORK_DIR: $CI_PROJECT_DIR/work
|
||||
KAS_REPO_REF_DIR: $CI_BUILDS_DIR/persist/repos
|
||||
SSTATE_DIR: $CI_BUILDS_DIR/persist/sstate
|
||||
DL_DIR: $CI_BUILDS_DIR/persist/downloads
|
||||
BB_LOGCONFIG: $CI_PROJECT_DIR/ci/logging.yml
|
||||
TOOLCHAIN_DIR: $CI_BUILDS_DIR/persist/toolchains
|
||||
IMAGE_DIR: $CI_PROJECT_DIR/work/build/tmp/deploy/images
|
||||
before_script:
|
||||
- echo KAS_WORK_DIR = $KAS_WORK_DIR
|
||||
- echo SSTATE_DIR = $SSTATE_DIR
|
||||
- echo DL_DIR = $DL_DIR
|
||||
- rm -rf $KAS_WORK_DIR
|
||||
- mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_DIR $TOOLCHAIN_DIR
|
||||
|
||||
# Generalised fragment to do a Kas build
|
||||
.build:
|
||||
extends: .setup
|
||||
script:
|
||||
- KASFILES=$(./ci/jobs-to-kas $CI_JOB_NAME)
|
||||
- kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
|
||||
- kas build $KASFILES
|
||||
- ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
|
||||
|
||||
#
|
||||
# Prep stage, update repositories once
|
||||
#
|
||||
update-repos:
|
||||
extends: .setup
|
||||
stage: prep
|
||||
script:
|
||||
- flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos
|
||||
|
||||
get-binary-toolchains:
|
||||
extends: .setup
|
||||
stage: prep
|
||||
script:
|
||||
- ./ci/get-binary-toolchains $DL_DIR $TOOLCHAIN_DIR
|
||||
|
||||
|
||||
#
|
||||
# Bootstrap stage, bootstrap and machine coverage
|
||||
#
|
||||
|
||||
# Build a number of native tools first to ensure the other builders don't race
|
||||
# over them
|
||||
n1sdp/bootstrap:
|
||||
extends: .build
|
||||
stage: bootstrap
|
||||
|
||||
# What percentage of machines in the layer do we build
|
||||
machine-coverage:
|
||||
stage: bootstrap
|
||||
interruptible: true
|
||||
script:
|
||||
- ./ci/check-machine-coverage
|
||||
coverage: '/Coverage: \d+/'
|
||||
|
||||
|
||||
#
|
||||
# Build stage, the actual build jobs
|
||||
#
|
||||
|
||||
a5ds:
|
||||
extends: .build
|
||||
|
||||
corstone700-fvp:
|
||||
extends: .build
|
||||
|
||||
corstone700-mps3:
|
||||
extends: .build
|
||||
|
||||
foundation-armv8:
|
||||
extends: .build
|
||||
|
||||
fvp-base:
|
||||
extends: .build
|
||||
|
||||
fvp-base-arm32:
|
||||
extends: .build
|
||||
|
||||
fvp-base-arm32/external-gccarm:
|
||||
extends: .build
|
||||
|
||||
gem5-arm64:
|
||||
extends: .build
|
||||
|
||||
juno:
|
||||
extends: .build
|
||||
|
||||
juno/clang:
|
||||
extends: .build
|
||||
|
||||
musca-b1:
|
||||
extends: .build
|
||||
|
||||
musca-s1:
|
||||
extends: .build
|
||||
|
||||
n1sdp:
|
||||
extends: .build
|
||||
|
||||
# This job currently fails when building gcc-runtime:
|
||||
# cc1: error: switch '-mcpu=armv8.2-a' conflicts with '-march=armv8-a' switch [-Werror]
|
||||
# Mark as manual so it doesn't get executed automatically
|
||||
n1sdp/armgcc:
|
||||
extends: .build
|
||||
when: manual
|
||||
|
||||
qemuarm/testimage:
|
||||
extends: .build
|
||||
|
||||
qemuarm64-secureboot/testimage:
|
||||
extends: .build
|
||||
|
||||
qemuarm64-secureboot/clang/testimage:
|
||||
extends: .build
|
||||
|
||||
qemuarm64-secureboot/clang/musl/testimage:
|
||||
extends: .build
|
||||
|
||||
qemuarm64-secureboot/musl/testimage:
|
||||
extends: .build
|
||||
|
||||
qemuarmv5/testimage:
|
||||
extends: .build
|
||||
|
||||
sgi575:
|
||||
extends: .build
|
||||
|
||||
tc0:
|
||||
extends: .build
|
||||
|
||||
|
||||
#
|
||||
# Utility tasks, not executed automatically
|
||||
#
|
||||
|
||||
delete-dl-dir:
|
||||
extends: .setup
|
||||
stage: prep
|
||||
when: manual
|
||||
script:
|
||||
- rm -rf $DL_DIR/*
|
||||
|
||||
delete-repo-dir:
|
||||
extends: .setup
|
||||
stage: prep
|
||||
when: manual
|
||||
script:
|
||||
- rm -rf $KAS_REPO_REF_DIR/*
|
||||
|
||||
# Delete all sstate
|
||||
delete-sstate:
|
||||
extends: .setup
|
||||
stage: prep
|
||||
when: manual
|
||||
script:
|
||||
- rm -rf $SSTATE_DIR/*
|
||||
|
||||
delete-toolchains:
|
||||
extends: .setup
|
||||
stage: prep
|
||||
when: manual
|
||||
script:
|
||||
- rm -rf $TOOLCHAIN_DIR/*
|
||||
|
||||
# Wipe out old sstate
|
||||
prune-sstate:
|
||||
extends: .setup
|
||||
stage: prep
|
||||
when: manual
|
||||
script:
|
||||
- du -h -s $SSTATE_DIR
|
||||
- find $SSTATE_DIR -type f -atime +30 -delete
|
||||
- du -h -s $SSTATE_DIR
|
||||
|
||||
# Report on disk usage
|
||||
usage:
|
||||
extends: .setup
|
||||
stage: prep
|
||||
when: manual
|
||||
script:
|
||||
- du -h -s $DL_DIR $SSTATE_DIR $KAS_REPO_REF_DIR $TOOLCHAIN_DIR
|
||||
@@ -1,50 +0,0 @@
|
||||
Introduction
|
||||
------------
|
||||
This repository contains Arm layers for OpenEmbedded
|
||||
|
||||
meta-arm:
|
||||
This layer provides support for general recipes for the Arm
|
||||
architecture. Anything that's not needed explicitly for BSPs, the IOTA
|
||||
distribution, or destined to be upstreamed belongs here.
|
||||
|
||||
meta-arm-bsp:
|
||||
This layer provides support for Arm reference platforms
|
||||
|
||||
meta-arm-iota:
|
||||
This layer provides support for Arm's IOTA Linux Distribution
|
||||
|
||||
meta-arm-toolchain:
|
||||
This layer provides support for Arm's GNU-A toolset releases
|
||||
|
||||
meta-arm-autonomy:
|
||||
This layer provides a reference stack for autonomous systems.
|
||||
|
||||
Contributing
|
||||
------------
|
||||
Currently, we only accept patches from the meta-arm mailing list. For general
|
||||
information on how to submit a patch, please read
|
||||
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
|
||||
|
||||
E-mail meta-arm@lists.yoctoproject.org with patches created using this process. You can configure git-send-email to automatically use this address for the meta-arm repository with the following git command:
|
||||
|
||||
$ git config --local --add sendemail.to meta-arm@lists.yoctoproject.org
|
||||
|
||||
Commits and patches added should follow the OpenEmbedded patch guidelines:
|
||||
|
||||
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
|
||||
|
||||
The component being changed in the shortlog should be prefixed with the layer name (without the meta- prefix), for example:
|
||||
|
||||
arm-bsp/trusted-firmware-a: decrease frobbing level
|
||||
|
||||
arm-toolchain/gcc: enable foobar v2
|
||||
|
||||
Reporting bugs
|
||||
--------------
|
||||
E-mail meta-arm@lists.yoctoproject.org with the error encountered and the steps
|
||||
to reproduce the issue.
|
||||
|
||||
Maintainer(s)
|
||||
-------------
|
||||
* Jon Mason <jon.mason@arm.com>
|
||||
* Ross Burton <ross.burton@arm.com>
|
||||
@@ -1,6 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: a5ds
|
||||
@@ -1,6 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
|
||||
local_conf_header:
|
||||
libc: |
|
||||
GCCVERSION = "arm-9.2"
|
||||
-45
@@ -1,45 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
|
||||
distro: poky
|
||||
|
||||
defaults:
|
||||
repos:
|
||||
refspec: gatesgarth
|
||||
|
||||
repos:
|
||||
meta-arm:
|
||||
layers:
|
||||
meta-arm:
|
||||
meta-arm-bsp:
|
||||
meta-arm-toolchain:
|
||||
|
||||
poky:
|
||||
url: https://git.yoctoproject.org/git/poky
|
||||
layers:
|
||||
meta:
|
||||
meta-poky:
|
||||
|
||||
env:
|
||||
BB_LOGCONFIG: ""
|
||||
TOOLCHAIN_DIR: ""
|
||||
|
||||
local_conf_header:
|
||||
base: |
|
||||
CONF_VERSION = "1"
|
||||
PACKAGE_CLASSES = "package_ipk"
|
||||
LICENSE_FLAGS_WHITELIST += "armcompiler"
|
||||
PACKAGECONFIG_remove_pn-qemu-system-native = "gtk+ sdl"
|
||||
EXTRA_IMAGE_FEATURES_append = " debug-tweaks"
|
||||
BB_NUMBER_THREADS = "16"
|
||||
PARALLEL_MAKE = "-j16"
|
||||
INHERIT += "rm_work"
|
||||
PACKAGECONFIG_append_pn-perf = " coresight"
|
||||
ptest: |
|
||||
DISTRO_FEATURES_remove = "ptest"
|
||||
|
||||
machine: unset
|
||||
|
||||
target:
|
||||
- core-image-base
|
||||
- perf
|
||||
@@ -1,9 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
|
||||
target:
|
||||
- binutils-cross-aarch64
|
||||
- gcc-cross-aarch64
|
||||
- python3-native
|
||||
- opkg-native
|
||||
- rpm-native
|
||||
@@ -1,26 +0,0 @@
|
||||
#! /usr/bin/env python3
|
||||
|
||||
from pathlib import Path
|
||||
import sys
|
||||
|
||||
metaarm = Path.cwd()
|
||||
|
||||
if metaarm.name != "meta-arm":
|
||||
print("Not running inside meta-arm")
|
||||
sys.exit(1)
|
||||
|
||||
# All machine configurations
|
||||
machines = metaarm.glob("meta-*/conf/machine/*.conf")
|
||||
machines = set(p.stem for p in machines)
|
||||
|
||||
# All ci files
|
||||
ci = metaarm.glob("ci/*.yml")
|
||||
ci = set(p.stem for p in ci)
|
||||
|
||||
missing = machines - ci
|
||||
print(f"The following machines are missing: {', '.join(sorted(missing))}.")
|
||||
|
||||
covered = len(machines) - len(missing)
|
||||
total = len(machines)
|
||||
percent = int(covered / total * 100)
|
||||
print(f"Coverage: {percent}%")
|
||||
@@ -1,19 +0,0 @@
|
||||
#! /bin/bash
|
||||
|
||||
# Expects the path to a log file as $1, and if this file has any content
|
||||
# then display the contents and exit with an error code.
|
||||
|
||||
set -e -u
|
||||
|
||||
LOGFILE=$1
|
||||
|
||||
LINES=$(grep --invert-match "attempting MIRRORS if available" $LOGFILE | wc -l)
|
||||
if test "$LINES" -ne 0; then
|
||||
echo ==============================
|
||||
echo The build had warnings/errors:
|
||||
echo ==============================
|
||||
cat $LOGFILE
|
||||
exit 1
|
||||
fi
|
||||
|
||||
exit 0
|
||||
@@ -1,11 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
|
||||
repos:
|
||||
meta-clang:
|
||||
url: https://github.com/kraj/meta-clang
|
||||
refspec: gatesgarth
|
||||
|
||||
local_conf_header:
|
||||
clang: |
|
||||
TOOLCHAIN = "clang"
|
||||
@@ -1,10 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: corstone700-fvp
|
||||
|
||||
local_conf_header:
|
||||
image: |
|
||||
CORE_IMAGE_EXTRA_INSTALL = "corstone700-test-app"
|
||||
@@ -1,6 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- corstone700-fvp.yml
|
||||
|
||||
machine: corstone700-mps3
|
||||
@@ -1,8 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
|
||||
local_conf_header:
|
||||
cc: |
|
||||
PNBLACKLIST[gcc-cross-arm] = "Using external toolchain"
|
||||
TCMODE = "external-arm"
|
||||
EXTERNAL_TOOLCHAIN = "${TOOLCHAIN_DIR}/${TARGET_ARCH}"
|
||||
@@ -1,6 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: foundation-armv8
|
||||
@@ -1,6 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: fvp-base-arm32
|
||||
@@ -1,7 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: fvp-base
|
||||
|
||||
@@ -1,21 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
repos:
|
||||
meta-arm:
|
||||
layers:
|
||||
meta-gem5:
|
||||
|
||||
meta-openembedded:
|
||||
url: https://git.openembedded.org/meta-openembedded
|
||||
layers:
|
||||
meta-oe:
|
||||
|
||||
machine: gem5-arm64
|
||||
|
||||
target:
|
||||
- core-image-minimal
|
||||
- perf
|
||||
- gem5-aarch64-native
|
||||
@@ -1,52 +0,0 @@
|
||||
#!/bin/bash
|
||||
set -u
|
||||
|
||||
HOST_ARCH=$(uname -m)
|
||||
VER="10.2-2020.11"
|
||||
|
||||
DOWNLOAD_DIR=$1
|
||||
TOOLCHAIN_DIR=$2
|
||||
|
||||
# These should be already created by .bitlab-ci.yml, but do here if run outside of that env
|
||||
mkdir -p $DOWNLOAD_DIR $TOOLCHAIN_DIR
|
||||
|
||||
if [ $HOST_ARCH = "aarch64" ]; then
|
||||
#AArch64 Linux hosted cross compilers
|
||||
|
||||
#AArch32 target with hard float (arm-none-linux-gnueabihf)
|
||||
wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu-a/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz
|
||||
elif [ $HOST_ARCH = "x86_64" ]; then
|
||||
#x86_64 Linux hosted cross compilers
|
||||
|
||||
#AArch32 target with hard float (arm-linux-none-gnueabihf)
|
||||
wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu-a/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz
|
||||
|
||||
#AArch64 GNU/Linux target (aarch64-none-linux-gnu)
|
||||
wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu-a/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-aarch64-none-linux-gnu.tar.xz
|
||||
|
||||
#AArch64 GNU/Linux target (aarch64_be-none-linux-gnu)
|
||||
wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu-a/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-aarch64_be-none-linux-gnu.tar.xz
|
||||
else
|
||||
echo "ERROR - Unknown build arch of $HOST_ARCH"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
for i in arm aarch64 aarch64_be; do
|
||||
if [ ! -f $DOWNLOAD_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz ]; then
|
||||
continue
|
||||
fi
|
||||
|
||||
if [ -d $TOOLCHAIN_DIR/$i ]; then
|
||||
echo "$TOOLCHAIN_DIR/$i EXISTS!"
|
||||
MANIFEST=$(ls $TOOLCHAIN_DIR/$i | grep txt)
|
||||
if [[ $MANIFEST != $VER-$HOST_ARCH-$i-none-linux-gnu*.txt ]]; then
|
||||
echo "Removing old $MANIFEST for $VER-$HOST_ARCH-$i-*.txt toolchain"
|
||||
rm -rf $TOOLCHAIN_DIR/$i
|
||||
fi
|
||||
fi
|
||||
|
||||
if [ ! -d $TOOLCHAIN_DIR/$i ]; then
|
||||
tar -C $TOOLCHAIN_DIR -axvf $DOWNLOAD_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz
|
||||
mv $TOOLCHAIN_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu*/ $TOOLCHAIN_DIR/$i
|
||||
fi
|
||||
done
|
||||
@@ -1,19 +0,0 @@
|
||||
#! /bin/bash
|
||||
|
||||
# Read a GitLab CI job name on $1 and transform it to a
|
||||
# list of Kas yaml files
|
||||
|
||||
set -e -u
|
||||
|
||||
# Read Job namne from $1 and split on /
|
||||
IFS=/ read -r -a PARTS<<<$1
|
||||
|
||||
# Prefix each part with ci/
|
||||
PARTS=("${PARTS[@]/#/ci/}")
|
||||
|
||||
# Suffix each part with .yml
|
||||
PARTS=("${PARTS[@]/%/.yml}")
|
||||
|
||||
# Print colon-separated
|
||||
IFS=":"
|
||||
echo "${PARTS[*]}"
|
||||
@@ -1,6 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: juno
|
||||
@@ -1,13 +0,0 @@
|
||||
# Python logging configuration to write all warnings to a separate file
|
||||
version: 1
|
||||
|
||||
handlers:
|
||||
warnings:
|
||||
class: logging.FileHandler
|
||||
level: WARNING
|
||||
filename: warnings.log
|
||||
formatter: BitBake.logfileFormatter
|
||||
|
||||
loggers:
|
||||
BitBake:
|
||||
handlers: [warnings]
|
||||
@@ -1,9 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
|
||||
repos:
|
||||
meta-openembedded:
|
||||
url: https://git.openembedded.org/meta-openembedded
|
||||
layers:
|
||||
meta-oe:
|
||||
meta-python:
|
||||
@@ -1,8 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- meta-python.yml
|
||||
|
||||
repos:
|
||||
meta-zephyr:
|
||||
url: https://git.yoctoproject.org/git/meta-zephyr
|
||||
@@ -1,11 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
- meta-zephyr.yml
|
||||
|
||||
machine: musca-b1
|
||||
|
||||
target:
|
||||
- trusted-firmware-m
|
||||
- zephyr-philosophers
|
||||
@@ -1,10 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
- meta-python.yml
|
||||
|
||||
machine: musca-s1
|
||||
|
||||
target:
|
||||
- trusted-firmware-m
|
||||
@@ -1,6 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
|
||||
local_conf_header:
|
||||
libc: |
|
||||
TCLIBC = "musl"
|
||||
@@ -1,6 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: n1sdp
|
||||
@@ -1,6 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: qemuarm
|
||||
@@ -1,16 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: qemuarm64-secureboot
|
||||
|
||||
local_conf_header:
|
||||
bugs: |
|
||||
# Only ping until errors can be resolved
|
||||
TEST_SUITES = "ping"
|
||||
|
||||
target:
|
||||
- core-image-base
|
||||
- perf
|
||||
- optee-examples
|
||||
@@ -1,11 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: qemuarmv5
|
||||
|
||||
local_conf_header:
|
||||
bugs: |
|
||||
# Remove parselogs until errors can be resolved
|
||||
TEST_SUITES_remove = "parselogs"
|
||||
@@ -1,6 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: sgi575
|
||||
@@ -1,6 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
includes:
|
||||
- base.yml
|
||||
|
||||
machine: tc0
|
||||
@@ -1,17 +0,0 @@
|
||||
header:
|
||||
version: 9
|
||||
|
||||
local_conf_header:
|
||||
testimage: |
|
||||
IMAGE_CLASSES += "testimage"
|
||||
TESTIMAGE_AUTO = "1"
|
||||
slirp: |
|
||||
TEST_RUNQEMUPARAMS = "slirp"
|
||||
TEST_SERVER_IP = "127.0.0.1"
|
||||
QEMU_USE_SLIRP = "1"
|
||||
packages: |
|
||||
IMAGE_FEATURES_append = " ssh-server-dropbear"
|
||||
|
||||
# Multiple targets are available, put it down to just one
|
||||
target:
|
||||
- core-image-base
|
||||
@@ -1,41 +0,0 @@
|
||||
#! /usr/bin/env python3
|
||||
|
||||
# Update clones of the repositories we need in KAS_REPO_REF_DIR to speed up fetches
|
||||
|
||||
import sys
|
||||
import os
|
||||
import subprocess
|
||||
import pathlib
|
||||
|
||||
def repo_shortname(url):
|
||||
# Taken from Kas (Repo.__getattr__) to ensure the logic is right
|
||||
from urllib.parse import urlparse
|
||||
url = urlparse(url)
|
||||
return ('{url.netloc}{url.path}'
|
||||
.format(url=url)
|
||||
.replace('@', '.')
|
||||
.replace(':', '.')
|
||||
.replace('/', '.')
|
||||
.replace('*', '.'))
|
||||
|
||||
repositories = (
|
||||
"https://git.yoctoproject.org/git/poky",
|
||||
"https://git.openembedded.org/meta-openembedded",
|
||||
"https://git.yoctoproject.org/git/meta-virtualization",
|
||||
"https://git.yoctoproject.org/git/meta-zephyr",
|
||||
"https://github.com/kraj/meta-clang",
|
||||
)
|
||||
|
||||
if __name__ == "__main__":
|
||||
if "KAS_REPO_REF_DIR" not in os.environ:
|
||||
print("KAS_REPO_REF_DIR needs to be set")
|
||||
sys.exit(1)
|
||||
|
||||
base_repodir = pathlib.Path(os.environ["KAS_REPO_REF_DIR"])
|
||||
|
||||
for repo in repositories:
|
||||
repodir = base_repodir / repo_shortname(repo)
|
||||
if repodir.exists():
|
||||
subprocess.run(["git", "-C", repodir, "fetch"], check=True)
|
||||
else:
|
||||
subprocess.run(["git", "clone", "--bare", repo, repodir], check=True)
|
||||
@@ -1,92 +0,0 @@
|
||||
meta-arm-autonomy Yocto Layer
|
||||
=============================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
This layer provides an hypervisor based solution (currently based on Xen) for
|
||||
autonomous system. It contains recipes and classes to build host and guests
|
||||
systems.
|
||||
|
||||
To start using this layer, please check the
|
||||
[Quick Start Guide](documentation/arm-autonomy-quickstart.md).
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
This layer depends on several other Yocto layers:
|
||||
* meta-openembedded (https://git.openembedded.org/meta-openembedded)
|
||||
* poky (https://git.yoctoproject.org/poky)
|
||||
* meta-virtualization (https://git.yoctoproject.org/meta-virtualization)
|
||||
|
||||
Distribution Features
|
||||
---------------------
|
||||
This layer is adding the following Yocto DISTRO_FEATURES:
|
||||
|
||||
* arm-autonomy-host: this feature activates functionalities required to build
|
||||
an autonomy host system. It is doing the following:
|
||||
- add 'xen' and 'ipv4' to DISTRO_FEATURES.
|
||||
- add xen backend drivers to linux kernel configuration.
|
||||
- To reduce the root filesystem image size the kernel image is not installed.
|
||||
|
||||
* arm-autonomy-guest: this feature activates functionalities to run as guest
|
||||
of an autonomy system. It is doing the following:
|
||||
- add 'ipv4' to DISTRO_FEATURES.
|
||||
- add xen frontend drivers to linux kernel configuration.
|
||||
- add console on hvc0 during init.
|
||||
|
||||
Bitbake variables
|
||||
-----------------
|
||||
Some recipes and classes in this layer are introducing variables which can be
|
||||
modified by the user in local.conf.
|
||||
Each recipe introducing such variables has a chapter "Bitbake parameters" in
|
||||
its documentation.
|
||||
|
||||
Those documentation files should be checked for variables:
|
||||
- [xen-devicetree](documentation/xen-devicetree.md)
|
||||
- [xenguest-manager](documentation/xenguest-manager.md)
|
||||
- [xenguest-network-bridge](documentation/xenguest-network-bridge.md)
|
||||
|
||||
BSPs
|
||||
----
|
||||
This layer is adding the following machines:
|
||||
|
||||
* arm64-autonomy-guest: this machines creates a minimal BSP suitable to be used
|
||||
as an autonomy guest. It is in fact only activating ARM64 architecture and
|
||||
SMP in the linux kernel and is enabling the DISTRO_FEATURE
|
||||
arm-autonomy-guest.
|
||||
|
||||
Images
|
||||
------
|
||||
This layer is adding the following images:
|
||||
|
||||
* arm-autonomy-host-image-minimal: this image includes all elements required
|
||||
to create a minimal arm-autonomy-host system. This includes xen and tools to
|
||||
manage xen guests. This image depends on 'arm-autonomy-host' distribution
|
||||
feature.
|
||||
|
||||
Recipes and classes
|
||||
-------------------
|
||||
This layer is adding the following recipes and classes:
|
||||
|
||||
* [xen-devicetree](documentation/xen-devicetree.md): this is a recipe to modify
|
||||
a device tree blob to add information required to boot xen and a Dom0 linux.
|
||||
|
||||
* [xenguest-mkimage](documentation/xenguest-mkimage.md): this is a tool to
|
||||
create and modify images to be used as Xen guests.
|
||||
|
||||
* [xenguest-manager](documentation/xenguest-manager.md): this is a tool to
|
||||
create/remove/start/stop xen guest generated using xenguest-mkimage.
|
||||
|
||||
* [xenguest-network-bridge](documentation/xenguest-network-bridge.md): this
|
||||
recipe add tools and init scripts to create a bridge connected to the
|
||||
external network on the host and allow guests to be connected to it.
|
||||
|
||||
Contributing
|
||||
------------
|
||||
This project has not put in place a process for contributions currently. If you
|
||||
would like to contribute, please contact the maintainers
|
||||
|
||||
|
||||
Maintainer(s)
|
||||
-------------
|
||||
* Diego Sueiro <diego.sueiro@arm.com>
|
||||
* Bertrand Marquis <bertrand.marquis@arm.com>
|
||||
@@ -1,5 +0,0 @@
|
||||
# Include arm-autonomy distro config files if the distro features are set
|
||||
|
||||
require ${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', '${ARM_AUTONOMY_DISTRO_CFGDIR}/arm-autonomy-host.inc', '', d)}
|
||||
require ${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-guest', '${ARM_AUTONOMY_DISTRO_CFGDIR}/arm-autonomy-guest.inc', '', d)}
|
||||
|
||||
@@ -1,108 +0,0 @@
|
||||
# Create a xenguest image with kernel and filesystem produced by Yocto
|
||||
# This will create a .xenguest file that the xenguest-manager can use.
|
||||
|
||||
inherit xenguest-image
|
||||
|
||||
# We are creating our guest in a local subdirectory
|
||||
# force the value so that we are not impacted if the user is changing it
|
||||
XENGUEST_IMAGE_DEPLOY_DIR = "${WORKDIR}/tmp-xenguest"
|
||||
|
||||
# Name of deployed file (keep standard image name and add .xenguest)
|
||||
XENGUEST_IMAGE_DEPLOY ??= "${IMAGE_NAME}"
|
||||
|
||||
# Add kernel XENGUEST_IMAGE_KERNEL from DEPLOY_DIR_IMAGE to image
|
||||
xenguest_image_add_kernel() {
|
||||
srcfile="${1:-}"
|
||||
if [ -z "${srcfile}" ]; then
|
||||
srcfile="${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_KERNEL}"
|
||||
fi
|
||||
call_xenguest_mkimage partial --xen-kernel=$srcfile
|
||||
}
|
||||
|
||||
# Add rootfs file to the image
|
||||
xenguest_image_add_rootfs() {
|
||||
call_xenguest_mkimage partial \
|
||||
--disk-add-file=${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${IMAGE_TYPEDEP_xenguest}:rootfs.${IMAGE_TYPEDEP_xenguest}
|
||||
}
|
||||
|
||||
# Pack xenguest image
|
||||
xenguest_image_pack() {
|
||||
mkdir -p ${IMGDEPLOYDIR}
|
||||
rm -f ${IMGDEPLOYDIR}/${XENGUEST_IMAGE_DEPLOY}.xenguest
|
||||
call_xenguest_mkimage pack \
|
||||
${IMGDEPLOYDIR}/${XENGUEST_IMAGE_DEPLOY}.xenguest
|
||||
}
|
||||
|
||||
#
|
||||
# Task finishing the bootimg
|
||||
# We need this task to actually create the symlinks
|
||||
#
|
||||
python do_bootimg_xenguest() {
|
||||
subtasks = d.getVarFlag('do_bootimg_xenguest', 'subtasks')
|
||||
|
||||
bb.build.exec_func('xenguest_image_clone', d)
|
||||
if subtasks:
|
||||
for tk in subtasks.split():
|
||||
bb.build.exec_func(tk, d)
|
||||
bb.build.exec_func('xenguest_image_pack', d)
|
||||
bb.build.exec_func('create_symlinks', d)
|
||||
}
|
||||
# This is used to add sub-tasks to do_bootimg_xenguest
|
||||
do_bootimg_xenguest[subtasks] = ""
|
||||
# Those are required by create_symlinks to find our image
|
||||
do_bootimg_xenguest[subimages] = "xenguest"
|
||||
do_bootimg_xenguest[imgsuffix] = "."
|
||||
do_bootimg_xenguest[depends] += "xenguest-base-image:do_deploy"
|
||||
# Need to have rootfs so all recipes have deployed their content
|
||||
do_bootimg_xenguest[depends] += "${PN}:do_rootfs"
|
||||
|
||||
# This set in python anonymous after, just set a default value here
|
||||
IMAGE_TYPEDEP_xenguest ?= "tar"
|
||||
|
||||
# We must not be built at rootfs build time because we need the kernel
|
||||
IMAGE_TYPES_MASKED += "xenguest"
|
||||
IMAGE_TYPES += "xenguest"
|
||||
|
||||
python __anonymous() {
|
||||
# Do not do anything if we are not in the want FSTYPES
|
||||
if bb.utils.contains_any('IMAGE_FSTYPES', 'xenguest', '1', '0', d):
|
||||
|
||||
# Check the coherency of the configuration
|
||||
rootfs_needed = False
|
||||
rootfs_file = ''
|
||||
kernel_needed = False
|
||||
|
||||
rootfs_file = xenguest_image_rootfs_file(d)
|
||||
if rootfs_file:
|
||||
rootfs_needed = True
|
||||
|
||||
if d.getVar('XENGUEST_IMAGE_KERNEL') and not d.getVar('INITRAMFS_IMAGE'):
|
||||
# If INITRAMFS_IMAGE is set, even if INITRAMFS_IMAGE_BUNDLE is not
|
||||
# set to 1 to bundle the initramfs with the kernel, kernel.bbclass
|
||||
# is setting a dependency on ${PN}:do_image_complete. We cannot
|
||||
# in this case depend on do_deploy as it would create a circular
|
||||
# dependency:
|
||||
# do_image_complete would depend on kernel:do_deploy which would
|
||||
# depend on ${PN}:do_image_complete
|
||||
# In the case INITRAMFS_IMAGE_BUNDLE = 1, the kernel-xenguest class
|
||||
# will handle the creation of a xenguest image with the kernel.
|
||||
# In the other case the kernel can be added manually to the image.
|
||||
kernel_needed = True
|
||||
|
||||
bb.build.addtask('do_bootimg_xenguest', 'do_image_complete', None, d)
|
||||
|
||||
if rootfs_needed:
|
||||
# tell do_bootimg_xenguest to call add_rootfs
|
||||
d.appendVarFlag('do_bootimg_xenguest', 'subtasks', ' xenguest_image_add_rootfs')
|
||||
# do_bootimg_xenguest will need the tar file
|
||||
d.appendVarFlag('do_bootimg_xenguest', 'depends', ' %s:do_image_tar' % (d.getVar('PN')))
|
||||
# set our TYPEDEP to the proper compression
|
||||
d.setVar('IMAGE_TYPEDEP_xenguest', 'tar' + (rootfs_file.split('.tar', 1)[1] or ''))
|
||||
|
||||
if kernel_needed:
|
||||
# Tell do_bootimg_xenguest to call xenguest_image_add_kernel
|
||||
d.appendVarFlag('do_bootimg_xenguest', 'subtasks', ' xenguest_image_add_kernel')
|
||||
# we will need kernel do_deploy
|
||||
d.appendVarFlag('do_bootimg_xenguest', 'depends', ' virtual/kernel:do_deploy')
|
||||
}
|
||||
|
||||
@@ -1,34 +0,0 @@
|
||||
# Create a xenguest image containing the kernel with initramfs when
|
||||
# initramfs is activated
|
||||
# This is done using kernel-fitimage as model
|
||||
# To activate this, kernel-xenguest must be added to KERNEL_CLASSES
|
||||
|
||||
inherit xenguest-image
|
||||
|
||||
# use a local copy to pack all together
|
||||
XENGUEST_IMAGE_DEPLOY_DIR = "${WORKDIR}/tmp-xenguest"
|
||||
|
||||
python __anonymous () {
|
||||
# only if xenguest image type is present
|
||||
if bb.utils.contains('IMAGE_FSTYPES', 'xenguest', '1', '0', d):
|
||||
# only if initramfs bundle is activated
|
||||
if d.getVar('INITRAMFS_IMAGE') and d.getVar('INITRAMFS_IMAGE_BUNDLE') == "1":
|
||||
if not bb.utils.contains('KERNEL_IMAGETYPES', 'Image', '1', '0', d):
|
||||
bb.fatal("xenguest image type with initramfs require Image kernel image type")
|
||||
bb.build.addtask('do_assemble_xenguest_initramfs', 'do_deploy', 'do_bundle_initramfs', d)
|
||||
}
|
||||
|
||||
do_assemble_xenguest_initramfs() {
|
||||
xenguest_image_clone
|
||||
call_xenguest_mkimage partial --xen-kernel=${B}/${KERNEL_OUTPUT_DIR}/Image.initramfs
|
||||
rm -f ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest
|
||||
call_xenguest_mkimage pack ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest
|
||||
}
|
||||
do_assemble_xenguest_initramfs[depends] += "${INITRAMFS_IMAGE}:do_image_complete"
|
||||
|
||||
kernel_do_deploy_append() {
|
||||
if [ -f "${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest" ]; then
|
||||
install -m 0644 ${B}/${KERNEL_OUTPUT_DIR}/Image-initramfs.xenguest "$deployDir/Image-${INITRAMFS_NAME}.xenguest"
|
||||
ln -snf Image-${INITRAMFS_NAME}.xenguest $deployDir/Image-${INITRAMFS_LINK_NAME}.xenguest
|
||||
fi
|
||||
}
|
||||
@@ -1,114 +0,0 @@
|
||||
# This class must be used to extend the xenguest image
|
||||
# It provides variables to add init scripts, a dtb, xen files or disk files.
|
||||
#
|
||||
# The class is extending deploy function so you recipe must inherit deploy and
|
||||
# have a do_deploy function (even if it is empty)
|
||||
|
||||
# Use standard xenguest-image
|
||||
inherit xenguest-image
|
||||
|
||||
# Add a DTB file for the guest
|
||||
# Only one file should be added, if this is set multiple times or in several
|
||||
# recipes, the last recipe setting it will prevail.
|
||||
XENGUEST_EXTRA_DTB ??= ""
|
||||
|
||||
# Add a ramdisk file for the guest
|
||||
# Only one file should be added, if this is set multiple times or in several
|
||||
# recipes, the last recipe setting it will prevail.
|
||||
XENGUEST_EXTRA_RAMDISK ??= ""
|
||||
|
||||
# Append something to the guest xen configuration
|
||||
# All files here will be merged together in the final xen configuration
|
||||
# This can contain several files or be used in several recipes
|
||||
XENGUEST_EXTRA_XENCONFIG ??= ""
|
||||
|
||||
# Add a xenguest init, init-pre or init-post script
|
||||
XENGUEST_EXTRA_INIT_PRE ??= ""
|
||||
XENGUEST_EXTRA_INIT ??= ""
|
||||
XENGUEST_EXTRA_INIT_POST ??= ""
|
||||
|
||||
# Add xenguest files, (to be used in extra xen config for example)
|
||||
# several files may be added, space separated, the path will be kept on the
|
||||
# generated xenguest image (if dir1/file1 is added, it can be used as
|
||||
# dir1/file1 file in the xen configuration).
|
||||
XENGUEST_EXTRA_FILES ??= ""
|
||||
|
||||
# Add xenguest disk files (to be used as disk partition content)
|
||||
# several files may be added, space separated, the path will be kept on the
|
||||
# generated xenguest image (if dir1/file1 is added, it can be used as
|
||||
# dir1/file1 file in the disk content parameters).
|
||||
XENGUEST_EXTRA_DISK_FILES ??= ""
|
||||
|
||||
do_deploy_append() {
|
||||
if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
|
||||
-z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
|
||||
die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
|
||||
fi
|
||||
rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
|
||||
mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
|
||||
|
||||
if [ -n "${XENGUEST_EXTRA_DTB}" ]; then
|
||||
if [ ! -f ${XENGUEST_EXTRA_DTB} ]; then
|
||||
die "xenguest-image: DTB file ${XENGUEST_EXTRA_DTB} does not exist"
|
||||
fi
|
||||
call_xenguest_mkimage partial --xen-device-tree=${XENGUEST_EXTRA_DTB}
|
||||
fi
|
||||
|
||||
if [ -n "${XENGUEST_EXTRA_RAMDISK}" ]; then
|
||||
if [ ! -f ${XENGUEST_EXTRA_RAMDISK} ]; then
|
||||
die "xenguest-image: DTB file ${XENGUEST_EXTRA_RAMDISK} does not exist"
|
||||
fi
|
||||
call_xenguest_mkimage partial --xen-ramdisk=${XENGUEST_EXTRA_RAMDISK}
|
||||
fi
|
||||
|
||||
if [ -n "${XENGUEST_EXTRA_XENCONFIG}" ]; then
|
||||
for f in ${XENGUEST_EXTRA_XENCONFIG}; do
|
||||
if [ ! -f $f ]; then
|
||||
die "xenguest-image: Xen config $f does not exist"
|
||||
fi
|
||||
call_xenguest_mkimage partial --xen-append=$f
|
||||
done
|
||||
fi
|
||||
|
||||
if [ -n "${XENGUEST_EXTRA_INIT_PRE}" ]; then
|
||||
if [ ! -f ${XENGUEST_EXTRA_INIT_PRE} ]; then
|
||||
die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT_PRE} does not exist"
|
||||
fi
|
||||
call_xenguest_mkimage partial --init-pre=${XENGUEST_EXTRA_INIT_PRE}
|
||||
fi
|
||||
|
||||
if [ -n "${XENGUEST_EXTRA_INIT}" ]; then
|
||||
if [ ! -f ${XENGUEST_EXTRA_INIT} ]; then
|
||||
die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT} does not exist"
|
||||
fi
|
||||
call_xenguest_mkimage partial --init-script=${XENGUEST_EXTRA_INIT}
|
||||
fi
|
||||
|
||||
if [ -n "${XENGUEST_EXTRA_INIT_POST}" ]; then
|
||||
if [ ! -f ${XENGUEST_EXTRA_INIT_POST} ]; then
|
||||
die "xenguest-image: Init script ${XENGUEST_EXTRA_INIT_POST} does not exist"
|
||||
fi
|
||||
call_xenguest_mkimage partial --init-post=${XENGUEST_EXTRA_INIT_POST}
|
||||
fi
|
||||
|
||||
if [ -n "${XENGUEST_EXTRA_FILES}" ]; then
|
||||
for f in ${XENGUEST_EXTRA_FILES}; do
|
||||
if [ ! -f $f ]; then
|
||||
die "xenguest-image: Xen file $f does not exist"
|
||||
fi
|
||||
call_xenguest_mkimage partial --xen-add-file=$f
|
||||
done
|
||||
fi
|
||||
|
||||
if [ -n "${XENGUEST_EXTRA_DISK_FILES}" ]; then
|
||||
for f in ${XENGUEST_EXTRA_DISK_FILES}; do
|
||||
if [ ! -f $f ]; then
|
||||
die "xenguest-image: Disk file $f does not exist"
|
||||
fi
|
||||
call_xenguest_mkimage partial --disk-add-file=$f
|
||||
done
|
||||
fi
|
||||
}
|
||||
# Need to have xenguest-image tool
|
||||
do_deploy[depends] += "xenguest-base-image:do_deploy"
|
||||
|
||||
@@ -1,199 +0,0 @@
|
||||
# This class must be used to create, extend or pack a xenguest image.
|
||||
# It is using xenguest-mkimage tool to do operations
|
||||
|
||||
DEPENDS += "xenguest-mkimage-native"
|
||||
|
||||
#
|
||||
# Xenguest image parameters
|
||||
# All the following parameters can be modified in local.conf or on recipes
|
||||
# inheriting this class
|
||||
#
|
||||
|
||||
# Guest memory size in MB
|
||||
XENGUEST_IMAGE_MEMORY_SIZE ??= "512"
|
||||
|
||||
# Guest number of vcpus
|
||||
XENGUEST_IMAGE_NUM_VCPUS ??= "1"
|
||||
|
||||
# Guest auto boot during init, set to 1 to have guest started during init or
|
||||
# to 0 if the guest should not be auto started
|
||||
XENGUEST_IMAGE_AUTOBOOT ??= "1"
|
||||
|
||||
# Partition containing the root file system
|
||||
# Xen will actually add root=${XENGUEST_IMAGE_ROOT} to your guest kernel
|
||||
# command line
|
||||
# You can let this empty if the root filesystem is specified in an other way
|
||||
# and have root= option added to the command line for example or if you don't
|
||||
# need a root filesystem mounted for your guest (initrd for example)
|
||||
XENGUEST_IMAGE_ROOT ??= "/dev/xvda1"
|
||||
|
||||
# Guest kernel command line arguments
|
||||
XENGUEST_IMAGE_CMDLINE ??= "earlyprintk=xenboot console=hvc0 rw"
|
||||
|
||||
# Extra commands to add to xenguest-image when creating the image
|
||||
XENGUEST_IMAGE_EXTRA_CMD ??= ""
|
||||
|
||||
# Kernel binary
|
||||
# This value is used by the xenguest image type but is declared here to have
|
||||
# all variables in the same place
|
||||
# If this value is empty no kernel will be added to the image
|
||||
XENGUEST_IMAGE_KERNEL ??= "Image"
|
||||
|
||||
# Size of the disk to create (if 0 no disk will be created and rootfs will not
|
||||
# be included in the xenguest image)
|
||||
XENGUEST_IMAGE_DISK_SIZE ??= "${@ '4' if not d.getVar('INITRAMFS_IMAGE') else '0'}"
|
||||
|
||||
#
|
||||
# XENGUEST_IMAGE_DISK PARTITIONS is used to describe the partitions to setup
|
||||
# and their content.
|
||||
# It must be set to a space separated list of entries with each entry having
|
||||
# the format num:sz:fs:[file] where:
|
||||
# - num is a partition number
|
||||
# - sz is the partition size in Gigabit
|
||||
# - fs is the filesystem to use for the partition
|
||||
# - file is optionally pointing to a file to use as content of the partition
|
||||
# Please check image_types_xenguest.bbclass for rootfs handling of files
|
||||
#
|
||||
# Default value creates a partition 1 using the full disk, formated with ext4
|
||||
# and containing the root filesystem produced by Yocto
|
||||
XENGUEST_IMAGE_DISK_PARTITIONS ??= "1:${XENGUEST_IMAGE_DISK_SIZE}:ext4:rootfs.tar.gz"
|
||||
|
||||
# XENGUEST_IMAGE_NETWORK_TYPE can be set to "bridge", "nat" or "none".
|
||||
# The "bridge" type will share the physical eth interface from dom0 with the
|
||||
# domU. This will allow the domU to have access to the external network.
|
||||
# The "nat" type will setup a virtual network between dom0 and domU and also
|
||||
# configure and run the kea dhcp4 server on dom0 to serve the domU.
|
||||
# The "none" type will not affect any networking setting between on dom0 and
|
||||
# domU.
|
||||
XENGUEST_IMAGE_NETWORK_TYPE ??= "bridge"
|
||||
|
||||
# Sub-directory in wich the guest is created. This is create in deploy as a
|
||||
# subdirectory and must be coherent between all components using this class so
|
||||
# it must only be modified from local.conf if needed
|
||||
XENGUEST_IMAGE_DEPLOY_SUBDIR ?= "xenguest"
|
||||
|
||||
# Directory in which the xenguest should be deployed
|
||||
# a sub-directory named ${XENGUEST_IMAGE_DEPLOY_SUBDIR} will be created there.
|
||||
# This should be set to:
|
||||
# - ${DEPLOYDIR} (default) if creating or extending the xenguest for a normal
|
||||
# recipe.
|
||||
# - something in ${WORKDIR} if you need to clone and manipulate an image
|
||||
XENGUEST_IMAGE_DEPLOY_DIR ??= "${DEPLOYDIR}"
|
||||
|
||||
#
|
||||
# Wrapper to call xenguest-mkimage
|
||||
# It is using XENGUEST_IMAGE_DEPLOY_DIR and XENGUEST_IMAGE_DEPLOY_SUBDIR
|
||||
# to find the image to operate on
|
||||
#
|
||||
# Usage: call_xenguest_mkimage [operation] [args]
|
||||
call_xenguest_mkimage() {
|
||||
local cmd="${1}"
|
||||
local img="${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}"
|
||||
shift
|
||||
|
||||
echo "xenguest-mkimage $cmd $img $@"
|
||||
xenguest-mkimage $cmd $img $@
|
||||
}
|
||||
|
||||
#
|
||||
# Create an initial xenguest image.
|
||||
# This is a task which must be added in a recipe inheriting deploy
|
||||
# It is using XENGUEST_IMAGE_MEMORY_SIZE, XENGUEST_IMAGE_NUM_VCPUS,
|
||||
# XENGUEST_IMAGE_AUTOBOOT, XENGUEST_IMAGE_ROOT, XENGUEST_IMAGE_EXTRA_CMD,
|
||||
# XENGUEST_IMAGE_CMDLINE, XENGUEST_IMAGE_DISK_SIZE and
|
||||
# XENGUEST_IMAGE_DISK_PARTITIONS to customize the initial guest
|
||||
#
|
||||
xenguest_image_create() {
|
||||
if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
|
||||
-z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
|
||||
die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
|
||||
fi
|
||||
|
||||
rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
|
||||
|
||||
mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
|
||||
|
||||
# Create the image
|
||||
call_xenguest_mkimage create --xen-memory=${XENGUEST_IMAGE_MEMORY_SIZE} \
|
||||
--xen-vcpus=${XENGUEST_IMAGE_NUM_VCPUS} \
|
||||
--xen-root=${XENGUEST_IMAGE_ROOT} \
|
||||
${XENGUEST_IMAGE_EXTRA_CMD}
|
||||
|
||||
# add command line
|
||||
if [ -n "${XENGUEST_IMAGE_CMDLINE}" ]; then
|
||||
call_xenguest_mkimage update --xen-clean-extra
|
||||
for arg in ${XENGUEST_IMAGE_CMDLINE}; do
|
||||
call_xenguest_mkimage update --xen-extra=$arg
|
||||
done
|
||||
fi
|
||||
|
||||
# create disk if needed
|
||||
disksize="${XENGUEST_IMAGE_DISK_SIZE}"
|
||||
if [ -z "$disksize" ]; then
|
||||
disksize="0"
|
||||
fi
|
||||
if [ $disksize -gt 0 ]; then
|
||||
# setup disk size
|
||||
call_xenguest_mkimage update --disk-reset-config --disk-size=$disksize
|
||||
|
||||
diskparts="${XENGUEST_IMAGE_DISK_PARTITIONS}"
|
||||
if [ -n "$diskparts" ]; then
|
||||
for arg in $diskparts; do
|
||||
call_xenguest_mkimage update --disk-add-part=$arg
|
||||
partnum="$(expr $partnum + 1)"
|
||||
done
|
||||
fi
|
||||
fi
|
||||
|
||||
if [ "${XENGUEST_IMAGE_AUTOBOOT}" = "1" ]; then
|
||||
call_xenguest_mkimage update --set-param=GUEST_AUTOBOOT=1
|
||||
else
|
||||
call_xenguest_mkimage update --set-param=GUEST_AUTOBOOT=0
|
||||
fi
|
||||
|
||||
if [ -n "${XENGUEST_IMAGE_NETWORK_TYPE}" ]; then
|
||||
call_xenguest_mkimage update --set-param=XENGUEST_NETWORK_TYPE="${XENGUEST_IMAGE_NETWORK_TYPE}"
|
||||
else
|
||||
call_xenguest_mkimage update --set-param=XENGUEST_NETWORK_TYPE="none"
|
||||
fi
|
||||
}
|
||||
|
||||
#
|
||||
# Clone the current xenguest from deploy to manipulate it locally
|
||||
# This is required if you need to change things before packing an image
|
||||
# To set the local directory where to clone you must set
|
||||
# XENGUEST_IMAGE_DEPLOY_DIR if you don't want to use do_deploy to modify the
|
||||
# image
|
||||
#
|
||||
xenguest_image_clone() {
|
||||
if [ -z "${XENGUEST_IMAGE_DEPLOY_DIR}" -o \
|
||||
-z "${XENGUEST_IMAGE_DEPLOY_SUBDIR}" ]; then
|
||||
die "Configuration error: XENGUEST_IMAGE_DEPLOY_DIR or XENGUEST_IMAGE_DEPLOY_SUBDIR is empty"
|
||||
fi
|
||||
|
||||
if [ ! -f ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}/guest.cfg ]; then
|
||||
die "xenguest-image: ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR} does not contain a valid guest"
|
||||
fi
|
||||
|
||||
rm -rf ${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
|
||||
mkdir -p ${XENGUEST_IMAGE_DEPLOY_DIR}
|
||||
cp -rf ${DEPLOY_DIR_IMAGE}/${XENGUEST_IMAGE_DEPLOY_SUBDIR} \
|
||||
${XENGUEST_IMAGE_DEPLOY_DIR}/${XENGUEST_IMAGE_DEPLOY_SUBDIR}
|
||||
}
|
||||
|
||||
# Helper function to retrieve rootfs file if present in one partition
|
||||
# This can return an empty string or rootfs.tar[.COMP]
|
||||
def xenguest_image_rootfs_file(d):
|
||||
disksize = d.getVar('XENGUEST_IMAGE_DISK_SIZE')
|
||||
# if disksize is 0, we don't create anything
|
||||
if not disksize or disksize == '0':
|
||||
return ""
|
||||
# Find first partition with file=rootfs.tar*
|
||||
partlist = d.getVar('XENGUEST_IMAGE_DISK_PARTITIONS')
|
||||
if partlist:
|
||||
for partdesc in partlist.split():
|
||||
partelems = partdesc.split(':', 3)
|
||||
if partelems[3]:
|
||||
if partelems[3].startswith('rootfs.tar'):
|
||||
return partelems[3]
|
||||
return ""
|
||||
@@ -1,15 +0,0 @@
|
||||
# This files is added when DISTRO_FEATURES contains arm-autonomy-guest
|
||||
|
||||
# We need to have ipv4 activated
|
||||
DISTRO_FEATURES_append = " ipv4"
|
||||
|
||||
# Build a xenguest type image
|
||||
IMAGE_CLASSES += "image_types_xenguest"
|
||||
IMAGE_FSTYPES += "xenguest"
|
||||
|
||||
# xenguest kernel extension to handle initramfs
|
||||
KERNEL_CLASSES += "kernel-xenguest"
|
||||
|
||||
IMAGE_INSTALL_append = "${@bb.utils.contains('DISTRO_FEATURES', 'docker', \
|
||||
' packagegroup-docker-runtime-minimal', \
|
||||
'', d)}"
|
||||
@@ -1,21 +0,0 @@
|
||||
# This files is added when DISTRO_FEATURES contains arm-autonomy-host
|
||||
|
||||
# We need to have xen and ipv4 activated
|
||||
DISTRO_FEATURES_append = " xen ipv4"
|
||||
DISTRO_FEATURES_NATIVE_append = " arm-autonomy-host"
|
||||
|
||||
# Don't include kernels in standard images when building arm-autonomy-host
|
||||
# If the kernel image is needed in the rootfs the following should be set from
|
||||
# a bbappend: RDEPENDS_${KERNEL_PACKAGE_NAME}-base = "${KERNEL_PACKAGE_NAME}-image"
|
||||
RDEPENDS_${KERNEL_PACKAGE_NAME}-base ?= ""
|
||||
|
||||
# Require extra machine specific settings from meta-arm-bsp dynamic-layers only
|
||||
# if meta-arm-bsp is in the bblayers.conf
|
||||
# Directory for meta-arm-autonomy/dynamic-layers/meta-arm-bsp machine extra settings
|
||||
ARM_AUTONOMY_ARM_BSP_DYNAMIC_EXTRA_CFGDIR = "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/conf/machine"
|
||||
ARM_AUTONOMY_MACHINE_EXTRA_REQUIRE ?= \
|
||||
"${ARM_AUTONOMY_ARM_BSP_DYNAMIC_EXTRA_CFGDIR}/arm-autonomy-machine-extra-settings.inc"
|
||||
|
||||
require ${@bb.utils.contains('BBFILE_COLLECTIONS', 'meta-arm-bsp', \
|
||||
'${ARM_AUTONOMY_MACHINE_EXTRA_REQUIRE}' , \
|
||||
'', d)}
|
||||
@@ -1,39 +0,0 @@
|
||||
# Add layer to BBPATH
|
||||
BBPATH .= ":${LAYERDIR}"
|
||||
|
||||
# Add recipes-* directories to BBFILES
|
||||
BBFILES += " \
|
||||
${LAYERDIR}/recipes-*/*/*.bb \
|
||||
${LAYERDIR}/recipes-*/*/*.bbappend \
|
||||
"
|
||||
|
||||
BBFILE_COLLECTIONS += "meta-arm-autonomy"
|
||||
BBFILE_PATTERN_meta-arm-autonomy = "^${LAYERDIR}/"
|
||||
BBFILE_PRIORITY_meta-arm-autonomy = "6"
|
||||
LAYERDEPENDS_meta-arm-autonomy = " \
|
||||
core \
|
||||
yocto \
|
||||
openembedded-layer \
|
||||
networking-layer \
|
||||
virtualization-layer \
|
||||
"
|
||||
LAYERSERIES_COMPAT_meta-arm-autonomy = "gatesgarth"
|
||||
|
||||
# We don't activate virtualization feature from meta-virtualization as it
|
||||
# brings in lots of stuff we don't need. We need to disable the sanity check
|
||||
# otherwise the user will see a warning on each build.
|
||||
SKIP_META_VIRT_SANITY_CHECK = "1"
|
||||
|
||||
ARM_AUTONOMY_LAYERDIR := "${LAYERDIR}"
|
||||
# Directory of our distro config files
|
||||
ARM_AUTONOMY_DISTRO_CFGDIR = "${ARM_AUTONOMY_LAYERDIR}/conf/distro/include/"
|
||||
|
||||
# Add class to handle arm-autonomy distro extensions
|
||||
USER_CLASSES_append = " arm-autonomy-features"
|
||||
|
||||
BBFILES_DYNAMIC += " \
|
||||
meta-arm-bsp:${LAYERDIR}/dynamic-layers/meta-arm-bsp/*/*/*.bbappend \
|
||||
meta-gem5:${LAYERDIR}/dynamic-layers/meta-gem5/*/*/*.bbappend \
|
||||
"
|
||||
# Root directory for the meta-arm-autonomy/dynamic-layers/meta-arm-bsp
|
||||
ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR = "${ARM_AUTONOMY_LAYERDIR}/dynamic-layers/meta-arm-bsp"
|
||||
@@ -1,17 +0,0 @@
|
||||
#@TYPE: Machine
|
||||
#@NAME: Autonomy Guest ARM64 machine
|
||||
#@DESCRIPTION: Machine configuration for ARM64 Autonomy Guest
|
||||
|
||||
TUNE_FEATURES = "aarch64"
|
||||
|
||||
require conf/machine/include/arm/arch-armv8a.inc
|
||||
|
||||
KERNEL_IMAGETYPE = "Image"
|
||||
|
||||
IMAGE_FSTYPES += "tar.bz2"
|
||||
|
||||
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
|
||||
PREFERRED_VERSION_linux-yocto ?= "5.4%"
|
||||
|
||||
DISTRO_FEATURES += "arm-autonomy-guest"
|
||||
|
||||
@@ -1,195 +0,0 @@
|
||||
arm-autonomy Multiconfig Build Environment Instructions
|
||||
==================
|
||||
|
||||
This documentation explains how to simplify the process of building hosts
|
||||
and guests in a single bitbake command, rather than in seperate build
|
||||
folders. You can read more about multiconfig in the bitbake documentation:
|
||||
|
||||
- [bitbake user manual](https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html)
|
||||
|
||||
To achieve a multiconfig build, a number of different config files need to
|
||||
be created in a single build directory.
|
||||
|
||||
Create a new project
|
||||
----------------
|
||||
|
||||
Before you start, you will need to follow the instructions in
|
||||
"Create a project" from the quickstart guide, to create a new project
|
||||
directory with
|
||||
```
|
||||
oe-init-build-env my-mc-project
|
||||
```
|
||||
Ensure it has all the required layers in bblayers.conf as listed in
|
||||
`arm-autonomy-quickstart.md`. The result should be a directory containing:
|
||||
|
||||
```
|
||||
-- conf
|
||||
| -- bblayers.conf
|
||||
| -- local.conf
|
||||
| -- templateconf.cfg
|
||||
```
|
||||
|
||||
Add multiconfig
|
||||
----------------
|
||||
|
||||
Here are the steps required to make the project build both the host and any
|
||||
number of guests as required.
|
||||
|
||||
1. Create a new directory under `conf/` named `multiconfig/`
|
||||
|
||||
2. Create two new files in this directory:
|
||||
`multiconfig/host.conf`
|
||||
`multiconfig/guest.conf`
|
||||
These files will contain any configurations that a specific to either the
|
||||
host or the guest
|
||||
|
||||
```
|
||||
-- conf
|
||||
| -- bblayers.conf
|
||||
| -- local.conf
|
||||
| -- templateconf.cfg
|
||||
| -- multiconfig
|
||||
| -- host.conf
|
||||
| -- guest.conf
|
||||
```
|
||||
|
||||
3. In `local.conf` the following config variables must be added:
|
||||
|
||||
```
|
||||
MACHINE ?= "fvp-base"
|
||||
|
||||
# ---Guest Config Start--- #
|
||||
MC_GUEST = "guest"
|
||||
|
||||
MC_GUEST_NAME = "guest1"
|
||||
|
||||
MC_GUEST_IMAGERECIPE = "core-image-minimal"
|
||||
MC_GUEST_MACHINE = "arm64-autonomy-guest"
|
||||
|
||||
MC_GUEST_INITRAMFS_IMAGE_BUNDLE ?= ""
|
||||
MC_GUEST_INITRAMFS_IMAGE ?= ""
|
||||
|
||||
# Uncomment for initramfs
|
||||
#MC_GUEST_INITRAMFS_IMAGE_BUNDLE = "1"
|
||||
#MC_GUEST_INITRAMFS_IMAGE = "${MC_GUEST_IMAGERECIPE}"
|
||||
|
||||
# These variables are set automatically, don't edit them!
|
||||
MC_GUEST_FILENAME_PREFIX = "${@ 'Image-initramfs' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else '${MC_GUEST_IMAGERECIPE}' }"
|
||||
|
||||
MC_GUEST_FILENAME = "${MC_GUEST_FILENAME_PREFIX}-${MC_GUEST_MACHINE}.xenguest"
|
||||
|
||||
MC_GUEST_DEP = "${@ 'virtual/kernel:do_deploy' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else '${MC_GUEST_IMAGERECIPE}:do_image_complete'}"
|
||||
|
||||
MC_DOIMAGE_MCDEPENDS += "mc:${MC_HOST}:${MC_GUEST}:${MC_GUEST_DEP} "
|
||||
|
||||
BBMULTICONFIG += "${MC_GUEST} "
|
||||
|
||||
ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS += "file://${TOPDIR}/${MC_GUEST}/deploy/images/${MC_GUEST_MACHINE}/${MC_GUEST_FILENAME};guestname=${MC_GUEST_NAME} "
|
||||
# ---Guest Config End--- #
|
||||
|
||||
# ---Host Config Start--- #
|
||||
MC_HOST = "host"
|
||||
|
||||
BBMULTICONFIG += "${MC_HOST} "
|
||||
# ---Host Config End--- #
|
||||
```
|
||||
|
||||
These variables will be used in both of the multiconf files. `MC_HOST` and
|
||||
`MC_GUEST` should not be altered without renaming the conf files, but most
|
||||
`MC_GUEST_*` variables can be customised if you desire.
|
||||
|
||||
4. Next set the contents of `multiconfig/guest.conf`:
|
||||
|
||||
```
|
||||
TMPDIR = "${TOPDIR}/${MC_GUEST}"
|
||||
|
||||
MACHINE = "${MC_GUEST_MACHINE}"
|
||||
DISTRO_FEATURES += " arm-autonomy-guest"
|
||||
|
||||
INITRAMFS_IMAGE_BUNDLE = "${MC_GUEST_INITRAMFS_IMAGE_BUNDLE}"
|
||||
INITRAMFS_IMAGE = "${MC_GUEST_INITRAMFS_IMAGE}"
|
||||
|
||||
IMAGE_FSTYPES += "${@ 'cpio' if d.getVar('MC_GUEST_INITRAMFS_IMAGE_BUNDLE',d) else ''}"
|
||||
|
||||
# ANY OTHER GUEST CONFIG
|
||||
```
|
||||
|
||||
This contents shouldn't be changed directly, rather change the equivalent
|
||||
config in local.conf. You can append any other config desired for the
|
||||
guest at this point, for example `XENGUEST_IMAGE_DISK_SIZE`
|
||||
|
||||
Make sure not to change `${DEPLOY_DIR_IMAGE}` to anything other than
|
||||
`${TMPDIR}/deploy/images`, as this is assumed by local.conf.
|
||||
|
||||
5. Lastly set the contents of `multiconfig/host.conf`:
|
||||
|
||||
```
|
||||
TMPDIR = "${TOPDIR}/${MC_HOST}"
|
||||
|
||||
DISTRO_FEATURES += " arm-autonomy-host"
|
||||
```
|
||||
|
||||
Building the image
|
||||
----------------
|
||||
|
||||
To build the multiconfig image the command is:
|
||||
```
|
||||
bitbake mc:host:arm-autonomy-host-image-minimal
|
||||
```
|
||||
|
||||
You should see that this triggers guest tasks to be built in
|
||||
parallel. Once the build completes the guest will already be in the
|
||||
rootfs of the host thanks to `ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUEST`
|
||||
|
||||
The deployed image including the guest will be in `host/deploy/images/`
|
||||
|
||||
|
||||
Multiple Guests
|
||||
----------------
|
||||
|
||||
To have multiple guests with the same config the line which appends to
|
||||
`ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUEST` just needs to be duplicated with
|
||||
a different guestname.
|
||||
|
||||
To have different config for each guest, each will need its own config
|
||||
file similar to guest.conf, ensuring TMPDIR is set to a different path,
|
||||
and everything between `---Guest Config Start---` and
|
||||
`---Guest Config End---` will need to be duplicated.
|
||||
|
||||
Any copies of variables that start `MC_GUEST` must be altered to avoid
|
||||
collisions (e.g. `MC_GUEST_2_*`), and the name of the conf file must also
|
||||
be added to BBMULTICONFIG.
|
||||
|
||||
|
||||
Guest with provisioned disk
|
||||
----------------
|
||||
|
||||
To add guest rootfs partition to host wic image,
|
||||
set `AUTONOMY_HOST_EXTRA_PARTITION` with proper wks partition entry, e.g:
|
||||
|
||||
```
|
||||
AUTONOMY_HOST_EXTRA_PARTITION = "part --label provisioned-guest --source rawcopy --fstype=ext4 --ondisk sda --align 1024 \
|
||||
--sourceparams=file=${TOPDIR}/${MC_GUEST}/deploy/images/${MC_GUEST_MACHINE}/${MC_GUEST_FILENAME_PREFIX}-${MC_GUEST_MACHINE}.ext4"
|
||||
```
|
||||
|
||||
inside host.conf file.
|
||||
|
||||
The rest of the configuration has to be appended to guest.conf file:
|
||||
|
||||
```
|
||||
XENGUEST_IMAGE_DISK_SIZE = "0"
|
||||
XENGUEST_IMAGE_SRC_URI_XEN_CONFIG = "file://\${TOPDIR}/path/to/rootdisk.cfg"
|
||||
XENGUEST_IMAGE_DISK_DEVICE = "_GUEST_DISK_DEVICE_"
|
||||
XENGUEST_IMAGE_ROOT = "/dev/xvda"
|
||||
IMAGE_ROOTFS_SIZE = "102400"
|
||||
IMAGE_FSTYPES = "ext4"
|
||||
```
|
||||
|
||||
content of rootdisk.cfg"
|
||||
|
||||
```
|
||||
disk = ["phy:_GUEST_DISK_DEVICE_,xvda,w"]
|
||||
```
|
||||
|
||||
`_GUEST_DISK_DEVICE_` should be substituted with `/dev/sdaX`,
|
||||
according to wks file.
|
||||
@@ -1,236 +0,0 @@
|
||||
arm-autonomy Quick Start
|
||||
==================
|
||||
|
||||
This documentation is explaining how to quickly start with arm-autonomy layer
|
||||
and the main features provided.
|
||||
You will find in the documentation directory some more detailed documentation
|
||||
for each of the functionalites provided by this layer.
|
||||
|
||||
What to use this layer for?
|
||||
---------------------------
|
||||
Using this layer, you can easily and rapidly create a system based on Xen with
|
||||
one or more guests created using Yocto.
|
||||
|
||||
For this you will need to create at least 2 Yocto projects:
|
||||
- a host project: This one will compile Xen and create a Linux system to be
|
||||
used as Xen Dom0. The Linux system will contain all functionalities required
|
||||
to start and manage guests.
|
||||
- one or several guest projects: Those will create Linux systems with the
|
||||
required Linux kernel configuration to run as Xen DomU.
|
||||
|
||||
Prepare your system
|
||||
-------------------
|
||||
|
||||
First you must download the Yocto layers needed:
|
||||
- [meta-openembedded](https://git.openembedded.org/meta-openembedded)
|
||||
- [poky](https://git.yoctoproject.org/poky)
|
||||
- [meta-virtualization](https://git.yoctoproject.org/meta-virtualization)
|
||||
- [meta-arm](https://git.yoctoproject.org/meta-arm)
|
||||
- all other layers you might want to use
|
||||
|
||||
For each of the downloaded layer make sure you checkout the release of Yocto
|
||||
you want to use (for example zeus using `git checkout zeus`).
|
||||
|
||||
Please follow [Yocto documentation](https://www.yoctoproject.org/docs/latest/brief-yoctoprojectqs/brief-yoctoprojectqs.html)
|
||||
in order to have the required dependencies.
|
||||
|
||||
|
||||
Create a project
|
||||
----------------
|
||||
|
||||
Here are the main steps to create an arm-autonomy project:
|
||||
|
||||
1. create a new Yocto project using `oe-init-build-env` in a new directory:
|
||||
```
|
||||
oe-init-build-env my-project
|
||||
```
|
||||
|
||||
2. Add `meta-arm/meta-arm-autonomy` layer to the list of layers of your
|
||||
project in the `conf/bblayers.conf`. Also add any other layers you
|
||||
might need (for example `meta-arm/meta-arm-bsp` and `meta-arm/meta-arm` to
|
||||
use Arm boards like Juno or FVP emulator). You can achieve this by using
|
||||
the `bitbake-layers add-layer layerdir [layerdir ...]` command.
|
||||
For example:
|
||||
```
|
||||
export LAYERDIR_BASE="/home/user/arm-autonomy/"
|
||||
bitbake-layers add-layer $LAYERDIR_BASE/meta-poky $LAYERDIR_BASE/meta-yocto-bsp \
|
||||
$LAYERDIR_BASE/meta-openembedded/meta-oe $LAYERDIR_BASE/meta-openembedded/meta-python \
|
||||
$LAYERDIR_BASE/meta-openembedded/meta-filesystems $LAYERDIR_BASE/meta-openembedded/meta-networking \
|
||||
$LAYERDIR_BASE/meta-arm/meta-arm $LAYERDIR_BASE/meta-arm/meta-arm-toolchain \
|
||||
$LAYERDIR_BASE/meta-arm/meta-arm-bsp $LAYERDIR_BASE/meta-arm/meta-arm-autonomy \
|
||||
```
|
||||
|
||||
Example of a `conf/bblayers.conf`:
|
||||
```
|
||||
BBLAYERS ?= " \
|
||||
/home/user/arm-autonomy/poky/meta \
|
||||
/home/user/arm-autonomy/poky/meta-poky \
|
||||
/home/user/arm-autonomy/poky/meta-yocto-bsp \
|
||||
/home/user/arm-autonomy/meta-openembedded/meta-oe \
|
||||
/home/user/arm-autonomy/meta-openembedded/meta-python \
|
||||
/home/user/arm-autonomy/meta-openembedded/meta-filesystems \
|
||||
/home/user/arm-autonomy/meta-openembedded/meta-networking \
|
||||
/home/user/arm-autonomy/meta-virtualization \
|
||||
/home/user/arm-autonomy/meta-arm/meta-arm \
|
||||
/home/user/arm-autonomy/meta-arm/meta-arm-toolchain \
|
||||
/home/user/arm-autonomy/meta-arm/meta-arm-bsp \
|
||||
/home/user/arm-autonomy/meta-arm/meta-arm-autonomy \
|
||||
"
|
||||
```
|
||||
|
||||
Be aware that changing the order may break some dependencies if editing the
|
||||
config file manually.
|
||||
|
||||
Those steps will have to be done for each project you will have to create.
|
||||
|
||||
Host project
|
||||
------------
|
||||
The host project will build Xen and the Dom0 Linux. It will be the only project
|
||||
that will be specific to the board (MACHINE) you will be running on.
|
||||
|
||||
To create a host project:
|
||||
1. Follow the steps of "Create a project"
|
||||
|
||||
2. Add the layers in `bblayers.conf` required to build a Yocto project for the
|
||||
board you want to use.
|
||||
For example to use Arm FVP Base emulator, add `meta-arm/meta-arm` and
|
||||
`meta-arm/meta-arm-bsp`.
|
||||
|
||||
3. edit conf/local.conf to add `arm-autonomy-host` to the DISTRO_FEATURES and
|
||||
set MACHINE to the board you want to use.
|
||||
For example, add the following lines:
|
||||
```
|
||||
MACHINE = "fvp-base"
|
||||
DISTRO_FEATURES += "arm-autonomy-host"
|
||||
```
|
||||
|
||||
4. build the image using `bitbake arm-autonomy-host-image-minimal`
|
||||
|
||||
The project will generate a Linux kernel, a root filesystem, a Xen binary and
|
||||
a DTB modified to include the required entries to boot Xen and Linux as Dom0
|
||||
(this DTB has the extension `-xen.dtb`).
|
||||
|
||||
To boot the system using an u-boot base board you will need to:
|
||||
- Load the kernel (by default at 0x80080000 unless you modify
|
||||
XEN_DEVICETREE_DOM0_ADDR value)
|
||||
- Load the xen device tree (for example at 0x83000000)
|
||||
- Load the xen-efi binary (for example at 0x84000000)
|
||||
- run using `booti 0x84000000 - 0x83000000`
|
||||
|
||||
In this example the addresses might need to be adapted depending on your board.
|
||||
|
||||
For arm-autonomy host on FVP-Base u-boot has been modified such that
|
||||
`booti 0x84000000 - 0x83000000` is the default boot command. If FVP-Base is your
|
||||
MACHINE target there should be no need to interfere with u-boot.
|
||||
|
||||
Guest project
|
||||
-------------
|
||||
The guest projects are not target specific and will use a Yocto MACHINE defined
|
||||
in meta-arm-autonomy to include only the Linux configuration required to run
|
||||
a xen guest.
|
||||
|
||||
To create a guest project:
|
||||
|
||||
1. Follow the steps of "Create a project"
|
||||
|
||||
2. Optionaly add layers required to build the image and features you need.
|
||||
|
||||
3. edit conf/local.conf to add `arm-autonomy-guest` to the DISTRO_FEATURES and
|
||||
set MACHINE to `arm64-autonomy-guest`:
|
||||
```
|
||||
MACHINE = "arm64-autonomy-guest"
|
||||
DISTRO_FEATURES += "arm-autonomy-guest"
|
||||
```
|
||||
|
||||
4. build the image you want.
|
||||
For example `bitbake core-image-minimal`
|
||||
|
||||
The build will create a ".xenguest" image that can be use on an host project
|
||||
with the xenguest-manager.
|
||||
|
||||
The guest can also be built as a 'multiconfig' sub project of the host, see
|
||||
`meta-arm-autonomy/documentation/arm-autonomy-multiconfig.md` for more information
|
||||
|
||||
Include guests directly in the host image
|
||||
-----------------------------------------
|
||||
The layer provides a way to directly include in the host project one or several
|
||||
images generated by guest projects.
|
||||
|
||||
To use this feature, you must edit your host project `local.conf` file and
|
||||
add set ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS to the list of xenguest images
|
||||
you want to include in your host. Each xenguest image must be given using a
|
||||
full path to it.
|
||||
For example:
|
||||
```
|
||||
ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS = "/home/user/guest-project/tmp/deploy/images/arm64-autonomy-guest/core-image-minimal-arm64-autonomy-guest.xenguest;guestname=myguest"
|
||||
```
|
||||
This will add the guest and name it `myguest` on the host project image and
|
||||
the xenguest-manager will automatically boot it during startup.
|
||||
|
||||
Add support for your board
|
||||
--------------------------
|
||||
Most of arm-autonomy layer is board independent but some functionalities
|
||||
might need to be customized for your board:
|
||||
|
||||
### Add the kernel configuration for the host
|
||||
The layer is using KERNEL_FEATURES to add drivers required to be a Xen Dom0
|
||||
system.
|
||||
Depending on the kernel used by your BSP and how it is configured you might
|
||||
need to add the required drivers to your kernel configuration:
|
||||
- if KERNEL_FEATURES system is supported by your kernel, make sure that the
|
||||
file `recipes-kernel/linux/linux-arm-autonomy.inc` from the layer is included
|
||||
by your kernel recipe.
|
||||
- if it is not supported, you must add the proper drivers inside your kernel
|
||||
(modules are possible but they must be loaded before xenguest-manager is
|
||||
started). You can find the complete list of the kernel configuration elements
|
||||
required in `recipes-kernel/linux/arm-autonomy-kmeta/features/arm-autonomy/xen-host.cfg`.
|
||||
|
||||
### Define the drive and partition to use for the LVM volume
|
||||
The xenguest-manager is creating disk hard drive using LVM on an empty
|
||||
partition. The default value is set to use /dev/sda2.
|
||||
You can change this for your board by setting XENGUEST_MANAGER_VOLUME_DEVICE.
|
||||
|
||||
Check `recipes-extended/xenguest/xenguest-manager.bbappend` for examples.
|
||||
|
||||
Please also read xenguest-manager.md.
|
||||
|
||||
### Define the interface to add to xenguest network bridge
|
||||
xenguest-network bridge is creating a bridge on the host and adds network
|
||||
interfaces to it so that guest connected to it have access to external network.
|
||||
By default `eth0` is set as the list of interfaces to be added to the bridge.
|
||||
Depending on your board or use case you might want to use an other interface
|
||||
or use multiple interfaces.
|
||||
You can change this for your board by setting XENGUEST_NETWORK_BRIDGE_MEMBERS.
|
||||
|
||||
Check `recipes-extended/xenguest/xenguest-network-bridge.bbappend` for
|
||||
exmaples.
|
||||
|
||||
Please also read xenguest-network-bridge.md.
|
||||
|
||||
### Define the network configuration of the xenguest network bridge
|
||||
xenguest network bridge is putting the host network interfaces in a bridge
|
||||
and is configuring it by default to use dhcp.
|
||||
If you need a different type of configuration you can set
|
||||
XENGUEST_NETWORK_BRIDGE_CONFIG in a xenguest-network-bridge.bbappend to use
|
||||
a different file.
|
||||
The recipe will look for the file in ${WORKDIR} so you will need to add it to
|
||||
SRC_URI in your bbappend.
|
||||
The recipe will also substitute `###BRIDGE_NAME###` with the bridge name
|
||||
configured in ${XENGUEST_NETWORK_BRIDGE_NAME}.
|
||||
|
||||
You can find an example configuration file in
|
||||
`recipes-extended/xenguest/files/xenguest-network-bridge-dhcp.cfg.in`.
|
||||
|
||||
Please also read xenguest-network-bridge.md.
|
||||
|
||||
### Customize Dom0 and Xen boot arguments for you board
|
||||
xen-devicetree is writting inside the generated DTB Xen and Linux boot
|
||||
arguments as long as the address where Dom0 Linux kernel can be found.
|
||||
You might need to have different values for your board or depending on your
|
||||
use case.
|
||||
|
||||
You can find examples to customize this in
|
||||
`recipes-extended/xen-devicetree/xen-devicetree.bbappend`.
|
||||
|
||||
Please also read xen-devicetree.md.
|
||||
|
||||
@@ -1,29 +0,0 @@
|
||||
Customizing Arm Autonomy Host image layout for N1SDP
|
||||
====================================================
|
||||
|
||||
When buiding with `DISTRO_FEATURES += "arm-autonomy-host"` the user can
|
||||
perform a couple of customizations in the generated wic image:
|
||||
|
||||
1. Set the guest partition size (default: 4iG) via `GUEST_PART_SIZE` and
|
||||
`GUEST_PART_SIZE_UNIT` (M or G) variables to be set in any conf file. The
|
||||
value of these variables should be aligned with the sum of all
|
||||
XENGUEST_IMAGE_DISK_SIZE set for the guests. By default, LVM2 metadata is
|
||||
1 MiB per physical volume, hence it needs to be taken into account when
|
||||
setting GUEST_PART_SIZE.
|
||||
|
||||
2. The wic image partition layout and contents with a custom wks file via
|
||||
`ARM_AUTONOMY_WKS_FILE` variable (default:
|
||||
arm-autonomy-n1sdp-efidisk.wks.in which is affected by GUEST_PART_SIZE,
|
||||
GUEST_PART_SIZE_UNIT and GRUB_CFG_FILE variables).
|
||||
|
||||
3. Custom grub.cfg file via `GRUB_CFG_FILE` (default:
|
||||
arm-autonomy-n1sdp-grub.cfg) variable to be set in any conf file. The full
|
||||
path or relative to `ARM_AUTONOMY_WKS_FILE` should be set.
|
||||
|
||||
The `arm-autonomy-n1sdp-efidisk.wks.in` and `arm-autonomy-n1sdp-grub.cfg` files
|
||||
are located at `meta-arm-autonomy/dynamic-layers/meta-arm-bsp/wic`.
|
||||
|
||||
Other variables can also be custmized to set what files need to be included
|
||||
in the wic image boot partition. Please refer to
|
||||
`meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/n1sdp-extra-settings.inc`
|
||||
for more details.
|
||||
@@ -1,104 +0,0 @@
|
||||
Xen device tree
|
||||
===============
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
xen-devicetree recipe can be used to modify an existing Device Tree Blob,
|
||||
produced by Linux kernel or another recipe, to include in it entries required
|
||||
to start Xen and a Dom0 Linux on top of it.
|
||||
|
||||
The recipe will do the following processing:
|
||||
- generate a xen.dtsi file with entries required for xen based on parameters
|
||||
- turn DTBs in ${XEN_DEVICETREE_DTBS} back to dts
|
||||
- include in xen.dtsi and all other dtsi from
|
||||
${XEN_DEVICETREE_DTSI_MERGE} (check Bitbake parameters for more information
|
||||
on this).
|
||||
- use dtc to create a new DTB file
|
||||
|
||||
The recipe will generate new files in deploy/images and name them with the
|
||||
extension "-xen.dtb".
|
||||
For example **machine.dtb** will generate **machine-xen.dtb**.
|
||||
|
||||
Entries added to the DTBs
|
||||
-------------------------
|
||||
|
||||
When a DTB is processed by the recipe, the following block is added:
|
||||
```
|
||||
chosen {
|
||||
xen,dom0-bootargs = "VAL";
|
||||
xen,xen-bootargs = "VAL";
|
||||
|
||||
modules {
|
||||
#size-cells = <0x00000001>;
|
||||
#address-cells = <0x00000001>;
|
||||
|
||||
module@0 {
|
||||
reg = <VAL VAL>;
|
||||
compatible = "multiboot,module";
|
||||
};
|
||||
};
|
||||
};
|
||||
```
|
||||
Each occurence of **VAL** is replaced by the content of the variables listed in
|
||||
this documentation.
|
||||
|
||||
Bitbake parameters
|
||||
------------------
|
||||
|
||||
Several parameters are available to configure the xen-devicetree during Yocto
|
||||
project compilation (those can be set in your project local.conf, for exmple).
|
||||
|
||||
The following parameters are available:
|
||||
|
||||
- XEN_DEVICETREE_DEPEND: This variable can be used to indicate which recipe
|
||||
task is generating the DTBs that xen-devicetree will modify. This makes sure
|
||||
the xen devicetrees are properly regenerated if the source DTBs are changed.
|
||||
This variable is set by default to "virtual/kernel:do_deploy" to use DTBs
|
||||
generated during the compilation of the Linux kernel. This must be changed
|
||||
if the machine your are using is not using a DTB listed in KERNEL_DEVICETREE.
|
||||
|
||||
- XEN_DEVICETREE_DTBS: This should be set to the list of DTBs you want to be
|
||||
modified by xen-devicetree. Those must be files that xen-devicetree can find
|
||||
in the ${DEPLOY_DIR_IMAGE} directory using only the basename of the entries.
|
||||
For example "mydir/board.dtb" will make the recipe look for
|
||||
${DEPLOY_DIR_IMAGE}/board.dtb.
|
||||
This variable is set by default to "${KERNEL_DEVICETREE}" to process the DTBs
|
||||
generated by the Linux kernel.
|
||||
|
||||
- XEN_DEVICETREE_DOM0_MEM: Memory size to allocate to Dom0.
|
||||
This variable is only used if XEN_DEVICETREE_XEN_BOOTARGS has a value
|
||||
containing "dom0_mem=${XEN_DEVICETREE_DOM0_MEM}" as the memory assigned to
|
||||
dom0 is defined using Xen boot arguments.
|
||||
This variable is set by default to "1024M".
|
||||
|
||||
- XEN_DEVICETREE_DOM0_BOOTARGS: Boot arguments to pass to Dom0 Linux when
|
||||
booting it.
|
||||
This variable is set by default to "console=hvc0 earlycon=xen".
|
||||
|
||||
- XEN_DEVICETREE_XEN_BOOTARGS: this variable should be set with the boot
|
||||
arguments to be passed to Xen on boot.
|
||||
This variable is set by default to
|
||||
"noreboot dom0_mem=${XEN_DEVICETREE_DOM0_MEM}".
|
||||
|
||||
- XEN_DEVICETREE_DOM0_ADDR: This is the address from which the Linux kernel to
|
||||
be used for Dom0 will be copied. When using u-boot, this is the address at
|
||||
which you will load the kernel Image before starting Xen.
|
||||
This variable is set by default to "0x80080000".
|
||||
|
||||
- XEN_DEVICETREE_DOM0_SIZE: This is the size of the kernel loaded at
|
||||
${XEN_DEVICETREE_DOM0_ADDR}. Xen will copy this amount of data inside the
|
||||
guest before starting it so the size must be at least equal to the kernel
|
||||
size but can be bigger. You must be careful not to have a value too big as it
|
||||
could slow down boot or copy other parts with it (like the DTB).
|
||||
You might need to increase this if you use a kernel with a bundled initramfs.
|
||||
This variable is set by default to "0x01000000".
|
||||
|
||||
- XEN_DEVICETREE_DTSI_MERGE: This variable contains the list of dtsi files that
|
||||
must be included inside the generated DTB file. By default the only one
|
||||
include is the "xen.dtsi" generated by the recipe.
|
||||
If your board or project needs to include more fixes or entries in the DTB,
|
||||
this variable can be appended from a bbappend file to include other dtsi. The
|
||||
files must be inside the recipe workspace during Yocto compilation.
|
||||
You can check xen-devicetree.bbappend for an example.
|
||||
|
||||
@@ -1,101 +0,0 @@
|
||||
Xenguest Manager
|
||||
================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
xenguest-manager is a tool to manage Xenguest images generated by
|
||||
[xenguest-mkimage](xenguest-mkimage.md).
|
||||
|
||||
On a Xen Dom0 system it will:
|
||||
- create a xen guest from a xenguest image: extract its components, create a
|
||||
disk for the guest using LVM volumes.
|
||||
- start/stop a xen guest (during init or using xenguest-manager directly).
|
||||
- check guest status
|
||||
|
||||
xenguest-manager is composed of 2 shell scripts:
|
||||
- xenguest-manager which can be used from command line to start/stop/check
|
||||
guests and create or remove guest using xenguest images.
|
||||
- xenguest-init which is called during init to automatically create and start
|
||||
some guests as part of the host init process.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
xenguest-manager must be called like this:
|
||||
`xenguest-manager OPERATION [OPTIONS]`
|
||||
The following operations are available:
|
||||
- create XENGUEST_IMAGE [GUESTNAME]: create a guest from a xenguest image file
|
||||
as guest GUESTNAME. If GUESTNAME is not given the image file name is used
|
||||
without the xenguest extension.
|
||||
- remove GUESTNAME: remove the guest GUESTNAME.
|
||||
- start GUESTNAME: start the guest GUESTNAME.
|
||||
- stop GUESTNAME: stop the guest GUESTNAME (this is using `xl stop` which is
|
||||
sending a stop signal to the running guest).
|
||||
- kill GUESTNAME: force stopping the guest GUESTNAME.
|
||||
- list: list the available guests.
|
||||
- status [GUESTNAME]: print the current status of GUESTNAME. If GUESTNAME is
|
||||
not given, print the status of all guests.
|
||||
|
||||
For a detailed help on available options please use:
|
||||
`xenguest-manager --help`
|
||||
|
||||
Bitbake parameters
|
||||
------------------
|
||||
|
||||
Several parameters are available to configure the xenguest manager during Yocto
|
||||
project compilation (those can be set in your project local.conf, for example).
|
||||
|
||||
The following parameters are available:
|
||||
|
||||
- XENGUEST_MANAGER_VOLUME_DEVICE: This is the device path used by the
|
||||
xenguest-manager on the device to create LVM disks when guests have a disk
|
||||
configuration.
|
||||
This is set by default to "/dev/sda2".
|
||||
|
||||
- XENGUEST_MANAGER_VOLUME_NAME: This is the LVM volume name that the
|
||||
xenguest-manager will create and use to create guest LVM disks.
|
||||
This is set by default to "vg-xen".
|
||||
|
||||
- XENGUEST_MANAGER_GUEST_DIR: This is the directory on Dom0 where the
|
||||
xenguest-manager will look for xenguest images to create during init. That's
|
||||
the place where xenguest images can be added to have them automatically
|
||||
created during next Dom0 boot. The xenguests found there will only be created
|
||||
if they were not already before (the basename of the files is used as guest
|
||||
name).
|
||||
This is set by default to "/usr/share/guests".
|
||||
|
||||
Init scripts
|
||||
------------
|
||||
|
||||
Shell scripts can be executed on the host when a guest is started. Depending on
|
||||
when the script should be executed it should be installed in a different
|
||||
directory on the target:
|
||||
|
||||
- /etc/xenguest/init.pre : Executed first, prior to guest creation
|
||||
|
||||
- /etc/xenguest/init.d : Executed after guest creation, but before it is started
|
||||
|
||||
- /etc/xenguest/init.post : Executed after starting the guest
|
||||
|
||||
Inside the directory, scripts will be executed in alphabetical order.
|
||||
|
||||
Since these scripts are sourced by xenguest-manager they can acccess functions
|
||||
and variables from the parent file's scope, including:
|
||||
|
||||
- ${guestname} : The name of the guest being created
|
||||
|
||||
- ${guestdir} : The path to the guest directory
|
||||
|
||||
- ${guestcfgfile} : The name of the config file for the starting guest
|
||||
|
||||
- ${LOGFILE} : The file to append any logging to, e.g.
|
||||
echo "Hello, World" >> ${LOGFILE}
|
||||
|
||||
Sourcing also allows the script to access params.cfg.
|
||||
|
||||
|
||||
An example of how to create the directory and install an init shell script can
|
||||
be found in:
|
||||
recipes-extended/xenguest/xenguest-network.bb
|
||||
Where network-bridge.sh is installed from network-bridge.sh.in
|
||||
@@ -1,121 +0,0 @@
|
||||
Xenguest mkimage
|
||||
================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
xenguest-mkimage is a tool to create and modify images to be used as Guest with
|
||||
Xen. It defines a format to store completely defined guests as a file or as
|
||||
a directory and provides options to create and modify those images.
|
||||
|
||||
A xenguest image contains all elements required to create a xen guest.
|
||||
This is the base elements like a Xen configuration and a Linux kernel binary
|
||||
but also some more advanced elements like init scripts or a disk definition.
|
||||
|
||||
The format is made to be deployable easily by storing everything in a single
|
||||
file and provide tools to easily manipulate the images. It can also easily be
|
||||
extended to have features like encryption or signature of images, updates or
|
||||
complex configurations by providing features to have init script that will be
|
||||
executed on the host embedded inside the image.
|
||||
|
||||
Xenguest images content
|
||||
-----------------------
|
||||
|
||||
### params.cfg
|
||||
|
||||
This file contains parameters that can be used by tools to configure some
|
||||
functionalities on the host. This can be used by init scripts to have
|
||||
configurable parameters as it is sourced before calling init scripts.
|
||||
|
||||
### guest.cfg and guest.d
|
||||
|
||||
guest.cfg is the main xen configuration and guest.d contains optional
|
||||
configuration parts. All those will be merged into one final xen configuration
|
||||
before starting the guest.
|
||||
|
||||
### files
|
||||
This directory contains files that can be used by the xen configuration, for
|
||||
example the binary of the kernel referenced in xen configuration).
|
||||
This is where the kernel binary, the dtb or a ramdisk will be stored.
|
||||
|
||||
### init.pre, init.d and init.post
|
||||
These directories contain init scripts that will be executed on the host
|
||||
during the guest startup. Those must be shell scripts and each directory
|
||||
contains scripts called at a different time:
|
||||
- init.pre: scripts executed before the guest is created. This can be used
|
||||
to prepare some features required to create the guest in xen or to
|
||||
generate part of the xen configuration dynamically.
|
||||
- init.d: scripts executed when the guest has been created but before it is
|
||||
started. This can be used to do some xenstore operations or configure the
|
||||
guest behaviour using xl, for example.
|
||||
- init.post: scripts executed just after starting the guest. This can be
|
||||
used to configure things created by xen for the guest like network
|
||||
network interfaces.
|
||||
|
||||
When a directory contains several scripts, those will be called in alphabetical
|
||||
order.
|
||||
|
||||
### disk.cfg and disk-files
|
||||
disk.cfg contains the guest disk description (disk size and disk partitions).
|
||||
The file contains the following entries:
|
||||
- `DISK_SIZE=X`: size of the disk to create in GB
|
||||
- `DISK_PARTX=SIZE:FS:CONTENT`: create a partition number X (1 to 4) with a
|
||||
size of SIZE GB, format it with filesystem FS (can be ext2, ext3, ext4, vfat
|
||||
or swap) and extract CONTENT as initial partition content
|
||||
(.tar[.gz|.xz|.bz2] file or img[.gz|.bz2] file to be dumped in the partition). FS and
|
||||
CONTENT can be empty.
|
||||
|
||||
The disk-files contain files to be used for initializing the disk partitions
|
||||
content. Those should be used to create a LVM or a physical disk and initialize
|
||||
it (create partitions, format them and put the initial content).
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
xenguest-mkimage is a shell script which must be called like this:
|
||||
`xenguest-mkimage OPERATION XENGUEST [OPTIONS]`
|
||||
|
||||
### Operations
|
||||
- create: create a xenguest image. If XENGUEST is an existing empty directory,
|
||||
the image is created as a directory otherwise it will be created as a file.
|
||||
- check: verify that XENGUEST is a valid xenguest image.
|
||||
- update: modify a xenguest image (see --help for a list of operations).
|
||||
- pack: pack a xenguest image directory into a xenguest image file. The file to
|
||||
be created must be given as 3rd argument.
|
||||
- extract: extract a xenguest image file into a directory. The destination
|
||||
directory must be given as 3rd argument.
|
||||
- dump-xenconfig: dump xenguest image xen configuration.
|
||||
- dump-diskconfig: dump xenguest image disk configuration.
|
||||
- dump-paramsconfig: dump xenguest image parameters configuration.
|
||||
|
||||
For a detailed help on available operations, please use:
|
||||
`xenguest-mkimage --help`
|
||||
|
||||
### Options
|
||||
- --kernel=FILE: add kernel FILE as guest kernel. This is both adding the file
|
||||
to the image and modifying the xen configuration to use it.
|
||||
- --xen-memory=SIZE: set the guest memory size in MB.
|
||||
- --xen-extra: add a kernel command line argument. This can be called several
|
||||
times to add several command line options.
|
||||
- --xen-device-tree=FILE: add dtb FILE as device tree. This both adding the
|
||||
file to the image and modifying the xen configuration to use it.
|
||||
- --xen-ramdisk=FILE: add ramdisk FILE as guest ramdisk. This both adding the
|
||||
file to the image and modifying the xen configuration to use it.
|
||||
- --init-script=FILE: add guest init script. The script is embedded inside the
|
||||
image file. Several script can be added and the basename of FILE is used to
|
||||
distinguish them (calling the option twice with the same file will update the
|
||||
script in the image with the second one).
|
||||
--disk-size=SIZE: set the guest disk size to SIZE in GB. Calling this with 0
|
||||
disable the guest disk.
|
||||
- --disk-add-part=NUM:SIZE:FS:CONTENT: This is adding a partition to the
|
||||
xenguest image disk. The partition is described with the arguments:
|
||||
- NUM: partition number.
|
||||
- SIZE: partition size in GB.
|
||||
- FS: filesystem to format the partition with. This can be ext2, ext3, ext4,
|
||||
vfat of swap. If empty the partition is not formated.
|
||||
- CONTENT: tar of img file to use to initialize the partition. The file must
|
||||
be added to the image using --disk-add-file=FILE:CONTENT.
|
||||
|
||||
For a detailed help on available options, please use:
|
||||
`xenguest-mkimage OPERATION --help`
|
||||
|
||||
@@ -1,80 +0,0 @@
|
||||
Xenguest Network
|
||||
================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The xenguest-network package is primarly creating a network bridge to share
|
||||
the host eth physical interfaces with the guests virtual interfaces (vif).
|
||||
This way the guests can have access to the external network.
|
||||
|
||||
At the moment 3 types of network arrangements are provided:
|
||||
|
||||
- Bridge: where the guest vif is added to the created bridge interface;
|
||||
|
||||
- NAT: where a private subnet is created for the guest,
|
||||
a kea dhcp4 server is started on the host to serve the guest
|
||||
and the proper iptables rules are created
|
||||
to allow the guest to access the external network;
|
||||
|
||||
- None: the guest vif is not connected to the bridge.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
On the host project the package xenguest-network must be included in your
|
||||
image, and on the guest project the XENGUEST_NETWORK_TYPE needs to be set to
|
||||
"bridge", "nat" or "none".
|
||||
|
||||
Bitbake parameters
|
||||
------------------
|
||||
|
||||
Several parameters are available to configure the xenguest network bridge
|
||||
during Yocto project compilation (those can be set in your project local.conf
|
||||
or xenguest-network.bbappend, for example).
|
||||
|
||||
The following parameters are available:
|
||||
|
||||
- XENGUEST_NETWORK_BRIDGE_NAME: This variable defines the name of the network
|
||||
bridge that is created on the host during init.
|
||||
This is set by default to "xenbr0".
|
||||
|
||||
- XENGUEST_NETWORK_BRIDGE_MEMBERS: This variable defines the list of the
|
||||
physical network interfaces that are added to the bridge when it is created
|
||||
on the host during init.
|
||||
By default no physical interfaces are added.
|
||||
|
||||
- XENGUEST_NETWORK_BRIDGE_CONFIG: This variable defines the configuration file
|
||||
to use to configure the bridge network. By default it points to have file
|
||||
configuring the network using dhcp.
|
||||
You can provide a different file using a bbappend and make this variable
|
||||
point to it if you want to customize your network configuration.
|
||||
|
||||
- XENGUEST_IMAGE_NETWORK_TYPE: This variable can be set to "bridge" (default),
|
||||
"nat" or "none".
|
||||
The **bridge** type will add the domU vif interface to a bridge which also
|
||||
contains the dom0 physical interface giving the guest direct access to the
|
||||
external network.
|
||||
The **nat** type will setup a private network between dom0 and domU, setup
|
||||
the appropriate routing table, configure and run the kea dhcp4 server
|
||||
on dom0 to serve the domU and apply the iptables rules to allow the guest
|
||||
to acess the external network. The kea dhcp4 server configuration for
|
||||
the guest can be customised by replacing the
|
||||
"meta-arm-autonomy/recipes-extended/xenguest/files/kea-subnet4.json" file
|
||||
in a xenguest-network.bbappend. The kea-subnet4.json file is installed in
|
||||
the xenguest image and copied to
|
||||
"/etc/xenguest/guests/${guestname}/files/kea-subnet4.json" when the guest
|
||||
image is created. It will be consumed by the
|
||||
"/etc/xen/scripts/vif-post.d/00-vif-xenguest.hook" script which is called by
|
||||
"/etc/xen/scripts/vif-nat" script when starting/stopping the xenguest.
|
||||
After guest start, "/etc/xenguest/init.post/xenguest-network-init-post.sh"
|
||||
script is called to reload kea dhcp4 server with updated configuration,
|
||||
after virtual network interface is ready.
|
||||
In the guest project, the NAT port forward can be customised by changing
|
||||
the XENGUEST_IMAGE_HOST_PORT (default: "1000 + ${domid}") and
|
||||
XENGUEST_IMAGE_GUEST_PORT (default: "22") variables in local.conf or
|
||||
xenguest-base-image.bbappend. This configuration is implemented and installed
|
||||
in "/etc/xenguest/guests/${guestname}/files/00-xenguest-nat-port-forward.hook"
|
||||
script which is called by "/etc/xen/scripts/vif-post.d/00-vif-xenguest.hook".
|
||||
The **none** type will not affect any networking setting between on dom0 and
|
||||
domU.
|
||||
-7
@@ -1,7 +0,0 @@
|
||||
# Require extra machine specific settings
|
||||
ARM_BSP_DYN_MACHINE_EXTRA_REQUIRE ?= ""
|
||||
ARM_BSP_DYN_MACHINE_EXTRA_REQUIRE_n1sdp = "n1sdp-extra-settings.inc"
|
||||
ARM_BSP_DYN_MACHINE_EXTRA_REQUIRE_fvp-base = "fvp-base-extra-settings.inc"
|
||||
ARM_BSP_DYN_MACHINE_EXTRA_REQUIRE_juno = "juno-extra-settings.inc"
|
||||
|
||||
require ${ARM_BSP_DYN_MACHINE_EXTRA_REQUIRE}
|
||||
@@ -1,7 +0,0 @@
|
||||
# Extra machine settings for fvp-base
|
||||
|
||||
# FVP uses vda as hard drive and partition 2 is the
|
||||
# default rootfs, so use vda3 for guest lvm
|
||||
XENGUEST_MANAGER_VOLUME_DEVICE ?= "/dev/vda3"
|
||||
|
||||
XENGUEST_NETWORK_BRIDGE_MEMBERS ?= "eth0"
|
||||
@@ -1,26 +0,0 @@
|
||||
# Extra machine settings for juno
|
||||
KERNEL_ALT_IMAGETYPE = "Image.lzma"
|
||||
|
||||
# Juno board has 2 network interfaces, add both of them to the bridge
|
||||
XENGUEST_NETWORK_BRIDGE_MEMBERS ?= "eth0 eth1"
|
||||
XEN_DEVICETREE_DOM0_SIZE ?= "0x02400000"
|
||||
|
||||
# We need to extend the wks search path to be able to find the wks file set in
|
||||
# ARM_AUTONOMY_WKS_FILE.
|
||||
WKS_SEARCH_PATH_prepend := "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic:"
|
||||
|
||||
ARM_AUTONOMY_WKS_FILE ?= "arm-autonomy-juno-disk.wks.in"
|
||||
# set wks file only if INITRAMFS_IMAGE_BUNDLE is not set
|
||||
WKS_FILE = "${@bb.utils.contains('INITRAMFS_IMAGE_BUNDLE', '1', '',\
|
||||
'${ARM_AUTONOMY_WKS_FILE}', d)}"
|
||||
|
||||
# Set the wks guest partition size and unit. It must be aligned with the sum of
|
||||
# all XENGUEST_IMAGE_DISK_SIZE set for the guests. By default, LVM2 metadata is
|
||||
# 1 MiB per physical volume, hence it needs to be taken into account when
|
||||
# setting GUEST_PART_SIZE. The XENGUEST_IMAGE_DISK_SIZE default value is 4GiB.
|
||||
GUEST_PART_SIZE ?= "4097"
|
||||
GUEST_PART_SIZE_UNIT ?= "M"
|
||||
|
||||
# set wic image type only if INITRAMFS_IMAGE_BUNDLE is not set
|
||||
IMAGE_FSTYPES += "${@bb.utils.contains('INITRAMFS_IMAGE_BUNDLE', '1', '',\
|
||||
'wic wic.gz wic.bmap', d)}"
|
||||
@@ -1,40 +0,0 @@
|
||||
# Extra machine settings for n1sdp
|
||||
|
||||
# We need to extent the wks search path to be able to find the wks file set in
|
||||
# ARM_AUTONOMY_WKS_FILE.
|
||||
WKS_SEARCH_PATH_prepend := "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic:"
|
||||
|
||||
ARM_AUTONOMY_WKS_FILE ?= "arm-autonomy-n1sdp-efidisk.wks.in"
|
||||
WKS_FILE = "${ARM_AUTONOMY_WKS_FILE}"
|
||||
|
||||
# Set the wks guest partition size and unit. It must be aligned with the sum of
|
||||
# all XENGUEST_IMAGE_DISK_SIZE set for the guests. By default, LVM2 metadata is
|
||||
# 1 MiB per physical volume, hence it needs to be taken into account when
|
||||
# setting GUEST_PART_SIZE. The XENGUEST_IMAGE_DISK_SIZE default value is 4GiB.
|
||||
GUEST_PART_SIZE ?= "4097"
|
||||
GUEST_PART_SIZE_UNIT ?= "M"
|
||||
|
||||
# The GRUB_CFG_FILE affects arm-autonomy-n1sdp-efidisk.wks.in file
|
||||
GRUB_CFG_FILE ?= "${ARM_AUTONOMY_ARM_BSP_DYNAMIC_DIR}/wic/arm-autonomy-n1sdp-grub.cfg"
|
||||
|
||||
# From arm-autonomy-n1sdp-efidisk.wks.in, the /boot partition is /dev/sda1, and
|
||||
# the "/" partition is /dev/sda2.
|
||||
XENGUEST_MANAGER_VOLUME_DEVICE ?= "/dev/sda3"
|
||||
|
||||
XENGUEST_NETWORK_BRIDGE_MEMBERS ?= "eth0"
|
||||
|
||||
# The XEN_DEVICETREE_DEPEND and XEN_DEVICETREE_DTBS variables aftect the
|
||||
# xen-devicetree.bb recipe
|
||||
XEN_DEVICETREE_DEPEND = "virtual/trusted-firmware-a:do_deploy"
|
||||
XEN_DEVICETREE_DTBS ?= "n1sdp-single-chip.dtb"
|
||||
# XEN_MOD_DEVICETREE_DTBS are the generated devicetrees for Xen. By default the
|
||||
# xen-devicetree.bb recipe adds '-xen' suffix to it
|
||||
XEN_MOD_DEVICETREE_DTBS ?= "n1sdp-single-chip-xen.dtb"
|
||||
|
||||
# When generating the wic image we need to have the xen deployed
|
||||
do_image_wic[depends] += "xen:do_deploy"
|
||||
|
||||
# Select the extra files to be included in the boot partition
|
||||
IMAGE_EFI_BOOT_FILES += "xen-n1sdp.efi;xen.efi"
|
||||
IMAGE_EFI_BOOT_FILES += "${XEN_MOD_DEVICETREE_DTBS}"
|
||||
|
||||
-50
@@ -1,50 +0,0 @@
|
||||
# Use OVERRIDES to minimize the usage of
|
||||
# ${@bb.utils.contains('DISTRO_FEATURES', 'xen', ...
|
||||
OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ':xen', '', d)}"
|
||||
|
||||
FILESEXTRAPATHS_prepend_xen := "${THISDIR}/${PN}:"
|
||||
|
||||
DEPENDS_append_xen = " dos2unix-native"
|
||||
|
||||
SRC_URI_append_xen = " file://add-xen-support.patch;patchdir=../"
|
||||
|
||||
do_install_append_xen() {
|
||||
mv -v ${D}/${UNPACK_DIR}/SOFTWARE/uEnv.txt \
|
||||
${D}/${UNPACK_DIR}/SOFTWARE/uenvfile
|
||||
for dir in $(ls ${D}/${UNPACK_DIR}/SITE1/)
|
||||
do
|
||||
unix2dos ${D}/${UNPACK_DIR}/SITE1/${dir}/images.txt
|
||||
done
|
||||
}
|
||||
|
||||
DEPLOY_EXTRA_DEPS ??= ""
|
||||
DEPLOY_EXTRA_DEPS_xen = "xen:do_deploy xen-devicetree:do_deploy"
|
||||
|
||||
do_deploy[depends] += "${DEPLOY_EXTRA_DEPS}"
|
||||
|
||||
do_deploy_prepend_xen() {
|
||||
# To avoid dependency loop between firmware-image-juno:do_install,
|
||||
# xen:do_deploy and xen-devicetree:do_deploy when
|
||||
# INITRAMFS_IMAGE_BUNDLE = "1", we need to handle the xen and
|
||||
# xen-devicetree binaries copying in the do_deploy task.
|
||||
|
||||
mkdir -p ${D}/${UNPACK_DIR}/SOFTWARE/XEN
|
||||
cp -v ${DEPLOY_DIR_IMAGE}/xen-${COMPATIBLE_MACHINE}.efi \
|
||||
${D}/${UNPACK_DIR}/SOFTWARE/XEN/xen
|
||||
|
||||
for dtb in $(basename -s .dtb ${KERNEL_DEVICETREE})
|
||||
do
|
||||
cp -v ${DEPLOY_DIR_IMAGE}/${dtb}-xen.dtb \
|
||||
${D}/${UNPACK_DIR}/SOFTWARE/XEN/${dtb}.dtb
|
||||
done
|
||||
|
||||
bbnote "Xen binaries added under SOFTWARE/XEN directory"
|
||||
|
||||
if [ "${INITRAMFS_IMAGE_BUNDLE}" != "1" -a "${KERNEL_ALT_IMAGETYPE}" = "Image.lzma" ]; then
|
||||
# KERNEL_ALT_IMAGETYPE is expected to be Image.lzma,
|
||||
# however NOR flash filesystem is DOS compatible with 8.3 naming,
|
||||
# so we need to replace ".lzma" with ".lzm"
|
||||
cp -L -f ${DEPLOY_DIR_IMAGE}/${KERNEL_ALT_IMAGETYPE} \
|
||||
${D}/${UNPACK_DIR}/SOFTWARE/Image.lzm
|
||||
fi
|
||||
}
|
||||
-173
@@ -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;
|
||||
|
||||
-11
@@ -1,11 +0,0 @@
|
||||
/*
|
||||
* Disable IOMMU on juno board when Xen is used
|
||||
*/
|
||||
|
||||
/ {
|
||||
|
||||
/* turn off iommu */
|
||||
iommu@2b600000 {
|
||||
status = "disabled";
|
||||
};
|
||||
};
|
||||
-41
@@ -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
@@ -1,23 +0,0 @@
|
||||
# Platform dependent parameters
|
||||
|
||||
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
|
||||
|
||||
# Add a dtb snippet to turn off iommu in dom0 on Juno board
|
||||
SRC_URI_append_juno = " file://xen-juno.dtsi"
|
||||
XEN_DEVICETREE_DTSI_MERGE_append_juno = " xen-juno.dtsi"
|
||||
|
||||
# Add a dtb snippet to remove pmu and iommu in dom0 on N1SDP
|
||||
SRC_URI_append_n1sdp = " file://xen-n1sdp.dtsi"
|
||||
XEN_DEVICETREE_DTSI_MERGE_append_n1sdp = " xen-n1sdp.dtsi"
|
||||
# For N1SDP, the XEN_DEVICETREE_DEPEND and XEN_DEVICETREE_DTBS variables are
|
||||
# being set in meta-arm-autonomy/dynamic-layers/meta-arm-bsp/conf/machine/n1sdp-extra-settings.inc
|
||||
|
||||
# Board specific configs
|
||||
XEN_DEVICETREE_DOM0_BOOTARGS_append_juno = " root=/dev/sda1 rootwait"
|
||||
XEN_DEVICETREE_XEN_BOOTARGS_append_juno = " console=dtuart dtuart=serial0 bootscrub=0 iommu=no"
|
||||
|
||||
XEN_DEVICETREE_DOM0_BOOTARGS_append_n1sdp = " root=/dev/sda2 rootwait"
|
||||
XEN_DEVICETREE_XEN_BOOTARGS_append_n1sdp = " console=dtuart dtuart=serial0 bootscrub=0 iommu=no"
|
||||
|
||||
XEN_DEVICETREE_DOM0_BOOTARGS_append_fvp-base = " root=/dev/vda2"
|
||||
XEN_DEVICETREE_XEN_BOOTARGS_append_fvp-base = " console=dtuart dtuart=serial0 bootscrub=0"
|
||||
-2
@@ -1,2 +0,0 @@
|
||||
CONFIG_DEBUG=y
|
||||
CONFIG_EARLY_PRINTK_FASTMODEL=y
|
||||
-2
@@ -1,2 +0,0 @@
|
||||
CONFIG_DEBUG=y
|
||||
CONFIG_EARLY_PRINTK_JUNO=y
|
||||
-3
@@ -1,3 +0,0 @@
|
||||
CONFIG_DEBUG=y
|
||||
CONFIG_EARLY_UART_CHOICE_PL011=y
|
||||
CONFIG_EARLY_UART_BASE_ADDRESS=0x2a400000
|
||||
-5
@@ -1,5 +0,0 @@
|
||||
CONFIG_EXPERT=y
|
||||
# Enable ACPI support
|
||||
CONFIG_ACPI=y
|
||||
# Enable ARM Interrupt Translation Service (ITS) emulation
|
||||
CONFIG_HAS_ITS=y
|
||||
@@ -1,15 +0,0 @@
|
||||
# FVP Base support
|
||||
COMPATIBLE_MACHINE_fvp-base = "fvp-base"
|
||||
FILESEXTRAPATHS_prepend_fvp-base := "${THISDIR}/files:"
|
||||
SRC_URI_append_fvp-base = " file://early-printk.cfg"
|
||||
|
||||
# Juno support
|
||||
COMPATIBLE_MACHINE_juno = "juno"
|
||||
FILESEXTRAPATHS_prepend_juno := "${THISDIR}/files:"
|
||||
SRC_URI_append_juno = " file://early-printk.cfg"
|
||||
|
||||
# N1SDP support
|
||||
COMPATIBLE_MACHINE_n1sdp = "n1sdp"
|
||||
FILESEXTRAPATHS_prepend_n1sdp := "${THISDIR}/files:"
|
||||
SRC_URI_append_n1sdp = " file://n1sdp.cfg \
|
||||
file://early-printk.cfg"
|
||||
-4
@@ -1,4 +0,0 @@
|
||||
# We need to turn off SVE support in the Linux kernel otherwise Xen is stopping
|
||||
# Linux kernel with a coredump while trying to access ZEN bit of CPACR1 core
|
||||
# register.
|
||||
# CONFIG_ARM64_SVE is not set
|
||||
-3
@@ -1,3 +0,0 @@
|
||||
define KFEATURE_DESCRIPTION "Disable SVE support"
|
||||
|
||||
kconf non-hardware disable-arm64-sve.cfg
|
||||
@@ -1,15 +0,0 @@
|
||||
FILESEXTRAPATHS_prepend := "${THISDIR}:"
|
||||
|
||||
#
|
||||
# arm-autonomy kmeta extra
|
||||
#
|
||||
SRC_URI_append = " file://arm-autonomy-kmeta-extra;type=kmeta;name=arm-autonomy-kmeta-extra;destsuffix=arm-autonomy-kmeta-extra"
|
||||
|
||||
# We need to turn off SVE support in the Linux kernel otherwise Xen is stopping
|
||||
# Linux kernel with a coredump while trying to access XEN bit of CPACR1 core
|
||||
# register.
|
||||
LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE = "${@bb.utils.contains_any('DISTRO_FEATURES', \
|
||||
'arm-autonomy-host arm-autonomy-guest', \
|
||||
' features/arm-autonomy/disable-arm64-sve.scc','',d)}"
|
||||
|
||||
KERNEL_FEATURES_append_fvp-base = "${LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE}"
|
||||
@@ -1,14 +0,0 @@
|
||||
# short-description: Create a disk image
|
||||
# long-description: Creates a partitioned disk image that the user
|
||||
# can directly dd to boot media.
|
||||
|
||||
# For Juno first partition is rootfs normally populated as /dev/sda1
|
||||
part / --source rootfs --ondisk sda --fstype=ext4 --label root --align 1024
|
||||
|
||||
# Second partition to accomodate guests images normally populated as /dev/sda2 (used by XENGUEST_MANAGER_VOLUME_DEVICE)
|
||||
part --label guests --source empty --ondisk sda --size="${GUEST_PART_SIZE}${GUEST_PART_SIZE_UNIT}" --system-id 8e --align 1024
|
||||
|
||||
# Third partition is user defined entry normally populated as /dev/sda3
|
||||
${AUTONOMY_HOST_EXTRA_PARTITION}
|
||||
|
||||
bootloader --ptable msdos
|
||||
@@ -1,17 +0,0 @@
|
||||
# short-description: Create an EFI disk image
|
||||
# long-description: Creates a partitioned EFI disk image that the user
|
||||
# can directly dd to boot media. Uses a custom grub.cfg file to configure the boot.
|
||||
|
||||
# First boot partition normally populated as /dev/sda1
|
||||
part /boot --source bootimg-efi --sourceparams="loader=grub-efi" --ondisk sda --label msdos --active --align 1024
|
||||
|
||||
# Second rootfs partition normally populated as /dev/sda2
|
||||
part / --source rootfs --ondisk sda --fstype=ext4 --label root --align 1024
|
||||
|
||||
# Third partition to accomodate guests images normally populated as /dev/sda3 (used by XENGUEST_MANAGER_VOLUME_DEVICE)
|
||||
part --label guests --source empty --ondisk sda --size="${GUEST_PART_SIZE}${GUEST_PART_SIZE_UNIT}" --system-id 8e --align 1024
|
||||
|
||||
# Fourth partition is user defined entry normally populated as /dev/sda4
|
||||
${AUTONOMY_HOST_EXTRA_PARTITION}
|
||||
|
||||
bootloader --ptable msdos --configfile="${GRUB_CFG_FILE}"
|
||||
@@ -1,28 +0,0 @@
|
||||
set term="vt100"
|
||||
set default="3"
|
||||
set timeout="5"
|
||||
|
||||
set kernel_cmdline="earlycon=pl011,0x2A400000 console=ttyAMA0,115200 root=/dev/sda2 rootwait"
|
||||
|
||||
menuentry 'N1SDP ACPI Boot' {
|
||||
linux /Image $kernel_cmdline acpi=force
|
||||
}
|
||||
|
||||
menuentry 'N1SDP Single-Chip Boot (Device Tree)' {
|
||||
devicetree /n1sdp-single-chip.dtb
|
||||
linux /Image $kernel_cmdline
|
||||
}
|
||||
|
||||
menuentry 'N1SDP Multi-Chip Boot (Device Tree)' {
|
||||
devicetree /n1sdp-multi-chip.dtb
|
||||
linux /Image $kernel_cmdline
|
||||
}
|
||||
|
||||
menuentry 'N1SDP Arm Autonomy (Xen) Single-Chip Boot (Device Tree)' {
|
||||
# no_argumants under here is a workaround for a bug
|
||||
# also any kernel or dom0 cmdline arguments has to be passed via dtb
|
||||
# because any arguments put here will be ignored by xen
|
||||
xen_hypervisor /xen.efi no_arguments=use_dtb_for_xen_or_kernel_cmdline
|
||||
xen_module /Image
|
||||
devicetree /n1sdp-single-chip-xen.dtb
|
||||
}
|
||||
-32
@@ -1,32 +0,0 @@
|
||||
# Use OVERRIDES to minimize the usage of
|
||||
# ${@bb.utils.contains('DISTRO_FEATURES', 'xen', ...
|
||||
OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ':xen', '', d)}"
|
||||
|
||||
# Xen image to put in the image
|
||||
# This should point to a file in the deploy image directory
|
||||
BOOT_WRAPPER_AARCH64_XEN ??= "xen-${MACHINE}"
|
||||
|
||||
# Xen command line for the image
|
||||
BOOT_WRAPPER_AARCH64_XEN_CMDLINE ??= "noreboot dom0_mem=256M"
|
||||
|
||||
BOOT_WRAPPER_AARCH64_XEN_CMDLINE_gem5-arm64 = "noreboot dom0_mem=256M console=dtuart \
|
||||
dtuart=/uart@1c090000 bootscrub=0"
|
||||
|
||||
# Fix command line in the axf file for gem5-arm64 when Xen is present
|
||||
BOOT_WRAPPER_AARCH64_CMDLINE_xen_gem5-arm64 = "console=hvc0 root=/dev/vda rw"
|
||||
|
||||
# Image generated by boot wrapper when Xen is present
|
||||
BOOT_WRAPPER_AARCH64_IMAGE_xen ?= "xen-system.axf"
|
||||
|
||||
EXTRA_OECONF_append_xen = " \
|
||||
--with-xen=${WORKDIR}/kernel/arch/arm64/boot/Image \
|
||||
--with-xen-cmdline="" \
|
||||
"
|
||||
|
||||
EXTRA_OEMAKE_append_xen = " \
|
||||
XEN_IMAGE=${DEPLOY_DIR_IMAGE}/${BOOT_WRAPPER_AARCH64_XEN} \
|
||||
XEN_CMDLINE="${BOOT_WRAPPER_AARCH64_XEN_CMDLINE}" \
|
||||
"
|
||||
|
||||
# We need xen if it is activated
|
||||
do_deploy[depends] += "${@bb.utils.contains('DISTRO_FEATURES', 'xen', 'xen:do_deploy', '', d)}"
|
||||
-7
@@ -1,7 +0,0 @@
|
||||
# When booting gem5-arm64 with Xen we need to set the cpu as Cortex A53 and
|
||||
# remove support for pointer authentification
|
||||
GEM5_RUN_EXTRA_append = " \
|
||||
${@bb.utils.contains('DISTRO_FEATURES_NATIVE', 'arm-autonomy-host', \
|
||||
'--param=system.cpu_cluster[0].cpus[0].isa[0].midr=0x410fd030 \
|
||||
--param=system.cpu_cluster[0].cpus[0].isa[0].id_aa64isar1_el1=0x0', \
|
||||
'', d)}"
|
||||
-2
@@ -1,2 +0,0 @@
|
||||
CONFIG_DEBUG=y
|
||||
CONFIG_EARLY_PRINTK_VEXPRESS=y
|
||||
@@ -1,4 +0,0 @@
|
||||
# gem5-arm64 support
|
||||
COMPATIBLE_MACHINE_gem5-arm64 = "gem5-arm64"
|
||||
FILESEXTRAPATHS_prepend_gem5-arm64 := "${THISDIR}/files:"
|
||||
SRC_URI_append_gem5-arm64 = " file://early-printk.cfg"
|
||||
-1
@@ -1 +0,0 @@
|
||||
XENGUEST_NETWORK_BRIDGE_MEMBERS_gem5-arm64 ?= "eth0"
|
||||
-4
@@ -1,4 +0,0 @@
|
||||
# We need to turn off SVE support in the Linux kernel otherwise Xen is stopping
|
||||
# Linux kernel with a coredump while trying to access ZEN bit of CPACR1 core
|
||||
# register.
|
||||
# CONFIG_ARM64_SVE is not set
|
||||
-3
@@ -1,3 +0,0 @@
|
||||
define KFEATURE_DESCRIPTION "Disable SVE support"
|
||||
|
||||
kconf non-hardware disable-arm64-sve.cfg
|
||||
@@ -1,15 +0,0 @@
|
||||
FILESEXTRAPATHS_prepend_gem5-arm64 := "${THISDIR}:"
|
||||
|
||||
#
|
||||
# arm-autonomy kmeta extra
|
||||
#
|
||||
SRC_URI_append_gem5-arm64 = " file://arm-autonomy-kmeta-extra-gem5;type=kmeta;name=arm-autonomy-kmeta-extra-gem5;destsuffix=arm-autonomy-kmeta-extra-gem5"
|
||||
|
||||
# We need to turn off SVE support in the Linux kernel otherwise Xen is stopping
|
||||
# Linux kernel with a coredump while trying to access XEN bit of CPACR1 core
|
||||
# register.
|
||||
LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE_gem5-arm64 = "${@bb.utils.contains_any('DISTRO_FEATURES', \
|
||||
'arm-autonomy-host arm-autonomy-guest', \
|
||||
' features/arm-autonomy/disable-arm64-sve.scc','',d)}"
|
||||
|
||||
KERNEL_FEATURES_append_gem5-arm64 = "${LINUX_ARM_AUTONOMY_DISABLE_ARM64_SVE}"
|
||||
@@ -1 +0,0 @@
|
||||
GRUB_BUILDIN += "${@bb.utils.contains('DISTRO_FEATURES', 'xen', 'xen_boot', '', d)}"
|
||||
-16
@@ -1,16 +0,0 @@
|
||||
Upstream Status: Inappropriate [meta-arm-autonomy specifc u-boot config]
|
||||
Signed-off-by: Nathan Dunne <nathan.dunne@arm.com>
|
||||
|
||||
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h
|
||||
index e63c335f85..9ee050a4a6 100644
|
||||
--- a/include/configs/vexpress_aemv8a.h
|
||||
+++ b/include/configs/vexpress_aemv8a.h
|
||||
@@ -162,7 +162,7 @@
|
||||
#elif CONFIG_TARGET_VEXPRESS64_BASE_FVP
|
||||
#define CONFIG_EXTRA_ENV_SETTINGS \
|
||||
"kernel_name=Image\0" \
|
||||
- "kernel_addr=0x80080000\0" \
|
||||
+ "kernel_addr=0x84000000\0" \
|
||||
"initrd_name=ramdisk.img\0" \
|
||||
"initrd_addr=0x88000000\0" \
|
||||
"fdtfile=devtree.dtb\0" \
|
||||
@@ -1,9 +0,0 @@
|
||||
# Machine specific u-boot
|
||||
|
||||
FILESEXTRAPATHS_prepend := "${THISDIR}/${BP}:"
|
||||
|
||||
#
|
||||
# FVP BASE
|
||||
#
|
||||
|
||||
SRC_URI_append_fvp-base = "${@bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', ' file://xen_u-boot_kernel_addr.patch', '', d)}"
|
||||
-19
@@ -1,19 +0,0 @@
|
||||
# SPDX-License-Identifier: MIT
|
||||
#
|
||||
# Copyright (c) 2020 Arm Limited
|
||||
#
|
||||
|
||||
SUMMARY = "Docker runtime minimal requirements"
|
||||
DESCRIPTION = "The minimal set of packages required for running Docker"
|
||||
|
||||
inherit packagegroup
|
||||
|
||||
RDEPENDS_${PN} = "\
|
||||
docker-ce \
|
||||
docker-ce-contrib \
|
||||
kernel-module-xt-nat \
|
||||
kernel-module-xt-masquerade \
|
||||
kernel-module-xt-addrtype \
|
||||
kernel-module-xt-conntrack \
|
||||
kernel-module-xt-ipvs \
|
||||
"
|
||||
@@ -1,145 +0,0 @@
|
||||
# Recipe to create a minimal Arm Autonomy stack host image
|
||||
|
||||
DESCRIPTION = "Arm Autonomy stack host minimal image"
|
||||
|
||||
inherit core-image
|
||||
|
||||
LICENSE = "MIT"
|
||||
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
|
||||
|
||||
# The ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS variable can be used to include in the
|
||||
# image one or several xenguest images.
|
||||
# The list must be space separated and each entry must have the following
|
||||
# format: URL[;guestname=NAME]
|
||||
# - URL can be the full path to a file or a Yocto compatible SRC_URI url
|
||||
# - guestname=NAME can be used to specify the name of the guest. If not
|
||||
# specified the basename of the file (without .xenguest extension) is used.
|
||||
# Here are examples of values:
|
||||
# /home/mydir/myguest.xenguest;guestname=guest1
|
||||
# http://www.url.com/testguest.xenguest
|
||||
#
|
||||
# If you are using the output of an other Yocto project, you should use the
|
||||
# full path syntax instead of the Yocto SRC_URI to be able to use the
|
||||
# symlink version of your image (as the real file has a new name on each
|
||||
# build as it includes the date). You must not use SRC_URI type file:// as
|
||||
# it will try to include the symlink and not the destination file which will
|
||||
# be detected by the recipe and output an error 'Guest file is a symlink'.
|
||||
#
|
||||
# Guests can also be added using a bbapend to this recipe by adding entries
|
||||
# to SRC_URI with parameter ;guestname=NAME to specify the destination
|
||||
# guestname. The parameter guestname must be present as it is used to detect
|
||||
# guests to be added
|
||||
ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS ??= ""
|
||||
|
||||
# Includes minimal set required to start and manage guest. The xen specific
|
||||
# modules are not explicitly included as they are built as part of the kernel
|
||||
# image for performance reasons. It doesn't include all kernel modules to
|
||||
# reduce the image size. If the kernel-modules packages are needed they can
|
||||
# be appended to IMAGE_INSTALL in a bbappend.
|
||||
IMAGE_INSTALL += " \
|
||||
packagegroup-core-boot \
|
||||
packagegroup-core-ssh-openssh \
|
||||
qemu-system-i386 \
|
||||
xenguest-manager \
|
||||
xenguest-network \
|
||||
"
|
||||
|
||||
# Build xen binary
|
||||
EXTRA_IMAGEDEPENDS += "xen"
|
||||
|
||||
# Build xen-devicetree to produce a xen ready devicetree
|
||||
EXTRA_IMAGEDEPENDS += "xen-devicetree"
|
||||
|
||||
# Documentation for setting up a multiconfig build can be found in:
|
||||
# meta-arm-autonomy/documentation/arm-autonomy-multiconfig.md
|
||||
|
||||
# In a multiconfig build this variable will hold a dependency string, which differs based
|
||||
# on whether the guest has initramfs or not.
|
||||
# It may have a space seperated list of dependency strings if mulitple guest types are
|
||||
# configured
|
||||
MC_DOIMAGE_MCDEPENDS ?= ""
|
||||
# Example value: mc:host:guest:core-image-minimal:do_image_complete
|
||||
|
||||
# In a multiconfig build the host task 'do_image' has a dependency on multiconfig guest.
|
||||
# This ensures that the guest image file already exists when it is needed by the host
|
||||
DO_IMAGE_MCDEPENDS := "${@ '${MC_DOIMAGE_MCDEPENDS}' if d.getVar('BBMULTICONFIG') else ''}"
|
||||
|
||||
# Apply mc dependency. Empty string if multiconfig not enabled
|
||||
do_image[mcdepends] += "${DO_IMAGE_MCDEPENDS}"
|
||||
|
||||
|
||||
python __anonymous() {
|
||||
if bb.utils.contains('DISTRO_FEATURES', 'arm-autonomy-host', False, True, d):
|
||||
raise bb.parse.SkipRecipe("DISTRO_FEATURES does not contain 'arm-autonomy-host'")
|
||||
|
||||
if bb.utils.contains('DISTRO_FEATURES', 'xen', False, True, d):
|
||||
raise bb.parse.SkipRecipe("DISTRO_FEATURES does not contain 'xen'")
|
||||
|
||||
# Check in ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS for extra guests and add them
|
||||
# to SRC_URI with xenguest parameter if not set
|
||||
guestlist = d.getVar('ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS')
|
||||
if guestlist:
|
||||
for guest in guestlist.split():
|
||||
# If the user just specified a file instead of file://FILE, add
|
||||
# the file:// prefix
|
||||
if guest.startswith('/'):
|
||||
guestfile = ''
|
||||
guestname = ''
|
||||
if ';guestname=' in guest:
|
||||
# user specified a guestname
|
||||
guestname = guest.split(';guestname=')[1]
|
||||
guestfile = guest.split(';guestname=')[0]
|
||||
else:
|
||||
# no guestname so use the basename
|
||||
guestname = os.path.basename(guest)
|
||||
guestfile = guest
|
||||
# in case we have a link we need the destination
|
||||
guestfile = os.path.realpath(guestfile)
|
||||
|
||||
# make sure the file exist to give a meaningfull error
|
||||
if not os.path.exists(guestfile):
|
||||
raise bb.parse.SkipRecipe("ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS entry does not exist: " + guest)
|
||||
|
||||
# In case the file is a symlink make sure we use the destination
|
||||
d.appendVar('SRC_URI', ' file://' + guestfile + ';guestname=' + guestname)
|
||||
else:
|
||||
# we have a Yocto URL
|
||||
try:
|
||||
_, _, path, _, _, parm = bb.fetch.decodeurl(guest)
|
||||
# force guestname param in if not already there
|
||||
if not 'guestname' in parm:
|
||||
guest += ';guestname=' + os.path.basename(path)
|
||||
d.appendVar('SRC_URI', ' ' + guest)
|
||||
except:
|
||||
raise bb.parse.SkipRecipe("ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS contains an invalid entry: " + guest)
|
||||
}
|
||||
|
||||
python add_extern_guests () {
|
||||
# Destination directory on the rootfs
|
||||
guestdir = d.getVar('IMAGE_ROOTFS') + d.getVar('datadir') + '/guests'
|
||||
|
||||
# Parse SRC_URI for files with ;guestname= parameter
|
||||
src_uri = d.getVar('SRC_URI')
|
||||
for entry in src_uri.split():
|
||||
_, _, path, _, _, parm = bb.fetch.decodeurl(entry)
|
||||
if 'guestname' in parm:
|
||||
if os.path.islink(path):
|
||||
realpath = os.path.realpath(path)
|
||||
|
||||
if not os.path.exists(realpath):
|
||||
bb.fatal("ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS link does not resolve: " + path)
|
||||
|
||||
bb.note("Guest file is a symlink:\n " + path + "\nResolved to:\n " + realpath)
|
||||
path = realpath
|
||||
|
||||
bb.utils.mkdirhier(guestdir)
|
||||
dstname = parm['guestname']
|
||||
# Add file extension if not there
|
||||
if not dstname.endswith('.xenguest'):
|
||||
dstname += '.xenguest'
|
||||
if not bb.utils.copyfile(path, guestdir + '/' + dstname):
|
||||
bb.fatal("Fail to copy Guest file " + path)
|
||||
}
|
||||
|
||||
IMAGE_PREPROCESS_COMMAND += "add_extern_guests; "
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
# Add support for interface configuration via interfaces.d directory. This
|
||||
# feature can be used by other packages to add network interface
|
||||
# configuration by adding network network interface configuration file under
|
||||
# interfaces.d directory.
|
||||
|
||||
do_install_append() {
|
||||
# Add scan of interfaces.d to interfaces file
|
||||
cp -f ${WORKDIR}/interfaces ${WORKDIR}/interfaces.subdir
|
||||
echo "source-directory ${sysconfdir}/network/interfaces.d/" \
|
||||
>> ${WORKDIR}/interfaces.subdir
|
||||
|
||||
# Create interfaces.d script in case nobody is adding a script
|
||||
# so that there is no error about non existing directory
|
||||
install -d -m 755 ${D}${sysconfdir}/network/interfaces.d
|
||||
|
||||
# Install our file instead of the original one
|
||||
install -m 644 interfaces.subdir ${D}${sysconfdir}/network/interfaces
|
||||
}
|
||||
@@ -1,16 +0,0 @@
|
||||
# if arm-autonomy-guest is activated, we are running as a xen guest so we must
|
||||
# have a console on hvc0
|
||||
# This is normally done in meta-virtualization if xen is activated but here
|
||||
# we don't have xen activated.
|
||||
#
|
||||
|
||||
SYSVINIT_ADDHVC0 = "${@bb.utils.contains('DISTRO_FEATURES', \
|
||||
'arm-autonomy-guest', 'true', 'false', d)}"
|
||||
|
||||
do_install_append() {
|
||||
if ${SYSVINIT_ADDHVC0}; then
|
||||
echo "" >> ${D}${sysconfdir}/inittab
|
||||
echo "X0:12345:respawn:/sbin/getty 115200 hvc0" >> \
|
||||
${D}${sysconfdir}/inittab
|
||||
fi
|
||||
}
|
||||
@@ -1,12 +0,0 @@
|
||||
# Use OVERRIDES to minimize the usage of
|
||||
# ${@bb.utils.contains('DISTRO_FEATURES', 'xen', ...
|
||||
OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ':xen', '', d)}"
|
||||
|
||||
# For Xen we only need the i386 binaries
|
||||
QEMU_TARGETS_xen = "i386"
|
||||
|
||||
PACKAGECONFIG[noaudio] = "--audio-drv-list='',,"
|
||||
PACKAGECONFIG_append_xen = " noaudio"
|
||||
PACKAGECONFIG_remove_xen = "fdt sdl kvm"
|
||||
|
||||
require ${@bb.utils.contains('DISTRO_FEATURES', 'xen', 'recipes-devtools/qemu/${BPN}-package-split.inc', '', d)}
|
||||
@@ -1,17 +0,0 @@
|
||||
/ {
|
||||
chosen {
|
||||
xen,dom0-bootargs = "###XEN_DOM0_BOOTARGS###";
|
||||
xen,xen-bootargs = "###XEN_XEN_BOOTARGS###";
|
||||
|
||||
modules {
|
||||
#size-cells = <0x00000001>;
|
||||
#address-cells = <0x00000001>;
|
||||
|
||||
module@0 {
|
||||
reg = <###XEN_DOM0_ADDR### ###XEN_DOM0_SIZE###>;
|
||||
compatible = "multiboot,module";
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@@ -1,101 +0,0 @@
|
||||
# This recipe can be used to modify one or several DTBS to add
|
||||
# entries required to declare and boot Linux as Dom0 from Xen
|
||||
|
||||
SRC_URI = "file://xen.dtsi.in"
|
||||
|
||||
LICENSE = "MIT"
|
||||
LIC_FILES_CHKSUM = "\
|
||||
file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \
|
||||
"
|
||||
|
||||
S = "${WORKDIR}"
|
||||
|
||||
DESCRIPTION = "Add entries in DTB for Xen and Dom0"
|
||||
|
||||
# Please refer to documentation/xen-devicetree.md for documentation on those
|
||||
# parameters
|
||||
# kernel size is passed to xen via xen.dtb so wee need to add
|
||||
# 'virtual/kernel:do_deploy' as a dependency
|
||||
XEN_DEVICETREE_DEPEND_append = " virtual/kernel:do_deploy"
|
||||
XEN_DEVICETREE_DTBS ?= "${KERNEL_DEVICETREE}"
|
||||
XEN_DEVICETREE_XEN_BOOTARGS ?= "noreboot dom0_mem=${XEN_DEVICETREE_DOM0_MEM}"
|
||||
XEN_DEVICETREE_DOM0_MEM ?= "1024M"
|
||||
XEN_DEVICETREE_DOM0_BOOTARGS ?= "console=hvc0 earlycon=xen"
|
||||
XEN_DEVICETREE_DOM0_ADDR ?= "0x80080000"
|
||||
XEN_DEVICETREE_DOM0_SIZE ?= "0x01000000"
|
||||
XEN_DEVICETREE_DTSI_MERGE ?= "xen.dtsi"
|
||||
|
||||
# Our package does not generate any package for the rootfs but contributes to
|
||||
# deploy
|
||||
inherit nopackages deploy
|
||||
|
||||
DEPENDS += "dtc-native"
|
||||
|
||||
do_configure[noexec] = "1"
|
||||
do_compile[noexec] = "1"
|
||||
do_install[noexec] = "1"
|
||||
|
||||
do_deploy() {
|
||||
if [ ! -f ${WORKDIR}/xen.dtsi.in ]; then
|
||||
die "xen.dtsi.in does not exist"
|
||||
fi
|
||||
cat ${WORKDIR}/xen.dtsi.in \
|
||||
| sed -e "s?###XEN_DOM0_BOOTARGS###?${XEN_DEVICETREE_DOM0_BOOTARGS}?" \
|
||||
| sed -e "s?###XEN_XEN_BOOTARGS###?${XEN_DEVICETREE_XEN_BOOTARGS}?" \
|
||||
| sed -e "s?###XEN_DOM0_ADDR###?${XEN_DEVICETREE_DOM0_ADDR}?" \
|
||||
| sed -e "s?###XEN_DOM0_SIZE###?${XEN_DEVICETREE_DOM0_SIZE}?" \
|
||||
> ${WORKDIR}/xen.dtsi
|
||||
|
||||
# Generate final dtbs
|
||||
for dtbf in ${XEN_DEVICETREE_DTBS}; do
|
||||
rdtb=`basename $dtbf`
|
||||
if [ ! -f ${DEPLOY_DIR_IMAGE}/$rdtb ]; then
|
||||
die "Wrong file in XEN_DEVICETREE_DTBS: ${DEPLOY_DIR_IMAGE}/$rdtb does not exist"
|
||||
fi
|
||||
dtc -I dtb -O dts -o ${WORKDIR}/dom0-linux.dts ${DEPLOY_DIR_IMAGE}/$rdtb
|
||||
|
||||
# Add external includes
|
||||
for inc in ${XEN_DEVICETREE_DTSI_MERGE}; do
|
||||
if [ ! -f ${WORKDIR}/${inc} ]; then
|
||||
die "Wrong file in XEN_DEVICETREE_DTSI_MERGE: ${WORKDIR}/${inc} does not exist"
|
||||
fi
|
||||
echo "/include/ \"$inc\"" >> ${WORKDIR}/dom0-linux.dts
|
||||
done
|
||||
|
||||
rdtbnoextn=`basename $dtbf ".dtb"`
|
||||
dtc -I dts -O dtb \
|
||||
-o ${WORKDIR}/${rdtbnoextn}-xen.dtb ${WORKDIR}/dom0-linux.dts
|
||||
install -m 644 ${rdtbnoextn}-xen.dtb ${DEPLOYDIR}/.
|
||||
done
|
||||
}
|
||||
do_deploy[depends] += "${XEN_DEVICETREE_DEPEND}"
|
||||
do_deploy[prefuncs] += "calc_xen_dtb_dom0_size"
|
||||
|
||||
addtask deploy after do_install
|
||||
|
||||
python calc_xen_dtb_dom0_size() {
|
||||
from math import ceil
|
||||
size = 0
|
||||
if d.getVar('KERNEL_IMAGE_MAXSIZE'):
|
||||
bb.note('size calculation based on KERNEL_IMAGE_MAXSIZE')
|
||||
size = int(d.getVar('KERNEL_IMAGE_MAXSIZE')) * 1024
|
||||
else:
|
||||
kernel = os.path.realpath(d.getVar('DEPLOY_DIR_IMAGE') + '/' +\
|
||||
d.getVar('KERNEL_IMAGETYPE'))
|
||||
size = os.stat(kernel).st_size
|
||||
bb.note('size calculation based on kernel Image file: %s' % kernel)
|
||||
|
||||
bb.note('size in bytes: %d' % size)
|
||||
# Ceil to MiB
|
||||
size_required = ceil(size / (2 ** 20)) * (2 ** 20)
|
||||
size_defined = int(d.getVar('XEN_DEVICETREE_DOM0_SIZE'), 16)
|
||||
|
||||
if size_required > size_defined:
|
||||
bb.warn ("Wrong kernel size setting inside xen dtb!\n"\
|
||||
"Required:\t%(req)d (%(req)#010X)\n"\
|
||||
"Requested:\t%(def)d (%(def)#010X)"\
|
||||
% {"req": size_required, "def": size_defined})
|
||||
bb.warn ("Overriding XEN_DEVICETREE_DOM0_SIZE with "\
|
||||
"%(req)d (%(req)#010X)" % {"req": size_required})
|
||||
d.setVar('XEN_DEVICETREE_DOM0_SIZE', hex(size_required))
|
||||
}
|
||||
-51
@@ -1,51 +0,0 @@
|
||||
From f4c1a541fa351e4f613471bbf397931f9e1ddd27 Mon Sep 17 00:00:00 2001
|
||||
Message-Id: <f4c1a541fa351e4f613471bbf397931f9e1ddd27.1602683707.git.diego.sueiro@arm.com>
|
||||
From: Wei Chen <wei.chen@arm.com>
|
||||
Date: Fri, 28 Aug 2020 02:34:04 +0000
|
||||
Subject: [PATCH] xen/arm: Throw messages for unknown FP/SIMD implement ID
|
||||
|
||||
Arm ID_AA64PFR0_EL1 register provides two fields to describe CPU
|
||||
FP/SIMD implementations. Currently, we exactly know the meaning of
|
||||
0x0, 0x1 and 0xf of these fields. Xen treats value < 8 as FP/SIMD
|
||||
features presented. If there is a value 0x2 bumped in the future,
|
||||
Xen behaviors for value <= 0x1 can also take effect. But what Xen
|
||||
done for value <= 0x1 may not always cover new value 0x2 required.
|
||||
We throw these messages to break the silence when Xen detected
|
||||
unknown FP/SIMD IDs to notice user to check.
|
||||
|
||||
Signed-off-by: Wei Chen <wei.chen@arm.com>
|
||||
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
|
||||
Acked-by: Julien Grall <jgrall@amazon.com>
|
||||
|
||||
Upstream-Status: Backport
|
||||
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
|
||||
---
|
||||
xen/arch/arm/setup.c | 12 ++++++++++++
|
||||
1 file changed, 12 insertions(+)
|
||||
|
||||
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
|
||||
index 7968cee..f16b33f 100644
|
||||
--- a/xen/arch/arm/setup.c
|
||||
+++ b/xen/arch/arm/setup.c
|
||||
@@ -133,6 +133,18 @@ static void __init processor_id(void)
|
||||
cpu_has_simd ? " AdvancedSIMD" : "",
|
||||
cpu_has_gicv3 ? " GICv3-SysReg" : "");
|
||||
|
||||
+ /* Warn user if we find unknown floating-point features */
|
||||
+ if ( cpu_has_fp && (boot_cpu_feature64(fp) >= 2) )
|
||||
+ printk(XENLOG_WARNING "WARNING: Unknown Floating-point ID:%d, "
|
||||
+ "this may result in corruption on the platform\n",
|
||||
+ boot_cpu_feature64(fp));
|
||||
+
|
||||
+ /* Warn user if we find unknown AdvancedSIMD features */
|
||||
+ if ( cpu_has_simd && (boot_cpu_feature64(simd) >= 2) )
|
||||
+ printk(XENLOG_WARNING "WARNING: Unknown AdvancedSIMD ID:%d, "
|
||||
+ "this may result in corruption on the platform\n",
|
||||
+ boot_cpu_feature64(simd));
|
||||
+
|
||||
printk(" Debug Features: %016"PRIx64" %016"PRIx64"\n",
|
||||
boot_cpu_data.dbg64.bits[0], boot_cpu_data.dbg64.bits[1]);
|
||||
printk(" Auxiliary Features: %016"PRIx64" %016"PRIx64"\n",
|
||||
--
|
||||
2.7.4
|
||||
|
||||
@@ -1,34 +0,0 @@
|
||||
Upstream-Status: Backport
|
||||
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
|
||||
Signed-off-by: Kamil Dziezyk <kamil.dziezyk@arm.com>
|
||||
|
||||
From 5499e0fc8082024bf7e2d0facd5c976e82105070 Mon Sep 17 00:00:00 2001
|
||||
From: Diego Sueiro <diego.sueiro@arm.com>
|
||||
Date: Thu, 20 Aug 2020 11:58:20 +0100
|
||||
Subject: [PATCH] tools/hotplug: Fix hostname setting in vif-nat
|
||||
|
||||
Setting the hostname is failing because the "$XENBUS_PATH/domain"
|
||||
doesn't exist anymore. To fix this we set it to dom$domid
|
||||
|
||||
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
|
||||
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
|
||||
Acked-by: Wei Liu <wl@xen.org>
|
||||
---
|
||||
tools/hotplug/Linux/vif-nat | 2 +-
|
||||
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||
|
||||
diff --git a/tools/hotplug/Linux/vif-nat b/tools/hotplug/Linux/vif-nat
|
||||
index a76d9c784b..26144350b3 100644
|
||||
--- a/tools/hotplug/Linux/vif-nat
|
||||
+++ b/tools/hotplug/Linux/vif-nat
|
||||
@@ -85,7 +85,7 @@ router_ip=$(routing_ip "$ip")
|
||||
# Split the given IP/bits pair.
|
||||
vif_ip=`echo ${ip} | awk -F/ '{print $1}'`
|
||||
|
||||
-hostname=$(xenstore_read "$XENBUS_PATH/domain" | tr -- '_.:/+' '-----')
|
||||
+hostname=dom$domid
|
||||
if [ "$vifid" != "1" ]
|
||||
then
|
||||
hostname="$hostname-$vifid"
|
||||
--
|
||||
2.17.1
|
||||
@@ -1,9 +0,0 @@
|
||||
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
||||
|
||||
SRC_URI += "file://0001-vif-nat-fix-hostname.patch \
|
||||
"
|
||||
|
||||
PACKAGECONFIG_remove = "\
|
||||
${@bb.utils.contains('DISTRO_FEATURES', \
|
||||
'arm-autonomy-host', \
|
||||
'sdl', '', d)}"
|
||||
@@ -1,9 +0,0 @@
|
||||
# Make Xen machine specific
|
||||
# This ensures that sstate is properly handled and that each machine can have
|
||||
# its own configuration
|
||||
PACKAGE_ARCH = "${MACHINE_ARCH}"
|
||||
|
||||
PACKAGECONFIG_remove = "\
|
||||
${@bb.utils.contains('DISTRO_FEATURES', \
|
||||
'arm-autonomy-host', \
|
||||
'sdl', '', d)}"
|
||||
@@ -1,5 +0,0 @@
|
||||
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-4.14:"
|
||||
|
||||
SRC_URI += " \
|
||||
file://0001-xen-arm-Throw-messages-for-unknown-FP-SIMD-implement.patch \
|
||||
"
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -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 $?
|
||||
@@ -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}\"
|
||||
}
|
||||
]
|
||||
},
|
||||
@@ -1,21 +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}
|
||||
;;
|
||||
bridge)
|
||||
echo "vif = ['script=vif-bridge,bridge=${BRIDGE_NAME}']" >> ${guestcfgfile}
|
||||
;;
|
||||
*)
|
||||
echo "${@}: XENGUEST_NETWORK_TYPE=$XENGUEST_NETWORK_TYPE invalid"
|
||||
;;
|
||||
esac
|
||||
@@ -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
|
||||
for f in $(find ${XENGUEST_GUEST_DIR} -name "*.xenguest" \
|
||||
-exec basename {} .xenguest \;); do
|
||||
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 \
|
||||
${XENGUEST_GUEST_DIR}/${f}.xenguest | \
|
||||
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 \
|
||||
${XENGUEST_GUEST_DIR}/${f}.xenguest
|
||||
# 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
|
||||
xl shutdown -w ${f} || xl destroy ${f}
|
||||
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 $?
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user