1. 24 May, 2017 1 commit
  2. 03 May, 2017 1 commit
  3. 20 Apr, 2017 1 commit
    • Yatharth Kochar's avatar
      Changes to support execution in AArch32 state for JUNO · 07570d59
      Yatharth Kochar authored
      
      
      Following steps are required to boot JUNO in AArch32 state:
      1> BL1, in AArch64 state, loads BL2.
      2> BL2, in AArch64 state, initializes DDR.
        Loads SP_MIN & BL33 (AArch32 executable)images.
        Calls RUN_IMAGE SMC to go back to BL1.
      3> BL1 writes AArch32 executable opcodes, to load and branch
        at the entrypoint address of SP_MIN, at HI-VECTOR address and
        then request for warm reset in AArch32 state using RMR_EL3.
      
      This patch makes following changes to facilitate above steps:
      * Added assembly function to carry out step 3 above.
      * Added region in TZC that enables Secure access to the
        HI-VECTOR(0xFFFF0000) address space.
      * AArch32 image descriptor is used, in BL2, to load
        SP_MIN and BL33 AArch32 executable images.
      
      A new flag `JUNO_AARCH32_EL3_RUNTIME` is introduced that
      controls above changes. By default this flag is disabled.
      
      NOTE: BL1 and BL2 are not supported in AArch32 state for JUNO.
      
      Change-Id: I091d56a0e6d36663e6d9d2bb53c92c672195d1ec
      Signed-off-by: default avatarYatharth Kochar <yatharth.kochar@arm.com>
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      07570d59
  4. 06 Feb, 2017 1 commit
    • Douglas Raillard's avatar
      Replace some memset call by zeromem · 32f0d3c6
      Douglas Raillard authored
      
      
      Replace all use of memset by zeromem when zeroing moderately-sized
      structure by applying the following transformation:
      memset(x, 0, sizeof(x)) => zeromem(x, sizeof(x))
      
      As the Trusted Firmware is compiled with -ffreestanding, it forbids the
      compiler from using __builtin_memset and forces it to generate calls to
      the slow memset implementation. Zeromem is a near drop in replacement
      for this use case, with a more efficient implementation on both AArch32
      and AArch64.
      
      Change-Id: Ia7f3a90e888b96d056881be09f0b4d65b41aa79e
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      32f0d3c6
  5. 18 Jan, 2017 2 commits
    • Masahiro Yamada's avatar
      Move BL_COHERENT_RAM_BASE/END defines to common_def.h · 47497053
      Masahiro Yamada authored
      
      
      We have lots of duplicated defines (and comment blocks too).
      Move them to include/plat/common/common_def.h.
      
      While we are here, suffix the end address with _END instead of
      _LIMIT.  The _END is a better fit to indicate the linker-derived
      real end address.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      47497053
    • Masahiro Yamada's avatar
      Use *_END instead of *_LIMIT for linker derived end addresses · ecdc898d
      Masahiro Yamada authored
      
      
      The usage of _LIMIT seems odd here, so rename as follows:
        BL_CODE_LIMIT     --> BL_CODE_END
        BL_RO_DATA_LIMIT  --> BL_RO_DATA_END
        BL1_CODE_LIMIT    --> BL1_CODE_END
        BL1_RO_DATA_LIMIT --> BL1_RO_DATA_END
      
      Basically, we want to use _LIMIT and _END properly as follows:
        *_SIZE + *_MAX_SIZE = *_LIMIT
        *_SIZE + *_SIZE     = *_END
      
      The _LIMIT is generally defined by platform_def.h to indicate the
      platform-dependent memory constraint.  So, its typical usage is
        ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.")
      in a linker script.
      
      On the other hand, _END is used to indicate the end address of the
      compiled image, i.e. we do not know it until the image is linked.
      
      Here, all of these macros belong to the latter, so should be
      suffixed with _END.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      ecdc898d
  6. 21 Sep, 2016 2 commits
    • Yatharth Kochar's avatar
      AArch32: Add ARM platform changes in BL2 · 6fe8aa2f
      Yatharth Kochar authored
      This patch adds ARM platform changes in BL2 for AArch32 state.
      It instantiates a descriptor array for ARM platforms describing
      image and entrypoint information for `SCP_BL2`, `BL32` and `BL33`.
      It also enables building of BL2 for ARCH=aarch32.
      
      Change-Id: I60dc7a284311eceba401fc789311c50ac746c51e
      6fe8aa2f
    • Yatharth Kochar's avatar
      ARM platform changes for new version of image loading · a8aa7fec
      Yatharth Kochar authored
      This patch adds changes in ARM platform code to use new
      version of image loading.
      
      Following are the major changes:
        -Refactor the signatures for bl31_early_platform_setup()
         and arm_bl31_early_platform_setup() function to use
         `void *` instead of `bl31_params_t *`.
        -Introduce `plat_arm_bl2_handle_scp_bl2()` to handle
         loading of SCP_BL2 image from BL2.
        -Remove usage of reserve_mem() function from
         `arm_bl1_early_platform_setup()`
        -Extract BL32 & BL33 entrypoint info, from the link list
         passed by BL2, in `arm_bl31_early_platform_setup()`
        -Provides weak definitions for following platform functions:
           plat_get_bl_image_load_info
           plat_get_next_bl_params
           plat_flush_next_bl_params
           bl2_plat_handle_post_image_load
        -Instantiates a descriptor array for ARM platforms
         describing image and entrypoint information for
         `SCP_BL2`, `BL31`, `BL32` and `BL33` images.
      
      All the above changes are conditionally compiled using the
      `LOAD_IMAGE_V2` flag.
      
      Change-Id: I5e88b9785a3df1a2b2bbbb37d85b8e353ca61049
      a8aa7fec
  7. 08 Jul, 2016 2 commits
    • Sandrine Bailleux's avatar
      ARM platforms: Add support for SEPARATE_CODE_AND_RODATA · 0af559a8
      Sandrine Bailleux authored
      The arm_setup_page_tables() function used to expect a single set of
      addresses defining the extents of the whole read-only section, code
      and read-only data mixed up, which was mapped as executable.
      
      This patch changes this behaviour. arm_setup_page_tables() now
      expects 2 separate sets of addresses:
      
       - the extents of the code section;
       - the extents of the read-only data section.
      
      The code is mapped as executable, whereas the data is mapped as
      execute-never. New #defines have been introduced to identify the
      extents of the code and the read-only data section. Given that
      all BL images except BL1 share the same memory layout and linker
      script structure, these #defines are common across these images.
      The slight memory layout differences in BL1 have been handled by
      providing values specific to BL1.
      
      Note that this patch also affects the Xilinx platform port, which
      uses the arm_setup_page_tables() function. It has been updated
      accordingly, such that the memory mappings on this platform are
      unchanged. This is achieved by passing null values as the extents
      of the read-only data section so that it is ignored. As a result,
      the whole read-only section is still mapped as executable.
      
      Fixes ARM-software/tf-issues#85
      
      Change-Id: I1f95865c53ce6e253a01286ff56e0aa1161abac5
      0af559a8
    • 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
  8. 08 Apr, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Remove BL32_BASE when building without SPD for FVP · 81d139d5
      Antonio Nino Diaz authored
      Previously, when building TF without SPD support, BL2 tried to load a
      BL32 image from the FIP and fails to find one, which resulted on
      warning messages on the console. Even if there is a BL32 image in the
      FIP it shouldn't be loaded because there is no way to transfer
      control to the Secure Payload without SPD support.
      
      The Makefile has been modified to pass a define of the form
      SPD_${SPD} to the source code the same way it's done for PLAT. The
      define SPD_none is then used to undefine BL32_BASE when BL32 is not
      used to prevent BL2 from trying to load a BL32 image and failing,
      thus removing the warning messages mentioned above.
      
      Fixes ARM-software/tf-issues#287
      
      Change-Id: Ifeb6f1c26935efb76afd353fea88e87ba09e9658
      81d139d5
  9. 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
  10. 14 Dec, 2015 2 commits
    • Juan Castillo's avatar
      Remove dashes from image names: 'BL3-x' --> 'BL3x' · d178637d
      Juan Castillo authored
      This patch removes the dash character from the image name, to
      follow the image terminology in the Trusted Firmware Wiki page:
      
          https://github.com/ARM-software/arm-trusted-firmware/wiki
      
      Changes apply to output messages, comments and documentation.
      
      non-ARM platform files have been left unmodified.
      
      Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
      d178637d
    • Juan Castillo's avatar
      Replace all SCP FW (BL0, BL3-0) references · f59821d5
      Juan Castillo authored
      This patch replaces all references to the SCP Firmware (BL0, BL30,
      BL3-0, bl30) with the image terminology detailed in the TF wiki
      (https://github.com/ARM-software/arm-trusted-firmware/wiki):
      
          BL0          -->  SCP_BL1
          BL30, BL3-0  -->  SCP_BL2
          bl30         -->  scp_bl2
      
      This change affects code, documentation, build system, tools and
      platform ports that load SCP firmware. ARM plaforms have been
      updated to the new porting API.
      
      IMPORTANT: build option to specify the SCP FW image has changed:
      
          BL30 --> SCP_BL2
      
      IMPORTANT: This patch breaks compatibility for platforms that use BL2
      to load SCP firmware. Affected platforms must be updated as follows:
      
          BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID
          BL30_BASE --> SCP_BL2_BASE
          bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo()
          bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2()
      
      Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
      f59821d5
  11. 28 Apr, 2015 1 commit
    • Dan Handley's avatar
      Add common ARM and CSS platform code · b4315306
      Dan Handley authored
      This major change pulls out the common functionality from the
      FVP and Juno platform ports into the following categories:
      
      *   (include/)plat/common. Common platform porting functionality that
      typically may be used by all platforms.
      
      *   (include/)plat/arm/common. Common platform porting functionality
      that may be used by all ARM standard platforms. This includes all
      ARM development platforms like FVP and Juno but may also include
      non-ARM-owned platforms.
      
      *   (include/)plat/arm/board/common. Common platform porting
      functionality for ARM development platforms at the board
      (off SoC) level.
      
      *   (include/)plat/arm/css/common. Common platform porting
      functionality at the ARM Compute SubSystem (CSS) level. Juno
      is an example of a CSS-based platform.
      
      *   (include/)plat/arm/soc/common. Common platform porting
      functionality at the ARM SoC level, which is not already defined
      at the ARM CSS level.
      
      No guarantees are made about the backward compatibility of
      functionality provided in (include/)plat/arm.
      
      Also remove any unnecessary variation between the ARM development
      platform ports, including:
      
      *   Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the
      Juno implementation, which copies the information from BL2 memory
      instead of expecting it to persist in shared memory.
      
      *   Unify the TZC configuration. There is no need to add a region
      for SCP in Juno; it's enough to simply not allow any access to
      this reserved region. Also set region 0 to provide no access by
      default instead of assuming this is the case.
      
      *   Unify the number of memory map regions required for ARM
      development platforms, although the actual ranges mapped for each
      platform may be different. For the FVP port, this reduces the
      mapped peripheral address space.
      
      These latter changes will only be observed when the platform ports
      are migrated to use the new common platform code in subsequent
      patches.
      
      Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
      b4315306
  12. 27 Apr, 2015 1 commit
    • Dan Handley's avatar
      Remove use of PLATFORM_CACHE_LINE_SIZE · ce4c820d
      Dan Handley authored
      The required platform constant PLATFORM_CACHE_LINE_SIZE is
      unnecessary since CACHE_WRITEBACK_GRANULE effectively provides the
      same information. CACHE_WRITEBACK_GRANULE is preferred since this
      is an architecturally defined term and allows comparison with the
      corresponding hardware register value.
      
      Replace all usage of PLATFORM_CACHE_LINE_SIZE with
      CACHE_WRITEBACK_GRANULE.
      
      Also, add a runtime assert in BL1 to check that the provided
      CACHE_WRITEBACK_GRANULE matches the value provided in CTR_EL0.
      
      Change-Id: If87286be78068424217b9f3689be358356500dcd
      ce4c820d
  13. 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
  14. 14 Oct, 2014 1 commit
    • Juan Castillo's avatar
      Juno: Reserve some DDR-DRAM for secure use · 740134e6
      Juan Castillo authored
      This patch configures the TrustZone Controller in Juno to split
      the 2GB DDR-DRAM memory at 0x80000000 into Secure and Non-Secure
      regions:
      
      - Secure DDR-DRAM: top 16 MB, except for the last 2 MB which are
        used by the SCP for DDR retraining
      - Non-Secure DDR-DRAM: remaining DRAM starting at base address
      
      Build option PLAT_TSP_LOCATION selects the location of the secure
      payload (BL3-2):
      
      - 'tsram' : Trusted SRAM (default option)
      - 'dram'  : Secure region in the DDR-DRAM (set by the TrustZone
                  controller)
      
      The MMU memory map has been updated to give BL2 permission to load
      BL3-2 into the DDR-DRAM secure region.
      
      Fixes ARM-software/tf-issues#233
      
      Change-Id: I6843fc32ef90aadd3ea6ac4c7f314f8ecbd5d07b
      740134e6
  15. 09 Oct, 2014 1 commit
    • Juan Castillo's avatar
      Juno: Use TZC-400 driver calls · ef538c6f
      Juan Castillo authored
      This patch replaces direct accesses to the TZC-400 registers by the
      appropiate calls to the generic driver available in the Trusted
      Firmware in order to initialize the TrustZone Controller.
      
      Functions related to the initialization of the secure memory,
      like the TZC-400 configuration, have been moved to a new file
      'plat_security.c'. This reorganization makes easier to set up
      the secure memory from any BL stage.
      
      TZC-400 initialization has been moved from BL1 to BL2 because BL1
      does not access the non-secure memory. It is BL2's responsibility
      to enable and configure the TZC-400 before loading the next BL
      images.
      
      In Juno, BL3-0 initializes some of the platform peripherals, like
      the DDR controller. Thus, BL3-0 must be loaded before configuring
      the TrustZone Controller. As a consequence, the IO layer
      initialization has been moved to early platform initialization.
      
      Fixes ARM-software/tf-issues#234
      
      Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
      ef538c6f
  16. 21 Aug, 2014 3 commits
    • 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
    • Juan Castillo's avatar
      Juno: Read primary CPU MPID from SCC GPR_1 · 38af430a
      Juan Castillo authored
      This patch removes the PRIMARY_CPU definition hardcoded in the
      Juno port. Instead, the primary CPU is obtained at runtime by
      reading the SCC General Purpose Register 1 (GPR_1), whose value
      is copied by the SCP into shared memory during the boot process.
      
      Change-Id: I3981daa92eb7142250712274cf7f655b219837f5
      38af430a
    • Sandrine Bailleux's avatar
      Juno: Implement initial platform port · 01b916bf
      Sandrine Bailleux authored
      This patch adds the initial port of the ARM Trusted Firmware on the Juno
      development platform. This port does not support a BL3-2 image or any PSCI APIs
      apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected
      Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno
      platform errata (Defect id 831273).
      
      Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
      01b916bf
  17. 14 Aug, 2014 1 commit
    • 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
  18. 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
  19. 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
  20. 01 Jul, 2014 1 commit
    • 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
  21. 24 Jun, 2014 2 commits
  22. 05 Jun, 2014 1 commit
  23. 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
  24. 23 May, 2014 3 commits
    • Dan Handley's avatar
      Rename FVP specific files and functions · 17a387ad
      Dan Handley authored
      FVP specific files and functions containing the word "plat" have been
      renamed to use the word "fvp" to distinguish them from the common
      platform functionality and porting functions.
      
      Change-Id: I39f9673dab3ee9c74bd18b3e62b7c21027232f7d
      17a387ad
    • Dan Handley's avatar
      Move BL porting functions into platform.h · dec5e0d1
      Dan Handley authored
      Some platform porting functions were in BL specific header files.
      These have been moved to platform.h so that all porting functions
      are in the same place. The functions are now grouped by BL.
      Obsolete BL headers files have been removed.
      
      Also, the weak declaration of the init_bl2_mem_layout() function
      has been moved out the header file and into the source file
      (bl_common.c) using the more succinct #pragma syntax. This
      mitigates the risk of 2 weak definitions being created and the
      wrong one being picked up by the compiler.
      
      Change-Id: Ib19934939fd755f3e5a5a5bceec88da684308a83
      dec5e0d1
    • 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
  25. 22 May, 2014 7 commits
    • Sandrine Bailleux's avatar
      fvp: Move TSP from Secure DRAM to Secure SRAM · 53514b29
      Sandrine Bailleux authored
      The TSP used to execute from secure DRAM on the FVPs because there was
      not enough space in Trusted SRAM to fit it in. Thanks to recent RAM
      usage enhancements being implemented, we have made enough savings for
      the TSP to execute in SRAM.
      
      However, there is no contiguous free chunk of SRAM big enough to hold
      the TSP. Therefore, the different bootloader images need to be moved
      around to reduce memory fragmentation. This patch keeps the overall
      memory layout (i.e. keeping BL1 R/W at the bottom, BL2 at the top and
      BL3-1 in between) but moves the base addresses of all the bootloader
      images in such a way that:
       - memory fragmentation is reduced enough to fit BL3-2 in;
       - new base addresses are suitable for release builds as well as debug
         ones;
       - each image has a few extra kilobytes for future growth.
         BL3-1 and BL3-2 are the images which received the biggest slice
         of the cake since they will most probably grow the most.
      
      A few useful numbers for reference (valid at the time of this patch):
              |-----------------------|-------------------------------
              |  image size (debug)   |  extra space for the future
      --------|-----------------------|-------------------------------
      BL1 R/W |         20 KB         |            4 KB
      BL2     |         44 KB         |            4 KB
      BL3-1   |        108 KB         |           12 KB
      BL3-2   |         56 KB         |            8 KB
      --------|-----------------------|-------------------------------
      Total   |        228 KB         |           28 KB       = 256 KB
      --------|-----------------------|-------------------------------
      
      Although on FVPs the TSP now executes from Trusted SRAM by default,
      this patch keeps the option to execute it from Trusted DRAM. This is
      controlled by the build configuration 'TSP_RAM_LOCATION'.
      
      Fixes ARM-Software/tf-issues#81
      
      Change-Id: Ifb9ef2befa9a2d5ac0813f7f79834df7af992b94
      53514b29
    • Sandrine Bailleux's avatar
      TSP: Let the platform decide which secure memory to use · 2467f70f
      Sandrine Bailleux authored
      The TSP's linker script used to assume that the TSP would
      execute from secure DRAM. Although it is currently the case
      on FVPs, platforms are free to use any secure memory they wish.
      
      This patch introduces the flexibility to load the TSP into any
      secure memory. The platform code gets to specify the extents of
      this memory in the platform header file, as well as the BL3-2 image
      limit address. The latter definition allows to check in a generic way
      that the BL3-2 image fits in its bounds.
      
      Change-Id: I9450f2d8b32d74bd00b6ce57a0a1542716ab449c
      2467f70f
    • Juan Castillo's avatar
      Reserve some DDR DRAM for secure use on FVP platforms · 364daf93
      Juan Castillo authored
      TZC-400 is configured to set the last 16MB of DRAM1 as secure memory and
      the rest of DRAM as non-secure. Non-secure software must not attempt to
      access the 16MB secure area.
      
      Device tree files (sources and binaries) have been updated to match this
      configuration, removing that memory from the Linux physical memory map.
      
      To use UEFI and Linux with this patch, the latest version of UEFI and
      the updated device tree files are required. Check the user guide in the
      documentation for more details.
      
      Replaced magic numbers with #define for memory region definition in the
      platform security initialization function.
      
      Fixes ARM-software/tf-issues#149
      
      Change-Id: Ia5d070244aae6c5288ea0e6c8e89d92859522bfe
      364daf93
    • Vikram Kanigiri's avatar
      Add support for BL3-1 as a reset vector · dbad1bac
      Vikram Kanigiri authored
      This change adds optional reset vector support to BL3-1
      which means BL3-1 entry point can detect cold/warm boot,
      initialise primary cpu, set up cci and mail box.
      
      When using BL3-1 as a reset vector it is assumed that
      the BL3-1 platform code can determine the location of
      the BL3-2 images, or load them as there are no parameters
      that can be passed to BL3-1 at reset.
      
      It also fixes the incorrect initialisation of mailbox
      registers on the FVP platform
      
      This feature can be enabled by building the code with
      make variable RESET_TO_BL31 set as 1
      
      Fixes ARM-software/TF-issues#133
      Fixes ARM-software/TF-issues#20
      
      Change-Id: I4e23939b1c518614b899f549f1e8d412538ee570
      dbad1bac
    • Vikram Kanigiri's avatar
      Rework memory information passing to BL3-x images · 6871c5d3
      Vikram Kanigiri authored
      The issues addressed in this patch are:
      
      1. Remove meminfo_t from the common interfaces in BL3-x,
      expecting that platform code will find a suitable mechanism
      to determine the memory extents in these images and provide
      it to the BL3-x images.
      
      2. Remove meminfo_t and bl31_plat_params_t from all FVP BL3-x
      code as the images use link-time information to determine
      memory extents.
      
      meminfo_t is still used by common interface in BL1/BL2 for
      loading images
      
      Change-Id: I4e825ebf6f515b59d84dc2bdddf6edbf15e2d60f
      6871c5d3
    • Vikram Kanigiri's avatar
      Populate BL31 input parameters as per new spec · 4112bfa0
      Vikram Kanigiri authored
      This patch is based on spec published at
      https://github.com/ARM-software/tf-issues/issues/133
      
      It rearranges the bl31_args struct into
      bl31_params and bl31_plat_params which provide the
      information needed for Trusted firmware and platform
      specific data via x0 and x1
      
      On the FVP platform BL3-1 params and BL3-1 plat params
      and its constituents are stored at the start of TZDRAM.
      
      The information about memory availability and size for
      BL3-1, BL3-2 and BL3-3 is moved into platform specific data.
      
      Change-Id: I8b32057a3d0dd3968ea26c2541a0714177820da9
      4112bfa0
    • Vikram Kanigiri's avatar
      Rework handover interface between BL stages · 29fb905d
      Vikram Kanigiri authored
      This patch reworks the handover interface from: BL1 to BL2 and
      BL2 to BL3-1. It removes the raise_el(), change_el(), drop_el()
      and run_image() functions as they catered for code paths that were
      never exercised.
      BL1 calls bl1_run_bl2() to jump into BL2 instead of doing the same
      by calling run_image(). Similarly, BL2 issues the SMC to transfer
      execution to BL3-1 through BL1 directly. Only x0 and x1 are used
      to pass arguments to BL31. These arguments and parameters for
      running BL3-1 are passed through a reference to a
      'el_change_info_t' structure. They were being passed value in
      general purpose registers earlier.
      
      Change-Id: Id4fd019a19a9595de063766d4a66295a2c9307e1
      29fb905d