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

Compare commits

...

9 Commits

Author SHA1 Message Date
Ross Burton 72f0580f70 CI: add documentation job
This job builds all of the Sphinx documentation it can find with fatal
warnings enabled.

Signed-off-by: Ross Burton <ross.burton@arm.com>
2022-10-24 12:02:01 -04:00
Vishnu Banavath 950372e99d meta-arm-bsp/doc: add readthedocs for corstone1000
These changes are to add support for readthedocs for
corstone1000 platform. readthedocs server traces
any changes to to corstone1000 documents and will trigger
a build which will generate html file which can will be
rendered by corstone1000.docs.arm.com server

Signed-off-by: Vishnu Banavath <vishnu.banavath@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2022-10-24 12:02:01 -04:00
Vishnu Banavath 0a7c6ae7e1 runfvp: corstone1000: add mmc card configuration
These changes are to pass appropriate MMC card configuration to
corstone1000 FVP.

Signed-off-by: Vishnu Banavath <vishnu.banavath@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2022-10-24 12:02:01 -04:00
Ross Burton bd01053121 arm-bsp/linux-arm64-ack: fix malformed Upstream-Status tag
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2022-10-24 12:02:01 -04:00
Ross Burton 062aef06c7 arm-bsp/hafnium: add missing Upstream-Status
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2022-10-24 12:02:01 -04:00
Ross Burton 0245e6609c arm/hafnium: add missing Upstream-Status
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2022-10-24 12:02:01 -04:00
Rui Miguel Silva a42ee82eda arm/trusted-services: port crypto config
Port crypto config to psa arch test api suite.This
needs to move to arm-bsp since is corstone1000 specific
configuration

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2022-10-24 12:02:01 -04:00
Mohamed Omar Asaker be90d2e4b0 arm-bsp/u-boot: corstone1000: support 32bit ffa direct messaging
Signed-off-by: Mohamed Omar Asaker <mohamed.omarasaker@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
2022-10-24 12:02:01 -04:00
Jon Mason 1935f51d0f CI: fix to langdale
Signed-off-by: Jon Mason <jon.mason@arm.com>
2022-10-19 14:30:01 -04:00
25 changed files with 1680 additions and 3 deletions
+15
View File
@@ -242,3 +242,18 @@ metrics:
script:
- kas shell --update --force-checkout ci/base.yml --command \
"$CI_PROJECT_DIR/ci/patchreview $CI_PROJECT_DIR/meta-* --verbose --metrics $CI_PROJECT_DIR/metrics.txt"
documentation:
extends: .setup
script:
- |
sudo pip3 install -r meta-arm-bsp/documentation/requirements.txt
for CONF in meta-*/documentation/*/conf.py ; do
SOURCE_DIR=$(dirname $CONF)
MACHINE=$(basename $SOURCE_DIR)
sphinx-build -vW $SOURCE_DIR build-docs/$MACHINE
done
test -d build-docs/
artifacts:
paths:
- build-docs/
+1 -1
View File
@@ -5,7 +5,7 @@ distro: poky
defaults:
repos:
refspec: master
refspec: langdale
repos:
meta-arm:
+1
View File
@@ -4,6 +4,7 @@ header:
repos:
meta-clang:
url: https://github.com/kraj/meta-clang
refspec: master
local_conf_header:
clang: |
+1
View File
@@ -4,6 +4,7 @@ header:
repos:
meta-openembedded:
url: https://git.openembedded.org/meta-openembedded
refspec: master
layers:
meta-filesystems:
meta-networking:
@@ -42,3 +42,7 @@ FVP_TERMINALS[host.host_terminal_1] ?= "Secure World Console"
FVP_TERMINALS[se.secenc_terminal] ?= "Secure Enclave Console"
FVP_TERMINALS[extsys0.extsys_terminal] ?= "Cortex M3"
# MMC card configuration
FVP_CONFIG[board.msd_mmc.card_type] ?= "SDHC"
FVP_CONFIG[board.msd_mmc.p_fast_access] ?= "0"
FVP_CONFIG[board.msd_mmc.diagnostics] ?= "2"
@@ -0,0 +1,98 @@
..
# Copyright (c) 2022, Arm Limited.
#
# SPDX-License-Identifier: MIT
##########
Change Log
##########
This document contains a summary of the new features, changes and
fixes in each release of corstone1000 software stack.
******************
Version 2022.04.04
******************
Changes
=======
- Linux distro openSUSE, raw image installation and boot in the FVP.
- SCT test support in FVP.
- Manual capsule update support in FVP.
******************
Version 2022.02.25
******************
Changes
=======
- Building and running psa-arch-tests on corstone1000 FVP
- Enabled smm-gateway partition in Trusted Service on corstone1000 FVP
- Enabled MHU driver in Trusted Service on corstone1000 FVP
- Enabled OpenAMP support in SE proxy SP on corstone1000 FVP
******************
Version 2022.02.21
******************
Changes
=======
- psa-arch-tests: recipe is dropped and merged into the secure-partitons recipe.
- psa-arch-tests: The tests are align with latest tfm version for psa-crypto-api suite.
******************
Version 2022.01.18
******************
Changes
=======
- psa-arch-tests: change master to main for psa-arch-tests
- U-Boot: fix null pointer exception for get_image_info
- TF-M: fix capsule instability issue for corstone1000
******************
Version 2022.01.07
******************
Changes
=======
- corstone1000: fix SystemReady-IR ACS test (SCT, FWTS) failures.
- U-Boot: send bootcomplete event to secure enclave.
- U-Boot: support populating corstone1000 image_info to ESRT table.
- U-Boot: add ethernet device and enable configs to support bootfromnetwork SCT.
******************
Version 2021.12.15
******************
Changes
=======
- Enabling corstone1000 FPGA support on:
- Linux 5.10
- OP-TEE 3.14
- Trusted Firmware-A 2.5
- Trusted Firmware-M 1.5
- Building and running psa-arch-tests
- Adding openamp support in SE proxy SP
- OP-TEE: adding smm-gateway partition
- U-Boot: introducing Arm FF-A and MM support
******************
Version 2021.10.29
******************
Changes
=======
- Enabling corstone1000 FVP support on:
- Linux 5.10
- OP-TEE 3.14
- Trusted Firmware-A 2.5
- Trusted Firmware-M 1.4
- Linux kernel: enabling EFI, adding FF-A debugfs driver, integrating ARM_FFA_TRANSPORT.
- U-Boot: Extending EFI support
- python3-imgtool: adding recipe for Trusted-firmware-m
- python3-imgtool: adding the Yocto recipe used in signing host images (based on MCUBOOT format)
--------------
*Copyright (c) 2021, Arm Limited. All rights reserved.*
@@ -0,0 +1,52 @@
# 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.
#
# import os
# import sys
# sys.path.insert(0, os.path.abspath('.'))
# -- Project information -----------------------------------------------------
project = 'corstone1000'
copyright = '2020-2022, 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 = [
]
# 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']
# -- 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'
# 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']
Binary file not shown.

After

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 35 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 147 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 60 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 72 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 96 KiB

@@ -0,0 +1,16 @@
..
# Copyright (c) 2022, Arm Limited.
#
# SPDX-License-Identifier: MIT
################
ARM Corstone1000
################
.. toctree::
:maxdepth: 1
software-architecture
user-guide
release-notes
change-log
@@ -0,0 +1,137 @@
..
# Copyright (c) 2022, Arm Limited.
#
# SPDX-License-Identifier: MIT
#############
Release notes
#############
**************************
Release notes - 2022.04.04
**************************
Known Issues or Limitations
---------------------------
- FGPA support Linux distro install and boot through installer. However,
FVP only support openSUSE raw image installation and boot.
- Due to the performance uplimit of MPS3 FPGA and FVP, some Linux distros like Fedora Rawhide
cannot boot on corstone1000 (i.e. user may experience timeouts or boot hang).
- Below SCT FAILURE is a known issues in the FVP:
UEFI Compliant - Boot from network protocols must be implemented -- FAILURE
Platform Support
-----------------
- This software release is tested on corstone1000 FPGA version AN550_v1
- This software release is tested on corstone1000 Fast Model platform (FVP) version 11.17_23
https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
**************************
Release notes - 2022.02.25
**************************
Known Issues or Limitations
---------------------------
- The following tests only work on corstone1000 FPGA: ACS tests (SCT, FWTS,
BSA), manual capsule update test, Linux distro install and boot.
Platform Support
----------------
- This software release is tested on corstone1000 FPGA version AN550_v1
- This software release is tested on corstone1000 Fast Model platform (FVP) version 11.17_23
https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
Release notes - 2022.02.21
--------------------------
Known Issues or Limitations
---------------------------
- The following tests only work on corstone1000 FPGA: ACS tests (SCT, FWTS,
BSA), manual capsule update test, Linux distro install and boot, psa-arch-test.
Platform Support
----------------
- This software release is tested on corstone1000 FPGA version AN550_v1
- This software release is tested on corstone1000 Fast Model platform (FVP) version 11.16.21
https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
Release notes - 2022.01.18
--------------------------
Known Issues or Limitations
---------------------------
- Before running each SystemReady-IR tests: ACS tests (SCT, FWTS, BSA), manual
capsule update test, Linux distro install and boot, etc., the SecureEnclave
flash must be cleaned. See user-guide "Clean Secure Flash Before Testing"
section.
Release notes - 2021.12.15
--------------------------
Software Features
------------------
The following components are present in the release:
- Yocto version Honister
- Linux kernel version 5.10
- U-Boot 2021.07
- OP-TEE version 3.14
- Trusted Firmware-A 2.5
- Trusted Firmware-M 1.5
- OpenAMP 347397decaa43372fc4d00f965640ebde042966d
- Trusted Services a365a04f937b9b76ebb2e0eeade226f208cbc0d2
Platform Support
----------------
- This software release is tested on corstone1000 FPGA version AN550_v1
- This software release is tested on corstone1000 Fast Model platform (FVP) version 11.16.21
https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
Known Issues or Limitations
---------------------------
- The following tests only work on corstone1000 FPGA: ACS tests (SCT, FWTS,
BSA), manual capsule update test, Linux distro install and boot, and
psa-arch-tests.
- Only the manual capsule update from UEFI shell is supported on FPGA.
- Due to flash size limitation and to support A/B banks,the wic image provided
by the user should be smaller than 15MB.
- The failures in PSA Arch Crypto Test are known limitations with crypto
library. It requires further investigation. The user can refer to `PSA Arch Crypto Test Failure Analysis In TF-M V1.5 Release <https://developer.trustedfirmware.org/w/tf_m/release/psa_arch_crypto_test_failure_analysis_in_tf-m_v1.5_release/>`__
for the reason for each failing test.
Release notes - 2021.10.29
--------------------------
Software Features
-----------------
This initial release of corstone1000 supports booting Linux on the Cortex-A35
and TF-M/MCUBOOT in the Secure Enclave. The following components are present in
the release:
- Linux kernel version 5.10
- U-Boot 2021.07
- OP-TEE version 3.14
- Trusted Firmware-A 2.5
- Trusted Firmware-M 1.4
Platform Support
----------------
- This Software release is tested on corstone1000 Fast Model platform (FVP) version 11.16.21
https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
Known Issues or Limitations
---------------------------
- No software support for external system(Cortex M3)
- No communication established between A35 and M0+
- Very basic functionality of booting Secure Enclave, Trusted Firmware-A , OP-TEE , u-boot and Linux are performed
Support
-------
For support email: support-subsystem-iot@arm.com
--------------
*Copyright (c) 2021, Arm Limited. All rights reserved.*
@@ -0,0 +1,239 @@
..
# Copyright (c) 2022, Arm Limited.
#
# SPDX-License-Identifier: MIT
######################
Software architecture
######################
*****************
ARM corstone1000
*****************
ARM corstone1000 is a reference solution for IoT devices. It is part of
Total Solution for IoT which consists of hardware and software reference
implementation.
Corstone1000 software plus hardware reference solution is PSA Level-2 ready
certified (`PSA L2 Ready`_) as well as System Ready IR certified(`SRIR cert`_).
More information on the corstone1000 subsystem product and design can be
found at:
`Arm corstone1000 Software`_ and `Arm corstone1000 Technical Overview`_.
This readme 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
***************
The software architecture of corstone1000 platform is a reference
implementation of Platform Security Architecture (`PSA`_) which provides
framework to build secure IoT devices.
The base system architecture of the platform is created from three
different tyes of systems: Secure Enclave, Host and External System.
Each subsystem provides different functionality to overall SoC.
.. image:: images/CorstoneSubsystems.png
:width: 720
:alt: CorstoneSubsystems
The Secure Enclave System, provides PSA Root of Trust (RoT) and
cryptographic functions. It is based on an Cortex-M0+ processor,
CC312 Cryptographic Accelerator and peripherals, such as watchdog and
secure flash. Software running on the Secure Enclave is isolated via
hardware for enhanced security. Communication with the Secure Encalve
is achieved using Message Hnadling Units (MHUs) and shared memory.
On system power on, the Secure Enclaves boots first. Its software
comprises of two boot loading stages, both based on mcuboot, and
TrustedFirmware-M(`TF-M`_) as runtime software. The software design on
Secure Enclave follows Firmware Framework for M class
processor (`FF-M`_) specification.
The Host System is based on ARM Cotex-A35 processor with standardized
peripherals to allow for the booting of a Linux OS. The Cortex-A35 has
the TrustZone technology that allows secure and non-secure security
states in the processor. The software design in the Host System follows
Firmware Framework for A class procseeor (`FF-A`_) specification.
The boot process follows Trusted Boot Base Requirement (`TBBR`_).
The Host Subsystem is taken out of reset by the Secure Enclave system
during its final stages of the initialization. The Host subsystem runs
FF-A Secure Partitions(based on `Trusted Services`_) and OPTEE-OS
(`OPTEE-OS`_) in the secure world, and u-boot(`u-boot repo`_) and
linux (`linux repo`_) in the non-secure world. The communication between
non-secure and the secure world is performed via FF-A messages.
An external system is intended to implement use-case specific
functionality. The system is based on Cortex-M3 and run RTX RTOS.
Communictaion between external system and Host(cortex-A35) is performed
using MHU as transport mechanism and rpmsg messaging system.
Overall, the corstone1000 architecture is designed to cover a range
of Power, Performance, and Area (PPA) applications, and enable extension
for use-case specific applications, for example, sensors, cloud
connectivitiy, and edge computing.
*****************
Secure Boot Chain
*****************
For the security of a device, it is essential that only authorized
software should run on the device. The corstone1000 boot uses a
Secure Boot 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 owner before it
is deployed into the field. In Corstone1000, the BL1 image of the secure
enclave and content of the CC312 OTP (One Time Programmable) memory
forms the RoT. The BL1 image exists in ROM (Read Only Memory).
.. image:: images/SecureBootChain.png
:width: 870
:alt: SecureBootChain
It is a lengthy chain to boot the software on corstone1000. On power on,
the secure enclave starts executing BL1 code from the ROM which is the RoT
of the device. Authentication of an image involves the steps listed below:
- Load image from flash to dynamic RAM.
- 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 verfied in the previous stages.
- The image is validated using the public key.
In the secure enclave, BL1 authenticates the BL2 and passes the execution
control. BL2 authenticates the initial boot loader of the host (Host BL2)
and TF-M. The execution control is now passed to TF-M. TF-M being the run
time executable of secure enclaves initializes itself and, in the end,
brings the host CPU out of rest. The host follows the boot standard defined
in the `TBBR`_ to authenticate the secure and non-secure software.
***************
Secure Services
***************
corstone1000 is unique in providing a secure environment to run a secure
workload. The platform has Trustzone technology in the Host subsystem but
it also has hardware isolated secure enclave environment to run such secure
workloads. In corstone1000, known Secure Services such as Crypto, Protected
Storage, Internal Trusted Storage and Attestation are available via PSA
Functional APIs in TF-M. There is no difference for a user communicating to
these services which are running on a secure enclave instead of the
secure world of the host subsystem. The below diagram presents the data
flow path for such calls.
.. image:: images/SecureServices.png
:width: 930
:alt: SecureServices
The SE Proxy SP (Secure Enclave Proxy Secure Partition) is a proxy partition
managed by OPTEE which forwards such calls to the secure enclave. The
solution relies on OpenAMP which uses shared memory and MHU interrupts as
a doorbell for communication between two cores. corstone1000 implements
isolation level 2. Cortex-M0+ MPU (Memory Protection Unit) is used to implement
isolation level 2.
For a user to define its own secure service, both the options of the host
secure world or secure encalve are available. It's a trade-off between
lower latency vs higher security. Services running on a secure enclave are
secure by real hardware isolation but have a higher latency path. In the
second scenario, the services running on the secure world of the host
subsystem have lower latency but virtual hardware isolation created by
Trustzone technology.
**********************
Secure Firmware Update
**********************
Apart from always booting the authorized images, it is also essential that
the device only accepts the authorized images in the firmware update
process. corstone1000 supports OTA (Over the Air) firmware updates and
follows Platform Security Firmware Update sepcification (`FWU`_).
As standardized into `FWU`_, the external flash is divided into two
banks of which one bank has currently running images and the other bank is
used for staging new images. There are four updatable units, i.e. Secure
Enclave's BL2 and TF-M, and Host's FIP (Firmware Image Package) and Kernel
Image. The new images are accepted in the form of a UEFI capsule.
.. image:: images/ExternalFlash.png
:width: 690
:alt: ExternalFlash
The Metadata Block in the flash has the below firmware update state machine.
TF-M runs an OTA service that is responsible for accepting and updating the
images in the flash. The communication between the UEFI Capsule update
subsystem and the OTA service follows the same data path explained above.
The OTA service writes the new images to the passive bank after successful
capsule verification. It changes the state of the system to trial state and
triggers the reset. Boot loaders in Secure Enclave and Host read the Metadata
block to get the information on the boot bank. In the successful trial stage,
the acknowledgment from the host moves the state of the system from trial to
regular. Any failure in the trial stage or system hangs leads to a system
reset. This is made sure by the use of watchdog hardware. The Secure Enclave's
BL1 has the logic to identify multiple resets and eventually switch back to the
previous good bank. The ability to revert to the previous bank is crucial to
guarantee the availability of the device.
.. image:: images/SecureFirmwareUpdate.png
:width: 430
:alt: SecureFirmwareUpdate
******************************
UEFI Runtime Support in u-boot
******************************
Implementation of UEFI boottime and runtime APIs require variable storage.
In corstone1000, these UEFI variables are stored in the Protected Storage
service. The below diagram presents the data flow to store UEFI variables.
The u-boot implementation of the UEFI subsystem uses the FF-A driver to
communicate with the SMM Service in the secure world. The backend of the
SMM service uses the proxy PS from the SE Proxy SP. From there on, the PS
calls are forwarded to the secure enclave as explained above.
.. image:: images/UEFISupport.png
:width: 590
:alt: UEFISupport
***************
References
***************
`ARM corstone1000 Search`_
`Arm security features`_
--------------
*Copyright (c) 2022, Arm Limited. All rights reserved.*
.. _Arm corstone1000 Technical Overview: https://developer.arm.com/documentation/102360/0000
.. _Arm corstone1000 Software: https://developer.arm.com/Tools%20and%20Software/Corstone-1000%20Software
.. _Arm corstone1000 Search: https://developer.arm.com/search#q=corstone-1000
.. _Arm security features: https://www.arm.com/architecture/security-features/platform-security
.. _linux repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
.. _FF-A: https://developer.arm.com/documentation/den0077/latest
.. _FF-M: https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Architect/DEN0063-PSA_Firmware_Framework-1.0.0-2.pdf?revision=2d1429fa-4b5b-461a-a60e-4ef3d8f7f4b4&hash=3BFD6F3E687F324672F18E5BE9F08EDC48087C93
.. _FWU: https://developer.arm.com/documentation/den0118/a/
.. _OPTEE-OS: https://github.com/OP-TEE/optee_os
.. _PSA: https://www.psacertified.org/
.. _PSA L2 Ready: https://www.psacertified.org/products/corstone-1000/
.. _SRIR cert: https://armkeil.blob.core.windows.net/developer/Files/pdf/certificate-list/arm-systemready-ir-certification-arm-corstone-1000.pdf
.. _TBBR: https://developer.arm.com/documentation/den0006/latest
.. _TF-M: https://www.trustedfirmware.org/projects/tf-m/
.. _Trusted Services: https://www.trustedfirmware.org/projects/trusted-services/
.. _u-boot repo: https://github.com/u-boot/u-boot.git
@@ -0,0 +1,685 @@
..
# Copyright (c) 2022, Arm Limited.
#
# SPDX-License-Identifier: MIT
##########
User Guide
##########
Notice
------
The corstone1000 software stack uses the `Yocto Project <https://www.yoctoproject.org/>`__ to build
a tiny Linux distribution suitable for the corstone1000 platform. The Yocto Project relies on the
`Bitbake <https://docs.yoctoproject.org/bitbake.html#bitbake-documentation>`__
tool as its build tool. Please see `Yocto Project documentation <https://docs.yoctoproject.org/>`__
for more information.
Prerequisites
-------------
These instructions assume your host PC is running Ubuntu Linux 18.04 or 20.04 LTS, with
at least 32GB of free disk space and 16GB of RAM as minimum requirement. The
following instructions expect that you are using a bash shell.
The following prerequisites must be available on the host system. To resolve these dependencies, run:
::
sudo apt-get update
sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \
build-essential chrpath socat cpio python3 python3-pip python3-pexpect \
xz-utils debianutils iputils-ping python3-git libegl1-mesa libsdl1.2-dev \
xterm zstd liblz4-tool picocom
sudo apt-get upgrade libstdc++6
Provided components
-------------------
Within the Yocto Project, each component included in the corstone1000 software stack is specified as
a `bitbake recipe <https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#recipes>`__.
The recipes specific to the corstone1000 BSP are located at:
``<_workspace>/meta-arm/meta-arm-bsp/``.
The Yocto machine config files for the corstone1000 FVP and FPGA are:
- ``<_workspace>/meta-arm/meta-arm-bsp/conf/machine/include/corstone1000.inc``
- ``<_workspace>/meta-arm/meta-arm-bsp/conf/machine/corstone1000-fvp.conf``
- ``<_workspace>/meta-arm/meta-arm-bsp/conf/machine/corstone1000-mps3.conf``
*****************
Software for Host
*****************
Trusted Firmware-A
==================
Based on `Trusted Firmware-A <https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git>`__
+----------+---------------------------------------------------------------------------------------------------+
| bbappend | <_workspace>/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.7.bbappend |
+----------+---------------------------------------------------------------------------------------------------+
| Recipe | <_workspace>/meta-arm/meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.7.bb |
+----------+---------------------------------------------------------------------------------------------------+
OP-TEE
======
Based on `OP-TEE <https://git.trustedfirmware.org/OP-TEE/optee_os.git>`__
+----------+------------------------------------------------------------------------------------+
| bbappend | <_workspace>/meta-arm/meta-arm-bsp/recipes-security/optee/optee-os_3.18.0.bbappend |
+----------+------------------------------------------------------------------------------------+
| Recipe | <_workspace>/meta-arm/meta-arm/recipes-security/optee/optee-os_3.18.0.bb |
+----------+------------------------------------------------------------------------------------+
U-Boot
=======
Based on `U-Boot <https://gitlab.com/u-boot>`__
+----------+---------------------------------------------------------------------+
| bbappend | <_workspace>/meta-arm/meta-arm/recipes-bsp/u-boot/u-boot_%.bbappend |
+----------+---------------------------------------------------------------------+
| Recipe | <_workspace>/poky/meta/recipes-bsp/u-boot/u-boot_2022.07.bb |
+----------+---------------------------------------------------------------------+
Linux
=====
The distro is based on the `poky-tiny <https://wiki.yoctoproject.org/wiki/Poky-Tiny>`__
distribution which is a Linux distribution stripped down to a minimal configuration.
The provided distribution is based on busybox and built using muslibc. The
recipe responsible for building a tiny version of linux is listed below.
+-----------+----------------------------------------------------------------------------------------------+
| bbappend | <_workspace>/meta-arm/meta-arm-bsp/recipes-kernel/linux/linux-yocto_%.bbappend |
+-----------+----------------------------------------------------------------------------------------------+
| Recipe | <_workspace>/poky/meta/recipes-kernel/linux/linux-yocto_5.19.bb |
+-----------+----------------------------------------------------------------------------------------------+
| defconfig | <_workspace>/meta-arm/meta-arm-bsp/recipes-kernel/linux/files/corstone1000/defconfig |
+-----------+----------------------------------------------------------------------------------------------+
**************************************************
Software for Boot Processor (a.k.a Secure Enclave)
**************************************************
Based on `Trusted Firmware-M <https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git>`__
+----------+-------------------------------------------------------------------------------------------------+
| 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_1.6.0.bb |
+----------+-------------------------------------------------------------------------------------------------+
Building the software stack
---------------------------
Create a new folder that will be your workspace and will henceforth be referred
to as ``<_workspace>`` in these instructions. To create the folder, run:
::
mkdir <_workspace>
cd <_workspace>
corstone1000 is a Bitbake based Yocto Project which uses kas and bitbake
commands to build the stack. To install kas tool, run:
::
pip3 install kas
In the top directory of the workspace ``<_workspace>``, run:
::
git clone https://git.yoctoproject.org/git/meta-arm -b CORSTONE1000-2022.04.07
To build corstone1000 image for MPS3 FPGA, run:
::
kas build meta-arm/kas/corstone1000-mps3.yml
Alternatively, to build corstone1000 image for FVP, run:
::
kas build meta-arm/kas/corstone1000-fvp.yml
The initial clean build will be lengthy, given that all host utilities are to
be built as well as the target images. This includes host executables (python,
cmake, etc.) and the required toolchain(s).
Once the build is successful, all output binaries will be placed in the following folders:
- ``<_workspace>/build/tmp/deploy/images/corstone1000-fvp/`` folder for FVP build;
- ``<_workspace>/build/tmp/deploy/images/corstone1000-mps3/`` folder for FPGA build.
Everything apart from the ROM firmware is bundled into a single binary, the
``corstone1000-image-corstone1000-{mps3,fvp}.wic.nopt`` file. The ROM firmware is the
``bl1.bin`` file.
The output binaries used by FVP are the following:
- The ROM firmware: ``<_workspace>/build/tmp/deploy/images/corstone1000-fvp/bl1.bin``
- The flash image: ``<_workspace>/build/tmp/deploy/images/corstone1000-fvp/corstone1000-image-corstone1000-fvp.wic.nopt``
The output binaries used by FPGA are the following:
- The ROM firmware: ``<_workspace>/build/tmp/deploy/images/corstone1000-mps3/bl1.bin``
- The flash image: ``<_workspace>/build/tmp/deploy/images/corstone1000-mps3/corstone1000-image-corstone1000-mps3.wic.nopt``
Flash the firmware image on FPGA
--------------------------------
The user should download the FPGA bit file image from `this link <https://developer.arm.com/tools-and-software/development-boards/fpga-prototyping-boards/download-fpga-images>`__
and under the section ``Arm® Corstone™-1000 for MPS3``.
The directory structure of the FPGA bundle is shown below.
::
Boardfiles
├── MB
│   ├── BRD_LOG.TXT
│   ├── HBI0309B
│   │   ├── AN550
│   │   │   ├── AN550_v1.bit
│   │   │   ├── an550_v1.txt
│   │   │   └── images.txt
│   │   ├── board.txt
│   │   └── mbb_v210.ebf
│   └── HBI0309C
│   ├── AN550
│   │   ├── AN550_v1.bit
│   │   ├── an550_v1.txt
│   │   └── images.txt
│   ├── board.txt
│   └── mbb_v210.ebf
├── SOFTWARE
│   ├── ES0.bin
│   ├── SE.bin
│   └── an550_st.axf
└── config.txt
Depending upon the MPS3 board version (printed on the MPS3 board) you should update the images.txt file
(in corresponding HBI0309x folder) so that the file points to the images under SOFTWARE directory.
Here is an example
::
;************************************************
; Preload port mapping *
;************************************************
; PORT 0 & ADDRESS: 0x00_0000_0000 QSPI Flash (XNVM) (32MB)
; PORT 0 & ADDRESS: 0x00_8000_0000 OCVM (DDR4 2GB)
; PORT 1 Secure Enclave (M0+) ROM (64KB)
; PORT 2 External System 0 (M3) Code RAM (256KB)
; PORT 3 Secure Enclave OTP memory (8KB)
; PORT 4 CVM (4MB)
;************************************************
[IMAGES]
TOTALIMAGES: 2 ;Number of Images (Max: 32)
IMAGE0PORT: 1
IMAGE0ADDRESS: 0x00_0000_0000
IMAGE0UPDATE: RAM
IMAGE0FILE: \SOFTWARE\bl1.bin
IMAGE1PORT: 0
IMAGE1ADDRESS: 0x00_00010_0000
IMAGE1UPDATE: AUTOQSPI
IMAGE1FILE: \SOFTWARE\cs1000.bin
OUTPUT_DIR = ``<_workspace>/build/tmp/deploy/images/corstone1000-mps3``
1. Copy ``bl1.bin`` from OUTPUT_DIR directory to SOFTWARE directory of the FPGA bundle.
2. Copy ``corstone1000-image-corstone1000-mps3.wic.nopt`` from OUTPUT_DIR directory to SOFTWARE
directory of the FPGA bundle and rename the wic image to ``cs1000.bin``.
**NOTE:** Renaming of the images are required because MCC firmware has
limitation of 8 characters before .(dot) and 3 characters after .(dot).
Now, copy the entire folder to board's SDCard and reboot the board.
Running the software on FPGA
----------------------------
On the host machine, open 3 minicom sessions. In case of Linux machine it will
be ttyUSB0, ttyUSB1, ttyUSB2 and it might be different on Window machine.
- ttyUSB0 for MCC, OP-TEE and Secure Partition
- ttyUSB1 for Boot Processor (Cortex-M0+)
- ttyUSB2 for Host Processor (Cortex-A35)
Run following commands to open minicom sessions on Linux:
::
sudo picocom -b 115200 /dev/ttyUSB0 # in one terminal
sudo picocom -b 115200 /dev/ttyUSB1 # in another terminal
sudo picocom -b 115200 /dev/ttyUSB2 # in another terminal.
Once the system boot is completed, you should see console
logs on the minicom sessions. Once the HOST(Cortex-A35) is
booted completely, user can login to the shell using
**"root"** login.
Running the software on FVP
---------------------------
An FVP (Fixed Virtual Platform) of the corstone1000 platform must be available to execute the
included run script.
The Fixed Virtual Platform (FVP) version 11.17_23 can be downloaded from the
`Arm Ecosystem FVPs`_ page. On this page, navigate to "Corstone IoT FVPs"
section to download the Corstone1000 platform FVP installer. Follow the
instructions of the installer and setup the FVP.
<_workspace>/meta-arm/scripts/runfvp --terminals=xterm <_workspace>/build/tmp/deploy/images/corstone1000-fvp/corstone1000-image-corstone1000-fvp.fvpconf
When the script is executed, three terminal instances will be launched, one for the boot processor
(aka Secure Enclave) processing element and two for the Host processing element. Once the FVP is
executing, the Boot Processor will start to boot, wherein the relevant memory contents of the .wic
file are copied to their respective memory locations within the model, enforce firewall policies
on memories and peripherals and then, bring the host out of reset.
The host will boot trusted-firmware-a, OP-TEE, U-Boot and then Linux, and present a login prompt
(FVP host_terminal_0):
::
corstone1000-fvp login:
Login using the username root.
Running test applications
-------------------------
**NOTE**: Running the SystemReady-IR tests described below requires the user to
work with USB sticks. In our testing, not all USB stick models work well with
MPS3 FPGA. Here are the USB sticks models that are stable in our test
environment.
- HP V165W 8 GB USB Flash Drive
- SanDisk Ultra 32GB Dual USB Flash Drive USB M3.0
- SanDisk Ultra 16GB Dual USB Flash Drive USB M3.0
**NOTE**:
Before running each of the tests in this chapter, the user should follow the
steps described in following section "Clean Secure Flash Before Testing" to
erase the SecureEnclave flash cleanly and prepare a clean board environment for
the testing.
Clean Secure Flash Before Testing (applicable to FPGA only)
-----------------------------------------------------------
To prepare a clean board environment with clean secure flash for the testing,
the user should prepare an image that erases the secure flash cleanly during
boot. Run following commands to build such image.
::
cd <_workspace>
git clone https://git.yoctoproject.org/git/meta-arm -b CORSTONE1000-2022.02.18
git clone https://git.gitlab.arm.com/arm-reference-solutions/systemready-patch.git
cp -f systemready-patch/embedded-a/corstone1000/erase_flash/0001-arm-bsp-trusted-firmware-m-corstone1000-Clean-Secure.patch meta-arm
cd meta-arm
git apply 0001-arm-bsp-trusted-firmware-m-corstone1000-Clean-Secure.patch
cd ..
kas build meta-arm/kas/corstone1000-mps3.yml
Replace the bl1.bin and cs1000.bin files on the SD card with following files:
- The ROM firmware: <_workspace>/build/tmp/deploy/images/corstone1000-mps3/bl1.bin
- The flash image: <_workspace>/build/tmp/deploy/images/corstone1000-mps3/corstone1000-image-corstone1000-mps3.wic.nopt
Now reboot the board. This step erases the Corstone1000 SecureEnclave flash
completely, the user should expect following message from TF-M log:
::
!!!SECURE FLASH HAS BEEN CLEANED!!!
NOW YOU CAN FLASH THE ACTUAL CORSTONE1000 IMAGE
PLEASE REMOVE THE LATEST ERASE SECURE FLASH PATCH AND BUILD THE IMAGE AGAIN
Then the user should follow "Building the software stack" to build a clean
software stack and flash the FPGA as normal. And continue the testing.
Run SystemReady-IR ACS tests
-----------------------------
ACS image contains two partitions. BOOT partition and RESULTS partition.
Following packages are under BOOT partition
* SCT
* FWTS
* BSA uefi
* BSA linux
* grub
* uefi manual capsule application
RESULTS partition is used to store the test results.
PLEASE MAKE SURE THAT THE RESULTS PARTITION IS EMPTY BEFORE YOU START THE TESTING. OTHERWISE THE TEST RESULTS
WILL NOT BE CONSISTENT
FPGA instructions for ACS image
-------------------------------
This section describes how the user can build and run Architecture Compliance
Suite (ACS) tests on Corstone1000.
First, the user should download the `Arm SystemReady ACS repository <https://github.com/ARM-software/arm-systemready/>`__.
This repository contains the infrastructure to build the Architecture
Compliance Suite (ACS) and the bootable prebuilt images to be used for the
certifications of SystemReady-IR. To download the repository, run command:
::
cd <_workspace>
git clone https://github.com/ARM-software/arm-systemready.git -b v21.09_REL1.0
Once the repository is successfully downloaded, the prebuilt ACS live image can be found in:
- ``<_workspace>/arm-systemready/IR/prebuilt_images/v21.07_0.9_BETA/ir_acs_live_image.img.xz``
**NOTE**: This prebuilt ACS image includes v5.13 kernel, which doesn't provide
USB driver support for Corstone1000. The ACS image with newer kernel version
and with full USB support for Corstone1000 will be available in the next
SystemReady release in this repository.
Then, the user should prepare a USB stick with ACS image. In the given example here,
we assume the USB device is ``/dev/sdb`` (the user should use ``lsblk`` command to
confirm). Be cautious here and don't confuse your host PC's own hard drive with the
USB drive. Run the following commands to prepare the ACS image in USB stick:
::
cd <_workspace>/arm-systemready/IR/scripts/output/
unxz ir_acs_live_image.img.xz
sudo dd if=ir_acs_live_image.img of=/dev/sdb iflag=direct oflag=direct bs=1M status=progress; sync
Once the USB stick with ACS image is prepared, the user should make sure that
ensure that only the USB stick with the ACS image is connected to the board,
and then boot the board.
FVP instructions for ACS image and run
---------------------------------------
Download acs image from:
- ``https://gitlab.arm.com/systemready/acs/arm-systemready/-/tree/linux-5.17-rc7/IR/prebuilt_images/v22.04_1.0-Linux-v5.17-rc7``
Use the below command to run the FVP with acs image support in the
SD card.
::
unxz ${<path-to-img>/ir_acs_live_image.img.xz}
<_workspace>/meta-arm/scripts/runfvp --terminals=xterm <_workspace>/build/tmp/deploy/images/corstone1000-fvp/corstone1000-image-corstone1000-fvp.fvpconf -- -C board.msd_mmc.p_mmc_file="${<path-to-img>/ir_acs_live_image.img}"
The test results can be fetched using following commands:
::
sudo mkdir /mnt/test
sudo mount -o rw,offset=<offset_2nd_partition> <path-to-img>/ir_acs_live_image.img /mnt/test/
fdisk -lu <path-to-img>/ir_acs_live_image.img
-> Device Start End Sectors Size Type
/home/emeara01/Downloads/ir_acs_live_image_modified.img1 2048 1050622 1048575 512M Microsoft basic data
/home/emeara01/Downloads/ir_acs_live_image_modified.img2 1050624 1153022 102399 50M Microsoft basic data
-> <offset_2nd_partition> = 1050624 * 512 (sector size) = 537919488
The FVP will reset multiple times during the test, and it might take up to 1 day to finish
the test. At the end of test, the FVP host terminal will halt showing a shell prompt.
Once test is finished, the FVP can be stoped, and result can be copied following above
instructions.
Common to FVP and FPGA
-----------------------
U-Boot should be able to boot the grub bootloader from
the 1st partition and if grub is not interrupted, tests are executed
automatically in the following sequence:
- SCT
- UEFI BSA
- FWTS
- BSA Linux
The results can be fetched from the ``acs_results`` partition of the USB stick (FPGA) / SD Card (FVP).
Manual capsule update test
--------------------------
The following steps describe running manual capsule update with the ``direct``
method.
Check the "Run SystemReady-IR ACS tests" section above to download and unpack the acs image file
- ``ir_acs_live_image.img.xz``
Download edk2 and generate capsule file:
::
git clone https://github.com/tianocore/edk2.git
edk2/BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o \
cs1k_cap --fw-version 1 --lsv 0 --guid \
e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose --update-image-index \
0 --verbose <binary_file>
The <binary_file> here should be a corstone1000-image-corstone1000-fvp.wic.nopt image for FVP and
corstone1000-image-corstone1000-mps3.wic.nopt for FPGA. And this input binary file
(capsule) should be less than 15 MB.
Based on the user's requirement, the user can change the firmware version
number given to ``--fw-version`` option (the version number needs to be >= 1).
Capsule Copy instructions for FPGA
-----------------------------------
The user should prepare a USB stick as explained in ACS image section (see above).
Place the generated ``cs1k_cap`` file in the root directory of the boot partition
in the USB stick. Note: As we are running the direct method, the ``cs1k_cap`` file
should not be under the EFI/UpdateCapsule directory as this may or may not trigger
the on disk method.
Capsule Copy instructions for FVP
---------------------------------
Run below commands to copy capsule into the
image file and run FVP software.
::
sudo mkdir /mnt/test
sudo mount -o rw,offset=<offset_1st_partition> <path-to-img>/ir_acs_live_image.img /mnt/test/
sudo cp cs1k_cap /mnt/test/
sudo umount /mnt/test
exit
<_workspace>/meta-arm/scripts/runfvp --terminals=xterm <_workspace>/build/tmp/deploy/images/corstone1000-fvp/corstone1000-image-corstone1000-fvp.fvpconf -- -C "board.msd_mmc.p_mmc_file ${<path-to-img>/ir_acs_live_image.img}"
Size of first partition in the image file is calculated in the following way. The data is
just an example and might vary with different ir_acs_live_image.img files.
::
fdisk -lu <path-to-img>/ir_acs_live_image.img
-> Device Start End Sectors Size Type
/home/emeara01/Downloads/ir_acs_live_image_modified.img1 2048 1050622 1048575 512M Microsoft basic data
/home/emeara01/Downloads/ir_acs_live_image_modified.img2 1050624 1153022 102399 50M Microsoft basic data
-> <offset_1st_partition> = 2048 * 512 (sector size) = 1048576
Common to FVP and FPGA
-----------------------
Reach u-boot then interrupt shell to reach EFI shell. Use below command at EFI shell.
::
FS0:
EFI/BOOT/app/CapsuleApp.efi cs1k_cap
For this test, the user can provide two capsules for testing: a positive test
case capsule which boots the board correctly, and a negative test case with an
incorrect capsule which fails to boot the host software.
In the positive case scenario, the user should see following log in TF-M log,
indicating the new capsule image is successfully applied, and the board boots
correctly.
::
...
SysTick_Handler: counted = 10, expiring on = 360
SysTick_Handler: counted = 20, expiring on = 360
SysTick_Handler: counted = 30, expiring on = 360
...
metadata_write: success: active = 1, previous = 0
accept_full_capsule: exit: fwu state is changed to regular
...
In the negative case scenario, the user should see appropriate logs in
the secure enclave terminal. If capsule pass initial verification, but fails
verifications performed during boot time, secure enclave will try new images
predetermined number of times (defined in the code), before reverting back to
the previous good bank.
::
...
metadata_write: success: active = 0, previous = 1
fwu_select_previous: in regular state by choosing previous active bank
...
*******************************************************
Linux distro install and boot (applicable to FPGA only)
*******************************************************
To test Linux distro install and boot, the user should prepare two empty USB sticks.
Download one of following Linux distro images:
- Debian installer image: https://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-dvd/
- OpenSUSE Tumbleweed installer image: http://download.opensuse.org/ports/aarch64/tumbleweed/iso/
- The user should look for a DVD Snapshot like openSUSE-Tumbleweed-DVD-aarch64-Snapshot20211125-Media.iso
Once the .iso file is downloaded, the .iso file needs to be flashed to your USB drive.
In the given example here, we assume the USB device is ``/dev/sdb`` (the user
should use `lsblk` command to confirm). Be cautious here and don't confuse your
host PC's own hard drive with the USB drive. Then copy the contents of an iso
file into the first USB stick, run:
::
sudo dd if=</path/to/iso_file> of=/dev/sdb iflag=direct oflag=direct status=progress bs=1M; sync;
Boot the MSP3 board with the first USB stick connected. Open following minicom sessions:
::
sudo picocom -b 115200 /dev/ttyUSB0 # in one terminal
sudo picocom -b 115200 /dev/ttyUSB2 # in another terminal.
Press <Ctrl+x>.
Now plug in the second USB stick, the distro installation process will start.
**NOTE:** Due to the performance limitation of Corstone1000 MPS3 FPGA, the
distro installation process can take up to 24 hours to complete.
Once installation is complete, unplug the first USB stick and reboot the board.
After successfully installing and booting the Linux distro, the user should see
a login prompt:
::
debian login:
Login with the username root.
Run psa-arch-test (applicable to both FPGA and FVP)
---------------------------------------------------
When running psa-arch-test on MPS3 FPGA, the user should make sure there is no
USB stick connected to the board. Power on the board and boot the board to
Linux. Then, the user should follow the steps below to run the psa_arch_tests.
When running psa-arch-test on Corstone1000 FVP, the user should follow the
instructions in `Running the software on FVP`_ section to boot Linux in FVP
host_terminal_0, and login using the username ``root``.
As a reference for the user's test results, the psa-arch-test report for `Corstone1000 software (CORSTONE1000-2022.02.18) <https://git.yoctoproject.org/meta-arm/tag/?h=CORSTONE1000-2022.02.18>`__
can be found in `here <https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/master/embedded-a/corstone1000>`__.
First, create a file containing SE_PROXY_SP UUID. Run:
::
echo 46bb39d1-b4d9-45b5-88ff-040027dab249 > sp_uuid_list.txt
Then, load FFA driver module into Linux kernel. Run:
::
load_ffa_debugfs.sh .
Then, check whether the FFA driver loaded correctly by using the following command:
::
cat /proc/modules | grep arm_ffa_user
The output should be:
::
arm_ffa_user 16384 - - Live 0xffffffc0084b0000 (O)
Now, run the PSA arch tests with following commands. The user should run the
tests in following order:
::
psa-iat-api-test
psa-crypto-api-test
psa-its-api-test
psa-ps-api-test
********************************************************
Linux distro: OpenSUSE Raw image installation (FVP Only)
********************************************************
Steps to download openSUSE Tumbleweed raw image:
- Go to: http://download.opensuse.org/ports/aarch64/tumbleweed/appliances/
- The user should look for a Tumbleweed-ARM-JeOS-efi.aarch64-* Snapshot, for example, ``openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2022.03.18-Snapshot20220331.raw.xz``
Once the .raw.xz file is downloaded, the raw image file needs to be extracted:
::
unxz <file-name.raw.xz>
The above command will generate a file ending with extension .raw image. Now, use the following command
to run FVP with raw image installation process.
::
<_workspace>/meta-arm/scripts/runfvp --terminals=xterm <_workspace>/build/tmp/deploy/images/corstone1000-fvp/corstone1000-image-corstone1000-fvp.fvpconf -- -C board.msd_mmc.p_mmc_file="${openSUSE raw image file path}"
After successfully installing and booting the Linux distro, the user should see
a openSUSE login prompt.
::
localhost login:
Login with the username 'root' and password 'linux'.
**************************************
Running the software on FVP on Windows
**************************************
If the user needs to run the Corstone1000 software on FVP on Windows. The user
should follow the build instructions in this document to build on Linux host
PC, and copy the output binaries to the Windows PC where the FVP is located,
and launch the FVP binary.
--------------
*Copyright (c) 2021, Arm Limited. All rights reserved.*
.. _Arm Ecosystem FVPs: https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
@@ -0,0 +1,12 @@
# Copyright (c) 2022, Arm Limited.
#
# SPDX-License-Identifier: MIT
# Read The Docs specific
jinja2==3.1.1
# Required to build the documentation
sphinx==4.5.0
sphinx_rtd_theme==1.0.0
sphinx-copybutton==0.5.0
docutils==0.17.1
@@ -3,6 +3,7 @@ From: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>
Date: Fri, 29 Apr 2022 20:07:50 +0100
Subject: [PATCH] tc: increase heap pages
Upstream-Status: Pending
Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>
---
/BUILD.gn | 2 +-
@@ -0,0 +1,182 @@
From 6cb8e5f83d53357fbc6e58c2c5c5a3450654f9e6 Mon Sep 17 00:00:00 2001
From: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Date: Wed, 19 Oct 2022 17:51:10 +0100
Subject: [PATCH] arm_ffa: add support for 32-bit direct messaging
add 32-bit mode for FFA_MSG_SEND_DIRECT_REQ and FFA_MSG_SEND_DIRECT_RESP
Tested-by: Mohamed Omar Asaker <mohamed.omarasaker@arm.com>
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Upstream-Status: Pending [Not submitted to upstream yet]
---
cmd/armffa.c | 2 +-
drivers/firmware/arm-ffa/core.c | 17 ++++++++++++++---
drivers/firmware/arm-ffa/sandbox.c | 2 +-
include/arm_ffa.h | 2 +-
lib/efi_loader/efi_capsule.c | 2 +-
lib/efi_loader/efi_setup.c | 2 +-
lib/efi_loader/efi_variable_tee.c | 2 +-
test/dm/ffa.c | 6 +++---
8 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/cmd/armffa.c b/cmd/armffa.c
index 9b56e8a830..9842b99181 100644
--- a/cmd/armffa.c
+++ b/cmd/armffa.c
@@ -129,7 +129,7 @@ int do_ffa_msg_send_direct_req(struct cmd_tbl *cmdtp, int flag, int argc,
return -EINVAL;
}
- ret = ffa_bus_ops_get()->sync_send_receive(part_id, &msg);
+ ret = ffa_bus_ops_get()->sync_send_receive(part_id, &msg, 1);
if (ret == 0) {
u8 cnt;
diff --git a/drivers/firmware/arm-ffa/core.c b/drivers/firmware/arm-ffa/core.c
index caba10caae..ba1ba59937 100644
--- a/drivers/firmware/arm-ffa/core.c
+++ b/drivers/firmware/arm-ffa/core.c
@@ -1032,6 +1032,7 @@ static int ffa_cache_partitions_info(void)
* ffa_msg_send_direct_req - FFA_MSG_SEND_DIRECT_{REQ,RESP} handler function
* @dst_part_id: destination partition ID
* @msg: pointer to the message data preallocated by the client (in/out)
+ * @is_smc64: select 64-bit or 32-bit FF-A ABI
*
* This is the runtime function that implements FFA_MSG_SEND_DIRECT_{REQ,RESP}
* FF-A functions.
@@ -1048,10 +1049,12 @@ static int ffa_cache_partitions_info(void)
*
* 0 on success. Otherwise, failure
*/
-static int __ffa_runtime ffa_msg_send_direct_req(u16 dst_part_id, struct ffa_send_direct_data *msg)
+static int __ffa_runtime ffa_msg_send_direct_req(u16 dst_part_id, struct ffa_send_direct_data *msg,
+ u8 is_smc64)
{
ffa_value_t res = {0};
int ffa_errno;
+ u64 req_mode, resp_mode;
if (!ffa_priv_data || !ffa_priv_data->invoke_ffa_fn)
return -EINVAL;
@@ -1060,8 +1063,16 @@ static int __ffa_runtime ffa_msg_send_direct_req(u16 dst_part_id, struct ffa_sen
if (!ffa_priv_data->partitions.count || !ffa_priv_data->partitions.descs)
return -ENODEV;
+ if(is_smc64) {
+ req_mode = FFA_SMC_64(FFA_MSG_SEND_DIRECT_REQ);
+ resp_mode = FFA_SMC_64(FFA_MSG_SEND_DIRECT_RESP);
+ } else {
+ req_mode = FFA_SMC_32(FFA_MSG_SEND_DIRECT_REQ);
+ resp_mode = FFA_SMC_32(FFA_MSG_SEND_DIRECT_RESP);
+ }
+
ffa_priv_data->invoke_ffa_fn((ffa_value_t){
- .a0 = FFA_SMC_64(FFA_MSG_SEND_DIRECT_REQ),
+ .a0 = req_mode,
.a1 = PREP_SELF_ENDPOINT_ID(ffa_priv_data->id) |
PREP_PART_ENDPOINT_ID(dst_part_id),
.a2 = 0,
@@ -1083,7 +1094,7 @@ static int __ffa_runtime ffa_msg_send_direct_req(u16 dst_part_id, struct ffa_sen
return 0;
}
- if (res.a0 == FFA_SMC_64(FFA_MSG_SEND_DIRECT_RESP)) {
+ if (res.a0 == resp_mode){
/*
* Message sent with response
* extract the return data
diff --git a/drivers/firmware/arm-ffa/sandbox.c b/drivers/firmware/arm-ffa/sandbox.c
index 16e1fdc809..8e8549441d 100644
--- a/drivers/firmware/arm-ffa/sandbox.c
+++ b/drivers/firmware/arm-ffa/sandbox.c
@@ -430,7 +430,7 @@ static int sandbox_ffa_sp_valid(u16 part_id)
* @{a0-a7} , res: The SMC call arguments and return structure.
*
* This is the function that emulates FFA_MSG_SEND_DIRECT_{REQ,RESP}
- * FF-A functions.
+ * FF-A functions. Only SMC 64-bit is supported in Sandbox.
*
* Emulating interrupts is not supported. So, FFA_RUN and FFA_INTERRUPT are not supported.
* In case of success FFA_MSG_SEND_DIRECT_RESP is returned with default pattern data (0xff).
diff --git a/include/arm_ffa.h b/include/arm_ffa.h
index 665413a0c5..4a7c59ff28 100644
--- a/include/arm_ffa.h
+++ b/include/arm_ffa.h
@@ -97,7 +97,7 @@ struct __packed ffa_send_direct_data {
struct ffa_bus_ops {
int (*partition_info_get)(const char *uuid_str,
u32 *parts_size, struct ffa_partition_info *buffer);
- int (*sync_send_receive)(u16 dst_part_id, struct ffa_send_direct_data *msg);
+ int (*sync_send_receive)(u16 dst_part_id, struct ffa_send_direct_data *msg, u8 is_smc64);
int (*rxtx_unmap)(void);
};
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 65e2fc8296..c479c53d04 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -591,7 +591,7 @@ static int __efi_runtime efi_corstone1000_buffer_ready_event(u32 capsule_image_s
msg.data1 = PREP_SEPROXY_SVC_ID(CORSTONE1000_SEPROXY_UPDATE_SVC_ID) |
PREP_SEPROXY_EVT(CORSTONE1000_BUFFER_READY_EVT); /* w4 */
- return ffa_bus_ops_get()->sync_send_receive(CORSTONE1000_SEPROXY_PART_ID, &msg);
+ return ffa_bus_ops_get()->sync_send_receive(CORSTONE1000_SEPROXY_PART_ID, &msg, 0);
}
#endif
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 6ccda175ff..416af8d663 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -153,7 +153,7 @@ static int efi_corstone1000_uboot_efi_started_event(void)
msg.data1 = PREP_SEPROXY_SVC_ID(CORSTONE1000_SEPROXY_UPDATE_SVC_ID) |
PREP_SEPROXY_EVT(CORSTONE1000_UBOOT_EFI_STARTED_EVT); /* w4 */
- return ffa_bus_ops_get()->sync_send_receive(CORSTONE1000_SEPROXY_PART_ID, &msg);
+ return ffa_bus_ops_get()->sync_send_receive(CORSTONE1000_SEPROXY_PART_ID, &msg, 0);
}
#endif
diff --git a/lib/efi_loader/efi_variable_tee.c b/lib/efi_loader/efi_variable_tee.c
index 7d9d577281..05f3c02911 100644
--- a/lib/efi_loader/efi_variable_tee.c
+++ b/lib/efi_loader/efi_variable_tee.c
@@ -201,7 +201,7 @@ static int __efi_runtime ffa_notify_mm_sp(void)
msg.data0 = FFA_SHARED_MM_BUFFER_OFFSET; /* x3 */
- ret = ffa_bus_ops_get()->sync_send_receive(mm_sp_id, &msg);
+ ret = ffa_bus_ops_get()->sync_send_receive(mm_sp_id, &msg, 1);
if (ret != 0)
return ret;
diff --git a/test/dm/ffa.c b/test/dm/ffa.c
index 052d5fc3f4..14b19cf71e 100644
--- a/test/dm/ffa.c
+++ b/test/dm/ffa.c
@@ -170,7 +170,7 @@ static int test_ffa_msg_send_direct_req(u16 part_id, struct unit_test_state *ut
struct ffa_send_direct_data msg = {0};
u8 cnt;
- ut_assertok(ffa_bus_ops_get()->sync_send_receive(part_id, &msg));
+ ut_assertok(ffa_bus_ops_get()->sync_send_receive(part_id, &msg, 1));
for (cnt = 0; cnt < sizeof(struct ffa_send_direct_data) / sizeof(u64); cnt++)
ut_assertok(((u64 *)&msg)[cnt] != 0xffffffffffffffff);
@@ -380,12 +380,12 @@ static int dm_test_ffa_nack(struct unit_test_state *uts)
ut_assertok(count != SANDBOX_SP_COUNT_PER_VALID_SERVICE);
/* send data to an invalid partition */
- ret = ffa_bus_ops_get()->sync_send_receive(part_id, &msg);
+ ret = ffa_bus_ops_get()->sync_send_receive(part_id, &msg, 1);
ut_assertok(ret != -EINVAL);
/* send data to a valid partition */
part_id = prvdata->partitions.descs[0].info.id;
- ret = ffa_bus_ops_get()->sync_send_receive(part_id, &msg);
+ ret = ffa_bus_ops_get()->sync_send_receive(part_id, &msg, 1);
ut_assertok(ret != 0);
return CMD_RET_SUCCESS;
--
2.17.1
@@ -48,7 +48,8 @@ SRC_URI:append:corstone1000 = " \
file://0028-Introduce-external-sys-driver-to-device-tree.patch \
file://0029-Add-mhu-and-rpmsg-client-to-u-boot-device-tree.patch \
file://0030-arm-corstone1000-esrt-support.patch \
"
file://0031-ffa-add-support-for-32-bit-direct-messaging.patch \
"
#
# FVP BASE
@@ -13,7 +13,8 @@ it around as necessary, and handling (most of) the new choices.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/e58b495bcc7deec3882be4bac910ed0bf6979674.1638530442.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Upstream-Status = Backport [https://lore.kernel.org/r/e58b495bcc7deec3882be4bac910ed0bf6979674.1638530442.git.robin.murphy@arm.com]
Upstream-Status: Backport [https://lore.kernel.org/r/e58b495bcc7deec3882be4bac910ed0bf6979674.1638530442.git.robin.murphy@arm.com]
Signed-off-by: Rupinderjit Singh <rupinderjit.singh@arm.com>
Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>
---
@@ -10,6 +10,7 @@ Fixes
noreturn void panic(const char *fmt, ...);
^
Upstream-Status: Pending
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
@@ -0,0 +1,230 @@
Upstream-Status: Pending [Not submitted to upstream yet]
Signed-off-by: Emekcan Aras <Emekcan.Aras@arm.com>
From c1bcab09bb5b73e0f7131d9433f5e23c3943f007 Mon Sep 17 00:00:00 2001
From: Satish Kumar <satish.kumar01@arm.com>
Date: Sat, 11 Dec 2021 11:06:57 +0000
Subject: [PATCH] corstone1000: port crypto config
Signed-off-by: Satish Kumar <satish.kumar01@arm.com>
%% original patch: 0002-corstone1000-port-crypto-config.patch
Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
---
.../nspe/pal_crypto_config.h | 81 +++++++++++++++----
1 file changed, 65 insertions(+), 16 deletions(-)
diff --git a/api-tests/platform/targets/tgt_dev_apis_linux/nspe/pal_crypto_config.h b/api-tests/platform/targets/tgt_dev_apis_linux/nspe/pal_crypto_config.h
index 218a94c69502..c6d4aadd8476 100755
--- a/api-tests/platform/targets/tgt_dev_apis_linux/nspe/pal_crypto_config.h
+++ b/api-tests/platform/targets/tgt_dev_apis_linux/nspe/pal_crypto_config.h
@@ -34,10 +34,14 @@
*
* Comment macros to disable the types
*/
+#ifndef TF_M_PROFILE_SMALL
+#ifndef TF_M_PROFILE_MEDIUM
#define ARCH_TEST_RSA
#define ARCH_TEST_RSA_1024
#define ARCH_TEST_RSA_2048
#define ARCH_TEST_RSA_3072
+#endif
+#endif
/**
* \def ARCH_TEST_ECC
@@ -50,11 +54,17 @@
* Requires: ARCH_TEST_ECC
* Comment macros to disable the curve
*/
+#ifndef TF_M_PROFILE_SMALL
#define ARCH_TEST_ECC
#define ARCH_TEST_ECC_CURVE_SECP192R1
+#ifndef TF_M_PROFILE_MEDIUM
#define ARCH_TEST_ECC_CURVE_SECP224R1
+#endif
#define ARCH_TEST_ECC_CURVE_SECP256R1
+#ifndef TF_M_PROFILE_MEDIUM
#define ARCH_TEST_ECC_CURVE_SECP384R1
+#endif
+#endif
/**
* \def ARCH_TEST_AES
@@ -78,10 +88,10 @@
*
* Comment macros to disable the types
*/
-#define ARCH_TEST_DES
-#define ARCH_TEST_DES_1KEY
-#define ARCH_TEST_DES_2KEY
-#define ARCH_TEST_DES_3KEY
+//#define ARCH_TEST_DES
+//#define ARCH_TEST_DES_1KEY
+//#define ARCH_TEST_DES_2KEY
+//#define ARCH_TEST_DES_3KEY
/**
* \def ARCH_TEST_RAW
@@ -104,7 +114,7 @@
*
* Enable the ARC4 key type.
*/
-#define ARCH_TEST_ARC4
+//#define ARCH_TEST_ARC4
/**
* \def ARCH_TEST_CIPHER_MODE_CTR
@@ -113,7 +123,11 @@
*
* Requires: ARCH_TEST_CIPHER
*/
+#ifndef TF_M_PROFILE_SMALL
+#ifndef TF_M_PROFILE_MEDIUM
#define ARCH_TEST_CIPHER_MODE_CTR
+#endif
+#endif
/**
* \def ARCH_TEST_CIPHER_MODE_CFB
@@ -138,7 +152,11 @@
*
* Requires: ARCH_TEST_CIPHER, ARCH_TEST_AES, ARCH_TEST_CIPHER_MODE_CTR
*/
+#ifndef TF_M_PROFILE_SMALL
+#ifndef TF_M_PROFILE_MEDIUM
#define ARCH_TEST_CTR_AES
+#endif
+#endif
/**
* \def ARCH_TEST_CBC_AES
@@ -157,7 +175,11 @@
*
* Comment macros to disable the types
*/
+#ifndef TF_M_PROFILE_SMALL
+#ifndef TF_M_PROFILE_MEDIUM
#define ARCH_TEST_CBC_NO_PADDING
+#endif
+#endif
/**
* \def ARCH_TEST_CFB_AES
@@ -177,11 +199,15 @@
*
* Comment macros to disable the types
*/
+#ifndef TF_M_PROFILE_SMALL
+#ifndef TF_M_PROFILE_MEDIUM
#define ARCH_TEST_PKCS1V15
#define ARCH_TEST_RSA_PKCS1V15_SIGN
#define ARCH_TEST_RSA_PKCS1V15_SIGN_RAW
#define ARCH_TEST_RSA_PKCS1V15_CRYPT
#define ARCH_TEST_RSA_OAEP
+#endif
+#endif
/**
* \def ARCH_TEST_CBC_PKCS7
@@ -190,7 +216,11 @@
*
* Comment macros to disable the types
*/
+#ifndef TF_M_PROFILE_SMALL
+#ifndef TF_M_PROFILE_MEDIUM
#define ARCH_TEST_CBC_PKCS7
+#endif
+#endif
/**
* \def ARCH_TEST_ASYMMETRIC_ENCRYPTION
@@ -227,21 +257,27 @@
*
* Comment macros to disable the types
*/
-// #define ARCH_TEST_MD2
-// #define ARCH_TEST_MD4
-#define ARCH_TEST_MD5
-#define ARCH_TEST_RIPEMD160
-#define ARCH_TEST_SHA1
+//#define ARCH_TEST_MD2
+//#define ARCH_TEST_MD4
+//#define ARCH_TEST_MD5
+//#define ARCH_TEST_RIPEMD160
+//#define ARCH_TEST_SHA1
+#ifndef TF_M_PROFILE_SMALL
#define ARCH_TEST_SHA224
+#endif
#define ARCH_TEST_SHA256
+#ifndef TF_M_PROFILE_SMALL
+#ifndef TF_M_PROFILE_MEDIUM
#define ARCH_TEST_SHA384
#define ARCH_TEST_SHA512
-// #define ARCH_TEST_SHA512_224
-// #define ARCH_TEST_SHA512_256
-// #define ARCH_TEST_SHA3_224
-// #define ARCH_TEST_SHA3_256
-// #define ARCH_TEST_SHA3_384
-// #define ARCH_TEST_SHA3_512
+#endif
+#endif
+//#define ARCH_TEST_SHA512_224
+//#define ARCH_TEST_SHA512_256
+//#define ARCH_TEST_SHA3_224
+//#define ARCH_TEST_SHA3_256
+//#define ARCH_TEST_SHA3_384
+//#define ARCH_TEST_SHA3_512
/**
* \def ARCH_TEST_HKDF
@@ -270,7 +306,12 @@
*
* Comment macros to disable the types
*/
+#ifndef TF_M_PROFILE_SMALL
+#ifndef TF_M_PROFILE_MEDIUM
#define ARCH_TEST_CMAC
+#endif
+#endif
+//#define ARCH_TEST_GMAC
#define ARCH_TEST_HMAC
/**
@@ -290,7 +331,11 @@
* Requires: ARCH_TEST_AES
*
*/
+#ifndef TF_M_PROFILE_SMALL
+#ifndef TF_M_PROFILE_MEDIUM
#define ARCH_TEST_GCM
+#endif
+#endif
/**
* \def ARCH_TEST_TRUNCATED_MAC
@@ -309,7 +354,9 @@
*
* Requires: ARCH_TEST_ECC
*/
+#ifndef TF_M_PROFILE_SMALL
#define ARCH_TEST_ECDH
+#endif
/**
* \def ARCH_TEST_ECDSA
@@ -317,7 +364,9 @@
* Enable the elliptic curve DSA library.
* Requires: ARCH_TEST_ECC
*/
+#ifndef TF_M_PROFILE_SMALL
#define ARCH_TEST_ECDSA
+#endif
/**
* \def ARCH_TEST_DETERMINISTIC_ECDSA
--
2.38.0
@@ -9,6 +9,7 @@ RDEPENDS:${PN} += "libts"
SRC_URI += "git://github.com/ARM-software/psa-arch-tests.git;name=psatest;protocol=https;branch=main;destsuffix=git/psatest \
file://0001-Pass-Yocto-build-settings-to-psa-arch-tests-native.patch;patchdir=../psatest \
file://0002-corstone1000-port-crypto-config.patch;patchdir=../psatest \
"
SRCREV_psatest = "451aa087a40d02c7d04778235014c5619d126471"