plar: rcar: add initial support for Gen4

RCar Gen4 is the next generation of Renesas automotive
chips. Currently only RCar S4 on board Spider is available. This
platform has 8 CortexA55 cores with G

plar: rcar: add initial support for Gen4

RCar Gen4 is the next generation of Renesas automotive
chips. Currently only RCar S4 on board Spider is available. This
platform has 8 CortexA55 cores with GICv3.

This is patch adds minimal support, so not all Gen4 features are
available. Namely, ROM API is not supported right now, so HW RNG and
ASLR are disabled. Also, ATF does not provide DTB, so non-secure DDR
ranges are hardcoded.

Apart from that, depending on external configuration, initial
bootloader can use two different UARTs as console: either SCIF3 or
HSCIF0. Thus, CFG_RCAR_UART is introduced.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat: rcar: implement hw_get_random_byte() function

As we now can call ROM API to access hardware random generator, it is
possible to implement generic interface to it, using hw_get_random_byte()
fu

plat: rcar: implement hw_get_random_byte() function

As we now can call ROM API to access hardware random generator, it is
possible to implement generic interface to it, using hw_get_random_byte()
function.

ROM API provides 32 bytes of random data at a time. To optimally use it, we
need to cache received random vector and provide random number bytes from
it one by one.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>

show more ...

plat: rcar: add support for ROM API calls including HW RNG

RCAR Gen3 SoCs have public ROM API functions that provide access to various
security-related features, including access to hardware random

plat: rcar: add support for ROM API calls including HW RNG

RCAR Gen3 SoCs have public ROM API functions that provide access to various
security-related features, including access to hardware random number
generator.

This patch adds both generic ROM API interface and wrapper function for
ROM_GetRndVector() call.

As ROM API code is written with identity mapping in mind, we can't call
those function with MMU enabled. So we need a special trampoline function
that would disable MMU, save state and jump to ROM API code.

Beginning with the latest revisions (H3 ES3.0, M3 ES1.1, etc) of Renesas
SoCs, ROM API addresses are fixed, but prior to that each family had own
address, so we need to maintain table of all possible addressed and select
correct one in runtime.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat: rcar: disable aarch32 support for OP-TEE core

While it is theoretically possible to boot RCar Gen3 SoC in aarch32
mode, it isn't supported by Renesas BSP. ARM TF provided by Renesas
boots only

plat: rcar: disable aarch32 support for OP-TEE core

While it is theoretically possible to boot RCar Gen3 SoC in aarch32
mode, it isn't supported by Renesas BSP. ARM TF provided by Renesas
boots only in aarch64 mode. Also it lacks aarch32 assembler code, so
it is not possible to built it for aarch32 at all.

Therefore, there is a little sense in supporting aarch32 in
OP-TEE (for plat-rcar, of course) - user just can't boot it. On other
hand it requires additional efforts to maintain aarch32 assembly code
that newer will be used.

This patch enforces CFG_ARM64_core build option and removes all
aarch32 related parts.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

plat: rcar: Derive core map from PRR

Instead of hard-coding the core count and the core ID mapping,
derive this information from the PRR register. All R-Car3 SoCs
have either one or two 4-core CPU c

plat: rcar: Derive core map from PRR

Instead of hard-coding the core count and the core ID mapping,
derive this information from the PRR register. All R-Car3 SoCs
have either one or two 4-core CPU clusters composed of CA53 or
CA57, except for M3W/M3W+, which has two CA57s and four CA53s.

So the approach here is to always set core count to 8, read out
PRR register once on boot, and then calculate the core ID using
CorePos = CoreId + (ClusterId << (IsM3W ? 1 : 0))

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>

show more ...

Add RCAR H3 platform support

Added support for Renesas RCAR devices. Initially RCAR H3 is supported.

Signed-off-by: Volodymyr Babchuk <volodymyr.babchuk@globallogic.com>
Reviewed-by: Jens Wiklander

Add RCAR H3 platform support

Added support for Renesas RCAR devices. Initially RCAR H3 is supported.

Signed-off-by: Volodymyr Babchuk <volodymyr.babchuk@globallogic.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...