1. 20 Jul, 2017 1 commit
    • Soby Mathew's avatar
      Resize the BL2 size limit for Juno · 6c401f31
      Soby Mathew authored
      
      
      Recent patches to reduce the memory footprint of BL images have
      resulted in saving several pages of memory. This patch reduces
      the BL2 size limit by 20KB for Juno when ARM_BOARD_OPTIMISE_MEM=1
      so that more free space can be freed up for Trusted OS (BL32). Also
      SCP_BL2/SCP_BL2U size is now restricted to 80K.
      
      Change-Id: I1573d7a34e24d15e4abce8a14da40dbb5dc81e37
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      6c401f31
  2. 28 Jun, 2017 1 commit
    • Soby Mathew's avatar
      ARM plat changes to enable CryptoCell integration · e60f2af9
      Soby Mathew authored
      
      
      This patch makes the necessary changes to enable ARM platform to
      successfully integrate CryptoCell during Trusted Board Boot. The
      changes are as follows:
      
      * A new build option `ARM_CRYPTOCELL_INTEG` is introduced to select
        the CryptoCell crypto driver for Trusted Board boot.
      
      * The TrustZone filter settings for Non Secure DRAM is modified
        to allow CryptoCell to read this memory. This is required to
        authenticate BL33 which is loaded into the Non Secure DDR.
      
      * The CSS platforms are modified to use coherent stacks in BL1 and BL2
        when CryptoCell crypto is selected. This is because CryptoCell makes
        use of DMA to transfer data and the CryptoCell SBROM library allocates
        buffers on the stack during signature/hash verification.
      
      Change-Id: I1e6f6dcd1899784f1edeabfa2a9f279bbfb90e31
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      e60f2af9
  3. 05 Jun, 2017 1 commit
  4. 03 May, 2017 1 commit
  5. 20 Apr, 2017 1 commit
  6. 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
  7. 14 Dec, 2016 1 commit
  8. 21 Sep, 2016 1 commit
    • 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
  9. 25 Jul, 2016 1 commit
    • Antonio Nino Diaz's avatar
      ARM platforms: Define common image sizes · 0289970d
      Antonio Nino Diaz authored
      Compile option `ARM_BOARD_OPTIMISE_MMAP` has been renamed to
      `ARM_BOARD_OPTIMISE_MEM` because it now applies not only to defines
      related to the translation tables but to the image size as well.
      
      The defines `PLAT_ARM_MAX_BL1_RW_SIZE`, `PLAT_ARM_MAX_BL2_SIZE` and
      `PLAT_ARM_MAX_BL31_SIZE` have been moved to the file board_arm_def.h.
      This way, ARM platforms no longer have to set their own values if
      `ARM_BOARD_OPTIMISE_MEM=0` and they can specify optimized values
      otherwise. The common sizes have been set to the highest values used
      for any of the current build configurations.
      
      This is needed because in some build configurations some images are
      running out of space. This way there is a common set of values known
      to work for all of them and it can be optimized for each particular
      platform if needed.
      
      The space reserved for BL2 when `TRUSTED_BOARD_BOOT=0` has been
      increased. This is needed because when memory optimisations are
      disabled the values for Juno of `PLAT_ARM_MMAP_ENTRIES` and
      `MAX_XLAT_TABLES` are higher. If in this situation the code is
      compiled in debug mode and with "-O0", the code won't fit.
      
      Change-Id: I70a3d8d3a0b0cad1d6b602c01a7ea334776e718e
      0289970d
  10. 22 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Rationalise MMU and Page table related constants on ARM platforms · c64a0448
      Vikram Kanigiri authored
      `board_arm_def.h` contains multiple definitions of
      `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for
      memory usage depending upon the chosen build configuration. To ease
      maintenance of these constants, this patch replaces their multiple
      definitions with a single set of definitions that will work on all ARM
      platforms.
      
      Platforms can override the defaults with optimal values by enabling the
      `ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in
      the Juno ADP port.
      
      Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate
      future ARM platforms.
      
      Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
      c64a0448
  11. 19 Feb, 2016 1 commit
    • Soby Mathew's avatar
      Allow multi cluster topology definitions for ARM platforms · 0108047a
      Soby Mathew authored
      The common topology description helper funtions and macros for
      ARM Standard platforms assumed a dual cluster system. This is not
      flexible enough to scale to multi cluster platforms. This patch does
      the following changes for more flexibility in defining topology:
      
      1. The `plat_get_power_domain_tree_desc()` definition is moved from
         `arm_topology.c` to platform specific files, that is `fvp_topology.c`
         and `juno_topology.c`. Similarly the common definition of the porting
         macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform
         specific `platform_def.h` header.
      
      2. The ARM common layer porting macros which were dual cluster specific
         are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced
         which must be defined by each ARM standard platform.
      
      3. A new mandatory ARM common layer porting API
         `plat_arm_get_cluster_core_count()` is introduced to enable the common
         implementation of `arm_check_mpidr()` to validate MPIDR.
      
      4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been
         introduced which allows the user to specify the cluster count to be
         used to build the topology tree within Trusted Firmare. This enables
         Trusted Firmware to be built for multi cluster FVP models.
      
      Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
      0108047a
  12. 15 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Support for varying BOM/SCPI protocol base addresses in ARM platforms · 8e083ecd
      Vikram Kanigiri authored
      Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address
      for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To
      cater for future ARM platforms this is made platform specific.
      Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made
      platform specific.
      
      Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
      8e083ecd
  13. 11 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Re-factor definition of some macros on ARM platforms · ecf70f7b
      Vikram Kanigiri authored
      This patch moves the definition of some macros used only on
      ARM platforms from common headers to platform specific headers.
      It also forces all ARM standard platforms to have distinct
      definitions (even if they are usually the same).
       1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been
           moved from `css_def.h` to `platform_def.h`.
       2. `MHU_BASE` used in CSS platforms is moved from common css_def.h
          to platform specific header `platform_def.h` on Juno and
          renamed as `PLAT_ARM_MHU_BASE`.
       3. To cater for different sizes of BL images, new macros like
          `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All
          ARM platforms need to define them for each image.
      
      Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
      ecf70f7b
  14. 09 Dec, 2015 1 commit
    • 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
  15. 30 Oct, 2015 1 commit
    • Soby Mathew's avatar
      CSS: Implement topology support for System power domain · 5f3a6030
      Soby Mathew authored
      This patch implements the necessary topology changes for supporting
      system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and
      PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform
      specific. In addition, the `arm_power_domain_tree_desc[]` and
      `arm_pm_idle_states[]` are modified to support the system power domain
      at level 2. With this patch, even though the power management operations
      involving the system power domain will not return any error, the platform
      layer will silently ignore any operations to the power domain. The actual
      power management support for the system power domain will be added later.
      
      Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
      5f3a6030
  16. 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
  17. 28 Apr, 2015 2 commits
    • Dan Handley's avatar
      Move Juno port to plat/arm/board/juno · 85135283
      Dan Handley authored
      Move the Juno port from plat/juno to plat/arm/board/juno. Also rename
      some of the files so they are consistently prefixed with juno_.
      Update the platform makefiles accordingly.
      
      Change-Id: I0af6cb52a5fee7ef209107a1188b76a3c33a2a9f
      85135283
    • Dan Handley's avatar
      Migrate Juno port to use common code · f8b0b22a
      Dan Handley authored
      Major update to the Juno 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 move the ARM SoC specific security setup (i.e. NIC-400 and PCIe
      initialization) from BL1 to `plat_arm_security_setup()` in BL2,
      where the other security setup is done.
      
      Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
      f8b0b22a
  18. 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
  19. 12 Feb, 2015 2 commits
    • Soby Mathew's avatar
      Export maximum affinity using PLATFORM_MAX_AFFLVL macro · 8c32bc26
      Soby Mathew authored
      This patch removes the plat_get_max_afflvl() platform API
      and instead replaces it with a platform macro PLATFORM_MAX_AFFLVL.
      This is done because the maximum affinity level for a platform
      is a static value and it is more efficient for it to be defined
      as a platform macro.
      
      NOTE: PLATFORM PORTS NEED TO BE UPDATED ON MERGE OF THIS COMMIT
      
      Fixes ARM-Software/tf-issues#265
      
      Change-Id: I31d89b30c2ccda30d28271154d869060d50df7bf
      8c32bc26
    • 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
  20. 28 Jan, 2015 3 commits
    • Juan Castillo's avatar
      TBB: authenticate BL3-x images and certificates · dec840af
      Juan Castillo authored
      This patch adds support to authenticate the Trusted Key certificate
      and the BL3-x certificates and images at BL2.
      
      Change-Id: I69a8c13a14c8da8b75f93097d3a4576aed71c5dd
      dec840af
    • Juan Castillo's avatar
      TBB: authenticate BL2 image and certificate · 01df3c14
      Juan Castillo authored
      This patch adds support to authenticate the BL2 content certificate
      and image using the authentication module in BL1.
      
      The FIP driver has been extended to include the BL2 certificate
      UUID.
      
      FVP and Juno ports include the BL2 certificate FIP file
      definition.
      
      Change-Id: I32680e9bd123c8db4a4193c14448c9b32b0e9325
      01df3c14
    • Juan Castillo's avatar
      TBB: add PolarSSL based authentication module · db6071c9
      Juan Castillo authored
      This patch implements an authentication module based on the
      PolarSSL library (v1.3.9) to verify the Chain of Trust when
      Trusted Boot is enabled.
      
      PolarSSL sources must be fetched separately. The POLARSSL_DIR
      build option may be used to indicate the path to the PolarSSL
      main directory (this directory must contain the 'include' and
      'library' subdirectories).
      
      To be able to build PolarSSL sources as a part of the Trusted
      Firmware build process, the DISABLE_PEDANTIC flag in polarssl.mk
      will tell the build system to remove the -pedantic option from
      the CFLAGS.
      
      Inclusion of PolarSSL increases the memory requirements of the BL1
      and BL2 images. The following are the changes made to the FVP and
      Juno platforms to cater for this when TRUSTED_BOARD_BOOT is
      defined:
      
      Changes on FVP:
      
        - BL1 and BL2 stacks have been increased to 4 KB
        - BL1(rw) section has been increased to 32 KB.
        - BL2 memory region has been increased to 112 KB
      
      Changes on Juno:
      
        - BL1 and BL2 stacks have been increased to 4 KB
        - BL1(rw) section has been increased to 32 KB.
        - Trusted ROM region in Flash has been increased to 128 KB.
        - BL2 memory region has been increased to 116 KB
      
      Change-Id: Ie87d80d43408eb6239c4acd0ec5ab2120e4e9e80
      db6071c9
  21. 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
  22. 12 Jan, 2015 1 commit
    • Juan Castillo's avatar
      Juno: Add support for image overlaying in Trusted SRAM · 1217d28d
      Juan Castillo authored
      This patch allows the BL3-1 NOBITS section to overlap the BL1 R/W
      section since the former will always be used after the latter.
      Similarly, the BL3-2 NOBITS section can overlay the BL2 image
      when BL3-2 is loaded in Trusted SRAM.
      
      Due to the current size of the images, there is no actual overlap.
      Nevertheless, this reorganization may help to optimise the Trusted
      SRAM usage when the images size grows.
      
      Note that because BL3-1 NOBITS section is allowed to overlap the
      BL1 R/W section, BL1 global variables will remain valid only until
      execution reaches the BL3-1 entry point during a cold boot.
      
      Documentation updated accordingly.
      
      Fixes ARM-software/tf-issues#254
      
      Change-Id: Id538f4d1c7f1f7858108280fd7b97e138572b879
      1217d28d
  23. 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
  24. 21 Aug, 2014 2 commits
    • Sandrine Bailleux's avatar
      Juno: Add support for Test Secure-EL1 Payload · edfda10a
      Sandrine Bailleux authored
      This patch implements the TSP on Juno. It executes from on-chip Trusted
      SRAM.
      
      Also, the other bootloader images (i.e. BL1 R/W, BL2 and BL3-1) have
      been moved around. The reason is, although there was enough space
      overall to store the TSP in SRAM, there was no contiguous free chunk
      of SRAM big enough to hold it.
      
      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 allocations
         since they will most probably grow the most.
      
      This patch also adds instruction synchronization barriers around the code which
      handles the timer interrupt in the TSP. This ensures that the interrupt is not
      acknowledged after or EOIed before it is deactivated at the peripheral.
      
      Change-Id: I1c5b51858700027ee283ac85d18e06863a27c72e
      edfda10a
    • 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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