Hi all,
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?
Jan
Hi,
On 4/18/21 8:44 PM, Jan Kiszka wrote:
Hi all,
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.
Thanks, Michal
On 19.04.21 17:21, Michal Simek wrote:
Hi,
On 4/18/21 8:44 PM, Jan Kiszka wrote:
Hi all,
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.
Jan
tf-a@lists.trustedfirmware.org
-
Jan Kiszka -
Michal Simek