[PATCH 0/5] add support for hs bootflows to am62a

Hello everyone!
Texas Instruments has started to enable security settings inside all the boot ROM and TIFS firmware in all of their SoCs. One of the few changes this brings is ROM and TIFS will now begin protecting the RAM regions they're using with firewalls.
This means the wakeup domain's SPL will need to move the stack and heap to HSM RAM to ensure it stays within its allotted memory regions as well as move the needed boot information to the main domain's bootloaders that will no longer have access to HSM RAM.
We will also need to edit the bootcmd to pull in the kernel and dtb's fitImage if uboot is enforcing the high security bootflow. While we're editing this bootcmd, we can also take the opportunity to convert it to a distro_bootcmd macro.
Thanks for reviewing! ~Bryan
Bryan Brattlof (5): configs: restrict am62ax wakup SPL size configs: am62a: move stack and heap to HSM RAM arm: mach-k3: copy bootindex to OCRAM for main domain SPL configs: am62a: convert bootcmd to distro_bootcmd configs: am62a: use kernel fitImage when using secure bootflow
arch/arm/mach-k3/Kconfig | 4 ++- arch/arm/mach-k3/am62a7_init.c | 16 +++++++-- .../arm/mach-k3/include/mach/am62a_hardware.h | 17 +++++++++- configs/am62ax_evm_a53_defconfig | 1 - configs/am62ax_evm_r5_defconfig | 15 +++++--- include/configs/am62ax_evm.h | 34 +++++++++++++++++-- 6 files changed, 74 insertions(+), 13 deletions(-)
base-commit: 52d91e1c20b399ddab276e2c03e5788ed5e5fdd2

In its current form, the am62a's wakeup SPL is fairly small, however this will not remain as more boot modes are eventually added. To protect us from overflowing our ~256k of HSM SRAM, add limits and check during the wakeup SPL build.
Signed-off-by: Bryan Brattlof bb@ti.com --- configs/am62ax_evm_r5_defconfig | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/configs/am62ax_evm_r5_defconfig b/configs/am62ax_evm_r5_defconfig index 59d5f4f80eb8d..bfffb8eef77d8 100644 --- a/configs/am62ax_evm_r5_defconfig +++ b/configs/am62ax_evm_r5_defconfig @@ -13,7 +13,9 @@ CONFIG_SPL_TEXT_BASE=0x43c00000 CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y CONFIG_SPL_STACK_R_ADDR=0x82000000 -CONFIG_SPL_SIZE_LIMIT=0x40000 +CONFIG_SPL_SYS_MALLOC_F_LEN=0x7145 +CONFIG_SPL_SIZE_LIMIT=0x3A7F0 +CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x3500 CONFIG_SPL_FS_FAT=y CONFIG_SPL_LIBDISK_SUPPORT=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y @@ -22,11 +24,14 @@ CONFIG_SPL_LOAD_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x80080000 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y # CONFIG_DISPLAY_CPUINFO is not set -CONFIG_SPL_MAX_SIZE=0x58000 +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y +CONFIG_SPL_MAX_SIZE=0x3B000 CONFIG_SPL_PAD_TO=0x0 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y -CONFIG_SPL_BSS_START_ADDR=0x43c37800 -CONFIG_SPL_BSS_MAX_SIZE=0x5000 +CONFIG_SPL_BSS_START_ADDR=0x43c3b000 +CONFIG_SPL_BSS_MAX_SIZE=0x3000 +CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y

On Fri, Dec 23, 2022 at 07:15:21PM -0600, Bryan Brattlof wrote:
In its current form, the am62a's wakeup SPL is fairly small, however this will not remain as more boot modes are eventually added. To protect us from overflowing our ~256k of HSM SRAM, add limits and check during the wakeup SPL build.
Signed-off-by: Bryan Brattlof bb@ti.com
Applied to u-boot/master, thanks!

Texas Instruments has begun enabling security setting on the SoCs they produce to instruct ROM and TIFS to begin protecting the Security Management Subsystem (SMS) from other binaries we load into the chip by default.
One way ROM does this is by enabling firewalls to protect the OCSRAM region it's using during bootup. Only after TIFS has started (and had time to disable the OCSRAM firewall region) will we have write access to the region.
This means we will need to move the stack & heap from OCSRAM to HSM RAM and reduce the size of BSS and the SPL to allow it to fit properly.
Signed-off-by: Bryan Brattlof bb@ti.com --- configs/am62ax_evm_r5_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/am62ax_evm_r5_defconfig b/configs/am62ax_evm_r5_defconfig index bfffb8eef77d8..0e48f0afa20a5 100644 --- a/configs/am62ax_evm_r5_defconfig +++ b/configs/am62ax_evm_r5_defconfig @@ -19,7 +19,7 @@ CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x3500 CONFIG_SPL_FS_FAT=y CONFIG_SPL_LIBDISK_SUPPORT=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x7000ffff +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x43c3a7f0 CONFIG_SPL_LOAD_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x80080000 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y

