Linker Script und Externer RAM

[Ch. Z. (crozeg)]

Hallo,

ich habe eine neue Entwicklungsumgebung für meinen STM32F4107ZG 
eingerichtet.
Die Entscheidung ist auf Em::Blocks (mit ARM GCC Compiler) gefallen.
Soweit läuft alles top ;).

An meinem STM32F4107ZG ist ein Externes RAM angeschlossen (ERAM1), 
woraus im LinkerSkript der folgende Memory Aufbau resultiert:

------------------------------------------------------------------------ 
-

MEMORY
{
  IROM1   (RX)    : ORIGIN = 0x08000000,  LENGTH = 0x00100000
  IRAM2   (RW)    : ORIGIN = 0x10000000,  LENGTH = 0x00010000
  IRAM1   (XRW)   : ORIGIN = 0x20000000,  LENGTH = 0x00020000
  ERAM1   (RW)    : ORIGIN = 0x60000000,  LENGTH = 0x00080000
}

...

.bss :
{
   _sbss = .; /* define a global symbol at bss start */
   _bss_start_ = _sbss;
   *(.bss)
   *(.bss*)
   *(COMMON)

   . = ALIGN(4);
   _ebss = .; /* define a global symbol at bss end */
   _bss_end_ = _ebss;
} >IRAM1

...

------------------------------------------------------------------------ 
-

Jetzt ist meine .bss-Sektion so groß das sie in keine der RAMs passt. 
Ich will dem LinkerSkript gerne folgendes sagen:
"Schreibe die .bss-Sektion erstmal in IRAM1 bis es voll ist, dann 
schreibe weiter in IRAM2 bis es voll ist und dann weiter in ERAM1."
Ich will sozusagen die RAMs aneinander hängen.

Ist das möglich?
Wenn ja, wie?

Viele Grüße
crozeg

.

[Alex E. (tecnologic)]

Hi,

so weit ich wieß geht das so nicht du wirst deine Variablen auf mehrere 
bss sections aufteilen müssen. Dann kannst du eine in jedem Ram anlegen.

Gruß

Tec

[Ch. Z. (crozeg)]

Hallo,

Schonmal danke für die schnelle Antwort.
Ich bin noch neu in LinkerScripting.
Kannst du mir verraten wie ich die Variablen auf mehrere .bss-Sektionen 
aufteile?

Viele Grüße
crozeg

.

[Alex E. (tecnologic)]

.bss2 :
{
   _sbss2 = .; /* define a global symbol at bss start */
   bss2_start = _sbss2;
   *(.bss2)
   *(.bss2*)
   *(COMMON)

   . = ALIGN(4);
   _ebss2 = .; /* define a global symbol at bss end */
   bss2_end = _ebss2;
} >ERAM1

und bei den Variablen Deklaration "__attribute__((section(".bss2")))"

das sollte dann passen. Vllt gibts auch n Makefile generator von 
Em:Blocks? Das man sowas über die Ide einstellen kann. Crossworks kann 
so was.

[Markus F. (mfro)]

Ch. Ziegler schrieb:
> Jetzt ist meine .bss-Sektion so groß das sie in keine der RAMs passt.
> Ich will dem LinkerSkript gerne folgendes sagen:
> "Schreibe die .bss-Sektion erstmal in IRAM1 bis es voll ist, dann
> schreibe weiter in IRAM2 bis es voll ist und dann weiter in ERAM1."

Ich hab's jetzt nicht selbst ausprobiert, das müsste aber eigentlich so 
gehen:

.bss1 :
{
   _sbss1 = .; /* define a global symbol at bss start */
   _bss_start_ = _sbss1;
   dir1/*(.bss)
   dir1/*(.bss*)
   dir1/*(COMMON)

   . = ALIGN(4);
   _ebss = .; /* define a global symbol at bss end */
   _bss_end_ = _ebss1;
} >IRAM1

