1. 09 Jan, 2018 1 commit
    • Wendy Liang's avatar
      Introduce ZynqMP IPI implementation · dc1dfe83
      Wendy Liang authored
      
      
      Previously, ZynqMP IPI in ATF is only for ZynqMP PM,
      This patch is to have a ZynqMP IPI implementation to handle
      both ZynqMP PM IPI requirement and IPI mailbox service requirement
      which will be introduced next.
      
      We control IPI agents registers access but not IPI buffers access in
      this implementation. Each IPI mailbox user will directly access the
      IPI buffers.
      Signed-off-by: default avatarWendy Liang <jliang@xilinx.com>
      dc1dfe83
  2. 30 Nov, 2017 1 commit
    • David Cunado's avatar
      Do not enable SVE on pre-v8.2 platforms · 3872fc2d
      David Cunado authored
      
      
      Pre-v8.2 platforms such as the Juno platform does not have
      the Scalable Vector Extensions implemented and so the build
      option ENABLE_SVE is set to zero.
      
      This has a minor performance improvement with no functional
      impact.
      
      Change-Id: Ib072735db7a0247406f8b60e325b7e28b1e04ad1
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      3872fc2d
  3. 17 Oct, 2017 1 commit
  4. 18 Sep, 2017 1 commit
  5. 14 Jul, 2017 1 commit
  6. 02 Jul, 2017 1 commit
  7. 03 May, 2017 1 commit
  8. 06 Apr, 2017 1 commit
  9. 20 Mar, 2017 1 commit
  10. 06 Feb, 2017 1 commit
    • Douglas Raillard's avatar
      Replace some memset call by zeromem · 32f0d3c6
      Douglas Raillard authored
      
      
      Replace all use of memset by zeromem when zeroing moderately-sized
      structure by applying the following transformation:
      memset(x, 0, sizeof(x)) => zeromem(x, sizeof(x))
      
      As the Trusted Firmware is compiled with -ffreestanding, it forbids the
      compiler from using __builtin_memset and forces it to generate calls to
      the slow memset implementation. Zeromem is a near drop in replacement
      for this use case, with a more efficient implementation on both AArch32
      and AArch64.
      
      Change-Id: Ia7f3a90e888b96d056881be09f0b4d65b41aa79e
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      32f0d3c6
  11. 18 Jan, 2017 2 commits
    • Masahiro Yamada's avatar
      Move BL_COHERENT_RAM_BASE/END defines to common_def.h · 47497053
      Masahiro Yamada authored
      
      
      We have lots of duplicated defines (and comment blocks too).
      Move them to include/plat/common/common_def.h.
      
      While we are here, suffix the end address with _END instead of
      _LIMIT.  The _END is a better fit to indicate the linker-derived
      real end address.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      47497053
    • Masahiro Yamada's avatar
      Use *_END instead of *_LIMIT for linker derived end addresses · ecdc898d
      Masahiro Yamada authored
      
      
      The usage of _LIMIT seems odd here, so rename as follows:
        BL_CODE_LIMIT     --> BL_CODE_END
        BL_RO_DATA_LIMIT  --> BL_RO_DATA_END
        BL1_CODE_LIMIT    --> BL1_CODE_END
        BL1_RO_DATA_LIMIT --> BL1_RO_DATA_END
      
      Basically, we want to use _LIMIT and _END properly as follows:
        *_SIZE + *_MAX_SIZE = *_LIMIT
        *_SIZE + *_SIZE     = *_END
      
      The _LIMIT is generally defined by platform_def.h to indicate the
      platform-dependent memory constraint.  So, its typical usage is
        ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.")
      in a linker script.
      
      On the other hand, _END is used to indicate the end address of the
      compiled image, i.e. we do not know it until the image is linked.
      
      Here, all of these macros belong to the latter, so should be
      suffixed with _END.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      ecdc898d
  12. 06 Jan, 2017 1 commit
  13. 20 Dec, 2016 1 commit
    • Masahiro Yamada's avatar
      zynqmp: add "override" directive to mandatory options · 34071d6a
      Masahiro Yamada authored
      
      
      The platform.mk sets build options required for ZynqMP, but users
      can still change them from the command line, like:
      
        make PLAT=zynqmp RESET_TO_BL31=0 CROSS_COMPILE=...
      
      Then, the makefile shows an error message in that case:
        Using BL31 as the reset vector is only one option supported on ZynqMP.
        Please set RESET_TO_BL31 to 1.
      
      If the option is not user-configurable, the makefile can specify
      "override" to prevent users from changing it.  We do not need the
      error message for the case that never happens.
      
      Likewise, ENABLE_PLAT_COMPAT := 0 and PROGRAMMABLE_RESET_ADDRESS := 1
      are mandatory to avoid build error.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarSoren Brinkmann <soren.brinkmann@xilinx.com>
      34071d6a
  14. 14 Dec, 2016 1 commit
  15. 05 Dec, 2016 1 commit
    • Jeenu Viswambharan's avatar
      Define and use no_ret macro where no return is expected · a806dad5
      Jeenu Viswambharan authored
      
      
      There are many instances in ARM Trusted Firmware where control is
      transferred to functions from which return isn't expected. Such jumps
      are made using 'bl' instruction to provide the callee with the location
      from which it was jumped to. Additionally, debuggers infer the caller by
      examining where 'lr' register points to. If a 'bl' of the nature
      described above falls at the end of an assembly function, 'lr' will be
      left pointing to a location outside of the function range. This misleads
      the debugger back trace.
      
      This patch defines a 'no_ret' macro to be used when jumping to functions
      from which return isn't expected. The macro ensures to use 'bl'
      instruction for the jump, and also, for debug builds, places a 'nop'
      instruction immediately thereafter (unless instructed otherwise) so as
      to leave 'lr' pointing within the function range.
      
      Change-Id: Ib34c69fc09197cfd57bc06e147cc8252910e01b0
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      a806dad5
  16. 16 Nov, 2016 9 commits
  17. 13 Sep, 2016 15 commits