mirrors/meta-arm
1
0
Fork 0
mirror of https://git.yoctoproject.org/meta-arm synced 2026-01-12 03:10:15 +00:00
Code Issues Projects Releases Wiki Activity

arm-bsp/documentation: corstone1000: Amend for CORSTONE1000-2025.05

Browse Source 
* Update software component recipe references
* Update Yocto Project release name
* Update Corstone-1000 release name
* Update release note
* Various other improvements

Signed-off-by: Hugues KAMBA MPIANA <hugues.kambampiana@arm.com>
Signed-off-by: Harsimran Singh Tungal <harsimransingh.tungal@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
This commit is contained in:
Hugues KAMBA MPIANA
2025-06-16 06:47:04 +01:00
committed by Jon Mason
parent 4f8d2f4b2f
commit 0acaf26833
8 changed files with 615 additions and 398 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
meta-arm-bsp/documentation/corstone1000/change-log.rst
View File

@@ -1,5 +1,5 @@
..
# Copyright (c) 2022-2024, Arm Limited.
# Copyright (c) 2022-2025, Arm Limited.
#
# SPDX-License-Identifier: MIT
@@ -10,6 +10,70 @@ Change Log
This document contains a summary of the new features, changes and
fixes in each release of Corstone-1000 software stack.
***************
Version 2025.05
***************
Changes
=======
- OP-TEE OS: Added support for v4.4
- Trusted Services: PSA-Crypto structures aligned with TF-M, added protobuf interface to crypto-sp
- Documentation: fixed typos, added host-level authentication section, enabled fly-out sidebar menu
- Das U-Boot: Reserved memory for RSS communication-pointer access protocol
- Linux Kernel: Upgraded kernel to v6.12, updated Upstream-Status notes for remoteproc patches
- Corstone-1000 image: Implemented IMAGE_ROOTFS_EXTRA_SPACE workaround
Corstone-1000 components versions
=================================
+-------------------------------------------+-------------------+
| linux-yocto | 6.12.30 |
+-------------------------------------------+-------------------+
| u-boot | 2023.07.02 |
+-------------------------------------------+-------------------+
| external-system | 0.1.0 |
+-------------------------------------------+-------------------+
| optee-client | 4.4.0 |
+-------------------------------------------+-------------------+
| optee-os | 4.4.0 |
+-------------------------------------------+-------------------+
| trusted-firmware-a | 2.11.0 |
+-------------------------------------------+-------------------+
| trusted-firmware-m | 2.1.1 |
+-------------------------------------------+-------------------+
| libts | 602be60719 |
+-------------------------------------------+-------------------+
| ts-newlib | 4.1.0 |
+-------------------------------------------+-------------------+
| ts-psa-{crypto, iat, its. ps}-api-test | 74dc6646ff |
+-------------------------------------------+-------------------+
| ts-sp-{se-proxy, smm-gateway} | 602be60719 |
+-------------------------------------------+-------------------+
Yocto distribution components versions
======================================
+-------------------------------------------+----------------+
| meta-arm | walnascar |
+-------------------------------------------+----------------+
| poky | ee0d8d8a61 |
+-------------------------------------------+----------------+
| meta-openembedded | 2169c9afcc |
+-------------------------------------------+----------------+
| meta-secure-core | 423bc85b05 |
+-------------------------------------------+----------------+
| busybox | 1.37.0 |
+-------------------------------------------+----------------+
| musl | 1.2.5 |
+-------------------------------------------+----------------+
| gcc-arm-none-eabi | 13.3.rel1 |
+-------------------------------------------+----------------+
| gcc-cross-aarch64 | 14.2.0 |
+-------------------------------------------+----------------+
| openssl | 3.4.1 |
+-------------------------------------------+----------------+
***************
Version 2024.11

BIN
meta-arm-bsp/documentation/corstone1000/images/Corstone1000SecureFlashFVP.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 43 KiB

BIN
meta-arm-bsp/documentation/corstone1000/images/Corstone1000SecureFlashMPS3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 44 KiB

BIN
meta-arm-bsp/documentation/corstone1000/images/ExternalFlash.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 63 KiB

After

Width:  |  Height:  |  Size: 58 KiB

BIN
meta-arm-bsp/documentation/corstone1000/images/FIPDiagram.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

18
meta-arm-bsp/documentation/corstone1000/release-notes.rst
View File

@@ -1,5 +1,5 @@
..
# Copyright (c) 2022-2024, Arm Limited.
# Copyright (c) 2022-2025, Arm Limited.
#
# SPDX-License-Identifier: MIT
@@ -19,6 +19,22 @@ 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 - 2025.05
***********************
Known Issues or Limitations
---------------------------
- Crypto isolation is not supported in the Secure world of Corstone-1000. Additionally, clients in
the Normal world are not isolated from one another.Therefore, if an end user wants to add a new
Secure Partition (SP) (such as a software TPM) that accesses the Crypto service via the SE-Proxy,
they are responsible for implementing their own isolation mechanisms to ensure proper security boundaries.
- DSTREAM debug probe may experience unreliable USB connectivity when used with Arm DS for secure debug.
This issue is under active investigation, and we are working to identify and resolve compatibility issues in a future update.
As a more stable alternative, the ULINKpro debug probe is recommended for use with Corstone-1000 in secure debug scenarios.
***********************
Release notes - 2024.11
***********************

492
meta-arm-bsp/documentation/corstone1000/software-architecture.rst
View File

