Conflicting files should be described in mutual exclusive way (linker files issue).

[DavidJurajdaNXP]

According to current CMSIS pack specification is possible to describe conflicting files with identical condition. Conflict is later solved in MDK linker settings by manual selection.

Here is pdsc snippet from https://mcuxpresso.nxp.com/cmsis_pack/repo/NXP.LPC55S69_DFP.14.0.0.pack:

<file condition="core_id.cm33_core0_AND_core_type.cm33_AND_mdk" category="linkerScript" attr="config" name="arm/LPC55S69_cm33_core0_flash.scf" version="1.1.0"/>
<file condition="core_id.cm33_core0_AND_core_type.cm33_AND_mdk" category="linkerScript" attr="config" name="arm/LPC55S69_cm33_core0_flash_ns.scf" version="1.1.0"/>
<file condition="core_id.cm33_core0_AND_core_type.cm33_AND_mdk" category="linkerScript" attr="config" name="arm/LPC55S69_cm33_core0_flash_s.scf" version="1.1.0"/>
<file condition="core_id.cm33_core0_AND_core_type.cm33_AND_mdk" category="linkerScript" attr="config" name="arm/LPC55S69_cm33_core0_ram.scf" version="1.1.0"/>

Here is snapshot of manual selection in MDK linker menu: Example trustzone_examples\hello_world from: https://mcuxpresso.nxp.com/cmsis_pack/repo/NXP.LPCXpresso55S69_BSP.14.0.0.pack.

This selection is not possible in current Open CMSIS Pack yml project description.

I am recommending to update the standard and set new rule which would guarantee that any conflicting files would be distinguished by unique conditions or would be part of separated component (component variant). Mutual exclusivity become visible directly from pdsc file in such case. It is not obvious in current solution, which require input from different interface than "run time manager". Mutual exclusivity is currently hidden property of linkerScript ''category''.

Related discussion https://linaro.atlassian.net/wiki/spaces/CMSIS/pages/28685566173/Open-CMSIS-Pack+Technical+Meeting+2022-02-15

[jkrech]

@DavidJurajdaNXP, very well captured. Additional thoughts:

• even if we achieve the mutual exclusivity within the context of a component, we could have multiple unrelated components specifying a linker script.
• even if the GNU linker supports the concurrent use of multiple linker scripts, it will be impossible to ensure that any combination of linker scripts actually works.
• probably the component is not the right scope for specifying linker scripts.
• assuming that the resource management will be used to generate linker scripts, providing a "template" for different use cases may not be necessary

Talking about "exclusivity", we may want to consider making category="doc" exclusive for simplicity. Listing a set of documentation for a component makes the interface unnecessarily complicated.

[fred-r]

Can't we say for linker scripts (like any other config element):

• either it is provided by the configuration (CMSIS-Zone for linker scripts)
• or it is delivered as part of a layer ?

So, the component only needs to provide a "template" ?

[ReinhardKeil]

This is an issue that needs to be addressed.

[ReinhardKeil]

Could you describe the usage of the different linker script files. When as a user would I select which variant of the linker script? I believe the current approach of just list these files is where the problem starts.