1. 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
  2. 24 Dec, 2017 1 commit
  3. 23 Dec, 2017 1 commit
  4. 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
  5. 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
  6. 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
  7. 21 Nov, 2017 1 commit
  8. 20 Nov, 2017 1 commit
  9. 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
  10. 08 Nov, 2017 5 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 may not support Generic Timer Extension · 86e26835
      Etienne Carriere authored
      
      
      If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform
      shall define ARMV7_SUPPORTS_GENERIC_TIMER to enable generic timer
      support.
      Signed-off-by: default avatarEtienne Carriere <etienne.carriere@linaro.org>
      86e26835
    • Etienne Carriere's avatar
      ARMv7 may not support Virtualization Extensions · 64cc6e91
      Etienne Carriere authored
      
      
      ARMv7-A Virtualization extensions brings new instructions and resources
      that were supported by later architectures. Reference ARM ARM Issue C.c
      [DDI0406C_C].
      
      ERET and extended MSR/MRS instructions, as specified in [DDI0406C_C] in
      ID_PFR1 description of bits[15:12] (Virtualization Extensions):
       A value of 0b0001 implies implementation of the HVC, ERET, MRS
       (Banked register), and MSR (Banked register) instructions. The ID_ISARs
       do not identify whether these instructions are implemented.
      
      UDIV/SDIV were introduced with the Virtualization extensions, even if
      not strictly related to the virtualization extensions.
      
      If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform
      shall define ARMV7_SUPPORTS_VIRTUALIZATION to enable virtualization
      extension related resources.
      Signed-off-by: default avatarEtienne Carriere <etienne.carriere@linaro.org>
      64cc6e91
    • Etienne Carriere's avatar
      ARMv7 may not support large page addressing · 51b992ec
      Etienne Carriere authored
      
      
      ARCH_SUPPORTS_LARGE_PAGE_ADDRESSING allows build environment to
      handle specific case when target ARMv7 core only supports 32bit MMU
      descriptor mode.
      
      If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform
      shall define ARMV7_SUPPORTS_LARGE_PAGE_ADDRESSING to enable
      large page addressing support.
      Signed-off-by: default avatarEtienne Carriere <etienne.carriere@linaro.org>
      51b992ec
    • 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
  11. 06 Nov, 2017 1 commit
  12. 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
  13. 20 Sep, 2017 1 commit
    • Nishanth Menon's avatar
      Makefile: Add ability to build dtb · 03b397a8
      Nishanth Menon authored
      This is a revamp of the original approach in:
      https://github.com/ARM-software/arm-trusted-firmware/pull/747
      
      
      
      Current build system has no means to automatically generate dtbs from
      dts, instead, stores the dtbs in the fdts/ folder. While this makes
      perfect sense for many reference platforms, this becomes a minor
      breakage in development flow for newer platforms.
      
      However, this can be solved by providing a rule for the dtbs while
      building the ATF binaries by purely describing which dts sources we
      need.
      
      For example, with this change, we will now be able to describe the
      dtbs we need for the platform in the corresponding platform.mk file:
      FDT_SOURCES += fdts/abc.dts
      
      This should be able to generate the abc.dtb appropriately.
      
      Since device trees are specification of hardware, we don't tie the rule
      to any specific BL, instead a generic rule is introduced.
      
      Further, this approach allows us to generate appropriate dtbs which may be
      need to be regenerated when a common dtsi gets updated, by just
      restricting changes to the dtsi alone, instead of synchronizing all the
      dtbs as well.
      
      If dtc is not available in default paths, but is available in an
      alternate location, it can be chosen by overriding the DTC variable
      such as 'make DTC=~/dtc/dtc ....`
      
      NOTE: dtbs are built only with the explicit make dtbs command. The rule
      is only available if the platform defines a FDT_SOURCES variable.
      Signed-off-by: default avatarBenjamin Fair <b-fair@ti.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      03b397a8
  14. 31 Aug, 2017 1 commit
    • Soby Mathew's avatar
      Export KEY_ALG as a user build option · 2091755c
      Soby Mathew authored
      
      
      The `KEY_ALG` variable is used to select the algorithm for key
      generation by `cert_create` tool for signing the certificates. This
      variable was previously undocumented and did not have a global default
      value. This patch corrects this and also adds changes to derive the
      value of `TF_MBEDTLS_KEY_ALG` based on `KEY_ALG` if it not set by the
      platform. The corresponding assignment of these variables are also now
      removed from the `arm_common.mk` makefile.
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Change-Id: I78e2d6f4fc04ed5ad35ce2266118afb63127a5a4
      2091755c
  15. 09 Aug, 2017 1 commit
  16. 01 Aug, 2017 1 commit
    • Jeenu Viswambharan's avatar
      CCI: Adapt for specific product at run time · e33fd445
      Jeenu Viswambharan authored
      
      
      The current build system and driver requires the CCI product to be
      specified at build time. The device constraints can be determined at run
      time from its ID registers, obviating the need for specifying them
      ahead.
      
      This patch adds changes to identify and validate CCI at run time. Some
      global variables are renamed to be in line with the rest of the code
      base.
      
      The build option ARM_CCI_PRODUCT_ID is now removed, and user guide is
      updated.
      
      Change-Id: Ibb765e349d3bc95ff3eb9a64bde1207ab710a93d
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      e33fd445
  17. 28 Jun, 2017 2 commits
  18. 22 Jun, 2017 1 commit
    • dp-arm's avatar
      aarch64: Enable Statistical Profiling Extensions for lower ELs · d832aee9
      dp-arm authored
      
      
      SPE is only supported in non-secure state.  Accesses to SPE specific
      registers from SEL1 will trap to EL3.  During a world switch, before
      `TTBR` is modified the SPE profiling buffers are drained.  This is to
      avoid a potential invalid memory access in SEL1.
      
      SPE is architecturally specified only for AArch64.
      
      Change-Id: I04a96427d9f9d586c331913d815fdc726855f6b0
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      d832aee9
  19. 01 Jun, 2017 1 commit
  20. 23 May, 2017 2 commits
    • Masahiro Yamada's avatar
      cert: move platform_oid.h to include/tools_share for all platforms · bb41eb7a
      Masahiro Yamada authored
      
      
      Platforms aligned with TBBR are supposed to use their own OIDs, but
      defining the same macros with different OIDs does not provide any
      value (at least technically).
      
      For easier use of TBBR, this commit allows platforms to reuse the OIDs
      obtained by ARM Ltd.  This will be useful for non-ARM vendors that
      do not need their own extension fields in their certificate files.
      
      The OIDs of ARM Ltd. have been moved to include/tools_share/tbbr_oid.h
      
      Platforms can include <tbbr_oid.h> instead of <platform_oid.h> by
      defining USE_TBBR_DEFS as 1.  USE_TBBR_DEFS is 0 by default to keep the
      backward compatibility.
      
      For clarification, I inserted a blank line between headers from the
      include/ directory (#include <...>) and ones from a local directory
      (#include "..." ).
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      bb41eb7a
    • Masahiro Yamada's avatar
      Build: fix assert_boolean implementation · be4cd40e
      Masahiro Yamada authored
      
      
      The current assert_boolean does not work with variables assigned with
      '=' flavor instead of ':='.
      
      For example,
      
       FOO = $(BAR)
       BAR := 1
      
      Here, $(value FOO) is evaluated to $(BAR), not 1.  This is not what
      we expect.  While I am here, I simplified the implementation.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      be4cd40e
  21. 15 May, 2017 1 commit
  22. 03 May, 2017 1 commit
  23. 02 May, 2017 2 commits
    • Evan Lloyd's avatar
      Build: Correct Unix specific echo commands · 052ab529
      Evan Lloyd authored
      
      
      Some recent changes have added direct use of the echo command without
      parameters.  This fails on a Windows shell, because echo without
      parameters reports the mode ("ECHO is on").
      This is corrected using the ECHO_BLANK_LINE macro already provided
      for that purpose.
      
      Change-Id: I5fd7192861b4496f6f46b4f096e80a752cd135d6
      Signed-off-by: default avatarEvan Lloyd <evan.lloyd@arm.com>
      052ab529
    • Evan Lloyd's avatar
      Build: Fix parallel build · 6ba7d274
      Evan Lloyd authored
      
      
      2 problems were found, but are in one change to avoid submitting a patch
      that might fail to build. The problems were:
      1.  The macro MAKE_PREREQ_DIR has a minor bug, in that it is capable of
          generating recursive dependencies.
      2.  The inclusion of BUILD_DIR in TEMP_OBJ_DIRS left no explicit
          dependency, BUILD_DIR might not exist when subdirectories are
          created by a thread on another CPU.
      
      This fix corrects these with the following changes:
      1.  MAKE_PREREQ_DIR does nothing for a direct self dependency.
      2.  BUILD_DIR is built using MAKE_PREREQ_DIR.
      3.  BUILD_DIR is an explicit prerequisite of all OBJ_DIRS.
      
      Change-Id: I938cddea4a006df225c02a47b9cf759212f27fb7
      Signed-off-by: default avatarEvan Lloyd <evan.lloyd@arm.com>
      6ba7d274
  24. 19 Apr, 2017 1 commit
    • Soby Mathew's avatar
      PSCI: Build option to enable D-Caches early in warmboot · bcc3c49c
      Soby Mathew authored
      
      
      This patch introduces a build option to enable D-cache early on the CPU
      after warm boot. This is applicable for platforms which do not require
      interconnect programming to enable cache coherency (eg: single cluster
      platforms). If this option is enabled, then warm boot path enables
      D-caches immediately after enabling MMU.
      
      Fixes ARM-Software/tf-issues#456
      
      Change-Id: I44c8787d116d7217837ced3bcf0b1d3441c8d80e
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      bcc3c49c
  25. 31 Mar, 2017 1 commit
    • Douglas Raillard's avatar
      Add support for GCC stack protection · 51faada7
      Douglas Raillard authored
      
      
      Introduce new build option ENABLE_STACK_PROTECTOR. It enables
      compilation of all BL images with one of the GCC -fstack-protector-*
      options.
      
      A new platform function plat_get_stack_protector_canary() is introduced.
      It returns a value that is used to initialize the canary for stack
      corruption detection. Returning a random value will prevent an attacker
      from predicting the value and greatly increase the effectiveness of the
      protection.
      
      A message is printed at the ERROR level when a stack corruption is
      detected.
      
      To be effective, the global data must be stored at an address
      lower than the base of the stacks. Failure to do so would allow an
      attacker to overwrite the canary as part of an attack which would void
      the protection.
      
      FVP implementation of plat_get_stack_protector_canary is weak as
      there is no real source of entropy on the FVP. It therefore relies on a
      timer's value, which could be predictable.
      
      Change-Id: Icaaee96392733b721fa7c86a81d03660d3c1bc06
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      51faada7
  26. 02 Mar, 2017 1 commit
  27. 14 Feb, 2017 1 commit
    • Jeenu Viswambharan's avatar
      Introduce locking primitives using CAS instruction · c877b414
      Jeenu Viswambharan authored
      
      
      The ARMv8v.1 architecture extension has introduced support for far
      atomics, which includes compare-and-swap. Compare and Swap instruction
      is only available for AArch64.
      
      Introduce build options to choose the architecture versions to target
      ARM Trusted Firmware:
      
        - ARM_ARCH_MAJOR: selects the major version of target ARM
          Architecture. Default value is 8.
      
        - ARM_ARCH_MINOR: selects the minor version of target ARM
          Architecture. Default value is 0.
      
      When:
      
        (ARM_ARCH_MAJOR > 8) || ((ARM_ARCH_MAJOR == 8) && (ARM_ARCH_MINOR >= 1)),
      
      for AArch64, Compare and Swap instruction is used to implement spin
      locks. Otherwise, the implementation falls back to using
      load-/store-exclusive instructions.
      
      Update user guide, and introduce a section in Firmware Design guide to
      summarize support for features introduced in ARMv8 Architecture
      Extensions.
      
      Change-Id: I73096a0039502f7aef9ec6ab3ae36680da033f16
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      c877b414
  28. 28 Jan, 2017 1 commit
    • Masahiro Yamada's avatar
      fiptool: support --align option to add desired alignment to image offset · 1c75d5df
      Masahiro Yamada authored
      
      
      The current fiptool packs all the images without any padding between
      them.  So, the offset to each image has no alignment.  This is not
      efficient, for example, when the FIP is read from a block-oriented
      device.
      
      For example, (e)MMC is accessed by block-addressing.  The block size
      is 512 byte.  So, the best case is each image is aligned by 512 byte
      since the DMA engine can transfer the whole of the image to its load
      address directly.  The worst case is the offset does not have even
      DMA-capable alignment (this is where we stand now).  In this case,
      we need to transfer every block to a bounce buffer, then do memcpy()
      from the bounce buffer to our final destination.  At least, this
      should work with the abstraction by the block I/O layer, but the
      CPU-intervention for the whole data transfer makes it really slow.
      
      This commit adds a new option --align to the fiptool.  This option,
      if given, requests the tool to align each component in the FIP file
      by the specified byte.  Also, add a new Make option FIP_ALIGN for
      easier access to this feature; users can give something like
      FIP_ALIGN=512 from the command line, or add "FIP_ALIGN := 512" to
      their platform.mk file.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      1c75d5df
  29. 19 Jan, 2017 2 commits