www.mikrocontroller.net

Forum: Compiler & IDEs Testprogramme für Leon3


Autor: Daniel Schembri (pod)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe einen Leon3 Prozessor auf dem Spartan SP601 Board laufen.
Ich möchte nun einige Testprogramme darauf laufen lassen um 
sicherzugehen, dass auch alles funktioniert.
Da wollte ich einfache Programme schreiben, die ein paar Werte von 
Registern verschieben, Schleifen, Speichertests und ein Helloworld 
Programm.

Mein Problem ist, dass ich nur begrenzt Speicher zur Verfügung habe. Ich 
Verwende momentan nur den AHB RAM (ca 30kByte).

Meine C-Programme sind aber immer größer nach dem compilieren (ca. 
50kbyte).

Ich verwende den sparc-elf-4.4.2 gcc compiler


- Kennt jemand eine Möglichkeit, das möglichst klein zu bekommen?

- Kennt jemand einen Assembler und den passenden Compiler für Leon3? 
Habe    irgendwie nichts gefunden...

Gruß Daniel

: Verschoben durch Admin
Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Schembri schrieb:
> Kennt jemand eine Möglichkeit, das möglichst klein zu bekommen?

Mit folgenden Optionen werden nur die benötigten Programmteile gelinkt:

CC_OPTIONS=-Wl,--relax -Wl,--gc-sections
OBJCOPY_OPTIONS=--strip-debug --discard-locals

Ich weiß nicht, ob das in Deinem Makefile schon drin steht und ob es bei 
Dir hilft; probier es aus.

Duke

Autor: Daniel Schembri (pod)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es hat ein wenig gebracht.

hatte vorher bei text: 51216 bytes
                 data: 2776 bytes

jetzt sind es mit deinen optionen

                 text: 46928 bytes
                 data: 2756 bytes

So sieht meine Makefile nun aus:

CC=sparc-elf-gcc
CCOPT=-Wl,--relax -Wl,--gc-sections -O3 -msoft-float
OBJCOPY_OPTIONS=--strip-debug --discard-locals
all: main.c
  $(CC) $(CCOPT) -o helloworld main.c


Welche Optionen gibt es noch die Platz bringen könnten. Ich sollte so 
auf die 30k runterkommen.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. -Os statt -O3
2. -ffunction-sections -fdata-sections, sonst bringt die Linkeroption 
--gc-sections wenig
3. Wenn möglich auf Gleitkomma verzichten.

--strip-debug --discard-locals dürfte gar nichts bringen, weil das Daten 
sind die im Hex- oder Binärformat sowieso nicht mehr vorhanden sind.

Autor: Daniel Schembri (pod)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab jetzt ein einfaches Programm geschrieben, dass einfach nur "T"
ausgibt.

Ich hab am Programmcode selbst änderungen vorgenommen und hab es so auf 
15kByte runter bekommen. Es funktioniert trotzdem nicht. Bekomme immer 
die Fehlermeldung 0x02 unimp.
C werd ich erstmal nicht mehr verwenden.


Ich möchte jetzt probieren mit Assembler für den Leon ein kleines 
Testprogramm zu schreiben, um zu sehen ob er überhaupt Programme 
ausführt. Es soll ein einfacher Zähler von 0-10 sein.
Mit einfachen mov Befehlen und so.

Habt ihr da einen Beipsielcode für Leon3? Wie sehen da die Befehle aus? 
Muss ich da spezielle Bibiliotheken einbinden?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Schembri schrieb:

> C werd ich erstmal nicht mehr verwenden.

> Habt ihr da einen Beipsielcode für Leon3? Wie sehen da die Befehle aus?
> Muss ich da spezielle Bibiliotheken einbinden?

Wenn du schon so fragen musst:
Sieh lieber zu, dass du deine C-Toolchain in den Griff bekommst.

Autor: Daniel Schembri (pod)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem ist nicht unbedingt die Toolchain.

Es geht mir jetzt momentan darum, erstmal festzustellen ob überhaupt 
einfach assembler anweisungen auf dem Leon3 ausführbar sind,wenn ihm 
sogar eine printf anweisung zu komplex ist.
Wenn ein einfaches Verschieben von register z.B. nicht möglich ist, dann 
weiß ich das das problem wo anders liegen muss 
(Hardwarekonfiguration,etc.)

