1. 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
  2. 05 Oct, 2017 1 commit
    • Soby Mathew's avatar
      GICv3: add functions for save and restore · ebf1ca10
      Soby Mathew authored
      
      
      During system suspend, the GICv3 Distributor and Redistributor context
      can be lost due to power gating of the system power domain. This means
      that the GICv3 context needs to be saved prior to system suspend and
      restored on wakeup. Currently the consensus is that the Firmware should
      be in charge of this. See tf-issues#464 for more details.
      
      This patch introduces helper APIs in the GICv3 driver to save and
      restore the Distributor and Redistributor contexts. The GICv3 ITS
      context is not considered in this patch because the specification says
      that the details of ITS power management is implementation-defined.
      These APIs are expected to be appropriately invoked by the platform
      layer during system suspend.
      
      Fixes ARM-software/tf-issues#464
      
      Change-Id: Iebb9c6770ab8c4d522546f161fa402d2fe02ec00
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      ebf1ca10
  3. 06 Sep, 2017 1 commit
    • 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
  4. 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
  5. 01 Aug, 2017 1 commit
    • Jeenu Viswambharan's avatar
      FVP: Add support for multi-threaded CPUs · 11ad8f20
      Jeenu Viswambharan authored
      
      
      ARM CPUs with multi-threading implementation has more than one
      Processing Element in a single physical CPU. Such an implementation will
      reflect the following changes in the MPIDR register:
      
        - The MT bit set;
      
        - Affinity levels pertaining to cluster and CPUs occupy one level
          higher than in a single-threaded implementation, and the lowest
          affinity level pertains to hardware threads. MPIDR affinity level
          fields essentially appear shifted to left than otherwise.
      
      The FVP port henceforth assumes that both properties above to be
      concomitant on a given FVP platform.
      
      To accommodate for varied MPIDR formats at run time, this patch
      re-implements the FVP platform-specific functions that translates MPIDR
      values to a linear indices, along with required validation. The same
      treatment is applied for GICv3 MPIDR hashing function as well.
      
      An FVP-specific build option FVP_MAX_PE_PER_CPU is introduced which
      specifies the maximum number of threads implemented per CPU. For
      backwards compatibility, its value defaults to 1.
      
      Change-Id: I729b00d3e121d16ce9a03de4f9db36dfac580e3f
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      11ad8f20
  6. 01 Jun, 2017 2 commits
    • Jeenu Viswambharan's avatar
      Introduce ARM GIC-600 driver · e1c59ab3
      Jeenu Viswambharan authored
      
      
      ARM GIC-600 IP complies with ARM GICv3 architecture, but among others,
      implements a power control register in the Redistributor frame. This
      register must be programmed to mark the frame as powered on, before
      accessing other registers in the frame. Rest of initialization sequence
      remains the same.
      
      The driver provides APIs for Redistributor power management, and
      overrides those in the generic GICv3 driver. The driver data is shared
      between generic GICv3 driver and that of GIC-600.
      
      For FVP platform, the GIC-600 driver is chosen when FVP_USE_GIC_DRIVER
      is set to FVP_GIC600. Also update user guide.
      
      Change-Id: I321b2360728d69f6d4b0a747b2cfcc3fe5a20d67
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      e1c59ab3
    • David Wang's avatar
      Add support for Cortex-A75 and Cortex-A55 CPUs · d40ab484
      David Wang authored
      
      
      Both Cortex-A75 and Cortex-A55 CPUs use the ARM DynamIQ Shared Unit
      (DSU). The power-down and power-up sequences are therefore mostly
      managed in hardware, and required software operations are considerably
      simpler.
      
      Change-Id: I68b30e6e1ebe7c041d5e67f39c59f08575fc7ecc
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      d40ab484
  7. 15 May, 2017 1 commit
  8. 03 May, 2017 1 commit
  9. 31 Mar, 2017 1 commit
    • Douglas Raillard's avatar
      Add support for GCC stack protection · 51faada7
      Douglas Raillard authored
      
      
      Introduce new build option ENABLE_STACK_PROTECTOR. It enables
      compilation of all BL images with one of the GCC -fstack-protector-*
      options.
      
      A new platform function plat_get_stack_protector_canary() is introduced.
      It returns a value that is used to initialize the canary for stack
      corruption detection. Returning a random value will prevent an attacker
      from predicting the value and greatly increase the effectiveness of the
      protection.
      
      A message is printed at the ERROR level when a stack corruption is
      detected.
      
      To be effective, the global data must be stored at an address
      lower than the base of the stacks. Failure to do so would allow an
      attacker to overwrite the canary as part of an attack which would void
      the protection.
      
      FVP implementation of plat_get_stack_protector_canary is weak as
      there is no real source of entropy on the FVP. It therefore relies on a
      timer's value, which could be predictable.
      
      Change-Id: Icaaee96392733b721fa7c86a81d03660d3c1bc06
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      51faada7
  10. 21 Sep, 2016 3 commits
    • Yatharth Kochar's avatar
      AArch32: Add support for ARM Cortex-A32 MPCore Processor · 03a3042b
      Yatharth Kochar authored
      This patch adds ARM Cortex-A32 MPCore Processor support
      in the CPU specific operations framework. It also includes
      this support for the Base FVP port.
      
      Change-Id: If3697b88678df737c29f79cf3fa1ea2cb6fa565d
      03a3042b
    • Yatharth Kochar's avatar
      AArch32: Add ARM platform changes in BL2 · 6fe8aa2f
      Yatharth Kochar authored
      This patch adds ARM platform changes in BL2 for AArch32 state.
      It instantiates a descriptor array for ARM platforms describing
      image and entrypoint information for `SCP_BL2`, `BL32` and `BL33`.
      It also enables building of BL2 for ARCH=aarch32.
      
      Change-Id: I60dc7a284311eceba401fc789311c50ac746c51e
      6fe8aa2f
    • Yatharth Kochar's avatar
      AArch32: Add ARM platform changes in BL1 · 83fc4a93
      Yatharth Kochar authored
      This patch adds ARM platform changes in BL1 for AArch32 state.
      It also enables building of BL1 for ARCH=aarch32.
      
      Change-Id: I079be81a93d027f37b0f7d8bb474b1252bb4cf48
      83fc4a93
  11. 10 Aug, 2016 1 commit
    • Soby Mathew's avatar
      AArch32: Add essential ARM platform and FVP support · 877cf3ff
      Soby Mathew authored
      This patch adds AArch32 support for FVP and implements common platform APIs
      like `plat_get_my_stack`, `plat_set_my_stack`, `plat_my_core_cos` for AArch32.
      Only Multi Processor(MP) implementations of these functions are considered in
      this patch. The ARM Standard platform layer helpers are implemented for
      AArch32 and the common makefiles are modified to cater for both AArch64 and
      AArch32 builds. Compatibility with the deprecated platform API is not
      supported for AArch32.
      
      Change-Id: Iad228400613eec91abf731b49e21a15bcf2833ea
      877cf3ff
  12. 03 Jun, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Implement plat_set_nv_ctr for FVP platforms · fe7de035
      Antonio Nino Diaz authored
      Replaced placeholder implementation of plat_set_nv_ctr for FVP
      platforms by a working one.
      
      On FVP, the mapping of region DEVICE2 has been changed from RO to RW
      to prevent exceptions when writing to the NV counter, which is
      contained in this region.
      
      Change-Id: I56a49631432ce13905572378cbdf106f69c82f57
      fe7de035
  13. 01 Jun, 2016 1 commit
    • Yatharth Kochar's avatar
      Add support for ARM Cortex-A73 MPCore Processor · 2460ac18
      Yatharth Kochar authored
      This patch adds ARM Cortex-A73 MPCore Processor support
      in the CPU specific operations framework. It also includes
      this support for the Base FVP port.
      
      Change-Id: I0e26b594f2ec1d28eb815db9810c682e3885716d
      2460ac18
  14. 25 May, 2016 1 commit
    • Soby Mathew's avatar
      Add CCN support to FVP platform port · 71237876
      Soby Mathew authored
      This patch adds support to select CCN driver for FVP during build.
      A new build option `FVP_INTERCONNECT_DRIVER` is added to allow
      selection between the CCI and CCN driver. Currently only the CCN-502
      variant is supported on FVP.
      
      The common ARM CCN platform helper file now verifies the cluster
      count declared by platform is equal to the number of root node
      masters exported by the ARM Standard platform.
      
      Change-Id: I71d7b4785f8925ed499c153b2e9b9925fcefd57a
      71237876
  15. 20 May, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Replace SP804 timer by generic delay timer on FVP · 32cd95f0
      Antonio Nino Diaz authored
      Added a build flag to select the generic delay timer on FVP instead
      of the SP804 timer. By default, the generic one will be selected. The
      user guide has been updated.
      
      Change-Id: Ica34425c6d4ed95a187b529c612f6d3b26b78bc6
      32cd95f0
  16. 28 Apr, 2016 1 commit
    • Soby Mathew's avatar
      Change the default driver to GICv3 in FVP · a8af6a4d
      Soby Mathew authored
      This patch changes the default driver for FVP platform from the deprecated
      GICv3 legacy to the GICv3 only driver. This means that the default build of
      Trusted Firmware will not be able boot Linux kernel with GICv2 FDT blob. The
      user guide is also updated to reflect this change of default GIC driver for
      FVP.
      
      Change-Id: Id6fc8c1ac16ad633dabb3cd189b690415a047764
      a8af6a4d
  17. 13 Apr, 2016 1 commit
    • Soby Mathew's avatar
      Migrate platform ports to the new xlat_tables library · 3e4b8fdc
      Soby Mathew authored
      This patch modifies the upstream platform port makefiles to use the new
      xlat_tables library files. This patch also makes mmap region setup common
      between AArch64 and AArch32 for FVP platform port. The file `fvp_common.c`
      is moved from the `plat/arm/board/fvp/aarch64` folder to the parent folder
      as it is not specific to AArch64.
      
      Change-Id: Id2e9aac45e46227b6f83cccfd1e915404018ea0b
      3e4b8fdc
  18. 31 Mar, 2016 1 commit
  19. 19 Feb, 2016 1 commit
    • Soby Mathew's avatar
      Allow multi cluster topology definitions for ARM platforms · 0108047a
      Soby Mathew authored
      The common topology description helper funtions and macros for
      ARM Standard platforms assumed a dual cluster system. This is not
      flexible enough to scale to multi cluster platforms. This patch does
      the following changes for more flexibility in defining topology:
      
      1. The `plat_get_power_domain_tree_desc()` definition is moved from
         `arm_topology.c` to platform specific files, that is `fvp_topology.c`
         and `juno_topology.c`. Similarly the common definition of the porting
         macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform
         specific `platform_def.h` header.
      
      2. The ARM common layer porting macros which were dual cluster specific
         are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced
         which must be defined by each ARM standard platform.
      
      3. A new mandatory ARM common layer porting API
         `plat_arm_get_cluster_core_count()` is introduced to enable the common
         implementation of `arm_check_mpidr()` to validate MPIDR.
      
      4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been
         introduced which allows the user to specify the cluster count to be
         used to build the topology tree within Trusted Firmare. This enables
         Trusted Firmware to be built for multi cluster FVP models.
      
      Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
      0108047a
  20. 16 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Rework use of interconnect drivers · 6355f234
      Vikram Kanigiri authored
      ARM Trusted Firmware supports 2 different interconnect peripheral
      drivers: CCI and CCN. ARM platforms are implemented using either of the
      interconnect peripherals.
      
      This patch adds a layer of abstraction to help ARM platform ports to
      choose the right interconnect driver and corresponding platform support.
      This is as described below:
      
      1. A set of ARM common functions have been implemented to initialise an
      interconnect and for entering/exiting a cluster from coherency. These
      functions are prefixed as "plat_arm_interconnect_". Weak definitions of
      these functions have been provided for each type of driver.
      
      2.`plat_print_interconnect_regs` macro used for printing CCI registers is
      moved from a common arm_macros.S to cci_macros.S.
      
      3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure
      is renamed to `ARM_CONFIG_HAS_INTERCONNECT`.
      
      Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
      6355f234
  21. 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
  22. 13 Jan, 2016 1 commit
    • Sandrine Bailleux's avatar
      FVP: Compile ARM Cortex-A72 CPU support in · b13ed5ef
      Sandrine Bailleux authored
      This patch enables the ARM Cortex-A72 support in BL1 and BL31 on FVP.
      This allows the same TF binaries to run on a Cortex-A72 based FVP
      without recompiling them.
      
      Change-Id: I4eb6bbad9f0e5d8704613f7c685c3bd22b45cf47
      b13ed5ef
  23. 12 Jan, 2016 1 commit
  24. 09 Dec, 2015 2 commits
    • Yatharth Kochar's avatar
      FWU: Add Firmware Update support in BL2U for ARM platforms · dcda29f6
      Yatharth Kochar authored
      This patch adds support for Firmware update in BL2U for ARM
      platforms such that TZC initialization is performed on all
      ARM platforms and (optionally) transfer of SCP_BL2U image on
      ARM CSS platforms.
      
      BL2U specific functions are added to handle early_platform and
      plat_arch setup. The MMU is configured to map in the BL2U
      code/data area and other required memory.
      
      Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
      dcda29f6
    • Achin Gupta's avatar
      Rework use of ARM GIC drivers on ARM platforms · 27573c59
      Achin Gupta authored
      Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three
      separate drivers instead of providing a single driver that can work on both
      versions of the GIC architecture. These drivers correspond to the following
      software use cases:
      
      1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations
         e.g. GIC-400
      
      2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations
         e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features
      
      3. A deprecated GICv3 driver that operates in legacy mode. This driver can
         operate only in the GICv2 mode in the secure world. On a GICv3 system, this
         driver allows normal world to run in either GICv3 mode (asymmetric mode)
         or in the GICv2 mode. Both modes of operation are deprecated on GICv3
         systems.
      
      ARM platforms implement both versions of the GIC architecture. This patch adds a
      layer of abstraction to help ARM platform ports chose the right GIC driver and
      corresponding platform support. This is as described below:
      
      1. A set of ARM common functions have been introduced to initialise the GIC and
         the driver during cold and warm boot. These functions are prefixed as
         "plat_arm_gic_". Weak definitions of these functions have been provided for
         each type of driver.
      
      2. Each platform includes the sources that implement the right functions
         directly into the its makefile. The FVP can be instantiated with different
         versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option
         to specify which of the three drivers should be included in the build.
      
      3. A list of secure interrupts has to be provided to initialise each of the
        three GIC drivers. For GIC v3.0 the interrupt ids have to be further
        categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two
        types are merged and treated as Group 0 interrupts.
      
        The two lists of interrupts are exported from the platform_def.h. The lists
        are constructed by adding a list of board specific interrupt ids to a list of
        ids common to all ARM platforms and Compute sub-systems.
      
      This patch also makes some fields of `arm_config` data structure in FVP redundant
      and these unused fields are removed.
      
      Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
      27573c59
  25. 02 Dec, 2015 1 commit
    • Juan Castillo's avatar
      TBB: add Trusted Watchdog support on ARM platforms · 7b4c1405
      Juan Castillo authored
      This patch adds watchdog support on ARM platforms (FVP and Juno).
      A secure instance of SP805 is used as Trusted Watchdog. It is
      entirely managed in BL1, being enabled in the early platform setup
      hook and disabled in the exit hook. By default, the watchdog is
      enabled in every build (even when TBB is disabled).
      
      A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG`
      has been introduced to allow the user to disable the watchdog at
      build time. This feature may be used for testing or debugging
      purposes.
      
      Specific error handlers for Juno and FVP are also provided in this
      patch. These handlers will be called after an image load or
      authentication error. On FVP, the Table of Contents (ToC) in the FIP
      is erased. On Juno, the corresponding error code is stored in the
      V2M Non-Volatile flags register. In both cases, the CPU spins until
      a watchdog reset is generated after 256 seconds (as specified in
      the TBBR document).
      
      Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
      7b4c1405
  26. 13 Aug, 2015 1 commit
    • Soby Mathew's avatar
      PSCI: Migrate ARM reference platforms to new platform API · 38dce70f
      Soby Mathew authored
      This patch migrates ARM reference platforms, Juno and FVP, to the new platform
      API mandated by the new PSCI power domain topology and composite power state
      frameworks. The platform specific makefiles now exports the build flag
      ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer.
      
      Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29
      38dce70f
  27. 25 Jun, 2015 1 commit
    • Juan Castillo's avatar
      TBB: add platform API to read the ROTPK information · 95cfd4ad
      Juan Castillo authored
      This patch extends the platform port by adding an API that returns
      either the Root of Trust public key (ROTPK) or its hash. This is
      usually stored in ROM or eFUSE memory. The ROTPK returned must be
      encoded in DER format according to the following ASN.1 structure:
      
          SubjectPublicKeyInfo  ::=  SEQUENCE  {
              algorithm           AlgorithmIdentifier,
              subjectPublicKey    BIT STRING
          }
      
      In case the platform returns a hash of the key:
      
          DigestInfo  ::= SEQUENCE {
              digestAlgorithm     AlgorithmIdentifier,
              keyDigest           OCTET STRING
          }
      
      An implementation for ARM development platforms is provided in this
      patch. When TBB is enabled, the ROTPK hash location must be specified
      using the build option 'ARM_ROTPK_LOCATION'. Available options are:
      
          - 'regs' : return the ROTPK hash stored in the Trusted
            root-key storage registers.
      
          - 'devel_rsa' : return a ROTPK hash embedded in the BL1 and
            BL2 binaries. This hash has been obtained from the development
            RSA public key located in 'plat/arm/board/common/rotpk'.
      
      On FVP, the number of MMU tables has been increased to map and
      access the ROTPK registers.
      
      A new file 'board_common.mk' has been added to improve code sharing
      in the ARM develelopment platforms.
      
      Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
      95cfd4ad
  28. 18 Jun, 2015 1 commit
    • Ryan Harkin's avatar
      FVP: Add SP804 delay timer · b49b3221
      Ryan Harkin authored
      
      
      Add SP804 delay timer support to the FVP BSP.
      
      This commit simply provides the 3 constants needed by the SP804
      delay timer driver and calls sp804_timer_init() in
      bl2_platform_setup(). The BSP does not currently use the delay
      timer functions.
      
      Note that the FVP SP804 is a normal world accessible peripheral
      and should not be used by the secure world after transition
      to the normal world.
      
      Change-Id: I5f91d2ac9eb336fd81943b3bb388860dfb5f2b39
      Co-authored-by: default avatarDan Handley <dan.handley@arm.com>
      b49b3221
  29. 28 Apr, 2015 2 commits
    • Dan Handley's avatar
      Move FVP port to plat/arm/board/fvp · 3fc4124c
      Dan Handley authored
      Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename
      some of the files so they are consistently prefixed with fvp_.
      Update the platform makefiles accordingly.
      
      Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
      3fc4124c
    • Dan Handley's avatar
      Migrate FVP port to use common code · 60eea55e
      Dan Handley authored
      Major update to the FVP platform port to use the common platform code
      in (include/)plat/arm/* and (include/)plat/common/*. This mainly
      consists of removing duplicated code but also introduces some small
      behavioural changes where there was unnecessary variation between the
      FVP and Juno ports. See earlier commit titled `Add common ARM and CSS
      platform code` for details.
      
      Also add support for Foundation FVP version 9.1 during FVP config
      setup to prevent a warning being emitted in the console.
      
      Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
      60eea55e
  30. 16 Mar, 2015 1 commit
  31. 28 Jan, 2015 1 commit
    • Juan Castillo's avatar
      TBB: add a platform specific function to validate the ROTPK · 6eadf762
      Juan Castillo authored
      This patch adds the function plat_match_rotpk() to the platform
      porting layer to provide a Root Of Trust Public key (ROTPK)
      verification mechanism. This function is called during the
      Trusted Board Boot process and receives a supposed valid copy
      of the ROTPK as a parameter, usually obtained from an external
      source (for instance, a certificate). It returns 0 (success) if
      that key matches the actual ROTPK stored in the system or any
      other value otherwise.
      
      The mechanism to access the actual ROTPK stored in the system
      is platform specific and should be implemented as part of this
      function. The format of the ROTPK is also platform specific
      (to save memory, some platforms might store a hash of the key
      instead of the whole key).
      
      TRUSTED_BOARD_BOOT build option has been added to allow the user
      to enable the Trusted Board Boot features. The implementation of
      the plat_match_rotpk() funtion is mandatory when Trusted Board
      Boot is enabled.
      
      For development purposes, FVP and Juno ports provide a dummy
      function that returns always success (valid key). A safe trusted
      boot implementation should provide a proper matching function.
      
      Documentation updated accordingly.
      
      Change-Id: I74ff12bc2b041556c48533375527d9e8c035b8c3
      6eadf762
  32. 26 Jan, 2015 1 commit
    • Juan Castillo's avatar
      FVP: Allow BL3-2 to sit in the secure region of DRAM · 513dd3a0
      Juan Castillo authored
      This patch allows the secure payload (BL3-2) to be loaded in the
      DRAM region secured by the TrustZone controller (top 16 MB of DRAM1).
      
      The location of BL3-2 can be selected at build time by setting the
      build flag FVP_TSP_RAM_LOCATION to one of the following options:
      
        - 'tsram' : Trusted SRAM (this is the default option)
        - 'tdram' : Trusted DRAM
        - 'dram'  : Secure region in DRAM1 (top 16MB configured by the
                    TrustZone controller)
      
      The number of MMU tables in BL3-2 depends on its location in
      memory: 3 in case it is loaded in DRAM, 2 otherwise.
      
      Documentation updated accordingly.
      
      Fixes ARM-software/tf-issues#212
      
      Change-Id: I371eef3a4159f06a0c9e3c6c1f4c905b2f93803a
      513dd3a0
  33. 22 Oct, 2014 1 commit
    • Juan Castillo's avatar
      FVP: keep shared data in Trusted SRAM · 20d51cad
      Juan Castillo authored
      This patch deprecates the build option to relocate the shared data
      into Trusted DRAM in FVP. After this change, shared data is always
      located at the base of Trusted SRAM. This reduces the complexity
      of the memory map and the number of combinations in the build
      options.
      
      Fixes ARM-software/tf-issues#257
      
      Change-Id: I68426472567b9d8c6d22d8884cb816f6b61bcbd3
      20d51cad
  34. 20 Aug, 2014 1 commit
    • Soby Mathew's avatar
      Introduce framework for CPU specific operations · 9b476841
      Soby Mathew authored
      This patch introduces a framework which will allow CPUs to perform
      implementation defined actions after a CPU reset, during a CPU or cluster power
      down, and when a crash occurs. CPU specific reset handlers have been implemented
      in this patch. Other handlers will be implemented in subsequent patches.
      
      Also moved cpu_helpers.S to the new directory lib/cpus/aarch64/.
      
      Change-Id: I1ca1bade4d101d11a898fb30fea2669f9b37b956
      9b476841
  35. 14 Aug, 2014 1 commit
    • Dan Handley's avatar
      Move IO storage source to drivers directory · 935db693
      Dan Handley authored
      Move the remaining IO storage source file (io_storage.c) from the
      lib to the drivers directory. This requires that platform ports
      explicitly add this file to the list of source files.
      
      Also move the IO header files to a new sub-directory, include/io.
      
      Change-Id: I862b1252a796b3bcac0d93e50b11e7fb2ded93d6
      935db693