1. 14 Dec, 2015 1 commit
  2. 09 Dec, 2015 5 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
      Ensure BL31 does not print to boot console by default · 78e61613
      Soby Mathew authored
      It is not ideal for BL31 to continue to use boot console at
      runtime which could be potentially uninitialized. This patch
      introduces a new optional platform porting API
      `bl31_plat_runtime_setup()` which allows the platform to perform
      any BL31 runtime setup just prior to BL31 exit during cold boot.
      The default weak implementation of this function will invoke
      `console_uninit()` which will suppress any BL31 runtime logs.
      
      On the ARM Standard platforms, there is an anomaly that
      the boot console will be reinitialized on resumption from
      system suspend in `arm_system_pwr_domain_resume()`. This
      will be resolved in the following patch.
      
      NOTE: The default weak definition of `bl31_plat_runtime_setup()`
      disables the BL31 console. To print the BL31 runtime
      messages, platforms must override this API and initialize a
      runtime console.
      
      Fixes ARM-software/tf-issues#328
      
      Change-Id: Ibaf8346fcceb447fe1a5674094c9f8eb4c09ac4a
      78e61613
    • Sandrine Bailleux's avatar
      Initialize VTTBR_EL2 when bypassing EL2 · 85d80e55
      Sandrine Bailleux authored
      In the situation that EL1 is selected as the exception level for the
      next image upon BL31 exit for a processor that supports EL2, the
      context management code must configure all essential EL2 register
      state to ensure correct execution of EL1.
      
      VTTBR_EL2 should be part of this set of EL2 registers because:
       - The ARMv8-A architecture does not define a reset value for this
         register.
       - Cache maintenance operations depend on VTTBR_EL2.VMID even when
         non-secure EL1&0 stage 2 address translation are disabled.
      
      This patch initializes the VTTBR_EL2 register to 0 when bypassing EL2
      to address this issue. Note that this bug has not yet manifested
      itself on FVP or Juno because VTTBR_EL2.VMID resets to 0 on the
      Cortex-A53 and Cortex-A57.
      
      Change-Id: I58ce2d16a71687126f437577a506d93cb5eecf33
      85d80e55
    • 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
    • Soby Mathew's avatar
      Enable support for EL3 interrupt in IMF · 4e0e0f44
      Soby Mathew authored
      This patch enables support for EL3 interrupts in the Interrupt Management
      Framework (IMF) of ARM Trusted Firmware. Please note that although the
      registration of the EL3 interrupt type is now supported, it has not been
      tested on any of the ARM Standard platforms.
      
      Change-Id: If4dcdc7584621522a2f3ea13ea9b1ad0a76bb8a1
      4e0e0f44
  3. 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
  4. 24 Nov, 2015 1 commit
    • Soby Mathew's avatar
      Replace build macro WARN_DEPRECATED with ERROR_DEPRECATED · 7a24cba5
      Soby Mathew authored
      This patch changes the build time behaviour when using deprecated API within
      Trusted Firmware. Previously the use of deprecated APIs would only trigger a
      build warning (which was always treated as a build error), when
      WARN_DEPRECATED = 1. Now, the use of deprecated C declarations will always
      trigger a build time warning. Whether this warning is treated as error or not
      is determined by the build flag ERROR_DEPRECATED which is disabled by default.
      When the build flag ERROR_DEPRECATED=1, the invocation of deprecated API or
      inclusion of deprecated headers will result in a build error.
      
      Also the deprecated context management helpers in context_mgmt.c are now
      conditionally compiled depending on the value of ERROR_DEPRECATED flag
      so that the APIs themselves do not result in a build error when the
      ERROR_DEPRECATED flag is set.
      
      NOTE: Build systems that use the macro WARN_DEPRECATED must migrate to
      using ERROR_DEPRECATED, otherwise deprecated API usage will no longer
      trigger a build error.
      
      Change-Id: I843bceef6bde979af7e9b51dddf861035ec7965a
      7a24cba5
  5. 05 Nov, 2015 1 commit
    • Juan Castillo's avatar
      IMF: postpone SCR_EL3 update if context is not initialized · 5c943f7f
      Juan Castillo authored
      The set_routing_model() function in the Interrupt Management
      Framework calls the context management library to update the
      SCR_EL3 register. This context management library assumes that
      the context has been previously initialized. Consequently, if
      a Secure Payload Dispatcher (SPD) tries to set the routing model
      before initializing the context, the system will fail (in debug
      mode, an assertion will be raised).
      
      This patch fixes the issue by checking if the context has been
      initialized before updating SCR_EL3. If a valid context is not
      available, SCR_EL3 update will be done when the SPD calls the
      context initialization function. This function will call
      get_scr_el3_from_routing_model() to obtain the SCR_EL3 value.
      If the SPD does not call the context initialization function
      then it is SPD's responsibility to obtain SCR_EL3 from the IMF
      and update the context accordingly.
      
      Fixes ARM-software/tf-issues#327
      
      Change-Id: Ic2f1c6e899e578a8db858ec43747c63a8539c16f
      5c943f7f
  6. 02 Nov, 2015 1 commit
    • Sandrine Bailleux's avatar
      Introduce print_entry_point_info() function · 68a68c92
      Sandrine Bailleux authored
      This patch introduces a new function called 'print_entry_point_info'
      that prints an entry_point_t structure for debugging purposes.
      As such, it can be used to display the entry point address, SPSR and
      arguments passed from a firmware image to the next one.
      
      This function is now called in the following images transitions:
       - BL1 to BL2
       - BL1 to BL31
       - BL31 to the next image (typically BL32 or BL33)
      
      The following changes have been introduced:
      
       - Fix the output format of the SPSR value : SPSR is a 32-bit value,
         not a 64-bit one.
      
       - Print all arguments values.
         The entry_point_info_t structure allows to pass up to 8 arguments.
         In most cases, only the first 2 arguments were printed.
         print_entry_point_info() now prints all of them as 'VERBOSE'
         traces.
      
      Change-Id: Ieb384bffaa7849e6cb95a01a47c0b7fc2308653a
      68a68c92
  7. 25 Sep, 2015 1 commit
    • Vikram Kanigiri's avatar
      Fix relocation of __PERCPU_BAKERY_LOCK_SIZE__ · 7173f5f6
      Vikram Kanigiri authored
      When a platform port does not define PLAT_PERCPU_BAKERY_LOCK_SIZE, the total
      memory that should be allocated per-cpu to accommodate all bakery locks is
      calculated by the linker in bl31.ld.S. The linker stores this value in the
      __PERCPU_BAKERY_LOCK_SIZE__ linker symbol. The runtime value of this symbol is
      different from the link time value as the symbol is relocated into the current
      section (.bss). This patch fixes this issue by marking the symbol as ABSOLUTE
      which allows it to retain its correct value even at runtime.
      
      The description of PLAT_PERCPU_BAKERY_LOCK_SIZE in the porting-guide.md has been
      made clearer as well.
      
      Change-Id: Ia0cfd42f51deaf739d792297e60cad5c6e6e610b
      7173f5f6
  8. 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
  9. 11 Sep, 2015 1 commit
    • Andrew Thoelke's avatar
      Re-design bakery lock memory allocation and algorithm · ee7b35c4
      Andrew Thoelke authored
      This patch unifies the bakery lock api's across coherent and normal
      memory implementation of locks by using same data type `bakery_lock_t`
      and similar arguments to functions.
      
      A separate section `bakery_lock` has been created and used to allocate
      memory for bakery locks using `DEFINE_BAKERY_LOCK`. When locks are
      allocated in normal memory, each lock for a core has to spread
      across multiple cache lines. By using the total size allocated in a
      separate cache line for a single core at compile time, the memory for
      other core locks is allocated at link time by multiplying the single
      core locks size with (PLATFORM_CORE_COUNT - 1). The normal memory lock
      algorithm now uses lock address instead of the `id` in the per_cpu_data.
      For locks allocated in coherent memory, it moves locks from
      tzfw_coherent_memory to bakery_lock section.
      
      The bakery locks are allocated as part of bss or in coherent memory
      depending on usage of coherent memory. Both these regions are
      initialised to zero as part of run_time_init before locks are used.
      Hence, bakery_lock_init() is made an empty function as the lock memory
      is already initialised to zero.
      
      The above design lead to the removal of psci bakery locks from
      non_cpu_power_pd_node to psci_locks.
      
      NOTE: THE BAKERY LOCK API WHEN USE_COHERENT_MEM IS NOT SET HAS CHANGED.
      THIS IS A BREAKING CHANGE FOR ALL PLATFORM PORTS THAT ALLOCATE BAKERY
      LOCKS IN NORMAL MEMORY.
      
      Change-Id: Ic3751c0066b8032dcbf9d88f1d4dc73d15f61d8b
      ee7b35c4
  10. 13 Aug, 2015 3 commits
    • 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
    • Soby Mathew's avatar
      PSCI: Switch to the new PSCI frameworks · 67487846
      Soby Mathew authored
      This commit does the switch to the new PSCI framework implementation replacing
      the existing files in PSCI folder with the ones in PSCI1.0 folder. The
      corresponding makefiles are modified as required for the new implementation.
      The platform.h header file is also is switched to the new one
      as required by the new frameworks. The build flag ENABLE_PLAT_COMPAT defaults
      to 1 to enable compatibility layer which let the existing platform ports to
      continue to build and run with minimal changes.
      
      The default weak implementation of platform_get_core_pos() is now removed from
      platform_helpers.S and is provided by the compatibility layer.
      
      Note: The Secure Payloads and their dispatchers still use the old platform
      and framework APIs and hence it is expected that the ENABLE_PLAT_COMPAT build
      flag will remain enabled in subsequent patch. The compatibility for SPDs using
      the older APIs on platforms migrated to the new APIs will be added in the
      following patch.
      
      Change-Id: I18c51b3a085b564aa05fdd98d11c9f3335712719
      67487846
    • Soby Mathew's avatar
      PSCI: Introduce new platform and CM helper APIs · 12d0d00d
      Soby Mathew authored
      This patch introduces new platform APIs and context management helper APIs
      to support the new topology framework based on linear core position. This
      framework will be introduced in the follwoing patch and it removes the
      assumption that the MPIDR based affinity levels map directly to levels
      in a power domain tree. The new platforms APIs and context management
      helpers based on core position are as described below:
      
      * plat_my_core_pos() and plat_core_pos_by_mpidr()
      
      These 2 new mandatory platform APIs are meant to replace the existing
      'platform_get_core_pos()' API. The 'plat_my_core_pos()' API returns the
      linear index of the calling core and 'plat_core_pos_by_mpidr()' returns
      the linear index of a core specified by its MPIDR. The latter API will also
      validate the MPIDR passed as an argument and will return an error code (-1)
      if an invalid MPIDR is passed as the argument. This enables the caller to
      safely convert an MPIDR of another core to its linear index without querying
      the PSCI topology tree e.g. during a call to PSCI CPU_ON.
      
      Since the 'plat_core_pos_by_mpidr()' API verifies an MPIDR, which is always
      platform specific, it is no longer possible to maintain a default implementation
      of this API. Also it might not be possible for a platform port to verify an
      MPIDR before the C runtime has been setup or the topology has been initialized.
      This would prevent 'plat_core_pos_by_mpidr()' from being callable prior to
      topology setup. As a result, the generic Trusted Firmware code does not call
      this API before the topology setup has been done.
      
      The 'plat_my_core_pos' API should be able to run without a C runtime.
      Since this API needs to return a core position which is equal to the one
      returned by 'plat_core_pos_by_mpidr()' API for the corresponding MPIDR,
      this too cannot have default implementation and is a mandatory API for
      platform ports. These APIs will be implemented by the ARM reference platform
      ports later in the patch stack.
      
      * plat_get_my_stack() and plat_set_my_stack()
      
      These APIs are the stack management APIs which set/return stack addresses
      appropriate for the calling core. These replace the 'platform_get_stack()' and
      'platform_set_stack()' APIs. A default weak MP version and a global UP version
      of these APIs are provided for the platforms.
      
      * Context management helpers based on linear core position
      
      A set of new context management(CM) helpers viz cm_get_context_by_index(),
      cm_set_context_by_index(), cm_init_my_context() and cm_init_context_by_index()
      are defined which are meant to replace the old helpers which took MPIDR
      as argument. The old CM helpers are implemented based on the new helpers to
      allow for code consolidation and will be deprecated once the switch to the new
      framework is done.
      
      Change-Id: I89758632b370c2812973a4b2efdd9b81a41f9b69
      12d0d00d
  11. 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
  12. 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
  13. 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
  14. 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
  15. 06 Mar, 2015 1 commit
    • Sandrine Bailleux's avatar
      Enable type-checking of arguments passed to printf() et al. · dad25049
      Sandrine Bailleux authored
      This patch modifies the declarations of the functions printf() et al.
      and adds the right GCC attribute to request the compiler to check
      the type of the arguments passed to these functions against the given
      format string. This will ensure that the compiler outputs warning
      messages like the following whenever it detects an inconsistency:
      
       file.c:42: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’
      
      It also fixes the type mismatch inconsistencies that it revealed
      across the code base.
      
      NOTE: THIS PATCH MAY FORCE PLATFORM PORTS OR SP/SPDS THAT USE THE
      PRINTF FAMILY OF FUNCTIONS TO FIX ANY TYPE MISMATCH INCONSISTENCIES.
      
      Change-Id: If36bb54ec7d6dd2cb4791d89b02a24ac13fd2df6
      dad25049
  16. 26 Jan, 2015 2 commits
    • 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
    • Soby Mathew's avatar
      Demonstrate model for routing IRQs to EL3 · f4f1ae77
      Soby Mathew authored
      This patch provides an option to specify a interrupt routing model
      where non-secure interrupts (IRQs) are routed to EL3 instead of S-EL1.
      When such an interrupt occurs, the TSPD arranges a return to
      the normal world after saving any necessary context. The interrupt
      routing model to route IRQs to EL3 is enabled only during STD SMC
      processing. Thus the pre-emption of S-EL1 is disabled during Fast SMC
      and Secure Interrupt processing.
      
      A new build option TSPD_ROUTE_NS_INT_EL3 is introduced to change
      the non secure interrupt target execution level to EL3.
      
      Fixes ARM-software/tf-issues#225
      
      Change-Id: Ia1e779fbbb6d627091e665c73fa6315637cfdd32
      f4f1ae77
  17. 22 Jan, 2015 2 commits
    • 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
    • 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
  18. 19 Sep, 2014 1 commit
    • Juan Castillo's avatar
      Fix LENGTH attribute value in linker scripts · d7fbf132
      Juan Castillo authored
      This patch fixes the incorrect value of the LENGTH attribute in
      the linker scripts. This attribute must define the memory size, not
      the limit address.
      
      Fixes ARM-software/tf-issues#252
      
      Change-Id: I328c38b9ec502debe12046a8912d7dfc54610c46
      d7fbf132
  19. 16 Sep, 2014 1 commit
  20. 02 Sep, 2014 1 commit
    • Soby Mathew's avatar
      Reset CNTVOFF_EL2 register before exit into EL1 on warm boot · 14c0526b
      Soby Mathew authored
      This patch resets the value of CNTVOFF_EL2 before exit to EL1 on
      warm boot. This needs to be done if only the Trusted Firmware exits
      to EL1 instead of EL2, otherwise the hypervisor would be responsible
      for this.
      
      Fixes ARM-software/tf-issues#240
      
      Change-Id: I79d54831356cf3215bcf1f251c373bd8f89db0e0
      14c0526b
  21. 27 Aug, 2014 1 commit
  22. 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
  23. 19 Aug, 2014 1 commit
    • Juan Castillo's avatar
      Add support for PSCI SYSTEM_OFF and SYSTEM_RESET APIs · d5f13093
      Juan Castillo authored
      This patch adds support for SYSTEM_OFF and SYSTEM_RESET PSCI
      operations. A platform should export handlers to complete the
      requested operation. The FVP port exports fvp_system_off() and
      fvp_system_reset() as an example.
      
      If the SPD provides a power management hook for system off and
      system reset, then the SPD is notified about the corresponding
      operation so it can do some bookkeeping. The TSPD exports
      tspd_system_off() and tspd_system_reset() for that purpose.
      
      Versatile Express shutdown and reset methods have been removed
      from the FDT as new PSCI sys_poweroff and sys_reset services
      have been added. For those kernels that do not support yet these
      PSCI services (i.e. GICv3 kernel), the original dtsi files have
      been renamed to *-no_psci.dtsi.
      
      Fixes ARM-software/tf-issues#218
      
      Change-Id: Ic8a3bf801db979099ab7029162af041c4e8330c8
      d5f13093
  24. 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
  25. 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
  26. 01 Aug, 2014 2 commits
    • Vikram Kanigiri's avatar
      Support asynchronous method for BL3-2 initialization · faaa2e76
      Vikram Kanigiri authored
      This patch adds support for BL3-2 initialization by asynchronous
      method where BL3-1 transfers control to BL3-2 using world switch.
      After BL3-2 initialization, it transfers control to BL3-3 via SPD
      service handler. The SPD service handler initializes the CPU context
      to BL3-3 entrypoint depending on the return function indentifier from
      TSP initialization.
      
      Fixes ARM-software/TF-issues#184
      
      Change-Id: I7b135c2ceeb356d3bb5b6a287932e96ac67c7a34
      faaa2e76
    • 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