[PATCH 1/2] mach-snapdragon: of_fixup: Add OP-TEE DT fixup support

[PATCH 1/2] mach-snapdragon: of_fixup: Add OP-TEE DT fixup support

[Sumit Garg]

From: Sumit Garg <sumit.garg@oss.qualcomm.com>

Add support for OP-TEE live tree DT fixup support which enables U-Boot
OP-TEE driver to be probed. As well as the EFI DT fixup protocol allows
the live tree fixup to be carried over to the OS for the OP-TEE driver
in the OS to probe as well.

Note that this fixup only gets applied if CONFIG_OPTEE gets enabled.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
---
 arch/arm/mach-snapdragon/of_fixup.c | 34 +++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/mach-snapdragon/of_fixup.c b/arch/arm/mach-snapdragon/of_fixup.c
index eec2c0c757e..29a99f73cf3 100644
--- a/arch/arm/mach-snapdragon/of_fixup.c
+++ b/arch/arm/mach-snapdragon/of_fixup.c
@@ -146,6 +146,37 @@ static void fixup_power_domains(struct device_node *root)
 	}
 }
 
+static void add_optee_node(struct device_node *root)
+{
+	struct device_node *fw = NULL, *optee = NULL;
+	int ret;
+
+	fw = of_find_node_by_path("/firmware");
+	if (!fw) {
+		log_err("Failed to find /firmware node\n");
+		return;
+	}
+
+	ret = of_add_subnode(fw, "optee", strlen("optee") + 1, &optee);
+	if (ret) {
+		log_err("Failed to add 'maximum-speed' property: %d\n", ret);
+		return;
+	}
+
+	ret = of_write_prop(optee, "compatible", strlen("linaro,optee-tz") + 1,
+			    "linaro,optee-tz");
+	if (ret) {
+		log_err("Failed to optee 'compatible' property: %d\n", ret);
+		return;
+	}
+
+	ret = of_write_prop(optee, "method", strlen("smc") + 1, "smc");
+	if (ret) {
+		log_err("Failed to optee 'method' property: %d\n", ret);
+		return;
+	}
+}
+
 #define time_call(func, ...) \
 	do { \
 		u64 start = timer_get_us(); \
@@ -160,6 +191,9 @@ static int qcom_of_fixup_nodes(void * __maybe_unused ctx, struct event *event)
 	time_call(fixup_usb_nodes, root);
 	time_call(fixup_power_domains, root);
 
+	if (IS_ENABLED(CONFIG_OPTEE))
+		time_call(add_optee_node, root);
+
 	return 0;
 }
 
-- 
2.51.0

[PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Sumit Garg]

From: Sumit Garg <sumit.garg@oss.qualcomm.com>

Recently upstream TF-A/OP-TEE has started gaining support for Qcom
platforms. RB3Gen2 being the first one and more to come. U-Boot in
corresponding boot flow is packaged as a position independent executable.

So, lets add a generic U-Boot defconfig for Qcom platforms to support
TF-A/OP-TEE based TrustZone stack. Build command:

$ make qcom_tfa_optee_defconfig
$ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2

For more information refer here:
https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
---
 configs/qcom_tfa_optee_defconfig | 7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 configs/qcom_tfa_optee_defconfig

diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
new file mode 100644
index 00000000000..c398521770f
--- /dev/null
+++ b/configs/qcom_tfa_optee_defconfig
@@ -0,0 +1,7 @@
+# Configuration for building a generic U-Boot image
+# with support for TF-A/OP-TEE based Arm TrustZone stack.
+
+#include "qcom_defconfig"
+
+CONFIG_TEE=y
+CONFIG_OPTEE=y
-- 
2.51.0

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Casey Connolly]

On 29/12/2025 12:43, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> 
> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
> platforms. RB3Gen2 being the first one and more to come. U-Boot in
> corresponding boot flow is packaged as a position independent executable.
> 
> So, lets add a generic U-Boot defconfig for Qcom platforms to support
> TF-A/OP-TEE based TrustZone stack. Build command:
> 
> $ make qcom_tfa_optee_defconfig
> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2

This would be better suited as a config fragment rather than a new
defconfig imo.

But more importantly, enabling OPTEE support in U-Boot doesn't imply
that it will be used, just that it's supported.

So I think the more appropriate patch here would be to just enable
OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
affected).

Considering the other patch is based on this assumption that if OP-TEE
support is enabled then the board must be using it, a different approach
is definitely needed.

When I was looking into this last year I remember discussing this same
issue from the Linux side, there is a good argument to be made that
OP-TEE support in Linux shouldn't be based on the devicetree -
particularly in the Qualcomm case where whether or not OP-TEE is used is
a simple software change, nothing to do with hardware.

So in general I'm not particularly keen on this approach, I think it
/might/ be acceptable for U-Boot to have some fixup code to add the
OP-TEE node if OP-TEE is in use with the idea of phasing that out in
favour of runtime detection in the OS itself. I'd also expect that fixup
code to go in the generic U-Boot DT fixup code that runs before we jump
to the OS (like the EFI DT fixup function).

Kind regards,

> 
> For more information refer here:
> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> 
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
>  configs/qcom_tfa_optee_defconfig | 7 +++++++
>  1 file changed, 7 insertions(+)
>  create mode 100644 configs/qcom_tfa_optee_defconfig
> 
> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
> new file mode 100644
> index 00000000000..c398521770f
> --- /dev/null
> +++ b/configs/qcom_tfa_optee_defconfig
> @@ -0,0 +1,7 @@
> +# Configuration for building a generic U-Boot image
> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
> +
> +#include "qcom_defconfig"
> +
> +CONFIG_TEE=y
> +CONFIG_OPTEE=y

-- 
// Casey (she/her)

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Sumit Garg]

On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
> 
> 
> On 29/12/2025 12:43, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > 
> > Recently upstream TF-A/OP-TEE has started gaining support for Qcom
> > platforms. RB3Gen2 being the first one and more to come. U-Boot in
> > corresponding boot flow is packaged as a position independent executable.
> > 
> > So, lets add a generic U-Boot defconfig for Qcom platforms to support
> > TF-A/OP-TEE based TrustZone stack. Build command:
> > 
> > $ make qcom_tfa_optee_defconfig
> > $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
> 
> This would be better suited as a config fragment rather than a new
> defconfig imo.

That's fine with me to add it as a config fragment.

> 
> But more importantly, enabling OPTEE support in U-Boot doesn't imply
> that it will be used, just that it's supported.

There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
secure EFI variables based on OP-TEE secure storage. Have a look here [1].

And sure there will be more such use-cases like fTPM, KASLR etc. can be
supported based on OP-TEE.

[1] lib/efi_loader/efi_variable_tee.c

> 
> So I think the more appropriate patch here would be to just enable
> OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
> affected).

The OP-TEE driver in U-Boot itself is probed based on DT and it's not
only specific to Qcom platforms but every other platform using OP-TEE.

> 
> Considering the other patch is based on this assumption that if OP-TEE
> support is enabled then the board must be using it, a different approach
> is definitely needed.

Yeah that's true even with TF-A boot flow, there is possibility to boot
without OP-TEE as well. However, TF-A generally doesn't provide a
generic option to detect whether OP-TEE is running or not.

> 
> When I was looking into this last year I remember discussing this same
> issue from the Linux side, there is a good argument to be made that
> OP-TEE support in Linux shouldn't be based on the devicetree -
> particularly in the Qualcomm case where whether or not OP-TEE is used is
> a simple software change, nothing to do with hardware.

Sadly it's true for every other silicon vendor too. But OP-TEE support
based on DT has become an ABI unless migration for OP-TEE support based
on FF-A comes into picture.

> 
> So in general I'm not particularly keen on this approach, I think it
> /might/ be acceptable for U-Boot to have some fixup code to add the
> OP-TEE node if OP-TEE is in use with the idea of phasing that out in
> favour of runtime detection in the OS itself. I'd also expect that fixup
> code to go in the generic U-Boot DT fixup code that runs before we jump
> to the OS (like the EFI DT fixup function).

The EFI DT fixup code is already there based on U-Boot DT. Have a look
here:

boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);

In general on Arm platforms there isn't any SMC bus to detect
dynamically if there is support for OP-TEE or not. That's why
platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
similar to how we have the SCM DT node for Qcom platforms.

FF-A bus tries to solve that problem to unify that approach for future
platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
driver too.

Anyhow, this is the sanest way I can come up with to enable OP-TEE
support in a general way for all the Qcom platforms. This is aligned
with how OP-TEE support is detected for other silicon vendors too.

-Sumit

> 
> Kind regards,
> 
> > 
> > For more information refer here:
> > https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> > 
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
> >  configs/qcom_tfa_optee_defconfig | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >  create mode 100644 configs/qcom_tfa_optee_defconfig
> > 
> > diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
> > new file mode 100644
> > index 00000000000..c398521770f
> > --- /dev/null
> > +++ b/configs/qcom_tfa_optee_defconfig
> > @@ -0,0 +1,7 @@
> > +# Configuration for building a generic U-Boot image
> > +# with support for TF-A/OP-TEE based Arm TrustZone stack.
> > +
> > +#include "qcom_defconfig"
> > +
> > +CONFIG_TEE=y
> > +CONFIG_OPTEE=y
> 
> -- 
> // Casey (she/her)
> 

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Casey Connolly]

On 09/01/2026 12:02, Sumit Garg wrote:
> On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
>>
>>
>> On 29/12/2025 12:43, Sumit Garg wrote:
>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>
>>> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
>>> platforms. RB3Gen2 being the first one and more to come. U-Boot in
>>> corresponding boot flow is packaged as a position independent executable.
>>>
>>> So, lets add a generic U-Boot defconfig for Qcom platforms to support
>>> TF-A/OP-TEE based TrustZone stack. Build command:
>>>
>>> $ make qcom_tfa_optee_defconfig
>>> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
>>
>> This would be better suited as a config fragment rather than a new
>> defconfig imo.
> 
> That's fine with me to add it as a config fragment.
> 
>>
>> But more importantly, enabling OPTEE support in U-Boot doesn't imply
>> that it will be used, just that it's supported.
> 
> There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
> secure EFI variables based on OP-TEE secure storage. Have a look here [1].
> 
> And sure there will be more such use-cases like fTPM, KASLR etc. can be
> supported based on OP-TEE.

I was referring literally to the fact that CONFIG_OPTEE being enabled
doesn't imply that OP-TEE is running, it's faulty logic to assume that's
the case and add nodes to the DT.

I just checked and there is an SMC call that tells you the UUID for the
trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
specifically.

My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
in qcom_psci_fixup(), compare the UUID and add the node if it matches.

> 
> [1] lib/efi_loader/efi_variable_tee.c
> 
>>
>> So I think the more appropriate patch here would be to just enable
>> OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
>> affected).
> 
> The OP-TEE driver in U-Boot itself is probed based on DT and it's not
> only specific to Qcom platforms but every other platform using OP-TEE.
> 
>>
>> Considering the other patch is based on this assumption that if OP-TEE
>> support is enabled then the board must be using it, a different approach
>> is definitely needed.
> 
> Yeah that's true even with TF-A boot flow, there is possibility to boot
> without OP-TEE as well. However, TF-A generally doesn't provide a
> generic option to detect whether OP-TEE is running or not.
> 
>>
>> When I was looking into this last year I remember discussing this same
>> issue from the Linux side, there is a good argument to be made that
>> OP-TEE support in Linux shouldn't be based on the devicetree -
>> particularly in the Qualcomm case where whether or not OP-TEE is used is
>> a simple software change, nothing to do with hardware.
> 
> Sadly it's true for every other silicon vendor too. But OP-TEE support
> based on DT has become an ABI unless migration for OP-TEE support based
> on FF-A comes into picture.
> 
>>
>> So in general I'm not particularly keen on this approach, I think it
>> /might/ be acceptable for U-Boot to have some fixup code to add the
>> OP-TEE node if OP-TEE is in use with the idea of phasing that out in
>> favour of runtime detection in the OS itself. I'd also expect that fixup
>> code to go in the generic U-Boot DT fixup code that runs before we jump
>> to the OS (like the EFI DT fixup function).
> 
> The EFI DT fixup code is already there based on U-Boot DT. Have a look
> here:
> 
> boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
> 
> In general on Arm platforms there isn't any SMC bus to detect
> dynamically if there is support for OP-TEE or not. That's why
> platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
> similar to how we have the SCM DT node for Qcom platforms.
> 
> FF-A bus tries to solve that problem to unify that approach for future
> platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
> driver too.
> 
> Anyhow, this is the sanest way I can come up with to enable OP-TEE
> support in a general way for all the Qcom platforms. This is aligned
> with how OP-TEE support is detected for other silicon vendors too.
> 
> -Sumit
> 
>>
>> Kind regards,
>>
>>>
>>> For more information refer here:
>>> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
>>>
>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>> ---
>>>  configs/qcom_tfa_optee_defconfig | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>  create mode 100644 configs/qcom_tfa_optee_defconfig
>>>
>>> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
>>> new file mode 100644
>>> index 00000000000..c398521770f
>>> --- /dev/null
>>> +++ b/configs/qcom_tfa_optee_defconfig
>>> @@ -0,0 +1,7 @@
>>> +# Configuration for building a generic U-Boot image
>>> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
>>> +
>>> +#include "qcom_defconfig"
>>> +
>>> +CONFIG_TEE=y
>>> +CONFIG_OPTEE=y
>>
>> -- 
>> // Casey (she/her)
>>

-- 
// Casey (she/her)

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Sumit Garg]

On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
> 
> 
> On 09/01/2026 12:02, Sumit Garg wrote:
> > On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
> >>
> >>
> >> On 29/12/2025 12:43, Sumit Garg wrote:
> >>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >>>
> >>> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
> >>> platforms. RB3Gen2 being the first one and more to come. U-Boot in
> >>> corresponding boot flow is packaged as a position independent executable.
> >>>
> >>> So, lets add a generic U-Boot defconfig for Qcom platforms to support
> >>> TF-A/OP-TEE based TrustZone stack. Build command:
> >>>
> >>> $ make qcom_tfa_optee_defconfig
> >>> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
> >>
> >> This would be better suited as a config fragment rather than a new
> >> defconfig imo.
> > 
> > That's fine with me to add it as a config fragment.
> > 
> >>
> >> But more importantly, enabling OPTEE support in U-Boot doesn't imply
> >> that it will be used, just that it's supported.
> > 
> > There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
> > secure EFI variables based on OP-TEE secure storage. Have a look here [1].
> > 
> > And sure there will be more such use-cases like fTPM, KASLR etc. can be
> > supported based on OP-TEE.
> 
> I was referring literally to the fact that CONFIG_OPTEE being enabled
> doesn't imply that OP-TEE is running, it's faulty logic to assume that's
> the case and add nodes to the DT.

I don't disagree here as having a runtime check is always a better
choice then a compile time config option. However, there isn't a common
info method from properietary firmware that says if QTEE is running
instead of OP-TEE.

> 
> I just checked and there is an SMC call that tells you the UUID for the
> trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
> OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
> specifically.

Also, we don't know how the QTEE will react to this OP-TEE specific SMC
call given it's different variants running on legacy and the newer SoCs.
So I would suggest to better gate OP-TEE presence behind a compile time
check only.

> 
> My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
> in qcom_psci_fixup(), compare the UUID and add the node if it matches.

That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
does to compare the UUID here [1] and bail out of the driver. I don't
see a value of a redundant invoke in the Qcom specific platform code.

[1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))

-Sumit

> 
> > 
> > [1] lib/efi_loader/efi_variable_tee.c
> > 
> >>
> >> So I think the more appropriate patch here would be to just enable
> >> OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
> >> affected).
> > 
> > The OP-TEE driver in U-Boot itself is probed based on DT and it's not
> > only specific to Qcom platforms but every other platform using OP-TEE.
> > 
> >>
> >> Considering the other patch is based on this assumption that if OP-TEE
> >> support is enabled then the board must be using it, a different approach
> >> is definitely needed.
> > 
> > Yeah that's true even with TF-A boot flow, there is possibility to boot
> > without OP-TEE as well. However, TF-A generally doesn't provide a
> > generic option to detect whether OP-TEE is running or not.
> > 
> >>
> >> When I was looking into this last year I remember discussing this same
> >> issue from the Linux side, there is a good argument to be made that
> >> OP-TEE support in Linux shouldn't be based on the devicetree -
> >> particularly in the Qualcomm case where whether or not OP-TEE is used is
> >> a simple software change, nothing to do with hardware.
> > 
> > Sadly it's true for every other silicon vendor too. But OP-TEE support
> > based on DT has become an ABI unless migration for OP-TEE support based
> > on FF-A comes into picture.
> > 
> >>
> >> So in general I'm not particularly keen on this approach, I think it
> >> /might/ be acceptable for U-Boot to have some fixup code to add the
> >> OP-TEE node if OP-TEE is in use with the idea of phasing that out in
> >> favour of runtime detection in the OS itself. I'd also expect that fixup
> >> code to go in the generic U-Boot DT fixup code that runs before we jump
> >> to the OS (like the EFI DT fixup function).
> > 
> > The EFI DT fixup code is already there based on U-Boot DT. Have a look
> > here:
> > 
> > boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
> > 
> > In general on Arm platforms there isn't any SMC bus to detect
> > dynamically if there is support for OP-TEE or not. That's why
> > platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
> > similar to how we have the SCM DT node for Qcom platforms.
> > 
> > FF-A bus tries to solve that problem to unify that approach for future
> > platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
> > driver too.
> > 
> > Anyhow, this is the sanest way I can come up with to enable OP-TEE
> > support in a general way for all the Qcom platforms. This is aligned
> > with how OP-TEE support is detected for other silicon vendors too.
> > 
> > -Sumit
> > 
> >>
> >> Kind regards,
> >>
> >>>
> >>> For more information refer here:
> >>> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> >>>
> >>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >>> ---
> >>>  configs/qcom_tfa_optee_defconfig | 7 +++++++
> >>>  1 file changed, 7 insertions(+)
> >>>  create mode 100644 configs/qcom_tfa_optee_defconfig
> >>>
> >>> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
> >>> new file mode 100644
> >>> index 00000000000..c398521770f
> >>> --- /dev/null
> >>> +++ b/configs/qcom_tfa_optee_defconfig
> >>> @@ -0,0 +1,7 @@
> >>> +# Configuration for building a generic U-Boot image
> >>> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
> >>> +
> >>> +#include "qcom_defconfig"
> >>> +
> >>> +CONFIG_TEE=y
> >>> +CONFIG_OPTEE=y
> >>
> >> -- 
> >> // Casey (she/her)
> >>
> 
> -- 
> // Casey (she/her)
> 

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[neil.armstrong]

On 1/15/26 07:10, Sumit Garg wrote:
> On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
>>
>>
>> On 09/01/2026 12:02, Sumit Garg wrote:
>>> On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
>>>>
>>>>
>>>> On 29/12/2025 12:43, Sumit Garg wrote:
>>>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>
>>>>> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
>>>>> platforms. RB3Gen2 being the first one and more to come. U-Boot in
>>>>> corresponding boot flow is packaged as a position independent executable.
>>>>>
>>>>> So, lets add a generic U-Boot defconfig for Qcom platforms to support
>>>>> TF-A/OP-TEE based TrustZone stack. Build command:
>>>>>
>>>>> $ make qcom_tfa_optee_defconfig
>>>>> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
>>>>
>>>> This would be better suited as a config fragment rather than a new
>>>> defconfig imo.
>>>
>>> That's fine with me to add it as a config fragment.
>>>
>>>>
>>>> But more importantly, enabling OPTEE support in U-Boot doesn't imply
>>>> that it will be used, just that it's supported.
>>>
>>> There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
>>> secure EFI variables based on OP-TEE secure storage. Have a look here [1].
>>>
>>> And sure there will be more such use-cases like fTPM, KASLR etc. can be
>>> supported based on OP-TEE.
>>
>> I was referring literally to the fact that CONFIG_OPTEE being enabled
>> doesn't imply that OP-TEE is running, it's faulty logic to assume that's
>> the case and add nodes to the DT.
> 
> I don't disagree here as having a runtime check is always a better
> choice then a compile time config option. However, there isn't a common
> info method from properietary firmware that says if QTEE is running
> instead of OP-TEE.
> 
>>
>> I just checked and there is an SMC call that tells you the UUID for the
>> trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
>> OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
>> specifically.
> 
> Also, we don't know how the QTEE will react to this OP-TEE specific SMC
> call given it's different variants running on legacy and the newer SoCs.
> So I would suggest to better gate OP-TEE presence behind a compile time
> check only.

So you say it's fine to add the optee node, and the driver will bail out if
OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
in the fixup code to enable OPTEE only if present ?

It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
node only if present _AND_ if CONFIG_OPTEE is enabled.

Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
select OPTEE explicitly on desired platforms, and won't run the naughty
OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.

Neil

> 
>>
>> My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
>> in qcom_psci_fixup(), compare the UUID and add the node if it matches.
> 
> That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
> does to compare the UUID here [1] and bail out of the driver. I don't
> see a value of a redundant invoke in the Qcom specific platform code.
> 
> [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
> 
> -Sumit
> 
>>
>>>
>>> [1] lib/efi_loader/efi_variable_tee.c
>>>
>>>>
>>>> So I think the more appropriate patch here would be to just enable
>>>> OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
>>>> affected).
>>>
>>> The OP-TEE driver in U-Boot itself is probed based on DT and it's not
>>> only specific to Qcom platforms but every other platform using OP-TEE.
>>>
>>>>
>>>> Considering the other patch is based on this assumption that if OP-TEE
>>>> support is enabled then the board must be using it, a different approach
>>>> is definitely needed.
>>>
>>> Yeah that's true even with TF-A boot flow, there is possibility to boot
>>> without OP-TEE as well. However, TF-A generally doesn't provide a
>>> generic option to detect whether OP-TEE is running or not.
>>>
>>>>
>>>> When I was looking into this last year I remember discussing this same
>>>> issue from the Linux side, there is a good argument to be made that
>>>> OP-TEE support in Linux shouldn't be based on the devicetree -
>>>> particularly in the Qualcomm case where whether or not OP-TEE is used is
>>>> a simple software change, nothing to do with hardware.
>>>
>>> Sadly it's true for every other silicon vendor too. But OP-TEE support
>>> based on DT has become an ABI unless migration for OP-TEE support based
>>> on FF-A comes into picture.
>>>
>>>>
>>>> So in general I'm not particularly keen on this approach, I think it
>>>> /might/ be acceptable for U-Boot to have some fixup code to add the
>>>> OP-TEE node if OP-TEE is in use with the idea of phasing that out in
>>>> favour of runtime detection in the OS itself. I'd also expect that fixup
>>>> code to go in the generic U-Boot DT fixup code that runs before we jump
>>>> to the OS (like the EFI DT fixup function).
>>>
>>> The EFI DT fixup code is already there based on U-Boot DT. Have a look
>>> here:
>>>
>>> boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
>>>
>>> In general on Arm platforms there isn't any SMC bus to detect
>>> dynamically if there is support for OP-TEE or not. That's why
>>> platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
>>> similar to how we have the SCM DT node for Qcom platforms.
>>>
>>> FF-A bus tries to solve that problem to unify that approach for future
>>> platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
>>> driver too.
>>>
>>> Anyhow, this is the sanest way I can come up with to enable OP-TEE
>>> support in a general way for all the Qcom platforms. This is aligned
>>> with how OP-TEE support is detected for other silicon vendors too.
>>>
>>> -Sumit
>>>
>>>>
>>>> Kind regards,
>>>>
>>>>>
>>>>> For more information refer here:
>>>>> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
>>>>>
>>>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>> ---
>>>>>   configs/qcom_tfa_optee_defconfig | 7 +++++++
>>>>>   1 file changed, 7 insertions(+)
>>>>>   create mode 100644 configs/qcom_tfa_optee_defconfig
>>>>>
>>>>> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
>>>>> new file mode 100644
>>>>> index 00000000000..c398521770f
>>>>> --- /dev/null
>>>>> +++ b/configs/qcom_tfa_optee_defconfig
>>>>> @@ -0,0 +1,7 @@
>>>>> +# Configuration for building a generic U-Boot image
>>>>> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
>>>>> +
>>>>> +#include "qcom_defconfig"
>>>>> +
>>>>> +CONFIG_TEE=y
>>>>> +CONFIG_OPTEE=y
>>>>
>>>> -- 
>>>> // Casey (she/her)
>>>>
>>
>> -- 
>> // Casey (she/her)
>>

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Sumit Garg]

+ Jens (OP-TEE driver author in U-Boot)

