On Wed, 6 Sep 2017, Kever Yang 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
Adding some documentation to U-Boot that documents the binary interface
with OPTEE would be helpful.
Signed-off-by: Kever Yang <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
---
common/spl/Kconfig | 7 +++++++
common/spl/Makefile | 1 +
common/spl/spl.c | 5 +++++
common/spl/spl_optee.S | 13 +++++++++++++
include/spl.h | 9 +++++++++
5 files changed, 35 insertions(+)
create mode 100644 common/spl/spl_optee.S
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 582b685..85f8d66 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -700,6 +700,13 @@ config SPL_ATF_TEXT_BASE
help
This is the base address in memory for ATF BL31 text and entry point.
+config SPL_OPTEE_SUPPORT
+ bool "Support OP-TEE Trusted OS"
+ depends on ARM
+ help
+ OP-TEE is an open source Trusted OS which is loaded by SPL.
+ More detail at: https://github.com/OP-TEE/optee_os
+
config TPL
bool
depends on SUPPORT_TPL
diff --git a/common/spl/Makefile b/common/spl/Makefile
index fde0d09..ec37428 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_$(SPL_TPL_)UBI) += spl_ubi.o
obj-$(CONFIG_$(SPL_TPL_)NET_SUPPORT) += spl_net.o
obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += spl_mmc.o
obj-$(CONFIG_$(SPL_TPL_)ATF_SUPPORT) += spl_atf.o
+obj-$(CONFIG_$(SPL_TPL_)OPTEE_SUPPORT) += spl_optee.o
obj-$(CONFIG_$(SPL_TPL_)USB_SUPPORT) += spl_usb.o
obj-$(CONFIG_$(SPL_TPL_)FAT_SUPPORT) += spl_fat.o
obj-$(CONFIG_$(SPL_TPL_)EXT_SUPPORT) += spl_ext.o
diff --git a/common/spl/spl.c b/common/spl/spl.c
index d245cfc..6ff390c 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -430,6 +430,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
bl31_entry();
}
+ if (CONFIG_IS_ENABLED(OPTEE_SUPPORT)) {
+ debug("loaded - jumping to U-Boot via OP-TEE.\n");
+ spl_optee_entry(0, 0, 0, (void *)spl_image.entry_point);
+ }
+
Shouldn't the fact that we will boot through the OPTEE tracked through
spl_image->os and shouldn't there be a IH_OS_... constant that indicates
that we are going to jump to an OPTEE? This would allow the above switch
statement to be extended for OPTEE.
debug("loaded - jumping to U-Boot...\n");
#ifdef CONFIG_BOOTSTAGE_STASH
int ret;
diff --git a/common/spl/spl_optee.S b/common/spl/spl_optee.S
new file mode 100644
index 0000000..4f7f8ba
--- /dev/null
+++ b/common/spl/spl_optee.S
@@ -0,0 +1,13 @@
+/*
+ * Copyright (C) 2017 Rockchip Electronic Co.,Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <linux/linkage.h>
+#include <asm/assembler.h>
+
+ENTRY(spl_optee_entry)
+ ldr lr, =CONFIG_SYS_TEXT_BASE
+ mov pc, r3
+ENDPROC(spl_optee_entry)
This looks ARM-specific and shouldn't be in common/spl.
Please note that the next OS image will not always be a CONFIG_SYS_TEXT_BASE.
So the address of the "next image to boot" should be an argument to this
function (we will need to solve this cleanly anyway, as I am currently
trying to address the same issue with booting through ATF where I have an
entry address into the ATF and need to keep track of the next image's
entry address as well).
diff --git a/include/spl.h b/include/spl.h
index ce4cf0a..13d46ed 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -270,6 +270,15 @@ int spl_mmc_load_image(struct spl_image_info *spl_image,
void bl31_entry(void);
/**
+ * spl_optee_entry - entry function for optee
+ * entry arg0, pagestore
+ * entry arg1, (ARMv7 standard bootarg #1)
+ * entry arg2, device tree address, (ARMv7 standard bootarg #2)
+ * entry arg3, non-secure entry address (ARMv7 bootarg #0)
+ */
+void spl_optee_entry(void *arg0, void *arg1, void *arg2, void *arg3);
+
+/**
* board_return_to_bootrom - allow for boards to continue with the boot ROM
*
* If a board (e.g. the Rockchip RK3368 boards) provide some
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
