[U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229

[U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229

[Kever Yang]

Add some generic options for TPL support for arm 32bit, and then
and TPL support for rk3229(cortex-A7), and then add OPTEE support
in SPL.

Tested on latest u-boot-rockchip master.


Changes in v4:
- remove non-used MACRO define
- use NULL instead of '0'
- add fdt_addr as arg2 of entry

Changes in v3:
- do not init ddr region in spl

Changes in v2:
- update subject with ARCH_MEM info
- Add new image type like ATF
- Using new image type for op-tee
- Make the its as common file used for all armv7 with op-tee
- update defconfig option

Kever Yang (11):
  lib: add TPL_OF_LIBFDT option for TPL
  arm: add option for TPL ARCH_MEM in arm 32bit
  arm: add a separate stack for TPL
  rockchip: rk322x: enable tpl support
  sysreset: enable driver support in SPL/TPL
  image: add os type for OP-TEE
  spl: add support to booting with OP-TEE
  rockchip: rk322x: dts: enable uart2 for SPL/TPL
  rockchip: add fit source file for pack itb with op-tee
  rockchip: evb-rk3229: add README file for OP-TEE support
  rockchip: evb-rk322x: update defconfig with tpl and optee support

 arch/arm/Kconfig                             | 29 +++++++++
 arch/arm/dts/rk3229-evb.dts                  |  1 +
 arch/arm/lib/crt0.S                          |  4 +-
 arch/arm/mach-rockchip/Kconfig               |  9 +++
 arch/arm/mach-rockchip/Makefile              |  3 +-
 arch/arm/mach-rockchip/fit_spl_optee.its     | 50 ++++++++++++++++
 arch/arm/mach-rockchip/rk322x-board-spl.c    | 63 +++++---------------
 arch/arm/mach-rockchip/rk322x-board-tpl.c    | 88 ++++++++++++++++++++++++++++
 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds | 13 ++++
 board/rockchip/evb_rk3229/README             | 72 +++++++++++++++++++++++
 common/image.c                               |  1 +
 common/spl/Kconfig                           |  7 +++
 common/spl/Makefile                          |  1 +
 common/spl/spl.c                             |  9 +++
 common/spl/spl_optee.S                       | 13 ++++
 configs/evb-rk3229_defconfig                 | 26 +++++++-
 drivers/sysreset/Kconfig                     | 18 ++++++
 drivers/sysreset/Makefile                    |  2 +-
 include/configs/rk322x_common.h              |  9 ++-
 include/image.h                              |  1 +
 include/spl.h                                | 13 ++++
 lib/Kconfig                                  | 10 ++++
 22 files changed, 384 insertions(+), 58 deletions(-)
 create mode 100644 arch/arm/mach-rockchip/fit_spl_optee.its
 create mode 100644 arch/arm/mach-rockchip/rk322x-board-tpl.c
 create mode 100644 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds
 create mode 100644 board/rockchip/evb_rk3229/README
 create mode 100644 common/spl/spl_optee.S

-- 
1.9.1

[U-Boot] [PATCH v4 01/11] lib: add TPL_OF_LIBFDT option for TPL

[Kever Yang]

TPL may need use libfdt for dt decode, add option for it.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 lib/Kconfig | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/lib/Kconfig b/lib/Kconfig
index 00ac650..5af421c 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -244,6 +244,16 @@ config SPL_OF_LIBFDT
 	  particular compatible nodes. The library operates on a flattened
 	  version of the device tree.
 
+config TPL_OF_LIBFDT
+	bool "Enable the FDT library for TPL"
+	default y if TPL_OF_CONTROL
+	help
+	  This enables the FDT library (libfdt). It provides functions for
+	  accessing binary device tree images in memory, such as adding and
+	  removing nodes and properties, scanning through the tree and finding
+	  particular compatible nodes. The library operates on a flattened
+	  version of the device tree.
+
 config FDT_FIXUP_PARTITIONS
 	bool "overwrite MTD partitions in DTS through defined in 'mtdparts'"
 	depends on OF_LIBFDT
-- 
1.9.1

[U-Boot] [PATCH v4 02/11] arm: add option for TPL ARCH_MEM in arm 32bit

[Kever Yang]

Some options like TPL_SYS_THUMB_BUILD, TPL_USE_ARCH_MEMCPY
and TPL_USE_ARCH_MEMCPY are needed for TPL build in 32bit arm.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- update subject with ARCH_MEM info

 arch/arm/Kconfig | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f2c35e3..fe4ca2a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -244,6 +244,17 @@ config SPL_SYS_THUMB_BUILD
 	   density. For ARM architectures that support Thumb2 this flag will
 	   result in Thumb2 code generated by GCC.
 
+config TPL_SYS_THUMB_BUILD
+	bool "Build TPL using the Thumb instruction set"
+	default y if SYS_THUMB_BUILD
+	depends on TPL && !ARM64
+	help
+	   Use this flag to build SPL using the Thumb instruction set for
+	   ARM architectures. Thumb instruction set provides better code
+	   density. For ARM architectures that support Thumb2 this flag will
+	   result in Thumb2 code generated by GCC.
+
+
 config SYS_L2CACHE_OFF
 	bool "L2cache off"
 	help
@@ -280,6 +291,15 @@ config SPL_USE_ARCH_MEMCPY
 	  Such implementation may be faster under some conditions
 	  but may increase the binary size.
 
+config TPL_USE_ARCH_MEMCPY
+	bool "Use an assembly optimized implementation of memcpy for TPL"
+	default y if USE_ARCH_MEMCPY
+	depends on !ARM64
+	help
+	  Enable the generation of an optimized version of memcpy.
+	  Such implementation may be faster under some conditions
+	  but may increase the binary size.
+
 config USE_ARCH_MEMSET
 	bool "Use an assembly optimized implementation of memset"
 	default y
@@ -298,6 +318,15 @@ config SPL_USE_ARCH_MEMSET
 	  Such implementation may be faster under some conditions
 	  but may increase the binary size.
 
+config TPL_USE_ARCH_MEMSET
+	bool "Use an assembly optimized implementation of memset for TPL"
+	default y if USE_ARCH_MEMSET
+	depends on !ARM64
+	help
+	  Enable the generation of an optimized version of memset.
+	  Such implementation may be faster under some conditions
+	  but may increase the binary size.
+
 config ARM64_SUPPORT_AARCH32
 	bool "ARM64 system support AArch32 execution state"
 	default y if ARM64 && !TARGET_THUNDERX_88XX
-- 
1.9.1

[U-Boot] [PATCH v4 03/11] arm: add a separate stack for TPL

[Kever Yang]

TPL stack may different from SPL and sys stack, add support for
separate one when the board defines it.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/lib/crt0.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index fa81317..3c1c603 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -70,7 +70,9 @@ ENTRY(_main)
  * Set up initial C runtime environment and call board_init_f(0).
  */
 
-#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
+#if defined(CONFIG_TPL_BUILD) && defined(CONFIG_TPL_NEEDS_SEPARATE_STACK)
+	ldr	r0, =(CONFIG_TPL_STACK)
+#elif defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
 	ldr	r0, =(CONFIG_SPL_STACK)
 #else
 	ldr	r0, =(CONFIG_SYS_INIT_SP_ADDR)
-- 
1.9.1

[U-Boot] [PATCH v4 04/11] rockchip: rk322x: enable tpl support

[Kever Yang]

Move original spl to tpl, and add spl to load next stage firmware,
adapt all the address and option for them.

Serial-changes: 2
- update upon latest source

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
---

Changes in v4:
- remove non-used MACRO define

Changes in v3:
- do not init ddr region in spl

Changes in v2: None

 arch/arm/mach-rockchip/Kconfig               |  9 +++
 arch/arm/mach-rockchip/Makefile              |  3 +-
 arch/arm/mach-rockchip/rk322x-board-spl.c    | 63 +++++---------------
 arch/arm/mach-rockchip/rk322x-board-tpl.c    | 88 ++++++++++++++++++++++++++++
 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds | 13 ++++
 include/configs/rk322x_common.h              |  9 ++-
 6 files changed, 132 insertions(+), 53 deletions(-)
 create mode 100644 arch/arm/mach-rockchip/rk322x-board-tpl.c
 create mode 100644 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 967290f..dbc197c 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -46,9 +46,18 @@ config ROCKCHIP_RK322X
 	bool "Support Rockchip RK3228/RK3229"
 	select CPU_V7
 	select SUPPORT_SPL
+	select SUPPORT_TPL
 	select SPL
+	select TPL
+	select TPL_NEEDS_SEPARATE_TEXT_BASE if SPL
+	select TPL_NEEDS_SEPARATE_STACK if TPL
+	select SPL_DRIVERS_MISC_SUPPORT
+	imply SPL_SERIAL_SUPPORT
+	imply TPL_SERIAL_SUPPORT
 	select ROCKCHIP_BROM_HELPER
 	select DEBUG_UART_BOARD_INIT
+	select TPL_LIBCOMMON_SUPPORT
+	select TPL_LIBGENERIC_SUPPORT
 	help
 	  The Rockchip RK3229 is a ARM-based SoC with a dual-core Cortex-A7
 	  including NEON and GPU, Mali-400 graphics, several DDR3 options
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index e1b0519..3c14236 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -13,10 +13,11 @@ obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
 
 obj-tpl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-tpl.o
 obj-tpl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-tpl.o
+obj-tpl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-tpl.o
 
 obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
 obj-spl-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-spl.o
-obj-spl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-spl.o
+obj-spl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-spl.o spl-boot-order.o
 obj-spl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o
 obj-spl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-spl.o spl-boot-order.o
 obj-spl-$(CONFIG_ROCKCHIP_RK3399) += rk3399-board-spl.o spl-boot-order.o
diff --git a/arch/arm/mach-rockchip/rk322x-board-spl.c b/arch/arm/mach-rockchip/rk322x-board-spl.c
index 35f4f97..89af1d9 100644
--- a/arch/arm/mach-rockchip/rk322x-board-spl.c
+++ b/arch/arm/mach-rockchip/rk322x-board-spl.c
@@ -5,77 +5,46 @@
  */
 
 #include <common.h>
-#include <debug_uart.h>
 #include <dm.h>
-#include <ram.h>
 #include <spl.h>
-#include <asm/io.h>
-#include <asm/arch/bootrom.h>
-#include <asm/arch/cru_rk322x.h>
-#include <asm/arch/grf_rk322x.h>
-#include <asm/arch/hardware.h>
-#include <asm/arch/timer.h>
-#include <asm/arch/uart.h>
+
+DECLARE_GLOBAL_DATA_PTR;
 
 u32 spl_boot_device(void)
 {
 	return BOOT_DEVICE_MMC1;
 }
-DECLARE_GLOBAL_DATA_PTR;
 
-#define GRF_BASE	0x11000000
-#define SGRF_BASE	0x10140000
-
-#define DEBUG_UART_BASE	0x11030000
+u32 spl_boot_mode(const u32 boot_device)
+{
+	return MMCSD_MODE_RAW;
+}
 
 void board_debug_uart_init(void)
 {
-static struct rk322x_grf * const grf = (void *)GRF_BASE;
-	/* Enable early UART2 channel 1 on the RK322x */
-	rk_clrsetreg(&grf->gpio1b_iomux,
-		     GPIO1B1_MASK | GPIO1B2_MASK,
-		     GPIO1B2_UART21_SIN << GPIO1B2_SHIFT |
-		     GPIO1B1_UART21_SOUT << GPIO1B1_SHIFT);
-	/* Set channel C as UART2 input */
-	rk_clrsetreg(&grf->con_iomux,
-		     CON_IOMUX_UART2SEL_MASK,
-		     CON_IOMUX_UART2SEL_21 << CON_IOMUX_UART2SEL_SHIFT);
 }
 
-#define SGRF_DDR_CON0 0x10150000
 void board_init_f(ulong dummy)
 {
-	struct udevice *dev;
 	int ret;
 
-	/*
-	 * Debug UART can be used from here if required:
-	 *
-	 * debug_uart_init();
-	 * printch('a');
-	 * printhex8(0x1234);
-	 * printascii("string");
-	 */
-	debug_uart_init();
-	printascii("SPL Init");
-
 	ret = spl_early_init();
 	if (ret) {
-		debug("spl_early_init() failed: %d\n", ret);
+		printf("spl_early_init() failed: %d\n", ret);
 		hang();
 	}
+	preloader_console_init();
+}
 
-	rockchip_timer_init();
-	printf("timer init done\n");
-	ret = uclass_get_device(UCLASS_RAM, 0, &dev);
-	if (ret) {
-		printf("DRAM init failed: %d\n", ret);
-		return;
-	}
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+	/* Just empty function now - can't decide what to choose */
+	debug("%s: %s\n", __func__, name);
 
-	/* Disable the ddr secure region setting to make it non-secure */
-	rk_clrreg(SGRF_DDR_CON0, 0x4000);
 #if defined(CONFIG_ROCKCHIP_SPL_BACK_TO_BROM) && !defined(CONFIG_SPL_BOARD_INIT)
 	back_to_bootrom(BROM_BOOT_NEXTSTAGE);
 #endif
+	return 0;
 }
+#endif
diff --git a/arch/arm/mach-rockchip/rk322x-board-tpl.c b/arch/arm/mach-rockchip/rk322x-board-tpl.c
new file mode 100644
index 0000000..a10a7a1
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk322x-board-tpl.c
@@ -0,0 +1,88 @@
+/*
+ * (C) Copyright 2017 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier:     GPL-2.0+
+ */
+
+#include <common.h>
+#include <debug_uart.h>
+#include <dm.h>
+#include <ram.h>
+#include <spl.h>
+#include <asm/io.h>
+#include <asm/arch/bootrom.h>
+#include <asm/arch/cru_rk322x.h>
+#include <asm/arch/grf_rk322x.h>
+#include <asm/arch/hardware.h>
+#include <asm/arch/timer.h>
+#include <asm/arch/uart.h>
+
+u32 spl_boot_device(void)
+{
+	return BOOT_DEVICE_MMC1;
+}
+DECLARE_GLOBAL_DATA_PTR;
+
+#define GRF_BASE	0x11000000
+#define SECURE_TIMER_BASE	0x110d0020
+#define SGRF_DDR_CON0 0x10150000
+
+void board_debug_uart_init(void)
+{
+	static struct rk322x_grf * const grf = (void *)GRF_BASE;
+	/* Enable early UART2 channel 1 on the RK322x */
+	rk_clrsetreg(&grf->gpio1b_iomux,
+		     GPIO1B1_MASK | GPIO1B2_MASK,
+		     GPIO1B2_UART21_SIN << GPIO1B2_SHIFT |
+		     GPIO1B1_UART21_SOUT << GPIO1B1_SHIFT);
+	/* Set channel C as UART2 input */
+	rk_clrsetreg(&grf->con_iomux,
+		     CON_IOMUX_UART2SEL_MASK,
+		     CON_IOMUX_UART2SEL_21 << CON_IOMUX_UART2SEL_SHIFT);
+}
+
+void secure_timer_init(void)
+{
+	writel(0, SECURE_TIMER_BASE + 0x10);
+	writel(0xffffffff, SECURE_TIMER_BASE);
+	writel(0xffffffff, SECURE_TIMER_BASE + 4);
+	writel(1, SECURE_TIMER_BASE + 0x10);
+}
+
+void board_init_f(ulong dummy)
+{
+	struct udevice *dev;
+	int ret;
+
+	/*
+	 * Debug UART can be used from here if required:
+	 *
+	 * debug_uart_init();
+	 * printch('a');
+	 * printhex8(0x1234);
+	 * printascii("string");
+	 */
+	debug_uart_init();
+	printascii("TPL Init");
+
+	ret = spl_early_init();
+	if (ret) {
+		debug("spl_early_init() failed: %d\n", ret);
+		hang();
+	}
+
+	secure_timer_init();
+	/* TODO: use arm generic timer instead for armv7 */
+	rockchip_timer_init();
+	ret = uclass_get_device(UCLASS_RAM, 0, &dev);
+	if (ret) {
+		printf("DRAM init failed: %d\n", ret);
+		return;
+	}
+
+	/* Disable the ddr secure region setting to make it non-secure */
+	rk_clrreg(SGRF_DDR_CON0, 0x4000);
+#if defined(CONFIG_TPL_ROCKCHIP_BACK_TO_BROM) && !defined(CONFIG_TPL_BOARD_INIT)
+	back_to_bootrom(BROM_BOOT_NEXTSTAGE);
+#endif
+}
diff --git a/arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds b/arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds
new file mode 100644
index 0000000..841c803
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds
@@ -0,0 +1,13 @@
+/*
+ * Copyright (C) 2017 Rockchip Electronic Co.,Ltd
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#undef CONFIG_SPL_TEXT_BASE
+#define CONFIG_SPL_TEXT_BASE CONFIG_TPL_TEXT_BASE
+
+#undef CONFIG_SPL_MAX_SIZE
+#define CONFIG_SPL_MAX_SIZE CONFIG_TPL_MAX_SIZE
+
+#include "../../cpu/u-boot-spl.lds"
diff --git a/include/configs/rk322x_common.h b/include/configs/rk322x_common.h
index b22169d..5536b58 100644
--- a/include/configs/rk322x_common.h
+++ b/include/configs/rk322x_common.h
@@ -20,11 +20,10 @@
 
 #define CONFIG_SPL_FRAMEWORK
 #define CONFIG_SYS_NS16550_MEM32
-#define CONFIG_SYS_TEXT_BASE		0x60000000
-#define CONFIG_SYS_INIT_SP_ADDR		0x60100000
-#define CONFIG_SYS_LOAD_ADDR		0x60800800
-#define CONFIG_SPL_STACK		0x10088000
-#define CONFIG_SPL_TEXT_BASE		0x10081004
+#define CONFIG_SYS_TEXT_BASE		0x61000000
+#define CONFIG_SYS_INIT_SP_ADDR		0x61100000
+#define CONFIG_SYS_LOAD_ADDR		0x61800800
+#define CONFIG_SPL_TEXT_BASE		0x60000000
 
 #define CONFIG_ROCKCHIP_MAX_INIT_SIZE	(28 << 10)
 #define CONFIG_ROCKCHIP_CHIP_TAG	"RK32"
-- 
1.9.1

[U-Boot] [PATCH v4 05/11] sysreset: enable driver support in SPL/TPL

[Kever Yang]

SPL/TPL also need use sysreset for some feature like panic callback.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/sysreset/Kconfig  | 18 ++++++++++++++++++
 drivers/sysreset/Makefile |  2 +-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index a6d48e8..a61a7d3 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -13,6 +13,24 @@ config SYSRESET
 	  to effect a reset. The uclass will try all available drivers when
 	  reset_walk() is called.
 
+config SPL_SYSRESET
+	bool "Enable support for system reset drivers in SPL mode"
+	depends on SYSRESET && SPL_DM
+	help
+	  Enable system reset drivers which can be used to reset the CPU or
+	  board. Each driver can provide a reset method which will be called
+	  to effect a reset. The uclass will try all available drivers when
+	  reset_walk() is called.
+
+config TPL_SYSRESET
+	bool "Enable support for system reset drivers in TPL mode"
+	depends on SYSRESET && TPL_DM
+	help
+	  Enable system reset drivers which can be used to reset the CPU or
+	  board. Each driver can provide a reset method which will be called
+	  to effect a reset. The uclass will try all available drivers when
+	  reset_walk() is called.
+
 if SYSRESET
 
 config SYSRESET_PSCI
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index 2e9598e..00be747 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -4,7 +4,7 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
-obj-$(CONFIG_SYSRESET) += sysreset-uclass.o
+obj-$(CONFIG_$(SPL_TPL_)SYSRESET) += sysreset-uclass.o
 obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
 obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
 obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
-- 
1.9.1

[U-Boot] [PATCH v4 06/11] image: add os type for OP-TEE

[Kever Yang]

OP-TEE is an open source trust OS maintained here:
https://github.com/OP-TEE/optee_os

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Add new image type like ATF

 common/image.c  | 1 +
 include/image.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/common/image.c b/common/image.c
index e9609cd..92234e5 100644
--- a/common/image.c
+++ b/common/image.c
@@ -91,6 +91,7 @@ static const table_entry_t uimage_arch[] = {
 
 static const table_entry_t uimage_os[] = {
 	{	IH_OS_INVALID,	"invalid",	"Invalid OS",		},
+	{       IH_OS_OP_TEE, "op-tee", "OP-TEE"  },
 	{       IH_OS_ARM_TRUSTED_FIRMWARE, "arm-trusted-firmware", "ARM Trusted Firmware"  },
 	{	IH_OS_LINUX,	"linux",	"Linux",		},
 #if defined(CONFIG_LYNXKDI) || defined(USE_HOSTCC)
diff --git a/include/image.h b/include/image.h
index a128a62..141ed00 100644
--- a/include/image.h
+++ b/include/image.h
@@ -153,6 +153,7 @@ enum {
 	IH_OS_PLAN9,			/* Plan 9	*/
 	IH_OS_OPENRTOS,		/* OpenRTOS	*/
 	IH_OS_ARM_TRUSTED_FIRMWARE,     /* ARM Trusted Firmware */
+	IH_OS_OP_TEE,			/* OP-TEE	*/
 
 	IH_OS_COUNT,
 };
