This option is intended to tell u-boot platform code that this u-boot
build is expected to be used in a FIP container, as part of a TF-A
boot flow.
It is introduced because STM32MP1 platform code needs special
considerations on a FIP boot, such as a different partition layout,
and decisions about who should patch the FDT optee nodes.
This Kconfig can be justified as a natural extension of TFABOOT.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
arch/arm/Kconfig | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2d59562665..0bfdc2adc4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1907,6 +1907,21 @@ 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
+ help
+ TF-A has its own container format, named FIP (not to be confused with
+ FIT). The assumptions u-boot makes about the platform in a non-FIP
+ boot are not always true with FIP.
+ These differences could in theory be resolved with dynamic devicetree
+ patching. However TF-A either can't patch devicetrees, or is
+ unwilling to do so. Even then, passing such devicetree to u-boot
+ might require custom mechanisms.
+ 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.
+
config TI_SECURE_DEVICE
bool "HS Device Type Support"
depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
--
2.31.1