Karl heinz Buchegger schrieb:
> Wenn du schon so fragen musst:

Sry. Ich hab noch nicht solang damit gearbeitet. Assembler kann ich ja 
=)

Hab aber nichts konkretes gefunden was näher auf die 
Assemblerprogrammierung für Leon3 eingeht; mich interessiert was ich da 
beachten muss.

Vielleicht kennt sich ja jemand damit aus und kann mir ein paar tipps 
geben.

Fragen darf man doch =)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Schembri schrieb:
> Das Problem ist nicht unbedingt die Toolchain.

Wenn das hier

> hab jetzt ein einfaches Programm geschrieben, dass einfach nur "T"
> ausgibt.

auf einem µC zu einem 15k Programm wird, dann ist es ein Problem der 
Toolchain. Da werden irgendwelche Libraries mit dazugelinkt, die das 
Programm aufblähen. (Was weiß ich, vielleicht die Floating Point 
Libraries)


> Karl heinz Buchegger schrieb:
>> Wenn du schon so fragen musst:
>
> Sry. Ich hab noch nicht solang damit gearbeitet. Assembler kann ich ja
> =)

Echt?

> Wie sehen da die Befehle aus?
> Muss ich da spezielle Bibiliotheken einbinden?

Klingt mir nicht danach.

Autor: Daniel Schembri (pod)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> auf einem µC zu einem 15k Programm wird, dann ist es ein Problem der
> Toolchain. Da werden irgendwelche Libraries mit dazugelinkt, die das
> Programm aufblähen. (Was weiß ich, vielleicht die Floating Point
> Libraries)

Da bin ich auch schon draufgekommen. Deswegen sollte das Programm aber 
trotzdem funktionieren.

Karl heinz Buchegger schrieb:
>> Karl heinz Buchegger schrieb:
>>> Wenn du schon so fragen musst:
>>
>> Sry. Ich hab noch nicht solang damit gearbeitet. Assembler kann ich ja
>> =)
>
> Echt?
>
>> Wie sehen da die Befehle aus?
>> Muss ich da spezielle Bibiliotheken einbinden?
>
> Klingt mir nicht danach.

Ich meinte speziell für Leon3...
Das die Grundbefehle (mov, jmp...) die selben sind ist mir auch klar...
Vielleicht hab ich mich falsch ausgedrückt.

Ein Kollege hat mir nun ne Seite geschickt, wo einiges beschrieben wird 
was speziell für die Sparc-Architektur wichtig ist und worin die 
Unterschiede liegen.

Karl heinz Buchegger schrieb:
> Echt?
> Klingt mir nicht danach.

Mir wären sinnvolle Beiträge lieber, als solche Kommentare -.-
Das bringt mich und andere die vll ein ähnliches Problem haben auch 
nicht weiter!

Wenn meinst das meine Fragen so selbstverständlich sind, dann brauchst 
ja auch nicht antworten. Ich finds toll wenn man nach Hilfe fragt und 
ein Moderator einem zeigen muss wie wenig Ahnung man doch habe.

die vorherigen Beiträge haben mich weitergebracht und ich finds echt 
toll wie sich einige engagieren =)

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann dir nur abraten,  den Leon3 in Assembler zu programmieren.  Der 
Startupcode bis der Prozessor über richtig läuft,  hat es in sich. Sie 
mal in den Sourcecode der sparc-elf Toolchain (gibt es bei Gaisler.com).
Dein RAM muß(!) bei Adresse 0x40000000 beginnen. Damit arbeitet auch das 
Linkerscript (wenn du die Toolchain von Gaisler.com hast).
Wenn dir in C nur die Funktion Main hast und z. B.  nur eine Variable 
inkrementierst,  dann solltest du mit deinem Ram hinkommen. Ich vermute 
dein RAM liegt nicht bei 0x40000000 oder bei deinem Leon sind ein paar 
Bits verbogen.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja,  die Infos zu SPARC-V8 Assembler gibt es alle bei SUN als PDF. 
Aber SPARC-Assembler hat es in sich. Wenn du die Eigenarten der 
Arcjtektur nicht kennst dann hab ich einen guten gemeinten Rat: lass es, 
ehrlich.
15kB für ein 'T' mittels printf sind normal.
Schreiben direkt in das UART-Datenregister.  Der UART ist schon durch 
den GRMON initialisiert für 38400Baud.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochwas:
0x02 unimp meint Trap 2 unimplemented Opcode.

