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

Compare commits

...

16 Commits

Author SHA1 Message Date
Harsimran Singh Tungal caa36c53f7 ci: enable testimage coverage for Corstone-1000 A320 FVP
Update the Corstone-1000 A320 FVP CI matrix to run testimage jobs.

This enables testimage coverage for both the firmware-only and no-firmware
entries.

Signed-off-by: Harsimran Singh Tungal <harsimransingh.tungal@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2026-06-30 09:00:17 -04:00
Harsimran Singh Tungal bcc633b8ce fvp:corstone1000-a320: update Corstone-1000 A320 FVP to 11.31
Update the Corstone-1000 with Cortex-A320 FVP recipe to use the
11.31.cs1000_a320_2 release from Arm Developer.

Switch the source URL to the new package layout, add the architecture-specific
download tokens, and update the x86_64 and aarch64 SHA256 checksums.

The new package extracts directly into the FVP install directory, so update the
install step and license paths accordingly.

Signed-off-by: Harsimran Singh Tungal <harsimransingh.tungal@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2026-06-30 09:00:17 -04:00
Harsimran Singh Tungal 9488c75a67 corstone1000: Pin layers SHA for wrynose release
Pinned layers in corstone1000-base.yml

Signed-off-by: Harsimran Singh Tungal <harsimransingh.tungal@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2026-06-30 09:00:17 -04:00
Harsimran Singh Tungal 2c9968a29c arm-bsp/documentation: corstone1000-a320: update 2026.05 wrynose release documentation
Update the Corstone-1000 with Cortex-A320 changelog, release notes,
user guide, tests documentation and metadata for the 2026.05 release.

Add the new 2026.05 changelog entry for the Corstone-1000 with
Cortex-A320 specific updates and align the component version tables and
Yocto distribution component versions with the current release content.

Refresh the user guide and tests documentation to align with the
2026.05 release state, including release tag references, recipe version
references, report links

Signed-off-by: Harsimran Singh Tungal <harsimransingh.tungal@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2026-06-30 09:00:17 -04:00
Harsimran Singh Tungal 80129934a6 arm-bsp/documentation: corstone1000: update 2026.05 wrynose release documentation
Update the Corstone-1000 changelog, release notes and user guide for
the 2026.05 wrynose release.

Add the new 2026.05 changelog entry and capture the main release work,
including the component upgrades, TF-M GPT and PSA FWU changes, and the
updated SSH-enabled build flow.
Refresh the component version tables and Yocto distribution component
versions in changelog for the new release.

Update the user guide to align with the 2026.05 release branch and
documentation state, including the Yocto release name, recipe version
references, release tag references, and related asset and report links.

Signed-off-by: Harsimran Singh Tungal <harsimransingh.tungal@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2026-06-30 09:00:17 -04:00
Ross Burton 01c33e4946 CI: add option to control whether warnings should be fatal or not
Warnings being always fatal is quite anti-social because sometimes there
are temporary warnings that we don't want to break the CI.

Signed-off-by: Ross Burton <ross.burton@arm.com>
2026-06-22 10:50:52 +01:00
Ross Burton 61fd528759 CI: use a single multiline script statement in .build
No change to the script, just formatting.

Signed-off-by: Ross Burton <ross.burton@arm.com>
2026-06-22 10:50:48 +01:00
Ross Burton 7d7f1fa63f CI: default CACHE_DIR to CI_PROJECT_DIR
Set the default cache directory to be the build tree so we don't assume
anything about the runner environment by default.

After this change, runners that don't set CACHE_DIR will need to set it
explicltly in their variables.

Signed-off-by: Ross Burton <ross.burton@arm.com>
2026-06-22 10:50:44 +01:00
Ross Burton bb4b6a9f7f CI: remove cve.yml and NVDCVE_API_KEY
This yml fragment wasn't actually used by our CI, and the cve-check class
no longer exists.

Signed-off-by: Ross Burton <ross.burton@arm.com>
2026-06-22 10:50:37 +01:00
Michael Safwat d3b55902fb arm-bsp/docs: corstone1000-a320: Add standalone A320 documentation
Add a separate Corstone-1000 Armv9-A Edge-AI documentation
set for the Cortex-A320 platform.

Populate the new documentation tree with the initial index,
user guide, software architecture, release notes, change log,
and supporting images.

Keep common Corstone-1000 material in the existing documentation
set and move A320-specific content into the new standalone
document set.

Signed-off-by: Michael Safwat <michael.safwat@arm.com>
Signed-off-by: Lisa Durbin <lisa.durbin@arm.com>
Signed-off-by: Alex Chapman <alex.chapman@arm.com>
Signed-off-by: Hugues KAMBA MPIANA <hugues.kambampiana@arm.com>
2026-05-28 09:51:15 -04:00
Michael Safwat 31dd0e8a89 arm-bsp/docs: corstone1000: Drop A320 content from base documentation
Remove Cortex-A320-specific content from the base Corstone-1000
documentation.

Drop the A320-only sections, commands, notes, and subsystem image from
the shared Corstone-1000 software architecture and user guide now that
the platform is documented in its own standalone document set.

Signed-off-by: Michael Safwat <michael.safwat@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2026-05-18 15:00:18 -04:00
Hugues KAMBA MPIANA d73bc7bea7 ci: Add Corstone-1000 with Cortex-A320 builds
Add CI coverage for the Corstone-1000 with Cortex-A320 FVP machine.

Build the Corstone-1000 with Cortex-A320 FVP with the firmware-only
configuration and run both `none` and `tftf`.
Also run `none` for the no-firmware build.

Signed-off-by: Alex Chapman <alex.chapman@arm.com>
Signed-off-by: Hugues KAMBA MPIANA <hugues.kambampiana@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2026-05-18 15:00:18 -04:00
Alex Chapman 9b00ce191c arm-bsp:corstone1000: Create a standalone corstone1000-a320-fvp machine
Add `corstone1000-a320-fvp` as a dedicated machine instead of enabling
the Cortex-A320 variant through a kas overlay on `corstone1000-fvp`.

Move the A320-specific machine features, overrides, FVP executable
selection, and Ethos-U85 configuration into the new machine
configuration. Keep the generic `corstone1000-fvp` machine focused on
the base FVP platform.

Update the A320 kas to use `corstone1000-a320-fvp` directly, and
allow pregenerated SSH host keys for the new virtual machine.

Signed-off-by: Alex Chapman <alex.chapman@arm.com>
Signed-off-by: Hugues KAMBA MPIANA <hugues.kambampiana@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2026-05-18 15:00:18 -04:00
Alex Chapman cd1a545618 arm-bsp/docs,kas:corstone1000: Add SSH image build support
Add a shared Corstone-1000 kas configuration for building SSH-enabled
mass storage images across the supported Corstone-1000 machines.

Enable Dropbear SSH in the mass storage OS image, add pregenerated SSH
host keys for FVP builds, and document the SSH image build flow in the
user guides.

SSH support is too large for the flash OS image, so provide a dedicated
`core-image-minimal` kas configuration for SSH-enabled mass storage
images instead.

Signed-off-by: Alex Chapman <alex.chapman@arm.com>
Signed-off-by: Hugues KAMBA MPIANA <hugues.kambampiana@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2026-05-18 15:00:18 -04:00
Alex Chapman b58ffc3a09 arm-bsp/tf-a: corstone1000: Fix Cortex-A320 errata override
Fix the Corstone-1000 with Cortex-A320 override for the
Trusted Firmware-A errata list.
The override was misspelled as
`ENABLE_CORTEX_A35_ERRATA:cortexta320` instead of
`ENABLE_CORTEX_A35_ERRATA:cortexa320`.

Rename the list to `ENABLE_CORTEX_A_ERRATA`, since it is shared by
the Cortex-A35 and Cortex-A320 variants.

