andrius
/
arm-trusted-firmware
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
arm-trusted-firmware/plat/arm/common/arm_common.mk

188 lines
6.2 KiB
Makefile
Raw Normal View History

Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +00:00
#
PSCI: Decouple PSCI stat residency calculation from PMF This patch introduces the following three platform interfaces: * void plat_psci_stat_accounting_start(const psci_power_state_t *state_info) This is an optional hook that platforms can implement in order to perform accounting before entering a low power state. This typically involves capturing a timestamp. * void plat_psci_stat_accounting_stop(const psci_power_state_t *state_info) This is an optional hook that platforms can implement in order to perform accounting after exiting from a low power state. This typically involves capturing a timestamp. * u_register_t plat_psci_stat_get_residency(unsigned int lvl, const psci_power_state_t *state_info, unsigned int last_cpu_index) This is an optional hook that platforms can implement in order to calculate the PSCI stat residency. If any of these interfaces are overridden by the platform, it is recommended that all of them are. By default `ENABLE_PSCI_STAT` is disabled. If `ENABLE_PSCI_STAT` is set but `ENABLE_PMF` is not set then an alternative PSCI stat collection backend must be provided. If both are set, then default weak definitions of these functions are provided, using PMF to calculate the residency. NOTE: Previously, platforms did not have to explicitly set `ENABLE_PMF` since this was automatically done by the top-level Makefile. Change-Id: I17b47804dea68c77bc284df15ee1ccd66bc4b79b Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-01-31 13:01:04 +00:00
# Copyright (c) 2015-2017, ARM Limited and Contributors. All rights reserved.
Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +00:00
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# Redistributions of source code must retain the above copyright notice, this
# list of conditions and the following disclaimer.
#
# Redistributions in binary form must reproduce the above copyright notice,
# this list of conditions and the following disclaimer in the documentation
# and/or other materials provided with the distribution.
#
# Neither the name of ARM nor the names of its contributors may be used
# to endorse or promote products derived from this software without specific
# prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
#
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
ifeq (${ARCH}, aarch64)
# On ARM standard platorms, the TSP can execute from Trusted SRAM, Trusted
# DRAM (if available) or the TZC secured area of DRAM.
# Trusted SRAM is the default.
ARM_TSP_RAM_LOCATION := tsram
ifeq (${ARM_TSP_RAM_LOCATION}, tsram)
ARM_TSP_RAM_LOCATION_ID = ARM_TRUSTED_SRAM_ID
else ifeq (${ARM_TSP_RAM_LOCATION}, tdram)
ARM_TSP_RAM_LOCATION_ID = ARM_TRUSTED_DRAM_ID
else ifeq (${ARM_TSP_RAM_LOCATION}, dram)
ARM_TSP_RAM_LOCATION_ID = ARM_DRAM_ID
else
$(error "Unsupported ARM_TSP_RAM_LOCATION value")
endif
Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +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
# Process flags
$(eval $(call add_define,ARM_TSP_RAM_LOCATION_ID))
# Process ARM_BL31_IN_DRAM flag
ARM_BL31_IN_DRAM := 0
$(eval $(call assert_boolean,ARM_BL31_IN_DRAM))
$(eval $(call add_define,ARM_BL31_IN_DRAM))
endif
Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +00:00
PSCI: Demonstrate support for composite power states This patch adds support to the Juno and FVP ports for composite power states with both the original and extended state-id power-state formats. Both the platform ports use the recommended state-id encoding as specified in Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag ARM_RECOM_STATE_ID_ENC is used to include this support. By default, to maintain backwards compatibility, the original power state parameter format is used and the state-id field is expected to be zero. Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
2015-04-16 14:49:09 +01:00
# For the original power-state parameter format, the State-ID can be encoded
# according to the recommended encoding or zero. This flag determines which
# State-ID encoding to be parsed.
ARM_RECOM_STATE_ID_ENC := 0
Clarify dependency for PSCI_EXTENDED_STATE_ID Add dependency information in the user guide for ARM_RECOM_STATE_ID_ENC that needs to be set when using PSCI_EXTENDED_STATE_ID on ARM platforms. Also clarify the build error message. Change-Id: Id125a0299b179f5f222bca4e2503204bf89a3c59 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2016-11-07 17:29:34 +00:00
# If the PSCI_EXTENDED_STATE_ID is set, then ARM_RECOM_STATE_ID_ENC need to
# be set. Else throw a build error.
PSCI: Demonstrate support for composite power states This patch adds support to the Juno and FVP ports for composite power states with both the original and extended state-id power-state formats. Both the platform ports use the recommended state-id encoding as specified in Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag ARM_RECOM_STATE_ID_ENC is used to include this support. By default, to maintain backwards compatibility, the original power state parameter format is used and the state-id field is expected to be zero. Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
2015-04-16 14:49:09 +01:00
ifeq (${PSCI_EXTENDED_STATE_ID}, 1)
ifeq (${ARM_RECOM_STATE_ID_ENC}, 0)
Clarify dependency for PSCI_EXTENDED_STATE_ID Add dependency information in the user guide for ARM_RECOM_STATE_ID_ENC that needs to be set when using PSCI_EXTENDED_STATE_ID on ARM platforms. Also clarify the build error message. Change-Id: Id125a0299b179f5f222bca4e2503204bf89a3c59 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2016-11-07 17:29:34 +00:00
$(error Build option ARM_RECOM_STATE_ID_ENC needs to be set if \
PSCI_EXTENDED_STATE_ID is set for ARM platforms)
PSCI: Demonstrate support for composite power states This patch adds support to the Juno and FVP ports for composite power states with both the original and extended state-id power-state formats. Both the platform ports use the recommended state-id encoding as specified in Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag ARM_RECOM_STATE_ID_ENC is used to include this support. By default, to maintain backwards compatibility, the original power state parameter format is used and the state-id field is expected to be zero. Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
2015-04-16 14:49:09 +01:00
endif
endif
# Process ARM_RECOM_STATE_ID_ENC flag
$(eval $(call assert_boolean,ARM_RECOM_STATE_ID_ENC))
$(eval $(call add_define,ARM_RECOM_STATE_ID_ENC))
TBB: add Trusted Watchdog support on ARM platforms This patch adds watchdog support on ARM platforms (FVP and Juno). A secure instance of SP805 is used as Trusted Watchdog. It is entirely managed in BL1, being enabled in the early platform setup hook and disabled in the exit hook. By default, the watchdog is enabled in every build (even when TBB is disabled). A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG` has been introduced to allow the user to disable the watchdog at build time. This feature may be used for testing or debugging purposes. Specific error handlers for Juno and FVP are also provided in this patch. These handlers will be called after an image load or authentication error. On FVP, the Table of Contents (ToC) in the FIP is erased. On Juno, the corresponding error code is stored in the V2M Non-Volatile flags register. In both cases, the CPU spins until a watchdog reset is generated after 256 seconds (as specified in the TBBR document). Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
2015-10-06 14:01:35 +01:00
# Process ARM_DISABLE_TRUSTED_WDOG flag
# By default, Trusted Watchdog is always enabled unless SPIN_ON_BL1_EXIT is set
ARM_DISABLE_TRUSTED_WDOG := 0
ifeq (${SPIN_ON_BL1_EXIT}, 1)
ARM_DISABLE_TRUSTED_WDOG := 1
endif
$(eval $(call assert_boolean,ARM_DISABLE_TRUSTED_WDOG))
$(eval $(call add_define,ARM_DISABLE_TRUSTED_WDOG))
ARM plat: add build option to unlock access to non-secure timer Currently, Trusted Firmware on ARM platforms unlocks access to the timer frame registers that will be used by the Non-Secure world. This unlock operation should be done by the Non-Secure software itself, instead of relying on secure firmware settings. This patch adds a new ARM specific build option 'ARM_CONFIG_CNTACR' to unlock access to the timer frame by setting the corresponding bits in the CNTACR<N> register. The frame id <N> is defined by 'PLAT_ARM_NSTIMER_FRAME_ID'. Default value is true (unlock timer access). Documentation updated accordingly. Fixes ARM-software/tf-issues#170 Change-Id: Id9d606efd781e43bc581868cd2e5f9c8905bdbf6
2015-11-06 16:02:32 +00:00
# Process ARM_CONFIG_CNTACR
ARM_CONFIG_CNTACR := 1
$(eval $(call assert_boolean,ARM_CONFIG_CNTACR))
$(eval $(call add_define,ARM_CONFIG_CNTACR))
Add support to load BL31 in DRAM This patch adds an option to the ARM common platforms to load BL31 in the TZC secured DRAM instead of the default secure SRAM. To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options. If TSP is present, then setting this option also sets the TSP location to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag. To use this feature, BL2 platform code must map in the DRAM used by BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose. Currently, only the FVP BL2 platform code maps in this DRAM. Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67
2016-03-07 03:02:57 +00:00
# Process ARM_BL31_IN_DRAM flag
ARM_BL31_IN_DRAM := 0
$(eval $(call assert_boolean,ARM_BL31_IN_DRAM))
$(eval $(call add_define,ARM_BL31_IN_DRAM))
Enable PSCI_STAT_COUNT/RESIDENCY for ARM standard platforms This patch enables optional PSCI functions `PSCI_STAT_COUNT` and `PSCI_STAT_RESIDENCY` for ARM standard platforms. The optional platform API 'translate_power_state_by_mpidr()' is implemented for the Juno platform. 'validate_power_state()' on Juno downgrades PSCI CPU_SUSPEND requests for the system power level to the cluster power level. Hence, it is not suitable for validating the 'power_state' parameter passed in a PSCI_STAT_COUNT/RESIDENCY call. Change-Id: I9548322676fa468d22912392f2325c2a9f96e4d2
2016-05-23 16:07:53 +01:00
# Enable PSCI_STAT_COUNT/RESIDENCY APIs on ARM platforms
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
ENABLE_PSCI_STAT := 1
PSCI: Decouple PSCI stat residency calculation from PMF This patch introduces the following three platform interfaces: * void plat_psci_stat_accounting_start(const psci_power_state_t *state_info) This is an optional hook that platforms can implement in order to perform accounting before entering a low power state. This typically involves capturing a timestamp. * void plat_psci_stat_accounting_stop(const psci_power_state_t *state_info) This is an optional hook that platforms can implement in order to perform accounting after exiting from a low power state. This typically involves capturing a timestamp. * u_register_t plat_psci_stat_get_residency(unsigned int lvl, const psci_power_state_t *state_info, unsigned int last_cpu_index) This is an optional hook that platforms can implement in order to calculate the PSCI stat residency. If any of these interfaces are overridden by the platform, it is recommended that all of them are. By default `ENABLE_PSCI_STAT` is disabled. If `ENABLE_PSCI_STAT` is set but `ENABLE_PMF` is not set then an alternative PSCI stat collection backend must be provided. If both are set, then default weak definitions of these functions are provided, using PMF to calculate the residency. NOTE: Previously, platforms did not have to explicitly set `ENABLE_PMF` since this was automatically done by the top-level Makefile. Change-Id: I17b47804dea68c77bc284df15ee1ccd66bc4b79b Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-01-31 13:01:04 +00:00
ENABLE_PMF := 1
Enable PSCI_STAT_COUNT/RESIDENCY for ARM standard platforms This patch enables optional PSCI functions `PSCI_STAT_COUNT` and `PSCI_STAT_RESIDENCY` for ARM standard platforms. The optional platform API 'translate_power_state_by_mpidr()' is implemented for the Juno platform. 'validate_power_state()' on Juno downgrades PSCI CPU_SUSPEND requests for the system power level to the cluster power level. Hence, it is not suitable for validating the 'power_state' parameter passed in a PSCI_STAT_COUNT/RESIDENCY call. Change-Id: I9548322676fa468d22912392f2325c2a9f96e4d2
2016-05-23 16:07:53 +01:00
ARM platforms: Add support for SEPARATE_CODE_AND_RODATA The arm_setup_page_tables() function used to expect a single set of addresses defining the extents of the whole read-only section, code and read-only data mixed up, which was mapped as executable. This patch changes this behaviour. arm_setup_page_tables() now expects 2 separate sets of addresses: - the extents of the code section; - the extents of the read-only data section. The code is mapped as executable, whereas the data is mapped as execute-never. New #defines have been introduced to identify the extents of the code and the read-only data section. Given that all BL images except BL1 share the same memory layout and linker script structure, these #defines are common across these images. The slight memory layout differences in BL1 have been handled by providing values specific to BL1. Note that this patch also affects the Xilinx platform port, which uses the arm_setup_page_tables() function. It has been updated accordingly, such that the memory mappings on this platform are unchanged. This is achieved by passing null values as the extents of the read-only data section so that it is ignored. As a result, the whole read-only section is still mapped as executable. Fixes ARM-software/tf-issues#85 Change-Id: I1f95865c53ce6e253a01286ff56e0aa1161abac5
2016-07-08 14:38:16 +01:00
# On ARM platforms, separate the code and read-only data sections to allow
# mapping the former as executable and the latter as execute-never.
SEPARATE_CODE_AND_RODATA := 1
Enable TRUSTED_BOARD_BOOT support for LOAD_IMAGE_V2=1 This patch enables TRUSTED_BOARD_BOOT (Authentication and FWU) support, for AArch64, when LOAD_IMAGE_V2 is enabled. This patch also enables LOAD_IMAGE_V2 for ARM platforms. Change-Id: I294a2eebce7a30b6784c80c9d4ac7752808ee3ad Signed-off-by: Yatharth Kochar <yatharth.kochar@arm.com>
2016-11-11 13:57:50 +00:00
# Enable new version of image loading on ARM platforms
LOAD_IMAGE_V2 := 1
ARM platforms: Add support for SEPARATE_CODE_AND_RODATA The arm_setup_page_tables() function used to expect a single set of addresses defining the extents of the whole read-only section, code and read-only data mixed up, which was mapped as executable. This patch changes this behaviour. arm_setup_page_tables() now expects 2 separate sets of addresses: - the extents of the code section; - the extents of the read-only data section. The code is mapped as executable, whereas the data is mapped as execute-never. New #defines have been introduced to identify the extents of the code and the read-only data section. Given that all BL images except BL1 share the same memory layout and linker script structure, these #defines are common across these images. The slight memory layout differences in BL1 have been handled by providing values specific to BL1. Note that this patch also affects the Xilinx platform port, which uses the arm_setup_page_tables() function. It has been updated accordingly, such that the memory mappings on this platform are unchanged. This is achieved by passing null values as the extents of the read-only data section so that it is ignored. As a result, the whole read-only section is still mapped as executable. Fixes ARM-software/tf-issues#85 Change-Id: I1f95865c53ce6e253a01286ff56e0aa1161abac5
2016-07-08 14:38:16 +01:00
TBB: add TBBR Chain of Trust This patch adds a CoT based on the Trusted Board Boot Requirements document*. The CoT consists of an array of authentication image descriptors indexed by the image identifiers. A new header file with TBBR image identifiers has been added. Platforms that use the TBBR (i.e. ARM platforms) may reuse these definitions as part of their platform porting. PLATFORM PORT - IMPORTANT: Default image IDs have been removed from the platform common definitions file (common_def.h). As a consequence, platforms that used those common definitons must now either include the IDs provided by the TBBR header file or define their own IDs. *The NVCounter authentication method has not been implemented yet. Change-Id: I7c4d591863ef53bb0cd4ce6c52a60b06fa0102d5
2015-05-07 14:52:44 +01:00
PLAT_INCLUDES += -Iinclude/common/tbbr \
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
-Iinclude/plat/arm/common
Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +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
ifeq (${ARCH}, aarch64)
PLAT_INCLUDES += -Iinclude/plat/arm/common/aarch64
endif
Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +00:00
ARM platforms: Enable xlat tables lib v2 Modify ARM common makefile to use version 2 of the translation tables library and include the new header in C files. Simplify header dependencies related to this library to simplify the change. The following table contains information about the size increase in bytes for BL1 after applying this patch. The code has been compiled for different configurations of FVP in AArch64 mode with compiler GCC 4.9.3 20150413. The sizes have been calculated with the output of `nm` by adding the size of all regions and comparing the total size before and after the change. They are sumarized in the table below: text bss data total Release +660 -20 +88 +728 Debug +740 -20 +242 +962 Debug (LOG_LEVEL=50) +1120 -20 +317 +1417 Change-Id: I539e307f158ab71e3a8b771640001fc1bf431b29 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2017-02-23 17:22:58 +00:00
include lib/xlat_tables_v2/xlat_tables.mk
PLAT_BL_COMMON_SOURCES += ${XLAT_TABLES_LIB_SRCS} \
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
plat/arm/common/${ARCH}/arm_helpers.S \
Move plat/common source file definitions to generic Makefiles These source file definitions should be defined in generic Makefiles so that all platforms can benefit. Ensure that the symbols are properly marked as weak so they can be overridden by platforms. NOTE: This change is a potential compatibility break for non-upstream platforms. Change-Id: I7b892efa9f2d6d216931360dc6c436e1d10cffed Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-03-07 11:02:47 +00:00
plat/arm/common/arm_common.c
Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +00:00
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
BL1_SOURCES += drivers/arm/sp805/sp805.c \
Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +00:00
drivers/io/io_fip.c \
drivers/io/io_memmap.c \
drivers/io/io_storage.c \
plat/arm/common/arm_bl1_setup.c \
Move plat/common source file definitions to generic Makefiles These source file definitions should be defined in generic Makefiles so that all platforms can benefit. Ensure that the symbols are properly marked as weak so they can be overridden by platforms. NOTE: This change is a potential compatibility break for non-upstream platforms. Change-Id: I7b892efa9f2d6d216931360dc6c436e1d10cffed Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-03-07 11:02:47 +00:00
plat/arm/common/arm_io_storage.c
CSS: Enable booting of EL3 payloads This patch adds support for booting EL3 payloads on CSS platforms, for example Juno. In this scenario, the Trusted Firmware follows its normal boot flow up to the point where it would normally pass control to the BL31 image. At this point, it jumps to the EL3 payload entry point address instead. Before handing over to the EL3 payload, the data SCP writes for AP at the beginning of the Trusted SRAM is restored, i.e. we zero the first 128 bytes and restore the SCP Boot configuration. The latter is saved before transferring the BL30 image to SCP and is restored just after the transfer (in BL2). The goal is to make it appear that the EL3 payload is the first piece of software to run on the target. The BL31 entrypoint info structure is updated to make the primary CPU jump to the EL3 payload instead of the BL31 image. The mailbox is populated with the EL3 payload entrypoint address, which releases the secondary CPUs out of their holding pen (if the SCP has powered them on). The arm_program_trusted_mailbox() function has been exported for this purpose. The TZC-400 configuration in BL2 is simplified: it grants secure access only to the whole DRAM. Other security initialization is unchanged. This alternative boot flow is disabled by default. A new build option EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3 payload's entry point address. The build system has been modified such that BL31 and BL33 are not compiled and/or not put in the FIP in this case, as those images are not used in this boot flow. Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
2015-11-26 16:31:34 +00:00
ifdef EL3_PAYLOAD_BASE
# Need the arm_program_trusted_mailbox() function to release secondary CPUs from
# their holding pen
BL1_SOURCES += plat/arm/common/arm_pm.c
endif
Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +00:00
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
BL2_SOURCES += drivers/io/io_fip.c \
Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +00:00
drivers/io/io_memmap.c \
drivers/io/io_storage.c \
plat/arm/common/arm_bl2_setup.c \
Move plat/common source file definitions to generic Makefiles These source file definitions should be defined in generic Makefiles so that all platforms can benefit. Ensure that the symbols are properly marked as weak so they can be overridden by platforms. NOTE: This change is a potential compatibility break for non-upstream platforms. Change-Id: I7b892efa9f2d6d216931360dc6c436e1d10cffed Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-03-07 11:02:47 +00:00
plat/arm/common/arm_io_storage.c
ARM platform changes for new version of image loading This patch adds changes in ARM platform code to use new version of image loading. Following are the major changes: -Refactor the signatures for bl31_early_platform_setup() and arm_bl31_early_platform_setup() function to use `void *` instead of `bl31_params_t *`. -Introduce `plat_arm_bl2_handle_scp_bl2()` to handle loading of SCP_BL2 image from BL2. -Remove usage of reserve_mem() function from `arm_bl1_early_platform_setup()` -Extract BL32 & BL33 entrypoint info, from the link list passed by BL2, in `arm_bl31_early_platform_setup()` -Provides weak definitions for following platform functions: plat_get_bl_image_load_info plat_get_next_bl_params plat_flush_next_bl_params bl2_plat_handle_post_image_load -Instantiates a descriptor array for ARM platforms describing image and entrypoint information for `SCP_BL2`, `BL31`, `BL32` and `BL33` images. All the above changes are conditionally compiled using the `LOAD_IMAGE_V2` flag. Change-Id: I5e88b9785a3df1a2b2bbbb37d85b8e353ca61049
2016-09-13 17:07:57 +01:00
ifeq (${LOAD_IMAGE_V2},1)
BL2_SOURCES += plat/arm/common/${ARCH}/arm_bl2_mem_params_desc.c\
plat/arm/common/arm_image_load.c \
common/desc_image_load.c
endif
Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +00:00
Move plat/common source file definitions to generic Makefiles These source file definitions should be defined in generic Makefiles so that all platforms can benefit. Ensure that the symbols are properly marked as weak so they can be overridden by platforms. NOTE: This change is a potential compatibility break for non-upstream platforms. Change-Id: I7b892efa9f2d6d216931360dc6c436e1d10cffed Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-03-07 11:02:47 +00:00
BL2U_SOURCES += plat/arm/common/arm_bl2u_setup.c
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
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
BL31_SOURCES += plat/arm/common/arm_bl31_setup.c \
Add common ARM and CSS platform code This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
2015-03-19 18:58:55 +00:00
plat/arm/common/arm_pm.c \
plat/arm/common/arm_topology.c \
Include `plat_psci_common.c` from the new location The `plat_psci_common.c` was moved to the new location `plat/common` and a stub file was retained at previous location for compatibility. This patch modifies the platform makefiles to include the file from the new location. Change-Id: Iabddeeb824e9a5d72d176d7c644735966c8c0699
2016-05-03 12:31:18 +01:00
plat/common/plat_psci_common.c
TBB: switch to the new authentication framework This patch modifies the Trusted Board Boot implementation to use the new authentication framework, making use of the authentication module, the cryto module and the image parser module to authenticate the images in the Chain of Trust. A new function 'load_auth_image()' has been implemented. When TBB is enabled, this function will call the authentication module to authenticate parent images following the CoT up to the root of trust to finally load and authenticate the requested image. The platform is responsible for picking up the right makefiles to build the corresponding cryptographic and image parser libraries. ARM platforms use the mbedTLS based libraries. The platform may also specify what key algorithm should be used to sign the certificates. This is done by declaring the 'KEY_ALG' variable in the platform makefile. FVP and Juno use ECDSA keys. On ARM platforms, BL2 and BL1-RW regions have been increased 4KB each to accommodate the ECDSA code. REMOVED BUILD OPTIONS: * 'AUTH_MOD' Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
2015-05-19 11:54:12 +01:00
Introduce ARM SiP service This patch adds ARM SiP service for use by ARM standard platforms. This service is added to support the SMC interface for the Performance measurement framework(PMF). Change-Id: I26f5712f9ab54f5f721dd4781e35a16f40aacc44 Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2016-09-19 11:21:03 +01:00
ifeq (${ENABLE_PMF}, 1)
BL31_SOURCES += plat/arm/common/arm_sip_svc.c \
lib/pmf/pmf_smc.c
endif
TBB: switch to the new authentication framework This patch modifies the Trusted Board Boot implementation to use the new authentication framework, making use of the authentication module, the cryto module and the image parser module to authenticate the images in the Chain of Trust. A new function 'load_auth_image()' has been implemented. When TBB is enabled, this function will call the authentication module to authenticate parent images following the CoT up to the root of trust to finally load and authenticate the requested image. The platform is responsible for picking up the right makefiles to build the corresponding cryptographic and image parser libraries. ARM platforms use the mbedTLS based libraries. The platform may also specify what key algorithm should be used to sign the certificates. This is done by declaring the 'KEY_ALG' variable in the platform makefile. FVP and Juno use ECDSA keys. On ARM platforms, BL2 and BL1-RW regions have been increased 4KB each to accommodate the ECDSA code. REMOVED BUILD OPTIONS: * 'AUTH_MOD' Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
2015-05-19 11:54:12 +01:00
ifneq (${TRUSTED_BOARD_BOOT},0)
# By default, ARM platforms use RSA keys
KEY_ALG := rsa
# Include common TBB sources
AUTH_SOURCES := drivers/auth/auth_mod.c \
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
drivers/auth/crypto_mod.c \
drivers/auth/img_parser_mod.c \
drivers/auth/tbbr/tbbr_cot.c \
TBB: switch to the new authentication framework This patch modifies the Trusted Board Boot implementation to use the new authentication framework, making use of the authentication module, the cryto module and the image parser module to authenticate the images in the Chain of Trust. A new function 'load_auth_image()' has been implemented. When TBB is enabled, this function will call the authentication module to authenticate parent images following the CoT up to the root of trust to finally load and authenticate the requested image. The platform is responsible for picking up the right makefiles to build the corresponding cryptographic and image parser libraries. ARM platforms use the mbedTLS based libraries. The platform may also specify what key algorithm should be used to sign the certificates. This is done by declaring the 'KEY_ALG' variable in the platform makefile. FVP and Juno use ECDSA keys. On ARM platforms, BL2 and BL1-RW regions have been increased 4KB each to accommodate the ECDSA code. REMOVED BUILD OPTIONS: * 'AUTH_MOD' Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
2015-05-19 11:54:12 +01:00
FWU: Add Firmware Update support in BL1 for ARM platforms This patch adds Firmware Update support for ARM platforms. New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide platform specific Firmware update code. BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for authenticating NS_BL2U image(For both FVP and JUNO platform). Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
2015-10-11 14:14:55 +01:00
PLAT_INCLUDES += -Iinclude/bl1/tbbr
Fix the inconsistencies in bl1_tbbr_image_descs[] This patch fixes inconsistencies in bl1_tbbr_image_descs[] and miscellaneous fixes in Firmware Update code. Following are the changes: * As part of the original FWU changes, a `copied_size` field was added to `image_info_t`. This was a subtle binary compatibility break because it changed the size of the `bl31_params_t` struct, which could cause problems if somebody used different versions of BL2 or BL31, one with the old `image_info_t` and one with the new version. This patch put the `copied_size` within the `image_desc_t`. * EXECUTABLE flag is now stored in `ep_info.h.attr` in place of `image_info.h.attr`, associating it to an entrypoint. * The `image_info.image_base` is only relevant for secure images that are copied from non-secure memory into secure memory. This patch removes initializing `image_base` for non secure images in the bl1_tbbr_image_descs[]. * A new macro `SET_STATIC_PARAM_HEAD` is added for populating bl1_tbbr_image_descs[].ep_info/image_info.h members statically. The version, image_type and image attributes are now populated using this new macro. * Added PLAT_ARM_NVM_BASE and PLAT_ARM_NVM_SIZE to avoid direct usage of V2M_FLASH0_XXX in plat/arm/common/arm_bl1_fwu.c. * Refactoring of code/macros related to SECURE and EXECUTABLE flags. NOTE: PLATFORM PORTS THAT RELY ON THE SIZE OF `image_info_t` OR USE the "EXECUTABLE" BIT WITHIN `image_info_t.h.attr` OR USE THEIR OWN `image_desc_t` ARRAY IN BL1, MAY BE BROKEN BY THIS CHANGE. THIS IS CONSIDERED UNLIKELY. Change-Id: Id4e5989af7bf0ed263d19d3751939da1169b561d
2016-02-01 11:04:46 +00:00
BL1_SOURCES += ${AUTH_SOURCES} \
bl1/tbbr/tbbr_img_desc.c \
tbbr: Fix updating of Non-Trusted NV counter The previous code required that a certificate be signed with the ROT key before the platform's NV counter could be updated with the value in the certificate. This implies that the Non-Trusted NV counter was not being updated for Non-Trusted content certificates, as they cannot be signed with the ROT key in the TBBR CoT scheme. The code is reworked to only allow updating the platform's Trusted NV counter when a certificate protected by the Trusted NV counter is signed with the ROT key. Content certificates protected by the Non-Trusted NV counter are allowed to update the platform's Non-Trusted NV counter, assuming that the certificate value is higher than the platform's value. A new optional platform API has been introduced, named plat_set_nv_ctr2(). Platforms may choose to implement it and perform additional checks based on the authentication image descriptor before modifying the NV counters. A default weak implementation is available that just calls into plat_set_nv_ctr(). Fixes ARM-software/tf-issues#426 Change-Id: I4fc978fd28a3007bc0cef972ff1f69ad0413b79c Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2016-12-12 14:48:13 +00:00
plat/arm/common/arm_bl1_fwu.c \
plat/common/tbbr/plat_tbbr.c
FWU: Add Firmware Update support in BL1 for ARM platforms This patch adds Firmware Update support for ARM platforms. New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide platform specific Firmware update code. BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for authenticating NS_BL2U image(For both FVP and JUNO platform). Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
2015-10-11 14:14:55 +01:00
tbbr: Fix updating of Non-Trusted NV counter The previous code required that a certificate be signed with the ROT key before the platform's NV counter could be updated with the value in the certificate. This implies that the Non-Trusted NV counter was not being updated for Non-Trusted content certificates, as they cannot be signed with the ROT key in the TBBR CoT scheme. The code is reworked to only allow updating the platform's Trusted NV counter when a certificate protected by the Trusted NV counter is signed with the ROT key. Content certificates protected by the Non-Trusted NV counter are allowed to update the platform's Non-Trusted NV counter, assuming that the certificate value is higher than the platform's value. A new optional platform API has been introduced, named plat_set_nv_ctr2(). Platforms may choose to implement it and perform additional checks based on the authentication image descriptor before modifying the NV counters. A default weak implementation is available that just calls into plat_set_nv_ctr(). Fixes ARM-software/tf-issues#426 Change-Id: I4fc978fd28a3007bc0cef972ff1f69ad0413b79c Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2016-12-12 14:48:13 +00:00
BL2_SOURCES += ${AUTH_SOURCES} \
plat/common/tbbr/plat_tbbr.c
TBB: switch to the new authentication framework This patch modifies the Trusted Board Boot implementation to use the new authentication framework, making use of the authentication module, the cryto module and the image parser module to authenticate the images in the Chain of Trust. A new function 'load_auth_image()' has been implemented. When TBB is enabled, this function will call the authentication module to authenticate parent images following the CoT up to the root of trust to finally load and authenticate the requested image. The platform is responsible for picking up the right makefiles to build the corresponding cryptographic and image parser libraries. ARM platforms use the mbedTLS based libraries. The platform may also specify what key algorithm should be used to sign the certificates. This is done by declaring the 'KEY_ALG' variable in the platform makefile. FVP and Juno use ECDSA keys. On ARM platforms, BL2 and BL1-RW regions have been increased 4KB each to accommodate the ECDSA code. REMOVED BUILD OPTIONS: * 'AUTH_MOD' Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
2015-05-19 11:54:12 +01:00
Apply TBBR naming convention to the fip_create options The fip_create tool specifies images in the command line using the ARM TF naming convention (--bl2, --bl31, etc), while the cert_create tool uses the TBBR convention (--tb-fw, --soc-fw, etc). This double convention is confusing and should be aligned. This patch updates the fip_create command line options to follow the TBBR naming convention. Usage examples in the User Guide have been also updated. NOTE: users that build the FIP by calling the fip_create tool directly from the command line must update the command line options in their scripts. Users that build the FIP by invoking the main ARM TF Makefile should not notice any difference. Change-Id: I84d602630a2585e558d927b50dfde4dd2112496f
2016-01-05 11:55:36 +00:00
$(eval $(call FWU_FIP_ADD_IMG,NS_BL2U,--fwu))
FWU: Add support for `fwu_fip` target Firmware update feature needs a new FIP called `fwu_fip.bin` that includes Secure(SCP_BL2U, BL2U) and Normal world(NS_BL2U) images along with the FWU_CERT certificate in order for NS_BL1U to load the images and help the Firmware update process to complete. This patch adds the capability to support the new target `fwu_fip` which includes above mentioned FWU images in the make files. The new target of `fwu_fip` and its dependencies are included for compilation only when `TRUSTED_BOARD_BOOT` is defined. Change-Id: Ie780e3aac6cbd0edfaff3f9af96a2332bd69edbc
2015-10-12 12:33:47 +01:00
TBB: switch to the new authentication framework This patch modifies the Trusted Board Boot implementation to use the new authentication framework, making use of the authentication module, the cryto module and the image parser module to authenticate the images in the Chain of Trust. A new function 'load_auth_image()' has been implemented. When TBB is enabled, this function will call the authentication module to authenticate parent images following the CoT up to the root of trust to finally load and authenticate the requested image. The platform is responsible for picking up the right makefiles to build the corresponding cryptographic and image parser libraries. ARM platforms use the mbedTLS based libraries. The platform may also specify what key algorithm should be used to sign the certificates. This is done by declaring the 'KEY_ALG' variable in the platform makefile. FVP and Juno use ECDSA keys. On ARM platforms, BL2 and BL1-RW regions have been increased 4KB each to accommodate the ECDSA code. REMOVED BUILD OPTIONS: * 'AUTH_MOD' Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
2015-05-19 11:54:12 +01:00
MBEDTLS_KEY_ALG := ${KEY_ALG}
# We expect to locate the *.mk files under the directories specified below
CRYPTO_LIB_MK := drivers/auth/mbedtls/mbedtls_crypto.mk
IMG_PARSER_LIB_MK := drivers/auth/mbedtls/mbedtls_x509.mk
$(info Including ${CRYPTO_LIB_MK})
include ${CRYPTO_LIB_MK}
$(info Including ${IMG_PARSER_LIB_MK})
include ${IMG_PARSER_LIB_MK}
endif