On 12/01/18 11:27, Philipp Tomsich wrote:
OP-TEE is an open source trusted OS, in armv7, its loading and
running are like this:
loading:
- SPL load both OP-TEE and U-Boot
running:
- SPL run into OP-TEE in secure mode;
- OP-TEE run into U-Boot in non-secure mode;
More detail:
https://github.com/OP-TEE/optee_os
and search for 'boot arguments' for detail entry parameter in:
core/arch/arm/kernel/generic_entry_a32.S
Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
---
Changes in v4:
- use NULL instead of '0'
- add fdt_addr as arg2 of entry
Changes in v3: None
Changes in v2:
- Using new image type for op-tee
common/spl/Kconfig | 7 +++++++
common/spl/Makefile | 1 +
common/spl/spl.c | 9 +++++++++
common/spl/spl_optee.S | 13 +++++++++++++
include/spl.h | 13 +++++++++++++
5 files changed, 43 insertions(+)
create mode 100644 common/spl/spl_optee.S
Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Kever, Philipp
I have patches that define a IH_TYPE_OPTEE as a bootable OPTEE image
(one that never returns to u-boot).
The image type allows bootm to identify the type of binary it is booting
and perform image-specific checks.
On this patch though, do you guys really need a new image type for SPL ?
Couldn't you use IH_TYPE_TEE in the same way ?
+#if CONFIG_IS_ENABLED(OPTEE)
+ case IH_TYPE_TEE:
+ debug("Jumping to U-Boot via OP-TEE\n");
+ spl_optee_entry(NULL, NULL, spl_image->fdt_addr,
+ (void *)spl_image.entry_point);
+ break;
+#endif
i.e. it appears to me as if you don't actually do anything
image-specific with IH_OS_OP_TEE that couldn't be done with the existing
IH_TYPE_TEE... as above you use spl_image->fdt_addr and
spl_image.entry_point - as opposed to any header specific data from the
binary you are booting..
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