On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
> On 1/15/26 07:10, Sumit Garg wrote:
> > On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
> > > 
> > > 
> > > On 09/01/2026 12:02, Sumit Garg wrote:
> > > > On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
> > > > > 
> > > > > 
> > > > > On 29/12/2025 12:43, Sumit Garg wrote:
> > > > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > 
> > > > > > Recently upstream TF-A/OP-TEE has started gaining support for Qcom
> > > > > > platforms. RB3Gen2 being the first one and more to come. U-Boot in
> > > > > > corresponding boot flow is packaged as a position independent executable.
> > > > > > 
> > > > > > So, lets add a generic U-Boot defconfig for Qcom platforms to support
> > > > > > TF-A/OP-TEE based TrustZone stack. Build command:
> > > > > > 
> > > > > > $ make qcom_tfa_optee_defconfig
> > > > > > $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
> > > > > 
> > > > > This would be better suited as a config fragment rather than a new
> > > > > defconfig imo.
> > > > 
> > > > That's fine with me to add it as a config fragment.
> > > > 
> > > > > 
> > > > > But more importantly, enabling OPTEE support in U-Boot doesn't imply
> > > > > that it will be used, just that it's supported.
> > > > 
> > > > There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
> > > > secure EFI variables based on OP-TEE secure storage. Have a look here [1].
> > > > 
> > > > And sure there will be more such use-cases like fTPM, KASLR etc. can be
> > > > supported based on OP-TEE.
> > > 
> > > I was referring literally to the fact that CONFIG_OPTEE being enabled
> > > doesn't imply that OP-TEE is running, it's faulty logic to assume that's
> > > the case and add nodes to the DT.
> > 
> > I don't disagree here as having a runtime check is always a better
> > choice then a compile time config option. However, there isn't a common
> > info method from properietary firmware that says if QTEE is running
> > instead of OP-TEE.
> > 
> > > 
> > > I just checked and there is an SMC call that tells you the UUID for the
> > > trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
> > > OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
> > > specifically.
> > 
> > Also, we don't know how the QTEE will react to this OP-TEE specific SMC
> > call given it's different variants running on legacy and the newer SoCs.
> > So I would suggest to better gate OP-TEE presence behind a compile time
> > check only.
> 
> So you say it's fine to add the optee node, and the driver will bail out if
> OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
> in the fixup code to enable OPTEE only if present ?
> 
> It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
> was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
> node only if present _AND_ if CONFIG_OPTEE is enabled.
> 
> Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
> select OPTEE explicitly on desired platforms, and won't run the naughty
> OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.

I am still trying to understand what benefit does invoking
OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
can't be used to detect OP-TEE not present when QTEE is running due to
unknown behaviour with QTEE.

Jens,

Will it be fine with you to expose is_optee_api() from the OP-TEE driver
for the platform code to invoke it independently? Just for the sake of this
discussion in case people still insist on it being the right thing to do.

-Sumit

> 
> Neil
> 
> > 
> > > 
> > > My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
> > > in qcom_psci_fixup(), compare the UUID and add the node if it matches.
> > 
> > That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
> > does to compare the UUID here [1] and bail out of the driver. I don't
> > see a value of a redundant invoke in the Qcom specific platform code.
> > 
> > [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
> > 
> > -Sumit
> > 
> > > 
> > > > 
> > > > [1] lib/efi_loader/efi_variable_tee.c
> > > > 
> > > > > 
> > > > > So I think the more appropriate patch here would be to just enable
> > > > > OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
> > > > > affected).
> > > > 
> > > > The OP-TEE driver in U-Boot itself is probed based on DT and it's not
> > > > only specific to Qcom platforms but every other platform using OP-TEE.
> > > > 
> > > > > 
> > > > > Considering the other patch is based on this assumption that if OP-TEE
> > > > > support is enabled then the board must be using it, a different approach
> > > > > is definitely needed.
> > > > 
> > > > Yeah that's true even with TF-A boot flow, there is possibility to boot
> > > > without OP-TEE as well. However, TF-A generally doesn't provide a
> > > > generic option to detect whether OP-TEE is running or not.
> > > > 
> > > > > 
> > > > > When I was looking into this last year I remember discussing this same
> > > > > issue from the Linux side, there is a good argument to be made that
> > > > > OP-TEE support in Linux shouldn't be based on the devicetree -
> > > > > particularly in the Qualcomm case where whether or not OP-TEE is used is
> > > > > a simple software change, nothing to do with hardware.
> > > > 
> > > > Sadly it's true for every other silicon vendor too. But OP-TEE support
> > > > based on DT has become an ABI unless migration for OP-TEE support based
> > > > on FF-A comes into picture.
> > > > 
> > > > > 
> > > > > So in general I'm not particularly keen on this approach, I think it
> > > > > /might/ be acceptable for U-Boot to have some fixup code to add the
> > > > > OP-TEE node if OP-TEE is in use with the idea of phasing that out in
> > > > > favour of runtime detection in the OS itself. I'd also expect that fixup
> > > > > code to go in the generic U-Boot DT fixup code that runs before we jump
> > > > > to the OS (like the EFI DT fixup function).
> > > > 
> > > > The EFI DT fixup code is already there based on U-Boot DT. Have a look
> > > > here:
> > > > 
> > > > boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
> > > > 
> > > > In general on Arm platforms there isn't any SMC bus to detect
> > > > dynamically if there is support for OP-TEE or not. That's why
> > > > platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
> > > > similar to how we have the SCM DT node for Qcom platforms.
> > > > 
> > > > FF-A bus tries to solve that problem to unify that approach for future
> > > > platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
> > > > driver too.
> > > > 
> > > > Anyhow, this is the sanest way I can come up with to enable OP-TEE
> > > > support in a general way for all the Qcom platforms. This is aligned
> > > > with how OP-TEE support is detected for other silicon vendors too.
> > > > 
> > > > -Sumit
> > > > 
> > > > > 
> > > > > Kind regards,
> > > > > 
> > > > > > 
> > > > > > For more information refer here:
> > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> > > > > > 
> > > > > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > ---
> > > > > >   configs/qcom_tfa_optee_defconfig | 7 +++++++
> > > > > >   1 file changed, 7 insertions(+)
> > > > > >   create mode 100644 configs/qcom_tfa_optee_defconfig
> > > > > > 
> > > > > > diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
> > > > > > new file mode 100644
> > > > > > index 00000000000..c398521770f
> > > > > > --- /dev/null
> > > > > > +++ b/configs/qcom_tfa_optee_defconfig
> > > > > > @@ -0,0 +1,7 @@
> > > > > > +# Configuration for building a generic U-Boot image
> > > > > > +# with support for TF-A/OP-TEE based Arm TrustZone stack.
> > > > > > +
> > > > > > +#include "qcom_defconfig"
> > > > > > +
> > > > > > +CONFIG_TEE=y
> > > > > > +CONFIG_OPTEE=y
> > > > > 
> > > > > -- 
> > > > > // Casey (she/her)
> > > > > 
> > > 
> > > -- 
> > > // Casey (she/her)
> > > 
> 

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Neil Armstrong]

On 1/15/26 13:25, Sumit Garg wrote:
> + Jens (OP-TEE driver author in U-Boot)
> 
> On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
>> On 1/15/26 07:10, Sumit Garg wrote:
>>> On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
>>>>
>>>>
>>>> On 09/01/2026 12:02, Sumit Garg wrote:
>>>>> On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
>>>>>>
>>>>>>
>>>>>> On 29/12/2025 12:43, Sumit Garg wrote:
>>>>>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>>
>>>>>>> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
>>>>>>> platforms. RB3Gen2 being the first one and more to come. U-Boot in
>>>>>>> corresponding boot flow is packaged as a position independent executable.
>>>>>>>
>>>>>>> So, lets add a generic U-Boot defconfig for Qcom platforms to support
>>>>>>> TF-A/OP-TEE based TrustZone stack. Build command:
>>>>>>>
>>>>>>> $ make qcom_tfa_optee_defconfig
>>>>>>> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
>>>>>>
>>>>>> This would be better suited as a config fragment rather than a new
>>>>>> defconfig imo.
>>>>>
>>>>> That's fine with me to add it as a config fragment.
>>>>>
>>>>>>
>>>>>> But more importantly, enabling OPTEE support in U-Boot doesn't imply
>>>>>> that it will be used, just that it's supported.
>>>>>
>>>>> There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
>>>>> secure EFI variables based on OP-TEE secure storage. Have a look here [1].
>>>>>
>>>>> And sure there will be more such use-cases like fTPM, KASLR etc. can be
>>>>> supported based on OP-TEE.
>>>>
>>>> I was referring literally to the fact that CONFIG_OPTEE being enabled
>>>> doesn't imply that OP-TEE is running, it's faulty logic to assume that's
>>>> the case and add nodes to the DT.
>>>
>>> I don't disagree here as having a runtime check is always a better
>>> choice then a compile time config option. However, there isn't a common
>>> info method from properietary firmware that says if QTEE is running
>>> instead of OP-TEE.
>>>
>>>>
>>>> I just checked and there is an SMC call that tells you the UUID for the
>>>> trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
>>>> OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
>>>> specifically.
>>>
>>> Also, we don't know how the QTEE will react to this OP-TEE specific SMC
>>> call given it's different variants running on legacy and the newer SoCs.
>>> So I would suggest to better gate OP-TEE presence behind a compile time
>>> check only.
>>
>> So you say it's fine to add the optee node, and the driver will bail out if
>> OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
>> in the fixup code to enable OPTEE only if present ?
>>
>> It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
>> was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
>> node only if present _AND_ if CONFIG_OPTEE is enabled.
>>
>> Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
>> select OPTEE explicitly on desired platforms, and won't run the naughty
>> OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
> 
> I am still trying to understand what benefit does invoking
> OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
> can't be used to detect OP-TEE not present when QTEE is running due to
> unknown behaviour with QTEE.

Sorry but what exactly do you expect that will happen if you enable the OPTEE
driver when running with QTEE ?

> 
> Jens,
> 
> Will it be fine with you to expose is_optee_api() from the OP-TEE driver
> for the platform code to invoke it independently? Just for the sake of this
> discussion in case people still insist on it being the right thing to do.
> 
> -Sumit
> 
>>
>> Neil
>>
>>>
>>>>
>>>> My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
>>>> in qcom_psci_fixup(), compare the UUID and add the node if it matches.
>>>
>>> That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
>>> does to compare the UUID here [1] and bail out of the driver. I don't
>>> see a value of a redundant invoke in the Qcom specific platform code.
>>>
>>> [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
>>>
>>> -Sumit
>>>
>>>>
>>>>>
>>>>> [1] lib/efi_loader/efi_variable_tee.c
>>>>>
>>>>>>
>>>>>> So I think the more appropriate patch here would be to just enable
>>>>>> OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
>>>>>> affected).
>>>>>
>>>>> The OP-TEE driver in U-Boot itself is probed based on DT and it's not
>>>>> only specific to Qcom platforms but every other platform using OP-TEE.
>>>>>
>>>>>>
>>>>>> Considering the other patch is based on this assumption that if OP-TEE
>>>>>> support is enabled then the board must be using it, a different approach
>>>>>> is definitely needed.
>>>>>
>>>>> Yeah that's true even with TF-A boot flow, there is possibility to boot
>>>>> without OP-TEE as well. However, TF-A generally doesn't provide a
>>>>> generic option to detect whether OP-TEE is running or not.
>>>>>
>>>>>>
>>>>>> When I was looking into this last year I remember discussing this same
>>>>>> issue from the Linux side, there is a good argument to be made that
>>>>>> OP-TEE support in Linux shouldn't be based on the devicetree -
>>>>>> particularly in the Qualcomm case where whether or not OP-TEE is used is
>>>>>> a simple software change, nothing to do with hardware.
>>>>>
>>>>> Sadly it's true for every other silicon vendor too. But OP-TEE support
>>>>> based on DT has become an ABI unless migration for OP-TEE support based
>>>>> on FF-A comes into picture.
>>>>>
>>>>>>
>>>>>> So in general I'm not particularly keen on this approach, I think it
>>>>>> /might/ be acceptable for U-Boot to have some fixup code to add the
>>>>>> OP-TEE node if OP-TEE is in use with the idea of phasing that out in
>>>>>> favour of runtime detection in the OS itself. I'd also expect that fixup
>>>>>> code to go in the generic U-Boot DT fixup code that runs before we jump
>>>>>> to the OS (like the EFI DT fixup function).
>>>>>
>>>>> The EFI DT fixup code is already there based on U-Boot DT. Have a look
>>>>> here:
>>>>>
>>>>> boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
>>>>>
>>>>> In general on Arm platforms there isn't any SMC bus to detect
>>>>> dynamically if there is support for OP-TEE or not. That's why
>>>>> platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
>>>>> similar to how we have the SCM DT node for Qcom platforms.
>>>>>
>>>>> FF-A bus tries to solve that problem to unify that approach for future
>>>>> platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
>>>>> driver too.
>>>>>
>>>>> Anyhow, this is the sanest way I can come up with to enable OP-TEE
>>>>> support in a general way for all the Qcom platforms. This is aligned
>>>>> with how OP-TEE support is detected for other silicon vendors too.
>>>>>
>>>>> -Sumit
>>>>>
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>>>
>>>>>>> For more information refer here:
>>>>>>> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
>>>>>>>
>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>> ---
>>>>>>>    configs/qcom_tfa_optee_defconfig | 7 +++++++
>>>>>>>    1 file changed, 7 insertions(+)
>>>>>>>    create mode 100644 configs/qcom_tfa_optee_defconfig
>>>>>>>
>>>>>>> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
>>>>>>> new file mode 100644
>>>>>>> index 00000000000..c398521770f
>>>>>>> --- /dev/null
>>>>>>> +++ b/configs/qcom_tfa_optee_defconfig
>>>>>>> @@ -0,0 +1,7 @@
>>>>>>> +# Configuration for building a generic U-Boot image
>>>>>>> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
>>>>>>> +
>>>>>>> +#include "qcom_defconfig"
>>>>>>> +
>>>>>>> +CONFIG_TEE=y
>>>>>>> +CONFIG_OPTEE=y
>>>>>>
>>>>>> -- 
>>>>>> // Casey (she/her)
>>>>>>
>>>>
>>>> -- 
>>>> // Casey (she/her)
>>>>
>>

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Sumit Garg]

On Thu, Jan 15, 2026 at 02:03:29PM +0100, Neil Armstrong wrote:
> On 1/15/26 13:25, Sumit Garg wrote:
> > + Jens (OP-TEE driver author in U-Boot)
> > 
> > On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
> > > On 1/15/26 07:10, Sumit Garg wrote:
> > > > On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
> > > > > 
> > > > > 
> > > > > On 09/01/2026 12:02, Sumit Garg wrote:
> > > > > > On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 29/12/2025 12:43, Sumit Garg wrote:
> > > > > > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > > > 
> > > > > > > > Recently upstream TF-A/OP-TEE has started gaining support for Qcom
> > > > > > > > platforms. RB3Gen2 being the first one and more to come. U-Boot in
> > > > > > > > corresponding boot flow is packaged as a position independent executable.
> > > > > > > > 
> > > > > > > > So, lets add a generic U-Boot defconfig for Qcom platforms to support
> > > > > > > > TF-A/OP-TEE based TrustZone stack. Build command:
> > > > > > > > 
> > > > > > > > $ make qcom_tfa_optee_defconfig
> > > > > > > > $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
> > > > > > > 
> > > > > > > This would be better suited as a config fragment rather than a new
> > > > > > > defconfig imo.
> > > > > > 
> > > > > > That's fine with me to add it as a config fragment.
> > > > > > 
> > > > > > > 
> > > > > > > But more importantly, enabling OPTEE support in U-Boot doesn't imply
> > > > > > > that it will be used, just that it's supported.
> > > > > > 
> > > > > > There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
> > > > > > secure EFI variables based on OP-TEE secure storage. Have a look here [1].
> > > > > > 
> > > > > > And sure there will be more such use-cases like fTPM, KASLR etc. can be
> > > > > > supported based on OP-TEE.
> > > > > 
> > > > > I was referring literally to the fact that CONFIG_OPTEE being enabled
> > > > > doesn't imply that OP-TEE is running, it's faulty logic to assume that's
> > > > > the case and add nodes to the DT.
> > > > 
> > > > I don't disagree here as having a runtime check is always a better
> > > > choice then a compile time config option. However, there isn't a common
> > > > info method from properietary firmware that says if QTEE is running
> > > > instead of OP-TEE.
> > > > 
> > > > > 
> > > > > I just checked and there is an SMC call that tells you the UUID for the
> > > > > trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
> > > > > OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
> > > > > specifically.
> > > > 
> > > > Also, we don't know how the QTEE will react to this OP-TEE specific SMC
> > > > call given it's different variants running on legacy and the newer SoCs.
> > > > So I would suggest to better gate OP-TEE presence behind a compile time
> > > > check only.
> > > 
> > > So you say it's fine to add the optee node, and the driver will bail out if
> > > OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
> > > in the fixup code to enable OPTEE only if present ?
> > > 
> > > It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
> > > was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
> > > node only if present _AND_ if CONFIG_OPTEE is enabled.
> > > 
> > > Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
> > > select OPTEE explicitly on desired platforms, and won't run the naughty
> > > OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
> > 
> > I am still trying to understand what benefit does invoking
> > OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
> > can't be used to detect OP-TEE not present when QTEE is running due to
> > unknown behaviour with QTEE.
> 
> Sorry but what exactly do you expect that will happen if you enable the OPTEE
> driver when running with QTEE ?

The OP-TEE SMC calls are not at all supported with QTEE, so the expected
behaviour is undefined. IOW, the OP-TEE SMC ABI is not compatible with
QTEE. However, it's going to be hit and trial method to see what QTEE
responds to OP-TEE SMC calls. So it's not a reliable source of
information we can use to detect which TEE is present or not.

-Sumit

> 
> > 
> > Jens,
> > 
> > Will it be fine with you to expose is_optee_api() from the OP-TEE driver
> > for the platform code to invoke it independently? Just for the sake of this
> > discussion in case people still insist on it being the right thing to do.
> > 
> > -Sumit
> > 
> > > 
> > > Neil
> > > 
> > > > 
> > > > > 
> > > > > My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
> > > > > in qcom_psci_fixup(), compare the UUID and add the node if it matches.
> > > > 
> > > > That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
> > > > does to compare the UUID here [1] and bail out of the driver. I don't
> > > > see a value of a redundant invoke in the Qcom specific platform code.
> > > > 
> > > > [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
> > > > 
> > > > -Sumit
> > > > 
> > > > > 
> > > > > > 
> > > > > > [1] lib/efi_loader/efi_variable_tee.c
> > > > > > 
> > > > > > > 
> > > > > > > So I think the more appropriate patch here would be to just enable
> > > > > > > OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
> > > > > > > affected).
> > > > > > 
> > > > > > The OP-TEE driver in U-Boot itself is probed based on DT and it's not
> > > > > > only specific to Qcom platforms but every other platform using OP-TEE.
> > > > > > 
> > > > > > > 
> > > > > > > Considering the other patch is based on this assumption that if OP-TEE
> > > > > > > support is enabled then the board must be using it, a different approach
> > > > > > > is definitely needed.
> > > > > > 
> > > > > > Yeah that's true even with TF-A boot flow, there is possibility to boot
> > > > > > without OP-TEE as well. However, TF-A generally doesn't provide a
> > > > > > generic option to detect whether OP-TEE is running or not.
> > > > > > 
> > > > > > > 
> > > > > > > When I was looking into this last year I remember discussing this same
> > > > > > > issue from the Linux side, there is a good argument to be made that
> > > > > > > OP-TEE support in Linux shouldn't be based on the devicetree -
> > > > > > > particularly in the Qualcomm case where whether or not OP-TEE is used is
> > > > > > > a simple software change, nothing to do with hardware.
> > > > > > 
> > > > > > Sadly it's true for every other silicon vendor too. But OP-TEE support
> > > > > > based on DT has become an ABI unless migration for OP-TEE support based
> > > > > > on FF-A comes into picture.
> > > > > > 
> > > > > > > 
> > > > > > > So in general I'm not particularly keen on this approach, I think it
> > > > > > > /might/ be acceptable for U-Boot to have some fixup code to add the
> > > > > > > OP-TEE node if OP-TEE is in use with the idea of phasing that out in
> > > > > > > favour of runtime detection in the OS itself. I'd also expect that fixup
> > > > > > > code to go in the generic U-Boot DT fixup code that runs before we jump
> > > > > > > to the OS (like the EFI DT fixup function).
> > > > > > 
> > > > > > The EFI DT fixup code is already there based on U-Boot DT. Have a look
> > > > > > here:
> > > > > > 
> > > > > > boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
> > > > > > 
> > > > > > In general on Arm platforms there isn't any SMC bus to detect
> > > > > > dynamically if there is support for OP-TEE or not. That's why
> > > > > > platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
> > > > > > similar to how we have the SCM DT node for Qcom platforms.
> > > > > > 
> > > > > > FF-A bus tries to solve that problem to unify that approach for future
> > > > > > platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
> > > > > > driver too.
> > > > > > 
> > > > > > Anyhow, this is the sanest way I can come up with to enable OP-TEE
> > > > > > support in a general way for all the Qcom platforms. This is aligned
> > > > > > with how OP-TEE support is detected for other silicon vendors too.
> > > > > > 
> > > > > > -Sumit
> > > > > > 
> > > > > > > 
> > > > > > > Kind regards,
> > > > > > > 
> > > > > > > > 
> > > > > > > > For more information refer here:
> > > > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> > > > > > > > 
> > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > > > ---
> > > > > > > >    configs/qcom_tfa_optee_defconfig | 7 +++++++
> > > > > > > >    1 file changed, 7 insertions(+)
> > > > > > > >    create mode 100644 configs/qcom_tfa_optee_defconfig
> > > > > > > > 
> > > > > > > > diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
> > > > > > > > new file mode 100644
> > > > > > > > index 00000000000..c398521770f
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/configs/qcom_tfa_optee_defconfig
> > > > > > > > @@ -0,0 +1,7 @@
> > > > > > > > +# Configuration for building a generic U-Boot image
> > > > > > > > +# with support for TF-A/OP-TEE based Arm TrustZone stack.
> > > > > > > > +
> > > > > > > > +#include "qcom_defconfig"
> > > > > > > > +
> > > > > > > > +CONFIG_TEE=y
> > > > > > > > +CONFIG_OPTEE=y
> > > > > > > 
> > > > > > > -- 
> > > > > > > // Casey (she/her)
> > > > > > > 
> > > > > 
> > > > > -- 
> > > > > // Casey (she/her)
> > > > > 
> > > 
> 

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Neil Armstrong]

On 1/15/26 14:27, Sumit Garg wrote:
> On Thu, Jan 15, 2026 at 02:03:29PM +0100, Neil Armstrong wrote:
>> On 1/15/26 13:25, Sumit Garg wrote:
>>> + Jens (OP-TEE driver author in U-Boot)
>>>
>>> On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
>>>> On 1/15/26 07:10, Sumit Garg wrote:
>>>>> On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
>>>>>>
>>>>>>
>>>>>> On 09/01/2026 12:02, Sumit Garg wrote:
>>>>>>> On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29/12/2025 12:43, Sumit Garg wrote:
>>>>>>>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>>>>
>>>>>>>>> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
>>>>>>>>> platforms. RB3Gen2 being the first one and more to come. U-Boot in
>>>>>>>>> corresponding boot flow is packaged as a position independent executable.
>>>>>>>>>
>>>>>>>>> So, lets add a generic U-Boot defconfig for Qcom platforms to support
>>>>>>>>> TF-A/OP-TEE based TrustZone stack. Build command:
>>>>>>>>>
>>>>>>>>> $ make qcom_tfa_optee_defconfig
>>>>>>>>> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
>>>>>>>>
>>>>>>>> This would be better suited as a config fragment rather than a new
>>>>>>>> defconfig imo.
>>>>>>>
>>>>>>> That's fine with me to add it as a config fragment.
>>>>>>>
>>>>>>>>
>>>>>>>> But more importantly, enabling OPTEE support in U-Boot doesn't imply
>>>>>>>> that it will be used, just that it's supported.
>>>>>>>
>>>>>>> There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
>>>>>>> secure EFI variables based on OP-TEE secure storage. Have a look here [1].
>>>>>>>
>>>>>>> And sure there will be more such use-cases like fTPM, KASLR etc. can be
>>>>>>> supported based on OP-TEE.
>>>>>>
>>>>>> I was referring literally to the fact that CONFIG_OPTEE being enabled
>>>>>> doesn't imply that OP-TEE is running, it's faulty logic to assume that's
>>>>>> the case and add nodes to the DT.
>>>>>
>>>>> I don't disagree here as having a runtime check is always a better
>>>>> choice then a compile time config option. However, there isn't a common
>>>>> info method from properietary firmware that says if QTEE is running
>>>>> instead of OP-TEE.
>>>>>
>>>>>>
>>>>>> I just checked and there is an SMC call that tells you the UUID for the
>>>>>> trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
>>>>>> OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
>>>>>> specifically.
>>>>>
>>>>> Also, we don't know how the QTEE will react to this OP-TEE specific SMC
>>>>> call given it's different variants running on legacy and the newer SoCs.
>>>>> So I would suggest to better gate OP-TEE presence behind a compile time
>>>>> check only.
>>>>
>>>> So you say it's fine to add the optee node, and the driver will bail out if
>>>> OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
>>>> in the fixup code to enable OPTEE only if present ?
>>>>
>>>> It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
>>>> was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
>>>> node only if present _AND_ if CONFIG_OPTEE is enabled.
>>>>
>>>> Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
>>>> select OPTEE explicitly on desired platforms, and won't run the naughty
>>>> OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
>>>
>>> I am still trying to understand what benefit does invoking
>>> OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
>>> can't be used to detect OP-TEE not present when QTEE is running due to
>>> unknown behaviour with QTEE.
>>
>> Sorry but what exactly do you expect that will happen if you enable the OPTEE
>> driver when running with QTEE ?
> 
> The OP-TEE SMC calls are not at all supported with QTEE, so the expected
> behaviour is undefined. IOW, the OP-TEE SMC ABI is not compatible with
> QTEE. However, it's going to be hit and trial method to see what QTEE
> responds to OP-TEE SMC calls. So it's not a reliable source of
> information we can use to detect which TEE is present or not.

