[PATCH 2/3] arm: Kconfig: Introduce a TFABOOT_FIP_CONTAINER option

[Alexandru Gagniuc]

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.me at 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