Re: [PATCH 0/3] stm32mp: Attempt to resolve unintended breakage with v2021.10-rc2

["Alex G." <mr.nuke.me@gmail.com>]

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