1. 09 Feb, 2021 2 commits
    • Manish V Badarkhe's avatar
      plat/arm: fvp: Protect GICR frames for fused/unused cores · f98630fb
      Manish V Badarkhe authored
      
      
      Currently, BLs are mapping the GIC memory region as read-write
      for all cores on boot-up.
      
      This opens up the security hole where the active core can write
      the GICR frame of fused/inactive core. To avoid this issue, disable
      the GICR frame of all inactive cores as below:
      
      1. After primary CPU boots up, map GICR region of all cores as
         read-only.
      2. After primary CPU boots up, map its GICR region as read-write
         and initialize its redistributor interface.
      3. After secondary CPU boots up, map its GICR region as read-write
         and initialize its redistributor interface.
      4. All unused/fused core's redistributor regions remain read-only and
         write attempt to such protected regions results in an exception.
      
      As mentioned above, this patch offers only the GICR memory-mapped
      region protection considering there is no facility at the GIC IP
      level to avoid writing the redistributor area.
      
      These changes are currently done in BL31 of Arm FVP and guarded under
      the flag 'FVP_GICR_REGION_PROTECTION'.
      
      As of now, this patch is tested manually as below:
      1. Disable the FVP cores (core 1, 2, 3) with core 0 as an active core.
      2. Verify data abort triggered by manually updating the ‘GICR_CTLR’
         register of core 1’s(fused) redistributor from core 0(active).
      
      Change-Id: I86c99c7b41bae137b2011cf2ac17fad0a26e776d
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      f98630fb
    • Manish V Badarkhe's avatar
      plat/arm: fvp: Do not map GIC region in BL1 and BL2 · e0cea783
      Manish V Badarkhe authored
      
      
      GIC memory region is not getting used in BL1 and BL2.
      Hence avoid its mapping in BL1 and BL2 that freed some
      page table entries to map other memory regions in the
      future.
      
      Retains mapping of CCN interconnect region in BL1 and BL2
      overlapped with the GIC memory region.
      
      Change-Id: I880dd0690f94b140e59e4ff0c0d436961b9cb0a7
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      e0cea783
  2. 18 Aug, 2020 1 commit
  3. 17 Aug, 2020 1 commit
  4. 31 Jul, 2020 1 commit
  5. 17 Mar, 2020 1 commit
    • Madhukar Pappireddy's avatar
      FVP: In BL31/SP_MIN, map only the needed DRAM region statically · 493545b3
      Madhukar Pappireddy authored
      
      
      Rather than creating entry in plat_arm_mmap array to map the
      entire DRAM region in BL31/SP_MIN, only map a smaller region holding
      HW_CONFIG DTB. Consequently, an increase in number of sub-translation
      tables(level-2 and level-3) i.e., MAX_XLAT_TABLES is necessary to map
      the new region in memory.
      
      In order to accommodate the increased code size in BL31 i.e.,
      PROGBITS, the max size of BL31 image is increased by 0x1000(4K).
      
      Change-Id: I540b8ee550588e22a3a9fb218183d2ab8061c851
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      493545b3
  6. 11 Mar, 2020 1 commit
    • Madhukar Pappireddy's avatar
      fconf: necessary modifications to support fconf in BL31 & SP_MIN · 26d1e0c3
      Madhukar Pappireddy authored
      
      
      Necessary infrastructure added to integrate fconf framework in BL31 & SP_MIN.
      Created few populator() functions which parse HW_CONFIG device tree
      and registered them with fconf framework. Many of the changes are
      only applicable for fvp platform.
      
      This patch:
      1. Adds necessary symbols and sections in BL31, SP_MIN linker script
      2. Adds necessary memory map entry for translation in BL31, SP_MIN
      3. Creates an abstraction layer for hardware configuration based on
         fconf framework
      4. Adds necessary changes to build flow (makefiles)
      5. Minimal callback to read hw_config dtb for capturing properties
         related to GIC(interrupt-controller node)
      6. updates the fconf documentation
      
      Change-Id: Ib6292071f674ef093962b9e8ba0d322b7bf919af
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      26d1e0c3
  7. 10 Feb, 2020 1 commit
  8. 20 Dec, 2019 3 commits
    • 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
  9. 18 Dec, 2019 1 commit
  10. 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
  11. 01 Aug, 2019 1 commit
    • 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
  12. 25 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Sanitise includes · bd9344f6
      Antonio Nino Diaz authored
      
      
      Use full include paths like it is done for common includes.
      
      This cleanup was started in commit d40e0e08283a ("Sanitise includes
      across codebase"), but it only cleaned common files and drivers. This
      patch does the same to Arm platforms.
      
      Change-Id: If982e6450bbe84dceb56d464e282bcf5d6d9ab9b
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      bd9344f6
  13. 22 Jan, 2019 1 commit
  14. 15 Jan, 2019 1 commit
    • 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
  15. 08 Jan, 2019 1 commit
  16. 04 Jan, 2019 1 commit
    • 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
  17. 11 Dec, 2018 1 commit
  18. 10 Dec, 2018 2 commits
  19. 06 Nov, 2018 1 commit
  20. 26 Oct, 2018 2 commits
    • Roberto Vargas's avatar
      Convert arm_setup_page_tables into a generic helper · 0916c38d
      Roberto Vargas authored
      
      
      This function is not related to Arm platforms and can be reused by other
      platforms if needed.
      
      Change-Id: Ia9c328ce57ce7e917b825a9e09a42b0abb1a53e8
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      0916c38d
    • Antonio Nino Diaz's avatar
      xlat: Fix compatibility between v1 and v2 · 03987d01
      Antonio Nino Diaz authored
      
      
      There are several platforms using arm_setup_page_tables(), which is
      supposed to be Arm platform only. This creates several dependency
      problems between platforms.
      
      This patch adds the definition XLAT_TABLES_LIB_V2 to the xlat tables lib
      v2 makefile. This way it is possible to detect from C code which version
      is being used and include the correct header.
      
      The file arm_xlat_tables.h has been renamed to xlat_tables_compat.h and
      moved to a common folder. This way, when in doubt, this header can be
      used to guarantee compatibility, as it includes the correct header based
      on XLAT_TABLES_LIB_V2.
      
      This patch also removes the usage of ARM_XLAT_TABLES_V1 from QEMU (so
      that is now locked in xlat lib v2) and ZynqMP (where it was added as a
      workaround).
      
      Change-Id: Ie1e22a23b44c549603d1402a237a70d0120d3e04
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      03987d01
  21. 03 Oct, 2018 1 commit
  22. 28 Sep, 2018 1 commit
  23. 04 Sep, 2018 1 commit
    • John Tsichritzis's avatar
      Support shared Mbed TLS heap for FVP · ba597da7
      John Tsichritzis authored
      
      
      This patch introduces the shared Mbed TLS heap optimisation for Arm
      platforms. The objective is the Mbed TLS heap to be shared between BL1
      and BL2 so as to not allocate the heap memory twice. To achieve that,
      the patch introduces all the necessary helpers for implementing this
      optimisation. It also applies it for FVP.
      
      Change-Id: I6d85eaa1361517b7490956b2ac50f5fa0d0bb008
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      ba597da7
  24. 15 Mar, 2018 1 commit
  25. 28 Feb, 2018 1 commit
  26. 29 Jan, 2018 1 commit
    • Sandrine Bailleux's avatar
      SPM: Map devices in the 1st GB · c4fa1739
      Sandrine Bailleux authored
      
      
      This patch maps the devices in the first GB of the system address map
      on the FVP into the S-EL1&0 translation regime when SPM support is
      enabled. This grants the Secure Partition access to the devices in
      this region, for example the memory-mapped Generic Timer device.
      
      Change-Id: I3aeea65f859ecbe83efde2acee20c55500c451bc
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      c4fa1739
  27. 09 Nov, 2017 1 commit
  28. 11 Oct, 2017 1 commit
    • Soby Mathew's avatar
      ARM platforms: enable GICv3 state save/restore · e35a3fb5
      Soby Mathew authored
      
      
      Provides GICv3 save/restore feature to arm_system_pwr_domain_resume and
      arm_system_pwr_domain_save functions.
      
      Introduce FVP PSCI power level 3 (System level) support. This is solely
      done to provide example code on how to use the GICv3 save and restore
      helpers.
      
      Also make CSS GICv3 platforms power off the Redistributor on SYSTEM
      SUSPEND as its state is saved and restored.
      
      Change-Id: I0d852f3af8824edee1a17c085cf593ddd33a4e77
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Co-Authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      e35a3fb5
  29. 25 Sep, 2017 2 commits
    • Roberto Vargas's avatar
      mem_protect: Add DRAM2 to the list of mem protected ranges · b09ba056
      Roberto Vargas authored
      
      
      On ARM platforms, the maximum size of the address space is limited
      to 32-bits as defined in arm_def.h. In order to access DRAM2, which
      is defined beyond the 32-bit address space, the maximum address space
      is increased to 36-bits in AArch64. It is possible to increase the
      virtual space for AArch32, but it is more difficult and not supported
      for now.
      
      NOTE - the actual maximum memory address space is platform dependent
      and is checked at run-time by querying the PARange field in the
      ID_AA64MMFR0_EL1 register.
      
      Change-Id: I6cb05c78a63b1fed96db9a9773faca04a5b93d67
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      b09ba056
    • Roberto Vargas's avatar
      mem_protect: Add mem_protect support in Juno and FVP for DRAM1 · f145403c
      Roberto Vargas authored
      
      
      mem_protect needs some kind of non-volatile memory because it has
      to remember its state across reset and power down events.
      The most suitable electronic part for this feature is a NVRAM
      which should be only accesible from the secure world. Juno and
      FVP lack such hardware and for this reason the MEM_PROTECT
      functionality is implemented with Flash EEPROM memory on both
      boards, even though this memory is accesible from the non-secure
      world. This is done only to show a full implementation of
      these PSCI features, but an actual system shouldn't use a
      non-secure NVRAM to implement it.
      
      The EL3 runtime software will write the mem_protect flag and BL2
      will read and clear the memory ranges if enabled. It is done in
      BL2 because it reduces the time that TF needs access to the full
      non-secure memory.
      
      The memory layout of both boards is defined using macros which
      take different values in Juno and FVP platforms. Generic platform
      helpers are added that use the platform specific macros to generate
      a mem_region_t that is valid for the platform.
      
      Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      f145403c
  30. 05 Sep, 2017 1 commit
  31. 31 Aug, 2017 1 commit
  32. 25 Aug, 2017 1 commit
  33. 23 Aug, 2017 1 commit
    • Isla Mitchell's avatar
      FVP: Always assume shifted affinity with MT bit · 8431635b
      Isla Mitchell authored
      
      
      At present, the MPIDR validation on FVP relies on MT bit set along
      with shifted affinities. This currently is additionally dependent
      on the FVP model being of variant C. This however should be based
      on the presence of MT bit alone.
      
      This patch makes the change to always assume that the affinities
      are shifted in the FVP model when MT bit is present.
      
      Change-Id: I09fcb0126e1b38d29124bdeaf3450a60b95d485d
      Signed-off-by: default avatarIsla Mitchell <isla.mitchell@arm.com>
      8431635b
  34. 02 Aug, 2017 1 commit
    • Jeenu Viswambharan's avatar
      FVP: Support Base FVP RevC · 955242d8
      Jeenu Viswambharan authored
      
      
      Revision C of the Base FVP has the same memory map as earlier revisions,
      but has the following differences:
      
        - Implements CCI550 instead of CCI400,
        - Has a single instantiation of SMMUv3,
        - CPU MPIDs are shifted left by one level, and has MT bit set in them.
      
      The correct interconnect to program is chosen at run time based on the
      FVP revision. Therefore, this patch implements FVP functions for
      interconnect programming, rather than depending on ARM generic ones. The
      macros used have been renamed to reflect this change.
      
      Additionally, this patch initializes SMMUv3 as part of FVP early
      platform setup.
      
      New ARM config flags are introduced for feature queries at run time.
      
      Change-Id: Ic7b7f080953a51fceaf62ce7daa6de0573801f09
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      955242d8