[PATCH 0/3] stm32mp: Attempt to resolve unintended breakage with v2021.10-rc2
Patrick DELAUNAY
patrick.delaunay at foss.st.com
Tue Sep 14 14:26:23 CEST 2021
Hi Alexandru,
On 9/9/21 4:55 PM, Alexandru Gagniuc wrote:
> u-boot v2021.10-rc2 Introduced support for booting from FIP images
> (not to be confused with FIT) for stm32mp. I am also working on a
> different boot flow based on u-boot's falcon mode. The changes to
> accommodate the FIP mode inadvertently broke the falcon flow. This
> series intends to address that.
>
> The core issue is that optee nodes are removed from the u-boot
> devicetree. For reasons detailed in my other series
> ("[PATCH v2 00/11] stm32mp1: Support falcon mode with OP-TEE payloads")
> the "optee" nodes are required.
>
> It might seem like an obvious solution to "just re-add the nodes", but
> I found out it didn't work like that. I couldn't use
> STM32MP15x_STM32IMAGE to get me back my nodes, because that would have
> required TFABOOT. What I needed was a new config that more accuratelyreflected the available boot flows.
>
> STM32MP15x_STM32IMAGE is a confusing because it conflates image
> generation with u-boot behavior. I'm proposing replacing it with
> TFABOOT_FIP_CONTAINER because I think this new config is much easier
> to understand in layman's terms. I also thinks it maps more elegantly
> to what STM is trying to do: add a new boot flow.
Again, I don't add a new boot flow BUT the support of the default
container = the FIP for the existing TFA BOOT flow .
It is the SAME boot flow, previously named "trusted"
TF-A (BL2) => secure monitor => U-Boot => kernel
And we have also 2 variant here: the secure monitor can be OP-TEE or SP_MIN
The only difference is the containers used by TF-A BL2 (FSBL) to load
the next stage (secure monitor / SSBL) and the DT is provided to U-Boot
by TF-A/OP-TEE.
And booth container can be used with OP-TEE or SP_MIN.
In the first support of STM32MP15 in TF-A, we use the STM32IMAGE
container (several files *.stm32)
but after some requests (PKI) and evolution and to avoid limitation
(SYSRAM size)
we conclude it was a error to a use this proprietary format after TF-A BL2.
We keep this format only for ROM code, for the first boot stage loader =
TF-A BL2 or SPL.
Now we are migrating the "trusted" boot (with TF-A boot) to use the FIP
container.
So the usage of STM32IMAGE container for U-Boot is STM32MP15x specific
and the FIP is the default container for TFABOOT
(for me no need to specific CONFIG to managed generic behavior),
It is strange to add a config for all board (so always activated), to
solve a problem
only present in the STM32MP platform because we badly support TFA in the
first upstreamed code.
So I prefer use a "CONFIG_STM32MP15x_" config to manage it;
it is only activated for TFABOOT and for STM32MP15
But perhaps you prefer a longer name ?
=> CONFIG_STM32MP15x_TFABOOT_STM32IMAGE_CONTAINER
or
=> CONFIG_STM32MP15x_TFABOOT_WITH_STM32IMAGE
For the OP-TEE nodes, on ST boards at least, they are assumes added by
OP-TEE
firmware. It is the expected behavior when OP-TEE is compiled for ST boards.
So for me it is not a issue but the expected behavior for ST boards for
upstream.
This behavior allows to dynamically manage the case when OP-TEE is not
present: driver is not probed,
because it can be replaced by SP-MIN in FIP or in STM32IMAGE, and avoid
to force information
in U-Boot device tree configuration which can be managed by OP-TEE.
U-Boot can start any OP-TEE binary, even if memory configuration change
and I try to limit the number of U-Bot add-on in "stm32mp*-u-boot.dtsi".
I agree that for you use can you could force OP-TEE nodes, when OP-TEE is
not compiled to update device tree, by it is not a option chosen
on ST Microelectronics boards for upstream support.
Moreover for me it is not possible to have one compilation flag which
defined the boot flow
and I see several other issue with the "falcon OP-TEE" mode:
SPL => OP-TEE => U-Boot
OP-TEE should provide PSCI / SCMI server to U-Boot running in non secure,
so the U-Boot configuration change:
=> CONFIG_ARCH_SUPPORT_PSCI = n
=> CONFIG_ARM_SMCCC
=> CONFIG_CPU_V7_HAS_NONSEC
=> CONFIG_SYSRESET_PSCI
=> CONFIG_SCMI_FIRMWARE / CONFIG_CLK_SCMI / CONFIG_RESET_SCMI
=> CONFIG_TEE / CONFIG_OPTEE
Today they configuration are only activate for TF-A boot
because I assume that with SPL, U-Boot is running is secure level with direct access
to secure ressources / wihtout OPTEE
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
config DDR_CACHEABLE_SIZE
hex "Size of the DDR marked cacheable in pre-reloc stage"
- default 0x10000000 if TFABOOT
+ default 0x10000000 if TFABOOT || SPL_OPTEE_IMAGE
default 0x40000000
help
Define the size of the DDR marked as cacheable in U-Boot
or move all these ARCH option from Kconfig in each defconfig....
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.
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.
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
>
> Alexandru Gagniuc (3):
> stm32mp: Rename FIP config to stm32mp15_tfaboot_fip_defconig
> arm: Kconfig: Introduce a TFABOOT_FIP_CONTAINER option
> stm32mp1: Replace STM32MP15x_STM32IMAGE with TFABOOT_FIP_CONTAINER
>
> arch/arm/Kconfig | 15 ++++++++++++
> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 9 ++++----
> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 9 ++++----
> arch/arm/mach-stm32mp/Kconfig | 7 ------
> .../cmd_stm32prog/cmd_stm32prog.c | 5 ++--
> .../mach-stm32mp/cmd_stm32prog/stm32prog.c | 4 ----
> .../mach-stm32mp/cmd_stm32prog/stm32prog.h | 2 --
> arch/arm/mach-stm32mp/config.mk | 2 +-
> arch/arm/mach-stm32mp/fdt.c | 4 +---
> .../arm/mach-stm32mp/include/mach/stm32prog.h | 2 --
> board/st/common/Kconfig | 23 ++++++++++---------
> board/st/common/stm32mp_mtdparts.c | 20 +---------------
> board/st/stm32mp1/MAINTAINERS | 2 +-
> board/st/stm32mp1/stm32mp1.c | 6 ++---
> ...config => stm32mp15_tfaboot_fip_defconfig} | 1 +
> configs/stm32mp15_trusted_defconfig | 1 -
> doc/board/st/stm32mp1.rst | 16 ++++++-------
> 17 files changed, 54 insertions(+), 74 deletions(-)
> rename configs/{stm32mp15_defconfig => stm32mp15_tfaboot_fip_defconfig} (99%)
>
PS: I push a patch to solve the GPT partition name force to fip in basic
boot
http://patchwork.ozlabs.org/project/uboot/list/?series=262257&state=*
NB: I will share my working branch with my proposal of SPL & OPT-TEE
support in few days
Regards
Patrick
More information about the U-Boot
mailing list