[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.