-- 
1.9.1

[U-Boot] [PATCH v4 07/11] spl: add support to booting with OP-TEE

[Kever Yang]

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.yang@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

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 9d35f41..7e44da5 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -739,6 +739,13 @@ config SPL_ATF_NO_PLATFORM_PARAM
 
 	  If your ATF is affected, say Y.
 
+config SPL_OPTEE
+	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 9bf8a2d..9918a2e 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) += spl_atf.o
+obj-$(CONFIG_$(SPL_TPL_)OPTEE) += 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 76c1963..97a98d6 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -436,6 +436,13 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 		spl_invoke_atf(&spl_image);
 		break;
 #endif
+#if CONFIG_IS_ENABLED(OPTEE)
+	case IH_OS_OP_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
 #ifdef CONFIG_SPL_OS_BOOT
 	case IH_OS_LINUX:
 		debug("Jumping to Linux\n");
@@ -450,6 +457,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 	debug("SPL malloc() used %#lx bytes (%ld KB)\n", gd->malloc_ptr,
 	      gd->malloc_ptr / 1024);
 #endif
+
+	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)
diff --git a/include/spl.h b/include/spl.h
index c14448b..adceb03 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -288,6 +288,19 @@ int spl_mmc_load_image(struct spl_image_info *spl_image,
 void spl_invoke_atf(struct spl_image_info *spl_image);
 
 /**
+ * spl_optee_entry - entry function for optee
+ *
+ * args defind in op-tee project
+ * https://github.com/OP-TEE/optee_os/
+ * core/arch/arm/kernel/generic_entry_a32.S
+ * @arg0: pagestore
+ * @arg1: (ARMv7 standard bootarg #1)
+ * @arg2: device tree address, (ARMv7 standard bootarg #2)
+ * @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
-- 
1.9.1

[U-Boot] [PATCH v4 08/11] rockchip: rk322x: dts: enable uart2 for SPL/TPL

[Kever Yang]

When we use DM_SERIAL for serial driver, we need enable the
dts node for the debug console.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/dts/rk3229-evb.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/rk3229-evb.dts b/arch/arm/dts/rk3229-evb.dts
index ae0b0a4..fe4abe9 100644
--- a/arch/arm/dts/rk3229-evb.dts
+++ b/arch/arm/dts/rk3229-evb.dts
@@ -83,6 +83,7 @@
 };
 
 &uart2 {
+	u-boot,dm-pre-reloc;
 	status = "okay";
 };
 
-- 
1.9.1

[U-Boot] [PATCH v4 09/11] rockchip: add fit source file for pack itb with op-tee

[Kever Yang]

We package U-Boot and OP-TEE into one itb file for SPL,
so that we can support OP-TEE in SPL.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Make the its as common file used for all armv7 with op-tee

 arch/arm/mach-rockchip/fit_spl_optee.its | 50 ++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 arch/arm/mach-rockchip/fit_spl_optee.its

diff --git a/arch/arm/mach-rockchip/fit_spl_optee.its b/arch/arm/mach-rockchip/fit_spl_optee.its
new file mode 100644
index 0000000..3aeecb8
--- /dev/null
+++ b/arch/arm/mach-rockchip/fit_spl_optee.its
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2017 Rockchip Electronic Co.,Ltd
+ *
+ * Simple U-boot fit source file containing U-Boot, dtb and optee
+ */
+
+/dts-v1/;
+
+/ {
+	description = "Simple image with OP-TEE support";
+	#address-cells = <1>;
+
+	images {
+		uboot at 1 {
+			description = "U-Boot";
+			data = /incbin/("../../../u-boot-nodtb.bin");
+			type = "standalone";
+			os = "U-Boot";
+			arch = "arm";
+			compression = "none";
+			load = <0x61000000>;
+		};
+		optee at 1 {
+			description = "OP-TEE";
+			data = /incbin/("../../../tee.bin");
+			type = "firmware";
+			arch = "arm";
+			os = "op-tee";
+			compression = "none";
+			load = <0x68400000>;
+			entry = <0x68400000>;
+		};
+		fdt at 1 {
+			description = "dtb";
+			data = /incbin/("../../../u-boot.dtb");
+			type = "flat_dt";
+			compression = "none";
+		};
+	};
+
+	configurations {
+		default = "conf at 1";
+		conf at 1 {
+			description = "Rockchip armv7 with OP-TEE";
+			firmware = "optee at 1";
+			loadables = "uboot at 1";
+			fdt = "fdt at 1";
+		};
+	};
+};
-- 
1.9.1

[U-Boot] [PATCH v4 10/11] rockchip: evb-rk3229: add README file for OP-TEE support

[Kever Yang]

Detail of step by step to bring up the board with OP-TEE support.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 board/rockchip/evb_rk3229/README | 72 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)
 create mode 100644 board/rockchip/evb_rk3229/README

