[PATCH 4/6] arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT

[Andrew Davis]

On 3/6/24 7:35 AM, Bryan Brattlof wrote:
> On February 14, 2024 thus sayeth Andrew Davis:
>> The address we load TF-A and OP-TEE to is configurable by Kconfig
>> CONFIG_K3_{ATF,OPTEE}_LOAD_ADDR, but the DT nodes reserving this memory
>> are often statically defined. As these binaries are dynamically loadable,
>> and in the case of OP-TEE may not even be loaded at all, hard-coding these
>> addresses is not a hardware description, but rather a configuration.
>>
>> If the address that U-Boot loaded TF-A or OP-TEE does not match the
>> address in hard-coded in DT, then fix that node address. This also handles
>> the case when no reserved memory for these is provided by DT, which is
>> more correct as explained above.
>>
>> Add this fixup function, and enable it for AM62.
>>
>> Signed-off-by: Andrew Davis <afd at ti.com>
> 
> Acked-by: Bryan Brattlof <bb at ti.com>
> 
> Does this mean we need to no-map these regions in the MMU as well? Right
> now it's just statically defined. I was looking into trying to read the
> reserved-memory{} node to see if we could dynamically build the MMU
> config but that would have to happen after this step right?
> 

Good question. So TF-A/OP-TEE are loaded by R5 SPL, which means by
the time A53 SPL starts they are already in place and firewalled,
which means yes we should no-map them in MMU to prevent some
speculative fetch (A53 doesn't do that, but A72 on other K3 device
might) or similar from causing a firewall exception.

The fixup in this patch is done to the Linux DT file right before
it is handed off to Linux, which as you point out happens after
we setup the U-Boot MMU.

This is more a problem in theory, but not really one in practice.
I know, I don't like that answer either, but I can't think of a
better solution outside of doing this fixup in R5 SPL to the
U-Boot DTB also. (Which might work, but seems overkill)..

Andrew

> ~Bryan