1. 26 Feb, 2018 1 commit
    • Soby Mathew's avatar
      ARM Platforms: Load HW_CONFIG in BL2 · cab0b5b0
      Soby Mathew authored
      
      
      The patch adds the necessary changes to load HW_CONFIG in BL2 for
      ARM Platforms :
      
      1. The load address of HW_CONFIG is specified via the `hw_config_addr`
      property in TB_FW_CONFIG is loaded by BL1. The `hw_config_max_size`
      property defines the maximum size to be expected for the HW_CONFIG.
      The `arm_dyn_cfg_helpers.c` and corresponding header implements
      utility functions to parse these DT properties defined.
      The `arm_dyn_cfg.c` implements wrappers to these helpers to enable
      them to be invoked from ARM platform layer.
      
      2. `HW_CONFIG` is added to the `bl2_mem_params_descs[]` array which is
      the list of images to be loaded by BL2.
      
      3. The `libfdt` sources are now included when BL2 is built
      
      4. A new helper `populate_next_bl_params_config()` is introduced in
      desc_image_load.c to populate the subsequent executable BL images
      with the `hw_config` and the corresponding `fw_config` if available.
      The `plat_get_next_bl_params()` API for ARM platforms is modified to
      invoke this new helper.
      
      5. The implementation of `bl2_early_platform_setup2()` is modified to
      consider `arg0` as well in addition to `arg1` passed from BL1.
      
      6. Bump up the BL2 size for Juno to accommodate the inclusion of libfdt.
      
      Change-Id: I80f1554adec41753e0d179a5237364f04fe13a3f
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      cab0b5b0
  2. 19 Dec, 2017 1 commit
  3. 29 Nov, 2017 1 commit
    • Soby Mathew's avatar
      ARM platforms: Fixup AArch32 builds · 5744e874
      Soby Mathew authored
      
      
      This patch fixes a couple of issues for AArch32 builds on ARM reference
      platforms :
      
      1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and
         AArch32 build. Since BL31 is not present in AArch32 mode, this meant that
         the BL31 memory is empty when built for AArch32. Hence this patch allocates
         BL32 to the memory region occupied by BL31 for AArch32 builds.
      
         As a side-effect of this change, the ARM_TSP_RAM_LOCATION macro cannot
         be used to control the load address of BL32 in AArch32 mode which was
         never the intention of the macro anyway.
      
      2. A static assert is added to sp_min linker script to check that the progbits
         are within the bounds expected when overlaid with other images.
      
      3. Fix specifying `SPD` when building Juno for AArch32 mode. Due to the quirks
         involved when building Juno for AArch32 mode, the build option SPD needed to
         specifed. This patch corrects this and also updates the documentation in the
         user-guide.
      
      4. Exclude BL31 from the build and FIP when building Juno for AArch32 mode. As
         a result the previous assumption that BL31 must be always present is removed
         and the certificates for BL31 is only generated if `NEED_BL31` is defined.
      
      Change-Id: I1c39bbc0abd2be8fbe9f2dea2e9cb4e3e3e436a8
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      5744e874
  4. 25 Oct, 2017 1 commit
  5. 16 Oct, 2017 1 commit
    • Jeenu Viswambharan's avatar
      ARM platforms: Migrate to using interrupt properties · b2c363b1
      Jeenu Viswambharan authored
      
      
      An earlier patch added provision for the platform to provide secure
      interrupt properties. ARM platforms already has a list of interrupts
      that fall into different secure groups.
      
      This patch defines macros that enumerate interrupt properties in the
      same fashion, and points the driver driver data to a list of interrupt
      properties rather than list of secure interrupts on ARM platforms.  The
      deprecated interrupt list definitions are however retained to support
      legacy builds.
      
      Configuration applied to individual interrupts remain unchanged, so no
      runtime behaviour change expected.
      
      NOTE: Platforms that use the arm/common function
      plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and
      PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and
      PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided
      INTR_PROP_DESC macro.
      
      Change-Id: I24d643b83e3333753a3ba97d4b6fb71e16bb0952
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      b2c363b1
  6. 25 Sep, 2017 2 commits
    • Roberto Vargas's avatar
      mem_protect: Add DRAM2 to the list of mem protected ranges · b09ba056
      Roberto Vargas authored
      
      
      On ARM platforms, the maximum size of the address space is limited
      to 32-bits as defined in arm_def.h. In order to access DRAM2, which
      is defined beyond the 32-bit address space, the maximum address space
      is increased to 36-bits in AArch64. It is possible to increase the
      virtual space for AArch32, but it is more difficult and not supported
      for now.
      
      NOTE - the actual maximum memory address space is platform dependent
      and is checked at run-time by querying the PARange field in the
      ID_AA64MMFR0_EL1 register.
      
      Change-Id: I6cb05c78a63b1fed96db9a9773faca04a5b93d67
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      b09ba056
    • 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
  7. 22 Sep, 2017 1 commit
  8. 06 Sep, 2017 1 commit
    • Soby Mathew's avatar
      CSS: Changes for SDS framework · 18e279eb
      Soby Mathew authored
      
      
      This patch does the required changes to enable CSS platforms
      to build and use the SDS framework. Since SDS is always coupled with
      SCMI protocol, the preexisting SCMI build flag is now renamed to
      `CSS_USE_SCMI_SDS_DRIVER` which will enable both SCMI and SDS on
      CSS platforms. Also some of the workarounds applied for SCMI are
      now removed with SDS in place.
      
      Change-Id: I94e8b93f05e3fe95e475c5501c25bec052588a9c
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      18e279eb
  9. 31 Aug, 2017 1 commit
    • Soby Mathew's avatar
      Juno: Define PLAT_LOG_LEVEL_ASSERT to LOG_LEVEL_INFO · bea363ad
      Soby Mathew authored
      
      
      This patch fixes the PLAT_LOG_LEVEL_ASSERT to 40 which corresponds
      to LOG_LEVEL_INFO. Having this level of log for assertions means that the
      `assert()` will not generate the strings implied in the expression taken
      as parameter. This allows to save some memory when Juno is built for
      LOG_LEVEL = LOG_LEVEL_VERBOSE and DEBUG = 1.
      
      Fixes ARM-software/tf-issues#511
      
      Change-Id: Id84a40f803ab07a5a8f6e587167af96694a07d04
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      bea363ad
  10. 09 Aug, 2017 1 commit
    • Summer Qin's avatar
      Add Trusted OS extra image parsing support for ARM standard platforms · 54661cd2
      Summer Qin authored
      
      
      Trusted OS may have extra images to be loaded. Load them one by one
      and do the parsing. In this patch, ARM TF need to load up to 3 images
      for optee os: header, pager and paged images. Header image is the info
      about optee os and images. Pager image include pager code and data.
      Paged image include the paging parts using virtual memory.
      
      Change-Id: Ia3bcfa6d8a3ed7850deb5729654daca7b00be394
      Signed-off-by: default avatarSummer Qin <summer.qin@arm.com>
      54661cd2
  11. 20 Jul, 2017 1 commit
    • Soby Mathew's avatar
      Resize the BL2 size limit for Juno · 6c401f31
      Soby Mathew authored
      
      
      Recent patches to reduce the memory footprint of BL images have
      resulted in saving several pages of memory. This patch reduces
      the BL2 size limit by 20KB for Juno when ARM_BOARD_OPTIMISE_MEM=1
      so that more free space can be freed up for Trusted OS (BL32). Also
      SCP_BL2/SCP_BL2U size is now restricted to 80K.
      
      Change-Id: I1573d7a34e24d15e4abce8a14da40dbb5dc81e37
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      6c401f31
  12. 28 Jun, 2017 1 commit
    • Soby Mathew's avatar
      ARM plat changes to enable CryptoCell integration · e60f2af9
      Soby Mathew authored
      
      
      This patch makes the necessary changes to enable ARM platform to
      successfully integrate CryptoCell during Trusted Board Boot. The
      changes are as follows:
      
      * A new build option `ARM_CRYPTOCELL_INTEG` is introduced to select
        the CryptoCell crypto driver for Trusted Board boot.
      
      * The TrustZone filter settings for Non Secure DRAM is modified
        to allow CryptoCell to read this memory. This is required to
        authenticate BL33 which is loaded into the Non Secure DDR.
      
      * The CSS platforms are modified to use coherent stacks in BL1 and BL2
        when CryptoCell crypto is selected. This is because CryptoCell makes
        use of DMA to transfer data and the CryptoCell SBROM library allocates
        buffers on the stack during signature/hash verification.
      
      Change-Id: I1e6f6dcd1899784f1edeabfa2a9f279bbfb90e31
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      e60f2af9
  13. 05 Jun, 2017 1 commit
  14. 23 May, 2017 2 commits
    • Masahiro Yamada's avatar
      FVP,Juno: switch FVP and Juno to use generic TBBR OID header · 232c6b34
      Masahiro Yamada authored
      
      
      The header tbbr_oid.h contains OIDs obtained by ARM Ltd.
      so there is no good reason to use platform_oid.h
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      232c6b34
    • Masahiro Yamada's avatar
      cert: move platform_oid.h to include/tools_share for all platforms · bb41eb7a
      Masahiro Yamada authored
      
      
      Platforms aligned with TBBR are supposed to use their own OIDs, but
      defining the same macros with different OIDs does not provide any
      value (at least technically).
      
      For easier use of TBBR, this commit allows platforms to reuse the OIDs
      obtained by ARM Ltd.  This will be useful for non-ARM vendors that
      do not need their own extension fields in their certificate files.
      
      The OIDs of ARM Ltd. have been moved to include/tools_share/tbbr_oid.h
      
      Platforms can include <tbbr_oid.h> instead of <platform_oid.h> by
      defining USE_TBBR_DEFS as 1.  USE_TBBR_DEFS is 0 by default to keep the
      backward compatibility.
      
      For clarification, I inserted a blank line between headers from the
      include/ directory (#include <...>) and ones from a local directory
      (#include "..." ).
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      bb41eb7a
  15. 03 May, 2017 1 commit
  16. 20 Apr, 2017 1 commit
  17. 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
  18. 14 Dec, 2016 1 commit
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 15 Feb, 2016 1 commit
    • 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
  26. 11 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Re-factor definition of some macros on ARM platforms · ecf70f7b
      Vikram Kanigiri authored
      This patch moves the definition of some macros used only on
      ARM platforms from common headers to platform specific headers.
      It also forces all ARM standard platforms to have distinct
      definitions (even if they are usually the same).
       1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been
           moved from `css_def.h` to `platform_def.h`.
       2. `MHU_BASE` used in CSS platforms is moved from common css_def.h
          to platform specific header `platform_def.h` on Juno and
          renamed as `PLAT_ARM_MHU_BASE`.
       3. To cater for different sizes of BL images, new macros like
          `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All
          ARM platforms need to define them for each image.
      
      Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
      ecf70f7b
  27. 09 Dec, 2015 1 commit
    • 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
  28. 30 Oct, 2015 1 commit
    • Soby Mathew's avatar
      CSS: Implement topology support for System power domain · 5f3a6030
      Soby Mathew authored
      This patch implements the necessary topology changes for supporting
      system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and
      PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform
      specific. In addition, the `arm_power_domain_tree_desc[]` and
      `arm_pm_idle_states[]` are modified to support the system power domain
      at level 2. With this patch, even though the power management operations
      involving the system power domain will not return any error, the platform
      layer will silently ignore any operations to the power domain. The actual
      power management support for the system power domain will be added later.
      
      Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
      5f3a6030
  29. 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
  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