1. 04 Jun, 2015 1 commit
    • Sandrine Bailleux's avatar
      Remove FIRST_RESET_HANDLER_CALL build option · 452b7fa2
      Sandrine Bailleux authored
      This patch removes the FIRST_RESET_HANDLER_CALL build flag and its
      use in ARM development platforms. If a different reset handling
      behavior is required between the first and subsequent invocations
      of the reset handling code, this should be detected at runtime.
      
      On Juno, the platform reset handler is now always compiled in.
      This means it is now executed twice on the cold boot path, first in
      BL1 then in BL3-1, and it has the same behavior in both cases. It is
      also executed twice on the warm boot path, first in BL1 then in the
      PSCI entrypoint code.
      
      Also update the documentation to reflect this change.
      
      NOTE: THIS PATCH MAY FORCE PLATFORM PORTS THAT USE THE
      FIRST_RESET_HANDLER_CALL BUILD OPTION TO FIX THEIR RESET HANDLER.
      
      Change-Id: Ie5c17dbbd0932f5fa3b446efc6e590798a5beae2
      452b7fa2
  2. 01 Jun, 2015 1 commit
    • Sandrine Bailleux's avatar
      Always enable CCI coherency in BL3-1 · a6695275
      Sandrine Bailleux authored
      On ARM standard platforms, snoop and DVM requests used to be enabled
      for the primary CPU's cluster only in the first EL3 bootloader.
      In other words, if the platform reset into BL1 then CCI coherency
      would be enabled by BL1 only, and not by BL3-1 again.
      
      However, this doesn't cater for platforms that use BL3-1 along with
      a non-TF ROM bootloader that doesn't enable snoop and DVM requests.
      In this case, CCI coherency is never enabled.
      
      This patch modifies the function bl31_early_platform_setup() on
      ARM standard platforms so that it always enables snoop and DVM
      requests regardless of whether earlier bootloader stages have
      already done it. There is no harm in executing this code twice.
      
      ARM Trusted Firmware Design document updated accordingly.
      
      Change-Id: Idf1bdeb24d2e1947adfbb76a509f10beef224e1c
      a6695275
  3. 19 May, 2015 1 commit
    • Dan Handley's avatar
      Fix return type of FVP plat_arm_topology_setup · 12ad4d88
      Dan Handley authored
      Fix the return type of the FVP `plat_arm_topology_setup` function
      to be `void` instead of `int` to match the declaration in
      `plat_arm.h`.
      
      This does not result in any change in behavior.
      
      Change-Id: I62edfa7652b83bd26cffb7d167153959b38e37e7
      12ad4d88
  4. 28 Apr, 2015 3 commits
    • Dan Handley's avatar
      Move Juno port to plat/arm/board/juno · 85135283
      Dan Handley authored
      Move the Juno port from plat/juno to plat/arm/board/juno. Also rename
      some of the files so they are consistently prefixed with juno_.
      Update the platform makefiles accordingly.
      
      Change-Id: I0af6cb52a5fee7ef209107a1188b76a3c33a2a9f
      85135283
    • 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
      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