From: Jens Wiklander <jens.wiklander@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/4] image: fdt: copy possible optee nodes to a loaded devicetree
Date: Wed, 23 Oct 2019 08:46:13 +0200 [thread overview]
Message-ID: <20191023064612.GA29514@jax> (raw)
In-Reply-To: <20191022190428.14868-3-heiko@sntech.de>
On Tue, Oct 22, 2019 at 09:04:27PM +0200, Heiko Stuebner wrote:
> From: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
>
> 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 <heiko.stuebner@theobroma-systems.com>
> ---
> 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]
Looks good to me:
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Cheers,
Jens
next prev parent reply other threads:[~2019-10-23 6:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-22 19:04 [U-Boot] [PATCH v2 1/4] fdtdec: protect against another NULL phandlep in fdtdec_add_reserved_memory() Heiko Stuebner
2019-10-22 19:04 ` [U-Boot] [PATCH v2 2/4] fdtdec: only create phandle if caller wants it " Heiko Stuebner
2019-10-30 1:48 ` Simon Glass
2019-10-22 19:04 ` [U-Boot] [PATCH v2 3/4] image: fdt: copy possible optee nodes to a loaded devicetree Heiko Stuebner
2019-10-23 6:46 ` Jens Wiklander [this message]
2019-10-23 7:10 ` Patrick DELAUNAY
2019-10-23 8:32 ` Heiko Stübner
2019-10-23 15:53 ` Patrick DELAUNAY
2019-10-22 19:04 ` [U-Boot] [PATCH v2 4/4] tests: add OP-TEE test suite Heiko Stuebner
2019-10-30 1:48 ` Simon Glass
2019-10-30 1:48 ` [U-Boot] [PATCH v2 1/4] fdtdec: protect against another NULL phandlep in fdtdec_add_reserved_memory() Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191023064612.GA29514@jax \
--to=jens.wiklander@linaro.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.