diff options
author | Heiko Stuebner <heiko.stuebner@theobroma-systems.com> | 2019-10-23 16:46:40 +0200 |
---|---|---|
committer | Simon Glass <sjg@chromium.org> | 2019-11-14 07:09:34 -0600 |
commit | 6ccb05eae01b660b0585accf338302af1069f419 (patch) | |
tree | 19f20b96462bff2528bef0e675bdc8080242ab8f /test/optee/test-optee-base.dts | |
parent | 357d2ceba0354e29462ac25924f5e42623c22b5b (diff) |
image: fdt: copy possible optee nodes to a loaded devicetree
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>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Diffstat (limited to 'test/optee/test-optee-base.dts')
0 files changed, 0 insertions, 0 deletions