Hi Thomas,
On Wed, Oct 11, 2023 at 10:40 AM Thomas Richard via TF-A tf-a@lists.trustedfirmware.org wrote:
Hello,
I just sent a series to gerrit: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23992. I'm writing this email to add more context to this series, as I didn't find how to to it with gerrit.
You should be able to hit Reply and add comment if you're logged into gerrit.
This series is only the TF-A part to add suspend to RAM support for the TI K3 J7200 target. Some modifications are also needed in Linux kernel, U-Boot (R5 SPL) and DM-Firmware. During the suspend sequence, TF-A save itself in DRAM, in a reserved memory region dedicated to lpm. TF-A will be restored by R5 SPL. We need to save it in DRAM (which will be in retention mode during suspend) because as it runs in SRAM, it will be lost once the SOC is powered-off by the PMIC.
General question/discussion point (although your description above provides a good context for it): TF-A BL31 canonically runs from SRAM. But in case like this where we have to copy it to DRAM any way, would it make sense to run BL31 from DRAM and therefore simplify the design? I can think of two reasons why one wouldn't want to do that. First is performance of SRAM vs DRAM. But do we have data which proves one way or the other? With caches enabled after some initial CPU init code, performance difference might be significantly mitigated. Second is a case where BL31 might need to run while DRAM is inaccessible, e.g. a component in the path from CPU to DRAM, or the memory controller itself is power gated. This is possible but seems like niche scenario which may not apply in most cases.
Best Regards,
-- Thomas Richard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org