Skip to content

GitLab

Switch branch/tag
  1. 18 Jan, 2019 3 commits
  3. 15 Jan, 2019 2 commits
    • Antonio Nino Diaz's avatar
      plat/arm: Fix header dependencies · 234bc7f8
      Antonio Nino Diaz authored 
      

From now on, platform_def.h must include any header with definitions that
are platform-specific (like arm_def.h) and the included headers mustn't
include back platform_def.h, and shouldn't be used by other files. Only
platform_def.h should be included in other files. This will ensure that all
needed definitions are present, rather than needing to include all the
headers in all the definitions' headers just in case.

This also prevents problems like cyclic dependencies.

Change-Id: I9d3cf4d1de4b956fa035c79545222697acdaf5ca
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      234bc7f8
    • Antonio Nino Diaz's avatar
      Move BL1 and BL2 private defines to bl_common.h · c9f9d9ea
      Antonio Nino Diaz authored 
      

The definitions in bl1/bl1_private.h and bl2/bl2_private.h are useful for
platforms that may need to access them.

Change-Id: Ifd1880f855ddafcb3bfcaf1ed4a4e0f121eda174
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c9f9d9ea
  5. 11 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      xlat v2: Dynamically detect need for CnP bit · 2559b2c8
      Antonio Nino Diaz authored 
      

ARMv8.2-TTCNP is mandatory from ARMv8.2 onwards, but it can be implemented
in CPUs that don't implement all mandatory 8.2 features (and so have to
claim to be a lower version).

This patch removes usage of the ARM_ARCH_AT_LEAST() macro and uses system
ID registers to detect whether it is needed to set the bit or not.

Change-Id: I7bcbf0c7c937590dfc2ca668cfd9267c50f7d52c
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2559b2c8
  7. 08 Jan, 2019 1 commit
  9. 07 Jan, 2019 2 commits
  11. 04 Jan, 2019 3 commits
    • Antonio Nino Diaz's avatar
      Sanitise includes across codebase · 09d40e0e
      Antonio Nino Diaz authored 
      Enforce full include path for includes. Deprecate old paths.

The following folders inside include/lib have been left unchanged:

- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}

The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).

For example, this patch had to be created because two headers were
called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3 ("drivers: add tzc380 support").

This problem was introduced in commit 4ecca339

 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.

Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.

Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      09d40e0e
    • Antonio Nino Diaz's avatar
      Reorganize architecture-dependent header files · f5478ded
      Antonio Nino Diaz authored 
      

The architecture dependant header files in include/lib/${ARCH} and
include/common/${ARCH} have been moved to /include/arch/${ARCH}.

Change-Id: I96f30fdb80b191a51448ddf11b1d4a0624c03394
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      f5478ded
    • Antonio Nino Diaz's avatar
      plat/arm: Always define TSP memory region · 07146afb
      Antonio Nino Diaz authored 
      

Even though this is not used unless SPD=tspd, only defining it when
SPD_tspd is defined doesn't have any advantage and it makes it harder to
read the code.

Change-Id: I3d93135e05f39be071d16f8a47394a9a3ff54bc8
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      07146afb
  13. 03 Jan, 2019 1 commit
  15. 18 Dec, 2018 3 commits
  17. 17 Dec, 2018 1 commit
  19. 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
  21. 11 Dec, 2018 11 commits
  23. 10 Dec, 2018 5 commits
  25. 07 Dec, 2018 1 commit
  27. 04 Dec, 2018 2 commits
  29. 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
  31. 26 Nov, 2018 1 commit
    • 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