Skip to content

GitLab

Switch branch/tag
  1. 01 Jul, 2019 1 commit
  3. 28 Jun, 2019 3 commits
  5. 26 Jun, 2019 5 commits
  7. 22 Jun, 2019 1 commit
  9. 20 Jun, 2019 2 commits
  11. 17 Jun, 2019 8 commits
  13. 13 Jun, 2019 1 commit
  15. 11 Jun, 2019 1 commit
  17. 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
  19. 06 Jun, 2019 4 commits
  21. 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
  23. 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
  25. 29 May, 2019 1 commit
  27. 22 May, 2019 2 commits
  29. 21 May, 2019 1 commit
  31. 20 May, 2019 2 commits
  33. 16 May, 2019 1 commit
  35. 15 May, 2019 3 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
    • Sami Mujawar's avatar
      Add option for defining platform DRAM2 base · 6bb6015f
      Sami Mujawar authored 
      

The default DRAM2 base address for Arm platforms
is 0x880000000. However, on some platforms the
firmware may want to move the start address to
a different value.

To support this introduce PLAT_ARM_DRAM2_BASE that
defaults to 0x880000000; but can be overridden by
a platform (e.g. in platform_def.h).

Change-Id: I0d81195e06070bc98f376444b48ada2db1666e28
Signed-off-by: default avatarSami Mujawar <sami.mujawar@arm.com>
      6bb6015f
  37. 13 May, 2019 1 commit