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, [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.
>>>
>>> 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 <[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)
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
--
// Casey (she/her)
