Hi Alexander,
On 6/13/26 10:41 PM, Alexander Sverdlin wrote:
[You don't often get email from [email protected]. 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
