Skip to content

GitLab

Switch branch/tag
  1. 17 Jun, 2019 1 commit
  3. 11 Jun, 2019 1 commit
  5. 06 Jun, 2019 4 commits
  7. 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
  9. 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
  11. 29 May, 2019 1 commit
  13. 22 May, 2019 2 commits
  15. 21 May, 2019 1 commit
  17. 20 May, 2019 2 commits
  19. 16 May, 2019 1 commit
  21. 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
  23. 13 May, 2019 1 commit
  25. 10 May, 2019 2 commits
    • Alexei Fedorov's avatar
      SMMUv3: Abort DMA transactions · 1461ad9f
      Alexei Fedorov authored 
      

For security DMA should be blocked at the SMMU by default
unless explicitly enabled for a device. SMMU is disabled
after reset with all streams bypassing the SMMU, and
abortion of all incoming transactions implements a default
deny policy on reset.
This patch also moves "bl1_platform_setup()" function from
arm_bl1_setup.c to FVP platforms' fvp_bl1_setup.c and
fvp_ve_bl1_setup.c files.

Change-Id: Ie0ffedc10219b1b884eb8af625bd4b6753749b1a
Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      1461ad9f
    • kenny liang's avatar
      Initialize platform for MediaTek mt8183 · 3fa9dec4
      kenny liang authored 
      

- Add basic platform setup
- Add generic CPU helper functions
- Add delay timer platform implementation
- Use TI 16550 uart driver

Change-Id: I1c29569c68fe9fca5e10e88a22a29690bab7141f
Signed-off-by: default avatarkenny liang <kenny.liang@mediatek.com>
      3fa9dec4
  27. 09 May, 2019 1 commit
  29. 08 May, 2019 2 commits
  31. 03 May, 2019 2 commits
    • John Tsichritzis's avatar
      Add compile-time errors for HW_ASSISTED_COHERENCY flag · 076b5f02
      John Tsichritzis authored 
      This patch fixes this issue:
https://github.com/ARM-software/tf-issues/issues/660



The introduced changes are the following:

1) Some cores implement cache coherency maintenance operation on the
hardware level. For those cores, such as - but not only - the DynamIQ
cores, it is mandatory that TF-A is compiled with the
HW_ASSISTED_COHERENCY flag. If not, the core behaviour at runtime is
unpredictable. To prevent this, compile time checks have been added and
compilation errors are generated, if needed.

2) To enable this change for FVP, a logical separation has been done for
the core libraries. A system cannot contain cores of both groups, i.e.
cores that manage coherency on hardware and cores that don't do it. As
such, depending on the HW_ASSISTED_COHERENCY flag, FVP includes the
libraries only of the relevant cores.

3) The neoverse_e1.S file has been added to the FVP sources.

Change-Id: I787d15819b2add4ec0d238249e04bf0497dc12f3
Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      076b5f02
    • Alexei Fedorov's avatar
      SMMUv3: refactor the driver code · ccd4d475
      Alexei Fedorov authored 
      

This patch is a preparation for the subsequent changes in
SMMUv3 driver. It introduces a new "smmuv3_poll" function
and replaces inline functions for accessing SMMU registers
with mmio read/write operations. Also the infinite loop
for the poll has been replaced with a counter based timeout.

Change-Id: I7a0547beb1509601f253e126b1a7a6ab3b0307e7
Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      ccd4d475
  33. 02 May, 2019 1 commit
    • Christoph Müllner's avatar
      rockchip: Disable binary generation for all SoCs. · 33218d2a
      Christoph Müllner authored 
      

All supported Rockchip SoCs (RK3288, RK3328, RK3368 and RK3399)
have non-continuous memory areas in the linker script with a huge
gap between them. This results in extremely padded binary images
with a size of about 4 GiB.

E.g. on the RK3399 we have the following memory areas (and base addresses):
RAM (0x1000), SRAM (0xFF8C0000), and PMUSRAM (0xFF3B0000).

Consumers of the TF-A project (e.g. coreboot or U-Boot) therefore
use the ELF image instead, which has a size of a few hundred kBs.