So until we know, this change is a no go, we can't just add the /optee node
and hope the person building uboot did the right thing.

I propose an alternate way, is to check for QTEE and then test for OPTEE.

Neil

> 
> -Sumit
> 
>>
>>>
>>> Jens,
>>>
>>> Will it be fine with you to expose is_optee_api() from the OP-TEE driver
>>> for the platform code to invoke it independently? Just for the sake of this
>>> discussion in case people still insist on it being the right thing to do.
>>>
>>> -Sumit
>>>
>>>>
>>>> Neil
>>>>
>>>>>
>>>>>>
>>>>>> My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
>>>>>> in qcom_psci_fixup(), compare the UUID and add the node if it matches.
>>>>>
>>>>> That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
>>>>> does to compare the UUID here [1] and bail out of the driver. I don't
>>>>> see a value of a redundant invoke in the Qcom specific platform code.
>>>>>
>>>>> [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
>>>>>
>>>>> -Sumit
>>>>>
>>>>>>
>>>>>>>
>>>>>>> [1] lib/efi_loader/efi_variable_tee.c
>>>>>>>
>>>>>>>>
>>>>>>>> So I think the more appropriate patch here would be to just enable
>>>>>>>> OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
>>>>>>>> affected).
>>>>>>>
>>>>>>> The OP-TEE driver in U-Boot itself is probed based on DT and it's not
>>>>>>> only specific to Qcom platforms but every other platform using OP-TEE.
>>>>>>>
>>>>>>>>
>>>>>>>> Considering the other patch is based on this assumption that if OP-TEE
>>>>>>>> support is enabled then the board must be using it, a different approach
>>>>>>>> is definitely needed.
>>>>>>>
>>>>>>> Yeah that's true even with TF-A boot flow, there is possibility to boot
>>>>>>> without OP-TEE as well. However, TF-A generally doesn't provide a
>>>>>>> generic option to detect whether OP-TEE is running or not.
>>>>>>>
>>>>>>>>
>>>>>>>> When I was looking into this last year I remember discussing this same
>>>>>>>> issue from the Linux side, there is a good argument to be made that
>>>>>>>> OP-TEE support in Linux shouldn't be based on the devicetree -
>>>>>>>> particularly in the Qualcomm case where whether or not OP-TEE is used is
>>>>>>>> a simple software change, nothing to do with hardware.
>>>>>>>
>>>>>>> Sadly it's true for every other silicon vendor too. But OP-TEE support
>>>>>>> based on DT has become an ABI unless migration for OP-TEE support based
>>>>>>> on FF-A comes into picture.
>>>>>>>
>>>>>>>>
>>>>>>>> So in general I'm not particularly keen on this approach, I think it
>>>>>>>> /might/ be acceptable for U-Boot to have some fixup code to add the
>>>>>>>> OP-TEE node if OP-TEE is in use with the idea of phasing that out in
>>>>>>>> favour of runtime detection in the OS itself. I'd also expect that fixup
>>>>>>>> code to go in the generic U-Boot DT fixup code that runs before we jump
>>>>>>>> to the OS (like the EFI DT fixup function).
>>>>>>>
>>>>>>> The EFI DT fixup code is already there based on U-Boot DT. Have a look
>>>>>>> here:
>>>>>>>
>>>>>>> boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
>>>>>>>
>>>>>>> In general on Arm platforms there isn't any SMC bus to detect
>>>>>>> dynamically if there is support for OP-TEE or not. That's why
>>>>>>> platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
>>>>>>> similar to how we have the SCM DT node for Qcom platforms.
>>>>>>>
>>>>>>> FF-A bus tries to solve that problem to unify that approach for future
>>>>>>> platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
>>>>>>> driver too.
>>>>>>>
>>>>>>> Anyhow, this is the sanest way I can come up with to enable OP-TEE
>>>>>>> support in a general way for all the Qcom platforms. This is aligned
>>>>>>> with how OP-TEE support is detected for other silicon vendors too.
>>>>>>>
>>>>>>> -Sumit
>>>>>>>
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>>
>>>>>>>>>
>>>>>>>>> For more information refer here:
>>>>>>>>> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
>>>>>>>>>
>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>>>> ---
>>>>>>>>>     configs/qcom_tfa_optee_defconfig | 7 +++++++
>>>>>>>>>     1 file changed, 7 insertions(+)
>>>>>>>>>     create mode 100644 configs/qcom_tfa_optee_defconfig
>>>>>>>>>
>>>>>>>>> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
>>>>>>>>> new file mode 100644
>>>>>>>>> index 00000000000..c398521770f
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/configs/qcom_tfa_optee_defconfig
>>>>>>>>> @@ -0,0 +1,7 @@
>>>>>>>>> +# Configuration for building a generic U-Boot image
>>>>>>>>> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
>>>>>>>>> +
>>>>>>>>> +#include "qcom_defconfig"
>>>>>>>>> +
>>>>>>>>> +CONFIG_TEE=y
>>>>>>>>> +CONFIG_OPTEE=y
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> // Casey (she/her)
>>>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> // Casey (she/her)
>>>>>>
>>>>
>>

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Sumit Garg]

On Thu, Jan 15, 2026 at 02:35:23PM +0100, Neil Armstrong wrote:
> On 1/15/26 14:27, Sumit Garg wrote:
> > On Thu, Jan 15, 2026 at 02:03:29PM +0100, Neil Armstrong wrote:
> > > On 1/15/26 13:25, Sumit Garg wrote:
> > > > + Jens (OP-TEE driver author in U-Boot)
> > > > 
> > > > On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
> > > > > On 1/15/26 07:10, Sumit Garg wrote:
> > > > > > On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 09/01/2026 12:02, Sumit Garg wrote:
> > > > > > > > On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 29/12/2025 12:43, Sumit Garg wrote:
> > > > > > > > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > > > > > 
> > > > > > > > > > Recently upstream TF-A/OP-TEE has started gaining support for Qcom
> > > > > > > > > > platforms. RB3Gen2 being the first one and more to come. U-Boot in
> > > > > > > > > > corresponding boot flow is packaged as a position independent executable.
> > > > > > > > > > 
> > > > > > > > > > So, lets add a generic U-Boot defconfig for Qcom platforms to support
> > > > > > > > > > TF-A/OP-TEE based TrustZone stack. Build command:
> > > > > > > > > > 
> > > > > > > > > > $ make qcom_tfa_optee_defconfig
> > > > > > > > > > $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
> > > > > > > > > 
> > > > > > > > > This would be better suited as a config fragment rather than a new
> > > > > > > > > defconfig imo.
> > > > > > > > 
> > > > > > > > That's fine with me to add it as a config fragment.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > But more importantly, enabling OPTEE support in U-Boot doesn't imply
> > > > > > > > > that it will be used, just that it's supported.
> > > > > > > > 
> > > > > > > > There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
> > > > > > > > secure EFI variables based on OP-TEE secure storage. Have a look here [1].
> > > > > > > > 
> > > > > > > > And sure there will be more such use-cases like fTPM, KASLR etc. can be
> > > > > > > > supported based on OP-TEE.
> > > > > > > 
> > > > > > > I was referring literally to the fact that CONFIG_OPTEE being enabled
> > > > > > > doesn't imply that OP-TEE is running, it's faulty logic to assume that's
> > > > > > > the case and add nodes to the DT.
> > > > > > 
> > > > > > I don't disagree here as having a runtime check is always a better
> > > > > > choice then a compile time config option. However, there isn't a common
> > > > > > info method from properietary firmware that says if QTEE is running
> > > > > > instead of OP-TEE.
> > > > > > 
> > > > > > > 
> > > > > > > I just checked and there is an SMC call that tells you the UUID for the
> > > > > > > trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
> > > > > > > OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
> > > > > > > specifically.
> > > > > > 
> > > > > > Also, we don't know how the QTEE will react to this OP-TEE specific SMC
> > > > > > call given it's different variants running on legacy and the newer SoCs.
> > > > > > So I would suggest to better gate OP-TEE presence behind a compile time
> > > > > > check only.
> > > > > 
> > > > > So you say it's fine to add the optee node, and the driver will bail out if
> > > > > OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
> > > > > in the fixup code to enable OPTEE only if present ?
> > > > > 
> > > > > It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
> > > > > was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
> > > > > node only if present _AND_ if CONFIG_OPTEE is enabled.
> > > > > 
> > > > > Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
> > > > > select OPTEE explicitly on desired platforms, and won't run the naughty
> > > > > OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
> > > > 
> > > > I am still trying to understand what benefit does invoking
> > > > OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
> > > > can't be used to detect OP-TEE not present when QTEE is running due to
> > > > unknown behaviour with QTEE.
> > > 
> > > Sorry but what exactly do you expect that will happen if you enable the OPTEE
> > > driver when running with QTEE ?
> > 
> > The OP-TEE SMC calls are not at all supported with QTEE, so the expected
> > behaviour is undefined. IOW, the OP-TEE SMC ABI is not compatible with
> > QTEE. However, it's going to be hit and trial method to see what QTEE
> > responds to OP-TEE SMC calls. So it's not a reliable source of
> > information we can use to detect which TEE is present or not.
> 
> So until we know, this change is a no go, we can't just add the /optee node
> and hope the person building uboot did the right thing.

Not sure why you think Qualcomm platforms are special in this regards
when similar OP-TEE node additions based on CONFIG_OPTEE exist for other
platforms, see example here [1] [2] [3].

The OP-TEE configs will surely be part of a separate config fragment and
I can add comments there for developer's awareness.

[1] arch/arm/dts/imx8mm-u-boot.dtsi:10
[2] arch/arm/dts/imx8mn-u-boot.dtsi:10
[3] arch/arm/dts/imx8mp-u-boot.dtsi:11

> 
> I propose an alternate way, is to check for QTEE and then test for OPTEE.

There are more combinations rather than just QTEE or OP-TEE as follows:
- Older targets have support for QSEECOM
- Newer targets with QTEE support
- Chrome targets without any TEE support
- IoT targets with OP-TEE support

Do you have any particular mechanism in mind for detecting OP-TEE
presence at runtime? And surely that has to be well supported on variety
of SoC where U-Boot is supported as of now.

Also, there is added complexity for targets where the developer can't
change the TZ firmware themselves on Qcom SoCs due to QTI signing
requirement.

-Sumit

> 
> Neil
> 
> > 
> > -Sumit
> > 
> > > 
> > > > 
> > > > Jens,
> > > > 
> > > > Will it be fine with you to expose is_optee_api() from the OP-TEE driver
> > > > for the platform code to invoke it independently? Just for the sake of this
> > > > discussion in case people still insist on it being the right thing to do.
> > > > 
> > > > -Sumit
> > > > 
> > > > > 
> > > > > Neil
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
> > > > > > > in qcom_psci_fixup(), compare the UUID and add the node if it matches.
> > > > > > 
> > > > > > That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
> > > > > > does to compare the UUID here [1] and bail out of the driver. I don't
> > > > > > see a value of a redundant invoke in the Qcom specific platform code.
> > > > > > 
> > > > > > [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
> > > > > > 
> > > > > > -Sumit
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > [1] lib/efi_loader/efi_variable_tee.c
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > So I think the more appropriate patch here would be to just enable
> > > > > > > > > OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
> > > > > > > > > affected).
> > > > > > > > 
> > > > > > > > The OP-TEE driver in U-Boot itself is probed based on DT and it's not
> > > > > > > > only specific to Qcom platforms but every other platform using OP-TEE.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Considering the other patch is based on this assumption that if OP-TEE
> > > > > > > > > support is enabled then the board must be using it, a different approach
> > > > > > > > > is definitely needed.
> > > > > > > > 
> > > > > > > > Yeah that's true even with TF-A boot flow, there is possibility to boot
> > > > > > > > without OP-TEE as well. However, TF-A generally doesn't provide a
> > > > > > > > generic option to detect whether OP-TEE is running or not.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > When I was looking into this last year I remember discussing this same
> > > > > > > > > issue from the Linux side, there is a good argument to be made that
> > > > > > > > > OP-TEE support in Linux shouldn't be based on the devicetree -
> > > > > > > > > particularly in the Qualcomm case where whether or not OP-TEE is used is
> > > > > > > > > a simple software change, nothing to do with hardware.
> > > > > > > > 
> > > > > > > > Sadly it's true for every other silicon vendor too. But OP-TEE support
> > > > > > > > based on DT has become an ABI unless migration for OP-TEE support based
> > > > > > > > on FF-A comes into picture.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > So in general I'm not particularly keen on this approach, I think it
> > > > > > > > > /might/ be acceptable for U-Boot to have some fixup code to add the
> > > > > > > > > OP-TEE node if OP-TEE is in use with the idea of phasing that out in
> > > > > > > > > favour of runtime detection in the OS itself. I'd also expect that fixup
> > > > > > > > > code to go in the generic U-Boot DT fixup code that runs before we jump
> > > > > > > > > to the OS (like the EFI DT fixup function).
> > > > > > > > 
> > > > > > > > The EFI DT fixup code is already there based on U-Boot DT. Have a look
> > > > > > > > here:
> > > > > > > > 
> > > > > > > > boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
> > > > > > > > 
> > > > > > > > In general on Arm platforms there isn't any SMC bus to detect
> > > > > > > > dynamically if there is support for OP-TEE or not. That's why
> > > > > > > > platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
> > > > > > > > similar to how we have the SCM DT node for Qcom platforms.
> > > > > > > > 
> > > > > > > > FF-A bus tries to solve that problem to unify that approach for future
> > > > > > > > platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
> > > > > > > > driver too.
> > > > > > > > 
> > > > > > > > Anyhow, this is the sanest way I can come up with to enable OP-TEE
> > > > > > > > support in a general way for all the Qcom platforms. This is aligned
> > > > > > > > with how OP-TEE support is detected for other silicon vendors too.
> > > > > > > > 
> > > > > > > > -Sumit
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Kind regards,
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > For more information refer here:
> > > > > > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > > > > > ---
> > > > > > > > > >     configs/qcom_tfa_optee_defconfig | 7 +++++++
> > > > > > > > > >     1 file changed, 7 insertions(+)
> > > > > > > > > >     create mode 100644 configs/qcom_tfa_optee_defconfig
> > > > > > > > > > 
> > > > > > > > > > diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
> > > > > > > > > > new file mode 100644
> > > > > > > > > > index 00000000000..c398521770f
> > > > > > > > > > --- /dev/null
> > > > > > > > > > +++ b/configs/qcom_tfa_optee_defconfig
> > > > > > > > > > @@ -0,0 +1,7 @@
> > > > > > > > > > +# Configuration for building a generic U-Boot image
> > > > > > > > > > +# with support for TF-A/OP-TEE based Arm TrustZone stack.
> > > > > > > > > > +
> > > > > > > > > > +#include "qcom_defconfig"
> > > > > > > > > > +
> > > > > > > > > > +CONFIG_TEE=y
> > > > > > > > > > +CONFIG_OPTEE=y
> > > > > > > > > 
> > > > > > > > > -- 
> > > > > > > > > // Casey (she/her)
> > > > > > > > > 
> > > > > > > 
> > > > > > > -- 
> > > > > > > // Casey (she/her)
> > > > > > > 
> > > > > 
> > > 
> 

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Neil Armstrong]

On 1/16/26 07:57, Sumit Garg wrote:
> On Thu, Jan 15, 2026 at 02:35:23PM +0100, Neil Armstrong wrote:
>> On 1/15/26 14:27, Sumit Garg wrote:
>>> On Thu, Jan 15, 2026 at 02:03:29PM +0100, Neil Armstrong wrote:
>>>> On 1/15/26 13:25, Sumit Garg wrote:
>>>>> + Jens (OP-TEE driver author in U-Boot)
>>>>>
>>>>> On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
>>>>>> On 1/15/26 07:10, Sumit Garg wrote:
>>>>>>> On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/01/2026 12:02, Sumit Garg wrote:
>>>>>>>>> On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 29/12/2025 12:43, Sumit Garg wrote:
>>>>>>>>>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>>>>>>
>>>>>>>>>>> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
>>>>>>>>>>> platforms. RB3Gen2 being the first one and more to come. U-Boot in
>>>>>>>>>>> corresponding boot flow is packaged as a position independent executable.
>>>>>>>>>>>
>>>>>>>>>>> So, lets add a generic U-Boot defconfig for Qcom platforms to support
>>>>>>>>>>> TF-A/OP-TEE based TrustZone stack. Build command:
>>>>>>>>>>>
>>>>>>>>>>> $ make qcom_tfa_optee_defconfig
>>>>>>>>>>> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
>>>>>>>>>>
>>>>>>>>>> This would be better suited as a config fragment rather than a new
>>>>>>>>>> defconfig imo.
>>>>>>>>>
>>>>>>>>> That's fine with me to add it as a config fragment.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But more importantly, enabling OPTEE support in U-Boot doesn't imply
>>>>>>>>>> that it will be used, just that it's supported.
>>>>>>>>>
>>>>>>>>> There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
>>>>>>>>> secure EFI variables based on OP-TEE secure storage. Have a look here [1].
>>>>>>>>>
>>>>>>>>> And sure there will be more such use-cases like fTPM, KASLR etc. can be
>>>>>>>>> supported based on OP-TEE.
>>>>>>>>
>>>>>>>> I was referring literally to the fact that CONFIG_OPTEE being enabled
>>>>>>>> doesn't imply that OP-TEE is running, it's faulty logic to assume that's
>>>>>>>> the case and add nodes to the DT.
>>>>>>>
>>>>>>> I don't disagree here as having a runtime check is always a better
>>>>>>> choice then a compile time config option. However, there isn't a common
>>>>>>> info method from properietary firmware that says if QTEE is running
>>>>>>> instead of OP-TEE.
>>>>>>>
>>>>>>>>
>>>>>>>> I just checked and there is an SMC call that tells you the UUID for the
>>>>>>>> trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
>>>>>>>> OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
>>>>>>>> specifically.
>>>>>>>
>>>>>>> Also, we don't know how the QTEE will react to this OP-TEE specific SMC
>>>>>>> call given it's different variants running on legacy and the newer SoCs.
>>>>>>> So I would suggest to better gate OP-TEE presence behind a compile time
>>>>>>> check only.
>>>>>>
>>>>>> So you say it's fine to add the optee node, and the driver will bail out if
>>>>>> OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
>>>>>> in the fixup code to enable OPTEE only if present ?
>>>>>>
>>>>>> It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
>>>>>> was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
>>>>>> node only if present _AND_ if CONFIG_OPTEE is enabled.
>>>>>>
>>>>>> Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
>>>>>> select OPTEE explicitly on desired platforms, and won't run the naughty
>>>>>> OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
>>>>>
>>>>> I am still trying to understand what benefit does invoking
>>>>> OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
>>>>> can't be used to detect OP-TEE not present when QTEE is running due to
>>>>> unknown behaviour with QTEE.
>>>>
>>>> Sorry but what exactly do you expect that will happen if you enable the OPTEE
>>>> driver when running with QTEE ?
>>>
>>> The OP-TEE SMC calls are not at all supported with QTEE, so the expected
>>> behaviour is undefined. IOW, the OP-TEE SMC ABI is not compatible with
>>> QTEE. However, it's going to be hit and trial method to see what QTEE
>>> responds to OP-TEE SMC calls. So it's not a reliable source of
>>> information we can use to detect which TEE is present or not.
>>
>> So until we know, this change is a no go, we can't just add the /optee node
>> and hope the person building uboot did the right thing.
> 
> Not sure why you think Qualcomm platforms are special in this regards
> when similar OP-TEE node additions based on CONFIG_OPTEE exist for other
> platforms, see example here [1] [2] [3].
> 
> The OP-TEE configs will surely be part of a separate config fragment and
> I can add comments there for developer's awareness.
> 
> [1] arch/arm/dts/imx8mm-u-boot.dtsi:10
> [2] arch/arm/dts/imx8mn-u-boot.dtsi:10
> [3] arch/arm/dts/imx8mp-u-boot.dtsi:11
> 
>>
>> I propose an alternate way, is to check for QTEE and then test for OPTEE.
> 
> There are more combinations rather than just QTEE or OP-TEE as follows:
> - Older targets have support for QSEECOM
> - Newer targets with QTEE support
> - Chrome targets without any TEE support
> - IoT targets with OP-TEE support
> 
> Do you have any particular mechanism in mind for detecting OP-TEE
> presence at runtime? And surely that has to be well supported on variety
> of SoC where U-Boot is supported as of now.

OPTEE_SMC_CALL_GET_OS_UUID which works fine on like all the other ARM based
platforms.

It's the only way, and only Qualcomm engineers can answer how to determine
without any risk which TEE is running on the system.

Without this, all this discussions is pointless.

> 
> Also, there is added complexity for targets where the developer can't
> change the TZ firmware themselves on Qcom SoCs due to QTI signing
> requirement.
> 
> -Sumit
> 
>>
>> Neil
>>
>>>
>>> -Sumit
>>>
>>>>
>>>>>
>>>>> Jens,
>>>>>
>>>>> Will it be fine with you to expose is_optee_api() from the OP-TEE driver
>>>>> for the platform code to invoke it independently? Just for the sake of this
>>>>> discussion in case people still insist on it being the right thing to do.
>>>>>
>>>>> -Sumit
>>>>>
>>>>>>
>>>>>> Neil
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
>>>>>>>> in qcom_psci_fixup(), compare the UUID and add the node if it matches.
>>>>>>>
>>>>>>> That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
>>>>>>> does to compare the UUID here [1] and bail out of the driver. I don't
>>>>>>> see a value of a redundant invoke in the Qcom specific platform code.
>>>>>>>
>>>>>>> [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
>>>>>>>
>>>>>>> -Sumit
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1] lib/efi_loader/efi_variable_tee.c
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So I think the more appropriate patch here would be to just enable
>>>>>>>>>> OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
>>>>>>>>>> affected).
>>>>>>>>>
>>>>>>>>> The OP-TEE driver in U-Boot itself is probed based on DT and it's not
>>>>>>>>> only specific to Qcom platforms but every other platform using OP-TEE.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Considering the other patch is based on this assumption that if OP-TEE
>>>>>>>>>> support is enabled then the board must be using it, a different approach
>>>>>>>>>> is definitely needed.
>>>>>>>>>
>>>>>>>>> Yeah that's true even with TF-A boot flow, there is possibility to boot
>>>>>>>>> without OP-TEE as well. However, TF-A generally doesn't provide a
>>>>>>>>> generic option to detect whether OP-TEE is running or not.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When I was looking into this last year I remember discussing this same
>>>>>>>>>> issue from the Linux side, there is a good argument to be made that
>>>>>>>>>> OP-TEE support in Linux shouldn't be based on the devicetree -
>>>>>>>>>> particularly in the Qualcomm case where whether or not OP-TEE is used is
>>>>>>>>>> a simple software change, nothing to do with hardware.
>>>>>>>>>
>>>>>>>>> Sadly it's true for every other silicon vendor too. But OP-TEE support
>>>>>>>>> based on DT has become an ABI unless migration for OP-TEE support based
>>>>>>>>> on FF-A comes into picture.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So in general I'm not particularly keen on this approach, I think it
>>>>>>>>>> /might/ be acceptable for U-Boot to have some fixup code to add the
>>>>>>>>>> OP-TEE node if OP-TEE is in use with the idea of phasing that out in
>>>>>>>>>> favour of runtime detection in the OS itself. I'd also expect that fixup
>>>>>>>>>> code to go in the generic U-Boot DT fixup code that runs before we jump
>>>>>>>>>> to the OS (like the EFI DT fixup function).
>>>>>>>>>
>>>>>>>>> The EFI DT fixup code is already there based on U-Boot DT. Have a look
>>>>>>>>> here:
>>>>>>>>>
>>>>>>>>> boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
>>>>>>>>>
>>>>>>>>> In general on Arm platforms there isn't any SMC bus to detect
>>>>>>>>> dynamically if there is support for OP-TEE or not. That's why
>>>>>>>>> platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
>>>>>>>>> similar to how we have the SCM DT node for Qcom platforms.
>>>>>>>>>
>>>>>>>>> FF-A bus tries to solve that problem to unify that approach for future
>>>>>>>>> platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
>>>>>>>>> driver too.
>>>>>>>>>
>>>>>>>>> Anyhow, this is the sanest way I can come up with to enable OP-TEE
>>>>>>>>> support in a general way for all the Qcom platforms. This is aligned
>>>>>>>>> with how OP-TEE support is detected for other silicon vendors too.
>>>>>>>>>
>>>>>>>>> -Sumit
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> For more information refer here:
>>>>>>>>>>> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>>>>>> ---
>>>>>>>>>>>      configs/qcom_tfa_optee_defconfig | 7 +++++++
>>>>>>>>>>>      1 file changed, 7 insertions(+)
>>>>>>>>>>>      create mode 100644 configs/qcom_tfa_optee_defconfig
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 00000000000..c398521770f
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/configs/qcom_tfa_optee_defconfig
>>>>>>>>>>> @@ -0,0 +1,7 @@
>>>>>>>>>>> +# Configuration for building a generic U-Boot image
>>>>>>>>>>> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
>>>>>>>>>>> +
>>>>>>>>>>> +#include "qcom_defconfig"
>>>>>>>>>>> +
>>>>>>>>>>> +CONFIG_TEE=y
>>>>>>>>>>> +CONFIG_OPTEE=y
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> // Casey (she/her)
>>>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> // Casey (she/her)
>>>>>>>>
>>>>>>
>>>>
>>

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Sumit Garg]

