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

129 lines
3.5 KiB
Makefile
Raw Normal View History

Juno: Implement initial platform port This patch adds the initial port of the ARM Trusted Firmware on the Juno development platform. This port does not support a BL3-2 image or any PSCI APIs apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno platform errata (Defect id 831273). Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
2014-07-17 16:06:39 +01:00
#
Juno: Add support for TrustZone Media Protection 1 (TZMP1) Add TZMP1 support on Juno and increase the BL2 size accordingly due to the extra data structures to describe the TZC regions and the additional code. Signed-off-by: Summer Qin <summer.qin@arm.com>
2018-03-02 07:51:14 +00:00
# Copyright (c) 2013-2018, ARM Limited and Contributors. All rights reserved.
Juno: Implement initial platform port This patch adds the initial port of the ARM Trusted Firmware on the Juno development platform. This port does not support a BL3-2 image or any PSCI APIs apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno platform errata (Defect id 831273). Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
2014-07-17 16:06:39 +01: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
Juno: Implement initial platform port This patch adds the initial port of the ARM Trusted Firmware on the Juno development platform. This port does not support a BL3-2 image or any PSCI APIs apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno platform errata (Defect id 831273). Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
2014-07-17 16:06:39 +01: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
JUNO_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
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
JUNO_INTERCONNECT_SOURCES := drivers/arm/cci/cci.c \
plat/arm/common/arm_cci.c
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
JUNO_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/juno/juno_security.c \
Juno: Introduce juno_getentropy(void *buf, size_t len) This function fills the buffer (first argument) with the specified number of bytes (second argument) from the trusted entropy source. This function will be used to initialize the stack protector canary. Change-Id: Iff15aaf4778c13fa883ecb5528fcf9b8479d4489 Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-02-27 12:21:43 +00:00
plat/arm/board/juno/juno_trng.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/common/arm_tzc400.c
Juno: Initialize stack protector canary from the trusted entropy source Change-Id: I7f3e4bfd46613c6311ba4015d56705414fd6feab Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-02-28 14:43:15 +00:00
ifneq (${ENABLE_STACK_PROTECTOR}, 0)
JUNO_SECURITY_SOURCES += plat/arm/board/juno/juno_stack_protector.c
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
juno: Revert FWU update detect mechanism The patch 7b56928 unified the FWU mechanism on FVP and Juno platforms due to issues with MCC firmware not preserving the NVFLAGS. With MCCv150 firmware, this issue is resolved. Also writing to the NOR flash while executing from the same flash in Bypass mode had some stability issues. Hence, since the MCC firmware issue is resolved, this patch reverts to the NVFLAGS mechanism to detect FWU. Also, with the introduction of SDS (Shared Data Structure) by the SCP, the reset syndrome needs to queried from the appropriate SDS field. Change-Id: If9c08f1afaaa4fcf197f3186887068103855f554 Signed-off-by: Sathees Balya <sathees.balya@arm.com> Signed-off-by: Soby Mathew <Soby.Mathew@arm.com>
2018-09-03 17:41:13 +01:00
# Select SCMI/SDS drivers instead of SCPI/BOM driver for communicating with the
# SCP during power management operations and for SCP RAM Firmware transfer.
CSS_USE_SCMI_SDS_DRIVER := 1
PLAT_INCLUDES := -Iplat/arm/board/juno/include \
-Iplat/arm/css/drivers/sds
Juno: Reserve some DDR-DRAM for secure use This patch configures the TrustZone Controller in Juno to split the 2GB DDR-DRAM memory at 0x80000000 into Secure and Non-Secure regions: - Secure DDR-DRAM: top 16 MB, except for the last 2 MB which are used by the SCP for DDR retraining - Non-Secure DDR-DRAM: remaining DRAM starting at base address Build option PLAT_TSP_LOCATION selects the location of the secure payload (BL3-2): - 'tsram' : Trusted SRAM (default option) - 'dram' : Secure region in the DDR-DRAM (set by the TrustZone controller) The MMU memory map has been updated to give BL2 permission to load BL3-2 into the DDR-DRAM secure region. Fixes ARM-software/tf-issues#233 Change-Id: I6843fc32ef90aadd3ea6ac4c7f314f8ecbd5d07b
2014-09-05 17:29:38 +01:00
Changes to support execution in AArch32 state for JUNO Following steps are required to boot JUNO in AArch32 state: 1> BL1, in AArch64 state, loads BL2. 2> BL2, in AArch64 state, initializes DDR. Loads SP_MIN & BL33 (AArch32 executable)images. Calls RUN_IMAGE SMC to go back to BL1. 3> BL1 writes AArch32 executable opcodes, to load and branch at the entrypoint address of SP_MIN, at HI-VECTOR address and then request for warm reset in AArch32 state using RMR_EL3. This patch makes following changes to facilitate above steps: * Added assembly function to carry out step 3 above. * Added region in TZC that enables Secure access to the HI-VECTOR(0xFFFF0000) address space. * AArch32 image descriptor is used, in BL2, to load SP_MIN and BL33 AArch32 executable images. A new flag `JUNO_AARCH32_EL3_RUNTIME` is introduced that controls above changes. By default this flag is disabled. NOTE: BL1 and BL2 are not supported in AArch32 state for JUNO. Change-Id: I091d56a0e6d36663e6d9d2bb53c92c672195d1ec Signed-off-by: Yatharth Kochar <yatharth.kochar@arm.com> Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2016-11-14 12:01:04 +00:00
PLAT_BL_COMMON_SOURCES := plat/arm/board/juno/${ARCH}/juno_helpers.S
Juno: Reserve some DDR-DRAM for secure use This patch configures the TrustZone Controller in Juno to split the 2GB DDR-DRAM memory at 0x80000000 into Secure and Non-Secure regions: - Secure DDR-DRAM: top 16 MB, except for the last 2 MB which are used by the SCP for DDR retraining - Non-Secure DDR-DRAM: remaining DRAM starting at base address Build option PLAT_TSP_LOCATION selects the location of the secure payload (BL3-2): - 'tsram' : Trusted SRAM (default option) - 'dram' : Secure region in the DDR-DRAM (set by the TrustZone controller) The MMU memory map has been updated to give BL2 permission to load BL3-2 into the DDR-DRAM secure region. Fixes ARM-software/tf-issues#233 Change-Id: I6843fc32ef90aadd3ea6ac4c7f314f8ecbd5d07b
2014-09-05 17:29:38 +01:00
Changes to support execution in AArch32 state for JUNO Following steps are required to boot JUNO in AArch32 state: 1> BL1, in AArch64 state, loads BL2. 2> BL2, in AArch64 state, initializes DDR. Loads SP_MIN & BL33 (AArch32 executable)images. Calls RUN_IMAGE SMC to go back to BL1. 3> BL1 writes AArch32 executable opcodes, to load and branch at the entrypoint address of SP_MIN, at HI-VECTOR address and then request for warm reset in AArch32 state using RMR_EL3. This patch makes following changes to facilitate above steps: * Added assembly function to carry out step 3 above. * Added region in TZC that enables Secure access to the HI-VECTOR(0xFFFF0000) address space. * AArch32 image descriptor is used, in BL2, to load SP_MIN and BL33 AArch32 executable images. A new flag `JUNO_AARCH32_EL3_RUNTIME` is introduced that controls above changes. By default this flag is disabled. NOTE: BL1 and BL2 are not supported in AArch32 state for JUNO. Change-Id: I091d56a0e6d36663e6d9d2bb53c92c672195d1ec Signed-off-by: Yatharth Kochar <yatharth.kochar@arm.com> Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2016-11-14 12:01:04 +00:00
# Flag to enable support for AArch32 state on JUNO
JUNO_AARCH32_EL3_RUNTIME := 0
$(eval $(call assert_boolean,JUNO_AARCH32_EL3_RUNTIME))
$(eval $(call add_define,JUNO_AARCH32_EL3_RUNTIME))
Juno: Add support for TrustZone Media Protection 1 (TZMP1) Add TZMP1 support on Juno and increase the BL2 size accordingly due to the extra data structures to describe the TZC regions and the additional code. Signed-off-by: Summer Qin <summer.qin@arm.com>
2018-03-02 07:51:14 +00:00
# Flag to enable support for TZMP1 on JUNO
JUNO_TZMP1 := 0
$(eval $(call assert_boolean,JUNO_TZMP1))
ifeq (${JUNO_TZMP1}, 1)
$(eval $(call add_define,JUNO_TZMP1))
endif
ARM platforms: Fixup AArch32 builds This patch fixes a couple of issues for AArch32 builds on ARM reference platforms : 1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and AArch32 build. Since BL31 is not present in AArch32 mode, this meant that the BL31 memory is empty when built for AArch32. Hence this patch allocates BL32 to the memory region occupied by BL31 for AArch32 builds. As a side-effect of this change, the ARM_TSP_RAM_LOCATION macro cannot be used to control the load address of BL32 in AArch32 mode which was never the intention of the macro anyway. 2. A static assert is added to sp_min linker script to check that the progbits are within the bounds expected when overlaid with other images. 3. Fix specifying `SPD` when building Juno for AArch32 mode. Due to the quirks involved when building Juno for AArch32 mode, the build option SPD needed to specifed. This patch corrects this and also updates the documentation in the user-guide. 4. Exclude BL31 from the build and FIP when building Juno for AArch32 mode. As a result the previous assumption that BL31 must be always present is removed and the certificates for BL31 is only generated if `NEED_BL31` is defined. Change-Id: I1c39bbc0abd2be8fbe9f2dea2e9cb4e3e3e436a8 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2017-11-14 14:10:10 +00:00
ifeq (${JUNO_AARCH32_EL3_RUNTIME}, 1)
# Include BL32 in FIP
NEED_BL32 := yes
# BL31 is not required
override BL31_SOURCES =
# The BL32 needs to be built separately invoking the AARCH32 compiler and
# be specifed via `BL32` build option.
ifneq (${ARCH}, aarch32)
override BL32_SOURCES =
endif
endif
Changes to support execution in AArch32 state for JUNO Following steps are required to boot JUNO in AArch32 state: 1> BL1, in AArch64 state, loads BL2. 2> BL2, in AArch64 state, initializes DDR. Loads SP_MIN & BL33 (AArch32 executable)images. Calls RUN_IMAGE SMC to go back to BL1. 3> BL1 writes AArch32 executable opcodes, to load and branch at the entrypoint address of SP_MIN, at HI-VECTOR address and then request for warm reset in AArch32 state using RMR_EL3. This patch makes following changes to facilitate above steps: * Added assembly function to carry out step 3 above. * Added region in TZC that enables Secure access to the HI-VECTOR(0xFFFF0000) address space. * AArch32 image descriptor is used, in BL2, to load SP_MIN and BL33 AArch32 executable images. A new flag `JUNO_AARCH32_EL3_RUNTIME` is introduced that controls above changes. By default this flag is disabled. NOTE: BL1 and BL2 are not supported in AArch32 state for JUNO. Change-Id: I091d56a0e6d36663e6d9d2bb53c92c672195d1ec Signed-off-by: Yatharth Kochar <yatharth.kochar@arm.com> Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2016-11-14 12:01:04 +00:00
ifeq (${ARCH},aarch64)
Migrate Juno port to use common code Major update to the Juno 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 move the ARM SoC specific security setup (i.e. NIC-400 and PCIe initialization) from BL1 to `plat_arm_security_setup()` in BL2, where the other security setup is done. Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
2015-03-19 19:22:44 +00:00
BL1_SOURCES += lib/cpus/aarch64/cortex_a53.S \
Add A72 support for Juno R2 Cortex-A72 library support is now compiled into the Juno platform port to go with the existing A53/A57 support. This enables a single set of Juno TF binaries to run on Juno R0, R1 and R2 boards. Change-Id: I4a601dc4f671e98bdb19d98bbb66f02f0d8b7fc7
2015-10-30 16:25:12 +00:00
lib/cpus/aarch64/cortex_a57.S \
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
lib/cpus/aarch64/cortex_a72.S \
juno: Revert FWU update detect mechanism The patch 7b56928 unified the FWU mechanism on FVP and Juno platforms due to issues with MCC firmware not preserving the NVFLAGS. With MCCv150 firmware, this issue is resolved. Also writing to the NOR flash while executing from the same flash in Bypass mode had some stability issues. Hence, since the MCC firmware issue is resolved, this patch reverts to the NVFLAGS mechanism to detect FWU. Also, with the introduction of SDS (Shared Data Structure) by the SCP, the reset syndrome needs to queried from the appropriate SDS field. Change-Id: If9c08f1afaaa4fcf197f3186887068103855f554 Signed-off-by: Sathees Balya <sathees.balya@arm.com> Signed-off-by: Soby Mathew <Soby.Mathew@arm.com>
2018-09-03 17:41:13 +01:00
plat/arm/board/juno/juno_err.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
plat/arm/board/juno/juno_bl1_setup.c \
Juno: Initialize stack protector canary from the trusted entropy source Change-Id: I7f3e4bfd46613c6311ba4015d56705414fd6feab Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-02-28 14:43:15 +00:00
${JUNO_INTERCONNECT_SOURCES} \
${JUNO_SECURITY_SOURCES}
Juno: Reserve some DDR-DRAM for secure use This patch configures the TrustZone Controller in Juno to split the 2GB DDR-DRAM memory at 0x80000000 into Secure and Non-Secure regions: - Secure DDR-DRAM: top 16 MB, except for the last 2 MB which are used by the SCP for DDR retraining - Non-Secure DDR-DRAM: remaining DRAM starting at base address Build option PLAT_TSP_LOCATION selects the location of the secure payload (BL3-2): - 'tsram' : Trusted SRAM (default option) - 'dram' : Secure region in the DDR-DRAM (set by the TrustZone controller) The MMU memory map has been updated to give BL2 permission to load BL3-2 into the DDR-DRAM secure region. Fixes ARM-software/tf-issues#233 Change-Id: I6843fc32ef90aadd3ea6ac4c7f314f8ecbd5d07b
2014-09-05 17:29:38 +01: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_SOURCES += lib/utils/mem_region.c \
juno: Revert FWU update detect mechanism The patch 7b56928 unified the FWU mechanism on FVP and Juno platforms due to issues with MCC firmware not preserving the NVFLAGS. With MCCv150 firmware, this issue is resolved. Also writing to the NOR flash while executing from the same flash in Bypass mode had some stability issues. Hence, since the MCC firmware issue is resolved, this patch reverts to the NVFLAGS mechanism to detect FWU. Also, with the introduction of SDS (Shared Data Structure) by the SCP, the reset syndrome needs to queried from the appropriate SDS field. Change-Id: If9c08f1afaaa4fcf197f3186887068103855f554 Signed-off-by: Sathees Balya <sathees.balya@arm.com> Signed-off-by: Soby Mathew <Soby.Mathew@arm.com>
2018-09-03 17:41:13 +01:00
plat/arm/board/juno/juno_err.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/board/juno/juno_bl2_setup.c \
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
${JUNO_SECURITY_SOURCES}
Juno: Reserve some DDR-DRAM for secure use This patch configures the TrustZone Controller in Juno to split the 2GB DDR-DRAM memory at 0x80000000 into Secure and Non-Secure regions: - Secure DDR-DRAM: top 16 MB, except for the last 2 MB which are used by the SCP for DDR retraining - Non-Secure DDR-DRAM: remaining DRAM starting at base address Build option PLAT_TSP_LOCATION selects the location of the secure payload (BL3-2): - 'tsram' : Trusted SRAM (default option) - 'dram' : Secure region in the DDR-DRAM (set by the TrustZone controller) The MMU memory map has been updated to give BL2 permission to load BL3-2 into the DDR-DRAM secure region. Fixes ARM-software/tf-issues#233 Change-Id: I6843fc32ef90aadd3ea6ac4c7f314f8ecbd5d07b
2014-09-05 17:29:38 +01: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
BL2U_SOURCES += ${JUNO_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
Migrate Juno port to use common code Major update to the Juno 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 move the ARM SoC specific security setup (i.e. NIC-400 and PCIe initialization) from BL1 to `plat_arm_security_setup()` in BL2, where the other security setup is done. Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
2015-03-19 19:22:44 +00:00
BL31_SOURCES += lib/cpus/aarch64/cortex_a53.S \
Support PSCI SYSTEM SUSPEND on Juno This patch adds the capability to power down at system power domain level on Juno via the PSCI SYSTEM SUSPEND API. The CSS power management helpers are modified to add support for power management operations at system power domain level. A new helper for populating `get_sys_suspend_power_state` handler in plat_psci_ops is defined. On entering the system suspend state, the SCP powers down the SYSTOP power domain on the SoC and puts the memory into retention mode. On wakeup from the power down, the system components on the CSS will be reinitialized by the platform layer and the PSCI client is responsible for restoring the context of these system components. According to PSCI Specification, interrupts targeted to cores in PSCI CPU SUSPEND should be able to resume it. On Juno, when the system power domain is suspended, the GIC is also powered down. The SCP resumes the final core to be suspend when an external wake-up event is received. But the other cores cannot be woken up by a targeted interrupt, because GIC doesn't forward these interrupts to the SCP. Due to this hardware limitation, we down-grade PSCI CPU SUSPEND requests targeted to the system power domain level to cluster power domain level in `juno_validate_power_state()` and the CSS default `plat_arm_psci_ops` is overridden in juno_pm.c. A system power domain resume helper `arm_system_pwr_domain_resume()` is defined for ARM standard platforms which resumes/re-initializes the system components on wakeup from system suspend. The security setup also needs to be done on resume from system suspend, which means `plat_arm_security_setup()` must now be included in the BL3-1 image in addition to previous BL images if system suspend need to be supported. Change-Id: Ie293f75f09bad24223af47ab6c6e1268f77bcc47
2015-10-12 17:32:29 +01:00
lib/cpus/aarch64/cortex_a57.S \
Add A72 support for Juno R2 Cortex-A72 library support is now compiled into the Juno platform port to go with the existing A53/A57 support. This enables a single set of Juno TF binaries to run on Juno R0, R1 and R2 boards. Change-Id: I4a601dc4f671e98bdb19d98bbb66f02f0d8b7fc7
2015-10-30 16:25:12 +00:00
lib/cpus/aarch64/cortex_a72.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
lib/utils/mem_region.c \
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
plat/arm/board/juno/juno_topology.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/board/common/drivers/norflash/norflash.c \
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
${JUNO_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
${JUNO_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
${JUNO_SECURITY_SOURCES}
juno: Revert FWU update detect mechanism The patch 7b56928 unified the FWU mechanism on FVP and Juno platforms due to issues with MCC firmware not preserving the NVFLAGS. With MCCv150 firmware, this issue is resolved. Also writing to the NOR flash while executing from the same flash in Bypass mode had some stability issues. Hence, since the MCC firmware issue is resolved, this patch reverts to the NVFLAGS mechanism to detect FWU. Also, with the introduction of SDS (Shared Data Structure) by the SCP, the reset syndrome needs to queried from the appropriate SDS field. Change-Id: If9c08f1afaaa4fcf197f3186887068103855f554 Signed-off-by: Sathees Balya <sathees.balya@arm.com> Signed-off-by: Soby Mathew <Soby.Mathew@arm.com>
2018-09-03 17:41:13 +01:00
ifeq (${CSS_USE_SCMI_SDS_DRIVER},1)
BL1_SOURCES += plat/arm/css/drivers/sds/sds.c
endif
Changes to support execution in AArch32 state for JUNO Following steps are required to boot JUNO in AArch32 state: 1> BL1, in AArch64 state, loads BL2. 2> BL2, in AArch64 state, initializes DDR. Loads SP_MIN & BL33 (AArch32 executable)images. Calls RUN_IMAGE SMC to go back to BL1. 3> BL1 writes AArch32 executable opcodes, to load and branch at the entrypoint address of SP_MIN, at HI-VECTOR address and then request for warm reset in AArch32 state using RMR_EL3. This patch makes following changes to facilitate above steps: * Added assembly function to carry out step 3 above. * Added region in TZC that enables Secure access to the HI-VECTOR(0xFFFF0000) address space. * AArch32 image descriptor is used, in BL2, to load SP_MIN and BL33 AArch32 executable images. A new flag `JUNO_AARCH32_EL3_RUNTIME` is introduced that controls above changes. By default this flag is disabled. NOTE: BL1 and BL2 are not supported in AArch32 state for JUNO. Change-Id: I091d56a0e6d36663e6d9d2bb53c92c672195d1ec Signed-off-by: Yatharth Kochar <yatharth.kochar@arm.com> Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2016-11-14 12:01:04 +00:00
endif
Juno: Reserve some DDR-DRAM for secure use This patch configures the TrustZone Controller in Juno to split the 2GB DDR-DRAM memory at 0x80000000 into Secure and Non-Secure regions: - Secure DDR-DRAM: top 16 MB, except for the last 2 MB which are used by the SCP for DDR retraining - Non-Secure DDR-DRAM: remaining DRAM starting at base address Build option PLAT_TSP_LOCATION selects the location of the secure payload (BL3-2): - 'tsram' : Trusted SRAM (default option) - 'dram' : Secure region in the DDR-DRAM (set by the TrustZone controller) The MMU memory map has been updated to give BL2 permission to load BL3-2 into the DDR-DRAM secure region. Fixes ARM-software/tf-issues#233 Change-Id: I6843fc32ef90aadd3ea6ac4c7f314f8ecbd5d07b
2014-09-05 17:29:38 +01:00
Juno: Disable 859971 and 859972 errata workarounds Earlier patches added errata workarounds 859972 for Cortex-A72, and 859972 for Cortex-A57 CPUs. Explicitly disable the workaround for Juno. Also reorganize errata workaround flags. No functional changes. Change-Id: I3fe3745de57d77e5bf52012826d3969fe5d4844e Signed-off-by: Eleanor Bonnici <Eleanor.bonnici@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-08-04 15:03:51 +01:00
# Errata workarounds for Cortex-A53:
ERRATA_A53_826319 := 1
Apply workarounds for A53 Cat A Errata 835769 and 843419 These errata are only applicable to AArch64 state. See the errata notice for more details: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.epm048406/index.html Introduce the build options ERRATA_A53_835769 and ERRATA_A53_843419. Enable both of them for Juno. Apply the 835769 workaround as following: * Compile with -mfix-cortex-a53-835769 * Link with --fix-cortex-a53-835769 Apply the 843419 workaround as following: * Link with --fix-cortex-a53-843419 The erratum 843419 workaround can lead the linker to create new sections suffixed with "*.stub*" and 4KB aligned. The erratum 835769 can lead the linker to create new "*.stub" sections with no particular alignment. Also add support for LDFLAGS_aarch32 and LDFLAGS_aarch64 in Makefile for architecture-specific linker options. Change-Id: Iab3337e338b7a0a16b0d102404d9db98c154f8f8 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2017-06-19 15:38:02 +01:00
ERRATA_A53_835769 := 1
Juno: Disable 859971 and 859972 errata workarounds Earlier patches added errata workarounds 859972 for Cortex-A72, and 859972 for Cortex-A57 CPUs. Explicitly disable the workaround for Juno. Also reorganize errata workaround flags. No functional changes. Change-Id: I3fe3745de57d77e5bf52012826d3969fe5d4844e Signed-off-by: Eleanor Bonnici <Eleanor.bonnici@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-08-04 15:03:51 +01:00
ERRATA_A53_836870 := 1
Apply workarounds for A53 Cat A Errata 835769 and 843419 These errata are only applicable to AArch64 state. See the errata notice for more details: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.epm048406/index.html Introduce the build options ERRATA_A53_835769 and ERRATA_A53_843419. Enable both of them for Juno. Apply the 835769 workaround as following: * Compile with -mfix-cortex-a53-835769 * Link with --fix-cortex-a53-835769 Apply the 843419 workaround as following: * Link with --fix-cortex-a53-843419 The erratum 843419 workaround can lead the linker to create new sections suffixed with "*.stub*" and 4KB aligned. The erratum 835769 can lead the linker to create new "*.stub" sections with no particular alignment. Also add support for LDFLAGS_aarch32 and LDFLAGS_aarch64 in Makefile for architecture-specific linker options. Change-Id: Iab3337e338b7a0a16b0d102404d9db98c154f8f8 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2017-06-19 15:38:02 +01:00
ERRATA_A53_843419 := 1
Add workaround for ARM Cortex-A53 erratum 855873 ARM erratum 855873 applies to all Cortex-A53 CPUs. The recommended workaround is to promote "data cache clean" instructions to "data cache clean and invalidate" instructions. For core revisions of r0p3 and later this can be done by setting a bit in the CPUACTLR_EL1 register, so that hardware takes care of the promotion. As CPUACTLR_EL1 is both IMPLEMENTATION DEFINED and can be trapped to EL3, we set the bit in firmware. Also we dump this register upon crashing to provide more debug information. Enable the workaround for the Juno boards. Change-Id: I3840114291958a406574ab6c49b01a9d9847fec8 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2016-10-06 16:54:53 +01:00
ERRATA_A53_855873 := 1
Juno: Disable 859971 and 859972 errata workarounds Earlier patches added errata workarounds 859972 for Cortex-A72, and 859972 for Cortex-A57 CPUs. Explicitly disable the workaround for Juno. Also reorganize errata workaround flags. No functional changes. Change-Id: I3fe3745de57d77e5bf52012826d3969fe5d4844e Signed-off-by: Eleanor Bonnici <Eleanor.bonnici@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-08-04 15:03:51 +01:00
# Errata workarounds for Cortex-A57:
Rationalise MMU and Page table related constants on ARM platforms `board_arm_def.h` contains multiple definitions of `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for memory usage depending upon the chosen build configuration. To ease maintenance of these constants, this patch replaces their multiple definitions with a single set of definitions that will work on all ARM platforms. Platforms can override the defaults with optimal values by enabling the `ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in the Juno ADP port. Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate future ARM platforms. Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
2016-01-20 15:57:35 +00:00
ERRATA_A57_806969 := 0
Apply workaround for errata 813419 of Cortex-A57 TLBI instructions for EL3 won't have the desired effect under specific circumstances in Cortex-A57 r0p0. The workaround is to execute DSB and TLBI twice each time. Even though this errata is only needed in r0p0, the current errata framework is not prepared to apply run-time workarounds. The current one is always applied if compiled in, regardless of the CPU or its revision. This errata has been enabled for Juno. The `DSB` instruction used when initializing the translation tables has been changed to `DSB ISH` as an optimization and to be consistent with the barriers used for the workaround. Change-Id: Ifc1d70b79cb5e0d87e90d88d376a59385667d338 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2017-02-24 11:39:22 +00:00
ERRATA_A57_813419 := 1
Rationalise MMU and Page table related constants on ARM platforms `board_arm_def.h` contains multiple definitions of `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for memory usage depending upon the chosen build configuration. To ease maintenance of these constants, this patch replaces their multiple definitions with a single set of definitions that will work on all ARM platforms. Platforms can override the defaults with optimal values by enabling the `ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in the Juno ADP port. Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate future ARM platforms. Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
2016-01-20 15:57:35 +00:00
ERRATA_A57_813420 := 1
Enable all A53 and A57 errata workarounds for Juno Juno platform Makefile is responsible for enabling all the relevant errata. As the Juno platform port does not know which revision of Juno the TF is compiled for, the revision of the cores are unknown and so all errata up to this date are needed on at least one revision of Juno. Change-Id: I38e1d6efc17e703f2bd55e0714f8d8fa4778f696 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2017-02-28 17:56:15 +00:00
ERRATA_A57_826974 := 1
ERRATA_A57_826977 := 1
ERRATA_A57_828024 := 1
ERRATA_A57_829520 := 1
ERRATA_A57_833471 := 1
Juno: Disable 859971 and 859972 errata workarounds Earlier patches added errata workarounds 859972 for Cortex-A72, and 859972 for Cortex-A57 CPUs. Explicitly disable the workaround for Juno. Also reorganize errata workaround flags. No functional changes. Change-Id: I3fe3745de57d77e5bf52012826d3969fe5d4844e Signed-off-by: Eleanor Bonnici <Eleanor.bonnici@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-08-04 15:03:51 +01:00
ERRATA_A57_859972 := 0
Enable all A53 and A57 errata workarounds for Juno Juno platform Makefile is responsible for enabling all the relevant errata. As the Juno platform port does not know which revision of Juno the TF is compiled for, the revision of the cores are unknown and so all errata up to this date are needed on at least one revision of Juno. Change-Id: I38e1d6efc17e703f2bd55e0714f8d8fa4778f696 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2017-02-28 17:56:15 +00:00
Juno: Disable 859971 and 859972 errata workarounds Earlier patches added errata workarounds 859972 for Cortex-A72, and 859972 for Cortex-A57 CPUs. Explicitly disable the workaround for Juno. Also reorganize errata workaround flags. No functional changes. Change-Id: I3fe3745de57d77e5bf52012826d3969fe5d4844e Signed-off-by: Eleanor Bonnici <Eleanor.bonnici@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-08-04 15:03:51 +01:00
# Errata workarounds for Cortex-A72:
ERRATA_A72_859971 := 0
Optimize Cortex-A57 cluster power down sequence on Juno This patch optimizes the Cortex-A57 cluster power down sequence by not flushing the Level1 data cache. The L1 data cache and the L2 unified cache are inclusive. A flush of the L2 by set/way flushes any dirty lines from the L1 as well. This is a known safe deviation from the Cortex-A57 TRM defined power down sequence. This optimization can be enabled by the platform through the 'SKIP_A57_L1_FLUSH_PWR_DWN' build flag. Each Cortex-A57 based platform must make its own decision on whether to use the optimization. This patch also renames the cpu-errata-workarounds.md to cpu-specific-build-macros.md as this facilitates documentation of both CPU Specific errata and CPU Specific Optimization build macros. Change-Id: I299b9fe79e9a7e08e8a0dffb7d345f9a00a71480
2014-09-22 14:13:34 +01:00
# Enable option to skip L1 data cache flush during the Cortex-A57 cluster
# power down sequence
SKIP_A57_L1_FLUSH_PWR_DWN := 1
Migrate Juno port to use common code Major update to the Juno 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 move the ARM SoC specific security setup (i.e. NIC-400 and PCIe initialization) from BL1 to `plat_arm_security_setup()` in BL2, where the other security setup is done. Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
2015-03-19 19:22:44 +00:00
Rationalise MMU and Page table related constants on ARM platforms `board_arm_def.h` contains multiple definitions of `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for memory usage depending upon the chosen build configuration. To ease maintenance of these constants, this patch replaces their multiple definitions with a single set of definitions that will work on all ARM platforms. Platforms can override the defaults with optimal values by enabling the `ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in the Juno ADP port. Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate future ARM platforms. Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
2016-01-20 15:57:35 +00:00
# Enable memory map related constants optimisation
ARM platforms: Define common image sizes Compile option `ARM_BOARD_OPTIMISE_MMAP` has been renamed to `ARM_BOARD_OPTIMISE_MEM` because it now applies not only to defines related to the translation tables but to the image size as well. The defines `PLAT_ARM_MAX_BL1_RW_SIZE`, `PLAT_ARM_MAX_BL2_SIZE` and `PLAT_ARM_MAX_BL31_SIZE` have been moved to the file board_arm_def.h. This way, ARM platforms no longer have to set their own values if `ARM_BOARD_OPTIMISE_MEM=0` and they can specify optimized values otherwise. The common sizes have been set to the highest values used for any of the current build configurations. This is needed because in some build configurations some images are running out of space. This way there is a common set of values known to work for all of them and it can be optimized for each particular platform if needed. The space reserved for BL2 when `TRUSTED_BOARD_BOOT=0` has been increased. This is needed because when memory optimisations are disabled the values for Juno of `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` are higher. If in this situation the code is compiled in debug mode and with "-O0", the code won't fit. Change-Id: I70a3d8d3a0b0cad1d6b602c01a7ea334776e718e
2016-07-25 12:04:31 +01:00
ARM_BOARD_OPTIMISE_MEM := 1
PSCI: Migrate ARM reference platforms to new platform API This patch migrates ARM reference platforms, Juno and FVP, to the new platform API mandated by the new PSCI power domain topology and composite power state frameworks. The platform specific makefiles now exports the build flag ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer. Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29
2015-07-01 16:16:20 +01:00
Do not enable SVE on pre-v8.2 platforms Pre-v8.2 platforms such as the Juno platform does not have the Scalable Vector Extensions implemented and so the build option ENABLE_SVE is set to zero. This has a minor performance improvement with no functional impact. Change-Id: Ib072735db7a0247406f8b60e325b7e28b1e04ad1 Signed-off-by: David Cunado <david.cunado@arm.com>
2017-10-31 23:19:21 +00:00
# Do not enable SVE
ENABLE_SVE_FOR_NS := 0
Migrate Juno port to use common code Major update to the Juno 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 move the ARM SoC specific security setup (i.e. NIC-400 and PCIe initialization) from BL1 to `plat_arm_security_setup()` in BL2, where the other security setup is done. Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
2015-03-19 19:22:44 +00:00
include plat/arm/board/common/board_css.mk
include plat/arm/common/arm_common.mk
include plat/arm/soc/common/soc_css.mk
include plat/arm/css/common/css_common.mk
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