1. 10 Mar, 2020 1 commit
  2. 06 Mar, 2020 1 commit
  3. 26 Feb, 2020 1 commit
    • Masahiro Yamada's avatar
      uniphier: prepare uniphier_soc_info() for next SoC · dd53cfe1
      Masahiro Yamada authored
      
      
      The revision register address will be changed in the next SoC.
      
      The LSI revision is needed in order to know where the revision
      register is located, but you need to read out the revision
      register for that. This is impossible.
      
      We need to know the revision register address by other means.
      Use BL_CODE_BASE, where the base address of the TF image that is
      currently running. If it is bigger than 0x80000000 (i.e. the DRAM
      base is 0x80000000), we assume it is a legacy SoC.
      
      Change-Id: I9d7f4325fe2085a8a1ab5310025e5948da611256
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      dd53cfe1
  4. 25 Feb, 2020 2 commits
  5. 12 Feb, 2020 11 commits
  6. 07 Feb, 2020 1 commit
  7. 28 Jan, 2020 1 commit
  8. 24 Jan, 2020 7 commits
  9. 26 Dec, 2019 1 commit
  10. 25 Dec, 2019 1 commit
  11. 20 Dec, 2019 2 commits
    • Paul Beesley's avatar
      spm-mm: Refactor secure_partition.h and its contents · aeaa225c
      Paul Beesley authored
      
      
      Before adding any new SPM-related components we should first do
      some cleanup around the existing SPM-MM implementation. The aim
      is to make sure that any SPM-MM components have names that clearly
      indicate that they are MM-related. Otherwise, when adding new SPM
      code, it could quickly become confusing as it would be unclear to
      which component the code belongs.
      
      The secure_partition.h header is a clear example of this, as the
      name is generic so it could easily apply to any SPM-related code,
      when it is in fact SPM-MM specific.
      
      This patch renames the file and the two structures defined within
      it, and then modifies any references in files that use the header.
      
      Change-Id: I44bd95fab774c358178b3e81262a16da500fda26
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      aeaa225c
    • Paul Beesley's avatar
      Remove dependency between SPM_MM and ENABLE_SPM build flags · 3f3c341a
      Paul Beesley authored
      
      
      There are two different implementations of Secure Partition
      management in TF-A. One is based on the "Management Mode" (MM)
      design, the other is based on the Secure Partition Client Interface
      (SPCI) specification. Currently there is a dependency between their
      build flags that shouldn't exist, making further development
      harder than it should be. This patch removes that
      dependency, making the two flags function independently.
      
      Before: ENABLE_SPM=1 is required for using either implementation.
              By default, the SPCI-based implementation is enabled and
              this is overridden if SPM_MM=1.
      
      After: ENABLE_SPM=1 enables the SPCI-based implementation.
             SPM_MM=1 enables the MM-based implementation.
             The two build flags are mutually exclusive.
      
      Note that the name of the ENABLE_SPM flag remains a bit
      ambiguous - this will be improved in a subsequent patch. For this
      patch the intention was to leave the name as-is so that it is
      easier to track the changes that were made.
      
      Change-Id: I8e64ee545d811c7000f27e8dc8ebb977d670608a
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      3f3c341a
  12. 03 Sep, 2019 1 commit
  13. 31 Jul, 2019 2 commits
  14. 12 Jul, 2019 1 commit
  15. 05 Jul, 2019 1 commit
    • Masahiro Yamada's avatar
      uniphier: support console based on multi-console · ac9f1b55
      Masahiro Yamada authored
      
      
      The legacy console is gone. Re-add the console support based on the
      multi-console framework.
      
      I am still keeping the putc, getc, and flush callbacks in
      uniphier_console.S to use plat/common/aarch64/crash_console_helpers.S
      
      The console registration code already relies on that C environment
      has been set up. So, I just filled the struct console fields with the
      callback pointers, then called console_register() directly. I also
      re-implemented the init function in C to improve the readability.
      
      Removing the custom crash console implementation has one disadvantage;
      we cannot use the crash console on very early crashes because
      crash_console_helpers.S works only after the console is registered.
      I can live with this limitation.
      
      Tested on my boards, and confirmed this worked like before.
      
      Change-Id: Ieab9c849853ff6c525c15ea894a85944f257db59
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      ac9f1b55
  16. 28 Jun, 2019 1 commit
  17. 12 Apr, 2019 1 commit
    • Ambroise Vincent's avatar
      Mbed TLS: Remove weak heap implementation · 2374ab17
      Ambroise Vincent authored
      
      
      The implementation of the heap function plat_get_mbedtls_heap() becomes
      mandatory for platforms supporting TRUSTED_BOARD_BOOT.
      
      The shared Mbed TLS heap default weak function implementation is
      converted to a helper function get_mbedtls_heap_helper() which can be
      used by the platforms for their own function implementation.
      
      Change-Id: Ic8f2994e25e3d9fcd371a21ac459fdcafe07433e
      Signed-off-by: default avatarAmbroise Vincent <ambroise.vincent@arm.com>
      2374ab17
  18. 13 Mar, 2019 2 commits
  19. 01 Feb, 2019 2 commits