On Fri, Dec 23, 2022 at 07:15:22PM -0600, Bryan Brattlof wrote:
Texas Instruments has begun enabling security setting on the SoCs they produce to instruct ROM and TIFS to begin protecting the Security Management Subsystem (SMS) from other binaries we load into the chip by default.
One way ROM does this is by enabling firewalls to protect the OCSRAM region it's using during bootup. Only after TIFS has started (and had time to disable the OCSRAM firewall region) will we have write access to the region.
This means we will need to move the stack & heap from OCSRAM to HSM RAM and reduce the size of BSS and the SPL to allow it to fit properly.
Signed-off-by: Bryan Brattlof bb@ti.com
Applied to u-boot/master, thanks!

Texas Instruments has begun enabling security settings on the SoCs it produces to instruct ROM and TIFS to begin protecting the Security Management Subsystem (SMS) from other binaries we load into the chip by default.
One way ROM and TIFS do this is by enabling firewalls to protect the OCSRAM and HSM RAM regions they're using during bootup.
The HSM RAM the wakeup SPL is in is firewalled by TIFS to protect itself from the main domain applications. This means the 'bootindex' value in HSM RAM, left by ROM to indicate if we're using the primary or secondary boot-method, must be moved to OCSRAM (that TIFS has open for us) before we make the jump to the main domain so the main domain's bootloaders can keep access to this information.
Signed-off-by: Bryan Brattlof bb@ti.com --- arch/arm/mach-k3/Kconfig | 4 +++- arch/arm/mach-k3/am62a7_init.c | 16 ++++++++++++++-- arch/arm/mach-k3/include/mach/am62a_hardware.h | 17 ++++++++++++++++- 3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index 87da6b49ee6b7..a8c3a593d5704 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -69,7 +69,9 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX default 0x41cffbfc if SOC_K3_J721E default 0x41cfdbfc if SOC_K3_J721S2 default 0x701bebfc if SOC_K3_AM642 - default 0x43c3f290 if SOC_K3_AM625 || SOC_K3_AM62A7 + default 0x43c3f290 if SOC_K3_AM625 + default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R + default 0x7000f290 if SOC_K3_AM62A7 && ARM64 help Address at which ROM stores the value which determines if SPL is booted up by primary boot media or secondary boot media. diff --git a/arch/arm/mach-k3/am62a7_init.c b/arch/arm/mach-k3/am62a7_init.c index e9569f0d26418..02da24a3d6f0d 100644 --- a/arch/arm/mach-k3/am62a7_init.c +++ b/arch/arm/mach-k3/am62a7_init.c @@ -25,8 +25,11 @@ static struct rom_extended_boot_data bootdata __section(".data"); static void store_boot_info_from_rom(void) { bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX); - memcpy(&bootdata, (uintptr_t *)ROM_ENTENDED_BOOT_DATA_INFO, - sizeof(struct rom_extended_boot_data)); + + if (IS_ENABLED(CONFIG_CPU_V7R)) { + memcpy(&bootdata, (uintptr_t *)ROM_ENTENDED_BOOT_DATA_INFO, + sizeof(struct rom_extended_boot_data)); + } }
static void ctrl_mmr_unlock(void) @@ -123,6 +126,15 @@ void board_init_f(ulong dummy) k3_sysfw_loader(true, NULL, NULL); #endif
+#if defined(CONFIG_CPU_V7R) + /* + * Relocate boot information to OCRAM (after TIFS has opend this + * region for us) so the next bootloader stages can keep access to + * primary vs backup bootmodes. + */ + writel(bootindex, K3_BOOT_PARAM_TABLE_INDEX_OCRAM); +#endif + /* * Force probe of clk_k3 driver here to ensure basic default clock * configuration is always done. diff --git a/arch/arm/mach-k3/include/mach/am62a_hardware.h b/arch/arm/mach-k3/include/mach/am62a_hardware.h index 52b0d9b3cb95c..13bf50f147b1e 100644 --- a/arch/arm/mach-k3/include/mach/am62a_hardware.h +++ b/arch/arm/mach-k3/include/mach/am62a_hardware.h @@ -68,7 +68,22 @@
#define ROM_ENTENDED_BOOT_DATA_INFO 0x43c3f1e0
-/* Use Last 2K as Scratch pad */ +#define K3_BOOT_PARAM_TABLE_INDEX_OCRAM 0x7000F290 + +/* + * During the boot process ROM will kill anything that writes to OCSRAM. + * This means the wakeup SPL cannot use this region during boot. To + * complicate things, TIFS will set a firewall between HSM RAM and the + * main domain. + * + * So, during the wakeup SPL, we will need to store the EEPROM data + * somewhere in HSM RAM, and the main domain's SPL will need to store it + * somewhere in OCSRAM + */ +#ifdef CONFIG_CPU_V7R +#define TI_SRAM_SCRATCH_BOARD_EEPROM_START 0x43c30000 +#else #define TI_SRAM_SCRATCH_BOARD_EEPROM_START 0x70000001 +#endif /* CONFIG_CPU_V7R */
#endif /* __ASM_ARCH_AM62A_HARDWARE_H */

