- 09 Nov, 2018 1 commit
-
-
Siva Durga Prasad Paladugu authored
Xilinx is introducing Versal, an adaptive compute acceleration platform (ACAP), built on 7nm FinFET process technology. Versal ACAPs combine Scalar Processing Engines, Adaptable Hardware Engines, and Intelligent Engines with leading-edge memory and interfacing technologies to deliver powerful heterogeneous acceleration for any application. The Versal AI Core series has five devices, offering 128 to 400 AI Engines. The series includes dual-core Arm Cortex-A72 application processors, dual-core Arm Cortex-R5 real-time processors, 256KB of on-chip memory with ECC, more than 1,900 DSP engines optimized for high-precision floating point with low latency. This patch adds Virtual QEMU platform support for this SoC "versal_virt". Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
-
- 29 Oct, 2018 1 commit
-
-
Soby Mathew authored
This patch adds a utility function to return the address of a symbol. By default, the compiler generates adr/adrp instruction pair to return the reference and this utility is used to override this compiler generated to code and use `ldr` instruction. This is needed for Position Independent Executable when it needs to reference a symbol which is constant and does not depend on the execute address of the binary. For example, on the FVP, the GICv3 register context is stored in a secure carveout (arm_el3_tzc_dram) within DDR and does not relocate with the BL image. Now if BL31 is executing at a different address other than the compiled address, using adrp/adr instructions to reference this memory will not work as they generate an address that is PC relative. The way to get around this problem is to reference it as non-PC relative (i.e non-relocatable location) via `ldr` instruction. Change-Id: I5008a951b007144258121690afb68dc8e12ee6f7 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 03 Oct, 2018 1 commit
-
-
Daniel Boulby authored
Mark the GICv3, CCI and CCN code only used in Bl31 initialization with __init to be reclaimed once no longer needed. Change-Id: I3d77f36758450d9d1d87ecc60bc1c63fe4082667 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
- 28 Feb, 2018 1 commit
-
-
Roberto Vargas authored
Rule 8.4: A compatible declaration shall be visible when an object or function with external linkage is defined Fixed for: make DEBUG=1 PLAT=fvp LOG_LEVEL=50 all Change-Id: I7c2ad3f5c015411c202605851240d5347e4cc8c7 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 16 Oct, 2017 1 commit
-
-
Jeenu Viswambharan authored
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>
-
- 11 Oct, 2017 1 commit
-
-
Soby Mathew authored
Provides GICv3 save/restore feature to arm_system_pwr_domain_resume and arm_system_pwr_domain_save functions. Introduce FVP PSCI power level 3 (System level) support. This is solely done to provide example code on how to use the GICv3 save and restore helpers. Also make CSS GICv3 platforms power off the Redistributor on SYSTEM SUSPEND as its state is saved and restored. Change-Id: I0d852f3af8824edee1a17c085cf593ddd33a4e77 Signed-off-by: Soby Mathew <soby.mathew@arm.com> Co-Authored-by: Douglas Raillard <douglas.raillard@arm.com>
-
- 01 Aug, 2017 1 commit
-
-
Jeenu Viswambharan authored
ARM CPUs with multi-threading implementation has more than one Processing Element in a single physical CPU. Such an implementation will reflect the following changes in the MPIDR register: - The MT bit set; - Affinity levels pertaining to cluster and CPUs occupy one level higher than in a single-threaded implementation, and the lowest affinity level pertains to hardware threads. MPIDR affinity level fields essentially appear shifted to left than otherwise. The FVP port henceforth assumes that both properties above to be concomitant on a given FVP platform. To accommodate for varied MPIDR formats at run time, this patch re-implements the FVP platform-specific functions that translates MPIDR values to a linear indices, along with required validation. The same treatment is applied for GICv3 MPIDR hashing function as well. An FVP-specific build option FVP_MAX_PE_PER_CPU is introduced which specifies the maximum number of threads implemented per CPU. For backwards compatibility, its value defaults to 1. Change-Id: I729b00d3e121d16ce9a03de4f9db36dfac580e3f Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 03 May, 2017 1 commit
-
-
dp-arm authored
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>
-
- 23 Jan, 2017 2 commits
-
-
Masahiro Yamada authored
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. For AARCH32/AARCH64, these macros are defined in the top-level Makefile as follows: ifeq (${ARCH},aarch32) $(eval $(call add_define,AARCH32)) else $(eval $(call add_define,AARCH64)) endif This means only one of the two is defined. So, AARCH32/AARCH64 belongs to the latter group where we should use #ifdef or #ifndef. The conditionals are mostly coded correctly, but I see some mistakes. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
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>
-
- 15 Dec, 2016 1 commit
-
-
Jeenu Viswambharan authored
As with other ARM platform GIC APIs, these directly invoke the GICv3 driver APIs for Redistributor power management. For the sake of uniform GIC API, empty stubs are placed for those GIC drivers that lack Redistributor component. Change-Id: Iad0d760d4dbca790998f7768cda621ff3b15a864 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 10 Aug, 2016 1 commit
-
-
Soby Mathew authored
This patch adds AArch32 support for FVP and implements common platform APIs like `plat_get_my_stack`, `plat_set_my_stack`, `plat_my_core_cos` for AArch32. Only Multi Processor(MP) implementations of these functions are considered in this patch. The ARM Standard platform layer helpers are implemented for AArch32 and the common makefiles are modified to cater for both AArch64 and AArch32 builds. Compatibility with the deprecated platform API is not supported for AArch32. Change-Id: Iad228400613eec91abf731b49e21a15bcf2833ea
-
- 27 Apr, 2016 1 commit
-
-
Soby Mathew authored
This patch removes support for legacy Versatile Express memory map for the GIC peripheral in the FVP platform. The user guide is also updated for the same. Change-Id: Ib8cfb819083aca359e5b46b5757cb56cb0ea6533
-
- 09 Dec, 2015 1 commit
-
-
Achin Gupta authored
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
-