1. 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
  2. 26 Jan, 2015 1 commit
    • Juan Castillo's avatar
      FVP: Allow BL3-2 to sit in the secure region of DRAM · 513dd3a0
      Juan Castillo authored
      This patch allows the secure payload (BL3-2) to be loaded in the
      DRAM region secured by the TrustZone controller (top 16 MB of DRAM1).
      
      The location of BL3-2 can be selected at build time by setting the
      build flag FVP_TSP_RAM_LOCATION to one of the following options:
      
        - 'tsram' : Trusted SRAM (this is the default option)
        - 'tdram' : Trusted DRAM
        - 'dram'  : Secure region in DRAM1 (top 16MB configured by the
                    TrustZone controller)
      
      The number of MMU tables in BL3-2 depends on its location in
      memory: 3 in case it is loaded in DRAM, 2 otherwise.
      
      Documentation updated accordingly.
      
      Fixes ARM-software/tf-issues#212
      
      Change-Id: I371eef3a4159f06a0c9e3c6c1f4c905b2f93803a
      513dd3a0
  3. 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
  4. 10 Dec, 2014 1 commit
    • Sandrine Bailleux's avatar
      Remove IRQ_SEC_SGI_8 constant · 47ca01e7
      Sandrine Bailleux authored
      In both FVP and Juno ports, IRQ #16, which is a PPI, is incorrectly
      identified as secure SGI #8 through the constant IRQ_SEC_SGI_8.
      This patch removes it.
      
      Fixes ARM-software/tf-issues#282
      
      Change-Id: I9e52d849611ffcd2b1f28e56dd156c5b217ed63e
      47ca01e7
  5. 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
  6. 19 Aug, 2014 1 commit
    • Juan Castillo's avatar
      Add support for PSCI SYSTEM_OFF and SYSTEM_RESET APIs · d5f13093
      Juan Castillo authored
      This patch adds support for SYSTEM_OFF and SYSTEM_RESET PSCI
      operations. A platform should export handlers to complete the
      requested operation. The FVP port exports fvp_system_off() and
      fvp_system_reset() as an example.
      
      If the SPD provides a power management hook for system off and
      system reset, then the SPD is notified about the corresponding
      operation so it can do some bookkeeping. The TSPD exports
      tspd_system_off() and tspd_system_reset() for that purpose.
      
      Versatile Express shutdown and reset methods have been removed
      from the FDT as new PSCI sys_poweroff and sys_reset services
      have been added. For those kernels that do not support yet these
      PSCI services (i.e. GICv3 kernel), the original dtsi files have
      been renamed to *-no_psci.dtsi.
      
      Fixes ARM-software/tf-issues#218
      
      Change-Id: Ic8a3bf801db979099ab7029162af041c4e8330c8
      d5f13093
  7. 14 Aug, 2014 3 commits
    • Dan Handley's avatar
      Simplify interface to TZC-400 driver · 3279f625
      Dan Handley authored
      The TZC-400 driver previously allowed the possibility of multiple
      controller instances to be present in the same executable. This
      was unnecessary since there will only ever be one instance.
      
      This change simplifies the tzc_init() function to only take the
      base address argument needed by implementation, conforming to the
      driver initialization model of other drivers. It also hides some
      of the implementation details that were previously exposed by the
      API.
      
      The FVP port has been updated accordingly.
      
      THIS CHANGE REQUIRES ALL PLATFORM PORTS THAT USE THE TZC-400
      DRIVER TO BE UPDATED
      
      Fixes ARM-software/tf-issues#181
      
      Change-Id: I7b721edf947064989958d8f457d6462d92e742c8
      3279f625
    • 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
  8. 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
  9. 01 Aug, 2014 1 commit
    • Juan Castillo's avatar
      Call platform_is_primary_cpu() only from reset handler · 53fdcebd
      Juan Castillo authored
      The purpose of platform_is_primary_cpu() is to determine after reset
      (BL1 or BL3-1 with reset handler) if the current CPU must follow the
      cold boot path (primary CPU), or wait in a safe state (secondary CPU)
      until the primary CPU has finished the system initialization.
      
      This patch removes redundant calls to platform_is_primary_cpu() in
      subsequent bootloader entrypoints since the reset handler already
      guarantees that code is executed exclusively on the primary CPU.
      
      Additionally, this patch removes the weak definition of
      platform_is_primary_cpu(), so the implementation of this function
      becomes mandatory. Removing the weak symbol avoids other
      bootloaders accidentally picking up an invalid definition in case the
      porting layer makes the real function available only to BL1.
      
      The define PRIMARY_CPU is no longer mandatory in the platform porting
      because platform_is_primary_cpu() hides the implementation details
      (for instance, there may be platforms that report the primary CPU in
      a system register). The primary CPU definition in FVP has been moved
      to fvp_def.h.
      
      The porting guide has been updated accordingly.
      
      Fixes ARM-software/tf-issues#219
      
      Change-Id: If675a1de8e8d25122b7fef147cb238d939f90b5e
      53fdcebd
  10. 28 Jul, 2014 1 commit
    • Soby Mathew's avatar
      Parametrize baudrate and UART clock during console_init() · 462c8350
      Soby Mathew authored
      This patch adds baud rate and UART clock frequency as parameters
      to the pl011 driver api console_init(). This allows each platform
      to specify UART clock and baud rate according to their specific
      hardware implementation.
      
      Fixes ARM-software/tf-issues#215
      
      Change-Id: Id13eef70a1c530e709b34dd1e6eb84db0797ced2
      462c8350
  11. 09 Jul, 2014 1 commit
    • Dan Handley's avatar
      Refactor fvp_config into common platform header · 6f3b195a
      Dan Handley authored
      Changed the fvp_config array in fvp_common.c into a struct and
      moved into a new optional common platform header,
      include/plat/common/plat_config.h. Removed the config definitions
      in fvp_def.h and updated all references to the platform config.
      
      This makes the interface to the platform config cleaner and uses
      a little less RAM.
      
      Fixes ARM-software/tf-issues#180
      
      Change-Id: I58dd7b3c150f24f7ee230a26fd57c827853ba803
      6f3b195a
  12. 27 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Support later revisions of the Foundation FVP · 90e31479
      Andrew Thoelke authored
      The code in the FVP port which checks the platform type and
      revision information in the SYS_ID register strictly supported
      only the first revision of the Base and Foundation FVPs.
      
      The current check also does not reflect the fact that the
      board revision field is 'local' to the board type (HBI field).
      
      Support for a new Foundation model is required now, and the
      checking code is relaxed to allow execution (with a diagnostic)
      on unrecognised revisions of the Base and Foundation FVP.
      
      Change-Id: I7cd3519dfb56954aafe5f52ce1fcea0ee257ba9f
      90e31479
  13. 16 Jun, 2014 1 commit
  14. 29 May, 2014 1 commit
    • Andrew Thoelke's avatar
      Allow platform parameter X1 to be passed to BL3-1 · 03462671
      Andrew Thoelke authored
      bl2_main() was overwriting any platform set X1 parameter for BL3-1
      with the value zero.
      
      This patch ensure that any platform set value is correctly passed
      to BL3-1. The FVP port adds a check to verify this parameter is
      being passed correctly.
      
      Fixes ARM-software/tf-issues#173
      
      Change-Id: Ifbcda73d3d41d2b04a4baf5614e9d2d21f1717c8
      03462671
  15. 23 May, 2014 1 commit
    • Dan Handley's avatar
      Split platform.h into separate headers · 5f0cdb05
      Dan Handley authored
      Previously, platform.h contained many declarations and definitions
      used for different purposes. This file has been split so that:
      
      * Platform definitions used by common code that must be defined
        by the platform are now in platform_def.h. The exact include
        path is exported through $PLAT_INCLUDES in the platform makefile.
      
      * Platform definitions specific to the FVP platform are now in
        /plat/fvp/fvp_def.h.
      
      * Platform API declarations specific to the FVP platform are now
        in /plat/fvp/fvp_private.h.
      
      * The remaining platform API declarations that must be ported by
        each platform are still in platform.h but this file has been
        moved to /include/plat/common since this can be shared by all
        platforms.
      
      Change-Id: Ieb3bb22fbab3ee8027413c6b39a783534aee474a
      5f0cdb05