1. 29 Apr, 2021 1 commit
  2. 28 Apr, 2021 1 commit
  3. 19 Feb, 2020 1 commit
    • Suyash Pathak's avatar
      plat/arm: allow boards to specify second DRAM Base address · 86f297a3
      Suyash Pathak authored
      
      
      The base address for second DRAM varies across different platforms.
      So allow platforms to define second DRAM by moving Juno/SGM-775 specific
      definition of second DRAM base address to Juno/SGM-775 board definition
      respectively, SGI/RD specific definition of DRAM 2 base address to SGI
      board definition.
      
      Change-Id: I0ecd3a2bd600b6c7019c7f06f8c452952bd07cae
      Signed-off-by: default avatarSuyash Pathak <suyash.pathak@arm.com>
      86f297a3
  4. 01 Aug, 2019 1 commit
    • Julius Werner's avatar
      Replace __ASSEMBLY__ with compiler-builtin __ASSEMBLER__ · d5dfdeb6
      Julius Werner authored
      
      
      NOTE: __ASSEMBLY__ macro is now deprecated in favor of __ASSEMBLER__.
      
      All common C compilers predefine a macro called __ASSEMBLER__ when
      preprocessing a .S file. There is no reason for TF-A to define it's own
      __ASSEMBLY__ macro for this purpose instead. To unify code with the
      export headers (which use __ASSEMBLER__ to avoid one extra dependency),
      let's deprecate __ASSEMBLY__ and switch the code base over to the
      predefined standard.
      
      Change-Id: Id7d0ec8cf330195da80499c68562b65cb5ab7417
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      d5dfdeb6
  5. 15 May, 2019 1 commit
    • Sami Mujawar's avatar
      Add option for defining platform DRAM2 base · 6bb6015f
      Sami Mujawar authored
      
      
      The default DRAM2 base address for Arm platforms
      is 0x880000000. However, on some platforms the
      firmware may want to move the start address to
      a different value.
      
      To support this introduce PLAT_ARM_DRAM2_BASE that
      defaults to 0x880000000; but can be overridden by
      a platform (e.g. in platform_def.h).
      
      Change-Id: I0d81195e06070bc98f376444b48ada2db1666e28
      Signed-off-by: default avatarSami Mujawar <sami.mujawar@arm.com>
      6bb6015f
  6. 18 Feb, 2019 1 commit
  7. 25 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Sanitise includes · bd9344f6
      Antonio Nino Diaz authored
      
      
      Use full include paths like it is done for common includes.
      
      This cleanup was started in commit d40e0e08283a ("Sanitise includes
      across codebase"), but it only cleaned common files and drivers. This
      patch does the same to Arm platforms.
      
      Change-Id: If982e6450bbe84dceb56d464e282bcf5d6d9ab9b
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      bd9344f6
  8. 04 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      Sanitise includes across codebase · 09d40e0e
      Antonio Nino Diaz authored
      Enforce full include path for includes. Deprecate old paths.
      
      The following folders inside include/lib have been left unchanged:
      
      - include/lib/cpus/${ARCH}
      - include/lib/el3_runtime/${ARCH}
      
      The reason for this change is that having a global namespace for
      includes isn't a good idea. It defeats one of the advantages of having
      folders and it introduces problems that are sometimes subtle (because
      you may not know the header you are actually including if there are two
      of them).
      
      For example, this patch had to be created because two headers were
      called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform
      to avoid collision."). More recently, this patch has had similar
      problems: 46f9b2c3 ("drivers: add tzc380 support").
      
      This problem was introduced in commit 4ecca339
      
       ("Move include and
      source files to logical locations"). At that time, there weren't too
      many headers so it wasn't a real issue. However, time has shown that
      this creates problems.
      
      Platforms that want to preserve the way they include headers may add the
      removed paths to PLAT_INCLUDES, but this is discouraged.
      
      Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      09d40e0e
  9. 08 Nov, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Standardise header guards across codebase · c3cf06f1
      Antonio Nino Diaz authored
      
      
      All identifiers, regardless of use, that start with two underscores are
      reserved. This means they can't be used in header guards.
      
      The style that this project is now to use the full name of the file in
      capital letters followed by 'H'. For example, for a file called
      "uart_example.h", the header guard is UART_EXAMPLE_H.
      
      The exceptions are files that are imported from other projects:
      
      - CryptoCell driver
      - dt-bindings folders
      - zlib headers
      
      Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c3cf06f1
  10. 01 Nov, 2018 1 commit
  11. 26 Oct, 2018 1 commit
    • Antonio Nino Diaz's avatar
      xlat: Fix compatibility between v1 and v2 · 03987d01
      Antonio Nino Diaz authored
      
      
      There are several platforms using arm_setup_page_tables(), which is
      supposed to be Arm platform only. This creates several dependency
      problems between platforms.
      
      This patch adds the definition XLAT_TABLES_LIB_V2 to the xlat tables lib
      v2 makefile. This way it is possible to detect from C code which version
      is being used and include the correct header.
      
      The file arm_xlat_tables.h has been renamed to xlat_tables_compat.h and
      moved to a common folder. This way, when in doubt, this header can be
      used to guarantee compatibility, as it includes the correct header based
      on XLAT_TABLES_LIB_V2.
      
      This patch also removes the usage of ARM_XLAT_TABLES_V1 from QEMU (so
      that is now locked in xlat lib v2) and ZynqMP (where it was added as a
      workaround).
      
      Change-Id: Ie1e22a23b44c549603d1402a237a70d0120d3e04
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      03987d01
  12. 11 Oct, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Remove file arm_board_def.h · 0f58d4f2
      Antonio Nino Diaz authored
      
      
      This file is shared between FVP and all CSS platforms. While it may be
      true that some definitions can be common, it doesn't make sense
      conceptually. For example, the stack size depends on the platform and so
      does the SRAM size.
      
      After removing them, there are not enough common definitions to justify
      having this header, so the other definitions have been moved to the
      platform_def.h of FVP, board_css_def.h and arm_def.h.
      
      Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      0f58d4f2
  13. 10 Oct, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Move norflash driver to drivers/ folder · aa7877c4
      Antonio Nino Diaz authored
      
      
      This way it can be reused by other platforms if needed.
      
      Note that this driver is designed to work with the Versatile Express NOR
      flash of Juno and FVP. In said platforms, the memory is organized as an
      interleaved memory of two chips with a 16 bit word.
      
      Any platform that wishes to reuse it with a different configuration will
      need to modify the driver so that it is more generic.
      
      Change-Id: Ic721758425864e0cf42b7b9b04bf0d9513b6022e
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      aa7877c4
  14. 09 Oct, 2018 1 commit
  15. 02 Oct, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Remove option ARM_BOARD_OPTIMISE_MEM · c0740e4f
      Antonio Nino Diaz authored
      
      
      This option makes it hard to optimize the memory definitions of all Arm
      platforms because any change in the common defines must work in all of
      them. The best thing to do is to remove it and move the definition to
      each platform's header.
      
      FVP, SGI and SGM were using the definitions in board_arm_def.h. The
      definitions have been copied to each platform's platform_def.h. Juno
      was already using the ones in platform_def.h, so there have been no
      changes.
      
      Change-Id: I9aecd11bbc72a3d0d7aad1ef9934d8df21dcfaf2
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c0740e4f
  16. 07 Sep, 2018 2 commits
    • Sathees Balya's avatar
      juno: Revert FWU update detect mechanism · 4da6f6cd
      Sathees Balya authored
      The patch 7b56928a
      
       unified the FWU mechanism on FVP and Juno
      platforms due to issues with MCC firmware not preserving the
      NVFLAGS. With MCCv150 firmware, this issue is resolved. Also
      writing to the NOR flash while executing from the same flash
      in Bypass mode had some stability issues. Hence, since the
      MCC firmware issue is resolved, this patch reverts to the
      NVFLAGS mechanism to detect FWU. Also, with the introduction
      of SDS (Shared Data Structure) by the SCP, the reset syndrome
      needs to queried from the appropriate SDS field.
      
      Change-Id: If9c08f1afaaa4fcf197f3186887068103855f554
      Signed-off-by: default avatarSathees Balya <sathees.balya@arm.com>
      Signed-off-by: default avatarSoby Mathew <Soby.Mathew@arm.com>
      4da6f6cd
    • John Tsichritzis's avatar
      Readjust BL2 size after sharing Mbed TLS heap · 2dac2c0b
      John Tsichritzis authored
      
      
      After introducing the Mbed TLS shared heap optimisation, reducing BL2
      size by 3 pages didn't leave enough space for growth. We give 1 page
      back to maximum BL2 size.
      
      Change-Id: I4f05432f00b923693160f69a4e4ec310a37a2b16
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      2dac2c0b
  17. 04 Sep, 2018 1 commit
  18. 06 Aug, 2018 1 commit
  19. 20 Jul, 2018 1 commit
  20. 21 Jun, 2018 1 commit
  21. 19 Jun, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Migrate AArch64 port to the multi console driver · 88a0523e
      Antonio Nino Diaz authored
      
      
      The old API is deprecated and will eventually be removed.
      
      Arm platforms now use the multi console driver for boot and runtime
      consoles. However, the crash console uses the direct console API because
      it doesn't need any memory access to work. This makes it more robust
      during crashes.
      
      The AArch32 port of the Trusted Firmware doesn't support this new API
      yet, so it is only enabled in AArch64 builds. Because of this, the
      common code must maintain compatibility with both systems. SP_MIN
      doesn't have to be updated because it's only used in AArch32 builds.
      The TSP is only used in AArch64, so it only needs to support the new
      API without keeping support for the old one.
      
      Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this
      causes the UARTs to reset (except for the one used by the TSP). This
      means that they must be unregistered when suspending and re-registered
      when resuming. This wasn't a problem with the old driver because it just
      restarted the UART, and there were no problems associated with
      registering and unregistering consoles.
      
      The size reserved for BL2 has been increased.
      
      Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      88a0523e
  22. 18 Jun, 2018 1 commit
  23. 07 Jun, 2018 1 commit
    • Soby Mathew's avatar
      ARM platforms: Move BL31 below BL2 to enable BL2 overlay · c099cd39
      Soby Mathew authored
      
      
      The patch changes the layout of BL images in memory to enable
      more efficient use of available space. Previously BL31 was loaded
      with the expectation that BL2 memory would be reclaimed by BL32
      loaded in SRAM. But with increasing memory requirements in the
      firmware, we can no longer fit BL32 in SRAM anymore which means the
      BL2 memory is not reclaimed by any runtime image. Positioning BL2
      below BL1-RW and above BL31 means that the BL31 NOBITS can be
      overlaid on BL2 and BL1-RW.
      
      This patch also propogates the same memory layout to BL32 for AArch32
      mode. The reset addresses for the following configurations are also
      changed :
         * When RESET_TO_SP_MIN=1 for BL32 in AArch32 mode
         * When BL2_AT_EL3=1 for BL2
      
      The restriction on BL31 to be only in DRAM when SPM is enabled
      is now removed with this change. The update to the firmware design
      guide for the BL memory layout is done in the following patch.
      
      Change-Id: Icca438e257abe3e4f5a8215f945b9c3f9fbf29c9
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      c099cd39
  24. 24 May, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: SPM: Force BL31 to DRAM when SPM is used · e829a379
      Antonio Nino Diaz authored
      
      
      BL31 is running out of space, and the use-case of SPM doesn't require it
      to be in SRAM. To prevent BL31 from running out of space in the future,
      move BL31 to DRAM if SPM is enabled.
      
      Secure Partition Manager design document updated to reflect the changes.
      
      Increased the size of the stack of BL31 for builds with SPM.
      
      The translation tables used by SPM in Arm platforms have been moved back
      to the 'xlat_tables' region instead of 'arm_el3_tzc_dram'. Everything is
      in DRAM now, so it doesn't make sense to treat them in a different way.
      
      Change-Id: Ia6136c8e108b8da9edd90e9d72763dada5e5e5dc
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      e829a379
  25. 21 May, 2018 1 commit
    • Soby Mathew's avatar
      FVP: Add dummy configs for BL31, BL32 and BL33 · 1d71ba14
      Soby Mathew authored
      
      
      This patch adds soc_fw_config, tos_fw_config and nt_fw_config to the FVP.
      The config files are placeholders and do not have any useful bindings
      defined. The tos_fw_config is packaged in FIP and loaded by BL2 only
      if SPD=tspd. The load address of these configs are specified in tb_fw_config
      via new bindings defined for these configs. Currently, in FVP, the
      soc_fw_config and tos_fw_config is loaded in the page between BL2_BASE
      and ARM_SHARED_RAM. This memory was typically used for BL32 when
      ARM_TSP_RAM_LOCATION=tsram but since we cannot fit BL32 in that
      space anymore, it should be safe to use this memory for these configs.
      There is also a runtime check in arm_bl2_dyn_cfg_init() which ensures
      that this overlap doesn't happen.
      
      The previous arm_dyn_get_hwconfig_info() is modified to accept configs
      other than hw_config and hence renamed to arm_dyn_get_config_load_info().
      The patch also corrects the definition of ARM_TB_FW_CONFIG_LIMIT to be
      BL2_BASE.
      
      Change-Id: I03a137d9fa1f92c862c254be808b8330cfd17a5a
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      1d71ba14
  26. 15 May, 2018 1 commit
  27. 11 May, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Migrate AArch64 port to the multi console driver · 2f18aa1f
      Antonio Nino Diaz authored
      
      
      The old API is deprecated and will eventually be removed.
      
      Arm platforms now use the multi console driver for boot and runtime
      consoles. However, the crash console uses the direct console API because
      it doesn't need any memory access to work. This makes it more robust
      during crashes.
      
      The AArch32 port of the Trusted Firmware doesn't support this new API
      yet, so it is only enabled in AArch64 builds. Because of this, the
      common code must maintain compatibility with both systems. SP_MIN
      doesn't have to be updated because it's only used in AArch32 builds.
      The TSP is only used in AArch64, so it only needs to support the new
      API without keeping support for the old one.
      
      Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this
      causes the UARTs to reset (except for the one used by the TSP). This
      means that they must be unregistered when suspending and re-registered
      when resuming. This wasn't a problem with the old driver because it just
      restarted the UART, and there were no problems associated with
      registering and unregistering consoles.
      
      The size of BL31 has been increased in builds with SPM.
      
      Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2f18aa1f
  28. 01 May, 2018 1 commit
    • Roberto Vargas's avatar
      ARM platforms: Demonstrate mem_protect from el3_runtime · 638b034c
      Roberto Vargas authored
      
      
      Previously mem_protect used to be only supported from BL2. This is not
      helpful in the case when ARM TF-A BL2 is not used. This patch demonstrates
      mem_protect from el3_runtime firmware on ARM Platforms specifically
      when RESET_TO_BL31 or RESET_TO_SP_MIN flag is set as BL2 may be absent
      in these cases. The Non secure DRAM is dynamically mapped into EL3 mmap
      tables temporarily and then the protected regions are then cleared. This
      avoids the need to map the non secure DRAM permanently to BL31/sp_min.
      
      The stack size is also increased, because DYNAMIC_XLAT_TABLES require
      a bigger stack.
      
      Change-Id: Ia44c594192ed5c5adc596c0cff2c7cc18c001fde
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      638b034c
  29. 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
  30. 11 Jan, 2018 1 commit
  31. 03 Jan, 2018 1 commit
  32. 06 Dec, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Move S-EL1/S-EL0 xlat tables to TZC DRAM · 45d640f0
      Antonio Nino Diaz authored
      
      
      A new platform define, `PLAT_SP_IMAGE_XLAT_SECTION_NAME`, has been
      introduced to select the section where the translation tables used by
      the S-EL1/S-EL0 are placed.
      
      This define has been used to move the translation tables to DRAM secured
      by TrustZone.
      
      Most of the extra needed space in BL31 when SPM is enabled is due to the
      large size of the translation tables. By moving them to this memory
      region we can save 44 KiB.
      
      A new argument has been added to REGISTER_XLAT_CONTEXT2() to specify the
      region where the translation tables have to be placed by the linker.
      
      Change-Id: Ia81709b4227cb8c92601f0caf258f624c0467719
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      45d640f0
  33. 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
  34. 09 Nov, 2017 1 commit
  35. 25 Oct, 2017 1 commit
  36. 11 Oct, 2017 1 commit
    • Soby Mathew's avatar
      ARM platforms: enable GICv3 state save/restore · e35a3fb5
      Soby Mathew authored
      
      
      Provides GICv3 save/restore feature to arm_system_pwr_domain_resume and
      arm_system_pwr_domain_save functions.
      
      Introduce FVP PSCI power level 3 (System level) support. This is solely
      done to provide example code on how to use the GICv3 save and restore
      helpers.
      
      Also make CSS GICv3 platforms power off the Redistributor on SYSTEM
      SUSPEND as its state is saved and restored.
      
      Change-Id: I0d852f3af8824edee1a17c085cf593ddd33a4e77
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Co-Authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      e35a3fb5
  37. 06 Oct, 2017 1 commit
    • David Cunado's avatar
      Increase PLAT_ARM_MMAP_ENTRIES and MAX_XLAT_TABLES · 2e421ad2
      David Cunado authored
      
      
      The MEM_PROTECT support adds a MMAP region for DRAM2, which when
      building with TBBR support and OP-TEE tsp requires an additional
      entry in the MMAP region array in BL2 - PLAT_ARM_MMAP_ENTRIES is
      increased.
      
      The MEM_PROTECT support also adds a new region in BL31, and when
      BL31 is placed in DRAM, the memory mappings require an additional
      translation table - MAX_XLAT_TABLES is increased.
      
      Change-Id: I0b76260da817dcfd0b8f73a7193c36efda977625
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      2e421ad2
  38. 25 Sep, 2017 1 commit
    • Roberto Vargas's avatar
      mem_protect: Add mem_protect support in Juno and FVP for DRAM1 · f145403c
      Roberto Vargas authored
      
      
      mem_protect needs some kind of non-volatile memory because it has
      to remember its state across reset and power down events.
      The most suitable electronic part for this feature is a NVRAM
      which should be only accesible from the secure world. Juno and
      FVP lack such hardware and for this reason the MEM_PROTECT
      functionality is implemented with Flash EEPROM memory on both
      boards, even though this memory is accesible from the non-secure
      world. This is done only to show a full implementation of
      these PSCI features, but an actual system shouldn't use a
      non-secure NVRAM to implement it.
      
      The EL3 runtime software will write the mem_protect flag and BL2
      will read and clear the memory ranges if enabled. It is done in
      BL2 because it reduces the time that TF needs access to the full
      non-secure memory.
      
      The memory layout of both boards is defined using macros which
      take different values in Juno and FVP platforms. Generic platform
      helpers are added that use the platform specific macros to generate
      a mem_region_t that is valid for the platform.
      
      Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      f145403c
  39. 22 Sep, 2017 1 commit