Skip to content

GitLab

Switch branch/tag
  1. 05 Sep, 2019 19 commits
  3. 20 Aug, 2019 1 commit
    • Manish Pandey's avatar
      plat/arm: Introduce corstone700 platform. · 7bdc4698
      Manish Pandey authored 
      

This patch adds support for Corstone-700 foundation IP, which integrates
both Cortex-M0+ and Cortex-A(Host) processors in one handy, flexible
subsystem.
This is an example implementation of Corstone-700 IP host firmware.

Cortex-M0+ will take care of boot stages 1 and 2(BL1/BL2) as well as
bringing Host out RESET. Host will start execution directly from BL32 and
then will jump to Linux.

It is an initial port and additional features are expected to be added
later.

Change-Id: I7b5c0278243d574284b777b2408375d007a7736e
Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      7bdc4698
  5. 19 Aug, 2019 3 commits
  7. 16 Aug, 2019 3 commits
    • Alexei Fedorov's avatar
      FVP: Add Delay Timer driver to BL1 and BL31 · 1b597c22
      Alexei Fedorov authored 
      

SMMUv3 driver functions which are called from BL1 and BL31
currently use counter-based poll method for testing status
bits. Adding Delay Timer driver to BL1 and BL31 is required
for timeout-based implementation using timer delay functions
for SMMU and other drivers.
This patch adds new function `fvp_timer_init()` which
initialises either System level generic or SP804 timer based on
FVP_USE_SP804_TIMER build flag.
In BL2U `bl2u_early_platform_setup()` function the call to
`arm_bl2u_early_platform_setup()` (which calls
`generic_delay_timer_init()` ignoring FVP_USE_SP804_TIMER flag),
is replaced with `arm_console_boot_init()` and `fvp_timer_init()`.

Change-Id: Ifd8dcebf4019e877b9bc5641551deef77a44c0d1
Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      1b597c22
    • Marek Vasut's avatar
      rcar_gen3: plat: Rename RCAR_PRODUCT_* to PRR_PRODUCT_* · df51d8fe
      Marek Vasut authored 
      

Rename RCAR_PRODUCT_* to PRR_PRODUCT_* and drop the duplicate
RCAR_PRODUCT_* macro.
Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
Change-Id: I6b2789790b85edb79c026f0860d70f323d113d96
      df51d8fe
    • Marek Vasut's avatar
      rcar_gen3: plat: Factor out PRR_ macros into rcar_def.h · 7c103d60
      Marek Vasut authored 
      

Pull out the PRR_* macros into rcar_def.h and remove multiple copies of
it. Now that there are still RCAR_* macros in rcar_def.h too and they
have the exact same meaning as the PRR_* macros, but that's for another
patch.
Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
Change-Id: Icb7f61b971b1a23102bd1b9f58cda580660a55fc
      7c103d60
  9. 15 Aug, 2019 2 commits
  11. 14 Aug, 2019 1 commit
  13. 13 Aug, 2019 2 commits
  15. 09 Aug, 2019 2 commits
    • Heiko Stuebner's avatar
      rockchip: rk3399: store actual debug uart information on suspend · 0eb7fa91
      Heiko Stuebner authored 
      

The rk3399 suspend code saves and restores the debug uart settings, but
right now always does this for the default uart. Right now this works
only by chance for the majority of rk3399 boards, which do not deviate
from that default.

But both Coreboot as well as U-Boot-based platforms can actually use
different uarts for their output, which can be configured from either
devicetree or Coreboot-variables.

To fix this, just use the stored uart-base information instead of the
default constant.
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
Change-Id: I1ea059d59a1126f6f8702315df7e620e632b686e
      0eb7fa91
    • Heiko Stuebner's avatar
      rockchip: move dt-coreboot uart distinction into param handling code · dd4a0d16
      Heiko Stuebner authored 
      

Rockchip platforms can be booted from either u-boot or coreboot.

So far the Coreboot-console was initizalized from a coreboot data struct
in the early_param2 callbacks and dt-based consoles with data from the
rockchip_get_uart_* functions.

But later code may also need this console information for example for
special suspend handling. To make this easy follow a suggestion from
Julius Werner and move the coreboot<->dt distinction into the
rockchip_get_uart_* functions, thus making correct data about the used
uart available to all Rockchip platform code at all times.

