1. 04 Oct, 2019 1 commit
    • Soby Mathew's avatar
      Fix the CAS spinlock implementation · c97cba4e
      Soby Mathew authored
      
      
      Make the spinlock implementation use ARMv8.1-LSE CAS instruction based
      on a platform build option. The CAS-based implementation used to be
      unconditionally selected for all ARM8.1+ platforms.
      
      The previous CAS spinlock implementation had a bug wherein the spin_unlock()
      implementation had an `sev` after `stlr` which is not sufficient. A dsb is
      needed to ensure that the stlr completes prior to the sev. Having a dsb is
      heavyweight and a better solution would be to use load exclusive semantics
      to monitor the lock and wake up from wfe when a store happens to the lock.
      The patch implements the same.
      
      Change-Id: I5283ce4a889376e4cc01d1b9d09afa8229a2e522
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Signed-off-by: default avatarOlivier Deprez <olivier.deprez@arm.com>
      c97cba4e
  2. 12 Sep, 2019 1 commit
  3. 11 Sep, 2019 1 commit
    • Justin Chadwell's avatar
      Add UBSAN support and handlers · 1f461979
      Justin Chadwell authored
      
      
      This patch adds support for the Undefined Behaviour sanitizer. There are
      two types of support offered - minimalistic trapping support which
      essentially immediately crashes on undefined behaviour and full support
      with full debug messages.
      
      The full support relies on ubsan.c which has been adapted from code used
      by OPTEE.
      
      Change-Id: I417c810f4fc43dcb56db6a6a555bfd0b38440727
      Signed-off-by: default avatarJustin Chadwell <justin.chadwell@arm.com>
      1f461979
  4. 09 Sep, 2019 1 commit
    • Justin Chadwell's avatar
      Enable MTE support in both secure and non-secure worlds · 9dd94382
      Justin Chadwell authored
      
      
      This patch adds support for the new Memory Tagging Extension arriving in
      ARMv8.5. MTE support is now enabled by default on systems that support
      at EL0. To enable it at ELx for both the non-secure and the secure
      world, the compiler flag CTX_INCLUDE_MTE_REGS includes register saving
      and restoring when necessary in order to prevent register leakage
      between the worlds.
      
      Change-Id: I2d4ea993d6b11654ea0d4757d00ca20d23acf36c
      Signed-off-by: default avatarJustin Chadwell <justin.chadwell@arm.com>
      9dd94382
  5. 28 Jun, 2019 1 commit
  6. 26 Jun, 2019 1 commit
  7. 24 May, 2019 1 commit
    • Alexei Fedorov's avatar
      Add support for Branch Target Identification · 9fc59639
      Alexei Fedorov authored
      
      
      This patch adds the functionality needed for platforms to provide
      Branch Target Identification (BTI) extension, introduced to AArch64
      in Armv8.5-A by adding BTI instruction used to mark valid targets
      for indirect branches. The patch sets new GP bit [50] to the stage 1
      Translation Table Block and Page entries to denote guarded EL3 code
      pages which will cause processor to trap instructions in protected
      pages trying to perform an indirect branch to any instruction other
      than BTI.
      BTI feature is selected by BRANCH_PROTECTION option which supersedes
      the previous ENABLE_PAUTH used for Armv8.3-A Pointer Authentication
      and is disabled by default. Enabling BTI requires compiler support
      and was tested with GCC versions 9.0.0, 9.0.1 and 10.0.0.
      The assembly macros and helpers are modified to accommodate the BTI
      instruction.
      This is an experimental feature.
      Note. The previous ENABLE_PAUTH build option to enable PAuth in EL3
      is now made as an internal flag and BRANCH_PROTECTION flag should be
      used instead to enable Pointer Authentication.
      Note. USE_LIBROM=1 option is currently not supported.
      
      Change-Id: Ifaf4438609b16647dc79468b70cd1f47a623362e
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      9fc59639
  8. 02 May, 2019 1 commit
    • Christoph Müllner's avatar
      build_macros: Add mechanism to prevent bin generation. · 9e4609f1
      Christoph Müllner authored
      
      
      On certain platforms it does not make sense to generate
      TF-A binary images. For example a platform could make use of serveral
      memory areas, which are non-continuous and the resulting binary
      therefore would suffer from the padding-bytes.
      Typically these platforms use the ELF image.
      
      This patch introduces a variable DISABLE_BIN_GENERATION, which
      can be set to '1' in the platform makefile to prevent the binary
      generation.
      Signed-off-by: default avatarChristoph Müllner <christophm30@gmail.com>
      Change-Id: I62948e88bab685bb055fe6167d9660d14e604462
      9e4609f1
  9. 28 Feb, 2019 1 commit
  10. 27 Feb, 2019 2 commits
    • Antonio Nino Diaz's avatar
      Add support for pointer authentication · b86048c4
      Antonio Nino Diaz authored
      
      
      The previous commit added the infrastructure to load and save
      ARMv8.3-PAuth registers during Non-secure <-> Secure world switches, but
      didn't actually enable pointer authentication in the firmware.
      
      This patch adds the functionality needed for platforms to provide
      authentication keys for the firmware, and a new option (ENABLE_PAUTH) to
      enable pointer authentication in the firmware itself. This option is
      disabled by default, and it requires CTX_INCLUDE_PAUTH_REGS to be
      enabled.
      
      Change-Id: I35127ec271e1198d43209044de39fa712ef202a5
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      b86048c4
    • Antonio Nino Diaz's avatar
      Add ARMv8.3-PAuth registers to CPU context · 5283962e
      Antonio Nino Diaz authored
      
      
      ARMv8.3-PAuth adds functionality that supports address authentication of
      the contents of a register before that register is used as the target of
      an indirect branch, or as a load.
      
      This feature is supported only in AArch64 state.
      
      This feature is mandatory in ARMv8.3 implementations.
      
      This feature adds several registers to EL1. A new option called
      CTX_INCLUDE_PAUTH_REGS has been added to select if the TF needs to save
      them during Non-secure <-> Secure world switches. This option must be
      enabled if the hardware has the registers or the values will be leaked
      during world switches.
      
      To prevent leaks, this patch also disables pointer authentication in the
      Secure world if CTX_INCLUDE_PAUTH_REGS is 0. Any attempt to use it will
      be trapped in EL3.
      
      Change-Id: I27beba9907b9a86c6df1d0c5bf6180c972830855
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      5283962e
  11. 05 Feb, 2019 1 commit
  12. 30 Jan, 2019 1 commit
  13. 22 Jan, 2019 1 commit
  14. 10 Dec, 2018 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Deprecate the current implementation · 2d7b9e5e
      Antonio Nino Diaz authored
      
      
      The current SPM is a prototype that only supports one secure partition
      in EL0. The objective of SPM is to have multiple partitions. The current
      MM interface isn't adequate for this, so it is needed to modify heavily
      the code to add proper support for it.
      
      However, there are platforms which are already using this (like SGI) and
      removing the code would break it.  For this reason, the current SPM code
      has been duplicated in order to temporarily preserve compatibility. All
      new improvements/changes to SPM will be done in the non-deprecated copy,
      that may change without notice.
      
      The new build option SPM_DEPRECATED has been introduced to select the SPM
      implementation. It defaults to 1, that selects the deprecated SPM.
      
      Change-Id: Ic9f80b53b450e97b4d3f47e4ef4a138ee8d87443
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2d7b9e5e
  15. 29 Oct, 2018 1 commit
  16. 03 Oct, 2018 1 commit
    • Daniel Boulby's avatar
      Introduce RECLAIM_INIT_CODE build flag · 1dcc28cf
      Daniel Boulby authored
      
      
      This patch introduces a build flag "RECLAIM_INIT_CODE" to mark boot time
      code which allows platforms to place this memory in an appropriate
      section to be reclaimed later. This features is primarily targeted for
      BL31. Appropriate documentation updates are also done.
      
      Change-Id: If0ca062851614805d769c332c771083d46599194
      Signed-off-by: default avatarDaniel Boulby <daniel.boulby@arm.com>
      1dcc28cf
  17. 28 Sep, 2018 3 commits
  18. 30 Aug, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Allow manually setting the AArch32 instruction set · 8fd9d4d5
      Antonio Nino Diaz authored
      
      
      At the moment the AArch32 instruction set isn't specified in the command
      line, which means that the compiler is free to choose the one it sees
      fit. This decision may change between compiler versions, so it is better
      to specify it manually.
      
      The build option AARCH32_INSTRUCTION_SET has been introduced for this
      reason. This option can be set to T32 or A32 to pass the correct flags
      to the compiler.
      
      The current behaviour is to default to T32 due to it's smaller size.
      
      Change-Id: I02297eb1d9404b5868ff7c054fbff9b3cda7fdb6
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      8fd9d4d5
  19. 20 Aug, 2018 1 commit
    • Jeenu Viswambharan's avatar
      AArch64: Enable MPAM for lower ELs · 5f835918
      Jeenu Viswambharan authored
      
      
      Memory Partitioning And Monitoring is an Armv8.4 feature that enables
      various memory system components and resources to define partitions.
      Software running at various ELs can then assign themselves to the
      desired partition to control their performance aspects.
      
      With this patch, when ENABLE_MPAM_FOR_LOWER_ELS is set to 1, EL3 allows
      lower ELs to access their own MPAM registers without trapping to EL3.
      This patch however doesn't make use of partitioning in EL3; platform
      initialisation code should configure and use partitions in EL3 if
      required.
      
      Change-Id: I5a55b6771ccaa0c1cffc05543d2116b60cbbcdcd
      Co-authored-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      5f835918
  20. 03 Aug, 2018 1 commit
    • Roberto Vargas's avatar
      Add support for romlib in the build system · 5accce5b
      Roberto Vargas authored
      
      
      Romlib is a new image that is stored in ROM and contains the code of
      several libraries that can be shared between different images. All
      the functions within in the library are accessed using a jump table
      which allows to update the romlib image whithout changing the binary
      compatibility. This jump table can be also stored in RAM and it can
      allow to patch a romlib with potential bugs fixes..
      
      Change-Id: If980ccdaca24b7aaca900e32acc68baf6f94ab35
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      5accce5b
  21. 18 May, 2018 1 commit
  22. 04 May, 2018 3 commits
    • Jeenu Viswambharan's avatar
      RAS: Add fault injection support · 1a7c1cfe
      Jeenu Viswambharan authored
      
      
      The ARMv8.4 RAS extensions introduce architectural support for software
      to inject faults into the system in order to test fault-handling
      software. This patch introduces the build option FAULT_HANDLING_SUPPORT
      to allow for lower ELs to use registers in the Standard Error Record to
      inject fault. The build option RAS_EXTENSIONS must also be enabled along
      with fault injection.
      
      This feature is intended for testing purposes only, and is advisable to
      keep disabled for production images.
      
      Change-Id: I6f7a4454b15aec098f9505a10eb188c2f928f7ea
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      1a7c1cfe
    • Jeenu Viswambharan's avatar
      AArch64: Introduce RAS handling · 14c6016a
      Jeenu Viswambharan authored
      
      
      RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional
      extensions to base ARMv8.0 architecture.
      
      This patch adds build system support to enable RAS features in ARM
      Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for
      this.
      
      With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is
      inserted at all EL3 vector entry and exit. ESBs will synchronize pending
      external aborts before entering EL3, and therefore will contain and
      attribute errors to lower EL execution. Any errors thus synchronized are
      detected via. DISR_EL1 register.
      
      When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1.
      
      Change-Id: I38a19d84014d4d8af688bd81d61ba582c039383a
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      14c6016a
    • Jeenu Viswambharan's avatar
      AArch64: Introduce External Abort handling · 76454abf
      Jeenu Viswambharan authored
      
      
      At present, any External Abort routed to EL3 is reported as an unhandled
      exception and cause a panic. This patch enables ARM Trusted Firmware to
      handle External Aborts routed to EL3.
      
      With this patch, when an External Abort is received at EL3, its handling
      is delegated to plat_ea_handler() function. Platforms can provide their
      own implementation of this function. This patch adds a weak definition
      of the said function that prints out a message and just panics.
      
      In order to support handling External Aborts at EL3, the build option
      HANDLE_EA_EL3_FIRST must be set to 1.
      
      Before this patch, HANDLE_EA_EL3_FIRST wasn't passed down to
      compilation; this patch fixes that too.
      
      Change-Id: I4d07b7e65eb191ff72d63b909ae9512478cd01a1
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      76454abf
  23. 23 Apr, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Add support for the SMC Calling Convention 2.0 · 2f370465
      Antonio Nino Diaz authored
      
      
      Due to differences in the bitfields of the SMC IDs, it is not possible
      to support SMCCC 1.X and 2.0 at the same time.
      
      The behaviour of `SMCCC_MAJOR_VERSION` has changed. Now, it is a build
      option that specifies the major version of the SMCCC that the Trusted
      Firmware supports. The only two allowed values are 1 and 2, and it
      defaults to 1. The value of `SMCCC_MINOR_VERSION` is derived from it.
      
      Note: Support for SMCCC v2.0 is an experimental feature to enable
      prototyping of secure partition specifications. Support for this
      convention is disabled by default and could be removed without notice.
      
      Change-Id: I88abf9ccf08e9c66a13ce55c890edea54d9f16a7
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2f370465
  24. 07 Apr, 2018 1 commit
    • Jiafei Pan's avatar
      Add support for BL2 in XIP memory · 7d173fc5
      Jiafei Pan authored
      
      
      In some use-cases BL2 will be stored in eXecute In Place (XIP) memory,
      like BL1. In these use-cases, it is necessary to initialize the RW sections
      in RAM, while leaving the RO sections in place. This patch enable this
      use-case with a new build option, BL2_IN_XIP_MEM. For now, this option
      is only supported when BL2_AT_EL3 is 1.
      Signed-off-by: default avatarJiafei Pan <Jiafei.Pan@nxp.com>
      7d173fc5
  25. 01 Mar, 2018 1 commit
    • Dan Handley's avatar
      Improve MULTI_CONSOLE_API deprecation warnings · bc1a03c7
      Dan Handley authored
      
      
      For platforms that have not migrated to MULTI_CONSOLE_API == 1, there
      are a lot of confusing deprecated declaration warnings relating to
      use of console_init() and console_uninit(). Some of these relate to use
      by the generic code, not the platform code. These functions are not really
      deprecated but *removed* when MULTI_CONSOLE_API == 1.
      
      This patch consolidates these warnings into a single preprocessor warning.
      The __deprecated attribute is removed from the console_init() and
      console_uninit() declarations.
      
      For preprocessor warnings like this to not cause fatal build errors,
      this patch adds -Wno-error=cpp to the build flags when
      ERROR_DEPRECATED == 0.
      This option (and -Wno-error=deprecated-declarations) is now added to
      CPPFLAGS instead of TF_CFLAGS to ensure the build flags are used in the
      assembler as well as the compiler.
      
      This patch also disentangles the MULTI_CONSOLE_API and ERROR_DEPRECATED
      build flags by defaulting MULTI_CONSOLE_API to 0 instead of
      ERROR_DEPRECATED. This allows platforms that have not migrated to
      MULTI_CONSOLE_API to use ERROR_DEPRECATED == 1 to emit a more meaningful
      build error.
      
      Finally, this patch bans use of MULTI_CONSOLE_API == 1 and AARCH32, since
      the AArch32 console implementation does not support
      MULTI_CONSOLE_API == 1.
      
      Change-Id: If762165ddcb90c28aa7a4951aba70cb15c2b709c
      Signed-off-by: default avatarDan Handley <dan.handley@arm.com>
      bc1a03c7
  26. 19 Jan, 2018 1 commit
    • Julius Werner's avatar
      Add platform-independent coreboot support library · 3429c77a
      Julius Werner authored
      
      
      This patch adds the foundation for a platform-independent coreboot
      support library that can be shared by all platforms that boot BL31 from
      coreboot (acting as BL2). It adds code to parse the "coreboot table", a
      data structure that coreboot uses to communicate different kinds of
      information to later-stage firmware and certain OS drivers.
      
      As a first small use case for this information, allow platforms to
      access the serial console configuration used by coreboot, removing the
      need to hardcode base address and divisors and allowing Trusted Firmware
      to benefit from coreboot's user configuration (e.g. which UART to pick
      and which baud rate to use).
      
      Change-Id: I2bfb39cd2609ce6640b844ab68df6c9ae3f28e9e
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      3429c77a
  27. 18 Jan, 2018 1 commit
    • Roberto Vargas's avatar
      bl2-el3: Add BL2_EL3 image · b1d27b48
      Roberto Vargas authored
      
      
      This patch enables BL2 to execute at the highest exception level
      without any dependancy on TF BL1. This enables platforms which already
      have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL
      stages without need for BL1.  This is not currently possible because
      BL2 executes at S-EL1 and cannot jump straight to EL3.
      
      Change-Id: Ief1efca4598560b1b8c8e61fbe26d1f44e929d69
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      b1d27b48
  28. 12 Dec, 2017 1 commit
    • Julius Werner's avatar
      Add new function-pointer-based console API · 9536bae6
      Julius Werner authored
      
      
      This patch overhauls the console API to allow for multiple console
      instances of different drivers that are active at the same time. Instead
      of binding to well-known function names (like console_core_init),
      consoles now provide a register function (e.g. console_16550_register())
      that will hook them into the list of active consoles. All console
      operations will be dispatched to all consoles currently in the list.
      
      The new API will be selected by the build-time option MULTI_CONSOLE_API,
      which defaults to ${ERROR_DEPRECATED} for now. The old console API code
      will be retained to stay backwards-compatible to older platforms, but
      should no longer be used for any newly added platforms and can hopefully
      be removed at some point in the future.
      
      The new console API is intended to be used for both normal (bootup) and
      crash use cases, freeing platforms of the need to set up the crash
      console separately. Consoles can be individually configured to be active
      active at boot (until first handoff to EL2), at runtime (after first
      handoff to EL2), and/or after a crash. Console drivers should set a sane
      default upon registration that can be overridden with the
      console_set_scope() call. Code to hook up the crash reporting mechanism
      to this framework will be added with a later patch.
      
      This patch only affects AArch64, but the new API could easily be ported
      to AArch32 as well if desired.
      
      Change-Id: I35c5aa2cb3f719cfddd15565eb13c7cde4162549
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      9536bae6
  29. 30 Nov, 2017 1 commit
    • David Cunado's avatar
      Enable SVE for Non-secure world · 1a853370
      David Cunado authored
      
      
      This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set
      to one EL3 will check to see if the Scalable Vector Extension (SVE) is
      implemented when entering and exiting the Non-secure world.
      
      If SVE is implemented, EL3 will do the following:
      
      - Entry to Non-secure world: SIMD, FP and SVE functionality is enabled.
      
      - Exit from Non-secure world: SIMD, FP and SVE functionality is
        disabled. As SIMD and FP registers are part of the SVE Z-registers
        then any use of SIMD / FP functionality would corrupt the SVE
        registers.
      
      The build option default is 1. The SVE functionality is only supported
      on AArch64 and so the build option is set to zero when the target
      archiecture is AArch32.
      
      This build option is not compatible with the CTX_INCLUDE_FPREGS - an
      assert will be raised on platforms where SVE is implemented and both
      ENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1.
      
      Also note this change prevents secure world use of FP&SIMD registers on
      SVE-enabled platforms. Existing Secure-EL1 Payloads will not work on
      such platforms unless ENABLE_SVE_FOR_NS is set to 0.
      
      Additionally, on the first entry into the Non-secure world the SVE
      functionality is enabled and the SVE Z-register length is set to the
      maximum size allowed by the architecture. This includes the use case
      where EL2 is implemented but not used.
      
      Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7dae
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      1a853370
  30. 29 Nov, 2017 1 commit
  31. 23 Nov, 2017 1 commit
    • Matt Ma's avatar
      Replace macro ASM_ASSERTION with macro ENABLE_ASSERTIONS · 5f70d8de
      Matt Ma authored
      
      
      This patch replaces the macro ASM_ASSERTION with the macro
      ENABLE_ASSERTIONS in ARM Cortex-A53/57/72 MPCore Processor
      related files. There is build error when ASM_ASSERTION is set
      to 1 and ENABLE_ASSERTIONS is set to 0 because function
      asm_assert in common/aarch32/debug.S is defined in the macro
      ENABLE_ASSERTIONS but is called with the macro ASM_ASSERTION.
      
      There is also the indication to use ENABLE_ASSERTIONS but not
      ASM_ASSERTION in the Makefile.
      Signed-off-by: default avatarMatt Ma <matt.ma@spreadtrum.com>
      5f70d8de
  32. 20 Nov, 2017 1 commit
  33. 13 Nov, 2017 2 commits
    • Jeenu Viswambharan's avatar
      BL31: Add SDEI dispatcher · b7cb133e
      Jeenu Viswambharan authored
      The implementation currently supports only interrupt-based SDEI events,
      and supports all interfaces as defined by SDEI specification version
      1.0 [1].
      
      Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in
      BL31.
      
      Update user guide and porting guide. SDEI documentation to follow.
      
      [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
      
      
      
      Change-Id: I758b733084e4ea3b27ac77d0259705565842241a
      Co-authored-by: default avatarYousuf A <yousuf.sait@arm.com>
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      b7cb133e
    • Jeenu Viswambharan's avatar
      BL31: Introduce Exception Handling Framework · 21b818c0
      Jeenu Viswambharan authored
      
      
      EHF is a framework that allows dispatching of EL3 interrupts to their
      respective handlers in EL3.
      
      This framework facilitates the firmware-first error handling policy in
      which asynchronous exceptions may be routed to EL3. Such exceptions may
      be handed over to respective exception handlers. Individual handlers
      might further delegate exception handling to lower ELs.
      
      The framework associates the delegated execution to lower ELs with a
      priority value. For interrupts, this corresponds to the priorities
      programmed in GIC; for other types of exceptions, viz. SErrors or
      Synchronous External Aborts, individual dispatchers shall explicitly
      associate delegation to a secure priority. In order to prevent lower
      priority interrupts from preempting higher priority execution, the
      framework provides helpers to control preemption by virtue of
      programming Priority Mask register in the interrupt controller.
      
      This commit allows for handling interrupts targeted at EL3. Exception
      handlers own interrupts by assigning them a range of secure priorities,
      and registering handlers for each priority range it owns.
      
      Support for exception handling in BL31 image is enabled by setting the
      build option EL3_EXCEPTION_HANDLING=1.
      
      Documentation to follow.
      
      NOTE: The framework assumes the priority scheme supported by platform
      interrupt controller is compliant with that of ARM GIC architecture (v2
      or later).
      
      Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      21b818c0
  34. 08 Nov, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Introduce Secure Partition Manager · 2fccb228
      Antonio Nino Diaz authored
      
      
      A Secure Partition is a software execution environment instantiated in
      S-EL0 that can be used to implement simple management and security
      services. Since S-EL0 is an unprivileged exception level, a Secure
      Partition relies on privileged firmware e.g. ARM Trusted Firmware to be
      granted access to system and processor resources. Essentially, it is a
      software sandbox that runs under the control of privileged software in
      the Secure World and accesses the following system resources:
      
      - Memory and device regions in the system address map.
      - PE system registers.
      - A range of asynchronous exceptions e.g. interrupts.
      - A range of synchronous exceptions e.g. SMC function identifiers.
      
      A Secure Partition enables privileged firmware to implement only the
      absolutely essential secure services in EL3 and instantiate the rest in
      a partition. Since the partition executes in S-EL0, its implementation
      cannot be overly complex.
      
      The component in ARM Trusted Firmware responsible for managing a Secure
      Partition is called the Secure Partition Manager (SPM). The SPM is
      responsible for the following:
      
      - Validating and allocating resources requested by a Secure Partition.
      - Implementing a well defined interface that is used for initialising a
        Secure Partition.
      - Implementing a well defined interface that is used by the normal world
        and other secure services for accessing the services exported by a
        Secure Partition.
      - Implementing a well defined interface that is used by a Secure
        Partition to fulfil service requests.
      - Instantiating the software execution environment required by a Secure
        Partition to fulfil a service request.
      
      Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Co-authored-by: default avatarAchin Gupta <achin.gupta@arm.com>
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2fccb228