snesfreaks.com
http://forum.snesfreaks.com/

Firmware selber bauen – Erfahrungs- und Anleitungsthread
http://forum.snesfreaks.com/viewtopic.php?f=160&t=15444
Seite 1 von 2

Autor:  Ramsis [ 25.03.2017 21:23 ]
Betreff des Beitrags:  Firmware selber bauen – Erfahrungs- und Anleitungsthread

Habe heute endlich mal die Zeit gefunden, mich eingehender mit dem Kompilieren der sd2snes-Firmware zu befassen. Ein Stück weit bin ich schon vorangekommen, wenn ich auch letztlich viel Zeit verbraten habe, die ich mir hätte sparen können. Aber lest selbst ...

Um die Firmware zu kompilieren, geht man laut der – angesichts der Komplexität des Vorgangs erschreckend knappen – Anleitung nach <source-dir>/src/README folgendermaßen vor:

Zitat:
1) program the PIC (cic/supercic/supercic-key.asm)
2) build and program the bootloader.
3) build the firmware and copy it to the memory card
4) build the snes menu and copy it to the memory card
5) build and compress the FPGA configuration and copy it to the memory card
6) insert memory card, power on; the bootloader should begin flashing the
firmware and boot it

Die Punkte 1 und 2 sind bei vorhandener Hardware natürlich überflüssig, und Nr. 6 sollte jeder selber hinkriegen, wir brauchen uns also erst einmal nur um 3 bis 5 zu kümmern. :) Mein OS ist Linux Mint 18.1 x64, ich kann also nur Erfahrungen damit wiedergeben. Punkt 4 ist darunter im Prinzip der einfachste, vorausgesetzt man verfügt bereits über einwandfreie snescom-Binaries, die man sich notfalls auch erst selber bauen muss.

Aber der Reihe nach. Punkt 3, das Bauen der Datei firmware.img, setzt eine installierte Toolchain voraus, die den ARM Cortex M3 unterstützt. Laut README muss man sich diese erst selber kompilieren. Mein GCC 5.4.0 verschluckte sich erst mal an den binutils, der Hinweis im README konnte da aber Abhilfe schaffen. Hierzu öffnet man das Makefile in einem Texteditor und ändert Zeile 117 wie folgt:

Vorher:
      --with-gnu-as --with-gnu-ld

Nachher:
      --with-gnu-as --with-gnu-ld --disable-werror

Als nächstes stolperte der Make-Prozess über eine bestimmte Abfolge von Anweisungen für die Dokumentation (!) von GCC. Da ich diese sowieso nicht brauche, versuchte ich zunächst, deren Erstellung komplett zu unterbinden. Dies erwies sich ohne größeres Studium der Quellen als zu aufwändig, also recherchierte ich ein wenig und wich letztlich auf ein temporäres Downgrade von Texinfo aus, was wiederum auf eine separate Kompilierung hinauslief, die aber – oh Wunder – tatsächlich auf Anhieb geklappt hat. (Die aktuelle Version 6.1.0 aus der Paketverwaltung habe ich übrigens nicht erst entfernen müssen.)

Aber ab jetzt hat doch endlich alles funktioniert, oder? ........ Weit gefehlt. :D

Nach ellenlangem Gerödel brach der Build-Prozess mit kryptischen Hinweisen auf Fehler in gtype-desc.c ab. Google war mal wieder mein Freund, und nachdem ich die GCC-Quellen entsprechend gepatcht hatte, war zumindest dieses Problem ebenfalls aus der Welt geschafft.

Aber jetzt ... MUSS doch die Drachin besiegt und der Prinz endlich gerettet sein, nicht? ...... NICHT? ............ Nö. :-P

Nach ewigem Vorkompilieren und vielen, vielen, fettgedruckten Warnings beschloss der Compiler den Totalstreik: Segmentation fault, please file a bug report und bla.

Das darf doch nicht wahr sein. Ist es aber. Ich wollte aufgeben. Hab ich aber nicht. Sondern ein paar ältere GCCs installiert und mit dem Befehl

