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