diff --git a/board/rockchip/evb_rk3229/README b/board/rockchip/evb_rk3229/README
new file mode 100644
index 0000000..46c54c2
--- /dev/null
+++ b/board/rockchip/evb_rk3229/README
@@ -0,0 +1,72 @@
+Get the Source and prebuild binary
+==================================
+
+  > mkdir ~/evb_rk3229
+  > cd ~/evb_rk3229
+  > git clone git://git.denx.de/u-boot.git
+  > git clone https://github.com/OP-TEE/optee_os.git
+  > git clone https://github.com/rockchip-linux/rkbin.git
+  > git clone https://github.com/rockchip-linux/rkdeveloptool.git
+
+Compile the OP-TEE
+===============
+
+  > cd optee_os
+  > make clean
+  > make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x
+  Get tee.bin in this step, copy it to U-Boot root dir:
+  > cp out/arm-plat-rockchip/core/tee-pager.bin ../u-boot/tee.bin
+
+Compile the U-Boot
+==================
+
+  > cd ../u-boot
+  > export CROSS_COMPILE=arm-linux-gnueabihf-
+  > export ARCH=arm
+  > make evb-rk3229_defconfig
+  > make
+  > make u-boot.itb
+
+  Get tpl/u-boot-tpl.bin, spl/u-boot-spl.bin and u-boot.itb in this step.
+
+Compile the rkdeveloptool
+=======================
+  Follow instructions in latest README
+  > cd ../rkdeveloptool
+  > autoreconf -i
+  > ./configure
+  > make
+  > sudo make install
+
+  Get rkdeveloptool in you Host in this step.
+
+Both origin binaries and Tool are ready now, choose either option 1 or
+option 2 to deploy U-Boot.
+
+Package the image
+=================
+
+  > cd ../u-boot
+  > tools/mkimage -n rk322x -T rksd -d tpl/u-boot-spl.bin idbloader.img
+  > cat spl/u-boot-spl.bin >> idbloader.img
+
+  Get idbloader.img in this step.
+
+Flash the image to eMMC
+=======================
+Power on(or reset with RESET KEY) with MASKROM KEY preesed, and then:
+  > cd ..
+  > rkdeveloptool db rkbin/rk32/rk322x_loader_v1.04.232.bin
+  > rkdeveloptool wl 64 u-boot/idbloader.img
+  > rkdeveloptool wl 0x4000 u-boot/u-boot.itb
+  > rkdeveloptool rd
+
+Flash the image to SD card
+==========================
+  > dd if=u-boot/idbloader.img of=/dev/sdb seek=64
+  > dd if=u-boot/u-boot.itb of=/dev/sdb seek=16384
+
+You should be able to get U-Boot log message with OP-TEE boot info.
+
+For more detail, please reference to:
+http://opensource.rock-chips.com/wiki_Boot_option
-- 
1.9.1

