[PATCH] board: rzg2l: Do not expect a DTB blob from the TF-A.

[PATCH] board: rzg2l: Do not expect a DTB blob from the TF-A.

[Mathieu Othacehe]

On the RZG2L platform, the advised
TF-A (https://github.com/renesas-rz/rzg_trusted-firmware-a/tree/v2.5/rzg2l)
does not pass any DTB blob to U-Boot.

On the other hand, the RZG2L part of U-Boot expects a DTB to be passed.  It
means that if one flashes the latest TF-A as well as the mainline U-Boot,
it will crash trying to dereference the NULL DTB pointer before outputing
anything, which is painful to debug.

As the renesas_rzg2l_smarc_defconfig U-Boot configuration (the only RZG2L
supported configuration) is anyway embedding only the
renesas/r9a07g044l2-smarc.dts device-tree, it is fair to assume that we are
booting from that platform.

Remove any DTB blob expectation and assume that we are booting from the
platform we are compiling U-Boot for.

Signed-off-by: Mathieu Othacehe <othacehe@gnu.org>
---
 arch/arm/mach-renesas/cpu_info-rzg2l.c | 25 ++--------------
 board/renesas/rzg2l/rzg2l.c            | 40 --------------------------
 2 files changed, 2 insertions(+), 63 deletions(-)

diff --git a/arch/arm/mach-renesas/cpu_info-rzg2l.c b/arch/arm/mach-renesas/cpu_info-rzg2l.c
index ab95ce76388..97e0eb419a4 100644
--- a/arch/arm/mach-renesas/cpu_info-rzg2l.c
+++ b/arch/arm/mach-renesas/cpu_info-rzg2l.c
@@ -10,9 +10,6 @@
 
 #define SYSC_LSI_DEVID		0x11020A04
 
-/* If the firmware passed a device tree, use it for soc identification. */
-extern u64 rcar_atf_boot_args[];
-
 /* CPU information table */
 struct tfa_info {
 	const char *soc_name;
@@ -24,32 +21,14 @@ static const struct tfa_info tfa_info[] = {
 	{ "renesas,r9a07g044l2", "R9A07G044L", RENESAS_CPU_TYPE_R9A07G044L },
 };
 
-static const struct tfa_info invalid_tfa_info = { NULL, "(invalid)", 0 };
-
-static const struct tfa_info *get_tfa_info(void)
-{
-	void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
-
-	if (fdt_magic(atf_fdt_blob) == FDT_MAGIC) {
-		unsigned int i;
-		for (i = 0; i < ARRAY_SIZE(tfa_info); i++) {
-			if (!fdt_node_check_compatible(atf_fdt_blob, 0,
-						       tfa_info[i].soc_name))
-				return &tfa_info[i];
-		}
-	}
-
-	return &invalid_tfa_info;
-}
-
 const u8 *rzg_get_cpu_name(void)
 {
-	return get_tfa_info()->cpu_name;
+	return tfa_info->cpu_name;
 }
 
 u32 renesas_get_cpu_type(void)
 {
-	return get_tfa_info()->cpu_type;
+	return tfa_info->cpu_type;
 }
 
 u32 renesas_get_cpu_rev_integer(void)
diff --git a/board/renesas/rzg2l/rzg2l.c b/board/renesas/rzg2l/rzg2l.c
index 509c5dbb156..0bdf030eb15 100644
--- a/board/renesas/rzg2l/rzg2l.c
+++ b/board/renesas/rzg2l/rzg2l.c
@@ -7,46 +7,6 @@
 #include <fdtdec.h>
 #include <linux/libfdt.h>
 
-#if IS_ENABLED(CONFIG_MULTI_DTB_FIT)
-/* If the firmware passed a device tree, use it for board identification. */
-extern u64 rcar_atf_boot_args[];
-
-static bool is_rzg2l_board(const char *board_name)
-{
-	void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
-
-	return fdt_node_check_compatible(atf_fdt_blob, 0, board_name) == 0;
-}
-
-int board_fit_config_name_match(const char *name)
-{
-	void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
-
-	if (fdt_magic(atf_fdt_blob) != FDT_MAGIC)
-		return -1;
-
-	if (is_rzg2l_board("renesas,r9a07g044l2"))
-		return strcmp(name, "r9a07g044l2-smarc");
-
-	return -1;
-}
-#endif
-
-static void apply_atf_overlay(void *fdt_blob)
-{
-	void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
-
-	if (fdt_magic(atf_fdt_blob) == FDT_MAGIC)
-		fdt_overlay_apply_node(fdt_blob, 0, atf_fdt_blob, 0);
-}
-
-int fdtdec_board_setup(const void *fdt_blob)
-{
-	apply_atf_overlay((void *)fdt_blob);
-
-	return 0;
-}
-
 int ft_board_setup(void *blob, struct bd_info *bd)
 {
 	return 0;
-- 
2.49.0

Re: [PATCH] board: rzg2l: Do not expect a DTB blob from the TF-A.

[Marek Vasut]

On 9/18/25 2:48 PM, Mathieu Othacehe wrote:
> On the RZG2L platform, the advised
> TF-A (https://github.com/renesas-rz/rzg_trusted-firmware-a/tree/v2.5/rzg2l)
> does not pass any DTB blob to U-Boot.
> 
> On the other hand, the RZG2L part of U-Boot expects a DTB to be passed.  It
> means that if one flashes the latest TF-A as well as the mainline U-Boot,
> it will crash trying to dereference the NULL DTB pointer before outputing
> anything, which is painful to debug.

This part is unexpected ...

[...]

> -int board_fit_config_name_match(const char *name)
> -{
> -	void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
> -
> -	if (fdt_magic(atf_fdt_blob) != FDT_MAGIC)
... because every function which handles such passed DT is testing its 
DT magic validity first. Is the magic actually valid in your fail case?

Also, enable CONFIG_DEBUG_UART in your U-Boot config, then you will get 
very early UART output capabilities, it works even before DT is used.

Re: [PATCH] board: rzg2l: Do not expect a DTB blob from the TF-A.

[Mathieu Othacehe]

Hello Marek,

> magic validity first. Is the magic actually valid in your fail case?

So to clarify the situation, the mainline TF-A does not have RZG2L
support. So the only one available out there is the forked Reneasas one
that I have mentioned up in the thread.

Now, the mainline U-Boot is doing:

--8<---------------cut here---------------start------------->8---
	void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);

	if (fdt_magic(atf_fdt_blob) != FDT_MAGIC)
--8<---------------cut here---------------end--------------->8---

unconditionally, with rcar_atf_boot_args[1] being NULL as no arguments
are passed by the forked Reneasas TF-A fork to U-Boot.

I could test for NULL pointers as well, but I thought that getting rid
of that piece of code made more sense as there are no TF-As out there
passing such arguments.

If you think that it will be better to take the problem the other way
around and modify the forked TF-A to pass that argument that also makes
sense to me. Picking one of the two solutions would allow us to have
something working out of the box.

> Also, enable CONFIG_DEBUG_UART in your U-Boot config, then you will get very
> early UART output capabilities, it works even before DT is used.

Noted, thanks :)

Mathieu

Re: [PATCH] board: rzg2l: Do not expect a DTB blob from the TF-A.

[Marek Vasut]

On 9/18/25 4:39 PM, Mathieu Othacehe wrote:

Hello Mathieu,

>> magic validity first. Is the magic actually valid in your fail case?
> 
> So to clarify the situation, the mainline TF-A does not have RZG2L
> support. So the only one available out there is the forked Reneasas one
> that I have mentioned up in the thread.
> 
> Now, the mainline U-Boot is doing:
> 
> --8<---------------cut here---------------start------------->8---
> 	void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
> 
> 	if (fdt_magic(atf_fdt_blob) != FDT_MAGIC)
> --8<---------------cut here---------------end--------------->8---
> 
> unconditionally, with rcar_atf_boot_args[1] being NULL as no arguments
> are passed by the forked Reneasas TF-A fork to U-Boot.

Ah, thank you for clarification, now it makes sense.

> I could test for NULL pointers as well, but I thought that getting rid
> of that piece of code made more sense as there are no TF-As out there
> passing such arguments.

Hopefully the RZG2L upstream TFA is coming. When it does, it will likely 
pass the DT which contains various reserved-memory {} nodes to U-Boot.

Until then, I think check for params that are passed in being 0 is the 
right future-proof fix.

> If you think that it will be better to take the problem the other way
> around and modify the forked TF-A to pass that argument that also makes
> sense to me. Picking one of the two solutions would allow us to have
> something working out of the box.

No, because we cannot depend on the fact that users will update both TFA 
and U-Boot, they can update U-Boot and keep old TFA.

>> Also, enable CONFIG_DEBUG_UART in your U-Boot config, then you will get very
>> early UART output capabilities, it works even before DT is used.
> 
> Noted, thanks :)
You're welcome.

Re: [PATCH] board: rzg2l: Do not expect a DTB blob from the TF-A.

[Mathieu Othacehe]

Hello Marek,

> Until then, I think check for params that are passed in being 0 is the right
> future-proof fix.

OK makes sense, I reworked the proposed patch and sent a v2 that only
checks for NULL pointers.

Thanks,

Mathieu