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