Autor: 900ss D. (900ss)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Moin,
gestern mein Getipsel gestern auf dem Smartphone ist ja von Tipfehlern 
gespickt :-)

Hab mal ein paar kleine Tests gemacht.
Toolchain war sparc-elf-4.4.2-mingw (ja Windows ;-))
int main( void )
{
  //printf("H");
  *(int*)0x80000000 = 'U';
  return 0;
}

Größe bei Register schreiben, printf auskommentiert
sparc-elf-size main  
   text     data      bss      dec      hex  filename
  11568     2780      996    15344     3bf0  main

Größe bei printf, Register schreiben auskommentiert
sparc-elf-size main  
   text     data      bss      dec      hex  filename
  15968     2900      996    19864     4d98  main

Compileroptionen waren: -Os -g3 -ffunction-sections -fdata-sections
Linkeroptionen: -Wl,--relax -Wl,--gc-sections

Der Code ist auch relativ groß, weil dort mindestens schon 2 Traphandler 
mit drin sind für "Window underflow" und "Window overflow". Die 
Traptabelle ist auch schon 4kb lang ab Adresse 0.

Im Anhang mal der List- und Mapfile von dem kleinen Programm, damit du 
einen Eindruck vom SPARC-Assembler bekommst :-)

Der LEON in Verbindung mit dem GRMON hat übrigens recht gute 
Debug-Möglichkeiten. Der Prozessor hat einen Tracebuffer, den kannst du 
mit dem GRMON auslesen.
"inst 100" listet dir die letzten 100 ausgeführten assembler 
Instruktionen.
"hist 100" listet dir die letzten 100 ausgeführten assembler 
Instruktionen inklusive der AHB-Zugriffe.

Damit könntest du evtl. feststellen, was ihn zum Absturz geführt hat.

Das Manual vom GRMON ist dein Freund, was die Befehle betrifft.

Wenn Du das Programm mit GRMON geladen hast, gebe mal "regs" ein.
Er gibt die aktuellen Registerinhalte aus. "pc" sollte 0x40000000
und "npc" sollte 0x40000004 sein.

Und wie ich schon schrieb, dein Ram muß bei 0x40000000 anfangen.
Sonst mußt du das Linkerscript anpassen.

Ansonsten gibt es noch eine LEON group bei Yahoo.
http://tech.groups.yahoo.com/group/leon_sparc/

So und nun bist du wieder dran ;-)

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
900ss D. schrieb:
> gestern mein Getipsel gestern auf dem Smartphone ist ja von Tipfehlern
> gespickt :-)

Oh mann, ich muß einen Deutschkurs besuchen :-(

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab gerade zufällig eine Beitrag in der YAHOO group gelesen. Du kannst 
dem Linker die Lib "small" mitgeben mit -lsmall. Dann wird der Code noch 
deutlich kleiner. Oder warst du der TO dort :-)

Hier der Beitrag:
http://tech.groups.yahoo.com/group/leon_sparc/message/18816

Größe bei Register schreiben, printf auskommentiert
sparc-elf-size main
   text    data     bss     dec     hex filename
   8032    1620     788   10440    28c8 main

Das sieht doch nochmal besser aus. Und das steht tatsächlich im BCC 
Manual, hatte ich auch verdrängt (nie gebraucht).

Bist du denn weiter gekommen?

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Antworten =)

Ich teste das morgen früh. Ich schreib dann nochmal detailiert obs 
funktioniert hat.

Gruß Daniel

Autor: Daniel Schembri (pod)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So nun hab ichs zum laufen bekommen :-)

Er führt auch das printf("H"); aus.
Das Programm hat dann ca. 20kB.

Sobald ich aber 2 Buchstaben ausgeben will, also printf("Ha"); dann 
wächst das Programm auf 50kB.
Mehrmals das Printf ausführen funktioniert aber. Also printf("H"); 
printf("a"); usw. dann gibt er mir das komplett aus.

Vll muss ich eine eigene printf Methode schreiben. Kann auch sein, dass 
er noch unnötiges Zeug mit einbindet.

Jetzt müsste ich genau wissen was der Compiler alles macht.
Dazu bräuchte ich die map file.


