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/rpi4/rpi4_bl31_setup.c#n204
> [1]:
> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/allwinner/sun50i_h616/prepare_dtb.c
>

[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


--
François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog