1. 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
  2. 21 Dec, 2015 1 commit
  3. 14 Dec, 2015 1 commit
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  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. 27 Aug, 2014 1 commit
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 10 Jul, 2014 1 commit
  22. 24 Jun, 2014 1 commit
  23. 23 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Initialise CPU contexts from entry_point_info · 167a9357
      Andrew Thoelke authored
      Consolidate all BL3-1 CPU context initialization for cold boot, PSCI
      and SPDs into two functions:
      *  The first uses entry_point_info to initialize the relevant
         cpu_context for first entry into a lower exception level on a CPU
      *  The second populates the EL1 and EL2 system registers as needed
         from the cpu_context to ensure correct entry into the lower EL
      
      This patch alters the way that BL3-1 determines which exception level
      is used when first entering EL1 or EL2 during cold boot - this is now
      fully determined by the SPSR value in the entry_point_info for BL3-3,
      as set up by the platform code in BL2 (or otherwise provided to BL3-1).
      
      In the situation that EL1 (or svc mode) is selected for a processor
      that supports EL2, the context management code will now configure all
      essential EL2 register state to ensure correct execution of EL1. This
      allows the platform code to run non-secure EL1 payloads directly
      without requiring a small EL2 stub or OS loader.
      
      Change-Id: If9fbb2417e82d2226e47568203d5a369f39d3b0f
      167a9357
  24. 17 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Remove early_exceptions from BL3-1 · ee94cc6f
      Andrew Thoelke authored
      The crash reporting support and early initialisation of the
      cpu_data allow the runtime_exception vectors to be used from
      the start in BL3-1, removing the need for the additional
      early_exception vectors and 2KB of code from BL3-1.
      
      Change-Id: I5f8997dabbaafd8935a7455910b7db174a25d871
      ee94cc6f
  25. 16 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Per-cpu data cache restructuring · 5e910074
      Andrew Thoelke authored
      This patch prepares the per-cpu pointer cache for wider use by:
      * renaming the structure to cpu_data and placing in new header
      * providing accessors for this CPU, or other CPUs
      * splitting the initialization of the TPIDR pointer from the
        initialization of the cpu_data content
      * moving the crash stack initialization to a crash stack function
      * setting the TPIDR pointer very early during boot
      
      Change-Id: Icef9004ff88f8eb241d48c14be3158087d7e49a3
      5e910074
  26. 11 Jun, 2014 1 commit
    • Andrew Thoelke's avatar
      Make the BL3-1 crash reporting optional · 9c22b323
      Andrew Thoelke authored
      This patch makes the console crash dump of processor register
      state optional based on the CRASH_REPORTING make variable.
      
      This defaults to only being enabled for DEBUG builds. This can
      be overridden by setting a different value in the platform
      makefile or on the make command line.
      
      Change-Id: Icfa1b2d7ff0145cf0a85e8ad732f9cee7e7e993f
      9c22b323
  27. 05 Jun, 2014 1 commit
    • Sandrine Bailleux's avatar
      Include 'platform_def.h' header file in 'crash_reporting.S' · e4d13389
      Sandrine Bailleux authored
      'crash_reporting.S' needs to include 'platform_def.h' to get the
      definition of PLATFORM_CORE_COUNT.
      
      Note: On FVP it was compiling because 'platform_def.h' gets included
      through 'plat/fvp/include/plat_macros.S' but we don't want to rely on
      that for other platforms.
      
      Change-Id: I51e974776dd0f3bda10ad9849f5ef7b30c629833
      e4d13389
  28. 29 May, 2014 2 commits
    • Soby Mathew's avatar
      Fix compilation issue for IMF_READ_INTERRUPT_ID build flag · a3781085
      Soby Mathew authored
      This patch fixes the compilation issue for trusted firmware when the
      IMF_READ_INTERRUPT_ID is enabled.
      
      Change-Id: I94ab613b9bc96a7c1935796c674dc42246aaafee
      a3781085
    • Soby Mathew's avatar
      Pass 'cookie' parameter to interrupt handler in BL3-1 · b460b8bf
      Soby Mathew authored
      The interrupt handling routine in BL3-1 expects a cookie as its last
      parameter which was not being passed when invoking the interrupt
      handler in BL3-1. This patch fixes that by passing a dummy cookie
      parameter in the x3 register.
      
      Fixes ARM-software/tf-issues#171
      
      Change-Id: Ic98abbbd9f849e6f1c55343e865b5e0a4904a1c5
      b460b8bf
  29. 27 May, 2014 1 commit
    • Dan Handley's avatar
      Further renames of platform porting functions · 9865ac15
      Dan Handley authored
      Rename the ic_* platform porting functions to plat_ic_* to be
      consistent with the other functions in platform.h. Also rename
      bl31_get_next_image_info() to bl31_plat_get_next_image_ep_info()
      and remove the duplicate declaration in bl31.h.
      
      Change-Id: I4851842069d3cff14c0a468daacc0a891a7ede84
      9865ac15
  30. 23 May, 2014 1 commit
    • 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
  31. 22 May, 2014 1 commit
    • Achin Gupta's avatar
      Introduce interrupt handling framework in BL3-1 · dce74b89
      Achin Gupta authored
      This patch adds a common handler for FIQ and IRQ exceptions in the
      BL3-1 runtime exception vector table. This function determines the
      interrupt type and calls its handler. A crash is reported if an
      inconsistency in the interrupt management framework is detected. In
      the event of a spurious interrupt, execution resumes from the
      instruction where the interrupt was generated.
      
      This patch also removes 'cm_macros.S' as its contents have been moved
      to 'runtime_exceptions.S'
      
      Change-Id: I3c85ecf8eaf43a3fac429b119ed0bd706d2e2093
      dce74b89