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