What's wrong with this Linker script?

IoT Modules Development tools
1

Trying to get Persistent RAM to work with an SDK before v2.10 and/or firmware before R7.2
See: Persistent RAM - ADL_MEM_UNINIT
And: How to customise gcc.lkopt ?

This is the standard gcc.lkopt script used by M2MStudio:

The bits to do with the “Persistent RAM” are, I think, all the red stuff.

This doesn’t work with v6.63 Firmware - stuff gets corrupted & the app crashes - presumably because the firmware thinks that everything past Image$$ZI$$Limit is Free RAM and, hence, uses it for the Heap, etc?

Moving the definition of Image$$ZI$$Limit stops the corruption/crashing, but the UNINIT data gets cleared at startup - presumably because the firmware uses Image$$ZI$$Limit when it clears RAM?

Moving the whole .uninit section definition before the .bss section definition has similar results (data does not “persist”).

If I move the .uninit section definition before the .data section like this:

then the size of the .axf file balloons from under 10MB to over 400MB!! :open_mouth:

The resulting .bin file balloons from under 300KB to nearly 400MB;
the .dwl file goes from under 190KB to nearly 600KB - and fails to load (AT+wDWL gives MEMORY ALLOCATION ERROR)

SO the question is: why does this cause such ballooning of the .axf file size :question:

If I modify the script to explicitly set the start of the .data section, like this:

then the size of the .axf file returns to under 10MB :slight_smile:
But the .bin file remains at nearly 400MB, and the .dwl at nearly 600KB - and still fails to load (AT+wDWL gives MEMORY ALLOCATION ERROR)

So, again, the question is: What is causing this ballooning of the .bin and .dwl file sizes - even though the .axf file size is back to “normal” :question:

2

OK - I’ve been using objdump -p -h to see the sections in the .axf file.

For the “standard” M2MStudio linker script (giving ~10MB .axf file and ~300KB .bin), it shows:

cbox_424.axf:     file format elf32-littlearm

Program Header:
    LOAD off    0x00000054 vaddr 0x00210000 paddr 0x00210000 align 2**2
         filesz 0x0004798c memsz 0x00052568 flags rwx
private flags = 206: [interworking enabled] [APCS-32] [FPA float format] [software FP] [has entry point]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .oat_header   0000003c  00210000  00210000  00000054  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00046ddc  0021003c  0021003c  00000090  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .data         00000b74  180c0000  00256e18  00046e6c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0000abdc  180c0b74  180c0b74  000479e0  2**2
                  ALLOC
  4 .uninit       00000000  180cb750  180cb750  000479e0  2**0
                  CONTENTS
  5 .debug_abbrev 00018e3f  00000000  00000000  000479e0  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_info   0008dfde  00000000  00000000  0006081f  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_line   0005a06d  00000000  00000000  000ee7fd  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_macinfo 0072b309  00000000  00000000  0014886a  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_pubnames 000066b2  00000000  00000000  00873b73  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_str    00014fd7  00000000  00000000  0087a225  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .comment      0000142e  00000000  00000000  0088f1fc  2**0
                  CONTENTS, READONLY
 12 .debug_frame  000097cc  00000000  00000000  0089062c  2**2
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_loc    0003ba19  00000000  00000000  00899df8  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_aranges 00002360  00000000  00000000  008d5818  2**3
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_ranges 00002c60  00000000  00000000  008d7b78  2**0
                  CONTENTS, READONLY, DEBUGGING

Note the “filesz 0x0004798c memsz 0x00052568” (ie, 293260 and 337256).

With the script modified to move the .uninit section definition before the .data section (giving ~400MB .axf file and ~400MB .bin), it shows:

cbox_424.axf:     file format elf32-littlearm

Program Header:
    LOAD off    0x00000054 vaddr 0x00210000 paddr 0x00210000 align 2**2
         filesz 0x17eb0b80 memsz 0x17ebb768 flags rwx
