1. 01 Aug, 2019 2 commits
    • Julius Werner's avatar
      Switch AARCH32/AARCH64 to __aarch64__ · 402b3cf8
      Julius Werner authored
      
      
      NOTE: AARCH32/AARCH64 macros are now deprecated in favor of __aarch64__.
      
      All common C compilers pre-define the same macros to signal which
      architecture the code is being compiled for: __arm__ for AArch32 (or
      earlier versions) and __aarch64__ for AArch64. There's no need for TF-A
      to define its own custom macros for this. In order to unify code with
      the export headers (which use __aarch64__ to avoid another dependency),
      let's deprecate the AARCH32 and AARCH64 macros and switch the code base
      over to the pre-defined standard macro. (Since it is somewhat
      unintuitive that __arm__ only means AArch32, let's standardize on only
      using __aarch64__.)
      
      Change-Id: Ic77de4b052297d77f38fc95f95f65a8ee70cf200
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      402b3cf8
    • Julius Werner's avatar
      Replace __ASSEMBLY__ with compiler-builtin __ASSEMBLER__ · d5dfdeb6
      Julius Werner authored
      
      
      NOTE: __ASSEMBLY__ macro is now deprecated in favor of __ASSEMBLER__.
      
      All common C compilers predefine a macro called __ASSEMBLER__ when
      preprocessing a .S file. There is no reason for TF-A to define it's own
      __ASSEMBLY__ macro for this purpose instead. To unify code with the
      export headers (which use __ASSEMBLER__ to avoid one extra dependency),
      let's deprecate __ASSEMBLY__ and switch the code base over to the
      predefined standard.
      
      Change-Id: Id7d0ec8cf330195da80499c68562b65cb5ab7417
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      d5dfdeb6
  2. 31 Jul, 2019 1 commit
  3. 25 Jul, 2019 2 commits
    • Gilad Ben-Yossef's avatar
      cryptocell: add product version awareness support · 76f3c7dc
      Gilad Ben-Yossef authored
      
      
      Add support for multiple Cryptocell revisions which
      use different APIs.
      
      This commit only refactors the existing code in preperation to the addition
      of another Cryptocell revisions later on.
      Signed-off-by: default avatarGilad Ben-Yossef <gilad.benyossef@arm.com>
      Change-Id: I16d80b31afb6edd56dc645fee5ea619cc74f09b6
      76f3c7dc
    • Gilad Ben-Yossef's avatar
      cryptocell: move Cryptocell specific API into driver · 36ec2bb0
      Gilad Ben-Yossef authored
      
      
      Code using Cryptocell specific APIs was used as part of the
      arm common board ROT support, instead of being abstracted
      in Cryptocell specific driver code, creating two problems:
      - Any none arm board that uses Cryptocell wuld need to
        copy and paste the same code.
      - Inability to cleanly support multiple versions of Cryptocell
        API and products.
      
      Move over Cryptocell specific API calls into the Cryptocell
      driver, creating abstraction API where needed.
      Signed-off-by: default avatarGilad Ben-Yossef <gilad.benyossef@arm.com>
      Change-Id: I9e03ddce90fcc47cfdc747098bece86dbd11c58e
      36ec2bb0
  4. 24 Jul, 2019 4 commits
    • John Tsichritzis's avatar
      SSBS: init SPSR register with default SSBS value · c250cc3b
      John Tsichritzis authored
      
      
      This patch introduces an additional precautionary step to further
      enhance protection against variant 4. During the context initialisation
      before we enter the various BL stages, the SPSR.SSBS bit is explicitly
      set to zero. As such, speculative loads/stores are by default disabled
      for all BL stages when they start executing. Subsequently, each BL
      stage, can choose to enable speculative loads/stores or keep them
      disabled.
      
      This change doesn't affect the initial execution context of BL33 which
      is totally platform dependent and, thus, it is intentionally left up to
      each platform to initialise.
      
      For Arm platforms, SPSR.SSBS is set to zero for BL33 too. This means
      that, for Arm platforms, all BL stages start with speculative
      loads/stores disabled.
      
      Change-Id: Ie47d39c391d3f20fc2852fc59dbd336f8cacdd6c
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      c250cc3b
    • Julius Werner's avatar
      Add helper to parse BL31 parameters (both versions) · d9af1f7b
      Julius Werner authored
      BL31 used to take a single bl31_params_t parameter structure with entry
      point information in arg0. In commit 72600226
      
       (Add new version of image
      loading.) this API was changed to a more flexible linked list approach,
      and the old parameter structure was copied into all platforms that still
      used the old format. This duplicated code unnecessarily among all these
      platforms.
      
      This patch adds a helper function that platforms can optionally link to
      outsource the task of interpreting arg0. Many platforms are just
      interested in the BL32 and BL33 entry point information anyway. Since
      some platforms still need to support the old version 1 parameters, the
      helper will support both formats when ERROR_DEPRECATED == 0. This allows
      those platforms to drop a bunch of boilerplate code and asynchronously
      update their BL2 implementation to the newer format.
      
      Change-Id: I9e6475adb1a7d4bccea666118bd1c54962e9fc38
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      d9af1f7b
    • Julius Werner's avatar
      Factor out cross-BL API into export headers suitable for 3rd party code · 57bf6057
      Julius Werner authored
      
      
      This patch adds a new include/export/ directory meant for inclusion in
      third-party code. This is useful for cases where third-party code needs
      to interact with TF-A interfaces and data structures (such as a custom
      BL2-implementation like coreboot handing off to BL31). Directly
      including headers from the TF-A repository avoids having to duplicate
      all these definitions (and risk them going stale), but with the current
      header structure this is not possible because handoff API definitions
      are too deeply intertwined with other TF code/headers and chain-include
      other headers that will not be available in the other environment.
      
      The new approach aims to solve this by separating only the parts that
      are really needed into these special headers that are self-contained and
      will not chain-include other (non-export) headers. TF-A code should
      never include them directly but should instead always include the
      respective wrapper header, which will include the required prerequisites
      (like <stdint.h>) before including the export header. Third-party code
      can include the export headers via its own wrappers that make sure the
      necessary definitions are available in whatever way that environment can
      provide them.
      
      Change-Id: Ifd769320ba51371439a8e5dd5b79c2516c3b43ab
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      57bf6057
    • Julius Werner's avatar
      Use explicit-width data types in AAPCS parameter structs · 9352be88
      Julius Werner authored
      
      
      It's not a good idea to use u_register_t for the members of
      aapcs64_params_t and aapcs32_params_t, since the width of that type
      always depends on the current execution environment. This would cause
      problems if e.g. we used this structure to set up the entry point of an
      AArch32 program from within an AArch64 program. (It doesn't seem like
      any code is doing that today, but it's probably still a good idea to
      write this defensively. Also, it helps with my next patch.)
      
      Change-Id: I12c04a85611f2b6702589f3362bea3e6a7c9f776
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      9352be88
  5. 23 Jul, 2019 1 commit
    • Ambroise Vincent's avatar
      arm: Shorten the Firmware Update (FWU) process · 37b70031
      Ambroise Vincent authored
      
      
      The watchdog is configured with a default value of 256 seconds in order
      to implement the Trusted Board Boot Requirements.
      
      For the FVP and Juno platforms, the FWU process relies on a watchdog
      reset. In order to automate the test of FWU, the length of this process
      needs to be as short as possible. Instead of waiting for those 4 minutes
      to have a reset by the watchdog, tell it to reset immediately.
      
      There are no side effects as the value of the watchdog's load register
      resets to 0xFFFFFFFF.
      
      Tested on Juno.
      
      Change-Id: Ib1aea80ceddc18ff1e0813a5b98dd141ba8a3ff2
      Signed-off-by: default avatarAmbroise Vincent <ambroise.vincent@arm.com>
      37b70031
  6. 18 Jul, 2019 1 commit
    • Julius Werner's avatar
      Introduce lightweight BL platform parameter library · b852d229
      Julius Werner authored
      
      
      This patch adds some common helper code to support a lightweight
      platform parameter passing framework between BLs that has already been
      used on Rockchip platforms but is more widely useful to others as well.
      It can be used as an implementation for the SoC firmware configuration
      file mentioned in the docs, and is primarily intended for platforms
      that only require a handful of values to be passed and want to get by
      without a libfdt dependency. Parameters are stored in a linked list and
      the parameter space is split in generic and vendor-specific parameter
      types. Generic types will be handled by this code whereas
      vendor-specific types have to be handled by a vendor-specific handler
      function that gets passed in.
      
      Change-Id: If3413d44e86b99d417294ce8d33eb2fc77a6183f
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      b852d229
  7. 16 Jul, 2019 3 commits
  8. 12 Jul, 2019 2 commits
  9. 10 Jul, 2019 3 commits
  10. 02 Jul, 2019 8 commits
  11. 28 Jun, 2019 1 commit
  12. 26 Jun, 2019 1 commit
    • Manoj Kumar's avatar
      n1sdp: add code for DDR ECC enablement and BL33 copy to DDR · de8bc83e
      Manoj Kumar authored
      
      
      N1SDP platform supports RDIMMs with ECC capability. To use the ECC
      capability, the entire DDR memory space has to be zeroed out before
      enabling the ECC bits in DMC620. Zeroing out several gigabytes of
      memory from SCP is quite time consuming so functions are added that
      zeros out the DDR memory from application processor which is
      much faster compared to SCP. BL33 binary cannot be copied to DDR memory
      before enabling ECC so this is also done by TF-A from IOFPGA-DDR3
      memory to main DDR4 memory after ECC is enabled.
      
      Original PLAT_PHY_ADDR_SPACE_SIZE was limited to 36-bits with which
      the entire DDR space cannot be accessed as DRAM2 starts in base
      0x8080000000. So these macros are redefined for all ARM platforms.
      
      Change-Id: If09524fb65b421b7a368b1b9fc52c49f2ddb7846
      Signed-off-by: default avatarManoj Kumar <manoj.kumar3@arm.com>
      de8bc83e
  13. 17 Jun, 2019 3 commits
  14. 13 Jun, 2019 2 commits
    • Marek Vasut's avatar
      rcar_gen3: console: Convert to multi-console API · 018358fc
      Marek Vasut authored
      
      
      Convert the R-Car Gen3 platform and both SCIF and Log drivers
      to multi-console API.
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      Change-Id: I18556973937d150b60453f9150d54ee612571e35
      018358fc
    • Sandrine Bailleux's avatar
      Fix type of cot_desc_ptr · 2efb7ddc
      Sandrine Bailleux authored
      
      
      The chain of trust description and the pointer pointing to its first
      element were incompatible, thus requiring an explicit type cast for
      the assignment.
      
      - cot_desc was an array of
        const pointers to const image descriptors.
      
      - cot_desc_ptr was a const pointer to
        (non-constant) pointers to const image descriptors.
      
      Thus, trying to assign cot_desc to cot_desc_ptr (with no cast) would
      generate the following compiler warning:
      
      drivers/auth/tbbr/tbbr_cot.c:826:14: warning: initialization discards
        ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
       REGISTER_COT(cot_desc);
                    ^~~~~~~~
      
      Change-Id: Iae62dd1bdb43fe379e3843d96461d47cc2f68a06
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      2efb7ddc
  15. 06 Jun, 2019 1 commit
  16. 28 May, 2019 1 commit
  17. 24 May, 2019 1 commit
    • Alexei Fedorov's avatar
      Add support for Branch Target Identification · 9fc59639
      Alexei Fedorov authored
      
      
      This patch adds the functionality needed for platforms to provide
      Branch Target Identification (BTI) extension, introduced to AArch64
      in Armv8.5-A by adding BTI instruction used to mark valid targets
      for indirect branches. The patch sets new GP bit [50] to the stage 1
      Translation Table Block and Page entries to denote guarded EL3 code
      pages which will cause processor to trap instructions in protected
      pages trying to perform an indirect branch to any instruction other
      than BTI.
      BTI feature is selected by BRANCH_PROTECTION option which supersedes
      the previous ENABLE_PAUTH used for Armv8.3-A Pointer Authentication
      and is disabled by default. Enabling BTI requires compiler support
      and was tested with GCC versions 9.0.0, 9.0.1 and 10.0.0.
      The assembly macros and helpers are modified to accommodate the BTI
      instruction.
      This is an experimental feature.
      Note. The previous ENABLE_PAUTH build option to enable PAuth in EL3
      is now made as an internal flag and BRANCH_PROTECTION flag should be
      used instead to enable Pointer Authentication.
      Note. USE_LIBROM=1 option is currently not supported.
      
      Change-Id: Ifaf4438609b16647dc79468b70cd1f47a623362e
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      9fc59639
  18. 15 May, 2019 1 commit
    • Sami Mujawar's avatar
      Add option for defining platform DRAM2 base · 6bb6015f
      Sami Mujawar authored
      
      
      The default DRAM2 base address for Arm platforms
      is 0x880000000. However, on some platforms the
      firmware may want to move the start address to
      a different value.
      
      To support this introduce PLAT_ARM_DRAM2_BASE that
      defaults to 0x880000000; but can be overridden by
      a platform (e.g. in platform_def.h).
      
      Change-Id: I0d81195e06070bc98f376444b48ada2db1666e28
      Signed-off-by: default avatarSami Mujawar <sami.mujawar@arm.com>
      6bb6015f
  19. 10 May, 2019 1 commit
    • Alexei Fedorov's avatar
      SMMUv3: Abort DMA transactions · 1461ad9f
      Alexei Fedorov authored
      
      
      For security DMA should be blocked at the SMMU by default
      unless explicitly enabled for a device. SMMU is disabled
      after reset with all streams bypassing the SMMU, and
      abortion of all incoming transactions implements a default
      deny policy on reset.
      This patch also moves "bl1_platform_setup()" function from
      arm_bl1_setup.c to FVP platforms' fvp_bl1_setup.c and
      fvp_ve_bl1_setup.c files.
      
      Change-Id: Ie0ffedc10219b1b884eb8af625bd4b6753749b1a
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      1461ad9f
  20. 07 May, 2019 1 commit