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. > > > 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 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). Thank you, Chris > Cheers, > Quentin
