1. 03 Jan, 2020 1 commit
    • Vishnu Banavath's avatar
      drivers: add a driver for snoop control unit · c20c0525
      Vishnu Banavath authored
      
      
      The SCU connects one to four Cortex-A5/Cortex-A9 processors
      to the memory system through the AXI interfaces.
      
      The SCU functions are to:
      - maintain data cache coherency between the Cortex-A5/Cortex-A9
        processors
      - initiate L2 AXI memory accesses
      - arbitrate between Cortex-A5/Cortex-A9 processors requesting
        L2 accesses
      - manage ACP accesses.
      
      Snoop Control Unit will enable to snoop on other CPUs caches.
      This is very important when it comes to synchronizing data between
      CPUs. As an example, there is a high chance that data might be
      cache'd and other CPUs can't see the change. In such cases,
      if snoop control unit is enabled, data is synchoronized immediately
      between CPUs and the changes are visible to other CPUs.
      
      This driver provides functionality to enable SCU as well as enabling
      user to know the following
      - number of CPUs present
      - is a particular CPU operating in SMP mode or AMP mode
      - data cache size of a particular CPU
      - does SCU has ACP port
      - is L2CPRESENT
      
      Change-Id: I0d977970154fa60df57caf449200d471f02312a0
      Signed-off-by: default avatarVishnu Banavath <vishnu.banavath@arm.com>
      c20c0525
  2. 20 Dec, 2019 5 commits
    • Paul Beesley's avatar
      spm-mm: Remove mm_svc.h header · 962c44e7
      Paul Beesley authored
      
      
      The contents of this header have been merged into the spm_mm_svc.h
      header file.
      
      Change-Id: I01530b2e4ec1b4c091ce339758025e2216e740a4
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      962c44e7
    • Paul Beesley's avatar
      spm-mm: Refactor spm_svc.h and its contents · 0bf9f567
      Paul Beesley authored
      
      
      Change-Id: I91c192924433226b54d33e57d56d146c1c6df81b
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      0bf9f567
    • Paul Beesley's avatar
      spm-mm: Refactor secure_partition.h and its contents · aeaa225c
      Paul Beesley authored
      
      
      Before adding any new SPM-related components we should first do
      some cleanup around the existing SPM-MM implementation. The aim
      is to make sure that any SPM-MM components have names that clearly
      indicate that they are MM-related. Otherwise, when adding new SPM
      code, it could quickly become confusing as it would be unclear to
      which component the code belongs.
      
      The secure_partition.h header is a clear example of this, as the
      name is generic so it could easily apply to any SPM-related code,
      when it is in fact SPM-MM specific.
      
      This patch renames the file and the two structures defined within
      it, and then modifies any references in files that use the header.
      
      Change-Id: I44bd95fab774c358178b3e81262a16da500fda26
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      aeaa225c
    • Paul Beesley's avatar
      spm: Remove SPM Alpha 1 prototype and support files · 538b0020
      Paul Beesley authored
      
      
      The Secure Partition Manager (SPM) prototype implementation is
      being removed. This is preparatory work for putting in place a
      dispatcher component that, in turn, enables partition managers
      at S-EL2 / S-EL1.
      
      This patch removes:
      
      - The core service files (std_svc/spm)
      - The Resource Descriptor headers (include/services)
      - SPRT protocol support and service definitions
      - SPCI protocol support and service definitions
      
      Change-Id: Iaade6f6422eaf9a71187b1e2a4dffd7fb8766426
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      Signed-off-by: default avatarArtsem Artsemenka <artsem.artsemenka@arm.com>
      538b0020
    • Paul Beesley's avatar
      Remove dependency between SPM_MM and ENABLE_SPM build flags · 3f3c341a
      Paul Beesley authored
      
      
      There are two different implementations of Secure Partition
      management in TF-A. One is based on the "Management Mode" (MM)
      design, the other is based on the Secure Partition Client Interface
      (SPCI) specification. Currently there is a dependency between their
      build flags that shouldn't exist, making further development
      harder than it should be. This patch removes that
      dependency, making the two flags function independently.
      
      Before: ENABLE_SPM=1 is required for using either implementation.
              By default, the SPCI-based implementation is enabled and
              this is overridden if SPM_MM=1.
      
      After: ENABLE_SPM=1 enables the SPCI-based implementation.
             SPM_MM=1 enables the MM-based implementation.
             The two build flags are mutually exclusive.
      
      Note that the name of the ENABLE_SPM flag remains a bit
      ambiguous - this will be improved in a subsequent patch. For this
      patch the intention was to leave the name as-is so that it is
      easier to track the changes that were made.
      
      Change-Id: I8e64ee545d811c7000f27e8dc8ebb977d670608a
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      3f3c341a
  3. 19 Dec, 2019 1 commit
  4. 18 Dec, 2019 1 commit
  5. 17 Dec, 2019 2 commits
  6. 10 Dec, 2019 1 commit
    • Ambroise Vincent's avatar
      arm: gicv3: Fix compiler dependent behavior · d0196911
      Ambroise Vincent authored
      
      
      C99 standard: "What constitutes an access to an object that has
      volatile-qualified type is implementation-defined".
      
      GCC is not considering the cast to void of volatile structures as an
      access and so is not actually issuing reads.
      
      Clang does read those structures by copying them on the stack, which in
      this case creates an overflow because of their large size.
      
      This patch removes the cast to void and instead uses the USED attribute
      to tell the compiler to retain the static variables.
      
      Change-Id: I952b5056e3f6e91841e7ef9558434352710ab80d
      Signed-off-by: default avatarAmbroise Vincent <ambroise.vincent@arm.com>
      	       Zelalem Aweke <zelalem.aweke@arm.com>
      d0196911
  7. 09 Dec, 2019 2 commits
  8. 19 Nov, 2019 1 commit
  9. 18 Nov, 2019 1 commit
    • Louis Mayencourt's avatar
      ROMLIB: Optimize memory layout when ROMLIB is used · e7b39089
      Louis Mayencourt authored
      
      
      ROMLIB extract functions code from BL images to put them inside ROM.
      This has for effect to reduce the size of the BL images.
      
      This patch take this size reduction into consideration to optimize the
      memory layout of BL2.
      A new "PLAT_ARM_BL2_ROMLIB_OPTIMIZATION" macro is defined and used to
      reduce "PLAT_ARM_MAX_BL2_SIZE". This allows to remove the gap between
      BL1 and BL2 when ROMLIB is used and provides more room for BL31.
      
      The current memory gain is 0x6000 for fvp and 0x8000 for juno.
      
      Change-Id: I71c2c2c63b57bce5b22a125efaefc486ff3e87be
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      e7b39089
  10. 15 Nov, 2019 1 commit
  11. 11 Nov, 2019 1 commit
    • Manish Pandey's avatar
      n1sdp: setup multichip gic routing table · 6799a370
      Manish Pandey authored
      
      
      N1SDP supports multichip configuration wherein n1sdp boards are
      connected over high speed coherent CCIX link, for now only dual-chip
      is supported.
      
      Whether or not multiple chips are present is dynamically probed by
      SCP firmware and passed on to TF-A, routing table will be set up
      only if multiple chips are present.
      
      Initialize GIC-600 multichip operation by overriding the default GICR
      frames with array of GICR frames and setting the chip 0 as routing
      table owner.
      
      Change-Id: Ida35672be4bbf4c517469a5b330548d75e593ff2
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      6799a370
  12. 07 Nov, 2019 1 commit
  13. 05 Nov, 2019 1 commit
  14. 31 Oct, 2019 1 commit
    • Manish Pandey's avatar
      n1sdp: update platform macros for dual-chip setup · f91a8e4c
      Manish Pandey authored
      
      
      N1SDP supports multichip configuration wherein n1sdp boards are
      connected over high speed coherent CCIX link  for now only dual-chip is
      supported.
      
      A single instance of TF-A runs on master chip which should be aware of
      slave chip's CPU and memory topology.
      
      This patch updates platform macros to include remote chip's information
      and also ensures that a single version of firmware works for both single
      and dual-chip setup.
      
      Change-Id: I75799fd46dc10527aa99585226099d836c21da70
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      f91a8e4c
  15. 30 Oct, 2019 1 commit
    • Manish Pandey's avatar
      n1sdp: introduce platform information SDS region · 34c7af41
      Manish Pandey authored
      
      
      Platform information structure holds information about platform's DDR
      size(local/remote) which will be used to zero out the memory before
      enabling the ECC capability as well as information about multichip
      setup. Multichip and remote DDR information can only be probed in SCP,
      SDS region will be used by TF-A to get this information at boot up.
      
      This patch introduces a new SDS to store platform information, which is
      populated dynamically by SCP Firmware.previously used mem_info SDS is
      also made part of this structure itself.
      
      The platform information is also passed to BL33 by copying it to Non-
      Secure SRAM.
      
      Change-Id: I4781dc6a7232c3c0a3219b164d943ce9e3e469ee
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      34c7af41
  16. 21 Oct, 2019 1 commit
    • Manish Pandey's avatar
      plat/arm: use Aff3 bits also to validate mpidr · b30646a8
      Manish Pandey authored
      
      
      There are some platforms which uses MPIDR Affinity level 3 for storing
      extra affinity information e.g. N1SDP uses it for keeping chip id in a
      multichip setup, for such platforms MPIDR validation should not fail.
      
      This patch adds Aff3 bits also as part of mpidr validation mask, for
      platforms which does not uses Aff3 will not have any impact as these
      bits will be all zeros.
      
      Change-Id: Ia8273972fa7948fdb11708308d0239d2dc4dfa85
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      b30646a8
  17. 03 Oct, 2019 2 commits
  18. 02 Oct, 2019 1 commit
  19. 30 Sep, 2019 1 commit
  20. 26 Sep, 2019 1 commit
  21. 25 Sep, 2019 1 commit
    • Sandrine Bailleux's avatar
      FVP: Fix plat_set_nv_ctr() function · bd363d35
      Sandrine Bailleux authored
      The Fast Models provide a non-volatile counter component, which is used
      in the Trusted Board Boot implementation to protect against rollback
      attacks.
      
      This component comes in 2 versions (see [1]).
      
      - Version 0 is the default and models a locked non-volatile counter,
        whose value is fixed.
      
      - Version 1 of the counter may be incremented in a monotonic fashion.
      
      plat_set_nv_ctr() must cope with both versions. This is achieved by:
      1) Attempting to write the new value in the counter.
      2) Reading the value back.
      3) If there is a mismatch, we know the counter upgrade failed.
      
      When using version 0 of the counter, no upgrade is possible so the
      function is expected to fail all the time. However, the code is
      missing a compiler barrier between the write operation and the next
      read. Thus, the compiler may optimize and remove the read operation on
      the basis that the counter value has not changed. With the default
      optimization level used in TF-A (-Os), this is what's happening.
      
      The fix introduced in this patch marks the write and subsequent read
      accesses to the counter as volatile, such that the compiler makes no
      assumption about the value of the counter.
      
      Note that the comment above plat_set_nv_ctr() was clearly stating
      that when using the read-only version of the non-volatile counter,
      "we expect the values in the certificates to always match the RO
      values so that this function is never called". However, the fact that
      the counter value was read back seems to contradict this comment, as
      it is implementing a counter-measure against misuse of the
      function. The comment has been reworded to avoid any confusion.
      
      Without this patch, this bug may be demonstrated on the Base AEM FVP:
      - Using version 0 of the non-volatile counter (default version).
      - With certificates embedding a revision number value of 32
        (compiling TF-A with TFW_NVCTR_VAL=32).
      
      In this configuration, the non-volatile counter is tied to value 31 by
      default. When BL1 loads the Trusted Boot Firmware certificate, it
      notices that the two values do not match and tries to upgrade the
      non-volatile counter. This write operation is expected to fail
      (because the counter is locked) and the function is expected to return
      an error but it succeeds instead.
      
      As a result, the trusted boot does not abort as soon as it should and
      incorrectly boots BL2. The boot is finally aborted when BL2 verifies
      the BL31 image and figures out that the version of the SoC Firmware
      Key Certificate does not match. On Arm platforms, only certificates
      signed with the Root-of-Trust Key may trigger an upgrade of the
      non-volatile Trusted counter.
      
      [1] https://developer.arm.com/docs/100964/1160/fast-models-components/peripheral-components/nonvolatilecounter
      
      
      
      Change-Id: I9979f29c23b47b338b9b484013d1fb86c59db92f
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      bd363d35
  22. 23 Sep, 2019 2 commits
    • Usama Arif's avatar
      a5ds: add multicore support · ec885bac
      Usama Arif authored
      
      
      Enable cores 1-3 using psci. On receiving the smc call from kernel,
      core 0 will bring the secondary cores out pen and signal an event for
      the cores. Currently on switching the cores is enabled i.e. it is not
      possible to suspend, switch cores off, etc.
      
      Change-Id: I6087e1d2ec650e1d587fd543efc1b08cbb50ae5f
      Signed-off-by: default avatarUsama Arif <usama.arif@arm.com>
      ec885bac
    • Usama Arif's avatar
      a5ds: Hold the secondary cpus in pen rather than panic · e231f3a5
      Usama Arif authored
      
      
      For the secondary CPUs, hold the cpu in wfe rather then panic.
      This will be needed when multicore support is added to a5ds as
      the smc call will write to the hold base and signal an event to
      power on the secondary CPUs.
      
      Change-Id: I0ffc2059e9ef894c21375ca5c94def859bfa6599
      Signed-off-by: default avatarUsama Arif <usama.arif@arm.com>
      e231f3a5
  23. 13 Sep, 2019 1 commit
    • Alexei Fedorov's avatar
      Refactor ARMv8.3 Pointer Authentication support code · ed108b56
      Alexei Fedorov authored
      
      
      This patch provides the following features and makes modifications
      listed below:
      - Individual APIAKey key generation for each CPU.
      - New key generation on every BL31 warm boot and TSP CPU On event.
      - Per-CPU storage of APIAKey added in percpu_data[]
        of cpu_data structure.
      - `plat_init_apiakey()` function replaced with `plat_init_apkey()`
        which returns 128-bit value and uses Generic timer physical counter
        value to increase the randomness of the generated key.
        The new function can be used for generation of all ARMv8.3-PAuth keys
      - ARMv8.3-PAuth specific code placed in `lib\extensions\pauth`.
      - New `pauth_init_enable_el1()` and `pauth_init_enable_el3()` functions
        generate, program and enable APIAKey_EL1 for EL1 and EL3 respectively;
        pauth_disable_el1()` and `pauth_disable_el3()` functions disable
        PAuth for EL1 and EL3 respectively;
        `pauth_load_bl31_apiakey()` loads saved per-CPU APIAKey_EL1 from
        cpu-data structure.
      - Combined `save_gp_pauth_registers()` function replaces calls to
        `save_gp_registers()` and `pauth_context_save()`;
        `restore_gp_pauth_registers()` replaces `pauth_context_restore()`
        and `restore_gp_registers()` calls.
      - `restore_gp_registers_eret()` function removed with corresponding
        code placed in `el3_exit()`.
      - Fixed the issue when `pauth_t pauth_ctx` structure allocated space
        for 12 uint64_t PAuth registers instead of 10 by removal of macro
        CTX_PACGAKEY_END from `include/lib/el3_runtime/aarch64/context.h`
        and assigning its value to CTX_PAUTH_REGS_END.
      - Use of MODE_SP_ELX and MODE_SP_EL0 macro definitions
        in `msr	spsel`  instruction instead of hard-coded values.
      - Changes in documentation related to ARMv8.3-PAuth and ARMv8.5-BTI.
      
      Change-Id: Id18b81cc46f52a783a7e6a09b9f149b6ce803211
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      ed108b56
  24. 11 Sep, 2019 1 commit
    • John Tsichritzis's avatar
      Modify FVP makefile for cores that support both AArch64/32 · cd3c5b4c
      John Tsichritzis authored
      
      
      Some cores support only AArch64 from EL1 and above, e.g. A76, N1 etc. If
      TF-A is compiled with CTX_INCLUDE_AARCH32_REGS=0 so as to properly
      handle those cores, only the AArch64 cores' assembly is included in the
      TF-A binary. In other words, for FVP, TF-A assumes that AArch64 only
      cores will never exist in the same cluster with cores that also support
      AArch32.
      
      However, A55 and A75 can be used as AArch64 only cores, despite
      supporting AArch32, too. This patch enables A55 and A75 to exist in
      clusters together with AArch64 cores.
      
      Change-Id: I58750ad6c3d76ce77eb354784c2a42f2c179031d
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      cd3c5b4c
  25. 20 Aug, 2019 1 commit
    • Manish Pandey's avatar
      plat/arm: Introduce corstone700 platform. · 7bdc4698
      Manish Pandey authored
      
      
      This patch adds support for Corstone-700 foundation IP, which integrates
      both Cortex-M0+ and Cortex-A(Host) processors in one handy, flexible
      subsystem.
      This is an example implementation of Corstone-700 IP host firmware.
      
      Cortex-M0+ will take care of boot stages 1 and 2(BL1/BL2) as well as
      bringing Host out RESET. Host will start execution directly from BL32 and
      then will jump to Linux.
      
      It is an initial port and additional features are expected to be added
      later.
      
      Change-Id: I7b5c0278243d574284b777b2408375d007a7736e
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      7bdc4698
  26. 16 Aug, 2019 1 commit
    • Alexei Fedorov's avatar
      FVP: Add Delay Timer driver to BL1 and BL31 · 1b597c22
      Alexei Fedorov authored
      
      
      SMMUv3 driver functions which are called from BL1 and BL31
      currently use counter-based poll method for testing status
      bits. Adding Delay Timer driver to BL1 and BL31 is required
      for timeout-based implementation using timer delay functions
      for SMMU and other drivers.
      This patch adds new function `fvp_timer_init()` which
      initialises either System level generic or SP804 timer based on
      FVP_USE_SP804_TIMER build flag.
      In BL2U `bl2u_early_platform_setup()` function the call to
      `arm_bl2u_early_platform_setup()` (which calls
      `generic_delay_timer_init()` ignoring FVP_USE_SP804_TIMER flag),
      is replaced with `arm_console_boot_init()` and `fvp_timer_init()`.
      
      Change-Id: Ifd8dcebf4019e877b9bc5641551deef77a44c0d1
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      1b597c22
  27. 13 Aug, 2019 2 commits
  28. 01 Aug, 2019 2 commits
    • Julius Werner's avatar
      Switch AARCH32/AARCH64 to __aarch64__ · 402b3cf8
      Julius Werner authored
      
      
      NOTE: AARCH32/AARCH64 macros are now deprecated in favor of __aarch64__.
      
      All common C compilers pre-define the same macros to signal which
      architecture the code is being compiled for: __arm__ for AArch32 (or
      earlier versions) and __aarch64__ for AArch64. There's no need for TF-A
      to define its own custom macros for this. In order to unify code with
      the export headers (which use __aarch64__ to avoid another dependency),
      let's deprecate the AARCH32 and AARCH64 macros and switch the code base
      over to the pre-defined standard macro. (Since it is somewhat
      unintuitive that __arm__ only means AArch32, let's standardize on only
      using __aarch64__.)
      
      Change-Id: Ic77de4b052297d77f38fc95f95f65a8ee70cf200
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      402b3cf8
    • Julius Werner's avatar
      Replace __ASSEMBLY__ with compiler-builtin __ASSEMBLER__ · d5dfdeb6
      Julius Werner authored
      
      
      NOTE: __ASSEMBLY__ macro is now deprecated in favor of __ASSEMBLER__.
      
      All common C compilers predefine a macro called __ASSEMBLER__ when
      preprocessing a .S file. There is no reason for TF-A to define it's own
      __ASSEMBLY__ macro for this purpose instead. To unify code with the
      export headers (which use __ASSEMBLER__ to avoid one extra dependency),
      let's deprecate __ASSEMBLY__ and switch the code base over to the
      predefined standard.
      
      Change-Id: Id7d0ec8cf330195da80499c68562b65cb5ab7417
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      d5dfdeb6
  29. 25 Jul, 2019 2 commits