.. # SPDX-FileCopyrightText: Copyright 2024-2025 Arm Limited and/or its # affiliates # # SPDX-License-Identifier: MIT .. _rd-aspen_design_components: ########## Components ########## CSS-Aspen consists of the following main components: .. image:: ../images/aspen_compute_complex.png :align: center :alt: System Block Diagram *************** Primary Compute *************** The Primary Compute consists of four processor clusters to run a rich OS such as Linux. Each processor cluster includes four Cortex-A720AE cores and a DynamIQ Shared Unit (DSU-120AE). The DSU-120AE with up to 32MB of L3 cache ensures core coherency, supports features such as snoop filtering, bus protection, Dual-Core Lock-Step (DCLS) and power management via Power Policy Units (PPUs). For more details, refer to `DSU-120AE Technical Reference Manual`_. The adjacent Interrupt Block contains a GIC-720AE interrupt controller. .. _rd-aspen_design_components_devicetree: Device tree =========== The CSS-Aspen device tree contains the hardware description for the Primary Compute. The CPUs, memory and devices are statically configured in it. It is compiled by the Trusted Firmware-A, bundled in the Trusted Firmware-A Firmware Image Package (FIP) and is used to configure U-Boot and the Linux kernel at runtime. .. _rd-aspen_design_components_trusted-firmware-a: Trusted Firmware-A ================== :link_subs:`rd-aspen:tf-a-doc` is the initial bootloader on the Primary Compute. For CSS-Aspen, the initial TF-A boot stage is BL2, which runs from a known address at EL3, using the ``RESET_TO_BL2`` compilation option. This option has been extended for CSS-Aspen to load the ``FW_CONFIG`` for dynamic configuration (a role typically performed by BL1). BL2 is responsible for loading the subsequent boot stages and their configuration files from the flash containing the FIP image, which contains: * BL31 * BL32 (:ref:`rd-aspen_design_components_op-tee`) * BL33 (:ref:`rd-aspen_design_components_u-boot`) * The ``HW_CONFIG`` device tree * The ``TOS_FW_CONFIG`` device tree .. _rd-aspen_design_components_trusted-firmware-a_downstream_changes: Downstream changes - RD-Aspen ----------------------------- The RD-Aspen platform is currently implemented in TF-A as downstream patches at :repo:`yocto/meta-arm-bsp-extras/recipes-bsp/trusted-firmware-a/files/fvp-rd-aspen`. * Implement the RD-Aspen platform port. * Add device tree for RD-Aspen. * Add BL31 for RD-Aspen platform. * Add GIC 720AE model ID to RD-Aspen platform port. Trusted Firmware-A Tests ======================== :link_subs:`rd-aspen:tf-a-tests-doc` is a suite of baremetal tests to exercise the :link_subs:`rd-aspen:tf-a-doc` features from the Normal World. .. _rd-aspen_design_components_trusted-firmware-a-tests_downstream_changes: Downstream changes - RD-Aspen ----------------------------- The RD-Aspen platform is currently implemented in TF-A-Tests as downstream patches at :repo:`yocto/meta-arm-bsp-extras/recipes-bsp/trusted-firmware-a/files/fvp-rd-aspen/tests`. * Implement the RD-Aspen platform port. * Introduce platform tests for CPU RAS. .. _rd-aspen_design_components_op-tee: OP-TEE ====== :link_subs:`rd-aspen:op-tee-doc` is a Trusted Execution Environment (TEE) designed as a companion to a Normal world Linux kernel running on Cortex-A720AE cores using the :link_subs:`common:trustzone-doc` technology. The communication between TF-A and OP-TEE, OP-TEE and Secure Partitions uses :link_subs:`common:ff-a-doc` (FF-A) interface. .. _rd-aspen_design_components_op-tee_downstream_changes: Downstream Changes - RD-Aspen ----------------------------- Patch files can be found at :repo:`yocto/meta-arm-bsp-extras/recipes-security/optee/files/fvp-rd-aspen/` to: * Implement the RD-Aspen platform port. * Boot OP-TEE as SPMC running at SEL1. .. _rd-aspen_design_components_trusted-services: Trusted Services ================ The :link_subs:`rd-aspen:trusted-services-doc` project provides a framework for developing and deploying secure services for A-profile devices. Reference software stack provides the following components. * :link_subs:`rd-aspen:se-proxy-doc` to provide access to secure services hosted by RSE. * :link_subs:`rd-aspen:smm-gateway-sp-doc` as a smm-variable service provider. See :ref:`rd-aspen_design_primary_compute_secure_services` for more information. .. _rd-aspen_design_components_trusted-services_downstream_changes: Downstream Changes - RD-Aspen ----------------------------- Patch files can be found at :repo:`yocto/meta-arm-bsp-extras/recipes-security/trusted-services/files/fvp-rd-aspen/` to: * Implement the RD-Aspen platform port. * Support MHUv3 communication. * Support RSE communication protocol. * Support crypto and secure storage proxies for the RD-Aspen platform. .. _rd-aspen_design_components_u-boot: U-Boot ====== :link_subs:`rd-aspen:u-boot` is the Normal world second-stage bootloader (BL33 in TF-A) on the Primary Compute. It consumes the ``HW_CONFIG`` device tree provided by Trusted Firmware-A. The device tree is used to configure U-Boot and the Linux kernel at runtime, minimizing the need for platform-specific configuration. The implementation is based on the VExpress64 board family. Downstream patch files can be found at :repo:`yocto/meta-arm-bsp-extras/recipes-bsp/u-boot/files/fvp-rd-aspen/`. .. _rd-aspen_design_components_u-boot_downstream_changes: Downstream changes - RD-Aspen ----------------------------- The ``rd-aspen`` platform is currently implemented in U-Boot as downstream patches at :repo:`yocto/meta-arm-bsp-extras/recipes-bsp/u-boot/files/fvp-rd-aspen`. * Migrate ``sev`` and ``wfe`` definitions to common Arm headers. * Armv8 Generic Timer to use event stream for ``udelay``. * VExpress64 set the ``DM_RNG`` property. .. _rd-aspen_design_components_systemd-boot: systemd-boot ============ :link_subs:`rd-aspen:systemd-boot-doc` is a lightweight UEFI boot manager. It takes over control from U-Boot and then boots Linux. *********************** System Management Block *********************** The System Management Block (SMB) consists of the RSE Block, the Safety Island Block and the System Management Domain, as well as expansion interfaces for system management functions including SCMI services. .. image:: ../images/aspen_system_management_block.png :align: center :alt: System Management Block .. _rd-aspen_design_components_rse: RSE === Runtime Security Engine (RSE) is based on Cortex-M55 core and is a security subsystem fulfilling the role of Root of Trust. RSE provides an isolated Secure environment to provide security services to applications/services running in the PE Secure and Non-secure physical address spaces (PAS). In the current software stack, RSE offers: * Secure boot, further details of which can be found in the :link_subs:`rd-aspen:tf-m-sb` documentation. The following address range in the RSE memory map provides a window into system address space: .. list-table:: :widths: 50 50 25 :header-rows: 1 * - From - To - Region * - 0x6000_0000 - 0x6FFF_FFFF - ATU Non-secure data access * - 0x7000_0000 - 0x7FFF_FFFF - ATU Secure data access Safety Island block =================== The Safety Island Block is a subsystem comprising of one or more Cortex-R82AE CPU clusters. The software running on the Safety Island uses the SCP-firmware framework and is responsible for power, clock and CMN control. The number of clusters and cores depends on the chosen configuration. In the "min" configuration (the only one currently implemented), there is only one cluster with a single pair of dual lock-step cores. The Safety Island Block contains a GIC-720AE interrupt controller. SCP-firmware ------------ The SCP-firmware project provides a software reference implementation for dedicated system control processors that are used to abstract power and system management tasks away from application processors. In CSS-Aspen, the Safety Island is responsible for system management tasks, so the SCP-firmware framework is used. In CSS-Aspen, SCP-firmware is responsible for: * PPU control of the Primary Compute * CMN interconnect configuration * Runtime services: * Power domain management * System power management * System Control and Management Interface (SCMI, platform-side) MHUv3 Communication ~~~~~~~~~~~~~~~~~~~ The MHUv3 (Message Handling Unit version 3) facilitates communication between the Cortex-M of the RSE block running TF-M , the Cortex-A720AE running TF-A, and the Cortex-R82AE running SCP-firmware. SCMI (System Control and Management Interface) messages are transmitted using MHUv3 doorbell signals as the transport layer, with shared memory serving as the communication medium between the RSE, TF-A and SCP-firmware. On the RD-Aspen platform, SCMI communications occur in the following scenarios: * From the RSE to the SCP-firmware to confirm the SCP-firmware has booted successfully. * From the RSE to the SCP-firmware to power on AP primary core (cluster 0 core 0). * From the RSE to the SCP-firmware to subscribe to the system power state notifications. * From the TF-A to the SCP-firmware to power on AP secondary cores. * From the TF-A to the SCP-firmware to initiate a system power down or reset. * From the SCP-firmware to the RSE to notify of a system power down or reset. The diagram below illustrates the SCMI communication paths between the RSE, TF-A and SCP-firmware. | .. image:: ../images/scmi_comm_rse_tfa_scp.* :align: center :alt: SCMI Communication Between RSE, TF-A and SCP-firmware | The ``rd-aspen`` platform is currently implemented as downstream patches at :repo:`yocto/meta-arm-bsp-extras/recipes-bsp/scp-firmware/files/fvp-rd-aspen`. System management domain ======================== The System Management Domain (SMD) consists of shared peripherals, SRAM and an interconnect that connects the AP, RSE and SI blocks. ************** Address spaces ************** There are multiple address spaces in the system, each with address widths of up to 48 bits. Every component falls inside one of those regions. System interconnects handle addresses of 52-bit width, with the top 4 bits used to distinguish between the regions. Address Translation Units (ATUs) are located in the RSE, Safety Island, and SMD. They can be configured to map a system-wide 52-bit address range into a region-local logical window, to allow data accesses from one region to another. The system-wide regions are as follows: .. list-table:: :widths: 50 50 25 :header-rows: 1 * - From - To - Region * - 0x0_0000_0000_0000 - 0x0_FFFF_FFFF_FFFF - AP address space * - 0x2_0000_0000_0000 - 0x2_0000_FFFF_FFFF - SMD address space * - 0x3_0000_0000_0000 - 0x3_0000_FFFF_FFFF - RSE address space * - 0x4_0000_0000_0000 - 0x4_00FF_FFFF_FFFF - Safety Island address space The Safety Island owns the configuration of its ATU. The configuration of the RSE and SMD ATUs is owned by RSE.