1. 30 Nov, 2017 1 commit
    • David Cunado's avatar
      Enable SVE for Non-secure world · 1a853370
      David Cunado authored
      
      
      This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set
      to one EL3 will check to see if the Scalable Vector Extension (SVE) is
      implemented when entering and exiting the Non-secure world.
      
      If SVE is implemented, EL3 will do the following:
      
      - Entry to Non-secure world: SIMD, FP and SVE functionality is enabled.
      
      - Exit from Non-secure world: SIMD, FP and SVE functionality is
        disabled. As SIMD and FP registers are part of the SVE Z-registers
        then any use of SIMD / FP functionality would corrupt the SVE
        registers.
      
      The build option default is 1. The SVE functionality is only supported
      on AArch64 and so the build option is set to zero when the target
      archiecture is AArch32.
      
      This build option is not compatible with the CTX_INCLUDE_FPREGS - an
      assert will be raised on platforms where SVE is implemented and both
      ENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1.
      
      Also note this change prevents secure world use of FP&SIMD registers on
      SVE-enabled platforms. Existing Secure-EL1 Payloads will not work on
      such platforms unless ENABLE_SVE_FOR_NS is set to 0.
      
      Additionally, on the first entry into the Non-secure world the SVE
      functionality is enabled and the SVE Z-register length is set to the
      maximum size allowed by the architecture. This includes the use case
      where EL2 is implemented but not used.
      
      Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7dae
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      1a853370
  2. 29 Nov, 2017 3 commits
  3. 20 Nov, 2017 1 commit
    • Dimitris Papastamos's avatar
      Refactor Statistical Profiling Extensions implementation · 281a08cc
      Dimitris Papastamos authored
      
      
      Factor out SPE operations in a separate file.  Use the publish
      subscribe framework to drain the SPE buffers before entering secure
      world.  Additionally, enable SPE before entering normal world.
      
      A side effect of this change is that the profiling buffers are now
      only drained when a transition from normal world to secure world
      happens.  Previously they were drained also on return from secure
      world, which is unnecessary as SPE is not supported in S-EL1.
      
      Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      281a08cc
  4. 17 Nov, 2017 1 commit
  5. 15 Nov, 2017 1 commit
    • David Cunado's avatar
      Move FPEXC32_EL2 to FP Context · 91089f36
      David Cunado authored
      
      
      The FPEXC32_EL2 register controls SIMD and FP functionality when the
      lower ELs are executing in AArch32 mode. It is architecturally mapped
      to AArch32 system register FPEXC.
      
      This patch removes FPEXC32_EL2 register from the System Register context
      and adds it to the floating-point context. EL3 only saves / restores the
      floating-point context if the build option CTX_INCLUDE_FPREGS is set to 1.
      
      The rationale for this change is that if the Secure world is using FP
      functionality and EL3 is not managing the FP context, then the Secure
      world will save / restore the appropriate FP registers.
      
      NOTE - this is a break in behaviour in the unlikely case that
      CTX_INCLUDE_FPREGS is set to 0 and the platform contains an AArch32
      Secure Payload that modifies FPEXC, but does not save and restore
      this register
      
      Change-Id: Iab80abcbfe302752d52b323b4abcc334b585c184
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      91089f36
  6. 13 Nov, 2017 2 commits
    • Jeenu Viswambharan's avatar
      ARM platforms: Provide SDEI entry point validation · 781f4aac
      Jeenu Viswambharan authored
      
      
      Provide a strong definition for plat_sdei_validate_sdei_entrypoint()
      which translates client address to Physical Address, and then validating
      the address to be present in DRAM.
      
      Change-Id: Ib93eb66b413d638aa5524d1b3de36aa16d38ea11
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      781f4aac
    • Jeenu Viswambharan's avatar
      BL31: Introduce Exception Handling Framework · 21b818c0
      Jeenu Viswambharan authored
      
      
      EHF is a framework that allows dispatching of EL3 interrupts to their
      respective handlers in EL3.
      
      This framework facilitates the firmware-first error handling policy in
      which asynchronous exceptions may be routed to EL3. Such exceptions may
      be handed over to respective exception handlers. Individual handlers
      might further delegate exception handling to lower ELs.
      
      The framework associates the delegated execution to lower ELs with a
      priority value. For interrupts, this corresponds to the priorities
      programmed in GIC; for other types of exceptions, viz. SErrors or
      Synchronous External Aborts, individual dispatchers shall explicitly
      associate delegation to a secure priority. In order to prevent lower
      priority interrupts from preempting higher priority execution, the
      framework provides helpers to control preemption by virtue of
      programming Priority Mask register in the interrupt controller.
      
      This commit allows for handling interrupts targeted at EL3. Exception
      handlers own interrupts by assigning them a range of secure priorities,
      and registering handlers for each priority range it owns.
      
      Support for exception handling in BL31 image is enabled by setting the
      build option EL3_EXCEPTION_HANDLING=1.
      
      Documentation to follow.
      
      NOTE: The framework assumes the priority scheme supported by platform
      interrupt controller is compliant with that of ARM GIC architecture (v2
      or later).
      
      Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      21b818c0
  7. 08 Nov, 2017 11 commits
  8. 01 Nov, 2017 1 commit
  9. 31 Oct, 2017 2 commits
  10. 23 Oct, 2017 2 commits
  11. 17 Oct, 2017 4 commits
  12. 16 Oct, 2017 4 commits
  13. 13 Oct, 2017 3 commits
    • Roberto Vargas's avatar
      Update PSCI version to 1.1 · 829e97d7
      Roberto Vargas authored
      
      
      Updated the PSCI version conforming to the PSCI v1.1
      specification (ARM DEN022D).
      
      Change-Id: I1f34772ef6de37ec1ade719a1ab3aa062152d995
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      829e97d7
    • David Cunado's avatar
      Init and save / restore of PMCR_EL0 / PMCR · 3e61b2b5
      David Cunado authored
      
      
      Currently TF does not initialise the PMCR_EL0 register in
      the secure context or save/restore the register.
      
      In particular, the DP field may not be set to one to prohibit
      cycle counting in the secure state, even though event counting
      generally is prohibited via the default setting of MDCR_EL3.SMPE
      to 0.
      
      This patch initialises PMCR_EL0.DP to one in the secure state
      to prohibit cycle counting and also initialises other fields
      that have an architectually UNKNOWN reset value.
      
      Additionally, PMCR_EL0 is added to the list of registers that are
      saved and restored during a world switch.
      
      Similar changes are made for PMCR for the AArch32 execution state.
      
      NOTE: secure world code at lower ELs that assume other values in PMCR_EL0
      will be impacted.
      
      Change-Id: Iae40e8c0a196d74053accf97063ebc257b4d2f3a
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      3e61b2b5
    • Roberto Vargas's avatar
      reset2: Add PSCI system_reset2 function · 36a8f8fd
      Roberto Vargas authored
      
      
      This patch implements PSCI_SYSTEM_RESET2 API as defined in PSCI
      v1.1 specification. The specification allows architectural and
      vendor-specific resets via this API. In the current specification,
      there is only one architectural reset, the warm reset. This reset is
      intended to provide a fast reboot path that guarantees not to reset
      system main memory.
      
      Change-Id: I057bb81a60cd0fe56465dbb5791d8e1cca025bd3
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      36a8f8fd
  14. 05 Oct, 2017 4 commits
    • Soby Mathew's avatar
      GICv3: add functions for save and restore · ebf1ca10
      Soby Mathew authored
      
      
      During system suspend, the GICv3 Distributor and Redistributor context
      can be lost due to power gating of the system power domain. This means
      that the GICv3 context needs to be saved prior to system suspend and
      restored on wakeup. Currently the consensus is that the Firmware should
      be in charge of this. See tf-issues#464 for more details.
      
      This patch introduces helper APIs in the GICv3 driver to save and
      restore the Distributor and Redistributor contexts. The GICv3 ITS
      context is not considered in this patch because the specification says
      that the details of ITS power management is implementation-defined.
      These APIs are expected to be appropriately invoked by the platform
      layer during system suspend.
      
      Fixes ARM-software/tf-issues#464
      
      Change-Id: Iebb9c6770ab8c4d522546f161fa402d2fe02ec00
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      ebf1ca10
    • Antonio Nino Diaz's avatar
      xlat: Add support for EL0 and EL1 mappings · 609c9191
      Antonio Nino Diaz authored
      
      
      This patch introduces the ability of the xlat tables library to manage
      EL0 and EL1 mappings from a higher exception level.
      
      Attributes MT_USER and MT_PRIVILEGED have been added to allow the user
      specify the target EL in the translation regime EL1&0.
      
      REGISTER_XLAT_CONTEXT2 macro is introduced to allow creating a
      xlat_ctx_t that targets a given translation regime (EL1&0 or EL3).
      
      A new member is added to xlat_ctx_t to represent the translation regime
      the xlat_ctx_t manages. The execute_never mask member is removed as it
      is computed from existing information.
      
      Change-Id: I95e14abc3371d7a6d6a358cc54c688aa9975c110
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      609c9191
    • Douglas Raillard's avatar
      xlat: Introduce function xlat_arch_tlbi_va_regime() · b4ae615b
      Douglas Raillard authored
      
      
      Introduce a variant of the TLB invalidation helper function that
      allows the targeted translation regime to be specified, rather than
      defaulting to the current one.
      
      This new function is useful in the context of EL3 software managing
      translation tables for the S-EL1&0 translation regime, as then it
      might need to invalidate S-EL1&0 TLB entries rather than EL3 ones.
      
      Define a new enumeration to be able to represent translation regimes in
      the xlat tables library.
      
      Change-Id: Ibe4438dbea2d7a6e7470bfb68ff805d8bf6b07e5
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      b4ae615b
    • Sandrine Bailleux's avatar
      xlat: Introduce MAP_REGION2() macro · fdb1964c
      Sandrine Bailleux authored
      
      
      The current implementation of the memory mapping API favours mapping
      memory regions using the biggest possible block size in order to
      reduce the number of translation tables needed.
      
      In some cases, this behaviour might not be desirable. When translation
      tables are edited at run-time, coarse-grain mappings like that might
      need splitting into finer-grain tables. This operation has a
      performance cost.
      
      The MAP_REGION2() macro allows to specify the granularity of
      translation tables used for the initial mapping of a memory region.
      This might increase performance for memory regions that are likely to
      be edited in the future, at the expense of a potentially increased
      memory footprint.
      
      The Translation Tables Library Design Guide has been updated to
      explain the use case for this macro. Also added a few intermediate
      titles to make the guide easier to digest.
      
      Change-Id: I04de9302e0ee3d326b8877043a9f638766b81b7b
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      fdb1964c