- 09 Dec, 2020 1 commit
-
-
Aditya Angadi authored
Upcoming RD platforms have deviations in various definitions of platform macros from that of the exisiting platforms. In preparation for adding support for those upcoming RD platforms, refactor the header file inclusion to allow newer platforms to use a different set of platform macros. Change-Id: Ic80283ddadafaa7f766f300652cb0d4e507efdb6 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
- 07 Feb, 2020 3 commits
-
-
Vijayenthiran Subramaniam authored
In preparation for adding support for Reference Design platforms which have different base addresses for GIC Distributor or Redistributor, move GIC related base addresses to individual platform definition files. Change-Id: Iecf52b4392a30b86905e1cd047c0ff87d59d0191 Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
Vijayenthiran Subramaniam authored
RD-N1-Edge based platforms can operate in dual-chip configuration wherein two rdn1edge SoCs are connected through a high speed coherent CCIX link. This patch adds a function to check if the RD-N1-Edge platform is operating in multi-chip mode by reading the SID register's NODE_ID value. If operating in multi-chip mode, initialize GIC-600 multi-chip operation by overriding the default GICR frames with array of GICR frames and setting the chip 0 as routing table owner. The address space of the second RD-N1-Edge chip (chip 1) starts from the address 4TB. So increase the physical and virtual address space size to 43 bits to accommodate the multi-chip configuration. If the multi-chip mode configuration is detected, dynamically add mmap entry for the peripherals memory region of the second RD-N1-Edge SoC. This is required to let the BL31 platform setup stage to configure the devices in the second chip. PLATFORM_CORE_COUNT macro is set to be multiple of CSS_SGI_CHIP_COUNT and topology changes are added to represent the dual-chip configuration. In order the build the dual-chip platform, CSS_SGI_CHIP_COUNT macro should be set to 2: export CROSS_COMPILE=<path-to-cross-compiler> make PLAT=rdn1edge CSS_SGI_CHIP_COUNT=2 ARCH=aarch64 all Change-Id: I576cdaf71f0b0e41b9a9181fa4feb7091f8c7bb4 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com> Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
Aditya Angadi authored
In order to allow the MHUv2 driver to be usable with multiple MHUv2 controllers, use the base address of the controller from the platform information instead of the MHUV2_BASE_ADDR macro. Change-Id: I4dbab87b929fb0568935e6c8b339ce67937f8cd1 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
- 10 Jan, 2020 1 commit
-
-
Deepika Bhavnani authored
NOTE for platform integrators: API `plat_psci_stat_get_residency()` third argument `last_cpu_idx` is changed from "signed int" to the "unsigned int" type. Issue / Trouble points 1. cpu_idx is used as mix of `unsigned int` and `signed int` in code with typecasting at some places leading to coverity issues. 2. Underlying platform API's return cpu_idx as `unsigned int` and comparison is performed with platform specific defines `PLAFORM_xxx` which is not consistent Misra Rule 10.4: The value of a complex expression of integer type may only be cast to a type that is narrower and of the same signedness as the underlying type of the expression. Based on above points, cpu_idx is kept as `unsigned int` to match the API's and low-level functions and platform defines are updated where ever required Signed-off-by: Deepika Bhavnani <deepika.bhavnani@arm.com> Change-Id: Ib26fd16e420c35527204b126b9b91e8babcc3a5c
-
- 01 Aug, 2019 1 commit
-
-
Julius Werner authored
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>
-
- 26 Jun, 2019 1 commit
-
-
Manoj Kumar authored
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>
-
- 13 Mar, 2019 1 commit
-
-
Masahisa Kojima authored
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>
-
- 27 Feb, 2019 1 commit
-
-
Chandni Cherukuri authored
Replace all usage of 'sgiclark' with 'rdn1e1edge' and 'sgiclarka' with 'rdn1edge' as per the updated product names. Change-Id: Idbc157c73477ec32f507ba2d4a4e907d8813374c Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-
- 04 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
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: e0ea0928 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca339 ("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>
-
- 27 Nov, 2018 2 commits
-
-
Chandni Cherukuri authored
For platforms with multi-threaded CPUs, the number of power domains supported would be more than the value currently defined by PLAT_MAX_PWR_LVL. So move the PLAT_MAX_PWR_LVL macro to platform specific code and let the platform define the number of power domain levels. Change-Id: I21c0682e62b397860b2999031a0c9c5ce0d28eed Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-
Chandni Cherukuri authored
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>
-
- 21 Nov, 2018 1 commit
-
-
Vijayenthiran Subramaniam authored
Remove the platform common plat_arm_security_setup function to allow platform specific implementations of the security setup function implemented in the board directory of the platform. For use by secure software, configure region0 of DMC-620 trustzone controller to protect the upper 16MB of memory of the first DRAM block from non-secure accesses. Change-Id: I9a8c19656702c4fa4f6917b3655b692d443bb568 Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
- 26 Oct, 2018 1 commit
-
-
Chandni Cherukuri authored
SGI-Clark.Ares platform is a variant of the SGI-Clark platform. It has two clusters of four Ares CPUs each. Though very similar to the SGI575 platform, there are subtle differences. HW_CONFIG and TB_FW_CONFIG dts files have been added. Change-Id: I740a33cbd1c3b1f1984cb56243b46ad379bab3e6 Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-
- 18 Oct, 2018 1 commit
-
-
Chandni Cherukuri authored
In preparation of adding support for upcoming SGI platforms, macros common to all the SGI platforms are moved into sgi_base_platform_def.h file. Macros that are specific to sgi575 platform remain in the platform_def.h file. In addition to this, the platform_def.h file is moved to sgi575 board directory. Also the ENT_CPU_SOURCES has been renamed to SGI_CPU_SOURCES and moved from sgi-common.mk to board specific makefile platform.mk Change-Id: Iccdd9f070f4feea232b9fbf4fdcc0ef2e8eccbf2 Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-