1. 21 Jun, 2018 1 commit
    • Jeenu Viswambharan's avatar
      SDEI: Allow platforms to define explicit events · af2c9ecd
      Jeenu Viswambharan authored
      
      
      The current macros only allow to define dynamic and statically-bound
      SDEI events. However, there ought be a mechanism to define SDEI events
      that are explicitly dispatched; i.e., events that are dispatched as a
      result of a previous secure interrupt or other exception
      
      This patch introduces SDEI_EXPLICIT_EVENT() macro to define an explicit
      event. They must be placed under private mappings. Only the priority
      flags are allowed to be additionally specified.
      
      Documentation updated.
      
      Change-Id: I2e12f5571381195d6234c9dfbd5904608ad41db3
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      af2c9ecd
  2. 19 Jun, 2018 4 commits
  3. 18 Jun, 2018 1 commit
  4. 15 Jun, 2018 1 commit
  5. 14 Jun, 2018 1 commit
  6. 13 Jun, 2018 1 commit
  7. 11 Jun, 2018 1 commit
  8. 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
  9. 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
  10. 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
  11. 21 May, 2018 1 commit
  12. 18 May, 2018 1 commit
  13. 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
  14. 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
  15. 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
  16. 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
  17. 10 Apr, 2018 2 commits
  18. 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
  19. 03 Apr, 2018 1 commit
  20. 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
  21. 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
  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 3 commits
  24. 13 Mar, 2018 1 commit
  25. 05 Mar, 2018 3 commits
  26. 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
  27. 27 Feb, 2018 2 commits