From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick DELAUNAY Date: Wed, 23 Oct 2019 07:10:52 +0000 Subject: [U-Boot] [PATCH v2 3/4] image: fdt: copy possible optee nodes to a loaded devicetree In-Reply-To: <20191023064612.GA29514@jax> References: <20191022190428.14868-1-heiko@sntech.de> <20191022190428.14868-3-heiko@sntech.de> <20191023064612.GA29514@jax> Message-ID: <63f403a89e2f4af58c833394c65f0134@SFHDAG6NODE3.st.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Jens and Heiko, > From: U-Boot On Behalf Of Jens Wiklander > Sent: mercredi 23 octobre 2019 08:46 > > On Tue, Oct 22, 2019 at 09:04:27PM +0200, Heiko Stuebner wrote: > > From: Heiko Stuebner > > > > The loading convention for optee or any other tee on arm64 is as bl32 > > parameter to the trusted-firmware. So TF-A gets invoked with the TEE > > as > > bl32 and main u-boot as bl33. Once it has done its startup TF-A jumps > > into the bl32 for the TEE startup, returns to TF-A and then jumps to bl33. > > > > All of them get passed a devicetree as parameter and all components > > often get loaded from a FIT image. > > > > OP-TEE will create additional nodes in that devicetree namely a > > firmware node and possibly multiple reserved-memory nodes. > > > > While this devicetree is used in main u-boot, in most cases it won't > > be the one passed to the actual kernel. Instead most boot commands > > will load a new devicetree from somewhere like mass storage of the > > network, so if that happens u-boot should transfer the optee nodes to that new > devicetree. > > > > To make that happen introduce optee_copy_fdt_nodes() called from the > > dt setup function in image-fdt which after checking for the optee > > presence in the u-boot dt will make sure a optee node is present in > > the kernel dt and transfer any reserved-memory regions it can find. > > > > Signed-off-by: Heiko Stuebner > > --- > > changes in v2: > > - don't create a new optee firmware-node, but instead copy the > > compatible+method properties from the old fdt blob. > > > > common/image-fdt.c | 8 +++ > > include/tee/optee.h | 9 +++ > > lib/optee/optee.c | 132 ++++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 149 insertions(+) > > > [snip] On STM32MP1 platform (armv7 with TF-A support), we can use BL32 = OP-TEE or spmin provide by TF-A So we are plan to have the same type of feature but with an inversed logical: - Op-Tee nodes (firmwares and reserved) are present in kernel device tree - U-Boot deactivated these nodes when TEE is not present, with the next function called in ft_system_setup: static void stm32_fdt_disable_optee(void *blob) { int off, node; off = fdt_node_offset_by_compatible(blob, -1, "linaro,optee-tz"); if (off >= 0 && fdtdec_get_is_enabled(blob, off)) fdt_status_disabled(blob, off); /* Disabled "optee at ..." reserved-memory node */ off = fdt_path_offset(blob, "/reserved-memory/"); if (off < 0) return; for (node = fdt_first_subnode(blob, off); node >= 0; node = fdt_next_subnode(blob, node)) { if (!strncmp(fdt_get_name(blob, node, NULL), "optee@", 6)) fdt_status_disabled(blob, node); } } What is the better for you ? 1/ Copy the U-Boot op-tee nodes in kernel device tree (where op-tee nodes was present) or 2/ Deactivate the op-tee nodes in kernel device tree (where op-tee nodes are present) The advantage of us is to upstream a Linux Kernel device tree with the correct op-tee nodes... Regards > Looks good to me: > Reviewed-by: Jens Wiklander > > Cheers, > Jens Patrick