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

303 lines
8.7 KiB
C
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
/*
plat/arm: Move dynamic xlat enable logic to makefile The PLAT_XLAT_TABLES_DYNAMIC build option, defined in platform_def.h in Arm platforms, is checked by several headers, affecting their behaviour. To avoid issues around the include ordering of the headers, the definition should be moved to the platform's makefile. Change-Id: I0e12365c8d66309122e8a20790e1641a4f480a10 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-01-23 16:23:07 +00:00
* Copyright (c) 2014-2019, 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
*/
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#ifndef PLATFORM_DEF_H
#define PLATFORM_DEF_H
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
Sanitise includes across codebase Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3a282 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca33988b9 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-12-14 00:18:21 +00:00
#include <drivers/arm/tzc400.h>
#if TRUSTED_BOARD_BOOT
#include <drivers/auth/mbedtls/mbedtls_config.h>
#endif
plat/arm: Sanitise includes Use full include paths like it is done for common includes. This cleanup was started in commit d40e0e08283a ("Sanitise includes across codebase"), but it only cleaned common files and drivers. This patch does the same to Arm platforms. Change-Id: If982e6450bbe84dceb56d464e282bcf5d6d9ab9b Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-01-25 14:30:04 +00:00
#include <plat/arm/board/common/board_css_def.h>
#include <plat/arm/board/common/v2m_def.h>
#include <plat/arm/common/arm_def.h>
#include <plat/arm/css/common/css_def.h>
#include <plat/arm/soc/common/soc_css_def.h>
Sanitise includes across codebase Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3a282 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca33988b9 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-12-14 00:18:21 +00:00
#include <plat/common/common_def.h>
Juno: Add support for Test Secure-EL1 Payload This patch implements the TSP on Juno. It executes from on-chip Trusted SRAM. Also, the other bootloader images (i.e. BL1 R/W, BL2 and BL3-1) have been moved around. The reason is, although there was enough space overall to store the TSP in SRAM, there was no contiguous free chunk of SRAM big enough to hold it. This patch keeps the overall memory layout (i.e. keeping BL1 R/W at the bottom, BL2 at the top and BL3-1 in between) but moves the base addresses of all the bootloader images in such a way that: - memory fragmentation is reduced enough to fit BL3-2 in; - new base addresses are suitable for release builds as well as debug ones; - each image has a few extra kilobytes for future growth. BL3-1 and BL3-2 are the images which received the biggest allocations since they will most probably grow the most. This patch also adds instruction synchronization barriers around the code which handles the timer interrupt in the TSP. This ensures that the interrupt is not acknowledged after or EOIed before it is deactivated at the peripheral. Change-Id: I1c5b51858700027ee283ac85d18e06863a27c72e
2014-07-17 09:56:29 +01:00
#include "../juno_def.h"
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
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
/* Required platform porting definitions */
CSS: Implement topology support for System power domain This patch implements the necessary topology changes for supporting system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform specific. In addition, the `arm_power_domain_tree_desc[]` and `arm_pm_idle_states[]` are modified to support the system power domain at level 2. With this patch, even though the power management operations involving the system power domain will not return any error, the platform layer will silently ignore any operations to the power domain. The actual power management support for the system power domain will be added later. Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
2015-05-08 10:18:59 +01:00
/* Juno supports system power domain */
#define PLAT_MAX_PWR_LVL ARM_PWR_LVL2
#define PLAT_NUM_PWR_DOMAINS (ARM_SYSTEM_COUNT + \
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
JUNO_CLUSTER_COUNT + \
CSS: Implement topology support for System power domain This patch implements the necessary topology changes for supporting system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform specific. In addition, the `arm_power_domain_tree_desc[]` and `arm_pm_idle_states[]` are modified to support the system power domain at level 2. With this patch, even though the power management operations involving the system power domain will not return any error, the platform layer will silently ignore any operations to the power domain. The actual power management support for the system power domain will be added later. Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
2015-05-08 10:18:59 +01:00
PLATFORM_CORE_COUNT)
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
#define PLATFORM_CORE_COUNT (JUNO_CLUSTER0_CORE_COUNT + \
JUNO_CLUSTER1_CORE_COUNT)
ARM plat changes to enable CryptoCell integration This patch makes the necessary changes to enable ARM platform to successfully integrate CryptoCell during Trusted Board Boot. The changes are as follows: * A new build option `ARM_CRYPTOCELL_INTEG` is introduced to select the CryptoCell crypto driver for Trusted Board boot. * The TrustZone filter settings for Non Secure DRAM is modified to allow CryptoCell to read this memory. This is required to authenticate BL33 which is loaded into the Non Secure DDR. * The CSS platforms are modified to use coherent stacks in BL1 and BL2 when CryptoCell crypto is selected. This is because CryptoCell makes use of DMA to transfer data and the CryptoCell SBROM library allocates buffers on the stack during signature/hash verification. Change-Id: I1e6f6dcd1899784f1edeabfa2a9f279bbfb90e31 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2017-05-10 11:50:30 +01:00
/* Cryptocell HW Base address */
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_CRYPTOCELL_BASE UL(0x60050000)
ARM plat changes to enable CryptoCell integration This patch makes the necessary changes to enable ARM platform to successfully integrate CryptoCell during Trusted Board Boot. The changes are as follows: * A new build option `ARM_CRYPTOCELL_INTEG` is introduced to select the CryptoCell crypto driver for Trusted Board boot. * The TrustZone filter settings for Non Secure DRAM is modified to allow CryptoCell to read this memory. This is required to authenticate BL33 which is loaded into the Non Secure DDR. * The CSS platforms are modified to use coherent stacks in BL1 and BL2 when CryptoCell crypto is selected. This is because CryptoCell makes use of DMA to transfer data and the CryptoCell SBROM library allocates buffers on the stack during signature/hash verification. Change-Id: I1e6f6dcd1899784f1edeabfa2a9f279bbfb90e31 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2017-05-10 11:50:30 +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
/*
CSS: Implement topology support for System power domain This patch implements the necessary topology changes for supporting system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform specific. In addition, the `arm_power_domain_tree_desc[]` and `arm_pm_idle_states[]` are modified to support the system power domain at level 2. With this patch, even though the power management operations involving the system power domain will not return any error, the platform layer will silently ignore any operations to the power domain. The actual power management support for the system power domain will be added later. Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
2015-05-08 10:18:59 +01:00
* Other platform porting definitions are provided by included headers
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
*/
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
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
/*
* Required ARM standard platform porting definitions
*/
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
#define PLAT_ARM_CLUSTER_COUNT JUNO_CLUSTER_COUNT
TBB: authenticate BL2 image and certificate This patch adds support to authenticate the BL2 content certificate and image using the authentication module in BL1. The FIP driver has been extended to include the BL2 certificate UUID. FVP and Juno ports include the BL2 certificate FIP file definition. Change-Id: I32680e9bd123c8db4a4193c14448c9b32b0e9325
2015-01-07 13:49:59 +00:00
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_ARM_TRUSTED_SRAM_SIZE UL(0x00040000) /* 256 KB */
plat/arm: Remove file arm_board_def.h This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-11 13:02:34 +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
/* Use the bypass address */
juno: Add romlib support This patch adds support to build a combined BL1 and ROMLIB binary file with the right page alignment in Juno. When USE_ROMLIB=1 is set for Juno, it generates the combined file bl1_romlib.bin which needs to be used instead of bl1.bin Change-Id: I407efbe48d3e522fa6ef855538a9587193cb1919 Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-11-02 14:56:06 +00:00
#define PLAT_ARM_TRUSTED_ROM_BASE (V2M_FLASH0_BASE + \
BL1_ROM_BYPASS_OFFSET)
Juno: Add support for image overlaying in Trusted SRAM This patch allows the BL3-1 NOBITS section to overlap the BL1 R/W section since the former will always be used after the latter. Similarly, the BL3-2 NOBITS section can overlay the BL2 image when BL3-2 is loaded in Trusted SRAM. Due to the current size of the images, there is no actual overlap. Nevertheless, this reorganization may help to optimise the Trusted SRAM usage when the images size grows. Note that because BL3-1 NOBITS section is allowed to overlap the BL1 R/W section, BL1 global variables will remain valid only until execution reaches the BL3-1 entry point during a cold boot. Documentation updated accordingly. Fixes ARM-software/tf-issues#254 Change-Id: Id538f4d1c7f1f7858108280fd7b97e138572b879
2014-11-07 09:44:58 +00:00
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define NSRAM_BASE UL(0x2e000000)
#define NSRAM_SIZE UL(0x00008000) /* 32KB */
css: Fix erroneous non-secure RAM base address/size for SGI-575 SGI-575's NSRAM is neither in the same place nor the same size as Juno's. Change-Id: Id6d692e9c7e9c1360014bb525eda966ebe29c823 Signed-off-by: Chris Kay <chris.kay@arm.com>
2018-05-10 14:27:45 +01:00
ARM platforms: Demonstrate mem_protect from el3_runtime Previously mem_protect used to be only supported from BL2. This is not helpful in the case when ARM TF-A BL2 is not used. This patch demonstrates mem_protect from el3_runtime firmware on ARM Platforms specifically when RESET_TO_BL31 or RESET_TO_SP_MIN flag is set as BL2 may be absent in these cases. The Non secure DRAM is dynamically mapped into EL3 mmap tables temporarily and then the protected regions are then cleared. This avoids the need to map the non secure DRAM permanently to BL31/sp_min. The stack size is also increased, because DYNAMIC_XLAT_TABLES require a bigger stack. Change-Id: Ia44c594192ed5c5adc596c0cff2c7cc18c001fde Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-01-05 16:00:05 +00:00
/* virtual address used by dynamic mem_protect for chunk_base */
plat/arm: Fix misra warnings in platform code Change-Id: Ica944acc474a099219d50b041cfaeabd4f3d362f Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-09-27 14:41:02 +01:00
#define PLAT_ARM_MEM_PROTEC_VA_FRAME UL(0xc0000000)
ARM platforms: Demonstrate mem_protect from el3_runtime Previously mem_protect used to be only supported from BL2. This is not helpful in the case when ARM TF-A BL2 is not used. This patch demonstrates mem_protect from el3_runtime firmware on ARM Platforms specifically when RESET_TO_BL31 or RESET_TO_SP_MIN flag is set as BL2 may be absent in these cases. The Non secure DRAM is dynamically mapped into EL3 mmap tables temporarily and then the protected regions are then cleared. This avoids the need to map the non secure DRAM permanently to BL31/sp_min. The stack size is also increased, because DYNAMIC_XLAT_TABLES require a bigger stack. Change-Id: Ia44c594192ed5c5adc596c0cff2c7cc18c001fde Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-01-05 16:00:05 +00:00
juno: Add romlib support This patch adds support to build a combined BL1 and ROMLIB binary file with the right page alignment in Juno. When USE_ROMLIB=1 is set for Juno, it generates the combined file bl1_romlib.bin which needs to be used instead of bl1.bin Change-Id: I407efbe48d3e522fa6ef855538a9587193cb1919 Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-11-02 14:56:06 +00:00
/*
* PLAT_ARM_MAX_ROMLIB_RW_SIZE is define to use a full page
*/
#if USE_ROMLIB
#define PLAT_ARM_MAX_ROMLIB_RW_SIZE UL(0x1000)
#define PLAT_ARM_MAX_ROMLIB_RO_SIZE UL(0xe000)
#else
#define PLAT_ARM_MAX_ROMLIB_RW_SIZE UL(0)
#define PLAT_ARM_MAX_ROMLIB_RO_SIZE UL(0)
#endif
Juno: Add support for image overlaying in Trusted SRAM This patch allows the BL3-1 NOBITS section to overlap the BL1 R/W section since the former will always be used after the latter. Similarly, the BL3-2 NOBITS section can overlay the BL2 image when BL3-2 is loaded in Trusted SRAM. Due to the current size of the images, there is no actual overlap. Nevertheless, this reorganization may help to optimise the Trusted SRAM usage when the images size grows. Note that because BL3-1 NOBITS section is allowed to overlap the BL1 R/W section, BL1 global variables will remain valid only until execution reaches the BL3-1 entry point during a cold boot. Documentation updated accordingly. Fixes ARM-software/tf-issues#254 Change-Id: Id538f4d1c7f1f7858108280fd7b97e138572b879
2014-11-07 09:44:58 +00: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
* Actual ROM size on Juno is 64 KB, but TBB currently requires at least 80 KB
* in debug mode. We can test TBB on Juno bypassing the ROM and using 128 KB of
* flash
Juno: Add support for image overlaying in Trusted SRAM This patch allows the BL3-1 NOBITS section to overlap the BL1 R/W section since the former will always be used after the latter. Similarly, the BL3-2 NOBITS section can overlay the BL2 image when BL3-2 is loaded in Trusted SRAM. Due to the current size of the images, there is no actual overlap. Nevertheless, this reorganization may help to optimise the Trusted SRAM usage when the images size grows. Note that because BL3-1 NOBITS section is allowed to overlap the BL1 R/W section, BL1 global variables will remain valid only until execution reaches the BL3-1 entry point during a cold boot. Documentation updated accordingly. Fixes ARM-software/tf-issues#254 Change-Id: Id538f4d1c7f1f7858108280fd7b97e138572b879
2014-11-07 09:44:58 +00:00
*/
Add librom support in FVP Change-Id: Idb9ba3864d6de3053260724f07172fd32c1523e0 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-05-23 09:27:06 +01:00
TBB: add PolarSSL based authentication module This patch implements an authentication module based on the PolarSSL library (v1.3.9) to verify the Chain of Trust when Trusted Boot is enabled. PolarSSL sources must be fetched separately. The POLARSSL_DIR build option may be used to indicate the path to the PolarSSL main directory (this directory must contain the 'include' and 'library' subdirectories). To be able to build PolarSSL sources as a part of the Trusted Firmware build process, the DISABLE_PEDANTIC flag in polarssl.mk will tell the build system to remove the -pedantic option from the CFLAGS. Inclusion of PolarSSL increases the memory requirements of the BL1 and BL2 images. The following are the changes made to the FVP and Juno platforms to cater for this when TRUSTED_BOARD_BOOT is defined: Changes on FVP: - BL1 and BL2 stacks have been increased to 4 KB - BL1(rw) section has been increased to 32 KB. - BL2 memory region has been increased to 112 KB Changes on Juno: - BL1 and BL2 stacks have been increased to 4 KB - BL1(rw) section has been increased to 32 KB. - Trusted ROM region in Flash has been increased to 128 KB. - BL2 memory region has been increased to 116 KB Change-Id: Ie87d80d43408eb6239c4acd0ec5ab2120e4e9e80
2015-01-13 12:21:04 +00:00
#if TRUSTED_BOARD_BOOT
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_ARM_TRUSTED_ROM_SIZE UL(0x00020000)
TBB: add PolarSSL based authentication module This patch implements an authentication module based on the PolarSSL library (v1.3.9) to verify the Chain of Trust when Trusted Boot is enabled. PolarSSL sources must be fetched separately. The POLARSSL_DIR build option may be used to indicate the path to the PolarSSL main directory (this directory must contain the 'include' and 'library' subdirectories). To be able to build PolarSSL sources as a part of the Trusted Firmware build process, the DISABLE_PEDANTIC flag in polarssl.mk will tell the build system to remove the -pedantic option from the CFLAGS. Inclusion of PolarSSL increases the memory requirements of the BL1 and BL2 images. The following are the changes made to the FVP and Juno platforms to cater for this when TRUSTED_BOARD_BOOT is defined: Changes on FVP: - BL1 and BL2 stacks have been increased to 4 KB - BL1(rw) section has been increased to 32 KB. - BL2 memory region has been increased to 112 KB Changes on Juno: - BL1 and BL2 stacks have been increased to 4 KB - BL1(rw) section has been increased to 32 KB. - Trusted ROM region in Flash has been increased to 128 KB. - BL2 memory region has been increased to 116 KB Change-Id: Ie87d80d43408eb6239c4acd0ec5ab2120e4e9e80
2015-01-13 12:21:04 +00:00
#else
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_ARM_TRUSTED_ROM_SIZE UL(0x00010000)
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
#endif /* TRUSTED_BOARD_BOOT */
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
/*
* PLAT_ARM_MMAP_ENTRIES depends on the number of entries in the
* plat_arm_mmap array defined for each BL stage.
*/
Use #ifdef for IMAGE_BL* instead of #if One nasty part of ATF is some of boolean macros are always defined as 1 or 0, and the rest of them are only defined under certain conditions. For the former group, "#if FOO" or "#if !FOO" must be used because "#ifdef FOO" is always true. (Options passed by $(call add_define,) are the cases.) For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because checking the value of an undefined macro is strange. Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like follows: $(eval IMAGE := IMAGE_BL$(call uppercase,$(3))) $(OBJ): $(2) @echo " CC $$<" $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@ This means, IMAGE_BL* is defined when building the corresponding image, but *undefined* for the other images. So, IMAGE_BL* belongs to the latter group where we should use #ifdef or #ifndef. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-12-25 14:36:24 +00:00
#ifdef IMAGE_BL1
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
# define PLAT_ARM_MMAP_ENTRIES 7
# define MAX_XLAT_TABLES 4
#endif
Use #ifdef for IMAGE_BL* instead of #if One nasty part of ATF is some of boolean macros are always defined as 1 or 0, and the rest of them are only defined under certain conditions. For the former group, "#if FOO" or "#if !FOO" must be used because "#ifdef FOO" is always true. (Options passed by $(call add_define,) are the cases.) For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because checking the value of an undefined macro is strange. Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like follows: $(eval IMAGE := IMAGE_BL$(call uppercase,$(3))) $(OBJ): $(2) @echo " CC $$<" $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@ This means, IMAGE_BL* is defined when building the corresponding image, but *undefined* for the other images. So, IMAGE_BL* belongs to the latter group where we should use #ifdef or #ifndef. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-12-25 14:36:24 +00:00
#ifdef IMAGE_BL2
Add Trusted OS extra image parsing support for ARM standard platforms Trusted OS may have extra images to be loaded. Load them one by one and do the parsing. In this patch, ARM TF need to load up to 3 images for optee os: header, pager and paged images. Header image is the info about optee os and images. Pager image include pager code and data. Paged image include the paging parts using virtual memory. Change-Id: Ia3bcfa6d8a3ed7850deb5729654daca7b00be394 Signed-off-by: Summer Qin <summer.qin@arm.com>
2017-04-24 16:49:28 +01:00
#ifdef SPD_opteed
mem_protect: Add DRAM2 to the list of mem protected ranges On ARM platforms, the maximum size of the address space is limited to 32-bits as defined in arm_def.h. In order to access DRAM2, which is defined beyond the 32-bit address space, the maximum address space is increased to 36-bits in AArch64. It is possible to increase the virtual space for AArch32, but it is more difficult and not supported for now. NOTE - the actual maximum memory address space is platform dependent and is checked at run-time by querying the PARange field in the ID_AA64MMFR0_EL1 register. Change-Id: I6cb05c78a63b1fed96db9a9773faca04a5b93d67 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2017-08-08 11:27:20 +01:00
# define PLAT_ARM_MMAP_ENTRIES 11
mem_protect: Add mem_protect support in Juno and FVP for DRAM1 mem_protect needs some kind of non-volatile memory because it has to remember its state across reset and power down events. The most suitable electronic part for this feature is a NVRAM which should be only accesible from the secure world. Juno and FVP lack such hardware and for this reason the MEM_PROTECT functionality is implemented with Flash EEPROM memory on both boards, even though this memory is accesible from the non-secure world. This is done only to show a full implementation of these PSCI features, but an actual system shouldn't use a non-secure NVRAM to implement it. The EL3 runtime software will write the mem_protect flag and BL2 will read and clear the memory ranges if enabled. It is done in BL2 because it reduces the time that TF needs access to the full non-secure memory. The memory layout of both boards is defined using macros which take different values in Juno and FVP platforms. Generic platform helpers are added that use the platform specific macros to generate a mem_region_t that is valid for the platform. Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2017-08-03 09:16:43 +01:00
# define MAX_XLAT_TABLES 5
Add Trusted OS extra image parsing support for ARM standard platforms Trusted OS may have extra images to be loaded. Load them one by one and do the parsing. In this patch, ARM TF need to load up to 3 images for optee os: header, pager and paged images. Header image is the info about optee os and images. Pager image include pager code and data. Paged image include the paging parts using virtual memory. Change-Id: Ia3bcfa6d8a3ed7850deb5729654daca7b00be394 Signed-off-by: Summer Qin <summer.qin@arm.com>
2017-04-24 16:49:28 +01:00
#else
mem_protect: Add DRAM2 to the list of mem protected ranges On ARM platforms, the maximum size of the address space is limited to 32-bits as defined in arm_def.h. In order to access DRAM2, which is defined beyond the 32-bit address space, the maximum address space is increased to 36-bits in AArch64. It is possible to increase the virtual space for AArch32, but it is more difficult and not supported for now. NOTE - the actual maximum memory address space is platform dependent and is checked at run-time by querying the PARange field in the ID_AA64MMFR0_EL1 register. Change-Id: I6cb05c78a63b1fed96db9a9773faca04a5b93d67 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2017-08-08 11:27:20 +01:00
# define PLAT_ARM_MMAP_ENTRIES 10
Add Trusted OS extra image parsing support for ARM standard platforms Trusted OS may have extra images to be loaded. Load them one by one and do the parsing. In this patch, ARM TF need to load up to 3 images for optee os: header, pager and paged images. Header image is the info about optee os and images. Pager image include pager code and data. Paged image include the paging parts using virtual memory. Change-Id: Ia3bcfa6d8a3ed7850deb5729654daca7b00be394 Signed-off-by: Summer Qin <summer.qin@arm.com>
2017-04-24 16:49:28 +01:00
# define MAX_XLAT_TABLES 4
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
#endif
Add Trusted OS extra image parsing support for ARM standard platforms Trusted OS may have extra images to be loaded. Load them one by one and do the parsing. In this patch, ARM TF need to load up to 3 images for optee os: header, pager and paged images. Header image is the info about optee os and images. Pager image include pager code and data. Paged image include the paging parts using virtual memory. Change-Id: Ia3bcfa6d8a3ed7850deb5729654daca7b00be394 Signed-off-by: Summer Qin <summer.qin@arm.com>
2017-04-24 16:49:28 +01:00
#endif
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
Use #ifdef for IMAGE_BL* instead of #if One nasty part of ATF is some of boolean macros are always defined as 1 or 0, and the rest of them are only defined under certain conditions. For the former group, "#if FOO" or "#if !FOO" must be used because "#ifdef FOO" is always true. (Options passed by $(call add_define,) are the cases.) For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because checking the value of an undefined macro is strange. Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like follows: $(eval IMAGE := IMAGE_BL$(call uppercase,$(3))) $(OBJ): $(2) @echo " CC $$<" $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@ This means, IMAGE_BL* is defined when building the corresponding image, but *undefined* for the other images. So, IMAGE_BL* belongs to the latter group where we should use #ifdef or #ifndef. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-12-25 14:36:24 +00:00
#ifdef IMAGE_BL2U
Rework page table setup for varying number of mem regions Change arm_setup_page_tables() to take a variable number of memory regions. Remove coherent memory region from BL1, BL2 and BL2U as their coherent memory region doesn't contain anything and therefore has a size of 0. Add check to ensure this doesn't change without us knowing. Change-Id: I790054e3b20b056dda1043a4a67bd7ac2d6a3bc0 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
2018-07-06 16:54:44 +01:00
# define PLAT_ARM_MMAP_ENTRIES 5
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
# define MAX_XLAT_TABLES 3
#endif
Use #ifdef for IMAGE_BL* instead of #if One nasty part of ATF is some of boolean macros are always defined as 1 or 0, and the rest of them are only defined under certain conditions. For the former group, "#if FOO" or "#if !FOO" must be used because "#ifdef FOO" is always true. (Options passed by $(call add_define,) are the cases.) For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because checking the value of an undefined macro is strange. Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like follows: $(eval IMAGE := IMAGE_BL$(call uppercase,$(3))) $(OBJ): $(2) @echo " CC $$<" $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@ This means, IMAGE_BL* is defined when building the corresponding image, but *undefined* for the other images. So, IMAGE_BL* belongs to the latter group where we should use #ifdef or #ifndef. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-12-25 14:36:24 +00:00
#ifdef IMAGE_BL31
mem_protect: Add DRAM2 to the list of mem protected ranges On ARM platforms, the maximum size of the address space is limited to 32-bits as defined in arm_def.h. In order to access DRAM2, which is defined beyond the 32-bit address space, the maximum address space is increased to 36-bits in AArch64. It is possible to increase the virtual space for AArch32, but it is more difficult and not supported for now. NOTE - the actual maximum memory address space is platform dependent and is checked at run-time by querying the PARange field in the ID_AA64MMFR0_EL1 register. Change-Id: I6cb05c78a63b1fed96db9a9773faca04a5b93d67 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2017-08-08 11:27:20 +01:00
# define PLAT_ARM_MMAP_ENTRIES 7
mem_protect: Add mem_protect support in Juno and FVP for DRAM1 mem_protect needs some kind of non-volatile memory because it has to remember its state across reset and power down events. The most suitable electronic part for this feature is a NVRAM which should be only accesible from the secure world. Juno and FVP lack such hardware and for this reason the MEM_PROTECT functionality is implemented with Flash EEPROM memory on both boards, even though this memory is accesible from the non-secure world. This is done only to show a full implementation of these PSCI features, but an actual system shouldn't use a non-secure NVRAM to implement it. The EL3 runtime software will write the mem_protect flag and BL2 will read and clear the memory ranges if enabled. It is done in BL2 because it reduces the time that TF needs access to the full non-secure memory. The memory layout of both boards is defined using macros which take different values in Juno and FVP platforms. Generic platform helpers are added that use the platform specific macros to generate a mem_region_t that is valid for the platform. Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2017-08-03 09:16:43 +01:00
# define MAX_XLAT_TABLES 3
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
#endif
Use #ifdef for IMAGE_BL* instead of #if One nasty part of ATF is some of boolean macros are always defined as 1 or 0, and the rest of them are only defined under certain conditions. For the former group, "#if FOO" or "#if !FOO" must be used because "#ifdef FOO" is always true. (Options passed by $(call add_define,) are the cases.) For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because checking the value of an undefined macro is strange. Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like follows: $(eval IMAGE := IMAGE_BL$(call uppercase,$(3))) $(OBJ): $(2) @echo " CC $$<" $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@ This means, IMAGE_BL* is defined when building the corresponding image, but *undefined* for the other images. So, IMAGE_BL* belongs to the latter group where we should use #ifdef or #ifndef. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-12-25 14:36:24 +00:00
#ifdef IMAGE_BL32
ARM platforms: Demonstrate mem_protect from el3_runtime Previously mem_protect used to be only supported from BL2. This is not helpful in the case when ARM TF-A BL2 is not used. This patch demonstrates mem_protect from el3_runtime firmware on ARM Platforms specifically when RESET_TO_BL31 or RESET_TO_SP_MIN flag is set as BL2 may be absent in these cases. The Non secure DRAM is dynamically mapped into EL3 mmap tables temporarily and then the protected regions are then cleared. This avoids the need to map the non secure DRAM permanently to BL31/sp_min. The stack size is also increased, because DYNAMIC_XLAT_TABLES require a bigger stack. Change-Id: Ia44c594192ed5c5adc596c0cff2c7cc18c001fde Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-01-05 16:00:05 +00:00
# define PLAT_ARM_MMAP_ENTRIES 6
AArch32: Add SP_MIN support for JUNO This patch adds support for SP_MIN on JUNO platform. The changes include addition of AArch32 assembly files, JUNO specific SP_MIN make file and miscellaneous changes in ARM platform files to enable support for SP_MIN. Change-Id: Id1303f422fc9b98b9362c757b1a4225a16fffc0b Signed-off-by: Yatharth Kochar <yatharth.kochar@arm.com> Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2016-11-14 12:00:41 +00:00
# define MAX_XLAT_TABLES 4
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
#endif
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
/*
* PLAT_ARM_MAX_BL1_RW_SIZE is calculated using the current BL1 RW debug size
* plus a little space for growth.
*/
#if TRUSTED_BOARD_BOOT
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLAT_ARM_MAX_BL1_RW_SIZE UL(0xB000)
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
#else
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLAT_ARM_MAX_BL1_RW_SIZE UL(0x6000)
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
#endif
/*
* PLAT_ARM_MAX_BL2_SIZE is calculated using the current BL2 debug size plus a
* little space for growth.
*/
#if TRUSTED_BOARD_BOOT
plat/arm: enlarge the BL2 size on Arm platforms when TBB is enabled For Trusted Board Boot, BL2 needs more space to support the ECDSA and ECDSA+RSA algorithms. Change-Id: Ie7eda9a1315ce836dbc6d18d6588f8d17891a92d Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
2017-10-13 02:23:42 +01:00
#if TF_MBEDTLS_KEY_ALG_ID == TF_MBEDTLS_RSA_AND_ECDSA
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLAT_ARM_MAX_BL2_SIZE UL(0x1F000)
Juno: Increase bl2 max size to fix build when SPD=opteed Building TBBR(SPD=opteed) and non-TBBR TF-A images is breaking for Juno for different configurations listed below: * Overflow error of 4096 bytes for rsa algorithm. * Overflow error of 8192 bytes for ecdsa algorithm. * Overflow error of 4096 bytes for rsa+ecdsa algorithm. * Overflow error of 4096 bytes for non-TBBR case. So this patch increments macro PLAT_ARM_MAX_BL2_SIZE for all the above cases accordingly. Change-Id: I75ec6c0a718181d34553fe55437f0496f467683f Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
2018-03-23 06:26:23 +00:00
#elif TF_MBEDTLS_KEY_ALG_ID == TF_MBEDTLS_ECDSA
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLAT_ARM_MAX_BL2_SIZE UL(0x1D000)
plat/arm: enlarge the BL2 size on Arm platforms when TBB is enabled For Trusted Board Boot, BL2 needs more space to support the ECDSA and ECDSA+RSA algorithms. Change-Id: Ie7eda9a1315ce836dbc6d18d6588f8d17891a92d Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
2017-10-13 02:23:42 +01:00
#else
plat/arm: Save BL2 descriptors to reserved memory. On ARM platforms, the BL2 memory can be overlaid by BL31/BL32. The memory descriptors describing the list of executable images are created in BL2 R/W memory, which could be possibly corrupted later on by BL31/BL32 due to overlay. This patch creates a reserved location in SRAM for these descriptors and are copied over by BL2 before handing over to next BL image. Also this patch increases the PLAT_ARM_MAX_BL2_SIZE for juno when TBBR is enabled. Fixes ARM-Software/tf-issues#626 Change-Id: I755735706fa702024b4032f51ed4895b3687377f Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-11-15 14:22:30 +00:00
# define PLAT_ARM_MAX_BL2_SIZE UL(0x1D000)
plat/arm: enlarge the BL2 size on Arm platforms when TBB is enabled For Trusted Board Boot, BL2 needs more space to support the ECDSA and ECDSA+RSA algorithms. Change-Id: Ie7eda9a1315ce836dbc6d18d6588f8d17891a92d Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
2017-10-13 02:23:42 +01:00
#endif
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
#else
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLAT_ARM_MAX_BL2_SIZE UL(0xF000)
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
#endif
/*
ARM platforms: Move BL31 below BL2 to enable BL2 overlay The patch changes the layout of BL images in memory to enable more efficient use of available space. Previously BL31 was loaded with the expectation that BL2 memory would be reclaimed by BL32 loaded in SRAM. But with increasing memory requirements in the firmware, we can no longer fit BL32 in SRAM anymore which means the BL2 memory is not reclaimed by any runtime image. Positioning BL2 below BL1-RW and above BL31 means that the BL31 NOBITS can be overlaid on BL2 and BL1-RW. This patch also propogates the same memory layout to BL32 for AArch32 mode. The reset addresses for the following configurations are also changed : * When RESET_TO_SP_MIN=1 for BL32 in AArch32 mode * When BL2_AT_EL3=1 for BL2 The restriction on BL31 to be only in DRAM when SPM is enabled is now removed with this change. The update to the firmware design guide for the BL memory layout is done in the following patch. Change-Id: Icca438e257abe3e4f5a8215f945b9c3f9fbf29c9 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-06-01 16:53:38 +01:00
* Since BL31 NOBITS overlays BL2 and BL1-RW, PLAT_ARM_MAX_BL31_SIZE is
* calculated using the current BL31 PROGBITS debug size plus the sizes of
* BL2 and BL1-RW. SCP_BL2 image is loaded into the space BL31 -> BL2_BASE.
* Hence the BL31 PROGBITS size should be >= PLAT_CSS_MAX_SCP_BL2_SIZE.
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
*/
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_ARM_MAX_BL31_SIZE UL(0x3E000)
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 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
#if JUNO_AARCH32_EL3_RUNTIME
/*
ARM platforms: Move BL31 below BL2 to enable BL2 overlay The patch changes the layout of BL images in memory to enable more efficient use of available space. Previously BL31 was loaded with the expectation that BL2 memory would be reclaimed by BL32 loaded in SRAM. But with increasing memory requirements in the firmware, we can no longer fit BL32 in SRAM anymore which means the BL2 memory is not reclaimed by any runtime image. Positioning BL2 below BL1-RW and above BL31 means that the BL31 NOBITS can be overlaid on BL2 and BL1-RW. This patch also propogates the same memory layout to BL32 for AArch32 mode. The reset addresses for the following configurations are also changed : * When RESET_TO_SP_MIN=1 for BL32 in AArch32 mode * When BL2_AT_EL3=1 for BL2 The restriction on BL31 to be only in DRAM when SPM is enabled is now removed with this change. The update to the firmware design guide for the BL memory layout is done in the following patch. Change-Id: Icca438e257abe3e4f5a8215f945b9c3f9fbf29c9 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-06-01 16:53:38 +01:00
* Since BL32 NOBITS overlays BL2 and BL1-RW, PLAT_ARM_MAX_BL32_SIZE is
* calculated using the current BL32 PROGBITS debug size plus the sizes of
* BL2 and BL1-RW. SCP_BL2 image is loaded into the space BL32 -> BL2_BASE.
* Hence the BL32 PROGBITS size should be >= PLAT_CSS_MAX_SCP_BL2_SIZE.
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
*/
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_ARM_MAX_BL32_SIZE UL(0x3E000)
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
#endif
plat/arm: Remove file arm_board_def.h This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-11 13:02:34 +01:00
/*
* Size of cacheable stacks
*/
#if defined(IMAGE_BL1)
# if TRUSTED_BOARD_BOOT
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLATFORM_STACK_SIZE UL(0x1000)
plat/arm: Remove file arm_board_def.h This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-11 13:02:34 +01:00
# else
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLATFORM_STACK_SIZE UL(0x440)
plat/arm: Remove file arm_board_def.h This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-11 13:02:34 +01:00
# endif
#elif defined(IMAGE_BL2)
# if TRUSTED_BOARD_BOOT
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLATFORM_STACK_SIZE UL(0x1000)
plat/arm: Remove file arm_board_def.h This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-11 13:02:34 +01:00
# else
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLATFORM_STACK_SIZE UL(0x400)
plat/arm: Remove file arm_board_def.h This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-11 13:02:34 +01:00
# endif
#elif defined(IMAGE_BL2U)
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLATFORM_STACK_SIZE UL(0x400)
plat/arm: Remove file arm_board_def.h This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-11 13:02:34 +01:00
#elif defined(IMAGE_BL31)
# if PLAT_XLAT_TABLES_DYNAMIC
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLATFORM_STACK_SIZE UL(0x800)
plat/arm: Remove file arm_board_def.h This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-11 13:02:34 +01:00
# else
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLATFORM_STACK_SIZE UL(0x400)
plat/arm: Remove file arm_board_def.h This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-11 13:02:34 +01:00
# endif
#elif defined(IMAGE_BL32)
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
# define PLATFORM_STACK_SIZE UL(0x440)
plat/arm: Remove file arm_board_def.h This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-11 13:02:34 +01:00
#endif
Juno: Define PLAT_LOG_LEVEL_ASSERT to LOG_LEVEL_INFO This patch fixes the PLAT_LOG_LEVEL_ASSERT to 40 which corresponds to LOG_LEVEL_INFO. Having this level of log for assertions means that the `assert()` will not generate the strings implied in the expression taken as parameter. This allows to save some memory when Juno is built for LOG_LEVEL = LOG_LEVEL_VERBOSE and DEBUG = 1. Fixes ARM-software/tf-issues#511 Change-Id: Id84a40f803ab07a5a8f6e587167af96694a07d04 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2017-08-22 14:06:19 +01:00
/*
* Since free SRAM space is scant, enable the ASSERTION message size
* optimization by fixing the PLAT_LOG_LEVEL_ASSERT to LOG_LEVEL_INFO (40).
*/
#define PLAT_LOG_LEVEL_ASSERT 40
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
/* CCI related constants */
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_ARM_CCI_BASE UL(0x2c090000)
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
#define PLAT_ARM_CCI_CLUSTER0_SL_IFACE_IX 4
#define PLAT_ARM_CCI_CLUSTER1_SL_IFACE_IX 3
Re-factor definition of some macros on ARM platforms This patch moves the definition of some macros used only on ARM platforms from common headers to platform specific headers. It also forces all ARM standard platforms to have distinct definitions (even if they are usually the same). 1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been moved from `css_def.h` to `platform_def.h`. 2. `MHU_BASE` used in CSS platforms is moved from common css_def.h to platform specific header `platform_def.h` on Juno and renamed as `PLAT_ARM_MHU_BASE`. 3. To cater for different sizes of BL images, new macros like `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All ARM platforms need to define them for each image. Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
2016-01-21 14:08:15 +00:00
/* System timer related constants */
plat/arm: Fix MISRA defects in common code Change-Id: I2419416fadfcdf64da8b7690a348007591c4edf3 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-11-06 13:14:21 +00:00
#define PLAT_ARM_NSTIMER_FRAME_ID U(1)
Re-factor definition of some macros on ARM platforms This patch moves the definition of some macros used only on ARM platforms from common headers to platform specific headers. It also forces all ARM standard platforms to have distinct definitions (even if they are usually the same). 1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been moved from `css_def.h` to `platform_def.h`. 2. `MHU_BASE` used in CSS platforms is moved from common css_def.h to platform specific header `platform_def.h` on Juno and renamed as `PLAT_ARM_MHU_BASE`. 3. To cater for different sizes of BL images, new macros like `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All ARM platforms need to define them for each image. Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
2016-01-21 14:08:15 +00: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
/* TZC related constants */
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_ARM_TZC_BASE UL(0x2a4a0000)
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
#define PLAT_ARM_TZC_NS_DEV_ACCESS ( \
TZC_REGION_ACCESS_RDWR(TZC400_NSAID_CCI400) | \
TZC_REGION_ACCESS_RDWR(TZC400_NSAID_PCIE) | \
TZC_REGION_ACCESS_RDWR(TZC400_NSAID_HDLCD0) | \
TZC_REGION_ACCESS_RDWR(TZC400_NSAID_HDLCD1) | \
TZC_REGION_ACCESS_RDWR(TZC400_NSAID_USB) | \
TZC_REGION_ACCESS_RDWR(TZC400_NSAID_DMA330) | \
TZC_REGION_ACCESS_RDWR(TZC400_NSAID_THINLINKS) | \
TZC_REGION_ACCESS_RDWR(TZC400_NSAID_AP) | \
TZC_REGION_ACCESS_RDWR(TZC400_NSAID_GPU) | \
TZC_REGION_ACCESS_RDWR(TZC400_NSAID_CORESIGHT))
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 image overlaying in Trusted SRAM This patch allows the BL3-1 NOBITS section to overlap the BL1 R/W section since the former will always be used after the latter. Similarly, the BL3-2 NOBITS section can overlay the BL2 image when BL3-2 is loaded in Trusted SRAM. Due to the current size of the images, there is no actual overlap. Nevertheless, this reorganization may help to optimise the Trusted SRAM usage when the images size grows. Note that because BL3-1 NOBITS section is allowed to overlap the BL1 R/W section, BL1 global variables will remain valid only until execution reaches the BL3-1 entry point during a cold boot. Documentation updated accordingly. Fixes ARM-software/tf-issues#254 Change-Id: Id538f4d1c7f1f7858108280fd7b97e138572b879
2014-11-07 09:44:58 +00: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
* Required ARM CSS based platform porting definitions
Juno: Add support for image overlaying in Trusted SRAM This patch allows the BL3-1 NOBITS section to overlap the BL1 R/W section since the former will always be used after the latter. Similarly, the BL3-2 NOBITS section can overlay the BL2 image when BL3-2 is loaded in Trusted SRAM. Due to the current size of the images, there is no actual overlap. Nevertheless, this reorganization may help to optimise the Trusted SRAM usage when the images size grows. Note that because BL3-1 NOBITS section is allowed to overlap the BL1 R/W section, BL1 global variables will remain valid only until execution reaches the BL3-1 entry point during a cold boot. Documentation updated accordingly. Fixes ARM-software/tf-issues#254 Change-Id: Id538f4d1c7f1f7858108280fd7b97e138572b879
2014-11-07 09:44:58 +00: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
/* GIC related constants (no GICR in GIC-400) */
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_ARM_GICD_BASE UL(0x2c010000)
#define PLAT_ARM_GICC_BASE UL(0x2c02f000)
#define PLAT_ARM_GICH_BASE UL(0x2c04f000)
#define PLAT_ARM_GICV_BASE UL(0x2c06f000)
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
Re-factor definition of some macros on ARM platforms This patch moves the definition of some macros used only on ARM platforms from common headers to platform specific headers. It also forces all ARM standard platforms to have distinct definitions (even if they are usually the same). 1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been moved from `css_def.h` to `platform_def.h`. 2. `MHU_BASE` used in CSS platforms is moved from common css_def.h to platform specific header `platform_def.h` on Juno and renamed as `PLAT_ARM_MHU_BASE`. 3. To cater for different sizes of BL images, new macros like `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All ARM platforms need to define them for each image. Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
2016-01-21 14:08:15 +00:00
/* MHU related constants */
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_CSS_MHU_BASE UL(0x2b1f0000)
plat/arm: mhu: make mhu driver generic MHU doorbell driver requires arm platform specific macro "PLAT_CSS_MHU_BASE". Rename it to "PLAT_MHUV2_BASE", so that platforms other than arm can use generic MHU doorbell driver. Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
2019-03-07 02:23:42 +00:00
#define PLAT_MHUV2_BASE PLAT_CSS_MHU_BASE
Re-factor definition of some macros on ARM platforms This patch moves the definition of some macros used only on ARM platforms from common headers to platform specific headers. It also forces all ARM standard platforms to have distinct definitions (even if they are usually the same). 1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been moved from `css_def.h` to `platform_def.h`. 2. `MHU_BASE` used in CSS platforms is moved from common css_def.h to platform specific header `platform_def.h` on Juno and renamed as `PLAT_ARM_MHU_BASE`. 3. To cater for different sizes of BL images, new macros like `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All ARM platforms need to define them for each image. Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
2016-01-21 14:08:15 +00:00
Support for varying BOM/SCPI protocol base addresses in ARM platforms Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To cater for future ARM platforms this is made platform specific. Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made platform specific. Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
2016-02-08 16:29:30 +00:00
/*
* Base address of the first memory region used for communication between AP
* and SCP. Used by the BOM and SCPI protocols.
CSS: Changes for SDS framework This patch does the required changes to enable CSS platforms to build and use the SDS framework. Since SDS is always coupled with SCMI protocol, the preexisting SCMI build flag is now renamed to `CSS_USE_SCMI_SDS_DRIVER` which will enable both SCMI and SDS on CSS platforms. Also some of the workarounds applied for SCMI are now removed with SDS in place. Change-Id: I94e8b93f05e3fe95e475c5501c25bec052588a9c Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2017-06-12 12:37:10 +01:00
*/
#if !CSS_USE_SCMI_SDS_DRIVER
/*
Support for varying BOM/SCPI protocol base addresses in ARM platforms Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To cater for future ARM platforms this is made platform specific. Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made platform specific. Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
2016-02-08 16:29:30 +00:00
* Note that this is located at the same address as SCP_BOOT_CFG_ADDR, which
* means the SCP/AP configuration data gets overwritten when the AP initiates
* communication with the SCP. The configuration data is expected to be a
* 32-bit word on all CSS platforms. On Juno, part of this configuration is
* which CPU is the primary, according to the shift and mask definitions below.
*/
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_CSS_SCP_COM_SHARED_MEM_BASE (ARM_TRUSTED_SRAM_BASE + UL(0x80))
Support for varying BOM/SCPI protocol base addresses in ARM platforms Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To cater for future ARM platforms this is made platform specific. Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made platform specific. Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
2016-02-08 16:29:30 +00:00
#define PLAT_CSS_PRIMARY_CPU_SHIFT 8
#define PLAT_CSS_PRIMARY_CPU_BIT_WIDTH 4
CSS: Changes for SDS framework This patch does the required changes to enable CSS platforms to build and use the SDS framework. Since SDS is always coupled with SCMI protocol, the preexisting SCMI build flag is now renamed to `CSS_USE_SCMI_SDS_DRIVER` which will enable both SCMI and SDS on CSS platforms. Also some of the workarounds applied for SCMI are now removed with SDS in place. Change-Id: I94e8b93f05e3fe95e475c5501c25bec052588a9c Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2017-06-12 12:37:10 +01:00
#endif
Support for varying BOM/SCPI protocol base addresses in ARM platforms Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To cater for future ARM platforms this is made platform specific. Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made platform specific. Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
2016-02-08 16:29:30 +00:00
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
/*
* PLAT_CSS_MAX_SCP_BL2_SIZE is calculated using the current
* SCP_BL2 size plus a little space for growth.
*/
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_CSS_MAX_SCP_BL2_SIZE UL(0x14000)
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
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
/*
* PLAT_CSS_MAX_SCP_BL2U_SIZE is calculated using the current
* SCP_BL2U size plus a little space for growth.
*/
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_CSS_MAX_SCP_BL2U_SIZE UL(0x14000)
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
ARM platforms: Migrate to using interrupt properties An earlier patch added provision for the platform to provide secure interrupt properties. ARM platforms already has a list of interrupts that fall into different secure groups. This patch defines macros that enumerate interrupt properties in the same fashion, and points the driver driver data to a list of interrupt properties rather than list of secure interrupts on ARM platforms. The deprecated interrupt list definitions are however retained to support legacy builds. Configuration applied to individual interrupts remain unchanged, so no runtime behaviour change expected. NOTE: Platforms that use the arm/common function plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided INTR_PROP_DESC macro. Change-Id: I24d643b83e3333753a3ba97d4b6fb71e16bb0952 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-09-22 08:59:59 +01:00
#define PLAT_ARM_G1S_IRQ_PROPS(grp) \
CSS_G1S_IRQ_PROPS(grp), \
ARM_G1S_IRQ_PROPS(grp), \
INTR_PROP_DESC(JUNO_IRQ_DMA_SMMU, GIC_HIGHEST_SEC_PRIORITY, \
plat/arm: Fix misra warnings in platform code Change-Id: Ica944acc474a099219d50b041cfaeabd4f3d362f Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-09-27 14:41:02 +01:00
(grp), GIC_INTR_CFG_LEVEL), \
ARM platforms: Migrate to using interrupt properties An earlier patch added provision for the platform to provide secure interrupt properties. ARM platforms already has a list of interrupts that fall into different secure groups. This patch defines macros that enumerate interrupt properties in the same fashion, and points the driver driver data to a list of interrupt properties rather than list of secure interrupts on ARM platforms. The deprecated interrupt list definitions are however retained to support legacy builds. Configuration applied to individual interrupts remain unchanged, so no runtime behaviour change expected. NOTE: Platforms that use the arm/common function plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided INTR_PROP_DESC macro. Change-Id: I24d643b83e3333753a3ba97d4b6fb71e16bb0952 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-09-22 08:59:59 +01:00
INTR_PROP_DESC(JUNO_IRQ_HDLCD0_SMMU, GIC_HIGHEST_SEC_PRIORITY, \
plat/arm: Fix misra warnings in platform code Change-Id: Ica944acc474a099219d50b041cfaeabd4f3d362f Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-09-27 14:41:02 +01:00
(grp), GIC_INTR_CFG_LEVEL), \
ARM platforms: Migrate to using interrupt properties An earlier patch added provision for the platform to provide secure interrupt properties. ARM platforms already has a list of interrupts that fall into different secure groups. This patch defines macros that enumerate interrupt properties in the same fashion, and points the driver driver data to a list of interrupt properties rather than list of secure interrupts on ARM platforms. The deprecated interrupt list definitions are however retained to support legacy builds. Configuration applied to individual interrupts remain unchanged, so no runtime behaviour change expected. NOTE: Platforms that use the arm/common function plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided INTR_PROP_DESC macro. Change-Id: I24d643b83e3333753a3ba97d4b6fb71e16bb0952 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-09-22 08:59:59 +01:00
INTR_PROP_DESC(JUNO_IRQ_HDLCD1_SMMU, GIC_HIGHEST_SEC_PRIORITY, \
plat/arm: Fix misra warnings in platform code Change-Id: Ica944acc474a099219d50b041cfaeabd4f3d362f Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-09-27 14:41:02 +01:00
(grp), GIC_INTR_CFG_LEVEL), \
ARM platforms: Migrate to using interrupt properties An earlier patch added provision for the platform to provide secure interrupt properties. ARM platforms already has a list of interrupts that fall into different secure groups. This patch defines macros that enumerate interrupt properties in the same fashion, and points the driver driver data to a list of interrupt properties rather than list of secure interrupts on ARM platforms. The deprecated interrupt list definitions are however retained to support legacy builds. Configuration applied to individual interrupts remain unchanged, so no runtime behaviour change expected. NOTE: Platforms that use the arm/common function plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided INTR_PROP_DESC macro. Change-Id: I24d643b83e3333753a3ba97d4b6fb71e16bb0952 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-09-22 08:59:59 +01:00
INTR_PROP_DESC(JUNO_IRQ_USB_SMMU, GIC_HIGHEST_SEC_PRIORITY, \
plat/arm: Fix misra warnings in platform code Change-Id: Ica944acc474a099219d50b041cfaeabd4f3d362f Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-09-27 14:41:02 +01:00
(grp), GIC_INTR_CFG_LEVEL), \
ARM platforms: Migrate to using interrupt properties An earlier patch added provision for the platform to provide secure interrupt properties. ARM platforms already has a list of interrupts that fall into different secure groups. This patch defines macros that enumerate interrupt properties in the same fashion, and points the driver driver data to a list of interrupt properties rather than list of secure interrupts on ARM platforms. The deprecated interrupt list definitions are however retained to support legacy builds. Configuration applied to individual interrupts remain unchanged, so no runtime behaviour change expected. NOTE: Platforms that use the arm/common function plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided INTR_PROP_DESC macro. Change-Id: I24d643b83e3333753a3ba97d4b6fb71e16bb0952 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-09-22 08:59:59 +01:00
INTR_PROP_DESC(JUNO_IRQ_THIN_LINKS_SMMU, GIC_HIGHEST_SEC_PRIORITY, \
plat/arm: Fix misra warnings in platform code Change-Id: Ica944acc474a099219d50b041cfaeabd4f3d362f Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-09-27 14:41:02 +01:00
(grp), GIC_INTR_CFG_LEVEL), \
ARM platforms: Migrate to using interrupt properties An earlier patch added provision for the platform to provide secure interrupt properties. ARM platforms already has a list of interrupts that fall into different secure groups. This patch defines macros that enumerate interrupt properties in the same fashion, and points the driver driver data to a list of interrupt properties rather than list of secure interrupts on ARM platforms. The deprecated interrupt list definitions are however retained to support legacy builds. Configuration applied to individual interrupts remain unchanged, so no runtime behaviour change expected. NOTE: Platforms that use the arm/common function plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided INTR_PROP_DESC macro. Change-Id: I24d643b83e3333753a3ba97d4b6fb71e16bb0952 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-09-22 08:59:59 +01:00
INTR_PROP_DESC(JUNO_IRQ_SEC_I2C, GIC_HIGHEST_SEC_PRIORITY, \
plat/arm: Fix misra warnings in platform code Change-Id: Ica944acc474a099219d50b041cfaeabd4f3d362f Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-09-27 14:41:02 +01:00
(grp), GIC_INTR_CFG_LEVEL), \
ARM platforms: Migrate to using interrupt properties An earlier patch added provision for the platform to provide secure interrupt properties. ARM platforms already has a list of interrupts that fall into different secure groups. This patch defines macros that enumerate interrupt properties in the same fashion, and points the driver driver data to a list of interrupt properties rather than list of secure interrupts on ARM platforms. The deprecated interrupt list definitions are however retained to support legacy builds. Configuration applied to individual interrupts remain unchanged, so no runtime behaviour change expected. NOTE: Platforms that use the arm/common function plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided INTR_PROP_DESC macro. Change-Id: I24d643b83e3333753a3ba97d4b6fb71e16bb0952 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-09-22 08:59:59 +01:00
INTR_PROP_DESC(JUNO_IRQ_GPU_SMMU_1, GIC_HIGHEST_SEC_PRIORITY, \
plat/arm: Fix misra warnings in platform code Change-Id: Ica944acc474a099219d50b041cfaeabd4f3d362f Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-09-27 14:41:02 +01:00
(grp), GIC_INTR_CFG_LEVEL), \
ARM platforms: Migrate to using interrupt properties An earlier patch added provision for the platform to provide secure interrupt properties. ARM platforms already has a list of interrupts that fall into different secure groups. This patch defines macros that enumerate interrupt properties in the same fashion, and points the driver driver data to a list of interrupt properties rather than list of secure interrupts on ARM platforms. The deprecated interrupt list definitions are however retained to support legacy builds. Configuration applied to individual interrupts remain unchanged, so no runtime behaviour change expected. NOTE: Platforms that use the arm/common function plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided INTR_PROP_DESC macro. Change-Id: I24d643b83e3333753a3ba97d4b6fb71e16bb0952 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-09-22 08:59:59 +01:00
INTR_PROP_DESC(JUNO_IRQ_ETR_SMMU, GIC_HIGHEST_SEC_PRIORITY, \
plat/arm: Fix misra warnings in platform code Change-Id: Ica944acc474a099219d50b041cfaeabd4f3d362f Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-09-27 14:41:02 +01:00
(grp), GIC_INTR_CFG_LEVEL)
ARM platforms: Migrate to using interrupt properties An earlier patch added provision for the platform to provide secure interrupt properties. ARM platforms already has a list of interrupts that fall into different secure groups. This patch defines macros that enumerate interrupt properties in the same fashion, and points the driver driver data to a list of interrupt properties rather than list of secure interrupts on ARM platforms. The deprecated interrupt list definitions are however retained to support legacy builds. Configuration applied to individual interrupts remain unchanged, so no runtime behaviour change expected. NOTE: Platforms that use the arm/common function plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided INTR_PROP_DESC macro. Change-Id: I24d643b83e3333753a3ba97d4b6fb71e16bb0952 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-09-22 08:59:59 +01:00
#define PLAT_ARM_G0_IRQ_PROPS(grp) ARM_G0_IRQ_PROPS(grp)
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: Add support for image overlaying in Trusted SRAM This patch allows the BL3-1 NOBITS section to overlap the BL1 R/W section since the former will always be used after the latter. Similarly, the BL3-2 NOBITS section can overlay the BL2 image when BL3-2 is loaded in Trusted SRAM. Due to the current size of the images, there is no actual overlap. Nevertheless, this reorganization may help to optimise the Trusted SRAM usage when the images size grows. Note that because BL3-1 NOBITS section is allowed to overlap the BL1 R/W section, BL1 global variables will remain valid only until execution reaches the BL3-1 entry point during a cold boot. Documentation updated accordingly. Fixes ARM-software/tf-issues#254 Change-Id: Id538f4d1c7f1f7858108280fd7b97e138572b879
2014-11-07 09:44:58 +00: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
* Required ARM CSS SoC based platform porting definitions
Juno: Add support for image overlaying in Trusted SRAM This patch allows the BL3-1 NOBITS section to overlap the BL1 R/W section since the former will always be used after the latter. Similarly, the BL3-2 NOBITS section can overlay the BL2 image when BL3-2 is loaded in Trusted SRAM. Due to the current size of the images, there is no actual overlap. Nevertheless, this reorganization may help to optimise the Trusted SRAM usage when the images size grows. Note that because BL3-1 NOBITS section is allowed to overlap the BL1 R/W section, BL1 global variables will remain valid only until execution reaches the BL3-1 entry point during a cold boot. Documentation updated accordingly. Fixes ARM-software/tf-issues#254 Change-Id: Id538f4d1c7f1f7858108280fd7b97e138572b879
2014-11-07 09:44:58 +00: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
/* CSS SoC NIC-400 Global Programmers View (GPV) */
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#define PLAT_SOC_CSS_NIC400_BASE UL(0x2a000000)
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
ARM platforms: Allow platforms to define SDEI events With this patch, ARM platforms are expected to define the macros PLAT_ARM_SDEI_PRIVATE_EVENTS and PLAT_ARM_SDEI_SHARED_EVENTS as a list of private and shared events, respectively. This allows for individual platforms to define their own events. Change-Id: I66851fdcbff83fd9568c2777ade9eb12df284b49 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-12-08 10:38:24 +00:00
#define PLAT_ARM_PRIVATE_SDEI_EVENTS ARM_SDEI_PRIVATE_EVENTS
#define PLAT_ARM_SHARED_SDEI_EVENTS ARM_SDEI_SHARED_EVENTS
plat/css: allow platforms to define the system power domain level The CSS_SYSTEM_PWR_DMN_LVL macro that defines the system power domain level is fixed at ARM_PWR_LVL2 for all CSS platforms. However, the system power domain level can be different for CSS platforms that use multi-threaded CPUs. So, in preparation towards adding support for platforms that use multi-threaded CPUs, refactor the definition of CSS_SYSTEM_PWR_DMN_LVL such that CSS_SYSTEM_PWR_DMN_LVL is uniquely defined for each of the CSS platform. Change-Id: Ia837b13f6865e71da01780993c048b45b7f36d85 Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
2018-10-16 10:49:54 +01:00
/* System power domain level */
#define CSS_SYSTEM_PWR_DMN_LVL ARM_PWR_LVL2
n1sdp: add code for DDR ECC enablement and BL33 copy to DDR N1SDP platform supports RDIMMs with ECC capability. To use the ECC capability, the entire DDR memory space has to be zeroed out before enabling the ECC bits in DMC620. Zeroing out several gigabytes of memory from SCP is quite time consuming so functions are added that zeros out the DDR memory from application processor which is much faster compared to SCP. BL33 binary cannot be copied to DDR memory before enabling ECC so this is also done by TF-A from IOFPGA-DDR3 memory to main DDR4 memory after ECC is enabled. Original PLAT_PHY_ADDR_SPACE_SIZE was limited to 36-bits with which the entire DDR space cannot be accessed as DRAM2 starts in base 0x8080000000. So these macros are redefined for all ARM platforms. Change-Id: If09524fb65b421b7a368b1b9fc52c49f2ddb7846 Signed-off-by: Manoj Kumar <manoj.kumar3@arm.com>
2019-06-21 17:07:13 +01:00
/*
* Physical and virtual address space limits for MMU in AARCH64 & AARCH32 modes
*/
Switch AARCH32/AARCH64 to __aarch64__ NOTE: AARCH32/AARCH64 macros are now deprecated in favor of __aarch64__. All common C compilers pre-define the same macros to signal which architecture the code is being compiled for: __arm__ for AArch32 (or earlier versions) and __aarch64__ for AArch64. There's no need for TF-A to define its own custom macros for this. In order to unify code with the export headers (which use __aarch64__ to avoid another dependency), let's deprecate the AARCH32 and AARCH64 macros and switch the code base over to the pre-defined standard macro. (Since it is somewhat unintuitive that __arm__ only means AArch32, let's standardize on only using __aarch64__.) Change-Id: Ic77de4b052297d77f38fc95f95f65a8ee70cf200 Signed-off-by: Julius Werner <jwerner@chromium.org>
2019-07-09 22:02:43 +01:00
#ifdef __aarch64__
n1sdp: add code for DDR ECC enablement and BL33 copy to DDR N1SDP platform supports RDIMMs with ECC capability. To use the ECC capability, the entire DDR memory space has to be zeroed out before enabling the ECC bits in DMC620. Zeroing out several gigabytes of memory from SCP is quite time consuming so functions are added that zeros out the DDR memory from application processor which is much faster compared to SCP. BL33 binary cannot be copied to DDR memory before enabling ECC so this is also done by TF-A from IOFPGA-DDR3 memory to main DDR4 memory after ECC is enabled. Original PLAT_PHY_ADDR_SPACE_SIZE was limited to 36-bits with which the entire DDR space cannot be accessed as DRAM2 starts in base 0x8080000000. So these macros are redefined for all ARM platforms. Change-Id: If09524fb65b421b7a368b1b9fc52c49f2ddb7846 Signed-off-by: Manoj Kumar <manoj.kumar3@arm.com>
2019-06-21 17:07:13 +01:00
#define PLAT_PHY_ADDR_SPACE_SIZE (1ULL << 36)
#define PLAT_VIRT_ADDR_SPACE_SIZE (1ULL << 36)
#else
#define PLAT_PHY_ADDR_SPACE_SIZE (1ULL << 32)
#define PLAT_VIRT_ADDR_SPACE_SIZE (1ULL << 32)
#endif
plat/arm: Fix types of constants in headers Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-10-30 16:12:32 +00:00
#endif /* PLATFORM_DEF_H */