Skip to content

GitLab

Switch branch/tag
  1. 02 Apr, 2020 1 commit
    • Masahiro Yamada's avatar
      Pass more -D options to BL*_CPPFLAGS instead of BL*_CFLAGS · 9cefb4b1
      Masahiro Yamada authored 
      Commit d5e97a1d ("Build: define IMAGE_AT_EL1 or IMAGE_AT_EL3
globally for C files") does not have commit 848a7e8c ("Build:
introduce per-BL CPPFLAGS and ASFLAGS") as an ancestor because
they were pulled almost at the same time.

This is a follow-up conversion to be consistent with commit
11a3c5ee

 ("plat: pass -D option to BL*_CPPFLAGS instead of
BL*_CFLAGS").

With this change, the command line option, IMAGE_AT_EL3, will be
passed to .S files as well.

I remove the definition in include/lib/cpus/aarch64/cpu_macros.S

Otherwise, the following error would happen.

  include/lib/cpus/aarch64/cpu_macros.S:29:0: error: "IMAGE_AT_EL3" redefined [-Werror]

Change-Id: I943c8f22356483c2ae3c57b515c69243a8fa6889
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      9cefb4b1
  3. 01 Apr, 2020 2 commits
  5. 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
  9. 06 Mar, 2020 1 commit
  11. 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
  13. 25 Feb, 2020 2 commits
  15. 12 Feb, 2020 11 commits
  17. 07 Feb, 2020 1 commit
  19. 28 Jan, 2020 1 commit
  21. 24 Jan, 2020 7 commits
  23. 26 Dec, 2019 1 commit
  25. 25 Dec, 2019 1 commit
  27. 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
  29. 03 Sep, 2019 1 commit
  31. 31 Jul, 2019 2 commits
  33. 12 Jul, 2019 1 commit
  35. 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
  37. 28 Jun, 2019 1 commit
  39. 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