1. 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
  2. 05 Sep, 2017 1 commit
  3. 31 Aug, 2017 1 commit
  4. 25 Aug, 2017 1 commit
  5. 23 Aug, 2017 1 commit
    • Isla Mitchell's avatar
      FVP: Always assume shifted affinity with MT bit · 8431635b
      Isla Mitchell authored
      
      
      At present, the MPIDR validation on FVP relies on MT bit set along
      with shifted affinities. This currently is additionally dependent
      on the FVP model being of variant C. This however should be based
      on the presence of MT bit alone.
      
      This patch makes the change to always assume that the affinities
      are shifted in the FVP model when MT bit is present.
      
      Change-Id: I09fcb0126e1b38d29124bdeaf3450a60b95d485d
      Signed-off-by: default avatarIsla Mitchell <isla.mitchell@arm.com>
      8431635b
  6. 02 Aug, 2017 1 commit
    • Jeenu Viswambharan's avatar
      FVP: Support Base FVP RevC · 955242d8
      Jeenu Viswambharan authored
      
      
      Revision C of the Base FVP has the same memory map as earlier revisions,
      but has the following differences:
      
        - Implements CCI550 instead of CCI400,
        - Has a single instantiation of SMMUv3,
        - CPU MPIDs are shifted left by one level, and has MT bit set in them.
      
      The correct interconnect to program is chosen at run time based on the
      FVP revision. Therefore, this patch implements FVP functions for
      interconnect programming, rather than depending on ARM generic ones. The
      macros used have been renamed to reflect this change.
      
      Additionally, this patch initializes SMMUv3 as part of FVP early
      platform setup.
      
      New ARM config flags are introduced for feature queries at run time.
      
      Change-Id: Ic7b7f080953a51fceaf62ce7daa6de0573801f09
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      955242d8
  7. 25 Jul, 2017 1 commit
  8. 03 May, 2017 1 commit
  9. 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
  10. 23 Sep, 2016 1 commit
    • Sandrine Bailleux's avatar
      Whitelist version 9.6 of Foundation FVP · 4faa4a1d
      Sandrine Bailleux authored
      This prevents a warning being emitted in the console during FVP
      configuration setup when using the Foundation FVP 9.6 onwards.
      
      Change-Id: I685b8bd0dbd0119af4b0cb3f7d708fcc08e99561
      4faa4a1d
  11. 10 Aug, 2016 1 commit
    • Soby Mathew's avatar
      AArch32: Add essential ARM platform and FVP support · 877cf3ff
      Soby Mathew authored
      This patch adds AArch32 support for FVP and implements common platform APIs
      like `plat_get_my_stack`, `plat_set_my_stack`, `plat_my_core_cos` for AArch32.
      Only Multi Processor(MP) implementations of these functions are considered in
      this patch. The ARM Standard platform layer helpers are implemented for
      AArch32 and the common makefiles are modified to cater for both AArch64 and
      AArch32 builds. Compatibility with the deprecated platform API is not
      supported for AArch32.
      
      Change-Id: Iad228400613eec91abf731b49e21a15bcf2833ea
      877cf3ff
  12. 08 Jul, 2016 2 commits
    • Sandrine Bailleux's avatar
      ARM CSS platforms: Map flash as execute-never by default · 91fad655
      Sandrine Bailleux authored
      On ARM CSS platforms, the whole flash used to be mapped as executable.
      This is not required, given that the flash is used to store the BL1
      and FIP images and:
      
       - The FIP is not executed in place, its images are copied to RAM
         and executed from there.
      
       - BL1 is executed in place from flash but only its code needs to be
         mapped as executable and platform code takes care of re-mapping
         BL1's read-only section as executable.
      
      Therefore, this patch now maps the flash as non-executable by default
      on these platforms. This increases security by restricting the
      executable region to what is strictly needed.
      
      This patch also adds some comments to clarify the memory mapping
      attributes on these platforms.
      
      Change-Id: I4db3c145508bea1f43fbe0f6dcd551e1aec1ecd3
      91fad655
    • Sandrine Bailleux's avatar
      Introduce arm_setup_page_tables() function · b5fa6563
      Sandrine Bailleux authored
      This patch introduces the arm_setup_page_tables() function to
      set up page tables on ARM platforms. It replaces the
      arm_configure_mmu_elx() functions and does the same thing except
      that it doesn't enable the MMU at the end. The idea is to reduce
      the amount of per-EL code that is generated by the C preprocessor
      by splitting the memory regions definitions and page tables creation
      (which is generic) from the MMU enablement (which is the only per-EL
      configuration).
      
      As a consequence, the call to the enable_mmu_elx() function has been
      moved up into the plat_arch_setup() hook. Any other ARM standard
      platforms that use the functions `arm_configure_mmu_elx()` must be
      updated.
      
      Change-Id: I6f12a20ce4e5187b3849a8574aac841a136de83d
      b5fa6563
  13. 03 Jun, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Implement plat_set_nv_ctr for FVP platforms · fe7de035
      Antonio Nino Diaz authored
      Replaced placeholder implementation of plat_set_nv_ctr for FVP
      platforms by a working one.
      
      On FVP, the mapping of region DEVICE2 has been changed from RO to RW
      to prevent exceptions when writing to the NV counter, which is
      contained in this region.
      
      Change-Id: I56a49631432ce13905572378cbdf106f69c82f57
      fe7de035
  14. 25 May, 2016 1 commit
    • Soby Mathew's avatar
      Add CCN support to FVP platform port · 71237876
      Soby Mathew authored
      This patch adds support to select CCN driver for FVP during build.
      A new build option `FVP_INTERCONNECT_DRIVER` is added to allow
      selection between the CCI and CCN driver. Currently only the CCN-502
      variant is supported on FVP.
      
      The common ARM CCN platform helper file now verifies the cluster
      count declared by platform is equal to the number of root node
      masters exported by the ARM Standard platform.
      
      Change-Id: I71d7b4785f8925ed499c153b2e9b9925fcefd57a
      71237876
  15. 27 Apr, 2016 1 commit
    • Soby Mathew's avatar
      Remove support for legacy VE memory map in FVP · 21a3973d
      Soby Mathew authored
      This patch removes support for legacy Versatile Express memory map for the
      GIC peripheral in the FVP platform. The user guide is also updated for the
      same.
      
      Change-Id: Ib8cfb819083aca359e5b46b5757cb56cb0ea6533
      21a3973d
  16. 13 Apr, 2016 1 commit
    • Soby Mathew's avatar
      Migrate platform ports to the new xlat_tables library · 3e4b8fdc
      Soby Mathew authored
      This patch modifies the upstream platform port makefiles to use the new
      xlat_tables library files. This patch also makes mmap region setup common
      between AArch64 and AArch32 for FVP platform port. The file `fvp_common.c`
      is moved from the `plat/arm/board/fvp/aarch64` folder to the parent folder
      as it is not specific to AArch64.
      
      Change-Id: Id2e9aac45e46227b6f83cccfd1e915404018ea0b
      3e4b8fdc
  17. 31 Mar, 2016 1 commit
    • 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
  18. 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
  19. 09 Dec, 2015 3 commits
    • Yatharth Kochar's avatar
      FWU: Add Firmware Update support in BL2U for ARM platforms · dcda29f6
      Yatharth Kochar authored
      This patch adds support for Firmware update in BL2U for ARM
      platforms such that TZC initialization is performed on all
      ARM platforms and (optionally) transfer of SCP_BL2U image on
      ARM CSS platforms.
      
      BL2U specific functions are added to handle early_platform and
      plat_arch setup. The MMU is configured to map in the BL2U
      code/data area and other required memory.
      
      Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
      dcda29f6
    • Yatharth Kochar's avatar
      FWU: Add Firmware Update support in BL1 for ARM platforms · 436223de
      Yatharth Kochar authored
      This patch adds Firmware Update support for ARM platforms.
      
      New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide
      platform specific Firmware update code.
      
      BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for
      authenticating NS_BL2U image(For both FVP and JUNO platform).
      
      Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
      436223de
    • Achin Gupta's avatar
      Rework use of ARM GIC drivers on ARM platforms · 27573c59
      Achin Gupta authored
      Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three
      separate drivers instead of providing a single driver that can work on both
      versions of the GIC architecture. These drivers correspond to the following
      software use cases:
      
      1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations
         e.g. GIC-400
      
      2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations
         e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features
      
      3. A deprecated GICv3 driver that operates in legacy mode. This driver can
         operate only in the GICv2 mode in the secure world. On a GICv3 system, this
         driver allows normal world to run in either GICv3 mode (asymmetric mode)
         or in the GICv2 mode. Both modes of operation are deprecated on GICv3
         systems.
      
      ARM platforms implement both versions of the GIC architecture. This patch adds a
      layer of abstraction to help ARM platform ports chose the right GIC driver and
      corresponding platform support. This is as described below:
      
      1. A set of ARM common functions have been introduced to initialise the GIC and
         the driver during cold and warm boot. These functions are prefixed as
         "plat_arm_gic_". Weak definitions of these functions have been provided for
         each type of driver.
      
      2. Each platform includes the sources that implement the right functions
         directly into the its makefile. The FVP can be instantiated with different
         versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option
         to specify which of the three drivers should be included in the build.
      
      3. A list of secure interrupts has to be provided to initialise each of the
        three GIC drivers. For GIC v3.0 the interrupt ids have to be further
        categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two
        types are merged and treated as Group 0 interrupts.
      
        The two lists of interrupts are exported from the platform_def.h. The lists
        are constructed by adding a list of board specific interrupt ids to a list of
        ids common to all ARM platforms and Compute sub-systems.
      
      This patch also makes some fields of `arm_config` data structure in FVP redundant
      and these unused fields are removed.
      
      Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
      27573c59
  20. 02 Dec, 2015 1 commit
    • Juan Castillo's avatar
      TBB: add Trusted Watchdog support on ARM platforms · 7b4c1405
      Juan Castillo authored
      This patch adds watchdog support on ARM platforms (FVP and Juno).
      A secure instance of SP805 is used as Trusted Watchdog. It is
      entirely managed in BL1, being enabled in the early platform setup
      hook and disabled in the exit hook. By default, the watchdog is
      enabled in every build (even when TBB is disabled).
      
      A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG`
      has been introduced to allow the user to disable the watchdog at
      build time. This feature may be used for testing or debugging
      purposes.
      
      Specific error handlers for Juno and FVP are also provided in this
      patch. These handlers will be called after an image load or
      authentication error. On FVP, the Table of Contents (ToC) in the FIP
      is erased. On Juno, the corresponding error code is stored in the
      V2M Non-Volatile flags register. In both cases, the CPU spins until
      a watchdog reset is generated after 256 seconds (as specified in
      the TBBR document).
      
      Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
      7b4c1405
  21. 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
  22. 25 Jun, 2015 1 commit
    • Juan Castillo's avatar
      TBB: add platform API to read the ROTPK information · 95cfd4ad
      Juan Castillo authored
      This patch extends the platform port by adding an API that returns
      either the Root of Trust public key (ROTPK) or its hash. This is
      usually stored in ROM or eFUSE memory. The ROTPK returned must be
      encoded in DER format according to the following ASN.1 structure:
      
          SubjectPublicKeyInfo  ::=  SEQUENCE  {
              algorithm           AlgorithmIdentifier,
              subjectPublicKey    BIT STRING
          }
      
      In case the platform returns a hash of the key:
      
          DigestInfo  ::= SEQUENCE {
              digestAlgorithm     AlgorithmIdentifier,
              keyDigest           OCTET STRING
          }
      
      An implementation for ARM development platforms is provided in this
      patch. When TBB is enabled, the ROTPK hash location must be specified
      using the build option 'ARM_ROTPK_LOCATION'. Available options are:
      
          - 'regs' : return the ROTPK hash stored in the Trusted
            root-key storage registers.
      
          - 'devel_rsa' : return a ROTPK hash embedded in the BL1 and
            BL2 binaries. This hash has been obtained from the development
            RSA public key located in 'plat/arm/board/common/rotpk'.
      
      On FVP, the number of MMU tables has been increased to map and
      access the ROTPK registers.
      
      A new file 'board_common.mk' has been added to improve code sharing
      in the ARM develelopment platforms.
      
      Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
      95cfd4ad
  23. 28 Apr, 2015 2 commits
    • Dan Handley's avatar
      Move FVP port to plat/arm/board/fvp · 3fc4124c
      Dan Handley authored
      Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename
      some of the files so they are consistently prefixed with fvp_.
      Update the platform makefiles accordingly.
      
      Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
      3fc4124c
    • Dan Handley's avatar
      Migrate FVP port to use common code · 60eea55e
      Dan Handley authored
      Major update to the FVP platform port to use the common platform code
      in (include/)plat/arm/* and (include/)plat/common/*. This mainly
      consists of removing duplicated code but also introduces some small
      behavioural changes where there was unnecessary variation between the
      FVP and Juno ports. See earlier commit titled `Add common ARM and CSS
      platform code` for details.
      
      Also add support for Foundation FVP version 9.1 during FVP config
      setup to prevent a warning being emitted in the console.
      
      Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
      60eea55e
  24. 16 Mar, 2015 2 commits
  25. 12 Feb, 2015 1 commit
    • Soby Mathew's avatar
      Minimize MAX_MMAP_REGIONS for each BL stage · ce41250e
      Soby Mathew authored
      This patch defines MAX_MMAP_REGIONS separately for each BL stage
      as per its requirements. This minimizes the size of the mmap[]
      array.
      
      Fixes ARM-Software/tf-issues#201
      
      Change-Id: I19b15e1a91a8365b2ecf24e2cd71937cb73916b2
      ce41250e
  26. 22 Jan, 2015 1 commit
    • Soby Mathew's avatar
      Remove coherent memory from the BL memory maps · ab8707e6
      Soby Mathew authored
      This patch extends the build option `USE_COHERENT_MEMORY` to
      conditionally remove coherent memory from the memory maps of
      all boot loader stages. The patch also adds necessary
      documentation for coherent memory removal in firmware-design,
      porting and user guides.
      
      Fixes ARM-Software/tf-issues#106
      
      Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
      ab8707e6
  27. 21 Jan, 2015 1 commit
    • Juan Castillo's avatar
      FVP: map non-secure DRAM1 in the MMU · 6fd9eaf3
      Juan Castillo authored
      This patch maps the non-secure region of DRAM1 in the MMU. The
      non-secure region comprises the whole DRAM1 (0x80000000 -
      0xffffffff) excluding the top 16 MB (0xff000000 - 0xffffffff).
      The TrustZone controller configures this 16 MB region as secure
      memory, so it can not be accessed in non-secure mode.
      
      The number of MMU tables in BL2 has been increased to 3 because
      the new size of the non-secure region in DRAM requires an extra L2
      table.
      
      Change-Id: I5ad080c6e181f6b6060e15cebb1d18b7fa128cf5
      6fd9eaf3
  28. 22 Oct, 2014 1 commit
    • Juan Castillo's avatar
      FVP: keep shared data in Trusted SRAM · 20d51cad
      Juan Castillo authored
      This patch deprecates the build option to relocate the shared data
      into Trusted DRAM in FVP. After this change, shared data is always
      located at the base of Trusted SRAM. This reduces the complexity
      of the memory map and the number of combinations in the build
      options.
      
      Fixes ARM-software/tf-issues#257
      
      Change-Id: I68426472567b9d8c6d22d8884cb816f6b61bcbd3
      20d51cad
  29. 25 Sep, 2014 1 commit
    • Soby Mathew's avatar
      Create BL stage specific translation tables · d0ecd979
      Soby Mathew authored
      This patch uses the IMAGE_BL<x> constants to create translation tables specific
      to a boot loader stage. This allows each stage to create mappings only for areas
      in the memory map that it needs.
      
      Fixes ARM-software/tf-issues#209
      
      Change-Id: Ie4861407ddf9317f0fb890fc7575eaa88d0de51c
      d0ecd979
  30. 20 Aug, 2014 1 commit
    • Soby Mathew's avatar
      Add CPU specific power management operations · add40351
      Soby Mathew authored
      This patch adds CPU core and cluster power down sequences to the CPU specific
      operations framework introduced in a earlier patch. Cortex-A53, Cortex-A57 and
      generic AEM sequences have been added. The latter is suitable for the
      Foundation and Base AEM FVPs. A pointer to each CPU's operations structure is
      saved in the per-cpu data so that it can be easily accessed during power down
      seqeunces.
      
      An optional platform API has been introduced to allow a platform to disable the
      Accelerator Coherency Port (ACP) during a cluster power down sequence. The weak
      definition of this function (plat_disable_acp()) does not take any action. It
      should be overriden with a strong definition if the ACP is present on a
      platform.
      
      Change-Id: I8d09bd40d2f528a28d2d3f19b77101178778685d
      add40351
  31. 14 Aug, 2014 2 commits
    • Dan Handley's avatar
      Remove platform dependency in CCI-400 driver · cae3ef99
      Dan Handley authored
      * Create cci_init() function in CCI-400 driver to allow platform
        to provide arguments needed by the driver (i.e. base address
        and cluster indices for the ACE slave interfaces).
      
      * Rename cci_(en|dis)able_coherency to
        cci_(en|dis)able_cluster_coherency to make it clear that
        the driver only enables/disables the coherency of CPU
        clusters and not other devices connected to the CCI-400.
      
      * Update FVP port to use new cci_init() function and remove
        unnecessary CCI defintions from platform_def.h. Also rename
        fvp_cci_setup() to fvp_cci_enable() to more clearly
        differentiate between CCI initialization and enabling.
      
      THIS CHANGE REQUIRES PLATFORM PORTS THAT USE THE CCI-400 DRIVER
      TO BE UPDATED
      
      Fixes ARM-software/tf-issues#168
      
      Change-Id: I1946a51409b91217b92285b6375082619f607fec
      cae3ef99
    • Juan Castillo's avatar
      FVP: make usage of Trusted DRAM optional at build time · 186c1d4b
      Juan Castillo authored
      This patch groups the current contents of the Trusted DRAM region at
      address 0x00_0600_0000 (entrypoint mailboxes and BL3-1 parameters) in
      a single shared memory area that may be allocated to Trusted SRAM
      (default) or Trusted DRAM at build time by setting the
      FVP_SHARED_DATA_LOCATION make variable. The size of this shared
      memory is 4096 bytes.
      
      The combination 'Shared data in Trusted SRAM + TSP in Trusted DRAM'
      is not currently supported due to restrictions in the maximum number
      of mmu tables that can be created.
      
      Documentation has been updated to reflect these changes.
      
      Fixes ARM-software/tf-issues#100
      
      Change-Id: I26ff04d33ce4cacf8d770d1a1e24132b4fc53ff0
      186c1d4b
  32. 12 Aug, 2014 1 commit
    • Juan Castillo's avatar
      FVP: apply new naming conventions to memory regions · 637ebd2e
      Juan Castillo authored
      Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM
      Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM
      Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM
      
      BLn_BASE and BLn_LIMIT definitions have been updated and are based on
      these new memory regions.
      
      The available memory for each bootloader in the linker script is
      defined by BLn_BASE and BLn_LIMIT, instead of the complete memory
      region.
      
      TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of
      the platform porting.
      
      FVP common definitions are defined in fvp_def.h while platform_def.h
      contains exclusively (with a few exceptions) the definitions that are
      mandatory in the porting guide. Therefore, platform_def.h now includes
      fvp_def.h instead of the other way around.
      
      Porting guide has been updated to reflect these changes.
      
      Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05
      637ebd2e
  33. 28 Jul, 2014 1 commit
    • Juan Castillo's avatar
      Rework incorrect use of assert() and panic() in codebase · d3280beb
      Juan Castillo authored
      Assert a valid security state using the macro sec_state_is_valid().
      Replace assert() with panic() in those cases that might arise
      because of runtime errors and not programming errors.
      Replace panic() with assert() in those cases that might arise
      because of programming errors.
      
      Fixes ARM-software/tf-issues#96
      
      Change-Id: I51e9ef0439fd5ff5e0edfef49050b69804bf14d5
      d3280beb