Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig

Sumit Garg
2026-01-21T11:31:11Z

On Wed, Jan 21, 2026 at 11:38:52AM +0100, Casey Connolly wrote:
>
>
> 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.
>

See existing usage of CONFIG_OPTEE for DT fixups here [1] [2] [3].

[1] https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/imx8mm-u-boot.dtsi#L10
[2] https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/imx8mn-u-boot.dtsi#L10
[3] https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/imx8mp-u-boot.dtsi#L11

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

I don't think the unique elf format is used on Chromebook, right?

>
> >
> > 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"?

I would like you to refer to SMC calling conventions here [4].
OPTEE_GET_OS_UUID falls in the range of Trusted OS specific SMC call.
Each trusted OS can choose the Owning Entity Number from 50-63 as per
SMC calling convention.

Calling random SMC calls isn't a good idea until you know that those SMC
calls are properly handled by the TZ entity. The whole reason why OP-TEE
driver works on DT based probing is this reason only. Otherwise why
would we need DT based probing in the first place for OP-TEE in case you
can rely on the OP-TEE SMC calls being properly handled on every
platform. IOW, there isn't a reliable SMC bus based OP-TEE driver probe.

I will defer to Jens to give further historical background here too.

[4] https://developer.arm.com/documentation/den0028/gb/?lang=en

>
> >
> >> 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?

Sure, lets schedule a call to close on this discussion. I know we are
already going in loops. Would you prefer a zoom call?

-Sumit

>
> 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, neil.armstrong@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@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.
> >>>
> >>> 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 <sumit.garg@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)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
>
> --
> // Casey (she/her)
>