private flags = 206: [interworking enabled] [APCS-32] [FPA float format] [software FP] [has entry point]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .oat_header   0000003c  00210000  00210000  00000054  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00046ee8  0021003c  0021003c  00000090  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .uninit       0000000c  180c0000  180c0000  00046f78  2**2
                  ALLOC
  3 .data         00000b74  180c000c  180c000c  17eb006c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          0000abdc  180c0b80  180c0b80  17eb0be0  2**2
                  ALLOC
  5 .debug_abbrev 00018e3f  00000000  00000000  17eb0be0  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_info   0008dff2  00000000  00000000  17ec9a1f  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_line   0005a09f  00000000  00000000  17f57a11  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_macinfo 0072b58f  00000000  00000000  17fb1ab0  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_pubnames 000066c4  00000000  00000000  186dd03f  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_str    00014fe5  00000000  00000000  186e3703  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .comment      0000142e  00000000  00000000  186f86e8  2**0
                  CONTENTS, READONLY
 12 .debug_frame  000097e8  00000000  00000000  186f9b18  2**2
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_loc    0003ba19  00000000  00000000  18703300  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_aranges 00002360  00000000  00000000  1873ed20  2**3
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_ranges 00002c60  00000000  00000000  18741080  2**0
                  CONTENTS, READONLY, DEBUGGING

Note the “filesz 0x17eb0b80 memsz 0x17ebb768” (ie, 401279872 and 401323880)

With the script modified to explicitly set the start of the .data section (back to ~10MB .axf file, but still ~400MB .bin), it shows:

cbox_424.axf:     file format elf32-littlearm

Program Header:
    LOAD off    0x00000054 vaddr 0x00210000 paddr 0x00210000 align 2**2
         filesz 0x00047aa4 memsz 0x0005268c flags rwx
private flags = 206: [interworking enabled] [APCS-32] [FPA float format] [software FP] [has entry point]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .oat_header   0000003c  00210000  00210000  00000054  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00046ee8  0021003c  0021003c  00000090  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .uninit       0000000c  180c0000  180c0000  00046f78  2**2
                  ALLOC
  3 .data         00000b74  180c000c  180c000c  00046f90  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          0000abdc  180c0b80  180c0b80  00047b04  2**2
                  ALLOC
  5 .debug_abbrev 00018e3f  00000000  00000000  00047b04  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_info   0008dff2  00000000  00000000  00060943  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_line   0005a09f  00000000  00000000  000ee935  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_macinfo 0072b58f  00000000  00000000  001489d4  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_pubnames 000066c4  00000000  00000000  00873f63  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_str    00014fe5  00000000  00000000  0087a627  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .comment      0000142e  00000000  00000000  0088f60c  2**0
                  CONTENTS, READONLY
 12 .debug_frame  000097e8  00000000  00000000  00890a3c  2**2
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_loc    0003ba19  00000000  00000000  0089a224  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_aranges 00002360  00000000  00000000  008d5c40  2**3
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_ranges 00002c60  00000000  00000000  008d7fa0  2**0
                  CONTENTS, READONLY, DEBUGGING

Note the “filesz 0x00047aa4 memsz 0x0005268c” (ie, 293540 and 337548).
This is now about the same as the original - so why is the .bin file still bloated :question:

Do I need to change the options to objcopy (which creates the .bin from the .axf) :question:
If so, how :question:

3

It looks like some (unnecessary?) padding is being inserted - but where? and why? and how to stop it?!

4

Here’s a useful article on GCC Linker Scripts: warmi.net/docs/gnupro/5_ut/b … ripts.html

The secret is in:

The “AT” specifies the location for the section in the ROM Image (the LMA) - not in the runtime memory (VMA).
(the ROM image contains the initialisation values which are copied into the runtim RAM location at startup).

So my script should have looked something like:

.text :
   {
      :
      :
      _etext = .;
   } > ROM_MAP :appli

   .uninit (NOLOAD) :
   {
      :
      :
   } > RAM_MAP :appli

  .data :  AT (_etext)
   {
      :
      :
   } > RAM_MAP :appli

   .bss :
   {
      :
      :
   } > RAM_MAP :appli

With that, I get sensible sizes for both the .axf file and binary files. :slight_smile:

The code loads OK with AT+WDWL, but the application doesn’t start.

AT+WOPEN=7 gives +WOPEN: 7,8 - which means, “Link Issue. The application global variables area initialisation is impossible”

SO it does look like this is impossible with this firmware. :cry:

Unless someone can think of a way to tell the firmware not to use the top of RAM…?

5

Wow… a deep investigation :wink:
… to get the final result I was afraid of…

BTW, please note that if you move to Devleoper Studio 1.1.2, you’ll see that the default linker script has been modified a bit, to make it compatible with both current ARM ELF GCC 4.0.1, and new ARM EABI GCC 4.4.1 now shiped with the studio.
Unfortunately, it shouldn’t help you, in this case, it’s just for information.
It’s true that GCC linker seems to easily run away on generating huge output files when wrong linker script syntax. We had headackes for several days when trying to tune the new script; and the trickiest part is to understand why the linker script is wrong…