1. 19 Aug, 2014 1 commit
    • Dan Handley's avatar
      Clarify platform porting interface to TSP · 5a06bb7e
      Dan Handley authored
      * Move TSP platform porting functions to new file:
        include/bl32/tsp/platform_tsp.h.
      
      * Create new TSP_IRQ_SEC_PHY_TIMER definition for use by the generic
        TSP interrupt handling code, instead of depending on the FVP
        specific definition IRQ_SEC_PHY_TIMER.
      
      * Rename TSP platform porting functions from bl32_* to tsp_*, and
        definitions from BL32_* to TSP_*.
      
      * Update generic TSP code to use new platform porting function names
        and definitions.
      
      * Update FVP port accordingly and move all TSP source files to:
        plat/fvp/tsp/.
      
      * Update porting guide with above changes.
      
      Note: THIS CHANGE REQUIRES ALL PLATFORM PORTS OF THE TSP TO
            BE UPDATED
      
      Fixes ARM-software/tf-issues#167
      
      Change-Id: Ic0ff8caf72aebb378d378193d2f017599fc6b78f
      5a06bb7e
  2. 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
  3. 12 Aug, 2014 2 commits
    • Dan Handley's avatar
      Rationalize console log output · 6ad2e461
      Dan Handley authored
      Fix the following issues with the console log output:
      
      * Make sure the welcome string is the first thing in the log output
      (during normal boot).
      * Prefix each message with the BL image name so it's clear which
      BL the output is coming from.
      * Ensure all output is wrapped in one of the log output macros so it can
      be easily compiled out if necessary. Change some of the INFO() messages
      to VERBOSE(), especially in the TSP.
      * Create some extra NOTICE() and INFO() messages during cold boot.
      * Remove all usage of \r in log output.
      
      Fixes ARM-software/tf-issues#231
      
      Change-Id: Ib24f7acb36ce64bbba549f204b9cde2dbb46c8a3
      6ad2e461
    • 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
  4. 11 Aug, 2014 1 commit
    • Soby Mathew's avatar
      Reduce the runtime stack size in BL stages. · aa442d34
      Soby Mathew authored
      This patch separates the stack size for each BL stage and
      reduces it after stack usage analysis was done.
      
      Fixes ARM-software/tf-issues#200
      
      Change-Id: I8edc6de2551b0a6788761d121937692b2149bb29
      aa442d34
  5. 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
  6. 28 Jul, 2014 1 commit
    • Achin Gupta's avatar
      Remove the concept of coherent stacks · 539a7b38
      Achin Gupta authored
      This patch removes the allocation of memory for coherent stacks, associated
      accessor function and some dead code which called the accessor function. It also
      updates the porting guide to remove the concept and the motivation behind using
      stacks allocated in coherent memory.
      
      Fixes ARM-software/tf-issues#198
      
      Change-Id: I00ff9a04f693a03df3627ba39727e3497263fc38
      539a7b38
  7. 10 Jul, 2014 1 commit
    • Sandrine Bailleux's avatar
      fvp: Reuse BL1 and BL2 memory through image overlaying · a1b6db6c
      Sandrine Bailleux authored
      This patch re-organizes the memory layout on FVP as to give the
      BL3-2 image as much memory as possible.
      
      Considering these two facts:
       - not all images need to live in memory at the same time. Once
         in BL3-1, the memory used by BL1 and BL2 can be reclaimed.
       - when BL2 loads the BL3-1 and BL3-2 images, it only considers the
         PROGBITS sections of those 2 images. The memory occupied by the
         NOBITS sections will be touched only at execution of the BL3-x
         images;
      Then it is possible to choose the different base addresses such that
      the NOBITS sections of BL3-1 and BL3-2 overlay BL1 and BL2.
      
      On FVP we choose to put:
       - BL1 and BL3-1 at the top of the Trusted RAM, with BL3-1 NOBITS
         sections overlaying BL1;
       - BL3-2 at the bottom of the Trusted RAM, with its NOBITS sections
         overlaying BL2;
      
      This is illustrated by the following diagram:
      
      0x0404_0000 ------------    ------------------
                  |   BL1    | <= |  BL3-1 NOBITS  |
                  ------------ <= ------------------
                  |          | <= | BL3-1 PROGBITS |
                  ------------    ------------------
                  |   BL2    | <= |  BL3-2 NOBITS  |
                  ------------ <= ------------------
                  |          | <= | BL3-2 PROGBITS |
      0x0400_0000 ------------    ------------------
      
      New platform-specific constants have been introduced to easily check
      at link time that BL3-1 and BL3-2 PROGBITS sections don't overwrite
      BL1 and BL2. These are optional and the platform code is free to define
      them or not. If not defined, the linker won't attempt to check
      image overlaying.
      
      Fixes ARM-software/tf-issues#117
      
      Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042
      a1b6db6c
  8. 23 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Correctly dimension the PSCI aff_map_node array · 6c0b45d1
      Andrew Thoelke authored
      The array of affinity nodes is currently allocated for 32 entries
      with the PSCI_NUM_AFFS value defined in psci.h. This is not enough
      for large systems, and will substantially over allocate the array
      for small systems.
      
      This patch introduces an optional platform definition
      PLATFORM_NUM_AFFS to platform_def.h. If defined this value is
      used for PSCI_NUM_AFFS, otherwise a value of two times the number
      of CPU cores is used.
      
      The FVP port defines PLATFORM_NUM_AFFS to be 10 which saves
      nearly 1.5KB of memory.
      
      Fixes ARM-software/tf-issues#192
      
      Change-Id: I68e30ac950de88cfbd02982ba882a18fb69c1445
      6c0b45d1
  9. 20 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Remove NSRAM from FVP memory map · 15f195bf
      Andrew Thoelke authored
      This memory is not used by the FVP port and requires an additional
      4KB translation table.
      
      This patch removes the entry from the memory map and reduces the
      number of allocated translation tables.
      
      Fixes ARM-software/tf-issues#196
      
      Change-Id: I5b959e4fe92f5f892ed127c40dbe6c85eed3ed72
      15f195bf
  10. 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