linker script help: What is meant by >RAM_D1 AT> FLASH

[GreenGuy]

Posted on April 28, 2018 at 02:30

This follows the .data {....} section.  I think I understand the first part >RAM_D1 meaning the data sections start in the RAM_D1 memory who's origin is 0x240000000 in my case, but what does the AT> Flash do?  My guess is that since this section is for initialized data the values used to initialize the variables in this section are stored in flash and copied out to RAM_D1 starting at the origin.  This is why the next section for .bss simply ends with >RAM_D1.  If I am correct, then I am confused with the next section for .lwip_sec which is:

.lwip_sec (NOLOAD) : {

    . = ABSOLUTE(0x30040000);    *(.RxDecripSection)         . = ABSOLUTE(0x30040060);    *(.TxDecripSection)        . = ABSOLUTE(0x30040200);    *(.RxArraySection)   } >RAM_D2 AT> FLASH

So does this man that 1) there is initialized data in Flash that goes here and 2) what is meant by (NOLOAD) and 3) how does the linker or code know how to get said data to these sections *(...)?

[Tesla DeLorean]

Posted on April 28, 2018 at 04:19

The linker takes the section names described in the object file. Sections can be generated for individual functions, providing the Linker with the ability to do dead code elimination (recursive dependency trimming). In assemblers you can usually name the sections, and in compilers you usually have access to #pragmas or attributes.

Linker Scripts typically provide a means of marshaling specific objects, or sections within the object to specific areas of memory, and to hold them in a different monolithic (ROMable) image. Should end up with your executable code, and then your initial statics tacked on the back-end. You have to unpack it in your startup code, tools like Keil have a more elegant table driven unpacking scheme, where the table is built by the Linker. Keil was built for doing embedded, GNU for building EXE/DLLs for Linux, where the Loader takes the .ELF and jams the sections described into memory.

NOLOAD (like NOINIT in other systems) should mean there is no data behind the section in the .ELF file

When a .ELF file describes an app destined for ROM/FLASH the content of RAM needs to be unpacked from data in the ROM/FLASH, or zeroed out. The Linker should throw an error if non-zero data is placed in areas you indicate should be empty.

Having NOLOAD and AT> FLASH seems a bit contrived, probably a copy-n-paste job where the Linker remained happy

[Jack Peacock]

Posted on April 28, 2018 at 04:38

The purpose is to force certain sections of code to be resolved by the linker at a specific address, but store the initialcontents in a different memory region.  This is a common practice for initializing the C runtime, where a block of flash is copied to an SRAM region to initialize variable located there.

The '>RAM_D2 AT> FLASH' clause instructs the linker to resolve the addresses as if they were in the 'RAM_D2' region, but actually append the startup contents to the 'FLASH' region.  If the code section included global variables that were initialized to certain values at compile time, then the block of those values is stored in flash and copied to RAM at runtime initialization, right after reset.  This is what the 'AT>FLASH' does.

In your example the RX and TX buffers are assigned to RAM_D2 space but are not included in the binary image, otherwise (without the NOLOAD) you would have a huge binary since it would be a linear image from flash through SRAM regions.  In general any volatile memory region should include NOLOAD in the linker file.

The C runtime code at startup must be modified to explicitly load the RAM_D2 region from the block of flash allocated to the initialization values.  That's how the data gets there after reset.  Remember, all you have for non-volatile storage in a basic controller is the flash, so everything has to start from there.

  Jack Peacock