[U-Boot] [PATCH v4 11/11] rockchip: evb-rk322x: update defconfig with tpl and optee support

[Kever Yang]

Enable all the options for TPL/SPL and OPTEE.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- update defconfig option

 configs/evb-rk3229_defconfig | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/configs/evb-rk3229_defconfig b/configs/evb-rk3229_defconfig
index b226f66..025822d 100644
--- a/configs/evb-rk3229_defconfig
+++ b/configs/evb-rk3229_defconfig
@@ -4,14 +4,27 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SYS_MALLOC_F_LEN=0x800
 CONFIG_ROCKCHIP_RK322X=y
-CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y
+CONFIG_TPL_LDSCRIPT="arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds"
+CONFIG_TPL_TEXT_BASE=0x10081000
+CONFIG_TPL_MAX_SIZE=28672
+CONFIG_TPL_STACK=0x10088000
+CONFIG_TPL_ROCKCHIP_BACK_TO_BROM=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x0
 CONFIG_TARGET_EVB_RK3229=y
-CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_SPL_STACK_R_ADDR=0x60600000
 CONFIG_DEFAULT_DEVICE_TREE="rk3229-evb"
 CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_SOURCE="arch/arm/mach-rockchip/fit_spl_optee.its"
 # CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
-CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x4000
+CONFIG_SPL_OPTEE=y
 CONFIG_FASTBOOT_FLASH=y
 CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_CMD_GPT=y
@@ -19,14 +32,19 @@ CONFIG_CMD_MMC=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_TIME=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_TPL_OF_CONTROL=y
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_TPL_DM=y
 CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
+CONFIG_TPL_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_SPL_SYSCON=y
+CONFIG_TPL_SYSCON=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
+CONFIG_TPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
@@ -35,12 +53,14 @@ CONFIG_PINCTRL=y
 CONFIG_PINCTRL_ROCKCHIP_RK322X=y
 CONFIG_RAM=y
 CONFIG_SPL_RAM=y
+CONFIG_TPL_RAM=y
 CONFIG_BAUDRATE=1500000
 CONFIG_DEBUG_UART_BASE=0x11030000
 CONFIG_DEBUG_UART_CLOCK=24000000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550=y
 CONFIG_SYSRESET=y
