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