Remove CCM SRAM definitions for devices without this memory type

[ThomasGravekamp]

All linker scripts currently contain a definition for CCM SRAM. A lot of devices do not have this type of SRAM.

Look into the possibilities of omitting this definition for devices without CCM SRAM. For example, does ld throw an error when it is omitted? Or are there options to conditionally execute parts of linker scripts?

[gszy]

Or are there options to conditionally execute parts of linker scripts?

Have you considered splitting the common.ld script into several smaller ones? (See https://stackoverflow.com/questions/55638429/why-would-a-linker-script-have-multiple-section-commands.) Then, for example, the F030x4 script could look like this:

MEMORY {
    FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 16K
    RAM   (wx) : ORIGIN = 0x20000000, LENGTH = 4K
}

INCLUDE entry-point-no-ccmram.ld

That entry-point-no-ccmram.ld script would include all SECTIONS files except .ccmram, roughly something like:

INCLUDE section-isr.ld
INCLUDE section-text.ld
/* … other INCLUDEs, but no CCMRAM … */
INCLUDE section-arm-attrs.ld

Each of these files would contain a SECTIONS statement with one output section (or more) defined.

[ThomasGravekamp]

I found a different approach for this. See the GH-6-refactor-linker-files branch.

The linker files specific to devices contain only memory regions that the device actually has. They also contain separate regions for the different flash banks a device might have. A little bit more thought needs to go into how one may use two memory banks as one when they're next to each other in the address space.

There should be an additional config.ld file on project level which should define aliases for memory regions. So instead of putting .text into FLASH, it would put it into TEXT_REGION or something like that. The config.ld would then contain an alias like this: REGION_ALIAS("TEXT_REGION", FLASH_BANK_1);.

This also allows for defining custom sections on project level for memories like CCM.

Let me know what you think of this approach.

[gszy]

Well, I had seen that branch, but hadn’t known, what that config.ld file should contain. Thank you for explaining that. TEXT_REGION­‑like aliases seem useful.

I think providing some default config.lds, for each device series, is also worth considering. It would make it easier to use STM32-base in basic projects, especially on simpler devices (that only have FLASH and RAM), as their authors wouldn’t have to worry about maintaining yet another config file. And even if that default file wasn’t included (in Makefiles) by default, one could simply symlink it in their project directory and have it always up to date (not that it’s going to change often…).

[ThomasGravekamp]

I think providing some default config.lds, for each device series, is also worth considering.

Yep. Templates should work out of the box after completing the setup guide. This means that the templates will have to be updated to include a default config.ld.

And there needs to be documentation on how to make changes to the config.ld.

[gszy]

This means that the templates will have to be updated to include a default config.ld.

That is, that default config.ld (path) would be set as a Makefile variable, there wouldn’t be actual config.ld files in the templates?

[ThomasGravekamp]

Yes, I think there will be actual config.ld files in the templates. The config.ld files can be changed by users, so I want that file to be already there. I don't want users to change add things to the make file in their project, only if they prefer a different location of the config.ld file.