Mit welcher Compileroption hast du die map-File erzeugt?

Daniel =)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Schembri schrieb:
> So nun hab ichs zum laufen bekommen :-)
>
> Er führt auch das printf("H"); aus.
> Das Programm hat dann ca. 20kB.
>
> Sobald ich aber 2 Buchstaben ausgeben will, also printf("Ha"); dann
> wächst das Programm auf 50kB.

Ungewöhnlich

> Vll muss ich eine eigene printf Methode schreiben.

Das hat mit dem printf nichts zu tun, sondern dass Compiler/Linker hier 
offenbar wie wild Datenbereiche allokieren.

> Jetzt müsste ich genau wissen was der Compiler alles macht.
> Dazu bräuchte ich die map file.

Yep.
Dort würd ich auch erst mal anfangen

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Schembri schrieb:
> So nun hab ichs zum laufen bekommen :-)

Wäre für den nächsten schön, wenn du auch beschreibst, was denn das 
Problem war. Und mich würde es auch interessieren.

> Sobald ich aber 2 Buchstaben ausgeben will, also printf("Ha"); dann
> wächst das Programm auf 50kB.

Hmmm.... hab ich gerade getestet. Stimmt, ich komme von 15kB auf 40kB.
Hab aber gerade keine Zeit, das zu analysieren.

> Mit welcher Compileroption hast du die map-File erzeugt?
Das macht der Linker, aber die Optionen dafür werden dem Wrapper für 
Compiler und Linker übergeben, also dem sparc-elf-gcc mittels "-Wl".
Den Rest findest du im Linkermanual.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
900ss D. schrieb:
> Den Rest findest du im Linkermanual.

Bzw. im Compiler Manual, mußt aber wohl die GNU Docs nehmen, da das im 
BCC Manual wohl nicht drin steht.

Autor: Daniel Schembri (pod)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Tut mir leid, das habe ich ganz vergessen.

Der Speicherbereich des AHB ist standdardmässig bei A00.
Dementsprechend habe ich versucht das Programm mit den Befehlen 
-Tdata=A00...
und -Ttext=... manuell einzustellen. Das hat aber nicht funktioniert.
Den Speicherbereich des AHB-RAM habe ich dann auf 400 gelegt über die 
Xconfig (Das hatte vorher nicht richtig funktioniert,da es sich mit 
anderen Bereichen überschnitt. Als ich es heute nochmal probiert habe 
ging es plötzlich. Weiß nicht genau woran es genau gelegen hatte am 
Anfang ).

Der entscheidende Punkt war wohl den Ram auf die Addresse 0x40000000 zu
legen. Dann kann man die Addressierung einfach dem Compiler überlassen!

Das Programm läuft nicht wenn die Compileroption -Wl,--gc-sections 
angegeben wird ist mir aufgefallen.

Das hab ich verwendet:
CC=sparc-elf-gcc
#CCOPT=-g -Os -g3 -ffunction-sections -fdata-sections -Wl,--relax 
-Wl,--gc-sections -msoft-float -lsmall #-Tdata=A0000000 -Ttext=A0001DB0 
#--gc-sections -Os -Tdata=A0000000 -Ttext=A0000F00 -msoft-float
CCOPT=-g -O3 -msoft-float -lsmall
OBJCOPY_OPTIONS=--strip-debug --discard-locals
all: hello.c
  $(CC) $(CCOPT) $(OBJCOPY) -o helloworld hello.c


Hier noch die Sysinfo. Mit diesen Einstellungen läuft es. Aber die 
Einstellungen für den Leon sind noch nicht optimal:

Grmon> info sys
00.01:003   Gaisler Research  LEON3 SPARC V8 Processor (ver 0x0)
             ahb master 0
01.01:01c   Gaisler Research  AHB Debug JTAG TAP (ver 0x1)
             ahb master 1
02.01:01d   Gaisler Research  GR Ethernet MAC (ver 0x0)
             ahb master 2, irq 12
             apb: 80000f00 - 80001000
01.01:006   Gaisler Research  AHB/APB Bridge (ver 0x0)
             ahb: 80000000 - 80100000
