[U-Boot] [PATCH 0/7] Adds support for secure boot on Keystone SoCs (K2E)
This series adds support for secure keystone family of devices, more specifically for K2E (Edison).This work is similar to what has already been done for the AM43xx and AM57xx SoCs and leverages much of the infrastructure from them.
The big difference here is the ROM on keystone2 devices does not provide any APIs for image authentication. Rather, the image authentication and decryption routines and other security functions are provided by software and can run on the ARM in Trustzone as well as on secure DSPs.
A component known as the boot monitor acts as they gateway to this secure processing, and abstracts out the details from the public world. Unlike OMAP class devices, where u-boot calls ROM APIs, u-boot calls into the boot- monitor on keystone devices.
Other than this difference, most of the secure framework for AMxx and DRAxx devices have been re-used.
Couple of other points to note :-
-Support for SPL on secure keystone devices is still TBD, so boot from SPI flash, which needs SPL, is not supported currently on K2 devices.
-A single image will work across all boot media for secure K2 devices.
Madan Srinivas (4): include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS arm: omap-common: Reuse secure image name between OMAP and keystone arm: mach-keystone: config.mk: Adds support for secure images on K2 doc: Updates info on using keystone secure devices from TI
Vitaly Andrianov (3): arm: mach-keystone: Implements FIT post-processing call for keystone SoCs arm: omap-common: Enable support for K2 HS devices in u-boot configs: Adds a defconfig for K2E High Security EVM
arch/arm/cpu/armv7/omap-common/Kconfig | 2 +- arch/arm/cpu/armv7/omap-common/config_secure.mk | 4 +- arch/arm/mach-keystone/config.mk | 6 +++ arch/arm/mach-keystone/mon.c | 53 +++++++++++++++++++++++++ configs/k2e_hs_evm_defconfig | 44 ++++++++++++++++++++ doc/README.ti-secure | 20 ++++++++++ include/image.h | 3 +- 7 files changed, 129 insertions(+), 3 deletions(-) create mode 100644 configs/k2e_hs_evm_defconfig
The function board_fit_image_post_process is defined only when the config CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure systems that do not use SPL but use FIT kernel images, only CONFIG_FIT_IMAGE_POST_PROCESS will defined, which will result in an implicit declaration of function 'board_fit_image_post_process' warning while building u-boot. This patch fixes this warning.
Signed-off-by: Madan Srinivas madans@ti.com ---
include/image.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/image.h b/include/image.h index 64da722..6884421 100644 --- a/include/image.h +++ b/include/image.h @@ -1245,7 +1245,8 @@ void android_print_contents(const struct andr_img_hdr *hdr); */ int board_fit_config_name_match(const char *name);
-#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS +#if defined(CONFIG_SPL_FIT_IMAGE_POST_PROCESS) || \ + defined(CONFIG_FIT_IMAGE_POST_PROCESS) /** * board_fit_image_post_process() - Do any post-process on FIT binary data *
On 08/26/2016 01:30 AM, Madan Srinivas wrote:
The function board_fit_image_post_process is defined only when the config
I think you mean "declared" here, it is "defined" when ether CONFIG_SPL_FIT_IMAGE_POST_PROCESS *or* CONFIG_FIT_IMAGE_POST_PROCESS is enabled, but only "declared" here in this header when the first is enabled.
CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure systems that do not use SPL but use FIT kernel images, only CONFIG_FIT_IMAGE_POST_PROCESS will
I think you are missing a word here. (will {be} defined)
defined, which will result in an implicit declaration of function 'board_fit_image_post_process' warning while building u-boot. This patch fixes this warning.
Signed-off-by: Madan Srinivas madans@ti.com
Otherwise looks good to me,
Acked-by: Andrew F. Davis afd@ti.com
include/image.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/image.h b/include/image.h index 64da722..6884421 100644 --- a/include/image.h +++ b/include/image.h @@ -1245,7 +1245,8 @@ void android_print_contents(const struct andr_img_hdr *hdr); */ int board_fit_config_name_match(const char *name);
-#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS +#if defined(CONFIG_SPL_FIT_IMAGE_POST_PROCESS) || \
- defined(CONFIG_FIT_IMAGE_POST_PROCESS)
/**
- board_fit_image_post_process() - Do any post-process on FIT binary data
From: Vitaly Andrianov vitalya@ti.com
This commit implements the board_fit_image_post_process() function for the keystone architecture. Unlike OMAP class devices, security functions in keystone are not handled in the ROM. The interface to the secure functions is TI proprietary and depending on the keystone platform, the security functions like encryption, decryption and authentication might even be offloaded to other secure processing elements in the SoC. The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure
Signed-off-by: Vitaly Andrianov vitalya@ti.com Signed-off-by: Madan Srinivas madans@ti.com ---
arch/arm/mach-keystone/mon.c | 53 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)
diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c index 256f630..b4a6f1c 100644 --- a/arch/arm/mach-keystone/mon.c +++ b/arch/arm/mach-keystone/mon.c @@ -12,10 +12,31 @@ #include <mach/mon.h> asm(".arch_extension sec\n\t");
+#ifdef CONFIG_TI_SECURE_DEVICE +#define KS2_HS_AUTH_FN_OFFSET 8 +#define KS2_HS_SEC_HEADER_LEN 0x60 +#define KS2_AUTH_CMD "2" +/** + * (*fn_auth)() - Invokes security functions using a + * proprietary TI interface. This binary and source for + * this is available in the secure development package or + * SECDEV. For details on how to access this please refer + * doc/README.ti-secure + * + * @first param: no. of parameters + * @second param: parameter list + * @return non-zero value on success, zero on error + */ +static unsigned int (*fn_auth)(int, char * const []); +#endif + int mon_install(u32 addr, u32 dpsc, u32 freq) { int result;
+#ifdef CONFIG_TI_SECURE_DEVICE + fn_auth = (void *)(addr + KS2_HS_AUTH_FN_OFFSET); +#endif __asm__ __volatile__ ( "stmfd r13!, {lr}\n" "mov r0, %1\n" @@ -61,3 +82,35 @@ int mon_power_off(int core_id) : "cc", "r0", "r1", "memory"); return result; } + +#ifdef CONFIG_TI_SECURE_DEVICE +static void k2_hs_auth(void *addr) +{ + char *argv1 = KS2_AUTH_CMD; + char argv2[32]; + char *argv[3] = {NULL, argv1, argv2}; + int ret; + + sprintf(argv2, "0x%08x", (u32)addr); + ret = fn_auth(3, argv); + + if (ret == 0) { + printf("FAIL!!!\n"); /* remove form production code */ + hang(); + } +} + +void board_fit_image_post_process(void **p_image, size_t *p_size) +{ + void *dst = *p_image; + void *src = dst + KS2_HS_SEC_HEADER_LEN; + + k2_hs_auth(*p_image); + + /* + * Overwrite the image headers after authentication + * and decryption. Move the image to its run address + */ + memcpy(dst, src, *p_size - KS2_HS_SEC_HEADER_LEN); +} +#endif
On 08/26/2016 01:30 AM, Madan Srinivas wrote:
From: Vitaly Andrianov vitalya@ti.com
This commit implements the board_fit_image_post_process() function for the keystone architecture. Unlike OMAP class devices, security functions in keystone are not handled in the ROM. The interface to the secure functions is TI proprietary and depending on the keystone platform, the security functions like encryption, decryption and authentication might even be offloaded to other secure processing elements in the SoC. The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure
Signed-off-by: Vitaly Andrianov vitalya@ti.com Signed-off-by: Madan Srinivas madans@ti.com
arch/arm/mach-keystone/mon.c | 53 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)
diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c index 256f630..b4a6f1c 100644 --- a/arch/arm/mach-keystone/mon.c +++ b/arch/arm/mach-keystone/mon.c @@ -12,10 +12,31 @@ #include <mach/mon.h> asm(".arch_extension sec\n\t");
+#ifdef CONFIG_TI_SECURE_DEVICE +#define KS2_HS_AUTH_FN_OFFSET 8 +#define KS2_HS_SEC_HEADER_LEN 0x60 +#define KS2_AUTH_CMD "2" +/**
- (*fn_auth)() - Invokes security functions using a
- proprietary TI interface. This binary and source for
- this is available in the secure development package or
- SECDEV. For details on how to access this please refer
- doc/README.ti-secure
- @first param: no. of parameters
- @second param: parameter list
- @return non-zero value on success, zero on error
- */
+static unsigned int (*fn_auth)(int, char * const []); +#endif
int mon_install(u32 addr, u32 dpsc, u32 freq) { int result;
+#ifdef CONFIG_TI_SECURE_DEVICE
- fn_auth = (void *)(addr + KS2_HS_AUTH_FN_OFFSET);
+#endif __asm__ __volatile__ ( "stmfd r13!, {lr}\n" "mov r0, %1\n" @@ -61,3 +82,35 @@ int mon_power_off(int core_id) : "cc", "r0", "r1", "memory"); return result; }
+#ifdef CONFIG_TI_SECURE_DEVICE +static void k2_hs_auth(void *addr) +{
- char *argv1 = KS2_AUTH_CMD;
- char argv2[32];
- char *argv[3] = {NULL, argv1, argv2};
- int ret;
- sprintf(argv2, "0x%08x", (u32)addr);
- ret = fn_auth(3, argv);
- if (ret == 0) {
Can this be if (!ret)?
printf("FAIL!!!\n"); /* remove form production code */
Wouldn't this be production code? If this print is intended to stay the s/form/from
Dan
hang();- }
+}
+void board_fit_image_post_process(void **p_image, size_t *p_size) +{
- void *dst = *p_image;
- void *src = dst + KS2_HS_SEC_HEADER_LEN;
- k2_hs_auth(*p_image);
- /*
- Overwrite the image headers after authentication
- and decryption. Move the image to its run address
- */
- memcpy(dst, src, *p_size - KS2_HS_SEC_HEADER_LEN);
+} +#endif
On Friday 26 August 2016 12:00 PM, Madan Srinivas wrote:
From: Vitaly Andrianov vitalya@ti.com
This commit implements the board_fit_image_post_process() function for the keystone architecture. Unlike OMAP class devices, security functions in keystone are not handled in the ROM. The interface to the secure functions is TI proprietary and depending on the keystone platform, the security functions like encryption, decryption and authentication might even be offloaded to other secure processing elements in the SoC. The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure
Signed-off-by: Vitaly Andrianov vitalya@ti.com Signed-off-by: Madan Srinivas madans@ti.com
arch/arm/mach-keystone/mon.c | 53 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)
diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c index 256f630..b4a6f1c 100644 --- a/arch/arm/mach-keystone/mon.c +++ b/arch/arm/mach-keystone/mon.c @@ -12,10 +12,31 @@ #include <mach/mon.h> asm(".arch_extension sec\n\t");
+#ifdef CONFIG_TI_SECURE_DEVICE +#define KS2_HS_AUTH_FN_OFFSET 8 +#define KS2_HS_SEC_HEADER_LEN 0x60 +#define KS2_AUTH_CMD "2" +/**
- (*fn_auth)() - Invokes security functions using a
- proprietary TI interface. This binary and source for
- this is available in the secure development package or
- SECDEV. For details on how to access this please refer
- doc/README.ti-secure
- @first param: no. of parameters
- @second param: parameter list
- @return non-zero value on success, zero on error
- */
+static unsigned int (*fn_auth)(int, char * const []); +#endif
int mon_install(u32 addr, u32 dpsc, u32 freq) { int result;
+#ifdef CONFIG_TI_SECURE_DEVICE
- fn_auth = (void *)(addr + KS2_HS_AUTH_FN_OFFSET);
+#endif __asm__ __volatile__ ( "stmfd r13!, {lr}\n" "mov r0, %1\n" @@ -61,3 +82,35 @@ int mon_power_off(int core_id) : "cc", "r0", "r1", "memory"); return result; }
+#ifdef CONFIG_TI_SECURE_DEVICE +static void k2_hs_auth(void *addr) +{
- char *argv1 = KS2_AUTH_CMD;
- char argv2[32];
- char *argv[3] = {NULL, argv1, argv2};
- int ret;
- sprintf(argv2, "0x%08x", (u32)addr);
- ret = fn_auth(3, argv);
Can fn_auth be checked before calling it? Just to make sure monitor is installed before processing any image.
- if (ret == 0) {
printf("FAIL!!!\n"); /* remove form production code */hang();- }
+}
+void board_fit_image_post_process(void **p_image, size_t *p_size) +{
- void *dst = *p_image;
- void *src = dst + KS2_HS_SEC_HEADER_LEN;
- k2_hs_auth(*p_image);
- /*
- Overwrite the image headers after authentication
- and decryption. Move the image to its run address
- */
- memcpy(dst, src, *p_size - KS2_HS_SEC_HEADER_LEN);
Technically image is not being moved to its run address. This is just updating FIT image after post processing. Also, *p_size should be updated to remove header size.
Thanks and regards, Lokesh
+} +#endif
From: Vitaly Andrianov vitalya@ti.com
Like the OMAP54xx, AM43xx & AM33xx family SoCs, the keystone family of SoCs also have high security enabled models. Allow K2E devices to be built with HS Device Type Support.
This patch applies on top of the patch ti: omap-common: Allow AM33xx devices to be built securely sumitted by Andrew Davis
Signed-off-by: Vitaly Andrianov vitalya@ti.com Signed-off-by: Madan Srinivas madans@ti.com ---
arch/arm/cpu/armv7/omap-common/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig b/arch/arm/cpu/armv7/omap-common/Kconfig index 4daccd9..91d6b2c 100644 --- a/arch/arm/cpu/armv7/omap-common/Kconfig +++ b/arch/arm/cpu/armv7/omap-common/Kconfig @@ -1,6 +1,6 @@ config TI_SECURE_DEVICE bool "HS Device Type Support" - depends on OMAP54XX || AM43XX || AM33XX + depends on OMAP54XX || AM43XX || AM33XX || ARCH_KEYSTONE help If a high secure (HS) device type is being used, this config must be set. This option impacts various aspects of the
On 08/26/2016 01:30 AM, Madan Srinivas wrote:
From: Vitaly Andrianov vitalya@ti.com
Like the OMAP54xx, AM43xx & AM33xx family SoCs, the keystone family of SoCs also have high security enabled models. Allow K2E devices to be built with HS Device Type Support.
This patch applies on top of the patch ti: omap-common: Allow AM33xx devices to be built securely sumitted by Andrew Davis
Signed-off-by: Vitaly Andrianov vitalya@ti.com Signed-off-by: Madan Srinivas madans@ti.com
Acked-by: Andrew F. Davis afd@ti.com
arch/arm/cpu/armv7/omap-common/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig b/arch/arm/cpu/armv7/omap-common/Kconfig index 4daccd9..91d6b2c 100644 --- a/arch/arm/cpu/armv7/omap-common/Kconfig +++ b/arch/arm/cpu/armv7/omap-common/Kconfig @@ -1,6 +1,6 @@ config TI_SECURE_DEVICE bool "HS Device Type Support"
- depends on OMAP54XX || AM43XX || AM33XX
- depends on OMAP54XX || AM43XX || AM33XX || ARCH_KEYSTONE help If a high secure (HS) device type is being used, this config must be set. This option impacts various aspects of the
On 08/26/2016 01:30 AM, Madan Srinivas wrote:
From: Vitaly Andrianov vitalya@ti.com
Like the OMAP54xx, AM43xx & AM33xx family SoCs, the keystone family of SoCs also have high security enabled models. Allow K2E devices to be built with HS Device Type Support.
This patch applies on top of the patch ti: omap-common: Allow AM33xx devices to be built securely sumitted by Andrew Davis
Signed-off-by: Vitaly Andrianov vitalya@ti.com Signed-off-by: Madan Srinivas madans@ti.com
arch/arm/cpu/armv7/omap-common/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig b/arch/arm/cpu/armv7/omap-common/Kconfig index 4daccd9..91d6b2c 100644 --- a/arch/arm/cpu/armv7/omap-common/Kconfig +++ b/arch/arm/cpu/armv7/omap-common/Kconfig @@ -1,6 +1,6 @@ config TI_SECURE_DEVICE bool "HS Device Type Support"
- depends on OMAP54XX || AM43XX || AM33XX
- depends on OMAP54XX || AM43XX || AM33XX || ARCH_KEYSTONE help If a high secure (HS) device type is being used, this config must be set. This option impacts various aspects of the
Acked-by: Dan Murphy dmurphy@ti.com
As K2 can directly boot u-boot, re-use u-boot_HS_XIP_X-LOADER as the secure image while booting secure K2 devices. Updates the comments in the file to reflect this.
Signed-off-by: Madan Srinivas madans@ti.com ---
arch/arm/cpu/armv7/omap-common/config_secure.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk b/arch/arm/cpu/armv7/omap-common/config_secure.mk index 1122439..ae5e8de 100644 --- a/arch/arm/cpu/armv7/omap-common/config_secure.mk +++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk @@ -78,7 +78,9 @@ u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin
# For supporting single stage XiP QSPI on AM43xx, the image is a full u-boot # file, not an SPL. In this case the mkomapsecimg command looks for a -# u-boot-HS_* prefix +# u-boot-HS_* prefix. Keystone devices also support a single stage boot +# so this image can be used for booting from all media on keystone +# secure devices u-boot_HS_XIP_X-LOADER: $(obj)/u-boot.bin $(call if_changed,mkomapsecimg)
On 08/26/2016 01:30 AM, Madan Srinivas wrote:
As K2 can directly boot u-boot, re-use u-boot_HS_XIP_X-LOADER as the secure image while booting secure K2 devices. Updates the comments in the file to reflect this.
Signed-off-by: Madan Srinivas madans@ti.com
arch/arm/cpu/armv7/omap-common/config_secure.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk b/arch/arm/cpu/armv7/omap-common/config_secure.mk index 1122439..ae5e8de 100644 --- a/arch/arm/cpu/armv7/omap-common/config_secure.mk +++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk @@ -78,7 +78,9 @@ u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin
# For supporting single stage XiP QSPI on AM43xx, the image is a full u-boot
If we are re-using this name for as the various mode image for K2, then this above line is wrong, and much of the XIP* info in this file is then wrong.
I think it would make more sense to just go ahead and add a new target for this, u-boot_HS_MLO perhaps, as the "MLO" target is already used for K2 as the general boot media target.
# file, not an SPL. In this case the mkomapsecimg command looks for a -# u-boot-HS_* prefix +# u-boot-HS_* prefix. Keystone devices also support a single stage boot +# so this image can be used for booting from all media on keystone +# secure devices u-boot_HS_XIP_X-LOADER: $(obj)/u-boot.bin $(call if_changed,mkomapsecimg)
Adds an additional image type needed for supporting secure keystone devices. The build generates u-boot_HS_XIP_X-LOADER which can be used to boot from all media on secure keystone devices.
Signed-off-by: Madan Srinivas madans@ti.com ---
arch/arm/mach-keystone/config.mk | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-keystone/config.mk b/arch/arm/mach-keystone/config.mk index 9ae1e9a..565d718 100644 --- a/arch/arm/mach-keystone/config.mk +++ b/arch/arm/mach-keystone/config.mk @@ -5,9 +5,15 @@ # SPDX-License-Identifier: GPL-2.0+ #
+include $(srctree)/$(CPUDIR)/omap-common/config_secure.mk + ifndef CONFIG_SPL_BUILD +ifeq ($(CONFIG_TI_SECURE_DEVICE),y) +ALL-y += u-boot_HS_XIP_X-LOADER +else ALL-y += MLO endif +endif
MKIMAGEFLAGS_u-boot-spl.gph = -A $(ARCH) -T gpimage -C none \ -a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) -n SPL
On 08/26/2016 01:30 AM, Madan Srinivas wrote:
Adds an additional image type needed for supporting secure keystone devices. The build generates u-boot_HS_XIP_X-LOADER which can be used to boot from all media on secure keystone devices.
Signed-off-by: Madan Srinivas madans@ti.com
arch/arm/mach-keystone/config.mk | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-keystone/config.mk b/arch/arm/mach-keystone/config.mk index 9ae1e9a..565d718 100644 --- a/arch/arm/mach-keystone/config.mk +++ b/arch/arm/mach-keystone/config.mk @@ -5,9 +5,15 @@ # SPDX-License-Identifier: GPL-2.0+ #
+include $(srctree)/$(CPUDIR)/omap-common/config_secure.mk
ifndef CONFIG_SPL_BUILD +ifeq ($(CONFIG_TI_SECURE_DEVICE),y) +ALL-y += u-boot_HS_XIP_X-LOADER
Same comment as before, u-boot_HS_MLO here would match the regular MLO target below.
+else ALL-y += MLO endif +endif
MKIMAGEFLAGS_u-boot-spl.gph = -A $(ARCH) -T gpimage -C none \ -a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) -n SPL
Add a section describing the secure boot image used on keystone secure devices.
This patch applies on top of the patch doc: Update info on using AM33xx secure devices from TI submitted by Andrew Davis
Signed-off-by: Madan Srinivas madans@ti.com ---
doc/README.ti-secure | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
diff --git a/doc/README.ti-secure b/doc/README.ti-secure index 9b0fbf9..ffda69a 100644 --- a/doc/README.ti-secure +++ b/doc/README.ti-secure @@ -133,6 +133,26 @@ Booting of U-Boot SPL u-boot-spl_HS_X-LOADER - boot image for all other flash memories including QSPI and NOR flash
+ Invoking the script for Keystone Secure Devices + ============================================= + + create-boot-image.sh \ + <UNUSED> <INPUT_FILE> <OUTPUT_FILE> <UNUSED> + + <UNUSED> is currently ignored and reserved for future use. + + <INPUT_FILE> is the full path and filename of the public world boot + loader binary file (only u-boot.bin is currently supported on + keystone devices, u-boot-spl.bin is not currently supported). + + <OUTPUT_FILE> is the full path and filename of the final secure + image. The output binary images should be used in place of the standard + non-secure binary images (see the platform-specific user's guides and + releases notes for how the non-secure images are typically used) + u-boot_HS_XIP_X-LOADER - signed and encrypted boot image that can + be used to boot from all media. Secure boot from SPI NOR + flash is not currently supported. + Booting of Primary U-Boot (u-boot.img) ======================================
From: Vitaly Andrianov vitalya@ti.com
Add a new defconfig file for the K2E High Security EVM.
This defconfig is the same as for the non-secure part, except for: CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_FIT option set to 'y' CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'
Enables the platform-specific post-processing of FIT-extracted blobs such as Kernel, DTB, and initramfs on TI K2E high-security (HS) devices which will ultimately invokes TI proprietary secure functions that performs secure processing such as blob authentication and decryption.
Signed-off-by: Vitaly Andrianov vitalya@ti.com Signed-off-by: Madan Srinivas madans@ti.com ---
configs/k2e_hs_evm_defconfig | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 configs/k2e_hs_evm_defconfig
diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig new file mode 100644 index 0000000..ec0542d --- /dev/null +++ b/configs/k2e_hs_evm_defconfig @@ -0,0 +1,44 @@ +CONFIG_ARM=y +CONFIG_ARCH_KEYSTONE=y +CONFIG_TARGET_K2E_EVM=y +CONFIG_DM_SERIAL=y +CONFIG_DEFAULT_DEVICE_TREE="k2e-evm" +CONFIG_SPL=y +CONFIG_OF_BOARD_SETUP=y +CONFIG_HUSH_PARSER=y +CONFIG_SYS_PROMPT="K2E EVM # " +CONFIG_CMD_BOOTZ=y +# CONFIG_CMD_IMLS is not set +CONFIG_CMD_ASKENV=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_NAND=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_OF_CONTROL=y +CONFIG_DM=y +CONFIG_TI_AEMIF=y +CONFIG_DM_SPI=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_DM_ETH=y +CONFIG_SYS_NS16550=y +CONFIG_USB=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_LIB_RAND=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_TI_SECURE_DEVICE=y +CONFIG_FIT=y +CONFIG_FIT_IMAGE_POST_PROCESS=y
On 08/26/2016 01:30 AM, Madan Srinivas wrote:
From: Vitaly Andrianov vitalya@ti.com
Add a new defconfig file for the K2E High Security EVM.
This defconfig is the same as for the non-secure part, except for: CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_FIT option set to 'y' CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'
Enables the platform-specific post-processing of FIT-extracted blobs such as Kernel, DTB, and initramfs on TI K2E high-security (HS) devices which will ultimately invokes TI proprietary secure functions that performs secure processing such as blob authentication and decryption.
Signed-off-by: Vitaly Andrianov vitalya@ti.com Signed-off-by: Madan Srinivas madans@ti.com
configs/k2e_hs_evm_defconfig | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 configs/k2e_hs_evm_defconfig
diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig new file mode 100644 index 0000000..ec0542d --- /dev/null +++ b/configs/k2e_hs_evm_defconfig @@ -0,0 +1,44 @@ +CONFIG_ARM=y +CONFIG_ARCH_KEYSTONE=y +CONFIG_TARGET_K2E_EVM=y +CONFIG_DM_SERIAL=y +CONFIG_DEFAULT_DEVICE_TREE="k2e-evm" +CONFIG_SPL=y +CONFIG_OF_BOARD_SETUP=y +CONFIG_HUSH_PARSER=y +CONFIG_SYS_PROMPT="K2E EVM # " +CONFIG_CMD_BOOTZ=y +# CONFIG_CMD_IMLS is not set +CONFIG_CMD_ASKENV=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_NAND=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_OF_CONTROL=y +CONFIG_DM=y +CONFIG_TI_AEMIF=y +CONFIG_DM_SPI=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_DM_ETH=y +CONFIG_SYS_NS16550=y +CONFIG_USB=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_LIB_RAND=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_TI_SECURE_DEVICE=y +CONFIG_FIT=y +CONFIG_FIT_IMAGE_POST_PROCESS=y
Although it makes it more clear when adding new options to add them to the end, when someone regenerates this defconfig with savedefconfig or similar tools, these options will get moved up into their natural order, causing more delta to their patches than necessary. This should be regenerated (make k2e_hs_evm_defconfig; make savedefconfig; cp defconfig configs/k2e_hs_evm_defconfig).
participants (4)
-
Andrew F. Davis -
Dan Murphy -
Lokesh Vutla -
Madan Srinivas