Hi Chris,

On 1/31/25 5:59 PM, Chris Morgan wrote:

On Fri, Jan 31, 2025 at 05:46:20PM +0100, Quentin Schulz wrote:

quoted

Hi Chris,

On 1/30/25 7:10 PM, Chris Morgan wrote:

[...]

quoted

quoted

When Optee is not present or used, the node will trigger a probe
that generates a (harmless) message on the kernel log.

And what if we have OP-TEE without this node present, which would be
possible if we have CONFIG_SPL_ATF_NO_PLATFORM_PARAM set in U-Boot?

I guess we could detect from U-Boot if a TEE is loaded as part of u-boot.itb
and fixup the DTB otherwise to mark this node as status = "disabled"?

Based on my understanding of how each of these projects communicate
with each other, Optee can only work if you either include both the
Optee node in the firmware AND the reserved memory nodes yourself, or
if you have neither and let U-Boot do it (by including each of these
patches as well as setting the CONFIG_SPL_ATF_NO_PLATFORM_PARAM). So
basically just this node alone is insufficient for it to work today.

Therefore I think we should either have this node defined + the 
reserved-memory node (with hardcoded address and size if guaranteed to 
be stable forever) added or nothing.

Can we mark a reserved-memory node as "disabled"? If not, then we should 
rather have nothing at all I believe.

The core issue is that Optee requires you to map the memory as
reserved so that Linux doesn't try to use it. You can either do that
yourself or you can have U-Boot do it automatically. Having the Optee
node in the devicetree makes no sense today unless we also carve out
the memory.

We should patch U-boot to add these nodes to the DT if an OP-TEE OS is 
passed and either SPL_ATF_NO_PLATFORM_PARAM=y or we cannot detect the 
OP-TEE nodes in the kernel DT. What do you think?

Cheers,
Quentin