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]