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