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...
On 20.04.21 02:51, Samuel Holland wrote:
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.
I know the RPi4 model (just had to debug it [3]). But I wonder if that is possible on the zynqmp as well. Are we passing a DT to BL33 here already and, thus, could inject that reservation?
Jan
Regards, Samuel
[3] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9316
Hi,
On 4/20/21 7:49 AM, Jan Kiszka wrote:
On 20.04.21 02:51, Samuel Holland wrote:
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.
I know the RPi4 model (just had to debug it [3]). But I wonder if that is possible on the zynqmp as well. Are we passing a DT to BL33 here already and, thus, could inject that reservation?
I have played with it and there is no issue to wire it up. But there are also changes needed in u-boot and make sense to run this code when you run TF-A from DDR because normally it runs out of OCM which is not mapped by Linux that's why reserving space is not needed. But I was also looking at optee and there is also DT support there which is also reading information about secure console (or standard console). Is this something where TF-A wants to also go to and use information from DT for own configuration?
Thanks, Michal
tf-a@lists.trustedfirmware.org
-
Jan Kiszka -
Michal Simek -
Samuel Holland