ARM: stm32mp: build extra barebox-stm32mp-generic-bl33.img

barebox-dt-2nd.img expects being loaded at an offset, so the stack can
grow down from entry point. The STM32MP TF-A default is to not have an
offset. Avoid this issue by having a stm32mp specific entry point that
sets up a 64 byte stack after end of barebox. As it's stm32mp-specific
anyway, we can skip the early FDT parsing and ask the SDRAM controller
about RAM size.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20220220124736.3052502-8-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

1 files changed, 44 insertions, 7 deletions

diff --git a/Documentation/boards/stm32mp.rst b/Documentation/boards/stm32mp.rst
index 2b9dc01b55..55bdafe785 100644
--- a/Documentation/boards/stm32mp.rst
+++ b/Documentation/boards/stm32mp.rst
@@ -13,20 +13,26 @@ then the second stage boot loader (SSBL) is loaded into DRAM.
 When building barebox, the resulting ``barebox-${board}.stm32`` file has the STM32
 header preprended, so it can be loaded directly as SSBL by the ARM TF-A
 (https://github.com/ARM-software/arm-trusted-firmware). Each entry point has a
-header-less image ending in ``*.pblb`` as well.
+header-less image ending in ``*.pblb`` as well. Additionally, there is
+a ``barebox-stm32mp-generic.img``, which is a header-less image for
+use as part of a Firmware Image Package (FIP).
 
-Use of barebox as FSBL is not supported.
+barebox images are meant to be loaded by the ARM TF-A
+(https://github.com/ARM-software/arm-trusted-firmware). FIP images are
+mandatory for STM32MP1 since TF-A v2.7.
+
+Use of barebox as FSBL is not implemented.
 
 Building barebox
 ----------------
 
-With multi-image and device trees, it's expected to have ``stm32mp_defconfig``
-as sole defconfig for all STM32MP boards::
+There's a single ``stm32mp_defconfig`` for all STM32MP boards::
 
   make ARCH=arm stm32mp_defconfig
 
 The resulting images will be placed under ``images/``::
 
+  barebox-stm32mp-generic-bl33.img
   barebox-stm32mp15xx-dkx.stm32
   barebox-stm32mp15x-ev1.stm32
   barebox-stm32mp157c-lxa-mc1.stm32
@@ -37,13 +43,44 @@ The resulting images will be placed under ``images/``::
   barebox-dt-2nd.img
 
 In the above output, images with a ``.stm32`` extension feature the (legacy)
-stm32image header. ``barebox-dt-2nd.img`` is a generic barebox image that
-received an external device tree.
+stm32image header. ``barebox-dt-2nd.img`` and ``barebox-stm32mp-generic-bl33.img``
+are board-generic barebox images that receive an external device tree.
+
+Flashing barebox (FIP)
+----------------------
+
+After building barebox in ``$BAREBOX_BUILDDIR``, change directory to ARM
+Trusted Firmware to build a FIP image. Example building STM32MP157C-DK2
+with SP_min (no OP-TEE):
+
+.. code:: bash
+
+    make CROSS_COMPILE=arm-none-eabi- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 \
+        STM32MP_EMMC=1 STM32MP_EMMC_BOOT=1 STM32MP_SDMMC=1 STM32MP_SPI_NOR=1 \
+        AARCH32_SP=sp_min \
+        DTB_FILE_NAME=stm32mp157c-dk2.dtb \
+        BL33=$BAREBOX_BUILDDIR/images/barebox-stm32mp-generic-bl33.img \
+        BL33_CFG=$BAREBOX_BUILDDIR/arch/arm/dts/stm32mp157c-dk2.dtb \
+        fip
+
+For different boards, adjust ``DTB_FILENAME`` and ``BL33_CFG`` as appropriate.
+
+If OP-TEE is used, ensure ``CONFIG_OPTEE_SIZE`` is set appropriately, so
+early barebox code does not attempt accessing secure memory.
+
+barebox can also be patched into an existing FIP image with ``fiptool``:
+
+.. code:: bash
+
+    fiptool update mmcblk0p3  \
+      --nt-fw $BAREBOX_BUILDDIR/images/barebox-stm32mp-generic-bl33.img \
+      --hw-config $BAREBOX_BUILDDIR/arch/arm/dts/stm32mp135f-dk.dtb
 
 Flashing barebox (legacy stm32image)
 ------------------------------------
 
-An appropriate image for a SD-Card can be generated with following
+After building ARM Trusted Firmware with ``STM32MP_USE_STM32IMAGE=1``,
+an appropriate image for a SD-Card can be generated with following
 ``genimage(1)`` config::
 
   image @STM32MP_BOARD@.img {