On Fri, Dec 23, 2022 at 07:15:23PM -0600, Bryan Brattlof wrote:
Texas Instruments has begun enabling security settings on the SoCs it produces to instruct ROM and TIFS to begin protecting the Security Management Subsystem (SMS) from other binaries we load into the chip by default.
One way ROM and TIFS do this is by enabling firewalls to protect the OCSRAM and HSM RAM regions they're using during bootup.
The HSM RAM the wakeup SPL is in is firewalled by TIFS to protect itself from the main domain applications. This means the 'bootindex' value in HSM RAM, left by ROM to indicate if we're using the primary or secondary boot-method, must be moved to OCSRAM (that TIFS has open for us) before we make the jump to the main domain so the main domain's bootloaders can keep access to this information.
Signed-off-by: Bryan Brattlof bb@ti.com
Applied to u-boot/master, thanks!

We're currently using CONFIG_BOOTCOMMAND to run custom boot scripts to jump into linux. While this works, let's begin the transition to more distribution friendly jumps to linux by enabling distro_bootcmd.
Convert the custom bootcmd to a distro_bootcmd
Signed-off-by: Judith Mendez jm@ti.com Signed-off-by: Bryan Brattlof bb@ti.com --- configs/am62ax_evm_a53_defconfig | 1 - include/configs/am62ax_evm.h | 29 ++++++++++++++++++++++++++--- 2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig index 0c2cf945c62bf..6e97fd4060e05 100644 --- a/configs/am62ax_evm_a53_defconfig +++ b/configs/am62ax_evm_a53_defconfig @@ -20,7 +20,6 @@ CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80480000 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SPL_LOAD_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x81000000 -CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern" CONFIG_SPL_MAX_SIZE=0x58000 CONFIG_SPL_PAD_TO=0x0 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y diff --git a/include/configs/am62ax_evm.h b/include/configs/am62ax_evm.h index 5406c39350f64..0bc0b13922f0f 100644 --- a/include/configs/am62ax_evm.h +++ b/include/configs/am62ax_evm.h @@ -9,7 +9,6 @@ #define __CONFIG_AM62AX_EVM_H
#include <linux/sizes.h> -#include <config_distro_bootcmd.h> #include <environment/ti/mmc.h> #include <environment/ti/k3_dfu.h>
@@ -55,12 +54,36 @@ "${bootdir}/${name_fit}\0" \ "partitions=" PARTS_DEFAULT
+#define BOOTENV_DEV_TI_MMC(devtypeu, devtypel, instance) \ + DEFAULT_MMC_TI_ARGS \ + EXTRA_ENV_AM62A7_BOARD_SETTINGS_MMC \ + "bootcmd_ti_mmc=" \ + "run findfdt; run envboot; run init_mmc;" \ + "run get_kern_mmc; run get_fdt_mmc;" \ + "run get_overlay_mmc;" \ + "run run_kern;\0" + +#define BOOTENV_DEV_NAME_TI_MMC(devtyeu, devtypel, instance) \ + "ti_mmc " + +#if CONFIG_IS_ENABLED(CMD_MMC) + #define BOOT_TARGET_MMC(func) \ + func(TI_MMC, ti_mmc, na) +#else + #define BOOT_TARGET_MMC(func) +#endif /* CONFIG_IS_ENABLED(CMD_MMC) */ + +#define BOOT_TARGET_DEVICES(func) \ + BOOT_TARGET_MMC(func) + +#include <config_distro_bootcmd.h> + /* Incorporate settings into the U-Boot environment */ #define CONFIG_EXTRA_ENV_SETTINGS \ DEFAULT_LINUX_BOOT_ENV \ - DEFAULT_MMC_TI_ARGS \ + DEFAULT_FIT_TI_ARGS \ EXTRA_ENV_AM62A7_BOARD_SETTINGS \ - EXTRA_ENV_AM62A7_BOARD_SETTINGS_MMC \ + BOOTENV
/* Now for the remaining common defines */ #include <configs/ti_armv7_common.h>

