1. 18 Jul, 2018 4 commits
  2. 28 Jun, 2018 2 commits
  3. 27 Jun, 2018 7 commits
    • Dimitris Papastamos's avatar
      Merge pull request #1429 from jeenu-arm/mmu-direct · d48f193d
      Dimitris Papastamos authored
      Enable MMU without stack for xlat v2/DynamIQ
      d48f193d
    • Jeenu Viswambharan's avatar
      TSP: Enable cache along with MMU · bb00ea5b
      Jeenu Viswambharan authored
      
      
      Previously, data caches were disabled while enabling MMU only because of
      active stack. Now that we can enable MMU without using stack, we can
      enable both MMU and data caches at the same time.
      
      Change-Id: I73f3b8bae5178610e17e9ad06f81f8f6f97734a6
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      bb00ea5b
    • Jeenu Viswambharan's avatar
      DynamIQ: Enable MMU without using stack · 64ee263e
      Jeenu Viswambharan authored
      
      
      Having an active stack while enabling MMU has shown coherency problems.
      This patch builds on top of translation library changes that introduces
      MMU-enabling without using stacks.
      
      Previously, with HW_ASSISTED_COHERENCY, data caches were disabled while
      enabling MMU only because of active stack. Now that we can enable MMU
      without using stack, we can enable both MMU and data caches at the same
      time.
      
      NOTE: Since this feature depends on using translation table library v2,
      disallow using translation table library v1 with HW_ASSISTED_COHERENCY.
      
      Fixes ARM-software/tf-issues#566
      
      Change-Id: Ie55aba0c23ee9c5109eb3454cb8fa45d74f8bbb2
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      64ee263e
    • Jeenu Viswambharan's avatar
      xlat v1: Provide direct MMU-enabling stubs · 92bec97f
      Jeenu Viswambharan authored
      
      
      An earlier patch split MMU-enabling function for translation library v2.
      Although we don't intend to introduce the exact same functionality for
      xlat v1, this patch introduces stubs for directly enabling MMU to
      maintain API-compatibility.
      
      Change-Id: Id7d56e124c80af71de999fcda10f1734b50bca97
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      92bec97f
    • Jeenu Viswambharan's avatar
      xlat v2: Split MMU setup and enable · 0cc7aa89
      Jeenu Viswambharan authored
      
      
      At present, the function provided by the translation library to enable
      MMU constructs appropriate values for translation library, and programs
      them to the right registers. The construction of initial values,
      however, is only required once as both the primary and secondaries
      program the same values.
      
      Additionally, the MMU-enabling function is written in C, which means
      there's an active stack at the time of enabling MMU. On some systems,
      like Arm DynamIQ, having active stack while enabling MMU during warm
      boot might lead to coherency problems.
      
      This patch addresses both the above problems by:
      
        - Splitting the MMU-enabling function into two: one that sets up
          values to be programmed into the registers, and another one that
          takes the pre-computed values and writes to the appropriate
          registers. With this, the primary effectively calls both functions
          to have the MMU enabled, but secondaries only need to call the
          latter.
      
        - Rewriting the function that enables MMU in assembly so that it
          doesn't use stack.
      
      This patch fixes a bunch of MISRA issues on the way.
      
      Change-Id: I0faca97263a970ffe765f0e731a1417e43fbfc45
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      0cc7aa89
    • Dimitris Papastamos's avatar
      Merge pull request #1453 from soby-mathew/sm/set_cntfrq_bl1 · 86e07ae6
      Dimitris Papastamos authored
      ARM platforms: Initialize cntfrq for BL1 Firmware update
      86e07ae6
    • Dimitris Papastamos's avatar
      Merge pull request #1455 from antonio-nino-diaz-arm/an/ep-doc · a5298db2
      Dimitris Papastamos authored
      Document ep_info attribute flags
      a5298db2
  4. 26 Jun, 2018 2 commits
  5. 25 Jun, 2018 4 commits
  6. 23 Jun, 2018 2 commits
  7. 22 Jun, 2018 14 commits
  8. 21 Jun, 2018 5 commits
    • Dimitris Papastamos's avatar
      Merge pull request #1436 from antonio-nino-diaz-arm/an/spm-sync · ab676e00
      Dimitris Papastamos authored
      SPM: Allow entering the SP without needing a SMC
      ab676e00
    • Jeenu Viswambharan's avatar
      Arm platforms: Remove common RAS configuration source · a7055c58
      Jeenu Viswambharan authored
      
      
      The file arm_ras.c intended to provide common platform-specific RAS
      configuration for Arm platforms. Because this file has symbol
      definitions, it's proving difficult to provide a common definition.
      
      This patch therefore renames and makes the file specific to FVP. Other
      platforms shall provide their own configuration in similar fashion.
      
      Change-Id: I766fd238946e3e49cdb659680e1b45f41b237901
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      a7055c58
    • Jeenu Viswambharan's avatar
      SDEI: Make dispatches synchronous · cdb6ac94
      Jeenu Viswambharan authored
      
      
      SDEI event dispatches currently only sets up the Non-secure context
      before returning to the caller. The actual dispatch only happens upon
      exiting EL3 next time.
      
      However, for various error handling scenarios, it's beneficial to have
      the dispatch happen synchronously. I.e. when receiving SDEI interrupt,
      or for a successful sdei_dispatch_event() call, the event handler is
      executed; and upon the event completion, dispatcher execution resumes
      after the point of dispatch. The jump primitives introduced in the
      earlier patch facilitates this feature.
      
      With this patch:
      
        - SDEI interrupts and calls to sdei_dispatch_event prepares the NS
          context for event dispatch, then sets a jump point, and immediately
          exits EL3. This results in the client handler executing in
          Non-secure.
      
        - When the SDEI client completes the dispatched event, the SDEI
          dispatcher does a longjmp to the jump pointer created earlier. For
          the caller of the sdei_dispatch_event() in particular, this would
          appear as if call returned successfully.
      
      The dynamic workaround for CVE_2018_3639 is slightly shifted around as
      part of related minor refactoring. It doesn't affect the workaround
      functionality.
      
      Documentation updated.
      
      NOTE: This breaks the semantics of the explicit dispatch API, and any
      exiting usages should be carefully reviewed.
      
      Change-Id: Ib9c876d27ea2af7fb22de49832e55a0da83da3f9
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      cdb6ac94
    • Jeenu Viswambharan's avatar
      BL31: Introduce jump primitives · e7b9473e
      Jeenu Viswambharan authored
      
      
      This patch introduces setjmp() and ongjmp() primitives to enable
      standard setjmp/longjmp style execution. Both APIs parameters take a
      pointer to struct jmpbuf type, which hosts CPU registers saved/restored
      during jump.
      
      As per the standard usage:
      
        - setjmp() return 0 when a jump is setup; and a non-zero value when
          returning from jump.
      
        - The caller of setjmp() must not return, or otherwise update stack
          pointer since.
      
      Change-Id: I4af1d32e490cfa547979631b762b4cba188d0551
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      e7b9473e
    • Jeenu Viswambharan's avatar
      SDEI: Determine client EL from NS context's SCR_EL3 · 2ccfcb2e
      Jeenu Viswambharan authored
      
      
      Currently, the dispatcher reads from SCR_EL3 register directly to
      determine the EL of SDEI client. This is with the assumption that
      SCR_EL3 is not modified throughout. However, with RAS work flows, it's
      possible that SCR_EL3 register contains values corresponding to Secure
      world, and therefore EL determination can go wrong. To mitigate this,
      always read the register from the saved Non-secure context.
      
      Change-Id: Ic85e4021deb18eb58757f676f9a001174998543a
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      2ccfcb2e