Signed-off-by: Alex Chapman <alex.chapman@arm.com>
Signed-off-by: Hugues KAMBA MPIANA <hugues.kambampiana@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2026-05-18 15:00:18 -04:00
Jon Mason 052c2cf333 CI: use wrynose branches
Signed-off-by: Jon Mason <jon.mason@arm.com>
2026-04-29 11:26:18 -04:00
38 changed files with 2582 additions and 260 deletions
+24 -11
View File
@@ -9,14 +9,16 @@ variables:
CPU_REQUEST: ""
# The default machine tag for the build jobs
DEFAULT_TAG: ""
# The directory to use as the persistent cache (the root for DL_DIR, SSTATE_DIR, etc)
CACHE_DIR: $CI_BUILDS_DIR/persist
# The directory to use as the persistent cache (the root for DL_DIR,
# SSTATE_DIR, etc). The default is the build tree which will not be
# persistent, so this should be set in the runner.
CACHE_DIR: $CI_PROJECT_DIR
# The container mirror to use
MIRROR_GHCR: ghcr.io
# 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: ""
# Whether warnings should be fatal (0/1)
FATAL_WARNINGS: 0
stages:
- prep
@@ -61,13 +63,15 @@ stages:
# 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"
- |
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
if [ $FATAL_WARNINGS -ne 0 ]; then
./ci/check-warnings $KAS_BUILD_DIR/warnings.log
fi
kas shell ci/base.yml:lockfile.yml --command "$CI_PROJECT_DIR/ci/junit.sh $KAS_WORK_DIR/build"
artifacts:
name: "logs"
when: on_failure
@@ -156,6 +160,15 @@ corstone1000-mps3:
- FIRMWARE: none
SECUREDEBUG: [none, secure-debug]
corstone1000-a320-fvp:
extends: .build
parallel:
matrix:
- FIRMWARE: corstone1000-firmware-only
TESTING: [testimage, tftf]
- FIRMWARE: none
TESTING: testimage
documentation:
extends: .setup
script:
+2 -1
View File
@@ -7,11 +7,12 @@ distro: poky
defaults:
repos:
branch: master
branch: wrynose
repos:
bitbake:
url: https://git.openembedded.org/bitbake
branch: "2.18"
layers:
bitbake: disabled
@@ -2,8 +2,7 @@
header:
version: 14
includes:
- ci/corstone1000-fvp.yml
local_conf_header:
a320: |
MACHINE_FEATURES += "cortexa320"
OVERRIDES .= ":cortexa320"
machine: corstone1000-a320-fvp
-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
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"
# Ignore the kernel, we sometime carry kernels in meta-arm
CVE_CHECK_SHOW_WARNINGS:pn-linux-yocto = "0"
+22
View File
@@ -0,0 +1,22 @@
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-a320-fvp
+7 -3
View File
@@ -5,21 +5,25 @@ distro: poky
defaults:
repos:
branch: master
branch: wrynose
repos:
bitbake:
url: https://git.openembedded.org/bitbake
branch: "2.18"
commit: 22021758e66737bcf68dfd2b74adc6a0cb1d42d9
layers:
bitbake: disabled
core:
url: https://git.openembedded.org/openembedded-core
commit: 06dd66e6220e5ce4ed4b9af4d8231ae5f0a8ce80
layers:
meta:
meta-yocto:
url: https://git.yoctoproject.org/meta-yocto
commit: 8251bdad5fda780a000fb41e6eda82eadf0fa39e
layers:
meta-poky:
@@ -31,7 +35,7 @@ repos:
meta-openembedded:
url: https://git.openembedded.org/meta-openembedded
# commit: 461d85a1831318747af5abe86da193bcde3fd9b4
commit: 9af4488d46cb4fd4c0d2d64820c86225ebd6ac71
layers:
meta-oe:
meta-python:
@@ -39,7 +43,7 @@ repos:
meta-secure-core:
url: https://github.com/wind-river/meta-secure-core.git
# commit: 59d7e90542947c342098863b9998693ac79352b0
commit: 07a99ae241acd488a2feda1ededf87dc70dfde80
layers:
meta-secure-core-common:
meta-signing-key:
+13
View File
@@ -0,0 +1,13 @@
header:
version: 14
includes:
- ci/debug.yml
local_conf_header:
sshd: |
IMAGE_FEATURES += "ssh-server-dropbear"
fvp_sshkeys: |
CORE_IMAGE_EXTRA_INSTALL:append = " ssh-pregen-hostkeys"
target:
- core-image-minimal
@@ -0,0 +1,17 @@
#@TYPE: Machine
#@NAME: corstone1000-a320-fvp machine
#@DESCRIPTION: Machine configuration for Corstone1000 64-bit FVP with A320 CPU
require conf/machine/include/corstone1000-a320.inc
require conf/machine/corstone1000-fvp.conf
# Ethos-U85 FVP configuration
ETHOSU_NUM_MACS ?= "256"
FVP_CONFIG[host.ethosu.num_macs] = "${ETHOSU_NUM_MACS}"
# Reuse FVP recipe overrides
MACHINEOVERRIDES .= ":corstone1000-fvp"
# Override FVP executable provider and executable name.
FVP_PROVIDER:corstone1000-a320-fvp ??= "fvp-corstone1000-a320-native"
FVP_EXE:corstone1000-a320-fvp = "FVP_Corstone-1000-A320"
@@ -6,9 +6,6 @@ require conf/machine/include/corstone1000.inc
require ${@bb.utils.contains('MACHINE_FEATURES', 'corstone1000-extsys', \
'conf/machine/include/corstone1000-extsys.inc', '', d)}
require ${@bb.utils.contains('MACHINE_FEATURES', 'cortexa320', \
'conf/machine/include/corstone1000-a320.inc', '', d)}
TFA_TARGET_PLATFORM = "fvp"
TFM_PLATFORM_IS_FVP = "TRUE"
@@ -24,9 +21,7 @@ DEFAULT_TEST_SUITES:append = " fvp_boot fvp_devices"
# FVP Config
FVP_PROVIDER ?= "fvp-corstone1000-native"
FVP_PROVIDER:cortexa320 ?= "fvp-corstone1000-a320-native"
FVP_EXE ?= "FVP_Corstone-1000"
FVP_EXE:cortexa320 = "FVP_Corstone-1000-A320"
FVP_CONSOLES[default] = "host_terminal_0"
FVP_CONSOLES[tf-a] = "host_terminal_1"
FVP_CONSOLES[se] = "secenc_terminal"
@@ -1,3 +1,4 @@
ETHOSU_NUM_MACS ?= "256"
FVP_CONFIG[host.ethosu.num_macs] = "${ETHOSU_NUM_MACS}"
# Cortex-A320 variant of the Corstone-1000 platform.
MACHINEOVERRIDES =. "corstone1000-a320:"
MACHINE_FEATURES += "cortexa320"
OVERRIDES .= ":cortexa320"
@@ -0,0 +1,12 @@
version: 2
build:
os: "ubuntu-22.04"
tools:
python: "3.9"
sphinx:
configuration: meta-arm-bsp/documentation/corstone1000-a320/conf.py
formats:
- pdf
python:
install:
- requirements: meta-arm-bsp/documentation/requirements.txt
@@ -0,0 +1,117 @@
# SPDX-FileCopyrightText: <text>Copyright 2026 Arm Limited and/or its
# affiliates <open-source-office@arm.com></text>
#
# SPDX-License-Identifier: MIT
# Configuration file for the Sphinx documentation builder.
#
# This file only contains a selection of the most common options. For a full
# list see the documentation:
# https://www.sphinx-doc.org/en/master/usage/configuration.html
# -- Path setup --------------------------------------------------------------
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
#
# sys.path.insert(0, os.path.abspath('.'))
import os
import re
import sys
import yaml
# Append the documentation directory to the path, so we can import variables
sys.path.append(os.path.dirname(__file__))
_metadata_path = os.path.join(os.path.dirname(__file__), 'corstone-a320_metadata.yaml')
with open(_metadata_path, encoding='utf-8') as metadata_file:
_metadata = yaml.safe_load(metadata_file) or {}
_metadata_variables = {
item['name']: item['value']
for item in _metadata.get('variables', [])
if item.get('name') and item.get('value')
}
# -- Project information -----------------------------------------------------
project = 'Corstone-1000 Armv9-A Edge-AI'
copyright = '2026, Arm Limited'
author = 'Arm Limited'
# -- General configuration ---------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = [
'myst_parser',
'sphinx_rtd_theme',
]
source_suffix = {
'.rst': 'restructuredtext',
'.md': 'markdown',
}
myst_enable_extensions = [
'colon_fence',
]
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
# This pattern also affects html_static_path and html_extra_path.
exclude_patterns = [
'_build',
'Thumbs.db',
'.DS_Store',
'docs/infra',
'corstone-a320_map.md',
'corstone-a320_metadata.yaml',
]
# -- Options for HTML output -------------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
#
html_theme = 'sphinx_rtd_theme'
html_theme_options = {
'flyout_display': 'attached',
}
# Define the canonical URL if you are using a custom domain on Read the Docs
html_baseurl = os.environ.get("READTHEDOCS_CANONICAL_URL", "")
# Tell Jinja2 templates the build is running on Read the Docs
if os.environ.get("READTHEDOCS", "") == "True":
if "html_context" not in globals():
html_context = {}
html_context["READTHEDOCS"] = True
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
#html_static_path = ['_static']
def _replace_metadata_variables(app, docname, source):
source[0] = re.sub(
r'\$([A-Za-z0-9_]+)',
lambda match: _metadata_variables.get(match.group(1), match.group(0)),
source[0],
)
def setup(app):
app.connect('source-read', _replace_metadata_variables)
@@ -0,0 +1,6 @@
- topics/introducing.md
- topics/software-architecture.md
- topics/user-guide.md
- topics/tests.md
- topics/release-notes.md
- topics/change-log.md
@@ -0,0 +1,106 @@
---
title: Corstone-1000 with Cortex-A320
subtitle: ""
abstract: Arm Corstone-1000 with Cortex-A320 is a reference solution for IoT devices. It is part of Total Solution for IoT which consists of hardware and software reference implementation.
author: Arm
status: REL
keywords: [IoT, software]
bookpartno: 112000
product: Corstone-1000 with Cortex-A320
product_type: Open Source Projects
product_revision:
- prefix: Version
version: "0101"
version_label: "2026.02"
output_type: "software"
conformance_notice: "true"
content_type: User Guide
audience:
- Software Developers
categories:
- IoT
themes:
- IoT
intended_audience: Software Developers
terminology_review: new
releases:
- revision: 0100-01
date: 2026-05-01
change_summary: Update
permissions: nonconfidential
variables:
- name: arm_developer_cs1000_website
value: 'https://developer.arm.com/Tools%20and%20Software/Corstone-1000%20Software'
- name: arm_developer_cs1000_search
value: 'https://developer.arm.com/search#q=corstone-1000'
- name: arm_developer_mhu_website
value: 'https://developer.arm.com/documentation/ka005129/latest/#:~:text=An%20MHU%20is%20a%20device,that%20a%20message%20is%20available'
- name: arm_developer_secureboot_website
value: 'https://developer.arm.com/documentation/PRD29-GENC-009492/c/TrustZone-Software-Architecture/Booting-a-secure-system/Secure-boot'
- name: arm_architecture_security_features_platform_security
value: 'https://www.arm.com/architecture/security-features/platform-security'
- name: linux_repository
value: 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/'
- name: arm_trustzone_for_cortex_a_website
value: 'https://www.arm.com/technologies/trustzone-for-cortex-a'
- name: arm_fmw_framework_a_profile_pdf
value: 'https://developer.arm.com/documentation/den0077/latest'
- name: arm_fmw_framework_m_profile_pdf
value: 'https://developer.arm.com/architectures/Firmware%20Framework%20for%20M-Profile'
- name: platform_security_fwu_for_a_profile_pdf
value: 'https://developer.arm.com/documentation/den0118/a/'
- name: psa_firmware_update_ihi_0093_api_reference_website
value: 'https://arm-software.github.io/psa-api/fwu/1.0/api/api.html'
- name: edk2_capsule_generation_tool_repository
value: 'https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/Capsule/GenerateCapsule.py'
- name: psa_fwu_den0018_specification_website
value: 'https://developer.arm.com/documentation/den0118/latest/'
- name: ts_psa_fwu_service_website
value: 'https://trusted-services.readthedocs.io/en/stable/services/fwu/psa-fwu-m.html'
- name: tfm_shim_layer_website
value: 'https://trustedfirmware-m.readthedocs.io/en/latest/design_docs/services/tfm_fwu_service.html#shim-layer-between-fwu-and-bootloader'
- name: op_tee_os_repository
value: 'https://github.com/OP-TEE/optee_os'
- name: psa_certified_website
value: 'https://www.psacertified.org/'
- name: psa_l2_ready
value: 'https://www.psacertified.org/products/corstone-1000/'
- name: systemready_ir_certification
value: 'https://armkeil.blob.core.windows.net/developer/Files/pdf/certificate-list/arm-systemready-ve-arm-neoverse.pdf'
- name: trusted_board_boot_requirements_client_pdf
value: 'https://developer.arm.com/documentation/den0006/latest'
- name: trusted_firmware_m_website
value: 'https://www.trustedfirmware.org/projects/tf-m/'
- name: trusted_firmware_m_bl1_website
value: 'https://trustedfirmware-m.readthedocs.io/en/latest/design_docs/booting/bl1.html'
- name: trusted_firmware_a_bl2_website
value: 'https://developer.arm.com/documentation/108028/0000/RD-TC22-software/Software-components/AP-firmware/Trusted-firmware-A-BL2'
- name: trusted_firmware_a_fip_guide
value: 'https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html#firmware-image-package-fip'
- name: trusted_services_website
value: 'https://www.trustedfirmware.org/projects/trusted-services/'
- name: trusted_services_uefi_smm_website
value: 'https://trusted-services.readthedocs.io/en/integration/services/uefi-smm-services.html#'
- name: das_u_boot_repository
value: 'https://github.com/u-boot/u-boot.git'
- name: keil_rtx5_website
value: 'https://developer.arm.com/Tools%20and%20Software/Keil%20MDK/RTX5%20RTOS'
- name: ppa_website
value: 'https://developer.arm.com/documentation/102738/0100/Power--performance--and-area-analysis'
- name: mcuboot_website
value: 'https://docs.mcuboot.com/'
- name: arm_developer_fvp
value: 'https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps'
- name: secure_debug_manager_repo_readme
value: 'https://github.com/ARM-software/secure-debug-manager/tree/master?tab=readme-ov-file#secure-debug-manager-psa-adac--sdc-600'
- name: secure_debug_manager_armds_integration
value: 'https://github.com/ARM-software/secure-debug-manager?tab=readme-ov-file#arm-development-studio-integration'
- name: meta_arm_repository_release_branch
value: 'https://docs.yoctoproject.org/next/migration-guides/migration-6.0.html'
- name: arm_ulink_pro_website
value: 'https://www.arm.com/products/development-tools/debug-probes/ulink-pro'
- name: arm_ds_website
value: 'https://www.arm.com/products/development-tools/embedded-and-software/arm-development-studio'
- name: edk2_repository
value: 'https://github.com/tianocore/edk2'
Binary file not shown.

