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

352 lines
10 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
#
FVP: Stop reclaiming init code with Clang builds The reclaim init code functionality relies on forward reference in the linker script. The LLVM linker does not process it correctly. Change-Id: I993aeb9587bfa07af25b60ed823a6a2c5e970c94 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com> Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
2019-07-17 11:17:28 +01:00
# Copyright (c) 2013-2020, 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
#
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
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
# Use the SP804 timer instead of the generic one
FVP_USE_SP804_TIMER := 0
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
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
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
$(eval $(call assert_boolean,FVP_USE_SP804_TIMER))
$(eval $(call add_define,FVP_USE_SP804_TIMER))
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))
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
ifeq (${FVP_USE_GIC_DRIVER},$(filter ${FVP_USE_GIC_DRIVER},FVP_GICV3 FVP_GIC600))
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
# GIC500 is the default option in case GICV3_IMPL is not set
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
ifeq (${FVP_USE_GIC_DRIVER}, FVP_GIC600)
GICV3_IMPL := GIC600
endif
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
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))
# No support for extended PPI and SPI range
GIC_EXT_INTID := 0
$(eval $(call add_define,GIC_EXT_INTID))
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
FVP_GIC_SOURCES := drivers/arm/gic/common/gic_common.c \
drivers/arm/gic/v2/gicv2_main.c \
drivers/arm/gic/v2/gicv2_helpers.c \
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 \
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 \
lib/cpus/aarch64/neoverse_e1.S \
Cortex_hercules: Introduce preliminary cpu support Change-Id: Iab767e9937f5c6c8150953fcdc3b37e8ee83fa63 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
2019-05-14 11:00:45 +01:00
lib/cpus/aarch64/neoverse_zeus.S \
Cortex_hercules: Add support for Hercules-AE Not tested on FVP Model. Change-Id: Iedebc5c1fbc7ea577e94142b7feafa5546f1f4f9 Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com>
2019-09-16 15:11:21 +01:00
lib/cpus/aarch64/cortex_hercules.S \
Introducing support for Cortex-A65 Change-Id: I645442d52a295706948e2cac88c36c1a3cb0bc47 Signed-off-by: Imre Kis <imre.kis@arm.com>
2019-07-18 13:30:03 +01:00
lib/cpus/aarch64/cortex_hercules_ae.S \
Add CPULib for Klein Core Change-Id: I686fd623b8264c85434853a2a26ecd71e9eeac01 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
2019-12-09 20:02:22 +00:00
lib/cpus/aarch64/cortex_klein.S \
Add Matterhorn CPU lib Also update copyright statements Change-Id: Iba0305522ac0f2ddc4da99127fd773f340e67300 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
2020-01-08 19:52:51 +00:00
lib/cpus/aarch64/cortex_matterhorn.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 \
lib/cpus/aarch64/cortex_a65ae.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}
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
ifeq (${FVP_USE_SP804_TIMER},1)
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
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
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
ifeq (${FVP_USE_SP804_TIMER},1)
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
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
ifeq (${FVP_USE_SP804_TIMER},1)
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 \
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}),)
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
BL31_SOURCES += common/fdt_wrappers.c \
lib/fconf/fconf.c \
plat/arm/board/fvp/fconf/fconf_hw_config_getter.c
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
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
ifeq (${FVP_USE_SP804_TIMER},1)
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 \
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 \
)
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
FVP_TB_FW_CONFIG := ${BUILD_PLAT}/fdts/${PLAT}_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
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_TOS_FW_CONFIG},--tos-fw-config))
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)
FDT_SOURCES += plat/arm/board/fvp/fdts/${PLAT}_spmc_manifest.dts
FVP_TOS_FW_CONFIG := ${BUILD_PLAT}/fdts/${PLAT}_spmc_manifest.dtb
# Add the TOS_FW_CONFIG to FIP and specify the same to certtool
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_TOS_FW_CONFIG},--tos-fw-config))
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
# Add the TB_FW_CONFIG to FIP and specify the same to certtool
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_TB_FW_CONFIG},--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
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_SOC_FW_CONFIG},--soc-fw-config))
# Add the NT_FW_CONFIG to FIP and specify the same to certtool
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_NT_FW_CONFIG},--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
$(eval $(call TOOL_ADD_PAYLOAD,${FVP_HW_CONFIG},--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
plat/arm: Re-enable PIE when RESET_TO_BL31=1 Earlier PIE support was enabled for all arm platforms when RESET_TO_BL31=1, but later on it was restricted only to FVP with patch SHA d4580d17 because of n1sdp platform. Now it has been verified that PIE does work for n1sdp platform also, so enabling it again for all arm platforms. Change-Id: I05ad4f1775ef72e7cb578ec9245cde3fbce971a5 Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
2019-11-06 13:17:46 +00:00
# Enable reclaiming of BL31 initialisation code for secondary cores
FVP: Stop reclaiming init code with Clang builds The reclaim init code functionality relies on forward reference in the linker script. The LLVM linker does not process it correctly. Change-Id: I993aeb9587bfa07af25b60ed823a6a2c5e970c94 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com> Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
2019-07-17 11:17:28 +01:00
# stacks for FVP. However, don't enable reclaiming for clang.
FVP: Enable PIE for RESET_TO_BL31=1 This patch enabled PIE for FVP when RESET_TO_BL31=1. The references to BL31_BASE are replaced by BL31_START as being a symbol exported by the linker, will create a dynamic relocation entry in .rela.dyn and hence will be fixed up by dynamic linker at runtime. Also, we disable RECLAIM_INIT_CODE when PIE is enabled as the init section overlay creates some static relocations which cannot be handled by the dynamic linker currently. Change-Id: I86df1b0a8b2a8bbbe7c3f3c0b9a08c86c2963ec0 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-10-14 08:13:44 +01:00
ifneq (${RESET_TO_BL31},1)
FVP: Stop reclaiming init code with Clang builds The reclaim init code functionality relies on forward reference in the linker script. The LLVM linker does not process it correctly. Change-Id: I993aeb9587bfa07af25b60ed823a6a2c5e970c94 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com> Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
2019-07-17 11:17:28 +01:00
ifeq ($(findstring clang,$(notdir $(CC))),)
FVP: Reclaim init code for the stack Map the initialization code for BL31 to overlap with the memory required for the secondary cores stack. Once BL31 has been initialized the memory can be remapped to RW data so that it can be used for secondary cores stacks. By moving code from .text to .text.init the size of the BL31 image is decreased by a page. Split arm_common.ld.S into two linker scripts, one for tzc_dram (arm_tzc_dram.ld.S) and one for reclaiming initialization code (arm_reclaim_init.ld.S) so that platforms can chose which memory regions they wish to include. Change-Id: I648e88f3eda1aa71765744cf34343ecda9320b32 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
2018-09-18 11:52:49 +01:00
RECLAIM_INIT_CODE := 1
FVP: Enable PIE for RESET_TO_BL31=1 This patch enabled PIE for FVP when RESET_TO_BL31=1. The references to BL31_BASE are replaced by BL31_START as being a symbol exported by the linker, will create a dynamic relocation entry in .rela.dyn and hence will be fixed up by dynamic linker at runtime. Also, we disable RECLAIM_INIT_CODE when PIE is enabled as the init section overlay creates some static relocations which cannot be handled by the dynamic linker currently. Change-Id: I86df1b0a8b2a8bbbe7c3f3c0b9a08c86c2963ec0 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-10-14 08:13:44 +01:00
endif
FVP: Stop reclaiming init code with Clang builds The reclaim init code functionality relies on forward reference in the linker script. The LLVM linker does not process it correctly. Change-Id: I993aeb9587bfa07af25b60ed823a6a2c5e970c94 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com> Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
2019-07-17 11:17:28 +01:00
endif
FVP: Reclaim init code for the stack Map the initialization code for BL31 to overlap with the memory required for the secondary cores stack. Once BL31 has been initialized the memory can be remapped to RW data so that it can be used for secondary cores stacks. By moving code from .text to .text.init the size of the BL31 image is decreased by a page. Split arm_common.ld.S into two linker scripts, one for tzc_dram (arm_tzc_dram.ld.S) and one for reclaiming initialization code (arm_reclaim_init.ld.S) so that platforms can chose which memory regions they wish to include. Change-Id: I648e88f3eda1aa71765744cf34343ecda9320b32 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
2018-09-18 11:52:49 +01:00
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.
ifeq (${ARCH},aarch32)
ifeq (${RESET_TO_SP_MIN},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
BL32_CPPFLAGS += -DPLAT_XLAT_TABLES_DYNAMIC
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
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/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
ifeq (${RESET_TO_BL31},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
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
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
ifeq (${SPD},trusty)
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
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
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
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
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