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, [email protected] 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 <[email protected]>
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/[email protected]/
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 <[email protected]>
---
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)