.bss2 :
{
   _sbss2 = .; /* define a global symbol at bss start */
   _bss2_start_ = _sbss2;
   dir2/*(.bss)
   dir2/*(.bss*)
   dir2/*(COMMON)

   . = ALIGN(4);
   _ebss2 = .; /* define a global symbol at bss end */
   _bss2_end_ = _ebss2;
} > IRAM2

D.h. Du "sammelst" die Objektdateien in zwei Verzeichnissen, aus denen 
sich der Linker dann pro Segment bedient. So was wie einen 
"automatischen Überlauf" gibt's meiner Ansicht nach nicht.

[Marc P. (marcvonwindscooting)]

Ja, das nervt, dass die uC-Hersteller das RAM so zerstueckeln :(

Generell finde ich es aber sowieso schoener, die sections explizit im 
C-code anzugeben, damit man mit dem Linker-Script noch jonglieren kann. 
Wo man den Stack hinlegt wird ja wohl auch zu einer ganz wichtigen 
Entscheidung - vielleicht wichtiger als die die .bss Variablen.
Ich vermeide die .bss-Variablen meist zugunsten von Stack-Variablen, 
wegen deren Speicher-Wiederverwertung ;-)

Aber ich hoffe, dass noch ein Toolchain-Guru hier eine L"osung bietet.
Ich koennte sowas n"amlich sinngemaess in der .text brauchen...

[Ch. Z. (crozeg)]

Wie und wo sage ich dem LinkerScript welche Dateien/Objekte er in welche 
Section legen soll?

Kennt jemand vielleicht ein gutes Tutorial für die ganze Sache hier?

Viele Grüße,
crozeg

.

[Ch. Z. (crozeg)]

Tec Nologic schrieb:
> und bei den Variablen Deklaration "__attribute__((section(".bss2")))"

Gibt es anstatt "__attribute__((section(".bss2")))" auch ein #pragma für 
eine ganze C-Datei?


Markus F. schrieb:
> D.h. Du "sammelst" die Objektdateien in zwei Verzeichnissen, aus denen
> sich der Linker dann pro Segment bedient. So was wie einen
> "automatischen Überlauf" gibt's meiner Ansicht nach nicht.

Wie teilt man die *.o-Dateien auf verschiedene Unterverzeichnisse auf? 
Die Sourcedateien liegen bereits in verschiedenen Unterordnern, die 
O-Dateien werden beim Bauen in einem einzigen Ordner abgelegt.


Viele Grüße
crozeg

[Alex E. (tecnologic)]

Du kannst eine die bss section einer datei im Linkerskript angeben.

.bss2 :
{
   _sbss2 = .; /* define a global symbol at bss start */
   _bss2_start_ = _sbss2;
   dir2/*main.o(.bss .bss*) // hier wird bss von main gesetzt.
   dir2/*(.bss) //
   dir2/*(.bss*)
   dir2/*(COMMON)

   . = ALIGN(4);
   _ebss2 = .; /* define a global symbol at bss end */
   _bss2_end_ = _ebss2;
} > IRAM2

ich weis aber gerade nicht ob das ganz korrekt ist. Vllt weiß das noch 
jemand anderes.

[Alex E. (tecnologic)]

Korrektur:

There are two ways to include more than one section: 

*(.text .rdata)
*(.text) *(.rdata)

