1. 29 Jun, 2020 1 commit
    • Masahiro Yamada's avatar
      uniphier: increase BL33 max size and GZIP temporary buffer size · 39784f2a
      Masahiro Yamada authored
      
      
      The current BL33 size is large enough for U-Boot, but we need to
      increase the limit to use other boot loaders such as edk2.
      
      Increase the buffer size used for GZIP decompression too.
      
       BL33 max size (UNIPHIER_BL33_MAX_SIZE):  1MB -> 8MB
       GZIP buffer (UNIPHIER_IMAGE_BUF_SIZE):   1MB -> 8MB
      
      Increasing the block buffer size (UNIPHIER_BLOCK_BUF_SIZE) is not
      required, but I increased it too to make it work more efficiently.
      
      Change-Id: I4fa6d795bed9ab9ada7f8f616c7d47076139e3a8
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      39784f2a
  2. 02 Jun, 2020 1 commit
    • Masahisa Kojima's avatar
      xlat_tables_v2: add base table section name parameter for spm_mm · 0922e481
      Masahisa Kojima authored
      Core spm_mm code expects the translation tables are located in the
      inner & outer WBWA & shareable memory.
      REGISTER_XLAT_CONTEXT2 macro is used to specify the translation
      table section in spm_mm.
      
      In the commit 363830df
      
       (xlat_tables_v2: merge
      REGISTER_XLAT_CONTEXT_{FULL_SPEC,RO_BASE_TABLE}), REGISTER_XLAT_CONTEXT2
      macro explicitly specifies the base xlat table goes into .bss by default.
      This change affects the existing SynQuacer spm_mm implementation.
      plat/socionext/synquacer/include/plat.ld.S linker script intends to
      locate ".bss.sp_base_xlat_table" into "sp_xlat_table" section,
      but this implementation is no longer available.
      
      This patch adds the base table section name parameter for
      REGISTER_XLAT_CONTEXT2 so that platform can specify the
      inner & outer WBWA & shareable memory for spm_mm base xlat table.
      If PLAT_SP_IMAGE_BASE_XLAT_SECTION_NAME is not defined, base xlat table
      goes into .bss by default, the result is same as before.
      
      Change-Id: Ie0e1a235e5bd4288dc376f582d6c44c5df6d31b2
      Signed-off-by: default avatarMasahisa Kojima <masahisa.kojima@linaro.org>
      0922e481
  3. 19 May, 2020 1 commit
  4. 02 Apr, 2020 3 commits
  5. 01 Apr, 2020 2 commits
  6. 30 Mar, 2020 1 commit
    • Alexei Fedorov's avatar
      TF-A GICv3 driver: Introduce makefile · a6ea06f5
      Alexei Fedorov authored
      
      
      This patch moves all GICv3 driver files into new added
      'gicv3.mk' makefile for the benefit of the generic driver
      which can evolve in the future without affecting platforms.
      The patch adds GICv3 driver configuration flags
      'GICV3_IMPL', 'GICV3_IMPL_GIC600_MULTICHIP' and
      'GICV3_OVERRIDE_DISTIF_PWR_OPS' described in
      'GICv3 driver options' section of 'build-option.rst'
      document.
      
      NOTE: Platforms with GICv3 driver need to be modified to
      include 'drivers/arm/gic/v3/gicv3.mk' in their makefiles.
      
      Change-Id: If055f6770ff20f5dee5a3c99ae7ced7cdcac5c44
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      a6ea06f5
  7. 10 Mar, 2020 1 commit
  8. 06 Mar, 2020 1 commit
  9. 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
  10. 25 Feb, 2020 2 commits
  11. 12 Feb, 2020 11 commits
  12. 07 Feb, 2020 1 commit
  13. 28 Jan, 2020 1 commit
  14. 24 Jan, 2020 7 commits
  15. 26 Dec, 2019 1 commit
  16. 25 Dec, 2019 1 commit
  17. 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
  18. 03 Sep, 2019 1 commit
  19. 31 Jul, 2019 1 commit
    • Masahiro Yamada's avatar
      uniphier: fix typo and coding style · 4dd4bde4
      Masahiro Yamada authored
      
      
      Fix the typo "warn" -> "warm".
      
      Also fix the following checkpatch.pl warnings:
      
        CHECK: Prefer using the BIT macro
        CHECK: No space is necessary after a cast
        CHECK: Alignment should match open parenthesis
        CHECK: Unnecessary parentheses around uniphier_io_policies[image_id].dev_handle
      
      Change-Id: Ic11eea2668c4bf2d1e8f089e6338ba7b7156d80b
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      4dd4bde4