1. 11 Dec, 2018 11 commits
  2. 10 Dec, 2018 5 commits
  3. 07 Dec, 2018 1 commit
  4. 04 Dec, 2018 2 commits
  5. 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
  6. 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
  7. 23 Nov, 2018 1 commit
  8. 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
  9. 21 Nov, 2018 1 commit
  10. 15 Nov, 2018 4 commits
  11. 12 Nov, 2018 1 commit
  12. 09 Nov, 2018 3 commits
    • Yann Gautier's avatar
      stm32mp1: remove duplicate function declaration · 7227d892
      Yann Gautier authored
      
      
      It is already in include/drivers/st/stm32mp1_ddr_helpers.h.
      Signed-off-by: default avatarYann Gautier <yann.gautier@st.com>
      7227d892
    • Yann Gautier's avatar
      stm32mp1: correct some static analysis tools issues · 3e6fab43
      Yann Gautier authored
      
      
      These issues wer found by sparse:
      
      drivers/st/clk/stm32mp1_clk.c:1524:19:
       warning: incorrect type in assignment (different base types)
          expected restricted fdt32_t const [usertype] *pkcs_cell
          got unsigned int const [usertype] *
      
      plat/st/stm32mp1/plat_image_load.c:13:6:
       warning: symbol 'plat_flush_next_bl_params' was not declared.
       Should it be static?
      plat/st/stm32mp1/plat_image_load.c:21:16:
       warning: symbol 'plat_get_bl_image_load_info' was not declared.
       Should it be static?
      plat/st/stm32mp1/plat_image_load.c:29:13:
       warning: symbol 'plat_get_next_bl_params' was not declared.
       Should it be static?
      
      plat/st/stm32mp1/bl2_io_storage.c:40:10:
       warning: symbol 'block_buffer' was not declared. Should it be static?
      Signed-off-by: default avatarYann Gautier <yann.gautier@st.com>
      3e6fab43
    • Yann Gautier's avatar
      psci: put __dead2 attribute after void in plat_psci_ops · 3c471c35
      Yann Gautier authored
      
      
      These warnings were issued by sparse:
      plat/st/stm32mp1/stm32mp1_pm.c:365:36:
       warning: incorrect type in initializer (different modifiers)
          expected void ( *[noreturn] pwr_domain_pwr_down_wfi )( ... )
          got void ( [noreturn] *<noident> )( ... )
      plat/st/stm32mp1/stm32mp1_pm.c:366:23:
       warning: incorrect type in initializer (different modifiers)
          expected void ( *[noreturn] system_off )( ... )
          got void ( [noreturn] *<noident> )( ... )
      plat/st/stm32mp1/stm32mp1_pm.c:367:25:
       warning: incorrect type in initializer (different modifiers)
          expected void ( *[noreturn] system_reset )( ... )
          got void ( [noreturn] *<noident> )( ... )
      
      This cannot be changed the other way in all platforms pm drivers
      or else there is a compilation error:
      plat/st/stm32mp1/stm32mp1_pm.c:234:1: error: attributes should be specified
       before the declarator in a function definition
      Signed-off-by: default avatarYann Gautier <yann.gautier@st.com>
      3c471c35
  13. 08 Nov, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Standardise header guards across codebase · c3cf06f1
      Antonio Nino Diaz authored
      
      
      All identifiers, regardless of use, that start with two underscores are
      reserved. This means they can't be used in header guards.
      
      The style that this project is now to use the full name of the file in
      capital letters followed by 'H'. For example, for a file called
      "uart_example.h", the header guard is UART_EXAMPLE_H.
      
      The exceptions are files that are imported from other projects:
      
      - CryptoCell driver
      - dt-bindings folders
      - zlib headers
      
      Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c3cf06f1
  14. 07 Nov, 2018 1 commit
    • Sandrine Bailleux's avatar
      Arm platforms: Fix DRAM address macros · 3d449de0
      Sandrine Bailleux authored
      
      
      On AArch32, ARM_DRAM1_BASE and ARM_DRAM1_SIZE constants are currently
      32-bit values (because they are suffixed with UL and the value
      0x80000000 fits in a unsigned long int, i.e. a 32-bit value). When
      summing them up, the result overflows the maximum value that can be
      encoded in a 32-bit value so it wraps around and does not result in
      the expected value.
      
      This patch changes the suffix of these constants into ULL so that they
      always are 64-bit values.
      
      Change-Id: I3b19b1805e35cc7e43050458df379081b1e882d5
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      3d449de0
  15. 02 Nov, 2018 3 commits