1. 03 Nov, 2016 2 commits
    • dp-arm's avatar
      Perform a cache flush after ENTER PSCI timestamp capture · bfef6106
      dp-arm authored
      
      
      Without an explicit cache flush, the next timestamp captured might have
      a bogus value.
      
      This can happen if the following operations happen in order,
      on a CPU that's being powered down.
      
      1) ENTER PSCI timestamp is captured with caches enabled.
      
      2) The next timestamp (ENTER_HW_LOW_PWR) is captured with caches
         disabled.
      
      3) On a system that uses a write-back cache configuration, the
         cache line that holds the PMF timestamps is evicted.
      
      After step 1), the ENTER_PSCI timestamp is cached and not in main memory.
      After step 2), the ENTER_HW_LOW_PWR timestamp is stored in main memory.
      Before the CPU power down happens, the hardware evicts the cache line that
      contains the PMF timestamps for this service.  As a result, the timestamp
      captured in step 2) is overwritten with a bogus value.
      
      Change-Id: Ic1bd816498d1a6d4dc16540208ed3a5efe43f529
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      bfef6106
    • dp-arm's avatar
      user guide: Document `ENABLE_RUNTIME_INSTRUMENTATION` option · fc1d1e2d
      dp-arm authored
      
      
      Change-Id: I8e50df67e860b9589834445761a7b9927690fdce
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      fc1d1e2d
  2. 31 Oct, 2016 1 commit
  3. 28 Oct, 2016 1 commit
  4. 27 Oct, 2016 2 commits
  5. 26 Oct, 2016 3 commits
  6. 24 Oct, 2016 9 commits
  7. 21 Oct, 2016 1 commit
  8. 18 Oct, 2016 2 commits
  9. 17 Oct, 2016 4 commits
  10. 14 Oct, 2016 2 commits
  11. 13 Oct, 2016 6 commits
  12. 12 Oct, 2016 7 commits
    • danh-arm's avatar
      Merge pull request #732 from dp-arm/dp/pmf-doc · b314c9fa
      danh-arm authored
      PMF: Add documentation
      b314c9fa
    • dp-arm's avatar
      PMF: Add documentation · 514a94c2
      dp-arm authored
      
      
      Add a Performance Measurement Framework (PMF) section
      to the firmware design document.
      
      Change-Id: I5953bd3b1067501f190164c8827d2b0d8022fc0b
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      514a94c2
    • dp-arm's avatar
      Remove non-standard <sys/cdefs.h> include from uuid.h · 9e23f9ab
      dp-arm authored
      This include provides nothing useful for TF and prevents building
      the fiptool using musl libc[0].
      
      [0] https://www.musl-libc.org/
      
      
      
      Change-Id: Ied35e16b9ea2b40213433f2a8185dddc59077884
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      9e23f9ab
    • dp-arm's avatar
      Add PMF instrumentation points in TF · 872be88a
      dp-arm authored
      
      
      In order to quantify the overall time spent in the PSCI software
      implementation, an initial collection of PMF instrumentation points
      has been added.
      
      Instrumentation has been added to the following code paths:
      
      - Entry to PSCI SMC handler.  The timestamp is captured as early
        as possible during the runtime exception and stored in memory
        before entering the PSCI SMC handler.
      
      - Exit from PSCI SMC handler.  The timestamp is captured after
        normal return from the PSCI SMC handler or if a low power state
        was requested it is captured in the bl31 warm boot path before
        return to normal world.
      
      - Entry to low power state.  The timestamp is captured before entry
        to a low power state which implies either standby or power down.
        As these power states are mutually exclusive, only one timestamp
        is defined to describe both.  It is possible to differentiate between
        the two power states using the PSCI STAT interface.
      
      - Exit from low power state.  The timestamp is captured after a standby
        or power up operation has completed.
      
      To calculate the number of cycles spent running code in Trusted Firmware
      one can perform the following calculation:
      
      (exit_psci - enter_psci) - (exit_low_pwr - enter_low_pwr).
      
      The resulting number of cycles can be converted to time given the
      frequency of the counter.
      
      Change-Id: Ie3b8f3d16409b6703747093b3a2d5c7429ad0166
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      872be88a
    • dp-arm's avatar
      Introduce ARM SiP service · f10796a0
      dp-arm authored
      
      
      This patch adds ARM SiP service for use by ARM standard platforms.
      This service is added to support the SMC interface for the Performance
      measurement framework(PMF).
      
      Change-Id: I26f5712f9ab54f5f721dd4781e35a16f40aacc44
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      f10796a0
    • danh-arm's avatar
      Merge pull request #731 from danh-arm/an/fix-juno-doc · 2c8df7c1
      danh-arm authored
      Fix documentation of bootwrapper boot on juno
      2c8df7c1
    • Antonio Nino Diaz's avatar
      Fix documentation of bootwrapper boot on juno · 7486eb04
      Antonio Nino Diaz authored
      
      
      The user guide incorrectly claimed that it is possible to load a
      bootwrapped kernel over JTAG on Juno in the same manner as an EL3
      payload. In the EL3 payload boot flow, some of the platform
      initialisations in BL2 are modified. In particular, the TZC settings
      are modified to allow unrestricted access to DRAM. This in turn allows
      the debugger to access the DRAM and therefore to load the image there.
      
      In the BL33-preloaded boot flow though, BL2 uses the default TZC
      programming, which prevent access to most of the DRAM from secure state.
      When execution reaches the SPIN_ON_BL1_EXIT loop, the MMU is disabled
      and thus DS-5 presumably issues secure access transactions while trying
      to load the image, which fails.
      
      One way around it is to stop execution at the end of BL2 instead. At
      this point, the MMU is still enabled and the DRAM is mapped as
      non-secure memory. Therefore, the debugger is allowed to access this
      memory in this context and to sucessfully load the bootwrapped kernel in
      DRAM. The user guide is updated to suggest this alternative method.
      Co-Authored-By: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Signed-off-by: default avatarDan Handley <dan.handley@arm.com>
      
      Change-Id: I537ea1c6d2f96edc06bc3f512e770c748bcabe94
      7486eb04