Hi
There is a discussion started by Harb from Ampere about standardizing information from secure firmware to BL33: look at HOB in the object.
A side aspect of the HOB is: DT shall be used wisely for things that are really static. Dynamic (such as plugged DIMMs) or configurable aspects (secure memory size) should be controllable by a single authoritative entity. On a number of platforms, the definition of secure memory size is "copied" in at least for different independent projects which make it a nightmare for product makers to choose a size for the trusted application they want to onboard.
Cheers
FF
On Tue, 20 Apr 2021 at 07:49, Jan Kiszka via TF-A < tf-a@lists.trustedfirmware.org> 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?
Jan
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...
[3] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9316
TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a