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

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

[Marek Vasut]

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 .

Before:
"
$ mkimage -l u-boot.itb
FIT description: Configuration to load ATF before U-Boot
Created:         Tue Jun 30 17:23:54 2026
 Image 0 (uboot)
...
 Image 2 (tee) <------------------------------ bogus empty image entry
  Description:  OP-TEE                                 |
  Created:      Tue Jun 30 17:23:54 2026               |
  Type:         Trusted Execution Environment Image    |
  Compression:  uncompressed                           |
  Data Size:    0 Bytes = 0.00 KiB = 0.00 MiB <--------'
 Image 3 (fdt-1)
...
"

After:
"
$ mkimage -l u-boot.itb
FIT description: Configuration to load ATF before U-Boot
Created:         Tue Jun 30 17:58:15 2026
 Image 0 (uboot)
...
 Image 1 (atf)
...
 Image 2 (fdt-1)
...
"

Fixes: b57ed147939c ("dts: imx8m{m,n,p,q}: Make optee packaging optional")
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: "NXP i.MX U-Boot Team" <uboot-imx@nxp.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@nabladev.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Yannic Moog <y.moog@phytec.de>
Cc: Ye Li <ye.li@nxp.com>
Cc: u-boot@lists.denx.de
---
 arch/arm/dts/imx8mm-u-boot.dtsi | 6 ++++++
 arch/arm/dts/imx8mn-u-boot.dtsi | 6 ++++++
 arch/arm/dts/imx8mp-u-boot.dtsi | 6 ++++++
 arch/arm/dts/imx8mq-u-boot.dtsi | 6 ++++++
 4 files changed, 24 insertions(+)

diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
index ab135fc8a47..56ab70e54ea 100644
--- a/arch/arm/dts/imx8mm-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-u-boot.dtsi
@@ -165,6 +165,7 @@
 					};
 #endif
 
+#ifdef CONFIG_OPTEE
 					tee: tee {
 						description = "OP-TEE";
 						type = "tee";
@@ -179,6 +180,7 @@
 							optional;
 						};
 					};
+#endif
 
 					binman_fip: fip {
 						arch = "arm64";
@@ -208,7 +210,11 @@
 						fdt = "fdt-SEQ";
 						firmware = "uboot";
 #ifndef CONFIG_ARMV8_PSCI
+#ifdef CONFIG_OPTEE
 						loadables = "atf", "tee";
+#else
+						loadables = "atf";
+#endif
 #endif
 					};
 				};
diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
index 8993605af3c..e4918bf5975 100644
--- a/arch/arm/dts/imx8mn-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-u-boot.dtsi
@@ -241,6 +241,7 @@
 					};
 #endif
 
+#ifdef CONFIG_OPTEE
 					tee: tee {
 						description = "OP-TEE";
 						type = "tee";
@@ -255,6 +256,7 @@
 							optional;
 						};
 					};
+#endif
 
 					binman_fip: fip {
 						arch = "arm64";
@@ -284,7 +286,11 @@
 						fdt = "fdt-SEQ";
 						firmware = "uboot";
 #ifndef CONFIG_ARMV8_PSCI
+#ifdef CONFIG_OPTEE
 						loadables = "atf", "tee";
+#else
+						loadables = "atf";
+#endif
 #endif
 					};
 				};
diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi
index d9d220c70db..58b6863f003 100644
--- a/arch/arm/dts/imx8mp-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-u-boot.dtsi
@@ -189,6 +189,7 @@
 					};
 #endif
 
+#ifdef CONFIG_OPTEE
 					tee: tee {
 						description = "OP-TEE";
 						type = "tee";
@@ -203,6 +204,7 @@
 							optional;
 						};
 					};
+#endif
 
 					@fdt-SEQ {
 						description = "NAME";
@@ -223,7 +225,11 @@
 						fdt = "fdt-SEQ";
 						firmware = "uboot";
 #ifndef CONFIG_ARMV8_PSCI
+#ifdef CONFIG_OPTEE
 						loadables = "atf", "tee";
+#else
+						loadables = "atf";
+#endif
 #endif
 					};
 				};
diff --git a/arch/arm/dts/imx8mq-u-boot.dtsi b/arch/arm/dts/imx8mq-u-boot.dtsi
index ed2c704f2e5..2f9b4a504c3 100644
--- a/arch/arm/dts/imx8mq-u-boot.dtsi
+++ b/arch/arm/dts/imx8mq-u-boot.dtsi
@@ -173,6 +173,7 @@
 				};
 #endif
 
+#ifdef CONFIG_OPTEE
 				tee: tee {
 					description = "OP-TEE";
 					type = "tee";
@@ -187,6 +188,7 @@
 						optional;
 					};
 				};
