Hi Marek,
On 3/2/25 9:59 PM, Marek Vasut wrote:
Implement custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
handling in case the TFA was loaded. The loadables handler sets up custom
handoff structure used by Renesas TFA fork in fixed location in DRAM and
indicates the TFA has been loaded.
The custom armv8_switch_to_el2_prep() handling tests whether the TFA BL31
was previously loaded and the custom handoff structure was set up, and if
so, jumps to TFA BL31 which switches from EL3 to EL2 and then returns to
U-Boot just past bl in armv8_switch_to_el2() to finish starting the Linux
kernel.
The jump to Linux through TFA works in such a way that the custom
armv8_switch_to_el2_prep() handler configures the custom handoff structure
such that the target jump address of the TFA BL31 on exit is set to the
armv8_switch_to_el2() + 4, which is just past the bl, and just before the
U-Boot code which implements the Linux kernel boot from either EL. The
registers passed through the TFA BL31 are all the registers passed into
armv8_switch_to_el2_prep() to assure maximum compatibility with all the
boot modes. The armv8_switch_to_el2_prep() handler jumps to the TFA BL31,
which does its setup, drops EL from EL3 to EL2 and finally jumps to the
armv8_switch_to_el2() + 4 entry point, which then allows U-Boot to boot
the Linux kernel the usual way.
In order to build suitable kernel fitImage, build TFA first, upstream
is currently under review:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/35799
Or if necessary, downstream repository:
remote: https://github.com/renesas-rcar/arm-trusted-firmware.git
branch: rcar_gen4_v2.7_v4x
```
$ git clean -fqdx
$ MBEDTLS_DIR=/path/to/mbedtls/ make -j$(nproc) bl31 \
PLAT=rcar_gen4 ARCH=aarch64 LSI=V4H SPD=none \
CTX_INCLUDE_AARCH32_REGS=0 MBEDTLS_COMMON_MK=1 \
PTP_NONSECURE_ACCESS=1 LOG_LEVEL=20 DEBUG=0 \
ENABLE_ASSERTIONS=0 E=0
```
Build Linux kernel Image and device tree from current mainline Linux
kernel repository, obtain 'Image' and 'r8a779g0-white-hawk.dtb' .
Bundle the files together using provided fit-image.its fitImage description:
```
$ mkimage -f fit-image.its fitImage
```
To start the kernel fiImage generated in previous step, load fitImage
to DRAM and use the 'bootm' command to start it:
=> load 0x58000000 ... fitImage && bootm 0x58000000
Signed-off-by: Marek Vasut <[email protected]>
---
Cc: Andre Przywara <[email protected]>
Cc: Caleb Connolly <[email protected]>
Cc: Igor Opaniuk <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Julien Masson <[email protected]>
Cc: Mattijs Korpershoek <[email protected]>
Cc: Maxim Moskalets <[email protected]>
Cc: Michael Walle <[email protected]>
Cc: Nobuhiro Iwamatsu <[email protected]>
Cc: Patrick Rudolph <[email protected]>
Cc: Paul Barker <[email protected]>
Cc: Paul-Erwan Rio <[email protected]>
Cc: Peter Hoyes <[email protected]>
Cc: Quentin Schulz <[email protected]>
Cc: Raymond Mao <[email protected]>
Cc: Sam Protsenko <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Sughosh Ganu <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: [email protected]
---
V2: Only start the BL31 if running in EL3
V3: Update link to upstream TFA BL31 posting
---
board/renesas/common/gen4-common.c | 126 +++++++++++++++++++++++++++++
1 file changed, 126 insertions(+)
diff --git a/board/renesas/common/gen4-common.c
b/board/renesas/common/gen4-common.c
index 52a0639073b..f7d129be4c8 100644
--- a/board/renesas/common/gen4-common.c
+++ b/board/renesas/common/gen4-common.c
I'm wondering if it really makes sense to have this in board/? If I
understood correctly, this is all SoC-specific? So shouldn't that rather
be in arch/arm/mach-renesas maybe? So that boards based on an R-Car gen4
SoC don't have to set SYS_VENDOR to renesas or copy the code in their
own board/<vendor>/common directory?
What do you think?
Cheers,
Quentin
