1. 11 Jun, 2018 1 commit
  2. 07 Jun, 2018 2 commits
    • Soby Mathew's avatar
      docs: Firmware design update for BL memory layout · 0f57fabf
      Soby Mathew authored
      
      
      This patch updates the firmware design guide for the BL memory
      layout change on ARM platforms.
      
      Change-Id: Icbfe7249484bb8b4ba3c94421172d42f27605c52
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      0f57fabf
    • 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
  3. 24 May, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: SPM: Force BL31 to DRAM when SPM is used · e829a379
      Antonio Nino Diaz authored
      
      
      BL31 is running out of space, and the use-case of SPM doesn't require it
      to be in SRAM. To prevent BL31 from running out of space in the future,
      move BL31 to DRAM if SPM is enabled.
      
      Secure Partition Manager design document updated to reflect the changes.
      
      Increased the size of the stack of BL31 for builds with SPM.
      
      The translation tables used by SPM in Arm platforms have been moved back
      to the 'xlat_tables' region instead of 'arm_el3_tzc_dram'. Everything is
      in DRAM now, so it doesn't make sense to treat them in a different way.
      
      Change-Id: Ia6136c8e108b8da9edd90e9d72763dada5e5e5dc
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      e829a379
  4. 23 May, 2018 2 commits
    • Dimitris Papastamos's avatar
      Add support for dynamic mitigation for CVE-2018-3639 · fe007b2e
      Dimitris Papastamos authored
      
      
      Some CPUS may benefit from using a dynamic mitigation approach for
      CVE-2018-3639.  A new SMC interface is defined to allow software
      executing in lower ELs to enable or disable the mitigation for their
      execution context.
      
      It should be noted that regardless of the state of the mitigation for
      lower ELs, code executing in EL3 is always mitigated against
      CVE-2018-3639.
      
      NOTE: This change is a compatibility break for any platform using
      the declare_cpu_ops_workaround_cve_2017_5715 macro.  Migrate to
      the declare_cpu_ops_wa macro instead.
      
      Change-Id: I3509a9337ad217bbd96de9f380c4ff8bf7917013
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      fe007b2e
    • Dimitris Papastamos's avatar
      Implement static workaround for CVE-2018-3639 · b8a25bbb
      Dimitris Papastamos authored
      For affected CPUs, this approach enables the mitigation during EL3
      initialization, following every PE reset. No mechanism is provided to
      disable the mitigation at runtime.
      
      This approach permanently mitigates the entire software stack and no
      additional mitigation code is required in other software components.
      
      TF-A implements this approach for the following affected CPUs:
      
      *   Cortex-A57 and Cortex-A72, by setting bit 55 (Disable load pass store) of
          `CPUACTLR_EL1` (`S3_1_C15_C2_0`).
      
      *   Cortex-A73, by setting bit 3 of `S3_0_C15_C0_0` (not documented in the
          Technical Reference Manual (TRM)).
      
      *   Cortex-A75, by setting bit 35 (reserved in TRM) of `CPUACTLR_EL1`
          (`S3_0_C15_C1_0`).
      
      Additionally, a new SMC interface is implemented to allow software
      executing in lower ELs to discover whether the system is mitigated
      against CVE-2018-3639.
      
      Refer to "Firmware interfaces for mitigating cache speculation
      vulnerabilities System Software on Arm Systems"[0] for more
      information.
      
      [0] https://developer.arm.com/cache-speculation-vulnerability-firmware-specification
      
      
      
      Change-Id: I084aa7c3bc7c26bf2df2248301270f77bed22ceb
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      b8a25bbb
  5. 21 May, 2018 1 commit
  6. 18 May, 2018 1 commit
  7. 14 May, 2018 2 commits
    • Sandrine Bailleux's avatar
      Fix doc for bl31_plat_get_next_image_ep_info() · 1ec1ebf7
      Sandrine Bailleux authored
      
      
      In the porting guide, fix the function name and the argument type to
      reflect the code.
      
      Change-Id: Iac8d69af403194de5586bc0d5890da531e3c8da2
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      1ec1ebf7
    • 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
  8. 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
  9. 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
  10. 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
  11. 10 Apr, 2018 2 commits
  12. 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
  13. 03 Apr, 2018 1 commit
  14. 27 Mar, 2018 1 commit
    • Antonio Nino Diaz's avatar
      rpi3: Use new console APIs · e0f21f62
      Antonio Nino Diaz authored
      
      
      Switch to the new console APIs enabled by setting MULTI_CONSOLE_API=1.
      
      The crash console doesn't use this API, it uses internally the core
      functions of the 16550 console.
      
      `bl31_plat_runtime_setup` is no longer needed. When this platform port
      was introduced, that function used to disable the console. It was needed
      to override that behaviour. The new behaviour is to switch to the
      runtime console. The console is registered for all scopes (boot, crash
      and runtime) in `rpi3_console_init` so it is not needed to override the
      default behaviour anymore.
      
      Update documentation.
      
      Change-Id: If2ee8f91044216183b7ef142e5c05ad6220ae92f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      e0f21f62
  15. 21 Mar, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Rename 'smcc' to 'smccc' · 085e80ec
      Antonio Nino Diaz authored
      
      
      When the source code says 'SMCC' it is talking about the SMC Calling
      Convention. The correct acronym is SMCCC. This affects a few definitions
      and file names.
      
      Some files have been renamed (smcc.h, smcc_helpers.h and smcc_macros.S)
      but the old files have been kept for compatibility, they include the
      new ones with an ERROR_DEPRECATED guard.
      
      Change-Id: I78f94052a502436fdd97ca32c0fe86bd58173f2f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      085e80ec
  16. 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
  17. 15 Mar, 2018 3 commits
  18. 13 Mar, 2018 1 commit
  19. 05 Mar, 2018 3 commits
  20. 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
  21. 27 Feb, 2018 2 commits
  22. 26 Feb, 2018 2 commits
    • Soby Mathew's avatar
      BL1: Deprecate the `bl1_init_bl2_mem_layout()` API · 101d01e2
      Soby Mathew authored
      
      
      The `bl1_init_bl2_mem_layout()` API is now deprecated. The default weak
      implementation of `bl1_plat_handle_post_image_load()` calculates the
      BL2 memory layout and populates the same in x1(r1). This ensures
      compatibility for the deprecated API.
      
      Change-Id: Id44bdc1f572dc42ee6ceef4036b3a46803689315
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      101d01e2
    • 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
  23. 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
  24. 06 Feb, 2018 3 commits
    • Jeenu Viswambharan's avatar
      interrupt-framework-design.rst: Cosmetic changes · fb750ee1
      Jeenu Viswambharan authored
      
      
      Change-Id: Id2e2800af59ca35fc0c4cfdddd9f5c5afd56a4db
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      fb750ee1
    • 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
    • Jeenu Viswambharan's avatar
      Deprecate one EL3 interrupt routing model with EL3 exception handling · 26ea3908
      Jeenu Viswambharan authored
      
      
      When ARM Trusted Firmware is built with EL3_EXCEPTION_HANDLING=1,
      EL3 interrupts (INTR_TYPE_EL3) will always preempt both Non-secure and
      secure execution.
      
      The interrupt management framework currently treats EL3 interrupt
      routing as valid. For the above reason, this patch makes them invalid
      when EL3_EXCEPTION_HANDLING is in effect.
      
      Change-Id: I95bca8f5dc8df8eb0ff6f305cfba098611522a39
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      26ea3908
  25. 01 Feb, 2018 2 commits
  26. 29 Jan, 2018 1 commit