1. 20 Apr, 2017 2 commits
    • Yatharth Kochar's avatar
      AArch32: Add SP_MIN support for JUNO · 6f249345
      Yatharth Kochar authored
      
      
      This patch adds support for SP_MIN on JUNO platform.
      The changes include addition of AArch32 assembly files,
      JUNO specific SP_MIN make file and miscellaneous changes
      in ARM platform files to enable support for SP_MIN.
      
      Change-Id: Id1303f422fc9b98b9362c757b1a4225a16fffc0b
      Signed-off-by: default avatarYatharth Kochar <yatharth.kochar@arm.com>
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      6f249345
    • Yatharth Kochar's avatar
      Changes to support execution in AArch32 state for JUNO · 07570d59
      Yatharth Kochar authored
      
      
      Following steps are required to boot JUNO in AArch32 state:
      1> BL1, in AArch64 state, loads BL2.
      2> BL2, in AArch64 state, initializes DDR.
        Loads SP_MIN & BL33 (AArch32 executable)images.
        Calls RUN_IMAGE SMC to go back to BL1.
      3> BL1 writes AArch32 executable opcodes, to load and branch
        at the entrypoint address of SP_MIN, at HI-VECTOR address and
        then request for warm reset in AArch32 state using RMR_EL3.
      
      This patch makes following changes to facilitate above steps:
      * Added assembly function to carry out step 3 above.
      * Added region in TZC that enables Secure access to the
        HI-VECTOR(0xFFFF0000) address space.
      * AArch32 image descriptor is used, in BL2, to load
        SP_MIN and BL33 AArch32 executable images.
      
      A new flag `JUNO_AARCH32_EL3_RUNTIME` is introduced that
      controls above changes. By default this flag is disabled.
      
      NOTE: BL1 and BL2 are not supported in AArch32 state for JUNO.
      
      Change-Id: I091d56a0e6d36663e6d9d2bb53c92c672195d1ec
      Signed-off-by: default avatarYatharth Kochar <yatharth.kochar@arm.com>
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      07570d59
  2. 31 Mar, 2017 2 commits
  3. 30 Mar, 2017 1 commit
  4. 20 Mar, 2017 1 commit
    • Andre Przywara's avatar
      Add workaround for ARM Cortex-A53 erratum 855873 · b75dc0e4
      Andre Przywara authored
      
      
      ARM erratum 855873 applies to all Cortex-A53 CPUs.
      The recommended workaround is to promote "data cache clean"
      instructions to "data cache clean and invalidate" instructions.
      For core revisions of r0p3 and later this can be done by setting a bit
      in the CPUACTLR_EL1 register, so that hardware takes care of the promotion.
      As CPUACTLR_EL1 is both IMPLEMENTATION DEFINED and can be trapped to EL3,
      we set the bit in firmware.
      Also we dump this register upon crashing to provide more debug
      information.
      
      Enable the workaround for the Juno boards.
      
      Change-Id: I3840114291958a406574ab6c49b01a9d9847fec8
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      b75dc0e4
  5. 08 Mar, 2017 1 commit
    • Antonio Nino Diaz's avatar
      Apply workaround for errata 813419 of Cortex-A57 · ccbec91c
      Antonio Nino Diaz authored
      
      
      TLBI instructions for EL3 won't have the desired effect under specific
      circumstances in Cortex-A57 r0p0. The workaround is to execute DSB and
      TLBI twice each time.
      
      Even though this errata is only needed in r0p0, the current errata
      framework is not prepared to apply run-time workarounds. The current one
      is always applied if compiled in, regardless of the CPU or its revision.
      
      This errata has been enabled for Juno.
      
      The `DSB` instruction used when initializing the translation tables has
      been changed to `DSB ISH` as an optimization and to be consistent with
      the barriers used for the workaround.
      
      Change-Id: Ifc1d70b79cb5e0d87e90d88d376a59385667d338
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      ccbec91c
  6. 15 Feb, 2017 1 commit
    • dp-arm's avatar
      Juno: Disable SPIDEN in release builds · 09fad498
      dp-arm authored
      
      
      On Juno, the secure privileged invasive debug authentication signal
      (SPIDEN) is controlled by board SCC registers, which by default enable
      SPIDEN.  Disable secure privileged external debug in release builds by
      programming the appropriate Juno SoC registers.
      
      Change-Id: I61045f09a47dc647bbe95e1b7a60e768f5499f49
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      09fad498
  7. 23 Jan, 2017 1 commit
    • Masahiro Yamada's avatar
      Use #ifdef for IMAGE_BL* instead of #if · 3d8256b2
      Masahiro Yamada authored
      
      
      One nasty part of ATF is some of boolean macros are always defined
      as 1 or 0, and the rest of them are only defined under certain
      conditions.
      
      For the former group, "#if FOO" or "#if !FOO" must be used because
      "#ifdef FOO" is always true.  (Options passed by $(call add_define,)
      are the cases.)
      
      For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because
      checking the value of an undefined macro is strange.
      
      Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like
      follows:
      
        $(eval IMAGE := IMAGE_BL$(call uppercase,$(3)))
      
        $(OBJ): $(2)
                @echo "  CC      $$<"
                $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@
      
      This means, IMAGE_BL* is defined when building the corresponding
      image, but *undefined* for the other images.
      
      So, IMAGE_BL* belongs to the latter group where we should use #ifdef
      or #ifndef.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      3d8256b2
  8. 14 Dec, 2016 1 commit
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 31 Mar, 2016 1 commit
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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