Im Moment beschätige ich mich gerade mit Conrollern auf PowerPC Basis (SPX560x, MPC560x). Allerdings habe ich das Problem, dass die aktuell unter Linux verfügbare Toolchain (macraigor GCC 4.7) kein VLE kann. Zumindest nicht der Compiler, der erzeugt mir immer nur "normalen" PowerPC-Code. Da der Assembler aber VLE kann, behelfe ich mir im Moment damit, dass der Compiler ein Assemblerlisting erzeugt, dieses durch ein von mir geschriebenes Tool in VLE-Code umgewandelt wird den ich dann durch den Assembler mittels -mvle jagen kann. Allerdings klappt das alles andere als problemlos. Codesourcery G++ Lite für PowerPC scheint es ja nicht mehr zu geben. Ich habe auch schon versucht, mit Hilfe von Patches aus dem Internet mir selbst einen passenden GCC zu compilieren, aber bisher ohne Erfolg. Gibt es vielleicht noch andere Möglichkeiten, auf die ich bisher nicht gekommen bin? (CW und COSMIC unter WINE sind für mich als dauerhafte Löungen nicht akzeptabel) Jörg
Hi Joerg, ich arbeite mit diesen Viehern auch manchmal. Ich muss Dich enttauschen. So weit ich weiss gibt es keinen freien Compiler der VLE-Befehle absetzen kann. Ich hoffe es wird mir jemand widersprechen ;-) Es gab mal Bewegung auf der GCC-Front, diese ist aber wieder etwas eingeschlafen. Bleibt nur die teure Alternative, wie zB: Windriver diab, oder Green Hills. -Foka
Erstmal danke an alle, die mir hier und per PM weitergeholfen haben. Inzwischen kann ich VLE-ASM ganz gut, so dass es für meine Zwecke reicht. Und das beherrscht ja auch der POWERPC-ELF-AS. Jörg
Hmm, zwar nicht Linux, und wenn 128 KB reichen-> Eval Version http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CW-MPC55XX_56XX&fpsp=1&tab=Design_Tools_Tab
Update: Nach einigen Versuchen, den SUBC-Compiler von i386 auf PowerPC-VLE "umzustricken", habe ich mich dann doch wieder an den GCC gewagt. Mit einem 4.8.0 und den im Internet verfügbaren Patches ist es mir dann gelungen. Wenn auch mit vielem Probieren bei den configure-Optionen und manuellem Ändern der Makefiles. Eine aktuelle Newlib konnte ich dann damit auch compilieren und eine erste lauffähige Test-Anwendung. Nur mit der libgcc will es nicht klappen, da nutze ich momentan eine eigene Lib, in die ich die wichtigsten Sachen (vor allen Dingen Soft-Float) reincompiliert habe. Bei Interesse kann ich das Binärverzeichnis (Linux i386) als Archiv auf meiner Webseite zum Download zur Verfügung stellen. Jörg
Hallo Jörg, das klingt total super. Wir sind seit einiger Zeit schon auf der Suche nach so einer Toolchain. Wir hatten zwar die alte von CodeSourcery ausgegraben, doch wir benötigen eine unter Linux lauffähige. Wäre super wenn du die irgendwie zur Verfügung stellen könntest. Oder Tipps geben wie wir die selbst erstellen können. Wir sind dann auch gerne bereit Zeit in die libgcc zu investieren. Frage hast du nur den gcc an laufen oder auch den g++? Freue mich über Rückmeldung Frank
Ja, es ist auch ein C++ Compiler dabei, wobei ich den nicht getestet habe (mir genügt C). Eine Newlib habe ich auch compiliert, aber bisher noch nicht benutzt. Inzwischen "bastle" ich an einer portablen Bibliothek und dem ganzen Drumherum (Compiler, Makefiles, Includes, Startup-Code, Linkerscripts, Programmer), die auf einer Anzahl von Mikrocontrollerplattformen annähernd identisches Verhalten zeigen soll. Eigentlich wollte ich alles im Rahmen meines Projektes "universelle Toolchain für Linux" veröffentlichen, aber da auch so Interesse daran besteht, werde ich die Compiler-Pakete schon vorher zum Download bereitstellen. Link folgt also in den nächsten Tagen.
Die aktuelle Toolchain ist unter http://www.jcwolfram.de/downloads/files/umdp/powerpc-vle-elf.tar.xz zu finden, bei mir liegt das Ganze unter /usr/local/toolchain/ Was ich bisher nicht geschafft habe, dass powerpc-elf-objdump mit der Option -Mvle auch VLE Instruktionen disassembliert. Jörg
Hallo Jörg, danke für den Link. Eine Frage nur zur Sicherheit unter welchem Linux benutzt du das? Wir würden das mal mit Code von uns testen von dem wir wissen wie er aussieht und das er mit GCC compiliert und läuft. Melde mich wieder wie erfolgreich ich damit bin. Frank
Ich habe auf meinem Laptop OpenSuse 13.1 (i386). Ein kleines Beispielprojekt habe ich angehängt. Das lässt zwei LEDs an PB0/PB1 im Wechsel blinken. Startup für einen 8MHz Quarz und Linkerscript ist mit dabei. Jörg
Hallo Jörg, so hat leider etwas gedauert, doch heut bin ich dazu gekommen es zu testen. Der Startupcode für unseren Controller liess sich übersetzen und er läuft auch. Was ich sehen kann ist das auch VLE Code dabei ist. Leider sind die C/C++ Anteile noch zu klein um es richtig beurteilen zu können, der VLE Code kommt zumeist aus den Assembler Files. doch fürs Erste ist das schon mal ein Erfolg finde ich. Ich musste etwas kämpfen um das alles unter Ubuntu 64Bit ans laufen zu bekommen doch irgendwann ging es. Der Compiler selbst läuft nun problemlos. Noch eine Frage, da wir auch auf der Suche nach einer aktuellen Standard C/C++ toolchain sind. Würdest du auch den gcc build oder den VLE Patch zur Verfügung stellen. Ich habe ihn leider nirgendwo gefunden, muss zugeben das mein bemühen auch nicht unbedingt zwingend war. Unser Ziel ist es einen C/C++ Compiler zu bekommen der auch die aktuellen Standards unterstützt. Deshalb wäre der gcc5 sehr interessant. (C++14) Frank
Hallo Frank, ich will nicht sagen, dass es ein aussichtsloses Unterfangen ist, aber dafür muss man sich wohl sehr gut mit den "Innereien" des GCC auskennen. Aber ich kann auf jeden Fall die Patches nochmal raussuchen. Einen "offiziellen" GCC habe ich damit nicht gepatcht bekommen und deswegen alle SVN-Snapshots um die Zeit der Veröffentlichung der Patches herum durchprobiert. Eine Portierung auf einen halbwegs aktuellen GCC 4.9.2 habe ich irgendwann nach mehreren Wochen aufgegeben. Zugegeben, das Beispiel war nicht sehr C-lastig, aber inzwischen ist meine Bibliothek schon recht angewachsen, u.a.: - Clock/PLL - Port-IO - UART - SPI - PWM - ADC - Interrupts (Timer) - printf mit Ausgabeumlenkung wobei ich da mein "eigenes Ding" verfolge, insbesondere Codekompatibilität zwischen verschiedenen µC-Familien bei gleichzeitiger Einschränkung auf grundlegende Funktionen. Jörg
Ich hab mal den Patch angehängt, den ich damals benutzt habe. Viellecht hilft Euch das weiter. Jörg
@Joerg I just tested the toolchain on linux mint17 x64 I had to install the 32-bit mpc/mpfr/gmp libs, (i have ia-32libs installed) sudo apt-get install libmpc3:i386 And i had to change a few things in the demo. I had to change (this dir isn't in the tc) #include "/usr/local/include/ppc/xpc560bc.h" to #include <xpc560bc.h> In order to find the .../ppc/powerpc-vle-elf/include/xpc560bc.h Then i had to replace all .R to match the .REG in the above includefile. I have included the modified main.c & makefile Thanx for the effort I suppose the patch is for : gcc version 4.8.0 20120906 (experimental) (GCC) /Bingo Ps: I could find several other xpc560bc.h on the net where they used .R and not .REG , but the one in the TC uses .REG
:
Bearbeitet durch User
@Karsten sorry for my late answer... I know, all include files from the internet use the .R / .B syntax. I have changed this because of my "internal comaptibility". Currently I'm working on a universal toolchain/library for different microcontroller families. Some use GCC ports, some the SDCC. The register definitions in the header files are very different (or not avaliable in case of Renesas 78K0R / RL78) and so I decided to create my own format for easier development. Joerg
I have seen, there is an issue with the "tlbwe" and "tlbre" menmonics in VLE mode. These commands are necessary for programming the MMU of some controllers. A first fix is to use
1 | .dc 0x7c000,0x07a4 |
for tlbwe. I`ll fix this in the binutils soon. Joerg
Hi together, thanks for the thread and the toolchain, Joerg. I downloaded it and tried it with the Chibios project (http://www.chibios.org). I got an ARM compiler and the demos for ARM are working. However when I used your toolchain for the demo of the SPC564 (actually I wanna use a freescale MPC564 with the same core: e200z4) [location in the zip file ChibiOS_3.0.3/demos/SPC5/RT-SPC564A-EVB], I get the following error:
1 | Compiling boot.s |
2 | powerpc-elf-gcc: error: unrecognized argument in option '-mcpu=e200zx' |
3 | powerpc-elf-gcc: note: valid arguments to '-mcpu=' are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e native power3 power4 power5 power5+ power6 power6x power7 powerpc powerpc64 rs64 titan |
4 | powerpc-elf-gcc: error: unrecognized command line option '-mnew-mnemonics' |
5 | make: *** [build/obj/boot.o] Error 1 |
I changed the Makefile section for the MCU to powerpc option because I read to try this but I recon the following error means that the e200z4 core has some special registers which are not part of the powerpc option:
1 | Compiling boot.s |
2 | Compiling vectors.s |
3 | Compiling crt0.s |
4 | Compiling ivor.s |
5 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s: Assembler messages: |
6 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:63: Error: unrecognized opcode: `e_stmvsrrw' |
7 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:64: Error: unrecognized opcode: `e_stmvsprw' |
8 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:65: Error: unrecognized opcode: `e_stmvgprw' |
9 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:94: Error: unrecognized opcode: `eaddi' |
10 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:139: Error: unrecognized opcode: `e_stmvsrrw' |
11 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:140: Error: unrecognized opcode: `e_stmvsprw' |
12 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:141: Error: unrecognized opcode: `e_stmvgprw' |
13 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:170: Error: unrecognized opcode: `eaddi' |
14 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:207: Error: unrecognized opcode: `eaddi' |
15 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:230: Error: unrecognized opcode: `e_lmvgprw' |
16 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:231: Error: unrecognized opcode: `e_lmvsprw' |
17 | ../../../os/rt/ports/e200/compilers/GCC/ivor.s:232: Error: unrecognized opcode: `e_lmvsrrw' |
18 | make: *** [build/obj/ivor.o] Error 1 |
Last but not least I tried to change the mcu option to e500mc because I read in some freescale docs that the core are the same and it brought up this error:
1 | Compiling boot.s |
2 | powerpc-elf-gcc: error: unrecognized command line option '-mnew-mnemonics' |
3 | make: *** [build/obj/boot.o] Error 1 |
I am a long time user of gcc for ARM but I never had anything to do with powerpc architecture or building your own gcc at all. I hope this info makes more sense for anyone of you guys than for me. And hopefully one can help me out or point me to a helpful direction. Looking forward to your answers and Thanks in advance, J
Nach langer Zeit gibt es ein Update, inzwischen kann mittels -mhard-float auch die FPU des e200Z4 etc. genutzt werden. http://www.jcwolfram.de/downloads/files/umdp/toolchain_001/powerpc-vle-elf_001.tar.xz Beispiele folgen demnächst. Jörg
Da es mich manchmal genervt hat, dass die Binutils nicht dazu zu bewegen waren, VLE-Code im Dump zu disassemblieren, habe ich mir einen kleinen Quick & Dirty Disassembler geschrieben. Bei der Soft-Float Variante scheint er alle vom GCC genutzten Codes zu erkennen, komplett ist er aber auf keinen Fall. Falls es jemand braucht:
1 | powerpc-elf-objdump -S -D -xdC xxxx.elf > main.dump |
2 | ./disass-vle.pl |
Erstellt eine Datei result.vleasm Die "komische" Endung aus dem Grund, damit mir der MC-Editor ordentliches Syntax-Highlighting macht.
Hi, ich habe gerade auf einer NXP Seite gesehen, dass es da die Sourcen für den GCC-4.9.2 mit VLE gibt. http://www.nxp.com/lgfiles/updates/S32DS/e200-gcc-1.1.3.tar.bz2 Viel Spaß beim ausprobieren. Gruß Olaf
Hat jemand den Code von NXP kompiliert bzw. es probiert? Mir ist das nicht gelungen, das Build-Script bricht beim GCC ab. Ich habe dann die Patches "von Hand" in die 4.9.2-Sources eingepflegt und nach ein paar Änderungen hat es dann funktioniert. Auf jeden Fall sind die Patches für die Binutils sinnvoll, weil jetzt objdump auch VLE disassembliert. Beim GCC muss ich noch sehen, Erste Vergleiche mit einfachen Programmen haben keinerlei Unterschiede im generierten Hexfile gezeigt. Jörg
Bitte 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.