1. 22 Jan, 2015 1 commit
    • Soby Mathew's avatar
      Move bakery algorithm implementation out of coherent memory · 8c5fe0b5
      Soby Mathew authored
      This patch moves the bakery locks out of coherent memory to normal memory.
      This implies that the lock information needs to be placed on a separate cache
      line for each cpu. Hence the bakery_lock_info_t structure is allocated in the
      per-cpu data so as to minimize memory wastage. A similar platform per-cpu
      data is introduced for the platform locks.
      
      As a result of the above changes, the bakery lock api is completely changed.
      Earlier, a reference to the lock structure was passed to the lock implementation.
      Now a unique-id (essentially an index into the per-cpu data array) and an offset
      into the per-cpu data for bakery_info_t needs to be passed to the lock
      implementation.
      
      Change-Id: I1e76216277448713c6c98b4c2de4fb54198b39e0
      8c5fe0b5
  2. 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
  3. 04 Nov, 2014 1 commit
    • Soby Mathew's avatar
      Use the BL3-1 runtime console as the crash console. · ce6ee933
      Soby Mathew authored
      This patch reassigns the crash console on Juno and FVP to use the runtime
      BL3-1 console. The crash console is changed to SoC UART0 (UART2) from the
      previous FPGA UART0 (UART0) on Juno. In FVP, it is changed from UART0 to
      UART1.
      
      Fixes ARM-software/tf-issues#256
      
      Change-Id: I7df54f86ca00ec2652c27261dd66a94c12610816
      ce6ee933
  4. 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
  5. 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
  6. 22 Sep, 2014 1 commit
    • Soby Mathew's avatar
      Remove BSS section access by 'plat_print_gic' during crash reporting · 6ab03912
      Soby Mathew authored
      This patch avoids the problem of crash reporting mechanism accessing
      global data in BSS by 'plat_print_gic_regs' for FVP platforms. Earlier
      it depended on the global 'plat_config' object for the GIC Base address
      in FVP platforms which would have caused exception if it were accessed
      before the BSS was initialized. It is now fixed by dynamically
      querying the V2M_SYS_ID to find the FVP model type and accordingly
      selecting the appropriate GIC Base address.
      
      This patch also fixes the 'plat_print_gic_regs' to use the correct GIC
      Distributor base address for printing GICD_IS_PENDR register values
      for both Juno and FVP platforms.
      
      Fixes ARM-Software/tf-issues#236
      
      Change-Id: I545c7b908b3111419bf27db0575ce86acf86784b
      6ab03912
  7. 27 Aug, 2014 1 commit
  8. 21 Aug, 2014 1 commit
    • Soby Mathew's avatar
      Rationalize UART usage among different BL stages · 12d554f9
      Soby Mathew authored
      This patch changes the UART port assignment for various BL stages
      so as to make it consistent on the platform ports. The BL1, BL2 and
      BL3-1 now uses UART0 on the FVP port and SoC UART0 on the Juno port.
      The BL3-2 uses UART2 on the FVP port and FPGA UART0 on the Juno
      port.
      
      This provides an interim fix to ARM-software/tf-issues#220 until
      support is added for changing the UART port for a BL image between
      cold boot and runtime.
      
      Change-Id: Iae5faea90be3d59e41e597b34a902f93e737505a
      12d554f9
  9. 20 Aug, 2014 2 commits
    • 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
    • Soby Mathew's avatar
      Introduce framework for CPU specific operations · 9b476841
      Soby Mathew authored
      This patch introduces a framework which will allow CPUs to perform
      implementation defined actions after a CPU reset, during a CPU or cluster power
      down, and when a crash occurs. CPU specific reset handlers have been implemented
      in this patch. Other handlers will be implemented in subsequent patches.
      
      Also moved cpu_helpers.S to the new directory lib/cpus/aarch64/.
      
      Change-Id: I1ca1bade4d101d11a898fb30fea2669f9b37b956
      9b476841
  10. 19 Aug, 2014 4 commits
    • Soby Mathew's avatar
      Rework use of labels in assembly macros. · aecc0840
      Soby Mathew authored
      This patch provides a workaround for the ASM_ASSERT label issue
      and also reworks the use of labels in assembly macros.
      If the caller of the ASM_ASSERT macro happened to use the
      label '1' to jump past the ASM_ASSERT macro, it would not have
      worked since the ASM_ASSERT macro internally used the same label.
      Hence, as a workaround, this patch makes the label a high
      number in the expectation that the caller will never use it.
      
      Also updated the other assembly macros using numerical labels to
      named lables.
      
      Change-Id: Iec892359db84f2391ad2a83a92141c4d7049776a
      aecc0840
    • Achin Gupta's avatar
      fvp: Rework when platform actions are performed · 7d2ccfd7
      Achin Gupta authored
      This patch reworks FVP port's power management implementation to perform
      platform actions only when the platform exported hook is invoked for the highest
      affinity level to enter/exit the OFF state.
      
      For example, during a CPU_OFF operation, fvp_affinst_off() is called twice: for
      affinity level 0 and affinity level 1 (in that order). CPU specific operations
      are deferred until the next invocation if it is determined through a call to
      psci_get_max_phys_off_afflvl() that this is CPU is the last in the cluster.
      
      Similarly, during power up if the CPU is the first in the cluster, both CPU and
      cluster specific operations are performed when fvp_affinst_on_finish() is
      invoked for affinity level 1. Earlier, they were done across the two invocations
      of the handler.
      
      Change-Id: I4288ed3ba1385db36a69cc2e598deb219f209b8a
      7d2ccfd7
    • 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
    • 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
  11. 14 Aug, 2014 5 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
      Move IO storage source to drivers directory · 935db693
      Dan Handley authored
      Move the remaining IO storage source file (io_storage.c) from the
      lib to the drivers directory. This requires that platform ports
      explicitly add this file to the list of source files.
      
      Also move the IO header files to a new sub-directory, include/io.
      
      Change-Id: I862b1252a796b3bcac0d93e50b11e7fb2ded93d6
      935db693
    • Dan Handley's avatar
      Remove redundant io_init() function · 6d16ce0b
      Dan Handley authored
      The intent of io_init() was to allow platform ports to provide
      a data object (io_plat_data_t) to the IO storage framework to
      allocate into. The abstraction was incomplete because io_plat_data_t
      uses a platform defined constant and the IO storage framework
      internally allocates other arrays using platform defined constants.
      
      This change simplifies the implementation by instantiating the
      supporting objects in the IO storage framework itself. There is now
      no need for the platform to call io_init().
      
      The FVP port has been updated accordingly.
      
      THIS CHANGE REQUIRES ALL PLATFORM PORTS THAT USE THE IO STORAGE
      FRAMEWORK TO BE UDPATED.
      
      Change-Id: Ib48ac334de9e538064734334c773f8b43df3a7dc
      6d16ce0b
    • 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
  12. 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
  13. 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
  14. 01 Aug, 2014 2 commits
    • Vikram Kanigiri's avatar
      Rework the TSPD setup code · 50e27dad
      Vikram Kanigiri authored
      There is no mechanism which allows the TSPD to specify what SPSR to
      use when entering BL3-2 instead of BL3-3. This patch divides the
      responsibility between tspd_setup() and tspd_init() for initializing
      the TSPD and TSP to support the alternate BL3-2 initialization flow
      where BL3-1 handsover control to BL3-2 instead of BL3-3.
      SPSR generated by TSPD for TSP is preserved due the new division of
      labour which fixes #174.
      
      This patch also moves the cpu_context initialization code from
      tspd_setup() to tspd_init() immediately before entering the TSP.
      Instead tspd_setup() updates the BL3-2 entrypoint info structure
      with the state required for initializing the TSP later.
      
      Fixes  ARM-software/TF-issues#174
      
      Change-Id: Ida0a8a48d466c71d5b07b8c7f2af169b73f96940
      50e27dad
    • 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
  15. 28 Jul, 2014 7 commits
    • 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
    • Soby Mathew's avatar
      Add CPUECTLR_EL1 and Snoop Control register to crash reporting · 8c106902
      Soby Mathew authored
      This patch adds the CPUECTLR_EL1 register and the CCI Snoop Control
      register to the list of registers being reported when an unhandled
      exception occurs.
      
      Change-Id: I2d997f2d6ef3d7fa1fad5efe3364dc9058f9f22c
      8c106902
    • Soby Mathew's avatar
      Rework the crash reporting in BL3-1 to use less stack · 626ed510
      Soby Mathew authored
      This patch reworks the crash reporting mechanism to further
      optimise the stack and code size. The reporting makes use
      of assembly console functions to avoid calling C Runtime
      to report the CPU state. The crash buffer requirement is
      reduced to 64 bytes with this implementation. The crash
      buffer is now part of per-cpu data which makes retrieving
      the crash buffer trivial.
      
      Also now panic() will use crash reporting if
      invoked from BL3-1.
      
      Fixes ARM-software/tf-issues#199
      
      Change-Id: I79d27a4524583d723483165dc40801f45e627da5
      626ed510
    • Soby Mathew's avatar
      Introduce crash console APIs for crash reporting · c67b09bd
      Soby Mathew authored
      This patch introduces platform APIs to initialise and
      print a character on a designated crash console.
      For the FVP platform, PL011_UART0 is the designated
      crash console. The platform porting guide is also updated
      to document the new APIs.
      
      Change-Id: I5e97d8762082e0c88c8c9bbb479353eac8f11a66
      c67b09bd
    • 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
    • Soby Mathew's avatar
      Introduce asm console functions in TF · fce5f750
      Soby Mathew authored
      This patch replaces the pl011 console family of functions
      with their equivalents defined in assembly. The baud rate is
      defined by the PL011_BAUDRATE macro and IBRD and FBRD values
      for pl011 are computed statically. This patch will enable
      us to invoke the console functions without the C Runtime Stack.
      
      Change-Id: Ic3f7b7370ded38bf9020bf746b362081b76642c7
      fce5f750
    • 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
  16. 19 Jul, 2014 1 commit
    • Achin Gupta's avatar
      Make enablement of the MMU more flexible · afff8cbd
      Achin Gupta authored
      This patch adds a 'flags' parameter to each exception level specific function
      responsible for enabling the MMU. At present only a single flag which indicates
      whether the data cache should also be enabled is implemented. Subsequent patches
      will use this flag when enabling the MMU in the warm boot paths.
      
      Change-Id: I0eafae1e678c9ecc604e680851093f1680e9cefa
      afff8cbd
  17. 17 Jul, 2014 1 commit
    • Sandrine Bailleux's avatar
      Define ARM_GIC_ARCH default value for all platforms · 2b98e789
      Sandrine Bailleux authored
      The ARM_GIC_ARCH build option was supposed to default to 2 on all
      platforms. However, the default value was set in the FVP makefile
      so for all other platforms it wasn't even defined.
      
      This patch moves the default value to the main Makefile. The platform
      port can then override it if needed.
      
      Change-Id: I8e2da1cce7ffa3ed18814bbdcbcf2578101f18a6
      2b98e789
  18. 16 Jul, 2014 1 commit
    • Juan Castillo's avatar
      FVP: Ensure system reset wake-up results in cold boot · 08783e43
      Juan Castillo authored
      platform_get_entrypoint() did not consider that a wakeup due to
      System Reset Pin (by reading the power controller's PSYSR) requires
      a cold boot. As a result, the code would execute the warm boot path
      and eventually panic because entrypoint mailboxes are empty.
      
      This patch ensures that the following wake-up reasons result in cold
      boot:
        - Cold Power-on
        - System Reset Pin (includes reset by software)
      
      Fixes ARM-software/tf-issues#217
      
      Change-Id: I65ae0a0f7a46548b575900a5aac107d352b0e2cd
      08783e43
  19. 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
  20. 09 Jul, 2014 2 commits
    • Dan Handley's avatar
      Refactor fvp gic code to be a generic driver · 1e8c5c4f
      Dan Handley authored
      Refactor the FVP gic code in plat/fvp/fvp_gic.c to be a generic ARM
      GIC driver in drivers/arm/gic/arm_gic.c. Provide the platform
      specific inputs in the arm_gic_setup() function so that the driver
      has no explicit dependency on platform code.
      
      Provide weak implementations of the platform interrupt controller
      API in a new file, plat/common/plat_gic.c. These simply call through
      to the ARM GIC driver.
      
      Move the only remaining FVP GIC function, fvp_gic_init() to
      plat/fvp/aarch64/fvp_common.c and remove plat/fvp/fvp_gic.c
      
      Fixes ARM-software/tf-issues#182
      
      Change-Id: Iea82fe095fad62dd33ba9efbddd48c57717edd21
      1e8c5c4f
    • 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
  21. 01 Jul, 2014 2 commits
    • Sandrine Bailleux's avatar
      fvp: Properly detect the location of BL1 R/W data · 60633799
      Sandrine Bailleux authored
      There was already a rudimentary mechanism to detect whether BL1
      R/W data was loaded at the top or bottom of memory. Basically,
       - either BL1 was loaded at the very end of the trusted RAM
       - in all other cases BL1 was considered sitting at the bottom of
         the memory and the memory usage structure was updated accordingly,
         potentially resulting in critical memory waste.
      For instance, if BL1 R/W base address was set to
      (TZRAM_END - 4096 - bl1_size), it would virtually occupy the whole
      memory.
      
      This patch improves the mechanism to detect the location of BL1
      to avoid such scenarios.
      
      Change-Id: I224a9edf0fe8d34208545d84b28b63f2bb830d03
      60633799
    • Sandrine Bailleux's avatar
      Remove concept of top/bottom image loading · 8f55dfb4
      Sandrine Bailleux authored
      This concept is no longer required since we now support loading of
      images at fixed addresses only.
      
      The image loader now automatically detects the position of the image
      inside the current memory layout and updates the layout such that
      memory fragmentation is minimised.
      
      The 'attr' field of the meminfo data structure, which used to hold
      the bottom/top loading information, has been removed. Also the 'next'
      field has been removed as it wasn't used anywhere.
      
      The 'init_bl2_mem_layout()' function has been moved out of common
      code and put in BL1-specific code. It has also been renamed into
      'bl1_init_bl2_mem_layout'.
      
      Fixes ARM-software/tf-issues#109
      
      Change-Id: I3f54642ce7b763d5ee3b047ad0ab59eabbcf916d
      8f55dfb4
  22. 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