+#endif
 
 				fdt {
 					compression = "none";
@@ -208,7 +210,11 @@
 					fdt = "fdt";
 					firmware = "uboot";
 #ifndef CONFIG_ARMV8_PSCI
+#ifdef CONFIG_OPTEE
 					loadables = "atf", "tee";
+#else
+					loadables = "atf";
+#endif
 #endif
 				};
 			};
-- 
2.53.0

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

[Peng Fan]

On Tue, Jun 30, 2026 at 06:08:56PM +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 .
>
>Before:
>"
>$ mkimage -l u-boot.itb
>FIT description: Configuration to load ATF before U-Boot
>Created:         Tue Jun 30 17:23:54 2026
> Image 0 (uboot)
>...
> Image 2 (tee) <------------------------------ bogus empty image entry
>  Description:  OP-TEE                                 |
>  Created:      Tue Jun 30 17:23:54 2026               |
>  Type:         Trusted Execution Environment Image    |
>  Compression:  uncompressed                           |
>  Data Size:    0 Bytes = 0.00 KiB = 0.00 MiB <--------'
> Image 3 (fdt-1)
>...
>"
>
>After:
>"
>$ mkimage -l u-boot.itb
>FIT description: Configuration to load ATF before U-Boot
>Created:         Tue Jun 30 17:58:15 2026
> Image 0 (uboot)
>...
> Image 1 (atf)
>...
> Image 2 (fdt-1)
>...
>"
>
>Fixes: b57ed147939c ("dts: imx8m{m,n,p,q}: Make optee packaging optional")
>Signed-off-by: Marek Vasut <marex@nabladev.com>


Reviewed-by: Peng Fan <peng.fan@nxp.com>

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

[Yannic Moog]

Hi Marek,

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.

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

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.

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.

Yannic

> 
> Before:
> "
> $ mkimage -l u-boot.itb
> FIT description: Configuration to load ATF before U-Boot
> Created:         Tue Jun 30 17:23:54 2026
>  Image 0 (uboot)
> ...
>  Image 2 (tee) <------------------------------ bogus empty image entry
>   Description:  OP-TEE                                 |
>   Created:      Tue Jun 30 17:23:54 2026               |
>   Type:         Trusted Execution Environment Image    |
>   Compression:  uncompressed                           |
>   Data Size:    0 Bytes = 0.00 KiB = 0.00 MiB <--------'
>  Image 3 (fdt-1)
> ...
> "
> 
> After:
> "
> $ mkimage -l u-boot.itb
> FIT description: Configuration to load ATF before U-Boot
> Created:         Tue Jun 30 17:58:15 2026
>  Image 0 (uboot)
> ...
>  Image 1 (atf)
> ...
>  Image 2 (fdt-1)
> ...
> "
> 
> Fixes: b57ed147939c ("dts: imx8m{m,n,p,q}: Make optee packaging optional")
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: "NXP i.MX U-Boot Team" <uboot-imx@nxp.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Peng Fan <peng.fan@nxp.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Stefano Babic <sbabic@nabladev.com>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: Yannic Moog <y.moog@phytec.de>
> Cc: Ye Li <ye.li@nxp.com>
> Cc: u-boot@lists.denx.de
> ---
>  arch/arm/dts/imx8mm-u-boot.dtsi | 6 ++++++
>  arch/arm/dts/imx8mn-u-boot.dtsi | 6 ++++++
>  arch/arm/dts/imx8mp-u-boot.dtsi | 6 ++++++
>  arch/arm/dts/imx8mq-u-boot.dtsi | 6 ++++++
>  4 files changed, 24 insertions(+)
> 
> diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
> index ab135fc8a47..56ab70e54ea 100644
> --- a/arch/arm/dts/imx8mm-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-u-boot.dtsi
> @@ -165,6 +165,7 @@
>  					};
>  #endif
>  
> +#ifdef CONFIG_OPTEE
>  					tee: tee {
>  						description = "OP-TEE";
>  						type = "tee";
> @@ -179,6 +180,7 @@
>  							optional;
>  						};
>  					};
> +#endif
>  
>  					binman_fip: fip {
>  						arch = "arm64";
> @@ -208,7 +210,11 @@
>  						fdt = "fdt-SEQ";
>  						firmware = "uboot";
>  #ifndef CONFIG_ARMV8_PSCI
> +#ifdef CONFIG_OPTEE
>  						loadables = "atf", "tee";
> +#else
> +						loadables = "atf";
> +#endif
>  #endif
>  					};
>  				};
> diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
> index 8993605af3c..e4918bf5975 100644
> --- a/arch/arm/dts/imx8mn-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mn-u-boot.dtsi
> @@ -241,6 +241,7 @@
>  					};
>  #endif
>  
> +#ifdef CONFIG_OPTEE
>  					tee: tee {
>  						description = "OP-TEE";
>  						type = "tee";
> @@ -255,6 +256,7 @@
>  							optional;
>  						};
>  					};
> +#endif
>  
>  					binman_fip: fip {
>  						arch = "arm64";
> @@ -284,7 +286,11 @@
>  						fdt = "fdt-SEQ";
>  						firmware = "uboot";
>  #ifndef CONFIG_ARMV8_PSCI
> +#ifdef CONFIG_OPTEE
>  						loadables = "atf", "tee";
> +#else
> +						loadables = "atf";
> +#endif
>  #endif
>  					};
>  				};
> diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi
> index d9d220c70db..58b6863f003 100644
> --- a/arch/arm/dts/imx8mp-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-u-boot.dtsi
> @@ -189,6 +189,7 @@
>  					};
>  #endif
>  
> +#ifdef CONFIG_OPTEE
>  					tee: tee {
>  						description = "OP-TEE";
>  						type = "tee";
> @@ -203,6 +204,7 @@
>  							optional;
>  						};
>  					};
> +#endif
>  
>  					@fdt-SEQ {
>  						description = "NAME";
> @@ -223,7 +225,11 @@
>  						fdt = "fdt-SEQ";
>  						firmware = "uboot";
>  #ifndef CONFIG_ARMV8_PSCI
> +#ifdef CONFIG_OPTEE
>  						loadables = "atf", "tee";
> +#else
> +						loadables = "atf";
> +#endif
>  #endif
>  					};
>  				};
> diff --git a/arch/arm/dts/imx8mq-u-boot.dtsi b/arch/arm/dts/imx8mq-u-boot.dtsi
> index ed2c704f2e5..2f9b4a504c3 100644
> --- a/arch/arm/dts/imx8mq-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-u-boot.dtsi
> @@ -173,6 +173,7 @@
>  				};
>  #endif
>  
> +#ifdef CONFIG_OPTEE
>  				tee: tee {
>  					description = "OP-TEE";
>  					type = "tee";
> @@ -187,6 +188,7 @@
>  						optional;
>  					};
>  				};
> +#endif
>  
>  				fdt {
>  					compression = "none";
> @@ -208,7 +210,11 @@
>  					fdt = "fdt";
>  					firmware = "uboot";
>  #ifndef CONFIG_ARMV8_PSCI
> +#ifdef CONFIG_OPTEE
>  					loadables = "atf", "tee";
> +#else
> +					loadables = "atf";
> +#endif
>  #endif
>  				};
>  			};

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