sudo make CC=gcc-4.7

dem ganzen Spuk ein Ende bereitet. Der Build-Prozess lief anstandslos durch, und nach ca. 15 Minuten (Laptop mit i5-Dualcore, auf meiner Quadcore-WS wär's wohl schneller gegangen) hatte ich endlich meine Toolchain. Die lag unter /opt, also musste noch flugs die .bashrc mit dem Pfad zu den Binaries ergänzt und das System neu gestartet (bzw. mein Benutzer ab- und wieder angemeldet) werden, um endlich einen ersten Test der Firmware-Kompilierung fahren zu können.

Und der klappte auch. HAAALLELUJA! HAAAAAALLE....*scratch*

Zitat:
somebullshit not defined in line blablabla error wirwerdenallesterben und bla

So. Das war's dann. Da ich weiß, dass ikari keinen nicht-funktionierenden Code schreibt, war klar: Hier ist das Ende der Fahnenstange.

Oder ...?

*nochmal in den src ordner geguckt*
*komisches README.GCC-ARM-NONE_EABI-49 entdeckt*
*les les hm aha schnall oje neiiiiiin*

Die entsetzlichen menschlichen löwigen Dramen, die sich heute, hier und jetzt abspielten, werden wir an dieser Stelle nicht rekapitulieren. Stattdessen verweisen wir darauf, was nahelag – nämlich die Anwendungsverwaltung aufzurufen (schließlich sind wir hier nicht unter Ubuntu, also würde auch das PPA nicht funktionieren – O RLY, unter Mint funktioniert es nicht) und die drei Pakete namens Binutils-arm-none-eabi, Gcc-arm-none-eabi und Libnewlib-arm-none-eabi zu installieren.

Und nach einem erneuten Anlauf hab ich auf einmal wie durch Zauberhand eine frische firmware.img – ich fass es kaum. :o

Ob sie funktioniert ... ich weiß es nicht. Das ist mir im Moment auch egal, da ich die FPGA-Files eh erst morgen werde erstellen können. Aber, liebe Linux-Mint-User, diese Erkenntnis (s. o.) ist für euch. <3

Und ikari, deine READMEs gehören dringend überarbeitet ... echt jetzt :ugly: (Konstruktiver Vorschlag: Der Hinweis, PPAs oder gar die Paketquellen der verwendeten Distribution zu checken, bevor man sich auf die Kompilierodyssee begibt, gehört m. E. in die erste Zeile von Punkt b des READMEs!)

To be continued ...

Autor:  Ramsis [ 26.03.2017 20:42 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

Hab das ISE-Webpack jetzt (trotz aller eigentlich skandalös-inakzeptablen Nutzungsbedingungen) installiert – eine Benutzung ist allerdings trotzdem nicht erlaubt ahem ... vorgesehen, denn:

Bild

Habe den dritten Punkt von oben (Shell, Bash shell, Korn shell 64 bit environment) befolgt, aber gelauncht wurde exakt: nix. :x

Edit: Hab's eeendlich hinbekommen ... :starwars:

Der Bash-Befehl allein setzt anscheinend nur bestimmte Variablen, das Programm selber startet man dann mit dem Befehl


... woher man das wissen soll, ohne Google zu bemühen, ist mir zwar ein absolutes Rätsel, aber gut. :roll:

Dann startet der Project Navigator und haut einem gleich mal die fehlende Lizenz um die Ohren. Glücklicherweise kann man die sich kostenlos von Xilinx holen – natürlich nicht ohne Hängen und Würgen. :ugly: Klickt man nämlich im Lizenz-Manager auf "Get Free Vivado/ISE WebPack License", dann auf "Next" und im aufpoppenden Fenster auf "Connect Now", so passiert erst einmal ... gar nichts. :poeh:

Ein Blick ins Terminal, aus dem man das Programm gestartet hat, verrät, dass irgendeine bescheuerte GLIBCXX nicht gefunden wird, die angeblich von Firefox gebraucht wird. What. The. F**k??? :crazy:

Noch eine Google-Sitzung später und nach einigem Suchen und Herumprobieren stellt sich die Lösung folgendermaßen dar:

cd /opt/Xilinx/14.7/ISE_DS/common/lib/lin64
sudo mv libstdc++.so.6 libstdc++.so.6.orig
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 libstdc++.so.6

Danach ließ sich Firefox endlich aus dem Programm heraus launchen. Man darf sich bei Xilinx einloggen und landet direkt auf der richtigen Seite. (Evtl. könnte man auch einfach über http://www.xilinx.com gehen, um eine Lizenz zu ordern, das hab ich aber nicht ausprobiert.)

Und viel Rumgeklicke, einige (grenzdebile) fette rote Warnings und reichlich Lizenzierungs-Mimimi später hat man dann endlich eine kleine Datei namens Xilinx.lic, die man einfach im Lizenz-Manager laden muss.

Feddisch! Programm läuft!! Yay! :band:

Jetzt bin ich ja riesig gespannt, ob das mit dem Basteln der FPGA-Files klappt ...... :rock:

Autor:  ikari_01 [ 27.03.2017 12:22 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

Hm, ja, danke für den Erfahrungsbericht :nice:

Ja, das Kompilieren der Toolchain (weniger der Firmware selbst) ist ein Krampf. Nun ist es halt nicht so, dass ich das ständig neu versuche - ich setze einmal die Umgebung auf, freue mich dann, wenn sie funktioniert, und hoffe, dass ich es nicht so bald wieder machen muss. Außer halt bei einem umfangreicheren Reinstall oder OS-Upgrade.

Ich habe kein Desktop-Linux mehr und fände es jetzt IMO auch nicht zumutbar, die Paketnamen von jeder erdenklichen Distro rauszufinden (und dann am besten noch bei jeder den Build mit allen Eigenheiten zu testen) :ugly:

Die Sache mit dem kaputten TeX finde ich von den daran beteiligten Parteien in der Tat ziemlich lächerlich, vor allem, dass weder gcc noch LaTeX da mal einen Schritt macht, um das Problem aus der Welt zu schaffen.

Einige der von dir geschilderten Fehler kannte ich noch gar nicht. Nun könnte ich natürlich jeden Tag in 20 VMs die Toolchain bauen, mit jeder erdenklichen Host- und Target-Version von GCC, um jede Eventualität aufschreiben zu können... Aber dann kann ich die Entwicklung genausogut gleich komplett einstellen. Macht von der Außenwirkung eh fast keinen Unterschied. :pfeif:

Zitat:
Binutils-arm-none-eabi, Gcc-arm-none-eabi und Libnewlib-arm-none-eabi

Die sind alle auch Bestandteil der Toolchain, dann ist da evtl. bei der Installation was schiefgegangen ;)
Die README.GCC-ARM-NONE_EABI-49 von Borti ist gut, wenn man die Toolchain nicht installieren, sondern mit Distro-Bordmitteln arbeiten möchte. (IMO ein durchaus brauchbarer, wenn nicht sogar anzustrebender Weg). Streng genommen könnte das Mitliefern der CMSIS-1.3-Header unter src/include aber schon als Lizenzverletzung ausgelegt werden. Andererseits ist ARM inzwischen bei deutlich höheren Versionen (mit restriktiveren Lizenzen), von daher... Hahn, krähen usw.

Zitat:
Der Hinweis, PPAs oder gar die Paketquellen der verwendeten Distribution zu checken

PPAs, naja. Keine Lust da was Ubuntu-spezifisches reinzuschreiben ;) (Die sind für mich eh gestorben, als sie versucht haben, Unity als Default durchzudrücken oder bei Firefox extra per Canonical-Extension das "URL im Clipboard durch mittlere Maustaste öffnen"-Feature zu deaktivieren.)
Der Gedanke, die Toolchain aber komplett wegzulassen und nur mit Bordmitteln zu arbeiten, kam mir selber gerade zum ersten Mal. Finde ich aber durchaus nicht verkehrt. Für die Firmware braucht man im Endeffekt eh nur die Hälfte von der Toolchain - ziemlich genau die Pakete, die du nachinstalliert hast, plus die CMSIS-Header. Und insight schmiert eh ständig ab :ugly: Als ich mit der ARM-Entwicklung angefangen habe, kam mir das Ding aber halt recht gelegen.

Naja, und die Xilinx-Tools.... sind die Xilinx-Tools, nech. :ugly: Laufen jetzt unter Windows etwas geschmeidiger. Aber selbst da muss man unter Windows 10 64Bit noch irgendwelche DLLs ersetzen, damit es richtig funktioniert (sonst crash beim Filedialog).....

Autor:  borti4938 [ 27.03.2017 19:47 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

Achja, die Leidensgeschichte.

Mit der Toolchain habe ich auch schon Stunden verbracht, die zum Laufen zu bringen. Teilweise wusste ich dann auch nicht mehr weiter und habe einfach mal das OS neu installiert, Toolchain neu und dann lief es mit einmal :crazy:

Und irgendwann habe ich dann den Weg entdeckt, den ich in der README.GCC-ARM-NONE_EABI-49. War eher mal n Notlösung als die eigentlich laufende Toolchain meinte, "ich habe kein Bock mehr" und jetzt installiere ich das mal bei nem OS Upgrade / Reinstall immer so...

Ja, das mit der src/include :pfeif: :ugly: Dumdidum, Trallala :megaman:

ISE ist dann nochmal n anderes Thema. Gerade unter einer Linux-Distribution, die nicht gerade Red Har Enterprise Workstation 5 oder 6 bzw. SUSE Linux Enterprise 11 ist. Die werden offiziell nur supported und nimmt man n andere Linux-Distribution, kann es n Krampf werden.

Momentan kann ich die IP-Cores nicht generieren - zumindest nicht direkt, sondern nur über Umwege. Installiere ich dat neu, wäre sicherlich wieder was anderes nicht i.O. :pieks:
Das ist auch der Grund, warum bei mir das ISE Zeugs in ner VM mit Windows 7 läuft ;)
(Arbeite eh zumeist unter macOS, wo ISE eh nicht läuft)

Wenn mal was bei den verilog Files neu ist, lasse ich einmal ISE in der VM laufen und der Rest wird dann mit nem Shell-Script auf'm Host (Linux oder macOS) erledigt. Fertisch :D

Autor:  Ramsis [ 27.03.2017 22:26 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

ikari_01 hat geschrieben:
Die README.GCC-ARM-NONE_EABI-49 von Borti ist gut
(...)
PPAs, naja. Keine Lust da was Ubuntu-spezifisches reinzuschreiben ;)

Nirgendwo stand/steht geschrieben, dass README.GCC-ARM-NONE_EABI-49 (mit Erwähnung der PPAs) nicht von dir ist. Ich sach ja, deine Readmes gehören mal überarbeitet. :D

FPGA-Files erstellen klappt übrigens niemals nie nicht (6 Fehler bei sd2snes.xise, 5 Fehler bei sd2snes_obc1.xise, auf noch mehr Frust hab ich heut Abend keine Lust :-P ) ... Ist das überhaupt richtig, auf diesen komischen Play-Button (ebenso brandheißer wie kryptischer Tooltip: "Implement Top Module") zu klicken??

Autor:  borti4938 [ 27.03.2017 22:33 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

Du musst erst die IP-Cores generieren. Das sind die Dinger in der Hierarchie mit der Glühbirne (oder so ähnlich). Wenn du die anwählst, kannst du "Regenerate" darunter anwählen ;)

[Edit]
Du kannst auch einen IP-Core in der Hierarchie anklicken, dann darunter auf "Manage Cores" gehen und dann alle im neu geöffnetem Fenster auf "Regenerate all project IP (under current project settings)" gehen. Dann brauchst du nicht alle IPs einzeln durchgehen.
[Edit Ende]

Sobald du einmal durch bist, kannst du die Synthese des Hauptmoduls laufen lassen. Dann kriegst du dein main.bit, dass durch das rle-Tool (utils-Ordner im Projekt-Root) jagen kannst, um die fpga_base.bit etc zu bekommen.

Autor:  ikari_01 [ 28.03.2017 07:57 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

Naja, Bortis README kam halt über nen Mergerequest rein... und da stand nix weiter über den Autor drin :D Aber aus dem git geht's ja hervor: https://github.com/mrehkopf/sd2snes/com ... NE_EABI-49

Die Info mit dem "Regenerate IP Cores" ist wichtig, die fehlt auch tatsächlich noch. Dachte, das hätte ich dem README hinzugefügt, aber anscheinend habe ich es nur ca. 100x in irgendwelchen Foren geschrieben... hat man dann davon :ugly:

Autor:  ikari_01 [ 28.03.2017 09:08 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

Habe den Weg mit "vanilla" arm-none-eabi-Paketen gerade mal unter linux mint verprobt, da gibt es die in den normalen Repositories. Das ist ja geradezu lächerlich schnell und einfach, ich passe die Dokumentation mal so an, dass das der Standardweg wird.

Autor:  borti4938 [ 28.03.2017 10:33 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

gut zu wissen, dass eine Notlösung irgendwann dann doch zum "Standard" wird :ugly: Hatte das damals echt quick 'n' dirty zusammengeschrieben - deswegen auch keinen extra Hinweis zum Autor.

Ich habe mal meine kleinen Shell-Skripte angehängt, wenn Interesse besteht. Die FPGA-Dateien (main.bit) lasse ich damit nicht erstellen, da ich wie gesagt zumeist unter macOS arbeite und sogar auch unter Linux eher ISE in der VM laufen lasse.

Bei mir liegen die Skripte im misc Ordner; wenn man einen anderen Ordner verwendet, müsste man toRootDir ggf. anpassen.
Ein Skript 'sammelt' quasi nur die Dateien aus den anderen Ordnern (rle-tool muss kompiliert sein). Das andere Skript kompiliert die kleinen Hilfstools, lässt die Makefiles laufen und 'sammelt' dann ein.

Natürlich könnte man die noch erweitern, um bspw. die src/config durch Parametereingabe zum Skript anzupassen. Aber... bisher zu faul gewesen :pfeif:

Dateianhänge:
misc.zip [1004 Bytes]
33-mal heruntergeladen

Autor:  Ramsis [ 03.04.2017 19:59 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

borti4938 hat geschrieben:
Du musst erst die IP-Cores generieren. Das sind die Dinger in der Hierarchie mit der Glühbirne (oder so ähnlich). Wenn du die anwählst, kannst du "Regenerate" darunter anwählen ;)

[Edit]
Du kannst auch einen IP-Core in der Hierarchie anklicken, dann darunter auf "Manage Cores" gehen und dann alle im neu geöffnetem Fenster auf "Regenerate all project IP (under current project settings)" gehen. Dann brauchst du nicht alle IPs einzeln durchgehen.
[Edit Ende]

Danke, das war der entscheidende Punkt.

Dachte ich zumindest. :D

Habe also die Cores regeneriert (was einzeln nicht klappte dank kryptischer Fehlermeldung, sondern erst via coregen --> regenerate all cores und bla).

Dann hab ich den Build-Prozess gestartet mit einem Klick auf das Play-Symbol (oder so dachte ich, in Ermangelung vernünftiger ISE-Dokumentation) .. und wartete ... bis "success" im Terminal erschien.

Freu! :D

Also muss es ja jetzt eine main.bit geben. (erwart)

Ja. (main.bit such --> nix find ... aba Überzeugung und so)
Ja (Überzeugung obsiegt). (Dok les)
Doch (Überzeugung am Sprengen sein tut). (Dok nochmal les)
Muss. (Ahn dass nix bringen tut so alles)

To cut an idiot's story short, where's my main.bit?? :ugly:

(Edit: Hab das Ganze für Cx4 und OBC1 wiederholt, mit demselben Ergebnis, dass alles fehlerfrei durchläuft, aber keine *.bit-Datei erstellt wird. :| )

Autor:  borti4938 [ 03.04.2017 20:13 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

Ramsis hat geschrieben:
Habe also die Cores regeneriert (was einzeln nicht klappte dank kryptischer Fehlermeldung, sondern erst via coregen --> regenerate all cores und bla).

"Juhu" - ich bin nicht der einzige mit dem Fehler. Ich weiß aber, dass ich es mal auf Linux zum Laufen gebracht hatte. War wohl eher Zufall oder Kernel-abhängig oder oder :ugly:

Ramsis hat geschrieben:
Dann hab ich den Build-Prozess gestartet mit einem Klick auf das Play-Symbol (oder so dachte ich, in Ermangelung vernünftiger ISE-Dokumentation) .. und wartete ... bis "success" im Terminal erschien.

Freu! :D

Also muss es ja jetzt eine main.bit geben. (erwart)

[...]

To cut an idiot's story short, where's my main.bit?? :ugly:


Gerade mal geschaut und Aha-Effekt gehabt - das Play-Symbol lässt lediglich Synthese und Implementation (Translate, Map, Place&Route) laufen. Du musst in dem Prozess-Reiter auf "Generate Programming File" gehen - dann wird das main.bit erstellt. ;)

Dateianhang:
ise_genprogfile.PNG
ise_genprogfile.PNG [ 39.65 KiB | 2281-mal betrachtet ]

Autor:  Ramsis [ 04.04.2017 08:03 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

borti4938 hat geschrieben:
Gerade mal geschaut und Aha-Effekt gehabt - das Play-Symbol lässt lediglich Synthese und Implementation (Translate, Map, Place&Route) laufen. Du musst in dem Prozess-Reiter auf "Generate Programming File" gehen - dann wird das main.bit erstellt. ;)

Cool, danke! :nice: Damit hat es (mit sd2snes und sd2snes_obc1) tatsächlich geklappt. Purrfect! :D Nur sd2snes_cx4 macht jetzt noch Probleme, da bricht die Core-Regenerierung bei ca. 12% mit folgendem Fehler ab:

Zitat:
Failed to generate 'cx4_datrom'. Failed executing Tcl generator.

Ist aber erst mal zweitrangig, da ich jetzt zumindest sicher sein kann, dass mein Workflow richtig ist. :wink:

Autor:  borti4938 [ 04.04.2017 08:17 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

Meine Glaskugel sagt mir, dass diese Zeile in der cx4_datarom.xco Schuld daran ist.

Ersetze mal durch
CSET coe_file=./cx4rom.coe

Dann sollte das auch unter Linux funktionieren. :)

Autor:  ikari_01 [ 04.04.2017 14:10 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

Nicht übel :D Ich hatte allerdings auch von Linux zu Linux schon komische Fehler bei neu aufgesetzten Projekten... mal geht manuelles regenerate nicht, mal "regenerate all"... :roll:

Autor:  Ramsis [ 05.04.2017 10:33 ]
Betreff des Beitrags:  Re: Firmware selber bauen – Erfahrungs- und Anleitungsthread

borti4938 hat geschrieben:
Ersetze mal durch
CSET coe_file=./cx4rom.coe

Dann sollte das auch unter Linux funktionieren. :)

Nochmal danke, das war die Lösung. :applaus:

Habe mir die selbstgebauten Dateien jetzt mal auf die SD-Karte geladen, und so weit ich sehe, funktioniert alles normal. Frage: Wird die firmware.img bei jedem Start von der Karte geladen (wie auch die menu.bin und die FPGA-Dateien)? Habe nämlich irgendwo gelesen, dass diese Datei "geflasht" werde, wenn eine neue/alte Firmware auf die Karte kopiert wird. Da ich die Versionsnummer nicht geändert habe, kann ja beim Testen auch nix geflasht worden sein, oder? :?:

Seite 1 von 2 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/