On Fri, Jan 16, 2026 at 08:34:33AM +0100, Neil Armstrong wrote:
> On 1/16/26 07:57, Sumit Garg wrote:
> > On Thu, Jan 15, 2026 at 02:35:23PM +0100, Neil Armstrong wrote:
> > > On 1/15/26 14:27, Sumit Garg wrote:
> > > > On Thu, Jan 15, 2026 at 02:03:29PM +0100, Neil Armstrong wrote:
> > > > > On 1/15/26 13:25, Sumit Garg wrote:
> > > > > > + Jens (OP-TEE driver author in U-Boot)
> > > > > > 
> > > > > > On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
> > > > > > > On 1/15/26 07:10, Sumit Garg wrote:
> > > > > > > > On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 09/01/2026 12:02, Sumit Garg wrote:
> > > > > > > > > > On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 29/12/2025 12:43, Sumit Garg wrote:
> > > > > > > > > > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > > > > > > > 
> > > > > > > > > > > > Recently upstream TF-A/OP-TEE has started gaining support for Qcom
> > > > > > > > > > > > platforms. RB3Gen2 being the first one and more to come. U-Boot in
> > > > > > > > > > > > corresponding boot flow is packaged as a position independent executable.
> > > > > > > > > > > > 
> > > > > > > > > > > > So, lets add a generic U-Boot defconfig for Qcom platforms to support
> > > > > > > > > > > > TF-A/OP-TEE based TrustZone stack. Build command:
> > > > > > > > > > > > 
> > > > > > > > > > > > $ make qcom_tfa_optee_defconfig
> > > > > > > > > > > > $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
> > > > > > > > > > > 
> > > > > > > > > > > This would be better suited as a config fragment rather than a new
> > > > > > > > > > > defconfig imo.
> > > > > > > > > > 
> > > > > > > > > > That's fine with me to add it as a config fragment.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > But more importantly, enabling OPTEE support in U-Boot doesn't imply
> > > > > > > > > > > that it will be used, just that it's supported.
> > > > > > > > > > 
> > > > > > > > > > There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
> > > > > > > > > > secure EFI variables based on OP-TEE secure storage. Have a look here [1].
> > > > > > > > > > 
> > > > > > > > > > And sure there will be more such use-cases like fTPM, KASLR etc. can be
> > > > > > > > > > supported based on OP-TEE.
> > > > > > > > > 
> > > > > > > > > I was referring literally to the fact that CONFIG_OPTEE being enabled
> > > > > > > > > doesn't imply that OP-TEE is running, it's faulty logic to assume that's
> > > > > > > > > the case and add nodes to the DT.
> > > > > > > > 
> > > > > > > > I don't disagree here as having a runtime check is always a better
> > > > > > > > choice then a compile time config option. However, there isn't a common
> > > > > > > > info method from properietary firmware that says if QTEE is running
> > > > > > > > instead of OP-TEE.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > I just checked and there is an SMC call that tells you the UUID for the
> > > > > > > > > trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
> > > > > > > > > OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
> > > > > > > > > specifically.
> > > > > > > > 
> > > > > > > > Also, we don't know how the QTEE will react to this OP-TEE specific SMC
> > > > > > > > call given it's different variants running on legacy and the newer SoCs.
> > > > > > > > So I would suggest to better gate OP-TEE presence behind a compile time
> > > > > > > > check only.
> > > > > > > 
> > > > > > > So you say it's fine to add the optee node, and the driver will bail out if
> > > > > > > OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
> > > > > > > in the fixup code to enable OPTEE only if present ?
> > > > > > > 
> > > > > > > It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
> > > > > > > was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
> > > > > > > node only if present _AND_ if CONFIG_OPTEE is enabled.
> > > > > > > 
> > > > > > > Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
> > > > > > > select OPTEE explicitly on desired platforms, and won't run the naughty
> > > > > > > OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
> > > > > > 
> > > > > > I am still trying to understand what benefit does invoking
> > > > > > OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
> > > > > > can't be used to detect OP-TEE not present when QTEE is running due to
> > > > > > unknown behaviour with QTEE.
> > > > > 
> > > > > Sorry but what exactly do you expect that will happen if you enable the OPTEE
> > > > > driver when running with QTEE ?
> > > > 
> > > > The OP-TEE SMC calls are not at all supported with QTEE, so the expected
> > > > behaviour is undefined. IOW, the OP-TEE SMC ABI is not compatible with
> > > > QTEE. However, it's going to be hit and trial method to see what QTEE
> > > > responds to OP-TEE SMC calls. So it's not a reliable source of
> > > > information we can use to detect which TEE is present or not.
> > > 
> > > So until we know, this change is a no go, we can't just add the /optee node
> > > and hope the person building uboot did the right thing.
> > 
> > Not sure why you think Qualcomm platforms are special in this regards
> > when similar OP-TEE node additions based on CONFIG_OPTEE exist for other
> > platforms, see example here [1] [2] [3].
> > 
> > The OP-TEE configs will surely be part of a separate config fragment and
> > I can add comments there for developer's awareness.
> > 
> > [1] arch/arm/dts/imx8mm-u-boot.dtsi:10
> > [2] arch/arm/dts/imx8mn-u-boot.dtsi:10
> > [3] arch/arm/dts/imx8mp-u-boot.dtsi:11
> > 
> > > 
> > > I propose an alternate way, is to check for QTEE and then test for OPTEE.
> > 
> > There are more combinations rather than just QTEE or OP-TEE as follows:
> > - Older targets have support for QSEECOM
> > - Newer targets with QTEE support
> > - Chrome targets without any TEE support
> > - IoT targets with OP-TEE support
> > 
> > Do you have any particular mechanism in mind for detecting OP-TEE
> > presence at runtime? And surely that has to be well supported on variety
> > of SoC where U-Boot is supported as of now.
> 
> OPTEE_SMC_CALL_GET_OS_UUID which works fine on like all the other ARM based
> platforms.

Can you share at-least one example of other Arm based platform where this
SMC call is used to add OP-TEE DT node?

> 
> It's the only way, and only Qualcomm engineers can answer how to determine
> without any risk which TEE is running on the system.

The fact that you keep ignoring my responses that OP-TEE SMC ABI is not
compatible with QTEE/QSEECOM SMC ABI is not going to change (see [1]).

I am not sure why it's a blocker to use CONFIG_OPTEE for OP-TEE DT node
addition on Qcom platforms when the same criteria is being used for imx8*
platforms already.

[1] https://lore.kernel.org/all/aWjrLF9DUPTaSA1c@sumit-xelite/.

-Sumit

> 
> Without this, all this discussions is pointless.
> 
> > 
> > Also, there is added complexity for targets where the developer can't
> > change the TZ firmware themselves on Qcom SoCs due to QTI signing
> > requirement.
> > 
> > -Sumit
> > 
> > > 
> > > Neil
> > > 
> > > > 
> > > > -Sumit
> > > > 
> > > > > 
> > > > > > 
> > > > > > Jens,
> > > > > > 
> > > > > > Will it be fine with you to expose is_optee_api() from the OP-TEE driver
> > > > > > for the platform code to invoke it independently? Just for the sake of this
> > > > > > discussion in case people still insist on it being the right thing to do.
> > > > > > 
> > > > > > -Sumit
> > > > > > 
> > > > > > > 
> > > > > > > Neil
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
> > > > > > > > > in qcom_psci_fixup(), compare the UUID and add the node if it matches.
> > > > > > > > 
> > > > > > > > That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
> > > > > > > > does to compare the UUID here [1] and bail out of the driver. I don't
> > > > > > > > see a value of a redundant invoke in the Qcom specific platform code.
> > > > > > > > 
> > > > > > > > [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
> > > > > > > > 
> > > > > > > > -Sumit
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > [1] lib/efi_loader/efi_variable_tee.c
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > So I think the more appropriate patch here would be to just enable
> > > > > > > > > > > OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
> > > > > > > > > > > affected).
> > > > > > > > > > 
> > > > > > > > > > The OP-TEE driver in U-Boot itself is probed based on DT and it's not
> > > > > > > > > > only specific to Qcom platforms but every other platform using OP-TEE.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Considering the other patch is based on this assumption that if OP-TEE
> > > > > > > > > > > support is enabled then the board must be using it, a different approach
> > > > > > > > > > > is definitely needed.
> > > > > > > > > > 
> > > > > > > > > > Yeah that's true even with TF-A boot flow, there is possibility to boot
> > > > > > > > > > without OP-TEE as well. However, TF-A generally doesn't provide a
> > > > > > > > > > generic option to detect whether OP-TEE is running or not.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > When I was looking into this last year I remember discussing this same
> > > > > > > > > > > issue from the Linux side, there is a good argument to be made that
> > > > > > > > > > > OP-TEE support in Linux shouldn't be based on the devicetree -
> > > > > > > > > > > particularly in the Qualcomm case where whether or not OP-TEE is used is
> > > > > > > > > > > a simple software change, nothing to do with hardware.
> > > > > > > > > > 
> > > > > > > > > > Sadly it's true for every other silicon vendor too. But OP-TEE support
> > > > > > > > > > based on DT has become an ABI unless migration for OP-TEE support based
> > > > > > > > > > on FF-A comes into picture.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > So in general I'm not particularly keen on this approach, I think it
> > > > > > > > > > > /might/ be acceptable for U-Boot to have some fixup code to add the
> > > > > > > > > > > OP-TEE node if OP-TEE is in use with the idea of phasing that out in
> > > > > > > > > > > favour of runtime detection in the OS itself. I'd also expect that fixup
> > > > > > > > > > > code to go in the generic U-Boot DT fixup code that runs before we jump
> > > > > > > > > > > to the OS (like the EFI DT fixup function).
> > > > > > > > > > 
> > > > > > > > > > The EFI DT fixup code is already there based on U-Boot DT. Have a look
> > > > > > > > > > here:
> > > > > > > > > > 
> > > > > > > > > > boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
> > > > > > > > > > 
> > > > > > > > > > In general on Arm platforms there isn't any SMC bus to detect
> > > > > > > > > > dynamically if there is support for OP-TEE or not. That's why
> > > > > > > > > > platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
> > > > > > > > > > similar to how we have the SCM DT node for Qcom platforms.
> > > > > > > > > > 
> > > > > > > > > > FF-A bus tries to solve that problem to unify that approach for future
> > > > > > > > > > platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
> > > > > > > > > > driver too.
> > > > > > > > > > 
> > > > > > > > > > Anyhow, this is the sanest way I can come up with to enable OP-TEE
> > > > > > > > > > support in a general way for all the Qcom platforms. This is aligned
> > > > > > > > > > with how OP-TEE support is detected for other silicon vendors too.
> > > > > > > > > > 
> > > > > > > > > > -Sumit
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Kind regards,
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > For more information refer here:
> > > > > > > > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > > > > > > > ---
> > > > > > > > > > > >      configs/qcom_tfa_optee_defconfig | 7 +++++++
> > > > > > > > > > > >      1 file changed, 7 insertions(+)
> > > > > > > > > > > >      create mode 100644 configs/qcom_tfa_optee_defconfig
> > > > > > > > > > > > 
> > > > > > > > > > > > diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
> > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > index 00000000000..c398521770f
> > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > +++ b/configs/qcom_tfa_optee_defconfig
> > > > > > > > > > > > @@ -0,0 +1,7 @@
> > > > > > > > > > > > +# Configuration for building a generic U-Boot image
> > > > > > > > > > > > +# with support for TF-A/OP-TEE based Arm TrustZone stack.
> > > > > > > > > > > > +
> > > > > > > > > > > > +#include "qcom_defconfig"
> > > > > > > > > > > > +
> > > > > > > > > > > > +CONFIG_TEE=y
> > > > > > > > > > > > +CONFIG_OPTEE=y
> > > > > > > > > > > 
> > > > > > > > > > > -- 
> > > > > > > > > > > // Casey (she/her)
> > > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > -- 
> > > > > > > > > // Casey (she/her)
> > > > > > > > > 
> > > > > > > 
> > > > > 
> > > 
> 

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Neil Armstrong]

On 1/16/26 08:53, Sumit Garg wrote:
> On Fri, Jan 16, 2026 at 08:34:33AM +0100, Neil Armstrong wrote:
>> On 1/16/26 07:57, Sumit Garg wrote:
>>> On Thu, Jan 15, 2026 at 02:35:23PM +0100, Neil Armstrong wrote:
>>>> On 1/15/26 14:27, Sumit Garg wrote:
>>>>> On Thu, Jan 15, 2026 at 02:03:29PM +0100, Neil Armstrong wrote:
>>>>>> On 1/15/26 13:25, Sumit Garg wrote:
>>>>>>> + Jens (OP-TEE driver author in U-Boot)
>>>>>>>
>>>>>>> On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
>>>>>>>> On 1/15/26 07:10, Sumit Garg wrote:
>>>>>>>>> On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 09/01/2026 12:02, Sumit Garg wrote:
>>>>>>>>>>> On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 29/12/2025 12:43, Sumit Garg wrote:
>>>>>>>>>>>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
>>>>>>>>>>>>> platforms. RB3Gen2 being the first one and more to come. U-Boot in
>>>>>>>>>>>>> corresponding boot flow is packaged as a position independent executable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, lets add a generic U-Boot defconfig for Qcom platforms to support
>>>>>>>>>>>>> TF-A/OP-TEE based TrustZone stack. Build command:
>>>>>>>>>>>>>
>>>>>>>>>>>>> $ make qcom_tfa_optee_defconfig
>>>>>>>>>>>>> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
>>>>>>>>>>>>
>>>>>>>>>>>> This would be better suited as a config fragment rather than a new
>>>>>>>>>>>> defconfig imo.
>>>>>>>>>>>
>>>>>>>>>>> That's fine with me to add it as a config fragment.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> But more importantly, enabling OPTEE support in U-Boot doesn't imply
>>>>>>>>>>>> that it will be used, just that it's supported.
>>>>>>>>>>>
>>>>>>>>>>> There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
>>>>>>>>>>> secure EFI variables based on OP-TEE secure storage. Have a look here [1].
>>>>>>>>>>>
>>>>>>>>>>> And sure there will be more such use-cases like fTPM, KASLR etc. can be
>>>>>>>>>>> supported based on OP-TEE.
>>>>>>>>>>
>>>>>>>>>> I was referring literally to the fact that CONFIG_OPTEE being enabled
>>>>>>>>>> doesn't imply that OP-TEE is running, it's faulty logic to assume that's
>>>>>>>>>> the case and add nodes to the DT.
>>>>>>>>>
>>>>>>>>> I don't disagree here as having a runtime check is always a better
>>>>>>>>> choice then a compile time config option. However, there isn't a common
>>>>>>>>> info method from properietary firmware that says if QTEE is running
>>>>>>>>> instead of OP-TEE.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I just checked and there is an SMC call that tells you the UUID for the
>>>>>>>>>> trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
>>>>>>>>>> OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
>>>>>>>>>> specifically.
>>>>>>>>>
>>>>>>>>> Also, we don't know how the QTEE will react to this OP-TEE specific SMC
>>>>>>>>> call given it's different variants running on legacy and the newer SoCs.
>>>>>>>>> So I would suggest to better gate OP-TEE presence behind a compile time
>>>>>>>>> check only.
>>>>>>>>
>>>>>>>> So you say it's fine to add the optee node, and the driver will bail out if
>>>>>>>> OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
>>>>>>>> in the fixup code to enable OPTEE only if present ?
>>>>>>>>
>>>>>>>> It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
>>>>>>>> was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
>>>>>>>> node only if present _AND_ if CONFIG_OPTEE is enabled.
>>>>>>>>
>>>>>>>> Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
>>>>>>>> select OPTEE explicitly on desired platforms, and won't run the naughty
>>>>>>>> OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
>>>>>>>
>>>>>>> I am still trying to understand what benefit does invoking
>>>>>>> OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
>>>>>>> can't be used to detect OP-TEE not present when QTEE is running due to
>>>>>>> unknown behaviour with QTEE.
>>>>>>
>>>>>> Sorry but what exactly do you expect that will happen if you enable the OPTEE
>>>>>> driver when running with QTEE ?
>>>>>
>>>>> The OP-TEE SMC calls are not at all supported with QTEE, so the expected
>>>>> behaviour is undefined. IOW, the OP-TEE SMC ABI is not compatible with
>>>>> QTEE. However, it's going to be hit and trial method to see what QTEE
>>>>> responds to OP-TEE SMC calls. So it's not a reliable source of
>>>>> information we can use to detect which TEE is present or not.
>>>>
>>>> So until we know, this change is a no go, we can't just add the /optee node
>>>> and hope the person building uboot did the right thing.
>>>
>>> Not sure why you think Qualcomm platforms are special in this regards
>>> when similar OP-TEE node additions based on CONFIG_OPTEE exist for other
>>> platforms, see example here [1] [2] [3].
>>>
>>> The OP-TEE configs will surely be part of a separate config fragment and
>>> I can add comments there for developer's awareness.
>>>
>>> [1] arch/arm/dts/imx8mm-u-boot.dtsi:10
>>> [2] arch/arm/dts/imx8mn-u-boot.dtsi:10
>>> [3] arch/arm/dts/imx8mp-u-boot.dtsi:11
>>>
>>>>
>>>> I propose an alternate way, is to check for QTEE and then test for OPTEE.
>>>
>>> There are more combinations rather than just QTEE or OP-TEE as follows:
>>> - Older targets have support for QSEECOM
>>> - Newer targets with QTEE support
>>> - Chrome targets without any TEE support
>>> - IoT targets with OP-TEE support
>>>
>>> Do you have any particular mechanism in mind for detecting OP-TEE
>>> presence at runtime? And surely that has to be well supported on variety
>>> of SoC where U-Boot is supported as of now.
>>
>> OPTEE_SMC_CALL_GET_OS_UUID which works fine on like all the other ARM based
>> platforms.
> 
> Can you share at-least one example of other Arm based platform where this
> SMC call is used to add OP-TEE DT node?

AFAIK no other platforms does that, I never said it was a standard thing,
I said it would be necessary to avoid messing with the qualcomm proprietary
boot chain.

> 
>>
>> It's the only way, and only Qualcomm engineers can answer how to determine
>> without any risk which TEE is running on the system.
> 
> The fact that you keep ignoring my responses that OP-TEE SMC ABI is not
> compatible with QTEE/QSEECOM SMC ABI is not going to change (see [1]).
> 
> I am not sure why it's a blocker to use CONFIG_OPTEE for OP-TEE DT node
> addition on Qcom platforms when the same criteria is being used for imx8*
> platforms already.

It is not, if the node is present the it's fine. I'm concerned by adding
the node when CONFIG_OPTEE is enabled.

Usually, the ARM64 platforms are shipped with a well-known or compatible
boot chain like TF-A, and OPTEE is present or not. Those platforms
will add the optee node knowing it can be present, and knowing other TEE
won't crash if OPTEE_SMC_CALL_GET_OS_UUID is called.

You propose the other way, adding the optee node when config is present,
not knowing exactly if the current system has optee or a qualcomm proprietary
TEE that could not survive a OPTEE_SMC_CALL_GET_OS_UUID call.

So my suggestion is:
- ask the boot team a sequence/way to determine exactly which TEE is loaded (using SMC, smem or whatever)
- only add the optee node if OPTEE or a compatible TEE is present

Then if CONFIG_OPTEE is enabled & the node is present the driver will
be able to communicate with OPTEE.

> 
> [1] https://lore.kernel.org/all/aWjrLF9DUPTaSA1c@sumit-xelite/.
> 
> -Sumit
> 
>>
>> Without this, all this discussions is pointless.
>>
>>>
>>> Also, there is added complexity for targets where the developer can't
>>> change the TZ firmware themselves on Qcom SoCs due to QTI signing
>>> requirement.
>>>
>>> -Sumit
>>>
>>>>
>>>> Neil
>>>>
>>>>>
>>>>> -Sumit
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Jens,
>>>>>>>
>>>>>>> Will it be fine with you to expose is_optee_api() from the OP-TEE driver
>>>>>>> for the platform code to invoke it independently? Just for the sake of this
>>>>>>> discussion in case people still insist on it being the right thing to do.
>>>>>>>
>>>>>>> -Sumit
>>>>>>>
>>>>>>>>
>>>>>>>> Neil
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
>>>>>>>>>> in qcom_psci_fixup(), compare the UUID and add the node if it matches.
>>>>>>>>>
>>>>>>>>> That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
>>>>>>>>> does to compare the UUID here [1] and bail out of the driver. I don't
>>>>>>>>> see a value of a redundant invoke in the Qcom specific platform code.
>>>>>>>>>
>>>>>>>>> [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
>>>>>>>>>
>>>>>>>>> -Sumit
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [1] lib/efi_loader/efi_variable_tee.c
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So I think the more appropriate patch here would be to just enable
>>>>>>>>>>>> OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
>>>>>>>>>>>> affected).
>>>>>>>>>>>
>>>>>>>>>>> The OP-TEE driver in U-Boot itself is probed based on DT and it's not
>>>>>>>>>>> only specific to Qcom platforms but every other platform using OP-TEE.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Considering the other patch is based on this assumption that if OP-TEE
>>>>>>>>>>>> support is enabled then the board must be using it, a different approach
>>>>>>>>>>>> is definitely needed.
>>>>>>>>>>>
>>>>>>>>>>> Yeah that's true even with TF-A boot flow, there is possibility to boot
>>>>>>>>>>> without OP-TEE as well. However, TF-A generally doesn't provide a
>>>>>>>>>>> generic option to detect whether OP-TEE is running or not.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> When I was looking into this last year I remember discussing this same
>>>>>>>>>>>> issue from the Linux side, there is a good argument to be made that
>>>>>>>>>>>> OP-TEE support in Linux shouldn't be based on the devicetree -
>>>>>>>>>>>> particularly in the Qualcomm case where whether or not OP-TEE is used is
>>>>>>>>>>>> a simple software change, nothing to do with hardware.
>>>>>>>>>>>
>>>>>>>>>>> Sadly it's true for every other silicon vendor too. But OP-TEE support
>>>>>>>>>>> based on DT has become an ABI unless migration for OP-TEE support based
>>>>>>>>>>> on FF-A comes into picture.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So in general I'm not particularly keen on this approach, I think it
>>>>>>>>>>>> /might/ be acceptable for U-Boot to have some fixup code to add the
>>>>>>>>>>>> OP-TEE node if OP-TEE is in use with the idea of phasing that out in
>>>>>>>>>>>> favour of runtime detection in the OS itself. I'd also expect that fixup
>>>>>>>>>>>> code to go in the generic U-Boot DT fixup code that runs before we jump
>>>>>>>>>>>> to the OS (like the EFI DT fixup function).
>>>>>>>>>>>
>>>>>>>>>>> The EFI DT fixup code is already there based on U-Boot DT. Have a look
>>>>>>>>>>> here:
>>>>>>>>>>>
>>>>>>>>>>> boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
>>>>>>>>>>>
>>>>>>>>>>> In general on Arm platforms there isn't any SMC bus to detect
>>>>>>>>>>> dynamically if there is support for OP-TEE or not. That's why
>>>>>>>>>>> platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
>>>>>>>>>>> similar to how we have the SCM DT node for Qcom platforms.
>>>>>>>>>>>
>>>>>>>>>>> FF-A bus tries to solve that problem to unify that approach for future
>>>>>>>>>>> platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
>>>>>>>>>>> driver too.
>>>>>>>>>>>
>>>>>>>>>>> Anyhow, this is the sanest way I can come up with to enable OP-TEE
>>>>>>>>>>> support in a general way for all the Qcom platforms. This is aligned
>>>>>>>>>>> with how OP-TEE support is detected for other silicon vendors too.
>>>>>>>>>>>
>>>>>>>>>>> -Sumit
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> For more information refer here:
>>>>>>>>>>>>> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>       configs/qcom_tfa_optee_defconfig | 7 +++++++
>>>>>>>>>>>>>       1 file changed, 7 insertions(+)
>>>>>>>>>>>>>       create mode 100644 configs/qcom_tfa_optee_defconfig
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
>>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>>> index 00000000000..c398521770f
>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>> +++ b/configs/qcom_tfa_optee_defconfig
>>>>>>>>>>>>> @@ -0,0 +1,7 @@
>>>>>>>>>>>>> +# Configuration for building a generic U-Boot image
>>>>>>>>>>>>> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +#include "qcom_defconfig"
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +CONFIG_TEE=y
>>>>>>>>>>>>> +CONFIG_OPTEE=y
>>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>> // Casey (she/her)
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> // Casey (she/her)
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Sumit Garg]