On Fri, Dec 23, 2022 at 07:15:24PM -0600, Bryan Brattlof wrote:
We're currently using CONFIG_BOOTCOMMAND to run custom boot scripts to jump into linux. While this works, let's begin the transition to more distribution friendly jumps to linux by enabling distro_bootcmd.
Convert the custom bootcmd to a distro_bootcmd
Signed-off-by: Judith Mendez jm@ti.com Signed-off-by: Bryan Brattlof bb@ti.com
Applied to u-boot/master, thanks!

In order to maintain the chain of trust, each stage of the boot process will first authenticate each binary it loads before continuing. To extend this to the kernal and its dtbs we can package the kernal and its dtbs into another fitImage for Uboot to authenticate and extend the chain of trust all the way to the kernel.
When 'boot_fit' is set, indicating we're using the secure bootflow, look for and authenticate the kernel's fitImage.
Signed-off-by: Judith Mendez jm@ti.com Signed-off-by: Bryan Brattlof bb@ti.com --- include/configs/am62ax_evm.h | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/configs/am62ax_evm.h b/include/configs/am62ax_evm.h index 0bc0b13922f0f..ce5dcd34787fa 100644 --- a/include/configs/am62ax_evm.h +++ b/include/configs/am62ax_evm.h @@ -59,9 +59,14 @@ EXTRA_ENV_AM62A7_BOARD_SETTINGS_MMC \ "bootcmd_ti_mmc=" \ "run findfdt; run envboot; run init_mmc;" \ - "run get_kern_mmc; run get_fdt_mmc;" \ - "run get_overlay_mmc;" \ - "run run_kern;\0" + "if test ${boot_fit} -eq 1; then;" \ + "run get_fit_mmc; run get_overlaystring;" \ + "run run_fit;" \ + "else;" \ + "run get_kern_mmc; run get_fdt_mmc;" \ + "run get_overlay_mmc;" \ + "run run_kern;" \ + "fi;\0"
#define BOOTENV_DEV_NAME_TI_MMC(devtyeu, devtypel, instance) \ "ti_mmc "

On Fri, Dec 23, 2022 at 07:15:25PM -0600, Bryan Brattlof wrote:
In order to maintain the chain of trust, each stage of the boot process will first authenticate each binary it loads before continuing. To extend this to the kernal and its dtbs we can package the kernal and its dtbs into another fitImage for Uboot to authenticate and extend the chain of trust all the way to the kernel.
When 'boot_fit' is set, indicating we're using the secure bootflow, look for and authenticate the kernel's fitImage.
Signed-off-by: Judith Mendez jm@ti.com Signed-off-by: Bryan Brattlof bb@ti.com
Applied to u-boot/master, thanks!

Bryan Brattlof bb@ti.com writes:
Hello everyone!
Texas Instruments has started to enable security settings inside all the boot ROM and TIFS firmware in all of their SoCs. One of the few changes this brings is ROM and TIFS will now begin protecting the RAM regions they're using with firewalls.
This means the wakeup domain's SPL will need to move the stack and heap to HSM RAM to ensure it stays within its allotted memory regions as well as move the needed boot information to the main domain's bootloaders that will no longer have access to HSM RAM.
We will also need to edit the bootcmd to pull in the kernel and dtb's fitImage if uboot is enforcing the high security bootflow. While we're editing this bootcmd, we can also take the opportunity to convert it to a distro_bootcmd macro.
Thanks for reviewing! ~Bryan
Bryan Brattlof (5): configs: restrict am62ax wakup SPL size configs: am62a: move stack and heap to HSM RAM arm: mach-k3: copy bootindex to OCRAM for main domain SPL configs: am62a: convert bootcmd to distro_bootcmd configs: am62a: use kernel fitImage when using secure bootflow
arch/arm/mach-k3/Kconfig | 4 ++- arch/arm/mach-k3/am62a7_init.c | 16 +++++++-- .../arm/mach-k3/include/mach/am62a_hardware.h | 17 +++++++++- configs/am62ax_evm_a53_defconfig | 1 - configs/am62ax_evm_r5_defconfig | 15 +++++--- include/configs/am62ax_evm.h | 34 +++++++++++++++++-- 6 files changed, 74 insertions(+), 13 deletions(-)
base-commit: 52d91e1c20b399ddab276e2c03e5788ed5e5fdd2
2.39.0
All patches look good to me.
Reviewed-by: Kamlesh Gurudasani kamlesh@ti.com
Thanks
participants (3)
-
Bryan Brattlof
-
Kamlesh Gurudasani
-
Tom Rini