On March 6, 2024 thus sayeth 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@ti.com
Acked-by: Bryan Brattlof bb@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)..
Ah that's a good point. Only the SoCs with A53s are using DRAM for TFA so we should be good for now :)
Thanks Andrew
Andrew
~Bryan