1. 21 Apr, 2016 6 commits
  2. 14 Apr, 2016 2 commits
    • 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
    • Sandrine Bailleux's avatar
      Fix build error with optimizations disabled (-O0) · 10c252c1
      Sandrine Bailleux authored
      If Trusted Firmware is built with optimizations disabled (-O0), the
      linker throws the following error:
      
          undefined reference to 'xxx'
      
      Where 'xxx' is a raw inline function defined in a header file. The
      reason is that, with optimizations disabled, GCC may decide to skip
      the inlining. If that is the case, an external definition to the
      compilation unit must be provided. Because no external definition
      is present, the linker throws the error.
      
      This patch fixes the problem by declaring the following inline
      functions static, so the internal definition is used:
       - cm_set_next_context()
       - bakery_lock_init()
      
      Note that building the TF with optimizations disabled when Trusted
      Board Boot is enabled is currently unsupported, as this makes the BL2
      image too big to fit in memory without any adjustment of its base
      address. Similarly, disabling optimizations for debug builds on FVP
      is unsupported at the moment.
      
      Change-Id: I284a9f84cc8df96a0c1a52dfe05c9e8544c0cefe
      10c252c1
  3. 13 Apr, 2016 1 commit
    • Soby Mathew's avatar
      Refactor the xlat_tables library code · 3ca9928d
      Soby Mathew authored
      The AArch32 long descriptor format and the AArch64 descriptor format
      correspond to each other which allows possible sharing of xlat_tables
      library code between AArch64 and AArch32. This patch refactors the
      xlat_tables library code to seperate the common functionality from
      architecture specific code. Prior to this patch, all of the xlat_tables
      library code were in `lib/aarch64/xlat_tables.c` file. The refactored code
      is now in `lib/xlat_tables/` directory. The AArch64 specific programming
      for xlat_tables is in `lib/xlat_tables/aarch64/xlat_tables.c` and the rest
      of the code common to AArch64 and AArch32 is in
      `lib/xlat_tables/xlat_tables_common.c`. Also the data types used in
      xlat_tables library APIs are reworked to make it compatible between AArch64
      and AArch32.
      
      The `lib/aarch64/xlat_tables.c` file now includes the new xlat_tables
      library files to retain compatibility for existing platform ports.
      The macros related to xlat_tables library are also moved from
      `include/lib/aarch64/arch.h` to the header `include/lib/xlat_tables.h`.
      
      NOTE: THE `lib/aarch64/xlat_tables.c` FILE IS DEPRECATED AND PLATFORM PORTS
      ARE EXPECTED TO INCLUDE THE NEW XLAT_TABLES LIBRARY FILES IN THEIR MAKEFILES.
      
      Change-Id: I3d17217d24aaf3a05a4685d642a31d4d56255a0f
      3ca9928d
  4. 12 Apr, 2016 1 commit
    • Yatharth Kochar's avatar
      Use unsigned long long instead of uintptr_t in TZC400/DMC500 drivers · 9fbdb802
      Yatharth Kochar authored
      Currently the `tzc400_configure_region` and `tzc_dmc500_configure_region`
      functions uses uintptr_t as the data type for `region_top` and `region_base`
      variables, which will be converted to 32/64 bits for AArch32/AArch64
      respectively. But the expectation is to keep these addresses at least 64 bit.
      
      This patch modifies the data types to make it at least 64 bit by using
      unsigned long long instead of uintptr_t for the `region_top` and
      `region_base` variables. It also modifies the associated macros
      `_tzc##fn_name##_write_region_xxx` accordingly.
      
      Change-Id: I4e3c6a8a39ad04205cf0f3bda336c3970b15a28b
      9fbdb802
  5. 08 Apr, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Remove BL32_BASE when building without SPD for FVP · 81d139d5
      Antonio Nino Diaz authored
      Previously, when building TF without SPD support, BL2 tried to load a
      BL32 image from the FIP and fails to find one, which resulted on
      warning messages on the console. Even if there is a BL32 image in the
      FIP it shouldn't be loaded because there is no way to transfer
      control to the Secure Payload without SPD support.
      
      The Makefile has been modified to pass a define of the form
      SPD_${SPD} to the source code the same way it's done for PLAT. The
      define SPD_none is then used to undefine BL32_BASE when BL32 is not
      used to prevent BL2 from trying to load a BL32 image and failing,
      thus removing the warning messages mentioned above.
      
      Fixes ARM-software/tf-issues#287
      
      Change-Id: Ifeb6f1c26935efb76afd353fea88e87ba09e9658
      81d139d5
  6. 07 Apr, 2016 1 commit
    • Soby Mathew's avatar
      Enable SCR_EL3.SIF bit · 99e58f9e
      Soby Mathew authored
      This patch enables the SCR_EL3.SIF (Secure Instruction Fetch) bit in BL1 and
      BL31 common architectural setup code. When in secure state, this disables
      instruction fetches from Non-secure memory.
      
      NOTE: THIS COULD BREAK PLATFORMS THAT HAVE SECURE WORLD CODE EXECUTING FROM
      NON-SECURE MEMORY, BUT THIS IS CONSIDERED UNLIKELY AND IS A SERIOUS SECURITY
      RISK.
      
      Fixes ARM-Software/tf-issues#372
      
      Change-Id: I684e84b8d523c3b246e9a5fabfa085b6405df319
      99e58f9e
  7. 01 Apr, 2016 2 commits
  8. 31 Mar, 2016 7 commits
    • Vikram Kanigiri's avatar
      Add support to program a DMC-500 TZC on ARM platforms · 618f0fee
      Vikram Kanigiri authored
      This patch adds support to program TrustZone protection on ARM platforms that
      implement a DMC-500. arm_dmc_500.c has been added which implements the
      arm_dmc_tzc_setup() function. This function relies on constants related to TZC
      programming that are exported by each platform to program TrustZone protection
      using the DMC-500 TrustZone controller driver. This function should be called
      from plat_arm_security_setup() which is implemented by each platform.
      
      Change-Id: I5400bdee9e4b29155fd11296a40693d512312f29
      618f0fee
    • Vikram Kanigiri's avatar
      Add ARM CoreLink DMC-500 driver to program TrustZone protection · f568604b
      Vikram Kanigiri authored
      The ARM CoreLink DMC-500 Dynamic Memory Controller provides the
      programmable address region control of a TrustZone Address Space
      Controller. The access permissions can be defined for eight
      separate address regions plus a background or default region.
      This patch adds a DMC-500 driver to define address regions and
      program their access permissions as per ARM 100131_0000_02_en
      (r0p0) document.
      
      Change-Id: I9d33120f9480d742bcf7937e4b876f9d40c727e6
      f568604b
    • Soby Mathew's avatar
      Migrate ARM standard platforms to the refactored TZC driver · 57f78201
      Soby Mathew authored
      This patch migrates ARM Standard platforms to the refactored TZC driver.
      
      Change-Id: I2a2f60b645f73e14d8f416740c4551cec87cb1fb
      57f78201
    • Vikram Kanigiri's avatar
      Refactor the ARM CoreLink TZC-400 driver · 6b477063
      Vikram Kanigiri authored
      TrustZone protection can be programmed by both memory and TrustZone
      address space controllers like DMC-500 and TZC-400. These peripherals
      share a similar programmer's view.
      
      Furthermore, it is possible to have multiple instances of each type of
      peripheral in a system resulting in multiple programmer's views.
      For example, on the TZC-400 each of the 4 filter units can be enabled
      or disabled for each region. There is a single set of registers to
      program the region attributes. On the DMC-500, each filter unit has its
      own programmer's view resulting in multiple sets of registers to program
      the region attributes. The layout of the registers is almost the same
      across all these variations.
      
      Hence the existing driver in `tzc400\tzc400.c` is refactored into the
      new driver in `tzc\tzc400.c`. The previous driver file is still maintained
      for compatibility and it is now deprecated.
      
      Change-Id: Ieabd0528e244582875bc7e65029a00517671216d
      6b477063
    • Antonio Nino Diaz's avatar
      Remove xlat_helpers.c · f33fbb2f
      Antonio Nino Diaz authored
      lib/aarch64/xlat_helpers.c defines helper functions to build
      translation descriptors, but no common code or upstream platform
      port uses them. As the rest of the xlat_tables code evolves, there
      may be conflicts with these helpers, therefore this code should be
      removed.
      
      Change-Id: I9f5be99720f929264818af33db8dada785368711
      f33fbb2f
    • Juan Castillo's avatar
      TBB: add non-volatile counter support · 48279d52
      Juan Castillo authored
      This patch adds support for non-volatile counter authentication to
      the Authentication Module. This method consists of matching the
      counter values provided in the certificates with the ones stored
      in the platform. If the value from the certificate is lower than
      the platform, the boot process is aborted. This mechanism protects
      the system against rollback.
      
      The TBBR CoT has been updated to include this method as part of the
      authentication process. Two counters are used: one for the trusted
      world images and another for the non trusted world images.
      
      ** NEW PLATFORM APIs (mandatory when TBB is enabled) **
      
      int plat_get_nv_ctr(void *cookie, unsigned int *nv_ctr);
      
          This API returns the non-volatile counter value stored
          in the platform. The cookie in the first argument may be
          used to select the counter in case the platform provides
          more than one (i.e. TBSA compliant platforms must provide
          trusted and non-trusted counters). This cookie is specified
          in the CoT.
      
      int plat_set_nv_ctr(void *cookie, unsigned int nv_ctr);
      
          This API sets a new counter value. The cookie may be
          used to select the counter to be updated.
      
      An implementation of these new APIs for ARM platforms is also
      provided. The values are obtained from the Trusted Non-Volatile
      Counters peripheral. The cookie is used to pass the extension OID.
      This OID may be interpreted by the platform to know which counter
      must return. On Juno, The trusted and non-trusted counter values
      have been tied to 31 and 223, respectively, and cannot be modified.
      
      ** IMPORTANT **
      
      THIS PATCH BREAKS THE BUILD WHEN TRUSTED_BOARD_BOOT IS ENABLED. THE
      NEW PLATFORM APIs INTRODUCED IN THIS PATCH MUST BE IMPLEMENTED IN
      ORDER TO SUCCESSFULLY BUILD TF.
      
      Change-Id: Ic943b76b25f2a37f490eaaab6d87b4a8b3cbc89a
      48279d52
    • David Wang's avatar
      Add support to load BL31 in DRAM · 4518dd9a
      David Wang authored
      This patch adds an option to the ARM common platforms to load BL31 in the
      TZC secured DRAM instead of the default secure SRAM.
      
      To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options.
      If TSP is present, then setting this option also sets the TSP location
      to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag.
      
      To use this feature, BL2 platform code must map in the DRAM used by
      BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose.
      Currently, only the FVP BL2 platform code maps in this DRAM.
      
      Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67
      4518dd9a
  9. 30 Mar, 2016 3 commits
    • Gerald Lejeune's avatar
      Add ISR_EL1 to crash report · 6b836cf9
      Gerald Lejeune authored
      
      
      Bring ISR bits definition as a mnemonic for troublershooters as well.
      Signed-off-by: default avatarGerald Lejeune <gerald.lejeune@st.com>
      6b836cf9
    • Gerald Lejeune's avatar
      Remove DAIF bits handling macros · 4ca57535
      Gerald Lejeune authored
      
      
      These macros are unused and redundant with other CPU system registers
      functions.
      
      Moreover enable_serror() function implementation may not reach its purpose
      because it does not handle the value of SCR_EL3.EA.
      Signed-off-by: default avatarGerald Lejeune <gerald.lejeune@st.com>
      4ca57535
    • Gerald Lejeune's avatar
      Enable asynchronous abort exceptions during boot · adb4fcfb
      Gerald Lejeune authored
      
      
      Asynchronous abort exceptions generated by the platform during cold boot are
      not taken in EL3 unless SCR_EL3.EA is set.
      
      Therefore EA bit is set along with RES1 bits in early BL1 and BL31 architecture
      initialisation. Further write accesses to SCR_EL3 preserve these bits during
      cold boot.
      
      A build flag controls SCR_EL3.EA value to keep asynchronous abort exceptions
      being trapped by EL3 after cold boot or not.
      
      For further reference SError Interrupts are also known as asynchronous external
      aborts.
      
      On Cortex-A53 revisions below r0p2, asynchronous abort exceptions are taken in
      EL3 whatever the SCR_EL3.EA value is.
      
      Fixes arm-software/tf-issues#368
      Signed-off-by: default avatarGerald Lejeune <gerald.lejeune@st.com>
      adb4fcfb
  10. 22 Mar, 2016 1 commit
    • Soby Mathew's avatar
      Make cpu operations warning a VERBOSE print · 1319e7b1
      Soby Mathew authored
      The assembler helper function `print_revision_warning` is used when a
      CPU specific operation is enabled in the debug build (e.g. an errata
      workaround) but doesn't apply to the executing CPU's revision/part number.
      However, in some cases the system integrator may want a single binary to
      support multiple platforms with different IP versions, only some of which
      contain a specific erratum.  In this case, the warning can be emitted very
      frequently when CPUs are being powered on/off.
      
      This patch modifies this warning print behaviour so that it is emitted only
      when LOG_LEVEL >= LOG_LEVEL_VERBOSE. The `debug.h` header file now contains
      guard macros so that it can be included in assembly code.
      
      Change-Id: Ic6e7a07f128dcdb8498a5bfdae920a8feeea1345
      1319e7b1
  11. 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
  12. 07 Mar, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Initialize secondary CPUs during cold boot · 4e85e4fd
      Antonio Nino Diaz authored
      The previous reset code in BL1 performed the following steps in
      order:
      
      1. Warm/Cold boot detection.
         If it's a warm boot, jump to warm boot entrypoint.
      
      2. Primary/Secondary CPU detection.
         If it's a secondary CPU, jump to plat_secondary_cold_boot_setup(),
         which doesn't return.
      
      3. CPU initialisations (cache, TLB...).
      
      4. Memory and C runtime initialization.
      
      For a secondary CPU, steps 3 and 4 are never reached. This shouldn't
      be a problem in most cases, since current implementations of
      plat_secondary_cold_boot_setup() either panic or power down the
      secondary CPUs.
      
      The main concern is the lack of secondary CPU initialization when
      bare metal EL3 payloads are used in case they don't take care of this
      initialisation themselves.
      
      This patch moves the detection of primary/secondary CPU after step 3
      so that the CPU initialisations are performed per-CPU, while the
      memory and the C runtime initialisation are only performed on the
      primary CPU. The diagrams used in the ARM Trusted Firmware Reset
      Design documentation file have been updated to reflect the new boot
      flow.
      
      Platforms ports might be affected by this patch depending on the
      behaviour of plat_secondary_cold_boot_setup(), as the state of the
      platform when entering this function will be different.
      
      Fixes ARM-software/tf-issues#342
      
      Change-Id: Icbf4a0ee2a3e5b856030064472f9fa6696f2eb9e
      4e85e4fd
  13. 03 Mar, 2016 1 commit
    • Sandrine Bailleux's avatar
      Extend memory attributes to map non-cacheable memory · 5f654975
      Sandrine Bailleux authored
      At the moment, the memory translation library allows to create memory
      mappings of 2 types:
      
       - Device nGnRE memory (named MT_DEVICE in the library);
      
       - Normal, Inner Write-back non-transient, Outer Write-back
         non-transient memory (named MT_MEMORY in the library).
      
      As a consequence, the library code treats the memory type field as a
      boolean: everything that is not device memory is normal memory and
      vice-versa.
      
      In reality, the ARMv8 architecture allows up to 8 types of memory to
      be used at a single time for a given exception level. This patch
      reworks the memory attributes such that the memory type is now defined
      as an integer ranging from 0 to 7 instead of a boolean. This makes it
      possible to extend the list of memory types supported by the memory
      translation library.
      
      The priority system dictating memory attributes for overlapping
      memory regions has been extended to cope with these changes but the
      algorithm at its core has been preserved. When a memory region is
      re-mapped with different memory attributes, the memory translation
      library examines the former attributes and updates them only if
      the new attributes create a more restrictive mapping. This behaviour
      is unchanged, only the manipulation of the value has been modified
      to cope with the new format.
      
      This patch also introduces a new type of memory mapping in the memory
      translation library: MT_NON_CACHEABLE, meaning Normal, Inner
      Non-cacheable, Outer Non-cacheable memory. This can be useful to map
      a non-cacheable memory region, such as a DMA buffer for example.
      
      The rules around the Execute-Never (XN) bit in a translation table
      for an MT_NON_CACHEABLE memory mapping have been aligned on the rules
      used for MT_MEMORY mappings:
       - If the memory is read-only then it is also executable (XN = 0);
       - If the memory is read-write then it is not executable (XN = 1).
      
      The shareability field for MT_NON_CACHEABLE mappings is always set as
      'Outer-Shareable'. Note that this is not strictly needed since
      shareability is only relevant if the memory is a Normal Cacheable
      memory type, but this is to align with the existing device memory
      mappings setup. All Device and Normal Non-cacheable memory regions
      are always treated as Outer Shareable, regardless of the translation
      table shareability attributes.
      
      This patch also removes the 'ATTR_SO' and 'ATTR_SO_INDEX' #defines.
      They were introduced to map memory as Device nGnRnE (formerly called
      "Strongly-Ordered" memory in the ARMv7 architecture) but were not
      used anywhere in the code base. Removing them avoids any confusion
      about the memory types supported by the library.
      
      Upstream platforms do not currently use the MT_NON_CACHEABLE memory
      type.
      
      NOTE: THIS CHANGE IS SOURCE COMPATIBLE BUT PLATFORMS THAT RELY ON THE
      BINARY VALUES OF `mmap_attr_t` or the `attr` argument of
      `mmap_add_region()` MAY BE BROKEN.
      
      Change-Id: I717d6ed79b4c845a04e34132432f98b93d661d79
      5f654975
  14. 22 Feb, 2016 2 commits
    • Yatharth Kochar's avatar
      Fix the inconsistencies in bl1_tbbr_image_descs[] · 843ddee4
      Yatharth Kochar authored
      This patch fixes inconsistencies in bl1_tbbr_image_descs[]
      and miscellaneous fixes in Firmware Update code.
      
      Following are the changes:
      * As part of the original FWU changes, a `copied_size`
        field was added to `image_info_t`. This was a subtle binary
        compatibility break because it changed the size of the
        `bl31_params_t` struct, which could cause problems if
        somebody used different versions of BL2 or BL31, one with
        the old `image_info_t` and one with the new version.
        This patch put the `copied_size` within the `image_desc_t`.
      * EXECUTABLE flag is now stored in `ep_info.h.attr` in place
        of `image_info.h.attr`, associating it to an entrypoint.
      * The `image_info.image_base` is only relevant for secure
        images that are copied from non-secure memory into secure
        memory. This patch removes initializing `image_base` for
        non secure images in the bl1_tbbr_image_descs[].
      * A new macro `SET_STATIC_PARAM_HEAD` is added for populating
        bl1_tbbr_image_descs[].ep_info/image_info.h members statically.
        The version, image_type and image attributes are now
        populated using this new macro.
      * Added PLAT_ARM_NVM_BASE and PLAT_ARM_NVM_SIZE to avoid direct
        usage of V2M_FLASH0_XXX in plat/arm/common/arm_bl1_fwu.c.
      * Refactoring of code/macros related to SECURE and EXECUTABLE flags.
      
      NOTE: PLATFORM PORTS THAT RELY ON THE SIZE OF `image_info_t`
            OR USE the "EXECUTABLE" BIT WITHIN `image_info_t.h.attr`
            OR USE THEIR OWN `image_desc_t` ARRAY IN BL1, MAY BE
            BROKEN BY THIS CHANGE. THIS IS CONSIDERED UNLIKELY.
      
      Change-Id: Id4e5989af7bf0ed263d19d3751939da1169b561d
      843ddee4
    • 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
  15. 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
  16. 18 Feb, 2016 1 commit
    • Juan Castillo's avatar
      ARM platforms: rationalise memory attributes of shared memory · 74eb26e4
      Juan Castillo authored
      The shared memory region on ARM platforms contains the mailboxes and,
      on Juno, the payload area for communication with the SCP. This shared
      memory may be configured as normal memory or device memory at build
      time by setting the platform flag 'PLAT_ARM_SHARED_RAM_CACHED' (on
      Juno, the value of this flag is defined by 'MHU_PAYLOAD_CACHED').
      When set as normal memory, the platform port performs the corresponding
      cache maintenance operations. From a functional point of view, this is
      the equivalent of setting the shared memory as device memory, so there
      is no need to maintain both options.
      
      This patch removes the option to specify the shared memory as normal
      memory on ARM platforms. Shared memory is always treated as device
      memory. Cache maintenance operations are no longer needed and have
      been replaced by data memory barriers to guarantee that payload and
      MHU are accessed in the right order.
      
      Change-Id: I7f958621d6a536dd4f0fa8768385eedc4295e79f
      74eb26e4
  17. 16 Feb, 2016 2 commits
    • 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
    • Vikram Kanigiri's avatar
      Make SCP_BL2(U) image loading configurable on CSS platforms · 7fb9a32d
      Vikram Kanigiri authored
      Current code mandates loading of SCP_BL2/SCP_BL2U images for all
      CSS platforms. On future ARM CSS platforms, the Application
      Processor (AP) might not need to load these images. So, these
      items can be removed from the FIP on those platforms.
      
      BL2 tries to load  SCP_BL2/SCP_BL2U images if their base
      addresses are defined causing boot error if the images are not
      found in FIP.
      
      This change adds a make flag `CSS_LOAD_SCP_IMAGES` which if set
      to `1` does:
      1. Adds SCP_BL2, SCP_BL2U images to FIP.
      2. Defines the base addresses of these images so that AP loads
         them.
      
      And vice-versa if it is set to `0`. The default value is set to
      `1`.
      
      Change-Id: I5abfe22d5dc1e9d80d7809acefc87b42a462204a
      7fb9a32d
  18. 15 Feb, 2016 2 commits
    • 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
    • Vikram Kanigiri's avatar
      Add API to return memory map on ARM platforms · 65cb1c4c
      Vikram Kanigiri authored
      Functions to configure the MMU in S-EL1 and EL3 on ARM platforms
      expect each platform to export its memory map in the `plat_arm_mmap`
      data structure. This approach does not scale well in case the memory
      map cannot be determined until runtime. To cater for this possibility,
      this patch introduces the plat_arm_get_mmap() API. It returns a
      reference to the `plat_arm_mmap` by default but can be overridden
      by a platform if required.
      
      Change-Id: Idae6ad8fdf40cdddcd8b992abc188455fa047c74
      65cb1c4c
  19. 12 Feb, 2016 2 commits
  20. 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