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

Compare commits

..

5 Commits

Author SHA1 Message Date
Tushar Khandelwal 43b6449601 add test app support recipe
Change-Id: I7536c80ba6c5c0ad5827a187dd5b5db51d24bc6e
Signed-off-by: Tushar Khandelwal <tushar.khandelwal@arm.com>
2019-05-28 23:25:40 +01:00
Tushar Khandelwal 95cfe5ad83 add flash wic image for corstone700
Change-Id: Ieff6811292cdbcb61178fa933ab3d0a41bb200b6
Signed-off-by: Tushar Khandelwal <tushar.khandelwal@arm.com>
2019-05-28 23:25:34 +01:00
Tushar Khandelwal c1a92ede20 add corstone 700 bsp support
Change-Id: Ib5568e274f14efdaad18d9fb4add461578f51270
Signed-off-by: Tushar Khandelwal <tushar.khandelwal@arm.com>
2019-05-28 23:25:29 +01:00
Rui Silva c4057679c8 add base recipes for tiny distro
Change-Id: Ibcab926c91ab472e05a9a9077ad06ea8372117b7
Signed-off-by: Rui Silva <rui.silva@arm.com>
2019-05-28 23:25:20 +01:00
Tushar Khandelwal 3d59929e06 Initial Commit 2019-05-28 22:27:15 +01:00
609 changed files with 711 additions and 35073 deletions
-2
View File
@@ -1,2 +0,0 @@
[b4]
send-series-to = meta-arm@lists.yoctoproject.org
-2
View File
@@ -1,2 +0,0 @@
__pycache__
build
-350
View File
@@ -1,350 +0,0 @@
image: ${MIRROR_GHCR}/siemens/kas/kas:4.4
variables:
# These are needed as the k8s executor doesn't respect the container
# entrypoint by default
FF_KUBERNETES_HONOR_ENTRYPOINT: 1
FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY: 0
# The default value for KUBERNETES_CPU_REQUEST
CPU_REQUEST: ""
# The default machine tag for the build jobs
DEFAULT_TAG: ""
# The machine tag for the ACS test jobs
ACS_TAG: ""
# The directory to use as the persistent cache (the root for DL_DIR, SSTATE_DIR, etc)
CACHE_DIR: $CI_BUILDS_DIR/persist
# The container mirror to use
MIRROR_GHCR: ghcr.io
# Whether to run the SystemReady ACS tests
ACS_TEST: 0
# The list of extra Kas fragments to be used when building
EXTRA_KAS_FILES: ""
# The NVD API key to use when fetching CVEs
NVDCVE_API_KEY: ""
stages:
- prep
- build
# Common job fragment to get a worker ready
.setup:
tags:
- $DEFAULT_TAG
stage: build
interruptible: true
variables:
KAS_WORK_DIR: $CI_PROJECT_DIR/work
KAS_BUILD_DIR: $KAS_WORK_DIR/build
KAS_REPO_REF_DIR: $CACHE_DIR/repos
SSTATE_DIR: $CACHE_DIR/sstate
DL_DIR: $CACHE_DIR/downloads
BB_LOGCONFIG: $CI_PROJECT_DIR/ci/logging.yml
TOOLCHAIN_DIR: $CACHE_DIR/toolchains
IMAGE_DIR: $KAS_BUILD_DIR/tmp/deploy/images
TOOLCHAIN_LINK_DIR: $KAS_BUILD_DIR/toolchains
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 $TOOLCHAIN_LINK_DIR
# Must do this here, as it's the only way to make sure the toolchain is installed on the same builder
- ./ci/get-binary-toolchains $DL_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
# Generalised fragment to do a Kas build
.build:
extends: .setup
variables:
KUBERNETES_CPU_REQUEST: $CPU_REQUEST
rules:
# Don't run MR pipelines
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: never
# Don't run pipelines for tags
- if: $CI_COMMIT_TAG
when: never
# Don't run if BUILD_ENABLE_REGEX is set, but the job doesn't match the regex
- if: '$BUILD_ENABLE_REGEX != null && $CI_JOB_NAME !~ $BUILD_ENABLE_REGEX'
when: never
# Allow the dev kernels to fail and not fail the overall build
- if: '$KERNEL == "linux-yocto-dev"'
allow_failure: true
# Catch all for everything else
- if: '$KERNEL != "linux-yocto-dev"'
script:
- KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME" $EXTRA_KAS_FILES):lockfile.yml
- echo KASFILES=$KASFILES
- kas dump --update --force-checkout --resolve-refs --resolve-env $KASFILES
- kas build $KASFILES
- ./ci/check-warnings $KAS_BUILD_DIR/warnings.log
- kas shell ci/base.yml:lockfile.yml --command "$CI_PROJECT_DIR/ci/junit.sh $KAS_WORK_DIR/build"
artifacts:
name: "logs"
when: always
paths:
- $KAS_BUILD_DIR/tmp*/work*/**/temp/log.do_*.*
- $KAS_BUILD_DIR/tmp*/work*/**/testimage/*
reports:
junit: $KAS_BUILD_DIR/tmp/log/oeqa/junit.xml
#
# Prep stage, update repositories once.
# Set the CI variable CI_CLEAN_REPOS=1 to refetch the respositories from scratch
#
update-repos:
extends: .setup
stage: prep
allow_failure:
exit_codes: 128
script:
- |
flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos
# Only generate if doesn't already exist, to allow feature branches to drop one in.
if test -f lockfile.yml; then
echo Using existing lockfile.yml
else
# Be sure that this is the complete list of layers being fetched
kas dump --lock --update ci/qemuarm64.yml:ci/meta-openembedded.yml:ci/clang.yml:ci/meta-virtualization.yml | tee lockfile.yml
fi
artifacts:
name: "lockfile"
paths:
- lockfile.yml
#
# Build stage, the actual build jobs
#
# Available options for building are
# DISTRO: [poky, poky-altcfg, poky-tiny]
# KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
# TOOLCHAINS: [gcc, clang, external-gccarm]
# TCLIBC: [glibc, musl]
# FIRMWARE: [u-boot, edk2]
# TS: [none, trusted-services]
# VIRT: [none, xen]
# TESTING: testimage
# SECUREDEBUG: [none, secure-debug]
arm-systemready-ir-acs:
extends: .build
timeout: 12h
parallel:
matrix:
# arm-systemready-ir-acs must be specified after fvp-base for ordering
# purposes for the jobs-to-kas output. It is not enough to just have it
# in the job name because fvp-base.yml overwrites the target.
- PLATFORM: [fvp-base, corstone1000-fvp]
ARM_SYSTEMREADY_IR_ACS: arm-systemready-ir-acs
tags:
- ${ACS_TAG}
# Validate layers are Yocto Project Compatible
check-layers:
extends: .setup
script:
- kas shell --update --force-checkout ci/base.yml:ci/meta-openembedded.yml:lockfile.yml --command \
"yocto-check-layer-wrapper $CI_PROJECT_DIR/$LAYER --dependency $CI_PROJECT_DIR/meta-* $KAS_WORK_DIR/meta-openembedded/meta-oe --no-auto-dependency"
parallel:
matrix:
- LAYER: [meta-arm, meta-arm-bsp, meta-arm-toolchain]
corstone1000-fvp:
extends: .build
parallel:
matrix:
- FIRMWARE: corstone1000-firmware-only
TESTING: [testimage, tftf]
- FIRMWARE: none
TESTING: testimage
- SYSTEMREADY_FIRMWARE: arm-systemready-firmware
corstone1000-mps3:
extends: .build
parallel:
matrix:
- FIRMWARE: corstone1000-firmware-only
TESTING: [none, tftf]
- FIRMWARE: none
SECUREDEBUG: [none, secure-debug]
documentation:
extends: .setup
script:
- |
# This can be removed when the kas container has python3-venv installed
sudo apt-get update && sudo apt-get install --yes python3-venv
python3 -m venv venv
. ./venv/bin/activate
pip3 install -r meta-arm-bsp/documentation/requirements.txt
for CONF in meta-*/documentation/*/conf.py ; do
echo Building $CONF...
SOURCE_DIR=$(dirname $CONF)
MACHINE=$(basename $SOURCE_DIR)
sphinx-build -vW $SOURCE_DIR build-docs/$MACHINE
done
test -d build-docs/
artifacts:
paths:
- build-docs/
fvp-base:
extends: .build
parallel:
matrix:
- TS: [none, fvp-base-ts]
TESTING: testimage
- FIRMWARE: [u-boot, edk2]
TESTING: testimage
- SYSTEMREADY_FIRMWARE: arm-systemready-firmware
fvps:
extends: .build
genericarm64:
extends: .build
parallel:
matrix:
- TOOLCHAINS: [gcc, clang]
TESTING: testimage
- KERNEL: linux-yocto-dev
TESTING: testimage
juno:
extends: .build
parallel:
matrix:
- TOOLCHAINS: [gcc, clang]
FIRMWARE: [u-boot, edk2]
# What percentage of machines in the layer do we build
machine-coverage:
extends: .setup
script:
- ./ci/check-machine-coverage
coverage: '/Coverage: \d+/'
metrics:
extends: .setup
artifacts:
reports:
metrics: metrics.txt
script:
- kas shell --update --force-checkout ci/base.yml --command \
"$CI_PROJECT_DIR/ci/patchreview $CI_PROJECT_DIR/meta-* --verbose --metrics $CI_PROJECT_DIR/metrics.txt"
musca-b1:
extends: .build
musca-s1:
extends: .build
pending-updates:
extends: .setup
artifacts:
paths:
- update-report
script:
- rm -fr update-report
# This configuration has all of the layers we need enabled
- kas shell --update --force-checkout ci/qemuarm64.yml:ci/meta-openembedded.yml:ci/meta-secure-core.yml:lockfile.yml --command \
"$CI_PROJECT_DIR/scripts/machine-summary.py -t report -o $CI_PROJECT_DIR/update-report $($CI_PROJECT_DIR/ci/listmachines.py meta-arm meta-arm-bsp)"
# Do this on x86 whilst the compilers are x86-only
tags:
- x86_64
qemuarm64-secureboot:
extends: .build
parallel:
matrix:
- KERNEL: [linux-yocto, linux-yocto-rt]
TOOLCHAINS: [gcc, clang]
TCLIBC: [glibc, musl]
TS: [none, qemuarm64-secureboot-ts]
TESTING: testimage
- TOOLCHAINS: [gcc, clang]
TS: [none, qemuarm64-secureboot-ts]
UEFISB: [none, uefi-secureboot]
TESTING: testimage
- KERNEL: linux-yocto-dev
TESTING: testimage
qemuarm64:
extends: .build
parallel:
matrix:
- DISTRO: poky
KERNEL: [linux-yocto, linux-yocto-rt]
TOOLCHAINS: [gcc, clang]
FIRMWARE: [u-boot, edk2]
TESTING: testimage
- DISTRO: poky-tiny
TESTING: testimage
- VIRT: xen
- KERNEL: linux-yocto-dev
TESTING: testimage
qemuarm-secureboot:
extends: .build
parallel:
matrix:
- KERNEL: [linux-yocto, linux-yocto-rt]
TOOLCHAINS: [gcc, clang]
TCLIBC: [glibc, musl]
TESTING: testimage
- TOOLCHAINS: external-gccarm
TESTING: testimage
- KERNEL: linux-yocto-dev
TESTING: testimage
qemuarm:
extends: .build
parallel:
matrix:
- DISTRO: poky
KERNEL: [linux-yocto, linux-yocto-rt]
TOOLCHAINS: [gcc, clang]
FIRMWARE: [u-boot, edk2]
TESTING: testimage
- DISTRO: poky-tiny
TESTING: testimage
- VIRT: xen
- KERNEL: linux-yocto-dev
TESTING: testimage
qemuarmv5:
extends: .build
parallel:
matrix:
- DISTRO: poky
KERNEL: [linux-yocto, linux-yocto-dev, linux-yocto-rt]
TESTING: testimage
- DISTRO: poky-tiny
TESTING: testimage
sbsa-ref:
extends: .build
parallel:
matrix:
- KERNEL: [linux-yocto, linux-yocto-rt]
TOOLCHAINS: [gcc, clang]
TESTING: testimage
- DISTRO: poky-altcfg
TESTING: testimage
- KERNEL: linux-yocto-dev
TESTING: testimage
selftest:
extends: .setup
script:
- KASFILES=./ci/qemuarm64.yml:./ci/selftest.yml:lockfile.yml
- kas shell --update --force-checkout $KASFILES -c 'oe-selftest --num-processes 2 --select-tag meta-arm --run-all-tests'
sgi575:
extends: .build
toolchains:
extends: .build
-97
View File
@@ -1,97 +0,0 @@
Introduction
------------
This repository contains the Arm layers for OpenEmbedded.
* meta-arm
This layer contains general recipes for the Arm architecture, such as firmware, FVPs, and Arm-specific integration.
* meta-arm-bsp
This layer contains machines for Arm reference platforms, for example FVP Base, Corstone1000, and Juno.
* meta-arm-toolchain
This layer contains recipes for Arm's binary toolchains (GCC and Clang for -A and -M), and a recipe to build Arm's GCC.
Other Directories
-----------------
* ci
This directory contains gitlab continuous integration configuration files (KAS yaml files) as well as scripts needed for this.
* documentation
This directory contains information on the files in this repository, building, and other relevant documents.
* kas
This directory contains KAS yaml files to describe builds for systems not used in CI.
* scripts
This directory contains scripts used in running the CI tests.
Mailing List
------------
To interact with the meta-arm developer community, please email the meta-arm mailing list at <meta-arm@lists.yoctoproject.org>.
Currently, it is configured to only allow emails to members from those subscribed.
To subscribe to the meta-arm mailing list, please go to
https://lists.yoctoproject.org/g/meta-arm
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
All contributions are under the [MIT License](/COPYING.MIT).
For a quick start guide on how to build and use meta-arm, go to [quick-start.md](/documentation/quick-start.md).
For information on the continuous integration done on meta-arm and how to use it, go to [continuous-integration-and-kas.md](/documentation/continuous-integration-and-kas.md).
Backporting
--------------
Backporting patches to older releases may be done upon request, but only after a version of the patch has been accepted into the master branch. This is done by adding the branch name to email subject line. This should be between the square brackets (e.g., "[" and "]"), and before or after the "PATCH". For example,
> [nanbield PATCH] arm/linux-yocto: backport patch to fix 6.5.13 networking issues
Automatic backporting will be done to all branches if the "Fixes: <SHA>" wording is added to the patch commit message. This is similar to how the Linux kernel community does their LTS kernel backporting. For more information see the "Fixes" portion of
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#submittingpatches
Releases and Release Schedule
--------------
We follow the Yocto Project release methodology, schedule, and stable/LTS support timelines. For more information on these, please reference:
* https://docs.yoctoproject.org/ref-manual/release-process.html
* https://wiki.yoctoproject.org/wiki/Releases
* https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS
For more in-depth information on the meta-arm release and branch methodology, go to </documentation/releases.md>.
Reporting bugs
--------------
E-mail <meta-arm@lists.yoctoproject.org> with the error encountered and the steps
to reproduce the issue.
Security and Reporting Security Issues
--------------
For information on the security of meta-arm and how to report issues, please consult [SECURITY.md](/SECURITY.md).
Maintainer(s)
-------------
* Jon Mason <jon.mason@arm.com>
* Ross Burton <ross.burton@arm.com>
-46
View File
@@ -1,46 +0,0 @@
# Reporting vulnerabilities
Arm takes security issues seriously and welcomes feedback from researchers and
the security community in order to improve the security of its products and
services. We operate a coordinated disclosure policy for disclosing
vulnerabilities and other security issues.
Security issues can be complex and one single timescale doesn't fit all
circumstances. We will make best endeavours to inform you when we expect
security notifications and fixes to be available and facilitate coordinated
disclosure when notifications and patches/mitigations are available.
## How to Report a Potential Vulnerability?
If you would like to report a public issue (for example, one with a released CVE
number), please contact the meta-arm mailing list at
meta-arm@lists.yoctoproject.org and arm-security@arm.com.
If you are dealing with a not-yet released or urgent issue, please send a mail
to the maintainers \(see [README.md](/README.md)\) and arm-security@arm.com, including as much
detail as possible. Encrypted emails using PGP are welcome.
For more information, please visit https://developer.arm.com/support/arm-security-updates/report-security-vulnerabilities.
## Branches maintained with security fixes
meta-arm follows the Yocto release model, so see
[Stable release and LTS](https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS)
for detailed info regarding the policies and maintenance of stable
branches.
The [Release page](https://wiki.yoctoproject.org/wiki/Releases) contains a list of all
releases of the Yocto Project. Versions in grey are no longer actively maintained with
security patches, but well-tested patches may still be accepted for them for
significant issues.
# Disclaimer
Arm reference solutions are Arm public example software projects that track and
pull upstream components, incorporating their respective security fixes
published over time. Arm partners are responsible for ensuring that the
components they use contain all the required security fixes, if and when they
deploy a product derived from Arm reference solutions.
-6
View File
@@ -1,6 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 11
includes:
- kas/arm-systemready-firmware.yml
-19
View File
@@ -1,19 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 11
includes:
- kas/arm-systemready-ir-acs.yml
env:
ACS_TEST: "0"
local_conf_header:
testimage: |
TESTIMAGE_AUTO = "${ACS_TEST}"
target:
- arm-systemready-ir-acs
- arm-systemready-linux-distros-debian
- arm-systemready-linux-distros-opensuse
- arm-systemready-linux-distros-fedora
-45
View File
@@ -1,45 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
distro: poky
defaults:
repos:
branch: styhead
repos:
meta-arm:
layers:
meta-arm:
meta-arm-bsp:
meta-arm-toolchain:
poky:
url: https://git.yoctoproject.org/poky
layers:
meta:
meta-poky:
env:
BB_LOGCONFIG: ""
TOOLCHAIN_DIR: ""
local_conf_header:
base: |
CONF_VERSION = "2"
BB_SERVER_TIMEOUT = "300"
setup: |
PACKAGE_CLASSES = "package_ipk"
PACKAGECONFIG:remove:pn-qemu-system-native = "gtk+ sdl"
PACKAGECONFIG:append:pn-perf = " coresight"
INHERIT += "rm_work"
extrapackages: |
CORE_IMAGE_EXTRA_INSTALL += "perf opencsd"
CORE_IMAGE_EXTRA_INSTALL:append:aarch64 = " gator-daemon"
machine: unset
target:
- core-image-sato
-28
View File
@@ -1,28 +0,0 @@
#! /usr/bin/env python3
from pathlib import Path
import sys
from listmachines import list_machines
metaarm = Path.cwd()
if metaarm.name != "meta-arm":
print("Not running inside meta-arm")
sys.exit(1)
# Find all layers
layers = (p.name for p in metaarm.glob("meta-*") if p.is_dir())
# All machine configurations
machines = list_machines(layers)
# All kas files
kas = metaarm.glob("ci/*.yml")
kas = set(p.stem for p in kas)
missing = machines - kas
print(f"The following machines are missing: {', '.join(sorted(missing))}.")
covered = len(machines) - len(missing)
total = len(machines)
percent = int(covered / total * 100)
print(f"Coverage: {percent}%")
-19
View File
@@ -1,19 +0,0 @@
#! /bin/bash
# Expects the path to a log file as $1, and if this file has any content
# then display the contents and exit with an error code.
set -e -u
LOGFILE=$1
LINES=$(grep --invert-match "attempting MIRRORS if available" $LOGFILE | wc -l)
if test "$LINES" -ne 0; then
echo ==============================
echo The build had warnings/errors:
echo ==============================
cat $LOGFILE
exit 1
fi
exit 0
-12
View File
@@ -1,12 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
repos:
meta-clang:
url: https://github.com/kraj/meta-clang
local_conf_header:
toolchain: |
TOOLCHAIN = "clang"
-13
View File
@@ -1,13 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
- ci/meta-openembedded.yml
- ci/meta-secure-core.yml
- kas/corstone1000-image-configuration.yml
target:
- core-image-minimal
- perf
-10
View File
@@ -1,10 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- kas/corstone1000-firmware-only.yml
target:
- corstone1000-flash-firmware-image
- perf
-9
View File
@@ -1,9 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/corstone1000-common.yml
- ci/fvp.yml
machine: corstone1000-fvp
-8
View File
@@ -1,8 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/corstone1000-common.yml
machine: corstone1000-mps3
-21
View File
@@ -1,21 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
cve: |
INHERIT += "cve-check"
# Allow the runner environment to provide an API key
NVDCVE_API_KEY = "${@d.getVar('BB_ORIGENV').getVar('NVDCVE_API_KEY') or ''}"
# Just show the warnings for our layers
CVE_CHECK_SHOW_WARNINGS = "0"
CVE_CHECK_SHOW_WARNINGS:layer-arm-toolchain = "1"
CVE_CHECK_SHOW_WARNINGS:layer-meta-arm = "1"
CVE_CHECK_SHOW_WARNINGS:layer-meta-arm-bsp = "1"
CVE_CHECK_SHOW_WARNINGS:layer-meta-arm-systemready = "1"
# Ignore the kernel, we sometime carry kernels in meta-arm
CVE_CHECK_SHOW_WARNINGS:pn-linux-yocto = "0"
-9
View File
@@ -1,9 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
# Add universally helpful features when testing boards
local_conf_header:
debug: |
EXTRA_IMAGE_FEATURES:append = " debug-tweaks"
-31
View File
@@ -1,31 +0,0 @@
#! /usr/bin/env python3
"""
Download the lockfile.yml produced by a CI pipeline, specified by the GitLab
server, full name of the meta-arm project, and the refspec that was executed.
For example,
$ ./download-lockfile.py https://gitlab.com/ rossburton/meta-arm master
SPDX-FileCopyrightText: Copyright 2023 Arm Limited and Contributors
SPDX-License-Identifier: GPL-2.0-only
"""
import argparse
import gitlab
import io
import zipfile
parser = argparse.ArgumentParser()
parser.add_argument("server", help="GitLab server name")
parser.add_argument("project", help="meta-arm project name")
parser.add_argument("refspec", help="Branch/commit")
args = parser.parse_args()
gl = gitlab.Gitlab(args.server)
project = gl.projects.get(args.project)
artefact = project.artifacts.download(ref_name=args.refspec, job="update-repos")
z = zipfile.ZipFile(io.BytesIO(artefact))
z.extract("lockfile.yml")
print("Fetched lockfile.yml")
-17
View File
@@ -1,17 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
bootfirmware: |
PREFERRED_PROVIDER_virtual/bootloader = "edk2-firmware"
MACHINE_FEATURES += "efi"
TFA_UBOOT = "0"
TFA_UEFI = "1"
EXTRA_IMAGEDEPENDS += "edk2-firmware"
EFI_PROVIDER ?= "grub-efi"
QB_DEFAULT_BIOS = "QEMU_EFI.fd"
WKS_FILE ?= "efi-disk.wks.in"
-13
View File
@@ -1,13 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
cc: |
SKIP_RECIPE[gcc-cross-arm] = "Using external toolchain"
TCMODE = "external-arm"
EXTERNAL_TOOLCHAIN = "${TOPDIR}/toolchains/${TARGET_ARCH}"
# Disable ptest as this pulls target compilers, which don't
# work with external toolchain currently
DISTRO_FEATURES:remove = "ptest"
-34
View File
@@ -1,34 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/fvp-base.yml
- ci/meta-openembedded.yml
- ci/testimage.yml
local_conf_header:
trusted_services: |
# Enable the needed test suites
TEST_SUITES = " ping ssh trusted_services"
# Include all Secure Partitions into the image
MACHINE_FEATURES:append = " arm-ffa ts-crypto ts-storage ts-its"
MACHINE_FEATURES:append = " ts-attestation ts-smm-gateway optee-spmc-test"
MACHINE_FEATURES:append = " ts-block-storage ts-fwu"
# Include TS demo/test tools into image
IMAGE_INSTALL:append = " packagegroup-ts-tests"
# Include TS PSA Arch tests into image
IMAGE_INSTALL:append = " packagegroup-ts-tests-psa"
CORE_IMAGE_EXTRA_INSTALL += "optee-test"
# Set the TS environment
TS_ENV="sp"
# Enable and configure semihosting
FVP_CONFIG[cluster0.cpu0.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
FVP_CONFIG[cluster0.cpu1.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
FVP_CONFIG[cluster0.cpu2.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
FVP_CONFIG[cluster0.cpu3.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
FVP_CONFIG[cluster1.cpu0.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
FVP_CONFIG[cluster1.cpu1.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
FVP_CONFIG[cluster1.cpu2.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
FVP_CONFIG[cluster1.cpu3.semihosting-cwd] = "${DEPLOY_DIR_IMAGE}"
FVP_CONFIG[semihosting-enable] = "True"
-13
View File
@@ -1,13 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
- ci/fvp.yml
machine: fvp-base
target:
- core-image-full-cmdline
- boot-wrapper-aarch64
-9
View File
@@ -1,9 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
testimagefvp: |
LICENSE_FLAGS_ACCEPTED += "Arm-FVP-EULA"
IMAGE_CLASSES += "fvpboot"
-26
View File
@@ -1,26 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
# Simple target to build the FVPs that are publically available
header:
version: 14
includes:
- ci/base.yml
machine: qemuarm64
local_conf_header:
license: |
LICENSE_FLAGS_ACCEPTED += "Arm-FVP-EULA"
sdk: |
SDKMACHINE = "x86_64"
target:
# Target packages to test aarch64
- fvp-base-a-aem
- fvp-corstone1000
# Nativesdk to test x86-64
- nativesdk-fvp-base-a-aem
- nativesdk-fvp-corstone1000
- nativesdk-fvp-n1-edge
- nativesdk-fvp-sgi575
-9
View File
@@ -1,9 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
#NOTE: This is the default for poky. This is only being added for completeness/clarity
local_conf_header:
toolchain: |
TOOLCHAIN = "gcc"
-21
View File
@@ -1,21 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
repos:
poky:
layers:
meta-yocto-bsp:
local_conf_header:
bootloader: |
# If running genericarm64 in a qemu we need to manually build the bootloader
EXTRA_IMAGEDEPENDS += "virtual/bootloader"
sshpregen: |
# Allow the use of the pregen keys as this is CI so safe
COMPATIBLE_MACHINE:pn-ssh-pregen-hostkeys:genericarm64 = "genericarm64"
machine: genericarm64
-51
View File
@@ -1,51 +0,0 @@
#!/bin/bash
set -u -e
BASENAME=arm-gnu-toolchain
VER=${VER:-13.3.rel1}
HOST_ARCH=${HOST_ARCH:-$(uname -m)}
# Use the standard kas container locations if nothing is passed into the script
DOWNLOAD_DIR="${1:-/builds/persist/downloads/}"
TOOLCHAIN_DIR="${2:-/builds/persist//toolchains/}"
TOOLCHAIN_LINK_DIR="${3:-build/toolchains/}"
# These should be already created by .gitlab-ci.yml, but do here if run outside of that env
mkdir -p $DOWNLOAD_DIR $TOOLCHAIN_DIR $TOOLCHAIN_LINK_DIR
download() {
TRIPLE=$1
URL=https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/$BASENAME-$VER-$HOST_ARCH-$TRIPLE.tar.xz
wget -P $DOWNLOAD_DIR -nc $URL
}
if [ $HOST_ARCH = "aarch64" ]; then
# AArch64 Linux hosted cross compilers
# AArch32 target with hard float
download arm-none-linux-gnueabihf
elif [ $HOST_ARCH = "x86_64" ]; then
# x86_64 Linux hosted cross compilers
# AArch32 target with hard float
download arm-none-linux-gnueabihf
# AArch64 GNU/Linux target
download aarch64-none-linux-gnu
else
echo "ERROR - Unknown build arch of $HOST_ARCH"
exit 1
fi
for i in arm aarch64; do
if [ ! -d $TOOLCHAIN_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*/ ]; then
if [ ! -f $DOWNLOAD_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz ]; then
continue
fi
tar -C $TOOLCHAIN_DIR -axvf $DOWNLOAD_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz
fi
# Setup a link for the toolchain to use local to the building machine (e.g., not in a shared location)
ln -s $TOOLCHAIN_DIR/$BASENAME-$VER-$HOST_ARCH-$i-none-linux-gnu* $TOOLCHAIN_LINK_DIR/$i
done
-9
View File
@@ -1,9 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
#NOTE: This is the default for poky. This is only being added for completeness/clarity
local_conf_header:
libc: |
TCLIBC = "glibc"
-43
View File
@@ -1,43 +0,0 @@
#! /bin/bash
# This script is expecting an input of machine name, optionally followed by a
# colon and a list of one or more parameters separated by commas between
# brackets. For example, the following are acceptable:
# corstone1000-mps3
# fvp-base: [testimage]
# qemuarm64-secureboot: [clang, glibc, testimage]
# This argument should be quoted to avoid expansion and to be handled
# as a single value.
#
# Any further arguments will be handled as further yml file basenames.
#
# Turn this list into a series of yml files separated by colons to pass to kas
set -e -u
# First, parse the GitLab CI job name (CI_JOB_NAME via $1) and accumulate a list
# of Kas files.
JOBNAME="$1"
shift
# The base name of the job
FILES="ci/$(echo $JOBNAME | cut -d ':' -f 1).yml"
# The list of matrix variations
for i in $(echo $JOBNAME | cut -s -d ':' -f 2 | sed 's/[][,]//g'); do
# Given that there are no yml files for gcc or glibc, as those are the
# defaults, we can simply ignore those parameters. They are necessary
# to pass in so that matrix can correctly setup all of the permutations
# of each individual run.
if [[ $i == 'none' ]]; then
continue
fi
FILES+=":ci/$i.yml"
done
# Now pick up any further names
for i in $*; do
FILES+=":ci/$i.yml"
done
echo $FILES
-15
View File
@@ -1,15 +0,0 @@
#! /bin/bash
# $ ci/junit.sh <build directory>
#
# If there is a OEQA test report in JSON format present in the build directory,
# transform it to JUnit XML using resulttool.
set -e -u
BUILDDIR=$1
JSON=$BUILDDIR/tmp/log/oeqa/testresults.json
if test -f $JSON; then
resulttool junit $JSON
fi
-8
View File
@@ -1,8 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
machine: juno
-8
View File
@@ -1,8 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
kernel: |
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
-8
View File
@@ -1,8 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
kernel: |
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
-9
View File
@@ -1,9 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
#NOTE: This is the default for poky. This is only being added for completeness/clarity
local_conf_header:
kernel: |
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
-29
View File
@@ -1,29 +0,0 @@
#! /usr/bin/env python3
import pathlib
import typing
import sys
"""
List all of the machines available under the listed sub-layers of meta-arm.
"""
def list_machines(layers: typing.Sequence[str]) -> typing.Set[str]:
machines = set()
# We know we're in meta-arm/scripts, so find the top-level directory
metaarm = pathlib.Path(__file__).resolve().parent.parent
if metaarm.name != "meta-arm":
raise Exception("Not running inside meta-arm")
for layer in layers:
machines |= set(p.stem for p in (metaarm / layer / "conf" / "machine").glob("*.conf"))
return machines
if __name__ == "__main__":
if len(sys.argv) > 1:
machines = list_machines(sys.argv[1:])
print(" ".join(sorted(machines)))
sys.exit(0)
else:
print("Usage:\n$ %s [layer name ...] " % sys.argv[0])
sys.exit(1)
-13
View File
@@ -1,13 +0,0 @@
# Python logging configuration to write all warnings to a separate file
version: 1
handlers:
warnings:
class: logging.FileHandler
level: WARNING
filename: warnings.log
formatter: BitBake.logfileFormatter
loggers:
BitBake:
handlers: [warnings]
-14
View File
@@ -1,14 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
repos:
meta-openembedded:
url: https://git.openembedded.org/meta-openembedded
layers:
meta-filesystems:
meta-networking:
meta-oe:
meta-python:
meta-perl:
-13
View File
@@ -1,13 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
repos:
meta-secure-core:
url: https://github.com/Wind-River/meta-secure-core.git
layers:
meta-secure-core-common:
meta-signing-key:
meta-efi-secure-boot:
-10
View File
@@ -1,10 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/meta-openembedded.yml
repos:
meta-virtualization:
url: https://git.yoctoproject.org/meta-virtualization
-12
View File
@@ -1,12 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
- ci/meta-openembedded.yml
machine: musca-b1
target:
- trusted-firmware-m
-12
View File
@@ -1,12 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
- ci/meta-openembedded.yml
machine: musca-s1
target:
- trusted-firmware-m
-8
View File
@@ -1,8 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
libc: |
TCLIBC = "musl"
-286
View File
@@ -1,286 +0,0 @@
#! /usr/bin/env python3
#
# SPDX-License-Identifier: GPL-2.0-only
#
# TODO
# - option to just list all broken files
# - test suite
# - validate signed-off-by
import argparse
import collections
import json
import os
import re
import subprocess
status_values = (
"accepted",
"pending",
"inappropriate",
"backport",
"submitted",
"denied",
)
class PatchResult:
# Whether the patch has an Upstream-Status or not
missing_upstream_status = False
# If the Upstream-Status tag is malformed in some way (string for bad bit)
malformed_upstream_status = None
# If the Upstream-Status value is unknown (boolean)
unknown_upstream_status = False
# The upstream status value (Pending, etc)
upstream_status = None
# Whether the patch has a Signed-off-by or not
missing_sob = False
# Whether the Signed-off-by tag is malformed in some way
malformed_sob = False
# The Signed-off-by tag value
sob = None
# Whether a patch looks like a CVE but doesn't have a CVE tag
missing_cve = False
class Summary:
total = 0
cve_missing = 0
sob_missing = 0
sob_malformed = 0
status_missing = 0
status_malformed = 0
status_pending = 0
def blame_patch(patch):
"""
From a patch filename, return a list of "commit summary (author name <author
email>)" strings representing the history.
"""
return subprocess.check_output(("git", "log",
"--follow", "--find-renames", "--diff-filter=A",
"--format=%s (%aN <%aE>)",
"--", patch)).decode("utf-8").splitlines()
def patchreview(patches):
# General pattern: start of line, optional whitespace, tag with optional
# hyphen or spaces, maybe a colon, some whitespace, then the value, all case
# insensitive.
sob_re = re.compile(r"^[\t ]*(Signed[-_ ]off[-_ ]by:?)[\t ]*(.+)", re.IGNORECASE | re.MULTILINE)
status_re = re.compile(r"^[\t ]*(Upstream[-_ ]Status:?)[\t ]*(\w*)", re.IGNORECASE | re.MULTILINE)
cve_tag_re = re.compile(r"^[\t ]*(CVE:)[\t ]*(.*)", re.IGNORECASE | re.MULTILINE)
cve_re = re.compile(r"cve-[0-9]{4}-[0-9]{4,6}", re.IGNORECASE)
results = {}
for patch in patches:
result = PatchResult()
results[patch] = result
content = open(patch, encoding="ascii", errors="ignore").read()
# Find the Signed-off-by tag
match = sob_re.search(content)
if match:
value = match.group(1)
if value != "Signed-off-by:":
result.malformed_sob = value
result.sob = match.group(2)
else:
result.missing_sob = True
# Find the Upstream-Status tag
match = status_re.search(content)
if match:
value = match.group(1)
if value != "Upstream-Status:":
result.malformed_upstream_status = value
value = match.group(2).lower()
# TODO: check case
if value not in status_values:
result.unknown_upstream_status = True
result.upstream_status = value
else:
result.missing_upstream_status = True
# Check that patches which looks like CVEs have CVE tags
if cve_re.search(patch) or cve_re.search(content):
if not cve_tag_re.search(content):
result.missing_cve = True
# TODO: extract CVE list
return results
def analyse(results, want_blame=False, verbose=True):
"""
want_blame: display blame data for each malformed patch
verbose: display per-file results instead of just summary
"""
# want_blame requires verbose, so disable blame if we're not verbose
if want_blame and not verbose:
want_blame = False
summary = Summary()
for patch in sorted(results):
r = results[patch]
summary.total += 1
need_blame = False
# Build statistics
if r.missing_sob:
summary.sob_missing += 1
if r.malformed_sob:
summary.sob_malformed += 1
if r.missing_upstream_status:
summary.status_missing += 1
if r.malformed_upstream_status or r.unknown_upstream_status:
summary.status_malformed += 1
# Count patches with no status as pending
summary.status_pending += 1
if r.missing_cve:
summary.cve_missing += 1
if r.upstream_status == "pending":
summary.status_pending += 1
# Output warnings
if r.missing_sob:
need_blame = True
if verbose:
print("Missing Signed-off-by tag (%s)" % patch)
if r.malformed_sob:
need_blame = True
if verbose:
print("Malformed Signed-off-by '%s' (%s)" % (r.malformed_sob, patch))
if r.missing_cve:
need_blame = True
if verbose:
print("Missing CVE tag (%s)" % patch)
if r.missing_upstream_status:
need_blame = True
if verbose:
print("Missing Upstream-Status tag (%s)" % patch)
if r.malformed_upstream_status:
need_blame = True
if verbose:
print("Malformed Upstream-Status '%s' (%s)" % (r.malformed_upstream_status, patch))
if r.unknown_upstream_status:
need_blame = True
if verbose:
print("Unknown Upstream-Status value '%s' (%s)" % (r.upstream_status, patch))
if want_blame and need_blame:
print("\n".join(blame_patch(patch)) + "\n")
return summary
def display_summary(summary, verbose):
def percent(num):
try:
return "%d (%d%%)" % (num, round(num * 100.0 / summary.total))
except ZeroDivisionError:
return "N/A"
if verbose:
print()
print("""Total patches found: %d
Patches missing Signed-off-by: %s
Patches with malformed Signed-off-by: %s
Patches missing CVE: %s
Patches missing Upstream-Status: %s
Patches with malformed Upstream-Status: %s
Patches in Pending state: %s""" % (summary.total,
percent(summary.sob_missing),
percent(summary.sob_malformed),
percent(summary.cve_missing),
percent(summary.status_missing),
percent(summary.status_malformed),
percent(summary.status_pending)))
def generate_metrics(summary, output):
# https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md
# Summary attribute name, MetricPoint help
mapping = (
("total", "Total patches"),
("cve_missing", "Patches missing CVE tag"),
("sob_malformed", "Patches with malformed Signed-off-by"),
("sob_missing", "Patches with missing Signed-off-by"),
("status_malformed", "Patches with malformed Upstream-Status"),
("status_missing", "Patches with missing Upstream-Status"),
("status_pending", "Patches with Pending Upstream-Status")
)
for attr, help in mapping:
metric = f"patch_check_{attr}"
value = getattr(summary, attr)
output.write(f"""
# TYPE {metric} gauge
# HELP {help}
{metric} {value}
""")
output.write("\n# EOF\n")
def histogram(results):
import math
from toolz import dicttoolz, recipes
counts = recipes.countby(lambda r: r.upstream_status, results.values())
bars = dicttoolz.valmap(lambda v: "#" * int(math.ceil(float(v) / len(results) * 100)), counts)
for k in bars:
print("%-20s %s (%d)" % (k.capitalize() if k else "No status", bars[k], counts[k]))
def gather_patches(directories):
patches = []
for directory in directories:
filenames = subprocess.check_output(("git", "-C", directory, "ls-files", "recipes-*/**/*.patch", "recipes-*/**/*.diff")).decode("utf-8").split()
patches += [os.path.join(directory, f) for f in filenames]
return patches
if __name__ == "__main__":
args = argparse.ArgumentParser(description="Patch Review Tool")
args.add_argument("-b", "--blame", action="store_true", help="show blame for malformed patches")
args.add_argument("-v", "--verbose", action="store_true", help="show per-patch results")
args.add_argument("-g", "--histogram", action="store_true", help="show patch histogram")
args.add_argument("-j", "--json", help="update JSON")
args.add_argument("-m", "--metrics", type=argparse.FileType('w'), help="write OpenMetrics")
args.add_argument("dirs", metavar="DIRECTORY", nargs="+", help="directory to scan")
args = args.parse_args()
patches = gather_patches(args.dirs)
results = patchreview(patches)
summary = analyse(results, want_blame=args.blame, verbose=args.verbose)
display_summary(summary, verbose=args.verbose)
if args.json:
if os.path.isfile(args.json):
data = json.load(open(args.json))
else:
data = []
row = collections.Counter()
row["total"] = len(results)
row["date"] = subprocess.check_output(["git", "-C", args.dirs[0], "show", "-s", "--pretty=format:%cd", "--date=format:%s"]).decode("utf-8").strip()
for r in results.values():
if r.upstream_status in status_values:
row[r.upstream_status] += 1
if r.malformed_upstream_status or r.missing_upstream_status:
row["malformed-upstream-status"] += 1
if r.malformed_sob or r.missing_sob:
row["malformed-sob"] += 1
data.append(row)
json.dump(data, open(args.json, "w"))
if args.metrics:
generate_metrics(summary, args.metrics)
if args.histogram:
print()
histogram(results)
-4
View File
@@ -1,4 +0,0 @@
header:
version: 14
distro: poky-altcfg
-16
View File
@@ -1,16 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
distro: poky-tiny
local_conf_header:
hacking: |
TEST_SUITES = "_qemutiny ping"
extrapackages: |
# Intentionally blank to prevent perf from being added to the image in base.yml
target:
- core-image-minimal
- perf
-6
View File
@@ -1,6 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
distro: poky
-16
View File
@@ -1,16 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
machine: qemuarm-secureboot
target:
- core-image-base
local_conf_header:
optee: |
IMAGE_INSTALL:append = " optee-test optee-client optee-os-ta"
TEST_SUITES:append = " optee ftpm"
-8
View File
@@ -1,8 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
machine: qemuarm
-17
View File
@@ -1,17 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/meta-openembedded.yml
local_conf_header:
trusted_services: |
TEST_SUITES:append = " trusted_services"
# Include TS Crypto, TS Protected Storage, and TS Internal Trusted Storage and SPs into optee-os image
# FIXME - remove TS SMM Gateway due to QEMU v9.0.0 test failures
MACHINE_FEATURES:append = " arm-ffa ts-crypto ts-storage ts-its"
# Include TS demo/test tools into image
IMAGE_INSTALL:append = " packagegroup-ts-tests"
# Include TS PSA Arch tests into image
IMAGE_INSTALL:append = " packagegroup-ts-tests-psa"
-16
View File
@@ -1,16 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
machine: qemuarm64-secureboot
target:
- core-image-base
local_conf_header:
optee: |
IMAGE_INSTALL:append = " optee-test optee-client optee-os-ta"
TEST_SUITES:append = " optee ftpm"
-8
View File
@@ -1,8 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
machine: qemuarm64
-8
View File
@@ -1,8 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
machine: qemuarmv5
-12
View File
@@ -1,12 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
machine: sbsa-ref
target:
- core-image-sato
- sbsa-acs
-8
View File
@@ -1,8 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
secure-debug: |
MACHINE_FEATURES += "secure-debug"
-9
View File
@@ -1,9 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
setup: |
BB_LOGCONFIG = ""
SANITY_TESTED_DISTROS = ""
-8
View File
@@ -1,8 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
machine: sgi575
-11
View File
@@ -1,11 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
sstate_mirror: |
BB_HASHSERVE_UPSTREAM = "wss://hashserv.yoctoproject.org/ws"
SSTATE_MIRRORS = "file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH"
BB_HASHSERVE = "auto"
BB_SIGNATURE_HANDLER = "OEEquivHash"
-21
View File
@@ -1,21 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/debug.yml
local_conf_header:
testimage: |
IMAGE_CLASSES += "testimage"
TESTIMAGE_AUTO = "1"
kvm: |
QEMU_USE_KVM = ""
slirp: |
TEST_RUNQEMUPARAMS = "slirp"
sshd: |
IMAGE_FEATURES += "ssh-server-dropbear"
sshkeys: |
CORE_IMAGE_EXTRA_INSTALL += "ssh-pregen-hostkeys"
universally_failing_tests: |
TEST_SUITES:remove = "opkg"
-10
View File
@@ -1,10 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
tftf: |
TFA_UBOOT = "0"
TFA_UEFI = "0"
TFTF_TESTS = "1"
-20
View File
@@ -1,20 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/base.yml
# Target is arm64 and SDK is x86-64 to ensure that we exercise both
# architectures
machine: qemuarm64
local_conf_header:
toolchains: |
SDKMACHINE = "x86_64"
target:
- gcc-aarch64-none-elf
- nativesdk-gcc-aarch64-none-elf
- gcc-arm-none-eabi
- nativesdk-gcc-arm-none-eabi
-10
View File
@@ -1,10 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
bootfirmware: |
PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
TFA_UBOOT = "1"
TFA_UEFI = "0"
-37
View File
@@ -1,37 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
# UEFI Secure Boot: A mechanism to ensure that only trusted software is executed
# during the boot process.
header:
version: 14
includes:
- ci/meta-openembedded.yml
- ci/meta-secure-core.yml
local_conf_header:
uefi_secureboot: |
SBSIGN_KEYS_DIR = "${TOPDIR}/sbkeys"
BB_ENV_PASSTHROUGH_ADDITIONS = "SBSIGN_KEYS_DIR"
# Detected by passing kernel parameter
QB_KERNEL_ROOT = ""
# kernel is in the image, should not be loaded separately
QB_DEFAULT_KERNEL = "none"
WKS_FILE = "efi-disk.wks.in"
KERNEL_IMAGETYPE = "Image"
MACHINE_FEATURES:append = " efi uefi-secureboot"
EFI_PROVIDER = "systemd-boot"
# Use systemd as the init system
INIT_MANAGER = "systemd"
DISTRO_FEATURES:append = " systemd"
DISTRO_FEATURES_NATIVE:append = " systemd"
IMAGE_INSTALL:append = " systemd systemd-boot util-linux coreutils"
TEST_SUITES:append = " uefi_secureboot"
-56
View File
@@ -1,56 +0,0 @@
#! /usr/bin/env python3
# Update clones of the repositories we need in KAS_REPO_REF_DIR to speed up fetches
import sys
import os
import shutil
import subprocess
import pathlib
def repo_shortname(url):
# Taken from Kas (Repo.__getattr__) to ensure the logic is right
from urllib.parse import urlparse
url = urlparse(url)
return ('{url.netloc}{url.path}'
.format(url=url)
.replace('@', '.')
.replace(':', '.')
.replace('/', '.')
.replace('*', '.'))
repositories = (
"https://git.yoctoproject.org/poky",
"https://git.openembedded.org/meta-openembedded",
"https://git.yoctoproject.org/meta-virtualization",
"https://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"])
failed = False
for repo in repositories:
repodir = base_repodir / repo_shortname(repo)
if "CI_CLEAN_REPOS" in os.environ:
print("Cleaning %s..." % repo)
shutil.rmtree(repodir, ignore_errors=True)
if repodir.exists():
try:
print("Updating %s..." % repo)
subprocess.run(["git", "-C", repodir, "-c", "gc.autoDetach=false", "fetch"], check=True)
except subprocess.CalledProcessError as e:
print(e)
failed = True
else:
print("Cloning %s..." % repo)
subprocess.run(["git", "clone", "--bare", repo, repodir], check=True)
if failed:
sys.exit(128)
-13
View File
@@ -1,13 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
includes:
- ci/meta-virtualization.yml
local_conf_header:
meta-virt: |
DISTRO_FEATURES:append = " virtualization xen"
target:
- xen-image-minimal
@@ -1,67 +0,0 @@
# **CI for Yocto Project and meta-arm**
# **CI for Yocto Project**
The Yocto Project has an autobuilder that performs nightly builds and image tests on all of the defined QEMU machines, including qemuarm and qemuarm64 Also, it currently runs builds on the hardware reference platforms including genericarm64 and meta-arm mahines fvp-base and sbsa-ref. More information on the autobuilder can be found at <https://autobuilder.yoctoproject.org/>.
More information on the image tests can be found at <https://wiki.yoctoproject.org/wiki/Image_tests>.
The Yocto Project also has the ability to have individual package tests, ptests.  For more information on those, go to <https://wiki.yoctoproject.org/wiki/Ptest>.
# **CI for meta-arm**
meta-arm is using the Gitlab CI infrastructure.  This is currently being done internal to Arm, but an external version can be seen at <https://gitlab.com/jonmason00/meta-arm/-/pipelines>.
This CI is constantly being expanded to provide increased coverage of the software and hardware supported in meta-arm. All platforms are required to add a kas file and `.gitlab-ci.yml` entry as part of the initial patch series. More information on kas can be found at <https://github.com/siemens/kas>.
To this end, it would be wise to run kas locally to verify everything works prior to pushing to the CI build system.
## **Running kas locally**
### **Install kas**
kas can be installed with pip, for example:
```
$ pip3 install --user kas
```
See <https://kas.readthedocs.io/en/latest/userguide/getting-started.html> for information on the dependencies and more.
This assumes that the kas path ($HOME/.local/bin) is in $PATH. If not, the user will need to manually add this or the kas command will not be found.
### **Run kas locally**
```
$ cd ~/meta-arm/
$ kas build kas/juno.yml
```
By default kas will create a build directory under meta-arm to contain the checked out layers, build directory, and downloads.  You can change this by setting environment variables. DL\_DIR and SSTATE\_DIR are respected so these can point at existing directories, and setting KAS\_WORK\_DIR to the directory where repositories are already cloned will save having to re-fetch. This can look something like:
```
$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/qemuarm64.yml:ci/testimage.yml
```
See the [quick start guide](/documentation/quick-start.md) for more information on how to set this up.
## **Locked Revisions in CI with lockfiles**
The CI in meta-arm will generate a kas "lock file" when it starts to ensure that all of the builds checkout the same revision of the various different layers that are used. If this isn't done then there's a chance that a layer will be modified upstream during the CI, which results in some builds failing and some builds passing.
This lock file is saved as an artefact of the update-repos job by the CI, and only generated if it doesn't already exist in the repository. This can be used to force specific revisions of layers to be used instead of HEAD, which can be useful if upstream changes are causing problems in development.
The lockfile.yml can be downloaded manually, but there's a script in meta-arm to fetch the lock file for the latest successful build of the specified branch:
```
$ ./ci/download-lockfile.py --help
usage: download-lockfile.py [-h] server project refspec
positional arguments:
server GitLab server name
project meta-arm project name
refspec Branch/commit
$ ./ci/download-lockfile.py https://gitlab.com/jonmason00/meta-arm master
Fetched lockfile.yml
Commit this lockfile.yml to the top-level of the meta-arm repository and the CI will use it automatically.
```
# **Relevant Links for kas, CI, and testing**
<https://github.com/siemens/kas.git>
<https://wiki.yoctoproject.org/wiki/Oe-selftest>
<https://wiki.yoctoproject.org/wiki/Image_tests>
<https://wiki.yoctoproject.org/wiki/Ptest>
<https://wiki.yoctoproject.org/wiki/BSP_Test_Plan>
-49
View File
@@ -1,49 +0,0 @@
# OEQA on Arm FVPs
OE-Core's [oeqa][OEQA] framework provides a method of performing runtime tests on machines using the `testimage` Yocto task. meta-arm has good support for writing test cases against [Arm FVPs][FVP], meaning the [runfvp][RUNFVP] boot configuration can be re-used.
Tests can be configured to run automatically post-build by setting the variable `TESTIMAGE_AUTO="1"`, e.g. in your Kas file or local.conf.
meta-arm provides the OEFVPTarget which must be set up in the machine configuration:
```
TEST_TARGET = "OEFVPTarget"
TEST_SERVER_IP = "127.0.0.1"
TEST_TARGET_IP = "127.0.0.1:2222"
IMAGE_FEATURES:append = " ssh-server-dropbear"
FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] ?= "2222=22"
FVP_CONSOLES[default] = "terminal_0"
FVP_CONSOLES[tf-a] = "s_terminal_0"
```
The test target also generates a log file with the prefix 'fvp_log' in the image recipe's `${WORKDIR}/testimage` containing the FVP's stdout.
OEFVPTarget supports two different test interfaces - SSH and pexpect.
## SSH
As in OEQA in OE-core, tests cases can run commands on the machine using SSH. It therefore requires that an SSH server is installed in the image.
This uses the `run` method on the target, e.g:
```
(status, output) = self.target.run('uname -a')
```
which executes a single command on the target (using `ssh -c`) and returns the status code and the output. It is therefore useful for running tests in a Linux environment.
For examples of test cases, see meta/lib/oeqa/runtime/cases in OE-Core. The majority of test cases depend on `ssh.SSHTest.test_ssh`, which first validates that the SSH connection is functioning.
## pexpect
To support firmware and baremetal testing, OEFVPTarget also allows test cases to make assertions against one or more consoles using the pexpect library.
Internally, this test target launches a [Pexpect][PEXPECT] instance for each entry in FVP_CONSOLES which can be used with the provided alias. The whole Pexpect API is exposed on the target, where the alias is always passed as the first argument, e.g.:
```
self.target.expect('default', r'root@.*\:~#', timeout=30)
self.assertNotIn(b'ERROR:', self.target.before('tf-a'))
```
For an example of a full test case, see meta-arm/lib/oeqa/runtime/cases/linuxboot.py This test case can be used to minimally verify that a machine boots to a Linux shell. The default timeout is 10 minutes, but this can be configured with the variable TEST_FVP_LINUX_BOOT_TIMEOUT, which expects a value in seconds.
[OEQA]: https://docs.yoctoproject.org/test-manual/intro.html
[FVP]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
[RUNFVP]: runfvp.md
[PEXPECT]: https://pexpect.readthedocs.io/en/stable/overview.html
-105
View File
@@ -1,105 +0,0 @@
# **Yocto Project quick start for Arm system software developers**
If you want to read the The Yocto Project official quick start documentation, go to <https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html>
If that looks like too much reading, then here is how to do it even faster!
# **Step 0: Install build deps and kas**
```
$ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev python3-subunit mesa-common-dev zstd liblz4-tool file locales libacl1
$ pip install kas
```
OR, if you prefer to use a docker will all that stuff already installed:
```
$ sudo docker run -it --name kas-test --volume /mnt/yocto/:/builds/persist ghcr.io/siemens/kas/kas /bin/bash
```
> **_NOTE:_**
> the “--volume” is the directory where your persistent stuff (like downloads and build artifacts) will go to help speed up your builds and can be sharable amongst your builds/containers.  If you want to go completely clean-room, feel free to remove it
# **Step 1: clone meta-arm and build meta-arm**
```
$ git clone https://git.yoctoproject.org/meta-arm
$ cd meta-arm/
$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/fvp-base.yml:ci/testimage.yml
```
> **_NOTE:_**
> “ci/testimage.yml” will cause the build to run some basic system tests.  If you dont care about verifying basic functionality, then remove it and it should be faster (a few less programs will be added to the system image and the 2-3mins that it takes to run the test will not happen).
> **_NOTE:_**
> You may wish to add the Yocto Project SSTATE Mirror (especially the first time) to speed up the build by downloading the build fragments (built by the Yocto Project autobuilder) from the internet. This can be done by adding "ci/sstate-mirror.yml" in kas or adding the relevant lines to your local.conf. Using the above example:
```
$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/fvp-base.yml:ci/sstate-mirror.yml
```
> **_NOTE:_**
> This only fetches the parts necessary for your build and may take several minutes depending on your internet connection speed. Also, it only fetches what is available. There may still be a need to build things depending on your configuration.
For more information on kas and various commands, please reference <https://kas.readthedocs.io/en/latest/>.
Depending on what software you are building, fvp-base might not be the machine you want to build for.
The following website provides an EXTREMELY rough way to tell what software is in what machines, and what versions are being run:
<https://gitlab.com/jonmason00/meta-arm/-/jobs/artifacts/master/file/update-report/index.html?job=pending-updates>
If, as an example, were wanting to develop trusted-firmware-a; then fvp-base will work for us. 
### **Okay, you are done!  VICTORY!**
### **Oh, you actually wanted to mess around with the system software source code?**
# **Step 2: use devtool to get your source**
Setup your environment via the (non-kas) Yocto Project tools
```
$ source poky/oe-init-build-env
```
Use devtool to checkout the version of software being used on the machine above (in the above example, this will be trusted-firmware-a for fvp-base).
```
$ devtool modify trusted-firmware-a
```
This will download the source, hopefully in git (depending on how the Yocto Project recipe was written), and should print a path at the end where the source code was checked out.  In the trusted-firmware-a example, I got:
> /builder/meta-arm/build/workspace/sources/trusted-firmware-a
Inside of that directory, you should see the relevant source code.  In this example, it is a standard git tree.  So, you can add remotes, checkout different SHAs, etc
Ok, so you are set with your changes and want to build them.
```
$ devtool build trusted-firmware-a
```
This should build the software in question, but it is not yet integrated into a system image.  To do that, run:
```
$ devtool build-image core-image-sato
```
The image should match the image being used on your machine above.  Most of them in meta-arm are set to core-image-sato.  
Also, if you used testimage above, it will run testimage now
### **Okay, you are done!  VICTORY!**
# **Step 3.  Testing your patches outside of devtool**
At this point I will assume you have a patch and want to add it to the base recipe.  Using the above example, in the devtool directory:
```
$ git format-patch -1
0001-example.patch
$ mv 0001-example.patch ~/meta-arm/meta-arm/recipes-bsp/trusted-firmware-a/files/
$ cd ~/meta-arm
$ devtool reset trusted-firmware-a
$ echo SRC_URI:append = " file://0001-example.patch" >> meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.10.3.bb
```
> **_NOTE:_**
> there is a space before the “file” and yes it matters very much
At this point, you can go back using kas and verify that the patch works in a clean-ish tree.
```
$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/fvp-base.yml:ci/testimage.yml
```
There is obviously much more that can be done and other ways to do similar things.
## **If there are issues or questions then please ask them on the #meta-arm irc channel on libera.chat**
-43
View File
@@ -1,43 +0,0 @@
# **meta-arm Releases and Branching**
## **Release and Branching background**
The Yocto Project releases twice a year (April and October): "stable" releases are made every six months and have a lifetime of seven months to allow for migration, while "long term support" (LTS) releases are picked every two years starting from Dunfell in April 2020. The standard practice for all Yocto Compatible layers is to create a "named" branch consistent with the code name of that release. For example, the “dunfell” release of the Yocto Project will have a branch named “dunfell” in the official git repository, and layers compatible with dunfell will have a branch named “dunfell”. Thus, a customer can easily organize a collection of appropriate layers to make a product.
In the Yocto Project, these named branches are “stable”, and only take bug fixes or security-critical upgrades. Active development occurs on the master branch. However, this methodology can be problematic if mimicked with the compatible layers. Companies, like Arm, may not wish to release a snapshot of the relevant “master” branches under active development, due to the amount of testing, fixing, and hardening necessary to make a product from a non-stable release. Also, changes to keep the master branch of a layer working with the upstream master branch of the Yocto Project may result in that branch no longer being compatible with named branches (e.g., it might not be possible to mix and match master and dunfell). So, a decision must be made on the branching policy of meta-arm.
## **Adding new Hardware or Software features**
There are many different ways to resolve this issue. After some discussion, the best solution for us is to allow new hardware enablement (and relevant software features) to be included in LTS named branches (not just bug fixes). This will allow for a more stable software platform for software to be developed, tested, and released. Also, the single branch allows for focused testing (limiting the amount of resources needed for CI/CD), lessens/eliminates code diverging on various branches, and lessens confusion on which branch to use. The risk of making this choice is a potentially non-stable branch which will require more frequent testing to lessen the risk, and not following the “stable” methodology of the core Yocto Project layers (though it is not uncommon for BSP layers to behave this way).
## **Process**
The process for patches intended on being integrated into only the master branch is the normal internal process of pushing for code review and CI, approval and integration into upstream meta-arm master branch.
For patches intended on being included in an LTS named branch, the preferred process is to upstream via the master branch, rebase the patch (or series against the intended LTS branch) and send email with the release name in the subject line after the "PATCH" (e.g., "[PATCH dunfell] Add foo to bar").
If there is a time crunch and the preferred way above cannot be completed in time, upstreaming via the LTS branch can occur. This follows the normal process above but without the master integration step. However, any patches upstreamed in this manner must be pushed to master in a timely fashion (after the time crunch). Nagging emails will be sent and managers will be involved as the time grows.
## **Testing**
See [continuous-integration-and-kas.md](/documentation/continuous-integration-and-kas.md) for information how the layer is tested and what tests are run. It is presumed that all code will be compiled as part of the CI process of the gerrit code review. Also, testing on virtual platforms and code conformity checks will be run when enabled in the process.
## **Branching strategy and releases**
Named branches for meta-arm will be released as close as possible to the release of the YP LTS release. Meta-arm named branches will be created from the meta-arm master branch.
To minimize the additional work of maintaining multiple branches it is assumed that there will only be two active development branches at any given time: master and the most recent Long Term Stable (LTS) as the named branch. All previous named LTS branches will be EOLed when a new LTS has been released. Any branches that are EOLed will still exist in the meta-arm, but bug fix patches will be accepted. Limited to no testing will occur on EOLed branches. Exceptions to this can be made, but must be sized appropriately and agreed to by the relevant parties.
Named branch release will coincide with Yocto Project releases. These non-LTS branches will be bug fix only and will be EOLed on the next release (similar to the YP branching behavior).
### **Branch transitions**
When YP is approaching release, meta-arm will attempt to stabilize master so that the releases can coincide.
* T-6 weeks - Email is sent to meta-arm mailing list notifying of upcoming code freeze of features to meta-arm
* T-4 weeks - Code freeze to meta-arm. Only bug fixes are taken at this point.
* T-0 - Official upstream release occurs. With no outstanding critical bugs, a new named branch is created based on the current meta-arm master branch. Previous named branches are now frozen and will not accept new patches (but will continue to be present for reference and legacy usage).
## **Tagging**
### **Branch Tagging**
When each branch is released, a git tag with the Yocto Project version number will be added. For example, `4.3`. Also, this tag version number will be prepended with "yocto" in a duplicate tag (e.g., "yocto-4.3").
Conciding with the Yocto Project release schedule, every branch which has one or more changes added to it in the previous 6 months will get a minor versioned tag (e.g., "4.3.1" and "yocto-4.3.1").
### **BSP Release Tagging**
BSP releases for those boards supported in meta-arm-bsp maybe have an additional tag to denote their software releases. The tag will consist of the board name (in all capital letters), year, and month. For example, "CORSTONE1000-2023.11".
The release schedule for this is outside the standard Yocto Project release candence, but is generally encouraged to be as close to these releases as possible. Similarily, it is recommended the BSP releases be based on the latest LTS branch.
# **Relevant Links**
<https://wiki.yoctoproject.org/wiki/Releases>
-131
View File
@@ -1,131 +0,0 @@
# Running Images with a FVP
The `runfvp` tool in meta-arm makes it easy to run Yocto Project disk images inside a [Fixed Virtual Platform (FVP)][FVP]. Some FVPs, such as the [Arm Architecture Models][AEM], are available free to download, but others need registration or are only available commercially. The `fvp-base` machine in meta-arm-bsp uses one of these AEM models.
## Running images with `runfvp`
To build images with the FVP integration, the `fvpboot` image class needs to be inherited. If the machine does not do this explicitly it can be done in `local.conf`:
```
IMAGE_CLASSES += "fvpboot"
```
The class will download the correct FVP and write a `.fvpconf` configuration file when an image is built.
To run an image in a FVP, pass either a machine name or a `.fvpconf` path to `runfvp`.
```
$ ./meta-arm/scripts/runfvp tmp/deploy/images/fvp-base/core-image-minimal-fvp-base.fvpconf
```
When a machine name is passed, `runfvp` will start the latest image that has been built for that machine. This requires that the BitBake environment has been initialized (using `oe-init-build-env` or similar) as it will start BitBake to determine where the images are.
```
$ ./meta-arm/scripts/runfvp fvp-base
```
Note that currently meta-arm's `scripts` directory isn't in `PATH`, so a full path needs to be used.
`runfvp` will automatically start terminals connected to each of the serial ports that the machine specifies. This can be controlled by using the `--terminals` option, for example `--terminals=none` will mean no terminals are started, and `--terminals=tmux` will start the terminals in [`tmux`][tmux] sessions. Alternatively, passing `--console` will connect the serial port directly to the current session, without needing to open further windows.
The default terminal can also be configured by writing a [INI-style][INI] configuration file to `~/.config/runfvp.conf`:
```
[RunFVP]
Terminal=tmux
```
Arbitrary options can be passed directly to the FVP by specifying them after a double dash, for example this will list all of the FVP parameters:
```
$ runfvp fvp-base -- --list-params
```
## Configuring machines with `fvpboot`
To configure a machine so that it can be ran inside `runfvp`, a number of variables need to be set in the machine configuration file (such as `meta-arm-bsp/conf/machine/fvp-base.conf`).
Note that at present these variables are not stable and their behaviour may be changed in the future.
### `FVP_EXE`
The name of the FVP binary itself, for example `fvp-base` uses `FVP_Base_RevC-2xAEMvA`.
### `FVP_PROVIDER`
The name of the recipe that provides the FVP executable set in `FVP_EXE`, for example `fvp-base` uses `fvp-base-a-aem-native`. This *must* be a `-native` recipe as the binary will be executed on the build host.
There are recipes for common FVPs in meta-arm already, and writing new recipes is trivial. For FVPs which are free to download `fvp-base-a-aem.bb` is a good example. Some FVPs must be downloaded separately as they need an account on Arm's website.
If `FVP_PROVIDER` is not set then it is assumed that `FVP_EXE` is installed on the host already.
### `FVP_CONFIG`
Parameters passed to the FVP with the `--parameter`/`-C` option. These are expressed as variable flags so individual parameters can be altered easily. For example:
```
FVP_CONFIG[bp.flashloader0.fname] = "fip-fvp.bin"
```
### `FVP_DATA`
Specify raw data to load at the specified address, passed to the FVP with the `--data` option. This is a space-separated list of parameters in the format `[INST=]FILE@[MEMSPACE:]ADDRESS`. For example:
```
FVP_DATA = "cluster0.cpu0=Image@0x80080000 \
cluster0.cpu0=fvp-base-revc.dtb@0x83000000"
```
### `FVP_APPLICATIONS`
Applications to load on the cores, passed to the FVP with the `--application` option. These are expressed as variable flags with the flag name being the instance and flag value the filename, for example:
```
FVP_APPLICATIONS[cluster0] = "linux-system.axf"
```
Note that symbols are not allowed in flag names, so if you need to use a wildcard in the instance then you'll need to use `FVP_EXTRA_ARGS` and `--application` directly.
### `FVP_TERMINALS`
Map hardware serial ports to abstract names. For example the `FVP_Base_RevC-2xAEMvA` FVP exposes four serial ports, `terminal_0` to `terminal_3`. Typically only `terminal_0` is used in the `fvp-base` machine so this can be named `"Console"` and the others `""`. When runfvp starts terminals it will only start named serial ports, so instead of opening four windows where only one is useful, it will only open one.
For example:
```
FVP_TERMINALS[bp.terminal_0] = "Console"
FVP_TERMINALS[bp.terminal_1] = ""
FVP_TERMINALS[bp.terminal_2] = ""
FVP_TERMINALS[bp.terminal_3] = ""
```
### `FVP_CONSOLES`
This specifies what serial ports can be used in oeqa tests, along with an alias to be used in the test cases. Note that the values have to be the FVP identifier but without the board prefix, for example:
```
FVP_CONSOLES[default] = "terminal_0"
FVP_CONSOLES[tf-a] = "s_terminal_0"
```
The 'default' console is also used when `--console` is passed to runfvp.
### `FVP_EXTRA_ARGS`
Arbitrary extra arguments that are passed directly to the FVP. For example:
```
FVP_EXTRA_ARGS = "--simlimit 60"
```
### `FVP_ENV_PASSTHROUGH`
The FVP is launched with an isolated set of environment variables. Add the name of a Bitbake variable to this list to pass it through to the FVP environment. For example:
```
FVP_ENV_PASSTHROUGH = "ARMLMD_LICENSE_FILE FM_TRACE_PLUGINS"
```
[AEM]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms/arm-ecosystem-models
[FVP]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
[tmux]: https://tmux.github.io/
[INI]: https://docs.python.org/3/library/configparser.html
-68
View File
@@ -1,68 +0,0 @@
# The Trusted Services: framework for developing root-of-trust services
meta-arm layer includes recipes for [Trusted Services][^1] Secure Partitions and Normal World applications
in `meta-arm/recipes-security/trusted-services`
## Secure Partitions recipes
We define dedicated recipes for all supported Trusted Services (TS) Secure Partitions.
These recipes produce ELF and DTB files for SPs.
These files are automatically included into optee-os image accordingly to defined MACHINE_FEATURES.
### How to include TS SPs
To include TS SPs into optee-os image you need to add into MACHINE_FEATURES
features for each [Secure Partition][^2] you would like to include:
| Secure Partition | MACHINE_FEATURE |
| ----------------- | --------------- |
| Attestation | ts-attesation |
| Crypto | ts-crypto |
| Firmware Update | ts-fwu
| Internal Storage | ts-its |
| Protected Storage | ts-storage |
| se-proxy | ts-se-proxy |
| smm-gateway | ts-smm-gateway |
| spm-test[1-4] | optee-spmc-test |
Other steps depend on your machine/platform definition:
1. For communications between Secure and Normal Words Linux kernel option `CONFIG_ARM_FFA_TRANSPORT=y`
is required. If your platform doesn't include it already you can add `arm-ffa` into MACHINE_FEATURES.
(Please see ` meta-arm/recipes-kernel/arm-tstee`.)
For running the `uefi-test` or the `xtest -t ffa_spmc` tests under Linux the `arm-ffa-user` drivel is required. This is
enabled if the `ts-smm-gateway` and/or the `optee-spmc-test` machine features are enabled.
(Please see ` meta-arm/recipes-kernel/arm-ffa-user`.)
2. optee-os might require platform specific OP-TEE build parameters (for example what SEL the SPM Core is implemented at).
You can find examples in `meta-arm/recipes-security/optee/optee-os_%.bbappend` for qemuarm64-secureboot machine
and in `meta-arm-bsp/recipes-security/optee/optee-os-corstone1000-common.inc` for the Corstone1000 platform.
3. trusted-firmware-a might require platform specific TF-A build parameters (SPD and SPMC details on the platform).
See `meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend` for qemuarm64-secureboot machine
and in `meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-corstone1000.inc` for theCorstone1000 platform.
4. Trusted Services supports an SPMC agonistic binary format. To build SPs to this format the `TS_ENV` variable is to be
set to `sp`. The resulting SP binaries should be able to boot under any FF-A v1.1 compliant SPMC implementation.
## Normal World applications
Optionally for testing purposes you can add `packagegroup-ts-tests` into your image. It includes
[Trusted Services test and demo tools][^3] and [xtest][^4] configured to include the `ffa_spmc` tests.
## OEQA Trusted Services tests
meta-arm also includes Trusted Service OEQA tests which can be used for automated testing.
See `ci/trusted-services.yml` for an example how to include them into an image.
------
[^1]: https://trusted-services.readthedocs.io/en/integration/overview/index.html
[^2]: https://trusted-services.readthedocs.io/en/integration/deployments/secure-partitions.html
[^3]: https://trusted-services.readthedocs.io/en/integration/deployments/test-executables.html
[^4]: https://optee.readthedocs.io/en/latest/building/gits/optee_test.html
-12
View File
@@ -1,12 +0,0 @@
header:
version: 13
repos:
meta-arm:
layers:
meta-arm-systemready:
distro: nodistro
target:
- arm-systemready-firmware
-12
View File
@@ -1,12 +0,0 @@
header:
version: 13
includes:
- kas/arm-systemready-firmware.yml
env:
TESTIMAGE_AUTO: "1"
# The full testimage run typically takes around 12-24h on fvp-base.
TEST_OVERALL_TIMEOUT: "${@ 24*60*60}"
target:
- arm-systemready-ir-acs
@@ -1,8 +0,0 @@
header:
version: 13
includes:
- kas/arm-systemready-firmware.yml
- kas/arm-systemready-linux-distros-unattended-installation.yml
target:
- arm-systemready-linux-distros-debian
@@ -1,8 +0,0 @@
header:
version: 16
includes:
- kas/arm-systemready-firmware.yml
- kas/arm-systemready-linux-distros-unattended-installation.yml
target:
- arm-systemready-linux-distros-fedora
@@ -1,8 +0,0 @@
header:
version: 13
includes:
- kas/arm-systemready-firmware.yml
- kas/arm-systemready-linux-distros-unattended-installation.yml
target:
- arm-systemready-linux-distros-opensuse
@@ -1,11 +0,0 @@
header:
version: 16
env:
DISTRO_UNATTENDED_INST_TESTS:
# The full testimage run typically takes around 12-24h on fvp-base.
TEST_OVERALL_TIMEOUT: "${@ 24*60*60}"
local_conf_header:
systemready-unattended-inst: |
TESTIMAGE_AUTO = "${@oe.utils.vartrue("DISTRO_UNATTENDED_INST_TESTS", "1", "", d)}"
-53
View File
@@ -1,53 +0,0 @@
header:
version: 14
distro: poky
defaults:
repos:
branch: styhead
repos:
meta-arm:
layers:
meta-arm:
meta-arm-bsp:
meta-arm-toolchain:
poky:
url: https://git.yoctoproject.org/git/poky
commit: 5465094be9a61a1639e1dab6d2b4ebea2bee7440
layers:
meta:
meta-poky:
meta-openembedded:
url: https://git.openembedded.org/meta-openembedded
commit: 461d85a1831318747af5abe86da193bcde3fd9b4
layers:
meta-oe:
meta-python:
meta-perl:
meta-secure-core:
url: https://github.com/wind-river/meta-secure-core.git
commit: 59d7e90542947c342098863b9998693ac79352b0
layers:
meta-secure-core-common:
meta-signing-key:
meta-efi-secure-boot:
local_conf_header:
base: |
CONF_VERSION = "2"
setup: |
PACKAGE_CLASSES = "package_ipk"
BB_NUMBER_THREADS ?= "16"
PARALLEL_MAKE ?= "-j16"
PACKAGECONFIG:append:pn-perf = " coresight"
machine: unset
target:
- corstone1000-flash-firmware-image
-6
View File
@@ -1,6 +0,0 @@
header:
version: 14
local_conf_header:
extsys: |
MACHINE_FEATURES += "corstone1000-extsys"
-23
View File
@@ -1,23 +0,0 @@
---
header:
version: 14
local_conf_header:
firmwarebuild: |
BBMULTICONFIG:remove = "firmware"
# Need to ensure the rescue linux options are selected
OVERRIDES .= ":firmware"
# Need to ensure we build with a small libc
TCLIBC="musl"
mass-storage: |
# Ensure the Mass Storage device is absent
FVP_CONFIG[board.msd_mmc.p_mmc_file] = "invalid.dat"
test-configuration: |
TEST_SUITES = "_qemutiny ping"
# Remove Dropbear SSH as it will not fit into the corstone1000 image.
IMAGE_FEATURES:remove = "ssh-server-dropbear"
CORE_IMAGE_EXTRA_INSTALL:remove = "ssh-pregen-hostkeys"
-8
View File
@@ -1,8 +0,0 @@
# yaml-language-server: $schema=https://raw.githubusercontent.com/siemens/kas/master/kas/schema-kas.json
header:
version: 14
local_conf_header:
fvp-multicore: |
MACHINE_FEATURES += "corstone1000_fvp_smp"
-22
View File
@@ -1,22 +0,0 @@
header:
version: 14
includes:
- kas/corstone1000-base.yml
- kas/corstone1000-image-configuration.yml
- kas/corstone1000-firmware-only.yml
- kas/fvp-eula.yml
env:
DISPLAY:
WAYLAND_DISPLAY:
XAUTHORITY:
local_conf_header:
testimagefvp: |
IMAGE_CLASSES += "fvpboot"
mass-storage: |
# Ensure the Mass Storage device is absent
FVP_CONFIG[board.msd_mmc.p_mmc_file] = "invalid.dat"
machine: corstone1000-fvp
-49
View File
@@ -1,49 +0,0 @@
header:
version: 14
local_conf_header:
extrapackages: |
# Intentionally blank to prevent perf from being added to the image in base.yml
firmwarebuild: |
# Only needed as kas doesn't add it automatically unless you have 2 targets in seperate configs
BBMULTICONFIG ?= "firmware"
distrosetup: |
DISTRO_FEATURES = "usbhost ipv4"
initramfsetup: |
# Telling the build system which image is responsible of the generation of the initramfs rootfs
INITRAMFS_IMAGE_BUNDLE:firmware = "1"
INITRAMFS_IMAGE:firmware ?= "corstone1000-recovery-image"
IMAGE_FSTYPES:firmware:pn-corstone1000-recovery-image = "${INITRAMFS_FSTYPES}"
IMAGE_NAME_SUFFIX:firmware = ""
# enable mdev/busybox for init
INIT_MANAGER:firmware = "mdev-busybox"
VIRTUAL-RUNTIME_init_manager:firmware = "busybox"
# prevent the kernel image from being included in the intramfs rootfs
PACKAGE_EXCLUDE:firmware += "kernel-image-*"
# Disable openssl in kmod to shrink the initramfs size
PACKAGECONFIG:remove:firmware:pn-kmod = "openssl"
imageextras: |
# Don't include kernel binary in rootfs /boot path
RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""
# all optee packages
CORE_IMAGE_EXTRA_INSTALL += "optee-client"
# TS PSA API tests commands for crypto, its, ps and iat
CORE_IMAGE_EXTRA_INSTALL += "packagegroup-ts-tests-psa"
CORE_IMAGE_EXTRA_INSTALL:firmware += "packagegroup-ts-tests-psa"
# external system firmware
CORE_IMAGE_EXTRA_INSTALL:firmware += "external-system-elf"
capsule: |
CAPSULE_EXTENSION = "uefi.capsule"
CAPSULE_FW_VERSION = "6"
CAPSULE_NAME = "${MACHINE}-v${CAPSULE_FW_VERSION}"
-8
View File
@@ -1,8 +0,0 @@
header:
version: 14
includes:
- kas/corstone1000-base.yml
- kas/corstone1000-image-configuration.yml
- kas/corstone1000-firmware-only.yml
machine: corstone1000-mps3
-43
View File
@@ -1,43 +0,0 @@
header:
version: 13
includes:
- kas/fvp-eula.yml
env:
DISPLAY:
WAYLAND_DISPLAY:
XAUTHORITY:
distro: poky
machine: fvp-base
defaults:
repos:
refspec: master
repos:
meta-arm:
layers:
meta-arm:
meta-arm-bsp:
meta-arm-toolchain:
poky:
url: https://git.yoctoproject.org/git/poky
path: layers/poky
layers:
meta:
meta-poky:
local_conf_header:
base: |
CONF_VERSION = "2"
PACKAGE_CLASSES = "package_ipk"
PACKAGECONFIG:remove:pn-qemu-system-native = "gtk+ sdl"
EXTRA_IMAGE_FEATURES:append = " debug-tweaks ssh-server-openssh"
CORE_IMAGE_EXTRA_INSTALL:append = " ssh-pregen-hostkeys"
IMAGE_CLASSES:append = " testimage fvpboot"
target:
- core-image-minimal
-5
View File
@@ -1,5 +0,0 @@
header:
version: 13
env:
ARM_FVP_EULA_ACCEPT:
-7
View File
@@ -1,7 +0,0 @@
header:
version: 9
local_conf_header:
tftf: |
TFA_UBOOT = "0"
TFTF_TESTS = "1"
-1
View File
@@ -1 +0,0 @@
See ../README.md
-30
View File
@@ -1,30 +0,0 @@
# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"
# We have recipes-* directories, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "meta-arm-bsp"
BBFILE_PATTERN_meta-arm-bsp = "^${LAYERDIR}/"
BBFILE_PRIORITY_meta-arm-bsp = "5"
LAYERSERIES_COMPAT_meta-arm-bsp = "styhead"
LAYERDEPENDS_meta-arm-bsp = "core meta-arm"
# This won't be used by layerindex-fetch, but works everywhere else
LAYERDEPENDS_meta-arm-bsp:append:corstone1000 = " meta-python openembedded-layer efi-secure-boot"
LAYERDEPENDS_meta-arm-bsp:append:musca-b1 = " meta-python"
LAYERDEPENDS_meta-arm-bsp:append:musca-s1 = " meta-python"
# Additional license directories.
LICENSE_PATH += "${LAYERDIR}/custom-licenses"
BBFILES_DYNAMIC += " \
meta-arm-systemready:${LAYERDIR}/dynamic-layers/meta-arm-systemready/*/*/*.bb \
meta-arm-systemready:${LAYERDIR}/dynamic-layers/meta-arm-systemready/*/*/*.bbappend \
"
WARN_QA:append:layer-meta-arm-bsp = " patch-status"
addpylib ${LAYERDIR}/lib oeqa
@@ -1,76 +0,0 @@
#@TYPE: Machine
#@NAME: corstone1000-fvp machine
#@DESCRIPTION: Machine configuration for Corstone1000 64-bit FVP
require conf/machine/include/corstone1000.inc
TFA_TARGET_PLATFORM = "fvp"
TFM_PLATFORM_IS_FVP = "TRUE"
# testimage config
TEST_TARGET = "OEFVPTarget"
TEST_TARGET_IP = "127.0.0.1:2222"
DEFAULT_TEST_SUITES:append = " fvp_boot fvp_devices"
# FVP Config
FVP_PROVIDER ?= "fvp-corstone1000-native"
FVP_EXE ?= "FVP_Corstone-1000"
FVP_CONSOLES[default] = "host_terminal_0"
FVP_CONSOLES[tf-a] = "host_terminal_1"
FVP_CONSOLES[se] = "secenc_terminal"
FVP_CONSOLES[extsys] = "extsys_terminal"
#Disable Time Annotation
FASTSIM_DISABLE_TA = "0"
# FVP Parameters
FVP_CONFIG[se.trustedBootROMloader.fname] ?= "bl1.bin"
FVP_CONFIG[board.xnvm_size] ?= "64"
FVP_CONFIG[se.trustedSRAM_config] ?= "6"
FVP_CONFIG[se.BootROM_config] ?= "3"
FVP_CONFIG[board.hostbridge.interfaceName] ?= "tap0"
FVP_CONFIG[board.smsc_91c111.enabled] ?= "1"
FVP_CONFIG[board.hostbridge.userNetworking] ?= "true"
FVP_CONFIG[board.hostbridge.userNetPorts] ?= "5555=5555,8080=80,2222=22"
FVP_CONFIG[board.se_flash_size] ?= "8192"
FVP_CONFIG[diagnostics] ?= "4"
FVP_CONFIG[disable_visualisation] ?= "true"
FVP_CONFIG[se.nvm.update_raw_image] ?= "0"
FVP_CONFIG[se.cryptocell.USER_OTP_FILTERING_DISABLE] ?= "1"
# Boot image
FVP_DATA ?= "board.flash0=corstone1000-flash-firmware-image-${MACHINE}.wic@0x68000000"
# External system (cortex-M3)
FVP_CONFIG[extsys_harness0.extsys_flashloader.fname] ?= "es_flashfw.bin"
# FVP Terminals
FVP_TERMINALS[host.host_terminal_0] ?= "Normal World Console"
FVP_TERMINALS[host.host_terminal_1] ?= "Secure World Console"
FVP_TERMINALS[se.secenc_terminal] ?= "Secure Enclave Console"
FVP_TERMINALS[extsys0.extsys_terminal] ?= "Cortex M3"
# MMC card configuration
FVP_CONFIG[board.msd_mmc.card_type] ?= "SDHC"
FVP_CONFIG[board.msd_mmc.p_fast_access] ?= "0"
FVP_CONFIG[board.msd_mmc.diagnostics] ?= "0"
FVP_CONFIG[board.msd_mmc.p_max_block_count] ?= "0xFFFF"
FVP_CONFIG[board.msd_config.pl180_fifo_depth] ?= "16"
FVP_CONFIG[board.msd_mmc.support_unpadded_images] ?= "true"
FVP_CONFIG[board.msd_mmc.p_mmc_file] ?= "${IMAGE_NAME}.wic"
# MMC2 card configuration
FVP_CONFIG[board.msd_mmc_2.card_type] ?= "SDHC"
FVP_CONFIG[board.msd_mmc_2.p_fast_access] ?= "0"
FVP_CONFIG[board.msd_mmc_2.diagnostics] ?= "0"
FVP_CONFIG[board.msd_mmc_2.p_max_block_count] ?= "0xFFFF"
FVP_CONFIG[board.msd_config_2.pl180_fifo_depth] ?= "16"
FVP_CONFIG[board.msd_mmc_2.support_unpadded_images] ?= "true"
FVP_CONFIG[board.msd_mmc_2.p_mmc_file] ?= "corstone1000-esp-image-${MACHINE}.wic"
# Virtio-Net configuration
FVP_CONFIG[board.virtio_net.enabled] ?= "1"
FVP_CONFIG[board.virtio_net.hostbridge.interfaceName] ?= "eth1"
FVP_CONFIG[board.virtio_net.hostbridge.userNetworking] ?= "true"
FVP_CONFIG[board.virtio_net.hostbridge.userNetPorts] ?= "5555=5555,8080=80,2222=22"
FVP_CONFIG[board.virtio_net.transport] ?= "legacy"
@@ -1,9 +0,0 @@
#@TYPE: Machine
#@NAME: corstone1000-mps3 machine
#@DESCRIPTION: Machine configuration for Corstone1000 64-bit MPS3 FPGA board
require conf/machine/include/corstone1000.inc
TFA_TARGET_PLATFORM = "fpga"
PLATFORM_IS_FVP = "FALSE"
-68
View File
@@ -1,68 +0,0 @@
# Configuration for Armv8-A Base Platform FVP
#@TYPE: Machine
#@NAME: Armv8-A Base Platform FVP machine
#@DESCRIPTION: Machine configuration for Armv8-A Base Platform FVP model
require conf/machine/include/arm/arch-armv8-4a.inc
ARM_SYSTEMREADY_FIRMWARE = "trusted-firmware-a:do_deploy"
ARM_SYSTEMREADY_ACS_CONSOLE = "default"
EXTRA_IMAGEDEPENDS = "${ARM_SYSTEMREADY_FIRMWARE}"
MACHINE_FEATURES = "efi vfat"
IMAGE_NAME_SUFFIX = ""
IMAGE_FSTYPES += "wic"
WKS_FILE ?= "efi-disk.wks.in"
SERIAL_CONSOLES = "115200;ttyAMA0"
# FIXME - This is being upstreamed. Remove once that has occurred.
KERNEL_CONSOLE ?= "${@','.join(d.getVar('SERIAL_CONSOLES').split(' ')[0].split(';')[::-1]) or 'ttyS0'}"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
KERNEL_DTB_NAME = "fvp-base-revc.dtb"
KERNEL_DEVICETREE = "arm/${KERNEL_DTB_NAME}"
KERNEL_IMAGETYPE = "Image"
EXTRA_IMAGEDEPENDS += "trusted-firmware-a"
# FVP u-boot configuration
UBOOT_MACHINE = "vexpress_fvp_defconfig"
EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boot", "grub-efi", d)}"
# As this is a virtual target that will not be used in the real world there is
# no need for real SSH keys.
MACHINE_EXTRA_RRECOMMENDS += "ssh-pregen-hostkeys"
TEST_TARGET = "OEFVPTarget"
TEST_TARGET_IP = "127.0.0.1:2222"
DEFAULT_TEST_SUITES:append = " fvp_boot fvp_devices"
TEST_FVP_DEVICES ?= "rtc watchdog networking virtiorng cpu_hotplug"
FVP_PROVIDER ?= "fvp-base-a-aem-native"
FVP_EXE ?= "FVP_Base_RevC-2xAEMvA"
FVP_CONFIG[bp.ve_sysregs.exit_on_shutdown] ?= "1"
FVP_CONFIG[bp.virtio_net.enabled] ?= "1"
FVP_CONFIG[bp.virtio_net.hostbridge.userNetworking] ?= "1"
# Tell testimage to connect to localhost:2222, and forward that to SSH in the FVP.
FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] = "2222=22"
FVP_CONFIG[bp.virtio_rng.enabled] ?= "1"
FVP_CONFIG[cache_state_modelled] ?= "0"
FVP_CONFIG[cluster0.check_memory_attributes] ?= "0"
FVP_CONFIG[cluster1.check_memory_attributes] ?= "0"
FVP_CONFIG[cluster0.stage12_tlb_size] ?= "1024"
FVP_CONFIG[cluster1.stage12_tlb_size] ?= "1024"
FVP_CONFIG[bp.secureflashloader.fname] ?= "bl1-fvp.bin"
FVP_CONFIG[bp.flashloader0.fname] ?= "fip-fvp.bin"
FVP_CONFIG[bp.virtioblockdevice.image_path] ?= "${IMAGE_NAME}.wic"
# Set the baseline to ARMv8.4, as the default is 8.0.
FVP_CONFIG[cluster0.has_arm_v8-4] = "1"
FVP_CONFIG[cluster1.has_arm_v8-4] = "1"
FVP_CONSOLES[default] = "terminal_0"
FVP_TERMINALS[bp.terminal_0] ?= "Console"
FVP_TERMINALS[bp.terminal_1] ?= ""
FVP_TERMINALS[bp.terminal_2] ?= ""
FVP_TERMINALS[bp.terminal_3] ?= ""
FVP_CONFIG[bp.secure_memory] ?= "1"
@@ -1,65 +0,0 @@
require conf/machine/include/arm/armv8a/tune-cortexa35.inc
MACHINEOVERRIDES =. "corstone1000:"
# TF-M
PREFERRED_VERSION_trusted-firmware-m ?= "2.1.%"
# TF-A
TFA_PLATFORM = "corstone1000"
PREFERRED_VERSION_trusted-firmware-a ?= "2.11.%"
PREFERRED_VERSION_tf-a-tests ?= "2.10.%"
TFA_BL2_BINARY = "bl2-corstone1000.bin"
TFA_FIP_BINARY = "fip-corstone1000.bin"
# optee
PREFERRED_VERSION_optee-os ?= "4.2.%"
# Trusted Services
TS_PLATFORM = "arm/corstone1000"
TS_SP_SE_PROXY_CONFIG = "corstone1000"
# Include smm-gateway and se-proxy SPs into optee-os binary
MACHINE_FEATURES += "ts-smm-gateway ts-se-proxy"
# u-boot
PREFERRED_VERSION_u-boot ?= "2023.07%"
MACHINE_FEATURES += "efi"
EFI_PROVIDER ?= "grub-efi"
# Grub
LINUX_KERNEL_ARGS ?= "earlycon=pl011,0x1a510000 console=ttyAMA0,115200"
GRUB_LINUX_APPEND ?= "${LINUX_KERNEL_ARGS}"
IMAGE_CMD:wic[vardeps] += "GRUB_LINUX_APPEND"
# Linux kernel
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "6.10.%"
KERNEL_IMAGETYPE = "Image"
KERNEL_IMAGETYPE:firmware = "Image.gz"
# add FF-A support in the kernel
MACHINE_FEATURES += "arm-ffa"
# enable this feature for kernel debugging
# MACHINE_FEATURES += "corstone1000_kernel_debug"
# login terminal serial port settings
SERIAL_CONSOLES ?= "115200;ttyAMA0"
IMAGE_FSTYPES += "wic"
# Need to clear the suffix so TESTIMAGE_AUTO works
IMAGE_NAME_SUFFIX = ""
WKS_FILE ?= "efi-disk-no-swap.wks.in"
WKS_FILE:firmware ?= "corstone1000-flash-firmware.wks.in"
# making sure EXTRA_IMAGEDEPENDS will be used while creating the image
WKS_FILE_DEPENDS:append = " ${EXTRA_IMAGEDEPENDS}"
# If not building under the firmware multiconf we need to build the actual firmware
FIRMWARE_DEPLOYMENT ?= "firmware-deploy-image"
FIRMWARE_DEPLOYMENT:firmware ?= ""
EXTRA_IMAGEDEPENDS += "${FIRMWARE_DEPLOYMENT}"
ARM_SYSTEMREADY_FIRMWARE = "${FIRMWARE_DEPLOYMENT}:do_deploy \
corstone1000-esp-image:do_image_complete \
"
ARM_SYSTEMREADY_ACS_CONSOLE ?= "default"
-30
View File
@@ -1,30 +0,0 @@
# Configuration for juno development board
#@TYPE: Machine
#@NAME: Juno machine
#@DESCRIPTION: Machine configuration for Juno
TUNE_FEATURES = "aarch64"
require conf/machine/include/arm/arch-armv8a.inc
MACHINE_FEATURES = "usbhost usbgadget alsa screen wifi bluetooth optee pci"
KERNEL_IMAGETYPE = "Image.gz"
KERNEL_DEVICETREE = "arm/juno.dtb arm/juno-r1.dtb arm/juno-r2.dtb"
IMAGE_FSTYPES += "tar.bz2 ext4 cpio.gz"
SERIAL_CONSOLES = "115200;ttyAMA0"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
EXTRA_IMAGEDEPENDS += "trusted-firmware-a virtual/bootloader firmware-image-juno"
# Juno u-boot configuration
UBOOT_MACHINE = "vexpress_aemv8a_juno_defconfig"
INITRAMFS_IMAGE_BUNDLE ?= "1"
INITRAMFS_IMAGE = "core-image-minimal"
IMAGE_NAME_SUFFIX = ""
-23
View File
@@ -1,23 +0,0 @@
# Configuration for Musca-B1 development board
#@TYPE: Machine
#@NAME: Musca-B1 machine
#@DESCRIPTION: Machine configuration for Musca-B1
DEFAULTTUNE ?= "armv8m-main"
require conf/machine/include/arm/armv8-m/tune-cortexm33.inc
# GLIBC will not work with Cortex-M.
TCLIBC = "newlib"
# For runqemu
IMAGE_FSTYPES += "ext4"
IMAGE_CLASSES += "qemuboot"
QB_SYSTEM_NAME = "qemu-system-arm"
QB_MACHINE = "-machine musca-b1"
QB_CPU = "-cpu cortex-m33"
QB_GRAPHICS = "-nographic -vga none"
QB_MEM = "512k"
QB_RNG = ""
TFM_PLATFORM = "arm/musca_b1"
-22
View File
@@ -1,22 +0,0 @@
# Configuration for Musca-S1 development board
#@TYPE: Machine
#@NAME: Musca-S1 machine
#@DESCRIPTION: Machine configuration for Musca-S1
require conf/machine/include/arm/armv8-m/tune-cortexm33.inc
# GLIBC will not work with Cortex-M.
TCLIBC = "newlib"
# For runqemu
IMAGE_FSTYPES += "ext4"
IMAGE_CLASSES += "qemuboot"
QB_SYSTEM_NAME = "qemu-system-arm"
QB_MACHINE = "-machine musca-s1"
QB_CPU = "-cpu cortex-m33"
QB_GRAPHICS = "-nographic -vga none"
QB_MEM = "512k"
QB_RNG = ""
TFM_PLATFORM = "arm/musca_s1"
-43
View File
@@ -1,43 +0,0 @@
#@TYPE: Machine
#@NAME: sbsa-ref
#@DESCRIPTION: Reference SBSA machine in qemu-system-aarch64 on Neoverse N2
require conf/machine/include/arm/armv9a/tune-neoversen2.inc
require conf/machine/include/qemu.inc
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
KERNEL_IMAGETYPE = "Image"
MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
MACHINE_FEATURES = " alsa bluetooth efi qemu-usermode rtc screen usbhost vfat wifi"
IMAGE_FSTYPES += "wic.qcow2"
# This unique WIC file is necessary because kernel boot args cannot be passed
# because there is no default kernel (see below). There is no default kernel
# because QEMU will only allow firmware or kernel to be passed in as a
# parameter, and we need the firmware. So, to allow for "ip=dhcp" as a kernel
# boot arg (which we need for testimage), we have to have a WIC file unique to
# this platform.
WKS_FILE = "qemu-efi-disk.wks.in"
EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boot", "grub-efi", d)}"
SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
EXTRA_IMAGEDEPENDS += "edk2-firmware"
QB_SYSTEM_NAME = "qemu-system-aarch64"
QB_MACHINE = "-machine sbsa-ref"
QB_CPU = "-cpu neoverse-n2"
QB_MEM = "-m 1024"
QB_DEFAULT_FSTYPE = "wic.qcow2"
QB_NETWORK_DEVICE = "-device virtio-net-pci,netdev=net0,mac=@MAC@"
QB_DRIVE_TYPE = "/dev/hd"
QB_ROOTFS_OPT = "-drive file=@ROOTFS@,if=ide,format=qcow2"
QB_DEFAULT_KERNEL = "none"
QB_OPT_APPEND = "-device usb-tablet -device usb-kbd -pflash @DEPLOY_DIR_IMAGE@/SBSA_FLASH0.fd -pflash @DEPLOY_DIR_IMAGE@/SBSA_FLASH1.fd"
QB_SERIAL_OPT = "-device virtio-serial-pci -chardev null,id=virtcon -device virtconsole,chardev=virtcon"
QB_TCPSERIAL_OPT = "-device virtio-serial-pci -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon"
# sbsa-ref is a true virtual machine so can't use KVM
QEMU_USE_KVM = "0"
-24
View File
@@ -1,24 +0,0 @@
# Configuration for Arm SGI575 development board
#@TYPE: Machine
#@NAME: SGI575
#@DESCRIPTION: Machine configuration for SGI575
require conf/machine/include/arm/armv8-2a/tune-cortexa75.inc
EXTRA_IMAGEDEPENDS += "virtual/control-processor-firmware"
EXTRA_IMAGEDEPENDS += "trusted-firmware-a"
KERNEL_IMAGETYPE ?= "Image"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
SERIAL_CONSOLES = "115200;ttyAMA0"
#grub-efi
EFI_PROVIDER ?= "grub-efi"
MACHINE_FEATURES += "efi"
IMAGE_FSTYPES += "cpio.gz wic"
WKS_FILE ?= "sgi575-efidisk.wks"
WKS_FILE_DEPENDS:append = " ${EXTRA_IMAGEDEPENDS}"
@@ -1,18 +0,0 @@
SLA0044 Rev5/February 2018
BY INSTALLING COPYING, DOWNLOADING, ACCESSING OR OTHERWISE USING THIS SOFTWARE OR ANY PART THEREOF (AND THE RELATED DOCUMENTATION) FROM STMICROELECTRONICS INTERNATIONAL N.V, SWISS BRANCH AND/OR ITS AFFILIATED COMPANIES (STMICROELECTRONICS), THE RECIPIENT, ON BEHALF OF HIMSELF OR HERSELF, OR ON BEHALF OF ANY ENTITY BY WHICH SUCH RECIPIENT IS EMPLOYED AND/OR ENGAGED AGREES TO BE BOUND BY THIS SOFTWARE LICENSE AGREEMENT.
Under STMicroelectronics intellectual property rights, the redistribution, reproduction and use in source and binary forms of the software or any part thereof, with or without modification, are permitted provided that the following conditions are met:
1. Redistribution of source code (modified or not) must retain any copyright notice, this list of conditions and the disclaimer set forth below as items 10 and 11.
2. Redistributions in binary form, except as embedded into microcontroller or microprocessor device manufactured by or for STMicroelectronics or a software update for such device, must reproduce any copyright notice provided with the binary code, this list of conditions, and the disclaimer set forth below as items 10 and 11, in documentation and/or other materials provided with the distribution.
3. Neither the name of STMicroelectronics nor the names of other contributors to this software may be used to endorse or promote products derived from this software or part thereof without specific written permission.
4. This software or any part thereof, including modifications and/or derivative works of this software, must be used and execute solely and exclusively on or in combination with a microcontroller or microprocessor device manufactured by or for STMicroelectronics.
5. No use, reproduction or redistribution of this software partially or totally may be done in any manner that would subject this software to any Open Source Terms. “Open Source Terms” shall mean any open source license which requires as part of distribution of software that the source code of such software is distributed therewith or otherwise made available, or open source license that substantially complies with the Open Source definition specified at www.opensource.org and any other comparable open source license such as for example GNU General Public License (GPL), Eclipse Public License (EPL), Apache Software License, BSD license or MIT license.
6. STMicroelectronics has no obligation to provide any maintenance, support or updates for the software.
7. The software is and will remain the exclusive property of STMicroelectronics and its licensors. The recipient will not take any action that jeopardizes STMicroelectronics and its licensors' proprietary rights or acquire any rights in the software, except the limited rights specified hereunder.
8. The recipient shall comply with all applicable laws and regulations affecting the use of the software or any part thereof including any applicable export control law or regulation.
9. Redistribution and use of this software or any part thereof other than as permitted under this license is void and will automatically terminate your rights under this license.
10. THIS SOFTWARE IS PROVIDED BY STMICROELECTRONICS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS, IMPLIED OR STATUTORY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF THIRD PARTY INTELLECTUAL PROPERTY RIGHTS, WHICH ARE DISCLAIMED TO THE FULLEST EXTENT PERMITTED BY LAW. IN NO EVENT SHALL STMICROELECTRONICS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
11. EXCEPT AS EXPRESSLY PERMITTED HEREUNDER, NO LICENSE OR OTHER RIGHTS, WHETHER EXPRESS OR IMPLIED, ARE GRANTED UNDER ANY PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS OF STMICROELECTRONICS OR ANY THIRD PARTY.
@@ -1,12 +0,0 @@
version: 2
build:
os: "ubuntu-22.04"
tools:
python: "3.9"
sphinx:
configuration: meta-arm-bsp/documentation/corstone1000/conf.py
formats:
- pdf
python:
install:
- requirements: meta-arm-bsp/documentation/requirements.txt
@@ -1,436 +0,0 @@
..
# Copyright (c) 2022-2024, Arm Limited.
#
# SPDX-License-Identifier: MIT
##########
Change Log
##########
This document contains a summary of the new features, changes and
fixes in each release of Corstone-1000 software stack.
***************
Version 2024.11
***************
Changes
=======
- Implementation of a replication strategy for FWU metadata in TF-M according to the FWU specification.
- Upgrade to metadata version 2 in TF-M.
- Increase the ITS and PS memory size in Secure Flash for TF-M.
- SW components upgrades.
- Bug fixes.
Corstone-1000 components versions
=================================
+-------------------------------------------+-----------------------------------------------------+
| linux-yocto | 6.10.14 |
+-------------------------------------------+-----------------------------------------------------+
| u-boot | 2023.07.02 |
+-------------------------------------------+-----------------------------------------------------+
| external-system | 0.1.0 |
+-------------------------------------------+-----------------------------------------------------+
| optee-client | 4.2.0 |
+-------------------------------------------+-----------------------------------------------------+
| optee-os | 4.2.0 |
+-------------------------------------------+-----------------------------------------------------+
| trusted-firmware-a | 2.11.0 |
+-------------------------------------------+-----------------------------------------------------+
| trusted-firmware-m | 2.1.0 |
+-------------------------------------------+-----------------------------------------------------+
| libts | 602be60719 |
+-------------------------------------------+-----------------------------------------------------+
| ts-newlib | 4.1.0 |
+-------------------------------------------+-----------------------------------------------------+
| ts-psa-{crypto, iat, its. ps}-api-test | 74dc6646ff |
+-------------------------------------------+-----------------------------------------------------+
| ts-sp-{se-proxy, smm-gateway} | 602be60719 |
+-------------------------------------------+-----------------------------------------------------+
Yocto distribution components versions
======================================
+-------------------------------------------+------------------------------+
| meta-arm | styhead |
+-------------------------------------------+------------------------------+
| poky | 5465094be9 |
+-------------------------------------------+------------------------------+
| meta-openembedded | 461d85a183 |
+-------------------------------------------+------------------------------+
| meta-secure-core | 59d7e90542 |
+-------------------------------------------+------------------------------+
| busybox | 1.36.1 |
+-------------------------------------------+------------------------------+
| musl | 1.2.5 |
+-------------------------------------------+------------------------------+
| gcc-arm-none-eabi | 13.3.rel1 |
+-------------------------------------------+------------------------------+
| gcc-cross-aarch64 | 14.2.0 |
+-------------------------------------------+------------------------------+
| openssl | 3.3.1 |
+-------------------------------------------+------------------------------+
***************
Version 2024.06
***************
Changes
=======
- Re-enabling support for the External System using linux remoteproc (only supporting switching on and off the External System)
- UEFI Secure Boot and Authenticated Variable support
- RSE Comms replaces OpenAMP
- The EFI System partition image is now created by the meta-arm build system.
This image is mounted on the second MMC card by default in the FVP.
- The capsule generation script is now part of the meta-arm build system.
Corstone1000-flash-firmware-image recipe generates a capsule binary using the U-Boot capsule generation tool that includes
all the firmware binaries and recovery kernel image.
- SW components upgrades
- Bug fixes
Corstone-1000 components versions
=================================
+-------------------------------------------+-----------------------------------------------------+
| arm-tstee | 2.0.0 |
+-------------------------------------------+-----------------------------------------------------+
| linux-yocto | 6.6.23 |
+-------------------------------------------+-----------------------------------------------------+
| u-boot | 2023.07.02 |
+-------------------------------------------+-----------------------------------------------------+
| external-system | 0.1.0 |
+-------------------------------------------+-----------------------------------------------------+
| optee-client | 4.1.0 |
+-------------------------------------------+-----------------------------------------------------+
| optee-os | 4.1.0 |
+-------------------------------------------+-----------------------------------------------------+
| trusted-firmware-a | 2.10.4 |
+-------------------------------------------+-----------------------------------------------------+
| trusted-firmware-m | 2.0.0 |
+-------------------------------------------+-----------------------------------------------------+
| libts | 602be60719 |
+-------------------------------------------+-----------------------------------------------------+
| ts-newlib | 4.1.0 |
+-------------------------------------------+-----------------------------------------------------+
| ts-psa-{crypto, iat, its. ps}-api-test | 602be60719 |
+-------------------------------------------+-----------------------------------------------------+
| ts-sp-{se-proxy, smm-gateway} | 602be60719 |
+-------------------------------------------+-----------------------------------------------------+
Yocto distribution components versions
======================================
+-------------------------------------------+------------------------------+
| meta-arm | scarthgap |
+-------------------------------------------+------------------------------+
| poky | scarthgap |
+-------------------------------------------+------------------------------+
| meta-openembedded | scarthgap |
+-------------------------------------------+------------------------------+
| meta-secure-core | scarthgap |
+-------------------------------------------+------------------------------+
| busybox | 1.36.1 |
+-------------------------------------------+------------------------------+
| musl | 1.2.4 |
+-------------------------------------------+------------------------------+
| gcc-arm-none-eabi | 13.2.Rel1 |
+-------------------------------------------+------------------------------+
| gcc-cross-aarch64 | 13.2.0 |
+-------------------------------------------+------------------------------+
| openssl | 3.2.1 |
+-------------------------------------------+------------------------------+
***************
Version 2023.11
***************
Changes
=======
- Making Corstone-1000 SystemReady IR 2.0 certifiable
- Allow booting Debian & OpenSUSE on FVP
- Add support for two MMC cards for the FVP
- Add signed capsule update support
- Enable on-disk capsule update
- Add the feature of purging specific DT nodes in U-Boot before Linux
- Add Ethernet over VirtIO support in U-Boot
- Add support for unaligned MMC card images
- Reducing the out-of-tree patches by upstreaming them to the corresponding open-source projects
- SW components upgrades
- Bug fixes
Corstone-1000 components versions
=================================
+-------------------------------------------+-----------------------------------------------------+
| arm-ffa-tee | 1.1.2-r0 |
+-------------------------------------------+-----------------------------------------------------+
| linux-yocto | 6.5.7 |
+-------------------------------------------+-----------------------------------------------------+
| u-boot | 2023.07 |
+-------------------------------------------+-----------------------------------------------------+
| external-system | 0.1.0+gitAUTOINC+8c9dca74b1-r0 |
+-------------------------------------------+-----------------------------------------------------+
| optee-client | 3.22.0 |
+-------------------------------------------+-----------------------------------------------------+
| optee-os | 3.22.0 |
+-------------------------------------------+-----------------------------------------------------+
| trusted-firmware-a | 2.9.0 |
+-------------------------------------------+-----------------------------------------------------+
| trusted-firmware-m | 1.8.1 |
+-------------------------------------------+-----------------------------------------------------+
| libts | 08b3d39471 |
+-------------------------------------------+-----------------------------------------------------+
| ts-newlib | 4.1.0 |
+-------------------------------------------+-----------------------------------------------------+
| ts-psa-{crypto, iat, its. ps}-api-test | 38cb53a4d9 |
+-------------------------------------------+-----------------------------------------------------+
| ts-sp-{se-proxy, smm-gateway} | 08b3d39471 |
+-------------------------------------------+-----------------------------------------------------+
Yocto distribution components versions
======================================
+-------------------------------------------+------------------------------+
| meta-arm | nanbield |
+-------------------------------------------+------------------------------+
| poky | nanbield |
+-------------------------------------------+------------------------------+
| meta-openembedded | nanbield |
+-------------------------------------------+------------------------------+
| meta-secure-core | nanbield |
+-------------------------------------------+------------------------------+
| busybox | 1.36.1 |
+-------------------------------------------+------------------------------+
| musl | 1.2.4 |
+-------------------------------------------+------------------------------+
| gcc-arm-none-eabi | 11.2-2022.02 |
+-------------------------------------------+------------------------------+
| gcc-cross-aarch64 | 13.2.0 |
+-------------------------------------------+------------------------------+
| openssl | 3.1.3 |
+-------------------------------------------+------------------------------+
***************
Version 2023.06
***************
Changes
=======
- GPT support (in TF-M, TF-A, U-boot)
- Use TF-M BL1 code as the ROM code instead of MCUboot (the next stage bootloader BL2 remains to be MCUboot)
- Secure Enclave uses CC312 OTP as the provisioning backend in FVP and FPGA
- NVMXIP block storage support in U-Boot
- Upgrading the SW stack recipes
- Upgrades for the U-Boot FF-A driver and MM communication
Corstone-1000 components versions
=================================
+-------------------------------------------+--------------------------------------------+
| arm-ffa-tee | 1.1.2-r0 |
+-------------------------------------------+--------------------------------------------+
| arm-ffa-user | 5.0.1-r0 |
+-------------------------------------------+--------------------------------------------+
| corstone1000-external-sys-tests | 1.0+gitAUTOINC+2945cd92f7-r0 |
+-------------------------------------------+--------------------------------------------+
| external-system | 0.1.0+gitAUTOINC+8c9dca74b1-r0 |
+-------------------------------------------+--------------------------------------------+
| linux-yocto | 6.1.25+gitAUTOINC+36901b5b29_581dc1aa2f-r0 |
+-------------------------------------------+--------------------------------------------+
| u-boot | 2023.01-r0 |
+-------------------------------------------+--------------------------------------------+
| optee-client | 3.18.0-r0 |
+-------------------------------------------+--------------------------------------------+
| optee-os | 3.20.0-r0 |
+-------------------------------------------+--------------------------------------------+
| trusted-firmware-a | 2.8.0-r0 |
+-------------------------------------------+--------------------------------------------+
| trusted-firmware-m | 1.7.0-r0 |
+-------------------------------------------+--------------------------------------------+
| ts-newlib | 4.1.0-r0 |
+-------------------------------------------+--------------------------------------------+
| ts-psa-{crypto, iat, its. ps}-api-test | 38cb53a4d9 |
+-------------------------------------------+--------------------------------------------+
| ts-sp-{se-proxy, smm-gateway} | 08b3d39471 |
+-------------------------------------------+--------------------------------------------+
Yocto distribution components versions
======================================
+-------------------------------------------+--------------------------------+
| meta-arm | mickledore |
+-------------------------------------------+--------------------------------+
| poky | mickledore |
+-------------------------------------------+--------------------------------+
| meta-openembedded | mickledore |
+-------------------------------------------+--------------------------------+
| busybox | 1.36.0-r0 |
+-------------------------------------------+--------------------------------+
| musl | 1.2.3+gitAUTOINC+7d756e1c04-r0 |
+-------------------------------------------+--------------------------------+
| gcc-arm-none-eabi-native | 11.2-2022.02 |
+-------------------------------------------+--------------------------------+
| gcc-cross-aarch64 | 12.2.rel1-r0 |
+-------------------------------------------+--------------------------------+
| openssl | 3.1.0-r0 |
+-------------------------------------------+--------------------------------+
******************
Version 2022.11.23
******************
Changes
=======
- Booting the External System (Cortex-M3) with RTX RTOS
- Adding MHU communication between the HOST (Cortex-A35) and the External System
- Adding a Linux application to test the External System
- Adding ESRT (EFI System Resource Table) support
- Upgrading the SW stack recipes
- Upgrades for the U-Boot FF-A driver and MM communication
Corstone-1000 components versions
=================================
+-------------------------------------------+------------+
| arm-ffa-tee | 1.1.1 |
+-------------------------------------------+------------+
| arm-ffa-user | 5.0.0 |
+-------------------------------------------+------------+
| corstone1000-external-sys-tests | 1.0 |
+-------------------------------------------+------------+
| external-system | 0.1.0 |
+-------------------------------------------+------------+
| linux-yocto | 5.19 |
+-------------------------------------------+------------+
| u-boot | 2022.07 |
+-------------------------------------------+------------+
| optee-client | 3.18.0 |
+-------------------------------------------+------------+
| optee-os | 3.18.0 |
+-------------------------------------------+------------+
| trusted-firmware-a | 2.7.0 |
+-------------------------------------------+------------+
| trusted-firmware-m | 1.6.0 |
+-------------------------------------------+------------+
| ts-newlib | 4.1.0 |
+-------------------------------------------+------------+
| ts-psa-{crypto, iat, its. ps}-api-test | 451aa087a4 |
+-------------------------------------------+------------+
| ts-sp-{se-proxy, smm-gateway} | 3d4956770f |
+-------------------------------------------+------------+
Yocto distribution components versions
======================================
+-------------------------------------------+---------------------+
| meta-arm | langdale |
+-------------------------------------------+---------------------+
| poky | langdale |
+-------------------------------------------+---------------------+
| meta-openembedded | langdale |
+-------------------------------------------+---------------------+
| busybox | 1.35.0 |
+-------------------------------------------+---------------------+
| musl | 1.2.3+git37e18b7bf3 |
+-------------------------------------------+---------------------+
| gcc-arm-none-eabi-native | 11.2-2022.02 |
+-------------------------------------------+---------------------+
| gcc-cross-aarch64 | 12.2 |
+-------------------------------------------+---------------------+
| openssl | 3.0.5 |
+-------------------------------------------+---------------------+
******************
Version 2022.04.04
******************
Changes
=======
- Linux distro openSUSE, raw image installation and boot in the FVP.
- SCT test support in FVP.
- Manual capsule update support in FVP.
******************
Version 2022.02.25
******************
Changes
=======
- Building and running psa-arch-tests on Corstone-1000 FVP
- Enabled smm-gateway partition in Trusted Service on Corstone-1000 FVP
- Enabled MHU driver in Trusted Service on Corstone-1000 FVP
- Enabled OpenAMP support in SE proxy SP on Corstone-1000 FVP
******************
Version 2022.02.21
******************
Changes
=======
- psa-arch-tests: recipe is dropped and merged into the secure-partitons recipe.
- psa-arch-tests: The tests are align with latest tfm version for psa-crypto-api suite.
******************
Version 2022.01.18
******************
Changes
=======
- psa-arch-tests: change master to main for psa-arch-tests
- U-Boot: fix null pointer exception for get_image_info
- TF-M: fix capsule instability issue for Corstone-1000
******************
Version 2022.01.07
******************
Changes
=======
- Corstone-1000: fix SystemReady-IR ACS test (SCT, FWTS) failures.
- U-Boot: send bootcomplete event to secure enclave.
- U-Boot: support populating Corstone-1000 image_info to ESRT table.
- U-Boot: add ethernet device and enable configs to support bootfromnetwork SCT.
******************
Version 2021.12.15
******************
Changes
=======
- Enabling Corstone-1000 FPGA support on:
- Linux 5.10
- OP-TEE 3.14
- Trusted Firmware-A 2.5
- Trusted Firmware-M 1.5
- Building and running psa-arch-tests
- Adding openamp support in SE proxy SP
- OP-TEE: adding smm-gateway partition
- U-Boot: introducing Arm FF-A and MM support
******************
Version 2021.10.29
******************
Changes
=======
- Enabling Corstone-1000 FVP support on:
- Linux 5.10
- OP-TEE 3.14
- Trusted Firmware-A 2.5
- Trusted Firmware-M 1.4
- Linux kernel: enabling EFI, adding FF-A debugfs driver, integrating ARM_FFA_TRANSPORT.
- U-Boot: Extending EFI support
- python3-imgtool: adding recipe for Trusted-firmware-m
- python3-imgtool: adding the Yocto recipe used in signing host images (based on MCUBOOT format)
--------------
*Copyright (c) 2022-2024, Arm Limited. All rights reserved.*

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