jim.lai/OpenBMC
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Your Name
2026-04-23 17:07:55 +08:00
commit b7e39e063b
16725 changed files with 1625565 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
meta-arm/meta-arm-bsp/documentation/corstone1000/change-log.rst
+230
View File
@@ -0,0 +1,230 @@
..
# Copyright (c) 2022-2023, Arm Limited.
#
# SPDX-License-Identifier: MIT
##########
Change Log
##########
This document contains a summary of the new features, changes and
fixes in each release of Corstone-1000 software stack.
***************
Version 2023.06
***************
Changes
=======
- GPT support (in TF-M, TF-A, U-boot)
- Use TF-M BL1 code as the ROM code instead of MCUboot (the next stage bootloader BL2 remains to be MCUboot)
- Secure Enclave uses CC312 OTP as the provisioning backend in FVP and FPGA
- NVMXIP block storage support in U-Boot
- Upgrading the SW stack recipes
- Upgrades for the U-Boot FF-A driver and MM communication
Corstone-1000 components versions
=================================
+-------------------------------------------+--------------------------------------------+
| arm-ffa-tee | 1.1.2-r0 |
+-------------------------------------------+--------------------------------------------+
| arm-ffa-user | 5.0.1-r0 |
+-------------------------------------------+--------------------------------------------+
| corstone1000-external-sys-tests | 1.0+gitAUTOINC+2945cd92f7-r0 |
+-------------------------------------------+--------------------------------------------+
| external-system | 0.1.0+gitAUTOINC+8c9dca74b1-r0 |
+-------------------------------------------+--------------------------------------------+
| linux-yocto | 6.1.25+gitAUTOINC+36901b5b29_581dc1aa2f-r0 |
+-------------------------------------------+--------------------------------------------+
| u-boot | 2023.01-r0 |
+-------------------------------------------+--------------------------------------------+
| optee-client | 3.18.0-r0 |
+-------------------------------------------+--------------------------------------------+
| optee-os | 3.20.0-r0 |
+-------------------------------------------+--------------------------------------------+
| trusted-firmware-a | 2.8.0-r0 |
+-------------------------------------------+--------------------------------------------+
| trusted-firmware-m | 1.7.0-r0 |
+-------------------------------------------+--------------------------------------------+
| ts-newlib | 4.1.0-r0 |
+-------------------------------------------+--------------------------------------------+
| ts-psa-{crypto, iat, its. ps}-api-test | 38cb53a4d9 |
+-------------------------------------------+--------------------------------------------+
| ts-sp-{se-proxy, smm-gateway} | 08b3d39471 |
+-------------------------------------------+--------------------------------------------+
Yocto distribution components versions
======================================
+-------------------------------------------+--------------------------------+
| meta-arm | mickledore |
+-------------------------------------------+--------------------------------+
| poky | mickledore |
+-------------------------------------------+--------------------------------+
| meta-openembedded | mickledore |
+-------------------------------------------+--------------------------------+
| busybox | 1.36.0-r0 |
+-------------------------------------------+--------------------------------+
| musl | 1.2.3+gitAUTOINC+7d756e1c04-r0 |
+-------------------------------------------+--------------------------------+
| gcc-arm-none-eabi-native | 11.2-2022.02 |
+-------------------------------------------+--------------------------------+
| gcc-cross-aarch64 | 12.2.rel1-r0 |
+-------------------------------------------+--------------------------------+
| openssl | 3.1.0-r0 |
+-------------------------------------------+--------------------------------+
******************
Version 2022.11.23
******************
Changes
=======
- Booting the External System (Cortex-M3) with RTX RTOS
- Adding MHU communication between the HOST (Cortex-A35) and the External System
- Adding a Linux application to test the External System
- Adding ESRT (EFI System Resource Table) support
- Upgrading the SW stack recipes
- Upgrades for the U-Boot FF-A driver and MM communication
Corstone-1000 components versions
=================================
+-------------------------------------------+------------+
| arm-ffa-tee | 1.1.1 |
+-------------------------------------------+------------+
| arm-ffa-user | 5.0.0 |
+-------------------------------------------+------------+
| corstone1000-external-sys-tests | 1.0 |
+-------------------------------------------+------------+
| external-system | 0.1.0 |
+-------------------------------------------+------------+
| linux-yocto | 5.19 |
+-------------------------------------------+------------+
| u-boot | 2022.07 |
+-------------------------------------------+------------+
| optee-client | 3.18.0 |
+-------------------------------------------+------------+
| optee-os | 3.18.0 |
+-------------------------------------------+------------+
| trusted-firmware-a | 2.7.0 |
+-------------------------------------------+------------+
| trusted-firmware-m | 1.6.0 |
+-------------------------------------------+------------+
| ts-newlib | 4.1.0 |
+-------------------------------------------+------------+
| ts-psa-{crypto, iat, its. ps}-api-test | 451aa087a4 |
+-------------------------------------------+------------+
| ts-sp-{se-proxy, smm-gateway} | 3d4956770f |
+-------------------------------------------+------------+
Yocto distribution components versions
======================================
+-------------------------------------------+---------------------+
| meta-arm | langdale |
+-------------------------------------------+---------------------+
| poky | langdale |
+-------------------------------------------+---------------------+
| meta-openembedded | langdale |
+-------------------------------------------+---------------------+
| busybox | 1.35.0 |
+-------------------------------------------+---------------------+
| musl | 1.2.3+git37e18b7bf3 |
+-------------------------------------------+---------------------+
| gcc-arm-none-eabi-native | 11.2-2022.02 |
+-------------------------------------------+---------------------+
| gcc-cross-aarch64 | 12.2 |
+-------------------------------------------+---------------------+
| openssl | 3.0.5 |
+-------------------------------------------+---------------------+
******************
Version 2022.04.04
******************
Changes
=======
- Linux distro openSUSE, raw image installation and boot in the FVP.
- SCT test support in FVP.
- Manual capsule update support in FVP.
******************
Version 2022.02.25
******************
Changes
=======
- Building and running psa-arch-tests on Corstone-1000 FVP
- Enabled smm-gateway partition in Trusted Service on Corstone-1000 FVP
- Enabled MHU driver in Trusted Service on Corstone-1000 FVP
- Enabled OpenAMP support in SE proxy SP on Corstone-1000 FVP
******************
Version 2022.02.21
******************
Changes
=======
- psa-arch-tests: recipe is dropped and merged into the secure-partitons recipe.
- psa-arch-tests: The tests are align with latest tfm version for psa-crypto-api suite.
******************
Version 2022.01.18
******************
Changes
=======
- psa-arch-tests: change master to main for psa-arch-tests
- U-Boot: fix null pointer exception for get_image_info
- TF-M: fix capsule instability issue for Corstone-1000
******************
Version 2022.01.07
******************
Changes
=======
- Corstone-1000: fix SystemReady-IR ACS test (SCT, FWTS) failures.
- U-Boot: send bootcomplete event to secure enclave.
- U-Boot: support populating Corstone-1000 image_info to ESRT table.
- U-Boot: add ethernet device and enable configs to support bootfromnetwork SCT.
******************
Version 2021.12.15
******************
Changes
=======
- Enabling Corstone-1000 FPGA support on:
- Linux 5.10
- OP-TEE 3.14
- Trusted Firmware-A 2.5
- Trusted Firmware-M 1.5
- Building and running psa-arch-tests
- Adding openamp support in SE proxy SP
- OP-TEE: adding smm-gateway partition
- U-Boot: introducing Arm FF-A and MM support
******************
Version 2021.10.29
******************
Changes
=======
- Enabling Corstone-1000 FVP support on:
- Linux 5.10
- OP-TEE 3.14
- Trusted Firmware-A 2.5
- Trusted Firmware-M 1.4
- Linux kernel: enabling EFI, adding FF-A debugfs driver, integrating ARM_FFA_TRANSPORT.
- U-Boot: Extending EFI support
- python3-imgtool: adding recipe for Trusted-firmware-m
- python3-imgtool: adding the Yocto recipe used in signing host images (based on MCUBOOT format)
--------------
*Copyright (c) 2022-2023, Arm Limited. All rights reserved.*
meta-arm/meta-arm-bsp/documentation/corstone1000/conf.py
+52
View File
@@ -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']
meta-arm/meta-arm-bsp/documentation/corstone1000/images/CorstoneSubsystems.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 77 KiB