On Fri, Jan 16, 2026 at 10:53:15AM +0100, Neil Armstrong wrote:
> On 1/16/26 08:53, Sumit Garg wrote:
> > On Fri, Jan 16, 2026 at 08:34:33AM +0100, Neil Armstrong wrote:
> > > On 1/16/26 07:57, Sumit Garg wrote:
> > > > On Thu, Jan 15, 2026 at 02:35:23PM +0100, Neil Armstrong wrote:
> > > > > On 1/15/26 14:27, Sumit Garg wrote:
> > > > > > On Thu, Jan 15, 2026 at 02:03:29PM +0100, Neil Armstrong wrote:
> > > > > > > On 1/15/26 13:25, Sumit Garg wrote:
> > > > > > > > + Jens (OP-TEE driver author in U-Boot)
> > > > > > > > 
> > > > > > > > On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
> > > > > > > > > On 1/15/26 07:10, Sumit Garg wrote:
> > > > > > > > > > On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 09/01/2026 12:02, Sumit Garg wrote:
> > > > > > > > > > > > On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On 29/12/2025 12:43, Sumit Garg wrote:
> > > > > > > > > > > > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Recently upstream TF-A/OP-TEE has started gaining support for Qcom
> > > > > > > > > > > > > > platforms. RB3Gen2 being the first one and more to come. U-Boot in
> > > > > > > > > > > > > > corresponding boot flow is packaged as a position independent executable.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > So, lets add a generic U-Boot defconfig for Qcom platforms to support
> > > > > > > > > > > > > > TF-A/OP-TEE based TrustZone stack. Build command:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > $ make qcom_tfa_optee_defconfig
> > > > > > > > > > > > > > $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
> > > > > > > > > > > > > 
> > > > > > > > > > > > > This would be better suited as a config fragment rather than a new
> > > > > > > > > > > > > defconfig imo.
> > > > > > > > > > > > 
> > > > > > > > > > > > That's fine with me to add it as a config fragment.
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > But more importantly, enabling OPTEE support in U-Boot doesn't imply
> > > > > > > > > > > > > that it will be used, just that it's supported.
> > > > > > > > > > > > 
> > > > > > > > > > > > There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
> > > > > > > > > > > > secure EFI variables based on OP-TEE secure storage. Have a look here [1].
> > > > > > > > > > > > 
> > > > > > > > > > > > And sure there will be more such use-cases like fTPM, KASLR etc. can be
> > > > > > > > > > > > supported based on OP-TEE.
> > > > > > > > > > > 
> > > > > > > > > > > I was referring literally to the fact that CONFIG_OPTEE being enabled
> > > > > > > > > > > doesn't imply that OP-TEE is running, it's faulty logic to assume that's
> > > > > > > > > > > the case and add nodes to the DT.
> > > > > > > > > > 
> > > > > > > > > > I don't disagree here as having a runtime check is always a better
> > > > > > > > > > choice then a compile time config option. However, there isn't a common
> > > > > > > > > > info method from properietary firmware that says if QTEE is running
> > > > > > > > > > instead of OP-TEE.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > I just checked and there is an SMC call that tells you the UUID for the
> > > > > > > > > > > trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
> > > > > > > > > > > OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
> > > > > > > > > > > specifically.
> > > > > > > > > > 
> > > > > > > > > > Also, we don't know how the QTEE will react to this OP-TEE specific SMC
> > > > > > > > > > call given it's different variants running on legacy and the newer SoCs.
> > > > > > > > > > So I would suggest to better gate OP-TEE presence behind a compile time
> > > > > > > > > > check only.
> > > > > > > > > 
> > > > > > > > > So you say it's fine to add the optee node, and the driver will bail out if
> > > > > > > > > OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
> > > > > > > > > in the fixup code to enable OPTEE only if present ?
> > > > > > > > > 
> > > > > > > > > It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
> > > > > > > > > was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
> > > > > > > > > node only if present _AND_ if CONFIG_OPTEE is enabled.
> > > > > > > > > 
> > > > > > > > > Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
> > > > > > > > > select OPTEE explicitly on desired platforms, and won't run the naughty
> > > > > > > > > OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
> > > > > > > > 
> > > > > > > > I am still trying to understand what benefit does invoking
> > > > > > > > OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
> > > > > > > > can't be used to detect OP-TEE not present when QTEE is running due to
> > > > > > > > unknown behaviour with QTEE.
> > > > > > > 
> > > > > > > Sorry but what exactly do you expect that will happen if you enable the OPTEE
> > > > > > > driver when running with QTEE ?
> > > > > > 
> > > > > > The OP-TEE SMC calls are not at all supported with QTEE, so the expected
> > > > > > behaviour is undefined. IOW, the OP-TEE SMC ABI is not compatible with
> > > > > > QTEE. However, it's going to be hit and trial method to see what QTEE
> > > > > > responds to OP-TEE SMC calls. So it's not a reliable source of
> > > > > > information we can use to detect which TEE is present or not.
> > > > > 
> > > > > So until we know, this change is a no go, we can't just add the /optee node
> > > > > and hope the person building uboot did the right thing.
> > > > 
> > > > Not sure why you think Qualcomm platforms are special in this regards
> > > > when similar OP-TEE node additions based on CONFIG_OPTEE exist for other
> > > > platforms, see example here [1] [2] [3].
> > > > 
> > > > The OP-TEE configs will surely be part of a separate config fragment and
> > > > I can add comments there for developer's awareness.
> > > > 
> > > > [1] arch/arm/dts/imx8mm-u-boot.dtsi:10
> > > > [2] arch/arm/dts/imx8mn-u-boot.dtsi:10
> > > > [3] arch/arm/dts/imx8mp-u-boot.dtsi:11
> > > > 
> > > > > 
> > > > > I propose an alternate way, is to check for QTEE and then test for OPTEE.
> > > > 
> > > > There are more combinations rather than just QTEE or OP-TEE as follows:
> > > > - Older targets have support for QSEECOM
> > > > - Newer targets with QTEE support
> > > > - Chrome targets without any TEE support
> > > > - IoT targets with OP-TEE support
> > > > 
> > > > Do you have any particular mechanism in mind for detecting OP-TEE
> > > > presence at runtime? And surely that has to be well supported on variety
> > > > of SoC where U-Boot is supported as of now.
> > > 
> > > OPTEE_SMC_CALL_GET_OS_UUID which works fine on like all the other ARM based
> > > platforms.
> > 
> > Can you share at-least one example of other Arm based platform where this
> > SMC call is used to add OP-TEE DT node?
> 
> AFAIK no other platforms does that, I never said it was a standard thing,
> I said it would be necessary to avoid messing with the qualcomm proprietary
> boot chain.
> 
> > 
> > > 
> > > It's the only way, and only Qualcomm engineers can answer how to determine
> > > without any risk which TEE is running on the system.
> > 
> > The fact that you keep ignoring my responses that OP-TEE SMC ABI is not
> > compatible with QTEE/QSEECOM SMC ABI is not going to change (see [1]).
> > 
> > I am not sure why it's a blocker to use CONFIG_OPTEE for OP-TEE DT node
> > addition on Qcom platforms when the same criteria is being used for imx8*
> > platforms already.
> 
> It is not, if the node is present the it's fine. I'm concerned by adding
> the node when CONFIG_OPTEE is enabled.
> 
> Usually, the ARM64 platforms are shipped with a well-known or compatible
> boot chain like TF-A, and OPTEE is present or not. Those platforms
> will add the optee node knowing it can be present, and knowing other TEE
> won't crash if OPTEE_SMC_CALL_GET_OS_UUID is called.
> 
> You propose the other way, adding the optee node when config is present,
> not knowing exactly if the current system has optee or a qualcomm proprietary
> TEE that could not survive a OPTEE_SMC_CALL_GET_OS_UUID call.

Maybe I should have provided reference to the overall open boot stack [1]
early which is being planned for IoT platforms to begin with. The PR for
meta-qcom is here [2]. We are mostly waiting for the OEM only signing
feature for TZ image to be available in XBL_SEC such that any developer
can excercise that stack:

PBL (ROM) -> XBL -> TF-A BL2 -> TF-A BL31 -> BL33 -> Linux kernel
                                    |
                                     --> OP-TEE as BL32

TF-A and OP-TEE are going to be supported in a similar fashion on Qcom
platforms as any other ARM64 platform.

[1] https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
[2] https://github.com/qualcomm-linux/meta-qcom/pull/1172

> 
> So my suggestion is:
> - ask the boot team a sequence/way to determine exactly which TEE is loaded (using SMC, smem or whatever)
> - only add the optee node if OPTEE or a compatible TEE is present
> 
> Then if CONFIG_OPTEE is enabled & the node is present the driver will
> be able to communicate with OPTEE.

Hence, OP-TEE is going to be supported in a developer controlled
environment only like any other ARM64 platform. So there is intention to
reuse the same workflows here. Since it's an open source boot stack then
it should be possible to use generic methodology if community comes up
with that later in future. That's why we should avoid Qcom specifc
platform code to enable such a feature apart from what others do.

-Sumit

> 
> > 
> > [1] https://lore.kernel.org/all/aWjrLF9DUPTaSA1c@sumit-xelite/.
> > 
> > -Sumit
> > 
> > > 
> > > Without this, all this discussions is pointless.
> > > 
> > > > 
> > > > Also, there is added complexity for targets where the developer can't
> > > > change the TZ firmware themselves on Qcom SoCs due to QTI signing
> > > > requirement.
> > > > 
> > > > -Sumit
> > > > 
> > > > > 
> > > > > Neil
> > > > > 
> > > > > > 
> > > > > > -Sumit
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > Jens,
> > > > > > > > 
> > > > > > > > Will it be fine with you to expose is_optee_api() from the OP-TEE driver
> > > > > > > > for the platform code to invoke it independently? Just for the sake of this
> > > > > > > > discussion in case people still insist on it being the right thing to do.
> > > > > > > > 
> > > > > > > > -Sumit
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Neil
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
> > > > > > > > > > > in qcom_psci_fixup(), compare the UUID and add the node if it matches.
> > > > > > > > > > 
> > > > > > > > > > That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
> > > > > > > > > > does to compare the UUID here [1] and bail out of the driver. I don't
> > > > > > > > > > see a value of a redundant invoke in the Qcom specific platform code.
> > > > > > > > > > 
> > > > > > > > > > [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
> > > > > > > > > > 
> > > > > > > > > > -Sumit
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > [1] lib/efi_loader/efi_variable_tee.c
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > So I think the more appropriate patch here would be to just enable
> > > > > > > > > > > > > OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
> > > > > > > > > > > > > affected).
> > > > > > > > > > > > 
> > > > > > > > > > > > The OP-TEE driver in U-Boot itself is probed based on DT and it's not
> > > > > > > > > > > > only specific to Qcom platforms but every other platform using OP-TEE.
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Considering the other patch is based on this assumption that if OP-TEE
> > > > > > > > > > > > > support is enabled then the board must be using it, a different approach
> > > > > > > > > > > > > is definitely needed.
> > > > > > > > > > > > 
> > > > > > > > > > > > Yeah that's true even with TF-A boot flow, there is possibility to boot
> > > > > > > > > > > > without OP-TEE as well. However, TF-A generally doesn't provide a
> > > > > > > > > > > > generic option to detect whether OP-TEE is running or not.
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > When I was looking into this last year I remember discussing this same
> > > > > > > > > > > > > issue from the Linux side, there is a good argument to be made that
> > > > > > > > > > > > > OP-TEE support in Linux shouldn't be based on the devicetree -
> > > > > > > > > > > > > particularly in the Qualcomm case where whether or not OP-TEE is used is
> > > > > > > > > > > > > a simple software change, nothing to do with hardware.
> > > > > > > > > > > > 
> > > > > > > > > > > > Sadly it's true for every other silicon vendor too. But OP-TEE support
> > > > > > > > > > > > based on DT has become an ABI unless migration for OP-TEE support based
> > > > > > > > > > > > on FF-A comes into picture.
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > So in general I'm not particularly keen on this approach, I think it
> > > > > > > > > > > > > /might/ be acceptable for U-Boot to have some fixup code to add the
> > > > > > > > > > > > > OP-TEE node if OP-TEE is in use with the idea of phasing that out in
> > > > > > > > > > > > > favour of runtime detection in the OS itself. I'd also expect that fixup
> > > > > > > > > > > > > code to go in the generic U-Boot DT fixup code that runs before we jump
> > > > > > > > > > > > > to the OS (like the EFI DT fixup function).
> > > > > > > > > > > > 
> > > > > > > > > > > > The EFI DT fixup code is already there based on U-Boot DT. Have a look
> > > > > > > > > > > > here:
> > > > > > > > > > > > 
> > > > > > > > > > > > boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
> > > > > > > > > > > > 
> > > > > > > > > > > > In general on Arm platforms there isn't any SMC bus to detect
> > > > > > > > > > > > dynamically if there is support for OP-TEE or not. That's why
> > > > > > > > > > > > platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
> > > > > > > > > > > > similar to how we have the SCM DT node for Qcom platforms.
> > > > > > > > > > > > 
> > > > > > > > > > > > FF-A bus tries to solve that problem to unify that approach for future
> > > > > > > > > > > > platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
> > > > > > > > > > > > driver too.
> > > > > > > > > > > > 
> > > > > > > > > > > > Anyhow, this is the sanest way I can come up with to enable OP-TEE
> > > > > > > > > > > > support in a general way for all the Qcom platforms. This is aligned
> > > > > > > > > > > > with how OP-TEE support is detected for other silicon vendors too.
> > > > > > > > > > > > 
> > > > > > > > > > > > -Sumit
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Kind regards,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > For more information refer here:
> > > > > > > > > > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >       configs/qcom_tfa_optee_defconfig | 7 +++++++
> > > > > > > > > > > > > >       1 file changed, 7 insertions(+)
> > > > > > > > > > > > > >       create mode 100644 configs/qcom_tfa_optee_defconfig
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
> > > > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > > > index 00000000000..c398521770f
> > > > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > > > +++ b/configs/qcom_tfa_optee_defconfig
> > > > > > > > > > > > > > @@ -0,0 +1,7 @@
> > > > > > > > > > > > > > +# Configuration for building a generic U-Boot image
> > > > > > > > > > > > > > +# with support for TF-A/OP-TEE based Arm TrustZone stack.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +#include "qcom_defconfig"
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +CONFIG_TEE=y
> > > > > > > > > > > > > > +CONFIG_OPTEE=y
> > > > > > > > > > > > > 
> > > > > > > > > > > > > -- 
> > > > > > > > > > > > > // Casey (she/her)
> > > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > -- 
> > > > > > > > > > > // Casey (she/her)
> > > > > > > > > > > 
> > > > > > > > > 
> > > > > > > 
> > > > > 
> > > 
> 

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Casey Connolly]

Hi Sumit,

(Top-posting since this thread is getting a bit busy)

I'm not sure if Neil and I properly conveyed why we don't agree with 
your proposal here: essentially it is an inversion of logic. 
CONFIG_OPTEE doesn't indicate that the board IS running OP-TEE, it just 
builds in support for OP-TEE. In general U-Boot is trying to trend away 
from using kconfig to dictate behaviour in this way.

Adjacently, for Qualcomm support in U-Boot we are trying to improve upon 
the status quo: we don't do board-specific code, we limit hardcoding 
functionality or build-time configuration in favour of runtime checks as 
much as possible.

With that perspective in mind, I would much prefer that switching from 
QTEE to TF-A/OP-TEE on the rb3gen2 (or any other qcom board) not require 
flashing a bespoke U-Boot build, the same build should just work on both.

There are several ways it might be possible to check for OP-TEE at 
runtime, arguably the simplest is the SMC call I proposed (which could 
be restricted to just kodiak), the other idea that comes to mind is 
populating the x2 register with a magic number when jumping to U-Boot, 
or even using the functionality already in place for passing data 
between bootloader stages (assuming the necessary bits are upstream in 
both projects).

You say that making that SMC call on QTEE is undefined behaviour, but 
surely it doesn't break stuff? I'd hope that simply seeing what happens 
would be enough to define it, maybe checking with the boot team too.

Your patch also mentions the EFI DT fixup protocol, but there is no 
corresponding code for that. iirc there are other DT changes needed for 
everything to work properly on rb3gen2 with OP-TEE, is the plan to get 
those changes done in such a way that the same DT will work with both 
OP-TEE and QTEE?

- Casey

On 1/16/26 13:17, Sumit Garg wrote:
> On Fri, Jan 16, 2026 at 10:53:15AM +0100, Neil Armstrong wrote:
>> On 1/16/26 08:53, Sumit Garg wrote:
>>> On Fri, Jan 16, 2026 at 08:34:33AM +0100, Neil Armstrong wrote:
>>>> On 1/16/26 07:57, Sumit Garg wrote:
>>>>> On Thu, Jan 15, 2026 at 02:35:23PM +0100, Neil Armstrong wrote:
>>>>>> On 1/15/26 14:27, Sumit Garg wrote:
>>>>>>> On Thu, Jan 15, 2026 at 02:03:29PM +0100, Neil Armstrong wrote:
>>>>>>>> On 1/15/26 13:25, Sumit Garg wrote:
>>>>>>>>> + Jens (OP-TEE driver author in U-Boot)
>>>>>>>>>
>>>>>>>>> On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
>>>>>>>>>> On 1/15/26 07:10, Sumit Garg wrote:
>>>>>>>>>>> On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 09/01/2026 12:02, Sumit Garg wrote:
>>>>>>>>>>>>> On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 29/12/2025 12:43, Sumit Garg wrote:
>>>>>>>>>>>>>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
>>>>>>>>>>>>>>> platforms. RB3Gen2 being the first one and more to come. U-Boot in
>>>>>>>>>>>>>>> corresponding boot flow is packaged as a position independent executable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, lets add a generic U-Boot defconfig for Qcom platforms to support
>>>>>>>>>>>>>>> TF-A/OP-TEE based TrustZone stack. Build command:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> $ make qcom_tfa_optee_defconfig
>>>>>>>>>>>>>>> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This would be better suited as a config fragment rather than a new
>>>>>>>>>>>>>> defconfig imo.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's fine with me to add it as a config fragment.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But more importantly, enabling OPTEE support in U-Boot doesn't imply
>>>>>>>>>>>>>> that it will be used, just that it's supported.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
>>>>>>>>>>>>> secure EFI variables based on OP-TEE secure storage. Have a look here [1].
>>>>>>>>>>>>>
>>>>>>>>>>>>> And sure there will be more such use-cases like fTPM, KASLR etc. can be
>>>>>>>>>>>>> supported based on OP-TEE.
>>>>>>>>>>>>
>>>>>>>>>>>> I was referring literally to the fact that CONFIG_OPTEE being enabled
>>>>>>>>>>>> doesn't imply that OP-TEE is running, it's faulty logic to assume that's
>>>>>>>>>>>> the case and add nodes to the DT.
>>>>>>>>>>>
>>>>>>>>>>> I don't disagree here as having a runtime check is always a better
>>>>>>>>>>> choice then a compile time config option. However, there isn't a common
>>>>>>>>>>> info method from properietary firmware that says if QTEE is running
>>>>>>>>>>> instead of OP-TEE.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I just checked and there is an SMC call that tells you the UUID for the
>>>>>>>>>>>> trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
>>>>>>>>>>>> OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
>>>>>>>>>>>> specifically.
>>>>>>>>>>>
>>>>>>>>>>> Also, we don't know how the QTEE will react to this OP-TEE specific SMC
>>>>>>>>>>> call given it's different variants running on legacy and the newer SoCs.
>>>>>>>>>>> So I would suggest to better gate OP-TEE presence behind a compile time
>>>>>>>>>>> check only.
>>>>>>>>>>
>>>>>>>>>> So you say it's fine to add the optee node, and the driver will bail out if
>>>>>>>>>> OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
>>>>>>>>>> in the fixup code to enable OPTEE only if present ?
>>>>>>>>>>
>>>>>>>>>> It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
>>>>>>>>>> was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
>>>>>>>>>> node only if present _AND_ if CONFIG_OPTEE is enabled.
>>>>>>>>>>
>>>>>>>>>> Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
>>>>>>>>>> select OPTEE explicitly on desired platforms, and won't run the naughty
>>>>>>>>>> OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
>>>>>>>>>
>>>>>>>>> I am still trying to understand what benefit does invoking
>>>>>>>>> OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
>>>>>>>>> can't be used to detect OP-TEE not present when QTEE is running due to
>>>>>>>>> unknown behaviour with QTEE.
>>>>>>>>
>>>>>>>> Sorry but what exactly do you expect that will happen if you enable the OPTEE
>>>>>>>> driver when running with QTEE ?
>>>>>>>
>>>>>>> The OP-TEE SMC calls are not at all supported with QTEE, so the expected
>>>>>>> behaviour is undefined. IOW, the OP-TEE SMC ABI is not compatible with
>>>>>>> QTEE. However, it's going to be hit and trial method to see what QTEE
>>>>>>> responds to OP-TEE SMC calls. So it's not a reliable source of
>>>>>>> information we can use to detect which TEE is present or not.
>>>>>>
>>>>>> So until we know, this change is a no go, we can't just add the /optee node
>>>>>> and hope the person building uboot did the right thing.
>>>>>
>>>>> Not sure why you think Qualcomm platforms are special in this regards
>>>>> when similar OP-TEE node additions based on CONFIG_OPTEE exist for other
>>>>> platforms, see example here [1] [2] [3].
>>>>>
>>>>> The OP-TEE configs will surely be part of a separate config fragment and
>>>>> I can add comments there for developer's awareness.
>>>>>
>>>>> [1] arch/arm/dts/imx8mm-u-boot.dtsi:10
>>>>> [2] arch/arm/dts/imx8mn-u-boot.dtsi:10
>>>>> [3] arch/arm/dts/imx8mp-u-boot.dtsi:11
>>>>>
>>>>>>
>>>>>> I propose an alternate way, is to check for QTEE and then test for OPTEE.
>>>>>
>>>>> There are more combinations rather than just QTEE or OP-TEE as follows:
>>>>> - Older targets have support for QSEECOM
>>>>> - Newer targets with QTEE support
>>>>> - Chrome targets without any TEE support
>>>>> - IoT targets with OP-TEE support
>>>>>
>>>>> Do you have any particular mechanism in mind for detecting OP-TEE
>>>>> presence at runtime? And surely that has to be well supported on variety
>>>>> of SoC where U-Boot is supported as of now.
>>>>
>>>> OPTEE_SMC_CALL_GET_OS_UUID which works fine on like all the other ARM based
>>>> platforms.
>>>
>>> Can you share at-least one example of other Arm based platform where this
>>> SMC call is used to add OP-TEE DT node?
>>
>> AFAIK no other platforms does that, I never said it was a standard thing,
>> I said it would be necessary to avoid messing with the qualcomm proprietary
>> boot chain.
>>
>>>
>>>>
>>>> It's the only way, and only Qualcomm engineers can answer how to determine
>>>> without any risk which TEE is running on the system.
>>>
>>> The fact that you keep ignoring my responses that OP-TEE SMC ABI is not
>>> compatible with QTEE/QSEECOM SMC ABI is not going to change (see [1]).
>>>
>>> I am not sure why it's a blocker to use CONFIG_OPTEE for OP-TEE DT node
>>> addition on Qcom platforms when the same criteria is being used for imx8*
>>> platforms already.
>>
>> It is not, if the node is present the it's fine. I'm concerned by adding
>> the node when CONFIG_OPTEE is enabled.
>>
>> Usually, the ARM64 platforms are shipped with a well-known or compatible
>> boot chain like TF-A, and OPTEE is present or not. Those platforms
>> will add the optee node knowing it can be present, and knowing other TEE
>> won't crash if OPTEE_SMC_CALL_GET_OS_UUID is called.
>>
>> You propose the other way, adding the optee node when config is present,
>> not knowing exactly if the current system has optee or a qualcomm proprietary
>> TEE that could not survive a OPTEE_SMC_CALL_GET_OS_UUID call.
> 
> Maybe I should have provided reference to the overall open boot stack [1]
> early which is being planned for IoT platforms to begin with. The PR for
> meta-qcom is here [2]. We are mostly waiting for the OEM only signing
> feature for TZ image to be available in XBL_SEC such that any developer
> can excercise that stack:
> 
> PBL (ROM) -> XBL -> TF-A BL2 -> TF-A BL31 -> BL33 -> Linux kernel
>                                      |
>                                       --> OP-TEE as BL32
> 
> TF-A and OP-TEE are going to be supported in a similar fashion on Qcom
> platforms as any other ARM64 platform.
> 
> [1] https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> [2] https://github.com/qualcomm-linux/meta-qcom/pull/1172
> 
>>
>> So my suggestion is:
>> - ask the boot team a sequence/way to determine exactly which TEE is loaded (using SMC, smem or whatever)
>> - only add the optee node if OPTEE or a compatible TEE is present
>>
>> Then if CONFIG_OPTEE is enabled & the node is present the driver will
>> be able to communicate with OPTEE.
> 
> Hence, OP-TEE is going to be supported in a developer controlled
> environment only like any other ARM64 platform. So there is intention to
> reuse the same workflows here. Since it's an open source boot stack then
> it should be possible to use generic methodology if community comes up
> with that later in future. That's why we should avoid Qcom specifc
> platform code to enable such a feature apart from what others do.
> 
> -Sumit
> 
>>
>>>
>>> [1] https://lore.kernel.org/all/aWjrLF9DUPTaSA1c@sumit-xelite/.
>>>
>>> -Sumit
>>>
>>>>
>>>> Without this, all this discussions is pointless.
>>>>
>>>>>
>>>>> Also, there is added complexity for targets where the developer can't
>>>>> change the TZ firmware themselves on Qcom SoCs due to QTI signing
>>>>> requirement.
>>>>>
>>>>> -Sumit
>>>>>
>>>>>>
>>>>>> Neil
>>>>>>
>>>>>>>
>>>>>>> -Sumit
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jens,
>>>>>>>>>
>>>>>>>>> Will it be fine with you to expose is_optee_api() from the OP-TEE driver
>>>>>>>>> for the platform code to invoke it independently? Just for the sake of this
>>>>>>>>> discussion in case people still insist on it being the right thing to do.
>>>>>>>>>
>>>>>>>>> -Sumit
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Neil
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
>>>>>>>>>>>> in qcom_psci_fixup(), compare the UUID and add the node if it matches.
>>>>>>>>>>>
>>>>>>>>>>> That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
>>>>>>>>>>> does to compare the UUID here [1] and bail out of the driver. I don't
>>>>>>>>>>> see a value of a redundant invoke in the Qcom specific platform code.
>>>>>>>>>>>
>>>>>>>>>>> [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
>>>>>>>>>>>
>>>>>>>>>>> -Sumit
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] lib/efi_loader/efi_variable_tee.c
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So I think the more appropriate patch here would be to just enable
>>>>>>>>>>>>>> OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
>>>>>>>>>>>>>> affected).
>>>>>>>>>>>>>
>>>>>>>>>>>>> The OP-TEE driver in U-Boot itself is probed based on DT and it's not
>>>>>>>>>>>>> only specific to Qcom platforms but every other platform using OP-TEE.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Considering the other patch is based on this assumption that if OP-TEE
>>>>>>>>>>>>>> support is enabled then the board must be using it, a different approach
>>>>>>>>>>>>>> is definitely needed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yeah that's true even with TF-A boot flow, there is possibility to boot
>>>>>>>>>>>>> without OP-TEE as well. However, TF-A generally doesn't provide a
>>>>>>>>>>>>> generic option to detect whether OP-TEE is running or not.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When I was looking into this last year I remember discussing this same
>>>>>>>>>>>>>> issue from the Linux side, there is a good argument to be made that
>>>>>>>>>>>>>> OP-TEE support in Linux shouldn't be based on the devicetree -
>>>>>>>>>>>>>> particularly in the Qualcomm case where whether or not OP-TEE is used is
>>>>>>>>>>>>>> a simple software change, nothing to do with hardware.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sadly it's true for every other silicon vendor too. But OP-TEE support
>>>>>>>>>>>>> based on DT has become an ABI unless migration for OP-TEE support based
>>>>>>>>>>>>> on FF-A comes into picture.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So in general I'm not particularly keen on this approach, I think it
>>>>>>>>>>>>>> /might/ be acceptable for U-Boot to have some fixup code to add the
>>>>>>>>>>>>>> OP-TEE node if OP-TEE is in use with the idea of phasing that out in
>>>>>>>>>>>>>> favour of runtime detection in the OS itself. I'd also expect that fixup
>>>>>>>>>>>>>> code to go in the generic U-Boot DT fixup code that runs before we jump
>>>>>>>>>>>>>> to the OS (like the EFI DT fixup function).
>>>>>>>>>>>>>
>>>>>>>>>>>>> The EFI DT fixup code is already there based on U-Boot DT. Have a look
>>>>>>>>>>>>> here:
>>>>>>>>>>>>>
>>>>>>>>>>>>> boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
>>>>>>>>>>>>>
>>>>>>>>>>>>> In general on Arm platforms there isn't any SMC bus to detect
>>>>>>>>>>>>> dynamically if there is support for OP-TEE or not. That's why
>>>>>>>>>>>>> platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
>>>>>>>>>>>>> similar to how we have the SCM DT node for Qcom platforms.
>>>>>>>>>>>>>
>>>>>>>>>>>>> FF-A bus tries to solve that problem to unify that approach for future
>>>>>>>>>>>>> platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
>>>>>>>>>>>>> driver too.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anyhow, this is the sanest way I can come up with to enable OP-TEE
>>>>>>>>>>>>> support in a general way for all the Qcom platforms. This is aligned
>>>>>>>>>>>>> with how OP-TEE support is detected for other silicon vendors too.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Sumit
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For more information refer here:
>>>>>>>>>>>>>>> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>        configs/qcom_tfa_optee_defconfig | 7 +++++++
>>>>>>>>>>>>>>>        1 file changed, 7 insertions(+)
>>>>>>>>>>>>>>>        create mode 100644 configs/qcom_tfa_optee_defconfig
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
>>>>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>>>>> index 00000000000..c398521770f
>>>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>>>> +++ b/configs/qcom_tfa_optee_defconfig
>>>>>>>>>>>>>>> @@ -0,0 +1,7 @@
>>>>>>>>>>>>>>> +# Configuration for building a generic U-Boot image
>>>>>>>>>>>>>>> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +#include "qcom_defconfig"
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +CONFIG_TEE=y
>>>>>>>>>>>>>>> +CONFIG_OPTEE=y
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> // Casey (she/her)
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>> // Casey (she/her)
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Sumit Garg]