+CONFIG_SPL_SYSRESET=y
 CONFIG_USB=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Rockchip"
-- 
1.9.1

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Philipp Tomsich]

> 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.yang@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.tomsich@theobroma-systems.com>

[U-Boot] [U-Boot, v4, 04/11] rockchip: rk322x: enable tpl support

[Philipp Tomsich]

> Move original spl to tpl, and add spl to load next stage firmware,
> adapt all the address and option for them.
> 
> Serial-changes: 2
> - update upon latest source
> 
> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> ---
> 
> Changes in v4:
> - remove non-used MACRO define
> 
> Changes in v3:
> - do not init ddr region in spl
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/Kconfig               |  9 +++
>  arch/arm/mach-rockchip/Makefile              |  3 +-
>  arch/arm/mach-rockchip/rk322x-board-spl.c    | 63 +++++---------------
>  arch/arm/mach-rockchip/rk322x-board-tpl.c    | 88 ++++++++++++++++++++++++++++
>  arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds | 13 ++++
>  include/configs/rk322x_common.h              |  9 ++-
>  6 files changed, 132 insertions(+), 53 deletions(-)
>  create mode 100644 arch/arm/mach-rockchip/rk322x-board-tpl.c
>  create mode 100644 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds
> 

Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Bryan O'Donoghue]

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.yang@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.tomsich@theobroma-systems.com>
> _______________________________________________
> U-Boot mailing list
> U-Boot at 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] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Kever Yang]

Bryan,


On 01/12/2018 11:10 PM, Bryan O'Donoghue wrote:
>
>
> 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.yang@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.tomsich@theobroma-systems.com>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at 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).

I don't understand how you use OP-TEE in your project.
You are using U-Boot 'bootm' cmd to run into OP-TEE and 'PC' never get 
out of the OP-TEE os?
The upstream OP-TEE will always be back to the pointer in 'lr'.

We are using boot flow like ARMv8 for OP-TEE in armv7, could you 
introduce your flow?
bootrom(BL1, secure word)->SPL(BL2, secure word)->OP-TEE(BL31/32, secure 
word)
->U-Boot(BL33, non-secure word)->Linux kernel(non secure word).
By the OP-TEE design we need jump to U-Boot with using 'lr' as pointer 
to next stage, that's why I add
new type for SPL image:
https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/generic_entry_a32.S#L186

Thanks,
- Kever
>
> 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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Peng Fan]

On Mon, Jan 15, 2018 at 11:25:00AM +0800, Kever Yang wrote:
>Bryan,
>
>
>On 01/12/2018 11:10 PM, Bryan O'Donoghue wrote:
>>
>>
>>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.yang@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.tomsich@theobroma-systems.com>
>>>_______________________________________________
>>>U-Boot mailing list
>>>U-Boot at 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).
>
>I don't understand how you use OP-TEE in your project.
>You are using U-Boot 'bootm' cmd to run into OP-TEE and 'PC' never
>get out of the OP-TEE os?
>The upstream OP-TEE will always be back to the pointer in 'lr'.
>
>We are using boot flow like ARMv8 for OP-TEE in armv7, could you
>introduce your flow?

The flow is ROM->U-Boot->OP-TEE->Linux.

Regards,
Peng.

>bootrom(BL1, secure word)->SPL(BL2, secure word)->OP-TEE(BL31/32,
>secure word)
>->U-Boot(BL33, non-secure word)->Linux kernel(non secure word).
>By the OP-TEE design we need jump to U-Boot with using 'lr' as
>pointer to next stage, that's why I add
>new type for SPL image:
>https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/generic_entry_a32.S#L186
>
>Thanks,
>- Kever
>>
>>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 at lists.denx.de
>>https://lists.denx.de/listinfo/u-boot
>
>
>_______________________________________________
>U-Boot mailing list
>U-Boot at lists.denx.de
>https://lists.denx.de/listinfo/u-boot

-- 

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Bryan O'Donoghue]

On 15/01/18 04:48, Peng Fan wrote:
> On Mon, Jan 15, 2018 at 11:25:00AM +0800, Kever Yang wrote:
>> Bryan,
>>
>>
>> On 01/12/2018 11:10 PM, Bryan O'Donoghue wrote:
>>>
>>>
>>> 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.yang@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.tomsich@theobroma-systems.com>
>>>> _______________________________________________
>>>> U-Boot mailing list
>>>> U-Boot at 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).
>>
>> I don't understand how you use OP-TEE in your project.
>> You are using U-Boot 'bootm' cmd to run into OP-TEE and 'PC' never
>> get out of the OP-TEE os?
>> The upstream OP-TEE will always be back to the pointer in 'lr'.
>>
>> We are using boot flow like ARMv8 for OP-TEE in armv7, could you
>> introduce your flow?
> 
> The flow is ROM->U-Boot->OP-TEE->Linux.

Hi Kever, this got buried in my mailbox...

Which I believe is the preferred flow for armv7

That said - if you look at the TI commits for IH_TYPE_TEE I believe 
*that* is the appropriate type for what you are doing with SPL.

As I read the TI code the TEE is installed into memory - jumped into and 
returned out of, which is the model you are using with SPL here.

Basically that's what 
arch/arm/mach-omap2/sec-common.c::secure_tee_install() does.

So, I think the SPL solution you have can co-exist quite easily with the 
model we have described above for imx7.

My only suggestion here is that you probably don't need to define a new 
image type for SPL - you can reuse IH_TYPE_TEE for SPL as below.

Other than that I think the SPL/bootm or indeed the TI method of 
installing a TEE are entirely able to (and should) live side-by-side.

>>> +#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

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Kever Yang]

Bryan,


On 01/18/2018 01:48 AM, Bryan O'Donoghue wrote:
>
>
> On 15/01/18 04:48, Peng Fan wrote:
>> On Mon, Jan 15, 2018 at 11:25:00AM +0800, Kever Yang wrote:
>>> Bryan,
>>>
>>>
>>> On 01/12/2018 11:10 PM, Bryan O'Donoghue wrote:
>>>>
>>>>
>>>> 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.yang@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.tomsich@theobroma-systems.com>
>>>>> _______________________________________________
>>>>> U-Boot mailing list
>>>>> U-Boot at 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).
>>>
>>> I don't understand how you use OP-TEE in your project.
>>> You are using U-Boot 'bootm' cmd to run into OP-TEE and 'PC' never
>>> get out of the OP-TEE os?
>>> The upstream OP-TEE will always be back to the pointer in 'lr'.
>>>
>>> We are using boot flow like ARMv8 for OP-TEE in armv7, could you
>>> introduce your flow?
>>
>> The flow is ROM->U-Boot->OP-TEE->Linux.
>
> Hi Kever, this got buried in my mailbox...
>
> Which I believe is the preferred flow for armv7
>
> That said - if you look at the TI commits for IH_TYPE_TEE I believe 
> *that* is the appropriate type for what you are doing with SPL.
>
> As I read the TI code the TEE is installed into memory - jumped into 
> and returned out of, which is the model you are using with SPL here.
>
> Basically that's what 
> arch/arm/mach-omap2/sec-common.c::secure_tee_install() does.
>
> So, I think the SPL solution you have can co-exist quite easily with 
> the model we have described above for imx7.
>
> My only suggestion here is that you probably don't need to define a 
> new image type for SPL - you can reuse IH_TYPE_TEE for SPL as below.

I don't think we can reuse IH_TYPE_TEE， it use a optee.img type create 
by mkimage and it seem use more then one cpu.
We use fit to pack uboot and optee into one itb file, and we use only 
one cpu now.
I may prefer to use what I have send with the type update to 
IH_TYPE_OPTEE_SPL.

Thanks,
- Kever
>
> Other than that I think the SPL/bootm or indeed the TI method of 
> installing a TEE are entirely able to (and should) live side-by-side.
>
>>>> +#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
>

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Bryan O'Donoghue]

