Re: [PATCH] arm64: dts: imx8m: Reinstate TEE ifdeffery

[Yannic Moog <Y.Moog@phytec.de>]

On Fri, 2026-07-03 at 00:25 +0200, Marek Vasut wrote:
> On 7/2/26 9:04 AM, Yannic Moog wrote:
> 
> Hello Yannic,
> 
> > On Tue, 2026-06-30 at 18:08 +0200, Marek Vasut wrote:
> > > Since b57ed147939c ("dts: imx8m{m,n,p,q}: Make optee packaging optional")
> > > the TEE node is always present in U-Boot proper fitImage, even if the
> > > CONFIG_OPTEE is disabled because the u-boot.itb should not contain any
> > > tee.bin. This is wasteful, and produces the following warning which is
> > > also confusing to users:
> > > 
> > > "
> > > Image 'image' is missing optional external blobs but is still functional: tee-os
> > > 
> > > /binman/section/fit/images/tee/tee-os (tee.bin):
> > >     See the documentation for your board. You may need to build Open Portable
> > >     Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
> > > "
> > > 
> > > Reinstate the CONFIG_OPTEE ifdeffery to mitigate the problem, but retain the
> > > binman "optional" keyword at tee.bin .
> > 
> > I disagree. You are removing a feature and cause further problems with this commit.
> 
> I tried to avoid outright reverting the offending commit b57ed147939c 
> ("dts: imx8m{m,n,p,q}: Make optee packaging optional") which introduced 
> the problem I described above.
> 
> > Your initial assumption
> > 
> > > even if the
> > > CONFIG_OPTEE is disabled because the u-boot.itb should not contain any
> > > tee.bin
> > 
> > is not accurate. You were able to package OP-TEE without needing to enable support in U-Boot.
> > And
> > afaik this is a perfectly valid use-case.
> 
> When you include optee-os in the U-Boot fitImage, what do you do with 
> that optee-os which U-Boot does not support ? Details please ?

Sure, sorry. OS can/will use it. There is no requirement, that I know, of any bootloader
interfacing with OP-TEE for proper functionality and its purpose is to work with Linux kernel.
I guess the only job bootloader needs to do is load it into memory. I don't know details about
specific uses within the security context and if there are any that require bootloader support.

> 
> > With this change you can no longer do that, so this change is a regression.
> > 
> > About the warning message. I understand that you find it confusing; binman is designed so that
> > it
> > emits a warning when an optional blob is not found.
> 
> Please see above.
> 
> > I prefer that approach to no message at all. You may want to package OP-TEE (e.g. you have an
> > tf-a
> > blob which jumps to OP-TEE addr) and being alerted to a possible mistake is important; Let's
> > say
> > tee path was incorrect during build.
> 
> Is this some sort of a board-specific configuration ?

kind of. We have tee path set in <soc>-u-boot.dtsi: filename = "tee.bin";

Could happen that TEE=teee.bin is set or file is named tee-raw.bin and then it helps to get a
warning that binman was not able to package the blob.

> 
> Why does U-Boot not enable OPTEE-OS support in this case ?

No need to. Maybe to conserve space, or by principle only enable the configs that are actually
needed? I believe PHYTEC boards used to do that before KASLR support.

> 
> > Also, keeping optional when using if defs is not a good idea. Binman will still build you an
> > image
> > when no OP-TEE blob is present, but should not since you enabled OPTEE configs. If you enable
> > OPTEE, you should have an OP-TEE blob packaged.
> > We could add ifndef OPTEE around the optional property.
> 
> The optional keyword is actually kept in this case, it is not a full revert.
> 
> You did however miss one vital point -- the tee node is part of the 
> U-boot fitImage, even if the tee.bin binary is not present and OPTEE 
> support in U-Boot is disabled. Binman prints a confusing message, and 
> generates a bogus empty tee {} node in the fitImage. That is incorrect.

Yes, forgot to address that. I don't think it is confusing, at least content wise. Visually, I can
see how that is confusing. I want to neither agree nor disagree on the correctness part because I
don't really know the fitImage spec. Having the tee node be part of the fitImage is a design
choice, all optional blobs behave that way from my understanding.
I guess it means that there is a bug in binman if you say having empty tee node is incorrect.
And so it should be fixed in binman itself imo, not here for imx8.

Yannic