1. 08 Mar, 2017 1 commit
  2. 02 Mar, 2017 1 commit
  3. 05 Dec, 2016 1 commit
    • Jeenu Viswambharan's avatar
      Define and use no_ret macro where no return is expected · a806dad5
      Jeenu Viswambharan authored
      
      
      There are many instances in ARM Trusted Firmware where control is
      transferred to functions from which return isn't expected. Such jumps
      are made using 'bl' instruction to provide the callee with the location
      from which it was jumped to. Additionally, debuggers infer the caller by
      examining where 'lr' register points to. If a 'bl' of the nature
      described above falls at the end of an assembly function, 'lr' will be
      left pointing to a location outside of the function range. This misleads
      the debugger back trace.
      
      This patch defines a 'no_ret' macro to be used when jumping to functions
      from which return isn't expected. The macro ensures to use 'bl'
      instruction for the jump, and also, for debug builds, places a 'nop'
      instruction immediately thereafter (unless instructed otherwise) so as
      to leave 'lr' pointing within the function range.
      
      Change-Id: Ib34c69fc09197cfd57bc06e147cc8252910e01b0
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      a806dad5
  4. 14 Nov, 2016 1 commit
    • Douglas Raillard's avatar
      Cosmetic change to exception table · a6ef4393
      Douglas Raillard authored
      
      
      * Move comments on unhandled exceptions at the right place.
      * Reformat the existing comments to highlight the start of
        each block of 4 entries in the exception table to ease
        navigation (lines of dash reserved for head comments).
      * Reflow comments to 80 columns.
      
      Change-Id: I5ab88a93d0628af8e151852cb5b597eb34437677
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      a6ef4393
  5. 12 Oct, 2016 1 commit
    • dp-arm's avatar
      Add PMF instrumentation points in TF · 872be88a
      dp-arm authored
      
      
      In order to quantify the overall time spent in the PSCI software
      implementation, an initial collection of PMF instrumentation points
      has been added.
      
      Instrumentation has been added to the following code paths:
      
      - Entry to PSCI SMC handler.  The timestamp is captured as early
        as possible during the runtime exception and stored in memory
        before entering the PSCI SMC handler.
      
      - Exit from PSCI SMC handler.  The timestamp is captured after
        normal return from the PSCI SMC handler or if a low power state
        was requested it is captured in the bl31 warm boot path before
        return to normal world.
      
      - Entry to low power state.  The timestamp is captured before entry
        to a low power state which implies either standby or power down.
        As these power states are mutually exclusive, only one timestamp
        is defined to describe both.  It is possible to differentiate between
        the two power states using the PSCI STAT interface.
      
      - Exit from low power state.  The timestamp is captured after a standby
        or power up operation has completed.
      
      To calculate the number of cycles spent running code in Trusted Firmware
      one can perform the following calculation:
      
      (exit_psci - enter_psci) - (exit_low_pwr - enter_low_pwr).
      
      The resulting number of cycles can be converted to time given the
      frequency of the counter.
      
      Change-Id: Ie3b8f3d16409b6703747093b3a2d5c7429ad0166
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      872be88a
  6. 19 Jul, 2016 1 commit
    • Soby Mathew's avatar
      Introduce PSCI Library Interface · cf0b1492
      Soby Mathew authored
      This patch introduces the PSCI Library interface. The major changes
      introduced are as follows:
      
      * Earlier BL31 was responsible for Architectural initialization during cold
      boot via bl31_arch_setup() whereas PSCI was responsible for the same during
      warm boot. This functionality is now consolidated by the PSCI library
      and it does Architectural initialization via psci_arch_setup() during both
      cold and warm boots.
      
      * Earlier the warm boot entry point was always `psci_entrypoint()`. This was
      not flexible enough as a library interface. Now PSCI expects the runtime
      firmware to provide the entry point via `psci_setup()`. A new function
      `bl31_warm_entrypoint` is introduced in BL31 and the previous
      `psci_entrypoint()` is deprecated.
      
      * The `smc_helpers.h` is reorganized to separate the SMC Calling Convention
      defines from the Trusted Firmware SMC helpers. The former is now in a new
      header file `smcc.h` and the SMC helpers are moved to Architecture specific
      header.
      
      * The CPU context is used by PSCI for context initialization and
      restoration after power down (PSCI Context). It is also used by BL31 for SMC
      handling and context management during Normal-Secure world switch (SMC
      Context). The `psci_smc_handler()` interface is redefined to not use SMC
      helper macros thus enabling to decouple the PSCI context from EL3 runtime
      firmware SMC context. This enables PSCI to be integrated with other runtime
      firmware using a different SMC context.
      
      NOTE: With this patch the architectural setup done in `bl31_arch_setup()`
      is done as part of `psci_setup()` and hence `bl31_platform_setup()` will be
      invoked prior to architectural setup. It is highly unlikely that the platform
      setup will depend on architectural setup and cause any failure. Please be
      be aware of this change in sequence.
      
      Change-Id: I7f497a08d33be234bbb822c28146250cb20dab73
      cf0b1492
  7. 18 Jul, 2016 1 commit
    • Soby Mathew's avatar
      Introduce `el3_runtime` and `PSCI` libraries · 532ed618
      Soby Mathew authored
      This patch moves the PSCI services and BL31 frameworks like context
      management and per-cpu data into new library components `PSCI` and
      `el3_runtime` respectively. This enables PSCI to be built independently from
      BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant
      PSCI library sources and gets included by `bl31.mk`. Other changes which
      are done as part of this patch are:
      
      * The runtime services framework is now moved to the `common/` folder to
        enable reuse.
      * The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture
        specific folder.
      * The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder
        to `plat/common` folder. The original file location now has a stub which
        just includes the file from new location to maintain platform compatibility.
      
      Most of the changes wouldn't affect platform builds as they just involve
      changes to the generic bl1.mk and bl31.mk makefiles.
      
      NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT
      THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR
      MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION.
      
      Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86
      532ed618
  8. 26 May, 2016 1 commit
    • Sandrine Bailleux's avatar
      Introduce some helper macros for exception vectors · e0ae9fab
      Sandrine Bailleux authored
      This patch introduces some assembler macros to simplify the
      declaration of the exception vectors. It abstracts the section
      the exception code is put into as well as the alignments
      constraints mandated by the ARMv8 architecture. For all TF images,
      the exception code has been updated to make use of these macros.
      
      This patch also updates some invalid comments in the exception
      vector code.
      
      Change-Id: I35737b8f1c8c24b6da89b0a954c8152a4096fa95
      e0ae9fab
  9. 20 May, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Add 32 bit version of plat_get_syscnt_freq · d4486391
      Antonio Nino Diaz authored
      Added plat_get_syscnt_freq2, which is a 32 bit variant of the 64 bit
      plat_get_syscnt_freq. The old one has been flagged as deprecated.
      Common code has been updated to use this new version. Porting guide
      has been updated.
      
      Change-Id: I9e913544926c418970972bfe7d81ee88b4da837e
      d4486391
  10. 14 Apr, 2016 1 commit
    • Gerald Lejeune's avatar
      Dump platform-defined regs in crash reporting · 9ff67fa6
      Gerald Lejeune authored
      
      
      It is up to the platform to implement the new plat_crash_print_regs macro to
      report all relevant platform registers helpful for troubleshooting.
      
      plat_crash_print_regs merges or calls previously defined plat_print_gic_regs
      and plat_print_interconnect_regs macros for each existing platforms.
      
      NOTE: THIS COMMIT REQUIRES ALL PLATFORMS THAT ENABLE THE `CRASH_REPORTING`
      BUILD FLAG TO MIGRATE TO USE THE NEW `plat_crash_print_regs()` MACRO. BY
      DEFAULT, `CRASH_REPORTING` IS ENABLED IN DEBUG BUILDS FOR ALL PLATFORMS.
      
      Fixes: arm-software/tf-issues#373
      Signed-off-by: default avatarGerald Lejeune <gerald.lejeune@st.com>
      9ff67fa6
  11. 30 Mar, 2016 2 commits
    • Gerald Lejeune's avatar
      Add ISR_EL1 to crash report · 6b836cf9
      Gerald Lejeune authored
      
      
      Bring ISR bits definition as a mnemonic for troublershooters as well.
      Signed-off-by: default avatarGerald Lejeune <gerald.lejeune@st.com>
      6b836cf9
    • Gerald Lejeune's avatar
      Enable asynchronous abort exceptions during boot · adb4fcfb
      Gerald Lejeune authored
      
      
      Asynchronous abort exceptions generated by the platform during cold boot are
      not taken in EL3 unless SCR_EL3.EA is set.
      
      Therefore EA bit is set along with RES1 bits in early BL1 and BL31 architecture
      initialisation. Further write accesses to SCR_EL3 preserve these bits during
      cold boot.
      
      A build flag controls SCR_EL3.EA value to keep asynchronous abort exceptions
      being trapped by EL3 after cold boot or not.
      
      For further reference SError Interrupts are also known as asynchronous external
      aborts.
      
      On Cortex-A53 revisions below r0p2, asynchronous abort exceptions are taken in
      EL3 whatever the SCR_EL3.EA value is.
      
      Fixes arm-software/tf-issues#368
      Signed-off-by: default avatarGerald Lejeune <gerald.lejeune@st.com>
      adb4fcfb
  12. 14 Mar, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Remove all non-configurable dead loops · 1c3ea103
      Antonio Nino Diaz authored
      Added a new platform porting function plat_panic_handler, to allow
      platforms to handle unexpected error situations. It must be
      implemented in assembly as it may be called before the C environment
      is initialized. A default implementation is provided, which simply
      spins.
      
      Corrected all dead loops in generic code to call this function
      instead. This includes the dead loop that occurs at the end of the
      call to panic().
      
      All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have
      been removed.
      
      Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134
      1c3ea103
  13. 21 Dec, 2015 1 commit
  14. 14 Dec, 2015 1 commit
  15. 09 Dec, 2015 2 commits
    • Yatharth Kochar's avatar
      Move context management code to common location · bbf8f6f9
      Yatharth Kochar authored
      The upcoming Firmware Update feature needs transitioning across
      Secure/Normal worlds to complete the FWU process and hence requires
      context management code to perform this task.
      
      Currently context management code is part of BL31 stage only.
      This patch moves the code from (include)/bl31 to (include)/common.
      Some function declarations/definitions and macros have also moved
      to different files to help code sharing.
      
      Change-Id: I3858b08aecdb76d390765ab2b099f457873f7b0c
      bbf8f6f9
    • Soby Mathew's avatar
      Fix issue in Floating point register restore · 817ac8d1
      Soby Mathew authored
      The `fpregs_context_restore()` function used to restore the floating point
      regsiter context had a typo error wherein it was doing `str` instead of
      `ldr` for a register. This issue remained undetected becuase none of the ARM
      Standard development platforms save and restore the floating point register
      context when a context switch is done. This patch corrects the issue.
      
      Change-Id: Id178e0ba254a5e0a4a844f54b39d71dc34e0f6ea
      817ac8d1
  16. 26 Nov, 2015 2 commits
    • Sandrine Bailleux's avatar
      Introduce COLD_BOOT_SINGLE_CPU build option · a9bec67d
      Sandrine Bailleux authored
      This patch introduces a new build option named COLD_BOOT_SINGLE_CPU,
      which allows platforms that only release a single CPU out of reset to
      slightly optimise their cold boot code, both in terms of code size
      and performance.
      
      COLD_BOOT_SINGLE_CPU defaults to 0, which assumes that the platform
      may release several CPUs out of reset. In this case, the cold reset
      code needs to coordinate all CPUs via the usual primary/secondary
      CPU distinction.
      
      If a platform guarantees that only a single CPU will ever be released
      out of reset, there is no need to arbitrate execution ; the notion of
      primary and secondary CPUs itself no longer exists. Such platforms
      may set COLD_BOOT_SINGLE_CPU to 1 in order to compile out the
      primary/secondary CPU identification in the cold reset code.
      
      All ARM standard platforms can release several CPUs out of reset
      so they use COLD_BOOT_SINGLE_CPU=0. However, on CSS platforms like
      Juno, bringing up more than one CPU at reset should only be attempted
      when booting an EL3 payload, as it is not fully supported in the
      normal boot flow.
      
      For platforms using COLD_BOOT_SINGLE_CPU=1, the following 2 platform
      APIs become optional:
        - plat_secondary_cold_boot_setup();
        - plat_is_my_cpu_primary().
      The Porting Guide has been updated to reflect that.
      
      User Guide updated as well.
      
      Change-Id: Ic5b474e61b7aec1377d1e0b6925d17dfc376c46b
      a9bec67d
    • Soby Mathew's avatar
      Remove the IMF_READ_INTERRUPT_ID build option · 54718418
      Soby Mathew authored
      The IMF_READ_INTERRUPT_ID build option enables a feature where the interrupt
      ID of the highest priority pending interrupt is passed as a parameter to the
      interrupt handler registered for that type of interrupt. This additional read
      of highest pending interrupt id from GIC is problematic as it is possible that
      the original interrupt may get deasserted and another interrupt of different
      type maybe become the highest pending interrupt. Hence it is safer to prevent
      such behaviour by removing the IMF_READ_INTERRUPT_ID build option.
      
      The `id` parameter of the interrupt handler `interrupt_type_handler_t` is
      now made a reserved parameter with this patch. It will always contain
      INTR_ID_UNAVAILABLE.
      
      Fixes ARM-software/tf-issues#307
      
      Change-Id: I2173aae1dd37edad7ba6bdfb1a99868635fa34de
      54718418
  17. 14 Sep, 2015 1 commit
    • Achin Gupta's avatar
      Make generic code work in presence of system caches · 54dc71e7
      Achin Gupta authored
      On the ARMv8 architecture, cache maintenance operations by set/way on the last
      level of integrated cache do not affect the system cache. This means that such a
      flush or clean operation could result in the data being pushed out to the system
      cache rather than main memory. Another CPU could access this data before it
      enables its data cache or MMU. Such accesses could be serviced from the main
      memory instead of the system cache. If the data in the sysem cache has not yet
      been flushed or evicted to main memory then there could be a loss of
      coherency. The only mechanism to guarantee that the main memory will be updated
      is to use cache maintenance operations to the PoC by MVA(See section D3.4.11
      (System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G).
      
      This patch removes the reliance of Trusted Firmware on the flush by set/way
      operation to ensure visibility of data in the main memory. Cache maintenance
      operations by MVA are now used instead. The following are the broad category of
      changes:
      
      1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is
         initialised. This ensures that any stale cache lines at any level of cache
         are removed.
      
      2. Updates to global data in runtime firmware (BL31) by the primary CPU are made
         visible to secondary CPUs using a cache clean operation by MVA.
      
      3. Cache maintenance by set/way operations are only used prior to power down.
      
      NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN
      ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES.
      
      Fixes ARM-software/tf-issues#205
      
      Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a
      54dc71e7
  18. 13 Aug, 2015 1 commit
    • Soby Mathew's avatar
      PSCI: Migrate TF to the new platform API and CM helpers · 85a181ce
      Soby Mathew authored
      This patch migrates the rest of Trusted Firmware excluding Secure Payload and
      the dispatchers to the new platform and context management API. The per-cpu
      data framework APIs which took MPIDRs as their arguments are deleted and only
      the ones which take core index as parameter are retained.
      
      Change-Id: I839d05ad995df34d2163a1cfed6baa768a5a595d
      85a181ce
  19. 04 Jun, 2015 2 commits
    • Sandrine Bailleux's avatar
      Introduce PROGRAMMABLE_RESET_ADDRESS build option · bf031bba
      Sandrine Bailleux authored
      This patch introduces a new platform build option, called
      PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has
      a programmable or fixed reset vector address.
      
      If the reset vector address is fixed then the code relies on the
      platform_get_entrypoint() mailbox mechanism to figure out where
      it is supposed to jump. On the other hand, if it is programmable
      then it is assumed that the platform code will program directly
      the right address into the RVBAR register (instead of using the
      mailbox redirection) so the mailbox is ignored in this case.
      
      Change-Id: If59c3b11fb1f692976e1d8b96c7e2da0ebfba308
      bf031bba
    • Sandrine Bailleux's avatar
      Rationalize reset handling code · 52010cc7
      Sandrine Bailleux authored
      The attempt to run the CPU reset code as soon as possible after reset
      results in highly complex conditional code relating to the
      RESET_TO_BL31 option.
      
      This patch relaxes this requirement a little. In the BL1, BL3-1 and
      PSCI entrypoints code, the sequence of operations is now as follows:
       1) Detect whether it is a cold or warm boot;
       2) For cold boot, detect whether it is the primary or a secondary
          CPU. This is needed to handle multiple CPUs entering cold reset
          simultaneously;
       3) Run the CPU init code.
      
      This patch also abstracts the EL3 registers initialisation done by
      the BL1, BL3-1 and PSCI entrypoints into common code.
      
      This improves code re-use and consolidates the code flows for
      different types of systems.
      
      NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO
      NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE
      FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION.
      OTHERWISE, SECONDARY CPUS WILL PANIC.
      
      Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
      52010cc7
  20. 13 May, 2015 1 commit
    • Achin Gupta's avatar
      Fix handling of spurious interrupts in BL3_1 · 5717aae1
      Achin Gupta authored
      There are couple of issues with how the interrupt routing framework in BL3_1
      handles spurious interrupts.
      
      1. In the macro 'handle_interrupt_exception', if a spurious interrupt is
         detected by plat_ic_get_pending_interrupt_type(), then execution jumps to
         'interrupt_exit_\label'. This macro uses the el3_exit() function to return to
         the original exception level. el3_exit() attempts to restore the SPSR_EL3 and
         ELR_EL3 registers with values from the current CPU context. Since these
         registers were not saved in this code path, it programs stale values into
         these registers. This leads to unpredictable behaviour after the execution of
         the ERET instruction.
      
      2. When an interrupt is routed to EL3, it could be de-asserted before the
         GICC_HPPIR is read in plat_ic_get_pending_interrupt_type(). There could be
         another interrupt pending at the same time e.g. a non-secure interrupt. Its
         type will be returned instead of the original interrupt. This would result in
         a call to get_interrupt_type_handler(). The firmware will panic if the
         handler for this type of interrupt has not been registered.
      
      This patch fixes the first problem by saving SPSR_EL3 and ELR_EL3 early in the
      'handle_interrupt_exception' macro, instead of only doing so once the validity
      of the interrupt has been determined.
      
      The second problem is fixed by returning execution back to the lower exception
      level through the 'interrupt_exit_\label' label instead of treating it as an
      error condition. The 'interrupt_error_\label' label has been removed since it is
      no longer used.
      
      Fixes ARM-software/tf-issues#305
      
      Change-Id: I81c729a206d461084db501bb81b44dff435021e8
      5717aae1
  21. 08 Apr, 2015 1 commit
    • Kévin Petit's avatar
      Add support to indicate size and end of assembly functions · 8b779620
      Kévin Petit authored
      
      
      In order for the symbol table in the ELF file to contain the size of
      functions written in assembly, it is necessary to report it to the
      assembler using the .size directive.
      
      To fulfil the above requirements, this patch introduces an 'endfunc'
      macro which contains the .endfunc and .size directives. It also adds
      a .func directive to the 'func' assembler macro.
      
      The .func/.endfunc have been used so the assembler can fail if
      endfunc is omitted.
      
      Fixes ARM-Software/tf-issues#295
      
      Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc
      Signed-off-by: default avatarKévin Petit <kevin.petit@arm.com>
      8b779620
  22. 13 Mar, 2015 1 commit
    • Vikram Kanigiri's avatar
      Initialise cpu ops after enabling data cache · 12e7c4ab
      Vikram Kanigiri authored
      The cpu-ops pointer was initialized before enabling the data cache in the cold
      and warm boot paths. This required a DCIVAC cache maintenance operation to
      invalidate any stale cache lines resident in other cpus.
      
      This patch moves this initialization to the bl31_arch_setup() function
      which is always called after the data cache and MMU has been enabled.
      
      This change removes the need:
       1. for the DCIVAC cache maintenance operation.
       2. to initialise the CPU ops upon resumption from a PSCI CPU_SUSPEND
          call since memory contents are always preserved in this case.
      
      Change-Id: Ibb2fa2f7460d1a1f1e721242025e382734c204c6
      12e7c4ab
  23. 26 Jan, 2015 1 commit
    • Yatharth Kochar's avatar
      Call reset handlers upon BL3-1 entry. · 79a97b2e
      Yatharth Kochar authored
      This patch adds support to call the reset_handler() function in BL3-1 in the
      cold and warm boot paths when another Boot ROM reset_handler() has already run.
      
      This means the BL1 and BL3-1 versions of the CPU and platform specific reset
      handlers may execute different code to each other. This enables a developer to
      perform additional actions or undo actions already performed during the first
      call of the reset handlers e.g. apply additional errata workarounds.
      
      Typically, the reset handler will be first called from the BL1 Boot ROM. Any
      additional functionality can be added to the reset handler when it is called
      from BL3-1 resident in RW memory. The constant FIRST_RESET_HANDLER_CALL is used
      to identify whether this is the first version of the reset handler code to be
      executed or an overridden version of the code.
      
      The Cortex-A57 errata workarounds are applied only if they have not already been
      applied.
      
      Fixes ARM-software/tf-issue#275
      
      Change-Id: Id295f106e4fda23d6736debdade2ac7f2a9a9053
      79a97b2e
  24. 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
  25. 27 Aug, 2014 1 commit
  26. 20 Aug, 2014 3 commits
    • Soby Mathew's avatar
      Add CPU specific crash reporting handlers · d3f70af6
      Soby Mathew authored
      This patch adds handlers for dumping Cortex-A57 and Cortex-A53 specific register
      state to the CPU specific operations framework. The contents of CPUECTLR_EL1 are
      dumped currently.
      
      Change-Id: I63d3dbfc4ac52fef5e25a8cf6b937c6f0975c8ab
      d3f70af6
    • 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
  27. 15 Aug, 2014 1 commit
    • Achin Gupta's avatar
      Unmask SError interrupt and clear SCR_EL3.EA bit · 0c8d4fef
      Achin Gupta authored
      This patch disables routing of external aborts from lower exception levels to
      EL3 and ensures that a SError interrupt generated as a result of execution in
      EL3 is taken locally instead of a lower exception level.
      
      The SError interrupt is enabled in the TSP code only when the operation has not
      been directly initiated by the normal world. This is to prevent the possibility
      of an asynchronous external abort which originated in normal world from being
      taken when execution is in S-EL1.
      
      Fixes ARM-software/tf-issues#153
      
      Change-Id: I157b996c75996d12fd86d27e98bc73dd8bce6cd5
      0c8d4fef
  28. 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
  29. 31 Jul, 2014 1 commit
    • Soby Mathew's avatar
      Optimize EL3 register state stored in cpu_context structure · fdfabec1
      Soby Mathew authored
      This patch further optimizes the EL3 register state stored in
      cpu_context. The 2 registers which are removed from cpu_context are:
      
        * cntfrq_el0 is the system timer register which is writable
          only in EL3 and it can be programmed during cold/warm boot. Hence
          it need not be saved to cpu_context.
      
        * cptr_el3 controls access to Trace, Floating-point, and Advanced
          SIMD functionality and it is programmed every time during cold
          and warm boot. The current BL3-1 implementation does not need to
          modify the access controls during normal execution and hence
          they are expected to remain static.
      
      Fixes ARM-software/tf-issues#197
      
      Change-Id: I599ceee3b73a7dcfd37069fd41b60e3d397a7b18
      fdfabec1
  30. 28 Jul, 2014 3 commits
    • 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
    • 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
  31. 19 Jul, 2014 2 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
      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