On 4/19/21 11:11 AM, Jan Kiszka via TF-A wrote:
On 19.04.21 17:21, Michal Simek wrote:
On 4/18/21 8:44 PM, Jan Kiszka wrote:
when SPD or DEBUG is enabled, TF-A is moved to RAM on the zynqmp (as it longer fits into OCM). U-Boot happens to avoid that region, but the kernel's DTB has no reservation entry, and Linux will trigger an exception when accessing that region during early boot.
Can we improve this - without requiring the user to manually add a reservation to the DTB? Should we unconditionally reserve 0x1000..0x7ffff in all BL33 DTBs? Or is there a chance to communicate that need? Or some way to detect in BL33 whether it is needed?
Normally this ddr region should be also protected by security IPs that NS has no access there. It means in Xilinx flow this can be (and should be) propagated via device-tree generator to final DTS file that you don't need to touch it by hand. I am not aware about any way that NS can query secure world what memory can be used. And not sure if there is any standard way to do so.
OK, understood. But then, to be safe, shouldn't the upstream "static" default DT contain an exclusion of that region so that it won't get stuck if it is in use? Would block half a meg, but when you have a custom platform that does not need that, you can and will provide your own DT anyway.
Ideally, the static DTS is a description of the hardware only, and not of runtime constraints imposed by the firmware. If BL31 needs to reserve some memory, it can add that reservation to the DTB at runtime. The fdt_add_reserved_memory() function is available for this purpose. For an example, see the code used by the rpi4[0] or sun50i_h616[1] platforms.
If you later load a DTB from disk for use by Linux, you will need to copy the reserved-memory nodes from the U-Boot DTB to the loaded DTB.
Regards, Samuel
[0]: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/rpi/rp... [1]: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/allwin...