[Marek Vasut]

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 ?

> 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 ?

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

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

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

[Yannic Moog]

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

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

[Marek Vasut]

On 7/3/26 8:16 AM, Yannic Moog wrote:

Hello Yannic,

[...]

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

At minimum, if CONFIG_OPTEE is not enabled, U-Boot won't execute 
optee_copy_fdt_nodes() and won't transfer any optee-os firmware and 
reserved-memory DT nodes to the Linux DT when starting the kernel, so 
Linux DT will be buggy and Linux may possibly misbehave.

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

If in your use case, U-Boot is supposed to only load optee-os into 
memory , why not load it from U-Boot command line or as part of fitImage 
when booting Linux kernel ?

It seems in your use case, optee-os does not have to be part of the 
bootloader image at all ?

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

This does not seem correct, please see above.

At this point, I would suggest that if you want to retain this kind of 
configuration for your hardware, it should be moved into board specific 
DT, it should not be part of the common DTs.

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

It is a broken node introduced by commit b57ed147939c ("dts: 
imx8m{m,n,p,q}: Make optee packaging optional") , it is not supposed to 
be part of the fitImage unless optee-os is bundled into the fitImage.

> 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.
No, this is not a bug in binman, please see above.

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

[Yannic Moog]

Hey Marek,

On Sat, 2026-07-04 at 22:13 +0200, Marek Vasut wrote:
> On 7/3/26 8:16 AM, Yannic Moog wrote:
> 
> Hello Yannic,
> 
> [...]
> 
> > > > 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.
> 
> At minimum, if CONFIG_OPTEE is not enabled, U-Boot won't execute 
> optee_copy_fdt_nodes() and won't transfer any optee-os firmware and 
> reserved-memory DT nodes to the Linux DT when starting the kernel, so 
> Linux DT will be buggy and Linux may possibly misbehave.

Got it. I tested your theory and with all TEE configs off and OP-TEE packaged, kernel device tree
still has the necessary device tree nodes. Is there something I missed (am using phycore-imx8mp
board) ? How does your Linux dtb look like in that scenario?

> 
> > 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.
> 
> If in your use case, U-Boot is supposed to only load optee-os into 
> memory , why not load it from U-Boot command line or as part of fitImage 
> when booting Linux kernel ?

I figured via the u-boot.dtsi is the easiest solution.

> 
> It seems in your use case, optee-os does not have to be part of the 
> bootloader image at all ?

I believe it does. The init phase looks the following (on imx8m)

ROM -> U-Boot SPL -> tf-a -> OP-TEE -> tf-a -> U-boot proper

and something has to load OP-TEE into main memory when tf-a is done with init and jumps to the
OPTEE load addr. That's what U-Boot does.

> 
> > > > 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.
> 
> This does not seem correct, please see above.
> 
> At this point, I would suggest that if you want to retain this kind of 
> configuration for your hardware, it should be moved into board specific 
> DT, it should not be part of the common DTs.
> 
> > > > 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.
> 
> It is a broken node introduced by commit b57ed147939c ("dts: 
> imx8m{m,n,p,q}: Make optee packaging optional") , it is not supposed to 
> be part of the fitImage unless optee-os is bundled into the fitImage.

This I still do not understand how you come to the conclusion that it (tee node) is not supposed to
be part of the fitImage. Can you point me to the doc that disallows this?


> 
> > 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.
> No, this is not a bug in binman, please see above.

Also, assuming that it is indeed illegal: Binman looks at an external blob and does not remove the
parent node when it is the only child and found to be missing.
Can you please clarify what should happen when no tee blob could be found and packaged?
I am asking because you wanted to keep the optional property which will cause us to end up in the
same situation you said is illegal: Having the tee node in the fitImage but no tee blob.

Yannic

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

[Marek Vasut]

On 7/6/26 2:36 PM, Yannic Moog wrote:

Hello Yannic,

>>>> 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.
>>
>> At minimum, if CONFIG_OPTEE is not enabled, U-Boot won't execute
>> optee_copy_fdt_nodes() and won't transfer any optee-os firmware and
>> reserved-memory DT nodes to the Linux DT when starting the kernel, so
>> Linux DT will be buggy and Linux may possibly misbehave.
> 
> Got it. I tested your theory and with all TEE configs off and OP-TEE packaged, kernel device tree
> still has the necessary device tree nodes. Is there something I missed (am using phycore-imx8mp
> board) ? How does your Linux dtb look like in that scenario?

I cannot answer this question, the test you performed is not well 
documented -- kernel version is unknown, whether the kernel was in any 
way modified is also unknown, etc. Maybe your kernel tree already 
contains some optee-os node ?

>>> 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.
>>
>> If in your use case, U-Boot is supposed to only load optee-os into
>> memory , why not load it from U-Boot command line or as part of fitImage
>> when booting Linux kernel ?
> 
> I figured via the u-boot.dtsi is the easiest solution.
> 
>>
>> It seems in your use case, optee-os does not have to be part of the
>> bootloader image at all ?
> 
> I believe it does. The init phase looks the following (on imx8m)
> 
> ROM -> U-Boot SPL -> tf-a -> OP-TEE -> tf-a -> U-boot proper
> 
> and something has to load OP-TEE into main memory when tf-a is done with init and jumps to the
> OPTEE load addr. That's what U-Boot does.

In that case, U-Boot should be aware of that optee-os , i.e. enable 
CONFIG_OPTEE .

[...]

>>>>> 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.
>>
>> It is a broken node introduced by commit b57ed147939c ("dts:
>> imx8m{m,n,p,q}: Make optee packaging optional") , it is not supposed to
>> be part of the fitImage unless optee-os is bundled into the fitImage.
> 
> This I still do not understand how you come to the conclusion that it (tee node) is not supposed to
> be part of the fitImage. Can you point me to the doc that disallows this?

The empty tee node is dead code, that is why it should not be in the 
fitImage. Before b57ed147939c ("dts: imx8m{m,n,p,q}: Make optee 
packaging optional") that tee node was correctly not part of the 
fitImage unless explicitly configured in by the user (CONFIG_OPTEE=y).

>>> 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.
>> No, this is not a bug in binman, please see above.
> 
> Also, assuming that it is indeed illegal: Binman looks at an external blob and does not remove the
> parent node when it is the only child and found to be missing.
> Can you please clarify what should happen when no tee blob could be found and packaged?

In case of CONFIG_OPTEE=y and "optional" keyword and missing tee.bin 
blob , I think the node should be retained, because the user might 
inject tee.bin into the u-boot.itb after the build with some "mkimage -F 
..." invocation.

In case of CONFIG_OPTEE=n , there should be no tee node.

> I am asking because you wanted to keep the optional property which will cause us to end up in the
> same situation you said is illegal: Having the tee node in the fitImage but no tee blob.
Please see above.