1. 08 Jan, 2018 1 commit
  2. 12 Dec, 2017 1 commit
    • Sandrine Bailleux's avatar
      SPM: Fix MM_COMMUNICATE_AARCH32/64 parameters · 4d2787ce
      Sandrine Bailleux authored
      This partially reverts commit d6b532b5
      
      , keeping only the fixes to
      the assertions. The changes related to the order of arguments passed
      to the secure partition were not correct and violated the
      specification of the SP_EVENT_COMPLETE SMC.
      
      This patch also improves the MM_COMMUNICATE argument validation.  The
      cookie argument, as it comes from normal world, can't be trusted and thus
      needs to always be validated at run time rather than using an assertion.
      
      Also validate the communication buffer address and return
      INVALID_PARAMETER if it is zero, as per the MM specification.
      
      Fix a few typos in comments and use the "secure partition" terminology
      rather than "secure payload".
      
      Change-Id: Ice6b7b5494b729dd44611f9a93d362c55ab244f7
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      4d2787ce
  3. 06 Dec, 2017 3 commits
  4. 05 Dec, 2017 2 commits
  5. 20 Nov, 2017 2 commits
  6. 15 Nov, 2017 2 commits
  7. 13 Nov, 2017 3 commits
  8. 10 Nov, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Fix pointer to MP info in boot info struct · ff7d0805
      Antonio Nino Diaz authored
      
      
      The MP info struct is placed right after the boot info struct. However,
      when calculating the address of the MP info, the size of the boot info
      struct was being multiplied by the size of the MP boot info. This left
      a big gap of empty space between the structs.
      
      This didn't break any code because the boot info struct has a pointer to
      the MP info struct. It was just wasting space.
      
      Change-Id: I1668e3540d9173261968f6740623549000bd48db
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      ff7d0805
  9. 08 Nov, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Introduce Secure Partition Manager · 2fccb228
      Antonio Nino Diaz authored
      
      
      A Secure Partition is a software execution environment instantiated in
      S-EL0 that can be used to implement simple management and security
      services. Since S-EL0 is an unprivileged exception level, a Secure
      Partition relies on privileged firmware e.g. ARM Trusted Firmware to be
      granted access to system and processor resources. Essentially, it is a
      software sandbox that runs under the control of privileged software in
      the Secure World and accesses the following system resources:
      
      - Memory and device regions in the system address map.
      - PE system registers.
      - A range of asynchronous exceptions e.g. interrupts.
      - A range of synchronous exceptions e.g. SMC function identifiers.
      
      A Secure Partition enables privileged firmware to implement only the
      absolutely essential secure services in EL3 and instantiate the rest in
      a partition. Since the partition executes in S-EL0, its implementation
      cannot be overly complex.
      
      The component in ARM Trusted Firmware responsible for managing a Secure
      Partition is called the Secure Partition Manager (SPM). The SPM is
      responsible for the following:
      
      - Validating and allocating resources requested by a Secure Partition.
      - Implementing a well defined interface that is used for initialising a
        Secure Partition.
      - Implementing a well defined interface that is used by the normal world
        and other secure services for accessing the services exported by a
        Secure Partition.
      - Implementing a well defined interface that is used by a Secure
        Partition to fulfil service requests.
      - Instantiating the software execution environment required by a Secure
        Partition to fulfil a service request.
      
      Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Co-authored-by: default avatarAchin Gupta <achin.gupta@arm.com>
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2fccb228
  10. 03 May, 2017 1 commit
  11. 03 Nov, 2016 1 commit
    • 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
  12. 12 Oct, 2016 1 commit
    • 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
  13. 22 Sep, 2016 1 commit
    • Soby Mathew's avatar
      PSCI: Do psci_setup() as part of std_svc_setup() · 58e946ae
      Soby Mathew authored
      This patch moves the invocation of `psci_setup()` from BL31 and SP_MIN
      into `std_svc_setup()` as part of ARM Standard Service initialization.
      This allows us to consolidate ARM Standard Service initializations which
      will be added to in the future. A new function `get_arm_std_svc_args()`
      is introduced to get arguments corresponding to each standard service.
      This function must be implemented by the EL3 Runtime Firmware and both
      SP_MIN and BL31 implement it.
      
      Change-Id: I38e1b644f797fa4089b20574bd4a10f0419de184
      58e946ae
  14. 19 Jul, 2016 1 commit
    • Soby Mathew's avatar
      Introduce PSCI Library Interface · cf0b1492
      Soby Mathew authored
      This patch introduces the PSCI Library interface. The major changes
      introduced are as follows:
      
      * Earlier BL31 was responsible for Architectural initialization during cold
      boot via bl31_arch_setup() whereas PSCI was responsible for the same during
      warm boot. This functionality is now consolidated by the PSCI library
      and it does Architectural initialization via psci_arch_setup() during both
      cold and warm boots.
      
      * Earlier the warm boot entry point was always `psci_entrypoint()`. This was
      not flexible enough as a library interface. Now PSCI expects the runtime
      firmware to provide the entry point via `psci_setup()`. A new function
      `bl31_warm_entrypoint` is introduced in BL31 and the previous
      `psci_entrypoint()` is deprecated.
      
      * The `smc_helpers.h` is reorganized to separate the SMC Calling Convention
      defines from the Trusted Firmware SMC helpers. The former is now in a new
      header file `smcc.h` and the SMC helpers are moved to Architecture specific
      header.
      
      * The CPU context is used by PSCI for context initialization and
      restoration after power down (PSCI Context). It is also used by BL31 for SMC
      handling and context management during Normal-Secure world switch (SMC
      Context). The `psci_smc_handler()` interface is redefined to not use SMC
      helper macros thus enabling to decouple the PSCI context from EL3 runtime
      firmware SMC context. This enables PSCI to be integrated with other runtime
      firmware using a different SMC context.
      
      NOTE: With this patch the architectural setup done in `bl31_arch_setup()`
      is done as part of `psci_setup()` and hence `bl31_platform_setup()` will be
      invoked prior to architectural setup. It is highly unlikely that the platform
      setup will depend on architectural setup and cause any failure. Please be
      be aware of this change in sequence.
      
      Change-Id: I7f497a08d33be234bbb822c28146250cb20dab73
      cf0b1492
  15. 18 Jul, 2016 3 commits
    • Soby Mathew's avatar
      Introduce `el3_runtime` and `PSCI` libraries · 532ed618
      Soby Mathew authored
      This patch moves the PSCI services and BL31 frameworks like context
      management and per-cpu data into new library components `PSCI` and
      `el3_runtime` respectively. This enables PSCI to be built independently from
      BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant
      PSCI library sources and gets included by `bl31.mk`. Other changes which
      are done as part of this patch are:
      
      * The runtime services framework is now moved to the `common/` folder to
        enable reuse.
      * The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture
        specific folder.
      * The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder
        to `plat/common` folder. The original file location now has a stub which
        just includes the file from new location to maintain platform compatibility.
      
      Most of the changes wouldn't affect platform builds as they just involve
      changes to the generic bl1.mk and bl31.mk makefiles.
      
      NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT
      THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR
      MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION.
      
      Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86
      532ed618
    • Soby Mathew's avatar
      Fix coding guideline warnings · da554d74
      Soby Mathew authored
      This patch fixes some coding guideline warnings reported by the checkpatch
      script. Only files related to upcoming feature development have been fixed.
      
      Change-Id: I26fbce75c02ed62f00493ed6c106fe7c863ddbc5
      da554d74
    • Soby Mathew's avatar
      Rework type usage in Trusted Firmware · 4c0d0390
      Soby Mathew authored
      This patch reworks type usage in generic code, drivers and ARM platform files
      to make it more portable. The major changes done with respect to
      type usage are as listed below:
      
      * Use uintptr_t for storing address instead of uint64_t or unsigned long.
      * Review usage of unsigned long as it can no longer be assumed to be 64 bit.
      * Use u_register_t for register values whose width varies depending on
        whether AArch64 or AArch32.
      * Use generic C types where-ever possible.
      
      In addition to the above changes, this patch also modifies format specifiers
      in print invocations so that they are AArch64/AArch32 agnostic. Only files
      related to upcoming feature development have been reworked.
      
      Change-Id: I9f8c78347c5a52ba7027ff389791f1dad63ee5f8
      4c0d0390
  16. 16 Jun, 2016 1 commit
    • Yatharth Kochar's avatar
      Add optional PSCI STAT residency & count functions · 170fb93d
      Yatharth Kochar authored
      This patch adds following optional PSCI STAT functions:
      
      - PSCI_STAT_RESIDENCY: This call returns the amount of time spent
        in power_state in microseconds, by the node represented by the
        `target_cpu` and the highest level of `power_state`.
      
      - PSCI_STAT_COUNT: This call returns the number of times a
        `power_state` has been used by the node represented by the
        `target_cpu` and the highest power level of `power_state`.
      
      These APIs provides residency statistics for power states that has
      been used by the platform. They are implemented according to v1.0
      of the PSCI specification.
      
      By default this optional feature is disabled in the PSCI
      implementation. To enable it, set the boolean flag
      `ENABLE_PSCI_STAT` to 1. This also sets `ENABLE_PMF` to 1.
      
      Change-Id: Ie62e9d37d6d416ccb1813acd7f616d1ddd3e8aff
      170fb93d
  17. 25 May, 2016 1 commit
    • Soby Mathew's avatar
      PSCI: Add pwr_domain_pwr_down_wfi() hook in plat_psci_ops · ac1cc8eb
      Soby Mathew authored
      This patch adds a new optional platform hook `pwr_domain_pwr_down_wfi()` in
      the plat_psci_ops structure. This hook allows the platform to perform platform
      specific actions including the wfi invocation to enter powerdown. This hook
      is invoked by both psci_do_cpu_off() and psci_cpu_suspend_start() functions.
      The porting-guide.md is also updated for the same.
      
      This patch also modifies the `psci_power_down_wfi()` function to invoke
      `plat_panic_handler` incase of panic instead of the busy while loop.
      
      Fixes ARM-Software/tf-issues#375
      
      Change-Id: Iba104469a1445ee8d59fb3a6fdd0a98e7f24dfa3
      ac1cc8eb
  18. 20 May, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Add 32 bit version of plat_get_syscnt_freq · d4486391
      Antonio Nino Diaz authored
      Added plat_get_syscnt_freq2, which is a 32 bit variant of the 64 bit
      plat_get_syscnt_freq. The old one has been flagged as deprecated.
      Common code has been updated to use this new version. Porting guide
      has been updated.
      
      Change-Id: I9e913544926c418970972bfe7d81ee88b4da837e
      d4486391
  19. 25 Apr, 2016 2 commits
  20. 08 Feb, 2016 1 commit
    • Soby Mathew's avatar
      PSCI: Resolve GCC static analysis false positive · 6d18969f
      Soby Mathew authored
      When BL31 is compiled at `-O3` optimization level using Linaro GCC 4.9
      AArch64 toolchain, it reports the following error:
      
      ```
      services/std_svc/psci/psci_common.c: In function 'psci_do_state_coordination':
      services/std_svc/psci/psci_common.c:220:27: error: array subscript is above
      array bounds [-Werror=array-bounds]
        psci_req_local_pwr_states[pwrlvl - 1][cpu_idx] = req_pwr_state;
                                 ^
      ```
      
      This error is a false positive and this patch resolves the error by asserting
      the array bounds in `psci_do_state_coordination()`.
      
      Fixes ARM-software/tf-issues#347
      
      Change-Id: I3584ed7b2e28faf455b082cb3281d6e1d11d6495
      6d18969f
  21. 01 Feb, 2016 1 commit
    • Soby Mathew's avatar
      Fix PSCI CPU ON race when setting state to ON_PENDING · 203cdfe2
      Soby Mathew authored
      When a CPU is powered down using PSCI CPU OFF API, it disables its caches
      and updates its `aff_info_state` to OFF. The corresponding cache line is
      invalidated by the CPU so that the update will be observed by other CPUs
      running with caches enabled. There is a possibility that another CPU
      which has been trying to turn ON this CPU via PSCI CPU ON API,
      has already seen the update to `aff_info_state` and proceeds to update
      the state to ON_PENDING prior to the cache invalidation. This may result
      in the update of the state to ON_PENDING being discarded.
      
      This patch fixes this issue by making sure that the update of `aff_info_state`
      to ON_PENDING sticks by reading back the value after the cache flush and
      retrying it if not updated. The patch also adds a dsbish() to
      `psci_do_cpu_off()` to ensure ordering of the update to `aff_info_state`
      prior to cache line invalidation.
      
      Fixes ARM-software/tf-issues#349
      
      Change-Id: I225de99957fe89871f8c57bcfc243956e805dcca
      203cdfe2
  22. 14 Jan, 2016 1 commit
  23. 21 Dec, 2015 1 commit
  24. 14 Dec, 2015 1 commit
  25. 06 Oct, 2015 1 commit
    • Soby Mathew's avatar
      PSCI: Update state only if CPU_OFF is not denied by SPD · 16e05cdb
      Soby Mathew authored
      This patch fixes an issue in the PSCI framework where the affinity info
      state of a core was being set to OFF even when the SPD had denied the
      CPU_OFF request. Now, the state remains set to ON instead.
      
      Fixes ARM-software/tf-issues#323
      
      Change-Id: Ia9042aa41fae574eaa07fd2ce3f50cf8cae1b6fc
      16e05cdb
  26. 14 Sep, 2015 1 commit
    • Achin Gupta's avatar
      Make generic code work in presence of system caches · 54dc71e7
      Achin Gupta authored
      On the ARMv8 architecture, cache maintenance operations by set/way on the last
      level of integrated cache do not affect the system cache. This means that such a
      flush or clean operation could result in the data being pushed out to the system
      cache rather than main memory. Another CPU could access this data before it
      enables its data cache or MMU. Such accesses could be serviced from the main
      memory instead of the system cache. If the data in the sysem cache has not yet
      been flushed or evicted to main memory then there could be a loss of
      coherency. The only mechanism to guarantee that the main memory will be updated
      is to use cache maintenance operations to the PoC by MVA(See section D3.4.11
      (System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G).
      
      This patch removes the reliance of Trusted Firmware on the flush by set/way
      operation to ensure visibility of data in the main memory. Cache maintenance
      operations by MVA are now used instead. The following are the broad category of
      changes:
      
      1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is
         initialised. This ensures that any stale cache lines at any level of cache
         are removed.
      
      2. Updates to global data in runtime firmware (BL31) by the primary CPU are made
         visible to secondary CPUs using a cache clean operation by MVA.
      
      3. Cache maintenance by set/way operations are only used prior to power down.
      
      NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN
      ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES.
      
      Fixes ARM-software/tf-issues#205
      
      Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a
      54dc71e7
  27. 11 Sep, 2015 1 commit
    • Andrew Thoelke's avatar
      Re-design bakery lock memory allocation and algorithm · ee7b35c4
      Andrew Thoelke authored
      This patch unifies the bakery lock api's across coherent and normal
      memory implementation of locks by using same data type `bakery_lock_t`
      and similar arguments to functions.
      
      A separate section `bakery_lock` has been created and used to allocate
      memory for bakery locks using `DEFINE_BAKERY_LOCK`. When locks are
      allocated in normal memory, each lock for a core has to spread
      across multiple cache lines. By using the total size allocated in a
      separate cache line for a single core at compile time, the memory for
      other core locks is allocated at link time by multiplying the single
      core locks size with (PLATFORM_CORE_COUNT - 1). The normal memory lock
      algorithm now uses lock address instead of the `id` in the per_cpu_data.
      For locks allocated in coherent memory, it moves locks from
      tzfw_coherent_memory to bakery_lock section.
      
      The bakery locks are allocated as part of bss or in coherent memory
      depending on usage of coherent memory. Both these regions are
      initialised to zero as part of run_time_init before locks are used.
      Hence, bakery_lock_init() is made an empty function as the lock memory
      is already initialised to zero.
      
      The above design lead to the removal of psci bakery locks from
      non_cpu_power_pd_node to psci_locks.
      
      NOTE: THE BAKERY LOCK API WHEN USE_COHERENT_MEM IS NOT SET HAS CHANGED.
      THIS IS A BREAKING CHANGE FOR ALL PLATFORM PORTS THAT ALLOCATE BAKERY
      LOCKS IN NORMAL MEMORY.
      
      Change-Id: Ic3751c0066b8032dcbf9d88f1d4dc73d15f61d8b
      ee7b35c4
  28. 10 Sep, 2015 1 commit
    • Achin Gupta's avatar
      Pass the target suspend level to SPD suspend hooks · f1054c93
      Achin Gupta authored
      In certain Trusted OS implementations it is a requirement to pass them the
      highest power level which will enter a power down state during a PSCI
      CPU_SUSPEND or SYSTEM_SUSPEND API invocation. This patch passes this power level
      to the SPD in the "max_off_pwrlvl" parameter of the svc_suspend() hook.
      
      Currently, the highest power level which was requested to be placed in a low
      power state (retention or power down) is passed to the SPD svc_suspend_finish()
      hook. This hook is called after emerging from the low power state. It is more
      useful to pass the highest power level which was powered down instead. This
      patch does this by changing the semantics of the parameter passed to an SPD's
      svc_suspend_finish() hook. The name of the parameter has been changed from
      "suspend_level" to "max_off_pwrlvl" as well. Same changes have been made to the
      parameter passed to the tsp_cpu_resume_main() function.
      
      NOTE: THIS PATCH CHANGES THE SEMANTICS OF THE EXISTING "svc_suspend_finish()"
            API BETWEEN THE PSCI AND SPD/SP IMPLEMENTATIONS. THE LATTER MIGHT NEED
            UPDATES TO ENSURE CORRECT BEHAVIOUR.
      
      Change-Id: If3a9d39b13119bbb6281f508a91f78a2f46a8b90
      f1054c93
  29. 13 Aug, 2015 2 commits
    • Soby Mathew's avatar
      PSCI: Rework generic code to conform to coding guidelines · 9d070b99
      Soby Mathew authored
      This patch reworks the PSCI generic implementation to conform to ARM
      Trusted Firmware coding guidelines as described here:
      https://github.com/ARM-software/arm-trusted-firmware/wiki
      
      This patch also reviews the use of signed data types within PSCI
      Generic code and replaces them with their unsigned counterparts wherever
      they are not appropriate. The PSCI_INVALID_DATA macro which was defined
      to -1 is now replaced with PSCI_INVALID_PWR_LVL macro which is defined
      to PLAT_MAX_PWR_LVL + 1.
      
      Change-Id: Iaea422d0e46fc314e0b173c2b4c16e0d56b2515a
      9d070b99
    • Soby Mathew's avatar
      PSCI: Fix the return code for invalid entrypoint · 617540d8
      Soby Mathew authored
      As per PSCI1.0 specification, the error code to be returned when an invalid
      non secure entrypoint address is specified by the PSCI client for CPU_SUSPEND,
      CPU_ON or SYSTEM_SUSPEND must be PSCI_E_INVALID_ADDRESS. The current PSCI
      implementation returned PSCI_E_INVAL_PARAMS. This patch rectifies this error
      and also implements a common helper function to validate the entrypoint
      information to be used across these PSCI API implementations.
      
      Change-Id: I52d697d236c8bf0cd3297da4008c8e8c2399b170
      617540d8