1. 28 Feb, 2018 1 commit
  2. 05 Dec, 2017 1 commit
  3. 09 Nov, 2017 1 commit
  4. 11 Oct, 2017 1 commit
    • 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
  5. 28 Jun, 2017 1 commit
    • Soby Mathew's avatar
      ARM plat changes to enable CryptoCell integration · e60f2af9
      Soby Mathew authored
      
      
      This patch makes the necessary changes to enable ARM platform to
      successfully integrate CryptoCell during Trusted Board Boot. The
      changes are as follows:
      
      * A new build option `ARM_CRYPTOCELL_INTEG` is introduced to select
        the CryptoCell crypto driver for Trusted Board boot.
      
      * The TrustZone filter settings for Non Secure DRAM is modified
        to allow CryptoCell to read this memory. This is required to
        authenticate BL33 which is loaded into the Non Secure DDR.
      
      * The CSS platforms are modified to use coherent stacks in BL1 and BL2
        when CryptoCell crypto is selected. This is because CryptoCell makes
        use of DMA to transfer data and the CryptoCell SBROM library allocates
        buffers on the stack during signature/hash verification.
      
      Change-Id: I1e6f6dcd1899784f1edeabfa2a9f279bbfb90e31
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      e60f2af9
  6. 03 May, 2017 1 commit
  7. 31 Mar, 2016 1 commit
  8. 15 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Perform security setup separately for each ARM platform · a9cc84d7
      Vikram Kanigiri authored
      Prior to this patch, it was assumed that on all ARM platforms the bare
      minimal security setup required is to program TrustZone protection. This
      would always be done by programming the TZC-400 which was assumed to be
      present in all ARM platforms. The weak definition of
      platform_arm_security_setup() in plat/arm/common/arm_security.c
      reflected these assumptions.
      
      In reality, each ARM platform either decides at runtime whether
      TrustZone protection needs to be programmed (e.g. FVPs) or performs
      some security setup in addition to programming TrustZone protection
      (e.g. NIC setup on Juno). As a result, the weak definition of
      plat_arm_security_setup() is always overridden.
      
      When a platform needs to program TrustZone protection and implements the
      TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is
      also possible to program TrustZone protection through other peripherals
      that include a TrustZone controller e.g. DMC-500. The programmer's
      interface is slightly different across these various peripherals.
      
      In order to satisfy the above requirements, this patch makes the
      following changes to the way security setup is done on ARM platforms.
      
      1. arm_security.c retains the definition of arm_tzc_setup() and has been
         renamed to arm_tzc400.c. This is to reflect the reliance on the
         TZC-400 peripheral to perform TrustZone programming. The new file is
         not automatically included in all platform ports through
         arm_common.mk. Each platform must include it explicitly in a platform
         specific makefile if needed.
      
         This approach enables introduction of similar library code to program
         TrustZone protection using a different peripheral. This code would be
         used by the subset of ARM platforms that implement this peripheral.
      
      2. Due to #1 above, existing platforms which implements the TZC-400 have been
         updated to include the necessary files for both BL2, BL2U and BL31
         images.
      
      Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735
      a9cc84d7
  9. 26 Nov, 2015 1 commit
    • Sandrine Bailleux's avatar
      CSS: Enable booting of EL3 payloads · 4c117f6c
      Sandrine Bailleux authored
      This patch adds support for booting EL3 payloads on CSS platforms,
      for example Juno. In this scenario, the Trusted Firmware follows
      its normal boot flow up to the point where it would normally pass
      control to the BL31 image. At this point, it jumps to the EL3
      payload entry point address instead.
      
      Before handing over to the EL3 payload, the data SCP writes for AP
      at the beginning of the Trusted SRAM is restored, i.e. we zero the
      first 128 bytes and restore the SCP Boot configuration. The latter
      is saved before transferring the BL30 image to SCP and is restored
      just after the transfer (in BL2). The goal is to make it appear that
      the EL3 payload is the first piece of software to run on the target.
      
      The BL31 entrypoint info structure is updated to make the primary
      CPU jump to the EL3 payload instead of the BL31 image.
      
      The mailbox is populated with the EL3 payload entrypoint address,
      which releases the secondary CPUs out of their holding pen (if the
      SCP has powered them on). The arm_program_trusted_mailbox() function
      has been exported for this purpose.
      
      The TZC-400 configuration in BL2 is simplified: it grants secure
      access only to the whole DRAM. Other security initialization is
      unchanged.
      
      This alternative boot flow is disabled by default. A new build option
      EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
      payload's entry point address. The build system has been modified
      such that BL31 and BL33 are not compiled and/or not put in the FIP in
      this case, as those images are not used in this boot flow.
      
      Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
      4c117f6c
  10. 11 Sep, 2015 1 commit
    • Vikram Kanigiri's avatar
      Re-factor definition of TZC-400 base address · e86c1ff0
      Vikram Kanigiri authored
      This patch replaces the `ARM_TZC_BASE` constant with `PLAT_ARM_TZC_BASE` to
      support different TrustZone Controller base addresses across ARM platforms.
      
      Change-Id: Ie4e1c7600fd7a5875323c7cc35e067de0c6ef6dd
      e86c1ff0
  11. 28 Apr, 2015 1 commit
    • Dan Handley's avatar
      Add common ARM and CSS platform code · b4315306
      Dan Handley authored
      This major change pulls out the common functionality from the
      FVP and Juno platform ports into the following categories:
      
      *   (include/)plat/common. Common platform porting functionality that
      typically may be used by all platforms.
      
      *   (include/)plat/arm/common. Common platform porting functionality
      that may be used by all ARM standard platforms. This includes all
      ARM development platforms like FVP and Juno but may also include
      non-ARM-owned platforms.
      
      *   (include/)plat/arm/board/common. Common platform porting
      functionality for ARM development platforms at the board
      (off SoC) level.
      
      *   (include/)plat/arm/css/common. Common platform porting
      functionality at the ARM Compute SubSystem (CSS) level. Juno
      is an example of a CSS-based platform.
      
      *   (include/)plat/arm/soc/common. Common platform porting
      functionality at the ARM SoC level, which is not already defined
      at the ARM CSS level.
      
      No guarantees are made about the backward compatibility of
      functionality provided in (include/)plat/arm.
      
      Also remove any unnecessary variation between the ARM development
      platform ports, including:
      
      *   Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the
      Juno implementation, which copies the information from BL2 memory
      instead of expecting it to persist in shared memory.
      
      *   Unify the TZC configuration. There is no need to add a region
      for SCP in Juno; it's enough to simply not allow any access to
      this reserved region. Also set region 0 to provide no access by
      default instead of assuming this is the case.
      
      *   Unify the number of memory map regions required for ARM
      development platforms, although the actual ranges mapped for each
      platform may be different. For the FVP port, this reduces the
      mapped peripheral address space.
      
      These latter changes will only be observed when the platform ports
      are migrated to use the new common platform code in subsequent
      patches.
      
      Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
      b4315306
  12. 10 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Make system register functions inline assembly · 5c3272a7
      Andrew Thoelke authored
      Replace the current out-of-line assembler implementations of
      the system register and system instruction operations with
      inline assembler.
      
      This enables better compiler optimisation and code generation
      when accessing system registers.
      
      Fixes ARM-software/tf-issues#91
      
      Change-Id: I149af3a94e1e5e5140a3e44b9abfc37ba2324476
      5c3272a7
  13. 23 May, 2014 1 commit
  14. 06 May, 2014 2 commits
    • Dan Handley's avatar
      Refactor GIC header files · 8a4fb6f6
      Dan Handley authored
      Move the function prototypes from gic.h into either gic_v2.h or
      gic_v3.h as appropriate. Update the source files to include the
      correct headers.
      
      Change-Id: I368cfda175cdcbd3a68f46e2332738ec49048e19
      8a4fb6f6
    • Dan Handley's avatar
      Move include and source files to logical locations · 4ecca339
      Dan Handley authored
      Move almost all system include files to a logical sub-directory
      under ./include. The only remaining system include directories
      not under ./include are specific to the platform. Move the
      corresponding source files to match the include directory
      structure.
      
      Also remove pm.h as it is no longer used.
      
      Change-Id: Ie5ea6368ec5fad459f3e8a802ad129135527f0b3
      4ecca339
  15. 17 Jan, 2014 2 commits
    • Harry Liebel's avatar
      Probe for GICv3 re-distributors on core bring-up · eaec590e
      Harry Liebel authored
      The GICv3 distributor can have more ports than CPUs are available in
      the system. Probe all re-distributors and use the matching affinity
      levels as specified by each core and re-distributor to decide which
      re-distributor to use with which CPU core.
      
      If a core cannot be matched with a re-distributor, the core panics and
      is placed in an endless loop.
      
      Change-Id: Ie393cfe07c7449a2383959e3c968664882e18afc
      eaec590e
    • Dan Handley's avatar
      Update year in copyright text to 2014 · e83b0cad
      Dan Handley authored
      Change-Id: Ic7fb61aabae1d515b9e6baf3dd003807ff42da60
      e83b0cad
  16. 05 Dec, 2013 1 commit
    • Dan Handley's avatar
      Enable third party contributions · ab2d31ed
      Dan Handley authored
      - Add instructions for contributing to ARM Trusted Firmware.
      
      - Update copyright text in all files to acknowledge contributors.
      
      Change-Id: I9311aac81b00c6c167d2f8c889aea403b84450e5
      ab2d31ed
  17. 27 Nov, 2013 1 commit
  18. 25 Oct, 2013 1 commit