1. 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
  2. 31 Mar, 2016 3 commits
    • Soby Mathew's avatar
      Migrate ARM standard platforms to the refactored TZC driver · 57f78201
      Soby Mathew authored
      This patch migrates ARM Standard platforms to the refactored TZC driver.
      
      Change-Id: I2a2f60b645f73e14d8f416740c4551cec87cb1fb
      57f78201
    • Juan Castillo's avatar
      TBB: add non-volatile counter support · 48279d52
      Juan Castillo authored
      This patch adds support for non-volatile counter authentication to
      the Authentication Module. This method consists of matching the
      counter values provided in the certificates with the ones stored
      in the platform. If the value from the certificate is lower than
      the platform, the boot process is aborted. This mechanism protects
      the system against rollback.
      
      The TBBR CoT has been updated to include this method as part of the
      authentication process. Two counters are used: one for the trusted
      world images and another for the non trusted world images.
      
      ** NEW PLATFORM APIs (mandatory when TBB is enabled) **
      
      int plat_get_nv_ctr(void *cookie, unsigned int *nv_ctr);
      
          This API returns the non-volatile counter value stored
          in the platform. The cookie in the first argument may be
          used to select the counter in case the platform provides
          more than one (i.e. TBSA compliant platforms must provide
          trusted and non-trusted counters). This cookie is specified
          in the CoT.
      
      int plat_set_nv_ctr(void *cookie, unsigned int nv_ctr);
      
          This API sets a new counter value. The cookie may be
          used to select the counter to be updated.
      
      An implementation of these new APIs for ARM platforms is also
      provided. The values are obtained from the Trusted Non-Volatile
      Counters peripheral. The cookie is used to pass the extension OID.
      This OID may be interpreted by the platform to know which counter
      must return. On Juno, The trusted and non-trusted counter values
      have been tied to 31 and 223, respectively, and cannot be modified.
      
      ** IMPORTANT **
      
      THIS PATCH BREAKS THE BUILD WHEN TRUSTED_BOARD_BOOT IS ENABLED. THE
      NEW PLATFORM APIs INTRODUCED IN THIS PATCH MUST BE IMPLEMENTED IN
      ORDER TO SUCCESSFULLY BUILD TF.
      
      Change-Id: Ic943b76b25f2a37f490eaaab6d87b4a8b3cbc89a
      48279d52
    • David Wang's avatar
      Add support to load BL31 in DRAM · 4518dd9a
      David Wang authored
      This patch adds an option to the ARM common platforms to load BL31 in the
      TZC secured DRAM instead of the default secure SRAM.
      
      To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options.
      If TSP is present, then setting this option also sets the TSP location
      to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag.
      
      To use this feature, BL2 platform code must map in the DRAM used by
      BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose.
      Currently, only the FVP BL2 platform code maps in this DRAM.
      
      Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67
      4518dd9a
  3. 14 Mar, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Remove all non-configurable dead loops · 1c3ea103
      Antonio Nino Diaz authored
      Added a new platform porting function plat_panic_handler, to allow
      platforms to handle unexpected error situations. It must be
      implemented in assembly as it may be called before the C environment
      is initialized. A default implementation is provided, which simply
      spins.
      
      Corrected all dead loops in generic code to call this function
      instead. This includes the dead loop that occurs at the end of the
      call to panic().
      
      All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have
      been removed.
      
      Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134
      1c3ea103
  4. 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
  5. 18 Feb, 2016 1 commit
    • Juan Castillo's avatar
      ARM platforms: rationalise memory attributes of shared memory · 74eb26e4
      Juan Castillo authored
      The shared memory region on ARM platforms contains the mailboxes and,
      on Juno, the payload area for communication with the SCP. This shared
      memory may be configured as normal memory or device memory at build
      time by setting the platform flag 'PLAT_ARM_SHARED_RAM_CACHED' (on
      Juno, the value of this flag is defined by 'MHU_PAYLOAD_CACHED').
      When set as normal memory, the platform port performs the corresponding
      cache maintenance operations. From a functional point of view, this is
      the equivalent of setting the shared memory as device memory, so there
      is no need to maintain both options.
      
      This patch removes the option to specify the shared memory as normal
      memory on ARM platforms. Shared memory is always treated as device
      memory. Cache maintenance operations are no longer needed and have
      been replaced by data memory barriers to guarantee that payload and
      MHU are accessed in the right order.
      
      Change-Id: I7f958621d6a536dd4f0fa8768385eedc4295e79f
      74eb26e4
  6. 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
  7. 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
  8. 11 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Re-factor definition of some macros on ARM platforms · ecf70f7b
      Vikram Kanigiri authored
      This patch moves the definition of some macros used only on
      ARM platforms from common headers to platform specific headers.
      It also forces all ARM standard platforms to have distinct
      definitions (even if they are usually the same).
       1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been
           moved from `css_def.h` to `platform_def.h`.
       2. `MHU_BASE` used in CSS platforms is moved from common css_def.h
          to platform specific header `platform_def.h` on Juno and
          renamed as `PLAT_ARM_MHU_BASE`.
       3. To cater for different sizes of BL images, new macros like
          `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All
          ARM platforms need to define them for each image.
      
      Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
      ecf70f7b
  9. 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
  10. 12 Jan, 2016 1 commit
  11. 21 Dec, 2015 2 commits
  12. 14 Dec, 2015 2 commits
    • Juan Castillo's avatar
      Remove dashes from image names: 'BL3-x' --> 'BL3x' · d178637d
      Juan Castillo authored
      This patch removes the dash character from the image name, to
      follow the image terminology in the Trusted Firmware Wiki page:
      
          https://github.com/ARM-software/arm-trusted-firmware/wiki
      
      Changes apply to output messages, comments and documentation.
      
      non-ARM platform files have been left unmodified.
      
      Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
      d178637d
    • Juan Castillo's avatar
      TBB: apply TBBR naming convention to certificates and extensions · 516beb58
      Juan Castillo authored
      This patch applies the TBBR naming convention to the certificates
      and the corresponding extensions defined by the CoT:
      
          * Certificate UUID names
          * Certificate identifier names
          * OID names
      
      Changes apply to:
      
          * Generic code (variables and defines)
          * The default certificate identifiers provided in the generic
            code
          * Build system
          * ARM platforms port
          * cert_create tool internal definitions
          * fip_create and cert_create tools command line options
          * Documentation
      
      IMPORTANT: this change breaks the compatibility with platforms
      that use TBBR. The platform will need to adapt the identifiers
      and OIDs to the TBBR naming convention introduced by this patch:
      
      Certificate UUIDs:
      
          UUID_TRUSTED_BOOT_FIRMWARE_BL2_CERT --> UUID_TRUSTED_BOOT_FW_CERT
          UUID_SCP_FIRMWARE_BL30_KEY_CERT --> UUID_SCP_FW_KEY_CERT
          UUID_SCP_FIRMWARE_BL30_CERT --> UUID_SCP_FW_CONTENT_CERT
          UUID_EL3_RUNTIME_FIRMWARE_BL31_KEY_CERT --> UUID_SOC_FW_KEY_CERT
          UUID_EL3_RUNTIME_FIRMWARE_BL31_CERT --> UUID_SOC_FW_CONTENT_CERT
          UUID_SECURE_PAYLOAD_BL32_KEY_CERT --> UUID_TRUSTED_OS_FW_KEY_CERT
          UUID_SECURE_PAYLOAD_BL32_CERT --> UUID_TRUSTED_OS_FW_CONTENT_CERT
          UUID_NON_TRUSTED_FIRMWARE_BL33_KEY_CERT --> UUID_NON_TRUSTED_FW_KEY_CERT
          UUID_NON_TRUSTED_FIRMWARE_BL33_CERT --> UUID_NON_TRUSTED_FW_CONTENT_CERT
      
      Certificate identifiers:
      
          BL2_CERT_ID --> TRUSTED_BOOT_FW_CERT_ID
          BL30_KEY_CERT_ID --> SCP_FW_KEY_CERT_ID
          BL30_CERT_ID --> SCP_FW_CONTENT_CERT_ID
          BL31_KEY_CERT_ID --> SOC_FW_KEY_CERT_ID
          BL31_CERT_ID --> SOC_FW_CONTENT_CERT_ID
          BL32_KEY_CERT_ID --> TRUSTED_OS_FW_KEY_CERT_ID
          BL32_CERT_ID --> TRUSTED_OS_FW_CONTENT_CERT_ID
          BL33_KEY_CERT_ID --> NON_TRUSTED_FW_KEY_CERT_ID
          BL33_CERT_ID --> NON_TRUSTED_FW_CONTENT_CERT_ID
      
      OIDs:
      
          TZ_FW_NVCOUNTER_OID --> TRUSTED_FW_NVCOUNTER_OID
          NTZ_FW_NVCOUNTER_OID --> NON_TRUSTED_FW_NVCOUNTER_OID
          BL2_HASH_OID --> TRUSTED_BOOT_FW_HASH_OID
          TZ_WORLD_PK_OID --> TRUSTED_WORLD_PK_OID
          NTZ_WORLD_PK_OID --> NON_TRUSTED_WORLD_PK_OID
          BL30_CONTENT_CERT_PK_OID --> SCP_FW_CONTENT_CERT_PK_OID
          BL30_HASH_OID --> SCP_FW_HASH_OID
          BL31_CONTENT_CERT_PK_OID --> SOC_FW_CONTENT_CERT_PK_OID
          BL31_HASH_OID --> SOC_AP_FW_HASH_OID
          BL32_CONTENT_CERT_PK_OID --> TRUSTED_OS_FW_CONTENT_CERT_PK_OID
          BL32_HASH_OID --> TRUSTED_OS_FW_HASH_OID
          BL33_CONTENT_CERT_PK_OID --> NON_TRUSTED_FW_CONTENT_CERT_PK_OID
          BL33_HASH_OID --> NON_TRUSTED_WORLD_BOOTLOADER_HASH_OID
          BL2U_HASH_OID --> AP_FWU_CFG_HASH_OID
          SCP_BL2U_HASH_OID --> SCP_FWU_CFG_HASH_OID
          NS_BL2U_HASH_OID --> FWU_HASH_OID
      
      Change-Id: I1e047ae046299ca913911c39ac3a6e123bd41079
      516beb58
  13. 09 Dec, 2015 5 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
    • Yatharth Kochar's avatar
      FWU: Add Firmware Update support in BL1 for ARM platforms · 436223de
      Yatharth Kochar authored
      This patch adds Firmware Update support for ARM platforms.
      
      New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide
      platform specific Firmware update code.
      
      BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for
      authenticating NS_BL2U image(For both FVP and JUNO platform).
      
      Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
      436223de
    • Soby Mathew's avatar
      Specify BL31 runtime console for ARM Standard platforms · 080225da
      Soby Mathew authored
      This patch overrides the default weak definition of
      `bl31_plat_runtime_setup()` for ARM Standard platforms to
      specify a BL31 runtime console. ARM Standard platforms are
      now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and
      `PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required
      by `arm_bl31_plat_runtime_setup()` to initialize the runtime
      console.
      
      The system suspend resume helper `arm_system_pwr_domain_resume()`
      is fixed to initialize the runtime console rather than the boot
      console on resumption from system suspend.
      
      Fixes ARM-software/tf-issues#220
      
      Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975
      080225da
    • 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
    • Soby Mathew's avatar
      Prepare platforms to use refactored ARM GIC drivers · f14d1886
      Soby Mathew authored
      This patch adds platform helpers for the new GICv2 and GICv3 drivers in
      plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate
      file in their build according to the GIC driver to be used. The existing
      plat_gic.c is only meant for the legacy GIC driver.
      
      In the case of ARM platforms, the major changes are as follows:
      
      1. The crash reporting helper macro `arm_print_gic_regs` that prints the GIC CPU
         interface register values has been modified to detect the type of CPU
         interface being used (System register or memory mappped interface) before
         using the right interface to print the registers.
      
      2. The power management helper function that is called after a core is powered
         up has been further refactored. This is to highlight that the per-cpu
         distributor interface should be initialised only when the core was originally
         powered down using the CPU_OFF PSCI API and not when the CPU_SUSPEND PSCI API
         was used.
      
      3. In the case of CSS platforms, the system power domain restore helper
         `arm_system_pwr_domain_resume()` is now only invoked in the `suspend_finish`
         handler as the system power domain is always expected to be initialized when
         the `on_finish` handler is invoked.
      
      Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6
      f14d1886
  14. 04 Dec, 2015 1 commit
    • Juan Castillo's avatar
      Fix SP804 delay timer on FVP · 540a5ba8
      Juan Castillo authored
      This patch fixes several issues with the SP804 delay timer on FVP:
      
      * By default, the SP804 dual timer on FVP runs at 32 KHz. In order
        to run the timer at 35 MHz (as specified in the FVP user manual)
        the Overwrite bit in the SP810 control register must be set.
      
      * The CLKMULT and CLKDIV definitions are mixed up:
      
            delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz)
      
        From the delay function:
      
            delta_us = (delta * ops->clk_mult) / ops->clk_div;
      
        Matching both expressions:
      
            1 / f(MHz) = ops->clk_mult / ops->clk_div
      
        And consequently:
      
            f(MHz) = ops->clk_div / ops->clk_mult
      
        Which, for a 35 MHz timer, translates to:
      
            ops->clk_div = 35
            ops->clk_mult = 1
      
      * The comment in the delay timer header file has been corrected:
        The ratio of the multiplier and the divider is the clock period
        in microseconds, not the frequency.
      
      Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1
      540a5ba8
  15. 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
  16. 26 Nov, 2015 1 commit
    • Sandrine Bailleux's avatar
      FVP: Do not power off secondary CPUs when booting an EL3 payload · cdf14088
      Sandrine Bailleux authored
      Normally, in the FVP port, secondary CPUs are immediately powered
      down if they are powered on at reset. However, when booting an EL3
      payload, we need to keep them powered on as the requirement is for
      all CPUs to enter the EL3 payload image. This patch puts them in a
      holding pen instead of powering them off.
      
      Change-Id: I6526a88b907a0ddb820bead72f1d350a99b1692c
      cdf14088
  17. 02 Nov, 2015 1 commit
    • Juan Castillo's avatar
      Remove deprecated IO return definitions · e098e244
      Juan Castillo authored
      Patch 7e26fe1f deprecates IO specific return definitions in favour
      of standard errno codes. This patch removes those definitions
      and its usage from the IO framework, IO drivers and IO platform
      layer. Following this patch, standard errno codes must be used
      when checking the return value of an IO function.
      
      Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f
      e098e244
  18. 30 Oct, 2015 1 commit
    • Soby Mathew's avatar
      CSS: Implement topology support for System power domain · 5f3a6030
      Soby Mathew authored
      This patch implements the necessary topology changes for supporting
      system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and
      PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform
      specific. In addition, the `arm_power_domain_tree_desc[]` and
      `arm_pm_idle_states[]` are modified to support the system power domain
      at level 2. With this patch, even though the power management operations
      involving the system power domain will not return any error, the platform
      layer will silently ignore any operations to the power domain. The actual
      power management support for the system power domain will be added later.
      
      Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
      5f3a6030
  19. 20 Oct, 2015 1 commit
    • Soby Mathew's avatar
      Reorganise PSCI PM handler setup on ARM Standard platforms · 785fb92b
      Soby Mathew authored
      This patch does the following reorganization to psci power management (PM)
      handler setup for ARM standard platform ports :
      
      1. The mailbox programming required during `plat_setup_psci_ops()` is identical
         for all ARM platforms. Hence the implementation of this API is now moved
         to the common `arm_pm.c` file. Each ARM platform now must define the
         PLAT_ARM_TRUSTED_MAILBOX_BASE macro, which in current platforms is the same
         as ARM_SHARED_RAM_BASE.
      
      2. The PSCI PM handler callback structure, `plat_psci_ops`, must now be
         exported via `plat_arm_psci_pm_ops`. This allows the common implementation
         of `plat_setup_psci_ops()` to return a platform specific `plat_psci_ops`.
         In the case of CSS platforms, a default weak implementation of the same is
         provided in `css_pm.c` which can be overridden by each CSS platform.
      
      3. For CSS platforms, the PSCI PM handlers defined in `css_pm.c` are now
         made library functions and a new header file `css_pm.h` is added to export
         these generic PM handlers. This allows the platform to reuse the
         adequate CSS PM handlers and redefine others which need to be customized
         when overriding the default `plat_arm_psci_pm_ops` in `css_pm.c`.
      
      Change-Id: I277910f609e023ee5d5ff0129a80ecfce4356ede
      785fb92b
  20. 11 Sep, 2015 2 commits
    • Vikram Kanigiri's avatar
      Define the Non-Secure timer frame ID for ARM platforms · 4b1439c5
      Vikram Kanigiri authored
      On Juno and FVP platforms, the Non-Secure System timer corresponds
      to frame 1. However, this is a platform-specific decision and it
      shouldn't be hard-coded. Hence, this patch introduces
      PLAT_ARM_NSTIMER_FRAME_ID which should be used by all ARM platforms
      to specify the correct non-secure timer frame.
      
      Change-Id: I6c3a905d7d89200a2f58c20ce5d1e1d166832bba
      4b1439c5
    • 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
  21. 01 Sep, 2015 1 commit
    • Vikram Kanigiri's avatar
      Configure all secure interrupts on ARM platforms · a7270d35
      Vikram Kanigiri authored
      ARM TF configures all interrupts as non-secure except those which
      are present in irq_sec_array. This patch updates the irq_sec_array
      with the missing secure interrupts for ARM platforms.
      
      It also updates the documentation to be inline with the latest
      implementation.
      
      Fixes ARM-software/tf-issues#312
      
      Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc
      a7270d35
  22. 13 Aug, 2015 6 commits
    • Soby Mathew's avatar
      PSCI: Add documentation and fix plat_is_my_cpu_primary() · 58523c07
      Soby Mathew authored
      This patch adds the necessary documentation updates to porting_guide.md
      for the changes in the platform interface mandated as a result of the new
      PSCI Topology and power state management frameworks. It also adds a
      new document `platform-migration-guide.md` to aid the migration of existing
      platform ports to the new API.
      
      The patch fixes the implementation and callers of
      plat_is_my_cpu_primary() to use w0 as the return parameter as implied by
      the function signature rather than x0 which was used previously.
      
      Change-Id: Ic11e73019188c8ba2bd64c47e1729ff5acdcdd5b
      58523c07
    • 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
  23. 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
  24. 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
  25. 03 Jun, 2015 1 commit