Skip to content

GitLab

Switch branch/tag
  1. 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
  3. 01 Jul, 2019 2 commits
  5. 28 Jun, 2019 3 commits
  7. 26 Jun, 2019 5 commits
  9. 22 Jun, 2019 1 commit
  11. 20 Jun, 2019 2 commits
  13. 17 Jun, 2019 8 commits
  15. 13 Jun, 2019 1 commit
  17. 11 Jun, 2019 1 commit
  19. 08 Jun, 2019 1 commit
    • Samuel Holland's avatar
      allwinner: Disable unused features to save space · 8f31853b
      Samuel Holland authored 
      

As all Allwinner platforms are single-cluster A53 chips, we can disable
support for newer, unsupported architecture extensions. We can also
avoid some cache maintenance code, since no platform-specific setup is
required to enable coherency.

These changes reduce the size of .text on a default build with GCC 9.1
enough that .vectors again fits in the second half of a page, instead
of requiring its own page.

This commit was boot-tested on the Pinebook.
Signed-off-by: default avatarSamuel Holland <samuel@sholland.org>
Change-Id: Ib90454ef0c798d5e714b7780c585be0b1ed49c6d
      8f31853b
  21. 06 Jun, 2019 4 commits
  23. 05 Jun, 2019 1 commit
    • John Tsichritzis's avatar
      FVP: Remove GIC initialisation from secondary core cold boot · 9c29e5f7
      John Tsichritzis authored 
      

During the secondary cores' cold boot path, the cores initialise the GIC
CPU interface. However this is a redundant action since 1) the cores are
powered down immediately after that, 2) the GIC CPU interface is
initialised from scratch when the secondary cores are powered up again
later.

Moreover, this part of code was introducing a bug. In a GICv3 system,
the GIC's CPU interface system registers must not be written without the
core being marked as "awake" in the redistributor. However, this
sequence was performing such accesses and this would cause those cores
to hang. The hang was caused by the DSB instruction that would never
complete because of the GIC not recognising those writes.

For the two aforementioned reasons, the entire part of the GIC CPU
interface initialisation is removed.

Change-Id: I6c33a1edda69dd5b6add16a27390a70731b5532a
Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      9c29e5f7
  25. 04 Jun, 2019 1 commit
    • John Tsichritzis's avatar
      Apply compile-time check for AArch64-only cores · 629d04f5
      John Tsichritzis authored 
      

Some cores support only AArch64 mode. In those cores, only a limited
subset of the AArch32 system registers are implemented. Hence, if TF-A
is supposed to run on AArch64-only cores, it must be compiled with
CTX_INCLUDE_AARCH32_REGS=0.

Currently, the default settings for compiling TF-A are with the AArch32
system registers included. So, if we compile TF-A the default way and
attempt to run it on an AArch64-only core, we only get a runtime panic.

Now a compile-time check has been added to ensure that this flag has the
appropriate value when AArch64-only cores are included in the build.

Change-Id: I298ec550037fafc9347baafb056926d149197d4c
Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      629d04f5
  27. 29 May, 2019 1 commit
  29. 22 May, 2019 2 commits
  31. 21 May, 2019 1 commit
  33. 20 May, 2019 2 commits
  35. 16 May, 2019 1 commit
  37. 15 May, 2019 2 commits
    • Sami Mujawar's avatar
      N1SDP: Initialise CNTFRQ in Non Secure CNTBaseN · 603b372e
      Sami Mujawar authored 
      

N1SDP exhibits the behavior similar to Juno wherein CNTBaseN.CNTFRQ
can be written but does not reflect the value of the CNTFRQ register
in CNTCTLBase frame. This doesn't follow ARM ARM in that the value
updated in CNTCTLBase.CNTFRQ is not reflected in CNTBaseN.CNTFRQ.

Hence enable the workaround (applied to Juno) for N1SDP that updates
the CNTFRQ register in the Non Secure CNTBaseN frame.

Change-Id: Id89ee1bca0f25c9d62f8f794f2c4f4e618cdf092
Signed-off-by: default avatarSami Mujawar <sami.mujawar@arm.com>
      603b372e
    • Sami Mujawar's avatar
      N1SDP: Fix DRAM2 start address · 49d64e5d
      Sami Mujawar authored 
      

The default DRAM2 start address for Arm platforms
is 0x880000000. However, for N1SDP platform this is
0x8080000000.

Fix the DRAM2 start address by initialising
PLAT_ARM_DRAM2_BASE.

Without this fix there is a mismatch of the System
memory region view as seen by the BL31 runtime
firmware (PSCI) versus the view of the OS (which
is based on the description provided by UEFI. In
this case UEFI is correctly describing the DRAM2
start address).

This implicates in secondary cores failing to start
on some Operating Systems if the OS decides to place
the secondary start address in the mismatched region.

Change-Id: I57220e753219353dda429868b4c5e1a69944cc64
Signed-off-by: default avatarSami Mujawar <sami.mujawar@arm.com>
      49d64e5d