[PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

Neil Armstrong neil.armstrong at linaro.org
Fri Jan 16 10:53:15 CET 2026 

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

More information about the U-Boot mailing list