1. 25 Jun, 2015 2 commits
    • 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
    • Juan Castillo's avatar
      Use numbers to identify images instead of names · 16948ae1
      Juan Castillo authored
      The Trusted firmware code identifies BL images by name. The platform
      port defines a name for each image e.g. the IO framework uses this
      mechanism in the platform function plat_get_image_source(). For
      a given image name, it returns the handle to the image file which
      involves comparing images names. In addition, if the image is
      packaged in a FIP, a name comparison is required to find the UUID
      for the image. This method is not optimal.
      
      This patch changes the interface between the generic and platform
      code with regard to identifying images. The platform port must now
      allocate a unique number (ID) for every image. The generic code will
      use the image ID instead of the name to access its attributes.
      
      As a result, the plat_get_image_source() function now takes an image
      ID as an input parameter. The organisation of data structures within
      the IO framework has been rationalised to use an image ID as an index
      into an array which contains attributes of the image such as UUID and
      name. This prevents the name comparisons.
      
      A new type 'io_uuid_spec_t' has been introduced in the IO framework
      to specify images identified by UUID (i.e. when the image is contained
      in a FIP file). There is no longer need to maintain a look-up table
      [iname_name --> uuid] in the io_fip driver code.
      
      Because image names are no longer mandatory in the platform port, the
      debug messages in the generic code will show the image identifier
      instead of the file name. The platforms that support semihosting to
      load images (i.e. FVP) must provide the file names as definitions
      private to the platform.
      
      The ARM platform ports and documentation have been updated accordingly.
      All ARM platforms reuse the image IDs defined in the platform common
      code. These IDs will be used to access other attributes of an image in
      subsequent patches.
      
      IMPORTANT: applying this patch breaks compatibility for platforms that
      use TF BL1 or BL2 images or the image loading code. The platform port
      must be updated to match the new interface.
      
      Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
      16948ae1
  2. 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
  3. 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
  4. 03 Jun, 2015 1 commit
  5. 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
  6. 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
  7. 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