This includes a new rockchip_get_uart_clock as well, because while the
dt-platforms right now always just default the rate defined in a constant
Coreboot provides its own field for the clock rate and we don't want to
loose that information for the console init. Similarly the rk_uart_*
variables should move into the non-Coreboot code, to prevent them from
being marked as unused, which also requires the rk_get_uart_* functions
to move below the actual dt-parsing.
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
Change-Id: I278d595d2aa6c6864187fc8979a9fbff9814feac
      dd4a0d16
  17. 07 Aug, 2019 1 commit
  19. 05 Aug, 2019 2 commits
    • Heiko Stuebner's avatar
      rockchip: make uart baudrate configurable · 30970e0f
      Heiko Stuebner authored 
      

A previous patch already allowed to configure the uart output from the
devicetree, but on Rockchip platforms we also have the issue of different
vendors using different baudrates for their uarts.

For example, rk3399 has a default baudrate of 115200 which is true for
ChromeOS-devices and boards from Theobroma-Systems, while all the boards
using the vendor boot chain actually use a baudrate of 1500000.

Similarly the newly added px30 has a default of said 1500000 but some
boards may want to use the more widely used 115200.

The devicetree stdout-path node already contains the desired baudrate,
so add simple code to parse it from there and override the default,
which stays unchanged.
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
Change-Id: I7412139c3df3073a1996eb508ec08642ec6af90d
      30970e0f
    • Heiko Stuebner's avatar
      rockchip: px30: add uart5 as option for serial output · 5f441a7b
      Heiko Stuebner authored 
      

The px30 mini-evb can use either uart2 (muxed with the sd-card pins) or
uart5 via its pin header for serial output. Uart5 is especially useful
when needing to boot from the sd-card, where uart2 obviously is not
useable.

So add the uart5 constants and it as uart option for the serial-param
handler.
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
Change-Id: Ib88df7a55d761ee104d312c9953a13de3beba1c4
      5f441a7b
  21. 02 Aug, 2019 3 commits
    • Hadi Asyrafi's avatar
      intel: stratix10: Fix BL31 memory mapping · 600db4e3
      Hadi Asyrafi authored 
      

Previous config blocks ATF runtime service communications with SDM mailbox
Signed-off-by: default avatarHadi Asyrafi <muhammad.hadi.asyrafi.abdul.halim@intel.com>
Change-Id: Ia857facd0bd0790056df94ed1e016bcf619a161e
      600db4e3
    • Remi Pommarel's avatar
      meson: gxl: Fix CPU hotplug · b4694a86
      Remi Pommarel authored 
      

The CPU[1-3] are reset to initial/cold boot state (with their reset
address set to 0x0). In this state the cpus are waiting for another
one to set the reset address to bl31_warm_entrypoint and wake them up.

The CPU0 needs a bit of a workaround as changing the reset address
either through PSCI mailbox or the mmio mapped RVBAR (at 0xda834650)
does not seem to have any effect. Thus the workaround consists in
emulating the other CPUs' behavior with a WFE loop and manually jumping
to bl31_warm_entrypoint when woken back up by another one.

Change-Id: I11265620b5fd0619285e3993253a3f9a3ff6a7a4
Signed-off-by: default avatarRemi Pommarel <repk@triplefau.lt>
      b4694a86
    • Remi Pommarel's avatar
      meson: gxl: Fix reset and power off · 43d4a291
      Remi Pommarel authored 
      

Before CPU enters standby state (wfi), the AP needs to signal the SCP
through PSCI mailbox.

Also at boot time the AP has to wait for the SCP to be ready before
sending the first scpi commands or it can crash.

Change-Id: Iacc99f5bec745ad71922c5ea07ca5b87088133b6
Signed-off-by: default avatarRemi Pommarel <repk@triplefau.lt>
      43d4a291
  23. 01 Aug, 2019 1 commit
    • Julius Werner's avatar
      Switch AARCH32/AARCH64 to __aarch64__ · 402b3cf8
      Julius Werner authored 
      

NOTE: AARCH32/AARCH64 macros are now deprecated in favor of __aarch64__.

All common C compilers pre-define the same macros to signal which
architecture the code is being compiled for: __arm__ for AArch32 (or
earlier versions) and __aarch64__ for AArch64. There's no need for TF-A
to define its own custom macros for this. In order to unify code with
the export headers (which use __aarch64__ to avoid another dependency),
let's deprecate the AARCH32 and AARCH64 macros and switch the code base
over to the pre-defined standard macro. (Since it is somewhat
unintuitive that __arm__ only means AArch32, let's standardize on only
using __aarch64__.)

Change-Id: Ic77de4b052297d77f38fc95f95f65a8ee70cf200
Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      402b3cf8