Re: [PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

[Tomas Melin <tomas.melin@vaisala.com>]

Hi,

On 25/11/2025 12:30, Michal Simek wrote:
> 
> 
> On 11/25/25 08:53, Tomas Melin wrote:
>> This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe.
>>
>> OP-TEE logic in U-Boot automatically injects a reserved-memory
>> node along with optee firmware node to kernel device tree.
>> The injection logic is dependent on that there is no manually
>> defined optee node. Having the node in zynqmp.dtsi effectively
>> breaks OP-TEE's insertion of the reserved-memory node, causing
>> memory access violations during runtime.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>> For further information about the U-Boot logic related
>> to this, see lib/optee/optee.c in U-Boot repository.
> 
> What's the behavior with EDK2?
Sorry, I cannot comment on that.

> 
> U-Boot also have optee driver. How is it probed when you remove this node?
This is about the injection of the nodes to the kernel device tree. So
in the U-Boot side, optee driver can be enabled or not. This passing of
the optee nodes will happen outside of optee driver context (image-fdt).
The OP-TEE logic will not insert the required reserved memory regions
into the kernel side devicetree in case the node is already present and
that is a real problem.
If this change eventually is mapped from kernel to U-Boot side, OP-TEE
needs to be enabled by boards that use OP-TEE from U-Boot. But that
sounds logical and how it was before, why would OP-TEE be automatically
enabled.

Thanks,
Tomas


> 
> Thanks,
> Michal
> 
>