1. 11 Jul, 2018 1 commit
  2. 03 Jul, 2018 1 commit
    • Sandrine Bailleux's avatar
      AArch32: Force compiler to align memory accesses · a9c4dde3
      Sandrine Bailleux authored
      Alignment fault checking is always enabled in TF (by setting the
      SCTLR.A bit). Thus, all instructions that load or store one or more
      registers have an alignment check that the address being accessed is
      aligned to the size of the data element(s) being accessed. If this
      check fails it causes an Alignment fault, which is taken as a Data
      Abort exception.
      
      The compiler needs to be aware that it must not emit load and store
      instructions resulting in unaligned accesses. It already is for
      AArch64 builds (see commit fa1d3712
      
       "Add -mstrict-align to the gcc
      options"), this patch does the same for AArch32 builds.
      
      Change-Id: Ic885796bc6ed0ff392aae2d49f3a13f517e0169f
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      a9c4dde3
  3. 18 Jun, 2018 1 commit
    • Yann Gautier's avatar
      Build: add cpp build processing for dtb · 01d237cb
      Yann Gautier authored
      
      
      This is an add-on feature that allows processing
      device tree with external includes.
      
      "-Iinclude" is also added to INCLUDES.
      It allows inclusion of dt-bindings files either in dts files or drivers,
      as those files will be in include/dt-bindings/.
      
      "-i fdts" is added to the DTC command line.
      As the pre-processed files are in build directory, the DT source directory
      has to be explicitely included, to manages /include/ directives.
      
      fixes arm-software/tf-issues#595
      Signed-off-by: default avatarLionel Debieve <lionel.debieve@st.com>
      Signed-off-by: default avatarYann Gautier <yann.gautier@st.com>
      01d237cb
  4. 18 May, 2018 1 commit
  5. 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
  6. 01 May, 2018 1 commit
    • Roberto Vargas's avatar
      Remove the unused macro NDEBUG · 379dcab7
      Roberto Vargas authored
      
      
      The C standards specify that this macro is used to
      disable asserts but, in our code, the assert macro
      is controlled with ENABLE_ASSERTIONS. Having this macro
      here creates confusion about the behaviour of assert.
      
      Change-Id: Iab8689a14dc2b8790729857d56585ce43c0c4f51
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      379dcab7
  7. 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
  8. 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
  9. 03 Apr, 2018 1 commit
  10. 20 Mar, 2018 1 commit
  11. 16 Mar, 2018 1 commit
  12. 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
  13. 28 Feb, 2018 1 commit
  14. 26 Feb, 2018 2 commits
    • Soby Mathew's avatar
      Makefile: Add `all` target to MAKE_DTBS · 38c14d88
      Soby Mathew authored
      
      
      This patch makes some minor changes to `MAKE_DTBS` make macro
      and adds `dtbs` target to the `all` make target.
      
      Change-Id: I1c5b4a603ada31d2dac2ed73da9ff707b410dd11
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      38c14d88
    • Soby Mathew's avatar
      Add image_id to bl1_plat_handle_post/pre_image_load() · 566034fc
      Soby Mathew authored
      
      
      This patch adds an argument to bl1_plat_post/pre_image_load() APIs
      to make it more future proof. The default implementation of
      these are moved to `plat_bl1_common.c` file.
      
      These APIs are now invoked appropriately in the FWU code path prior
      to or post image loading by BL1 and are not restricted
      to LOAD_IMAGE_V2.
      
      The patch also reorganizes some common platform files. The previous
      `plat_bl2_el3_common.c` and `platform_helpers_default.c` files are
      merged into a new `plat_bl_common.c` file.
      
      NOTE: The addition of an argument to the above mentioned platform APIs
      is not expected to have a great impact because these APIs were only
      recently added and are unlikely to be used.
      
      Change-Id: I0519caaee0f774dd33638ff63a2e597ea178c453
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      566034fc
  15. 06 Feb, 2018 1 commit
  16. 01 Feb, 2018 6 commits
    • Masahiro Yamada's avatar
      plat/common: move arch-agnostic fallback functions to C file · 0fc50a86
      Masahiro Yamada authored
      
      
      When we add a new callback, we need to duplicate fallbacks among
      plat/common/{aarch32,aarch64}/platform_helpers.S  This is tedious.
      
      I created a new C file, then moved 3 functions:
        plat_error_handler
        bl2_plat_preload_setup
        plat_try_next_boot_source
      
      They are called from C, so I do not see a good reason to implement
      them in assembly.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      0fc50a86
    • Masahiro Yamada's avatar
      Build: change the first parameter of TOOL_ADD_IMG to lowercase · 33950dd8
      Masahiro Yamada authored
      
      
      In the next commit, I need the image name in lowercase because
      output files are generally named in lowercase.
      
      Unfortunately, TOOL_ADD_IMG takes the first argument in uppercase
      since we generally use uppercase Make variables.
      
      make_helpers/build_macros.mk provides 'uppercase' macro to convert
      a string into uppercase, but 'lowercase' does not exist.  We can
      implement it if we like, but it would be more straightforward to
      change the argument of TOOL_ADD_IMG.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      33950dd8
    • Masahiro Yamada's avatar
      Build: rename FIP_ADD_IMG to TOOL_ADD_IMG · c939d13a
      Masahiro Yamada authored
      
      
      Now FIP_ADD_IMG takes care of both fiptool and cert_create
      symmetrically.  Rename it so that it matches the behavior.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      c939d13a
    • Masahiro Yamada's avatar
      Build: merge build macros between FIP_ and FWU_FIP_ · 1dc0714f
      Masahiro Yamada authored
      
      
      The build system supports generating two FIP images, fip and fwu_fip.
      Accordingly, we have similar build macros.
      
         FIP_ADD_PAYLOAD   <-->  FWU_FIP_ADD_PAYLOAD
         CERT_ADD_CMD_OPT  <-->  FWU_CERT_ADD_CMD_OPT
         FIP_ADD_IMG       <-->  FWU_FIP_ADD_IMG
      
      The duplicated code increases the maintenance burden.  Also, the build
      rule of BL2U looks clumsy - we want to call MAKE_BL to compile it from
      source files, but we want to put it in fwu_fip.  We can not do it in a
      single macro call since the current MAKE_BL does not support fwu_fip.
      
      To refactor those in a clean way is to support one more argument to
      specify the FIP prefix.  If it is empty, the images are targeted to
      fip, whereas if the argument is "FWU_", targeted to fwu_fip.
      
      The build macros prefixed with FWU_ go away.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      1dc0714f
    • Masahiro Yamada's avatar
      Build: refactor BL32 build rules · 9cd15239
      Masahiro Yamada authored
      This complicated if-conditional combo was introduced by commit
      70d1fc53
      
       ("Fix build error when `BL32` is not defined") in order
      to fix the compile error of "make all" when SPD=opteed is given.
      
      The requirement for the build system is like follows:
      
       - If both BL32 and BL32_SOURCES are defined, the former takes
         precedence.
      
       - If BL32 is undefined but BL32_SOURCES is defined, we compile
         BL32 from the source files.
      
       - We want to let the build fail if neither of them is defined,
         but we want to check it only when we are building FIP.
      
      Refactor the code to not call FIP_ADD_IMG twice.  The behavior is
      still the same.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      9cd15239
    • Masahiro Yamada's avatar
      Build: replace $(call MAKE_TOOL_ARGS,...) with $(call FIP_ADD_IMG,...) · 76d27d24
      Masahiro Yamada authored
      
      
      We use $(call MAKE_TOOL_ARGS,...) or $(call FIP_ADD_IMG,...) where we
      expect externally built images.  The difference between the two is
      check_* target.  It now checks if the given path exists, so it is a
      good thing to use $(call FIP_ADD_IMG,...) in all the places.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      76d27d24
  17. 29 Jan, 2018 2 commits
    • Julius Werner's avatar
      Makefile: Use ld.bfd linker if available · b25a577f
      Julius Werner authored
      
      
      Some toolchain distributions install both the BFD and GOLD linkers under
      the names <target>-ld.bfd and <target>-ld.gold. <target>-ld will then be
      a symlink that may point to either one of these.
      
      Trusted Firmware should always be linked with the BFD linker, since GOLD
      is meant primarily for userspace programs and doesn't support many of
      the more obscure linker script features that may be needed for firmware.
      With this patch the Makefile will auto-detect if ld.bfd is available and
      use it explicitly in that case.
      
      Change-Id: I7017055f67db3bd57d191d20a7af06ca646937d7
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      b25a577f
    • Antonio Nino Diaz's avatar
      Analyze coding style of patches individually · 51d28937
      Antonio Nino Diaz authored
      
      
      With the old system `checkpatch.pl` gets one sole input that consists of
      the commit message and commit diff of each commit between BASE_COMMIT
      and HEAD. It also filters out changes in some files, which makes `git
      format-patch` completely ignore that commit, even the commit message.
      
      With the new system the commit message and commit diff are analyzed
      separately. This means that, even if all the files modified by a commit
      are filtered out, the commit message will still be analyzed.
      
      Also, all commits are analyzed individually. This way it's easier to
      know which commit caused the problem, and there are no warnings about
      repeated "Signed-off-by" lines.
      
      Change-Id: Ic676a0b76801bb2607141a8d73dc3a942dc01c0e
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      51d28937
  18. 23 Jan, 2018 1 commit
    • Steve Capper's avatar
      Correct the Makefile logic for disabling PIE · d1156e0b
      Steve Capper authored
      In the Makefile we use findstring to locate gcc toolchains
      that have PIE enabled by default.
      
      Unfortunately the result of findstring is compared against
      an integer, 1, rather than a non-empty string; the logic to
      disable PIE then doesn't get applied.
      
      This patch fixes the flag test.
      
      Fixes: f7ec31db
      
       ("Disable PIE compilation option")
      Change-Id: I4cd2866974e313d6b408f9681311d78a208ab468
      Signed-off-by: default avatarSteve Capper <steve.capper@arm.com>
      d1156e0b
  19. 18 Jan, 2018 2 commits
    • Roberto Vargas's avatar
      bl2-el3: Don't include BL2 in fip for BL2 at EL3 · c9b31ae8
      Roberto Vargas authored
      
      
      It is better to not include BL2 in FIP when using `BL2 at EL3` as
      platforms using this config would not have the capability to parse the
      FIP format in Boot ROM and BL2 needs to be loaded independently. This
      patch does the required changes for the same.
      
      Change-Id: Iad285c247b3440e2d827fef97c3dd81f5c09cabc
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      c9b31ae8
    • 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
  20. 14 Dec, 2017 1 commit
  21. 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
  22. 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
  23. 29 Nov, 2017 2 commits
    • Soby Mathew's avatar
      ARM platforms: Fixup AArch32 builds · 5744e874
      Soby Mathew authored
      
      
      This patch fixes a couple of issues for AArch32 builds on ARM reference
      platforms :
      
      1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and
         AArch32 build. Since BL31 is not present in AArch32 mode, this meant that
         the BL31 memory is empty when built for AArch32. Hence this patch allocates
         BL32 to the memory region occupied by BL31 for AArch32 builds.
      
         As a side-effect of this change, the ARM_TSP_RAM_LOCATION macro cannot
         be used to control the load address of BL32 in AArch32 mode which was
         never the intention of the macro anyway.
      
      2. A static assert is added to sp_min linker script to check that the progbits
         are within the bounds expected when overlaid with other images.
      
      3. Fix specifying `SPD` when building Juno for AArch32 mode. Due to the quirks
         involved when building Juno for AArch32 mode, the build option SPD needed to
         specifed. This patch corrects this and also updates the documentation in the
         user-guide.
      
      4. Exclude BL31 from the build and FIP when building Juno for AArch32 mode. As
         a result the previous assumption that BL31 must be always present is removed
         and the certificates for BL31 is only generated if `NEED_BL31` is defined.
      
      Change-Id: I1c39bbc0abd2be8fbe9f2dea2e9cb4e3e3e436a8
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      5744e874
    • Dimitris Papastamos's avatar
      Implement support for the Activity Monitor Unit on Cortex A75 · 0319a977
      Dimitris Papastamos authored
      
      
      The Cortex A75 has 5 AMU counters.  The first three counters are fixed
      and the remaining two are programmable.
      
      A new build option is introduced, `ENABLE_AMU`.  When set, the fixed
      counters will be enabled for use by lower ELs.  The programmable
      counters are currently disabled.
      
      Change-Id: I4bd5208799bb9ed7d2596e8b0bfc87abbbe18740
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      0319a977
  24. 24 Nov, 2017 1 commit
  25. 20 Nov, 2017 1 commit
    • Dimitris Papastamos's avatar
      Refactor Statistical Profiling Extensions implementation · 281a08cc
      Dimitris Papastamos authored
      
      
      Factor out SPE operations in a separate file.  Use the publish
      subscribe framework to drain the SPE buffers before entering secure
      world.  Additionally, enable SPE before entering normal world.
      
      A side effect of this change is that the profiling buffers are now
      only drained when a transition from normal world to secure world
      happens.  Previously they were drained also on return from secure
      world, which is unnecessary as SPE is not supported in S-EL1.
      
      Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      281a08cc
  26. 08 Nov, 2017 2 commits
    • 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
    • Etienne Carriere's avatar
      ARMv7 target is driven by ARM_ARCH_MAJOR==7 · 26e63c44
      Etienne Carriere authored
      
      
      External build environment shall sets directive ARM_ARCH_MAJOR to 7
      to specify a target ARMv7-A core.
      
      As ARM-TF expects AARCH to be set, ARM_ARCH_MAJOR==7 mandates
      AARCH=aarch32.
      
      The toolchain target architecture/cpu is delegated after the platform
      configuration is parsed. Platform shall define target core through
      ARM_CORTEX_A<x>=yes, <x> being 5, 7, 9, 12, 15 and/or 17.
      
      Platform can bypass ARM_CORTEX_A<x>=yes directive and provide straight
      the toolchain target directive through MARCH32_DIRECTIVE.
      Signed-off-by: default avatarEtienne Carriere <etienne.carriere@linaro.org>
      26e63c44
  27. 06 Nov, 2017 1 commit
  28. 16 Oct, 2017 1 commit
    • Jeenu Viswambharan's avatar
      GIC: Add APIs to set interrupt type and query support · 74dce7fa
      Jeenu Viswambharan authored
      
      
      The back end GIC driver converts and assigns the interrupt type to
      suitable group.
      
      For GICv2, a build option GICV2_G0_FOR_EL3 is introduced, which
      determines to which type Group 0 interrupts maps to.
      
       - When the build option is set 0 (the default), Group 0 interrupts are
         meant for Secure EL1. This is presently the case.
      
       - Otherwise, Group 0 interrupts are meant for EL3. This means the SPD
         will have to synchronously hand over the interrupt to Secure EL1.
      
      The query API allows the platform to query whether the platform supports
      interrupts of a given type.
      
      API documentation updated.
      
      Change-Id: I60fdb4053ffe0bd006b3b20914914ebd311fc858
      Co-authored-by: default avatarYousuf A <yousuf.sait@arm.com>
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      74dce7fa