On Fri, Jan 16, 2026 at 06:46:16PM +0100, Casey Connolly wrote:
> Hi Sumit,
> 
> (Top-posting since this thread is getting a bit busy)
> 
> I'm not sure if Neil and I properly conveyed why we don't agree with your
> proposal here: essentially it is an inversion of logic. CONFIG_OPTEE doesn't
> indicate that the board IS running OP-TEE, it just builds in support for
> OP-TEE. In general U-Boot is trying to trend away from using kconfig to
> dictate behaviour in this way.

OP-TEE as TZ is an optional feature for any arm64 SoC. And even with
U-Boot SPL as the initial boot-loader you get to decide via a Kconfig
option whether to support OP-TEE or not. Similarly with TF-A BL31, you
have to specify "spd=opteed" during build time if OP-TEE is supported or
not. So indeed it's a build time configuration for firmware to support
OP-TEE or not.

> 
> Adjacently, for Qualcomm support in U-Boot we are trying to improve upon the
> status quo: we don't do board-specific code, we limit hardcoding
> functionality or build-time configuration in favour of runtime checks as
> much as possible.

Not sure why you consider the OP-TEE feature being added here to be
board specific. It is rather extending the qcom_defconfig to support
OP-TEE based security features. For sure, we need to support similar
board agnostic config fragments to enable UEFI secure boot with EFI
runtime varibales based on OP-TEE RPMB storage.

> 
> With that perspective in mind, I would much prefer that switching from QTEE
> to TF-A/OP-TEE on the rb3gen2 (or any other qcom board) not require flashing
> a bespoke U-Boot build, the same build should just work on both.

The bespoke U-Boot build is already required for QTEE based flows, see:
- qcm6490_defconfig
- qcs9100_defconfig
- qcom_ipq5424_mmc_defconfig
- so on..

vs

U-Boot build with OP-TEE flow:
- qcom_defconfig + OP-TEE config fragment

And the resulting u-boot.bin gets used as BL33 for fip.bin as shown
here [1].

[1] https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html

> 
> There are several ways it might be possible to check for OP-TEE at runtime,
> arguably the simplest is the SMC call I proposed (which could be restricted
> to just kodiak),

This is going to be board specific logic and not scalable.

> the other idea that comes to mind is populating the x2
> register with a magic number when jumping to U-Boot, or even using the
> functionality already in place for passing data between bootloader stages
> (assuming the necessary bits are upstream in both projects).

Having a generic mechanism for passing data among bootloader stages is
the way to go here. Firmware handoff spec here [2] provides a good
reference for that. Although I don't see a specific bloblist tag which
can be used to detect OP-TEE presence.

Not sure why blocking this OP-TEE feature to be supported on Qcom
platforms is a good idea until that firmware handoff mechanism get's
realized on Qcom platforms. Also, even when the same U-Boot build can't
be used for both QTEE and OP-TEE.

[2] https://github.com/FirmwareHandoff/firmware_handoff

> 
> You say that making that SMC call on QTEE is undefined behaviour, but surely
> it doesn't break stuff? I'd hope that simply seeing what happens would be
> enough to define it, maybe checking with the boot team too.

As I said it's going to be hit and trial approach using SMC calls which
isn't scalable.

> 
> Your patch also mentions the EFI DT fixup protocol, but there is no
> corresponding code for that. iirc there are other DT changes needed for
> everything to work properly on rb3gen2 with OP-TEE, is the plan to get those
> changes done in such a way that the same DT will work with both OP-TEE and
> QTEE?

With OP-TEE, we would be booting Linux in EL2 and there is corresponding
DT work going on for QTEE with *_el2.dtso being added. So essentially
the plan is to reuse same DT with *_el2.dtso overlay which is
independent of whether OP-TEE or QTEE is running.

However, even without that we have a functional boot to shell system
that can be used for OP-TEE based use-cases development.

-Sumit

> 
> - Casey
> 
> On 1/16/26 13:17, Sumit Garg wrote:
> > On Fri, Jan 16, 2026 at 10:53:15AM +0100, Neil Armstrong wrote:
> > > On 1/16/26 08:53, Sumit Garg wrote:
> > > > On Fri, Jan 16, 2026 at 08:34:33AM +0100, Neil Armstrong wrote:
> > > > > On 1/16/26 07:57, Sumit Garg wrote:
> > > > > > On Thu, Jan 15, 2026 at 02:35:23PM +0100, Neil Armstrong wrote:
> > > > > > > On 1/15/26 14:27, Sumit Garg wrote:
> > > > > > > > On Thu, Jan 15, 2026 at 02:03:29PM +0100, Neil Armstrong wrote:
> > > > > > > > > On 1/15/26 13:25, Sumit Garg wrote:
> > > > > > > > > > + Jens (OP-TEE driver author in U-Boot)
> > > > > > > > > > 
> > > > > > > > > > On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
> > > > > > > > > > > On 1/15/26 07:10, Sumit Garg wrote:
> > > > > > > > > > > > On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On 09/01/2026 12:02, Sumit Garg wrote:
> > > > > > > > > > > > > > On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > On 29/12/2025 12:43, Sumit Garg wrote:
> > > > > > > > > > > > > > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Recently upstream TF-A/OP-TEE has started gaining support for Qcom
> > > > > > > > > > > > > > > > platforms. RB3Gen2 being the first one and more to come. U-Boot in
> > > > > > > > > > > > > > > > corresponding boot flow is packaged as a position independent executable.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > So, lets add a generic U-Boot defconfig for Qcom platforms to support
> > > > > > > > > > > > > > > > TF-A/OP-TEE based TrustZone stack. Build command:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > $ make qcom_tfa_optee_defconfig
> > > > > > > > > > > > > > > > $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > This would be better suited as a config fragment rather than a new
> > > > > > > > > > > > > > > defconfig imo.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > That's fine with me to add it as a config fragment.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > But more importantly, enabling OPTEE support in U-Boot doesn't imply
> > > > > > > > > > > > > > > that it will be used, just that it's supported.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
> > > > > > > > > > > > > > secure EFI variables based on OP-TEE secure storage. Have a look here [1].
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > And sure there will be more such use-cases like fTPM, KASLR etc. can be
> > > > > > > > > > > > > > supported based on OP-TEE.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I was referring literally to the fact that CONFIG_OPTEE being enabled
> > > > > > > > > > > > > doesn't imply that OP-TEE is running, it's faulty logic to assume that's
> > > > > > > > > > > > > the case and add nodes to the DT.
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't disagree here as having a runtime check is always a better
> > > > > > > > > > > > choice then a compile time config option. However, there isn't a common
> > > > > > > > > > > > info method from properietary firmware that says if QTEE is running
> > > > > > > > > > > > instead of OP-TEE.
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I just checked and there is an SMC call that tells you the UUID for the
> > > > > > > > > > > > > trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
> > > > > > > > > > > > > OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
> > > > > > > > > > > > > specifically.
> > > > > > > > > > > > 
> > > > > > > > > > > > Also, we don't know how the QTEE will react to this OP-TEE specific SMC
> > > > > > > > > > > > call given it's different variants running on legacy and the newer SoCs.
> > > > > > > > > > > > So I would suggest to better gate OP-TEE presence behind a compile time
> > > > > > > > > > > > check only.
> > > > > > > > > > > 
> > > > > > > > > > > So you say it's fine to add the optee node, and the driver will bail out if
> > > > > > > > > > > OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
> > > > > > > > > > > in the fixup code to enable OPTEE only if present ?
> > > > > > > > > > > 
> > > > > > > > > > > It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
> > > > > > > > > > > was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
> > > > > > > > > > > node only if present _AND_ if CONFIG_OPTEE is enabled.
> > > > > > > > > > > 
> > > > > > > > > > > Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
> > > > > > > > > > > select OPTEE explicitly on desired platforms, and won't run the naughty
> > > > > > > > > > > OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
> > > > > > > > > > 
> > > > > > > > > > I am still trying to understand what benefit does invoking
> > > > > > > > > > OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
> > > > > > > > > > can't be used to detect OP-TEE not present when QTEE is running due to
> > > > > > > > > > unknown behaviour with QTEE.
> > > > > > > > > 
> > > > > > > > > Sorry but what exactly do you expect that will happen if you enable the OPTEE
> > > > > > > > > driver when running with QTEE ?
> > > > > > > > 
> > > > > > > > The OP-TEE SMC calls are not at all supported with QTEE, so the expected
> > > > > > > > behaviour is undefined. IOW, the OP-TEE SMC ABI is not compatible with
> > > > > > > > QTEE. However, it's going to be hit and trial method to see what QTEE
> > > > > > > > responds to OP-TEE SMC calls. So it's not a reliable source of
> > > > > > > > information we can use to detect which TEE is present or not.
> > > > > > > 
> > > > > > > So until we know, this change is a no go, we can't just add the /optee node
> > > > > > > and hope the person building uboot did the right thing.
> > > > > > 
> > > > > > Not sure why you think Qualcomm platforms are special in this regards
> > > > > > when similar OP-TEE node additions based on CONFIG_OPTEE exist for other
> > > > > > platforms, see example here [1] [2] [3].
> > > > > > 
> > > > > > The OP-TEE configs will surely be part of a separate config fragment and
> > > > > > I can add comments there for developer's awareness.
> > > > > > 
> > > > > > [1] arch/arm/dts/imx8mm-u-boot.dtsi:10
> > > > > > [2] arch/arm/dts/imx8mn-u-boot.dtsi:10
> > > > > > [3] arch/arm/dts/imx8mp-u-boot.dtsi:11
> > > > > > 
> > > > > > > 
> > > > > > > I propose an alternate way, is to check for QTEE and then test for OPTEE.
> > > > > > 
> > > > > > There are more combinations rather than just QTEE or OP-TEE as follows:
> > > > > > - Older targets have support for QSEECOM
> > > > > > - Newer targets with QTEE support
> > > > > > - Chrome targets without any TEE support
> > > > > > - IoT targets with OP-TEE support
> > > > > > 
> > > > > > Do you have any particular mechanism in mind for detecting OP-TEE
> > > > > > presence at runtime? And surely that has to be well supported on variety
> > > > > > of SoC where U-Boot is supported as of now.
> > > > > 
> > > > > OPTEE_SMC_CALL_GET_OS_UUID which works fine on like all the other ARM based
> > > > > platforms.
> > > > 
> > > > Can you share at-least one example of other Arm based platform where this
> > > > SMC call is used to add OP-TEE DT node?
> > > 
> > > AFAIK no other platforms does that, I never said it was a standard thing,
> > > I said it would be necessary to avoid messing with the qualcomm proprietary
> > > boot chain.
> > > 
> > > > 
> > > > > 
> > > > > It's the only way, and only Qualcomm engineers can answer how to determine
> > > > > without any risk which TEE is running on the system.
> > > > 
> > > > The fact that you keep ignoring my responses that OP-TEE SMC ABI is not
> > > > compatible with QTEE/QSEECOM SMC ABI is not going to change (see [1]).
> > > > 
> > > > I am not sure why it's a blocker to use CONFIG_OPTEE for OP-TEE DT node
> > > > addition on Qcom platforms when the same criteria is being used for imx8*
> > > > platforms already.
> > > 
> > > It is not, if the node is present the it's fine. I'm concerned by adding
> > > the node when CONFIG_OPTEE is enabled.
> > > 
> > > Usually, the ARM64 platforms are shipped with a well-known or compatible
> > > boot chain like TF-A, and OPTEE is present or not. Those platforms
> > > will add the optee node knowing it can be present, and knowing other TEE
> > > won't crash if OPTEE_SMC_CALL_GET_OS_UUID is called.
> > > 
> > > You propose the other way, adding the optee node when config is present,
> > > not knowing exactly if the current system has optee or a qualcomm proprietary
> > > TEE that could not survive a OPTEE_SMC_CALL_GET_OS_UUID call.
> > 
> > Maybe I should have provided reference to the overall open boot stack [1]
> > early which is being planned for IoT platforms to begin with. The PR for
> > meta-qcom is here [2]. We are mostly waiting for the OEM only signing
> > feature for TZ image to be available in XBL_SEC such that any developer
> > can excercise that stack:
> > 
> > PBL (ROM) -> XBL -> TF-A BL2 -> TF-A BL31 -> BL33 -> Linux kernel
> >                                      |
> >                                       --> OP-TEE as BL32
> > 
> > TF-A and OP-TEE are going to be supported in a similar fashion on Qcom
> > platforms as any other ARM64 platform.
> > 
> > [1] https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> > [2] https://github.com/qualcomm-linux/meta-qcom/pull/1172
> > 
> > > 
> > > So my suggestion is:
> > > - ask the boot team a sequence/way to determine exactly which TEE is loaded (using SMC, smem or whatever)
> > > - only add the optee node if OPTEE or a compatible TEE is present
> > > 
> > > Then if CONFIG_OPTEE is enabled & the node is present the driver will
> > > be able to communicate with OPTEE.
> > 
> > Hence, OP-TEE is going to be supported in a developer controlled
> > environment only like any other ARM64 platform. So there is intention to
> > reuse the same workflows here. Since it's an open source boot stack then
> > it should be possible to use generic methodology if community comes up
> > with that later in future. That's why we should avoid Qcom specifc
> > platform code to enable such a feature apart from what others do.
> > 
> > -Sumit
> > 
> > > 
> > > > 
> > > > [1] https://lore.kernel.org/all/aWjrLF9DUPTaSA1c@sumit-xelite/.
> > > > 
> > > > -Sumit
> > > > 
> > > > > 
> > > > > Without this, all this discussions is pointless.
> > > > > 
> > > > > > 
> > > > > > Also, there is added complexity for targets where the developer can't
> > > > > > change the TZ firmware themselves on Qcom SoCs due to QTI signing
> > > > > > requirement.
> > > > > > 
> > > > > > -Sumit
> > > > > > 
> > > > > > > 
> > > > > > > Neil
> > > > > > > 
> > > > > > > > 
> > > > > > > > -Sumit
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Jens,
> > > > > > > > > > 
> > > > > > > > > > Will it be fine with you to expose is_optee_api() from the OP-TEE driver
> > > > > > > > > > for the platform code to invoke it independently? Just for the sake of this
> > > > > > > > > > discussion in case people still insist on it being the right thing to do.
> > > > > > > > > > 
> > > > > > > > > > -Sumit
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Neil
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
> > > > > > > > > > > > > in qcom_psci_fixup(), compare the UUID and add the node if it matches.
> > > > > > > > > > > > 
> > > > > > > > > > > > That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
> > > > > > > > > > > > does to compare the UUID here [1] and bail out of the driver. I don't
> > > > > > > > > > > > see a value of a redundant invoke in the Qcom specific platform code.
> > > > > > > > > > > > 
> > > > > > > > > > > > [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
> > > > > > > > > > > > 
> > > > > > > > > > > > -Sumit
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > [1] lib/efi_loader/efi_variable_tee.c
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > So I think the more appropriate patch here would be to just enable
> > > > > > > > > > > > > > > OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
> > > > > > > > > > > > > > > affected).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The OP-TEE driver in U-Boot itself is probed based on DT and it's not
> > > > > > > > > > > > > > only specific to Qcom platforms but every other platform using OP-TEE.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Considering the other patch is based on this assumption that if OP-TEE
> > > > > > > > > > > > > > > support is enabled then the board must be using it, a different approach
> > > > > > > > > > > > > > > is definitely needed.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Yeah that's true even with TF-A boot flow, there is possibility to boot
> > > > > > > > > > > > > > without OP-TEE as well. However, TF-A generally doesn't provide a
> > > > > > > > > > > > > > generic option to detect whether OP-TEE is running or not.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > When I was looking into this last year I remember discussing this same
> > > > > > > > > > > > > > > issue from the Linux side, there is a good argument to be made that
> > > > > > > > > > > > > > > OP-TEE support in Linux shouldn't be based on the devicetree -
> > > > > > > > > > > > > > > particularly in the Qualcomm case where whether or not OP-TEE is used is
> > > > > > > > > > > > > > > a simple software change, nothing to do with hardware.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Sadly it's true for every other silicon vendor too. But OP-TEE support
> > > > > > > > > > > > > > based on DT has become an ABI unless migration for OP-TEE support based
> > > > > > > > > > > > > > on FF-A comes into picture.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > So in general I'm not particularly keen on this approach, I think it
> > > > > > > > > > > > > > > /might/ be acceptable for U-Boot to have some fixup code to add the
> > > > > > > > > > > > > > > OP-TEE node if OP-TEE is in use with the idea of phasing that out in
> > > > > > > > > > > > > > > favour of runtime detection in the OS itself. I'd also expect that fixup
> > > > > > > > > > > > > > > code to go in the generic U-Boot DT fixup code that runs before we jump
> > > > > > > > > > > > > > > to the OS (like the EFI DT fixup function).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The EFI DT fixup code is already there based on U-Boot DT. Have a look
> > > > > > > > > > > > > > here:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > In general on Arm platforms there isn't any SMC bus to detect
> > > > > > > > > > > > > > dynamically if there is support for OP-TEE or not. That's why
> > > > > > > > > > > > > > platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
> > > > > > > > > > > > > > similar to how we have the SCM DT node for Qcom platforms.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > FF-A bus tries to solve that problem to unify that approach for future
> > > > > > > > > > > > > > platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
> > > > > > > > > > > > > > driver too.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Anyhow, this is the sanest way I can come up with to enable OP-TEE
> > > > > > > > > > > > > > support in a general way for all the Qcom platforms. This is aligned
> > > > > > > > > > > > > > with how OP-TEE support is detected for other silicon vendors too.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > -Sumit
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Kind regards,
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > For more information refer here:
> > > > > > > > > > > > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > >        configs/qcom_tfa_optee_defconfig | 7 +++++++
> > > > > > > > > > > > > > > >        1 file changed, 7 insertions(+)
> > > > > > > > > > > > > > > >        create mode 100644 configs/qcom_tfa_optee_defconfig
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
> > > > > > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > > > > > index 00000000000..c398521770f
> > > > > > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > > > > > +++ b/configs/qcom_tfa_optee_defconfig
> > > > > > > > > > > > > > > > @@ -0,0 +1,7 @@
> > > > > > > > > > > > > > > > +# Configuration for building a generic U-Boot image
> > > > > > > > > > > > > > > > +# with support for TF-A/OP-TEE based Arm TrustZone stack.
> > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > +#include "qcom_defconfig"
> > > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > > +CONFIG_TEE=y
> > > > > > > > > > > > > > > > +CONFIG_OPTEE=y
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > -- 
> > > > > > > > > > > > > > > // Casey (she/her)
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > -- 
> > > > > > > > > > > > > // Casey (she/her)
> > > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > 
> > > > > > > 
> > > > > 
> > > 
> 

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Casey Connolly]

On 21/01/2026 08:21, Sumit Garg wrote:
> On Fri, Jan 16, 2026 at 06:46:16PM +0100, Casey Connolly wrote:
>> Hi Sumit,
>>
>> (Top-posting since this thread is getting a bit busy)
>>
>> I'm not sure if Neil and I properly conveyed why we don't agree with your
>> proposal here: essentially it is an inversion of logic. CONFIG_OPTEE doesn't
>> indicate that the board IS running OP-TEE, it just builds in support for
>> OP-TEE. In general U-Boot is trying to trend away from using kconfig to
>> dictate behaviour in this way.
> 
> OP-TEE as TZ is an optional feature for any arm64 SoC. And even with
> U-Boot SPL as the initial boot-loader you get to decide via a Kconfig
> option whether to support OP-TEE or not. Similarly with TF-A BL31, you
> have to specify "spd=opteed" during build time if OP-TEE is supported or
> not. So indeed it's a build time configuration for firmware to support
> OP-TEE or not.

Right, but I would not expect that enabling CONFIG_OPTEE in U-Boot would
result in DT fixups being applied since I may actually be running QTEE,
or plain TF-A without OP-TEE. CONFIG_OPTEE does not tell U-Boot that
OPTEE is being used, it simply enables the OP-TEE drivers in U-Boot.

An additional kconfig option like "CONFIG_OPTEE_DT_FIXUP" would make
more sense here but would still be an imho hard to justify hack.

> 
>>
>> Adjacently, for Qualcomm support in U-Boot we are trying to improve upon the
>> status quo: we don't do board-specific code, we limit hardcoding
>> functionality or build-time configuration in favour of runtime checks as
>> much as possible.
> 
> Not sure why you consider the OP-TEE feature being added here to be
> board specific. It is rather extending the qcom_defconfig to support
> OP-TEE based security features. For sure, we need to support similar
> board agnostic config fragments to enable UEFI secure boot with EFI
> runtime varibales based on OP-TEE RPMB storage.
> 
>>
>> With that perspective in mind, I would much prefer that switching from QTEE
>> to TF-A/OP-TEE on the rb3gen2 (or any other qcom board) not require flashing
>> a bespoke U-Boot build, the same build should just work on both.
> 
> The bespoke U-Boot build is already required for QTEE based flows, see:
> - qcm6490_defconfig
> - qcs9100_defconfig
> - qcom_ipq5424_mmc_defconfig
> - so on..

