1. 20 Sep, 2018 1 commit
  2. 11 Sep, 2018 1 commit
  3. 30 Aug, 2018 3 commits
    • Douglas Raillard's avatar
      backtrace: Introduce backtrace function · 0c62883f
      Douglas Raillard authored
      
      
      This function diplays the backtrace, the current EL and security state
      to allow a post-processing tool to choose the right binary to interpret
      the dump.
      
      The output can be fed to GNU addr2line to resolve function names given
      an ELF binary compiled with debug information. The "-i" flag is
      recommended to improve display in case of inlined functions. The *.dump
      files generated during the build process can also be used.
      
      The function works in AArch64 and AArch32. In AArch32 it only works in
      A32 mode (without T32 interworking), which is enforced in the Makefile.
      
      Sample output of a backtrace at EL3:
      
          BACKTRACE: START: function_name
          0: EL3: 0x798
          1: EL3: 0x538
          2: EL3: 0x550
          3: EL3: 0x55c
          4: EL3: 0x568
          5: EL3: 0x5a8
          6: EL3: 0xf4
          BACKTRACE: END: function_name
      
      In order to enable it the new option ENABLE_BACKTRACE must be set to 1.
      This option is set to 1 by default only in AArch64 debug builds. As
      usual, it can be overridden by the platform makefile and in the build
      command line.
      
      Change-Id: Icaff39b0e5188329728be2f3c72b868b2368e794
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      0c62883f
    • 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
    • Julius Werner's avatar
      context_mgmt: Fix HANDLE_EA_EL3_FIRST implementation · 24f671f3
      Julius Werner authored
      This patch fixes a bug in the context management code that causes it to
      ignore the HANDLE_EA_EL3_FIRST compile-time option and instead always
      configure SCR_EL3 to force all external aborts to trap into EL3. The
      code used #ifdef to read compile-time option declared with add_define in
      the Makefile... however, those options are always defined, they're just
      defined to either 0 or 1, so #if is the correct syntax to check for
      them. Also update the documentation to match.
      
      This bug has existed since the Nov 2017 commit 76454abf
      
       (AArch64:
      Introduce External Abort handling), which changed the
      HANDLE_EA_EL3_FIRST option to use add_define.
      
      Change-Id: I7189f41d0daee78fa2fcf4066323e663e1e04d3d
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      24f671f3
  4. 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
  5. 17 Aug, 2018 1 commit
  6. 24 Jul, 2018 1 commit
  7. 11 Jul, 2018 2 commits
  8. 10 Jul, 2018 1 commit
  9. 27 Jun, 2018 1 commit
    • Jeenu Viswambharan's avatar
      DynamIQ: Enable MMU without using stack · 64ee263e
      Jeenu Viswambharan authored
      
      
      Having an active stack while enabling MMU has shown coherency problems.
      This patch builds on top of translation library changes that introduces
      MMU-enabling without using stacks.
      
      Previously, with HW_ASSISTED_COHERENCY, data caches were disabled while
      enabling MMU only because of active stack. Now that we can enable MMU
      without using stack, we can enable both MMU and data caches at the same
      time.
      
      NOTE: Since this feature depends on using translation table library v2,
      disallow using translation table library v1 with HW_ASSISTED_COHERENCY.
      
      Fixes ARM-software/tf-issues#566
      
      Change-Id: Ie55aba0c23ee9c5109eb3454cb8fa45d74f8bbb2
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      64ee263e
  10. 22 Jun, 2018 1 commit
    • John Tsichritzis's avatar
      Fix typos in documentation · 677ad32c
      John Tsichritzis authored
      
      
      In the porting guide, there are blue boxes that describe the argument
      types and the return type of each function.  A small typo caused some of
      these boxes not being properly rendered.
      
      In the user guide, small typos were fixed that caused random text being
      unintentionally rendered as bold.  Also, a slight rewording was done in
      the section describing the DYN_DISABLE_AUTH flag.
      
      Change-Id: I57303ca609436a82162fa9b42c06b0d5a63da6df
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      677ad32c
  11. 18 Jun, 2018 1 commit
  12. 14 Jun, 2018 1 commit
  13. 07 Jun, 2018 1 commit
    • Soby Mathew's avatar
      ARM platforms: Move BL31 below BL2 to enable BL2 overlay · c099cd39
      Soby Mathew authored
      
      
      The patch changes the layout of BL images in memory to enable
      more efficient use of available space. Previously BL31 was loaded
      with the expectation that BL2 memory would be reclaimed by BL32
      loaded in SRAM. But with increasing memory requirements in the
      firmware, we can no longer fit BL32 in SRAM anymore which means the
      BL2 memory is not reclaimed by any runtime image. Positioning BL2
      below BL1-RW and above BL31 means that the BL31 NOBITS can be
      overlaid on BL2 and BL1-RW.
      
      This patch also propogates the same memory layout to BL32 for AArch32
      mode. The reset addresses for the following configurations are also
      changed :
         * When RESET_TO_SP_MIN=1 for BL32 in AArch32 mode
         * When BL2_AT_EL3=1 for BL2
      
      The restriction on BL31 to be only in DRAM when SPM is enabled
      is now removed with this change. The update to the firmware design
      guide for the BL memory layout is done in the following patch.
      
      Change-Id: Icca438e257abe3e4f5a8215f945b9c3f9fbf29c9
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      c099cd39
  14. 21 May, 2018 1 commit
  15. 18 May, 2018 1 commit
  16. 14 May, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Replace bootwrapped kernel instructions from User Guide · 32412a8a
      Antonio Nino Diaz authored
      
      
      The instructions to boot the bootwrapped kernel were outdated.
      
      Also, the bootwrapped kernel boot flow isn't really useful. It was meant
      to be a replacement for the Trusted Firmware-A, not to be used as the next
      step during boot.
      
      The instructions have been removed in favour of the new build option
      ARM_LINUX_KERNEL_AS_BL33. This new system directly boots the Linux
      kernel from BL31, and requires RESET_TO_BL31 to be 1. Also, the kernel
      has to be preloaded in memory, so PRELOADED_BL33_BASE has to be set to its
      address. This way, the runtime services of the Trusted Firmware-A are
      available for the kernel in the least possible amount of time.
      
      This new system requires the DTB to be patched so that the kernel knows
      where the ramdisk is. A short script to add this information to the DTB
      has been added to the User Guide. The information related to it can be
      found in the following file in the Linux kernel tree:
      ``Documentation/devicetree/bindings/chosen.txt``
      
      Change-Id: Ide135580959e09f6aa8e4425f37ea55d97439178
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      32412a8a
  17. 11 May, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Introduce ARM_LINUX_KERNEL_AS_BL33 build option · b726c169
      Antonio Nino Diaz authored
      
      
      Normally, BL33 needs to contain a boot loader like U-Boot or UEFI that
      eventually gives control to the OS. However, in some cases, this boot
      sequence may be too slow. For example, when doing tests in a
      cycle-accurate emulator, the user may only be interested in the
      interaction between the Trusted Firmware and the OS, not in the boot
      process itself.
      
      The new option ARM_LINUX_KERNEL_AS_BL33 allows BL33 to contain the Linux
      kernel image by changing the value of registers x0-x3 to the values
      expected by the kernel. This option requires the device tree blob (DTB)
      to be present in memory. Its address must be specified in the newly
      introduced ARM_PRELOADED_DTB_BASE build option. For now, it only supports
      AArch64 kernels.
      
      This option is only available when RESET_TO_BL31=1. For this reason
      the BL33 binary must be preloaded in memory and PRELOADED_BL33_BASE must
      be used.
      
      For example, if the kernel is loaded at 0x80080000 and the DTB is loaded
      at address 0x82000000, the firmware could be built like this:
      
          CROSS_COMPILE=aarch64-linux-gnu-  \
          make PLAT=fvp DEBUG=1             \
          RESET_TO_BL31=1                   \
          ARM_LINUX_KERNEL_AS_BL33=1        \
          PRELOADED_BL33_BASE=0x80080000    \
          ARM_PRELOADED_DTB_BASE=0x82000000 \
          all fip
      
      Change-Id: If9dc847c65ae2d0c27b51f0fd44fc06b28497db9
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      b726c169
  18. 04 May, 2018 2 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
  19. 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
  20. 10 Apr, 2018 1 commit
  21. 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
  22. 20 Mar, 2018 1 commit
    • Joel Hutton's avatar
      Update user guide · bf7008a8
      Joel Hutton authored
      
      
      Following Out of Box testing for v1.5 release:
      
          Update host OS version to Ubuntu 16.04
          Clarify configuration files needed for checkpatch
          Add note on using Linaro precompiled binaries
      
      Change-Id: Ia4ae61e01128ddff1a288972ddf84b79370fa52c
      Signed-off-by: default avatarJoel Hutton <Joel.Hutton@Arm.com>
      bf7008a8
  23. 15 Mar, 2018 2 commits
  24. 13 Mar, 2018 1 commit
  25. 28 Feb, 2018 1 commit
    • Jeenu Viswambharan's avatar
      FVP: Allow building for DynamIQ systems · fe7210cd
      Jeenu Viswambharan authored
      
      
      FVPs that model DynamIQ configuration implements all CPUs in a single
      cluster. I.e., such models have a single cluster with more than 4 CPUs.
      This differs from existing default build configuration for FVP where up
      to 4 CPUs are assumed per cluster.
      
      To allow building for DynamIQ configuration, promote the macro
      FVP_MAX_CPUS_PER_CLUSTER as a build option to have it set from the build
      command line. The value of the build option defaults to 4.
      
      Change-Id: Idc3853bc95f680869b434b011c2dbd733e40c6ce
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      fe7210cd
  26. 23 Feb, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Fix Foundation FVP instructions in User Guide · 38d96de6
      Antonio Nino Diaz authored
      
      
      The Arm Trusted Firmware is built by default for ARMv8-A version 8.0.
      However, the Foundation FVP runs by default in the highest version of
      the architecture it supports. This causes problems when trying to run
      the Arm Trusted Firmware on it.
      
      This patch adds a note to the User Guide about this problem.
      
      Change-Id: I0220fe1a9c66c2292149ad4a7ffe5e27ba08ab28
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      38d96de6
  27. 06 Feb, 2018 1 commit
    • Jeenu Viswambharan's avatar
      TSPD: Require NS preemption along with EL3 exception handling · 6027796f
      Jeenu Viswambharan authored
      
      
      At present, the build option TSP_NS_INTR_ASYNC_PREEMPT controls how
      Non-secure interrupt affects TSPs execution. When TSP is executing:
      
        1. When TSP_NS_INTR_ASYNC_PREEMPT=0, Non-secure interrupts are received
           at the TSP's exception vector, and TSP voluntarily preempts itself.
      
        2. When TSP_NS_INTR_ASYNC_PREEMPT=1, Non-secure interrupts causes a
           trap to EL3, which preempts TSP execution.
      
      When EL3 exception handling is in place (i.e.,
      EL3_EXCEPTION_HANDLING=1), FIQs are always trapped to EL3. On a system
      with GICv3, pending NS interrupts while TSP is executing will be
      signalled as FIQ (which traps to EL3). This situation necessitates the
      same treatment applied to case (2) above.
      
      Therefore, when EL3 exception handling is in place, additionally
      require that TSP_NS_INTR_ASYNC_PREEMPT is set to one 1.
      
      Strictly speaking, this is not required on a system with GICv2, but the
      same model is uniformly followed regardless, for simplicity.
      
      Relevant documentation updated.
      
      Change-Id: I928a8ed081fb0ac96e8b1dfe9375c98384da1ccd
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      6027796f
  28. 18 Jan, 2018 1 commit
  29. 21 Dec, 2017 1 commit
    • David Cunado's avatar
      Update dependencies for ARM TF · fa05efb3
      David Cunado authored
      
      
      ARM TF has been tested as part of its CI system with the following
      dependencies updated:
      
      - Linaro binaries:    17.04 --> 17.10
      - mbed TLS library:   2.4.2 --> 2.6.0
      
      The version of AEM, Cortex-A and Foundation models that ARM TF is
      tested on has also been updated:
      
      - v11.1 build 11.1:22 --> v11.2 build 11.2:33
      - v8.9 build 0.8:8805 --> v9.0 build 0.8:9005
      
      This patch updates the user guide documentation to reflect these
      changes to the dependencies.
      
      Additionally, links to Linaro resources have been updated.
      
      Change-Id: I9ea5cb76e7443c9dbb0c9525069f450a02f59e58
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      fa05efb3
  30. 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
  31. 29 Nov, 2017 3 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
      AMU: Implement support for aarch64 · 380559c1
      Dimitris Papastamos authored
      
      
      The `ENABLE_AMU` build option can be used to enable the
      architecturally defined AMU counters.  At present, there is no support
      for the auxiliary counter group.
      
      Change-Id: I7ea0c0a00327f463199d1b0a481f01dadb09d312
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      380559c1
    • 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
  32. 21 Nov, 2017 1 commit
  33. 20 Nov, 2017 1 commit