1. 26 Mar, 2018 1 commit
  2. 28 Feb, 2018 2 commits
  3. 06 Dec, 2017 1 commit
    • Antonio Nino Diaz's avatar
      fvp: Disable SYSTEM_SUSPEND when ARM_BL31_IN_DRAM · 7d44ac1e
      Antonio Nino Diaz authored
      
      
      After returning from SYSTEM_SUSPEND state, BL31 reconfigures the
      TrustZone Controller during the boot sequence. If BL31 is placed in
      TZC-secured DRAM, it will try to change the permissions of the memory it
      is being executed from, causing an exception.
      
      The solution is to disable SYSTEM_SUSPEND when the Trusted Firmware has
      been compiled with ``ARM_BL31_IN_DRAM=1``.
      
      Change-Id: I96dc50decaacd469327c6b591d07964726e58db4
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      7d44ac1e
  4. 20 Nov, 2017 1 commit
    • Dimitris Papastamos's avatar
      Refactor Statistical Profiling Extensions implementation · 281a08cc
      Dimitris Papastamos authored
      
      
      Factor out SPE operations in a separate file.  Use the publish
      subscribe framework to drain the SPE buffers before entering secure
      world.  Additionally, enable SPE before entering normal world.
      
      A side effect of this change is that the profiling buffers are now
      only drained when a transition from normal world to secure world
      happens.  Previously they were drained also on return from secure
      world, which is unnecessary as SPE is not supported in S-EL1.
      
      Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      281a08cc
  5. 13 Nov, 2017 1 commit
    • Jeenu Viswambharan's avatar
      ARM platforms: Make arm_validate_ns_entrypoint() common · 71e7a4e5
      Jeenu Viswambharan authored
      
      
      The function arm_validate_ns_entrypoint() validates a given non-secure
      physical address. This function however specifically returns PSCI error
      codes.
      
      Non-secure physical address validation is potentially useful across ARM
      platforms, even for non-PSCI use cases. Therefore make this function
      common by returning 0 for success or -1 otherwise.
      
      Having made the function common, make arm_validate_psci_entrypoint() a
      wrapper around arm_validate_ns_entrypoint() which only translates return
      value into PSCI error codes. This wrapper is now used where
      arm_validate_ns_entrypoint() was currently used for PSCI entry point
      validation.
      
      Change-Id: Ic781fc3105d6d199fd8f53f01aba5baea0ebc310
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      71e7a4e5
  6. 11 Oct, 2017 1 commit
    • Soby Mathew's avatar
      ARM platforms: enable GICv3 state save/restore · e35a3fb5
      Soby Mathew authored
      
      
      Provides GICv3 save/restore feature to arm_system_pwr_domain_resume and
      arm_system_pwr_domain_save functions.
      
      Introduce FVP PSCI power level 3 (System level) support. This is solely
      done to provide example code on how to use the GICv3 save and restore
      helpers.
      
      Also make CSS GICv3 platforms power off the Redistributor on SYSTEM
      SUSPEND as its state is saved and restored.
      
      Change-Id: I0d852f3af8824edee1a17c085cf593ddd33a4e77
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Co-Authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      e35a3fb5
  7. 25 Sep, 2017 1 commit
    • Roberto Vargas's avatar
      mem_protect: Add mem_protect support in Juno and FVP for DRAM1 · f145403c
      Roberto Vargas authored
      
      
      mem_protect needs some kind of non-volatile memory because it has
      to remember its state across reset and power down events.
      The most suitable electronic part for this feature is a NVRAM
      which should be only accesible from the secure world. Juno and
      FVP lack such hardware and for this reason the MEM_PROTECT
      functionality is implemented with Flash EEPROM memory on both
      boards, even though this memory is accesible from the non-secure
      world. This is done only to show a full implementation of
      these PSCI features, but an actual system shouldn't use a
      non-secure NVRAM to implement it.
      
      The EL3 runtime software will write the mem_protect flag and BL2
      will read and clear the memory ranges if enabled. It is done in
      BL2 because it reduces the time that TF needs access to the full
      non-secure memory.
      
      The memory layout of both boards is defined using macros which
      take different values in Juno and FVP platforms. Generic platform
      helpers are added that use the platform specific macros to generate
      a mem_region_t that is valid for the platform.
      
      Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      f145403c
  8. 14 Jul, 2017 1 commit
  9. 22 Jun, 2017 1 commit
    • dp-arm's avatar
      aarch64: Enable Statistical Profiling Extensions for lower ELs · d832aee9
      dp-arm authored
      
      
      SPE is only supported in non-secure state.  Accesses to SPE specific
      registers from SEL1 will trap to EL3.  During a world switch, before
      `TTBR` is modified the SPE profiling buffers are drained.  This is to
      avoid a potential invalid memory access in SEL1.
      
      SPE is architecturally specified only for AArch64.
      
      Change-Id: I04a96427d9f9d586c331913d815fdc726855f6b0
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      d832aee9
  10. 24 May, 2017 1 commit
  11. 03 May, 2017 1 commit
  12. 15 Dec, 2016 1 commit
  13. 07 Dec, 2016 1 commit
    • Soby Mathew's avatar
      Allow ARM Standard platforms to dynamically define PSCI capability · 5486a965
      Soby Mathew authored
      
      
      The capabilities exposed by the PSCI generic layer depends on the hooks
      populated by the platform in `plat_arm_psci_pm_ops`. Currently ARM
      Standard platforms statically define this structure. However, some
      platforms may want to modify the hooks at runtime before registering
      them with the generic layer.
      
      This patch introduces a new ARM platform layer API
      `plat_arm_psci_override_pm_ops` which allows the platform to probe
      the power controller and modify `plat_arm_psci_pm_ops` if required.
      Consequently, 'plat_arm_psci_pm_ops' is no longer qualified as
      `const` on ARM Standard platforms.
      
      Change-Id: I7dbb44b7bd36c20ec14ded5ee45a96816ca2ab9d
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      5486a965
  14. 15 Sep, 2016 1 commit
    • Jeenu Viswambharan's avatar
      FVP: Implement support for NODE_HW_STATE · 1298ae02
      Jeenu Viswambharan authored
      This patch implements FVP platform hook to support NODE_HW_STATE PSCI
      API. The platform hook validates the given MPIDR and reads corresponding
      status from FVP power controller, and returns expected values for the
      PSCI call.
      
      Change-Id: I286c92637da11858db2c8aba8ba079389032de6d
      1298ae02
  15. 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
  16. 21 Dec, 2015 1 commit
    • Sandrine Bailleux's avatar
      Remove out-dated comment in FVP PWRC code · 0f09c8f7
      Sandrine Bailleux authored
      fvp_pwr_domain_on() used to program the CPUs mailbox. This changed
      with commit 804040d1 but the comment documenting this code still
      refers to the mailbox programming. This patch removes this out-dated
      information.
      
      Change-Id: Ibfe2a426bdda6e71f20c83a99cb223ceca9c559c
      0f09c8f7
  17. 09 Dec, 2015 2 commits
    • 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
  18. 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
  19. 13 Aug, 2015 4 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: 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
  20. 28 Apr, 2015 2 commits
    • 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
      Migrate FVP port to use common code · 60eea55e
      Dan Handley authored
      Major update to the FVP platform port to use the common platform code
      in (include/)plat/arm/* and (include/)plat/common/*. This mainly
      consists of removing duplicated code but also introduces some small
      behavioural changes where there was unnecessary variation between the
      FVP and Juno ports. See earlier commit titled `Add common ARM and CSS
      platform code` for details.
      
      Also add support for Foundation FVP version 9.1 during FVP config
      setup to prevent a warning being emitted in the console.
      
      Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
      60eea55e
  21. 16 Mar, 2015 1 commit
  22. 05 Mar, 2015 1 commit
    • Sandrine Bailleux's avatar
      Fix violations to the coding style · ba592e28
      Sandrine Bailleux authored
      All coding style violations have been fixed in a previous patch and
      since then, each individual patch has been checked in this regard.
      However, the latest version of the checkpatch.pl script from the Linux
      kernel is more advanced and it is able to flag new errors in the
      Trusted Firmware codebase. This patch fixes them.
      
      Change-Id: I1f332f2440984be85d36b231bb83260368987077
      ba592e28
  23. 23 Jan, 2015 2 commits
    • Soby Mathew's avatar
      Validate power_state and entrypoint when executing PSCI calls · 539dcedb
      Soby Mathew authored
      This patch allows the platform to validate the power_state and
      entrypoint information from the normal world early on in PSCI
      calls so that we can return the error safely. New optional
      pm_ops hooks `validate_power_state` and `validate_ns_entrypoint`
      are introduced to do this.
      
      As a result of these changes, all the other pm_ops handlers except
      the PSCI_ON handler are expected to be successful. Also, the PSCI
      implementation will now assert if a PSCI API is invoked without the
      corresponding pm_ops handler being registered by the platform.
      
      NOTE : PLATFORM PORTS WILL BREAK ON MERGE OF THIS COMMIT. The
      pm hooks have 2 additional optional callbacks and the return type
      of the other hooks have changed.
      
      Fixes ARM-Software/tf-issues#229
      
      Change-Id: I036bc0cff2349187c7b8b687b9ee0620aa7e24dc
      539dcedb
    • Soby Mathew's avatar
      Remove `ns_entrypoint` and `mpidr` from parameters in pm_ops · e146f4cc
      Soby Mathew authored
      This patch removes the non-secure entry point information being passed
      to the platform pm_ops which is not needed. Also, it removes the `mpidr`
      parameter for  platform pm hooks which are meant to do power management
      operations only on the current cpu.
      
      NOTE: PLATFORM PORTS MUST BE UPDATED AFTER MERGING THIS COMMIT.
      
      Change-Id: If632376a990b7f3b355f910e78771884bf6b12e7
      e146f4cc
  24. 20 Aug, 2014 1 commit
    • Soby Mathew's avatar
      Add CPU specific power management operations · add40351
      Soby Mathew authored
      This patch adds CPU core and cluster power down sequences to the CPU specific
      operations framework introduced in a earlier patch. Cortex-A53, Cortex-A57 and
      generic AEM sequences have been added. The latter is suitable for the
      Foundation and Base AEM FVPs. A pointer to each CPU's operations structure is
      saved in the per-cpu data so that it can be easily accessed during power down
      seqeunces.
      
      An optional platform API has been introduced to allow a platform to disable the
      Accelerator Coherency Port (ACP) during a cluster power down sequence. The weak
      definition of this function (plat_disable_acp()) does not take any action. It
      should be overriden with a strong definition if the ACP is present on a
      platform.
      
      Change-Id: I8d09bd40d2f528a28d2d3f19b77101178778685d
      add40351
  25. 19 Aug, 2014 2 commits
    • Achin Gupta's avatar
      fvp: Rework when platform actions are performed · 7d2ccfd7
      Achin Gupta authored
      This patch reworks FVP port's power management implementation to perform
      platform actions only when the platform exported hook is invoked for the highest
      affinity level to enter/exit the OFF state.
      
      For example, during a CPU_OFF operation, fvp_affinst_off() is called twice: for
      affinity level 0 and affinity level 1 (in that order). CPU specific operations
      are deferred until the next invocation if it is determined through a call to
      psci_get_max_phys_off_afflvl() that this is CPU is the last in the cluster.
      
      Similarly, during power up if the CPU is the first in the cluster, both CPU and
      cluster specific operations are performed when fvp_affinst_on_finish() is
      invoked for affinity level 1. Earlier, they were done across the two invocations
      of the handler.
      
      Change-Id: I4288ed3ba1385db36a69cc2e598deb219f209b8a
      7d2ccfd7
    • Juan Castillo's avatar
      Add support for PSCI SYSTEM_OFF and SYSTEM_RESET APIs · d5f13093
      Juan Castillo authored
      This patch adds support for SYSTEM_OFF and SYSTEM_RESET PSCI
      operations. A platform should export handlers to complete the
      requested operation. The FVP port exports fvp_system_off() and
      fvp_system_reset() as an example.
      
      If the SPD provides a power management hook for system off and
      system reset, then the SPD is notified about the corresponding
      operation so it can do some bookkeeping. The TSPD exports
      tspd_system_off() and tspd_system_reset() for that purpose.
      
      Versatile Express shutdown and reset methods have been removed
      from the FDT as new PSCI sys_poweroff and sys_reset services
      have been added. For those kernels that do not support yet these
      PSCI services (i.e. GICv3 kernel), the original dtsi files have
      been renamed to *-no_psci.dtsi.
      
      Fixes ARM-software/tf-issues#218
      
      Change-Id: Ic8a3bf801db979099ab7029162af041c4e8330c8
      d5f13093
  26. 14 Aug, 2014 2 commits
    • Dan Handley's avatar
      Remove platform dependency in CCI-400 driver · cae3ef99
      Dan Handley authored
      * Create cci_init() function in CCI-400 driver to allow platform
        to provide arguments needed by the driver (i.e. base address
        and cluster indices for the ACE slave interfaces).
      
      * Rename cci_(en|dis)able_coherency to
        cci_(en|dis)able_cluster_coherency to make it clear that
        the driver only enables/disables the coherency of CPU
        clusters and not other devices connected to the CCI-400.
      
      * Update FVP port to use new cci_init() function and remove
        unnecessary CCI defintions from platform_def.h. Also rename
        fvp_cci_setup() to fvp_cci_enable() to more clearly
        differentiate between CCI initialization and enabling.
      
      THIS CHANGE REQUIRES PLATFORM PORTS THAT USE THE CCI-400 DRIVER
      TO BE UPDATED
      
      Fixes ARM-software/tf-issues#168
      
      Change-Id: I1946a51409b91217b92285b6375082619f607fec
      cae3ef99
    • Juan Castillo's avatar
      FVP: make usage of Trusted DRAM optional at build time · 186c1d4b
      Juan Castillo authored
      This patch groups the current contents of the Trusted DRAM region at
      address 0x00_0600_0000 (entrypoint mailboxes and BL3-1 parameters) in
      a single shared memory area that may be allocated to Trusted SRAM
      (default) or Trusted DRAM at build time by setting the
      FVP_SHARED_DATA_LOCATION make variable. The size of this shared
      memory is 4096 bytes.
      
      The combination 'Shared data in Trusted SRAM + TSP in Trusted DRAM'
      is not currently supported due to restrictions in the maximum number
      of mmu tables that can be created.
      
      Documentation has been updated to reflect these changes.
      
      Fixes ARM-software/tf-issues#100
      
      Change-Id: I26ff04d33ce4cacf8d770d1a1e24132b4fc53ff0
      186c1d4b
  27. 12 Aug, 2014 1 commit
    • Juan Castillo's avatar
      FVP: apply new naming conventions to memory regions · 637ebd2e
      Juan Castillo authored
      Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM
      Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM
      Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM
      
      BLn_BASE and BLn_LIMIT definitions have been updated and are based on
      these new memory regions.
      
      The available memory for each bootloader in the linker script is
      defined by BLn_BASE and BLn_LIMIT, instead of the complete memory
      region.
      
      TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of
      the platform porting.
      
      FVP common definitions are defined in fvp_def.h while platform_def.h
      contains exclusively (with a few exceptions) the definitions that are
      mandatory in the porting guide. Therefore, platform_def.h now includes
      fvp_def.h instead of the other way around.
      
      Porting guide has been updated to reflect these changes.
      
      Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05
      637ebd2e
  28. 28 Jul, 2014 1 commit
    • Achin Gupta's avatar
      Remove the concept of coherent stacks · 539a7b38
      Achin Gupta authored
      This patch removes the allocation of memory for coherent stacks, associated
      accessor function and some dead code which called the accessor function. It also
      updates the porting guide to remove the concept and the motivation behind using
      stacks allocated in coherent memory.
      
      Fixes ARM-software/tf-issues#198
      
      Change-Id: I00ff9a04f693a03df3627ba39727e3497263fc38
      539a7b38
  29. 09 Jul, 2014 2 commits
    • Dan Handley's avatar
      Refactor fvp gic code to be a generic driver · 1e8c5c4f
      Dan Handley authored
      Refactor the FVP gic code in plat/fvp/fvp_gic.c to be a generic ARM
      GIC driver in drivers/arm/gic/arm_gic.c. Provide the platform
      specific inputs in the arm_gic_setup() function so that the driver
      has no explicit dependency on platform code.
      
      Provide weak implementations of the platform interrupt controller
      API in a new file, plat/common/plat_gic.c. These simply call through
      to the ARM GIC driver.
      
      Move the only remaining FVP GIC function, fvp_gic_init() to
      plat/fvp/aarch64/fvp_common.c and remove plat/fvp/fvp_gic.c
      
      Fixes ARM-software/tf-issues#182
      
      Change-Id: Iea82fe095fad62dd33ba9efbddd48c57717edd21
      1e8c5c4f
    • Dan Handley's avatar
      Refactor fvp_config into common platform header · 6f3b195a
      Dan Handley authored
      Changed the fvp_config array in fvp_common.c into a struct and
      moved into a new optional common platform header,
      include/plat/common/plat_config.h. Removed the config definitions
      in fvp_def.h and updated all references to the platform config.
      
      This makes the interface to the platform config cleaner and uses
      a little less RAM.
      
      Fixes ARM-software/tf-issues#180
      
      Change-Id: I58dd7b3c150f24f7ee230a26fd57c827853ba803
      6f3b195a
  30. 18 Jun, 2014 1 commit
    • Soby Mathew's avatar
      Remove re-initialisation of system timers after warm boot for FVP · b1e71b20
      Soby Mathew authored
      This patch removes the reinitialisation of memory mapped system timer
      registers after a warm boot for the FVP. The system timers in FVP are
      in the 'Always ON' power domain which meant the reinitialisation was
      redundant and it could have conflicted with the setup the normal
      world has done.
      
      The programming of CNTACR(x) and CNTNSAR, the system timer registers,
      are removed from the warm boot path with this patch.
      
      Fixes ARM-software/tf-issues#169
      
      Change-Id: Ie982eb03d1836b15ef3cf1568de2ea68a08b443e
      b1e71b20