* [U-Boot] [PATCH v4 01/11] lib: add TPL_OF_LIBFDT option for TPL
2018-01-04 7:06 [U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229 Kever Yang
@ 2018-01-04 7:07 ` Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 02/11] arm: add option for TPL ARCH_MEM in arm 32bit Kever Yang
` (9 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Kever Yang @ 2018-01-04 7:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [U-Boot] [PATCH v4 02/11] arm: add option for TPL ARCH_MEM in arm 32bit
2018-01-04 7:06 [U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229 Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 01/11] lib: add TPL_OF_LIBFDT option for TPL Kever Yang
@ 2018-01-04 7:07 ` Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 03/11] arm: add a separate stack for TPL Kever Yang
` (8 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Kever Yang @ 2018-01-04 7:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [U-Boot] [PATCH v4 03/11] arm: add a separate stack for TPL
2018-01-04 7:06 [U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229 Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 01/11] lib: add TPL_OF_LIBFDT option for TPL Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 02/11] arm: add option for TPL ARCH_MEM in arm 32bit Kever Yang
@ 2018-01-04 7:07 ` Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 04/11] rockchip: rk322x: enable tpl support Kever Yang
` (7 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Kever Yang @ 2018-01-04 7:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [U-Boot] [PATCH v4 04/11] rockchip: rk322x: enable tpl support
2018-01-04 7:06 [U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229 Kever Yang
` (2 preceding siblings ...)
2018-01-04 7:07 ` [U-Boot] [PATCH v4 03/11] arm: add a separate stack for TPL Kever Yang
@ 2018-01-04 7:07 ` Kever Yang
2018-01-12 11:27 ` [U-Boot] [U-Boot, v4, " Philipp Tomsich
2018-01-25 9:46 ` Philipp Tomsich
2018-01-04 7:07 ` [U-Boot] [PATCH v4 05/11] sysreset: enable driver support in SPL/TPL Kever Yang
` (6 subsequent siblings)
10 siblings, 2 replies; 30+ messages in thread
From: Kever Yang @ 2018-01-04 7:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 04/11] rockchip: rk322x: enable tpl support
2018-01-04 7:07 ` [U-Boot] [PATCH v4 04/11] rockchip: rk322x: enable tpl support Kever Yang
@ 2018-01-12 11:27 ` Philipp Tomsich
2018-01-25 9:46 ` Philipp Tomsich
1 sibling, 0 replies; 30+ messages in thread
From: Philipp Tomsich @ 2018-01-12 11:27 UTC (permalink / raw)
To: u-boot
> 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>
^ permalink raw reply [flat|nested] 30+ messages in thread
* [U-Boot] [U-Boot, v4, 04/11] rockchip: rk322x: enable tpl support
2018-01-04 7:07 ` [U-Boot] [PATCH v4 04/11] rockchip: rk322x: enable tpl support Kever Yang
2018-01-12 11:27 ` [U-Boot] [U-Boot, v4, " Philipp Tomsich
@ 2018-01-25 9:46 ` Philipp Tomsich
1 sibling, 0 replies; 30+ messages in thread
From: Philipp Tomsich @ 2018-01-25 9:46 UTC (permalink / raw)
To: u-boot
> 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>
^ permalink raw reply [flat|nested] 30+ messages in thread
* [U-Boot] [PATCH v4 05/11] sysreset: enable driver support in SPL/TPL
2018-01-04 7:06 [U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229 Kever Yang
` (3 preceding siblings ...)
2018-01-04 7:07 ` [U-Boot] [PATCH v4 04/11] rockchip: rk322x: enable tpl support Kever Yang
@ 2018-01-04 7:07 ` Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 06/11] image: add os type for OP-TEE Kever Yang
` (5 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Kever Yang @ 2018-01-04 7:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [U-Boot] [PATCH v4 06/11] image: add os type for OP-TEE
2018-01-04 7:06 [U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229 Kever Yang
` (4 preceding siblings ...)
2018-01-04 7:07 ` [U-Boot] [PATCH v4 05/11] sysreset: enable driver support in SPL/TPL Kever Yang
@ 2018-01-04 7:07 ` Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 07/11] spl: add support to booting with OP-TEE Kever Yang
` (4 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Kever Yang @ 2018-01-04 7:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [U-Boot] [PATCH v4 07/11] spl: add support to booting with OP-TEE
2018-01-04 7:06 [U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229 Kever Yang
` (5 preceding siblings ...)
2018-01-04 7:07 ` [U-Boot] [PATCH v4 06/11] image: add os type for OP-TEE Kever Yang
@ 2018-01-04 7:07 ` Kever Yang
2018-01-12 11:27 ` [U-Boot] [U-Boot, v4, " Philipp Tomsich
2018-01-25 9:46 ` Philipp Tomsich
2018-01-04 7:07 ` [U-Boot] [PATCH v4 08/11] rockchip: rk322x: dts: enable uart2 for SPL/TPL Kever Yang
` (3 subsequent siblings)
10 siblings, 2 replies; 30+ messages in thread
From: Kever Yang @ 2018-01-04 7:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-01-04 7:07 ` [U-Boot] [PATCH v4 07/11] spl: add support to booting with OP-TEE Kever Yang
@ 2018-01-12 11:27 ` Philipp Tomsich
2018-01-12 15:10 ` Bryan O'Donoghue
2018-01-25 9:46 ` Philipp Tomsich
1 sibling, 1 reply; 30+ messages in thread
From: Philipp Tomsich @ 2018-01-12 11:27 UTC (permalink / raw)
To: u-boot
> 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>
^ permalink raw reply [flat|nested] 30+ messages in thread
* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-01-12 11:27 ` [U-Boot] [U-Boot, v4, " Philipp Tomsich
@ 2018-01-12 15:10 ` Bryan O'Donoghue
2018-01-15 3:25 ` Kever Yang
0 siblings, 1 reply; 30+ messages in thread
From: Bryan O'Donoghue @ 2018-01-12 15:10 UTC (permalink / raw)
To: u-boot
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..
^ permalink raw reply [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-01-12 15:10 ` Bryan O'Donoghue
@ 2018-01-15 3:25 ` Kever Yang
2018-01-15 4:48 ` Peng Fan
0 siblings, 1 reply; 30+ messages in thread
From: Kever Yang @ 2018-01-15 3:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-01-15 3:25 ` Kever Yang
@ 2018-01-15 4:48 ` Peng Fan
2018-01-17 17:48 ` Bryan O'Donoghue
0 siblings, 1 reply; 30+ messages in thread
From: Peng Fan @ 2018-01-15 4:48 UTC (permalink / raw)
To: u-boot
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
--
^ permalink raw reply [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-01-15 4:48 ` Peng Fan
@ 2018-01-17 17:48 ` Bryan O'Donoghue
2018-01-18 1:31 ` Kever Yang
0 siblings, 1 reply; 30+ messages in thread
From: Bryan O'Donoghue @ 2018-01-17 17:48 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-01-17 17:48 ` Bryan O'Donoghue
@ 2018-01-18 1:31 ` Kever Yang
2018-01-18 11:21 ` Bryan O'Donoghue
0 siblings, 1 reply; 30+ messages in thread
From: Kever Yang @ 2018-01-18 1:31 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-01-18 1:31 ` Kever Yang
@ 2018-01-18 11:21 ` Bryan O'Donoghue
2018-01-25 10:09 ` Bryan O'Donoghue
0 siblings, 1 reply; 30+ messages in thread
From: Bryan O'Donoghue @ 2018-01-18 11:21 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-01-18 11:21 ` Bryan O'Donoghue
@ 2018-01-25 10:09 ` Bryan O'Donoghue
2018-02-02 15:02 ` Dr. Philipp Tomsich
0 siblings, 1 reply; 30+ messages in thread
From: Bryan O'Donoghue @ 2018-01-25 10:09 UTC (permalink / raw)
To: u-boot
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 ?
^ permalink raw reply [flat|nested] 30+ messages in thread
* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-01-25 10:09 ` Bryan O'Donoghue
@ 2018-02-02 15:02 ` Dr. Philipp Tomsich
2018-02-02 15:37 ` Bryan O'Donoghue
0 siblings, 1 reply; 30+ messages in thread
From: Dr. Philipp Tomsich @ 2018-02-02 15:02 UTC (permalink / raw)
To: u-boot
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-02-02 15:02 ` Dr. Philipp Tomsich
@ 2018-02-02 15:37 ` Bryan O'Donoghue
2018-02-02 15:56 ` Dr. Philipp Tomsich
0 siblings, 1 reply; 30+ messages in thread
From: Bryan O'Donoghue @ 2018-02-02 15:37 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-02-02 15:37 ` Bryan O'Donoghue
@ 2018-02-02 15:56 ` Dr. Philipp Tomsich
2018-02-19 15:44 ` Tom Rini
0 siblings, 1 reply; 30+ messages in thread
From: Dr. Philipp Tomsich @ 2018-02-02 15:56 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-02-02 15:56 ` Dr. Philipp Tomsich
@ 2018-02-19 15:44 ` Tom Rini
2018-02-21 3:27 ` Bryan O'Donoghue
0 siblings, 1 reply; 30+ messages in thread
From: Tom Rini @ 2018-02-19 15:44 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-02-19 15:44 ` Tom Rini
@ 2018-02-21 3:27 ` Bryan O'Donoghue
2018-02-21 13:16 ` Dr. Philipp Tomsich
2018-02-21 14:30 ` Andrew F. Davis
0 siblings, 2 replies; 30+ messages in thread
From: Bryan O'Donoghue @ 2018-02-21 3:27 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-02-21 3:27 ` Bryan O'Donoghue
@ 2018-02-21 13:16 ` Dr. Philipp Tomsich
2018-02-21 14:30 ` Andrew F. Davis
1 sibling, 0 replies; 30+ messages in thread
From: Dr. Philipp Tomsich @ 2018-02-21 13:16 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-02-21 3:27 ` Bryan O'Donoghue
2018-02-21 13:16 ` Dr. Philipp Tomsich
@ 2018-02-21 14:30 ` Andrew F. Davis
1 sibling, 0 replies; 30+ messages in thread
From: Andrew F. Davis @ 2018-02-21 14:30 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE
2018-01-04 7:07 ` [U-Boot] [PATCH v4 07/11] spl: add support to booting with OP-TEE Kever Yang
2018-01-12 11:27 ` [U-Boot] [U-Boot, v4, " Philipp Tomsich
@ 2018-01-25 9:46 ` Philipp Tomsich
1 sibling, 0 replies; 30+ messages in thread
From: Philipp Tomsich @ 2018-01-25 9:46 UTC (permalink / raw)
To: u-boot
> 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>
^ permalink raw reply [flat|nested] 30+ messages in thread
* [U-Boot] [PATCH v4 08/11] rockchip: rk322x: dts: enable uart2 for SPL/TPL
2018-01-04 7:06 [U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229 Kever Yang
` (6 preceding siblings ...)
2018-01-04 7:07 ` [U-Boot] [PATCH v4 07/11] spl: add support to booting with OP-TEE Kever Yang
@ 2018-01-04 7:07 ` Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 09/11] rockchip: add fit source file for pack itb with op-tee Kever Yang
` (2 subsequent siblings)
10 siblings, 0 replies; 30+ messages in thread
From: Kever Yang @ 2018-01-04 7:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [U-Boot] [PATCH v4 09/11] rockchip: add fit source file for pack itb with op-tee
2018-01-04 7:06 [U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229 Kever Yang
` (7 preceding siblings ...)
2018-01-04 7:07 ` [U-Boot] [PATCH v4 08/11] rockchip: rk322x: dts: enable uart2 for SPL/TPL Kever Yang
@ 2018-01-04 7:07 ` Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 10/11] rockchip: evb-rk3229: add README file for OP-TEE support Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 11/11] rockchip: evb-rk322x: update defconfig with tpl and optee support Kever Yang
10 siblings, 0 replies; 30+ messages in thread
From: Kever Yang @ 2018-01-04 7:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [U-Boot] [PATCH v4 10/11] rockchip: evb-rk3229: add README file for OP-TEE support
2018-01-04 7:06 [U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229 Kever Yang
` (8 preceding siblings ...)
2018-01-04 7:07 ` [U-Boot] [PATCH v4 09/11] rockchip: add fit source file for pack itb with op-tee Kever Yang
@ 2018-01-04 7:07 ` Kever Yang
2018-01-04 7:07 ` [U-Boot] [PATCH v4 11/11] rockchip: evb-rk322x: update defconfig with tpl and optee support Kever Yang
10 siblings, 0 replies; 30+ messages in thread
From: Kever Yang @ 2018-01-04 7:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [U-Boot] [PATCH v4 11/11] rockchip: evb-rk322x: update defconfig with tpl and optee support
2018-01-04 7:06 [U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229 Kever Yang
` (9 preceding siblings ...)
2018-01-04 7:07 ` [U-Boot] [PATCH v4 10/11] rockchip: evb-rk3229: add README file for OP-TEE support Kever Yang
@ 2018-01-04 7:07 ` Kever Yang
10 siblings, 0 replies; 30+ messages in thread
From: Kever Yang @ 2018-01-04 7:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 30+ messages in thread