After

Width:  |  Height:  |  Size: 77 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 58 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 86 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 60 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 69 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 65 KiB

@@ -0,0 +1,12 @@
# Corstone-1000 Armv9-A Edge-AI
```{toctree}
:maxdepth: 2
topics/introducing
topics/software-architecture
topics/user-guide
topics/tests
topics/release-notes
topics/change-log
```
@@ -0,0 +1,150 @@
# Change log {.chapter permissions=non-confidential}
This document contains a summary of the new features, changes and fixes in each release of the Corstone-1000 with Cortex-A320 software stack.
## Version 2026.05 {.reference}
The following changes are present in this release:
- Continued Corstone-1000 with Cortex-A320 enablement across U-Boot, TF-A, TF-M, OP-TEE, and Linux with the split A320 device tree, GIC-700 support, Ethos-U85 DT alignment, and NPU reset via the external-system controller.
- Enabled and documented FVP SMP builds and platform-agnostic multicore support, including the errata override fixes for Corstone-1000 with Cortex-A320 and removal of the reboot workaround note.
- Split Corstone-1000 with Cortex-A320 FVP support into a dedicated machine configuration and standalone documentation.
### Corstone-1000 with Cortex-A320 components versions {.reference}
The following component versions are available:
Table: Corstone-1000 with Cortex-A320 component versions
+----------------------------------------+-----------------------------------+
| Component | Version |
+========================================+===================================+
| linux-yocto | 6.19 |
+----------------------------------------+-----------------------------------+
| u-boot | 2025.10 |
+----------------------------------------+-----------------------------------+
| external-system | 0.1.0 |
+----------------------------------------+-----------------------------------+
| optee-client | 4.9.0 |
+----------------------------------------+-----------------------------------+
| optee-os | 4.9.0 |
+----------------------------------------+-----------------------------------+
| trusted-firmware-a | 2.14.1 |
+----------------------------------------+-----------------------------------+
| trusted-firmware-m | 2.2.2 |
+----------------------------------------+-----------------------------------+
| libts | v1.3.0 |
+----------------------------------------+-----------------------------------+
| ts-sp-{se-proxy, smm-gateway} | v1.3.0 |
+----------------------------------------+-----------------------------------+
| ts-psa-{crypto, iat, its. ps}-api-test | 74dc6646ff |
+----------------------------------------+-----------------------------------+
### Yocto distribution components versions {.reference}
The following Yocto distribution components versions are available:
Table: Yocto distribution component versions
+-------------------+------------+
| Component | Version |
+===================+============+
| meta-arm | wrynose |
+-------------------+------------+
| bitbake | 22021758e6 |
+-------------------+------------+
| meta-openembedded | 9af4488d46 |
+-------------------+------------+
| openembedded-core | 06dd66e622 |
+-------------------+------------+
| meta-yocto | 8251bdad5f |
+-------------------+------------+
| meta-secure-core | 07a99ae241 |
+-------------------+------------+
| busybox | 1.37.0 |
+-------------------+------------+
| musl | 1.2.6 |
+-------------------+------------+
| gcc-arm-none-eabi | 15.2.rel1 |
+-------------------+------------+
| gcc-cross-aarch64 | 15.2.0 |
+-------------------+------------+
| openssl | 3.5.6 |
+-------------------+------------+
## Version 2025.12 {.reference}
The following changes are present in this release:
- Delivered end-to-end Cortex-A320 enablement across U-Boot, TF-A, TF-M, OP-TEE, Yocto machine layers, and documentation, including device-tree updates, MPIDR handling, and FVP model renaming.
- Rolled out the PSA Firmware Update (DEN0118) pipeline: U-Boot capsule parsing, Bootloader Abstraction Layer in TF-M, ESRT exposure, and Trusted Services IPC bridges replacing legacy capsule code.
- Hardened the new firmware update flow with EFI self-tests, metadata restructuring for partial and multi-image acceptance, and RSE-COMMS gating refinements.
- Upgraded key firmware components (TF-A 2.13.0, TF-M 2.2.1, Trusted Services 1.2.0, OP-TEE OS 4.7.0) and introduced targeted test skips plus integer-only build modes to keep validation green.
- Cleaned and renumbered downstream patch series across Trusted Services and TF-M while removing obsolete integrations to align with upstream baselines.
- Refreshed release material and architecture guides to describe the A320 profile, PSA FWU behavior, and updated software stack.
- Added KAS profiles, machine includes, and automated FVP selection logic to streamline developer workflows for the refreshed platform configuration.
### Corstone-1000 with Cortex-A320 components versions {.reference}
The following component versions are available:
Table: Corstone-1000 with Cortex-A320 component versions
+----------------------------------------+-----------------------------------+
| Component | Version |
+========================================+===================================+
| linux-yocto | 6.12.60 |
+----------------------------------------+-----------------------------------+
| u-boot | 2025.04 |
+----------------------------------------+-----------------------------------+
| optee-client | 4.7.0 |
+----------------------------------------+-----------------------------------+
| optee-os | 4.7.0 |
+----------------------------------------+-----------------------------------+
| trusted-firmware-a | 2.13.0 |
+----------------------------------------+-----------------------------------+
| trusted-firmware-m | 2.2.1 |
+----------------------------------------+-----------------------------------+
| libts | v1.2.0 |
+----------------------------------------+-----------------------------------+
| ts-sp-{se-proxy, smm-gateway} | v1.2.0 |
+----------------------------------------+-----------------------------------+
| ts-psa-{crypto, iat, its. ps}-api-test | 74dc6646ff |
+----------------------------------------+-----------------------------------+
### Yocto distribution components versions {.reference}
The following Yocto distribution components versions are available:
Table: Yocto distribution component versions
+-------------------+------------+
| Component | Version |
+===================+============+
| meta-arm | whinlatter |
+-------------------+------------+
| bitbake | 0dde1a3ff8 |
+-------------------+------------+
| meta-openembedded | fc0152e434 |
+-------------------+------------+
| openembedded-core | 4bd920ad7d |
+-------------------+------------+
| meta-yocto | b3b6592635 |
+-------------------+------------+
| meta-secure-core | 63209fb150 |
+-------------------+------------+
| meta-ethos | aa2504a32f |
+-------------------+------------+
| meta-sca | e68f1a9d17 |
+-------------------+------------+
| busybox | 1.37.0 |
+-------------------+------------+
| musl | 1.2.5 |
+-------------------+------------+
| gcc-arm-none-eabi | 13.3.rel1 |
+-------------------+------------+
| gcc-cross-aarch64 | 15.2.0 |
+-------------------+------------+
| openssl | 3.5.4 |
+-------------------+------------+
@@ -0,0 +1,14 @@
# Introduction {.chapter permissions=non-confidential}
Arm Corstone-1000 with Cortex-A320 is a reference solution for IoT devices
based on Arm Corstone-1000, but with Cortex-A320 CPU, Ethos-U85 NPU and
GIC700 (Generic Interrupt Controller). It is part of Total Solution
for IoT which consists of hardware and software reference implementations.
## Disclaimer {.reference}
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.
@@ -0,0 +1,40 @@
# Release notes {.chapter permissions=non-confidential}
You expressly assume all liabilities and risks relating to your use or operation
of your software and hardware designed or modified using the Arm Tools,
including without limitation, your software or hardware designed or
intended for safety-critical applications. Should your software or hardware
prove defective, you assume the entire cost of all necessary servicing, repair
or correction.
## Release notes - 2026.05 {.reference}
The following knowns issues and limitations are present in this release:
- Crypto isolation is not supported in the Secure world of Corstone-1000. Additionally, clients in
the Normal world are not isolated from one another. Therefore, if an end user wants to add a new
Secure Partition (SP) (such as a software TPM) that accesses the Crypto service via the SE-Proxy,
they are responsible for implementing their own isolation mechanisms to ensure proper security boundaries.
- DSTREAM debug probe may experience unreliable USB connectivity when used with Arm DS for secure debug.
This issue is under active investigation, and we are working to identify and resolve compatibility issues in a future update.
As a more stable alternative, the ULINKpro debug probe is recommended for use with Corstone-1000 in secure debug scenarios.
## Release notes - 2025.12 {.reference}
The following knowns issues and limitations are present in this release:
- Corstone-1000 with Cortex-A320 FVP does not currently support Symmetric Multiprocessing
- Corstone-1000 with Cortex-A320 FVP becomes unresponsive when the Linux kernel driver for the Ethos-U85 NPU loads automatically after a software reboot.
- Crypto isolation is not supported in the Secure world of Corstone-1000. Additionally, clients in
the Normal world are not isolated from one another. Therefore, if an end user wants to add a new
Secure Partition (SP) (such as a software TPM) that accesses the Crypto service via the SE-Proxy,
they are responsible for implementing their own isolation mechanisms to ensure proper security boundaries.
- DSTREAM debug probe may experience unreliable USB connectivity when used with Arm DS for secure debug.
This issue is under active investigation, and we are working to identify and resolve compatibility issues in a future update.
As a more stable alternative, the ULINKpro debug probe is recommended for use with Corstone-1000 in secure debug scenarios.
## Support {.reference}
For technical support, email [Arm subsystem support](mailto:support-subsystem-iot@arm.com).
For security issues, contact [Arm Security](mailto:psirt@arm.com).
@@ -0,0 +1,311 @@
# Software architecture {.chapter permissions=non-confidential}
The combination of Corstone-1000 software and hardware reference solution is [PSA Level-2 ready certified]($psa_l2_ready) as well as [Arm SystemReady Devicetree certified]($systemready_ir_certification). Please rely on the Corstone-1000 platform for certification needs.
More information on the Corstone-1000 subsystems product(s), variants and design can be
found on [Arm Developer]($arm_developer_cs1000_website).
This document explicitly focuses on the software part of the solution and
provides internal details on the software components. The reference
software package of the platform can be retrieved following instructions
present in the user guide document.
## Design overview {.reference}
This variant of the Corstone-1000 platform replaces the Host System's Cortex-A35
processor with a Cortex-A320. In this configuration, the optional External System
(previously a Cortex-M3) is replaced by an Arm Ethos-U85 Neural Processing Unit (NPU).
The Ethos-U85 runs in the direct drive configuration, where the Host System is
responsible for managing the NPU directly.
![Cortex-A320 subsystems](../images/CorstoneA320Subsystems.png)
## Secure boot chain {.reference}
For the security of a device, it is essential that only authorized
software should run on the device.
The Corstone-1000 boot uses a [Secure boot]($arm_developer_secureboot_website) chain process
where an already authenticated image verifies and loads the following software in the chain.
For the boot chain process to work, the start of the chain should be trusted, forming the
Root of Trust (RoT) of the device. The RoT of the device is immutable in
nature and encoded into the device by the device manufacturer before it
is deployed into the field.
In Corstone-1000, the content of the ROM and CC312 One Time Programmable (OTP) memory forms the RoT.
Verification of an image can happen either by comparing the computed and stored hashes, or by
checking the signature of the image if the image is signed.
![Secure boot chain](../images/SecureBootChain.png)
It is a lengthy chain to boot the software on Corstone-1000.
### TF-M BL1\_1 {.reference}
On power-up, the Secure Enclave begins execution from TF-M BL1\_1, which resides in ROM and serves as
the Root of Trust (RoT) for the device.
TF-M BL1\_1 is the immutable bootloader and is responsible for:
- Provisioning the device during the first boot
- Performing hardware initialization
- Verifying the integrity and authenticity of the next stage in the boot chain
At boot time, TF-M BL1\_1:
- Copies the TF-M BL1\_2 image from OTP to RAM.
- Verifies the integrity of BL1\_2 by comparing its computed hash with the hash stored in OTP.
### TF-M BL1\_2 {.reference}
During provisioning, the TF-M BL1\_2 binary, along with its hashes and cryptographic keys, is stored
in One-Time Programmable (OTP) memory.
Once verified, TF-M BL1\_2:
- Takes control and verifies the next stage in the boot chain, which is TF-M BL2.
- Computes the hash of the BL2 image and compares it with the BL2 hash stored in OTP to ensure
integrity before transferring execution to BL2.
The TF-M BL1 design details can be found in the [TF-M design documents]($trusted_firmware_m_bl1_website).
:::note
Corstone-1000 has some differences compared to this design due to memory (OTP/ROM) limitations:
- BL1\_1 code size is larger than needed because it handles most of the hardware initialization instead of the BL1\_2.
- BL1\_2 cannot be updated during provisioning time because the provisioning bundle that contains its code is located in the ROM.
- BL1\_2 does not use the post-quantum LMS verification.
- BL2 cannot be updated because it is verified by comparing the computed hash to the hash stored in the OTP.
:::
### TF-M BL2 {.reference}
In this system, TF-M BL2 refers to MCUBoot.
On the first boot, MCUBoot can provision additional cryptographic keys. It is responsible for authenticating both:
- TF-M (Trusted Firmware-M), and
- The initial bootloader of the Host system, [Trusted Firmware-A (TF-A) BL2]($trusted_firmware_a_bl2_website)
This authentication is done by verifying the digital signatures of the respective images.
MCUBoot performs image verification in the following steps:
1. Load the image from non-volatile memory into RAM.
2. Validate the image's signature using the corresponding public key.
:::note
The public key present in the image header is validated by comparing with the hash. Depending on the image, the hash of the public key is either stored in the OTP or part of the software which is being already verified in the previous stages.
:::
The execution control is passed to TF-M after the verification.
As the runtime executable of the Secure Enclave, TF-M initializes itself before
bringing the Host system out of reset.
### Host system authentication {.reference}
The Host system follows the boot standard defined in [Trusted Board Boot Requirements Client]($trusted_board_boot_requirements_client_pdf)
to authenticate the Secure and Non-secure software.
The [Firmware Image Package (FIP)]($trusted_firmware_a_fip_guide) packs bootloader images and
other payloads into a single archive.
![FIPDiagram](../images/FIPDiagram.png)
The FIP for Corstone-1000 contains:
- Trusted firmware-A BL2
- AP EL3 Runtime firmware, BL31 image
- AP Secure Payload, BL32 image
- AP Normal world firmware -U-boot, BL33 image
- Trusted OS Firmware configuration file used by Trusted OS (BL32), TOS_FW_CONFIG
- Key certificates
- Content certificates
To load and validate TF-A BL2, TF-M BL2 first parses the GUID Partition Table (GPT)
to locate the FIP. It then determines the offset of TF-A BL2 within the FIP.
:::note
TF-M does not check the FIP signature, it only checks the TF-A BL2's signature in the FIP.
:::
The implicitly trusted components are:
- A SHA-256 hash of the Root of Trust Public Key (ROTPK.) For development purposes, a development ROTPK is used and its hash embedded into the TF-A BL2 image. This public key is provided by the TF-A source code.
- TF-A BL2 image - it can be trusted because it has been verified by TF-M BL2 before starting TF-A.
The remaining components in the Chain of Trust (CoT) are either certificates or bootloader images.
#### Bootloader authentication {.reference}
The FIP contains two types of certificates:
- Content Certificates used to store the hash of a bootloader image.
- Key Certificates used to verify public keys used to sign Content Certificates.
The Host system bootloader images are authenticated by computing their hash and comparing it to the corresponding hash found in the Content Certificate.
#### Certificates verification {.reference}
The public keys defined in the Trusted Key Certificate are used to verify the later certificates in
the CoT process. The Trusted Key Certificate is verified with the Root of Trust Public Key.
#### UEFI authenticated variables {.reference}
For UEFI Secure Boot, authenticated variables can be accessed from the secure flash.
The feature has been integrated in U-Boot, which authenticates the images as per the UEFI
specification before executing them.
## Secure services {.reference}
Corstone-1000 is unique in offering a secure environment for running trusted workloads.
While the Host system includes TrustZone technology, the platform also features a hardware-isolated
Secure Enclave, specifically designed to execute these secure workloads.
In Corstone-1000, essential Secure Services—such as Cryptography, Protected Storage,
Internal Trusted Storage, and Attestation—are provided through PSA Functional APIs implemented in TF-M.
From the user's perspective, there is no difference when communicating with these services,
whether they run in the Secure Enclave or in the Secure world of the Host system.
The diagram below illustrates the data flow for such calls.
![Secure services](../images/SecureServices.png)
The Secure Enclave Proxy Secure Partition (SE Proxy SP) is a proxy managed by OP-TEE that forwards
Secure Service calls to the Secure Enclave. This communication uses the
[RSE communication protocol](https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html).
While the protocol supports shared memory and MHU interrupts as a doorbell mechanism between cores,
in Corstone-1000, the entire message is currently transmitted through the MHU channels.
Corstone-1000 implements Isolation Level 2 using the Cortex-M0+ Memory Protection Unit (MPU).
Users can define their own secure services to run either in the Host system's Secure World or in
the Secure Enclave. This choice involves a trade-off between latency and security.
Services running in the Secure Enclave benefit from strong, hardware-enforced isolation,
offering higher security but at the cost of increased latency. In contrast, services running in the
Host Secure World experience lower latency, but rely on TrustZone technology for virtualized isolation,
which offers comparatively less robust security.
## PSA secure firmware update {.reference}
The Corstone-1000 platform necessitates a robust, secure, and flexible firmware update mechanism
including partial capsule update to ensure fielded devices can receive critical patches, feature enhancements,
and security fixes without compromising system integrity. To meet these requirements, we have implemented the
Platform Security Architecture (PSA) Firmware Update (FWU) framework on Corstone-1000, leveraging Trusted Firmware-M (TF-M)
for the Secure Enclave, U-Boot as the host-side client on Cortex-A, and the UEFI capsule update mechanism for payload
encapsulation. This design supports the Fixed Virtual Platform (FVP) target, providing consistent behavior across
simulation-based deployments. The Corstone-1000 supports FWU
which complies with the
[Platform Security Firmware Update for the A-profile Arm Architecture]($platform_security_fwu_for_a_profile_pdf)
and [PSA Firmware Update IHI 0093]($psa_firmware_update_ihi_0093_api_reference_website)
specifications.
To standardize and streamline capsule creation with multiple FMP payloads, the
[EDK2 capsule generation tool]($edk2_capsule_generation_tool_repository)
tool has been integrated into the meta-arm Yocto layer for Corstone-1000. This integration involves defining
build rules for generating UEFI capsules as part of the firmware image build process. Configuration parameters
exposed in the recipe allow developers to specify the number of FMP payloads, target image GUIDs, version numbers etc.
This capsule ensures that all update payloads conform to the UEFI FMP specification and are ready for
validation and delivery by UBoot.
The FWU solution for Corstone-1000 is composed of three primary domains:
- Host System
- Trusted Services intermediary
- Secure Enclave
Each domain has distinct responsibilities and communicates through standardized interfaces.
![System architecture PSA firmware update](../images/SystemArchitecturePSAFirmwareUpdate.png)
On the host side, U-Boot functions as the FWU client and orchestrates the update process from capsule retrieval to
payload delivery based on [PSA FWU DEN0018 specification]($psa_fwu_den0018_specification_website)
via Arm FF-A framework. The Trusted-Services SE Proxy secure partition serves as a gateway between the non-secure host
environment and the Secure Enclave. The [PSA FWU service]($ts_psa_fwu_service_website) running in the Trusted Services
implementation forwards the data to the Secure Enclave via MHU-based PSA calls. Within the Secure Enclave, the PSA FWU
Agent, conforming to [PSA Firmware Update IHI 0093]($psa_firmware_update_ihi_0093_api_reference_website) specification,
orchestrates the actual flash programming, metadata management, and rollback protection mechanisms. The agent relies on a
bespoke [shim layer]($tfm_shim_layer_website) to abstract hardwarespecific flash operations and bootloader interactions.
As defined in the specification, the external flash is divided into two banks: one bank holds the
currently running images, while the other is used to stage new images.
There are four updatable components: **BL2**, **TF-M**, **the FIP** and **the Kernel Image** (the initramfs bundle).
New images are delivered and accepted in the form of UEFI capsules.
![External flash](../images/ExternalFlash.png)
When a FWU is initiated on Corstone-1000, the following sequence of operations takes place:
1. Capsule Retrieval and Preparation
U-Boot on the host system retrieves the firmware capsule.
It validates the capsule header and parses the FMP (Firmware Management Protocol) descriptor list to identify the payloads to be updated.
For each FMP descriptor, U-Boot:
Splits the firmware payload into 4 KiB chunks.
Invokes the PSA_FWU_Update API for each chunk, transmitting the buffer address via the FF-A (Firmware Framework for Arm) shared memory interface.
2. Secure Transmission and Forwarding
The PSA Firmware Update (FWU) service, running as part of Trusted Services, receives the chunks through Secure Partition Client (SPC) calls.
It forwards these chunks to the Secure Enclave using MHU-based PSA calls.
3. Flashing Within the Secure Enclave
Inside the Secure Enclave, the PSA FWU Agent dispatches each chunk to the shim layer.
The shim layer:
Erases the corresponding sectors in the non-active flash bank.
Writes the received firmware chunks at the correct offsets.
During partial updates, it also copies static partitions from the active bank to the non-active one to maintain consistency.
4. Finalization and Boot Preparation
After all chunks are successfully written:
The shim updates the firmware manifest and the EFI System Resource Table (ESRT) entries to reflect the new image version.
This step enables the bootloader to recognize the new firmware for a trial boot.
The platform then performs an automatic reset, booting into the non-active bank in trial mode.
5. Trial Boot and Confirmation
In trial mode, U-Boot evaluates the new firmware and issues either an accept or reject command using the PSA FWU ABI.
These commands are sent to the Secure Enclave, instructing the shim to update the firmware metadata accordingly.
6. Recovery and Fallback Mechanism
If the trial boot is successful, the host sends an acknowledgment, transitioning the firmware state from 'trial' to 'regular'.
If the system fails or becomes unresponsive:
A watchdog timer triggers a system reset.
The BL1 firmware in the Secure Enclave detects repeated failures and reverts to the previously known-good flash bank.
This rollback mechanism ensures the device remains operational and recoverable, even after a failed update.
![Secure firmware update](../images/SecureFirmwareUpdate.png)
## UEFI runtime support in U-Boot {.reference}
The implementation of UEFI boot-time and runtime APIs requires persistent variable storage. In
Corstone-1000, UEFI variables are stored using the Protected Storage (PS) service.
The diagram below illustrates the data flow for storing UEFI variables. U-Boot's UEFI subsystem
communicates with the Secure World using the U-Boot FF-A driver, which interfaces with the
[UEFI System Management Mode (SMM) service]($trusted_services_uefi_smm_website).
The SMM service provides support for the UEFI System Management Mode. This support is implemented by the SMM Gateway secure partition.
The SMM service then uses the Proxy Protected Storage (PS) provided by the SE Proxy SP.
These PS calls are forwarded to the Secure Enclave, following the communication path described earlier.
![UEFI runtime support flow](../images/UEFISupport.png)
## References {.reference}
For more information, see:
- [Arm Developer]($arm_developer_cs1000_search)
- [Arm Security Architectures]($arm_architecture_security_features_platform_security)
File diff suppressed because it is too large Load Diff
@@ -0,0 +1,265 @@
# Build, flash and run {.chapter permissions=non-confidential}
The Arm Corstone-1000 with Cortex-A320 software stack uses the Yocto Project to build a tiny Linux distribution suitable for the Arm Corstone-1000 with Cortex-A320 platform (kernel and initramfs filesystem less than 6 MB on the flash).
The Corstone-1000 with Cortex-A320 software stack can be run on [Arm Corstone-1000 with Cortex-A320 FVP (Fixed Virtual Platform)](https://developer.arm.com/downloads/-/arm-ecosystem-fvps) and is built on top of Yocto Project's [Wrynose release]($meta_arm_repository_release_branch).
The Yocto Project relies on the [BitBake](https://docs.yoctoproject.org/bitbake.html#bitbake-documentation) tool as its build tool. Please see the [Yocto Project documentation](https://docs.yoctoproject.org/) for more information.
## Prerequisites {.reference}
This guide assumes that your host machine is running Ubuntu 24.04 LTS (with `sudo` rights), with at least
32GB of free disk space and 16GB of RAM as minimum requirement.
The following prerequisites must be available on the host system:
- Git 2.39.2 or greater.
- Python 3.11.2 or greater.
- GNU Tar 1.34 or greater.
- GNU Compiler Collection 12.2 or greater.
- GNU Make 4.3 or greater.
- tmux 3.3 or greater.
Please follow the steps described in the Yocto mega manual:
- [Compatible Linux Distribution](https://docs.yoctoproject.org/singleindex.html#compatible-linux-distribution)
- [Build Host Packages](https://docs.yoctoproject.org/singleindex.html#build-host-packages)
## Software components {.reference}
Within the Yocto Project, each component included in the Corstone-1000 with Cortex-A320 software stack is specified as
a [BitBake recipe](https://docs.yoctoproject.org/bitbake/2.2/bitbake-user-manual/bitbake-user-manual-intro.html#recipes).
The recipes specific to the Corstone-1000 with Cortex-A320 BSP are located at:
`${WORKSPACE}/meta-arm/meta-arm-bsp/`.
`${WORKSPACE}` refers to the absolute path to your workspace where the `meta-arm` repository will be cloned. Consider exporting it (e.g., `export WORKSPACE=$(realpath .)`) if you're already in the workspace directory,
so you can copy and paste the commands from this guide verbatim.
The Yocto machine config files are at:
- `${WORKSPACE}/meta-arm/meta-arm-bsp/conf/machine/include/corstone1000-a320.inc`
- `${WORKSPACE}/meta-arm/meta-arm-bsp/conf/machine/corstone1000-a320-fvp.conf`
:::note
All the paths stated in this document are absolute paths.
:::
### Host processor components {.reference}
This section describes the components used in the host processor.
#### Trusted Firmware-A {.reference}
The following [Trusted Firmware-A](https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git) components are used:
Table: Trusted Firmware-A components
| Type | Path |
| --------- | ---------------------------------------------------------------------------------------------------------------- |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.14.1.bb` |
#### Trusted Services {.reference}
The following [Trusted Services](https://trusted-services.readthedocs.io/en/latest/index.html) components are used:
Table: Trusted Services components
| Type | Path |
| --------- | ---------------------------------------------------------------------------------------------------------------- |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/libts_%.bbappend` |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-crypto-api-test_%.bbappend` |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-iat-api-test_%.bbappend` |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-its-api-test_%.bbappend` |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-ps-api-test_%.bbappend` |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-sp-se-proxy_%.bbappend` |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-sp-smm-gateway_%.bbappend` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/libts_git.bb` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-crypto-api-test_git.bb` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-iat-api-test_git.bb` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-its-api-test_git.bb` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-ps-api-test_git.bb` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-sp-smm-gateway_git.bb` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-sp-se-proxy_git.bb` |
#### OP-TEE {.reference}
The following [OP-TEE](https://git.trustedfirmware.org/OP-TEE/optee_os.git) components are used:
Table: OP-TEE components
| Type | Path |
| --------- | ---------------------------------------------------------------------------------------------------------------- |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/optee/optee-os_%.bbappend` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm/recipes-security/optee/optee-os_4.9.0.bb` |
#### U-Boot {.reference}
The following [U-Boot](https://github.com/u-boot/u-boot.git) components are used:
Table: U-Boot components
| Type | Path |
| --------- | ---------------------------------------------------------------------------------------------------------------- |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/u-boot/u-boot_%.bbappend` |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_%.bbappend` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_2025.10.bb` |
#### Linux {.reference}
The distribution is based on the [Poky](https://docs.yoctoproject.org/ref-manual/terms.html#term-Poky)
distribution which is a Linux distribution stripped down to a minimal configuration.
The provided distribution is based on [BusyBox](https://www.busybox.net/) and built using [musl libc](https://musl.libc.org/).
The following Linux components are used:
Table: Linux components
| Type | Path |
| --------- | ---------------------------------------------------------------------------------------------------------------- |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-kernel/linux/linux-yocto_%.bbappend` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-kernel/linux/linux-yocto_6.19.bb` |
| defconfig | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-kernel/linux/files/corstone1000/defconfig` |
### Secure enclave components {.reference}
This section describes the secure enclave components.
#### Trusted Firmware-M {.reference}
The following [Trusted Firmware-M](https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git) are used:
Table: Trusted Firmware-M secure enclave components
| Type | Path |
| --------- | ---------------------------------------------------------------------------------------------------------------- |
| bbappend | `${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-m/trusted-firmware-m_%.bbappend` |
| Recipe | `${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_2.2.2.bb` |
## Build {.reference}
To build the software stack, do the following:
:::note
Building binaries natively on Windows and AArch64 Linux is not supported. Use an Intel or AMD 64-bit architecture Linux based development machine to build the software stack and transfer the binaries to run the software stack on an FVP in Windows or AArch64 Linux if required.
:::
1. Create a new folder that will be your workspace:
```
mkdir ${WORKSPACE}
cd ${WORKSPACE}
```
2. Install kas version 4.4 with `sudo` rights:
```
sudo pip3 install kas==4.4
```
Ensure the kas installation directory is visible on the `$PATH` environment variable.
3. Clone the `meta-arm` Yocto layer in the workspace `${WORKSPACE}`.
```
cd ${WORKSPACE}
git clone https://git.yoctoproject.org/git/meta-arm -b CORSTONE1000-2026.05
```
4. Accept the EULA on the [Arm Developer](https://developer.arm.com/downloads/-/arm-ecosystem-fvps/eula) site to build a Corstone-1000 with Cortex-A320 image for FVP as follows:
```
export ARM_FVP_EULA_ACCEPT="True"
```
5. Build a Corstone-1000 with Cortex-A320 image:
```
kas build meta-arm/kas/corstone1000-a320-fvp.yml:meta-arm/ci/debug.yml
```
A clean build takes a significant amount of time given that all of the development machine utilities are also
built along with the target images. Those development machine utilities include executables (Python,
CMake, etc.) and the required toolchains.
Once the build succeeds, all output binaries will be placed in `${WORKSPACE}/build/tmp/deploy/images/corstone1000-a320-fvp/`.
Everything apart from the Secure Enclave ROM firmware is bundled into a single binary, the
`corstone1000-flash-firmware-image-corstone1000-a320-fvp.wic` file.
The output binaries run in the Corstone-1000 with Cortex-A320 platform are the following:
- The Secure Enclave ROM firmware: `${WORKSPACE}/build/tmp/deploy/images/corstone1000-a320-fvp/trusted-firmware-m/bl1.bin`
- The internal firmware flash image: `${WORKSPACE}/build/tmp/deploy/images/corstone1000-a320-fvp/corstone1000-flash-firmware-image-corstone1000-a320-fvp.wic`
## Build with SSH {.reference}
The `meta-arm/kas/corstone1000-a320-fvp.yml` build produces an image for booting from flash.
To build a bootable mass storage OS image with Dropbear SSH enabled, run:
```
kas build meta-arm/ci/corstone1000-a320-fvp.yml:meta-arm/kas/corstone1000-ssh.yml
```
The mass storage OS image can be found at `${WORKSPACE}/build/tmp/deploy/images/corstone1000-a320-fvp/core-image-minimal-corstone1000-a320-fvp.wic`
:::note
The generated `core-image-minimal-corstone1000-a320-fvp.fvpconf` attaches the mass storage OS image to `board.msd_mmc.p_mmc_file`.
:::
## Run {.reference}
Once the platform is turned ON, the Secure Enclave will start to boot, wherein the relevant memory contents of the `*.wic`
file are copied to their respective memory locations. Firewall policies are enforced
on memories and peripherals before bringing the Host Processor out of reset.
The Host Processor will boot TrustedFirmware-A, OP-TEE, U-Boot and then Linux before presenting a login prompt.
A Fixed Virtual Platform (FVP) model of the Corstone-1000 with Cortex-A320 platform must be available to run the
Corstone-1000 with Cortex-A320 FVP software image.
A Yocto recipe is provided to download the latest supported FVP version.
The recipe is located at `${WORKSPACE}/meta-arm/meta-arm/recipes-devtools/fvp/fvp-corstone1000-a320.bb`.
The latest FVP version is `11.31.cs1000_a320_2` for Corstone-1000 with Cortex-A320, and the model is automatically downloaded and installed when using the `runfvp` command as follows:
```
kas shell meta-arm/kas/corstone1000-a320-fvp.yml:meta-arm/ci/debug.yml \
-c "../meta-arm/scripts/runfvp -- --version"
```
The FVP can also be manually downloaded from [Arm Developer](https://developer.arm.com/downloads/-/arm-ecosystem-fvps) to download the Corstone-1000 with Cortex-A320 FVP package.
To set up the FVP:
1. Run `tmux`:
```
cd ${WORKSPACE} && tmux
```
2. Run the FVP within `tmux`:
```
kas shell meta-arm/kas/corstone1000-a320-fvp.yml:meta-arm/ci/debug.yml \
-c "../meta-arm/scripts/runfvp --terminals=tmux"
```
When the script is executed, three terminal instances will be launched:
- one for the Secure Enclave processing element
- two for the Host processor processing element.
```
corstone1000-a320-fvp login:
```
3. Log in using the `root` username.
## Security issue reporting {.reference}
To report any security issues identified with Corstone-1000 with Cortex-A320, please send an email to [psirt@arm.com](mailto:psirt@arm.com).
@@ -10,6 +10,71 @@ Change Log
This document contains a summary of the new features, changes and
fixes in each release of Corstone-1000 software stack.
***************
Version 2026.05
***************
Changes
=======
- Upgraded key Corstone-1000 components to U-Boot 2025.10, TF-A 2.14.1, TF-M 2.2.2, OP-TEE 4.9.0, Trusted Services 1.3.0, and Linux 6.19.
- Added GPT support in TF-M and updated MCUboot to use the GPT library for firmware-update partitions.
- Extended the TF-M firmware update flow with GPT fixes, partition create/remove/duplicate operations, metadata-only handling, flash erase protection, stale partition cleanup, and better handling of older images during PSA FWU.
- Added SSH-enabled build overlay for FVP mass-storage images.
- Removed GRUB from the initramfs boot package set.
Corstone-1000 components versions
=================================
+-------------------------------------------+-------------------+
| linux-yocto | 6.19 |
+-------------------------------------------+-------------------+
| u-boot | 2025.10 |
+-------------------------------------------+-------------------+
| external-system | 0.1.0 |
+-------------------------------------------+-------------------+
| optee-client | 4.9.0 |
+-------------------------------------------+-------------------+
| optee-os | 4.9.0 |
+-------------------------------------------+-------------------+
| trusted-firmware-a | 2.14.1 |
+-------------------------------------------+-------------------+
| trusted-firmware-m | 2.2.2 |
+-------------------------------------------+-------------------+
| libts | v1.3.0 |
+-------------------------------------------+-------------------+
| ts-sp-{se-proxy, smm-gateway} | v1.3.0 |
+-------------------------------------------+-------------------+
| ts-psa-{crypto, iat, its. ps}-api-test | 74dc6646ff |
+-------------------------------------------+-------------------+
Yocto distribution components versions
======================================
+-------------------------------------------+----------------+
| meta-arm | wrynose |
+-------------------------------------------+----------------+
| bitbake | 22021758e6 |
+-------------------------------------------+----------------+
| meta-openembedded | 9af4488d46 |
+-------------------------------------------+----------------+
| openembedded-core | 06dd66e622 |
+-------------------------------------------+----------------+
| meta-yocto | 8251bdad5f |
+-------------------------------------------+----------------+
| meta-secure-core | 07a99ae241 |
+-------------------------------------------+----------------+
| busybox | 1.37.0 |
+-------------------------------------------+----------------+
| musl | 1.2.6 |
+-------------------------------------------+----------------+
| gcc-arm-none-eabi | 15.2.rel1 |
+-------------------------------------------+----------------+
| gcc-cross-aarch64 | 15.2.0 |
+-------------------------------------------+----------------+
| openssl | 3.5.6 |
+-------------------------------------------+----------------+
***************
Version 2025.12
***************
@@ -19,6 +19,12 @@ intended for safety-critical applications. Should Your Software or Your Hardware
prove defective, you assume the entire cost of all necessary servicing, repair
or correction.
***********************
Release notes - 2026.05
***********************
The same notes as the 2025.05 release still apply.
***********************
Release notes - 2025.12
***********************
@@ -116,19 +116,6 @@ The Corstone-1000 architecture is designed to cover a range of
`Power, Performance, and Area (PPA) <ppa-website_>`__ applications, and enable extension
for use-case specific applications, for example, sensors, cloud connectivity, and edge computing.
**************************************
Corstone-1000 with Cortex-A320 Variant
**************************************
This variant of the Corstone-1000 platform replaces the Host System's Cortex-A35 processor
with a Cortex-A320. In this configuration, the optional External System (previously a Cortex-M3)
is replaced by an Arm Ethos-U85 Neural Processing Unit (NPU).
The Ethos-U85 runs in the direct drive configuration, where the Host System is responsible for managing the NPU directly.
.. image:: images/CorstoneA320Subsystems.png
:width: 720
:alt: CorstoneA320Subsystems
*****************
Secure Boot Chain
*****************
@@ -50,7 +50,7 @@ The Corstone-1000 software stack can be run on:
Yocto Stable Branch
-------------------
Corstone-1000 software stack is built on top of Yocto Project's `Whinlatter release <meta-arm-repository-release-branch_>`__.
Corstone-1000 software stack is built on top of Yocto Project's `Wrynose release <meta-arm-repository-release-branch_>`__.
Software Components
-------------------
@@ -91,7 +91,7 @@ Host Processor Components
+----------+-------------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend`` |
+----------+-------------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.14.0.bb`` |
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.14.1.bb`` |
+----------+-------------------------------------------------------------------------------------------------------+
`Trusted Services <https://trusted-services.readthedocs.io/en/latest/index.html>`__
@@ -131,7 +131,7 @@ Host Processor Components
================================================================
+----------+------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/optee/optee-os_4.%.bbappend`` |
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/optee/optee-os_%.bbappend`` |
+----------+------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-security/optee/optee-os_4.9.0.bb`` |
+----------+------------------------------------------------------------------------------------------+
@@ -144,7 +144,7 @@ Host Processor Components
+----------+----------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_%.bbappend`` |
+----------+----------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_2025.04.bb`` |
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_2025.10.bb`` |
+----------+----------------------------------------------------------------------------------+
Linux
@@ -172,7 +172,7 @@ Secure Enclave Components
+----------+-------------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-m/trusted-firmware-m_%.bbappend`` |
+----------+-------------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_2.2.1.bb`` |
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_2.2.2.bb`` |
+----------+-------------------------------------------------------------------------------------------------------+
************************************
@@ -223,7 +223,7 @@ Build
.. code-block:: console
cd ${WORKSPACE}
git clone https://git.yoctoproject.org/git/meta-arm -b CORSTONE1000-2025.12
git clone https://git.yoctoproject.org/git/meta-arm -b CORSTONE1000-2026.05
#. Build a Corstone-1000 image:
@@ -243,8 +243,6 @@ Build
.. warning::
**The External System Processor is not available on the Corstone-1000 with Cortex-A320 FVP.**
Access to the External System Processor is disabled by default on **Corstone-1000 with Cortex-A35**.
To build the Corstone-1000 image with External System Processor enabled, run:
@@ -253,18 +251,6 @@ Build
kas build meta-arm/kas/corstone1000-${TARGET}.yml:meta-arm/ci/debug.yml:meta-arm/kas/corstone1000-extsys.yml
.. warning::
**The Ethos-U85 Neural Processing Unit (NPU) is only available on
the Corstone-1000 with Cortex-A320 FVP.**
To build the Corstone-1000 image with the Ethos-U85 NPU enabled, run:
.. code-block:: console
kas build meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml:meta-arm/kas/corstone1000-a320.yml
A clean build takes a significant amount of time given that all of the development machine utilities are also
built along with the target images. Those development machine utilities include executables (Python,
CMake, etc.) and the required toolchains.
@@ -280,6 +266,34 @@ The output binaries run in the Corstone-1000 platform are the following:
- The External System Processor firmware: ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-${TARGET}/es_flashfw.bin``
- The internal firmware flash image: ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-${TARGET}/corstone1000-flash-firmware-image-corstone1000-${TARGET}.wic``
Build with SSH
--------------
The ``meta-arm/kas/corstone1000-${TARGET}.yml`` build produces an image for
booting from flash.
.. important::
The SSH-enabled mass storage image is supported only for the FVP target.
It is not supported for the MPS3 target, because it relies on pre-generated
SSH host keys intended for virtual platforms.
To build a bootable mass storage OS image with Dropbear SSH enabled for FVP,
run:
.. code-block:: console
kas build meta-arm/ci/corstone1000-fvp.yml:meta-arm/kas/corstone1000-ssh.yml
The mass storage OS image can be found at
``${WORKSPACE}/build/tmp/deploy/images/corstone1000-fvp/core-image-minimal-corstone1000-fvp.wic``
.. note::
The generated ``core-image-minimal-corstone1000-fvp.fvpconf`` configures
the mass storage OS image using ``board.msd_mmc.p_mmc_file``.
.. _flashing-firmware-images:
Flash
@@ -371,8 +385,8 @@ Flash
#. Copy ``bl1.bin`` from ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-mps3/trusted-firmware-m/`` to the ``SOFTWARE`` directory of the FPGA bundle.
#. Copy ``es_flashfw.bin`` from ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-mps3`` to the ``SOFTWARE`` directory of the FPGA bundle
and rename the binary to ``es0.bin``.
#. Remove ``ES0.bin`` from the ``SOFTWARE`` directory of the FPGA bundle. Copy ``es_flashfw.bin`` from
``${WORKSPACE}/build/tmp/deploy/images/corstone1000-mps3`` to the ``SOFTWARE`` directory of the FPGA bundle and rename the binary to ``es0.bin``.
#. Copy ``corstone1000-flash-firmware-image-corstone1000-mps3.wic`` from ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-mps3`` to the ``SOFTWARE``
directory of the FPGA bundle and rename the wic image to ``cs1000.bin``.
@@ -457,14 +471,9 @@ Corstone-1000 FVP software image.
A Yocto recipe is provided to download the latest supported FVP version.
The recipe is located at ``${WORKSPACE}/meta-arm/meta-arm/recipes-devtools/fvp/fvp-corstone1000.bb``.
This recipe supports selecting different Corstone1000 FVP models via MACHINE_FEATURES:
- ``cortexa320`` use the Cortex-A320 Host Processor with Ethos U85 enabled FVP build
- (default) use the Cortex-A35 Host Processor with Cortex-M3 External System FVP build
The latest FVP version is ``11.23.25`` for Corstone-1000 with Cortex-A35 and ``11.30.27`` for
Corstone-1000 with Cortex-A320, and each model is automatically downloaded and installed when using
the ``runfvp`` command as detailed below.
The latest FVP version is ``11.23.25`` and is automatically
downloaded and installed when using the ``runfvp`` command as detailed below.
.. note::
@@ -521,8 +530,8 @@ Tests
Reports
-------
Reports for the tests conducted on the `Corstone-1000 software (CORSTONE1000-2025.12) <https://git.yoctoproject.org/meta-arm/tag/?h=CORSTONE1000-2025.12>`__
release are available for reference `here <https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/CORSTONE1000-2025.12/embedded-a/corstone1000/CORSTONE1000-2025.12?ref_type=tags>`__.
Reports for the tests conducted on the `Corstone-1000 software (CORSTONE1000-2026.05) <https://git.yoctoproject.org/meta-arm/tag/?h=CORSTONE1000-2026.05>`__
release are available for reference `here <https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/CORSTONE1000-2026.05/embedded-a/corstone1000/CORSTONE1000-2026.05?ref_type=tags>`__.
.. _clean-secure-flash:
@@ -541,7 +550,7 @@ Clean Secure Flash
.. code-block:: console
cd ${WORKSPACE}
git clone https://git.gitlab.arm.com/arm-reference-solutions/iot-platform-assets.git -b CORSTONE1000-2025.12
git clone https://git.gitlab.arm.com/arm-reference-solutions/iot-platform-assets.git -b CORSTONE1000-2026.05
#. Copy the secure flash cleaning Git patch file to your copy of `meta-arm`.
@@ -779,7 +788,12 @@ MPS3
cd ${WORKSPACE}/arm-systemready/IR/prebuilt_images/v23.09_2.1.0
sudo dd if=ir-acs-live-image-generic-arm64.wic of=/dev/sdc iflag=direct oflag=direct bs=1M status=progress; sync
#. Plug the USB drive to the MPS3. At this point you should have both the USB drive with the ESP and the USB drive with the ACS image plugged to the MPS3.
#. Unplug the ESP USB drive from the MPS3, if connected.
#. Plug only the ACS image USB drive to the MPS3.
The ESP USB drive must remain unplugged while the ACS image is booting,
otherwise GRUB might fail to find the bootable partition on the ACS image USB drive.
#. Reboot the MPS3.
@@ -787,12 +801,10 @@ The MPS3 will reset multiple times during the test, and it might take approximat
.. important::
Unplug the ESP USB drive from the MPS3 if it is preventing GRUB
from finding the bootable partition. Leave only the ACS image USB drive
plugged in to run the ACS tests.
The ESP USB drive can be plugged in again after
selecting the `Linux Boot` option in the GRUB menu at the end of the ACS tests.
Keep the ESP USB drive unplugged until the GRUB menu is displayed during
the Linux boot timeout workaround described below. Plug the ESP USB drive
back in just before selecting the `Linux Boot` option, so it is available
for the remaining ACS tests.
.. warning::
@@ -803,6 +815,7 @@ The MPS3 will reset multiple times during the test, and it might take approximat
#. Press Enter at the Linux prompt.
#. Open the file `/etc/systemd/system.conf` and set `DefaultDeviceTimeoutSec=infinity`.
#. Reboot the platform using the `reboot` command.
#. When the GRUB menu appears, plug the ESP USB drive back into the MPS3.
#. Select the `Linux Boot` option from the GRUB menu.
#. Allow Linux to boot and run the remaining ACS tests until completion.
@@ -847,7 +860,7 @@ If GRUB is not interrupted, the tests are executed automatically in the followin
- UEFI BSA
- FWTS
The results can be fetched from the `acs_results` folder in the ``BOOT`` partition of the USB drive (for MPS3) or SD Card (for FVP).
The results can be fetched from the `acs_results` folder in the ``BOOT`` partition of the ACS image USB drive (for MPS3) or SD Card (for FVP).
.. note::
@@ -918,6 +931,11 @@ Generate Capsules
for the host machine during the firmware image building process.
The tool can be found at ``${WORKSPACE}/build/tmp/sysroots-components/aarch64/edk2-basetools-native/usr/bin/edk2-BaseTools/BinWrappers/PosixLike/GenerateCapsule``.
.. note::
The ``aarch64`` part of this path depends on the build host architecture
and can be different on another host.
A JSON file containing metadata about the capsule payloads needs to be created using the script
found at ``${WORKSPACE}/meta-arm/meta-arm/scripts/generate_capsule_json_multiple.py``.
This JSON file is required by EDK II's ``GenerateCapsule`` tool to generate the capsule.
@@ -1066,7 +1084,7 @@ MPS3
#. Prepare a USB drive as explained in `this <mps3-instructions-for-acs-image_>`_ section.
#. Copy the capsule file to the root directory of the ``BOOT`` partition in the USB drive.
#. Copy the capsule files to the root directory of the ``BOOT`` partition in the USB drive.
.. code-block:: console
@@ -1150,7 +1168,7 @@ This will be followed by using the invalid capsule to run the rollback protectio
Positive Full Capsule Update Test
=================================
#. Run Corstone-1000 with the ACS image containing the two capsule files:
#. Run Corstone-1000 with the ACS image containing the capsule files:
- MPS3:
@@ -1213,42 +1231,40 @@ Positive Full Capsule Update Test
The software stack copies the capsule content to the external flash, which is shared between the Secure Enclave and the Host Processor
before rebooting the system.
After the first reboot, TrustedFirmware-M should apply the valid capsule and display the following log on the Secure Enclave terminal (``ttyUSB1`` for MPS3)
before rebooting the system a second time:
before rebooting the system, and the following logs should be displayed on the Secure Enclave terminal (``ttyUSB1`` for MPS3):
.. code-block:: console
...
SysTick_Handler: counted = 10, expiring on = 360
SysTick_Handler: counted = 20, expiring on = 360
SysTick_Handler: counted = 30, expiring on = 360
...
fwu_bootloader_install_image: enter
metadata_read: success: active = 0, previous = 1
fwu_update_metadata: enter
metadata_write: success: active = 1, previous = 0
flash_full_capsule: exit
corstone1000_fwu_flash_image: exit: ret = 0
fwu_update_metadata: exit: ret = 0
fwu_bootloader_install_image: exit: ret = 0
...
The above log snippet indicates that the new capsule image is successfully applied, and the board is booting with the external flash's Bank-1.
After a second reboot, the following log should be displayed on on the Secure Enclave terminal (``ttyUSB1``):
.. code-block:: console
...
fmp_set_image_info:133 Enter
FMP image update: image id = 0
FMP image update: status = 0version=6 last_attempt_version=6.
fmp_set_image_info:157 Exit.
corstone1000_fwu_host_ack: exit: ret = 0
...
The above log snippet indicates that the new capsule image is successfully applied.
After the first reboot,
#. Interrupt the U-Boot shell.
.. code-block:: console
Hit any key to stop autoboot:
After the first reboot, TrustedFirmware-M should display the following log on the Secure Enclave terminal (``ttyUSB1`` for MPS3):
.. code-block:: console
...
[INF] Starting TF-M BL1_1
metadata_read: success: active = 1, previous = 0
get_fwu_agent_state: exit: FWU Agent PSA_FWU_TRIAL (index mismatch)
bl1_get_active_bl2_image: booting from trial bank: 1
bl1_get_active_bl2_image: exit: booting from bank = 1, offset = 0x1002000
...
#. Run the following commands in order to run the Corstone-1000 Linux kernel.
@@ -1261,6 +1277,18 @@ Positive Full Capsule Update Test
$ loadm 0x90000000 $kernel_addr_r $filesize
$ bootefi $kernel_addr_r $fdtcontroladdr
After executing above set of commands, the following log should be displayed on the Secure Enclave terminal (``ttyUSB1``):
.. code-block:: console
...
fwu_accept_image: success: fwu state is changed to regular
update_nv_counters: success
disable_host_ack_timer: timer to reset is disabled
FMP image update: status = 0version=6 last_attempt_version=6.
fwu_bootloader_mark_image_accepted: exit: ret = 0
...
#. The first boot after a capsule update is considered the trial stage, during which the FWU image is accepted.
However, to view the updated contents of the EFI System Resource Table (ESRT), an additional reboot is required.
@@ -1354,21 +1382,20 @@ Rollback Protection Capsule Update Test
.. code-block:: console
...
uefi_capsule_retrieve_images: image 0 at 0xa0000070, size=15654928
uefi_capsule_retrieve_images: exit
flash_full_capsule: enter: image = 0x0xa0000070, size = 7764541, version = 5
ERROR: flash_full_capsule: version error
private_metadata_write: enter: boot_index = 1
private_metadata_write: success
fmp_set_image_info:133 Enter
FMP image update: image id = 0
FMP image update: status = 1version=6 last_attempt_version=5.
fmp_set_image_info:157 Exit.
corstone1000_fwu_flash_image: exit: ret = -1
fmp_get_image_info:232 Enter
pack_image_info:207 ImageInfo size = 105, ImageName size = 34, ImageVersionName
size = 36
fmp_get_image_info:236 Exit
fwu_bootloader_load_image: enter: block_offset = 0
FMP version: 0x5, metadata version : 0x7
private_metadata_write: enter: boot_index = 0
private_metadata_write: success
fmp_set_image_info:160 Enter
FMP image update: image id = 0
FMP image update: status = 1version=7 last_attempt_version=5.
fmp_set_image_info:184 Exit.
ERROR: fwu_bootloader_load_image: version error
remove_all_stale_partitions: Removed GPT partition 'bl2_secondary'
remove_all_stale_partitions: Removed GPT partition 'tfm_secondary'
remove_all_stale_partitions: Removed GPT partition 'FIP_B'
remove_all_stale_partitions: Removed GPT partition 'kernel_secondary'
fwu_bootloader_load_image: exit: ret = -248
...
The Secure Enclave tries to load the new image a predetermined number of times
@@ -1631,7 +1658,7 @@ Corstone-1000 on-board non-volatile storage size is insufficient for installing
dd if=/dev/zero of=${WORKSPACE}/fvp_distro_system_drive.img \
bs=1 count=0 seek=10G; sync; \
parted -s fvp_distro_system_drive.img mklabel gpt
parted -s ${WORKSPACE}/fvp_distro_system_drive.img mklabel gpt
#. This MMC image will be used as the primary drive to boot the distribution.
@@ -1685,6 +1712,10 @@ FVP
-C board.msd_mmc.p_mmc_file=${WORKSPACE}/fvp_distro_system_drive.img \
-C board.msd_mmc_2.p_mmc_file=${DISTRO_INSTALLER_ISO_PATH}"
.. note::
The FVP distribution installation process can take 6-8 hours to complete.
The Linux distribution will be installed on ``fvp_distro_system_drive.img``.
@@ -1693,7 +1724,7 @@ Debian Installation Extra Steps
Debian installation may need some extra steps, that are indicated below:
#. Answer ``Yes`` to the question ``Force grub installation to the EFI removable media path?``.
#. Answer ``Yes`` to the question ``Install the GRUB boot loader``.
If the GRUB installation fails, these are the steps to follow on the subsequent
popups:
@@ -1852,8 +1883,7 @@ Generate Keys, Signed Image and Unsigned Image
cd ${WORKSPACE}
git clone https://gitlab.arm.com/arm-reference-solutions/iot-platform-assets \
-b CORSTONE1000-2025.12
-b CORSTONE1000-2026.05
#. Set the current working directory to build directory's subdirectory containing the software stack build images.
@@ -1865,7 +1895,7 @@ Generate Keys, Signed Image and Unsigned Image
.. code-block:: console
./${WORKSPACE}/iot-platform-assets/corstone1000/secureboot/create_keys_and_sign.sh \
${WORKSPACE}/iot-platform-assets/corstone1000/secureboot/create_keys_and_sign.sh \
-d ${TARGET} \
-v ${CERTIFICATE_VALIDITY_DURATION_IN_DAYS}
@@ -1899,7 +1929,7 @@ MPS3
#. Perform a cold boot of the MPS3.
#. On the Host Processor terminal host side, stop the execution of U-Boot when prompted to do so with the message ``Press any key to stop``.
#. On the Host Processor terminal host side, stop the execution of U-Boot when prompted to do so with the message ``Hit any key to stop autoboot``.
.. warning::
@@ -1972,7 +2002,7 @@ FVP
#. Run the software stack as described `here <running-software-stack-fvp_>`__.
#. On the Host Processor terminal host side, stop the execution of U-Boot when prompted to do so with the message ``Press any key to stop``.
#. On the Host Processor terminal host side, stop the execution of U-Boot when prompted to do so with the message ``Hit any key to stop autoboot``.
.. warning::
@@ -2073,9 +2103,12 @@ As a result, U-Boot reads these variables and verifies the Linux kernel image be
In a typical boot scenario, the Linux kernel image is not signed, which will prevent the system from booting due to failed image authentication.
To resolve this, the Platform Key (one of the UEFI authenticated variables for secure boot) needs to be deleted.
#. Perform a cold boot of the MPS3.
#. For MPS3, perform a cold boot.
#. On the Host Processor terminal host side, stop the execution of U-Boot when prompted to do so with the message ``Press any key to stop``.
#. For FVP, continue in the same boot cycle in which the UEFI secure boot keys were enrolled.
Do not cold boot FVP before deleting the Platform Key, because the secure flash contents are not preserved across an FVP cold boot.
#. On the Host Processor terminal host side, stop the execution of U-Boot when prompted to do so with the message ``Hit any key to stop autoboot``.
#. On the U-Boot console, delete the Platform Key (PK).
@@ -2156,42 +2189,21 @@ Symmetric Multiprocessing
.. warning::
Symmetric multiprocessing (SMP) mode is supported on Corstone-1000
with Cortex-A35 FVP and Corstone-1000 with Cortex-A320 FVP, but is disabled by default.
Symmetric multiprocessing (SMP) mode is supported on FVP but is disabled by default.
#. Build the software stack with SMP mode enabled:
#. Build the software stack with SMP mode enabled.
For Corstone-1000 with Cortex-A35 FVP:
.. code-block:: console
.. code-block:: console
kas build meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml:meta-arm/kas/corstone1000-multicore.yml
For Corstone-1000 with Cortex-A320 FVP:
.. code-block:: console
kas build meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml:meta-arm/kas/corstone1000-a320.yml:\
meta-arm/kas/corstone1000-multicore.yml
#. Run the Corstone-1000 FVP.
For Corstone-1000 with Cortex-A35 FVP:
.. code-block:: console
kas shell meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml:meta-arm/kas/corstone1000-multicore.yml \
-c "../meta-arm/scripts/runfvp"
For Corstone-1000 with Cortex-A320 FVP:
.. code-block:: console
kas shell meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml:meta-arm/kas/corstone1000-a320.yml:\
meta-arm/kas/corstone1000-multicore.yml \
-c "../meta-arm/scripts/runfvp"
#. Verify that the FVP is running the Host Processor with more than one CPU core:
.. code-block:: console
@@ -2199,78 +2211,6 @@ Symmetric Multiprocessing
nproc
4 # number of processing units
Ethos-U85 NPU
-------------
.. warning::
The Ethos-U85 NPU is only supported on Corstone-1000 with Cortex-A320 FVP.
#. Clone the `iot-platform-assets` repository to your ``${WORKSPACE}``.
.. code-block:: console
cd ${WORKSPACE}
git clone https://git.gitlab.arm.com/arm-reference-solutions/iot-platform-assets.git \
-b CORSTONE1000-2025.12
#. Copy the additional kas configuration file to:
.. code-block:: console
cp ${WORKSPACE}/iot-platform-assets/corstone1000/ethos-u85_test/ethos-u85-test.yml \
${WORKSPACE}/meta-arm/kas/
#. Copy the mesa package Git patch file to your copy of meta-arm.
.. code-block:: console
cp -f ${WORKSPACE}/iot-platform-assets/corstone1000/ethos-u85_test/0001-arm-bsp-mesa-Package-Teflon-test-runner-and-models.patch \
${WORKSPACE}/meta-arm/
#. Apply the Git patch to meta-arm.
.. code-block:: console
cd ${WORKSPACE}/meta-arm/
git apply 0001-arm-bsp-mesa-Package-Teflon-test-runner-and-models.patch
cd ${WORKSPACE}
#. Re-Build the Corstone-1000 with Cortex-A320 FVP software stack as follows:
.. code-block:: console
kas build meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml:meta-arm/kas/corstone1000-a320.yml:\
meta-arm/kas/ethos-u85-test.yml
#. Run the Corstone-1000 with Cortex-320 FVP:
.. code-block:: console
kas shell meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml:meta-arm/kas/corstone1000-a320.yml:\
meta-arm/kas/ethos-u85-test.yml \
-c "../meta-arm/scripts/runfvp"
#. To verify you are running the Corstone-1000 with Cortex-A320, build and run the FVP and inspect the CPU model
reported in ``/proc/cpuinfo`` as shown below. Inside the FVP shell, confirm the core type:
.. code-block:: console
grep -E 'CPU part|model name' /proc/cpuinfo
# Expect: CPU part : 0xd8f (which corresponds to Cortex-A320)
#. Run the `test_teflon` test application inside the FVP shell as follows:
.. code-block:: console
export TEFLON_TEST_DELEGATE=/usr/lib/libteflon.so
export TEFLON_TEST_DATA=/usr/share/teflon/tests
test_teflon --gtest_filter='Models.*'
The test completes in approximately one minute.
Secure Debug
------------
@@ -2369,7 +2309,7 @@ and `Arm Development Studio <arm-ds-website_>`__ versions 2022.2, 2022.c, or 202
.. _arm-developer-fvp: https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
.. _secure-debug-manager-repo-readme: https://github.com/ARM-software/secure-debug-manager/tree/master?tab=readme-ov-file#secure-debug-manager-psa-adac--sdc-600
.. _secure-debug-manager-armds-integration: https://github.com/ARM-software/secure-debug-manager?tab=readme-ov-file#arm-development-studio-integration
.. _meta-arm-repository-release-branch: https://docs.yoctoproject.org/next/migration-guides/migration-5.3.html
.. _meta-arm-repository-release-branch: https://docs.yoctoproject.org/next/migration-guides/migration-6.0.html
.. _arm-ulink-pro-website: https://www.arm.com/products/development-tools/debug-probes/ulink-pro
.. _arm-ds-website: https://www.arm.com/products/development-tools/embedded-and-software/arm-development-studio
.. _edk2-repository: https://github.com/tianocore/edk2
@@ -7,5 +7,6 @@ jinja2==3.1.1
# Required to build the documentation
sphinx==7.1.2
myst-parser~=3.0.1
sphinx_rtd_theme~=3.0.0
docutils~=0.18.1
@@ -23,10 +23,10 @@ TFA_SPMD_SPM_AT_SEL2 = "0"
# BL2 loads BL32 (optee). So, optee needs to be built first:
DEPENDS += "optee-os"
ENABLE_CORTEX_A35_ERRATA = " \
ENABLE_CORTEX_A_ERRATA = " \
ERRATA_A35_855472=1 \
"
ENABLE_CORTEX_A35_ERRATA:cortexta320 = ""
ENABLE_CORTEX_A_ERRATA:cortexa320 = ""
FVP_GIC_DRIVER ?= "FVP_GICV2"
FVP_GIC_DRIVER:cortexa320 = "FVP_GICV3"
@@ -54,7 +54,7 @@ EXTRA_OEMAKE:append = " \
NR_OF_IMAGES_IN_FW_BANK=4 \
COT=tbbr \
ARM_ROTPK_LOCATION=devel_rsa \
${ENABLE_CORTEX_A35_ERRATA} \
${ENABLE_CORTEX_A_ERRATA} \
ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem \
BL32=${RECIPE_SYSROOT}/${nonarch_base_libdir}/firmware/tee-pager_v2.bin \
FVP_USE_GIC_DRIVER=${FVP_GIC_DRIVER} \
@@ -1,6 +1,7 @@
# These machines cannot run in product as they are virtual
# platforms, so allow ssh-pregen-hostkeys to be used.
COMPATIBLE_MACHINE:corstone1000-fvp = "corstone1000-fvp"
COMPATIBLE_MACHINE:corstone1000 = "corstone1000-fvp"
COMPATIBLE_MACHINE:corstone1000:cortexa320 = "corstone1000-a320-fvp"
COMPATIBLE_MACHINE:fvp-base = "fvp-base"
COMPATIBLE_MACHINE:sbsa-ref = "sbsa-ref"
@@ -2,12 +2,19 @@ require fvp-ecosystem.inc
MODEL = "Corstone-1000-with-Cortex-A320"
MODEL_CODE = "FVP_Corstone_1000-A320"
PV = "11.30.27"
PV = "11.31.cs1000_a320_2"
FVP_INSTALL_DIR = "${MODEL_CODE}_${PV}"
FVP_AARCH64_SHA256SUM = "a45898fead5549779153263c3544fa1032c285d532275eb678f58cae3317b01f"
FVP_X86_64_SHA256SUM = "d57b248a1c1bc5a6040605d50af94a5151adc4da26ec9acc456ec86b819ffb76"
FVP_AARCH64_SHA256SUM = "37b67836ff09089c292c1c78fa23d60f8613a95cf4a768b70f5b4f037ad476ef"
FVP_X86_64_SHA256SUM = "f84b973efa6a65c76ae7038a281b592836081fea1920eb90fa9ca983f177a1f2"
SRC_URI = "https://developer.arm.com/-/cdn-downloads/permalink/FVPs-Corstone-IoT/${MODEL}/${MODEL_CODE}_${PV_URL}_${FVP_ARCH}.tgz;subdir=${BP};name=fvp-${HOST_ARCH}"
FVP_ARCH:aarch64 = "Linux_armv8"
FVP_ARCH:x86-64 = "Linux_x86"
FVP_URL_TOKEN:aarch64 = "st=1782487701~exp=2097847701~hmac=f31b5bcea56a5f3ac8cdb3d3bfe7611e5d394987752444c07c82365dc8936338"
FVP_URL_TOKEN:x86-64 = "st=1782487742~exp=2097847742~hmac=b2e12e26a2481d2c280e93c671f0b941fe9ebce5125a4c85f7d4bc7467f3e8f5"
SRC_URI = "https://developer.arm.com/-/cdn-downloads/FVPs-Corstone-IoT/${MODEL}/${MODEL_CODE}_${PV}_${FVP_ARCH}.tar.gz?__token__=${FVP_URL_TOKEN};subdir=${BP};name=fvp-${HOST_ARCH}"
SRC_URI[fvp-aarch64.sha256sum] = "${FVP_AARCH64_SHA256SUM}"
SRC_URI[fvp-x86_64.sha256sum] = "${FVP_X86_64_SHA256SUM}"
@@ -15,14 +22,24 @@ SRC_URI[fvp-x86_64.sha256sum] = "${FVP_X86_64_SHA256SUM}"
UPSTREAM_VERSION_UNKNOWN = "1"
LIC_FILES_CHKSUM = "\
file://license_terms/license_agreement.txt;md5=1a33828e132ba71861c11688dbb0bd16 \
file://license_terms/third_party_licenses/third_party_licenses.txt;md5=a5ce56e117d0ab63791fbb7c35ec2211 \
file://${FVP_INSTALL_DIR}/license_terms/license_agreement.txt;md5=7fde2369510c8bcafaf4cbf42f7aa23a \
file://${FVP_INSTALL_DIR}/license_terms/third_party_licenses/third_party_licenses.txt;md5=da95c9d79488fe4b6115bb7f9900b505 \
"
do_install:append() {
# This FVP embeds a Python runtime, so clean up RPATHs and remove pointless static libraries
chrpath --delete ${D}${FVPDIR}/python/lib/python*/lib-dynload/*.so
find ${D}${FVPDIR}/python/ -name *.a -delete
do_install() {
mkdir --parents ${D}${FVPDIR}/models/${FVP_ARCH_DIR} ${D}${bindir}
cp --archive --no-preserve=ownership ${S}/${FVP_INSTALL_DIR} ${D}${FVPDIR}/models/${FVP_ARCH_DIR}/
FVP_DIR="${D}${FVPDIR}/models/${FVP_ARCH_DIR}/${FVP_INSTALL_DIR}"
stat $FVP_DIR/bin/FVP_* >/dev/null 2>&1 || bbfatal Cannot find FVP binaries in $FVP_DIR/bin
for FVP in $FVP_DIR/bin/FVP_*; do
ln -rs "$FVP" "${D}${bindir}/$(basename "$FVP")"
done
}
COMPATIBLE_HOST = "(aarch64|x86_64).*-linux"
INSANE_SKIP:${PN} += "dev-so"