1. 20 Nov, 2017 1 commit
    • Dimitris Papastamos's avatar
      Refactor Statistical Profiling Extensions implementation · 281a08cc
      Dimitris Papastamos authored
      
      
      Factor out SPE operations in a separate file.  Use the publish
      subscribe framework to drain the SPE buffers before entering secure
      world.  Additionally, enable SPE before entering normal world.
      
      A side effect of this change is that the profiling buffers are now
      only drained when a transition from normal world to secure world
      happens.  Previously they were drained also on return from secure
      world, which is unnecessary as SPE is not supported in S-EL1.
      
      Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      281a08cc
  2. 13 Nov, 2017 5 commits
  3. 09 Nov, 2017 1 commit
  4. 08 Nov, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Introduce Secure Partition Manager · 2fccb228
      Antonio Nino Diaz authored
      
      
      A Secure Partition is a software execution environment instantiated in
      S-EL0 that can be used to implement simple management and security
      services. Since S-EL0 is an unprivileged exception level, a Secure
      Partition relies on privileged firmware e.g. ARM Trusted Firmware to be
      granted access to system and processor resources. Essentially, it is a
      software sandbox that runs under the control of privileged software in
      the Secure World and accesses the following system resources:
      
      - Memory and device regions in the system address map.
      - PE system registers.
      - A range of asynchronous exceptions e.g. interrupts.
      - A range of synchronous exceptions e.g. SMC function identifiers.
      
      A Secure Partition enables privileged firmware to implement only the
      absolutely essential secure services in EL3 and instantiate the rest in
      a partition. Since the partition executes in S-EL0, its implementation
      cannot be overly complex.
      
      The component in ARM Trusted Firmware responsible for managing a Secure
      Partition is called the Secure Partition Manager (SPM). The SPM is
      responsible for the following:
      
      - Validating and allocating resources requested by a Secure Partition.
      - Implementing a well defined interface that is used for initialising a
        Secure Partition.
      - Implementing a well defined interface that is used by the normal world
        and other secure services for accessing the services exported by a
        Secure Partition.
      - Implementing a well defined interface that is used by a Secure
        Partition to fulfil service requests.
      - Instantiating the software execution environment required by a Secure
        Partition to fulfil a service request.
      
      Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Co-authored-by: default avatarAchin Gupta <achin.gupta@arm.com>
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2fccb228
  5. 25 Oct, 2017 1 commit
  6. 24 Oct, 2017 1 commit
  7. 16 Oct, 2017 11 commits
  8. 11 Oct, 2017 2 commits
    • 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
    • Soby Mathew's avatar
      ARM platforms: Add support for EL3 TZC memory region · a22dffc6
      Soby Mathew authored
      
      
      Some recent enhancements to EL3 runtime firmware like support for
      save and restoring GICv3 register context during system_suspend
      necessitates additional data memory for the firmware. This patch
      introduces support for creating a TZC secured DDR carveout for use
      by ARM reference platforms. A new linker section `el3_tzc_dram` is
      created using platform supplied linker script and data marked with
      the attribute `arm_el3_tzc_dram` will be placed in this section.
      The FVP makefile now defines the `PLAT_EXTRA_LD_SCRIPT` variable to
      allow inclusion of the platform linker script by the top level BL31
      linker script.
      
      Change-Id: I0e7f4a75a6ac51419c667875ff2677043df1585d
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      a22dffc6
  9. 06 Oct, 2017 1 commit
    • David Cunado's avatar
      Increase PLAT_ARM_MMAP_ENTRIES and MAX_XLAT_TABLES · 2e421ad2
      David Cunado authored
      
      
      The MEM_PROTECT support adds a MMAP region for DRAM2, which when
      building with TBBR support and OP-TEE tsp requires an additional
      entry in the MMAP region array in BL2 - PLAT_ARM_MMAP_ENTRIES is
      increased.
      
      The MEM_PROTECT support also adds a new region in BL31, and when
      BL31 is placed in DRAM, the memory mappings require an additional
      translation table - MAX_XLAT_TABLES is increased.
      
      Change-Id: I0b76260da817dcfd0b8f73a7193c36efda977625
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      2e421ad2
  10. 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
  11. 22 Sep, 2017 1 commit
  12. 12 Sep, 2017 1 commit
    • Qixiang Xu's avatar
      plat/arm: Fix BL31_BASE when RESET_TO_BL31=1 · fd5763ea
      Qixiang Xu authored
      
      
      The value of BL31_BASE currently depends on the size of BL31. This
      causes problems in the RESET_TO_BL31 case because the value of
      BL31_BASE is used in the model launch parameters, which often changes.
      
      Therefore, this patch fixes BL31_BASE to the middle of Trusted SRAM,
      to avoid further model parameter changes in future.
      
      Change-Id: I6d7fa4fe293717d84768974679539c0e0cb6d935
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      fd5763ea
  13. 11 Sep, 2017 1 commit
    • Soby Mathew's avatar
      Implement log framework · 7f56e9a3
      Soby Mathew authored
      
      
      This patch gives users control over logging messages printed from the C
      code using the LOG macros defined in debug.h Users now have the ability
      to reduce the log_level at run time using the tf_log_set_max_level()
      function. The default prefix string can be defined by platform by
      overriding the `plat_log_get_prefix()` platform API which is also
      introduced in this patch.
      
      The new log framework results in saving of some RO data. For example,
      when BL1 is built for FVP with LOG_LEVEL=LOG_LEVEL_VERBOSE, resulted
      in saving 384 bytes of RO data and increase of 8 bytes of RW data. The
      framework also adds about 108 bytes of code to the release build of FVP.
      
      Fixes ARM-software/tf-issues#462
      
      Change-Id: I476013d9c3deedfdd4c8b0b0f125665ba6250554
      Co-authored-by: default avatarEleanor Bonnici <Eleanor.bonnici@arm.com>
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      7f56e9a3
  14. 06 Sep, 2017 2 commits
    • Soby Mathew's avatar
      CSS: Changes for SDS framework · 18e279eb
      Soby Mathew authored
      
      
      This patch does the required changes to enable CSS platforms
      to build and use the SDS framework. Since SDS is always coupled with
      SCMI protocol, the preexisting SCMI build flag is now renamed to
      `CSS_USE_SCMI_SDS_DRIVER` which will enable both SCMI and SDS on
      CSS platforms. Also some of the workarounds applied for SCMI are
      now removed with SDS in place.
      
      Change-Id: I94e8b93f05e3fe95e475c5501c25bec052588a9c
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      18e279eb
    • Soby Mathew's avatar
      Fix JUNO AArch32 build · ba6c31da
      Soby Mathew authored
      
      
      This patch fixes the inconsistency with regards as to how
      BL2_BASE/BL2U_BASE and BL2_LIMIT/BL2U_LIMIT macros are defined
      when building Juno to run in AArch32 mode at EL3. In this case,
      BL32 is compiled for AArch32 whereas BL1 and BL2 are compiled
      for AArch64. This resulted in BL32 conditionally compiling a
      different definition of the above mentioned macros from BL1/BL2.
      This is fixed by taking into consideration the
      JUNO_AARCH32_EL3_RUNTIME build flag as well in the conditional
      compilation check.
      
      Change-Id: I27ac68aa4df0502089c1739c05366a9c509eb5be
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      ba6c31da
  15. 05 Sep, 2017 1 commit
  16. 31 Aug, 2017 1 commit
  17. 29 Aug, 2017 1 commit
    • Jeenu Viswambharan's avatar
      plat/arm: Fix ARM_INSTANTIATE_LOCK syntax anomaly · 19583169
      Jeenu Viswambharan authored
      
      
      The current definition of ARM_INSTANTIATE_LOCK macro includes a
      semicolon, which means it's omitted where it's used. This is anomalous
      for a C statement in global scope.
      
      Fix this by removing semicolon from the definition; and where it's a
      NOP, declare a file-scoped variable explicitly tagged as unused to avoid
      compiler warning.
      
      No functional changes.
      
      Change-Id: I2c1d92ece4777e272a025011e03b8003f3543335
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      19583169
  18. 25 Aug, 2017 1 commit
    • Jens Wiklander's avatar
      ARM plat: change OP-TEE pageable load base · 04f72bae
      Jens Wiklander authored
      
      
      Changes ARM_OPTEE_PAGEABLE_LOAD_BASE to end of ARM_AP_TZC_DRAM1.
      ARM_OPTEE_PAGEABLE_LOAD_SIZE is also increased to 4MB to optimize
      translation table usage.
      
      This change makes loading of paged part easier inside OP-TEE OS as the
      previous location of ARM_OPTEE_PAGEABLE_LOAD_BASE normally isn't mapped
      if paging is enabled.
      Signed-off-by: default avatarJens Wiklander <jens.wiklander@linaro.org>
      04f72bae
  19. 22 Aug, 2017 2 commits
  20. 09 Aug, 2017 1 commit
    • Summer Qin's avatar
      Add Trusted OS extra image parsing support for ARM standard platforms · 54661cd2
      Summer Qin authored
      
      
      Trusted OS may have extra images to be loaded. Load them one by one
      and do the parsing. In this patch, ARM TF need to load up to 3 images
      for optee os: header, pager and paged images. Header image is the info
      about optee os and images. Pager image include pager code and data.
      Paged image include the paging parts using virtual memory.
      
      Change-Id: Ia3bcfa6d8a3ed7850deb5729654daca7b00be394
      Signed-off-by: default avatarSummer Qin <summer.qin@arm.com>
      54661cd2
  21. 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
  22. 25 Jul, 2017 1 commit