Skip to content

GitLab

Switch branch/tag
  1. 04 Jan, 2019 1 commit
  3. 03 Jan, 2019 1 commit
  5. 18 Dec, 2018 3 commits
  7. 17 Dec, 2018 1 commit
  9. 14 Dec, 2018 1 commit
    • Jeenu Viswambharan's avatar
      GIC: Remove lowest priority constants · 35cd9e81
      Jeenu Viswambharan authored 
      

The GIC lowest priority values for each world depends on the number of
priority values implemented in hardware. These constants currently
defined in gic_common.h only meant to enumerate lowest possible
architectural values. Since these values are not used in generic code or
upstream platforms, and that general use of these constants can be
wrong, remove these. Platforms should either define and use these as
appropriate, or determine correct values at run time.

Change-Id: I3805cea8ceb8a592b9eff681ea1b63b7496cec5f
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      35cd9e81
  11. 11 Dec, 2018 11 commits
  13. 10 Dec, 2018 5 commits
  15. 07 Dec, 2018 1 commit
  17. 04 Dec, 2018 2 commits
  19. 27 Nov, 2018 2 commits
    • Chandni Cherukuri's avatar
      plat/arm/common: add an additional platform power level · 0e27faf4
      Chandni Cherukuri authored 
      

For platforms using multi-threaded CPUs, there can be upto four
platform power domain levels. At present, there are three platform
power domain levels that are defined for the CSS platforms. Define a
fourth level 'ARM_PWR_LVL3' as well to provide support for an
additional platform power domain level.

Change-Id: I40cc17a10f4690a560776f504364fd7277a7e72a
Signed-off-by: default avatarChandni Cherukuri <chandni.cherukuri@arm.com>
      0e27faf4
    • Chandni Cherukuri's avatar
      plat/css: allow platforms to define the system power domain level · eff2f444
      Chandni Cherukuri authored 
      

The CSS_SYSTEM_PWR_DMN_LVL macro that defines the system power domain
level is fixed at ARM_PWR_LVL2 for all CSS platforms. However, the
system power domain level can be different for CSS platforms that
use multi-threaded CPUs.

So, in preparation towards adding support for platforms that use
multi-threaded CPUs, refactor the definition of CSS_SYSTEM_PWR_DMN_LVL
such that CSS_SYSTEM_PWR_DMN_LVL is uniquely defined for each of the
CSS platform.

Change-Id: Ia837b13f6865e71da01780993c048b45b7f36d85
Signed-off-by: default avatarChandni Cherukuri <chandni.cherukuri@arm.com>
      eff2f444
  21. 26 Nov, 2018 2 commits
    • Joel Hutton's avatar
      Initial Spectre V1 mitigations (CVE-2017-5753). · 9edd8912
      Joel Hutton authored 
      Initial Spectre Variant 1 mitigations (CVE-2017-5753).
A potential speculative data leak was found in PSCI code, this depends
on a non-robust implementation of the `plat_get_core_pos_by_mpidr()`
function. This is considered very low-risk. This patch adds a macro to
mitigate this. Note not all code paths could be analyzed with current
tools.

Add a macro which makes a variable 'speculation safe', using the
 __builtin_speculation_safe_value function of GCC and llvm. This will be
available in GCC 9, and is planned for llvm, but is not currently in
mainline GCC or llvm. In order to implement this mitigation the compiler
must support this builtin. Support is indicated by the
__HAVE_SPECULATION_SAFE_VALUE flag.

The -mtrack-speculation option maintains a 'tracker' register, which
determines if the processor is in false speculation at any point. This
adds instructions and increases code size, but avoids the performance
impact of a hard barrier.

Without the -mtrack-speculation option, __builtin_speculation_safe_value
expands to a

    ISB
    DSB SY

sequence after a conditional branch, before the
speculation safe variable is used. With -mtrack-speculation a

    CSEL tracker, tracker, XZR, [cond];
    AND safeval,tracker;
    CSDB

sequence is added instead, clearing the vulnerable variable by
AND'ing it with the tracker register, which is zero during speculative
execution. [cond] are the status flags which will only be true during
speculative execution. For more information on
__builtin_speculation_safe_value and the -mtrack-speculation option see
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/compiler-support-for-mitigations



The -mtracking option was not added, as the performance impact of the
mitigation is low, and there is only one occurence.

Change-Id: Ic9e66d1f4a5155e42e3e4055594974c230bfba3c
Signed-off-by: default avatarJoel Hutton <Joel.Hutton@Arm.com>
      9edd8912
    • Antonio Nino Diaz's avatar
      Synchronise arch.h and arch_helpers.h with TF-A-Tests · 932b3ae2
      Antonio Nino Diaz authored 
      

The headers forked at some point in the past and have diverged a lot. In
order to make it easier to share code between TF-A-Tests and TF-A, this
patch synchronises most of the definitions in the mentioned headers.

This is not a complete sync, it has to be followed by more cleanup.

This patch also removes the read helpers for the AArch32 instructions
ats1cpr and ats1hr (they are write-only).

Change-Id: Id13ecd7aeb83bd2318cd47156d71a42f1c9f6ba2
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      932b3ae2
  23. 23 Nov, 2018 1 commit
  25. 22 Nov, 2018 2 commits
    • Antonio Nino Diaz's avatar
      Revert "aarch32: Apply workaround for errata 813419 of Cortex-A57" · c4cdd9e4
      Antonio Nino Diaz authored 
      This reverts commit 6f512a3d

.

According to the 'Cortex-A57 MPCore Software Developers Errata Notice':

    This bug will only affect secure AArch64 EL3. If the above
    conditions occur, the CPU will not invalidate the targeted EL3 TLB
    entries and incorrect translations might occur.

For this reason it is not needed in AArch32.

Change-Id: I6f7b333817515499723e8f306145790ad6af9975
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c4cdd9e4
    • Antonio Nino Diaz's avatar
      xlat v2: Support mapping regions with allocated VA · 9056f108
      Antonio Nino Diaz authored 
      

Provide new APIs to add new regions without specifying the base VA.

- `mmap_add_region_alloc_va` adds a static region to mmap choosing as
  base VA the first possible address after all the currently mapped
  regions. It is aligned to an appropriate boundary in relation to the
  size and base PA of the requested region. No attempt is made to fill
  any unused VA holes.

- `mmap_add_dynamic_region_alloc_va` it adds a region the same way as
  `mmap_add_region_alloc_va` does, but it's dynamic instead of static.

- `mmap_add_alloc_va` takes an array of non const `mmap_region_t`,
  maps them in the same way as `mmap_add_region_alloc_va` and fills
  their `base_va` field. A helper macro has been created to help create
  the array, called `MAP_REGION_ALLOC_VA`.

Change-Id: I5ef3f82ca0dfd0013d2e8034aa22f13ca528ba37
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      9056f108
  27. 21 Nov, 2018 1 commit
  29. 15 Nov, 2018 4 commits
  31. 12 Nov, 2018 1 commit
  33. 09 Nov, 2018 1 commit