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@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