On 18/01/18 01:31, Kever Yang wrote:
> I don't think we can reuse IH_TYPE_TEE， it use a optee.img type create 
> by mkimage and it seem use more then one cpu.

Don't really understand what you mean by using more than one CPU - can 
you give an example in the code ?

---
bod

[U-Boot] [U-Boot, v4, 04/11] rockchip: rk322x: enable tpl support

[Philipp Tomsich]

> Move original spl to tpl, and add spl to load next stage firmware,
> adapt all the address and option for them.
> 
> Serial-changes: 2
> - update upon latest source
> 
> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
> ---
> 
> Changes in v4:
> - remove non-used MACRO define
> 
> Changes in v3:
> - do not init ddr region in spl
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/Kconfig               |  9 +++
>  arch/arm/mach-rockchip/Makefile              |  3 +-
>  arch/arm/mach-rockchip/rk322x-board-spl.c    | 63 +++++---------------
>  arch/arm/mach-rockchip/rk322x-board-tpl.c    | 88 ++++++++++++++++++++++++++++
>  arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds | 13 ++++
>  include/configs/rk322x_common.h              |  9 ++-
>  6 files changed, 132 insertions(+), 53 deletions(-)
>  create mode 100644 arch/arm/mach-rockchip/rk322x-board-tpl.c
>  create mode 100644 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds
> 

Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Philipp Tomsich]

> 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.yang@rock-chips.com>
> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.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
> 

Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Bryan O'Donoghue]

On 18/01/18 11:21, Bryan O'Donoghue wrote:
> 
> 
> On 18/01/18 01:31, Kever Yang wrote:
>> I don't think we can reuse IH_TYPE_TEE， it use a optee.img type 
>> create by mkimage and it seem use more then one cpu.
> 
> Don't really understand what you mean by using more than one CPU - can 
> you give an example in the code ?
> 
> ---
> bod

So - what's the proposed resolution here ?

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Dr. Philipp Tomsich]

> On 25 Jan 2018, at 11:09, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
> 
> On 18/01/18 11:21, Bryan O'Donoghue wrote:
>> On 18/01/18 01:31, Kever Yang wrote:
>>> I don't think we can reuse IH_TYPE_TEE， it use a optee.img type create by mkimage and it seem use more then one cpu.
>> Don't really understand what you mean by using more than one CPU - can you give an example in the code ?
>> ---
>> bod
> 
> So - what's the proposed resolution here ?

Where do we stand on this: can we reuse IH_TYPE_TEE, will be use IH_TYPE_OPTEE or will there be a new IH_TYPE_OPTEE_SPL?
This series has been hanging in limbo for the better part of January and it seems as if just a naming issue is holding it back at the moment…

Thanks,
Philipp.

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Bryan O'Donoghue]

On 02/02/18 15:02, Dr. Philipp Tomsich wrote:
> Where do we stand on this: can we reuse IH_TYPE_TEE, will be use IH_TYPE_OPTEE or will there be a new IH_TYPE_OPTEE_SPL?

I think because you aren't doing anything different with the image type 
you can reuse IH_TYPE_TEE

This

+#if CONFIG_IS_ENABLED(OPTEE)
+	case IH_OS_OP_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

could just as easily be this

+#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

should be a matter of just replacing the call to mkimage to use

mkimage -A arm -T tee

instead of

mkimage -A arm -T optee

and the suggested change above.. case IH_OS_OP_TEE -> case IH_TYPE_TEE

---
bod

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Dr. Philipp Tomsich]

Bryan,

> On 2 Feb 2018, at 16:37, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
> 
> 
> 
> On 02/02/18 15:02, Dr. Philipp Tomsich wrote:
>> Where do we stand on this: can we reuse IH_TYPE_TEE, will be use IH_TYPE_OPTEE or will there be a new IH_TYPE_OPTEE_SPL?
> 
> I think because you aren't doing anything different with the image type you can reuse IH_TYPE_TEE
> 
> This
> 
> +#if CONFIG_IS_ENABLED(OPTEE)
> +	case IH_OS_OP_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
> 
> could just as easily be this
> 
> +#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
> 
> should be a matter of just replacing the call to mkimage to use
> 
> mkimage -A arm -T tee
> 
> instead of
> 
> mkimage -A arm -T optee
> 
> and the suggested change above.. case IH_OS_OP_TEE -> case IH_TYPE_TEE

Thanks for summarising your suggestion.

However, my mail was intended to test the waters to see what the consensus was.
A it appears that none has yet emerged between all the involved parties (including
our colleagues from TI that had also chimed in on the discussion).
So for now, I’ll sit back and wait until some sort of consensus (or at least a majority
for one solution or the other) emerges.

Personally, I am not happy with having a ‘tee’ and an ‘optee’ both refering to OP-TEE
and the upstream OP-TEE documentation suggesting that their envisioned boot
process was to boot through the OP-TEE (i.e. what the ‘tee’ image type does).
However, with the ‘tee’ image type already being defined, we seem to have already
backed ourselves into a situation where the naming is non-intuitive. 

Regards,
Philipp.

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Tom Rini]

On Fri, Feb 02, 2018 at 04:56:57PM +0100, Dr. Philipp Tomsich wrote:
> Bryan,
> 
> > On 2 Feb 2018, at 16:37, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
> > 
> > 
> > 
> > On 02/02/18 15:02, Dr. Philipp Tomsich wrote:
> >> Where do we stand on this: can we reuse IH_TYPE_TEE, will be use IH_TYPE_OPTEE or will there be a new IH_TYPE_OPTEE_SPL?
> > 
> > I think because you aren't doing anything different with the image type you can reuse IH_TYPE_TEE
> > 
> > This
> > 
> > +#if CONFIG_IS_ENABLED(OPTEE)
> > +	case IH_OS_OP_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
> > 
> > could just as easily be this
> > 
> > +#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
> > 
> > should be a matter of just replacing the call to mkimage to use
> > 
> > mkimage -A arm -T tee
> > 
> > instead of
> > 
> > mkimage -A arm -T optee
> > 
> > and the suggested change above.. case IH_OS_OP_TEE -> case IH_TYPE_TEE
> 
> Thanks for summarising your suggestion.
> 
> However, my mail was intended to test the waters to see what the consensus was.
> A it appears that none has yet emerged between all the involved parties (including
> our colleagues from TI that had also chimed in on the discussion).
> So for now, I’ll sit back and wait until some sort of consensus (or at least a majority
> for one solution or the other) emerges.
> 
> Personally, I am not happy with having a ‘tee’ and an ‘optee’ both refering to OP-TEE
> and the upstream OP-TEE documentation suggesting that their envisioned boot
> process was to boot through the OP-TEE (i.e. what the ‘tee’ image type does).
> However, with the ‘tee’ image type already being defined, we seem to have already
> backed ourselves into a situation where the naming is non-intuitive. 

Alright, I'm a little confused here.  I guess first, there's a
disconnect in upstream OP-TEE land about how 32bit ARM should be done?
I guess we have three different implemented and upstreamed flows:
- SPL->U-Boot->OP-TEE->U-Boot->Linux
- SPL->U-Boot->OP-TEE->Linux
- SPL->OP-TEE->U-Boot->Linux

And in this last case we have a combined image that is passed from SPL
to OP-TEE.

Since all 3 of these flows are in upstream OP-TEE, we need to support
them all.  The biggest constraint is that we have the first flow already
in and named "tee" (my fault, I should have made sure everyone would use
the same flow).  So we need to have descriptive enough names for the
other flows that we're going to add so that it's clear what's what.  How
about "tee-standalone" for "U-Boot starts OP-TEE, and is done" and
"tee-combo" for "SPL gives OP-TEE an image to deal with".  This could
even in theory I suspect be SPL gives OP-TEE a Linux kernel to boot.
I'm also happy to hear better suffixes but I don't want "tee" and
"optee".  And if we can cover two flows under the same name, that's good
too, we just need to name the last flow "tee-something".  Thanks all!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180219/8ff24172/attachment.sig>

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Bryan O'Donoghue]

