1. 14 Dec, 2016 1 commit
  2. 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
  3. 05 Dec, 2016 1 commit
    • Jeenu Viswambharan's avatar
      Define and use no_ret macro where no return is expected · a806dad5
      Jeenu Viswambharan authored
      
      
      There are many instances in ARM Trusted Firmware where control is
      transferred to functions from which return isn't expected. Such jumps
      are made using 'bl' instruction to provide the callee with the location
      from which it was jumped to. Additionally, debuggers infer the caller by
      examining where 'lr' register points to. If a 'bl' of the nature
      described above falls at the end of an assembly function, 'lr' will be
      left pointing to a location outside of the function range. This misleads
      the debugger back trace.
      
      This patch defines a 'no_ret' macro to be used when jumping to functions
      from which return isn't expected. The macro ensures to use 'bl'
      instruction for the jump, and also, for debug builds, places a 'nop'
      instruction immediately thereafter (unless instructed otherwise) so as
      to leave 'lr' pointing within the function range.
      
      Change-Id: Ib34c69fc09197cfd57bc06e147cc8252910e01b0
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      a806dad5
  4. 21 Sep, 2016 1 commit
    • Yatharth Kochar's avatar
      ARM platform changes for new version of image loading · a8aa7fec
      Yatharth Kochar authored
      This patch adds changes in ARM platform code to use new
      version of image loading.
      
      Following are the major changes:
        -Refactor the signatures for bl31_early_platform_setup()
         and arm_bl31_early_platform_setup() function to use
         `void *` instead of `bl31_params_t *`.
        -Introduce `plat_arm_bl2_handle_scp_bl2()` to handle
         loading of SCP_BL2 image from BL2.
        -Remove usage of reserve_mem() function from
         `arm_bl1_early_platform_setup()`
        -Extract BL32 & BL33 entrypoint info, from the link list
         passed by BL2, in `arm_bl31_early_platform_setup()`
        -Provides weak definitions for following platform functions:
           plat_get_bl_image_load_info
           plat_get_next_bl_params
           plat_flush_next_bl_params
           bl2_plat_handle_post_image_load
        -Instantiates a descriptor array for ARM platforms
         describing image and entrypoint information for
         `SCP_BL2`, `BL31`, `BL32` and `BL33` images.
      
      All the above changes are conditionally compiled using the
      `LOAD_IMAGE_V2` flag.
      
      Change-Id: I5e88b9785a3df1a2b2bbbb37d85b8e353ca61049
      a8aa7fec
  5. 15 Sep, 2016 1 commit
    • Jeenu Viswambharan's avatar
      CSS: Implement support for NODE_HW_STATE · 3cc17aae
      Jeenu Viswambharan authored
      This patch implements CSS platform hook to support NODE_HW_STATE PSCI
      API. The platform hook queries SCP to obtain CSS power state. Power
      states returned by SCP are then converted to expected PSCI return codes.
      
      Juno's PSCI operation structure is modified to use the CSS
      implementation.
      
      Change-Id: I4a5edac0e5895dd77b51398cbd78f934831dafc0
      3cc17aae
  6. 19 Aug, 2016 1 commit
    • Sandrine Bailleux's avatar
      Add WFI in platform's unexpected error handlers · 8c9e1af0
      Sandrine Bailleux authored
      This patch adds a WFI instruction in the default implementations of
      plat_error_handler() and plat_panic_handler(). This potentially reduces
      power consumption by allowing the hardware to enter a low-power state.
      The same change has been made to the FVP and Juno platform ports.
      
      Change-Id: Ia4e6e1e5bf1ed42efbba7d0ebbad7be8d5f9f173
      8c9e1af0
  7. 25 Jul, 2016 1 commit
    • Antonio Nino Diaz's avatar
      ARM platforms: Define common image sizes · 0289970d
      Antonio Nino Diaz authored
      Compile option `ARM_BOARD_OPTIMISE_MMAP` has been renamed to
      `ARM_BOARD_OPTIMISE_MEM` because it now applies not only to defines
      related to the translation tables but to the image size as well.
      
      The defines `PLAT_ARM_MAX_BL1_RW_SIZE`, `PLAT_ARM_MAX_BL2_SIZE` and
      `PLAT_ARM_MAX_BL31_SIZE` have been moved to the file board_arm_def.h.
      This way, ARM platforms no longer have to set their own values if
      `ARM_BOARD_OPTIMISE_MEM=0` and they can specify optimized values
      otherwise. The common sizes have been set to the highest values used
      for any of the current build configurations.
      
      This is needed because in some build configurations some images are
      running out of space. This way there is a common set of values known
      to work for all of them and it can be optimized for each particular
      platform if needed.
      
      The space reserved for BL2 when `TRUSTED_BOARD_BOOT=0` has been
      increased. This is needed because when memory optimisations are
      disabled the values for Juno of `PLAT_ARM_MMAP_ENTRIES` and
      `MAX_XLAT_TABLES` are higher. If in this situation the code is
      compiled in debug mode and with "-O0", the code won't fit.
      
      Change-Id: I70a3d8d3a0b0cad1d6b602c01a7ea334776e718e
      0289970d
  8. 18 Jul, 2016 1 commit
    • Soby Mathew's avatar
      Rework type usage in Trusted Firmware · 4c0d0390
      Soby Mathew authored
      This patch reworks type usage in generic code, drivers and ARM platform files
      to make it more portable. The major changes done with respect to
      type usage are as listed below:
      
      * Use uintptr_t for storing address instead of uint64_t or unsigned long.
      * Review usage of unsigned long as it can no longer be assumed to be 64 bit.
      * Use u_register_t for register values whose width varies depending on
        whether AArch64 or AArch32.
      * Use generic C types where-ever possible.
      
      In addition to the above changes, this patch also modifies format specifiers
      in print invocations so that they are AArch64/AArch32 agnostic. Only files
      related to upcoming feature development have been reworked.
      
      Change-Id: I9f8c78347c5a52ba7027ff389791f1dad63ee5f8
      4c0d0390
  9. 16 Jun, 2016 1 commit
    • Soby Mathew's avatar
      Enable PSCI_STAT_COUNT/RESIDENCY for ARM standard platforms · d75f2578
      Soby Mathew authored
      This patch enables optional PSCI functions `PSCI_STAT_COUNT` and
      `PSCI_STAT_RESIDENCY` for ARM standard platforms. The optional platform
      API 'translate_power_state_by_mpidr()' is implemented for the Juno
      platform. 'validate_power_state()' on Juno downgrades PSCI CPU_SUSPEND
      requests for the system power level to the cluster power level.
      Hence, it is not suitable for validating the 'power_state' parameter
      passed in a PSCI_STAT_COUNT/RESIDENCY call.
      
      Change-Id: I9548322676fa468d22912392f2325c2a9f96e4d2
      d75f2578
  10. 14 Apr, 2016 1 commit
    • Gerald Lejeune's avatar
      Dump platform-defined regs in crash reporting · 9ff67fa6
      Gerald Lejeune authored
      
      
      It is up to the platform to implement the new plat_crash_print_regs macro to
      report all relevant platform registers helpful for troubleshooting.
      
      plat_crash_print_regs merges or calls previously defined plat_print_gic_regs
      and plat_print_interconnect_regs macros for each existing platforms.
      
      NOTE: THIS COMMIT REQUIRES ALL PLATFORMS THAT ENABLE THE `CRASH_REPORTING`
      BUILD FLAG TO MIGRATE TO USE THE NEW `plat_crash_print_regs()` MACRO. BY
      DEFAULT, `CRASH_REPORTING` IS ENABLED IN DEBUG BUILDS FOR ALL PLATFORMS.
      
      Fixes: arm-software/tf-issues#373
      Signed-off-by: default avatarGerald Lejeune <gerald.lejeune@st.com>
      9ff67fa6
  11. 31 Mar, 2016 1 commit
  12. 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
  13. 22 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Rationalise MMU and Page table related constants on ARM platforms · c64a0448
      Vikram Kanigiri authored
      `board_arm_def.h` contains multiple definitions of
      `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for
      memory usage depending upon the chosen build configuration. To ease
      maintenance of these constants, this patch replaces their multiple
      definitions with a single set of definitions that will work on all ARM
      platforms.
      
      Platforms can override the defaults with optimal values by enabling the
      `ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in
      the Juno ADP port.
      
      Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate
      future ARM platforms.
      
      Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
      c64a0448
  14. 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
  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. 15 Feb, 2016 2 commits
    • 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
    • Vikram Kanigiri's avatar
      Support for varying BOM/SCPI protocol base addresses in ARM platforms · 8e083ecd
      Vikram Kanigiri authored
      Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address
      for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To
      cater for future ARM platforms this is made platform specific.
      Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made
      platform specific.
      
      Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
      8e083ecd
  17. 11 Feb, 2016 2 commits
    • Vikram Kanigiri's avatar
      Add support for SSC_VERSION register on CSS platforms · 421295a0
      Vikram Kanigiri authored
      Each ARM Compute Subsystem based platform implements a System Security
      Control (SSC) Registers Unit. The SSC_VERSION register inside it carries
      information to identify the platform. This enables ARM Trusted Firmware
      to compile in support for multiple ARM platforms and choose one at
      runtime. This patch adds macros to enable access to this register.
      Each platform is expected to export its PART_NUMBER separately.
      
      Additionally, it also adds juno part number.
      
      Change-Id: I2b1d5f5b65a9c7b76c6f64480cc7cf0aef019422
      421295a0
    • 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
  18. 15 Dec, 2015 1 commit
    • Dan Handley's avatar
      FWU: Pass client cookie to FWU_SMC_UPDATE_DONE · 1f37b944
      Dan Handley authored
      The current FWU_SMC_UPDATE_DONE implementation incorrectly passes
      an unused framework cookie through to the 1st argument in the
      platform function `bl1_plat_fwu_done`. The intent is to allow
      the SMC caller to pass a cookie through to this function.
      
      This patch fixes FWU_SMC_UPDATE_DONE to pass x1 from the caller
      through to `bl1_plat_fwu_done`. The argument names are updated
      for clarity.
      
      Upstream platforms currently do not use this argument so no
      impact is expected.
      
      Change-Id: I107f4b51eb03e7394f66d9a534ffab1cbc09a9b2
      1f37b944
  19. 09 Dec, 2015 3 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
    • 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
  20. 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
  21. 19 Nov, 2015 2 commits
    • Sandrine Bailleux's avatar
      Juno R2: Configure the correct L2 RAM latency values · 1dbe3159
      Sandrine Bailleux authored
      The default reset values for the L2 Data & Tag RAM latencies on the
      Cortex-A72 on Juno R2 are not suitable. This patch modifies
      the Juno platform reset handler to configure the right settings
      on Juno R2.
      
      Change-Id: I20953de7ba0619324a389e0b7bbf951b64057db8
      1dbe3159
    • Sandrine Bailleux's avatar
      Juno: Rework platform reset handler · 23d39dbc
      Sandrine Bailleux authored
      This patch splits the Juno reset handler in 4 distinct pieces:
      
       - Detection of the board revision;
       - Juno R0 specific handler;
       - Juno R1 specific handler;
       - Juno R2 specific handler.
      
      Depending on the board revision, the appropriate handler is called.
      This makes the code easier to understand and maintain.
      
      This patch is mainly cosmetic. The only functional change introduced
      is that the Juno platform reset handler will now spin infinitely if
      the board revision is not recognised. Previously, it would have
      assumed that it was running on Juno R1 in this case.
      
      Change-Id: I54ed77c4665085ead9d1573316c9c884d7d3ffa0
      23d39dbc
  22. 04 Nov, 2015 1 commit
    • Brendan Jackman's avatar
      Add A72 support for Juno R2 · 0f829ea9
      Brendan Jackman authored
      Cortex-A72 library support is now compiled into the Juno platform port to go
      with the existing A53/A57 support. This enables a single set of Juno TF
      binaries to run on Juno R0, R1 and R2 boards.
      
      Change-Id: I4a601dc4f671e98bdb19d98bbb66f02f0d8b7fc7
      0f829ea9
  23. 30 Oct, 2015 2 commits
    • 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
    • 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
  24. 27 Oct, 2015 1 commit
    • David Wang's avatar
      Allow CSS to redefine function `plat_arm_calc_core_pos` · 371d4399
      David Wang authored
      Currently all ARM CSS platforms which include css_helpers.S use the same
      strong definition of `plat_arm_calc_core_pos`. This patch allows these CSS
      platforms to define their own strong definition of this function.
      
      * Replace the strong definition of `plat_arm_calc_core_pos` in
        css_helpers.S with a utility function `css_calc_core_pos_swap_cluster`
        does the same thing (swaps cluster IDs). ARM CSS platforms may choose
        to use this function or not.
      
      * Add a Juno strong definition of `plat_arm_calc_core_pos`, which uses
        `css_calc_core_pos_swap_cluster`.
      
      Change-Id: Ib5385ed10e44adf6cd1398a93c25973eb3506d9d
      371d4399
  25. 11 Sep, 2015 1 commit
    • Vikram Kanigiri's avatar
      Separate CSS security setup from SOC security setup · 883852ca
      Vikram Kanigiri authored
      Currently, on ARM platforms(ex. Juno) non-secure access to specific
      peripheral regions, config registers which are inside and outside CSS
      is done in the soc_css_security_setup(). This patch separates the CSS
      security setup from the SOC security setup in the css_security_setup().
      
      The CSS security setup involves programming of the internal NIC to
      provide access to regions inside the CSS. This is needed only in
      Juno, hence Juno implements it in its board files as css_init_nic400().
      
      Change-Id: I95a1fb9f13f9b18fa8e915eb4ae2f15264f1b060
      883852ca
  26. 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
  27. 13 Aug, 2015 1 commit
    • 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
  28. 25 Jun, 2015 1 commit
    • 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
  29. 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
  30. 28 Apr, 2015 1 commit
    • 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