[En-Nut-Discussion] Devnut_m3n: Changing the linker stage

[Ulrich Prinz]

No problem for me if you warn me early on implementation.
We have about 20 devices running on STM32 and the actual linker
installation but use a local different linker script. So check for the
option to use such a local script instead of the configured ones.

I see no use for the RAM debugging version of the ld script as CortexM
series do not have these ugly bugs in flash debugging like the older
ARM7 chips. So you can debug more clos to real life where your
application is in flash and your data in RAM.
Running latest dbg >= 6.2 works pretty fine from flash.

We have a bootloader implementation too, but that is highly application
dependant. So we use lower 8k of flash for the bootloader, rest for
application, top flash for configuration data. RAM is used by both,
bootloader and application until the last two words which are shared by
both. Through the last two words of RAM the application can force the
bootloader to run after soft-reset. On the other hand the bootloader can
tell the application its version and state through these two words.

Ulrich

Am 20.01.2012 13:30, schrieb Uwe Bonnes:
> Hello,
> 
> while the actual requirement in real world may still be different, I see
> three prominent situations:
> - Run standalone from flash
> - Run after a bootloader from flash
> - Run from ram when developping
> 
> At present each device has a linker script like
> stm32f107xC_flash.ld. This linker script hard included stm32f10x_flash.ld.
> 
> I proposed to remove the hard include and construct the linker calls like
> 
> -L<directory> -Tstm32f107xC.ld {-Tstm32f1_boot.ld} -Tstm32f10x_flash.ld
> 
> where:
>  stm32f107xC.ld only defines the device specific FLASH0 and RAM0 values
>                 and a bootloader_offset variable with size 0
>  stm32f1_boot.ld eventually redefines the bootloader_offset
>  stm32f10x_flash.ld contains the family specific definitions as before
>                     and has a bootloader section with the NOLOAD option and
>                     the bootloader size before the text section
> 
> This way we could keep the needed number of different linker scripts
> small. The present approach would need 3 scripts for each device. Maybe
> there is even way to define bootloader_offset on the command line.
> 
> Any options?
> 
> The files would look like
> 
> /******************************************************************************
>  *
>  *  stm32f107xC_flash.ld - linker script for nutos on cotrex-m3 STM32F107xC
>  *
>  *****************************************************************************/
> 
> ENTRY(NutInit)
> SEARCH_DIR(.)
> 
> "bootloader_offset" = 0x00;
> 
> MEMORY
> {
>     FLASH0 (rx) : ORIGIN = 0x08000000, LENGTH = 256K
>     SRAM0 (rwx) : ORIGIN = 0x20000000, LENGTH = 64K
> ===
> /******************************************************************************
>  *
>  *  bootloader offset
>  *
>  *****************************************************************************/
> 
> "bootloader_offset" = 0x800;
> ===
> /****************************************************************************
>  *
>  * stm32f10x_flash.ld - linker script include for nutos on cotrex-m3 STM32F series
>  *
>  *****************************************************************************/
> 
> /* PROVIDE (__heap_start = _sheap); */
> 
> _ramend = ORIGIN(SRAM0) + LENGTH(SRAM0);
> 
> SECTIONS
> {
>     .bootloader (NOLOAD):
>     {
> 	. = bootloader_offset;
>     } > FLASH0
> 
>     .text :
>     {
> ...