[RFC PATCH] stm32mp1: Replace STM32IMAGE config with TFABOOT_FIP
Patrick DELAUNAY
patrick.delaunay at foss.st.com
Tue Aug 31 16:54:22 CEST 2021
Hi Alexandru,
On 8/26/21 11:47 PM, Alexandru Gagniuc wrote:
> Hi Patrick,
>
> I proposing a better fix fir the issues I outlined earlier, I made a
> classification of the currently supported boot modes.
>
> 1) BL1 -> SPL -> U-Boot
> 2) BL1 -> SPL -> OP-TEE
> ---------------------------------------------------------------------
> | 3) BL1 -> TF-A -> U-Boot |
> | 4) BL1 -> TF-A -> OP-TEE |
> | _________________________________________________________________ |
> || 5) BL1 -> TF-A -> FIP container ||
> || CONFIG_TFABOOT_FIP ||
> ||_________________________________________________________________||
> | |
> | CONFIG_TFABOOT |
> ---------------------------------------------------------------------
>
> Here, I'm looking at FIP as a new boot mode. In order to avoid
> breakage, any changes to support FIP it should naturally be done only
> to this new path.
>
> This proposal contains several changes, but I've squashed them into
> one for ease of discussion.
>
> This better matches the boot mode classification above.
1) is supported but with many constraint for security part and low power
management
it is not recommended for real product / it will be not supported
by STMicroelectronics
2) is not supported by STMicroelectronics, introduced by your patchset
3 and 4) are common for U-Boot point of view: running in normal world,
STM32IMAGE container
BL1 -> TF-A -> SecureMonitor -> U-Boot (STM32IMAGE or FIP container)
With Secure Monitor
= SPMIN (included in a the STM32IMAGE container of TF-A)
or OP-TEE (loaded by TF-A BL2 in "tf-a.stm32", using the STM32IMAGE
container)
The STM32IMAGE container are correct for the BL1 load with first root of
trust but have limitations
for new security features (Public key infrastructure, secure software
update, M4 firmware load by TF-A)
or for next products (coming soon) with limited size of embedded RAM.
So we decide to use for future development/product the default TF-A
container = the FIP.
=> For the next products only we only support FIP container.
And the FIP containers is now the recommended TF-A container for
STM32MP15 platform
and we could decide one day to deprecate/remove the STM32IMAGE support
for STM32MP15 platform....
It is why I introduced the CONFIG_STM32MP15x_STM32IMAGE,
to keep the compatibility with the previous "trusted" boot chain
and the default container is/becomes the FIP for all STM32MP product
=> this STM32IMAGE support (under compilation flag) could be removed in
future
by choice for the maintenance I prefer to mark the code
to remove under a specific compilation flags only supported for
STM32MP15x
Today I have the classification:
1) BL1 -> SPL -> u-boot ("basic" boot)
---------------------------------------------------------------------
| 2) BL1 -> TF-A -> u-boot ("trusted" boot) |
| |
| 2.1) TF-A BL2 use STM32IMAGE container |
| (CONFIG_STM32MP15x_STM32IMAGE => deprecated) |
| |
| 2.2) TF-A BL2 use FIP container (new default) |
| |
| CONFIG_TFABOOT |
---------------------------------------------------------------------
The STM32IMAGE container support is only variant for STM32MP15x trusted boot.
FIP is a evolution of the STMicroelectronics proposal
and is now the default recommended container for trusted boot.
OP-TEE presence is detected dynamically in U-Boot (it should be
mandatory for next STM32MP product).
The root cause the of the issue is the introduction of
the "strange" OP-TEE after SPL boot mode (*)
1) BL1 -> SPL (secure) -> U-Boot (secure)
*) BL1 -> SPL (secure) -> OP-TEE (secure) -> kernel (normal world) for falcon mode
-> U-Boot (normal world)
it is strange for me, because SPL and U-Boot are not running at the same exception level,
and OP-TEE firmware is only present/running when U-Boot proper is running.
So all my assumption in STM32MP platform are false
(SPL support => U-Boot is running in secure world when TFABOOT is not present)
and not only the FIP support.
This mode is not recommended: it will not supported by STMicroelectronics
and not supported by next products.
But you are free to manage it.
This new boot scheme could be managed by a new defconfig....
to avoid to break the existing configuration (basic / trusted)
>
> This config mixes boot path (2) with paths (3) and (4), and thus is
> contrary to our goal of making changes only to the new FIP path.
> Because it mixes and matches SPL assumptions with TF-A assumptions,
> I've had a hard time figuting it out. I suspect it would be just as
> confusing for others in the future.
Yes I make the assumption that SPL is for "basic" boot
SPL loads the next stage in secure world because it the general use case
for SPL / U-Boot:
the switch to normal world is done AFTER U-Boot when the
secure monitor for PSCI suport is installed by U-Boot.
But in you use-case you mix the 2 boot schemes ("basic" for SPL and
"trusted" for U-boot)
For my point of view you can use
- SPL (u-boot-spl.stm32) from stm32mp15_basic_defconfig:
=> simple loader / running in secure world
- U-Boot (u-boot-nodtb.bin + u-boot.dtb = included in FIT) from
stm32mp15_trusted_defconfig:
=> U-Boot running in normal world / using OP-TEE
If you want manage the feature with a single defconfig it should be
difficult
to avoid to break the existing boot schemes.
>
> I've had issues with tee_find_device() in the past when using SPL as
> the FSBL. As u-boot was running in secure mode and did not have a
> handler, it would result in a CPU exception and crash.
yes it is normal for me: OP-TEE driver support should be only activated when
U-Boot is running in normal world, in "trusted" defconfig
tee_find_device() should not be called when OP-TEE driver is not
supported, in SPL or for "basic" boot.
PS: in the code the API call are protected by CONFIG_IS_ENABLED:
if (CONFIG_IS_ENABLED(OPTEE) && !tee_find_device(NULL, NULL, NULL,
NULL))
I thought that was enought because
the config CONFIG_OPTEE is used to activate the OP-TEE driver support in
U-Boot
So the CONFIG_SPL_OPTEE is used to activate the OP-TEE driver support in SPL
=> for me CONFIG_SPL_OPTEE should be never activated
but after check and I am confused with the CONFIG_OPTEE: it is defined 2
times with 2 meanings
and I think U-Boot have a issue here....
./lib/optee/Kconfig:
config OPTEE
bool "Support OPTEE images"
help
U-Boot can be configured to boot OPTEE images.
Selecting this option will enable shared OPTEE library code and
enable an OPTEE specific bootm command that will perform
additional
OPTEE specific checks before booting an OPTEE image created with
mkimage.
./drivers/tee/optee/Kconfig:
config OPTEE
bool "OP-TEE"
depends on ARM_SMCCC
help
This implements the OP-TEE Trusted Execution Environment (TEE)
driver. OP-TEE is a Trusted OS designed primarily to rely on the
ARM TrustZone(R) technology as the underlying hardware isolation
mechanism. This driver can request services from OP-TEE, but also
handle Remote Procedure Calls (RPC) from OP-TEE needed to
execute a service. For more information see: https://www.op-tee.org
/lib/Makefile:19:obj-$(CONFIG_OPTEE) += optee/
./drivers/tee/Makefile:7:obj-$(CONFIG_OPTEE) += optee/
I think one existing CONFIG_OPTEE should be renamed to a better name
"CONFIG_OPTEE_IMAGE" for "BOOT of OPTEE firmware"
./lib/optee/Kconfig:
- config OPTEE
+ config OPTEE_IMAGE
and the associated becomes
- config SPL_OPTEE
+ config SPL_OPTEE_IMAGE
bool "Support boot of OP-TEE Trusted OS"
depends on ARM
help
OP-TEE is an open source Trusted OS which is loaded by SPL.
More detail at: https://github.com/OP-TEE/optee_os
.....
- #if CONFIG_IS_ENABLED(OPTEE)
- #if CONFIG_IS_ENABLED(OPTEE_IMAGE)
case IH_OS_TEE:
debug("Jumping to U-Boot via OP-TEE\n");
spl_board_prepare_for_optee(spl_image.fdt_addr);
spl_optee_entry(NULL, NULL, spl_image.fdt_addr,
(void *)spl_image.entry_point);
break;
#endif
+ other part in the code
I think I will propose this patch to solve this issue
> The second argument against this is that stm32mp1 is the only platform
> to call tee_find_device() with the intent of detecting the presence of
> OP-TEE.
I introduce this check to avoid to duplicate the trusted defconfig
for OP-TEE /SPMIN support and I think the dynamic detection is more
flexible:
the same U-Boot can be used with SPMIN or OP-TEE as secure monitor
I don't see the problem here: it CONFIG_OPTEE is activated,
the OP-TEE driver is present and the function can be called
(at least in U-Boot, but see previous remark).
but perhaps some inline function in include/tee.h could be more elegant
when the CONFIG issue is solved....
#if CONFIG_IS_ENABLED(OPTEE)
struct udevice *tee_find_device(struct udevice *start,
int (*match)(struct tee_version_data *vers,
const void *data),
const void *data,
struct tee_version_data *vers);
#else
static inline struct udevice *tee_find_device(struct udevice *start,
int (*match)(struct tee_version_data *vers,
const void *data),
const void *data,
struct tee_version_data *vers) {
return NULL;
}
#endif
Your problem here is that you activate OPTEE in SPL= CONFIG_SPL_OPTEE
and this config is strange, the OP-TEE driver is not activated in SPL
but SPL boot OPTEE image.
> Have there been issues with not callinf this in the past, or was this
> more of a "seems nice to have" ?
>
> "stm32mp15_defconfig" implies that would be the correct configuraion
> for STM32MP1. New contributor chooses this config, tries to run SPL
> + u-boot, which is what u-boot user expects is the default. Things
> likely fail miserably. A lot of u-boot users don't know what FIP is.
> It's an extra concept that is not strictly necessary in u-boot.
For me, SPL is not the only configuration expected by U-Boot user
(sometime you have SPL , TPL, TF-A or proprietary first stage bootloader).
And yes "stm32mp15_defconfig" it the new STMicroelectronics configuration to use
for STMicroelectronics STM32MP15x boards and the recommended starting point
for new customer board support. And it doesn't use SPL.
TF-A and FIP are perhaps not necessary today for STM32MP15x,
but they will be mandatory in the next products (SPL boot will be no
more supported).
I try to document each defconfig in platform documentation (in
doc/board/st/)
https://u-boot.readthedocs.io/en/latest/board/st/stm32mp1.html#boot-sequences
And it is also explained in our WIKI:
https://wiki.st.com/stm32mpu/wiki/Boot_chain_overview
https://wiki.st.com/stm32mpu/wiki/TF-A_overview
but if the user don't read the SW documentation....
yes he can be confused.
>
> So I think this name is vague, as it doesn't really describe what is
> going on. If we change it to "stm32mp15_tfaboot_fip_defconfig", then
> it very accurately describes the boot scenario, and avoids the
> confusion above.
for next product STM32MP1X, and for ST boards, as only the TF-A with FIP
is supported I will use the simple name:
- stm32mpXX_defconfig
with for STM32MP15x:
- stm32mp15_defconfig => boot with TF-A with FIP (default)
only for stm32mp15 I keeps the previous defconfig only for compatibility
- stm32mp15_basic_defconfig => boot with SPL
- stm32mp15_trusted_defconfig => boot with TF-A without FIP support (deprecated)
PS: our Marketing team don't like "FIP" / "tfaboot" in config name...
my first proposal was stm32mp15_spl_defconfig /
stm32mp15_tfa_defconfig
instead of stm32mp15_basic_defconfig / stm32mp15_trusted_defconfig
but if you want support a other configuration / a other customization /
a other board, you can manage
your stm32mp15 defconfig with your boot configuration, for example
stm32mp15_spl_optee_defconfig
> We're setting CONFIG_MTDPARTS_xxx based on TFABOOT_FIP_CONTAINER now,
> so I don't think we need any ifdefs here. This part needs the most
> scrutiny, as I don't have a way to test if I've broken anything.
> ---
> arch/arm/Kconfig | 14 +++++++
> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 7 ++--
> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 9 ++---
> arch/arm/mach-stm32mp/Kconfig | 7 ----
> .../cmd_stm32prog/cmd_stm32prog.c | 2 -
> .../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 | 37 -------------------
> .../arm/mach-stm32mp/include/mach/stm32prog.h | 2 -
> board/st/common/Kconfig | 20 +++++-----
> board/st/common/stm32mp_mtdparts.c | 18 ---------
> board/st/stm32mp1/stm32mp1.c | 6 +--
> ...config => stm32mp15_tfaboot_fip_defconfig} | 1 +
> configs/stm32mp15_trusted_defconfig | 1 -
> 15 files changed, 35 insertions(+), 97 deletions(-)
> rename configs/{stm32mp15_defconfig => stm32mp15_tfaboot_fip_defconfig} (99%)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d692139199..4c6f7ab3de 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1905,6 +1905,20 @@ config TFABOOT
> Enabling this option will make a U-Boot binary that is relying
> on other firmware layers to provide secure functionality.
>
> +config TFABOOT_FIP_CONTAINER
> + bool "Support for booting from TF-A inside a FIP container"
> + depends on TFABOOT
> + default n
default y ?
> + help
> + TF-A has its own container format, named FIP (not to be confused with
> + FIT). When u-boot is started from a FIP, it sometimes needs to make
> + different assumptions than it would with a non-FIP boot. Although
> + those could be resolved with dynamic devicetree patching, TF-A is
> + either can't patch devicetrees, or is unwilling to do so.
> + Enabling this option will tell u-boot platform code that it is okay
> + to assume U-Boot will be started from a FIP container, even if such
> + assumptions would break things in a more normal setting.
> +
As FIP container is the default container for TF-A.... no need to have
configuration for it.
I prefer to have a compilation flag for the ST specific container
= STM32IMAGE (it will be marked deprecated soon)
> config TI_SECURE_DEVICE
> bool "HS Device Type Support"
> depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
> diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> index 0101962ea5..54424e398f 100644
> --- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> @@ -15,18 +15,18 @@
> config {
> u-boot,boot-led = "heartbeat";
> u-boot,error-led = "error";
> - u-boot,mmc-env-partition = "fip";
> + u-boot,mmc-env-partition = "fip1";
why it is "fip1" for dk1 and "fip" for ed1, in eMMC the GPT parttion is
named fip
fip1 is for NAND
> st,adc_usb_pd = <&adc1 18>, <&adc1 19>;
> st,fastboot-gpios = <&gpioa 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> st,stm32prog-gpios = <&gpioa 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> };
>
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> +#ifdef CONFIG_TFABOOT_FIP_CONTAINER
> config {
> u-boot,mmc-env-partition = "ssbl";
> };
> +#endif
I prefer the initial code => the default devicetree if for FIP support
on ST board because it is the ST Microelectronics recommandation
And I assure the backward compatibility with compilation flag.
=> it is more easy to compare the STM32MP15 device tree with next products.
NB: a other solution is to remove the "basic" / SPL support ....
as ST Microelectronics don't support it.
but it is not acceptable as it is already used by customers
>
> - /* only needed for boot with TF-A, witout FIP support */
> firmware {
> optee {
> compatible = "linaro,optee-tz";
> @@ -43,7 +43,6 @@
> u-boot,dm-spl;
> };
> };
> -#endif
>
> led {
> red {
> diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> index 32777384c6..184774df58 100644
> --- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> @@ -15,17 +15,17 @@
> config {
> u-boot,boot-led = "heartbeat";
> u-boot,error-led = "error";
> - u-boot,mmc-env-partition = "fip";
> + u-boot,mmc-env-partition = "ssbl";
> st,fastboot-gpios = <&gpioa 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> st,stm32prog-gpios = <&gpioa 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> };
>
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> +#ifdef CONFIG_TFABOOT_FIP_CONTAINER
> config {
> - u-boot,mmc-env-partition = "ssbl";
> + u-boot,mmc-env-partition = "fip";
> };
> +#endif
>
> - /* only needed for boot with TF-A, witout FIP support */
> firmware {
> optee {
> compatible = "linaro,optee-tz";
> @@ -39,7 +39,6 @@
> no-map;
> };
> };
> -#endif
>
> led {
> red {
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index 5d7eca649a..4c1eeef165 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -56,13 +56,6 @@ config STM32MP15x
> dual core A7 for STM32MP157/3, monocore for STM32MP151
> target all the STMicroelectronics board with SOC STM32MP1 family
>
> -config STM32MP15x_STM32IMAGE
> - bool "Support STM32 image for generated U-Boot image"
> - depends on STM32MP15x && TFABOOT
> - help
> - Support of STM32 image generation for SOC STM32MP15x
> - for TF-A boot when FIP container is not used
> -
> choice
> prompt "STM32MP15x board select"
> optional
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> index 41452b5a29..be53a52977 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> @@ -185,7 +185,6 @@ U_BOOT_CMD(stm32prog, 5, 0, do_stm32prog,
> " <size> = size of flashlayout (optional for image with STM32 header)\n"
> );
>
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> bool stm32prog_get_tee_partitions(void)
> {
> if (stm32prog_data)
> @@ -193,7 +192,6 @@ bool stm32prog_get_tee_partitions(void)
>
> return false;
> }
> -#endif
I prefer to have the code under compilation flag to prepare code removal
and STM32IMAGE will be no more supported
and also easy customer board creation (with FIP support) to detect part
of obsolete code.
>
> bool stm32prog_get_fsbl_nor(void)
> {
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index 3b6ca4e773..26fe8b654a 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -824,9 +824,7 @@ static int treat_partition_list(struct stm32prog_data *data)
> INIT_LIST_HEAD(&data->dev[j].part_list);
> }
>
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
#ifndef CONFIG_TFABOOT_FIP_CONTAINER ?
> data->tee_detected = false;
> -#endif
> data->fsbl_nor_detected = false;
> for (i = 0; i < data->part_nb; i++) {
> part = &data->part_array[i];
> @@ -880,12 +878,10 @@ static int treat_partition_list(struct stm32prog_data *data)
> /* fallthrough */
> case STM32PROG_NAND:
> case STM32PROG_SPI_NAND:
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
#ifndef CONFIG_TFABOOT_FIP_CONTAINER ?
> if (!data->tee_detected &&
> !strncmp(part->name, "tee", 3))
> data->tee_detected = true;
> break;
> -#endif
> default:
> break;
> }
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> index 240c5c44bc..9d58cf0e2d 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> @@ -122,9 +122,7 @@ struct stm32prog_data {
> struct stm32prog_dev_t dev[STM32PROG_MAX_DEV]; /* array of device */
> int part_nb; /* nb of partition */
> struct stm32prog_part_t *part_array; /* array of partition */
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> bool tee_detected;
> -#endif
> bool fsbl_nor_detected;
>
> /* command internal information */
> diff --git a/arch/arm/mach-stm32mp/config.mk b/arch/arm/mach-stm32mp/config.mk
> index f7f5b77c41..c30bf482f7 100644
> --- a/arch/arm/mach-stm32mp/config.mk
> +++ b/arch/arm/mach-stm32mp/config.mk
> @@ -4,7 +4,7 @@
> #
>
> ifndef CONFIG_SPL
> -INPUTS-$(CONFIG_STM32MP15x_STM32IMAGE) += u-boot.stm32
> +INPUTS-y += u-boot.stm32
normally "u-boot.stm32" is not generated when FIP is expected to avoid
user confusion !
it is no more the case with your proposal
> else
> ifdef CONFIG_SPL_BUILD
> INPUTS-y += u-boot-spl.stm32
> diff --git a/arch/arm/mach-stm32mp/fdt.c b/arch/arm/mach-stm32mp/fdt.c
> index a19e954cf7..8c729e1f32 100644
> --- a/arch/arm/mach-stm32mp/fdt.c
> +++ b/arch/arm/mach-stm32mp/fdt.c
> @@ -224,30 +224,6 @@ static void stm32_fdt_disable(void *fdt, int offset, u32 addr,
> string, addr, name);
> }
>
> -static void stm32_fdt_disable_optee(void *blob)
> -{
> - int off, node;
> -
> - /* Delete "optee" firmware node */
> - off = fdt_node_offset_by_compatible(blob, -1, "linaro,optee-tz");
> - if (off >= 0 && fdtdec_get_is_enabled(blob, off))
> - fdt_del_node(blob, off);
> -
> - /* Delete "optee at ..." reserved-memory node */
> - off = fdt_path_offset(blob, "/reserved-memory/");
> - if (off < 0)
> - return;
> - for (node = fdt_first_subnode(blob, off);
> - node >= 0;
> - node = fdt_next_subnode(blob, node)) {
> - if (strncmp(fdt_get_name(blob, node, NULL), "optee@", 6))
> - continue;
> -
> - if (fdt_del_node(blob, node))
> - printf("Failed to remove optee reserved-memory node\n");
> - }
> -}
> -
> /*
> * This function is called right before the kernel is booted. "blob" is the
> * device tree that will be passed to the kernel.
> @@ -332,18 +308,5 @@ int ft_system_setup(void *blob, struct bd_info *bd)
> "st,package", pkg, false);
> }
>
> - /*
> - * TEMP: remove OP-TEE nodes in kernel device tree
> - * copied from U-Boot device tree by optee_copy_fdt_nodes
> - * when OP-TEE is not detected (probe failed)
> - * these OP-TEE nodes are present in <board>-u-boot.dtsi
> - * under CONFIG_STM32MP15x_STM32IMAGE only for compatibility
> - * when FIP is not used by TF-A
> - */
> - if (CONFIG_IS_ENABLED(STM32MP15x_STM32IMAGE) &&
> - CONFIG_IS_ENABLED(OPTEE) &&
> - !tee_find_device(NULL, NULL, NULL, NULL))
> - stm32_fdt_disable_optee(blob);
> -
without this code you break the TF-A boot with SPMIN (the existing
upstreamed support)
> return ret;
> }
> diff --git a/arch/arm/mach-stm32mp/include/mach/stm32prog.h b/arch/arm/mach-stm32mp/include/mach/stm32prog.h
> index 99be4e1d65..c080b9cc42 100644
> --- a/arch/arm/mach-stm32mp/include/mach/stm32prog.h
> +++ b/arch/arm/mach-stm32mp/include/mach/stm32prog.h
> @@ -11,8 +11,6 @@ int stm32prog_read_medium_virt(struct dfu_entity *dfu, u64 offset,
> void *buf, long *len);
> int stm32prog_get_medium_size_virt(struct dfu_entity *dfu, u64 *size);
>
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> bool stm32prog_get_tee_partitions(void);
> -#endif
>
> bool stm32prog_get_fsbl_nor(void);
> diff --git a/board/st/common/Kconfig b/board/st/common/Kconfig
> index 2f57118bb2..0bb8e808aa 100644
> --- a/board/st/common/Kconfig
> +++ b/board/st/common/Kconfig
> @@ -8,9 +8,8 @@ config CMD_STBOARD
>
> config MTDPARTS_NAND0_BOOT
> string "mtd boot partitions for nand0"
> - default "2m(fsbl),2m(ssbl1),2m(ssbl2)" if STM32MP15x_STM32IMAGE || \
> - !TFABOOT
> - default "2m(fsbl),4m(fip1),4m(fip2)"
> + default "2m(fsbl),2m(ssbl1),2m(ssbl2)"
> + default "2m(fsbl),4m(fip1),4m(fip2)" if TFABOOT_FIP_CONTAINER
> depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
> help
> This define the partitions of nand0 used to build mtparts dynamically
> @@ -23,7 +22,7 @@ config MTDPARTS_NAND0_BOOT
> config MTDPARTS_NAND0_TEE
> string "mtd tee partitions for nand0"
> default "512k(teeh),512k(teed),512k(teex)"
> - depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP && STM32MP15x_STM32IMAGE
> + depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
NAK => the tee partitions are not present when FIP is used by TF-A /
this define should be not defined
> help
> This define the tee partitions added in mtparts dynamically
> when tee is supported with boot from nand0.
> @@ -32,9 +31,8 @@ config MTDPARTS_NAND0_TEE
>
> config MTDPARTS_NOR0_BOOT
> string "mtd boot partitions for nor0"
> - default "256k(fsbl1),256k(fsbl2),2m(ssbl),512k(u-boot-env)" if STM32MP15x_STM32IMAGE || \
> - !TFABOOT
> - default "256k(fsbl1),256k(fsbl2),4m(fip),512k(u-boot-env)"
> + default "256k(fsbl1),256k(fsbl2),2m(ssbl),512k(u-boot-env)"
> + default "256k(fsbl1),256k(fsbl2),4m(fip),512k(u-boot-env)" if TFABOOT_FIP_CONTAINER
> depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
> help
> This define the partitions of nand0 used to build mtparts dynamically
> @@ -46,15 +44,15 @@ config MTDPARTS_NOR0_BOOT
> config MTDPARTS_NOR0_TEE
> string "mtd tee partitions for nor0"
> default "256k(teeh),512k(teed),256k(teex)"
> - depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP && STM32MP15x_STM32IMAGE
> + depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
NAK => same
> help
> This define the tee partitions added in mtparts dynamically
> when tee is supported with boot from nor0.
>
> config MTDPARTS_SPINAND0_BOOT
> string "mtd boot partitions for spi-nand0"
> - default "2m(fsbl),2m(ssbl1),2m(ssbl2)" if STM32MP15x_STM32IMAGE || !TFABOOT
> - default "2m(fsbl),4m(fip1),4m(fip2)"
> + default "2m(fsbl),2m(ssbl1),2m(ssbl2)"
> + default "2m(fsbl),4m(fip1),4m(fip2)" if TFABOOT_FIP_CONTAINER
> depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
> help
> This define the partitions of nand0 used to build mtparts dynamically
> @@ -66,7 +64,7 @@ config MTDPARTS_SPINAND0_BOOT
> config MTDPARTS_SPINAND0_TEE
> string "mtd tee partitions for spi-nand0"
> default "512k(teeh),512k(teed),512k(teex)"
> - depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP && STM32MP15x_STM32IMAGE
> + depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
NAK => same
> help
> This define the tee partitions added in mtparts dynamically
> when tee is supported with boot from spi-nand0,
> diff --git a/board/st/common/stm32mp_mtdparts.c b/board/st/common/stm32mp_mtdparts.c
> index 8b636d62fa..dea5d506a1 100644
> --- a/board/st/common/stm32mp_mtdparts.c
> +++ b/board/st/common/stm32mp_mtdparts.c
> @@ -11,9 +11,7 @@
> #include <log.h>
> #include <mtd.h>
> #include <mtd_node.h>
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> #include <tee.h>
> -#endif
> #include <asm/arch/stm32prog.h>
> #include <asm/arch/sys_proto.h>
> #include <asm/global_data.h>
> @@ -33,9 +31,7 @@ static void board_set_mtdparts(const char *dev,
> char *mtdids,
> char *mtdparts,
> const char *boot,
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> const char *tee,
> -#endif
> const char *user)
> {
> /* mtdids: "<dev>=<dev>, ...." */
> @@ -59,12 +55,10 @@ static void board_set_mtdparts(const char *dev,
> strncat(mtdparts, ",", MTDPARTS_LEN);
> }
>
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> if (tee) {
> strncat(mtdparts, tee, MTDPARTS_LEN);
> strncat(mtdparts, ",", MTDPARTS_LEN);
> }
> -#endif
>
> strncat(mtdparts, user, MTDPARTS_LEN);
> }
> @@ -77,9 +71,7 @@ void board_mtdparts_default(const char **mtdids, const char **mtdparts)
> static char ids[MTDIDS_LEN + 1];
> static bool mtd_initialized;
> bool nor, nand, spinand, serial;
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> bool tee = false;
> -#endif
>
> if (mtd_initialized) {
> *mtdids = ids;
> @@ -97,9 +89,7 @@ void board_mtdparts_default(const char **mtdids, const char **mtdparts)
> case BOOT_SERIAL_USB:
> serial = true;
> if (CONFIG_IS_ENABLED(CMD_STM32PROG)) {
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> tee = stm32prog_get_tee_partitions();
> -#endif
> nor = stm32prog_get_fsbl_nor();
> }
> nand = true;
> @@ -118,11 +108,9 @@ void board_mtdparts_default(const char **mtdids, const char **mtdparts)
> break;
> }
>
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> if (!serial && CONFIG_IS_ENABLED(OPTEE) &&
> tee_find_device(NULL, NULL, NULL, NULL))
> tee = true;
> -#endif
>
> memset(parts, 0, sizeof(parts));
> memset(ids, 0, sizeof(ids));
> @@ -139,9 +127,7 @@ void board_mtdparts_default(const char **mtdids, const char **mtdparts)
> if (!IS_ERR_OR_NULL(mtd)) {
> board_set_mtdparts("nand0", ids, parts,
> CONFIG_MTDPARTS_NAND0_BOOT,
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> !nor && tee ? CONFIG_MTDPARTS_NAND0_TEE : NULL,
> -#endif
> "-(UBI)");
> put_mtd_device(mtd);
> }
> @@ -152,9 +138,7 @@ void board_mtdparts_default(const char **mtdids, const char **mtdparts)
> if (!IS_ERR_OR_NULL(mtd)) {
> board_set_mtdparts("spi-nand0", ids, parts,
> CONFIG_MTDPARTS_SPINAND0_BOOT,
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> !nor && tee ? CONFIG_MTDPARTS_SPINAND0_TEE : NULL,
> -#endif
> "-(UBI)");
> put_mtd_device(mtd);
> }
> @@ -164,9 +148,7 @@ void board_mtdparts_default(const char **mtdids, const char **mtdparts)
> if (!uclass_get_device(UCLASS_SPI_FLASH, 0, &dev)) {
> board_set_mtdparts("nor0", ids, parts,
> CONFIG_MTDPARTS_NOR0_BOOT,
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> tee ? CONFIG_MTDPARTS_NOR0_TEE : NULL,
> -#endif
> "-(nor_user)");
> }
> }
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index 032f08d795..583f923d29 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -106,10 +106,10 @@ int checkboard(void)
> int fdt_compat_len;
>
> if (IS_ENABLED(CONFIG_TFABOOT)) {
> - if (IS_ENABLED(CONFIG_STM32MP15x_STM32IMAGE))
> - mode = "trusted - stm32image";
> - else
> + if (IS_ENABLED(CONFIG_TFABOOT_FIP_CONTAINER))
> mode = "trusted";
> + else
> + mode = "trusted - stm32image";
> } else {
> mode = "basic";
> }
> diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_tfaboot_fip_defconfig
> similarity index 99%
> rename from configs/stm32mp15_defconfig
> rename to configs/stm32mp15_tfaboot_fip_defconfig
> index e725b916b9..f7ef511e9c 100644
> --- a/configs/stm32mp15_defconfig
> +++ b/configs/stm32mp15_tfaboot_fip_defconfig
> @@ -1,6 +1,7 @@
> CONFIG_ARM=y
> CONFIG_ARCH_STM32MP=y
> CONFIG_TFABOOT=y
> +CONFIG_TFABOOT_FIP_CONTAINER=y
> CONFIG_SYS_MALLOC_F_LEN=0x3000
> CONFIG_SYS_MEMTEST_START=0xc0000000
> CONFIG_SYS_MEMTEST_END=0xc4000000
> diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig
> index 2e2f0c76ca..1671cb24f5 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -7,7 +7,6 @@ CONFIG_SYS_MEMTEST_END=0xc4000000
> CONFIG_ENV_OFFSET=0x280000
> CONFIG_ENV_SECT_SIZE=0x40000
> CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
> -CONFIG_STM32MP15x_STM32IMAGE=y
> CONFIG_TARGET_ST_STM32MP15x=y
> CONFIG_CMD_STM32KEY=y
> CONFIG_CMD_STM32PROG=y
For me you just inverse the logic for the config
CONFIG_STM32MP15x_STM32IMAGE => !CONFIG_TFABOOT_FIP_CONTAINER
I don't see the gain here, and this proposition will make more difficult
for me the introduction of the next product (in few months)
because it is based only on TF-A/FIP.
Sorry for the long answer, and sorry if my last update breaks
your OP-TEE load feature in SPL.
Patrick
More information about the U-Boot
mailing list