@@ -16,180 +16,266 @@ 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 Corstone-1000 Software`_ and `Arm Corstone-1000 Technical Overview`_.
The combination of Corstone-1000 software and hardware reference solution is `PSA Level-2 ready
certified <psa_l2-ready_>`__ as well as `Arm SystemReady Devicetree certified <systemready-ir-certification_>`__.
This readme explicitly focuses on the software part of the solution and
More information on the Corstone-1000 subsystems product and design can be
found on `Arm Developer <arm-developer-cs1000-website_>`__.
This document explicitly focuses on the software part of the solution and
provides internal details on the software components. The reference
software package of the platform can be retrieved following instructions
present in the user-guide document.
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
implementation of `Platform Security Architecture <psa-certified-website_>`__ 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.
The base system architecture of the platform is created from three different types of subsystems:
- Secure Enclave
- Host System
- External System
Each subsystem provides different functionality to the overall system on a chip (SoC).
.. image:: images/CorstoneSubsystems.png
:width: 720
:alt: CorstoneSubsystems
Secure Enclave
==============
The Secure Enclave System, provides PSA Root of Trust (RoT) and
cryptographic functions. It is based on a 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 Secure Enclave boots first on system power on, it provides `PSA Root of Trust (RoT) <psa-certified-website_>`__ and
cryptographic functions. It is based on a Cortex-M0+ processor, CC312 Cryptographic Accelerator and
peripherals such as watchdog and secure flash.
.. image:: images/Corstone1000SecureFlashMPS3.png
:width: 400
:alt: Corstone1000SecureFlashMPS3
.. image:: images/Corstone1000SecureFlashFVP.png
:width: 400
:alt: Corstone1000SecureFlashFVP
Software running on the Secure Enclave is isolated via hardware for enhanced security.
Communication with the Secure Enclave is achieved using `Message Handling Units (MHUs) <arm-developer-mhu-website_>`__
and shared memory.
Its software components comprises:
- `Trusted Firmware-M (TF-M) BL1 <trusted-firmware-m-bl1-website_>`__
- `MCUboot <mcuboot-website_>`__
- `TrustedFirmware-M <trusted-firmware-m-website_>`__
The software design on the Secure Enclave follows `Arm Firmware Framework for M-Profile
processor <arm-fmw-framework-m-profile-pdf_>`__ (FF-M) specification.
Host System
===========
The Host System is based on ARM Cortex-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 processor (`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.
peripherals to allow booting a Linux-based operating system (OS). The Cortex-A35 has
the `TrustZone <arm-trustzone-for-cortex-a-website_>`__ technology that allows Secure and Non-secure security
states in the processor.
An external system is intended to implement use-case specific functionality.
The system is based on Cortex-M3 and run RTX RTOS. Communication between the
external system and Host (Cortex-A35) can be performed using MHU as transport
mechanism. The current software release supports switching on and off the
external system. Support for OpenAMP-based communication is under
development.
The boot process follows `Trusted Boot Base Requirements Client <trusted-board-boot-requirements-client-pdf_>`__.
The Host System is taken out of reset by the Secure Enclave system during its final stages of the
initialization.
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
connectivity, and edge computing.
In the Secure world, the Host System runs:
- FF-A Secure Partitions (based on `Trusted Services <trusted-services-website_>`__)
- `OP-TEE OS <op-tee-os-repository_>`__
In the Non-secure World, the Host System runs:
- `U-Boot <das-u-boot-repository_>`__
- `Linux kernel <linux-repository_>`__
The software design in the Host System follows `Arm Firmware Framework for Arm A-profile
<arm-fmw-framework-a-profile-pdf_>`__ (FF-A) specification.
The communication between Non-secure and the Secure world is performed via FF-A messages.
External System
===============
The External System is intended to implement use-case specific functionality.
The system is based on Cortex-M3 and runs `Keil RTX5 <keil-rtx5-website_>`__.
Communication between the external system and Host (Cortex-A35) can be performed using MHU as transport
mechanism. The current software release supports switching the External System ON and OFF.
The Corstone-1000 architecture is designed to cover a range of
`Power, Performance, and Area (PPA) <ppa-website_>`__ applications, and enable extension
for use-case specific applications, for example, sensors, cloud connectivity, and edge computing.
*****************
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 content of the ROM
and CC312 OTP (One Time Programmable) memory forms the RoT.
software should run on the device.
Verification of an image can happen either by comparing the computed and
stored hashes, or by checking the signature of the image if the image
is signed.
The Corstone-1000 boot uses a `Secure boot <arm-developer-secureboot-website_>`__ chain process
where an already authenticated image verifies and loads the following software in the chain.
For the boot chain process to work, the start of the chain should be trusted, forming the
Root of Trust (RoT) of the device. The RoT of the device is immutable in
nature and encoded into the device by the device manufacturer before it
is deployed into the field.
In Corstone-1000, the content of the ROM and CC312 One Time Programmable (OTP) memory forms the RoT.
Verification of an image can happen either by comparing the computed and stored hashes, or by
checking the signature of the image if the image is signed.
.. 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_1 code from the ROM which is the RoT
of the device. The BL1_1 is the immutable bootloader of the system, it handles
the provisioning on the first boot, hardware initialization and verification
of the next stage.
It is a lengthy chain to boot the software on Corstone-1000.
The BL1_2 code, hashes and keys are written into the OTP during the provisioning.
The next bootstage is the BL1_2 which is copied from the OTP into the RAM. The
BL1_1 also compares the BL1_2 hash with the hash saved to the OTP. The BL1_2
verifies and transfers control to the next bootstage which is the BL2. During the
verification, the BL1_2 compares the BL2 image's computed hash with the BL2 hash in
the OTP. The BL2 is MCUBoot in the system. BL2 can provision additional keys on the
first boot and it authenticates the initial bootloader of the host (Host Trusted Firmware-A BL2)
and TF-M by checking the signatures of the images.
The MCUBoot handles the image verification the following way:
TF-M BL1_1
==========
- Load image from a non-volatile memory 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.
On power-up, the Secure Enclave begins execution from TF-M BL1_1, which resides in ROM and serves as
the Root of Trust (RoT) for the device.
TF-M BL1_1 is the immutable bootloader and is responsible for:
- Provisioning the device during the first boot
- Performing hardware initialization
- Verifying the integrity and authenticity of the next stage in the boot chain
At boot time, TF-M BL1_1:
- Copies the TF-M BL1_2 image from OTP to RAM.
- Verifies the integrity of BL1_2 by comparing its computed hash with the hash stored in OTP.
TF-M BL1_2
==========
During provisioning, the TF-M BL1_2 binary, along with its hashes and cryptographic keys, is stored
in One-Time Programmable (OTP) memory.
Once verified, TF-M BL1_2:
- Takes control and verifies the next stage in the boot chain, which is TF-M BL2.
- Computes the hash of the BL2 image and compares it with the BL2 hash stored in OTP to ensure
integrity before transferring execution to BL2.
.. note::
The TF-M BL1 design details can be found in the `TF-M design documents <trusted-firmware-m-bl1-website_>`_.
.. important::
Corstone-1000 has some differences compared to this design due to memory (OTP/ROM)
limitations:
- BL1_1 code size is larger than needed because it handles most of the hardware initialization instead of the BL1_2.
- BL1_2 cannot be updated during provisioning time because the provisioning bundle that contains its code is located in the ROM.
- BL1_2 does not use the post-quantum LMS verification.
- BL2 cannot be updated because it is verified by comparing the computed hash to the hash stored in the OTP.
TF-M BL2
========
In this system, TF-M BL2 refers to MCUBoot.
On the first boot, MCUBoot can provision additional cryptographic keys. It is responsible for authenticating both:
- TF-M (Trusted Firmware-M), and
- The initial bootloader of the Host system, `Trusted Firmware-A (TF-A) BL2 <trusted-firmware-a-bl2-website_>`__
This authentication is done by verifying the digital signatures of the respective images.
MCUBoot performs image verification in the following steps:
#. Load the image from non-volatile memory into RAM.
#. Validate the image's signature using the corresponding public key.
.. note::
The public key present in the image header is validated by comparing with the hash.
Depending on the image, the hash of the public key is either stored in the OTP or part
of the software which is being already verified in the previous stages.
The execution control is passed to TF-M after the verification. TF-M being
the runtime executable of the Secure Enclave which initializes itself and, at the end,
brings the host CPU out of rest.
The execution control is passed to TF-M after the verification.
As the runtime executable of the Secure Enclave, TF-M initializes itself before
bringing the Host system out of reset.
The TF-M BL1 design details and reasoning can be found in the `TF-M design documents
<https://tf-m-user-guide.trustedfirmware.org/design_docs/booting/bl1.html>`_.
The Corstone-1000 has some differences compared to this design due to memory (OTP/ROM)
limitations:
- The provisioning bundle that contains the BL1_2 code is located in the ROM.
This means the BL1_2 cannot be updated during provisioning time.
- The BL1_1 handles most of the hardware initialization instead of the BL1_2. This
results in a bigger BL1_1 code size than needed.
- The BL1_2 does not use the post-quantum LMS verification. The BL2 is verified by
comparing the computed hash to the hash which is stored in the OTP. This means the
BL2 is not updatable.
Host System Authentication
==========================
Host Level Authentication
=========================
The Host system follows the boot standard defined in the `Trusted Board Boot Requirements Client <trusted-board-boot-requirements-client-pdf_>`__
to authenticate the Secure and Non-secure software.
The host follows the boot standard defined in the `TBBR`_ to authenticate the
secure and non-secure software.
The `Firmware Image Package (FIP) <trusted-firmware-a-fip-guide_>`__ packs bootloader images and
other payloads into a single archive.
The Firmware Image Package (FIP) packs bootloader images and other payloads into a
single archive. The FIP for Corstone-1000 contains:
.. image:: images/FIPDiagram.png
:alt: FIPDiagram
- Trusted Boot Firmware BL2
- EL3 Runtime Firmware BL31
- Secure Payload BL32 (Trusted OS)
- Non-Trusted Firmware BL33,
- TOS_FW_CONFIG
- key & content certificates
The FIP for Corstone-1000 contains:
TF-M does not check the FIP signature, it only checks the Trsuted Firmware-A (TF-A) BL2's signature
in the FIP. The TF-M BL2 (MCUBoot) gets the offset for the TF-A BL2 by parsing the
GUID Partition Table (GPT) to find the FIP offset, then parsing the FIP to get the offset for the
TF-A BL2. Finally, MCUBoot loads and validates the TF-A BL2 image.
- Trusted firmware-A BL2
- AP EL3 Runtime firmware, BL31 image
- AP Secure Payload, BL32 image
- AP Normal world firmware -U-boot, BL33 image
- Trusted OS Firmware configuration file used by Trusted OS (BL32), TOS_FW_CONFIG
- Key certificates
- Content certificates
The implicitly trusted components are:
- A SHA-256 hash of the Root of Trust Public Key (ROTPK). A development ROTPK
is used and its hash embedded into the TF-A BL2 image (only for development purposes).
This public key is provided by TF-A source-code.
- In case of Corstone-1000, the TF-A BL2 image, can be trusted because it has been verified
by the secure enclave's BL2 (MCUBoot) before starting TF-A.
To load and validate TF-A BL2, TF-M BL2 first parses the GUID Partition Table (GPT)
to locate the FIP. It then determines the offset of TF-A BL2 within the FIP.
.. note::
TF-M does not check the FIP signature, it only checks the TF-A BL2's signature in the FIP.
.. important::
The implicitly trusted components are:
- A SHA-256 hash of the Root of Trust Public Key (ROTPK) -
For development purposes, a development ROTPK is used and its hash embedded into the TF-A BL2 image.
This public key is provided by the TF-A source code.
- TF-A BL2 image - it can be trusted because it has been verified by TF-M BL2 before starting TF-A.
The remaining components in the Chain of Trust (CoT) are either certificates or bootloader images.
BL images authentication using the FIP certificates:
Bootloader Authentication
-------------------------
- The certificates are categorized as "Key" and "Content" certificates.
The key certificates are used to verify public keys which have been used to sign
content certificates. The content certificates are used to store the hash of a
boot loader image. An image can be authenticated by calculating its hash and
matching it with the hash extracted from the content certificate.
The FIP contains two types of certificates:
Verification of the certificates:
- **Content Certificates** - used to store the hash of a bootloader image.
- **Key Certificates** - used to verify public keys used to sign Content Certificates.
- The public keys defined in the Trusted Key certificate are used to verify the
later certificates in the CoT process. The Trusted Key certificate is
verified with the Root of Trust Public Key.
The Host system bootloader images are authenticated by computing their hash and comparing it to the corresponding hash found in the Content Certificate.
Certificates Verification
-------------------------
The public keys defined in the Trusted Key Certificate are used to verify the later certificates in
the CoT process. The Trusted Key Certificate is verified with the Root of Trust Public Key.
UEFI Authenticated Variables
----------------------------
For UEFI Secure Boot, authenticated variables can be accessed from the secure flash.
The feature has been integrated in U-Boot, which authenticates the images as per the UEFI
@@ -199,82 +285,74 @@ specification before executing them.
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.
Corstone-1000 is unique in offering a secure environment for running trusted workloads.
While the Host system includes TrustZone technology, the platform also features a hardware-isolated
Secure Enclave, specifically designed to execute these secure workloads.
In Corstone-1000, essential Secure Services—such as Cryptography, Protected Storage,
Internal Trusted Storage, and Attestation—are provided through PSA Functional APIs implemented in TF-M.
From the user's perspective, there is no difference when communicating with these services,
whether they run in the Secure Enclave or in the Secure world of the Host system.
The diagram below illustrates the data flow for such calls.
.. image:: images/SecureServices.png
:width: 930
:alt: SecureServices
The Secure Enclave Proxy Secure Partition (SE Proxy SP) is a proxy managed by OP-TEE that forwards
Secure Service calls to the Secure Enclave. This communication uses the `RSE communication protocol <https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html>`_.
While the protocol supports shared memory and MHU interrupts as a doorbell mechanism between cores,
in Corstone-1000, the entire message is currently transmitted through the MHU channels.
Corstone-1000 implements Isolation Level 2 using the Cortex-M0+ Memory Protection Unit (MPU).
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 the `RSE communication protocol
<https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html>`_
which is a lightweight serialization of the psa_call() API. It can use shared
memory and MHU interrupts as a doorbell for communication between two cores
but currently the whole message is forwarded through the MHU channels in Corstone-1000.
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.
Users can define their own secure services to run either in the Host system's Secure World or in
the Secure Enclave. This choice involves a trade-off between latency and security.
Services running in the Secure Enclave benefit from strong, hardware-enforced isolation,
offering higher security but at the cost of increased latency. In contrast, services running in the
Host Secure World experience lower latency, but rely on TrustZone technology for virtualized isolation,
which offers comparatively less robust security.
**********************
Secure Firmware Update
**********************
Apart from always booting the authorized images, it is also essential that
the device only accepts the authorized (signed) images in the firmware update
process. Corstone-1000 supports OTA (Over the Air) firmware updates and
follows Platform Security Firmware Update specification (`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.
In addition to always booting authorized images, it is equally important that the device only accepts
authorized (signed) images during the firmware update process. Corstone-1000 supports over-the-air (OTA)
firmware updates and complies with the `Platform Security Firmware Update for the A-profile Arm Architecture <platform-security-fwu-for-a-profile-pdf_>`__
specification.
As defined in the specification, the external flash is divided into two banks: one bank holds the
currently running images, while the other is used to stage new images.
There are four updatable components: **BL2**, **TF-M**, **the FIP** and **the Kernel Image** (the initramfs bundle).
New images are delivered and accepted in the form of UEFI capsules.
.. image:: images/ExternalFlash.png
:width: 690
:alt: ExternalFlash
When Firmware update is triggered, U-Boot verifies the capsule by checking the
capsule signature, version number and size. Then it signals the Secure Enclave
that can start writing UEFI capsule into the flash.
When a firmware update is triggered, U-Boot begins by verifying the UEFI capsule by checking its signature,
version number, and size. After successful verification, it signals the Secure Enclave, which then
starts writing the capsule contents to flash memory.
Once this operation finishes, Secure Enclave resets the entire system.
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.
Once the write operation is complete, the Secure Enclave resets the entire system. The update process
is tracked using a state machine stored in the Metadata Block within flash. TF-M runs an OTA service
that is responsible for verifying and updating the images in the passive flash bank. Communication
between the UEFI capsule update subsystem and the OTA service follows the same data path described
earlier. After verifying the capsule, the OTA service writes the new images to the passive bank,
updates the system state to 'trial,' and initiates a 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.
During boot, the bootloaders in both the Secure Enclave and the Host system read the Metadata Block to
determine which bank to boot from. If the trial boot succeeds, the Host system sends an acknowledgment
that transitions the system state from 'trial' to 'regular.' If the system fails during the trial phase
or hangs, a watchdog timer triggers a reset. The Secure Enclave’s BL1 contains logic to detect multiple
resets and can revert to the previously known-good bank. This fallback mechanism is essential to ensure
the device remains available and functional.
.. image:: images/SecureFirmwareUpdate.png
@@ -287,13 +365,15 @@ guarantee the availability of the device.
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.
The implementation of UEFI boot-time and runtime APIs requires persistent variable storage. In
Corstone-1000, UEFI variables are stored using the Protected Storage (PS) service.
The diagram below illustrates the data flow for storing UEFI variables. U-Boot’s UEFI subsystem
communicates with the Secure World using the U-Boot FF-A driver, which interfaces with the `UEFI System Management Mode (SMM) service <trusted-services-uefi-smm-website_>`__.
The SMM service provides support for the UEFI System Management Mode. This support is implemented by the SMM Gateway secure partition.
The SMM service then uses the Proxy Protected Storage (PS) provided by the SE Proxy SP.
These PS calls are forwarded to the Secure Enclave, following the communication path described earlier.
.. image:: images/UEFISupport.png
@@ -301,30 +381,38 @@ calls are forwarded to the Secure Enclave as explained above.
:alt: UEFISupport
***************
**********
References
***************
`ARM Corstone-1000 Search`_
`Arm security features`_
**********
* `Arm Developer <arm-developer-cs1000-search_>`__
* `Arm Security Architectures <arm-architecture-security-features-platform-security_>`_
--------------
*Copyright (c) 2022-2024, Arm Limited. All rights reserved.*
*Copyright (c) 2022-2025, Arm Limited. All rights reserved.*
.. _Arm Corstone-1000 Technical Overview: https://developer.arm.com/documentation/102360/0000
.. _Arm Corstone-1000 Software: https://developer.arm.com/Tools%20and%20Software/Corstone-1000%20Software
.. _Arm Corstone-1000 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/architectures/Firmware%20Framework%20for%20M-Profile
.. _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
.. _arm-developer-cs1000-website: https://developer.arm.com/Tools%20and%20Software/Corstone-1000%20Software
.. _arm-developer-cs1000-search: https://developer.arm.com/search#q=corstone-1000
.. _arm-developer-mhu-website: https://developer.arm.com/documentation/ka005129/latest/#:~:text=An%20MHU%20is%20a%20device,that%20a%20message%20is%20available
.. _arm-developer-secureboot-website: https://developer.arm.com/documentation/PRD29-GENC-009492/c/TrustZone-Software-Architecture/Booting-a-secure-system/Secure-boot
.. _arm-architecture-security-features-platform-security: https://www.arm.com/architecture/security-features/platform-security
.. _linux-repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
.. _arm-trustzone-for-cortex-a-website: https://www.arm.com/technologies/trustzone-for-cortex-a
.. _arm-fmw-framework-a-profile-pdf: https://developer.arm.com/documentation/den0077/latest
.. _arm-fmw-framework-m-profile-pdf: https://developer.arm.com/architectures/Firmware%20Framework%20for%20M-Profile
.. _platform-security-fwu-for-a-profile-pdf: https://developer.arm.com/documentation/den0118/a/
.. _op-tee-os-repository: https://github.com/OP-TEE/optee_os
.. _psa-certified-website: https://www.psacertified.org/
.. _psa_l2-ready: https://www.psacertified.org/products/corstone-1000/
.. _systemready-ir-certification: https://armkeil.blob.core.windows.net/developer/Files/pdf/certificate-list/arm-systemready-ve-arm-neoverse.pdf
.. _trusted-board-boot-requirements-client-pdf: https://developer.arm.com/documentation/den0006/latest
.. _trusted-firmware-m-website: https://www.trustedfirmware.org/projects/tf-m/
.. _trusted-firmware-m-bl1-website: https://trustedfirmware-m.readthedocs.io/en/latest/design_docs/booting/bl1.html
.. _trusted-firmware-a-bl2-website: https://developer.arm.com/documentation/108028/0000/RD-TC22-software/Software-components/AP-firmware/Trusted-firmware-A-BL2
.. _trusted-firmware-a-fip-guide: https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html#firmware-image-package-fip
.. _trusted-services-website: https://www.trustedfirmware.org/projects/trusted-services/
.. _trusted-services-uefi-smm-website: https://trusted-services.readthedocs.io/en/integration/services/uefi-smm-services.html#
.. _das-u-boot-repository: https://github.com/u-boot/u-boot.git
.. _keil-rtx5-website: https://developer.arm.com/Tools%20and%20Software/Keil%20MDK/RTX5%20RTOS
.. _ppa-website: https://developer.arm.com/documentation/102738/0100/Power--performance--and-area-analysis
.. _mcuboot-website: https://docs.mcuboot.com/

437
meta-arm-bsp/documentation/corstone1000/user-guide.rst
View File

@@ -1,5 +1,5 @@
..
# Copyright (c) 2022-2024, Arm Limited.
# Copyright (c) 2022-2025, Arm Limited.
#
# SPDX-License-Identifier: MIT
@@ -50,25 +50,32 @@ The Corstone-1000 software stack can be run on:
Yocto Stable Branch
-------------------
Corstone-1000 software stack is built on top of Yocto styhead release.
Corstone-1000 software stack is built on top of Yocto Project's `Walnascar release <meta-arm-repository-release-branch_>`__.
Software Components
-------------------
Within the Yocto Project, each component included in the Corstone-1000 software stack is specified as
a `BitBake recipe <https://docs.yoctoproject.org/bitbake/2.2/bitbake-user-manual/bitbake-user-manual-intro.html#recipes>`__.
The recipes specific to the Corstone-1000 BSP are located at:
``$WORKSPACE/meta-arm/meta-arm-bsp/``.
``${WORKSPACE}/meta-arm/meta-arm-bsp/``.
.. important::
``$WORKSPACE`` refers to the absolute path to your workspace where the `meta-arm` repository will be cloned.
``${WORKSPACE}`` refers to the absolute path to your workspace where the `meta-arm` repository will be cloned.
``$TARGET`` is either ``mps3`` or ``fvp``.
Consider exporting it (e.g., ``export WORKSPACE=$(realpath .)``) if you're already in the workspace directory,
so you can copy and paste the commands from this guide verbatim.
.. important::
``${TARGET}`` is either ``mps3`` or ``fvp``.
Consider exporting it (e.g., ``export TARGET=mps3``) so you can copy and paste the commands from this guide verbatim.
The Yocto machine config files for the Corstone-1000 FVP and MPS3 targets are:
- ``$WORKSPACE/meta-arm/meta-arm-bsp/conf/machine/include/corstone1000.inc``
- ``$WORKSPACE/meta-arm/meta-arm-bsp/conf/machine/corstone1000-$TARGET.conf``
- ``${WORKSPACE}/meta-arm/meta-arm-bsp/conf/machine/include/corstone1000.inc``
- ``${WORKSPACE}/meta-arm/meta-arm-bsp/conf/machine/corstone1000-${TARGET}.conf``
.. note::
@@ -81,64 +88,64 @@ Host Processor Components
`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_%.bbappend`` |
+----------+-----------------------------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/meta-arm/meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.11.0.bb`` |
+----------+-----------------------------------------------------------------------------------------------------+
+----------+-------------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend`` |
+----------+-------------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.11.0.bb`` |
+----------+-------------------------------------------------------------------------------------------------------+
`Trusted Services <https://trusted-services.readthedocs.io/en/latest/index.html>`__
====================================================================================
+----------+-----------------------------------------------------------------------------------------------------------+
| bbappend | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-security/trusted-services/libts_%.bbappend`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| bbappend | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-crypto-api-test_%.bbappend`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| bbappend | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-iat-api-test_%.bbappend`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| bbappend | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-its-api-test_%.bbappend`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| bbappend | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-ps-api-test_%.bbappend`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| bbappend | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-sp-se-proxy_%.bbappend`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| bbappend | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-sp-smm-gateway_%.bbappend`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/meta-arm/meta-arm/recipes-security/trusted-services/libts_git.bb`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-crypto-api-test_git.bb`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-iat-api-test_git.bb`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-its-api-test_git.bb`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-ps-api-test_git.bb`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/meta-arm/meta-arm/recipes-security/trusted-services/ts-sp-smm-gateway.bb`` |
+----------+-----------------------------------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/meta-arm/meta-arm/recipes-security/trusted-services/ts-sp-se-proxy.bb`` |
+----------+-----------------------------------------------------------------------------------------------------------+
+----------+-------------------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/libts_%.bbappend`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-crypto-api-test_%.bbappend`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-iat-api-test_%.bbappend`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-its-api-test_%.bbappend`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-psa-ps-api-test_%.bbappend`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-sp-se-proxy_%.bbappend`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/trusted-services/ts-sp-smm-gateway_%.bbappend`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/libts_git.bb`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-crypto-api-test_git.bb`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-iat-api-test_git.bb`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-its-api-test_git.bb`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-psa-ps-api-test_git.bb`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-sp-smm-gateway_git.bb`` |
+----------+-------------------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-security/trusted-services/ts-sp-se-proxy_git.bb`` |
+----------+-------------------------------------------------------------------------------------------------------------+
`OP-TEE <https://git.trustedfirmware.org/OP-TEE/optee_os.git>`__
================================================================
+----------+----------------------------------------------------------------------------------------+
| bbappend | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-security/optee/optee-os_4.%.bbappend`` |
+----------+----------------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/meta-arm/meta-arm/recipes-security/optee/optee-os_4.2.0.bb`` |
+----------+----------------------------------------------------------------------------------------+
+----------+------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-security/optee/optee-os_4.%.bbappend`` |
+----------+------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-security/optee/optee-os_4.4.0.bb`` |
+----------+------------------------------------------------------------------------------------------+
`U-Boot <https://github.com/u-boot/u-boot.git>`__
=================================================
+----------+--------------------------------------------------------------------------------+
| bbappend | ``$WORKSPACE/meta-arm/meta-arm/recipes-bsp/u-boot/u-boot_%.bbappend`` |
+----------+--------------------------------------------------------------------------------+
| bbappend | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_%.bbappend`` |
+----------+--------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_2023.07.02.bb`` |
+----------+--------------------------------------------------------------------------------+
+----------+----------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/u-boot/u-boot_%.bbappend`` |
+----------+----------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_%.bbappend`` |
+----------+----------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_2023.07.02.bb`` |
+----------+----------------------------------------------------------------------------------+
Linux
=====
@@ -147,13 +154,13 @@ distribution which is a Linux distribution stripped down to a minimal configurat
The provided distribution is based on `BusyBox <https://www.busybox.net/>`__ and built using `musl libc <https://musl.libc.org/>`__.
+-----------+----------------------------------------------------------------------------------------------+
| bbappend | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-kernel/linux/linux-yocto_%.bbappend`` |
+-----------+----------------------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/poky/meta/recipes-kernel/linux/linux-yocto_6.12.bb`` |
+-----------+----------------------------------------------------------------------------------------------+
| defconfig | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-kernel/linux/files/corstone1000/defconfig`` |
+-----------+----------------------------------------------------------------------------------------------+
+-----------+------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-kernel/linux/linux-yocto_%.bbappend`` |
+-----------+------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/poky/meta/recipes-kernel/linux/linux-yocto_6.12.bb`` |
+-----------+------------------------------------------------------------------------------------------------+
| defconfig | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-kernel/linux/files/corstone1000/defconfig`` |
+-----------+------------------------------------------------------------------------------------------------+
*************************
Secure Enclave Components
@@ -162,11 +169,11 @@ Secure Enclave Components
`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_2.1.0.bb`` |
+----------+-----------------------------------------------------------------------------------------------------+
+----------+-------------------------------------------------------------------------------------------------------+
| bbappend | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-m/trusted-firmware-m_%.bbappend`` |
+----------+-------------------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_2.1.1.bb`` |
+----------+-------------------------------------------------------------------------------------------------------+
************************************
External System Processor Components
@@ -179,9 +186,9 @@ An example application that uses the `RTX Real-Time Operating System <https://de
The application project can be found `here <https://git.gitlab.arm.com/arm-reference-solutions/corstone1000/external_system/rtx>`__.
+----------+--------------------------------------------------------------------------------------------+
| Recipe | ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-bsp/external-system/external-system_0.1.0.bb`` |
+----------+--------------------------------------------------------------------------------------------+
+----------+----------------------------------------------------------------------------------------------+
| Recipe | ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/external-system/external-system_0.1.0.bb`` |
+----------+----------------------------------------------------------------------------------------------+
.. _building-the-software-stack:
@@ -192,7 +199,7 @@ Build
Building binaries natively on Windows and AArch64 Linux is not supported.
Use an AMD64 Linux based development machine to build the software stack and transfer the binaries to run the software stack on an FVP in Windows or AArch64 Linux
Use an Intel or AMD 64-bit architecture Linux based development machine to build the software stack and transfer the binaries to run the software stack on an FVP in Windows or AArch64 Linux
if required.
@@ -200,8 +207,8 @@ Build
.. code-block:: console
mkdir $WORKSPACE
cd $WORKSPACE
mkdir ${WORKSPACE}
cd ${WORKSPACE}
#. Install kas version 4.4 with ``sudo`` rights.
@@ -211,18 +218,18 @@ Build
Ensure the kas installation directory is visible on the ``$PATH`` environment variable.
#. Clone the `meta-arm` Yocto layer in the workspace ``$WORKSPACE``.
#. Clone the `meta-arm` Yocto layer in the workspace ``${WORKSPACE}``.
.. code-block:: console
cd $WORKSPACE
git clone https://git.yoctoproject.org/git/meta-arm -b CORSTONE1000-2024.11
cd ${WORKSPACE}
git clone https://git.yoctoproject.org/git/meta-arm -b CORSTONE1000-2025.05
#. Build a Corstone-1000 image:
.. code-block:: console
kas build meta-arm/kas/corstone1000-$TARGET.yml:meta-arm/ci/debug.yml
kas build meta-arm/kas/corstone1000-${TARGET}.yml:meta-arm/ci/debug.yml
.. important::
@@ -241,22 +248,22 @@ Build
.. code-block:: console
kas build meta-arm/kas/corstone1000-$TARGET.yml:meta-arm/ci/debug.yml:meta-arm/kas/corstone1000-extsys.yml
kas build meta-arm/kas/corstone1000-${TARGET}.yml:meta-arm/ci/debug.yml:meta-arm/kas/corstone1000-extsys.yml
A clean build takes a significant amount of time given that all of the development machine utilities are also
built along with the target images. Those development machine utilities include executables (Python,
CMake, etc.) and the required toolchains.
Once the build succeeds, all output binaries will be placed in ``$WORKSPACE/build/tmp/deploy/images/corstone1000-$TARGET/``
Once the build succeeds, all output binaries will be placed in ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-${TARGET}/``
Everything apart from the Secure Enclave ROM firmware and External System firmware, is bundled into a single binary, the
``corstone1000-flash-firmware-image-corstone1000-$TARGET.wic`` file.
``corstone1000-flash-firmware-image-corstone1000-${TARGET}.wic`` file.
The output binaries run in the Corstone-1000 platform are the following:
- The Secure Enclave ROM firmware: ``$WORKSPACE/build/tmp/deploy/images/corstone1000-$TARGET/bl1.bin``
- The External System Processor firmware: ``$WORKSPACE/build/tmp/deploy/images/corstone1000-$TARGET/es_flashfw.bin``
- The internal firmware flash image: ``$WORKSPACE/build/tmp/deploy/images/corstone1000-$TARGET/corstone1000-flash-firmware-image-corstone1000-$TARGET.wic``
- The Secure Enclave ROM firmware: ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-${TARGET}/bl1.bin``
- The External System Processor firmware: ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-${TARGET}/es_flashfw.bin``
- The internal firmware flash image: ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-${TARGET}/corstone1000-flash-firmware-image-corstone1000-${TARGET}.wic``
.. _flashing-firmware-images:
@@ -269,6 +276,13 @@ Flash
machine does not require any firmware flashing. Refer to `this <running-software-stack-fvp_>`__
section for running the software stack on FVP.
.. important::
When preparing the SD card for flashing, ensure that it is at least 4GB in size and formatted
with a FAT32 partition.
Using smaller cards or unsupported file systems (e.g., exFAT, NTFS) may cause the flashing
process to fail or the device to become unresponsive.
#. Download the FPGA bit file image ``AN550: Arm® Corstone™-1000 for MPS3 Version 2.0``
on the `Arm Developer website <https://developer.arm.com/tools-and-software/development-boards/fpga-prototyping-boards/download-fpga-images>`__.
Click on the ``Download AN550 bundle`` button and login to download the file.
@@ -302,9 +316,9 @@ Flash
└── ES0.bin
#. Depending upon the MPS3 board version, you should update the ``images.txt`` file
(found in the corresponding ``HBI0309x`` folder e.g. ``Boardfiles/MB/HBI0309$BOARD_VERSION/AN550/images.txt``)
(found in the corresponding ``HBI0309x`` folder e.g. ``Boardfiles/MB/HBI0309${BOARD_VERSION}/AN550/images.txt``)
so it points to the images under the ``SOFTWARE`` directory.
Where ``$BOARD_VERSION`` is a variable containing the board printed on the MPS3 board.
Where ``${BOARD_VERSION}`` is a variable containing the board printed on the MPS3 board.
The ``images.txt`` file compatible with the latest version of the software
stack can be seen below;
@@ -341,10 +355,10 @@ Flash
IMAGE2FILE: \SOFTWARE\es0.bin
#. Copy ``bl1.bin`` from ``$WORKSPACE/build/tmp/deploy/images/corstone1000-mps3`` to the ``SOFTWARE`` directory of the FPGA bundle.
#. Copy ``es_flashfw.bin`` from ``$WORKSPACE/build/tmp/deploy/images/corstone1000-mps3`` to the ``SOFTWARE`` directory of the FPGA bundle
#. Copy ``bl1.bin`` from ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-mps3`` to the ``SOFTWARE`` directory of the FPGA bundle.
#. Copy ``es_flashfw.bin`` from ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-mps3`` to the ``SOFTWARE`` directory of the FPGA bundle
and rename the binary to ``es0.bin``.
#. Copy ``corstone1000-flash-firmware-image-corstone1000-mps3.wic`` from ``$WORKSPACE/build/tmp/deploy/images/corstone1000-mps3`` to the ``SOFTWARE``
#. Copy ``corstone1000-flash-firmware-image-corstone1000-mps3.wic`` from ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-mps3`` to the ``SOFTWARE``
directory of the FPGA bundle and rename the wic image to ``cs1000.bin``.
.. note::
@@ -427,7 +441,7 @@ Corstone-1000 FVP software image.
A Yocto recipe is provided to download the latest supported FVP version.
The recipe is located at ``$WORKSPACE/meta-arm/meta-arm/recipes-devtools/fvp/fvp-corstone1000.bb``.
The recipe is located at ``${WORKSPACE}/meta-arm/meta-arm/recipes-devtools/fvp/fvp-corstone1000.bb``.
The latest FVP version is ``11.23.25`` and is automatically downloaded and installed when using the
``runfvp`` command as detailed below.
@@ -439,14 +453,15 @@ The latest FVP version is ``11.23.25`` and is automatically downloaded and insta
kas shell meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml \
-c "../meta-arm/scripts/runfvp -- --version"
The FVP can also be manually downloaded from the `Arm Ecosystem FVPs`_ page by navigating
to "Corstone IoT FVPs" section to download the Corstone-1000 platform FVP installer. Follow the
instructions of the installer to setup the FVP.
The FVP can also be manually downloaded from `Arm Developer <arm-developer-fvp_>`__ to download
the Corstone-1000 platform FVP installer.
Follow the instructions of the installer to setup the FVP.
#. Run the FVP
.. code-block:: console
tmux
kas shell meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml \
-c "../meta-arm/scripts/runfvp --terminals=tmux"
@@ -478,6 +493,13 @@ Tests
following the instructions `here <building-the-software-stack_>`__.
Reports
-------
Reports for the tests conducted on the `Corstone-1000 software (CORSTONE1000-2025.05) <https://git.yoctoproject.org/meta-arm/tag/?h=CORSTONE1000-2025.05>`__
release are available for reference `here <https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/CORSTONE1000-2025.05/embedded-a/corstone1000/CORSTONE1000-2025.05?ref_type=tags>`__.
.. _clean-secure-flash:
Clean Secure Flash
@@ -489,12 +511,12 @@ Clean Secure Flash
This is to erase the flash cleanly and prepare a clean board environment for testing.
#. Clone the `systemready-patch` repository to your $WORKSPACE.
#. Clone the `systemready-patch` repository to your ${WORKSPACE}.
.. code-block:: console
cd $WORKSPACE
git clone https://git.gitlab.arm.com/arm-reference-solutions/systemready-patch.git -b CORSTONE1000-2024.11
cd ${WORKSPACE}
git clone https://git.gitlab.arm.com/arm-reference-solutions/systemready-patch.git -b CORSTONE1000-2025.05
#. Copy the secure flash cleaning Git patch file to your copy of `meta-arm`.
@@ -513,12 +535,12 @@ Clean Secure Flash
.. code-block:: console
cd $WORKSPACE
cd ${WORKSPACE}
kas shell meta-arm/kas/corstone1000-mps3.yml:meta-arm/ci/debug.yml
bitbake -c cleansstate trusted-firmware-m corstone1000-flash-firmware-image
bitbake -c build corstone1000-flash-firmware-image
#. Replace the ``bl1.bin`` file on the SD card with ``$WORKSPACE/build/tmp/deploy/images/corstone1000-mps3/bl1.bin``.
#. Replace the ``bl1.bin`` file on the SD card with ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-mps3/bl1.bin``.
#. Reboot the board to completely erase the secure flash.
@@ -534,7 +556,7 @@ Clean Secure Flash
.. code-block:: console
cd $WORKSPACE/meta-arm
cd ${WORKSPACE}/meta-arm
git reset --hard
cd ..
bitbake -c cleansstate trusted-firmware-m corstone1000-flash-firmware-image
@@ -544,11 +566,14 @@ Clean Secure Flash
You can proceed with the test instructions in the following section after having done all the above.
SystemReady-IR
SystemReady IR
--------------
.. important::
Running the SystemReady-IR tests described below requires USB drives.
**SystemReady IR** has now been renamed **SystemReady Devicetree Band**.
Running the tests described below requires USB drives.
In our testing, not all USB drive models worked well with the MPS3.
Here are the USB drive models that were stable in our test environment:
@@ -572,10 +597,10 @@ A storage with EFI System Partition (ESP) must exist in the system for the UEFI-
.. code-block:: console
kas build meta-arm/kas/corstone1000-$TARGET.yml:meta-arm/ci/debug.yml --target corstone1000-esp-image
kas build meta-arm/kas/corstone1000-${TARGET}.yml:meta-arm/ci/debug.yml --target corstone1000-esp-image
#. Locate the ``corstone1000-esp-image-corstone1000-$TARGET.wic`` build artefact
in ``$WORKSPACE/build/tmp/deploy/images/corstone1000-$TARGET/``
#. Locate the ``corstone1000-esp-image-corstone1000-${TARGET}.wic`` build artefact
in ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-${TARGET}/``
****************************
Use the EFI System Partition
@@ -605,7 +630,7 @@ MPS3
.. code-block:: console
sudo dd \
if=$WORKSPACE/build/tmp/deploy/images/corstone1000-mps3/corstone1000-esp-image-corstone1000-mps3.wic \
if=${WORKSPACE}/build/tmp/deploy/images/corstone1000-mps3/corstone1000-esp-image-corstone1000-mps3.wic \
of=/dev/sdb \
iflag=direct oflag=direct status=progress bs=512; sync;
@@ -622,7 +647,7 @@ It will be used when the SystemReady-IR tests is performed on the FVP in the lat
****************************
Run SystemReady-IR ACS Tests
Run SystemReady IR ACS Tests
****************************
ACS is used to ensure architectural compliance across different implementations of the architecture.
@@ -643,20 +668,31 @@ See the directory structure of the ACS image ``BOOT`` partition below:
.. code-block:: console
├── acs_results
├── EFI
│   └── BOOT
│   ├── app
│   ├── bbr
│   ├── bootaa64.efi
│   ├── bsa
│   ├── debug
│   ├── Shell.efi
│   └── startup.nsh
├── grub
├── grub.cfg
│ └── BOOT
│ ├── app
│ ├── bbr
│ ├── bootaa64.efi
│ ├── bsa
│ ├── debug
│ ├── grub.cfg
│ ├── Shell.efi
│ ├── sie_startup.nsh
│ └── startup.nsh
├── Image
├── ramdisk-busybox.img
└── acs_results
├── security-interface-extension-keys
│ ├── NullPK.auth
│ ├── TestDB1.auth
│ ├── TestDB1.der
│ ├── TestDBX1.auth
│ ├── TestDBX1.der
│ ├── TestKEK1.auth
│ ├── TestKEK1.der
│ ├── TestPK1.auth
│ └── TestPK1.der
├── startup.nsh
└── yocto_image.flag
The ``BOOT`` partition is also used to store test results in the ``acs_results`` folder.
@@ -674,13 +710,13 @@ This sections below describe how to build and run ACS tests on Corstone-1000.
.. code-block:: console
cd $WORKSPACE
git clone https://github.com/ARM-software/arm-systemready.git
cd ${WORKSPACE}
git clone https://github.com/ARM-software/arm-systemready.git -b v23.09_SR_REL2.0.0_ES_REL1.3.0_IR_REL2.1.0 --depth 1
This repository contains the infrastructure to build the ACS and the bootable prebuilt images to be used for the
certifications of SystemReady-IR.
certifications of SystemReady IR.
#. Find the pre-built ACS live image in ``$WORKSPACE/arm-systemready/IR/prebuilt_images/v23.09_2.1.0/ir-acs-live-image-generic-arm64.wic.xz``.
#. Find the pre-built ACS live image in ``${WORKSPACE}/arm-systemready/IR/prebuilt_images/v23.09_2.1.0/ir-acs-live-image-generic-arm64.wic.xz``.
.. note::
@@ -693,7 +729,7 @@ This sections below describe how to build and run ACS tests on Corstone-1000.
.. code-block:: console
cd $WORKSPACE/arm-systemready/IR/prebuilt_images/v23.09_2.1.0
cd ${WORKSPACE}/arm-systemready/IR/prebuilt_images/v23.09_2.1.0
unxz ir-acs-live-image-generic-arm64.wic.xz
MPS3
@@ -717,7 +753,7 @@ MPS3
.. code-block:: console
cd $WORKSPACE/arm-systemready/IR/prebuilt_images/v23.09_2.1.0
cd ${WORKSPACE}/arm-systemready/IR/prebuilt_images/v23.09_2.1.0
sudo dd if=ir-acs-live-image-generic-arm64.wic of=/dev/sdc iflag=direct oflag=direct bs=1M status=progress; sync
#. Plug the USB drive to the MPS3. At this point you should have both the USB drive with the ESP and the USB drive with the ACS image plugged to the MPS3.
@@ -757,12 +793,12 @@ Run the commands below to run the ACS test on FVP using the built firmware image
.. code-block:: console
cd $WORKSPACE
cd ${WORKSPACE}
tmux
./meta-arm/scripts/runfvp \
--terminals=tmux \
./build/tmp/deploy/images/corstone1000-fvp/corstone1000-flash-firmware-image-corstone1000-fvp.fvpconf \
-- -C board.msd_mmc.p_mmc_file=$WORKSPACE/arm-systemready/IR/prebuilt_images/v23.09_2.1.0/ir-acs-live-image-generic-arm64.wic
-- -C board.msd_mmc.p_mmc_file=${WORKSPACE}/arm-systemready/IR/prebuilt_images/v23.09_2.1.0/ir-acs-live-image-generic-arm64.wic
.. note::
@@ -794,7 +830,7 @@ The results can be fetched from the `acs_results` folder in the ``BOOT`` partiti
sudo mkdir /mnt/test
sudo mount -o rw,offset=1048576 \
$WORKSPACE/arm-systemready/IR/prebuilt_images/v23.09_2.1.0/ir-acs-live-image-generic-arm64.wic \
${WORKSPACE}/arm-systemready/IR/prebuilt_images/v23.09_2.1.0/ir-acs-live-image-generic-arm64.wic \
/mnt/test
#####################################################
@@ -822,18 +858,18 @@ Generate Capsules
*****************
U-Boot's ``mkeficapsule`` tool is used to generate capsules. It is built automatically for the host machine during the firmware image building process.
The tool can be found in the ``$WORKSPACE/build/tmp/sysroots-components/x86_64/u-boot-tools-native/usr/bin/mkeficapsule`` directory.
The tool can be found in the ``${WORKSPACE}/build/tmp/sysroots-components/x86_64/u-boot-tools-native/usr/bin/mkeficapsule`` directory.
``mkeficapsule`` uses a no-partition image which is created when performing a clean firmware build.
The no-partition image can be found in the ``$WORKSPACE/build/tmp/deploy/images/corstone1000-$TARGET/corstone1000-$TARGET_image.nopt`` directory.
The no-partition image can be found in the ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-${TARGET}/corstone1000-${TARGET}/corstone1000-${TARGET}_image.nopt`` directory.
The capsule's default metadata passed can be found in the ``$WORKSPACE/meta-arm/meta-arm-bsp/recipes-bsp/images/corstone1000-flash-firmware-image.bb``
and ``$WORKSPACE/meta-arm/kas/corstone1000-image-configuration.yml`` files.
The capsule's default metadata passed can be found in the ``${WORKSPACE}/meta-arm/meta-arm-bsp/recipes-bsp/images/corstone1000-flash-firmware-image.bb``
and ``${WORKSPACE}/meta-arm/kas/corstone1000-image-configuration.yml`` files.
Valid Capsule
=============
An automatically generated capsule can be found in ``$WORKSPACE/build/tmp/deploy/images/corstone1000-$TARGET/corstone1000-$TARGET-v6.uefi.capsule`` after running a firmware build.
An automatically generated capsule can be found in ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-${TARGET}/corstone1000-${TARGET}-v6.uefi.capsule`` after running a firmware build.
The default metadata values are assumed to be correct to generate a valid capsule.
@@ -850,26 +886,27 @@ Run the following commands to generate an invalid capsule with a ``fw-version``
.. code-block:: console
cd $WORKSPACE
cd ${WORKSPACE}
./build/tmp/sysroots-components/x86_64/u-boot-tools-native/usr/bin/mkeficapsule \
--monotonic-count 1 \
--private-key build/tmp/deploy/images/corstone1000-$TARGET/corstone1000_capsule_key.key \
--certificate build/tmp/deploy/images/corstone1000-$TARGET/corstone1000_capsule_cert.crt \
--private-key build/tmp/deploy/images/corstone1000-${TARGET}/corstone1000_capsule_key.key \
--certificate build/tmp/deploy/images/corstone1000-${TARGET}/corstone1000_capsule_cert.crt \
--index 1 \
--guid $TARGET_GUID \
--fw-version 5 build/tmp/deploy/images/corstone1000-$TARGET/corstone1000-$TARGET_image.nopt \
corstone1000-$TARGET-v5.uefi.capsule
--guid ${TARGET}_GUID \
--fw-version 5 \
build/tmp/deploy/images/corstone1000-${TARGET}/corstone1000-${TARGET}_image.nopt \
corstone1000-${TARGET}-v5.uefi.capsule
.. important::
``$TARGET_GUID`` is different depending on whether the capsule is built for the ``fvp`` or ``mps3`` ``$TARGET``.
``${TARGET}_GUID`` is different depending on whether the capsule is built for the ``fvp`` or ``mps3`` ``${TARGET}``.
- ``fvp`` ``$TARGET_GUID`` is ``989f3a4e-46e0-4cd0-9877-a25c70c01329``
- ``mps3`` ``$TARGET_GUID`` is ``df1865d1-90fb-4d59-9c38-c9f2c1bba8cc``
- ``fvp`` ``${TARGET}_GUID`` is ``989f3a4e-46e0-4cd0-9877-a25c70c01329``
- ``mps3`` ``${TARGET}_GUID`` is ``df1865d1-90fb-4d59-9c38-c9f2c1bba8cc``
The invalid capsule will be located in the ``$WORKSPACE`` directory.
The invalid capsule will be located in the ``${WORKSPACE}`` directory.
***************************
Transfer Capsules to Target
@@ -887,10 +924,16 @@ MPS3
.. code-block:: console
sudo cp $CAPSULES_PATH/corstone1000-mps3-v6.uefi.capsule $ACS_IMAGE_USB_DRIVE_PATH/BOOT/
sudo cp $CAPSULES_PATH/corstone1000-mps3-v5.uefi.capsule $ACS_IMAGE_USB_DRIVE_PATH/BOOT/
cp ${WORKSPACE}/build/tmp/deploy/images/corstone1000-mps3/corstone1000-mps3-v6.uefi.capsule /dev/sdc/BOOT/
cp ${WORKSPACE}/corstone1000-mps3-v5.uefi.capsule /dev/sdc/EFI/BOOT/
sync
.. note::
``/dev/sdc`` is the assumed path for the ACS Image USB drive.
Replace it with the actual device path as enumerated on your development machine.
.. important::
Since we are using the direct Capsule Update method, the capsule files should not be placed in
@@ -900,7 +943,7 @@ FVP
===
#. Download and extract the ACS image `as described for the MPS3 <mps3-instructions-for-acs-image_>`_.
The ACS image extraction location will be referred below as ``$ACS_IMAGE_PATH``.
The ACS image extraction location will be referred below as ``${ACS_IMAGE_PATH}``.
.. note::
@@ -911,10 +954,10 @@ FVP
.. code-block:: console
fdisk -lu $ACS_IMAGE_PATH/ir-acs-live-image-generic-arm64.wic
fdisk -lu ${ACS_IMAGE_PATH}/ir-acs-live-image-generic-arm64.wic
Device Start End Sectors Size Type
$ACS_IMAGE_PATH/ir-acs-live-image-generic-arm64.wic1 2048 309247 307200 150M Microsoft basic data
$ACS_IMAGE_PATH/ir-acs-live-image-generic-arm64.wic2 309248 1343339 1034092 505M Linux filesystem
${ACS_IMAGE_PATH}/ir-acs-live-image-generic-arm64.wic1 2048 309247 307200 150M Microsoft basic data
${ACS_IMAGE_PATH}/ir-acs-live-image-generic-arm64.wic2 309248 1343339 1034092 505M Linux filesystem
Given that the first partition starts at sector 2048 and each sector is 512 bytes in size,
@@ -925,14 +968,14 @@ FVP
.. code-block:: console
sudo mkdir /mnt/ir-acs-live-image-generic-arm64
sudo mount -o rw,offset=<first_partition_offset> $ACS_IMAGE_PATH/ir-acs-live-image-generic-arm64.wic /mnt/ir-acs-live-image-generic-arm64
sudo mount -o rw,offset=<first_partition_offset> ${ACS_IMAGE_PATH}/ir-acs-live-image-generic-arm64.wic /mnt/ir-acs-live-image-generic-arm64
#. Copy the capsules:
.. code-block:: console
sudo cp $CAPSULES_PATH/corstone1000-fvp-v6.uefi.capsule /mnt/ir-acs-live-image-generic-arm64/
sudo cp $CAPSULES_PATH/corstone1000-fvp-v5.uefi.capsule /mnt/ir-acs-live-image-generic-arm64/
sudo cp ${WORKSPACE}/build/tmp/deploy/images/corstone1000-fvp/corstone1000-fvp-v6.uefi.capsule /mnt/ir-acs-live-image-generic-arm64/
sudo cp ${WORKSPACE}/corstone1000-fvp-v5.uefi.capsule /mnt/ir-acs-live-image-generic-arm64/
sync
#. Unmount the IR image:
@@ -945,8 +988,8 @@ FVP
Run Capsule Update Tests
************************
The valid capsule (``corstone1000-$TARGET-v6.uefi.capsule``) will be used first to run the positive capsule update test.
This will be followed by using the invalid capsule (``corstone1000-$TARGET-v5.uefi.capsule``) to run the negative capsule update test.
The valid capsule (``corstone1000-${TARGET}-v6.uefi.capsule``) will be used first to run the positive capsule update test.
This will be followed by using the invalid capsule (``corstone1000-${TARGET}-v5.uefi.capsule``) to run the negative capsule update test.
.. important::
@@ -972,16 +1015,17 @@ Positive Capsule Update Test
.. code-block:: console
tmux
kas shell meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml \
-c "../meta-arm/scripts/runfvp --terminals=tmux \
-- -C board.msd_mmc.p_mmc_file=$ACS_IMAGE_PATH/ir-acs-live-image-generic-arm64.wic"
-- -C board.msd_mmc.p_mmc_file=${ACS_IMAGE_PATH}/ir-acs-live-image-generic-arm64.wic"
.. warning::
``$ACS_IMAGE_PATH`` must be an absolute path. Ensure there are no spaces before or after of ``=`` of the ``-C board.msd_mmc.p_mmc_file`` option.
``${ACS_IMAGE_PATH}`` must be an absolute path. Ensure there are no spaces before or after of ``=`` of the ``-C board.msd_mmc.p_mmc_file`` option.
#. Wait until U-Boot loads EFI from the ACS image and interrupt the EFI shell by pressing the ``Escape`` key when the following prompt is displayed on the Host Processor terminal (``ttyUSB2``).
#. Wait until U-Boot loads EFI from the ACS image and interrupt the EFI shell by pressing the ``Escape`` key when the following prompt is displayed on the Host Processor terminal (``ttyUSB2`` for MPS3).
.. code-block:: console
@@ -1018,7 +1062,7 @@ Positive Capsule Update Test
The software stack copies the capsule content to the external flash, which is shared between the Secure Enclave and the Host Processor
before rebooting the system.
After the first reboot, TrustedFirmware-M should apply the valid capsule and display the following log on the Secure Enclave terminal (``ttyUSB1``)
After the first reboot, TrustedFirmware-M should apply the valid capsule and display the following log on the Secure Enclave terminal (``ttyUSB1`` for MPS3)
before rebooting the system a second time:
.. code-block:: console
@@ -1093,13 +1137,13 @@ Negative Capsule Update Test
The `positive capsule update test <positive-capsule-update-test_>`__ must be run before running the negative capsule update test.
#. After running the positive capsule update test, reboot the system by typing the following command on the Host Processor terminal (``ttyUSB2``):
#. After running the positive capsule update test, reboot the system by typing the following command on the Host Processor terminal (``ttyUSB2`` for MPS3):
.. code-block:: console
reboot
#. Wait until U-Boot loads EFI from the ACS image and interrupt the EFI shell by pressing the ``Escape`` key when the following prompt is displayed on the Host Processor terminal (``ttyUSB2``).
#. Wait until U-Boot loads EFI from the ACS image and interrupt the EFI shell by pressing the ``Escape`` key when the following prompt is displayed on the Host Processor terminal (``ttyUSB2`` for MPS3).
.. code-block:: console
@@ -1126,7 +1170,7 @@ Negative Capsule Update Test
EFI/BOOT/app/CapsuleApp.efi corstone1000-fvp-v5.uefi.capsule
#. TrustedFirmware-M should reject the capsule due to having a lower firmware version and display the following log on the Secure Enclave terminal (``ttyUSB1``):
#. TrustedFirmware-M should reject the capsule due to having a lower firmware version and display the following log on the Secure Enclave terminal (``ttyUSB1`` for MPS3):
.. code-block:: console
@@ -1230,9 +1274,9 @@ Follow the instructions below to create the installation media.
For openSUSE Tumbleweed, search for an ISO file with the format: ``openSUSE-Tumbleweed-DVD-aarch64-Snapshot$DATE-Media.iso``.
``openSUSE-Tumbleweed-DVD-aarch64-Snapshot20240516-Media.iso`` was used during development.
``openSUSE-Tumbleweed-DVD-aarch64-Snapshot20250509-Media.iso`` was used during development.
The location of the ISO file on the development machine will be referred to as ``$DISTRO_INSTALLER_ISO_PATH``.
The location of the ISO file on the development machine will be referred to as ``${DISTRO_INSTALLER_ISO_PATH}``.
#. Create the installation media which will contain the necessary files to install the operation system.
@@ -1256,7 +1300,7 @@ Follow the instructions below to create the installation media.
.. code-block:: console
sudo dd if=$DISTRO_INSTALLER_ISO_PATH of=/dev/sdb iflag=direct oflag=direct status=progress bs=1M; sync;
sudo dd if=${DISTRO_INSTALLER_ISO_PATH} of=/dev/sdb iflag=direct oflag=direct status=progress bs=1M; sync;
- FVP:
@@ -1279,7 +1323,7 @@ Corstone-1000 on-board non-volatile storage size is insufficient for installing
.. code-block:: console
dd if=/dev/zero of=$WORKSPACE/fvp_distro_system_drive.img \
dd if=/dev/zero of=${WORKSPACE}/fvp_distro_system_drive.img \
bs=1 count=0 seek=10G; sync; \
parted -s fvp_distro_system_drive.img mklabel gpt
@@ -1323,10 +1367,11 @@ FVP
.. code-block:: console
tmux
kas shell meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml \
-c "../meta-arm/scripts/runfvp --terminals=tmux -- \
-C board.msd_mmc.p_mmc_file=$WORKSPACE/fvp_distro_system_drive.img \
-C board.msd_mmc_2.p_mmc_file=$DISTRO_INSTALLER_ISO_PATH"
-C board.msd_mmc.p_mmc_file=${WORKSPACE}/fvp_distro_system_drive.img \
-C board.msd_mmc_2.p_mmc_file=${DISTRO_INSTALLER_ISO_PATH}"
The Linux distribution will be installed on ``fvp_distro_system_drive.img``.
@@ -1389,9 +1434,10 @@ Boot Distribution
.. code-block:: console
tmux
kas shell meta-arm/kas/corstone1000-fvp.yml:meta-arm/ci/debug.yml \
-c "../meta-arm/scripts/runfvp --terminals=tmux -- \
-C board.msd_mmc.p_mmc_file=$WORKSPACE/fvp_distro_system_drive.img"
-C board.msd_mmc.p_mmc_file=${WORKSPACE}/fvp_distro_system_drive.img"
.. warning::
@@ -1486,29 +1532,32 @@ Generate Keys, Signed Image and Unsigned Image
.. code-block:: console
cd $WORKSPACE
cd ${WORKSPACE}
git clone https://git.gitlab.arm.com/arm-reference-solutions/systemready-patch.git \
-b CORSTONE1000-2024.11
git clone https://gitlab.arm.com/arm-reference-solutions/systemready-patch \
-b CORSTONE1000-2025.05
#. Set the current working directory to build directory's subdirectory containing the software stack build images.
.. code-block:: console
cd $WORKSPACE/build/tmp/deploy/images/corstone1000-$TARGET/
cd ${WORKSPACE}/build/tmp/deploy/images/corstone1000-${TARGET}/
#. Run the image signing script (without changing the current working directory).
.. code-block:: console
./$WORKSPACE/systemready-patch/embedded-a/corstone1000/secureboot/create_keys_and_sign.sh \
-d $TARGET \
-v $CERTIFICATE_VALIDITY_DURATION_IN_DAYS
./${WORKSPACE}/systemready-patch/embedded-a/corstone1000/secureboot/create_keys_and_sign.sh \
-d ${TARGET} \
-v ${CERTIFICATE_VALIDITY_DURATION_IN_DAYS}
.. important::
The `efitools <https://github.com/vathpela/efitools/>`__ package is required to execute the script.
``${CERTIFICATE_VALIDITY_DURATION_IN_DAYS}`` is an integer that specifies the certificate's validity period in days.
.. note::
Consult the image signing script help message (``-h``) for more information about other optional arguments.
@@ -1517,7 +1566,7 @@ Generate Keys, Signed Image and Unsigned Image
The keys, signed kernel image, and unsigned kernel image will be copied to the exisiting ESP image.
The modified ESP image can be found at ``$WORKSPACE/build/tmp/deploy/images/corstone1000-$TARGET/corstone1000-esp-image-corstone1000-$TARGET.wic``.
The modified ESP image can be found at ``${WORKSPACE}/build/tmp/deploy/images/corstone1000-${TARGET}/corstone1000-esp-image-corstone1000-${TARGET}.wic``.
****************************
@@ -1743,7 +1792,7 @@ The tests use the `arm_tstee` driver to access Trusted Services Secure Partition
Ensure there are no USB drives connected to the board when running the test on the MPS3.
The steps below are applicable to both MPS3 and FVP).
The steps below are applicable to both MPS3 and FVP.
#. Start the Corstone-1000 and wait until it boots to Linux on the Host Processor terminal (``ttyUSB2``).
@@ -1825,31 +1874,33 @@ For more information about this, see the following resources:
- `Authenticated Debug Access Control Specification <https://developer.arm.com/documentation/den0101/latest/>`__
- `Arm Corstone-1000 for MPS3 Application Note AN550, Chapter 7 <https://developer.arm.com/documentation/dai0550/latest/>`__
The Secure Debug Manager API is implemented in the `secure-debug-manager <https://github.com/ARM-software/secure-debug-manager>`__ repository.
The Secure Debug Manager API is implemented in the `Secure Debug Manager (PSA-ADAC / SDC-600) <secure-debug-manager-repo-readme_>`__ repository.
This repository also contains the necessary files for the Arm Development Studio support.
The build and integration instructions can be found in its `README <secure-debug-manager-repo-readme_>`__.
The `secure-debug-manager` repository also contains the private key and chain certificate to be used during the tests.
The private key's public pair is provisioned into the One-Time Programmable memory in TrustedFirmware-M. These are dummy keys that should not be used in production.
The `Secure Debug Manager (PSA-ADAC / SDC-600)` repository also contains the private key and chain certificate to be used during the tests.
The private key's public pair is provisioned into the One-Time Programmable memory in TrustedFirmware-M.
These are dummy keys that should not be used in production.
To test the Secure Debug feature, you'll need a debug probe from the DSTREAM family and Arm Development Studio versions 2022.2, 2022.c, or 2023.a.
To test the Secure Debug feature, you'll need a debug probe from the `Arm ULINKpro family <arm-ulink-pro-website_>`__
and `Arm Development Studio <arm-ds-website_>`__ versions 2022.2, 2022.c, or 2023.a.
#. Clone the `secure-debug-manager` repository to your workspace.
#. Clone the `Secure Debug Manager (PSA-ADAC / SDC-600)` repository to your workspace.
.. code-block:: console
cd $WORKSPACE
cd ${WORKSPACE}
git clone https://github.com/ARM-software/secure-debug-manager.git
#. Navigate into the repository directory and checkout the specific commit in the listing below.
.. code-block:: console
cd $WORKSPACE/secure-debug-manager
cd ${WORKSPACE}/secure-debug-manager
git checkout b30d6496ca749123e86b39b161b9f70ef76106d6
#. Follow the steps in the `secure-debug-manager`'s `README <secure-debug-manager-repo-readme_>`__ for the development machine setup.
#. Follow the instructions in the `Secure Debug Manager (PSA-ADAC / SDC-600)'s README <secure-debug-manager-repo-readme_>`__ for the development machine setup.
#. Rebuild the software stack with Secure Debug.
@@ -1871,7 +1922,7 @@ To test the Secure Debug feature, you'll need a debug probe from the DSTREAM fam
#. Connect the debug probe to the MPS3 using the 20-pin 1.27mm connector with the ``CS_20W_1.27MM silkscreen`` label.
#. Create a debug configuration in Arm Development Studio as described in the `secure-debug-manager`'s `README <https://github.com/ARM-software/secure-debug-manager?tab=readme-ov-file#arm-development-studio-integration>`__.
#. Create a debug configuration in Arm Development Studio as described in the `Secure Debug Manager (PSA-ADAC / SDC-600)'s README <secure-debug-manager-armds-integration_>`__.
#. Connect the debuger to the target using the debug configuration.
@@ -1882,14 +1933,14 @@ To test the Secure Debug feature, you'll need a debug probe from the DSTREAM fam
...
Please provide private key file path:
Enter file path > $WORKSPACE\secure-debug-manager\example\data\keys\EcdsaP256Key-3.pem
Enter file path > ${WORKSPACE}\secure-debug-manager\example\data\keys\EcdsaP256Key-3.pem
Please provide trust chain file path:
Enter file path > $WORKSPACE\secure-debug-manager\example\data\chains\chain.EcdsaP256-3
Enter file path > ${WORKSPACE}\secure-debug-manager\example\data\chains\chain.EcdsaP256-3
...
#. When successful authenticated, Arm Development Studio will connect to the running MS3 and the debug features can be used.
#. When successful authenticated, Arm Development Studio will connect to the running MPS3 and the debug features can be used.
The following prompt should appear in the Secure Enclave terminal (``ttyUSB1``):
.. code-block:: console
@@ -1899,15 +1950,13 @@ To test the Secure Debug feature, you'll need a debug probe from the DSTREAM fam
...
Reports
-------
Various test reports for the `Corstone-1000 software (CORSTONE1000-2024.11) <https://git.yoctoproject.org/meta-arm/tag/?h=CORSTONE1000-2024.11>`__
release version are available for reference `here <https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/CORSTONE1000-2024.11/embedded-a/corstone1000/CORSTONE1000-2024.11?ref_type=tags>`__.
--------------
*Copyright (c) 2022-2024, Arm Limited. All rights reserved.*
*Copyright (c) 2022-2025, Arm Limited. All rights reserved.*
.. _Arm Ecosystem FVPs: https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
.. _secure-debug-manager-repo-readme: https://github.com/ARM-software/secure-debug-manager/blob/master/README.md
.. _arm-developer-fvp: https://developer.arm.com/tools-and-software/open-source-software/arm-platforms-software/arm-ecosystem-fvps
.. _secure-debug-manager-repo-readme: https://github.com/ARM-software/secure-debug-manager/tree/master?tab=readme-ov-file#secure-debug-manager-psa-adac--sdc-600
.. _secure-debug-manager-armds-integration: https://github.com/ARM-software/secure-debug-manager?tab=readme-ov-file#arm-development-studio-integration
.. _meta-arm-repository-release-branch: https://web.git.yoctoproject.org/meta-arm?h=walnascar
.. _arm-ulink-pro-website: https://www.arm.com/products/development-tools/debug-probes/ulink-pro
.. _arm-ds-website: https://www.arm.com/products/development-tools/embedded-and-software/arm-development-studio