In order to prevent the generation of a huge and useless file,
this patch disables the binary generation for all affected Rockchip
SoCs.
Signed-off-by: default avatarChristoph Müllner <christophm30@gmail.com>
Change-Id: I4ac65bdf1e598c3e1a59507897d183aee9a36916
      33218d2a
  35. 01 May, 2019 3 commits
    • Christoph Müllner's avatar
      rockchip: Allow console device to be set by DTB. · 220c33a2
      Christoph Müllner authored 
      

Currently the compile-time constant PLAT_RK_UART_BASE defines
which UART is used as console device. E.g. on RK3399 it is set
to UART2. That means, that a single bl31 image can not be used
for two boards, which just differ on the UART console.

This patch addresses this limitation by parsing the "stdout-path"
property from the "chosen" node in the DTB. The expected property
string is expected to have the form "serialN:XXX", with
N being either 0, 1, 2, 3 or 4. When the property is found, it will
be used to override PLAT_RK_UART_BASE.

Tested on RK3399-Q7, with a stdout-path of "serial0:115200n8".
Signed-off-by: default avatarChristoph Müllner <christophm30@gmail.com>
Change-Id: Iafe1320e77ab006c121f8d52745d54cef68a48c7
      220c33a2
    • Christoph Müllner's avatar
      rockchip: Add params_setup to RK3328. · f476e63f
      Christoph Müllner authored 
      

params_setup.c provides the function params_early_setup, which
takes care of parsing ATF parameters (bl31_plat_param array,
fdt or coreboot table). As params_early_setup is defined as weak
symbol in bl31_plat_setup.c, providing a platform-specific
bl31_plat_setup implementation is optional.

This patch adds the rockchip-common params_setup.c to the sources
for RK3328. This streamlines the parameter handling for all supported
rockchip SoCs.
Signed-off-by: default avatarChristoph Müllner <christophm30@gmail.com>
Change-Id: I071c03106114364ad2fc408e49cc791fe5b35925
      f476e63f
    • Christoph Müllner's avatar
      rockchip: Streamline and complete UARTn_BASE macros. · 0957b9b2
      Christoph Müllner authored 
      

In order to set the UART base during bootup in common code of
plat/rockchip, we need to streamline the way the UART base addresses
are defined and add the missing definitions and mappings.

This patch does so by following the pattern UARTn_BASE, which is
already in use on RK3399 and RK3328. The numbering itself is derived
from the upstream Linux DTS files of the individual SoCs.
Signed-off-by: default avatarChristoph Müllner <christophm30@gmail.com>
Change-Id: I341a1996f4ceed5f82a2f6687d4dead9d7cc5c1f
      0957b9b2
  37. 30 Apr, 2019 2 commits
  39. 26 Apr, 2019 6 commits
  41. 25 Apr, 2019 2 commits
    • Heiko Stuebner's avatar
      rockchip: add support for rk3288 · 780e3f24
      Heiko Stuebner authored 
      

The rk3288 is a 4-core Cortex-A12 SoC and shares a lot of features
with later SoCs.

Working features are general non-secure mode (the gic needs special
love for that), psci-based smp bringing cpu cores online and also
taking them offline again, psci-based suspend (the simpler variant
also included in the linux kernel, deeper suspend following later)
and I was also already able to test HYP-mode and was able to boot
a virtual kernel using kvm.
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
Change-Id: Ibaaa583b2e78197591a91d254339706fe732476a
      780e3f24
    • Heiko Stuebner's avatar
      rockchip: add common aarch32 support · 82e18f89
      Heiko Stuebner authored 
      

There are a number or ARMv7 Rockchip SoCs that are very similar in their
bringup routines to the existing arm64 SoCs, so there is quite a high
commonality possible here.

Things like virtualization also need psci and hyp-mode and instead of
trying to cram this into bootloaders like u-boot, barebox or coreboot
(all used in the field), re-use the existing infrastructure in TF-A
for this (both Rockchip plat support and armv7 support in general).

So add core support for aarch32 Rockchip SoCs, with actual soc support
following in a separate patch.
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
Change-Id: I298453985b5d8434934fc0c742fda719e994ba0b
      82e18f89