The difference between these is the order in which the `.text' and `.rdata' input sections will appear in the output section. In the first example, they will be intermingled. In the second example, all `.text' input sections will appear first, followed by all `.rdata' input sections. 

You can specify a file name to include sections from a particular file. You would do this if one or more of your files contain special data that needs to be at a particular location in memory. For example: 

data.o(.data)

.bss2 :
{
   _sbss2 = .; /* define a global symbol at bss start */
   _bss2_start_ = _sbss2;
   main.o(.bss) // hier wird bss von main gesetzt.
   foo.o(.bss)  // usw.
   dir2/*(.bss) //
   dir2/*(.bss*)
   dir2/*(COMMON)

   . = ALIGN(4);
   _ebss2 = .; /* define a global symbol at bss end */
   _bss2_end_ = _ebss2;
} > IRAM2

[Alex E. (tecnologic)]

also clean,

MEMORY
{
  IROM1   (RX)    : ORIGIN = 0x08000000,  LENGTH = 0x00100000
  IRAM2   (RW)    : ORIGIN = 0x10000000,  LENGTH = 0x00010000
  IRAM1   (XRW)   : ORIGIN = 0x20000000,  LENGTH = 0x00020000
  ERAM1   (RW)    : ORIGIN = 0x60000000,  LENGTH = 0x00080000
}

...

.bss :
{
   _sbss = .; /* define a global symbol at bss start */
   _bss_start_ = _sbss;
   main.o(.bss)
   *(.bss)
   *(.bss*)
   *(COMMON)

   . = ALIGN(4);
   _ebss = .; /* define a global symbol at bss end */
   _bss_end_ = _ebss;
} >IRAM1

.bss2 :
{
   _sbss2 = .; /* define a global symbol at bss start */
   _bss2_start_ = _sbss2;
   foo.o(.bss)
   *(.bss2)
   *(.bss2*)
   *(COMMON)

   . = ALIGN(4);
   _ebss2 = .; /* define a global symbol at bss end */
   _bss2_end_ = _ebss2;
} >ERAM1

[Markus F. (mfro)]

@tecnologic: das wird so nicht funktionieren.

Das würde bedeuten, daß der Linker selbstständig das nächste Segment 
nutzen würde, wenn er feststellt, daß eins "voll" ist (was er leider 
nicht tut). Es bleibt nichts anderes übrig, als den Überlauf "händisch" 
zu steuern.

[Alex E. (tecnologic)]

@mfro

Jop, er muss jetzt aufpassen das die sections der files in die bss bzw. 
die bss2 section passen. Das ein riesen Array der Speicher aus dem 
internen wie externen Ram nehmen soll nicht geht, wurde ja bereits 
erklärt.

[Ch. Z. (crozeg)]

Schonmal vielen dank, ihr habt mir schon viel geholfen.

Momentan siehen meine bss-Sektionen wie folgt aus:
(Hoffe das stimmt soweit)

...

  .bss2 :
  {
    _sbss2 = .; /* define a global symbol at bss start */
    _bss2_start_ = _sbss2;

    obj/main.o(.bss .bss* COMMON)
    obj/hwe.o(.bss .bss* COMMON)

    /* FreeRTOS Objects */
    obj/port.o(.bss .bss* COMMON)
    obj/heap_4.o(.bss .bss* COMMON)
    obj/croutine.o(.bss .bss* COMMON)
    obj/event_groups.o(.bss .bss* COMMON)
    obj/list.o(.bss .bss* COMMON)
    obj/queue.o(.bss .bss* COMMON)
    obj/tasks.o(.bss .bss* COMMON)
    obj/timers.o(.bss .bss* COMMON)

    . = ALIGN(4);
    _ebss2 = .; /* define a global symbol at bss end */
    _bss2_end_ = _ebss2;
  } >IRAM1

  .bss :
  {
    _sbss = .; /* define a global symbol at bss start */
    _bss_start_ = _sbss;

    *(.bss)
    *(.bss*)
    *(COMMON)

    . = ALIGN(4);
    _ebss = .; /* define a global symbol at bss end */
    _bss_end_ = _ebss;
  } >ERAM1

...

Aber leider läuft meine Firmware nicht richtig.

Was genau scheinbar scheinen einige Dateien andere nicht mehr zu 
finden/erreichen?

Und was genau macht so ein AT befehl in LinkerScripts?
Zb im folgenden am ende meiner data-Sektion:

...
  .data :
  {
    . = ALIGN(4);
    _sdata = .;        /* create a global symbol at data start */
    *(.data)           /* .data sections */
    *(.data*)          /* .data* sections */

    . = ALIGN(4);
    _edata = .;        /* define a global symbol at data end */
  } >ERAM1 AT> IROM1
...

Viele Grüße
crozeg

[Markus F. (mfro)]

Ch. Ziegler schrieb:

> Und was genau macht so ein AT befehl in LinkerScripts?
> Zb im folgenden am ende meiner data-Sektion:
>

> ...
>   .data :
>   {
>     . = ALIGN(4);
>     _sdata = .;        /* create a global symbol at data start */
>     *(.data)           /* .data sections */
>     *(.data*)          /* .data* sections */
> 
>     . = ALIGN(4);
>     _edata = .;        /* define a global symbol at data end */
>   } >ERAM1 AT> IROM1
> ...

>
> Viele Grüße
> crozeg

das AT-Konstrukt packt die Objektdaten an die erste Adresse (ERAM1), 
reloziert den Code aber so, daß sie ab der zweiten Adresse (IROM1) 
referenziert werden.
Für dich bedeutet das, daß dein ausführbarer Code seine Daten ab der 
Startadresse IROM1 erwartet (wo sie aber nicht sind, falls Du sie nicht 
beim Programmstart umkopierst).

Das kann so m.E. nicht gut gehen.

[Markus F. (mfro)]

Ach, noch was:

wenn Du deinem Linker zusätzlich die Argumente

-Map mapfile.txt --cref

 mitgibst, kannst Du anhand des erzeugten Map-Files über die 
Crossreferenz nachvollziehen, wo dein Code/deine Daten gelandet sind.

[Alex E. (tecnologic)]

Außerdem brauchst du handling für dein .bss2 im startup code, gucke 
einfach mal was da für die .bss gemacht wird, üblicher weise nullen usw.

[Ch. Z. (crozeg)]

Hallo,

danke schonmal, seit dem nullen im startup code läufts schon besser. 
Zumindest die main.o.

...
  . = ALIGN(4);
  .bss_iram1 :
  {
    _sbss_iram1 = .; /* define a global symbol at bss start */
    _bss_iram1_start_ = _sbss_iram1;

    obj/main.o(.bss .bss* COMMON)
    obj/rm_tcp.o(.bss .bss* COMMON)

    /* FreeRTOS Objects */
    obj/port.o(.bss .bss* COMMON)
    obj/heap_4.o(.bss .bss* COMMON)
    obj/croutine.o(.bss .bss* COMMON)
    obj/event_groups.o(.bss .bss* COMMON)
    obj/list.o(.bss .bss* COMMON)
    obj/queue.o(.bss .bss* COMMON)
    obj/tasks.o(.bss .bss* COMMON)
    obj/timers.o(.bss .bss* COMMON)

    . = ALIGN(4);
    _ebss_iram1 = .; /* define a global symbol at bss end */
    _bss_iram1_end_ = _ebss_iram1;
  } >IRAM1


  . = ALIGN(4);
  .bss_eram1 :
  {
    /* This is used by the startup in order to initialize the .bss secion */
    _sbss_eram1 = .;         /* define a global symbol at bss start */
    __bss_eram1_start__ = _sbss_eram1;

    *(.bss)
    *(.bss*)
    *(COMMON)

    . = ALIGN(4);
    _ebss_eram1 = .;         /* define a global symbol at bss end */
    __bss_eram1_end__ = _ebss_eram1;
  } >ERAM1
...

Wenn ich die Zeile "obj/rm_tcp.o(.bss .bss* COMMON)" zur bss_iram1 
hinzufüge funktioniert nichts mehr. Der Compiler wirft folgendes:

Linking executable: bin\Debug\FreeRTOS4EGM.elf
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_n.a(lib_a-findfp.o): In function `_cleanup_r':
findfp.c:(.text._cleanup_r+0x0): multiple definition of `_cleanup_r'
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-findfp.o):findfp.c:(.text._cleanup_r+0x0): first defined here
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_n.a(lib_a-findfp.o): In function `__sfmoreglue':
findfp.c:(.text.__sfmoreglue+0x0): multiple definition of `__sfmoreglue'
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-findfp.o):findfp.c:(.text.__sfmoreglue+0x0): first defined here
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_n.a(lib_a-findfp.o): In function `_cleanup':
findfp.c:(.text._cleanup+0x0): multiple definition of `_cleanup'
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-findfp.o):findfp.c:(.text._cleanup+0x0): first defined here
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_n.a(lib_a-findfp.o): In function `__sinit':
findfp.c:(.text.__sinit+0x0): multiple definition of `__sinit'
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-findfp.o):findfp.c:(.text.__sinit+0x0): first defined here
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_n.a(lib_a-findfp.o): In function `__sfp':
findfp.c:(.text.__sfp+0x0): multiple definition of `__sfp'
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-findfp.o):findfp.c:(.text.__sfp+0x0): first defined here
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_n.a(lib_a-findfp.o): In function `__sfp_lock_acquire':
findfp.c:(.text.__sfp_lock_acquire+0x0): multiple definition of `__sfp_lock_acquire'
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-findfp.o):findfp.c:(.text.__sfp_lock_acquire+0x0): first defined here
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_n.a(lib_a-findfp.o): In function `__sfp_lock_release':
findfp.c:(.text.__sfp_lock_release+0x0): multiple definition of `__sfp_lock_release'
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-findfp.o):findfp.c:(.text.__sfp_lock_release+0x0): first defined here
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_n.a(lib_a-findfp.o): In function `__sinit_lock_acquire':
findfp.c:(.text.__sinit_lock_acquire+0x0): multiple definition of `__sinit_lock_acquire'
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-findfp.o):findfp.c:(.text.__sinit_lock_acquire+0x0): first defined here
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_n.a(lib_a-findfp.o): In function `__sinit_lock_release':
findfp.c:(.text.__sinit_lock_release+0x0): multiple definition of `__sinit_lock_release'
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-findfp.o):findfp.c:(.text.__sinit_lock_release+0x0): first defined here
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_n.a(lib_a-findfp.o): In function `__fp_lock_all':
findfp.c:(.text.__fp_lock_all+0x0): multiple definition of `__fp_lock_all'
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-findfp.o):findfp.c:(.text.__fp_lock_all+0x0): first defined here
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_n.a(lib_a-findfp.o): In function `__fp_unlock_all':
findfp.c:(.text.__fp_unlock_all+0x0): multiple definition of `__fp_unlock_all'
c:/program files (x86)/emblocks/1.45/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-findfp.o):findfp.c:(.text.__fp_unlock_all+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 5 seconds)
0 errors, 165 warnings (0 minutes, 5 seconds)

Siehe auch angehängtes Bild.

Im Bild sieht man auch das der Build mit 0 Errors abgeschlossen wurde, 
aber ich kann den Code nicht Debuggen/ins Target laden.


Viele Grüße
crozeg

[Markus F. (mfro)]

Das sieht mir jetzt so aus, als ob das mit dem Linkerscript nichts zu 
tun hätte - Du scheinst zu versuchen, die Newlib doppelt zuzulinken.

Laß' mal deinen Linker-Aufruf sehen.

[Ch. Z. (crozeg)]

Hallo,

ich mache keinen expliziten Linker-Aufruf, da ich ja mit der IDE 
Em::Blocks arbeite/baue.
In den Einstellungen habe ich folgende "extra command-line arguments" 
gefunden, vielleicht meinst du ja die:

-na -nd --batch-build-notify

Viele Grüße
crozeg

[Ch. Z. (crozeg)]

Hallo,

seit ich in den Em::Blocks Setting, bei Linker Settings, die "default 
libraries" angehakt (siehe angehägtes Bild). Jetz bauts und läuft (fürs 
erste).

War das richtig?

Viele Grüße
crozeg