Hi Patrick,
On 9/14/21 7:26 AM, Patrick DELAUNAY wrote:
Hi Alexandru,
I think you need to update arch/arm/mach-stm32mp/Kconfig
something like:
config STM32MP15x bool "Support STMicroelectronics STM32MP15x Soc" - select ARCH_SUPPORT_PSCI if !TFABOOT - select ARM_SMCCC if TFABOOT + select ARCH_SUPPORT_PSCI if !TFABOOT && !SPL_OPTEE_IMAGE + select ARM_SMCCC if TFABOOT || SPL_OPTEE_IMAGE select CPU_V7A - select CPU_V7_HAS_NONSEC if !TFABOOT + select CPU_V7_HAS_NONSEC if !TFABOOT && !SPL_OPTEE_IMAGE select CPU_V7_HAS_VIRT select OF_BOARD_SETUP select PINCTRL_STM32 @@ -47,8 +47,8 @@ config STM32MP15x select STM32_SERIAL select SYS_ARCH_TIMER imply CMD_NVEDIT_INFO - imply SYSRESET_PSCI if TFABOOT - imply SYSRESET_SYSCON if !TFABOOT + imply SYSRESET_PSCI if TFABOOT || SPL_OPTEE_IMAGE + imply SYSRESET_SYSCON if !TFABOOT && !SPL_OPTEE_IMAGE help support of STMicroelectronics SOC STM32MP15x family STM32MP157, STM32MP153 or STM32MP151 @@ -153,7 +153,7 @@ config NR_DRAM_BANKS
This is a terrible idea. We're trying to answer a few questions: * Did the FSBL provide a PSCI secure monitor * Is u-boot running in normal or secure world
But instead of clearly defining those answers, we're trying to infer them from other config options. This is confusing to start with, but it's also wrong.
For example, SPL_OPTEE_IMAGE means "we support OPTEE images in SPL". It doesn't mean that we loaded an OP-TEE kernel at all. SPL with SPL_OPTEE_IMAGE may as well boot a legacy uboot image -- nothing prevents it. So to infer from this that u-boot runs in the normal world is wrong.
Without loss of generality, any CONFIG that conflates u-boot options with SPL options is likely to cause some changes down the line.
So just introduce CONFIG_TFABOOT_FIP_CONTAINER don't solve all the issues....
I think you need to manage CONFIG_SPL_OPTEE_IMAGE to handle specific case when OPTEE is running after SPL.
Sure, but I'd have to adjust this at runtime, not in Kconfig for the reasons above.
I try to experiment the OPTEE load by SPL but I don't see how the OP-TEE pager can be managed by SPL in the current code. It must loaded in SYRAM at 0x2ffc0000, with a risk to overwrite the SPL code loaded by rom code at 0x2ffc2500.
This consideration is not unique to SPL. I don't have that problem because SPL loads OP-TEE to DRAM at 0xde000000. If OP-TEE wants to load parts of itself to SYSRAM, that happens after SPL passed control, so the conflict is not relevant.
or how to manage several binary, see OP-TEE header v2 support in OP-TEE,
Several file it is already supported in TF-A BL2 with FIP:
tee-header_v2.bin tee-pager_v2.bin tee-pageable_v2.bin
I don't know how to use use the OP-TEE pager with SPL, so I elected not to:
EXTRA_OEMAKE = "PLATFORM=${OPTEE_PLATFORM} \ CFG_WITH_PAGER=n \ CFG_NS_ENTRY_ADDR=${KERNEL_UIMAGE_LOADADDRESS} \ CROSS_COMPILE=${HOST_PREFIX} \ CFG_TEE_CORE_DEBUG=y \ CFG_TEE_CORE_LOG_LEVEL=2 \ ${TZDRAM_FLAGS} \ "
TZDRAM_FLAGS = "CFG_TZDRAM_START= 0xde000000\ CFG_DRAM_SIZE=0x20000000 "
Alex