These defconfigs are not "bespoke" for QTEE, they will work just fine if
you're using TF-A like on a Chromebook.

> 
> vs
> 
> U-Boot build with OP-TEE flow:
> - qcom_defconfig + OP-TEE config fragment
> 
> And the resulting u-boot.bin gets used as BL33 for fip.bin as shown
> here [1].
> 
> [1] https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> 
>>
>> There are several ways it might be possible to check for OP-TEE at runtime,
>> arguably the simplest is the SMC call I proposed (which could be restricted
>> to just kodiak),
> 
> This is going to be board specific logic and not scalable.

I think this is where I'm getting a bit stuck, can you substantiate this
a bit? iirc normal SIP calls aren't used for talking with TA's in QTEE

I just gave this a go on SM8650 HDK and it does just return an error:

Trying OPTEE_GET_OS_UUID call
res: 0xffffffffffffffff 0x0 0x0 0x0

So why isn't this appropriate or "scalable"?

> 
>> the other idea that comes to mind is populating the x2
>> register with a magic number when jumping to U-Boot, or even using the
>> functionality already in place for passing data between bootloader stages
>> (assuming the necessary bits are upstream in both projects).
> 
> Having a generic mechanism for passing data among bootloader stages is
> the way to go here. Firmware handoff spec here [2] provides a good
> reference for that. Although I don't see a specific bloblist tag which
> can be used to detect OP-TEE presence.
> 
> Not sure why blocking this OP-TEE feature to be supported on Qcom
> platforms is a good idea until that firmware handoff mechanism get's
> realized on Qcom platforms. Also, even when the same U-Boot build can't
> be used for both QTEE and OP-TEE.
> 
> [2] https://github.com/FirmwareHandoff/firmware_handoff

If firmware handoff is being used, then an SMC call can certainly be
used to check if OP-TEE is present!

> 
>>
>> You say that making that SMC call on QTEE is undefined behaviour, but surely
>> it doesn't break stuff? I'd hope that simply seeing what happens would be
>> enough to define it, maybe checking with the boot team too.
> 
> As I said it's going to be hit and trial approach using SMC calls which
> isn't scalable.
> 
>>
>> Your patch also mentions the EFI DT fixup protocol, but there is no
>> corresponding code for that. iirc there are other DT changes needed for
>> everything to work properly on rb3gen2 with OP-TEE, is the plan to get those
>> changes done in such a way that the same DT will work with both OP-TEE and
>> QTEE?
> 
> With OP-TEE, we would be booting Linux in EL2 and there is corresponding
> DT work going on for QTEE with *_el2.dtso being added. So essentially
> the plan is to reuse same DT with *_el2.dtso overlay which is
> independent of whether OP-TEE or QTEE is running.
> 
> However, even without that we have a functional boot to shell system
> that can be used for OP-TEE based use-cases development.

Ok I see, that's good to know!

I think we're running into the limits of email with this discussion,
maybe we can organise a call to sort this out? I don't suppose you'll be
at FOSDEM this year?

Kind regards,

> 
> -Sumit
> 
>>
>> - Casey
>>
>> On 1/16/26 13:17, Sumit Garg wrote:
>>> On Fri, Jan 16, 2026 at 10:53:15AM +0100, Neil Armstrong wrote:
>>>> On 1/16/26 08:53, Sumit Garg wrote:
>>>>> On Fri, Jan 16, 2026 at 08:34:33AM +0100, Neil Armstrong wrote:
>>>>>> On 1/16/26 07:57, Sumit Garg wrote:
>>>>>>> On Thu, Jan 15, 2026 at 02:35:23PM +0100, Neil Armstrong wrote:
>>>>>>>> On 1/15/26 14:27, Sumit Garg wrote:
>>>>>>>>> On Thu, Jan 15, 2026 at 02:03:29PM +0100, Neil Armstrong wrote:
>>>>>>>>>> On 1/15/26 13:25, Sumit Garg wrote:
>>>>>>>>>>> + Jens (OP-TEE driver author in U-Boot)
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
>>>>>>>>>>>> On 1/15/26 07:10, Sumit Garg wrote:
>>>>>>>>>>>>> On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 09/01/2026 12:02, Sumit Garg wrote:
>>>>>>>>>>>>>>> On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 29/12/2025 12:43, Sumit Garg wrote:
>>>>>>>>>>>>>>>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
>>>>>>>>>>>>>>>>> platforms. RB3Gen2 being the first one and more to come. U-Boot in
>>>>>>>>>>>>>>>>> corresponding boot flow is packaged as a position independent executable.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, lets add a generic U-Boot defconfig for Qcom platforms to support
>>>>>>>>>>>>>>>>> TF-A/OP-TEE based TrustZone stack. Build command:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> $ make qcom_tfa_optee_defconfig
>>>>>>>>>>>>>>>>> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This would be better suited as a config fragment rather than a new
>>>>>>>>>>>>>>>> defconfig imo.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's fine with me to add it as a config fragment.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But more importantly, enabling OPTEE support in U-Boot doesn't imply
>>>>>>>>>>>>>>>> that it will be used, just that it's supported.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
>>>>>>>>>>>>>>> secure EFI variables based on OP-TEE secure storage. Have a look here [1].
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And sure there will be more such use-cases like fTPM, KASLR etc. can be
>>>>>>>>>>>>>>> supported based on OP-TEE.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I was referring literally to the fact that CONFIG_OPTEE being enabled
>>>>>>>>>>>>>> doesn't imply that OP-TEE is running, it's faulty logic to assume that's
>>>>>>>>>>>>>> the case and add nodes to the DT.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't disagree here as having a runtime check is always a better
>>>>>>>>>>>>> choice then a compile time config option. However, there isn't a common
>>>>>>>>>>>>> info method from properietary firmware that says if QTEE is running
>>>>>>>>>>>>> instead of OP-TEE.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I just checked and there is an SMC call that tells you the UUID for the
>>>>>>>>>>>>>> trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
>>>>>>>>>>>>>> OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
>>>>>>>>>>>>>> specifically.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, we don't know how the QTEE will react to this OP-TEE specific SMC
>>>>>>>>>>>>> call given it's different variants running on legacy and the newer SoCs.
>>>>>>>>>>>>> So I would suggest to better gate OP-TEE presence behind a compile time
>>>>>>>>>>>>> check only.
>>>>>>>>>>>>
>>>>>>>>>>>> So you say it's fine to add the optee node, and the driver will bail out if
>>>>>>>>>>>> OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
>>>>>>>>>>>> in the fixup code to enable OPTEE only if present ?
>>>>>>>>>>>>
>>>>>>>>>>>> It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
>>>>>>>>>>>> was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
>>>>>>>>>>>> node only if present _AND_ if CONFIG_OPTEE is enabled.
>>>>>>>>>>>>
>>>>>>>>>>>> Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
>>>>>>>>>>>> select OPTEE explicitly on desired platforms, and won't run the naughty
>>>>>>>>>>>> OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
>>>>>>>>>>>
>>>>>>>>>>> I am still trying to understand what benefit does invoking
>>>>>>>>>>> OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
>>>>>>>>>>> can't be used to detect OP-TEE not present when QTEE is running due to
>>>>>>>>>>> unknown behaviour with QTEE.
>>>>>>>>>>
>>>>>>>>>> Sorry but what exactly do you expect that will happen if you enable the OPTEE
>>>>>>>>>> driver when running with QTEE ?
>>>>>>>>>
>>>>>>>>> The OP-TEE SMC calls are not at all supported with QTEE, so the expected
>>>>>>>>> behaviour is undefined. IOW, the OP-TEE SMC ABI is not compatible with
>>>>>>>>> QTEE. However, it's going to be hit and trial method to see what QTEE
>>>>>>>>> responds to OP-TEE SMC calls. So it's not a reliable source of
>>>>>>>>> information we can use to detect which TEE is present or not.
>>>>>>>>
>>>>>>>> So until we know, this change is a no go, we can't just add the /optee node
>>>>>>>> and hope the person building uboot did the right thing.
>>>>>>>
>>>>>>> Not sure why you think Qualcomm platforms are special in this regards
>>>>>>> when similar OP-TEE node additions based on CONFIG_OPTEE exist for other
>>>>>>> platforms, see example here [1] [2] [3].
>>>>>>>
>>>>>>> The OP-TEE configs will surely be part of a separate config fragment and
>>>>>>> I can add comments there for developer's awareness.
>>>>>>>
>>>>>>> [1] arch/arm/dts/imx8mm-u-boot.dtsi:10
>>>>>>> [2] arch/arm/dts/imx8mn-u-boot.dtsi:10
>>>>>>> [3] arch/arm/dts/imx8mp-u-boot.dtsi:11
>>>>>>>
>>>>>>>>
>>>>>>>> I propose an alternate way, is to check for QTEE and then test for OPTEE.
>>>>>>>
>>>>>>> There are more combinations rather than just QTEE or OP-TEE as follows:
>>>>>>> - Older targets have support for QSEECOM
>>>>>>> - Newer targets with QTEE support
>>>>>>> - Chrome targets without any TEE support
>>>>>>> - IoT targets with OP-TEE support
>>>>>>>
>>>>>>> Do you have any particular mechanism in mind for detecting OP-TEE
>>>>>>> presence at runtime? And surely that has to be well supported on variety
>>>>>>> of SoC where U-Boot is supported as of now.
>>>>>>
>>>>>> OPTEE_SMC_CALL_GET_OS_UUID which works fine on like all the other ARM based
>>>>>> platforms.
>>>>>
>>>>> Can you share at-least one example of other Arm based platform where this
>>>>> SMC call is used to add OP-TEE DT node?
>>>>
>>>> AFAIK no other platforms does that, I never said it was a standard thing,
>>>> I said it would be necessary to avoid messing with the qualcomm proprietary
>>>> boot chain.
>>>>
>>>>>
>>>>>>
>>>>>> It's the only way, and only Qualcomm engineers can answer how to determine
>>>>>> without any risk which TEE is running on the system.
>>>>>
>>>>> The fact that you keep ignoring my responses that OP-TEE SMC ABI is not
>>>>> compatible with QTEE/QSEECOM SMC ABI is not going to change (see [1]).
>>>>>
>>>>> I am not sure why it's a blocker to use CONFIG_OPTEE for OP-TEE DT node
>>>>> addition on Qcom platforms when the same criteria is being used for imx8*
>>>>> platforms already.
>>>>
>>>> It is not, if the node is present the it's fine. I'm concerned by adding
>>>> the node when CONFIG_OPTEE is enabled.
>>>>
>>>> Usually, the ARM64 platforms are shipped with a well-known or compatible
>>>> boot chain like TF-A, and OPTEE is present or not. Those platforms
>>>> will add the optee node knowing it can be present, and knowing other TEE
>>>> won't crash if OPTEE_SMC_CALL_GET_OS_UUID is called.
>>>>
>>>> You propose the other way, adding the optee node when config is present,
>>>> not knowing exactly if the current system has optee or a qualcomm proprietary
>>>> TEE that could not survive a OPTEE_SMC_CALL_GET_OS_UUID call.
>>>
>>> Maybe I should have provided reference to the overall open boot stack [1]
>>> early which is being planned for IoT platforms to begin with. The PR for
>>> meta-qcom is here [2]. We are mostly waiting for the OEM only signing
>>> feature for TZ image to be available in XBL_SEC such that any developer
>>> can excercise that stack:
>>>
>>> PBL (ROM) -> XBL -> TF-A BL2 -> TF-A BL31 -> BL33 -> Linux kernel
>>>                                      |
>>>                                       --> OP-TEE as BL32
>>>
>>> TF-A and OP-TEE are going to be supported in a similar fashion on Qcom
>>> platforms as any other ARM64 platform.
>>>
>>> [1] https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
>>> [2] https://github.com/qualcomm-linux/meta-qcom/pull/1172
>>>
>>>>
>>>> So my suggestion is:
>>>> - ask the boot team a sequence/way to determine exactly which TEE is loaded (using SMC, smem or whatever)
>>>> - only add the optee node if OPTEE or a compatible TEE is present
>>>>
>>>> Then if CONFIG_OPTEE is enabled & the node is present the driver will
>>>> be able to communicate with OPTEE.
>>>
>>> Hence, OP-TEE is going to be supported in a developer controlled
>>> environment only like any other ARM64 platform. So there is intention to
>>> reuse the same workflows here. Since it's an open source boot stack then
>>> it should be possible to use generic methodology if community comes up
>>> with that later in future. That's why we should avoid Qcom specifc
>>> platform code to enable such a feature apart from what others do.
>>>
>>> -Sumit
>>>
>>>>
>>>>>
>>>>> [1] https://lore.kernel.org/all/aWjrLF9DUPTaSA1c@sumit-xelite/.
>>>>>
>>>>> -Sumit
>>>>>
>>>>>>
>>>>>> Without this, all this discussions is pointless.
>>>>>>
>>>>>>>
>>>>>>> Also, there is added complexity for targets where the developer can't
>>>>>>> change the TZ firmware themselves on Qcom SoCs due to QTI signing
>>>>>>> requirement.
>>>>>>>
>>>>>>> -Sumit
>>>>>>>
>>>>>>>>
>>>>>>>> Neil
>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Sumit
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jens,
>>>>>>>>>>>
>>>>>>>>>>> Will it be fine with you to expose is_optee_api() from the OP-TEE driver
>>>>>>>>>>> for the platform code to invoke it independently? Just for the sake of this
>>>>>>>>>>> discussion in case people still insist on it being the right thing to do.
>>>>>>>>>>>
>>>>>>>>>>> -Sumit
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Neil
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
>>>>>>>>>>>>>> in qcom_psci_fixup(), compare the UUID and add the node if it matches.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
>>>>>>>>>>>>> does to compare the UUID here [1] and bail out of the driver. I don't
>>>>>>>>>>>>> see a value of a redundant invoke in the Qcom specific platform code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Sumit
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1] lib/efi_loader/efi_variable_tee.c
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So I think the more appropriate patch here would be to just enable
>>>>>>>>>>>>>>>> OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
>>>>>>>>>>>>>>>> affected).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The OP-TEE driver in U-Boot itself is probed based on DT and it's not
>>>>>>>>>>>>>>> only specific to Qcom platforms but every other platform using OP-TEE.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Considering the other patch is based on this assumption that if OP-TEE
>>>>>>>>>>>>>>>> support is enabled then the board must be using it, a different approach
>>>>>>>>>>>>>>>> is definitely needed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yeah that's true even with TF-A boot flow, there is possibility to boot
>>>>>>>>>>>>>>> without OP-TEE as well. However, TF-A generally doesn't provide a
>>>>>>>>>>>>>>> generic option to detect whether OP-TEE is running or not.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When I was looking into this last year I remember discussing this same
>>>>>>>>>>>>>>>> issue from the Linux side, there is a good argument to be made that
>>>>>>>>>>>>>>>> OP-TEE support in Linux shouldn't be based on the devicetree -
>>>>>>>>>>>>>>>> particularly in the Qualcomm case where whether or not OP-TEE is used is
>>>>>>>>>>>>>>>> a simple software change, nothing to do with hardware.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sadly it's true for every other silicon vendor too. But OP-TEE support
>>>>>>>>>>>>>>> based on DT has become an ABI unless migration for OP-TEE support based
>>>>>>>>>>>>>>> on FF-A comes into picture.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So in general I'm not particularly keen on this approach, I think it
>>>>>>>>>>>>>>>> /might/ be acceptable for U-Boot to have some fixup code to add the
>>>>>>>>>>>>>>>> OP-TEE node if OP-TEE is in use with the idea of phasing that out in
>>>>>>>>>>>>>>>> favour of runtime detection in the OS itself. I'd also expect that fixup
>>>>>>>>>>>>>>>> code to go in the generic U-Boot DT fixup code that runs before we jump
>>>>>>>>>>>>>>>> to the OS (like the EFI DT fixup function).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The EFI DT fixup code is already there based on U-Boot DT. Have a look
>>>>>>>>>>>>>>> here:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In general on Arm platforms there isn't any SMC bus to detect
>>>>>>>>>>>>>>> dynamically if there is support for OP-TEE or not. That's why
>>>>>>>>>>>>>>> platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
>>>>>>>>>>>>>>> similar to how we have the SCM DT node for Qcom platforms.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> FF-A bus tries to solve that problem to unify that approach for future
>>>>>>>>>>>>>>> platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
>>>>>>>>>>>>>>> driver too.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Anyhow, this is the sanest way I can come up with to enable OP-TEE
>>>>>>>>>>>>>>> support in a general way for all the Qcom platforms. This is aligned
>>>>>>>>>>>>>>> with how OP-TEE support is detected for other silicon vendors too.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Sumit
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For more information refer here:
>>>>>>>>>>>>>>>>> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>        configs/qcom_tfa_optee_defconfig | 7 +++++++
>>>>>>>>>>>>>>>>>        1 file changed, 7 insertions(+)
>>>>>>>>>>>>>>>>>        create mode 100644 configs/qcom_tfa_optee_defconfig
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
>>>>>>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>>>>>>> index 00000000000..c398521770f
>>>>>>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>>>>>>> +++ b/configs/qcom_tfa_optee_defconfig
>>>>>>>>>>>>>>>>> @@ -0,0 +1,7 @@
>>>>>>>>>>>>>>>>> +# Configuration for building a generic U-Boot image
>>>>>>>>>>>>>>>>> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> +#include "qcom_defconfig"
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> +CONFIG_TEE=y
>>>>>>>>>>>>>>>>> +CONFIG_OPTEE=y
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>> // Casey (she/her)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> // Casey (she/her)
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>

-- 
// Casey (she/her)

Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

[Sumit Garg]

On Wed, Jan 21, 2026 at 11:38:52AM +0100, Casey Connolly wrote:
> 
> 
> On 21/01/2026 08:21, Sumit Garg wrote:
> > On Fri, Jan 16, 2026 at 06:46:16PM +0100, Casey Connolly wrote:
> >> Hi Sumit,
> >>
> >> (Top-posting since this thread is getting a bit busy)
> >>
> >> I'm not sure if Neil and I properly conveyed why we don't agree with your
> >> proposal here: essentially it is an inversion of logic. CONFIG_OPTEE doesn't
> >> indicate that the board IS running OP-TEE, it just builds in support for
> >> OP-TEE. In general U-Boot is trying to trend away from using kconfig to
> >> dictate behaviour in this way.
> > 
> > OP-TEE as TZ is an optional feature for any arm64 SoC. And even with
> > U-Boot SPL as the initial boot-loader you get to decide via a Kconfig
> > option whether to support OP-TEE or not. Similarly with TF-A BL31, you
> > have to specify "spd=opteed" during build time if OP-TEE is supported or
> > not. So indeed it's a build time configuration for firmware to support
> > OP-TEE or not.
> 
> Right, but I would not expect that enabling CONFIG_OPTEE in U-Boot would
> result in DT fixups being applied since I may actually be running QTEE,
> or plain TF-A without OP-TEE. CONFIG_OPTEE does not tell U-Boot that
> OPTEE is being used, it simply enables the OP-TEE drivers in U-Boot.
>

See existing usage of CONFIG_OPTEE for DT fixups here [1] [2] [3].

[1] https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/imx8mm-u-boot.dtsi#L10
[2] https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/imx8mn-u-boot.dtsi#L10
[3] https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/imx8mp-u-boot.dtsi#L11

> An additional kconfig option like "CONFIG_OPTEE_DT_FIXUP" would make
> more sense here but would still be an imho hard to justify hack.
> 
> > 
> >>
> >> Adjacently, for Qualcomm support in U-Boot we are trying to improve upon the
> >> status quo: we don't do board-specific code, we limit hardcoding
> >> functionality or build-time configuration in favour of runtime checks as
> >> much as possible.
> > 
> > Not sure why you consider the OP-TEE feature being added here to be
> > board specific. It is rather extending the qcom_defconfig to support
> > OP-TEE based security features. For sure, we need to support similar
> > board agnostic config fragments to enable UEFI secure boot with EFI
> > runtime varibales based on OP-TEE RPMB storage.
> > 
> >>
> >> With that perspective in mind, I would much prefer that switching from QTEE
> >> to TF-A/OP-TEE on the rb3gen2 (or any other qcom board) not require flashing
> >> a bespoke U-Boot build, the same build should just work on both.
> > 
> > The bespoke U-Boot build is already required for QTEE based flows, see:
> > - qcm6490_defconfig
> > - qcs9100_defconfig
> > - qcom_ipq5424_mmc_defconfig
> > - so on..
> 
> These defconfigs are not "bespoke" for QTEE, they will work just fine if
> you're using TF-A like on a Chromebook.

I don't think the unique elf format is used on Chromebook, right?

> 
> > 
> > vs
> > 
> > U-Boot build with OP-TEE flow:
> > - qcom_defconfig + OP-TEE config fragment
> > 
> > And the resulting u-boot.bin gets used as BL33 for fip.bin as shown
> > here [1].
> > 
> > [1] https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> > 
> >>
> >> There are several ways it might be possible to check for OP-TEE at runtime,
> >> arguably the simplest is the SMC call I proposed (which could be restricted
> >> to just kodiak),
> > 
> > This is going to be board specific logic and not scalable.
> 
> I think this is where I'm getting a bit stuck, can you substantiate this
> a bit? iirc normal SIP calls aren't used for talking with TA's in QTEE
> 
> I just gave this a go on SM8650 HDK and it does just return an error:
> 
> Trying OPTEE_GET_OS_UUID call
> res: 0xffffffffffffffff 0x0 0x0 0x0
> 
> So why isn't this appropriate or "scalable"?

I would like you to refer to SMC calling conventions here [4].
OPTEE_GET_OS_UUID falls in the range of Trusted OS specific SMC call.
Each trusted OS can choose the Owning Entity Number from 50-63 as per
SMC calling convention.

Calling random SMC calls isn't a good idea until you know that those SMC
calls are properly handled by the TZ entity. The whole reason why OP-TEE
driver works on DT based probing is this reason only. Otherwise why
would we need DT based probing in the first place for OP-TEE in case you
can rely on the OP-TEE SMC calls being properly handled on every
platform. IOW, there isn't a reliable SMC bus based OP-TEE driver probe.

I will defer to Jens to give further historical background here too.

[4] https://developer.arm.com/documentation/den0028/gb/?lang=en

> 
> > 
> >> the other idea that comes to mind is populating the x2
> >> register with a magic number when jumping to U-Boot, or even using the
> >> functionality already in place for passing data between bootloader stages
> >> (assuming the necessary bits are upstream in both projects).
> > 
> > Having a generic mechanism for passing data among bootloader stages is
> > the way to go here. Firmware handoff spec here [2] provides a good
> > reference for that. Although I don't see a specific bloblist tag which
> > can be used to detect OP-TEE presence.
> > 
> > Not sure why blocking this OP-TEE feature to be supported on Qcom
> > platforms is a good idea until that firmware handoff mechanism get's
> > realized on Qcom platforms. Also, even when the same U-Boot build can't
> > be used for both QTEE and OP-TEE.
> > 
> > [2] https://github.com/FirmwareHandoff/firmware_handoff
> 
> If firmware handoff is being used, then an SMC call can certainly be
> used to check if OP-TEE is present!
> 
> > 
> >>
> >> You say that making that SMC call on QTEE is undefined behaviour, but surely
> >> it doesn't break stuff? I'd hope that simply seeing what happens would be
> >> enough to define it, maybe checking with the boot team too.
> > 
> > As I said it's going to be hit and trial approach using SMC calls which
> > isn't scalable.
> > 
> >>
> >> Your patch also mentions the EFI DT fixup protocol, but there is no
> >> corresponding code for that. iirc there are other DT changes needed for
> >> everything to work properly on rb3gen2 with OP-TEE, is the plan to get those
> >> changes done in such a way that the same DT will work with both OP-TEE and
> >> QTEE?
> > 
> > With OP-TEE, we would be booting Linux in EL2 and there is corresponding
> > DT work going on for QTEE with *_el2.dtso being added. So essentially
> > the plan is to reuse same DT with *_el2.dtso overlay which is
> > independent of whether OP-TEE or QTEE is running.
> > 
> > However, even without that we have a functional boot to shell system
> > that can be used for OP-TEE based use-cases development.
> 
> Ok I see, that's good to know!
> 
> I think we're running into the limits of email with this discussion,
> maybe we can organise a call to sort this out? I don't suppose you'll be
> at FOSDEM this year?

Sure, lets schedule a call to close on this discussion. I know we are
already going in loops. Would you prefer a zoom call?

-Sumit