02.01:004   Gaisler Research  LEON3 Debug Support Unit (ver 0x1)
             ahb: 90000000 - a0000000
             AHB trace 128 lines, 32-bit bus, stack pointer 0x40007ff0
             CPU#0 win 8, itrace 128, V8 mul/div, srmmu, lddel 1
                   icache 1 * 4 kbyte, 32 byte/line
                   dcache 1 * 2 kbyte, 16 byte/line
03.01:00e   Gaisler Research  AHB static ram (ver 0xf)
             ahb: 40000000 - 40100000
             32 kbyte AHB ram @ 0x40000000
05.04:00f   European Space Agency  LEON2 Memory Controller (ver 0x1)
             ahb: 00000000 - 20000000
             ahb: 20000000 - 40000000
             apb: 80000000 - 80000100
             8-bit prom @ 0x00000000
06.01:01b   Gaisler Research  AHB ROM (ver 0x0)
             ahb: 00000000 - 00100000
01.01:00c   Gaisler Research  Generic APB UART (ver 0x1)
             irq 2
             apb: 80000100 - 80000200
             baud rate 38461, DSU mode (FIFO debug)
02.01:00d   Gaisler Research  Multi-processor Interrupt Ctrl (ver 0x3)
             apb: 80000200 - 80000300
03.01:011   Gaisler Research  Modular Timer Unit (ver 0x0)
             irq 8
             apb: 80000300 - 80000400
             8-bit scaler, 2 * 32-bit timers, divisor 56
0b.01:01a   Gaisler Research  General purpose I/O port (ver 0x1)
             apb: 80000b00 - 80000c00


Die Printf-Anweisung verbraucht ca 8kB.Diese kommt im kleineren Prog gar 
nicht vor, statt dessen verwendet dies putchar. Hier ein Auszug aus der 
Map die ich erstellt habe. Wies Karl Heinz Buchegger gesagt hat werden 
warsch auch die Allokationen viel ausmachen:

 .text          0x4000127c     0x1f74 
c:/opt/sparc-elf-4.4.2-mingw/bin/../lib/gcc/sparc-elf/4.4.2/../../../../ 
sparc-elf/lib/soft\libc.a(vfprintf.o)
                0x40001418                _vfprintf_r
                0x400031c4                vfprintf

Eine weitere Idee, wäre vll die Bibliotheken z.B. in den Flash zu laden 
(als Module für ein Programm). Damit könnte man im Ram den benötigten 
Platz gering halten.

Ich hab hier noch ein paar Dateien angehängt. Einmal das Testprog. und 
ein Bild vom GRMON

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Schembri schrieb:
> Der entscheidende Punkt war wohl den Ram auf die Addresse 0x40000000 zu
> legen.

Ja, daher kam sicher der "0x02 unimp" Fehler. Ist typisch wenn der Leon 
in die Leere greift :-)

Gut dass es jetzt geht.

Ja du kannst sicher kleine Routinen ins Flash legen. Aber du mußt das 
auch brennen können. Der GRMON kann flashen (siehe GRMON Manual), wenn 
du ein Flash benutzt was er unterstützt. Aber trotzdem ist das nicht so 
einfach, du brauchst ja einen Loader. Du kannst natürlich auch die 
Programme direkt aus dem Flash laufen lassen. Das sollte dann im 
Adressraum 0x00000000-0x1FFFFFFF passieren, also dort müßte sich das 
Flash befinden und das Ram nutzt du nur für die Variablen und den Stack. 
Das sollte gehen.

Es gibt noch das Tool "sparc-elf-mkprom". Mit dem kannst du bootfähige 
PROM-Files erzeugen (BCC Manual). Ich bin mir nicht mehr sicher, ob sich 
der Loader selber erst ins Ram kopiert und dann die Anwendung nachlädt 
oder ob der Loader vollständig aus dem Flash läuft und nur die Anwedung 
dann ins Ram kopiert und startet. Aber damit kannst du eben genau eine 
Anwendung ins Flash bringen. Multiboot unterstützt das Tool nicht ;-)

Bau dir da mehr RAM ran. 30kB ist quasi nichts für diesen Prozessor.

Evtl. kannst du zum Vergrößern des Rams den Data und Instruction cache 
verkleinern. Dann hast den Platz über für dein AHB-Ram denke ich.
Aber ich bin kein FPGA Experte. Ich weiß nur, dass ein Kollege, der mir 
einen Leon gehäkelt hat, den Cache verkleinert hat zugunsten anderer 
Dinge.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.