1. 28 Jul, 2014 4 commits
    • danh-arm's avatar
      Merge pull request #170 from achingupta/ag/tf-issues#226 · 9fd41277
      danh-arm authored
      Simplify management of SCTLR_EL3 and SCTLR_EL1
      9fd41277
    • danh-arm's avatar
      Merge pull request #169 from achingupta/ag/tf-issues#198 · d9b1128b
      danh-arm authored
      Ag/tf issues#198
      d9b1128b
    • Achin Gupta's avatar
      Simplify management of SCTLR_EL3 and SCTLR_EL1 · ec3c1003
      Achin Gupta authored
      This patch reworks the manner in which the M,A, C, SA, I, WXN & EE bits of
      SCTLR_EL3 & SCTLR_EL1 are managed. The EE bit is cleared immediately after reset
      in EL3. The I, A and SA bits are set next in EL3 and immediately upon entry in
      S-EL1. These bits are no longer managed in the blX_arch_setup() functions. They
      do not have to be saved and restored either. The M, WXN and optionally the C
      bit are set in the enable_mmu_elX() function. This is done during both the warm
      and cold boot paths.
      
      Fixes ARM-software/tf-issues#226
      
      Change-Id: Ie894d1a07b8697c116960d858cd138c50bc7a069
      ec3c1003
    • 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
  2. 25 Jul, 2014 6 commits
  3. 19 Jul, 2014 3 commits
    • Achin Gupta's avatar
      Remove coherent stack usage from the warm boot path · b51da821
      Achin Gupta authored
      This patch uses stacks allocated in normal memory to enable the MMU early in the
      warm boot path thus removing the dependency on stacks allocated in coherent
      memory. Necessary cache and stack maintenance is performed when a cpu is being
      powered down and up. This avoids any coherency issues that can arise from
      reading speculatively fetched stale stack memory from another CPUs cache. These
      changes affect the warm boot path in both BL3-1 and BL3-2.
      
      The EL3 system registers responsible for preserving the MMU state are not saved
      and restored any longer. Static values are used to program these system
      registers when a cpu is powered on or resumed from suspend.
      
      Change-Id: I8357e2eb5eb6c5f448492c5094b82b8927603784
      b51da821
    • 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
    • Achin Gupta's avatar
      Remove coherent stack usage from the cold boot path · 754a2b7a
      Achin Gupta authored
      This patch reworks the cold boot path across the BL1, BL2, BL3-1 and BL3-2 boot
      loader stages to not use stacks allocated in coherent memory for early platform
      setup and enabling the MMU. Stacks allocated in normal memory are used instead.
      
      Attributes for stack memory change from nGnRnE when the MMU is disabled to
      Normal WBWA Inner-shareable when the MMU and data cache are enabled. It is
      possible for the CPU to read stale stack memory after the MMU is enabled from
      another CPUs cache. Hence, it is unsafe to turn on the MMU and data cache while
      using normal stacks when multiple CPUs are a part of the same coherency
      domain. It is safe to do so in the cold boot path as only the primary cpu
      executes it. The secondary cpus are in a quiescent state.
      
      This patch does not remove the allocation of coherent stack memory. That is done
      in a subsequent patch.
      
      Change-Id: I12c80b7c7ab23506d425c5b3a8a7de693498f830
      754a2b7a
  4. 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
  5. 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
  6. 11 Jul, 2014 4 commits
  7. 10 Jul, 2014 6 commits
    • Sandrine Bailleux's avatar
      Add support for BL3-0 image · 93d81d64
      Sandrine Bailleux authored
       - Add support for loading a BL3-0 image in BL2. Information about
         memory extents is populated by platform-specific code. Subsequent
         handling of BL3-0 is also platform specific.
         The BL2 main function has been broken down to improve readability.
         The BL3-2 image is now loaded before the BL3-3 image to align with
         the boot flow.
      
       - Build system: Add support for specifying a BL3-0 image that will be
         included into the FIP image.
      
       - IO FIP driver: Add support for identifying a BL3-0 image inside a
         FIP image.
      
       - Update the documentation to reflect the above changes.
      
      Change-Id: I067c184afd52ccaa86569f13664757570c86fc48
      93d81d64
    • 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
    • danh-arm's avatar
      Merge pull request #157 from sandrine-bailleux/sb/tf-issue-109 · 6a223156
      danh-arm authored
      TF issue 109
      6a223156
    • danh-arm's avatar
      Merge pull request #146 from danh-arm/dh/refactor-fvp-gic · 3fc938b5
      danh-arm authored
      Refactor fvp config and gic code
      3fc938b5
    • danh-arm's avatar
      Merge pull request #161 from danh-arm/lm/calc-tcr-bits · 06bd0262
      danh-arm authored
      Calculate TCR bits based on VA and PA
      06bd0262
    • Juan Castillo's avatar
      Allow FP register context to be optional at build time · 0f21c547
      Juan Castillo authored
      CTX_INCLUDE_FPREGS make variable allows us to include or exclude FP
      registers from context structure, in case FP is not used by TSPD.
      
      Fixes ARM-software/tf-issues#194
      
      Change-Id: Iee41af382d691340c7ae21830ad1bbf95dad1f4b
      0f21c547
  8. 09 Jul, 2014 3 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
    • Lin Ma's avatar
      Calculate TCR bits based on VA and PA · 73ad2572
      Lin Ma authored
      Currently the TCR bits are hardcoded in xlat_tables.c. In order to
      map higher physical address into low virtual address, the TCR bits
      need to be configured accordingly.
      
      This patch is to save the max VA and PA and calculate the TCR.PS/IPS
      and t0sz bits in init_xlat_tables function.
      
      Change-Id: Ia7a58e5372b20200153057d457f4be5ddbb7dae4
      73ad2572
  9. 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
  10. 27 Jun, 2014 3 commits
  11. 26 Jun, 2014 2 commits
  12. 25 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Remove current CPU mpidr from PSCI common code · 56378aa6
      Andrew Thoelke authored
      Many of the interfaces internal to PSCI pass the current CPU
      MPIDR_EL1 value from function to function. This is not required,
      and with inline access to the system registers is less efficient
      than requiring the code to read that register whenever required.
      
      This patch remove the mpidr parameter from the affected interfaces
      and reduces code in FVP BL3-1 size by 160 bytes.
      
      Change-Id: I16120a7c6944de37232016d7e109976540775602
      56378aa6
  13. 24 Jun, 2014 4 commits