Thanks all for the inputs.

May I collect answers for these questions:

• Does the build system/IDE support sub-project for components and finally assemble them into one final image? The intention is to check the possibility to integrate TFM with sub-projects instead of a whole item.
• Is there scenarios that dynamic sections being added into sct/ld, how do you deal with this? A reference link is also helpful.

The intention:

TF-M is actually a set of components, and the secure firmware part (secure boot is another image binary so not listed here) contains:

1. Libraries.
2. Partitions.
3. SPM.
4. Image assembling with all above components.

The straight way is to generate  ABC as *.a and assemble them together into a final image.

Then go through each component, A and C can be configured in C domain, as what they needs maybe just some feature flags. B is a bit special but we still could provide specification defined .json and its compatible .yaml manifest and pre-generated C-based manifest with preprocessors.

D is the hard part, as it needs special arrangement inside ld/sct, which make this discussion happen. Even the ‘include’ and ‘preprocessor’ are supported inside sct/ld, we still can not avoid the partitions including part, we can not do a foreach on the partition list which involve the preprocessor complexity into sct/ld. Looks like the templating can’t be avoided here. For platform specific requirements like:

• Some platform won’t separate RODATA and CODE;
• Some platform got non-continuous memory regions for special data;

Put a platform dedicated sct/ld into the platform folder would help; but to mitigate the effort of platform, a common sct/ld needs to be abstracted.

Thanks again for  your great feedback.

/Ken

[History collapsed due to message size limitation]