1. 13 Nov, 2017 1 commit
    • Jeenu Viswambharan's avatar
      ARM platforms: Make arm_validate_ns_entrypoint() common · 71e7a4e5
      Jeenu Viswambharan authored
      
      
      The function arm_validate_ns_entrypoint() validates a given non-secure
      physical address. This function however specifically returns PSCI error
      codes.
      
      Non-secure physical address validation is potentially useful across ARM
      platforms, even for non-PSCI use cases. Therefore make this function
      common by returning 0 for success or -1 otherwise.
      
      Having made the function common, make arm_validate_psci_entrypoint() a
      wrapper around arm_validate_ns_entrypoint() which only translates return
      value into PSCI error codes. This wrapper is now used where
      arm_validate_ns_entrypoint() was currently used for PSCI entry point
      validation.
      
      Change-Id: Ic781fc3105d6d199fd8f53f01aba5baea0ebc310
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      71e7a4e5
  2. 11 Oct, 2017 1 commit
    • Soby Mathew's avatar
      ARM platforms: enable GICv3 state save/restore · e35a3fb5
      Soby Mathew authored
      
      
      Provides GICv3 save/restore feature to arm_system_pwr_domain_resume and
      arm_system_pwr_domain_save functions.
      
      Introduce FVP PSCI power level 3 (System level) support. This is solely
      done to provide example code on how to use the GICv3 save and restore
      helpers.
      
      Also make CSS GICv3 platforms power off the Redistributor on SYSTEM
      SUSPEND as its state is saved and restored.
      
      Change-Id: I0d852f3af8824edee1a17c085cf593ddd33a4e77
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Co-Authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      e35a3fb5
  3. 24 May, 2017 1 commit
  4. 03 May, 2017 1 commit
  5. 07 Dec, 2016 1 commit
    • Soby Mathew's avatar
      Allow ARM Standard platforms to dynamically define PSCI capability · 5486a965
      Soby Mathew authored
      
      
      The capabilities exposed by the PSCI generic layer depends on the hooks
      populated by the platform in `plat_arm_psci_pm_ops`. Currently ARM
      Standard platforms statically define this structure. However, some
      platforms may want to modify the hooks at runtime before registering
      them with the generic layer.
      
      This patch introduces a new ARM platform layer API
      `plat_arm_psci_override_pm_ops` which allows the platform to probe
      the power controller and modify `plat_arm_psci_pm_ops` if required.
      Consequently, 'plat_arm_psci_pm_ops' is no longer qualified as
      `const` on ARM Standard platforms.
      
      Change-Id: I7dbb44b7bd36c20ec14ded5ee45a96816ca2ab9d
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      5486a965
  6. 18 Feb, 2016 1 commit
    • Juan Castillo's avatar
      ARM platforms: rationalise memory attributes of shared memory · 74eb26e4
      Juan Castillo authored
      The shared memory region on ARM platforms contains the mailboxes and,
      on Juno, the payload area for communication with the SCP. This shared
      memory may be configured as normal memory or device memory at build
      time by setting the platform flag 'PLAT_ARM_SHARED_RAM_CACHED' (on
      Juno, the value of this flag is defined by 'MHU_PAYLOAD_CACHED').
      When set as normal memory, the platform port performs the corresponding
      cache maintenance operations. From a functional point of view, this is
      the equivalent of setting the shared memory as device memory, so there
      is no need to maintain both options.
      
      This patch removes the option to specify the shared memory as normal
      memory on ARM platforms. Shared memory is always treated as device
      memory. Cache maintenance operations are no longer needed and have
      been replaced by data memory barriers to guarantee that payload and
      MHU are accessed in the right order.
      
      Change-Id: I7f958621d6a536dd4f0fa8768385eedc4295e79f
      74eb26e4
  7. 09 Dec, 2015 2 commits
    • Soby Mathew's avatar
      Specify BL31 runtime console for ARM Standard platforms · 080225da
      Soby Mathew authored
      This patch overrides the default weak definition of
      `bl31_plat_runtime_setup()` for ARM Standard platforms to
      specify a BL31 runtime console. ARM Standard platforms are
      now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and
      `PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required
      by `arm_bl31_plat_runtime_setup()` to initialize the runtime
      console.
      
      The system suspend resume helper `arm_system_pwr_domain_resume()`
      is fixed to initialize the runtime console rather than the boot
      console on resumption from system suspend.
      
      Fixes ARM-software/tf-issues#220
      
      Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975
      080225da
    • Achin Gupta's avatar
      Rework use of ARM GIC drivers on ARM platforms · 27573c59
      Achin Gupta authored
      Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three
      separate drivers instead of providing a single driver that can work on both
      versions of the GIC architecture. These drivers correspond to the following
      software use cases:
      
      1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations
         e.g. GIC-400
      
      2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations
         e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features
      
      3. A deprecated GICv3 driver that operates in legacy mode. This driver can
         operate only in the GICv2 mode in the secure world. On a GICv3 system, this
         driver allows normal world to run in either GICv3 mode (asymmetric mode)
         or in the GICv2 mode. Both modes of operation are deprecated on GICv3
         systems.
      
      ARM platforms implement both versions of the GIC architecture. This patch adds a
      layer of abstraction to help ARM platform ports chose the right GIC driver and
      corresponding platform support. This is as described below:
      
      1. A set of ARM common functions have been introduced to initialise the GIC and
         the driver during cold and warm boot. These functions are prefixed as
         "plat_arm_gic_". Weak definitions of these functions have been provided for
         each type of driver.
      
      2. Each platform includes the sources that implement the right functions
         directly into the its makefile. The FVP can be instantiated with different
         versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option
         to specify which of the three drivers should be included in the build.
      
      3. A list of secure interrupts has to be provided to initialise each of the
        three GIC drivers. For GIC v3.0 the interrupt ids have to be further
        categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two
        types are merged and treated as Group 0 interrupts.
      
        The two lists of interrupts are exported from the platform_def.h. The lists
        are constructed by adding a list of board specific interrupt ids to a list of
        ids common to all ARM platforms and Compute sub-systems.
      
      This patch also makes some fields of `arm_config` data structure in FVP redundant
      and these unused fields are removed.
      
      Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
      27573c59
  8. 26 Nov, 2015 1 commit
    • Sandrine Bailleux's avatar
      CSS: Enable booting of EL3 payloads · 4c117f6c
      Sandrine Bailleux authored
      This patch adds support for booting EL3 payloads on CSS platforms,
      for example Juno. In this scenario, the Trusted Firmware follows
      its normal boot flow up to the point where it would normally pass
      control to the BL31 image. At this point, it jumps to the EL3
      payload entry point address instead.
      
      Before handing over to the EL3 payload, the data SCP writes for AP
      at the beginning of the Trusted SRAM is restored, i.e. we zero the
      first 128 bytes and restore the SCP Boot configuration. The latter
      is saved before transferring the BL30 image to SCP and is restored
      just after the transfer (in BL2). The goal is to make it appear that
      the EL3 payload is the first piece of software to run on the target.
      
      The BL31 entrypoint info structure is updated to make the primary
      CPU jump to the EL3 payload instead of the BL31 image.
      
      The mailbox is populated with the EL3 payload entrypoint address,
      which releases the secondary CPUs out of their holding pen (if the
      SCP has powered them on). The arm_program_trusted_mailbox() function
      has been exported for this purpose.
      
      The TZC-400 configuration in BL2 is simplified: it grants secure
      access only to the whole DRAM. Other security initialization is
      unchanged.
      
      This alternative boot flow is disabled by default. A new build option
      EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
      payload's entry point address. The build system has been modified
      such that BL31 and BL33 are not compiled and/or not put in the FIP in
      this case, as those images are not used in this boot flow.
      
      Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
      4c117f6c
  9. 30 Oct, 2015 1 commit
    • Soby Mathew's avatar
      Support PSCI SYSTEM SUSPEND on Juno · c1bb8a05
      Soby Mathew authored
      This patch adds the capability to power down at system power domain level
      on Juno via the PSCI SYSTEM SUSPEND API. The CSS power management helpers
      are modified to add support for power management operations at system
      power domain level. A new helper for populating `get_sys_suspend_power_state`
      handler in plat_psci_ops is defined. On entering the system suspend state,
      the SCP powers down the SYSTOP power domain on the SoC and puts the memory
      into retention mode. On wakeup from the power down, the system components
      on the CSS will be reinitialized by the platform layer and the PSCI client
      is responsible for restoring the context of these system components.
      
      According to PSCI Specification, interrupts targeted to cores in PSCI CPU
      SUSPEND should be able to resume it. On Juno, when the system power domain
      is suspended, the GIC is also powered down. The SCP resumes the final core
      to be suspend when an external wake-up event is received. But the other
      cores cannot be woken up by a targeted interrupt, because GIC doesn't
      forward these interrupts to the SCP. Due to this hardware limitation,
      we down-grade PSCI CPU SUSPEND requests targeted to the system power domain
      level to cluster power domain level in `juno_validate_power_state()`
      and the CSS default `plat_arm_psci_ops` is overridden in juno_pm.c.
      
      A system power domain resume helper `arm_system_pwr_domain_resume()` is
      defined for ARM standard platforms which resumes/re-initializes the
      system components on wakeup from system suspend. The security setup also
      needs to be done on resume from system suspend, which means
      `plat_arm_security_setup()` must now be included in the BL3-1 image in
      addition to previous BL images if system suspend need to be supported.
      
      Change-Id: Ie293f75f09bad24223af47ab6c6e1268f77bcc47
      c1bb8a05
  10. 20 Oct, 2015 1 commit
    • Soby Mathew's avatar
      Reorganise PSCI PM handler setup on ARM Standard platforms · 785fb92b
      Soby Mathew authored
      This patch does the following reorganization to psci power management (PM)
      handler setup for ARM standard platform ports :
      
      1. The mailbox programming required during `plat_setup_psci_ops()` is identical
         for all ARM platforms. Hence the implementation of this API is now moved
         to the common `arm_pm.c` file. Each ARM platform now must define the
         PLAT_ARM_TRUSTED_MAILBOX_BASE macro, which in current platforms is the same
         as ARM_SHARED_RAM_BASE.
      
      2. The PSCI PM handler callback structure, `plat_psci_ops`, must now be
         exported via `plat_arm_psci_pm_ops`. This allows the common implementation
         of `plat_setup_psci_ops()` to return a platform specific `plat_psci_ops`.
         In the case of CSS platforms, a default weak implementation of the same is
         provided in `css_pm.c` which can be overridden by each CSS platform.
      
      3. For CSS platforms, the PSCI PM handlers defined in `css_pm.c` are now
         made library functions and a new header file `css_pm.h` is added to export
         these generic PM handlers. This allows the platform to reuse the
         adequate CSS PM handlers and redefine others which need to be customized
         when overriding the default `plat_arm_psci_pm_ops` in `css_pm.c`.
      
      Change-Id: I277910f609e023ee5d5ff0129a80ecfce4356ede
      785fb92b
  11. 13 Aug, 2015 3 commits
    • Soby Mathew's avatar
      PSCI: Validate non secure entrypoint on ARM platforms · f9e858b1
      Soby Mathew authored
      This patch implements the platform power managment handler to verify
      non secure entrypoint for ARM platforms. The handler ensures that the
      entry point specified by the normal world during CPU_SUSPEND, CPU_ON
      or SYSTEM_SUSPEND PSCI API is a valid address within the non secure
      DRAM.
      
      Change-Id: I4795452df99f67a24682b22f0e0967175c1de429
      f9e858b1
    • Soby Mathew's avatar
      PSCI: Demonstrate support for composite power states · 2204afde
      Soby Mathew authored
      This patch adds support to the Juno and FVP ports for composite power states
      with both the original and extended state-id power-state formats. Both the
      platform ports use the recommended state-id encoding as specified in
      Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag
      ARM_RECOM_STATE_ID_ENC is used to include this support.
      
      By default, to maintain backwards compatibility, the original power state
      parameter format is used and the state-id field is expected to be zero.
      
      Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
      2204afde
    • Soby Mathew's avatar
      PSCI: Migrate ARM reference platforms to new platform API · 38dce70f
      Soby Mathew authored
      This patch migrates ARM reference platforms, Juno and FVP, to the new platform
      API mandated by the new PSCI power domain topology and composite power state
      frameworks. The platform specific makefiles now exports the build flag
      ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer.
      
      Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29
      38dce70f
  12. 28 Apr, 2015 1 commit
    • Dan Handley's avatar
      Add common ARM and CSS platform code · b4315306
      Dan Handley authored
      This major change pulls out the common functionality from the
      FVP and Juno platform ports into the following categories:
      
      *   (include/)plat/common. Common platform porting functionality that
      typically may be used by all platforms.
      
      *   (include/)plat/arm/common. Common platform porting functionality
      that may be used by all ARM standard platforms. This includes all
      ARM development platforms like FVP and Juno but may also include
      non-ARM-owned platforms.
      
      *   (include/)plat/arm/board/common. Common platform porting
      functionality for ARM development platforms at the board
      (off SoC) level.
      
      *   (include/)plat/arm/css/common. Common platform porting
      functionality at the ARM Compute SubSystem (CSS) level. Juno
      is an example of a CSS-based platform.
      
      *   (include/)plat/arm/soc/common. Common platform porting
      functionality at the ARM SoC level, which is not already defined
      at the ARM CSS level.
      
      No guarantees are made about the backward compatibility of
      functionality provided in (include/)plat/arm.
      
      Also remove any unnecessary variation between the ARM development
      platform ports, including:
      
      *   Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the
      Juno implementation, which copies the information from BL2 memory
      instead of expecting it to persist in shared memory.
      
      *   Unify the TZC configuration. There is no need to add a region
      for SCP in Juno; it's enough to simply not allow any access to
      this reserved region. Also set region 0 to provide no access by
      default instead of assuming this is the case.
      
      *   Unify the number of memory map regions required for ARM
      development platforms, although the actual ranges mapped for each
      platform may be different. For the FVP port, this reduces the
      mapped peripheral address space.
      
      These latter changes will only be observed when the platform ports
      are migrated to use the new common platform code in subsequent
      patches.
      
      Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
      b4315306
  13. 31 Mar, 2015 1 commit
  14. 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
  15. 28 Jul, 2014 1 commit
    • 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
  16. 24 Jun, 2014 1 commit
  17. 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
  18. 07 May, 2014 2 commits
    • Andrew Thoelke's avatar
      Correct usage of data and instruction barriers · 8cec598b
      Andrew Thoelke authored
      The current code does not always use data and instruction
      barriers as required by the architecture and frequently uses
      barriers excessively due to their inclusion in all of the
      write_*() helper functions.
      
      Barriers should be used explicitly in assembler or C code
      when modifying processor state that requires the barriers in
      order to enable review of correctness of the code.
      
      This patch removes the barriers from the helper functions and
      introduces them as necessary elsewhere in the code.
      
      PORTING NOTE: check any port of Trusted Firmware for use of
      system register helper functions for reliance on the previous
      barrier behaviour and add explicit barriers as necessary.
      
      Fixes ARM-software/tf-issues#92
      
      Change-Id: Ie63e187404ff10e0bdcb39292dd9066cb84c53bf
      8cec598b
    • Andrew Thoelke's avatar
      Set processor endianness immediately after RESET · 40fd0725
      Andrew Thoelke authored
      SCTLR_EL3.EE is being configured too late in bl1_arch_setup() and
      bl31_arch_setup() after data accesses have already occured on
      the cold and warm boot paths.
      
      This control bit must be configured immediately on CPU reset to
      match the endian state of the firmware (little endian).
      
      Fixes ARM-software/tf-issues#145
      
      Change-Id: Ie12e46fbbed6baf024c30beb50751591bb8c8655
      40fd0725
  19. 06 May, 2014 1 commit
    • Dan Handley's avatar
      Reduce deep nesting of header files · 97043ac9
      Dan Handley authored
      Reduce the number of header files included from other header
      files as much as possible without splitting the files. Use forward
      declarations where possible. This allows removal of some unnecessary
      "#ifndef __ASSEMBLY__" statements.
      
      Also, review the .c and .S files for which header files really need
      including and reorder the #include statements alphabetically.
      
      Fixes ARM-software/tf-issues#31
      
      Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e
      97043ac9
  20. 08 Apr, 2014 2 commits
    • Sandrine Bailleux's avatar
      Define frequency of system counter in platform code · 9e86490f
      Sandrine Bailleux authored
      BL3-1 architecture setup code programs the system counter frequency
      into the CNTFRQ_EL0 register. This frequency is defined by the
      platform, though. This patch introduces a new platform hook that
      the architecture setup code can call to retrieve this information.
      In the ARM FVP port, this returns the first entry of the frequency
      modes table from the memory mapped generic timer.
      
      All system counter setup code has been removed from BL1 as some
      platforms may not have initialized the system counters at this stage.
      The platform specific settings done exclusively in BL1 have been moved
      to BL3-1. In the ARM FVP port, this consists in enabling and
      initializing the System level generic timer. Also, the frequency change
      request in the counter control register has been set to 0 to make it
      explicit it's using the base frequency. The CNTCR_FCREQ() macro has been
      fixed in this context to give an entry number rather than a bitmask.
      
      In future, when support for firmware update is implemented, there
      is a case where BL1 platform specific code will need to program
      the counter frequency. This should be implemented at that time.
      
      This patch also updates the relevant documentation.
      
      It properly fixes ARM-software/tf-issues#24
      
      Change-Id: If95639b279f75d66ac0576c48a6614b5ccb0e84b
      9e86490f
    • Sandrine Bailleux's avatar
      Revert "Move architecture timer setup to platform-specific code" · 65a9c0e9
      Sandrine Bailleux authored
      This reverts commit 1c297bf0
      because it introduced a bug: the CNTFRQ_EL0 register was no
      longer programmed by all CPUs.  bl31_platform_setup() function
      is invoked only in the cold boot path and consequently only
      on the primary cpu.
      
      A subsequent commit will correctly implement the necessary changes
      to the counter frequency setup code.
      
      Fixes ARM-software/tf-issues#125
      
      Conflicts:
      
      	docs/firmware-design.md
      	plat/fvp/bl31_plat_setup.c
      
      Change-Id: Ib584ad7ed069707ac04cf86717f836136ad3ab54
      65a9c0e9
  21. 21 Mar, 2014 1 commit
    • Vikram Kanigiri's avatar
      Remove partially qualified asm helper functions · 6ba0b6d6
      Vikram Kanigiri authored
      Each ARM Trusted Firmware image should know in which EL it is running
      and it should use the corresponding register directly instead of reading
      currentEL and knowing which asm register to read/write
      
      Change-Id: Ief35630190b6f07c8fbb7ba6cb20db308f002945
      6ba0b6d6
  22. 10 Mar, 2014 1 commit
    • Jeenu Viswambharan's avatar
      Move architecture timer setup to platform-specific code · 1c297bf0
      Jeenu Viswambharan authored
      At present, bl1_arch_setup() and bl31_arch_setup() program the counter
      frequency using a value from the memory mapped generic timer. The
      generic timer however is not necessarily present on all ARM systems
      (although it is architected to be present on all server systems).
      
      This patch moves the timer setup to platform-specific code and updates
      the relevant documentation. Also, CNTR.FCREQ is set as the specification
      requires the bit corresponding to the counter's frequency to be set when
      enabling. Since we intend to use the base frequency, set bit 8.
      
      Fixes ARM-software/tf-issues#24
      
      Change-Id: I32c52cf882253e01f49056f47c58c23e6f422652
      1c297bf0
  23. 17 Jan, 2014 2 commits
    • Harry Liebel's avatar
      Do not trap access to floating point registers · 4f603683
      Harry Liebel authored
      Traps when accessing architectural features are disabled by clearing bits
      in CPTR_EL3 during early boot, including accesses to floating point
      registers. The value of this register was previously undetermined, causing
      unwanted traps to EL3. Future EL3 code (for example, context save/restore
      code) may use floating point registers, although they are not used by current
      code.
      
      Also, the '-mgeneral-regs-only' flag is enabled in the GCC settings to
      prevent generation of code that uses floating point registers.
      
      Change-Id: I9a03675f6387bbbee81a6f2c9ccf81150db03747
      4f603683
    • Dan Handley's avatar
      Update year in copyright text to 2014 · e83b0cad
      Dan Handley authored
      Change-Id: Ic7fb61aabae1d515b9e6baf3dd003807ff42da60
      e83b0cad
  24. 05 Dec, 2013 1 commit
    • Dan Handley's avatar
      Enable third party contributions · ab2d31ed
      Dan Handley authored
      - Add instructions for contributing to ARM Trusted Firmware.
      
      - Update copyright text in all files to acknowledge contributors.
      
      Change-Id: I9311aac81b00c6c167d2f8c889aea403b84450e5
      ab2d31ed
  25. 27 Nov, 2013 1 commit
    • Sandrine Bailleux's avatar
      Unmask SError and Debug exceptions. · 3738274d
      Sandrine Bailleux authored
      Any asynchronous exception caused by the firmware should be handled
      in the firmware itself.  For this reason, unmask SError exceptions
      (and Debug ones as well) on all boot paths.  Also route external
      abort and SError interrupts to EL3, otherwise they will target EL1.
      
      Change-Id: I9c191d2d0dcfef85f265641c8460dfbb4d112092
      3738274d
  26. 25 Oct, 2013 1 commit