[PATCH] ARM: fdt: copy TF-A reserved memory into fdt passed to Linux

[Quentin Schulz]

Hi Alexander,

On 6/13/26 10:41 PM, Alexander Sverdlin wrote:
> [You don't often get email from alexander.sverdlin at gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Currently some ARM-based platforms reserve TF-A memory in their own ways:
> - Mediatek gets BL31 region via SMC call in ft_system_setup()
> - K3 uses CONFIG_K3_ATF_LOAD_ADDR, effectively in ft_system_setup()
> 

On Rockchip, we reserve the first 2MiB of DRAM. c.f. 
arch/arm/mach-rockchip/sdram.c. I haven't checked how it makes it to the 
Linux FDT but I'm assuming it does otherwise it'd be broken in 
interesting ways.
Don't ask us how we'll handle TF-A changing its location or amount of 
RAM. We also need to support Rockchip's TF-A blob which... doesn't 
support FDT (hence NO_PLATFORM_PARAM=y for most SoCs by default).

When xPL passes an FDT to TF-A (BL31; CONFIG=NO_PLATFORM_PARAM=n), TF-A 
passes it to OP-TEE OS (BL32) and OP-TEE OS writes its reserved area to 
the FDT before going back to U-Boot BL33.

U-Boot reads this (if CONFIG_OPTEE_LIB=y + CONFIG_OF_LIBFDT=y which are 
forced if you built with TEE variable present in your environment) and 
propagates the reserved areas to the kernel FDT, c.f. 
optee_copy_firmware_node(). So you probably want to hook yourself to 
wherever this is called.

Doing a quick grep in TF-A sources, it seems Alwinner is patching the 
FDT (and I'm now concerned not seeing Rockchip in there.... some more 
work to do I guess) which I assume is what prompted this series :)

Cheers,
Quentin