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.
---
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 938b014ca9231d265314c0d6a934d0be706e420b..b55c6b2e8e0e10916fdfe762f9b6ae04f89a2cfc 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -192,11 +192,6 @@ psci {
 	};
 
 	firmware {
-		optee: optee  {
-			compatible = "linaro,optee-tz";
-			method = "smc";
-		};
-
 		zynqmp_firmware: zynqmp-firmware {
 			compatible = "xlnx,zynqmp-firmware";
 			#power-domain-cells = <1>;

---
base-commit: ac3fd01e4c1efce8f2c054cdeb2ddd2fc0fb150d
change-id: 20251125-revert-zynqmp-optee-a9d77159b243

Best regards,
-- 
Tomas Melin <tomas.melin@vaisala.com>

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?

U-Boot also have optee driver. How is it probed when you remove this node?

Thanks,
Michal

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
> 
>