On 19/02/18 15:44, Tom Rini wrote:
> On Fri, Feb 02, 2018 at 04:56:57PM +0100, Dr. Philipp Tomsich wrote:
>> Bryan,
>>
>>> On 2 Feb 2018, at 16:37, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
>>>
>>>
>>>
>>> On 02/02/18 15:02, Dr. Philipp Tomsich wrote:
>>>> Where do we stand on this: can we reuse IH_TYPE_TEE, will be use IH_TYPE_OPTEE or will there be a new IH_TYPE_OPTEE_SPL?
>>>
>>> I think because you aren't doing anything different with the image type you can reuse IH_TYPE_TEE
>>>
>>> This
>>>
>>> +#if CONFIG_IS_ENABLED(OPTEE)
>>> +	case IH_OS_OP_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
>>>
>>> could just as easily be this
>>>
>>> +#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
>>>
>>> should be a matter of just replacing the call to mkimage to use
>>>
>>> mkimage -A arm -T tee
>>>
>>> instead of
>>>
>>> mkimage -A arm -T optee
>>>
>>> and the suggested change above.. case IH_OS_OP_TEE -> case IH_TYPE_TEE
>>
>> Thanks for summarising your suggestion.
>>
>> However, my mail was intended to test the waters to see what the consensus was.
>> A it appears that none has yet emerged between all the involved parties (including
>> our colleagues from TI that had also chimed in on the discussion).
>> So for now, I’ll sit back and wait until some sort of consensus (or at least a majority
>> for one solution or the other) emerges.
>>
>> Personally, I am not happy with having a ‘tee’ and an ‘optee’ both refering to OP-TEE
>> and the upstream OP-TEE documentation suggesting that their envisioned boot
>> process was to boot through the OP-TEE (i.e. what the ‘tee’ image type does).
>> However, with the ‘tee’ image type already being defined, we seem to have already
>> backed ourselves into a situation where the naming is non-intuitive.
> 
> Alright, I'm a little confused here.  I guess first, there's a
> disconnect in upstream OP-TEE land about how 32bit ARM should be done?
> I guess we have three different implemented and upstreamed flows:
> - SPL->U-Boot->OP-TEE->U-Boot->Linux
> - SPL->U-Boot->OP-TEE->Linux
> - SPL->OP-TEE->U-Boot->Linux

I'd call that

- SPL/BootROM->U-Boot->OP-TEE->U-Boot->Linux
- SPL/BootROM->U-Boot->OP-TEE->Linux
- SPL/BootROM->OP-TEE->U-Boot->Linux

But yes - fundamentally your flow is correct.

> 
> And in this last case we have a combined image that is passed from SPL
> to OP-TEE.
> 
> Since all 3 of these flows are in upstream OP-TEE, we need to support
> them all. 

Agreed.

> The biggest constraint is that we have the first flow already
> in and named "tee" (my fault, I should have made sure everyone would use
> the same flow).  So we need to have descriptive enough names for the
> other flows that we're going to add so that it's clear what's what.  How
> about "tee-standalone" for "U-Boot starts OP-TEE, and is done"

> "tee-combo" for "SPL gives OP-TEE an image to deal with".  This could
> even in theory I suspect be SPL gives OP-TEE a Linux kernel to boot.
> I'm also happy to hear better suffixes but I don't want "tee" and
> "optee".  And if we can cover two flows under the same name, that's good
> too, we just need to name the last flow "tee-something".  Thanks all!

Yes I take your point "tee" and "optee" are the opposite of descriptive 
names.

- SPL/BootROM->U-Boot->OP-TEE->U-Boot->Linux
   Currently called "tee" - has type IH_TEE - maintained as is for
   compatibility - deserves some documentation.

- SPL/BootROM->U-Boot->OP-TEE->Linux
   New type "tee-standalone" this would be the type I've proposed
   in my patch set. New type IH_TYPE_TEE_STANDALONE

- SPL/BootROM->OP-TEE->U-Boot->Linux
   New type "tee-combo" this would be Kever's type IH_TYPE_TEE_COMBO

I've suggested to Kever that he doesn't actually need a separate type 
(though I could be wrong).

I resend my previous patchset renaming "optee" to "tee-standalone" and 
add the type IH_TYPE_TEE_STANDALONE.

I leave it to Kever to decide next steps for his patches.

---
bod

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Dr. Philipp Tomsich]

Bryan,

> On 21 Feb 2018, at 04:27, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
> 
> On 19/02/18 15:44, Tom Rini wrote:
>> On Fri, Feb 02, 2018 at 04:56:57PM +0100, Dr. Philipp Tomsich wrote:
>>> Bryan,
>>> 
>>>> On 2 Feb 2018, at 16:37, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 02/02/18 15:02, Dr. Philipp Tomsich wrote:
>>>>> Where do we stand on this: can we reuse IH_TYPE_TEE, will be use IH_TYPE_OPTEE or will there be a new IH_TYPE_OPTEE_SPL?
>>>> 
>>>> I think because you aren't doing anything different with the image type you can reuse IH_TYPE_TEE
>>>> 
>>>> This
>>>> 
>>>> +#if CONFIG_IS_ENABLED(OPTEE)
>>>> +	case IH_OS_OP_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
>>>> 
>>>> could just as easily be this
>>>> 
>>>> +#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
>>>> 
>>>> should be a matter of just replacing the call to mkimage to use
>>>> 
>>>> mkimage -A arm -T tee
>>>> 
>>>> instead of
>>>> 
>>>> mkimage -A arm -T optee
>>>> 
>>>> and the suggested change above.. case IH_OS_OP_TEE -> case IH_TYPE_TEE
>>> 
>>> Thanks for summarising your suggestion.
>>> 
>>> However, my mail was intended to test the waters to see what the consensus was.
>>> A it appears that none has yet emerged between all the involved parties (including
>>> our colleagues from TI that had also chimed in on the discussion).
>>> So for now, I’ll sit back and wait until some sort of consensus (or at least a majority
>>> for one solution or the other) emerges.
>>> 
>>> Personally, I am not happy with having a ‘tee’ and an ‘optee’ both refering to OP-TEE
>>> and the upstream OP-TEE documentation suggesting that their envisioned boot
>>> process was to boot through the OP-TEE (i.e. what the ‘tee’ image type does).
>>> However, with the ‘tee’ image type already being defined, we seem to have already
>>> backed ourselves into a situation where the naming is non-intuitive.
>> Alright, I'm a little confused here.  I guess first, there's a
>> disconnect in upstream OP-TEE land about how 32bit ARM should be done?
>> I guess we have three different implemented and upstreamed flows:
>> - SPL->U-Boot->OP-TEE->U-Boot->Linux
>> - SPL->U-Boot->OP-TEE->Linux
>> - SPL->OP-TEE->U-Boot->Linux
> 
> I'd call that
> 
> - SPL/BootROM->U-Boot->OP-TEE->U-Boot->Linux
> - SPL/BootROM->U-Boot->OP-TEE->Linux
> - SPL/BootROM->OP-TEE->U-Boot->Linux
> 
> But yes - fundamentally your flow is correct.
> 
>> And in this last case we have a combined image that is passed from SPL
>> to OP-TEE.
>> Since all 3 of these flows are in upstream OP-TEE, we need to support
>> them all. 
> 
> Agreed.
> 
>> The biggest constraint is that we have the first flow already
>> in and named "tee" (my fault, I should have made sure everyone would use
>> the same flow).  So we need to have descriptive enough names for the
>> other flows that we're going to add so that it's clear what's what.  How
>> about "tee-standalone" for "U-Boot starts OP-TEE, and is done"
> 
>> "tee-combo" for "SPL gives OP-TEE an image to deal with".  This could
>> even in theory I suspect be SPL gives OP-TEE a Linux kernel to boot.
>> I'm also happy to hear better suffixes but I don't want "tee" and
>> "optee".  And if we can cover two flows under the same name, that's good
>> too, we just need to name the last flow "tee-something".  Thanks all!
> 
> Yes I take your point "tee" and "optee" are the opposite of descriptive names.
> 
> - SPL/BootROM->U-Boot->OP-TEE->U-Boot->Linux
>  Currently called "tee" - has type IH_TEE - maintained as is for
>  compatibility - deserves some documentation.
> 
> - SPL/BootROM->U-Boot->OP-TEE->Linux
>  New type "tee-standalone" this would be the type I've proposed
>  in my patch set. New type IH_TYPE_TEE_STANDALONE
> 
> - SPL/BootROM->OP-TEE->U-Boot->Linux
>  New type "tee-combo" this would be Kever's type IH_TYPE_TEE_COMBO
> 
> I've suggested to Kever that he doesn't actually need a separate type (though I could be wrong).

