1. 09 Nov, 2018 1 commit
    • Siva Durga Prasad Paladugu's avatar
      arm64: versal: Add support for new Xilinx Versal ACAPs · f91c3cb1
      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: default avatarSiva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>
      Signed-off-by: default avatarMichal Simek <michal.simek@xilinx.com>
      f91c3cb1
  2. 29 Oct, 2018 1 commit
    • Soby Mathew's avatar
      Add helper to return reference to a symbol · 6a7b3005
      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: default avatarSoby Mathew <soby.mathew@arm.com>
      6a7b3005
  3. 03 Oct, 2018 1 commit
  4. 28 Feb, 2018 1 commit
  5. 16 Oct, 2017 1 commit
    • Jeenu Viswambharan's avatar
      ARM platforms: Migrate to using interrupt properties · b2c363b1
      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: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      b2c363b1
  6. 11 Oct, 2017 1 commit
    • Soby Mathew's avatar
      ARM platforms: enable GICv3 state save/restore · e35a3fb5
      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: default avatarSoby Mathew <soby.mathew@arm.com>
      Co-Authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      e35a3fb5
  7. 01 Aug, 2017 1 commit
    • Jeenu Viswambharan's avatar
      FVP: Add support for multi-threaded CPUs · 11ad8f20
      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: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      11ad8f20
  8. 03 May, 2017 1 commit
  9. 23 Jan, 2017 2 commits
    • Masahiro Yamada's avatar
      Use #ifdef for AARCH32 instead of #if · 6af03f9c
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      6af03f9c
    • Masahiro Yamada's avatar
      Use #ifdef for IMAGE_BL* instead of #if · 3d8256b2
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      3d8256b2
  10. 15 Dec, 2016 1 commit
  11. 10 Aug, 2016 1 commit
    • Soby Mathew's avatar
      AArch32: Add essential ARM platform and FVP support · 877cf3ff
      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
      877cf3ff
  12. 27 Apr, 2016 1 commit
    • Soby Mathew's avatar
      Remove support for legacy VE memory map in FVP · 21a3973d
      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
      21a3973d
  13. 09 Dec, 2015 1 commit
    • Achin Gupta's avatar
      Rework use of ARM GIC drivers on ARM platforms · 27573c59
      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
      27573c59