1. 13 Aug, 2015 5 commits
    • Soby Mathew's avatar
      PSCI: Validate non secure entrypoint on ARM platforms · f9e858b1
      Soby Mathew authored
      This patch implements the platform power managment handler to verify
      non secure entrypoint for ARM platforms. The handler ensures that the
      entry point specified by the normal world during CPU_SUSPEND, CPU_ON
      or SYSTEM_SUSPEND PSCI API is a valid address within the non secure
      DRAM.
      
      Change-Id: I4795452df99f67a24682b22f0e0967175c1de429
      f9e858b1
    • Sandrine Bailleux's avatar
      PSCI: Pool platform_mem_init() in common ARM platforms code · a6bd5ffb
      Sandrine Bailleux authored
      Now that the FVP mailbox is no longer zeroed, the function
      platform_mem_init() does nothing both on FVP and on Juno. Therefore,
      this patch pools it as the default implementation on ARM platforms.
      
      Change-Id: I007220f4531f15e8b602c3368a1129a5e3a38d91
      a6bd5ffb
    • Sandrine Bailleux's avatar
      PSCI: Use a single mailbox for warm reset for FVP and Juno · 804040d1
      Sandrine Bailleux authored
      Since there is a unique warm reset entry point, the FVP and Juno
      port can use a single mailbox instead of maintaining one per core.
      The mailbox gets programmed only once when plat_setup_psci_ops()
      is invoked during PSCI initialization. This means mailbox is not
      zeroed out during wakeup.
      
      Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432
      804040d1
    • Soby Mathew's avatar
      PSCI: Demonstrate support for composite power states · 2204afde
      Soby Mathew authored
      This patch adds support to the Juno and FVP ports for composite power states
      with both the original and extended state-id power-state formats. Both the
      platform ports use the recommended state-id encoding as specified in
      Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag
      ARM_RECOM_STATE_ID_ENC is used to include this support.
      
      By default, to maintain backwards compatibility, the original power state
      parameter format is used and the state-id field is expected to be zero.
      
      Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
      2204afde
    • 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
  2. 25 Jun, 2015 5 commits
    • Juan Castillo's avatar
      TBB: delete deprecated plat_match_rotpk() · f04585f3
      Juan Castillo authored
      The authentication framework deprecates plat_match_rotpk()
      in favour of plat_get_rotpk_info(). This patch removes
      plat_match_rotpk() from the platform port.
      
      Change-Id: I2250463923d3ef15496f9c39678b01ee4b33883b
      f04585f3
    • Juan Castillo's avatar
      TBB: switch to the new authentication framework · 1779ba6b
      Juan Castillo authored
      This patch modifies the Trusted Board Boot implementation to use
      the new authentication framework, making use of the authentication
      module, the cryto module and the image parser module to
      authenticate the images in the Chain of Trust.
      
      A new function 'load_auth_image()' has been implemented. When TBB
      is enabled, this function will call the authentication module to
      authenticate parent images following the CoT up to the root of
      trust to finally load and authenticate the requested image.
      
      The platform is responsible for picking up the right makefiles to
      build the corresponding cryptographic and image parser libraries.
      ARM platforms use the mbedTLS based libraries.
      
      The platform may also specify what key algorithm should be used
      to sign the certificates. This is done by declaring the 'KEY_ALG'
      variable in the platform makefile. FVP and Juno use ECDSA keys.
      
      On ARM platforms, BL2 and BL1-RW regions have been increased 4KB
      each to accommodate the ECDSA code.
      
      REMOVED BUILD OPTIONS:
      
        * 'AUTH_MOD'
      
      Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
      1779ba6b
    • Juan Castillo's avatar
      TBB: add TBBR Chain of Trust · dff93c86
      Juan Castillo authored
      This patch adds a CoT based on the Trusted Board Boot Requirements
      document*. The CoT consists of an array of authentication image
      descriptors indexed by the image identifiers.
      
      A new header file with TBBR image identifiers has been added.
      Platforms that use the TBBR (i.e. ARM platforms) may reuse these
      definitions as part of their platform porting.
      
      PLATFORM PORT - IMPORTANT:
      
      Default image IDs have been removed from the platform common
      definitions file (common_def.h). As a consequence, platforms that
      used those common definitons must now either include the IDs
      provided by the TBBR header file or define their own IDs.
      
      *The NVCounter authentication method has not been implemented yet.
      
      Change-Id: I7c4d591863ef53bb0cd4ce6c52a60b06fa0102d5
      dff93c86
    • 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
  3. 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
  4. 09 Jun, 2015 1 commit
    • Sandrine Bailleux's avatar
      CSS: Remove the constants MHU_SECURE_BASE/SIZE · fe55612b
      Sandrine Bailleux authored
      For CSS based platforms, the constants MHU_SECURE_BASE and
      MHU_SECURE_SIZE used to define the extents of the Trusted Mailboxes.
      As such, they were misnamed because the mailboxes are completely
      unrelated to the MHU hardware.
      
      This patch removes the MHU_SECURE_BASE and MHU_SECURE_SIZE #defines.
      The address of the Trusted Mailboxes is now relative to the base of
      the Trusted SRAM.
      
      This patch also introduces a new constant, SCP_COM_SHARED_MEM_BASE,
      which is the address of the first memory region used for communication
      between AP and SCP. This is used by the BOM and SCPI protocols.
      
      Change-Id: Ib200f057b19816bf05e834d111271c3ea777291f
      fe55612b
  5. 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
  6. 03 Jun, 2015 1 commit
  7. 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
  8. 27 May, 2015 1 commit
  9. 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
  10. 28 Apr, 2015 5 commits
    • Sandrine Bailleux's avatar
      Detect SCP version incompatibility · 556b966f
      Sandrine Bailleux authored
      There has been a breaking change in the communication protocols used
      between the AP cores and the SCP on CSS based platforms like Juno.
      This means both the AP Trusted Firmware and SCP firmware must be
      updated at the same time.
      
      In case the user forgets to update the SCP ROM firmware, this patch
      detects when it still uses the previous version of the communication
      protocol. It will then output a comprehensive error message that helps
      trouble-shoot the issue.
      
      Change-Id: I7baf8f05ec0b7d8df25e0ee53df61fe7be0207c2
      556b966f
    • Sandrine Bailleux's avatar
      Move to the new ARM SCP Messaging Interfaces · e234ba03
      Sandrine Bailleux authored
      The communication protocol used between the AP cores and the SCP
      in CSS-based platforms like Juno has undergone a number of changes.
      This patch makes the required modifications to the SCP Boot Protocol,
      SCPI Protocol and MHU driver code in shared CSS platform code so that
      the AP cores are still able to communicate with the SCP.
      
      This patch focuses on the mandatory changes to make it work. The
      design of this code needs to be improved but this will come in
      a subsequent patch.
      
      The main changes are:
      
       - MHU communication protocol
      
         - The command ID and payload size are no longer written into the
           MHU registers directly. Instead, they are stored in the payload
           area. The MHU registers are now used only as a doorbell to kick
           off messages. Same goes for any command result, the AP has to
           pick it up from the payload area.
      
       - SCP Boot Protocol
      
         - The BL3-0 image is now expected to embed a checksum. This
           checksum must be passed to the SCP, which uses it to check the
           integrity of the image it received.
      
         - The BL3-0 image used to be transferred a block (4KB)
           at a time. The SCP now supports receiving up to 128KB at a
           time, which is more than the size of the BL3-0 image.
           Therefore, the image is now sent in one go.
      
         - The command IDs have changed.
      
       - SCPI Protocol
      
         - The size of the SCPI payload has been reduced down from 512
           bytes to 256 bytes. This changes the base address of the
           AP-to-SCP payload area.
      
         - For commands that have a response, the response is the same SCPI
           header that was sent, except for the size and the status, which
           both must be updated appropriately. Success/Failure of a command
           is determined by looking at the updated status code.
      
         - Some command IDs have changed.
      
      NOTE: THIS PATCH BREAKS COMPATIBILITY WITH FORMER VERSIONS OF THE SCP
      FIRMWARE AND THUS REQUIRES AN UPDATE OF THIS BINARY. THE LATEST SCP
      BINARY CAN BE OBTAINED FROM THE ARM CONNECTED COMMUNITY WEBSITE.
      
      Change-Id: Ia5f6b95fe32401ee04a3805035748e8ef6718da7
      e234ba03
    • 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