1. 26 Apr, 2016 1 commit
    • Yatharth Kochar's avatar
      Conditionally compile `plat_get_syscnt_freq()` in ARM standard platforms · 1969625a
      Yatharth Kochar authored
      This patch puts the definition of `plat_get_syscnt_freq()`
      under `#ifdef ARM_SYS_CNTCTL_BASE` in arm_common.c file.
      This is the fix for compilation error introduced by commit-id
      `749ade45`, for platforms that use arm_common.c but do not
      provide a memory mapped interface to the generic counter.
      
      Fixes ARM-software/tf-issues#395
      
      Change-Id: I2f2b10bd9500fa15308541ccb15829306a76a745
      1969625a
  2. 21 Apr, 2016 1 commit
    • Yatharth Kochar's avatar
      Move `plat_get_syscnt_freq()` to arm_common.c · c073fda1
      Yatharth Kochar authored
      This patch moves the definition for `plat_get_syscnt_freq()`
      from arm_bl31_setup.c to arm_common.c. This could be useful
      in case a delay timer needs to be installed based on the
      generic timer in other BLs.
      This patch also modifies the return type for this function
      from `uint64_t` to `unsigned long long` within ARM and other
      platform files.
      
      Change-Id: Iccdfa811948e660d4fdcaae60ad1d700e4eda80d
      c073fda1
  3. 01 Apr, 2016 2 commits
  4. 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
  5. 15 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Add API to return memory map on ARM platforms · 65cb1c4c
      Vikram Kanigiri authored
      Functions to configure the MMU in S-EL1 and EL3 on ARM platforms
      expect each platform to export its memory map in the `plat_arm_mmap`
      data structure. This approach does not scale well in case the memory
      map cannot be determined until runtime. To cater for this possibility,
      this patch introduces the plat_arm_get_mmap() API. It returns a
      reference to the `plat_arm_mmap` by default but can be overridden
      by a platform if required.
      
      Change-Id: Idae6ad8fdf40cdddcd8b992abc188455fa047c74
      65cb1c4c
  6. 20 Jan, 2016 1 commit
    • Juan Castillo's avatar
      ARM plat: add build option to unlock access to non-secure timer · 0e5dcdd2
      Juan Castillo authored
      Currently, Trusted Firmware on ARM platforms unlocks access to the
      timer frame registers that will be used by the Non-Secure world. This
      unlock operation should be done by the Non-Secure software itself,
      instead of relying on secure firmware settings.
      
      This patch adds a new ARM specific build option 'ARM_CONFIG_CNTACR'
      to unlock access to the timer frame by setting the corresponding
      bits in the CNTACR<N> register. The frame id <N> is defined by
      'PLAT_ARM_NSTIMER_FRAME_ID'. Default value is true (unlock timer
      access).
      
      Documentation updated accordingly.
      
      Fixes ARM-software/tf-issues#170
      
      Change-Id: Id9d606efd781e43bc581868cd2e5f9c8905bdbf6
      0e5dcdd2
  7. 14 Dec, 2015 1 commit
  8. 30 Oct, 2015 1 commit
    • Soby Mathew's avatar
      Support PSCI SYSTEM SUSPEND on Juno · c1bb8a05
      Soby Mathew authored
      This patch adds the capability to power down at system power domain level
      on Juno via the PSCI SYSTEM SUSPEND API. The CSS power management helpers
      are modified to add support for power management operations at system
      power domain level. A new helper for populating `get_sys_suspend_power_state`
      handler in plat_psci_ops is defined. On entering the system suspend state,
      the SCP powers down the SYSTOP power domain on the SoC and puts the memory
      into retention mode. On wakeup from the power down, the system components
      on the CSS will be reinitialized by the platform layer and the PSCI client
      is responsible for restoring the context of these system components.
      
      According to PSCI Specification, interrupts targeted to cores in PSCI CPU
      SUSPEND should be able to resume it. On Juno, when the system power domain
      is suspended, the GIC is also powered down. The SCP resumes the final core
      to be suspend when an external wake-up event is received. But the other
      cores cannot be woken up by a targeted interrupt, because GIC doesn't
      forward these interrupts to the SCP. Due to this hardware limitation,
      we down-grade PSCI CPU SUSPEND requests targeted to the system power domain
      level to cluster power domain level in `juno_validate_power_state()`
      and the CSS default `plat_arm_psci_ops` is overridden in juno_pm.c.
      
      A system power domain resume helper `arm_system_pwr_domain_resume()` is
      defined for ARM standard platforms which resumes/re-initializes the
      system components on wakeup from system suspend. The security setup also
      needs to be done on resume from system suspend, which means
      `plat_arm_security_setup()` must now be included in the BL3-1 image in
      addition to previous BL images if system suspend need to be supported.
      
      Change-Id: Ie293f75f09bad24223af47ab6c6e1268f77bcc47
      c1bb8a05
  9. 28 Apr, 2015 1 commit
    • 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