[U-Boot] [PATCH v4 00/11] rockchip: add tpl and OPTEE support for rk3229
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
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
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
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)
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"
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
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
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
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, };
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
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
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@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..
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@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_...
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@lists.denx.de https://lists.denx.de/listinfo/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@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_...
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@lists.denx.de https://lists.denx.de/listinfo/u-boot
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/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@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
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@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
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
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 ?
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.
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
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.
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!
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
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.
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
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
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"; };
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@1 { + description = "U-Boot"; + data = /incbin/("../../../u-boot-nodtb.bin"); + type = "standalone"; + os = "U-Boot"; + arch = "arm"; + compression = "none"; + load = <0x61000000>; + }; + optee@1 { + description = "OP-TEE"; + data = /incbin/("../../../tee.bin"); + type = "firmware"; + arch = "arm"; + os = "op-tee"; + compression = "none"; + load = <0x68400000>; + entry = <0x68400000>; + }; + fdt@1 { + description = "dtb"; + data = /incbin/("../../../u-boot.dtb"); + type = "flat_dt"; + compression = "none"; + }; + }; + + configurations { + default = "conf@1"; + conf@1 { + description = "Rockchip armv7 with OP-TEE"; + firmware = "optee@1"; + loadables = "uboot@1"; + fdt = "fdt@1"; + }; + }; +};
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
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"
participants (7)
-
Andrew F. Davis -
Bryan O'Donoghue -
Dr. Philipp Tomsich -
Kever Yang -
Peng Fan -
Philipp Tomsich
-
Tom Rini