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
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
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.
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.
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?
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.
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 =)
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.
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 =)
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.
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.
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 ;-))
1 | int main( void ) |
2 | {
|
3 | //printf("H");
|
4 | *(int*)0x80000000 = 'U'; |
5 | return 0; |
6 | } |
Größe bei Register schreiben, printf auskommentiert
1 | sparc-elf-size main |
2 | text data bss dec hex filename |
3 | 11568 2780 996 15344 3bf0 main |
Größe bei printf, Register schreiben auskommentiert
1 | sparc-elf-size main |
2 | text data bss dec hex filename |
3 | 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 ;-)
900ss D. schrieb: > gestern mein Getipsel gestern auf dem Smartphone ist ja von Tipfehlern > gespickt :-) Oh mann, ich muß einen Deutschkurs besuchen :-(
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
1 | sparc-elf-size main |
2 | text data bss dec hex filename |
3 | 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?
Vielen Dank für die Antworten =) Ich teste das morgen früh. Ich schreib dann nochmal detailiert obs funktioniert hat. Gruß Daniel
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 =)
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
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.
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.
Angehängte Dateien:
-
grmon.PNG
44 KB
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.