Hi Chris,
On 2/3/25 10:27 PM, Chris Morgan wrote:
On Mon, Feb 03, 2025 at 05:32:53PM +0100, Quentin Schulz wrote:
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:
Hi Chris,
On 1/30/25 7:10 PM, Chris Morgan wrote:
[...]
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.
I honestly would just rather remove this node. The reason I say that is
while we support Optee with the RK3399, RK3228, the PX30, and the
RK3588; howver only the RK3588 has the node already populated in Linux.
And we have a product based on PX30 that has OP-TEE OS running without a
hardcoded node in the DTS, so that's a valid point of comparison to me.
That seems to justify the deletion to me!
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?
We would have to assume some hard coded values in that event as I'm not
aware of a mechanism to grab them at runtime from Optee except when you
pass it a device tree. That said I think the concern above where you
Yes, but that would be the same as BL31 for example and an expected side
effect of using CONFIG_SPL_ATF_NO_PLATFORM_PARAM except if there's a way
to provide information back from TEE to U-Boot without using the params
that would be passed by U-Boot to TF-A had we
CONFIG_SPL_ATF_NO_PLATFORM_PARAM disabled.
mention "guaranteed to be stable forever" is the problem, as even now
the current address in the Optee upstream project conflicts with the
kernel_comp_addr_r in upstream U-Boot, necessesitating one of them be
changed (I'm attempting to change the Optee one, for what it's worth).
I think it makes more sense to change the load addresses in U-Boot,
especially since those are just the default values for variables which
are configurable per board type, per board or even per boot, so it's
something one would be able to modify without necessarily rebuilding
anything. Essentially, it's easier to move that around than checking
which OP-TEE OS version one is booting before providing advice on where
to load the image? Up to you though, no strong opinion there.
Cheers,
Quentin