meta-arm/meta-arm-bsp/documentation/corstone1000/images/ExternalFlash.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

meta-arm/meta-arm-bsp/documentation/corstone1000/images/SecureBootChain.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 93 KiB

meta-arm/meta-arm-bsp/documentation/corstone1000/images/SecureFirmwareUpdate.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 60 KiB

meta-arm/meta-arm-bsp/documentation/corstone1000/images/SecureServices.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 57 KiB

meta-arm/meta-arm-bsp/documentation/corstone1000/images/UEFISupport.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 65 KiB

meta-arm/meta-arm-bsp/documentation/corstone1000/index.rst
+16
View File
@@ -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
meta-arm/meta-arm-bsp/documentation/corstone1000/release-notes.rst
+199
View File
@@ -0,0 +1,199 @@
..
# Copyright (c) 2022-2023, Arm Limited.
#
# SPDX-License-Identifier: MIT
#############
Release notes
#############
*************************
Disclaimer
*************************
You expressly assume all liabilities and risks relating to your use or operation
of Your Software and Your Hardware designed or modified using the Arm Tools,
including without limitation, Your software or Your Hardware designed or
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 - 2023.06
***********************
Known Issues or Limitations
---------------------------
- FPGA supports Linux distro install and boot through installer. However, FVP only supports openSUSE raw image installation and boot.
- Due to the performance uplimit of MPS3 FPGA and FVP, some Linux distros like Fedora Rawhide can not boot on Corstone-1000 (i.e. user may experience timeouts or boot hang).
- PSA Crypto tests (psa-crypto-api-test command) take 30 minutes to complete for FVP and 1 hour for MPS3.
- Corstone-1000 SoC on FVP doesn't have a secure debug peripheral. It does on the MPS3 .
- The following limitations listed in the previous release are still applicable:
- UEFI Compliant - Boot from network protocols must be implemented -- FAILURE
- Known limitations regarding ACS tests - see previous release's notes.
Platform Support
-----------------
- This software release is tested on Corstone-1000 FPGA version AN550_v2
https://developer.arm.com/downloads/-/download-fpga-images
- This software release is tested on Corstone-1000 Fast Model platform (FVP) version 11.19_21
https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
**************************
Release notes - 2022.11.23
**************************
Known Issues or Limitations
---------------------------
- The external-system can not be reset individually on (or using) AN550_v1 FPGA release. However, the system-wide reset still applies to the external-system.
- FPGA supports Linux distro install and boot through installer. However, FVP only supports openSUSE raw image installation and boot.
- Due to the performance uplimit of MPS3 FPGA and FVP, some Linux distros like Fedora Rawhide can not boot on Corstone-1000 (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
- Below SCT FAILURE is a known issue when a terminal emulator (in the system where the user connects to serial ports) does not support 80x25 or 80x50 mode:
EFI_SIMPLE_TEXT_OUT_PROTOCOL.SetMode - SetMode() with valid mode -- FAILURE
- Known limitations regarding ACS tests: The behavior after running ACS tests on FVP is not consistent. Both behaviors are expected and are valid;
The system might boot till the Linux prompt. Or, the system might wait after finishing the ACS tests.
In both cases, the system executes the entire test suite and writes the results as stated in the user guide.
Platform Support
-----------------
- This software release is tested on Corstone-1000 FPGA version AN550_v1
https://developer.arm.com/downloads/-/download-fpga-images
- This software release is tested on Corstone-1000 Fast Model platform (FVP) version 11.19_21
https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
**************************
Release notes - 2022.04.04
**************************
Known Issues or Limitations
---------------------------
- FPGA 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 Corstone-1000 (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 Corstone-1000 FPGA version AN550_v1
- This software release is tested on Corstone-1000 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 Corstone-1000 FPGA: ACS tests (SCT, FWTS,
BSA), manual capsule update test, Linux distro install and boot.
Platform Support
----------------
- This software release is tested on Corstone-1000 FPGA version AN550_v1
- This software release is tested on Corstone-1000 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 Corstone-1000 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 Corstone-1000 FPGA version AN550_v1
- This software release is tested on Corstone-1000 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 Corstone-1000 FPGA version AN550_v1
- This software release is tested on Corstone-1000 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 Corstone-1000 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 Corstone-1000 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 Corstone-1000 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 technical support email: support-subsystem-iot@arm.com
For all security issues, contact Arm by email at arm-security@arm.com.
--------------
*Copyright (c) 2022-2023, Arm Limited. All rights reserved.*
meta-arm/meta-arm-bsp/documentation/corstone1000/software-architecture.rst
+242
View File
@@ -0,0 +1,242 @@
..
# Copyright (c) 2022-2023, Arm Limited.
#
# SPDX-License-Identifier: MIT
######################
Software architecture
######################
*****************
Arm Corstone-1000
*****************
Arm Corstone-1000 is a reference solution for IoT devices. It is part of
Total Solution for IoT which consists of hardware and software reference
implementation.
Corstone-1000 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 Corstone-1000 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 Corstone-1000 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 types 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 Handling Units (MHUs) and shared memory.
On system power on, the Secure Enclave boots first. Its software
comprises of a ROM code (TF-M BL1), Mcuboot BL2, 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 Corstone-1000 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 Corstone-1000 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 Corstone-1000, 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 Corstone-1000. 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 verified 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 TF-A BL2)
and TF-M. The execution control is now passed to TF-M. TF-M being the run
time executable of secure enclave which initializes itself and, at 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
***************
Corstone-1000 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 Corstone-1000, 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. Corstone-1000 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. Corstone-1000 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 initramfs bundle). 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 Corstone-1000, 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 U-Boot 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-2023, 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
meta-arm/meta-arm-bsp/documentation/corstone1000/user-guide.rst
+1254
View File
File diff suppressed because it is too large Load Diff
meta-arm/meta-arm-bsp/documentation/corstone500.md
+28
View File
@@ -0,0 +1,28 @@
# Corstone-500 Platform Support in meta-arm-bsp
## Howto Build and Run
### Configuration:
Use the kas
### Build:
``bash$ kas build kas/corstone500.yml
### Run:
Building using kas should have fetch the Fixed Virtual Platform for this
platform and installed at:
build/tmp/sysroots-components/x86_64/fvp-corstone500-native/usr/bin/./FVP_Corstone-500
with this in place is possible to launch the FVP using the runfvp inside the
scripts directory:
cd scripts
./runfvp ../build/tmp/deploy/images/corstone500/core-image-minimal-corstone500.fvpconf --console
this will output the console in the launching terminal
meta-arm/meta-arm-bsp/documentation/fvp-base.md
+30
View File
@@ -0,0 +1,30 @@
# Armv8-A Base Platform FVP Support in meta-arm-bsp
## Howto Build and Run
### Configuration:
In the local.conf file, `MACHINE` should be set:
```
MACHINE = "fvp-base"
```
### Build:
```
$ bitbake core-image-base
```
### Run:
The `fvp-base` machine has support for the `runfvp` script, so running is simple:
```
$ runfvp tmp/deploy/images/fvp-base/core-image-base-fvp-base.fvpconf
```
## Devices supported in the kernel
- serial
- virtio disk
- network
- watchdog
- rtc
## Devices not supported or not functional
None
meta-arm/meta-arm-bsp/documentation/fvp-baser-aemv8r64.md
+264
View File
@@ -0,0 +1,264 @@
Armv8-R AArch64 AEM FVP Support in meta-arm-bsp
===============================================
Overview
--------
Fixed Virtual Platforms (FVP) are complete simulations of an Arm system,
including processor, memory and peripherals. These are set out in a
"programmer's view", which gives you a comprehensive model on which to build
and test your software.
The Armv8-R AEM FVP is a free of charge Armv8-R Fixed Virtual Platform. It
supports the latest Armv8-R feature set.
This BSP implements a reference stack for the AArch64 support in the R-class
first announced with the Cortex-R82 processor:
https://developer.arm.com/ip-products/processors/cortex-r/cortex-r82
Fast Models Fixed Virtual Platforms (FVP) Reference Guide:
https://developer.arm.com/docs/100966/latest
BSP Support
-----------
The fvp-baser-aemv8r64 Yocto MACHINE supports the following BSP components,
where either a standard or Real-Time Linux kernel (PREEMPT\_RT) can be built
and run:
- FVP_Base_AEMv8R: v11.20.15
- boot-wrapper-aarch64: provides PSCI support
- U-Boot: v2022.07 - provides UEFI services
- Linux kernel: linux-yocto-5.15
- Linux kernel with PREEMPT\_RT support: linux-yocto-rt-5.15
Note that the Real-Time Linux kernel (PREEMPT\_RT) does not use the real-time
architectural extensions of the Armv8-R feature set.
High-Level Architecture
-----------------------
The diagram below shows the current boot flow:
+---------------------------------------------------------------+
| Linux kernel |
+---------------------------------------------------------------+
/|\ /|\
| |
| UEFI services |
| PSCI services |
\|/ |
+----------------+ | S-EL1
----| U-Boot |------------------------------|-----------
+----------------+ | S-EL2
/|\ |
| |
| |
| |
+--------------------------------------------------\|/----------+
| +----------------+ +----------------+ |
| boot-wrapper-aarch64 | Device tree | | PSCI handler | |
| +----------------+ +----------------+ |
+---------------------------------------------------------------+
The firmware binary (generated as `linux-system.axf`) includes
boot-wrapper-aarch64, the flattened device tree and U-Boot. U-Boot is configured
to automatically detect a virtio block device and boot the UEFI payload at the
path `/efi/boot/bootaa64.efi`. Using the standard build, the first partition
contains a Grub image at this path, which boots the Linux kernel at `/Image` on
the same partition. The second partition of the image contains the Linux root
file system.
There is no EL3 or non-secure world in the Armv8-R AArch64 architecture, so the
reset vector starts boot-wrapper-aarch64 at S-EL2. Boot-wrapper-aarch64 is
compiled with the `--enable-keep-el` flag, which causes it to boot U-Boot at
S-EL2 too. U-Boot is compiled with the `CONFIG_ARMV8_SWITCH_TO_EL1` flag, which
causes it to switch to S-EL1 before booting Linux.
The bundled device tree is passed to U-Boot via register x0. U-Boot passes the
same device tree to Linux via the UEFI system table.
Power state management is provided by PSCI services in boot-wrapper-aarch64.
Linux accesses the PSCI handler via HVC calls to S-EL2. U-Boot has been patched
to prevent it from overriding the exception vector at S-EL2. The PSCI handler
memory region is added to a `/memreserve/` node in the device tree.
Please note that the final firmware architecture for the fvp-baser-aemv8r64 is
not yet stabilized. The patches in this layer are provided for development and
evaluation purposes only, and should not be used in production firmware.
Quick start: Howto Build and Run
--------------------------------
### Host environment setup
The following instructions have been tested on hosts running Ubuntu 18.04 and
Ubuntu 20.04.
Install the required packages for the build host:
https://docs.yoctoproject.org/singleindex.html#required-packages-for-the-build-host
Kas is a setup tool for bitbake based projects. The minimal supported version
is 3.0, install it like so:
pip3 install --user --upgrade kas
For more details on kas, see https://kas.readthedocs.io/.
To build the images for the fvp-baser-aemv8r64 machine, you also need to accept
the EULA at
https://developer.arm.com/downloads/-/arm-ecosystem-fvps/eula
by setting the following environment variable:
ARM_FVP_EULA_ACCEPT="True"
**Note:** The host machine should have at least 50 GBytes of free disk space
for the next steps to work correctly.
### Fetch sources
To fetch and build the ongoing development of the software stack follow the
instructions on this document.
To fetch and build the version 1 (single core) find instructions at https://community.arm.com/developer/tools-software/oss-platforms/w/docs/633/release-1-single-core
To fetch and build the version 2 (linux smp) find instructions at https://community.arm.com/developer/tools-software/oss-platforms/w/docs/634/release-2---smp
Fetch the meta-arm repository into a build directory:
mkdir -p ~/fvp-baser-aemv8r64-build
cd ~/fvp-baser-aemv8r64-build
git clone https://git.yoctoproject.org/git/meta-arm
### Build
Building with the standard Linux kernel:
cd ~/fvp-baser-aemv8r64-build
export ARM_FVP_EULA_ACCEPT="True"
kas build meta-arm/kas/fvp-baser-aemv8r64-bsp.yml
Building with the Real-Time Linux kernel (PREEMPT\_RT):
cd ~/fvp-baser-aemv8r64-build
export ARM_FVP_EULA_ACCEPT="True"
kas build meta-arm/kas/fvp-baser-aemv8r64-rt-bsp.yml
### Run
To run an image after the build is done with the standard Linux kernel:
kas shell --keep-config-unchanged \
meta-arm/kas/fvp-baser-aemv8r64-bsp.yml \
--command "../layers/meta-arm/scripts/runfvp \
--console "
To run an image after the build is done with the Real-Time Linux kernel
(PREEMPT\_RT):
kas shell --keep-config-unchanged \
meta-arm/kas/fvp-baser-aemv8r64-rt-bsp.yml \
--command "../layers/meta-arm/scripts/runfvp \
--console "
**Note:** The terminal console login is `root` without password.
To finish the fvp emulation, you need to close the telnet session:
- Escape to telnet console with ``ctrl+]``.
- Run ``quit`` to close the session.
### Networking
The FVP is configured by default to use "user-mode networking", which simulates
an IP router and DHCP server to avoid additional host dependencies and
networking configuration. Outbound connections work automatically, e.g. by
running:
wget www.arm.com
Inbound connections require an explicit port mapping from the host. By default,
port 8022 on the host is mapped to port 22 on the FVP, so that the following
command will connect to an ssh server running on the FVP:
ssh root@localhost -p 8022
Note that user-mode networking does not support ICMP, so `ping` will not work.
For more information about user-mode networking, please see
https://developer.arm.com/documentation/100964/1117/Introduction-to-Fast-Models/User-mode-networking?lang=en
### File sharing between host and fvp
It is possible to share a directory between the host machine and the fvp using
the virtio P9 device component included in the kernel. To do so, create a
directory to be mounted from the host machine:
mkdir /path/to/host-mount-dir
Then, add the following parameter containing the path to the directory when
launching the model:
--parameter 'bp.virtiop9device.root_path=/path/to/host-mount-dir'
e.g. for the standard Linux kernel:
kas shell --keep-config-unchanged \
meta-arm/kas/fvp-baser-aemv8r64-bsp.yml \
--command "../layers/meta-arm/scripts/runfvp \
--console -- --parameter \
'bp.virtiop9device.root_path=/path/to/host-mount-dir'"
Once you are logged into the fvp, the host directory can be mounted in a
directory on the model using the following command:
mount -t 9p -o trans=virtio,version=9p2000.L FM /path/to/fvp-mount-dir
Devices supported in the kernel
-------------------------------
- serial
- virtio 9p
- virtio disk
- virtio network
- virtio rng
- watchdog
- rtc
Known Issues and Limitations
----------------------------
- Only PSCI CPU\_ON and CPU\_OFF functions are supported
- Linux kernel does not support booting from secure EL2 on Armv8-R AArch64
- Linux KVM does not support Armv8-R AArch64
- Device DMA memory cache-coherence issue: the FVP `cache_state_modelled`
parameter will affect the cache coherence behavior of peripherals’ DMA. When
users set `cache_state_modelled=1`, they also have to set
`cci400.force_on_from_start=1` to force the FVP to enable snooping on upstream
ports.
Change Log
----------
- Enabled the ability for U-Boot to apply device tree overlays
- Fixed bug in U-Boot that caused changes to the `memory` node in the device
tree to be ignored.
- Added boot-wrapper-aarch64 support for booting SMP payloads at S-EL2.
- Enabled testimage support by default.
- Added virtio\_rng to improve random number generation.
- Added U-Boot v2022.01 for UEFI support.
- Updated Linux kernel version from 5.14 to 5.15 for both standard and
Real-Time (PREEMPT\_RT) builds.
- Updated boot-wrapper-aarch64 revision and added support for booting U-Boot.
- Included boot-wrapper-aarch64 PSCI services in `/memreserve/` region.
- Fixed the counter frequency initialization in boot-wrapper-aarch64.
- Configured the FVP to use the default RAM size of 4 Gb
- Fixed PL011 and SP805 register sizes in the device tree.
- Added virtio\_net User Networking mode by default and removed instructions
about tap networking setup.
- Updated Linux kernel version from 5.10 to 5.14 for both standard and
Real-Time (PREEMPT\_RT) builds.
- Enabled SMP support via boot-wrapper-aarch64 providing the PSCI CPU\_ON and
CPU\_OFF functions.
- Introduced Armv8-R64 compiler flags.
- Added Linux PREEMPT\_RT support via linux-yocto-rt-5.10.
- Added support for file sharing with the host machine using Virtio P9.
- Added support for runfvp.
- Added performance event support (PMU) in the Linux device tree.
- Introduced the fvp-baser-aemv8r64 machine and its BSP composed of
boot-wrapper-aarch64 and linux-yocto-5.10 supporting serial, virtio disk,
virtio network, watchdog and rtc.
meta-arm/meta-arm-bsp/documentation/juno.md
+75
View File
@@ -0,0 +1,75 @@
# Juno Development Platform Support in meta-arm-bsp
## Howto Build and Run
### Configuration:
In the local.conf file, MACHINE should be set as follow:
MACHINE ?= "juno"
Juno is using a USB hard drive for root filesystem by default. The distribution
used must have ```usbhost``` and ```usbgadget``` in DISTRO_FEATURES (this is
the case in poky distribution).
### Build:
```bash$ bitbake core-image-minimal```
### Update Juno SD card:
The SD card content is generated during the build here:
tmp/deploy/images/juno/firmware-image-juno.tar.gz
Its content must be written on the Juno firmware SD card.
To do this:
- insert the sdcard of the Juno in an SD card reader and mount it:
```bash$ sudo mount /dev/sdx1 /mnt```
(replace sdx by the device of the SD card)
- erase its content and put the new one:
```bash$ sudo rm -rf /mnt/*```
```bash$ sudo tar --no-same-owner -xzf tmp/deploy/images/juno/firmware-image-juno.tar.gz -C /mnt/```
```bash$ sudo umount /mnt```
- reinsert the SD card in the Juno board
### Create an USB hard drive:
Linux root file system should be stored on the second partition of an USB
drive that must be plugged on the Juno Platform.
This partition should be initialized with the content of the filesystem
generated by yocto that you can find here:
tmp/deploy/images/juno/core-image-minimal-juno.tar.bz2
To do this
- Format a USB disk, create two primary partitions (ext4).
- mount the secondary partition
- untar tmp/deploy/images/juno/core-image-minimal-juno.tar.bz2 on to the
secondary partition.
### Run:
You must insert the SD card and the USB drive and power-on the Juno board.
The console should be available on the second serial line:
screen -L /dev/tty.usbserial 115200
On the first boot the images will be flashed which can take some time.
## Devices supported in the kernel
- serial
- usb
- network
- watchdog
- rtc
- mmc
### Untested:
- i2c
- dma
- pci
- sata
- sound
## Devices not supported or not functional
- framebuffer: not functional
The HDMI is not properly detected.
- GPU (no user land libraries).
The mali-midgard-kernel can be used to have a kernel driver
meta-arm/meta-arm-bsp/documentation/musca-b1.md
+15
View File
@@ -0,0 +1,15 @@
# Musca B1
## Overview
For a description of the hardware, go to
https://developer.arm.com/tools-and-software/development-boards/iot-test-chips-and-boards/musca-b-test-chip-board
For emulated hardware, go to
https://www.qemu.org/docs/master/system/arm/musca.html
## Building
In the local.conf file, MACHINE should be set as follows:
MACHINE ?= "musca-b1"
To build the trusted firmware-m:
```bash$ bitbake trusted-firmware-m```
meta-arm/meta-arm-bsp/documentation/n1sdp.md
+78
View File
@@ -0,0 +1,78 @@
# N1SDP Development Platform Support in meta-arm-bsp
## Overview
The N1SDP provides access to the Arm Neoverse N1 SoC. The N1SDP enables software development for key enterprise technology
and general Arm software development. The N1SDP consists of the N1 board containing the N1 SoC.
The N1 SoC contains two dual-core Arm Neoverse N1 processor clusters.
The system demonstrates Arm technology in the context of Cache-Coherent Interconnect for Accelerators (CCIX) protocol by:
- Running coherent traffic between the N1 SoC and an accelerator card.
- Coherent communication between two N1 SoCs.
- Enabling development of CCIX-enabled FPGA accelerators.
Further information on N1SDP can be found at
https://community.arm.com/developer/tools-software/oss-platforms/w/docs/458/neoverse-n1-sdp
## Configuration:
In the local.conf file, MACHINE should be set as follow:
MACHINE ?= "n1sdp"
## Building
```bash$ bitbake core-image-minimal```
## Running
# Update Firmware on SD card:
(*) To use n1sdp board in single chip mode, flash:
n1sdp-board-firmware_primary.tar.gz firmware.
(*) To use n1sdp board in multi chip mode, flash:
n1sdp-board-firmware_primary.tar.gz firmware to primary board,
n1sdp-board-firmware_secondary.tar.gz firmware to secondary board.
The SD card content is generated during the build here:
tmp/deploy/images/n1sdp/n1sdp-board-firmware_primary.tar.gz
tmp/deploy/images/n1sdp/n1sdp-board-firmware_secondary.tar.gz
Its content must be written on the N1SDP firmware SD card.
To do this:
- insert the sdcard of the N1SDP in an SD card reader and mount it:
```bash$ sudo mount /dev/sdx1 /mnt```
(replace sdx by the device of the SD card)
- erase its content and put the new one:
```bash$ sudo rm -rf /mnt/*```
```bash$ sudo tar --no-same-owner -xzf tmp/deploy/images/n1sdp/n1sdp-board-firmware_primary.tar.gz -C /mnt/```
```bash$ sudo umount /mnt```
- reinsert the SD card in the N1SDP board
Firmware tarball contains iofpga configuration files, scp and uefi binaries.
**NOTE**:
If the N1SDP board was manufactured after November 2019 (Serial Number greater
than 36253xxx), a different PMIC firmware image must be used to prevent
potential damage to the board. More details can be found in [1].
The `MB/HBI0316A/io_v123f.txt` file located in the microSD needs to be updated.
To update it, set the PMIC image (300k_8c2.bin) to be used in the newer models
by running the following commands on your host PC:
$ sudo umount /dev/sdx1
$ sudo mount /dev/sdx1 /mnt
$ sudo sed -i '/^MBPMIC: pms_0V85.bin/s/^/;/g' /mnt/MB/HBI0316A/io_v123f.txt
$ sudo sed -i '/^;MBPMIC: 300k_8c2.bin/s/^;//g' /mnt/MB/HBI0316A/io_v123f.txt
$ sudo umount /mnt
# Prepare an USB hard drive:
Grub boot partition is placed on first partition of the *.wic image,
Linux root file system is placed on the second partition of the *.wic image:
tmp/deploy/images/n1sdp/core-image-minimal-n1sdp.wic
This *.wic image should be copied to USB stick with simple dd call.
[1]: https://community.arm.com/developer/tools-software/oss-platforms/w/docs/604/notice-potential-damage-to-n1sdp-boards-if-using-latest-firmware-release
meta-arm/meta-arm-bsp/documentation/requirements.txt
+12
View File
@@ -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
meta-arm/meta-arm-bsp/documentation/tc1.md
+32
View File
@@ -0,0 +1,32 @@
# TC1 Platform Support in meta-arm-bsp
## Overview
The Total Compute platform provides an envelope for all of Arm's latest IP and
software solutions, optimised to work together. Further information can be
found on the Total Compute community page:
https://community.arm.com/developer/tools-software/oss-platforms/w/docs/606/total-compute
The user guide for TC1 platform with detailed instructions for
syncing and building the source code and running on TC1 Fixed Virtual Platform
for poky and android distributions is available at:
https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms.git/tree/docs/tc1/user-guide.rst
## Building
In the local.conf file, MACHINE should be set as follows:
MACHINE = "tc1"
To build the required binaries for tc1, run the commmand:
```bash$ bitbake tc-artifacts-image```
Trusted-firmware-a is the final component to be built with the rest of the
components dependent of it, therefore building tc-artifacts-image which depends
on trusted-firmware-a will build all the required binaries.
## Running
To run the produced binaries in a TC1 Fixed Virtual Platform please get
the run scripts at:
https://git.linaro.org/landing-teams/working/arm/model-scripts.git/
and follow the instructions in the user-guide.rst available in:
https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms.git/tree/docs/tc1/user-guide.rst
meta-arm/meta-arm-bsp/documentation/template.md
+19
View File
@@ -0,0 +1,19 @@
# *Hardware Name*
## Overview
*Brief summary of the hardware*
*Link to reference documentation*
## Building
*Any special steps required to build successfully beyond setting MACHINE*
*For example: corstone700 needs DISTRO=poky-tiny, musca only supports TF-M*
## Running
*A summary of how to deploy or execute the image*
*For example, an overview of the N1SDP SD structure, or FVP arguments*