Why two separate TF-A binaries in BSP 2.0.0

[Grodriguez]

I have noticed that in BSP 2.0.0, two different TF-A binaries are built, one installed as fsbl and one used only for communications with STM32CubeProgrammer (the "serialboot" binary). I believe this was not necessary in BSP 1.2.0, where a single TF-A binary was used for both purposes.

I am just curious why this split is needed. Isn't it possible to build one single TF-A binary which would work for both purposes? What has changed from BSP 1.2.0 to 2.0.0 that makes it necessary to use separate binaries?

Thanks.

[Olivier GALLIEN]

Hi @Grodriguez​ ,

This split has been introduced to deal with memory constraint with TF-A in BSP V2.0.

Due to some added features/services ( SCMI, DVFS ) and ST board combinatory, TF-A no more fit in memory budget.

So ST decided to remove "serialboot" service support from the embedded version and keep them only in the "serialboot" profile require for flash.

If this 2 binaries approach is a problem for you ( thanks to elaborate since not forecasted on our side), you can indeed come back to a single profile by building a

custom / reduced TF-A fitting your need.

Hope it answer your question.

Olivier

[Grodriguez]

Hi @Community member​ ,

Thank you for your informative answer.

Not really a "problem" but it is easier for me if I can use a single TF-A image for both uses (less artifacts to manage). Your suggestion of building a reduced TF-A is perfect since I don't really need to support all possible boot devices.

Thanks!

Guillermo