STM32MP15 ECO 5.0.0 unable to generate FIP bin files due to TF-A / Optee build tool issues

[debugging]

After building the TF-A from ECU 5.0.0 download (not the git). found the FIP folder and bin files. Deleted the FIP folder (export FIP_DEPLOYDIR_ROOT=$PWD/../../FIP_artifacts 

After running $ make -f $PWD/../Makefile.sdk all again the FIP folder and files are not generated anymore.Also tried make clean but no resolve.

Deleted the tf-a folder, restarted everything again (untar the tar etc...and followed all from the readme again ) but still not FIP folder or  files are generated, even the build does report the files were generate (see below output)

# for some reason this does not create the FIP folder and files  after the 1st time run ! it also delets the FIP_artifacts /arm... folder if run for a 2nd time ! this is the same with optee. Why is this designed this way ? the solution might be never ever run this:

$ make -f $PWD/../Makefile.sdk all

# for some reason this creates the FIP folder and output files but does not create default binaries

$ make -f $PWD/../Makefile.sdk DEPLOYDIR=$FIP_DEPLOYDIR_ROOT/arm-trusted-firmware all

How to regenerate FIP bin files to flash ?????

fiptool-stm32mp config:
optee:
bl32 config value: optee
devicetree config: stm32mp157c-ed1 stm32mp157f-ed1 stm32mp157a-ev1 stm32mp157c-ev1 stm32mp157d-ev1 stm32mp157f-ev1 stm32mp135f-dk stm32mp157a-dk1 stm32mp157d-dk1 stm32mp157c-dk2 stm32mp157f-dk2

Switch configuration:
FIP_BL31_ENABLE :

Output folders:
FIP_DEPLOYDIR_ROOT : /media/user/H3D2P1/Tools/STM32MP1/STM_ECO_5.0.0/Developer-Package/linux/stm32mp1-openstlinux-6.1-yocto-mickledore-mp1-v23.06.21/sources/arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/tf-a-stm32mp-v2.8.6-stm32mp-r1/../../FIP_artifacts
FIP_DEPLOYDIR_FIP : /media/user/H3D2P1/Tools/STM32MP1/STM_ECO_5.0.0/Developer-Package/linux/stm32mp1-openstlinux-6.1-yocto-mickledore-mp1-v23.06.21/sources/arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/tf-a-stm32mp-v2.8.6-stm32mp-r1/../../FIP_artifacts/fip
FIP_DEPLOYDIR_TFA : /media/user/H3D2P1/Tools/STM32MP1/STM_ECO_5.0.0/Developer-Package/linux/stm32mp1-openstlinux-6.1-yocto-mickledore-mp1-v23.06.21/sources/arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/tf-a-stm32mp-v2.8.6-stm32mp-r1/../deploy/bl32
FIP_DEPLOYDIR_BL31 : /media/user/H3D2P1/Tools/STM32MP1/STM_ECO_5.0.0/Developer-Package/linux/stm32mp1-openstlinux-6.1-yocto-mickledore-mp1-v23.06.21/sources/arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/tf-a-stm32mp-v2.8.6-stm32mp-r1/../deploy/bl31
FIP_DEPLOYDIR_FWCONF: /media/user/H3D2P1/Tools/STM32MP1/STM_ECO_5.0.0/Developer-Package/linux/stm32mp1-openstlinux-6.1-yocto-mickledore-mp1-v23.06.21/sources/arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/tf-a-stm32mp-v2.8.6-stm32mp-r1/../deploy/fwconfig
FIP_DEPLOYDIR_OPTEE : /media/user/H3D2P1/Tools/STM32MP1/STM_ECO_5.0.0/Developer-Package/linux/stm32mp1-openstlinux-6.1-yocto-mickledore-mp1-v23.06.21/sources/arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/tf-a-stm32mp-v2.8.6-stm32mp-r1/../../FIP_artifacts/optee
FIP_DEPLOYDIR_UBOOT : /media/user/H3D2P1/Tools/STM32MP1/STM_ECO_5.0.0/Developer-Package/linux/stm32mp1-openstlinux-6.1-yocto-mickledore-mp1-v23.06.21/sources/arm-ostl-linux-gnueabi/tf-a-stm32mp-v2.8.6-stm32mp-r1-r0/tf-a-stm32mp-v2.8.6-stm32mp-r1/../../FIP_artifacts/u-boot

 

[Erwan SZYMANSKI]

Hello @debugging ,
Thank you for your feedback. I do not face the same trouble with executing make -f $PWD/../Makefile.sdk all command. Can you please attach the output logs when you start from scratch and execute this command ?
I well see the fip folder with binaries inside from my side with following the README file.

Kind regards,
Erwan.

[debugging]

At 1st run the bin files are created but next runs there are not. When you delete FIP folder with the bins and run the command again do you see the FIP binaries ?

 

[Erwan SZYMANSKI]

@debugging,
I deleted everything to be sure to start from scratch and please see the different steps I make below:

- unzip the TF-A tarball
- Go inside the folder and apply the patch delivered in the tarball (explanation in README file)
    (for p in `ls -1 ../*.patch`; do patch -p1 < $p; done)
- export FIP_DEPLOYDIR_ROOT=$PWD/../../FIP_artifacts
- make -f $PWD/../Makefile.sdk all

Now with doing this, no error during compilation, and outputs are:
- all binaries in ../deploy folder
- all fip binaries in ../../FIP_artifacts/fip folder

Can you cross check these steps from your side ?
Kind regards,
Erwan.

[debugging]

I am assuming the script creates u-boot folder and the .dtb file. Correct ?/ If yes, it did not create the u-boot folder and if it needs that to complete the build, logically that does not work.

Are you using the latest tf-a repo from ECIO or git ?

A much  quicker way to build TF-A than going through the whole SDK/ECO download is: (make sure the SDK is set to $ARCH=arm)

$ git clone https://github.com/STMicroelectronics/arm-trusted-firmware.git
$ cd arm-trusted-firmware
$ git checkout -b WORKING v2.8-stm32mp-r12

# Get the Makefile.sdk from the STM ECO 5.0.0 TF-A repository and put it in the root above the source (because .sdk file is missing on git)

$ export FIP_DEPLOYDIR_ROOT=$PWD/../../FIP_artifacts

$ make -f $PWD/../Makefile.sdk all

 

[debugging]

Did the whole thing again on a different drive, under the home folder. same result, no FIP_artfacts folder. attached is thelog. you can see it builds the dtb with DTC but somehow they are not in the output folders. Are you using the   the latest Developer package image or git repo ?

and BTW on this page the Yocto and SDK links are reversed. https://www.st.com/en/embedded-software/stm32mp1dev.html

and BTW the wiki does not mention to first use ggzip -d en.SDK-x86_64-stm32mp1-openstlinux-6.1-yocto-mickledore-mp1-v23.06.21.tar.gz
https://wiki.st.com/stm32mpu/wiki/STM32MP1_Developer_Package#Building_and_deploying_the_TF-A_for_the_first_time

it may be a good thing if someone worked through the wiki and checks if all steps are correct.

 

[debugging]

I guess I understand now what is going on. The ECO system sources tar file contains the FIP artifacts folder already with  u-boot and optee folder with the binaries. The TF-A make won't generate those binaries. that is why when the FIP_artifacts  folder is deleted, the u-boot and optee binary folder and files are not generated.

The generated FIP images are available in <FIP_DEPLOYDIR_ROOT>/fip

This is now correct.

TF-A makefile.sdk does not  generates any files in the output folder except for /fip. but it needs the ub-boot and optee files in that folder. So if the FIP_artifacts_u-boot or optee is deleted you need to get them again from the original ECO sources tar file. It means when building TF-A from the repo from github, it is not possible to build all files in FIP_artifacts. That means,  the u-boot and optee files must be taken from the FIP_artifacts folder in the original ECO  sources tar, The github and ECO tar file README should mention this, or at least point where those u-boot and optee binaries can be found for a successful build..(if by accident or other reason the  files are deleted). I placed those FIP_artifact u-boot and optee folders in the ../../FIP_artifacts  folder for building from the git repo and the  fip's are now correctly created. The only one exception us the on failing is for my custom board dts That is due to the .bin file missing in the optee and u-boot  folder.

Now my question are

1. Outside  the ECO sources tar file, where can these FIP_artifacts u-boot and optee binaries be downloaded or how to generate them ?

2. For a custom board, where can the bin files for u-boot and optee be found ? Assume the u-boot and and optee binaries for the board be placed in the FIP_artifacts folder  for the TF-A build ? In other words, the optee and u-boot .bin files should be build BEFORE TF-A ?  I  added the dtb file from a trusted u-boot build of the custom board (renamed from uboot-,dtb to the board name as in the makefile.sdk) in the u-boot folder of FIP_artifacts manually and the build the  custom board .bin files are in the optee and in fip folders. It seems the TF-A script does not use the .dts file in the ftds folder to generate the dtb for the board. CubeMX generates a different .dts file for TF-A and u-boot. and I placed the dts of TF-A in the fdts folder and biuld u-boot.dtb with the u-boot dts file..

3. Did you try to  delete the FIP_artifacts folder as I stated in the OP, and does the make regenerate  the u-boot and optee binary files  ?

 

[Erwan SZYMANSKI]

@debugging ,
You are right, that is why I asked if uboot file was already present in your artifact folder.

I think there was a misunderstanding concerning this folder so I will try to explain a little bit more how does it work, and I hope it will answer all your question in one.

Our BSP is composed by TF-A, UBOOT, OPTEE and Linux Kernel. We will keep the kernel out of this scope because it is not embedded in the FIP.

The Makefile.sdk with the all rule, both compile TF-A (this step is always good from your side) but also create the final FIP that will be deployed on the target.
But here, you are building only TF-A, so the new binaries that you you generate are only relative to TF-A ! It means that to compose your final FIP, you also need the U-Boot and OP-TEE binary files. But as you only compile TF-A, it will be impossible for the Makefile.sdk to invent U-boot and OP-TEE binaries, that is why we provide the FIP_artifacts folder. This is to provide you the other binaries that compose your FIP, and that are not generated by yourself.
If you erase these binaries, your FIP will be incomplete and ends with an error as you could have seen before in your case.

So, in a context of a custom board, how to process ?
In fact, in a custom board, you often have to update each element of the BSP.  So you will compile TF-A, U-boot, OP-TEE, and then create a new FIP (you can see it like a box) where you will put inside each binary needed and waited by the BSP.

If you want to take the default binaries provided by ST, you can find it in the Starter Package we deliver each release (in the Flash tarball (see this article)).

I hope you have now a better view of how the FIP works, and why you faced your issue before.

Kind regards,
Erwan.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.