My guess is that TEE_COMBO should cover Kever’s case.
We’ll probably need to wait and see if he encounters issues with this, once
he’s back after the Chinese New Year holiday.

> I resend my previous patchset renaming "optee" to "tee-standalone" and add the type IH_TYPE_TEE_STANDALONE.

As it looks as you’ll have your series revised first—could you add some
documentation that summarises the various the ways of how OPTEE
and some info on your use-case?

I’d then make sure (prior to merging) that Kever provides an update
against this file that provides more info on his use-case and implementation.

Thanks,
Philipp.

[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

[Andrew F. Davis]

On 02/20/2018 09:27 PM, Bryan O'Donoghue wrote:
> 
> 
> On 19/02/18 15:44, Tom Rini wrote:
>> On Fri, Feb 02, 2018 at 04:56:57PM +0100, Dr. Philipp Tomsich wrote:
>>> Bryan,
>>>
>>>> On 2 Feb 2018, at 16:37, Bryan O'Donoghue
>>>> <bryan.odonoghue@linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 02/02/18 15:02, Dr. Philipp Tomsich wrote:
>>>>> Where do we stand on this: can we reuse IH_TYPE_TEE, will be use
>>>>> IH_TYPE_OPTEE or will there be a new IH_TYPE_OPTEE_SPL?
>>>>
>>>> I think because you aren't doing anything different with the image
>>>> type you can reuse IH_TYPE_TEE
>>>>
>>>> This
>>>>
>>>> +#if CONFIG_IS_ENABLED(OPTEE)
>>>> +    case IH_OS_OP_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
>>>>
>>>> could just as easily be this
>>>>
>>>> +#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
>>>>
>>>> should be a matter of just replacing the call to mkimage to use
>>>>
>>>> mkimage -A arm -T tee
>>>>
>>>> instead of
>>>>
>>>> mkimage -A arm -T optee
>>>>
>>>> and the suggested change above.. case IH_OS_OP_TEE -> case IH_TYPE_TEE
>>>
>>> Thanks for summarising your suggestion.
>>>
>>> However, my mail was intended to test the waters to see what the
>>> consensus was.
>>> A it appears that none has yet emerged between all the involved
>>> parties (including
>>> our colleagues from TI that had also chimed in on the discussion).
>>> So for now, I’ll sit back and wait until some sort of consensus (or
>>> at least a majority
>>> for one solution or the other) emerges.
>>>
>>> Personally, I am not happy with having a ‘tee’ and an ‘optee’ both
>>> refering to OP-TEE
>>> and the upstream OP-TEE documentation suggesting that their
>>> envisioned boot
>>> process was to boot through the OP-TEE (i.e. what the ‘tee’ image
>>> type does).
>>> However, with the ‘tee’ image type already being defined, we seem to
>>> have already
>>> backed ourselves into a situation where the naming is non-intuitive.
>>
>> Alright, I'm a little confused here.  I guess first, there's a
>> disconnect in upstream OP-TEE land about how 32bit ARM should be done?
>> I guess we have three different implemented and upstreamed flows:
>> - SPL->U-Boot->OP-TEE->U-Boot->Linux
>> - SPL->U-Boot->OP-TEE->Linux
>> - SPL->OP-TEE->U-Boot->Linux
> 
> I'd call that
> 
> - SPL/BootROM->U-Boot->OP-TEE->U-Boot->Linux
> - SPL/BootROM->U-Boot->OP-TEE->Linux
> - SPL/BootROM->OP-TEE->U-Boot->Linux
> 
> But yes - fundamentally your flow is correct.
> 


I think it works better to have the secure/non-secure sides labeled,
here are two flows we support:

Non-Secure       Secure

                 BootROM
                   |
      -------------
     |
     v
    SPL
     |
     v
   U-Boot ------>
          <-----  OP-TEE
      |
      V
    Linux


Non-Secure       Secure

                 BootROM
                   |
      -------------
     |
     v
    SPL ------->
         <-----  OP-TEE
     |
     v
   U-Boot
      |
      V
    Linux

(Plus one were BootROM starts a TEE directly, but that is transparent to
SPL/U-Boot)

Both of these are handled by the IH_TEE type, which behaves much like a
regular function call in that it returns execution to were it was kicked
off from.

So to me there is only a need for two types, one like the above, and one
for when the TEE is a stage in the boot flow, whether in between
SPL->U-Boot or U-Boot->Linux, U-Boot needs to know it is not coming back
and so set it up like a regular OS payload.

>>
>> And in this last case we have a combined image that is passed from SPL
>> to OP-TEE.
>>
>> Since all 3 of these flows are in upstream OP-TEE, we need to support
>> them all. 
> 
> Agreed.
> 
>> The biggest constraint is that we have the first flow already
>> in and named "tee" (my fault, I should have made sure everyone would use
>> the same flow).  So we need to have descriptive enough names for the
>> other flows that we're going to add so that it's clear what's what.  How
>> about "tee-standalone" for "U-Boot starts OP-TEE, and is done"
> 
>> "tee-combo" for "SPL gives OP-TEE an image to deal with".  This could
>> even in theory I suspect be SPL gives OP-TEE a Linux kernel to boot.
>> I'm also happy to hear better suffixes but I don't want "tee" and
>> "optee".  And if we can cover two flows under the same name, that's good
>> too, we just need to name the last flow "tee-something".  Thanks all!
> 
> Yes I take your point "tee" and "optee" are the opposite of descriptive
> names.
> 
> - SPL/BootROM->U-Boot->OP-TEE->U-Boot->Linux
>   Currently called "tee" - has type IH_TEE - maintained as is for
>   compatibility - deserves some documentation.
> 
> - SPL/BootROM->U-Boot->OP-TEE->Linux
>   New type "tee-standalone" this would be the type I've proposed
>   in my patch set. New type IH_TYPE_TEE_STANDALONE
> 
> - SPL/BootROM->OP-TEE->U-Boot->Linux
>   New type "tee-combo" this would be Kever's type IH_TYPE_TEE_COMBO
> 


The two above didn't make sense to me until I realized their BootROM
starts SPL on the secure side, otherwise there would be no technical
reason not to have TEE return to the same spot in SPL/U-Boot. If I'm not
mistaken the two flows above look like this:

Non-Secure       Secure

                 BootROM
                   |
                   V
                  SPL
                   |
                   V
                OP-TEE
                   |
       -----------
      |
      V
    U-Boot
      |
      V
    Linux


Non-Secure       Secure

                 BootROM
                   |
                   V
                  SPL
                   |
                   V
                U-Boot
                   |
                   V
                OP-TEE
                  |
       ----------
      |
      V
    Linux


> I've suggested to Kever that he doesn't actually need a separate type
> (though I could be wrong).
> 
> I resend my previous patchset renaming "optee" to "tee-standalone" and
> add the type IH_TYPE_TEE_STANDALONE.
> 
> I leave it to Kever to decide next steps for his patches.
> 
> ---
> bod