1. 26 Sep, 2019 1 commit
    • Madhukar Pappireddy's avatar
      GICv3: Enable multi socket GIC redistributor frame discovery · ec834925
      Madhukar Pappireddy authored
      
      
      This patch provides declaration and definition of new GICv3 driver
      API: gicv3_rdistif_probe().This function delegates the responsibility
      of discovering the corresponding Redistributor base frame to each CPU
      itself. It is a modified version of gicv3_rdistif_base_addrs_probe()
      and is executed by each CPU in the platform unlike the previous
      approach in which only the Primary CPU did the discovery of all the
      Redistributor frames for every CPU.
      
      The flush operations as part of gicv3_driver_init() function are
      made necessary even for platforms with WARMBOOT_ENABLE_DCACHE_EARLY
      because the GICv3 driver data structure contents are accessed by CPU
      with D-Cache turned off during power down operations.
      
      Change-Id: I1833e81d3974b32a3e4a3df4766a33d070982268
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      ec834925
  2. 18 Sep, 2019 1 commit
  3. 13 Sep, 2019 3 commits
  4. 12 Sep, 2019 2 commits
    • Justin Chadwell's avatar
      Remove RSA PKCS#1 v1.5 support from cert_tool · 6a415a50
      Justin Chadwell authored
      Support for PKCS#1 v1.5 was deprecated in SHA 1001202d and fully removed
      in SHA fe199e3b
      
      , however, cert_tool is still able to generate
      certificates in that form. This patch fully removes the ability for
      cert_tool to generate these certificates.
      
      Additionally, this patch also fixes a bug where the issuing certificate
      was a RSA and the issued certificate was EcDSA. In this case, the issued
      certificate would be signed using PKCS#1 v1.5 instead of RSAPSS per
      PKCS#1 v2.1, preventing TF-A from verifying the image signatures. Now
      that PKCS#1 v1.5 support is removed, all certificates that are signed
      with RSA now use the more modern padding scheme.
      
      Change-Id: Id87d7d915be594a1876a73080528d968e65c4e9a
      Signed-off-by: default avatarJustin Chadwell <justin.chadwell@arm.com>
      6a415a50
    • Justin Chadwell's avatar
      Support larger RSA key sizes when using MBEDTLS · aacff749
      Justin Chadwell authored
      
      
      Previously, TF-A could not support large RSA key sizes as the
      configuration options passed to MBEDTLS prevented storing and performing
      calculations with the larger, higher-precision numbers required. With
      these changes to the arguments passed to MBEDTLS, TF-A now supports
      using 3072 (3K) and 4096 (4K) keys in certificates.
      
      Change-Id: Ib73a6773145d2faa25c28d04f9a42e86f2fd555f
      Signed-off-by: default avatarJustin Chadwell <justin.chadwell@arm.com>
      aacff749
  5. 10 Sep, 2019 1 commit
  6. 05 Sep, 2019 2 commits
  7. 02 Sep, 2019 7 commits
  8. 29 Aug, 2019 9 commits
  9. 19 Aug, 2019 1 commit
  10. 16 Aug, 2019 2 commits
  11. 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
  12. 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
  13. 16 Jul, 2019 1 commit
  14. 15 Jul, 2019 1 commit
  15. 14 Jul, 2019 5 commits