> 
> Kind regards,
> 
> > 
> > -Sumit
> > 
> >>
> >> - Casey
> >>
> >> On 1/16/26 13:17, Sumit Garg wrote:
> >>> On Fri, Jan 16, 2026 at 10:53:15AM +0100, Neil Armstrong wrote:
> >>>> On 1/16/26 08:53, Sumit Garg wrote:
> >>>>> On Fri, Jan 16, 2026 at 08:34:33AM +0100, Neil Armstrong wrote:
> >>>>>> On 1/16/26 07:57, Sumit Garg wrote:
> >>>>>>> On Thu, Jan 15, 2026 at 02:35:23PM +0100, Neil Armstrong wrote:
> >>>>>>>> On 1/15/26 14:27, Sumit Garg wrote:
> >>>>>>>>> On Thu, Jan 15, 2026 at 02:03:29PM +0100, Neil Armstrong wrote:
> >>>>>>>>>> On 1/15/26 13:25, Sumit Garg wrote:
> >>>>>>>>>>> + Jens (OP-TEE driver author in U-Boot)
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Jan 15, 2026 at 11:49:49AM +0100, neil.armstrong@linaro.org wrote:
> >>>>>>>>>>>> On 1/15/26 07:10, Sumit Garg wrote:
> >>>>>>>>>>>>> On Wed, Jan 14, 2026 at 03:56:02PM +0100, Casey Connolly wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 09/01/2026 12:02, Sumit Garg wrote:
> >>>>>>>>>>>>>>> On Thu, Jan 08, 2026 at 05:41:42PM +0100, Casey Connolly wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 29/12/2025 12:43, Sumit Garg wrote:
> >>>>>>>>>>>>>>>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
> >>>>>>>>>>>>>>>>> platforms. RB3Gen2 being the first one and more to come. U-Boot in
> >>>>>>>>>>>>>>>>> corresponding boot flow is packaged as a position independent executable.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> So, lets add a generic U-Boot defconfig for Qcom platforms to support
> >>>>>>>>>>>>>>>>> TF-A/OP-TEE based TrustZone stack. Build command:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> $ make qcom_tfa_optee_defconfig
> >>>>>>>>>>>>>>>>> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> This would be better suited as a config fragment rather than a new
> >>>>>>>>>>>>>>>> defconfig imo.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> That's fine with me to add it as a config fragment.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> But more importantly, enabling OPTEE support in U-Boot doesn't imply
> >>>>>>>>>>>>>>>> that it will be used, just that it's supported.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> There are real use-cases of OP-TEE in U-Boot for Qcom platforms like
> >>>>>>>>>>>>>>> secure EFI variables based on OP-TEE secure storage. Have a look here [1].
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> And sure there will be more such use-cases like fTPM, KASLR etc. can be
> >>>>>>>>>>>>>>> supported based on OP-TEE.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I was referring literally to the fact that CONFIG_OPTEE being enabled
> >>>>>>>>>>>>>> doesn't imply that OP-TEE is running, it's faulty logic to assume that's
> >>>>>>>>>>>>>> the case and add nodes to the DT.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I don't disagree here as having a runtime check is always a better
> >>>>>>>>>>>>> choice then a compile time config option. However, there isn't a common
> >>>>>>>>>>>>> info method from properietary firmware that says if QTEE is running
> >>>>>>>>>>>>> instead of OP-TEE.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I just checked and there is an SMC call that tells you the UUID for the
> >>>>>>>>>>>>>> trusted OS, referred to as OPTEE_SMC_CALL_GET_OS_UUID in U-Boot and
> >>>>>>>>>>>>>> OPTEE_ABI_CALL_GET_OS_UUID in OP-TEE. Presumably this identifies OP-TEE
> >>>>>>>>>>>>>> specifically.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Also, we don't know how the QTEE will react to this OP-TEE specific SMC
> >>>>>>>>>>>>> call given it's different variants running on legacy and the newer SoCs.
> >>>>>>>>>>>>> So I would suggest to better gate OP-TEE presence behind a compile time
> >>>>>>>>>>>>> check only.
> >>>>>>>>>>>>
> >>>>>>>>>>>> So you say it's fine to add the optee node, and the driver will bail out if
> >>>>>>>>>>>> OPTEE is not present, but it's not good to call OPTEE_SMC_CALL_GET_OS_UUID
> >>>>>>>>>>>> in the fixup code to enable OPTEE only if present ?
> >>>>>>>>>>>>
> >>>>>>>>>>>> It's literally the same, my point in https://lore.kernel.org/all/b60d5ee7-fa27-4dc1-8a09-964912ec5654@linaro.org/
> >>>>>>>>>>>> was exactly that, just call OPTEE_SMC_CALL_GET_OS_UUID and add the OPTEE
> >>>>>>>>>>>> node only if present _AND_ if CONFIG_OPTEE is enabled.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Move the CONFIG_OPTEE enable in a fragment and we're done, you will only
> >>>>>>>>>>>> select OPTEE explicitly on desired platforms, and won't run the naughty
> >>>>>>>>>>>> OPTEE_SMC_CALL_GET_OS_UUID on old crappy platforms.
> >>>>>>>>>>>
> >>>>>>>>>>> I am still trying to understand what benefit does invoking
> >>>>>>>>>>> OPTEE_SMC_CALL_GET_OS_UUID from platform code provides us. Surely it
> >>>>>>>>>>> can't be used to detect OP-TEE not present when QTEE is running due to
> >>>>>>>>>>> unknown behaviour with QTEE.
> >>>>>>>>>>
> >>>>>>>>>> Sorry but what exactly do you expect that will happen if you enable the OPTEE
> >>>>>>>>>> driver when running with QTEE ?
> >>>>>>>>>
> >>>>>>>>> The OP-TEE SMC calls are not at all supported with QTEE, so the expected
> >>>>>>>>> behaviour is undefined. IOW, the OP-TEE SMC ABI is not compatible with
> >>>>>>>>> QTEE. However, it's going to be hit and trial method to see what QTEE
> >>>>>>>>> responds to OP-TEE SMC calls. So it's not a reliable source of
> >>>>>>>>> information we can use to detect which TEE is present or not.
> >>>>>>>>
> >>>>>>>> So until we know, this change is a no go, we can't just add the /optee node
> >>>>>>>> and hope the person building uboot did the right thing.
> >>>>>>>
> >>>>>>> Not sure why you think Qualcomm platforms are special in this regards
> >>>>>>> when similar OP-TEE node additions based on CONFIG_OPTEE exist for other
> >>>>>>> platforms, see example here [1] [2] [3].
> >>>>>>>
> >>>>>>> The OP-TEE configs will surely be part of a separate config fragment and
> >>>>>>> I can add comments there for developer's awareness.
> >>>>>>>
> >>>>>>> [1] arch/arm/dts/imx8mm-u-boot.dtsi:10
> >>>>>>> [2] arch/arm/dts/imx8mn-u-boot.dtsi:10
> >>>>>>> [3] arch/arm/dts/imx8mp-u-boot.dtsi:11
> >>>>>>>
> >>>>>>>>
> >>>>>>>> I propose an alternate way, is to check for QTEE and then test for OPTEE.
> >>>>>>>
> >>>>>>> There are more combinations rather than just QTEE or OP-TEE as follows:
> >>>>>>> - Older targets have support for QSEECOM
> >>>>>>> - Newer targets with QTEE support
> >>>>>>> - Chrome targets without any TEE support
> >>>>>>> - IoT targets with OP-TEE support
> >>>>>>>
> >>>>>>> Do you have any particular mechanism in mind for detecting OP-TEE
> >>>>>>> presence at runtime? And surely that has to be well supported on variety
> >>>>>>> of SoC where U-Boot is supported as of now.
> >>>>>>
> >>>>>> OPTEE_SMC_CALL_GET_OS_UUID which works fine on like all the other ARM based
> >>>>>> platforms.
> >>>>>
> >>>>> Can you share at-least one example of other Arm based platform where this
> >>>>> SMC call is used to add OP-TEE DT node?
> >>>>
> >>>> AFAIK no other platforms does that, I never said it was a standard thing,
> >>>> I said it would be necessary to avoid messing with the qualcomm proprietary
> >>>> boot chain.
> >>>>
> >>>>>
> >>>>>>
> >>>>>> It's the only way, and only Qualcomm engineers can answer how to determine
> >>>>>> without any risk which TEE is running on the system.
> >>>>>
> >>>>> The fact that you keep ignoring my responses that OP-TEE SMC ABI is not
> >>>>> compatible with QTEE/QSEECOM SMC ABI is not going to change (see [1]).
> >>>>>
> >>>>> I am not sure why it's a blocker to use CONFIG_OPTEE for OP-TEE DT node
> >>>>> addition on Qcom platforms when the same criteria is being used for imx8*
> >>>>> platforms already.
> >>>>
> >>>> It is not, if the node is present the it's fine. I'm concerned by adding
> >>>> the node when CONFIG_OPTEE is enabled.
> >>>>
> >>>> Usually, the ARM64 platforms are shipped with a well-known or compatible
> >>>> boot chain like TF-A, and OPTEE is present or not. Those platforms
> >>>> will add the optee node knowing it can be present, and knowing other TEE
> >>>> won't crash if OPTEE_SMC_CALL_GET_OS_UUID is called.
> >>>>
> >>>> You propose the other way, adding the optee node when config is present,
> >>>> not knowing exactly if the current system has optee or a qualcomm proprietary
> >>>> TEE that could not survive a OPTEE_SMC_CALL_GET_OS_UUID call.
> >>>
> >>> Maybe I should have provided reference to the overall open boot stack [1]
> >>> early which is being planned for IoT platforms to begin with. The PR for
> >>> meta-qcom is here [2]. We are mostly waiting for the OEM only signing
> >>> feature for TZ image to be available in XBL_SEC such that any developer
> >>> can excercise that stack:
> >>>
> >>> PBL (ROM) -> XBL -> TF-A BL2 -> TF-A BL31 -> BL33 -> Linux kernel
> >>>                                      |
> >>>                                       --> OP-TEE as BL32
> >>>
> >>> TF-A and OP-TEE are going to be supported in a similar fashion on Qcom
> >>> platforms as any other ARM64 platform.
> >>>
> >>> [1] https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> >>> [2] https://github.com/qualcomm-linux/meta-qcom/pull/1172
> >>>
> >>>>
> >>>> So my suggestion is:
> >>>> - ask the boot team a sequence/way to determine exactly which TEE is loaded (using SMC, smem or whatever)
> >>>> - only add the optee node if OPTEE or a compatible TEE is present
> >>>>
> >>>> Then if CONFIG_OPTEE is enabled & the node is present the driver will
> >>>> be able to communicate with OPTEE.
> >>>
> >>> Hence, OP-TEE is going to be supported in a developer controlled
> >>> environment only like any other ARM64 platform. So there is intention to
> >>> reuse the same workflows here. Since it's an open source boot stack then
> >>> it should be possible to use generic methodology if community comes up
> >>> with that later in future. That's why we should avoid Qcom specifc
> >>> platform code to enable such a feature apart from what others do.
> >>>
> >>> -Sumit
> >>>
> >>>>
> >>>>>
> >>>>> [1] https://lore.kernel.org/all/aWjrLF9DUPTaSA1c@sumit-xelite/.
> >>>>>
> >>>>> -Sumit
> >>>>>
> >>>>>>
> >>>>>> Without this, all this discussions is pointless.
> >>>>>>
> >>>>>>>
> >>>>>>> Also, there is added complexity for targets where the developer can't
> >>>>>>> change the TZ firmware themselves on Qcom SoCs due to QTI signing
> >>>>>>> requirement.
> >>>>>>>
> >>>>>>> -Sumit
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Neil
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -Sumit
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Jens,
> >>>>>>>>>>>
> >>>>>>>>>>> Will it be fine with you to expose is_optee_api() from the OP-TEE driver
> >>>>>>>>>>> for the platform code to invoke it independently? Just for the sake of this
> >>>>>>>>>>> discussion in case people still insist on it being the right thing to do.
> >>>>>>>>>>>
> >>>>>>>>>>> -Sumit
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Neil
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> My suggestion would be to make this SMC call if CONFIG_OPTEE is enabled
> >>>>>>>>>>>>>> in qcom_psci_fixup(), compare the UUID and add the node if it matches.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That's exactly the first SMC call that U-Boot and Linux OP-TEE driver
> >>>>>>>>>>>>> does to compare the UUID here [1] and bail out of the driver. I don't
> >>>>>>>>>>>>> see a value of a redundant invoke in the Qcom specific platform code.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1] drivers/tee/optee/core.c:823:   if (!is_optee_api(pdata->invoke_fn))
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Sumit
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [1] lib/efi_loader/efi_variable_tee.c
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> So I think the more appropriate patch here would be to just enable
> >>>>>>>>>>>>>>>> OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
> >>>>>>>>>>>>>>>> affected).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The OP-TEE driver in U-Boot itself is probed based on DT and it's not
> >>>>>>>>>>>>>>> only specific to Qcom platforms but every other platform using OP-TEE.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Considering the other patch is based on this assumption that if OP-TEE
> >>>>>>>>>>>>>>>> support is enabled then the board must be using it, a different approach
> >>>>>>>>>>>>>>>> is definitely needed.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Yeah that's true even with TF-A boot flow, there is possibility to boot
> >>>>>>>>>>>>>>> without OP-TEE as well. However, TF-A generally doesn't provide a
> >>>>>>>>>>>>>>> generic option to detect whether OP-TEE is running or not.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> When I was looking into this last year I remember discussing this same
> >>>>>>>>>>>>>>>> issue from the Linux side, there is a good argument to be made that
> >>>>>>>>>>>>>>>> OP-TEE support in Linux shouldn't be based on the devicetree -
> >>>>>>>>>>>>>>>> particularly in the Qualcomm case where whether or not OP-TEE is used is
> >>>>>>>>>>>>>>>> a simple software change, nothing to do with hardware.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Sadly it's true for every other silicon vendor too. But OP-TEE support
> >>>>>>>>>>>>>>> based on DT has become an ABI unless migration for OP-TEE support based
> >>>>>>>>>>>>>>> on FF-A comes into picture.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> So in general I'm not particularly keen on this approach, I think it
> >>>>>>>>>>>>>>>> /might/ be acceptable for U-Boot to have some fixup code to add the
> >>>>>>>>>>>>>>>> OP-TEE node if OP-TEE is in use with the idea of phasing that out in
> >>>>>>>>>>>>>>>> favour of runtime detection in the OS itself. I'd also expect that fixup
> >>>>>>>>>>>>>>>> code to go in the generic U-Boot DT fixup code that runs before we jump
> >>>>>>>>>>>>>>>> to the OS (like the EFI DT fixup function).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The EFI DT fixup code is already there based on U-Boot DT. Have a look
> >>>>>>>>>>>>>>> here:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> boot/image-fdt.c:627:   fdt_ret = optee_copy_fdt_nodes(blob);
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> In general on Arm platforms there isn't any SMC bus to detect
> >>>>>>>>>>>>>>> dynamically if there is support for OP-TEE or not. That's why
> >>>>>>>>>>>>>>> platform bus was choosen for the U-Boot and Linux OP-TEE driver. It's
> >>>>>>>>>>>>>>> similar to how we have the SCM DT node for Qcom platforms.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> FF-A bus tries to solve that problem to unify that approach for future
> >>>>>>>>>>>>>>> platform but U-Boot hasn't yet gained support for FF-A based OP-TEE
> >>>>>>>>>>>>>>> driver too.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Anyhow, this is the sanest way I can come up with to enable OP-TEE
> >>>>>>>>>>>>>>> support in a general way for all the Qcom platforms. This is aligned
> >>>>>>>>>>>>>>> with how OP-TEE support is detected for other silicon vendors too.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Sumit
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Kind regards,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> For more information refer here:
> >>>>>>>>>>>>>>>>> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>        configs/qcom_tfa_optee_defconfig | 7 +++++++
> >>>>>>>>>>>>>>>>>        1 file changed, 7 insertions(+)
> >>>>>>>>>>>>>>>>>        create mode 100644 configs/qcom_tfa_optee_defconfig
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
> >>>>>>>>>>>>>>>>> new file mode 100644
> >>>>>>>>>>>>>>>>> index 00000000000..c398521770f
> >>>>>>>>>>>>>>>>> --- /dev/null
> >>>>>>>>>>>>>>>>> +++ b/configs/qcom_tfa_optee_defconfig
> >>>>>>>>>>>>>>>>> @@ -0,0 +1,7 @@
> >>>>>>>>>>>>>>>>> +# Configuration for building a generic U-Boot image
> >>>>>>>>>>>>>>>>> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
> >>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>> +#include "qcom_defconfig"
> >>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>> +CONFIG_TEE=y
> >>>>>>>>>>>>>>>>> +CONFIG_OPTEE=y
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -- 
> >>>>>>>>>>>>>>>> // Casey (she/her)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -- 
> >>>>>>>>>>>>>> // Casey (she/her)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> 
> -- 
> // Casey (she/her)
> 

Re: [PATCH 1/2] mach-snapdragon: of_fixup: Add OP-TEE DT fixup support

[neil.armstrong]

On 12/29/25 12:43, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> 
> Add support for OP-TEE live tree DT fixup support which enables U-Boot
> OP-TEE driver to be probed. As well as the EFI DT fixup protocol allows
> the live tree fixup to be carried over to the OS for the OP-TEE driver
> in the OS to probe as well.
> 
> Note that this fixup only gets applied if CONFIG_OPTEE gets enabled.

Can't the presence of OP-TEE be detected dynamically via scm calls ?

Thanks,
Neil

> 
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
>   arch/arm/mach-snapdragon/of_fixup.c | 34 +++++++++++++++++++++++++++++
>   1 file changed, 34 insertions(+)
> 
> diff --git a/arch/arm/mach-snapdragon/of_fixup.c b/arch/arm/mach-snapdragon/of_fixup.c
> index eec2c0c757e..29a99f73cf3 100644
> --- a/arch/arm/mach-snapdragon/of_fixup.c
> +++ b/arch/arm/mach-snapdragon/of_fixup.c
> @@ -146,6 +146,37 @@ static void fixup_power_domains(struct device_node *root)
>   	}
>   }
>   
> +static void add_optee_node(struct device_node *root)
> +{
> +	struct device_node *fw = NULL, *optee = NULL;
> +	int ret;
> +
> +	fw = of_find_node_by_path("/firmware");
> +	if (!fw) {
> +		log_err("Failed to find /firmware node\n");
> +		return;
> +	}
> +
> +	ret = of_add_subnode(fw, "optee", strlen("optee") + 1, &optee);
> +	if (ret) {
> +		log_err("Failed to add 'maximum-speed' property: %d\n", ret);
> +		return;
> +	}
> +
> +	ret = of_write_prop(optee, "compatible", strlen("linaro,optee-tz") + 1,
> +			    "linaro,optee-tz");
> +	if (ret) {
> +		log_err("Failed to optee 'compatible' property: %d\n", ret);
> +		return;
> +	}
> +
> +	ret = of_write_prop(optee, "method", strlen("smc") + 1, "smc");
> +	if (ret) {
> +		log_err("Failed to optee 'method' property: %d\n", ret);
> +		return;
> +	}
> +}
> +
>   #define time_call(func, ...) \
>   	do { \
>   		u64 start = timer_get_us(); \
> @@ -160,6 +191,9 @@ static int qcom_of_fixup_nodes(void * __maybe_unused ctx, struct event *event)
>   	time_call(fixup_usb_nodes, root);
>   	time_call(fixup_power_domains, root);
>   
> +	if (IS_ENABLED(CONFIG_OPTEE))
> +		time_call(add_optee_node, root);
> +
>   	return 0;
>   }
>   

Re: [PATCH 1/2] mach-snapdragon: of_fixup: Add OP-TEE DT fixup support

[Sumit Garg]

On Thu, Jan 08, 2026 at 05:19:32PM +0100, neil.armstrong@linaro.org wrote:
> On 12/29/25 12:43, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > 
> > Add support for OP-TEE live tree DT fixup support which enables U-Boot
> > OP-TEE driver to be probed. As well as the EFI DT fixup protocol allows
> > the live tree fixup to be carried over to the OS for the OP-TEE driver
> > in the OS to probe as well.
> > 
> > Note that this fixup only gets applied if CONFIG_OPTEE gets enabled.
> 
> Can't the presence of OP-TEE be detected dynamically via scm calls ?

SCM calls aren't present in case of TF-A/OP-TEE flow.

-Sumit

> 
> Thanks,
> Neil
> 
> > 
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
> >   arch/arm/mach-snapdragon/of_fixup.c | 34 +++++++++++++++++++++++++++++
> >   1 file changed, 34 insertions(+)
> > 
> > diff --git a/arch/arm/mach-snapdragon/of_fixup.c b/arch/arm/mach-snapdragon/of_fixup.c
> > index eec2c0c757e..29a99f73cf3 100644
> > --- a/arch/arm/mach-snapdragon/of_fixup.c
> > +++ b/arch/arm/mach-snapdragon/of_fixup.c
> > @@ -146,6 +146,37 @@ static void fixup_power_domains(struct device_node *root)
> >   	}
> >   }
> > +static void add_optee_node(struct device_node *root)
> > +{
> > +	struct device_node *fw = NULL, *optee = NULL;
> > +	int ret;
> > +
> > +	fw = of_find_node_by_path("/firmware");
> > +	if (!fw) {
> > +		log_err("Failed to find /firmware node\n");
> > +		return;
> > +	}
> > +
> > +	ret = of_add_subnode(fw, "optee", strlen("optee") + 1, &optee);
> > +	if (ret) {
> > +		log_err("Failed to add 'maximum-speed' property: %d\n", ret);
> > +		return;
> > +	}
> > +
> > +	ret = of_write_prop(optee, "compatible", strlen("linaro,optee-tz") + 1,
> > +			    "linaro,optee-tz");
> > +	if (ret) {
> > +		log_err("Failed to optee 'compatible' property: %d\n", ret);
> > +		return;
> > +	}
> > +
> > +	ret = of_write_prop(optee, "method", strlen("smc") + 1, "smc");
> > +	if (ret) {
> > +		log_err("Failed to optee 'method' property: %d\n", ret);
> > +		return;
> > +	}
> > +}
> > +
> >   #define time_call(func, ...) \
> >   	do { \
> >   		u64 start = timer_get_us(); \
> > @@ -160,6 +191,9 @@ static int qcom_of_fixup_nodes(void * __maybe_unused ctx, struct event *event)
> >   	time_call(fixup_usb_nodes, root);
> >   	time_call(fixup_power_domains, root);
> > +	if (IS_ENABLED(CONFIG_OPTEE))
> > +		time_call(add_optee_node, root);
> > +
> >   	return 0;
> >   }
> 

Re: [PATCH 1/2] mach-snapdragon: of_fixup: Add OP-TEE DT fixup support

[Neil Armstrong]

On 1/9/26 11:24, Sumit Garg wrote:
> On Thu, Jan 08, 2026 at 05:19:32PM +0100, neil.armstrong@linaro.org wrote:
>> On 12/29/25 12:43, Sumit Garg wrote:
>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>
>>> Add support for OP-TEE live tree DT fixup support which enables U-Boot
>>> OP-TEE driver to be probed. As well as the EFI DT fixup protocol allows
>>> the live tree fixup to be carried over to the OS for the OP-TEE driver
>>> in the OS to probe as well.
>>>
>>> Note that this fixup only gets applied if CONFIG_OPTEE gets enabled.
>>
>> Can't the presence of OP-TEE be detected dynamically via scm calls ?
> 
> SCM calls aren't present in case of TF-A/OP-TEE flow.

exact, but SMC calls are.

first thing optee driver does is calling OPTEE_SMC_CALLS_UID:

-> optee_probe()
-> is_optee_api()

Please investigate how this SMC would behave when QSEECOM or QTEE none are
present.

SMC calls are mandatory to be implemented for PSCI, so they should simply
return an error.

Neil

> 
> -Sumit
> 
>>
>> Thanks,
>> Neil
>>
>>>
>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>> ---
>>>    arch/arm/mach-snapdragon/of_fixup.c | 34 +++++++++++++++++++++++++++++
>>>    1 file changed, 34 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-snapdragon/of_fixup.c b/arch/arm/mach-snapdragon/of_fixup.c
>>> index eec2c0c757e..29a99f73cf3 100644
>>> --- a/arch/arm/mach-snapdragon/of_fixup.c
>>> +++ b/arch/arm/mach-snapdragon/of_fixup.c
>>> @@ -146,6 +146,37 @@ static void fixup_power_domains(struct device_node *root)
>>>    	}
>>>    }
>>> +static void add_optee_node(struct device_node *root)
>>> +{
>>> +	struct device_node *fw = NULL, *optee = NULL;
>>> +	int ret;
>>> +
>>> +	fw = of_find_node_by_path("/firmware");
>>> +	if (!fw) {
>>> +		log_err("Failed to find /firmware node\n");
>>> +		return;
>>> +	}
>>> +
>>> +	ret = of_add_subnode(fw, "optee", strlen("optee") + 1, &optee);
>>> +	if (ret) {
>>> +		log_err("Failed to add 'maximum-speed' property: %d\n", ret);
>>> +		return;
>>> +	}
>>> +
>>> +	ret = of_write_prop(optee, "compatible", strlen("linaro,optee-tz") + 1,
>>> +			    "linaro,optee-tz");
>>> +	if (ret) {
>>> +		log_err("Failed to optee 'compatible' property: %d\n", ret);
>>> +		return;
>>> +	}
>>> +
>>> +	ret = of_write_prop(optee, "method", strlen("smc") + 1, "smc");
>>> +	if (ret) {
>>> +		log_err("Failed to optee 'method' property: %d\n", ret);
>>> +		return;
>>> +	}
>>> +}
>>> +
>>>    #define time_call(func, ...) \
>>>    	do { \
>>>    		u64 start = timer_get_us(); \
>>> @@ -160,6 +191,9 @@ static int qcom_of_fixup_nodes(void * __maybe_unused ctx, struct event *event)
>>>    	time_call(fixup_usb_nodes, root);
>>>    	time_call(fixup_power_domains, root);
>>> +	if (IS_ENABLED(CONFIG_OPTEE))
>>> +		time_call(add_optee_node, root);
>>> +
>>>    	return 0;
>>>    }
>>