andrius
/
arm-trusted-firmware
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
arm-trusted-firmware/plat/arm/board/fvp/platform.mk

432 lines
13 KiB
Makefile
Raw Normal View History

Build system: Fixes #2: Add multi-platform support Move all explicit platform or architecture specific references into a new platform.mk file that is defined for each platform. Change-Id: I9d6320d1ba957e0cc8d9b316b3578132331fa428 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
2014-01-13 12:37:03 +00:00
#
refactor(fvp): avoid Measured-Boot dependency on Trusted-Boot As Measured-Boot and Trusted-Boot are orthogonal, removed Trusted-Boot's dependency on Measured-Boot by allowing them to apply the Crypto module changes independently using the CRYPTO_SUPPORT build flag. Change-Id: I5a420e5d84f3fefe0c0092d822dab981e6390bbf Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
2022-01-08 23:08:02 +00:00
# Copyright (c) 2013-2022, Arm Limited and Contributors. All rights reserved.
Build system: Fixes #2: Add multi-platform support Move all explicit platform or architecture specific references into a new platform.mk file that is defined for each platform. Change-Id: I9d6320d1ba957e0cc8d9b316b3578132331fa428 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
2014-01-13 12:37:03 +00:00
#
Use SPDX license identifiers To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file. NOTE: Files that have been imported by FreeBSD have not been modified. [0]: https://spdx.org/ Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-05-03 09:38:09 +01:00
# SPDX-License-Identifier: BSD-3-Clause
Build system: Fixes #2: Add multi-platform support Move all explicit platform or architecture specific references into a new platform.mk file that is defined for each platform. Change-Id: I9d6320d1ba957e0cc8d9b316b3578132331fa428 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
2014-01-13 12:37:03 +00:00
#
build(fdt-wrappers): introduce FDT wrappers makefile This has been introduced to simplify dependencies on the FDT wrappers. We generally want to avoid pulling in components on a file-by-file basis, particularly as we are trying to draw conceptual boxes around components in preparation for transitioning the build system to CMake, where dependencies are modelled on libraries rather than files. Signed-off-by: Chris Kay <chris.kay@arm.com> Change-Id: Idb7ee05a9b54a8caa3e07f36e608867e20b6dcd5
2021-09-28 15:52:14 +01:00
include common/fdt_wrappers.mk
Change the default driver to GICv3 in FVP This patch changes the default driver for FVP platform from the deprecated GICv3 legacy to the GICv3 only driver. This means that the default build of Trusted Firmware will not be able boot Linux kernel with GICv2 FDT blob. The user guide is also updated to reflect this change of default GIC driver for FVP. Change-Id: Id6fc8c1ac16ad633dabb3cd189b690415a047764
2016-04-07 17:40:04 +01:00
# Use the GICv3 driver on the FVP by default
FVP_USE_GIC_DRIVER := FVP_GICV3
FVP: Add support for multi-threaded CPUs ARM CPUs with multi-threading implementation has more than one Processing Element in a single physical CPU. Such an implementation will reflect the following changes in the MPIDR register: - The MT bit set; - Affinity levels pertaining to cluster and CPUs occupy one level higher than in a single-threaded implementation, and the lowest affinity level pertains to hardware threads. MPIDR affinity level fields essentially appear shifted to left than otherwise. The FVP port henceforth assumes that both properties above to be concomitant on a given FVP platform. To accommodate for varied MPIDR formats at run time, this patch re-implements the FVP platform-specific functions that translates MPIDR values to a linear indices, along with required validation. The same treatment is applied for GICv3 MPIDR hashing function as well. An FVP-specific build option FVP_MAX_PE_PER_CPU is introduced which specifies the maximum number of threads implemented per CPU. For backwards compatibility, its value defaults to 1. Change-Id: I729b00d3e121d16ce9a03de4f9db36dfac580e3f Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2016-11-15 13:53:57 +00:00
# Default cluster count for FVP
FVP_CLUSTER_COUNT := 2
FVP: Allow building for DynamIQ systems FVPs that model DynamIQ configuration implements all CPUs in a single cluster. I.e., such models have a single cluster with more than 4 CPUs. This differs from existing default build configuration for FVP where up to 4 CPUs are assumed per cluster. To allow building for DynamIQ configuration, promote the macro FVP_MAX_CPUS_PER_CLUSTER as a build option to have it set from the build command line. The value of the build option defaults to 4. Change-Id: Idc3853bc95f680869b434b011c2dbd733e40c6ce Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-01-31 14:52:08 +00:00
# Default number of CPUs per cluster on FVP
FVP_MAX_CPUS_PER_CLUSTER := 4
FVP: Add support for multi-threaded CPUs ARM CPUs with multi-threading implementation has more than one Processing Element in a single physical CPU. Such an implementation will reflect the following changes in the MPIDR register: - The MT bit set; - Affinity levels pertaining to cluster and CPUs occupy one level higher than in a single-threaded implementation, and the lowest affinity level pertains to hardware threads. MPIDR affinity level fields essentially appear shifted to left than otherwise. The FVP port henceforth assumes that both properties above to be concomitant on a given FVP platform. To accommodate for varied MPIDR formats at run time, this patch re-implements the FVP platform-specific functions that translates MPIDR values to a linear indices, along with required validation. The same treatment is applied for GICv3 MPIDR hashing function as well. An FVP-specific build option FVP_MAX_PE_PER_CPU is introduced which specifies the maximum number of threads implemented per CPU. For backwards compatibility, its value defaults to 1. Change-Id: I729b00d3e121d16ce9a03de4f9db36dfac580e3f Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2016-11-15 13:53:57 +00:00
# Default number of threads per CPU on FVP
FVP_MAX_PE_PER_CPU := 1
plat/arm: fvp: Protect GICR frames for fused/unused cores Currently, BLs are mapping the GIC memory region as read-write for all cores on boot-up. This opens up the security hole where the active core can write the GICR frame of fused/inactive core. To avoid this issue, disable the GICR frame of all inactive cores as below: 1. After primary CPU boots up, map GICR region of all cores as read-only. 2. After primary CPU boots up, map its GICR region as read-write and initialize its redistributor interface. 3. After secondary CPU boots up, map its GICR region as read-write and initialize its redistributor interface. 4. All unused/fused core's redistributor regions remain read-only and write attempt to such protected regions results in an exception. As mentioned above, this patch offers only the GICR memory-mapped region protection considering there is no facility at the GIC IP level to avoid writing the redistributor area. These changes are currently done in BL31 of Arm FVP and guarded under the flag 'FVP_GICR_REGION_PROTECTION'. As of now, this patch is tested manually as below: 1. Disable the FVP cores (core 1, 2, 3) with core 0 as an active core. 2. Verify data abort triggered by manually updating the ‘GICR_CTLR’ register of core 1’s(fused) redistributor from core 0(active). Change-Id: I86c99c7b41bae137b2011cf2ac17fad0a26e776d Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
2021-01-24 03:26:50 +00:00
# Disable redistributor frame of inactive/fused CPU cores by marking it as read
# only; enable redistributor frames of all CPU cores by default.
FVP_GICR_REGION_PROTECTION := 0
FVP: Add TB_FW_CONFIG and HW_CONFIG This patch adds TB_FW_CONFIG for FVP and allows FVP to select the appropriate HW_CONFIG to include in the fip. The HW_CONFIG for FVP is selected via `FVP_HW_CONFIG_DTS` build option. The TB_FW_CONFIG specifies the load address of HW_CONFIG to BL2. Since currently the load address is different between AARCH32 and AARCH64, 2 separate TB_FW_CONFIGs are maintained for the 2 modes. Change-Id: Ide8581e752dfa900087f5895c775073c841c0daf Signed-Off-By: Soby Mathew <soby.mathew@arm.com>
2018-02-08 11:39:38 +00:00
FVP_DT_PREFIX := fvp-base-gicv3-psci
Rework use of ARM GIC drivers on ARM platforms Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases: 1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400 2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features 3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems. ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver. 2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build. 3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts. The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems. This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed. Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
2015-11-03 14:18:34 +00:00
# The FVP platform depends on this macro to build with correct GIC driver.
$(eval $(call add_define,FVP_USE_GIC_DRIVER))
FVP: Add support for multi-threaded CPUs ARM CPUs with multi-threading implementation has more than one Processing Element in a single physical CPU. Such an implementation will reflect the following changes in the MPIDR register: - The MT bit set; - Affinity levels pertaining to cluster and CPUs occupy one level higher than in a single-threaded implementation, and the lowest affinity level pertains to hardware threads. MPIDR affinity level fields essentially appear shifted to left than otherwise. The FVP port henceforth assumes that both properties above to be concomitant on a given FVP platform. To accommodate for varied MPIDR formats at run time, this patch re-implements the FVP platform-specific functions that translates MPIDR values to a linear indices, along with required validation. The same treatment is applied for GICv3 MPIDR hashing function as well. An FVP-specific build option FVP_MAX_PE_PER_CPU is introduced which specifies the maximum number of threads implemented per CPU. For backwards compatibility, its value defaults to 1. Change-Id: I729b00d3e121d16ce9a03de4f9db36dfac580e3f Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2016-11-15 13:53:57 +00:00
# Pass FVP_CLUSTER_COUNT to the build system.
Allow multi cluster topology definitions for ARM platforms The common topology description helper funtions and macros for ARM Standard platforms assumed a dual cluster system. This is not flexible enough to scale to multi cluster platforms. This patch does the following changes for more flexibility in defining topology: 1. The `plat_get_power_domain_tree_desc()` definition is moved from `arm_topology.c` to platform specific files, that is `fvp_topology.c` and `juno_topology.c`. Similarly the common definition of the porting macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform specific `platform_def.h` header. 2. The ARM common layer porting macros which were dual cluster specific are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced which must be defined by each ARM standard platform. 3. A new mandatory ARM common layer porting API `plat_arm_get_cluster_core_count()` is introduced to enable the common implementation of `arm_check_mpidr()` to validate MPIDR. 4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been introduced which allows the user to specify the cluster count to be used to build the topology tree within Trusted Firmare. This enables Trusted Firmware to be built for multi cluster FVP models. Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
2016-02-01 14:04:34 +00:00
$(eval $(call add_define,FVP_CLUSTER_COUNT))
Add CCN support to FVP platform port This patch adds support to select CCN driver for FVP during build. A new build option `FVP_INTERCONNECT_DRIVER` is added to allow selection between the CCI and CCN driver. Currently only the CCN-502 variant is supported on FVP. The common ARM CCN platform helper file now verifies the cluster count declared by platform is equal to the number of root node masters exported by the ARM Standard platform. Change-Id: I71d7b4785f8925ed499c153b2e9b9925fcefd57a
2016-03-24 10:12:42 +00:00
FVP: Allow building for DynamIQ systems FVPs that model DynamIQ configuration implements all CPUs in a single cluster. I.e., such models have a single cluster with more than 4 CPUs. This differs from existing default build configuration for FVP where up to 4 CPUs are assumed per cluster. To allow building for DynamIQ configuration, promote the macro FVP_MAX_CPUS_PER_CLUSTER as a build option to have it set from the build command line. The value of the build option defaults to 4. Change-Id: Idc3853bc95f680869b434b011c2dbd733e40c6ce Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-01-31 14:52:08 +00:00
# Pass FVP_MAX_CPUS_PER_CLUSTER to the build system.
$(eval $(call add_define,FVP_MAX_CPUS_PER_CLUSTER))
FVP: Add support for multi-threaded CPUs ARM CPUs with multi-threading implementation has more than one Processing Element in a single physical CPU. Such an implementation will reflect the following changes in the MPIDR register: - The MT bit set; - Affinity levels pertaining to cluster and CPUs occupy one level higher than in a single-threaded implementation, and the lowest affinity level pertains to hardware threads. MPIDR affinity level fields essentially appear shifted to left than otherwise. The FVP port henceforth assumes that both properties above to be concomitant on a given FVP platform. To accommodate for varied MPIDR formats at run time, this patch re-implements the FVP platform-specific functions that translates MPIDR values to a linear indices, along with required validation. The same treatment is applied for GICv3 MPIDR hashing function as well. An FVP-specific build option FVP_MAX_PE_PER_CPU is introduced which specifies the maximum number of threads implemented per CPU. For backwards compatibility, its value defaults to 1. Change-Id: I729b00d3e121d16ce9a03de4f9db36dfac580e3f Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2016-11-15 13:53:57 +00:00
# Pass FVP_MAX_PE_PER_CPU to the build system.
$(eval $(call add_define,FVP_MAX_PE_PER_CPU))
plat/arm: fvp: Protect GICR frames for fused/unused cores Currently, BLs are mapping the GIC memory region as read-write for all cores on boot-up. This opens up the security hole where the active core can write the GICR frame of fused/inactive core. To avoid this issue, disable the GICR frame of all inactive cores as below: 1. After primary CPU boots up, map GICR region of all cores as read-only. 2. After primary CPU boots up, map its GICR region as read-write and initialize its redistributor interface. 3. After secondary CPU boots up, map its GICR region as read-write and initialize its redistributor interface. 4. All unused/fused core's redistributor regions remain read-only and write attempt to such protected regions results in an exception. As mentioned above, this patch offers only the GICR memory-mapped region protection considering there is no facility at the GIC IP level to avoid writing the redistributor area. These changes are currently done in BL31 of Arm FVP and guarded under the flag 'FVP_GICR_REGION_PROTECTION'. As of now, this patch is tested manually as below: 1. Disable the FVP cores (core 1, 2, 3) with core 0 as an active core. 2. Verify data abort triggered by manually updating the ‘GICR_CTLR’ register of core 1’s(fused) redistributor from core 0(active). Change-Id: I86c99c7b41bae137b2011cf2ac17fad0a26e776d Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
2021-01-24 03:26:50 +00:00
# Pass FVP_GICR_REGION_PROTECTION to the build system.
$(eval $(call add_define,FVP_GICR_REGION_PROTECTION))
Add CCN support to FVP platform port This patch adds support to select CCN driver for FVP during build. A new build option `FVP_INTERCONNECT_DRIVER` is added to allow selection between the CCI and CCN driver. Currently only the CCN-502 variant is supported on FVP. The common ARM CCN platform helper file now verifies the cluster count declared by platform is equal to the number of root node masters exported by the ARM Standard platform. Change-Id: I71d7b4785f8925ed499c153b2e9b9925fcefd57a
2016-03-24 10:12:42 +00:00
# Sanity check the cluster count and if FVP_CLUSTER_COUNT <= 2,
# choose the CCI driver , else the CCN driver
ifeq ($(FVP_CLUSTER_COUNT), 0)
$(error "Incorrect cluster count specified for FVP port")
else ifeq ($(FVP_CLUSTER_COUNT),$(filter $(FVP_CLUSTER_COUNT),1 2))
FVP_INTERCONNECT_DRIVER := FVP_CCI
else
FVP_INTERCONNECT_DRIVER := FVP_CCN
Allow multi cluster topology definitions for ARM platforms The common topology description helper funtions and macros for ARM Standard platforms assumed a dual cluster system. This is not flexible enough to scale to multi cluster platforms. This patch does the following changes for more flexibility in defining topology: 1. The `plat_get_power_domain_tree_desc()` definition is moved from `arm_topology.c` to platform specific files, that is `fvp_topology.c` and `juno_topology.c`. Similarly the common definition of the porting macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform specific `platform_def.h` header. 2. The ARM common layer porting macros which were dual cluster specific are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced which must be defined by each ARM standard platform. 3. A new mandatory ARM common layer porting API `plat_arm_get_cluster_core_count()` is introduced to enable the common implementation of `arm_check_mpidr()` to validate MPIDR. 4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been introduced which allows the user to specify the cluster count to be used to build the topology tree within Trusted Firmare. This enables Trusted Firmware to be built for multi cluster FVP models. Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
2016-02-01 14:04:34 +00:00
endif
Add CCN support to FVP platform port This patch adds support to select CCN driver for FVP during build. A new build option `FVP_INTERCONNECT_DRIVER` is added to allow selection between the CCI and CCN driver. Currently only the CCN-502 variant is supported on FVP. The common ARM CCN platform helper file now verifies the cluster count declared by platform is equal to the number of root node masters exported by the ARM Standard platform. Change-Id: I71d7b4785f8925ed499c153b2e9b9925fcefd57a
2016-03-24 10:12:42 +00:00
$(eval $(call add_define,FVP_INTERCONNECT_DRIVER))
TF-A GICv3 driver: Introduce makefile This patch moves all GICv3 driver files into new added 'gicv3.mk' makefile for the benefit of the generic driver which can evolve in the future without affecting platforms. The patch adds GICv3 driver configuration flags 'GICV3_IMPL', 'GICV3_IMPL_GIC600_MULTICHIP' and 'GICV3_OVERRIDE_DISTIF_PWR_OPS' described in 'GICv3 driver options' section of 'build-option.rst' document. NOTE: Platforms with GICv3 driver need to be modified to include 'drivers/arm/gic/v3/gicv3.mk' in their makefiles. Change-Id: If055f6770ff20f5dee5a3c99ae7ced7cdcac5c44 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2020-03-23 18:45:17 +00:00
# Choose the GIC sources depending upon the how the FVP will be invoked
GICv3: GIC-600: Detect GIC-600 at runtime The only difference between GIC-500 and GIC-600 relevant to TF-A is the differing power management sequence. A certain GIC implementation is detectable at runtime, for instance by checking the IIDR register. Let's add that test before initiating the GIC-600 specific sequence, so the code can be used on both GIC-600 and GIC-500 chips alike, without deciding on a GIC chip at compile time. This means that the GIC-500 "driver" is now redundant. To allow minimal platform support, add a switch to disable GIC-600 support. Change-Id: I17ea97d9fb05874772ebaa13e6678b4ba3415557 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2020-03-25 15:50:38 +00:00
ifeq (${FVP_USE_GIC_DRIVER}, FVP_GICV3)
TF-A GICv3 driver: Introduce makefile This patch moves all GICv3 driver files into new added 'gicv3.mk' makefile for the benefit of the generic driver which can evolve in the future without affecting platforms. The patch adds GICv3 driver configuration flags 'GICV3_IMPL', 'GICV3_IMPL_GIC600_MULTICHIP' and 'GICV3_OVERRIDE_DISTIF_PWR_OPS' described in 'GICv3 driver options' section of 'build-option.rst' document. NOTE: Platforms with GICv3 driver need to be modified to include 'drivers/arm/gic/v3/gicv3.mk' in their makefiles. Change-Id: If055f6770ff20f5dee5a3c99ae7ced7cdcac5c44 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2020-03-23 18:45:17 +00:00
GICv3: GIC-600: Detect GIC-600 at runtime The only difference between GIC-500 and GIC-600 relevant to TF-A is the differing power management sequence. A certain GIC implementation is detectable at runtime, for instance by checking the IIDR register. Let's add that test before initiating the GIC-600 specific sequence, so the code can be used on both GIC-600 and GIC-500 chips alike, without deciding on a GIC chip at compile time. This means that the GIC-500 "driver" is now redundant. To allow minimal platform support, add a switch to disable GIC-600 support. Change-Id: I17ea97d9fb05874772ebaa13e6678b4ba3415557 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2020-03-25 15:50:38 +00:00
# The GIC model (GIC-600 or GIC-500) will be detected at runtime
GICV3_SUPPORT_GIC600 := 1
TF-A GICv3 driver: Introduce makefile This patch moves all GICv3 driver files into new added 'gicv3.mk' makefile for the benefit of the generic driver which can evolve in the future without affecting platforms. The patch adds GICv3 driver configuration flags 'GICV3_IMPL', 'GICV3_IMPL_GIC600_MULTICHIP' and 'GICV3_OVERRIDE_DISTIF_PWR_OPS' described in 'GICv3 driver options' section of 'build-option.rst' document. NOTE: Platforms with GICv3 driver need to be modified to include 'drivers/arm/gic/v3/gicv3.mk' in their makefiles. Change-Id: If055f6770ff20f5dee5a3c99ae7ced7cdcac5c44 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2020-03-23 18:45:17 +00:00
GICV3_OVERRIDE_DISTIF_PWR_OPS := 1
# Include GICv3 driver files
include drivers/arm/gic/v3/gicv3.mk
FVP_GIC_SOURCES := ${GICV3_SOURCES} \
Rework use of ARM GIC drivers on ARM platforms Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases: 1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400 2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features 3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems. ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver. 2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build. 3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts. The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems. This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed. Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
2015-11-03 14:18:34 +00:00
plat/common/plat_gicv3.c \
plat/arm/common/arm_gicv3.c
Introduce ARM GIC-600 driver ARM GIC-600 IP complies with ARM GICv3 architecture, but among others, implements a power control register in the Redistributor frame. This register must be programmed to mark the frame as powered on, before accessing other registers in the frame. Rest of initialization sequence remains the same. The driver provides APIs for Redistributor power management, and overrides those in the generic GICv3 driver. The driver data is shared between generic GICv3 driver and that of GIC-600. For FVP platform, the GIC-600 driver is chosen when FVP_USE_GIC_DRIVER is set to FVP_GIC600. Also update user guide. Change-Id: I321b2360728d69f6d4b0a747b2cfcc3fe5a20d67 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2016-12-06 16:15:22 +00:00
plat/fvp: Populate GICv3 parameters dynamically Query the GICD and GICR base addresses in runtime using fconf getter APIs. Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com> Change-Id: I309fb2874f3329ddeb8677ddb53ed4c02199a1e9
2020-05-12 16:58:11 +01:00
ifeq ($(filter 1,${BL2_AT_EL3} ${RESET_TO_BL31} ${RESET_TO_SP_MIN}),)
FVP_GIC_SOURCES += plat/arm/board/fvp/fvp_gicv3.c
endif
Rework use of ARM GIC drivers on ARM platforms Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases: 1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400 2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features 3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems. ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver. 2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build. 3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts. The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems. This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed. Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
2015-11-03 14:18:34 +00:00
else ifeq (${FVP_USE_GIC_DRIVER}, FVP_GICV2)
FVP: Add support for GICv4 extension This patch adds support for GICv4 extension for FVP platform. Change-Id: Ia389b61266af669b1ca9b999a8b76476cab214f4 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2020-04-07 11:48:00 +01:00
# No GICv4 extension
GIC_ENABLE_V4_EXTN := 0
$(eval $(call add_define,GIC_ENABLE_V4_EXTN))
TF-A GICv2 driver: Introduce makefile This patch moves all GICv2 driver files into new added 'gicv2.mk' makefile for the benefit of the generic driver which can evolve in the future without affecting platforms. NOTE: Usage of 'drivers/arm/gic/common/gic_common.c' file is now deprecated and platforms with GICv2 driver need to be modified to include 'drivers/arm/gic/v2/gicv2.mk' in their makefiles. Change-Id: Ib10e71bdda0e5c7e80a049ddce2de1dd839602d1 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2020-07-14 10:47:25 +01:00
# Include GICv2 driver files
include drivers/arm/gic/v2/gicv2.mk
FVP: Add support for GICv4 extension This patch adds support for GICv4 extension for FVP platform. Change-Id: Ia389b61266af669b1ca9b999a8b76476cab214f4 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2020-04-07 11:48:00 +01:00
TF-A GICv2 driver: Introduce makefile This patch moves all GICv2 driver files into new added 'gicv2.mk' makefile for the benefit of the generic driver which can evolve in the future without affecting platforms. NOTE: Usage of 'drivers/arm/gic/common/gic_common.c' file is now deprecated and platforms with GICv2 driver need to be modified to include 'drivers/arm/gic/v2/gicv2.mk' in their makefiles. Change-Id: Ib10e71bdda0e5c7e80a049ddce2de1dd839602d1 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2020-07-14 10:47:25 +01:00
FVP_GIC_SOURCES := ${GICV2_SOURCES} \
Rework use of ARM GIC drivers on ARM platforms Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases: 1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400 2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features 3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems. ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver. 2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build. 3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts. The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems. This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed. Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
2015-11-03 14:18:34 +00:00
plat/common/plat_gicv2.c \
plat/arm/common/arm_gicv2.c
FVP: Add TB_FW_CONFIG and HW_CONFIG This patch adds TB_FW_CONFIG for FVP and allows FVP to select the appropriate HW_CONFIG to include in the fip. The HW_CONFIG for FVP is selected via `FVP_HW_CONFIG_DTS` build option. The TB_FW_CONFIG specifies the load address of HW_CONFIG to BL2. Since currently the load address is different between AARCH32 and AARCH64, 2 separate TB_FW_CONFIGs are maintained for the 2 modes. Change-Id: Ide8581e752dfa900087f5895c775073c841c0daf Signed-Off-By: Soby Mathew <soby.mathew@arm.com>
2018-02-08 11:39:38 +00:00
FVP_DT_PREFIX := fvp-base-gicv2-psci
Rework use of ARM GIC drivers on ARM platforms Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases: 1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400 2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features 3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems. ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver. 2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build. 3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts. The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems. This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed. Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
2015-11-03 14:18:34 +00:00
else
$(error "Incorrect GIC driver chosen on FVP port")
endif
Add CCN support to FVP platform port This patch adds support to select CCN driver for FVP during build. A new build option `FVP_INTERCONNECT_DRIVER` is added to allow selection between the CCI and CCN driver. Currently only the CCN-502 variant is supported on FVP. The common ARM CCN platform helper file now verifies the cluster count declared by platform is equal to the number of root node masters exported by the ARM Standard platform. Change-Id: I71d7b4785f8925ed499c153b2e9b9925fcefd57a
2016-03-24 10:12:42 +00:00
ifeq (${FVP_INTERCONNECT_DRIVER}, FVP_CCI)
FVP: Support Base FVP RevC Revision C of the Base FVP has the same memory map as earlier revisions, but has the following differences: - Implements CCI550 instead of CCI400, - Has a single instantiation of SMMUv3, - CPU MPIDs are shifted left by one level, and has MT bit set in them. The correct interconnect to program is chosen at run time based on the FVP revision. Therefore, this patch implements FVP functions for interconnect programming, rather than depending on ARM generic ones. The macros used have been renamed to reflect this change. Additionally, this patch initializes SMMUv3 as part of FVP early platform setup. New ARM config flags are introduced for feature queries at run time. Change-Id: Ic7b7f080953a51fceaf62ce7daa6de0573801f09 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-07-18 15:42:50 +01:00
FVP_INTERCONNECT_SOURCES := drivers/arm/cci/cci.c
Add CCN support to FVP platform port This patch adds support to select CCN driver for FVP during build. A new build option `FVP_INTERCONNECT_DRIVER` is added to allow selection between the CCI and CCN driver. Currently only the CCN-502 variant is supported on FVP. The common ARM CCN platform helper file now verifies the cluster count declared by platform is equal to the number of root node masters exported by the ARM Standard platform. Change-Id: I71d7b4785f8925ed499c153b2e9b9925fcefd57a
2016-03-24 10:12:42 +00:00
else ifeq (${FVP_INTERCONNECT_DRIVER}, FVP_CCN)
FVP_INTERCONNECT_SOURCES := drivers/arm/ccn/ccn.c \
plat/arm/common/arm_ccn.c
else
$(error "Incorrect CCN driver chosen on FVP port")
endif
Rework use of interconnect drivers ARM Trusted Firmware supports 2 different interconnect peripheral drivers: CCI and CCN. ARM platforms are implemented using either of the interconnect peripherals. This patch adds a layer of abstraction to help ARM platform ports to choose the right interconnect driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been implemented to initialise an interconnect and for entering/exiting a cluster from coherency. These functions are prefixed as "plat_arm_interconnect_". Weak definitions of these functions have been provided for each type of driver. 2.`plat_print_interconnect_regs` macro used for printing CCI registers is moved from a common arm_macros.S to cci_macros.S. 3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure is renamed to `ARM_CONFIG_HAS_INTERCONNECT`. Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
2016-02-15 11:54:14 +00:00
Migrate ARM standard platforms to the refactored TZC driver This patch migrates ARM Standard platforms to the refactored TZC driver. Change-Id: I2a2f60b645f73e14d8f416740c4551cec87cb1fb
2016-02-26 14:23:19 +00:00
FVP_SECURITY_SOURCES := drivers/arm/tzc/tzc400.c \
Perform security setup separately for each ARM platform Prior to this patch, it was assumed that on all ARM platforms the bare minimal security setup required is to program TrustZone protection. This would always be done by programming the TZC-400 which was assumed to be present in all ARM platforms. The weak definition of platform_arm_security_setup() in plat/arm/common/arm_security.c reflected these assumptions. In reality, each ARM platform either decides at runtime whether TrustZone protection needs to be programmed (e.g. FVPs) or performs some security setup in addition to programming TrustZone protection (e.g. NIC setup on Juno). As a result, the weak definition of plat_arm_security_setup() is always overridden. When a platform needs to program TrustZone protection and implements the TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is also possible to program TrustZone protection through other peripherals that include a TrustZone controller e.g. DMC-500. The programmer's interface is slightly different across these various peripherals. In order to satisfy the above requirements, this patch makes the following changes to the way security setup is done on ARM platforms. 1. arm_security.c retains the definition of arm_tzc_setup() and has been renamed to arm_tzc400.c. This is to reflect the reliance on the TZC-400 peripheral to perform TrustZone programming. The new file is not automatically included in all platform ports through arm_common.mk. Each platform must include it explicitly in a platform specific makefile if needed. This approach enables introduction of similar library code to program TrustZone protection using a different peripheral. This code would be used by the subset of ARM platforms that implement this peripheral. 2. Due to #1 above, existing platforms which implements the TZC-400 have been updated to include the necessary files for both BL2, BL2U and BL31 images. Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735
2016-02-10 14:50:53 +00:00
plat/arm/board/fvp/fvp_security.c \
plat/arm/common/arm_tzc400.c
Rework use of interconnect drivers ARM Trusted Firmware supports 2 different interconnect peripheral drivers: CCI and CCN. ARM platforms are implemented using either of the interconnect peripherals. This patch adds a layer of abstraction to help ARM platform ports to choose the right interconnect driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been implemented to initialise an interconnect and for entering/exiting a cluster from coherency. These functions are prefixed as "plat_arm_interconnect_". Weak definitions of these functions have been provided for each type of driver. 2.`plat_print_interconnect_regs` macro used for printing CCI registers is moved from a common arm_macros.S to cci_macros.S. 3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure is renamed to `ARM_CONFIG_HAS_INTERCONNECT`. Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
2016-02-15 11:54:14 +00:00
TBB: add platform API to read the ROTPK information This patch extends the platform port by adding an API that returns either the Root of Trust public key (ROTPK) or its hash. This is usually stored in ROM or eFUSE memory. The ROTPK returned must be encoded in DER format according to the following ASN.1 structure: SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } In case the platform returns a hash of the key: DigestInfo ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier, keyDigest OCTET STRING } An implementation for ARM development platforms is provided in this patch. When TBB is enabled, the ROTPK hash location must be specified using the build option 'ARM_ROTPK_LOCATION'. Available options are: - 'regs' : return the ROTPK hash stored in the Trusted root-key storage registers. - 'devel_rsa' : return a ROTPK hash embedded in the BL1 and BL2 binaries. This hash has been obtained from the development RSA public key located in 'plat/arm/board/common/rotpk'. On FVP, the number of MMU tables has been increased to map and access the ROTPK registers. A new file 'board_common.mk' has been added to improve code sharing in the ARM develelopment platforms. Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
2015-04-14 12:49:03 +01:00
PLAT_INCLUDES := -Iplat/arm/board/fvp/include
fvp: Move TSP from Secure DRAM to Secure SRAM The TSP used to execute from secure DRAM on the FVPs because there was not enough space in Trusted SRAM to fit it in. Thanks to recent RAM usage enhancements being implemented, we have made enough savings for the TSP to execute in SRAM. However, there is no contiguous free chunk of SRAM big enough to hold the TSP. Therefore, the different bootloader images need to be moved around to reduce memory fragmentation. This patch keeps the overall memory layout (i.e. keeping BL1 R/W at the bottom, BL2 at the top and BL3-1 in between) but moves the base addresses of all the bootloader images in such a way that: - memory fragmentation is reduced enough to fit BL3-2 in; - new base addresses are suitable for release builds as well as debug ones; - each image has a few extra kilobytes for future growth. BL3-1 and BL3-2 are the images which received the biggest slice of the cake since they will most probably grow the most. A few useful numbers for reference (valid at the time of this patch): |-----------------------|------------------------------- | image size (debug) | extra space for the future --------|-----------------------|------------------------------- BL1 R/W | 20 KB | 4 KB BL2 | 44 KB | 4 KB BL3-1 | 108 KB | 12 KB BL3-2 | 56 KB | 8 KB --------|-----------------------|------------------------------- Total | 228 KB | 28 KB = 256 KB --------|-----------------------|------------------------------- Although on FVPs the TSP now executes from Trusted SRAM by default, this patch keeps the option to execute it from Trusted DRAM. This is controlled by the build configuration 'TSP_RAM_LOCATION'. Fixes ARM-Software/tf-issues#81 Change-Id: Ifb9ef2befa9a2d5ac0813f7f79834df7af992b94
2014-05-20 17:28:25 +01:00
Build system: Fixes #2: Add multi-platform support Move all explicit platform or architecture specific references into a new platform.mk file that is defined for each platform. Change-Id: I9d6320d1ba957e0cc8d9b316b3578132331fa428 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
2014-01-13 12:37:03 +00:00
Migrate platform ports to the new xlat_tables library This patch modifies the upstream platform port makefiles to use the new xlat_tables library files. This patch also makes mmap region setup common between AArch64 and AArch32 for FVP platform port. The file `fvp_common.c` is moved from the `plat/arm/board/fvp/aarch64` folder to the parent folder as it is not specific to AArch64. Change-Id: Id2e9aac45e46227b6f83cccfd1e915404018ea0b
2016-04-08 16:42:58 +01:00
PLAT_BL_COMMON_SOURCES := plat/arm/board/fvp/fvp_common.c
Build system: Fixes #2: Add multi-platform support Move all explicit platform or architecture specific references into a new platform.mk file that is defined for each platform. Change-Id: I9d6320d1ba957e0cc8d9b316b3578132331fa428 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
2014-01-13 12:37:03 +00:00
AArch32: Add essential ARM platform and FVP support This patch adds AArch32 support for FVP and implements common platform APIs like `plat_get_my_stack`, `plat_set_my_stack`, `plat_my_core_cos` for AArch32. Only Multi Processor(MP) implementations of these functions are considered in this patch. The ARM Standard platform layer helpers are implemented for AArch32 and the common makefiles are modified to cater for both AArch64 and AArch32 builds. Compatibility with the deprecated platform API is not supported for AArch32. Change-Id: Iad228400613eec91abf731b49e21a15bcf2833ea
2016-07-11 14:13:56 +01:00
FVP_CPU_LIBS := lib/cpus/${ARCH}/aem_generic.S
ifeq (${ARCH}, aarch64)
Add compile-time errors for HW_ASSISTED_COHERENCY flag This patch fixes this issue: https://github.com/ARM-software/tf-issues/issues/660 The introduced changes are the following: 1) Some cores implement cache coherency maintenance operation on the hardware level. For those cores, such as - but not only - the DynamIQ cores, it is mandatory that TF-A is compiled with the HW_ASSISTED_COHERENCY flag. If not, the core behaviour at runtime is unpredictable. To prevent this, compile time checks have been added and compilation errors are generated, if needed. 2) To enable this change for FVP, a logical separation has been done for the core libraries. A system cannot contain cores of both groups, i.e. cores that manage coherency on hardware and cores that don't do it. As such, depending on the HW_ASSISTED_COHERENCY flag, FVP includes the libraries only of the relevant cores. 3) The neoverse_e1.S file has been added to the FVP sources. Change-Id: I787d15819b2add4ec0d238249e04bf0497dc12f3 Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-03-19 17:20:52 +00:00
Apply compile-time check for AArch64-only cores Some cores support only AArch64 mode. In those cores, only a limited subset of the AArch32 system registers are implemented. Hence, if TF-A is supposed to run on AArch64-only cores, it must be compiled with CTX_INCLUDE_AARCH32_REGS=0. Currently, the default settings for compiling TF-A are with the AArch32 system registers included. So, if we compile TF-A the default way and attempt to run it on an AArch64-only core, we only get a runtime panic. Now a compile-time check has been added to ensure that this flag has the appropriate value when AArch64-only cores are included in the build. Change-Id: I298ec550037fafc9347baafb056926d149197d4c Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-06-03 13:54:30 +01:00
# select a different set of CPU files, depending on whether we compile for
# hardware assisted coherency cores or not
Add compile-time errors for HW_ASSISTED_COHERENCY flag This patch fixes this issue: https://github.com/ARM-software/tf-issues/issues/660 The introduced changes are the following: 1) Some cores implement cache coherency maintenance operation on the hardware level. For those cores, such as - but not only - the DynamIQ cores, it is mandatory that TF-A is compiled with the HW_ASSISTED_COHERENCY flag. If not, the core behaviour at runtime is unpredictable. To prevent this, compile time checks have been added and compilation errors are generated, if needed. 2) To enable this change for FVP, a logical separation has been done for the core libraries. A system cannot contain cores of both groups, i.e. cores that manage coherency on hardware and cores that don't do it. As such, depending on the HW_ASSISTED_COHERENCY flag, FVP includes the libraries only of the relevant cores. 3) The neoverse_e1.S file has been added to the FVP sources. Change-Id: I787d15819b2add4ec0d238249e04bf0497dc12f3 Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-03-19 17:20:52 +00:00
ifeq (${HW_ASSISTED_COHERENCY}, 0)
Modify FVP makefile for cores that support both AArch64/32 Some cores support only AArch64 from EL1 and above, e.g. A76, N1 etc. If TF-A is compiled with CTX_INCLUDE_AARCH32_REGS=0 so as to properly handle those cores, only the AArch64 cores' assembly is included in the TF-A binary. In other words, for FVP, TF-A assumes that AArch64 only cores will never exist in the same cluster with cores that also support AArch32. However, A55 and A75 can be used as AArch64 only cores, despite supporting AArch32, too. This patch enables A55 and A75 to exist in clusters together with AArch64 cores. Change-Id: I58750ad6c3d76ce77eb354784c2a42f2c179031d Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-08-13 10:11:41 +01:00
# Cores used without DSU
Add compile-time errors for HW_ASSISTED_COHERENCY flag This patch fixes this issue: https://github.com/ARM-software/tf-issues/issues/660 The introduced changes are the following: 1) Some cores implement cache coherency maintenance operation on the hardware level. For those cores, such as - but not only - the DynamIQ cores, it is mandatory that TF-A is compiled with the HW_ASSISTED_COHERENCY flag. If not, the core behaviour at runtime is unpredictable. To prevent this, compile time checks have been added and compilation errors are generated, if needed. 2) To enable this change for FVP, a logical separation has been done for the core libraries. A system cannot contain cores of both groups, i.e. cores that manage coherency on hardware and cores that don't do it. As such, depending on the HW_ASSISTED_COHERENCY flag, FVP includes the libraries only of the relevant cores. 3) The neoverse_e1.S file has been added to the FVP sources. Change-Id: I787d15819b2add4ec0d238249e04bf0497dc12f3 Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-03-19 17:20:52 +00:00
FVP_CPU_LIBS += lib/cpus/aarch64/cortex_a35.S \
Introduce framework for CPU specific operations This patch introduces a framework which will allow CPUs to perform implementation defined actions after a CPU reset, during a CPU or cluster power down, and when a crash occurs. CPU specific reset handlers have been implemented in this patch. Other handlers will be implemented in subsequent patches. Also moved cpu_helpers.S to the new directory lib/cpus/aarch64/. Change-Id: I1ca1bade4d101d11a898fb30fea2669f9b37b956
2014-08-14 11:33:56 +01:00
lib/cpus/aarch64/cortex_a53.S \
lib/cpus/aarch64/cortex_a57.S \
Add support for ARM Cortex-A73 MPCore Processor This patch adds ARM Cortex-A73 MPCore Processor support in the CPU specific operations framework. It also includes this support for the Base FVP port. Change-Id: I0e26b594f2ec1d28eb815db9810c682e3885716d
2016-02-09 12:00:03 +00:00
lib/cpus/aarch64/cortex_a72.S \
Add compile-time errors for HW_ASSISTED_COHERENCY flag This patch fixes this issue: https://github.com/ARM-software/tf-issues/issues/660 The introduced changes are the following: 1) Some cores implement cache coherency maintenance operation on the hardware level. For those cores, such as - but not only - the DynamIQ cores, it is mandatory that TF-A is compiled with the HW_ASSISTED_COHERENCY flag. If not, the core behaviour at runtime is unpredictable. To prevent this, compile time checks have been added and compilation errors are generated, if needed. 2) To enable this change for FVP, a logical separation has been done for the core libraries. A system cannot contain cores of both groups, i.e. cores that manage coherency on hardware and cores that don't do it. As such, depending on the HW_ASSISTED_COHERENCY flag, FVP includes the libraries only of the relevant cores. 3) The neoverse_e1.S file has been added to the FVP sources. Change-Id: I787d15819b2add4ec0d238249e04bf0497dc12f3 Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-03-19 17:20:52 +00:00
lib/cpus/aarch64/cortex_a73.S
else
Modify FVP makefile for cores that support both AArch64/32 Some cores support only AArch64 from EL1 and above, e.g. A76, N1 etc. If TF-A is compiled with CTX_INCLUDE_AARCH32_REGS=0 so as to properly handle those cores, only the AArch64 cores' assembly is included in the TF-A binary. In other words, for FVP, TF-A assumes that AArch64 only cores will never exist in the same cluster with cores that also support AArch32. However, A55 and A75 can be used as AArch64 only cores, despite supporting AArch32, too. This patch enables A55 and A75 to exist in clusters together with AArch64 cores. Change-Id: I58750ad6c3d76ce77eb354784c2a42f2c179031d Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-08-13 10:11:41 +01:00
# Cores used with DSU only
Apply compile-time check for AArch64-only cores Some cores support only AArch64 mode. In those cores, only a limited subset of the AArch32 system registers are implemented. Hence, if TF-A is supposed to run on AArch64-only cores, it must be compiled with CTX_INCLUDE_AARCH32_REGS=0. Currently, the default settings for compiling TF-A are with the AArch32 system registers included. So, if we compile TF-A the default way and attempt to run it on an AArch64-only core, we only get a runtime panic. Now a compile-time check has been added to ensure that this flag has the appropriate value when AArch64-only cores are included in the build. Change-Id: I298ec550037fafc9347baafb056926d149197d4c Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-06-03 13:54:30 +01:00
ifeq (${CTX_INCLUDE_AARCH32_REGS}, 0)
Modify FVP makefile for cores that support both AArch64/32 Some cores support only AArch64 from EL1 and above, e.g. A76, N1 etc. If TF-A is compiled with CTX_INCLUDE_AARCH32_REGS=0 so as to properly handle those cores, only the AArch64 cores' assembly is included in the TF-A binary. In other words, for FVP, TF-A assumes that AArch64 only cores will never exist in the same cluster with cores that also support AArch32. However, A55 and A75 can be used as AArch64 only cores, despite supporting AArch32, too. This patch enables A55 and A75 to exist in clusters together with AArch64 cores. Change-Id: I58750ad6c3d76ce77eb354784c2a42f2c179031d Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-08-13 10:11:41 +01:00
# AArch64-only cores
Apply compile-time check for AArch64-only cores Some cores support only AArch64 mode. In those cores, only a limited subset of the AArch32 system registers are implemented. Hence, if TF-A is supposed to run on AArch64-only cores, it must be compiled with CTX_INCLUDE_AARCH32_REGS=0. Currently, the default settings for compiling TF-A are with the AArch32 system registers included. So, if we compile TF-A the default way and attempt to run it on an AArch64-only core, we only get a runtime panic. Now a compile-time check has been added to ensure that this flag has the appropriate value when AArch64-only cores are included in the build. Change-Id: I298ec550037fafc9347baafb056926d149197d4c Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-06-03 13:54:30 +01:00
FVP_CPU_LIBS += lib/cpus/aarch64/cortex_a76.S \
lib/cpus/aarch64/cortex_a76ae.S \
Rename Cortex-Deimos to Cortex-A77 Change-Id: I755e4c42242d9a052570fd1132ca3d937acadb13 Signed-off-by: Balint Dobszay <balint.dobszay@arm.com>
2019-07-03 12:02:56 +01:00
lib/cpus/aarch64/cortex_a77.S \
Rename Cortex Hercules Files to Cortex A78 This should allow git to easily track file moves Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com> Change-Id: I1592cf39a4f94209c560dc6d1a8bc1bfb21d8327
2020-06-01 22:49:34 +01:00
lib/cpus/aarch64/cortex_a78.S \
Add support for Neoverse-N2 CPUs. Enable basic support for Neoverse-N2 CPUs. Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com> Change-Id: I498adc2d9fc61ac6e1af8ece131039410872e8ad
2020-10-23 13:22:07 +01:00
lib/cpus/aarch64/neoverse_n_common.S \
Apply compile-time check for AArch64-only cores Some cores support only AArch64 mode. In those cores, only a limited subset of the AArch32 system registers are implemented. Hence, if TF-A is supposed to run on AArch64-only cores, it must be compiled with CTX_INCLUDE_AARCH32_REGS=0. Currently, the default settings for compiling TF-A are with the AArch32 system registers included. So, if we compile TF-A the default way and attempt to run it on an AArch64-only core, we only get a runtime panic. Now a compile-time check has been added to ensure that this flag has the appropriate value when AArch64-only cores are included in the build. Change-Id: I298ec550037fafc9347baafb056926d149197d4c Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-06-03 13:54:30 +01:00
lib/cpus/aarch64/neoverse_n1.S \
Add support for Neoverse-N2 CPUs. Enable basic support for Neoverse-N2 CPUs. Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com> Change-Id: I498adc2d9fc61ac6e1af8ece131039410872e8ad
2020-10-23 13:22:07 +01:00
lib/cpus/aarch64/neoverse_n2.S \
Apply compile-time check for AArch64-only cores Some cores support only AArch64 mode. In those cores, only a limited subset of the AArch32 system registers are implemented. Hence, if TF-A is supposed to run on AArch64-only cores, it must be compiled with CTX_INCLUDE_AARCH32_REGS=0. Currently, the default settings for compiling TF-A are with the AArch32 system registers included. So, if we compile TF-A the default way and attempt to run it on an AArch64-only core, we only get a runtime panic. Now a compile-time check has been added to ensure that this flag has the appropriate value when AArch64-only cores are included in the build. Change-Id: I298ec550037fafc9347baafb056926d149197d4c Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-06-03 13:54:30 +01:00
lib/cpus/aarch64/neoverse_e1.S \
Rename Neoverse Zeus to Neoverse V1 Change-Id: Ieb411e2f8092fa82062e619305b680673a8f184f Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
2020-09-30 21:28:03 +01:00
lib/cpus/aarch64/neoverse_v1.S \
fix(cpu): correct Demeter CPU name This patch changes Cortex Demeter to Neoverse Demeter. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: I7306d09ca60e101d0a96c9ceff9845422d75c160
2021-10-15 18:02:36 +01:00
lib/cpus/aarch64/neoverse_demeter.S \
Rename Cortex Hercules AE to Cortex 78 AE Change-Id: Ic0ca51a855660509264ff0d084c068e1421ad09a Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
2020-09-30 21:34:51 +01:00
lib/cpus/aarch64/cortex_a78_ae.S \
fix: rename Matterhorn, Matterhorn ELP, and Klein CPUs This patch renames the Matterhorn, Matterhorn ELP, and Klein CPUs to Cortex A710, Cortex X2, and Cortex A510 respectively. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: I056d3114210db71c2840a24562b51caf2546e195
2021-05-18 21:23:31 +01:00
lib/cpus/aarch64/cortex_a510.S \
lib/cpus/aarch64/cortex_a710.S \
Add Makalu CPU lib Add basic support for Makalu CPU. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: I4e85d425eedea499adf585eb8ab548931185043d
2020-10-15 19:40:04 +01:00
lib/cpus/aarch64/cortex_makalu.S \
Add "_arm" suffix to Makalu ELP CPU lib ELP processors can sometimes have different MIDR values or features so we are adding the "_arm" suffix to differentiate the reference implementation from other future versions. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: Ieea444288587c7c18a397d279ee4b22b7ad79e20
2021-04-20 23:05:04 +01:00
lib/cpus/aarch64/cortex_makalu_elp_arm.S \
Introducing support for Cortex-A65AE Change-Id: I1ea2bf088f1e001cdbd377cbfb7c6a2866af0422 Signed-off-by: Imre Kis <imre.kis@arm.com>
2019-07-22 13:36:30 +01:00
lib/cpus/aarch64/cortex_a65.S \
Add Cortex_A78C CPU lib Add basic support for Cortex_A78C CPU. Signed-off-by: Bipin Ravi <bipin.ravi@arm.com> Change-Id: Id9e41cbe0580a68c6412d194a5ee67940e8dae56
2021-03-16 20:20:58 +00:00
lib/cpus/aarch64/cortex_a65ae.S \
feat(cpu): add support for Hayes CPU This patch adds the basic CPU library code to support the Hayes CPU in TF-A. This CPU is based on the Klein core so that library code has been adapted for use here. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: If0e0070cfa77fee8f6eebfee13d3c4f209ad84fc
2021-08-19 22:12:50 +01:00
lib/cpus/aarch64/cortex_a78c.S \
feat(cpu): add support for Hunter CPU This patch adds the basic CPU library code to support the Hunter CPU in TF-A. This CPU is based on the Makalu core so that library code was adapted as the basis for this patch. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: I956b2dc0f43da7cec3e015252392e2694363e1b3
2021-08-19 22:51:26 +01:00
lib/cpus/aarch64/cortex_hayes.S \
fix(errata): workaround for Cortex X2 erratum 2083908 Cortex X2 erratum 2083908 is a Cat B erratum present in the Cortex X2 core. It applies to revision r2p0 and is still open. SDEN can be found here: https://developer.arm.com/documentation/SDEN1775100 Signed-off-by: John Powell <john.powell@arm.com> Change-Id: Id9dca2b042bf48e75fb3013ab37d1c5925824728
2021-12-01 23:40:39 +00:00
lib/cpus/aarch64/cortex_hunter.S \
feat(cpu): add library support for Poseidon CPU This patch adds the basic CPU library code to support the Poseidon CPU in TF-A. Poseidon is derived from HunterELP core, an implementation of v9.2 architecture. Currently, Hunter CPU the predecessor to HunterELP, is supported in TF-A. Accordingly the Hunter CPU library code has been as the base and adapted here. Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com> Change-Id: I406b4de156a67132e6a5523370115aaac933f18d
2021-12-07 17:20:10 +00:00
lib/cpus/aarch64/cortex_x2.S \
lib/cpus/aarch64/neoverse_poseidon.S
Apply compile-time check for AArch64-only cores Some cores support only AArch64 mode. In those cores, only a limited subset of the AArch32 system registers are implemented. Hence, if TF-A is supposed to run on AArch64-only cores, it must be compiled with CTX_INCLUDE_AARCH32_REGS=0. Currently, the default settings for compiling TF-A are with the AArch32 system registers included. So, if we compile TF-A the default way and attempt to run it on an AArch64-only core, we only get a runtime panic. Now a compile-time check has been added to ensure that this flag has the appropriate value when AArch64-only cores are included in the build. Change-Id: I298ec550037fafc9347baafb056926d149197d4c Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-06-03 13:54:30 +01:00
endif
Modify FVP makefile for cores that support both AArch64/32 Some cores support only AArch64 from EL1 and above, e.g. A76, N1 etc. If TF-A is compiled with CTX_INCLUDE_AARCH32_REGS=0 so as to properly handle those cores, only the AArch64 cores' assembly is included in the TF-A binary. In other words, for FVP, TF-A assumes that AArch64 only cores will never exist in the same cluster with cores that also support AArch32. However, A55 and A75 can be used as AArch64 only cores, despite supporting AArch32, too. This patch enables A55 and A75 to exist in clusters together with AArch64 cores. Change-Id: I58750ad6c3d76ce77eb354784c2a42f2c179031d Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-08-13 10:11:41 +01:00
# AArch64/AArch32 cores
FVP_CPU_LIBS += lib/cpus/aarch64/cortex_a55.S \
lib/cpus/aarch64/cortex_a75.S
Add compile-time errors for HW_ASSISTED_COHERENCY flag This patch fixes this issue: https://github.com/ARM-software/tf-issues/issues/660 The introduced changes are the following: 1) Some cores implement cache coherency maintenance operation on the hardware level. For those cores, such as - but not only - the DynamIQ cores, it is mandatory that TF-A is compiled with the HW_ASSISTED_COHERENCY flag. If not, the core behaviour at runtime is unpredictable. To prevent this, compile time checks have been added and compilation errors are generated, if needed. 2) To enable this change for FVP, a logical separation has been done for the core libraries. A system cannot contain cores of both groups, i.e. cores that manage coherency on hardware and cores that don't do it. As such, depending on the HW_ASSISTED_COHERENCY flag, FVP includes the libraries only of the relevant cores. 3) The neoverse_e1.S file has been added to the FVP sources. Change-Id: I787d15819b2add4ec0d238249e04bf0497dc12f3 Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-03-19 17:20:52 +00:00
endif
Introduce preliminary support for Neoverse Zeus Change-Id: If56d1e200a31bd716726d7fdc1cc0ae8a63ba3ee Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2018-10-08 17:09:43 +01:00
AArch32: Add support for ARM Cortex-A32 MPCore Processor This patch adds ARM Cortex-A32 MPCore Processor support in the CPU specific operations framework. It also includes this support for the Base FVP port. Change-Id: If3697b88678df737c29f79cf3fa1ea2cb6fa565d
2016-07-12 15:47:03 +01:00
else
FVP_CPU_LIBS += lib/cpus/aarch32/cortex_a32.S
AArch32: Add essential ARM platform and FVP support This patch adds AArch32 support for FVP and implements common platform APIs like `plat_get_my_stack`, `plat_set_my_stack`, `plat_my_core_cos` for AArch32. Only Multi Processor(MP) implementations of these functions are considered in this patch. The ARM Standard platform layer helpers are implemented for AArch32 and the common makefiles are modified to cater for both AArch64 and AArch32 builds. Compatibility with the deprecated platform API is not supported for AArch32. Change-Id: Iad228400613eec91abf731b49e21a15bcf2833ea
2016-07-11 14:13:56 +01:00
endif
FVP: Compile ARM Cortex-A72 CPU support in This patch enables the ARM Cortex-A72 support in BL1 and BL31 on FVP. This allows the same TF binaries to run on a Cortex-A72 based FVP without recompiling them. Change-Id: I4eb6bbad9f0e5d8704613f7c685c3bd22b45cf47
2016-01-13 09:04:26 +00:00
SMMUv3: Abort DMA transactions For security DMA should be blocked at the SMMU by default unless explicitly enabled for a device. SMMU is disabled after reset with all streams bypassing the SMMU, and abortion of all incoming transactions implements a default deny policy on reset. This patch also moves "bl1_platform_setup()" function from arm_bl1_setup.c to FVP platforms' fvp_bl1_setup.c and fvp_ve_bl1_setup.c files. Change-Id: Ie0ffedc10219b1b884eb8af625bd4b6753749b1a Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-05-09 12:14:40 +01:00
BL1_SOURCES += drivers/arm/smmu/smmu_v3.c \
drivers/arm/sp805/sp805.c \
FVP: Add Delay Timer driver to BL1 and BL31 SMMUv3 driver functions which are called from BL1 and BL31 currently use counter-based poll method for testing status bits. Adding Delay Timer driver to BL1 and BL31 is required for timeout-based implementation using timer delay functions for SMMU and other drivers. This patch adds new function `fvp_timer_init()` which initialises either System level generic or SP804 timer based on FVP_USE_SP804_TIMER build flag. In BL2U `bl2u_early_platform_setup()` function the call to `arm_bl2u_early_platform_setup()` (which calls `generic_delay_timer_init()` ignoring FVP_USE_SP804_TIMER flag), is replaced with `arm_console_boot_init()` and `fvp_timer_init()`. Change-Id: Ifd8dcebf4019e877b9bc5641551deef77a44c0d1 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-08-16 14:15:59 +01:00
drivers/delay_timer/delay_timer.c \
plat/arm: introduce wrapper functions to setup secure watchdog The BL1 stage setup code for ARM platforms sets up the SP805 watchdog controller as the secure watchdog. But not all ARM platforms use SP805 as the secure watchdog controller. So introduce two new ARM platform code specific wrapper functions to start and stop the secure watchdog. These functions then replace the calls to SP805 driver in common BL1 setup code. All the ARM platforms implement these wrapper functions by either calling into SP805 driver or the SBSA watchdog driver. Change-Id: I1a9a11b124cf3fac2a84f22ca40acd440a441257 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
2019-04-16 06:59:14 +01:00
drivers/io/io_semihosting.c \
Migrate FVP port to use common code Major update to the FVP platform port to use the common platform code in (include/)plat/arm/* and (include/)plat/common/*. This mainly consists of removing duplicated code but also introduces some small behavioural changes where there was unnecessary variation between the FVP and Juno ports. See earlier commit titled `Add common ARM and CSS platform code` for details. Also add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
2015-03-19 19:17:53 +00:00
lib/semihosting/semihosting.c \
AArch32: Add ARM platform changes in BL1 This patch adds ARM platform changes in BL1 for AArch32 state. It also enables building of BL1 for ARCH=aarch32. Change-Id: I079be81a93d027f37b0f7d8bb474b1252bb4cf48
2016-07-04 11:03:49 +01:00
lib/semihosting/${ARCH}/semihosting_call.S \
plat/arm/board/fvp/${ARCH}/fvp_helpers.S \
Move FVP port to plat/arm/board/fvp Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename some of the files so they are consistently prefixed with fvp_. Update the platform makefiles accordingly. Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
2015-04-27 19:17:18 +01:00
plat/arm/board/fvp/fvp_bl1_setup.c \
arm: Shorten the Firmware Update (FWU) process The watchdog is configured with a default value of 256 seconds in order to implement the Trusted Board Boot Requirements. For the FVP and Juno platforms, the FWU process relies on a watchdog reset. In order to automate the test of FWU, the length of this process needs to be as short as possible. Instead of waiting for those 4 minutes to have a reset by the watchdog, tell it to reset immediately. There are no side effects as the value of the watchdog's load register resets to 0xFFFFFFFF. Tested on Juno. Change-Id: Ib1aea80ceddc18ff1e0813a5b98dd141ba8a3ff2 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
2019-07-04 14:58:45 +01:00
plat/arm/board/fvp/fvp_err.c \
Rework use of interconnect drivers ARM Trusted Firmware supports 2 different interconnect peripheral drivers: CCI and CCN. ARM platforms are implemented using either of the interconnect peripherals. This patch adds a layer of abstraction to help ARM platform ports to choose the right interconnect driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been implemented to initialise an interconnect and for entering/exiting a cluster from coherency. These functions are prefixed as "plat_arm_interconnect_". Weak definitions of these functions have been provided for each type of driver. 2.`plat_print_interconnect_regs` macro used for printing CCI registers is moved from a common arm_macros.S to cci_macros.S. 3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure is renamed to `ARM_CONFIG_HAS_INTERCONNECT`. Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
2016-02-15 11:54:14 +00:00
plat/arm/board/fvp/fvp_io_storage.c \
${FVP_CPU_LIBS} \
${FVP_INTERCONNECT_SOURCES}
plat/arm: Use common build flag for using generic sp804 driver SP804 TIMER is not platform specific, and current code base adds multiple defines to use this driver. Like FVP_USE_SP804_TIMER and FVP_VE_USE_SP804_TIMER. This patch removes platform specific build flag and adds generic flag `USE_SP804_TIMER` to be set to 1 by platform if needed. Change-Id: I5ab792c189885fd1b98ddd187f3a38ebdd0baba2 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-08-12 19:18:19 +01:00
ifeq (${USE_SP804_TIMER},1)
FVP: Add Delay Timer driver to BL1 and BL31 SMMUv3 driver functions which are called from BL1 and BL31 currently use counter-based poll method for testing status bits. Adding Delay Timer driver to BL1 and BL31 is required for timeout-based implementation using timer delay functions for SMMU and other drivers. This patch adds new function `fvp_timer_init()` which initialises either System level generic or SP804 timer based on FVP_USE_SP804_TIMER build flag. In BL2U `bl2u_early_platform_setup()` function the call to `arm_bl2u_early_platform_setup()` (which calls `generic_delay_timer_init()` ignoring FVP_USE_SP804_TIMER flag), is replaced with `arm_console_boot_init()` and `fvp_timer_init()`. Change-Id: Ifd8dcebf4019e877b9bc5641551deef77a44c0d1 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-08-16 14:15:59 +01:00
BL1_SOURCES += drivers/arm/sp804/sp804_delay_timer.c
else
BL1_SOURCES += drivers/delay_timer/generic_delay_timer.c
endif
Build system: Fixes #2: Add multi-platform support Move all explicit platform or architecture specific references into a new platform.mk file that is defined for each platform. Change-Id: I9d6320d1ba957e0cc8d9b316b3578132331fa428 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
2014-01-13 12:37:03 +00:00
arm: Shorten the Firmware Update (FWU) process The watchdog is configured with a default value of 256 seconds in order to implement the Trusted Board Boot Requirements. For the FVP and Juno platforms, the FWU process relies on a watchdog reset. In order to automate the test of FWU, the length of this process needs to be as short as possible. Instead of waiting for those 4 minutes to have a reset by the watchdog, tell it to reset immediately. There are no side effects as the value of the watchdog's load register resets to 0xFFFFFFFF. Tested on Juno. Change-Id: Ib1aea80ceddc18ff1e0813a5b98dd141ba8a3ff2 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
2019-07-04 14:58:45 +01:00
BL2_SOURCES += drivers/arm/sp805/sp805.c \
drivers/io/io_semihosting.c \
memprotect: Move files to specific platform makefiles All the arm platforms were including the files related to mem-protect. This configuration generates some problems with new platforms that don't support such functionality, and for that reason this patch moves these files to the platform specific makefiles. Change-Id: I6923e5224668b76667795d8e11723cede7979b1e Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-08-06 13:35:31 +01:00
lib/utils/mem_region.c \
Migrate FVP port to use common code Major update to the FVP platform port to use the common platform code in (include/)plat/arm/* and (include/)plat/common/*. This mainly consists of removing duplicated code but also introduces some small behavioural changes where there was unnecessary variation between the FVP and Juno ports. See earlier commit titled `Add common ARM and CSS platform code` for details. Also add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
2015-03-19 19:17:53 +00:00
lib/semihosting/semihosting.c \
AArch32: Add ARM platform changes in BL2 This patch adds ARM platform changes in BL2 for AArch32 state. It instantiates a descriptor array for ARM platforms describing image and entrypoint information for `SCP_BL2`, `BL32` and `BL33`. It also enables building of BL2 for ARCH=aarch32. Change-Id: I60dc7a284311eceba401fc789311c50ac746c51e
2016-07-04 11:26:14 +01:00
lib/semihosting/${ARCH}/semihosting_call.S \
Move FVP port to plat/arm/board/fvp Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename some of the files so they are consistently prefixed with fvp_. Update the platform makefiles accordingly. Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
2015-04-27 19:17:18 +01:00
plat/arm/board/fvp/fvp_bl2_setup.c \
arm: Shorten the Firmware Update (FWU) process The watchdog is configured with a default value of 256 seconds in order to implement the Trusted Board Boot Requirements. For the FVP and Juno platforms, the FWU process relies on a watchdog reset. In order to automate the test of FWU, the length of this process needs to be as short as possible. Instead of waiting for those 4 minutes to have a reset by the watchdog, tell it to reset immediately. There are no side effects as the value of the watchdog's load register resets to 0xFFFFFFFF. Tested on Juno. Change-Id: Ib1aea80ceddc18ff1e0813a5b98dd141ba8a3ff2 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
2019-07-04 14:58:45 +01:00
plat/arm/board/fvp/fvp_err.c \
Move FVP port to plat/arm/board/fvp Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename some of the files so they are consistently prefixed with fvp_. Update the platform makefiles accordingly. Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
2015-04-27 19:17:18 +01:00
plat/arm/board/fvp/fvp_io_storage.c \
memprotect: Move files to specific platform makefiles All the arm platforms were including the files related to mem-protect. This configuration generates some problems with new platforms that don't support such functionality, and for that reason this patch moves these files to the platform specific makefiles. Change-Id: I6923e5224668b76667795d8e11723cede7979b1e Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-08-06 13:35:31 +01:00
plat/arm/common/arm_nor_psci_mem_protect.c \
Perform security setup separately for each ARM platform Prior to this patch, it was assumed that on all ARM platforms the bare minimal security setup required is to program TrustZone protection. This would always be done by programming the TZC-400 which was assumed to be present in all ARM platforms. The weak definition of platform_arm_security_setup() in plat/arm/common/arm_security.c reflected these assumptions. In reality, each ARM platform either decides at runtime whether TrustZone protection needs to be programmed (e.g. FVPs) or performs some security setup in addition to programming TrustZone protection (e.g. NIC setup on Juno). As a result, the weak definition of plat_arm_security_setup() is always overridden. When a platform needs to program TrustZone protection and implements the TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is also possible to program TrustZone protection through other peripherals that include a TrustZone controller e.g. DMC-500. The programmer's interface is slightly different across these various peripherals. In order to satisfy the above requirements, this patch makes the following changes to the way security setup is done on ARM platforms. 1. arm_security.c retains the definition of arm_tzc_setup() and has been renamed to arm_tzc400.c. This is to reflect the reliance on the TZC-400 peripheral to perform TrustZone programming. The new file is not automatically included in all platform ports through arm_common.mk. Each platform must include it explicitly in a platform specific makefile if needed. This approach enables introduction of similar library code to program TrustZone protection using a different peripheral. This code would be used by the subset of ARM platforms that implement this peripheral. 2. Due to #1 above, existing platforms which implements the TZC-400 have been updated to include the necessary files for both BL2, BL2U and BL31 images. Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735
2016-02-10 14:50:53 +00:00
${FVP_SECURITY_SOURCES}
Build system: Fixes #2: Add multi-platform support Move all explicit platform or architecture specific references into a new platform.mk file that is defined for each platform. Change-Id: I9d6320d1ba957e0cc8d9b316b3578132331fa428 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
2014-01-13 12:37:03 +00:00
memprotect: Move files to specific platform makefiles All the arm platforms were including the files related to mem-protect. This configuration generates some problems with new platforms that don't support such functionality, and for that reason this patch moves these files to the platform specific makefiles. Change-Id: I6923e5224668b76667795d8e11723cede7979b1e Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-08-06 13:35:31 +01:00
plat/arm: Get the base address of nv-counters from device tree Using the Fconf, register base address of the various nv-counters (currently, trusted, non-trusted nv-counters) are moved to the device tree and retrieved during run-time. This feature is enabled using the build option COT_DESC_IN_DTB. Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: I236f532e63cea63b179f60892cb406fc05cd5830
2020-08-23 09:58:44 +01:00
ifeq (${COT_DESC_IN_DTB},1)
BL2_SOURCES += plat/arm/common/fconf/fconf_nv_cntr_getter.c
endif
memprotect: Move files to specific platform makefiles All the arm platforms were including the files related to mem-protect. This configuration generates some problems with new platforms that don't support such functionality, and for that reason this patch moves these files to the platform specific makefiles. Change-Id: I6923e5224668b76667795d8e11723cede7979b1e Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-08-06 13:35:31 +01:00
feat(plat/fvp): add RMM image support for FVP platform This patch adds the necessary changes needed to build and load RMM image for the FVP platform. RMM image is loaded by BL2 after BL32 (if BL32 exists) and before BL33. Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com> Change-Id: I1ac9eade84c2e35c7479a322ca1d090b4e626819
2021-07-12 00:39:39 +01:00
ifeq (${ENABLE_RME},1)
BL2_SOURCES += plat/arm/board/fvp/aarch64/fvp_helpers.S
feat(rme): add dummy realm attestation key to RMMD Add a dummy realm attestation key to RMMD, and return it on request. The realm attestation key is requested with an SMC with the following parameters: * Fid (0xC400001B2). * Attestation key buffer PA (the realm attestation key is copied at this address by the monitor). * Attestation key buffer length as input and size of realm attesation key as output. * Type of elliptic curve. Signed-off-by: Tamas Ban <tamas.ban@arm.com> Signed-off-by: Subhasish Ghosh <subhasish.ghosh@arm.com> Signed-off-by: Soby Mathew <soby.mathew@arm.com> Change-Id: I12d8d98fd221f4638ef225c9383374ddf6e65eac
2022-03-22 16:21:19 +00:00
BL31_SOURCES += plat/arm/board/fvp/fvp_plat_attest_token.c \
plat/arm/board/fvp/fvp_realm_attest_key.c
feat(plat/fvp): add RMM image support for FVP platform This patch adds the necessary changes needed to build and load RMM image for the FVP platform. RMM image is loaded by BL2 after BL32 (if BL32 exists) and before BL33. Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com> Change-Id: I1ac9eade84c2e35c7479a322ca1d090b4e626819
2021-07-12 00:39:39 +01:00
endif
bl2-el3: Add BL2 at EL3 support in FVP This patch add supports for the new API added for BL2 at EL3 for FVP. We don't have a non-TF Boot ROM for FVP, but this option can be tested setting specific parameters in the model. The bl2 image is loaded directly in memory instead of being loaded by a non-TF Boot ROM and the reset address is changed: --data cluster0.cpu0=bl2.bin@0x4001000 -C cluster0.cpu0.RVBAR=0x4001000 These parameters mean that in the cold boot path the processor will jump to BL2 again. For this reason, BL2 is loaded in dram in this case, to avoid other images reclaiming BL2 memory. Change-Id: Ieb2ff8535a9e67ccebcd8c2212cad366e7776422 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2017-11-17 13:22:18 +00:00
ifeq (${BL2_AT_EL3},1)
BL2_SOURCES += plat/arm/board/fvp/${ARCH}/fvp_helpers.S \
plat/arm/board/fvp/fvp_bl2_el3_setup.c \
${FVP_CPU_LIBS} \
${FVP_INTERCONNECT_SOURCES}
endif
plat/arm: Use common build flag for using generic sp804 driver SP804 TIMER is not platform specific, and current code base adds multiple defines to use this driver. Like FVP_USE_SP804_TIMER and FVP_VE_USE_SP804_TIMER. This patch removes platform specific build flag and adds generic flag `USE_SP804_TIMER` to be set to 1 by platform if needed. Change-Id: I5ab792c189885fd1b98ddd187f3a38ebdd0baba2 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-08-12 19:18:19 +01:00
ifeq (${USE_SP804_TIMER},1)
Replace SP804 timer by generic delay timer on FVP Added a build flag to select the generic delay timer on FVP instead of the SP804 timer. By default, the generic one will be selected. The user guide has been updated. Change-Id: Ica34425c6d4ed95a187b529c612f6d3b26b78bc6
2016-05-17 09:48:10 +01:00
BL2_SOURCES += drivers/arm/sp804/sp804_delay_timer.c
endif
FWU: Add Firmware Update support in BL2U for ARM platforms This patch adds support for Firmware update in BL2U for ARM platforms such that TZC initialization is performed on all ARM platforms and (optionally) transfer of SCP_BL2U image on ARM CSS platforms. BL2U specific functions are added to handle early_platform and plat_arch setup. The MMU is configured to map in the BL2U code/data area and other required memory. Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
2015-10-14 15:28:11 +01:00
BL2U_SOURCES += plat/arm/board/fvp/fvp_bl2u_setup.c \
Perform security setup separately for each ARM platform Prior to this patch, it was assumed that on all ARM platforms the bare minimal security setup required is to program TrustZone protection. This would always be done by programming the TZC-400 which was assumed to be present in all ARM platforms. The weak definition of platform_arm_security_setup() in plat/arm/common/arm_security.c reflected these assumptions. In reality, each ARM platform either decides at runtime whether TrustZone protection needs to be programmed (e.g. FVPs) or performs some security setup in addition to programming TrustZone protection (e.g. NIC setup on Juno). As a result, the weak definition of plat_arm_security_setup() is always overridden. When a platform needs to program TrustZone protection and implements the TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is also possible to program TrustZone protection through other peripherals that include a TrustZone controller e.g. DMC-500. The programmer's interface is slightly different across these various peripherals. In order to satisfy the above requirements, this patch makes the following changes to the way security setup is done on ARM platforms. 1. arm_security.c retains the definition of arm_tzc_setup() and has been renamed to arm_tzc400.c. This is to reflect the reliance on the TZC-400 peripheral to perform TrustZone programming. The new file is not automatically included in all platform ports through arm_common.mk. Each platform must include it explicitly in a platform specific makefile if needed. This approach enables introduction of similar library code to program TrustZone protection using a different peripheral. This code would be used by the subset of ARM platforms that implement this peripheral. 2. Due to #1 above, existing platforms which implements the TZC-400 have been updated to include the necessary files for both BL2, BL2U and BL31 images. Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735
2016-02-10 14:50:53 +00:00
${FVP_SECURITY_SOURCES}
FWU: Add Firmware Update support in BL2U for ARM platforms This patch adds support for Firmware update in BL2U for ARM platforms such that TZC initialization is performed on all ARM platforms and (optionally) transfer of SCP_BL2U image on ARM CSS platforms. BL2U specific functions are added to handle early_platform and plat_arch setup. The MMU is configured to map in the BL2U code/data area and other required memory. Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
2015-10-14 15:28:11 +01:00
plat/arm: Use common build flag for using generic sp804 driver SP804 TIMER is not platform specific, and current code base adds multiple defines to use this driver. Like FVP_USE_SP804_TIMER and FVP_VE_USE_SP804_TIMER. This patch removes platform specific build flag and adds generic flag `USE_SP804_TIMER` to be set to 1 by platform if needed. Change-Id: I5ab792c189885fd1b98ddd187f3a38ebdd0baba2 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-08-12 19:18:19 +01:00
ifeq (${USE_SP804_TIMER},1)
FVP: Add Delay Timer driver to BL1 and BL31 SMMUv3 driver functions which are called from BL1 and BL31 currently use counter-based poll method for testing status bits. Adding Delay Timer driver to BL1 and BL31 is required for timeout-based implementation using timer delay functions for SMMU and other drivers. This patch adds new function `fvp_timer_init()` which initialises either System level generic or SP804 timer based on FVP_USE_SP804_TIMER build flag. In BL2U `bl2u_early_platform_setup()` function the call to `arm_bl2u_early_platform_setup()` (which calls `generic_delay_timer_init()` ignoring FVP_USE_SP804_TIMER flag), is replaced with `arm_console_boot_init()` and `fvp_timer_init()`. Change-Id: Ifd8dcebf4019e877b9bc5641551deef77a44c0d1 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-08-16 14:15:59 +01:00
BL2U_SOURCES += drivers/arm/sp804/sp804_delay_timer.c
endif
fvp: pwrc: Move to drivers/ folder Change-Id: I670ea80e0331c2d4b2ccfa563a45469a43f6902d Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-01-23 21:50:09 +00:00
BL31_SOURCES += drivers/arm/fvp/fvp_pwrc.c \
drivers/arm/smmu/smmu_v3.c \
FVP: Add Delay Timer driver to BL1 and BL31 SMMUv3 driver functions which are called from BL1 and BL31 currently use counter-based poll method for testing status bits. Adding Delay Timer driver to BL1 and BL31 is required for timeout-based implementation using timer delay functions for SMMU and other drivers. This patch adds new function `fvp_timer_init()` which initialises either System level generic or SP804 timer based on FVP_USE_SP804_TIMER build flag. In BL2U `bl2u_early_platform_setup()` function the call to `arm_bl2u_early_platform_setup()` (which calls `generic_delay_timer_init()` ignoring FVP_USE_SP804_TIMER flag), is replaced with `arm_console_boot_init()` and `fvp_timer_init()`. Change-Id: Ifd8dcebf4019e877b9bc5641551deef77a44c0d1 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-08-16 14:15:59 +01:00
drivers/delay_timer/delay_timer.c \
plat/arm: Move norflash driver to drivers/ folder This way it can be reused by other platforms if needed. Note that this driver is designed to work with the Versatile Express NOR flash of Juno and FVP. In said platforms, the memory is organized as an interleaved memory of two chips with a 16 bit word. Any platform that wishes to reuse it with a different configuration will need to modify the driver so that it is more generic. Change-Id: Ic721758425864e0cf42b7b9b04bf0d9513b6022e Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-10 11:14:44 +01:00
drivers/cfi/v2m/v2m_flash.c \
memprotect: Move files to specific platform makefiles All the arm platforms were including the files related to mem-protect. This configuration generates some problems with new platforms that don't support such functionality, and for that reason this patch moves these files to the platform specific makefiles. Change-Id: I6923e5224668b76667795d8e11723cede7979b1e Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-08-06 13:35:31 +01:00
lib/utils/mem_region.c \
FVP: Support Base FVP RevC Revision C of the Base FVP has the same memory map as earlier revisions, but has the following differences: - Implements CCI550 instead of CCI400, - Has a single instantiation of SMMUv3, - CPU MPIDs are shifted left by one level, and has MT bit set in them. The correct interconnect to program is chosen at run time based on the FVP revision. Therefore, this patch implements FVP functions for interconnect programming, rather than depending on ARM generic ones. The macros used have been renamed to reflect this change. Additionally, this patch initializes SMMUv3 as part of FVP early platform setup. New ARM config flags are introduced for feature queries at run time. Change-Id: Ic7b7f080953a51fceaf62ce7daa6de0573801f09 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-07-18 15:42:50 +01:00
plat/arm/board/fvp/fvp_bl31_setup.c \
plat/arm/fvp: populate runtime console parameters dynamically We query the UART base address and clk frequency in runtime using fconf getter APIs. Change-Id: I5f4e84953be5f384472bf90720b706d45cb86260 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-04-16 23:54:25 +01:00
plat/arm/board/fvp/fvp_console.c \
Move FVP port to plat/arm/board/fvp Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename some of the files so they are consistently prefixed with fvp_. Update the platform makefiles accordingly. Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
2015-04-27 19:17:18 +01:00
plat/arm/board/fvp/fvp_pm.c \
plat/arm/board/fvp/fvp_topology.c \
plat/arm/board/fvp/aarch64/fvp_helpers.S \
memprotect: Move files to specific platform makefiles All the arm platforms were including the files related to mem-protect. This configuration generates some problems with new platforms that don't support such functionality, and for that reason this patch moves these files to the platform specific makefiles. Change-Id: I6923e5224668b76667795d8e11723cede7979b1e Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-08-06 13:35:31 +01:00
plat/arm/common/arm_nor_psci_mem_protect.c \
Rework use of interconnect drivers ARM Trusted Firmware supports 2 different interconnect peripheral drivers: CCI and CCN. ARM platforms are implemented using either of the interconnect peripherals. This patch adds a layer of abstraction to help ARM platform ports to choose the right interconnect driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been implemented to initialise an interconnect and for entering/exiting a cluster from coherency. These functions are prefixed as "plat_arm_interconnect_". Weak definitions of these functions have been provided for each type of driver. 2.`plat_print_interconnect_regs` macro used for printing CCI registers is moved from a common arm_macros.S to cci_macros.S. 3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure is renamed to `ARM_CONFIG_HAS_INTERCONNECT`. Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
2016-02-15 11:54:14 +00:00
${FVP_CPU_LIBS} \
Perform security setup separately for each ARM platform Prior to this patch, it was assumed that on all ARM platforms the bare minimal security setup required is to program TrustZone protection. This would always be done by programming the TZC-400 which was assumed to be present in all ARM platforms. The weak definition of platform_arm_security_setup() in plat/arm/common/arm_security.c reflected these assumptions. In reality, each ARM platform either decides at runtime whether TrustZone protection needs to be programmed (e.g. FVPs) or performs some security setup in addition to programming TrustZone protection (e.g. NIC setup on Juno). As a result, the weak definition of plat_arm_security_setup() is always overridden. When a platform needs to program TrustZone protection and implements the TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is also possible to program TrustZone protection through other peripherals that include a TrustZone controller e.g. DMC-500. The programmer's interface is slightly different across these various peripherals. In order to satisfy the above requirements, this patch makes the following changes to the way security setup is done on ARM platforms. 1. arm_security.c retains the definition of arm_tzc_setup() and has been renamed to arm_tzc400.c. This is to reflect the reliance on the TZC-400 peripheral to perform TrustZone programming. The new file is not automatically included in all platform ports through arm_common.mk. Each platform must include it explicitly in a platform specific makefile if needed. This approach enables introduction of similar library code to program TrustZone protection using a different peripheral. This code would be used by the subset of ARM platforms that implement this peripheral. 2. Due to #1 above, existing platforms which implements the TZC-400 have been updated to include the necessary files for both BL2, BL2U and BL31 images. Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735
2016-02-10 14:50:53 +00:00
${FVP_GIC_SOURCES} \
Rework use of interconnect drivers ARM Trusted Firmware supports 2 different interconnect peripheral drivers: CCI and CCN. ARM platforms are implemented using either of the interconnect peripherals. This patch adds a layer of abstraction to help ARM platform ports to choose the right interconnect driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been implemented to initialise an interconnect and for entering/exiting a cluster from coherency. These functions are prefixed as "plat_arm_interconnect_". Weak definitions of these functions have been provided for each type of driver. 2.`plat_print_interconnect_regs` macro used for printing CCI registers is moved from a common arm_macros.S to cci_macros.S. 3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure is renamed to `ARM_CONFIG_HAS_INTERCONNECT`. Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
2016-02-15 11:54:14 +00:00
${FVP_INTERCONNECT_SOURCES} \
Perform security setup separately for each ARM platform Prior to this patch, it was assumed that on all ARM platforms the bare minimal security setup required is to program TrustZone protection. This would always be done by programming the TZC-400 which was assumed to be present in all ARM platforms. The weak definition of platform_arm_security_setup() in plat/arm/common/arm_security.c reflected these assumptions. In reality, each ARM platform either decides at runtime whether TrustZone protection needs to be programmed (e.g. FVPs) or performs some security setup in addition to programming TrustZone protection (e.g. NIC setup on Juno). As a result, the weak definition of plat_arm_security_setup() is always overridden. When a platform needs to program TrustZone protection and implements the TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is also possible to program TrustZone protection through other peripherals that include a TrustZone controller e.g. DMC-500. The programmer's interface is slightly different across these various peripherals. In order to satisfy the above requirements, this patch makes the following changes to the way security setup is done on ARM platforms. 1. arm_security.c retains the definition of arm_tzc_setup() and has been renamed to arm_tzc400.c. This is to reflect the reliance on the TZC-400 peripheral to perform TrustZone programming. The new file is not automatically included in all platform ports through arm_common.mk. Each platform must include it explicitly in a platform specific makefile if needed. This approach enables introduction of similar library code to program TrustZone protection using a different peripheral. This code would be used by the subset of ARM platforms that implement this peripheral. 2. Due to #1 above, existing platforms which implements the TZC-400 have been updated to include the necessary files for both BL2, BL2U and BL31 images. Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735
2016-02-10 14:50:53 +00:00
${FVP_SECURITY_SOURCES}
TBB: add a platform specific function to validate the ROTPK This patch adds the function plat_match_rotpk() to the platform porting layer to provide a Root Of Trust Public key (ROTPK) verification mechanism. This function is called during the Trusted Board Boot process and receives a supposed valid copy of the ROTPK as a parameter, usually obtained from an external source (for instance, a certificate). It returns 0 (success) if that key matches the actual ROTPK stored in the system or any other value otherwise. The mechanism to access the actual ROTPK stored in the system is platform specific and should be implemented as part of this function. The format of the ROTPK is also platform specific (to save memory, some platforms might store a hash of the key instead of the whole key). TRUSTED_BOARD_BOOT build option has been added to allow the user to enable the Trusted Board Boot features. The implementation of the plat_match_rotpk() funtion is mandatory when Trusted Board Boot is enabled. For development purposes, FVP and Juno ports provide a dummy function that returns always success (valid key). A safe trusted boot implementation should provide a proper matching function. Documentation updated accordingly. Change-Id: I74ff12bc2b041556c48533375527d9e8c035b8c3
2015-01-07 10:39:25 +00:00
fconf: necessary modifications to support fconf in BL31 & SP_MIN Necessary infrastructure added to integrate fconf framework in BL31 & SP_MIN. Created few populator() functions which parse HW_CONFIG device tree and registered them with fconf framework. Many of the changes are only applicable for fvp platform. This patch: 1. Adds necessary symbols and sections in BL31, SP_MIN linker script 2. Adds necessary memory map entry for translation in BL31, SP_MIN 3. Creates an abstraction layer for hardware configuration based on fconf framework 4. Adds necessary changes to build flow (makefiles) 5. Minimal callback to read hw_config dtb for capturing properties related to GIC(interrupt-controller node) 6. updates the fconf documentation Change-Id: Ib6292071f674ef093962b9e8ba0d322b7bf919af Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-01-27 19:37:51 +00:00
# Support for fconf in BL31
# Added separately from the above list for better readability
FVP: In BL31/SP_MIN, map only the needed DRAM region statically Rather than creating entry in plat_arm_mmap array to map the entire DRAM region in BL31/SP_MIN, only map a smaller region holding HW_CONFIG DTB. Consequently, an increase in number of sub-translation tables(level-2 and level-3) i.e., MAX_XLAT_TABLES is necessary to map the new region in memory. In order to accommodate the increased code size in BL31 i.e., PROGBITS, the max size of BL31 image is increased by 0x1000(4K). Change-Id: I540b8ee550588e22a3a9fb218183d2ab8061c851 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-03-13 18:00:17 +00:00
ifeq ($(filter 1,${BL2_AT_EL3} ${RESET_TO_BL31}),)
build(fdt-wrappers): introduce FDT wrappers makefile This has been introduced to simplify dependencies on the FDT wrappers. We generally want to avoid pulling in components on a file-by-file basis, particularly as we are trying to draw conceptual boxes around components in preparation for transitioning the build system to CMake, where dependencies are modelled on libraries rather than files. Signed-off-by: Chris Kay <chris.kay@arm.com> Change-Id: Idb7ee05a9b54a8caa3e07f36e608867e20b6dcd5
2021-09-28 15:52:14 +01:00
BL31_SOURCES += lib/fconf/fconf.c \
plat/arm: Use only fw_config between bl2 and bl31 Passed the address of fw_config instead of soc_fw_config as arg1 to BL31 from BL2 for ARM fvp platform. BL31 then retrieve load-address of other device trees from fw_config device tree. Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com> Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: Ib7e9581cd765d76111dcc3b7e0dafc12503c83c1
2020-05-30 17:40:44 +01:00
lib/fconf/fconf_dyn_cfg_getter.c \
fconf: necessary modifications to support fconf in BL31 & SP_MIN Necessary infrastructure added to integrate fconf framework in BL31 & SP_MIN. Created few populator() functions which parse HW_CONFIG device tree and registered them with fconf framework. Many of the changes are only applicable for fvp platform. This patch: 1. Adds necessary symbols and sections in BL31, SP_MIN linker script 2. Adds necessary memory map entry for translation in BL31, SP_MIN 3. Creates an abstraction layer for hardware configuration based on fconf framework 4. Adds necessary changes to build flow (makefiles) 5. Minimal callback to read hw_config dtb for capturing properties related to GIC(interrupt-controller node) 6. updates the fconf documentation Change-Id: Ib6292071f674ef093962b9e8ba0d322b7bf919af Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-01-27 19:37:51 +00:00
plat/arm/board/fvp/fconf/fconf_hw_config_getter.c
plat/fvp: Add support for dynamic description of secure interrupts Using the fconf framework, the Group 0 and Group 1 secure interrupt descriptors are moved to device tree and retrieved in runtime. This feature is enabled by the build flag SEC_INT_DESC_IN_FCONF. Change-Id: I360c63a83286c7ecc2426cd1ff1b4746d61e633c Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-06-02 15:26:30 +01:00
build(fdt-wrappers): introduce FDT wrappers makefile This has been introduced to simplify dependencies on the FDT wrappers. We generally want to avoid pulling in components on a file-by-file basis, particularly as we are trying to draw conceptual boxes around components in preparation for transitioning the build system to CMake, where dependencies are modelled on libraries rather than files. Signed-off-by: Chris Kay <chris.kay@arm.com> Change-Id: Idb7ee05a9b54a8caa3e07f36e608867e20b6dcd5
2021-09-28 15:52:14 +01:00
BL31_SOURCES += ${FDT_WRAPPERS_SOURCES}
plat/fvp: Add support for dynamic description of secure interrupts Using the fconf framework, the Group 0 and Group 1 secure interrupt descriptors are moved to device tree and retrieved in runtime. This feature is enabled by the build flag SEC_INT_DESC_IN_FCONF. Change-Id: I360c63a83286c7ecc2426cd1ff1b4746d61e633c Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-06-02 15:26:30 +01:00
ifeq (${SEC_INT_DESC_IN_FCONF},1)
BL31_SOURCES += plat/arm/common/fconf/fconf_sec_intr_config.c
endif
FVP: In BL31/SP_MIN, map only the needed DRAM region statically Rather than creating entry in plat_arm_mmap array to map the entire DRAM region in BL31/SP_MIN, only map a smaller region holding HW_CONFIG DTB. Consequently, an increase in number of sub-translation tables(level-2 and level-3) i.e., MAX_XLAT_TABLES is necessary to map the new region in memory. In order to accommodate the increased code size in BL31 i.e., PROGBITS, the max size of BL31 image is increased by 0x1000(4K). Change-Id: I540b8ee550588e22a3a9fb218183d2ab8061c851 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-03-13 18:00:17 +00:00
endif
fconf: necessary modifications to support fconf in BL31 & SP_MIN Necessary infrastructure added to integrate fconf framework in BL31 & SP_MIN. Created few populator() functions which parse HW_CONFIG device tree and registered them with fconf framework. Many of the changes are only applicable for fvp platform. This patch: 1. Adds necessary symbols and sections in BL31, SP_MIN linker script 2. Adds necessary memory map entry for translation in BL31, SP_MIN 3. Creates an abstraction layer for hardware configuration based on fconf framework 4. Adds necessary changes to build flow (makefiles) 5. Minimal callback to read hw_config dtb for capturing properties related to GIC(interrupt-controller node) 6. updates the fconf documentation Change-Id: Ib6292071f674ef093962b9e8ba0d322b7bf919af Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-01-27 19:37:51 +00:00
plat/arm: Use common build flag for using generic sp804 driver SP804 TIMER is not platform specific, and current code base adds multiple defines to use this driver. Like FVP_USE_SP804_TIMER and FVP_VE_USE_SP804_TIMER. This patch removes platform specific build flag and adds generic flag `USE_SP804_TIMER` to be set to 1 by platform if needed. Change-Id: I5ab792c189885fd1b98ddd187f3a38ebdd0baba2 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
2020-08-12 19:18:19 +01:00
ifeq (${USE_SP804_TIMER},1)
FVP: Add Delay Timer driver to BL1 and BL31 SMMUv3 driver functions which are called from BL1 and BL31 currently use counter-based poll method for testing status bits. Adding Delay Timer driver to BL1 and BL31 is required for timeout-based implementation using timer delay functions for SMMU and other drivers. This patch adds new function `fvp_timer_init()` which initialises either System level generic or SP804 timer based on FVP_USE_SP804_TIMER build flag. In BL2U `bl2u_early_platform_setup()` function the call to `arm_bl2u_early_platform_setup()` (which calls `generic_delay_timer_init()` ignoring FVP_USE_SP804_TIMER flag), is replaced with `arm_console_boot_init()` and `fvp_timer_init()`. Change-Id: Ifd8dcebf4019e877b9bc5641551deef77a44c0d1 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-08-16 14:15:59 +01:00
BL31_SOURCES += drivers/arm/sp804/sp804_delay_timer.c
else
BL31_SOURCES += drivers/delay_timer/generic_delay_timer.c
endif
FVP: restrict dynamic config to Unix build environment This patch restricts building the dynamic config DTBs to the Unix build environment as the Device Tree compiler may not be available on other build environments. Change-Id: Ie690e80010a174300e966240fd977b37561156e0 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-02-27 11:17:14 +00:00
# Add the FDT_SOURCES and options for Dynamic Config (only for Unix env)
ifdef UNIX_MK
FVP: Add TB_FW_CONFIG and HW_CONFIG This patch adds TB_FW_CONFIG for FVP and allows FVP to select the appropriate HW_CONFIG to include in the fip. The HW_CONFIG for FVP is selected via `FVP_HW_CONFIG_DTS` build option. The TB_FW_CONFIG specifies the load address of HW_CONFIG to BL2. Since currently the load address is different between AARCH32 and AARCH64, 2 separate TB_FW_CONFIGs are maintained for the 2 modes. Change-Id: Ide8581e752dfa900087f5895c775073c841c0daf Signed-Off-By: Soby Mathew <soby.mathew@arm.com>
2018-02-08 11:39:38 +00:00
FVP_HW_CONFIG_DTS := fdts/${FVP_DT_PREFIX}.dts
FVP: Add dummy configs for BL31, BL32 and BL33 This patch adds soc_fw_config, tos_fw_config and nt_fw_config to the FVP. The config files are placeholders and do not have any useful bindings defined. The tos_fw_config is packaged in FIP and loaded by BL2 only if SPD=tspd. The load address of these configs are specified in tb_fw_config via new bindings defined for these configs. Currently, in FVP, the soc_fw_config and tos_fw_config is loaded in the page between BL2_BASE and ARM_SHARED_RAM. This memory was typically used for BL32 when ARM_TSP_RAM_LOCATION=tsram but since we cannot fit BL32 in that space anymore, it should be safe to use this memory for these configs. There is also a runtime check in arm_bl2_dyn_cfg_init() which ensures that this overlap doesn't happen. The previous arm_dyn_get_hwconfig_info() is modified to accept configs other than hw_config and hence renamed to arm_dyn_get_config_load_info(). The patch also corrects the definition of ARM_TB_FW_CONFIG_LIMIT to be BL2_BASE. Change-Id: I03a137d9fa1f92c862c254be808b8330cfd17a5a Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-04-04 09:40:32 +01:00
FDT_SOURCES += $(addprefix plat/arm/board/fvp/fdts/, \
fconf: Add dynamic config DTBs info as property This patch introduces a better separation between the trusted-boot related properties, and the dynamic configuration DTBs loading information. The dynamic configuration DTBs properties are moved to a new node: `dtb-registry`. All the sub-nodes present will be provided to the dynamic config framework to be loaded. The node currently only contains the already defined configuration DTBs, but can be extended for future features if necessary. The dynamic config framework is modified to use the abstraction provided by the fconf framework, instead of directly accessing the DTBs. The trusted-boot properties are kept under the "arm,tb_fw" compatible string, but in a separate `tb_fw-config` node. The `tb_fw-config` property of the `dtb-registry` node simply points to the load address of `fw_config`, as the `tb_fw-config` is currently part of the same DTB. Change-Id: Iceb6c4c2cb92b692b6e28dbdc9fb060f1c46de82 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
2019-12-17 13:17:25 +00:00
${PLAT}_fw_config.dts \
plat/arm: Rentroduce tb_fw_config device tree Moved BL2 configuration nodes from fw_config to newly created tb_fw_config device tree. fw_config device tree's main usage is to hold properties shared across all BLx images. An example is the "dtb-registry" node, which contains the information about the other device tree configurations (load-address, size). Also, Updated load-address of tb_fw_config which is now located after fw_config in SRAM. Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: Ic398c86a4d822dacd55b5e25fd41d4fe3888d79a
2020-05-31 08:53:40 +01:00
${PLAT}_tb_fw_config.dts \
FVP: Add dummy configs for BL31, BL32 and BL33 This patch adds soc_fw_config, tos_fw_config and nt_fw_config to the FVP. The config files are placeholders and do not have any useful bindings defined. The tos_fw_config is packaged in FIP and loaded by BL2 only if SPD=tspd. The load address of these configs are specified in tb_fw_config via new bindings defined for these configs. Currently, in FVP, the soc_fw_config and tos_fw_config is loaded in the page between BL2_BASE and ARM_SHARED_RAM. This memory was typically used for BL32 when ARM_TSP_RAM_LOCATION=tsram but since we cannot fit BL32 in that space anymore, it should be safe to use this memory for these configs. There is also a runtime check in arm_bl2_dyn_cfg_init() which ensures that this overlap doesn't happen. The previous arm_dyn_get_hwconfig_info() is modified to accept configs other than hw_config and hence renamed to arm_dyn_get_config_load_info(). The patch also corrects the definition of ARM_TB_FW_CONFIG_LIMIT to be BL2_BASE. Change-Id: I03a137d9fa1f92c862c254be808b8330cfd17a5a Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-04-04 09:40:32 +01:00
${PLAT}_soc_fw_config.dts \
${PLAT}_nt_fw_config.dts \
)
plat/arm: Rentroduce tb_fw_config device tree Moved BL2 configuration nodes from fw_config to newly created tb_fw_config device tree. fw_config device tree's main usage is to hold properties shared across all BLx images. An example is the "dtb-registry" node, which contains the information about the other device tree configurations (load-address, size). Also, Updated load-address of tb_fw_config which is now located after fw_config in SRAM. Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: Ic398c86a4d822dacd55b5e25fd41d4fe3888d79a
2020-05-31 08:53:40 +01:00
FVP_FW_CONFIG := ${BUILD_PLAT}/fdts/${PLAT}_fw_config.dtb
FVP_TB_FW_CONFIG := ${BUILD_PLAT}/fdts/${PLAT}_tb_fw_config.dtb
FVP: Add dummy configs for BL31, BL32 and BL33 This patch adds soc_fw_config, tos_fw_config and nt_fw_config to the FVP. The config files are placeholders and do not have any useful bindings defined. The tos_fw_config is packaged in FIP and loaded by BL2 only if SPD=tspd. The load address of these configs are specified in tb_fw_config via new bindings defined for these configs. Currently, in FVP, the soc_fw_config and tos_fw_config is loaded in the page between BL2_BASE and ARM_SHARED_RAM. This memory was typically used for BL32 when ARM_TSP_RAM_LOCATION=tsram but since we cannot fit BL32 in that space anymore, it should be safe to use this memory for these configs. There is also a runtime check in arm_bl2_dyn_cfg_init() which ensures that this overlap doesn't happen. The previous arm_dyn_get_hwconfig_info() is modified to accept configs other than hw_config and hence renamed to arm_dyn_get_config_load_info(). The patch also corrects the definition of ARM_TB_FW_CONFIG_LIMIT to be BL2_BASE. Change-Id: I03a137d9fa1f92c862c254be808b8330cfd17a5a Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-04-04 09:40:32 +01:00
FVP_SOC_FW_CONFIG := ${BUILD_PLAT}/fdts/${PLAT}_soc_fw_config.dtb
FVP_NT_FW_CONFIG := ${BUILD_PLAT}/fdts/${PLAT}_nt_fw_config.dtb
ifeq (${SPD},tspd)
FDT_SOURCES += plat/arm/board/fvp/fdts/${PLAT}_tsp_fw_config.dts
FVP_TOS_FW_CONFIG := ${BUILD_PLAT}/fdts/${PLAT}_tsp_fw_config.dtb
# Add the TOS_FW_CONFIG to FIP and specify the same to certtool
plat/arm: Add dependencies to configuration files This patch adds dependencies to the generated configuration files that are included in the FIP. This fixes occasional build errors that occur when the FIP happens to be built first. Change-Id: I5a2bf724ba3aee13954403b141f2f19b4fd51d1b Signed-off-by: Anders Dellien <anders.dellien@arm.com>
2020-08-23 19:32:48 +01:00
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_TOS_FW_CONFIG},--tos-fw-config,${FVP_TOS_FW_CONFIG}))
FVP: Add dummy configs for BL31, BL32 and BL33 This patch adds soc_fw_config, tos_fw_config and nt_fw_config to the FVP. The config files are placeholders and do not have any useful bindings defined. The tos_fw_config is packaged in FIP and loaded by BL2 only if SPD=tspd. The load address of these configs are specified in tb_fw_config via new bindings defined for these configs. Currently, in FVP, the soc_fw_config and tos_fw_config is loaded in the page between BL2_BASE and ARM_SHARED_RAM. This memory was typically used for BL32 when ARM_TSP_RAM_LOCATION=tsram but since we cannot fit BL32 in that space anymore, it should be safe to use this memory for these configs. There is also a runtime check in arm_bl2_dyn_cfg_init() which ensures that this overlap doesn't happen. The previous arm_dyn_get_hwconfig_info() is modified to accept configs other than hw_config and hence renamed to arm_dyn_get_config_load_info(). The patch also corrects the definition of ARM_TB_FW_CONFIG_LIMIT to be BL2_BASE. Change-Id: I03a137d9fa1f92c862c254be808b8330cfd17a5a Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-04-04 09:40:32 +01:00
endif
FVP: Add TB_FW_CONFIG and HW_CONFIG This patch adds TB_FW_CONFIG for FVP and allows FVP to select the appropriate HW_CONFIG to include in the fip. The HW_CONFIG for FVP is selected via `FVP_HW_CONFIG_DTS` build option. The TB_FW_CONFIG specifies the load address of HW_CONFIG to BL2. Since currently the load address is different between AARCH32 and AARCH64, 2 separate TB_FW_CONFIGs are maintained for the 2 modes. Change-Id: Ide8581e752dfa900087f5895c775073c841c0daf Signed-Off-By: Soby Mathew <soby.mathew@arm.com>
2018-02-08 11:39:38 +00:00
SPMD: add support for an example SPM core manifest This patch repurposes the TOS FW configuration file as the manifest for the SPM core component which will reside at the secure EL adjacent to EL3. The SPM dispatcher component will use the manifest to determine how the core component must be initialised. Routines and data structure to parse the manifest have also been added. Signed-off-by: Achin Gupta <achin.gupta@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com> Change-Id: Id94f8ece43b4e05609f0a1d364708a912f6203cb
2019-10-11 14:54:48 +01:00
ifeq (${SPD},spmd)
SPM: build OP-TEE as an S-EL1 Secure Partition Provide manifest and build options to boot OP-TEE as a guest S-EL1 Secure Partition on top of Hafnium in S-EL2. Increase ARM_SP_MAX_SIZE to cope with OP-TEE debug build image. Signed-off-by: Olivier Deprez <olivier.deprez@arm.com> Change-Id: Idd2686fa689a78fe2d05ed92b1d23c65e2edd4cb
2020-04-01 20:28:26 +01:00
ifeq ($(ARM_SPMC_MANIFEST_DTS),)
ARM_SPMC_MANIFEST_DTS := plat/arm/board/fvp/fdts/${PLAT}_spmc_manifest.dts
endif
FDT_SOURCES += ${ARM_SPMC_MANIFEST_DTS}
FVP_TOS_FW_CONFIG := ${BUILD_PLAT}/fdts/$(notdir $(basename ${ARM_SPMC_MANIFEST_DTS})).dtb
SPMD: add support for an example SPM core manifest This patch repurposes the TOS FW configuration file as the manifest for the SPM core component which will reside at the secure EL adjacent to EL3. The SPM dispatcher component will use the manifest to determine how the core component must be initialised. Routines and data structure to parse the manifest have also been added. Signed-off-by: Achin Gupta <achin.gupta@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com> Change-Id: Id94f8ece43b4e05609f0a1d364708a912f6203cb
2019-10-11 14:54:48 +01:00
# Add the TOS_FW_CONFIG to FIP and specify the same to certtool
plat/arm: Add dependencies to configuration files This patch adds dependencies to the generated configuration files that are included in the FIP. This fixes occasional build errors that occur when the FIP happens to be built first. Change-Id: I5a2bf724ba3aee13954403b141f2f19b4fd51d1b Signed-off-by: Anders Dellien <anders.dellien@arm.com>
2020-08-23 19:32:48 +01:00
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_TOS_FW_CONFIG},--tos-fw-config,${FVP_TOS_FW_CONFIG}))
SPMD: add support for an example SPM core manifest This patch repurposes the TOS FW configuration file as the manifest for the SPM core component which will reside at the secure EL adjacent to EL3. The SPM dispatcher component will use the manifest to determine how the core component must be initialised. Routines and data structure to parse the manifest have also been added. Signed-off-by: Achin Gupta <achin.gupta@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com> Change-Id: Id94f8ece43b4e05609f0a1d364708a912f6203cb
2019-10-11 14:54:48 +01:00
endif
plat/arm: Rentroduce tb_fw_config device tree Moved BL2 configuration nodes from fw_config to newly created tb_fw_config device tree. fw_config device tree's main usage is to hold properties shared across all BLx images. An example is the "dtb-registry" node, which contains the information about the other device tree configurations (load-address, size). Also, Updated load-address of tb_fw_config which is now located after fw_config in SRAM. Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: Ic398c86a4d822dacd55b5e25fd41d4fe3888d79a
2020-05-31 08:53:40 +01:00
# Add the FW_CONFIG to FIP and specify the same to certtool
plat/arm: Add dependencies to configuration files This patch adds dependencies to the generated configuration files that are included in the FIP. This fixes occasional build errors that occur when the FIP happens to be built first. Change-Id: I5a2bf724ba3aee13954403b141f2f19b4fd51d1b Signed-off-by: Anders Dellien <anders.dellien@arm.com>
2020-08-23 19:32:48 +01:00
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_FW_CONFIG},--fw-config,${FVP_FW_CONFIG}))
FVP: Add TB_FW_CONFIG and HW_CONFIG This patch adds TB_FW_CONFIG for FVP and allows FVP to select the appropriate HW_CONFIG to include in the fip. The HW_CONFIG for FVP is selected via `FVP_HW_CONFIG_DTS` build option. The TB_FW_CONFIG specifies the load address of HW_CONFIG to BL2. Since currently the load address is different between AARCH32 and AARCH64, 2 separate TB_FW_CONFIGs are maintained for the 2 modes. Change-Id: Ide8581e752dfa900087f5895c775073c841c0daf Signed-Off-By: Soby Mathew <soby.mathew@arm.com>
2018-02-08 11:39:38 +00:00
# Add the TB_FW_CONFIG to FIP and specify the same to certtool
plat/arm: Add dependencies to configuration files This patch adds dependencies to the generated configuration files that are included in the FIP. This fixes occasional build errors that occur when the FIP happens to be built first. Change-Id: I5a2bf724ba3aee13954403b141f2f19b4fd51d1b Signed-off-by: Anders Dellien <anders.dellien@arm.com>
2020-08-23 19:32:48 +01:00
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_TB_FW_CONFIG},--tb-fw-config,${FVP_TB_FW_CONFIG}))
FVP: Add dummy configs for BL31, BL32 and BL33 This patch adds soc_fw_config, tos_fw_config and nt_fw_config to the FVP. The config files are placeholders and do not have any useful bindings defined. The tos_fw_config is packaged in FIP and loaded by BL2 only if SPD=tspd. The load address of these configs are specified in tb_fw_config via new bindings defined for these configs. Currently, in FVP, the soc_fw_config and tos_fw_config is loaded in the page between BL2_BASE and ARM_SHARED_RAM. This memory was typically used for BL32 when ARM_TSP_RAM_LOCATION=tsram but since we cannot fit BL32 in that space anymore, it should be safe to use this memory for these configs. There is also a runtime check in arm_bl2_dyn_cfg_init() which ensures that this overlap doesn't happen. The previous arm_dyn_get_hwconfig_info() is modified to accept configs other than hw_config and hence renamed to arm_dyn_get_config_load_info(). The patch also corrects the definition of ARM_TB_FW_CONFIG_LIMIT to be BL2_BASE. Change-Id: I03a137d9fa1f92c862c254be808b8330cfd17a5a Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-04-04 09:40:32 +01:00
# Add the SOC_FW_CONFIG to FIP and specify the same to certtool
plat/arm: Add dependencies to configuration files This patch adds dependencies to the generated configuration files that are included in the FIP. This fixes occasional build errors that occur when the FIP happens to be built first. Change-Id: I5a2bf724ba3aee13954403b141f2f19b4fd51d1b Signed-off-by: Anders Dellien <anders.dellien@arm.com>
2020-08-23 19:32:48 +01:00
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_SOC_FW_CONFIG},--soc-fw-config,${FVP_SOC_FW_CONFIG}))
FVP: Add dummy configs for BL31, BL32 and BL33 This patch adds soc_fw_config, tos_fw_config and nt_fw_config to the FVP. The config files are placeholders and do not have any useful bindings defined. The tos_fw_config is packaged in FIP and loaded by BL2 only if SPD=tspd. The load address of these configs are specified in tb_fw_config via new bindings defined for these configs. Currently, in FVP, the soc_fw_config and tos_fw_config is loaded in the page between BL2_BASE and ARM_SHARED_RAM. This memory was typically used for BL32 when ARM_TSP_RAM_LOCATION=tsram but since we cannot fit BL32 in that space anymore, it should be safe to use this memory for these configs. There is also a runtime check in arm_bl2_dyn_cfg_init() which ensures that this overlap doesn't happen. The previous arm_dyn_get_hwconfig_info() is modified to accept configs other than hw_config and hence renamed to arm_dyn_get_config_load_info(). The patch also corrects the definition of ARM_TB_FW_CONFIG_LIMIT to be BL2_BASE. Change-Id: I03a137d9fa1f92c862c254be808b8330cfd17a5a Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-04-04 09:40:32 +01:00
# Add the NT_FW_CONFIG to FIP and specify the same to certtool
plat/arm: Add dependencies to configuration files This patch adds dependencies to the generated configuration files that are included in the FIP. This fixes occasional build errors that occur when the FIP happens to be built first. Change-Id: I5a2bf724ba3aee13954403b141f2f19b4fd51d1b Signed-off-by: Anders Dellien <anders.dellien@arm.com>
2020-08-23 19:32:48 +01:00
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_NT_FW_CONFIG},--nt-fw-config,${FVP_NT_FW_CONFIG}))
FVP: Add TB_FW_CONFIG and HW_CONFIG This patch adds TB_FW_CONFIG for FVP and allows FVP to select the appropriate HW_CONFIG to include in the fip. The HW_CONFIG for FVP is selected via `FVP_HW_CONFIG_DTS` build option. The TB_FW_CONFIG specifies the load address of HW_CONFIG to BL2. Since currently the load address is different between AARCH32 and AARCH64, 2 separate TB_FW_CONFIGs are maintained for the 2 modes. Change-Id: Ide8581e752dfa900087f5895c775073c841c0daf Signed-Off-By: Soby Mathew <soby.mathew@arm.com>
2018-02-08 11:39:38 +00:00
FDT_SOURCES += ${FVP_HW_CONFIG_DTS}
$(eval FVP_HW_CONFIG := ${BUILD_PLAT}/$(patsubst %.dts,%.dtb,$(FVP_HW_CONFIG_DTS)))
# Add the HW_CONFIG to FIP and specify the same to certtool
plat/arm: Add dependencies to configuration files This patch adds dependencies to the generated configuration files that are included in the FIP. This fixes occasional build errors that occur when the FIP happens to be built first. Change-Id: I5a2bf724ba3aee13954403b141f2f19b4fd51d1b Signed-off-by: Anders Dellien <anders.dellien@arm.com>
2020-08-23 19:32:48 +01:00
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_HW_CONFIG},--hw-config,${FVP_HW_CONFIG}))
FVP: restrict dynamic config to Unix build environment This patch restricts building the dynamic config DTBs to the Unix build environment as the Device Tree compiler may not be available on other build environments. Change-Id: Ie690e80010a174300e966240fd977b37561156e0 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-02-27 11:17:14 +00:00
endif
FVP: Add TB_FW_CONFIG and HW_CONFIG This patch adds TB_FW_CONFIG for FVP and allows FVP to select the appropriate HW_CONFIG to include in the fip. The HW_CONFIG for FVP is selected via `FVP_HW_CONFIG_DTS` build option. The TB_FW_CONFIG specifies the load address of HW_CONFIG to BL2. Since currently the load address is different between AARCH32 and AARCH64, 2 separate TB_FW_CONFIGs are maintained for the 2 modes. Change-Id: Ide8581e752dfa900087f5895c775073c841c0daf Signed-Off-By: Soby Mathew <soby.mathew@arm.com>
2018-02-08 11:39:38 +00:00
fvp: Enable the Activity Monitor Unit extensions by default Change-Id: I96de88f44c36681ad8a70430af8e01016394bd14 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2017-11-14 13:27:41 +00:00
# Enable Activity Monitor Unit extensions by default
ENABLE_AMU := 1
Set DYNAMIC_WORKAROUND_CVE_2018_3639=1 on FVP by default The upcoming patch that adds dynamic mitigation for Cortex-A76 requires that DYNAMIC_WORKAROUND_CVE_2018_3639=1. On FVP, we pull in all the CPU files into the build which means there will be a build failure if DYNAMIC_WORKAROUND_CVE_2018_3639=0. Change-Id: I2e781cbeafbf5d16eaabf76a1677e0c9f81269d2 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2018-05-31 14:10:06 +01:00
# Enable dynamic mitigation support by default
DYNAMIC_WORKAROUND_CVE_2018_3639 := 1
Add hooks to save/restore AMU context for Cortex A75 Change-Id: I504d3f65ca5829bc1f4ebadb764931f8379ee81f Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2017-12-11 11:45:35 +00:00
ifeq (${ENABLE_AMU},1)
Add compile-time errors for HW_ASSISTED_COHERENCY flag This patch fixes this issue: https://github.com/ARM-software/tf-issues/issues/660 The introduced changes are the following: 1) Some cores implement cache coherency maintenance operation on the hardware level. For those cores, such as - but not only - the DynamIQ cores, it is mandatory that TF-A is compiled with the HW_ASSISTED_COHERENCY flag. If not, the core behaviour at runtime is unpredictable. To prevent this, compile time checks have been added and compilation errors are generated, if needed. 2) To enable this change for FVP, a logical separation has been done for the core libraries. A system cannot contain cores of both groups, i.e. cores that manage coherency on hardware and cores that don't do it. As such, depending on the HW_ASSISTED_COHERENCY flag, FVP includes the libraries only of the relevant cores. 3) The neoverse_e1.S file has been added to the FVP sources. Change-Id: I787d15819b2add4ec0d238249e04bf0497dc12f3 Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-03-19 17:20:52 +00:00
BL31_SOURCES += lib/cpus/aarch64/cpuamu.c \
Factor out CPU AMU helpers This patch also fixes `cpuamu_write_cpuamcntenclr_el0()` to use an MSR instruction instead of an MRS instruction. Change-Id: Ia6531f64b5ebc60ba432124eaa8d8eaccba40ed0 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2018-02-14 10:00:06 +00:00
lib/cpus/aarch64/cpuamu_helpers.S
Add compile-time errors for HW_ASSISTED_COHERENCY flag This patch fixes this issue: https://github.com/ARM-software/tf-issues/issues/660 The introduced changes are the following: 1) Some cores implement cache coherency maintenance operation on the hardware level. For those cores, such as - but not only - the DynamIQ cores, it is mandatory that TF-A is compiled with the HW_ASSISTED_COHERENCY flag. If not, the core behaviour at runtime is unpredictable. To prevent this, compile time checks have been added and compilation errors are generated, if needed. 2) To enable this change for FVP, a logical separation has been done for the core libraries. A system cannot contain cores of both groups, i.e. cores that manage coherency on hardware and cores that don't do it. As such, depending on the HW_ASSISTED_COHERENCY flag, FVP includes the libraries only of the relevant cores. 3) The neoverse_e1.S file has been added to the FVP sources. Change-Id: I787d15819b2add4ec0d238249e04bf0497dc12f3 Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
2019-03-19 17:20:52 +00:00
ifeq (${HW_ASSISTED_COHERENCY}, 1)
BL31_SOURCES += lib/cpus/aarch64/cortex_a75_pubsub.c \
lib/cpus/aarch64/neoverse_n1_pubsub.c
endif
Add hooks to save/restore AMU context for Cortex A75 Change-Id: I504d3f65ca5829bc1f4ebadb764931f8379ee81f Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2017-12-11 11:45:35 +00:00
endif
Arm platforms: Remove common RAS configuration source The file arm_ras.c intended to provide common platform-specific RAS configuration for Arm platforms. Because this file has symbol definitions, it's proving difficult to provide a common definition. This patch therefore renames and makes the file specific to FVP. Other platforms shall provide their own configuration in similar fashion. Change-Id: I766fd238946e3e49cdb659680e1b45f41b237901 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-06-08 08:44:36 +01:00
ifeq (${RAS_EXTENSION},1)
BL31_SOURCES += plat/arm/board/fvp/aarch64/fvp_ras.c
endif
Add support for GCC stack protection Introduce new build option ENABLE_STACK_PROTECTOR. It enables compilation of all BL images with one of the GCC -fstack-protector-* options. A new platform function plat_get_stack_protector_canary() is introduced. It returns a value that is used to initialize the canary for stack corruption detection. Returning a random value will prevent an attacker from predicting the value and greatly increase the effectiveness of the protection. A message is printed at the ERROR level when a stack corruption is detected. To be effective, the global data must be stored at an address lower than the base of the stacks. Failure to do so would allow an attacker to overwrite the canary as part of an attack which would void the protection. FVP implementation of plat_get_stack_protector_canary is weak as there is no real source of entropy on the FVP. It therefore relies on a timer's value, which could be predictable. Change-Id: Icaaee96392733b721fa7c86a81d03660d3c1bc06 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2017-02-24 18:14:15 +00:00
ifneq (${ENABLE_STACK_PROTECTOR},0)
PLAT_BL_COMMON_SOURCES += plat/arm/board/fvp/fvp_stack_protector.c
endif
AArch32: Add `TRUSTED_BOARD_BOOT` support This patch adds `TRUSTED_BOARD_BOOT` support for AArch32 mode. To build this patch the "mbedtls/include/mbedtls/bignum.h" needs to be modified to remove `#define MBEDTLS_HAVE_UDBL` when `MBEDTLS_HAVE_INT32` is defined. This is a workaround for "https://github.com/ARMmbed/mbedtls/issues/708" NOTE: TBBR support on Juno AArch32 is not currently supported. Change-Id: I86d80e30b9139adc4d9663f112801ece42deafcf Signed-off-by: dp-arm <dimitris.papastamos@arm.com> Co-Authored-By: Yatharth Kochar <yatharth.kochar@arm.com>
2017-02-15 11:07:55 +00:00
ifeq (${ARCH},aarch32)
NEED_BL32 := yes
endif
plat/arm: Move dynamic xlat enable logic to makefile The PLAT_XLAT_TABLES_DYNAMIC build option, defined in platform_def.h in Arm platforms, is checked by several headers, affecting their behaviour. To avoid issues around the include ordering of the headers, the definition should be moved to the platform's makefile. Change-Id: I0e12365c8d66309122e8a20790e1641a4f480a10 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-01-23 16:23:07 +00:00
# Enable the dynamic translation tables library.
feat(fvp): update HW_CONFIG DT loading mechanism Currently, HW-config is loaded into non-secure memory, which mean a malicious NS-agent could tamper with it. Ideally, this shouldn't be an issue since no software runs in non-secure world at this time (non-secure world has not been started yet). It does not provide a guarantee though since malicious external NS-agents can take control of this memory region for update/corruption after BL2 loads it and before BL31/BL32/SP_MIN consumes it. The threat is mapped to Threat ID#3 (Bypass authentication scenario) in threat model [1]. Hence modified the code as below - 1. BL2 loads the HW_CONFIG into secure memory 2. BL2 makes a copy of the HW_CONFIG in the non-secure memory at an address provided by the newly added property(ns-load-address) in the 'hw-config' node of the FW_CONFIG 3. SP_MIN receives the FW_CONFIG address from BL2 via arg1 so that it can retrieve details (address and size) of HW_CONFIG from FW_CONFIG 4. A secure and non-secure HW_CONFIG address will eventually be used by BL31/SP_MIN/BL32 and BL33 components respectively 5. BL31/SP_MIN dynamically maps the Secure HW_CONFIG region and reads information from it to local variables (structures) and then unmaps it 6. Reduce HW_CONFIG maximum size from 16MB to 1MB; it appears sufficient, and it will also create a free space for any future components to be added to memory [1]: https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html Change-Id: I1d431f3e640ded60616604b1c33aa638b9a1e55e Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
2022-03-15 16:05:58 +00:00
ifeq ($(filter 1,${BL2_AT_EL3} ${ARM_XLAT_TABLES_LIB_V1}),)
ifeq (${ARCH},aarch32)
plat: remove redundant =1 from -D option As GCC manual says, -D option defines a macro as 1, if =<value> is omitted. -D <name> Predefine <name> as a macro, with definition 1. The same applied with Clang, too. In the context of -D option, =1 is always redundant. Change-Id: I487489a1ea3eb51e734741619c1e65dab1420bc4 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-04-01 06:28:24 +01:00
BL32_CPPFLAGS += -DPLAT_XLAT_TABLES_DYNAMIC
feat(fvp): update HW_CONFIG DT loading mechanism Currently, HW-config is loaded into non-secure memory, which mean a malicious NS-agent could tamper with it. Ideally, this shouldn't be an issue since no software runs in non-secure world at this time (non-secure world has not been started yet). It does not provide a guarantee though since malicious external NS-agents can take control of this memory region for update/corruption after BL2 loads it and before BL31/BL32/SP_MIN consumes it. The threat is mapped to Threat ID#3 (Bypass authentication scenario) in threat model [1]. Hence modified the code as below - 1. BL2 loads the HW_CONFIG into secure memory 2. BL2 makes a copy of the HW_CONFIG in the non-secure memory at an address provided by the newly added property(ns-load-address) in the 'hw-config' node of the FW_CONFIG 3. SP_MIN receives the FW_CONFIG address from BL2 via arg1 so that it can retrieve details (address and size) of HW_CONFIG from FW_CONFIG 4. A secure and non-secure HW_CONFIG address will eventually be used by BL31/SP_MIN/BL32 and BL33 components respectively 5. BL31/SP_MIN dynamically maps the Secure HW_CONFIG region and reads information from it to local variables (structures) and then unmaps it 6. Reduce HW_CONFIG maximum size from 16MB to 1MB; it appears sufficient, and it will also create a free space for any future components to be added to memory [1]: https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html Change-Id: I1d431f3e640ded60616604b1c33aa638b9a1e55e Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
2022-03-15 16:05:58 +00:00
else # AArch64
plat: remove redundant =1 from -D option As GCC manual says, -D option defines a macro as 1, if =<value> is omitted. -D <name> Predefine <name> as a macro, with definition 1. The same applied with Clang, too. In the context of -D option, =1 is always redundant. Change-Id: I487489a1ea3eb51e734741619c1e65dab1420bc4 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-04-01 06:28:24 +01:00
BL31_CPPFLAGS += -DPLAT_XLAT_TABLES_DYNAMIC
fvp: trusty: Move dynamic xlat enable to platform Rather than letting the Trusty makefile set the option to enable dynamic translation tables, make platforms do it themselves. This also allows platforms to replace the implementation of the translation tables library as long as they use the same function prototypes. Change-Id: Ia60904f61709ac323addcb57f7a83391d9e21cd0 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-02-12 13:32:03 +00:00
endif
plat/arm: Move dynamic xlat enable logic to makefile The PLAT_XLAT_TABLES_DYNAMIC build option, defined in platform_def.h in Arm platforms, is checked by several headers, affecting their behaviour. To avoid issues around the include ordering of the headers, the definition should be moved to the platform's makefile. Change-Id: I0e12365c8d66309122e8a20790e1641a4f480a10 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-01-23 16:23:07 +00:00
endif
feat(rme): add dummy platform token to RMMD Add a dummy platform token to RMMD and return it on request. The platform token is requested with an SMC with the following parameters: * Fid (0xC40001B3). * Platform token PA (the platform token is copied at this address by the monitor). The challenge object needs to be passed by the caller in this buffer. * Platform token len. * Challenge object len. When calling the SMC, the platform token buffer received by EL3 contains the challenge object. It is not used on the FVP and is only printed to the log. Signed-off-by: Mate Toth-Pal <mate.toth-pal@arm.com> Signed-off-by: Subhasish Ghosh <subhasish.ghosh@arm.com> Change-Id: I8b2f1d54426c04e76d7a3baa6b0fbc40b0116348
2022-03-22 16:19:39 +00:00
ifeq (${ENABLE_RME},1)
BL31_CPPFLAGS += -DPLAT_XLAT_TABLES_DYNAMIC
endif
Read-only xlat tables for BL31 memory This patch introduces a build flag which allows the xlat tables to be mapped in a read-only region within BL31 memory. It makes it much harder for someone who has acquired the ability to write to arbitrary secure memory addresses to gain control of the translation tables. The memory attributes of the descriptors describing the tables themselves are changed to read-only secure data. This change happens at the end of BL31 runtime setup. Until this point, the tables have read-write permissions. This gives a window of opportunity for changes to be made to the tables with the MMU on (e.g. reclaiming init code). No changes can be made to the tables with the MMU turned on from this point onwards. This change is also enabled for sp_min and tspd. To make all this possible, the base table was moved to .rodata. The penalty we pay is that now .rodata must be aligned to the size of the base table (512B alignment). Still, this is better than putting the base table with the higher level tables in the xlat_table section, as that would cost us a full 4KB page. Changing the tables from read-write to read-only cannot be done with the MMU on, as the break-before-make sequence would invalidate the descriptor which resolves the level 3 page table where that very descriptor is located. This would make the translation required for writing the changes impossible, generating an MMU fault. The caches are also flushed. Signed-off-by: Petre-Ionut Tudor <petre-ionut.tudor@arm.com> Change-Id: Ibe5de307e6dc94c67d6186139ac3973516430466
2019-11-07 15:18:03 +00:00
ifeq (${ALLOW_RO_XLAT_TABLES}, 1)
ifeq (${ARCH},aarch32)
plat: remove redundant =1 from -D option As GCC manual says, -D option defines a macro as 1, if =<value> is omitted. -D <name> Predefine <name> as a macro, with definition 1. The same applied with Clang, too. In the context of -D option, =1 is always redundant. Change-Id: I487489a1ea3eb51e734741619c1e65dab1420bc4 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-04-01 06:28:24 +01:00
BL32_CPPFLAGS += -DPLAT_RO_XLAT_TABLES
Read-only xlat tables for BL31 memory This patch introduces a build flag which allows the xlat tables to be mapped in a read-only region within BL31 memory. It makes it much harder for someone who has acquired the ability to write to arbitrary secure memory addresses to gain control of the translation tables. The memory attributes of the descriptors describing the tables themselves are changed to read-only secure data. This change happens at the end of BL31 runtime setup. Until this point, the tables have read-write permissions. This gives a window of opportunity for changes to be made to the tables with the MMU on (e.g. reclaiming init code). No changes can be made to the tables with the MMU turned on from this point onwards. This change is also enabled for sp_min and tspd. To make all this possible, the base table was moved to .rodata. The penalty we pay is that now .rodata must be aligned to the size of the base table (512B alignment). Still, this is better than putting the base table with the higher level tables in the xlat_table section, as that would cost us a full 4KB page. Changing the tables from read-write to read-only cannot be done with the MMU on, as the break-before-make sequence would invalidate the descriptor which resolves the level 3 page table where that very descriptor is located. This would make the translation required for writing the changes impossible, generating an MMU fault. The caches are also flushed. Signed-off-by: Petre-Ionut Tudor <petre-ionut.tudor@arm.com> Change-Id: Ibe5de307e6dc94c67d6186139ac3973516430466
2019-11-07 15:18:03 +00:00
else # AArch64
plat: remove redundant =1 from -D option As GCC manual says, -D option defines a macro as 1, if =<value> is omitted. -D <name> Predefine <name> as a macro, with definition 1. The same applied with Clang, too. In the context of -D option, =1 is always redundant. Change-Id: I487489a1ea3eb51e734741619c1e65dab1420bc4 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-04-01 06:28:24 +01:00
BL31_CPPFLAGS += -DPLAT_RO_XLAT_TABLES
Read-only xlat tables for BL31 memory This patch introduces a build flag which allows the xlat tables to be mapped in a read-only region within BL31 memory. It makes it much harder for someone who has acquired the ability to write to arbitrary secure memory addresses to gain control of the translation tables. The memory attributes of the descriptors describing the tables themselves are changed to read-only secure data. This change happens at the end of BL31 runtime setup. Until this point, the tables have read-write permissions. This gives a window of opportunity for changes to be made to the tables with the MMU on (e.g. reclaiming init code). No changes can be made to the tables with the MMU turned on from this point onwards. This change is also enabled for sp_min and tspd. To make all this possible, the base table was moved to .rodata. The penalty we pay is that now .rodata must be aligned to the size of the base table (512B alignment). Still, this is better than putting the base table with the higher level tables in the xlat_table section, as that would cost us a full 4KB page. Changing the tables from read-write to read-only cannot be done with the MMU on, as the break-before-make sequence would invalidate the descriptor which resolves the level 3 page table where that very descriptor is located. This would make the translation required for writing the changes impossible, generating an MMU fault. The caches are also flushed. Signed-off-by: Petre-Ionut Tudor <petre-ionut.tudor@arm.com> Change-Id: Ibe5de307e6dc94c67d6186139ac3973516430466
2019-11-07 15:18:03 +00:00
ifeq (${SPD},tspd)
plat: remove redundant =1 from -D option As GCC manual says, -D option defines a macro as 1, if =<value> is omitted. -D <name> Predefine <name> as a macro, with definition 1. The same applied with Clang, too. In the context of -D option, =1 is always redundant. Change-Id: I487489a1ea3eb51e734741619c1e65dab1420bc4 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-04-01 06:28:24 +01:00
BL32_CPPFLAGS += -DPLAT_RO_XLAT_TABLES
Read-only xlat tables for BL31 memory This patch introduces a build flag which allows the xlat tables to be mapped in a read-only region within BL31 memory. It makes it much harder for someone who has acquired the ability to write to arbitrary secure memory addresses to gain control of the translation tables. The memory attributes of the descriptors describing the tables themselves are changed to read-only secure data. This change happens at the end of BL31 runtime setup. Until this point, the tables have read-write permissions. This gives a window of opportunity for changes to be made to the tables with the MMU on (e.g. reclaiming init code). No changes can be made to the tables with the MMU turned on from this point onwards. This change is also enabled for sp_min and tspd. To make all this possible, the base table was moved to .rodata. The penalty we pay is that now .rodata must be aligned to the size of the base table (512B alignment). Still, this is better than putting the base table with the higher level tables in the xlat_table section, as that would cost us a full 4KB page. Changing the tables from read-write to read-only cannot be done with the MMU on, as the break-before-make sequence would invalidate the descriptor which resolves the level 3 page table where that very descriptor is located. This would make the translation required for writing the changes impossible, generating an MMU fault. The caches are also flushed. Signed-off-by: Petre-Ionut Tudor <petre-ionut.tudor@arm.com> Change-Id: Ibe5de307e6dc94c67d6186139ac3973516430466
2019-11-07 15:18:03 +00:00
endif
endif
endif
debugfs: add SMC channel Provide an SMC interface to the 9p filesystem. This permits accessing firmware drivers through a common interface, using standardized read/write/control operations. Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com> Signed-off-by: Olivier Deprez <olivier.deprez@arm.com> Change-Id: I9314662314bb060f6bc02714476574da158b2a7d
2019-07-12 13:47:03 +01:00
ifeq (${USE_DEBUGFS},1)
plat: remove redundant =1 from -D option As GCC manual says, -D option defines a macro as 1, if =<value> is omitted. -D <name> Predefine <name> as a macro, with definition 1. The same applied with Clang, too. In the context of -D option, =1 is always redundant. Change-Id: I487489a1ea3eb51e734741619c1e65dab1420bc4 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-04-01 06:28:24 +01:00
BL31_CPPFLAGS += -DPLAT_XLAT_TABLES_DYNAMIC
debugfs: add SMC channel Provide an SMC interface to the 9p filesystem. This permits accessing firmware drivers through a common interface, using standardized read/write/control operations. Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com> Signed-off-by: Olivier Deprez <olivier.deprez@arm.com> Change-Id: I9314662314bb060f6bc02714476574da158b2a7d
2019-07-12 13:47:03 +01:00
endif
ARM platforms: Add support for EL3 TZC memory region Some recent enhancements to EL3 runtime firmware like support for save and restoring GICv3 register context during system_suspend necessitates additional data memory for the firmware. This patch introduces support for creating a TZC secured DDR carveout for use by ARM reference platforms. A new linker section `el3_tzc_dram` is created using platform supplied linker script and data marked with the attribute `arm_el3_tzc_dram` will be placed in this section. The FVP makefile now defines the `PLAT_EXTRA_LD_SCRIPT` variable to allow inclusion of the platform linker script by the top level BL31 linker script. Change-Id: I0e7f4a75a6ac51419c667875ff2677043df1585d Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2017-10-05 12:27:33 +01:00
# Add support for platform supplied linker script for BL31 build
$(eval $(call add_define,PLAT_EXTRA_LD_SCRIPT))
bl2-el3: Don't compile BL1 when BL2_AT_EL3 is defined in FVP This patch modifies the makefiles to avoid the definition of BL1_SOURCES and BL2_SOURCES in the tbbr makefiles, and it lets to the platform makefiles to define them if they actually need these images. In the case of BL2_AT_EL3 BL1 will not be needed usually because the Boot ROM will jump directly to BL2. Change-Id: Ib6845a260633a22a646088629bcd7387fe35dcf9 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-01-16 10:35:23 +00:00
ifneq (${BL2_AT_EL3}, 0)
override BL1_SOURCES =
endif
feat(plat/arm/fvp): enable RSS backend based measured boot Enable the RSS backend based measured boot feature. In the absence of RSS the mocked version of PSA APIs are used. They always return with success and hard-code data. Signed-off-by: Tamas Ban <tamas.ban@arm.com> Change-Id: I7543e9033a7a21f1b836d911d8d9498c6e09b956
2022-02-11 08:49:36 +00:00
# Include Measured Boot makefile before any Crypto library makefile.
# Crypto library makefile may need default definitions of Measured Boot build
# flags present in Measured Boot makefile.
ifeq (${MEASURED_BOOT},1)
RSS_MEASURED_BOOT_MK := drivers/measured_boot/rss/rss_measured_boot.mk
$(info Including ${RSS_MEASURED_BOOT_MK})
include ${RSS_MEASURED_BOOT_MK}
BL1_SOURCES += ${MEASURED_BOOT_SOURCES}
BL2_SOURCES += ${MEASURED_BOOT_SOURCES}
endif
TBB: add platform API to read the ROTPK information This patch extends the platform port by adding an API that returns either the Root of Trust public key (ROTPK) or its hash. This is usually stored in ROM or eFUSE memory. The ROTPK returned must be encoded in DER format according to the following ASN.1 structure: SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } In case the platform returns a hash of the key: DigestInfo ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier, keyDigest OCTET STRING } An implementation for ARM development platforms is provided in this patch. When TBB is enabled, the ROTPK hash location must be specified using the build option 'ARM_ROTPK_LOCATION'. Available options are: - 'regs' : return the ROTPK hash stored in the Trusted root-key storage registers. - 'devel_rsa' : return a ROTPK hash embedded in the BL1 and BL2 binaries. This hash has been obtained from the development RSA public key located in 'plat/arm/board/common/rotpk'. On FVP, the number of MMU tables has been increased to map and access the ROTPK registers. A new file 'board_common.mk' has been added to improve code sharing in the ARM develelopment platforms. Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
2015-04-14 12:49:03 +01:00
include plat/arm/board/common/board_common.mk
Migrate FVP port to use common code Major update to the FVP platform port to use the common platform code in (include/)plat/arm/* and (include/)plat/common/*. This mainly consists of removing duplicated code but also introduces some small behavioural changes where there was unnecessary variation between the FVP and Juno ports. See earlier commit titled `Add common ARM and CSS platform code` for details. Also add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
2015-03-19 19:17:53 +00:00
include plat/arm/common/arm_common.mk
FVP: Enable capability to disable auth via dynamic config This patch adds capability to FVP to disable authentication dynamically via the `disable_auth` property in TB_FW_CONFIG. Both BL1 and BL2 parses the TB_FW_CONFIG for the `disable_auth` property and invokes the `load_dyn_disable_auth()` API to disable authentication if the property is set to 1. The DYN_DISABLE_AUTH is enabled by default for FVP as it is a development platform. Note that the TB_FW_CONFIG has to be authenticated by BL1 irrespective of these settings. The arm_bl2_dyn_cfg_init() is now earlier in bl2_plat_preload_setup() rather than in bl2_platform_setup() as we need to get the value of `disable_auth` property prior to authentication of any image by BL2. Change-Id: I734acd59572849793e5020ec44c6ac51f654a4d1 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-03-26 15:16:46 +01:00
plat/arm/board/fvp: Add support for Measured Boot This patch adds support for Measured Boot functionality to FVP platform code. It also defines new properties in 'tpm_event_log' node to store Event Log address and it size 'tpm_event_log_sm_addr' 'tpm_event_log_addr' 'tpm_event_log_size' in 'event_log.dtsi' included in 'fvp_tsp_fw_config.dts' and 'fvp_nt_fw_config.dts'. The node and its properties are described in binding document 'docs\components\measured_boot\event_log.rst'. Change-Id: I087e1423afcb269d6cfe79c1af9c348931991292 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2020-07-13 14:59:02 +01:00
ifeq (${MEASURED_BOOT},1)
feat(measured_boot): image hash measurement and recording in BL1 It looks safer and cleaner approach to record the measurement taken by BL1 straightaway in TCG Event Log instead of deferring these recordings to BL2. Hence pull in the full-fledged measured boot driver into BL1 that replaces the former ad-hoc platform interfaces i.e. bl1_plat_set_bl2_hash, bl2_plat_get_hash. As a result of this change the BL1 of Arm FVP platform now do the measurements and recordings of below images: 1. FW_CONFIG 2. TB_FW_CONFIG 3. BL2 Change-Id: I798c20336308b5e91b547da4f8ed57c24d490731 Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
2021-09-14 23:12:42 +01:00
BL1_SOURCES += plat/arm/board/fvp/fvp_common_measured_boot.c \
feat(plat/arm/fvp): enable RSS backend based measured boot Enable the RSS backend based measured boot feature. In the absence of RSS the mocked version of PSA APIs are used. They always return with success and hard-code data. Signed-off-by: Tamas Ban <tamas.ban@arm.com> Change-Id: I7543e9033a7a21f1b836d911d8d9498c6e09b956
2022-02-11 08:49:36 +00:00
plat/arm/board/fvp/fvp_bl1_measured_boot.c \
lib/psa/measured_boot.c
feat(measured_boot): image hash measurement and recording in BL1 It looks safer and cleaner approach to record the measurement taken by BL1 straightaway in TCG Event Log instead of deferring these recordings to BL2. Hence pull in the full-fledged measured boot driver into BL1 that replaces the former ad-hoc platform interfaces i.e. bl1_plat_set_bl2_hash, bl2_plat_get_hash. As a result of this change the BL1 of Arm FVP platform now do the measurements and recordings of below images: 1. FW_CONFIG 2. TB_FW_CONFIG 3. BL2 Change-Id: I798c20336308b5e91b547da4f8ed57c24d490731 Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
2021-09-14 23:12:42 +01:00
BL2_SOURCES += plat/arm/board/fvp/fvp_common_measured_boot.c \
feat(plat/arm/fvp): enable RSS backend based measured boot Enable the RSS backend based measured boot feature. In the absence of RSS the mocked version of PSA APIs are used. They always return with success and hard-code data. Signed-off-by: Tamas Ban <tamas.ban@arm.com> Change-Id: I7543e9033a7a21f1b836d911d8d9498c6e09b956
2022-02-11 08:49:36 +00:00
plat/arm/board/fvp/fvp_bl2_measured_boot.c \
lib/psa/measured_boot.c
PLAT_INCLUDES += -Iinclude/lib/psa
# RSS is not supported on FVP right now. Thus, we use the mocked version
# of PSA Measured Boot APIs. They return with success and hard-coded data.
PLAT_RSS_NOT_SUPPORTED := 1
plat/arm/board/fvp: Add support for Measured Boot This patch adds support for Measured Boot functionality to FVP platform code. It also defines new properties in 'tpm_event_log' node to store Event Log address and it size 'tpm_event_log_sm_addr' 'tpm_event_log_addr' 'tpm_event_log_size' in 'event_log.dtsi' included in 'fvp_tsp_fw_config.dts' and 'fvp_nt_fw_config.dts'. The node and its properties are described in binding document 'docs\components\measured_boot\event_log.rst'. Change-Id: I087e1423afcb269d6cfe79c1af9c348931991292 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2020-07-13 14:59:02 +01:00
endif
refactor(fvp): avoid Measured-Boot dependency on Trusted-Boot As Measured-Boot and Trusted-Boot are orthogonal, removed Trusted-Boot's dependency on Measured-Boot by allowing them to apply the Crypto module changes independently using the CRYPTO_SUPPORT build flag. Change-Id: I5a420e5d84f3fefe0c0092d822dab981e6390bbf Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
2022-01-08 23:08:02 +00:00
ifeq (${TRUSTED_BOARD_BOOT}, 1)
BL1_SOURCES += plat/arm/board/fvp/fvp_trusted_boot.c
BL2_SOURCES += plat/arm/board/fvp/fvp_trusted_boot.c
FVP: Enable capability to disable auth via dynamic config This patch adds capability to FVP to disable authentication dynamically via the `disable_auth` property in TB_FW_CONFIG. Both BL1 and BL2 parses the TB_FW_CONFIG for the `disable_auth` property and invokes the `load_dyn_disable_auth()` API to disable authentication if the property is set to 1. The DYN_DISABLE_AUTH is enabled by default for FVP as it is a development platform. Note that the TB_FW_CONFIG has to be authenticated by BL1 irrespective of these settings. The arm_bl2_dyn_cfg_init() is now earlier in bl2_plat_preload_setup() rather than in bl2_platform_setup() as we need to get the value of `disable_auth` property prior to authentication of any image by BL2. Change-Id: I734acd59572849793e5020ec44c6ac51f654a4d1 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-03-26 15:16:46 +01:00
# FVP being a development platform, enable capability to disable Authentication
plat/arm: Migrate to new interfaces - Remove references to removed build options. - Remove support for legacy GIC driver. - Remove support for LOAD_IMAGE_V2=0. Change-Id: I72f8c05620bdf4a682765e6e53e2c04ca749a3d5 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-09-25 11:37:23 +01:00
# dynamically if TRUSTED_BOARD_BOOT is set.
Adds option to read ROTPK from registers for FVP Enables usage of ARM_ROTPK_LOCATION=regs for FVP board. Removes hard-coded developer keys. Instead, setting ARM_ROTPK_LOCATION=devel_* takes keys from default directory. In case of ROT_KEY specified - generates a new hash and replaces the original. Note: Juno board was tested by original feature author and was not tested for this patch since we don't have access to the private key. Juno implementation was moved to board-specific file without changing functionality. It is not known whether byte-swapping is still needed for this platform. Change-Id: I0fdbaca0415cdcd78f3a388551c2e478c01ed986 Signed-off-by: Max Shvetsov <maksims.svecovs@arm.com>
2019-12-06 11:50:12 +00:00
DYN_DISABLE_AUTH := 1
FVP: Enable capability to disable auth via dynamic config This patch adds capability to FVP to disable authentication dynamically via the `disable_auth` property in TB_FW_CONFIG. Both BL1 and BL2 parses the TB_FW_CONFIG for the `disable_auth` property and invokes the `load_dyn_disable_auth()` API to disable authentication if the property is set to 1. The DYN_DISABLE_AUTH is enabled by default for FVP as it is a development platform. Note that the TB_FW_CONFIG has to be authenticated by BL1 irrespective of these settings. The arm_bl2_dyn_cfg_init() is now earlier in bl2_plat_preload_setup() rather than in bl2_platform_setup() as we need to get the value of `disable_auth` property prior to authentication of any image by BL2. Change-Id: I734acd59572849793e5020ec44c6ac51f654a4d1 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-03-26 15:16:46 +01:00
endif
feat(plat/fvp): enable trace extension features by default Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: I3e344b0abda7ab4e54ee918ec65ff39d40855fcd
2021-08-24 14:42:35 +01:00
# enable trace buffer control registers access to NS by default
ENABLE_TRBE_FOR_NS := 1
feat(brbe): add BRBE support for NS world This patch enables access to the branch record buffer control registers in non-secure EL2 and EL1 using the new build option ENABLE_BRBE_FOR_NS. It is disabled for all secure world, and cannot be used with ENABLE_RME. This option is disabled by default, however, the FVP platform makefile enables it for FVP builds. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: I576a49d446a8a73286ea6417c16bd0b8de71fca0
2022-01-28 23:06:20 +00:00
# enable branch record buffer control registers access in NS by default
# only enable for aarch64
# do not enable when ENABLE_RME=1
ifeq (${ARCH}, aarch64)
ifeq (${ENABLE_RME},0)
ENABLE_BRBE_FOR_NS := 1
endif
endif
feat(plat/fvp): enable trace extension features by default Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: I3e344b0abda7ab4e54ee918ec65ff39d40855fcd
2021-08-24 14:42:35 +01:00
# enable trace system registers access to NS by default
ENABLE_SYS_REG_TRACE_FOR_NS := 1
# enable trace filter control registers access to NS by default
ENABLE_TRF_FOR_NS := 1
feat(plat/fvp): introduce accessor function to obtain datastore In order to provide the EL3 SPMC a sufficient datastore to record memory descriptors, a accessor function is used. This allows for the backing memory to be allocated in a platform defined manner, to accommodate memory constraints and desired use cases. Provide an implementation for the Arm FVP platform to use a default value of 512KB memory allocated in the TZC RAM section. Signed-off-by: Marc Bonnici <marc.bonnici@arm.com> Change-Id: I92bc55ba6e04bdad429eb52f0d2960ceda682804
2021-12-16 18:31:02 +00:00
ifeq (${SPMC_AT_EL3}, 1)
PLAT_BL_COMMON_SOURCES += plat/arm/board/fvp/fvp_el3_spmc.c
endif