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