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
