Crosscompiling für QNAP (Arm)
- af0815
- Lazarusforum e. V.
- Beiträge: 6209
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Crosscompiling für QNAP (Arm)
Ich habe QNAP TS212 zu Hause und würde darauf gerne ein paar für die Kommandozeile geschriebene Tools laufen lassen bzw dafür anpassen. Die 212 hat meines Wissens den gleichen Arm Prozesor wie die 259er.
Maschinell hat meines Wissens schon Erfahrung damit, vielleicht auch andere. Kann mir wer auf die Sprünge helfen wie ich am besten eine funktionierende Crosscompiling Umgebung für diesen speziellen Zweck erstelle und welcher Toolchain passt.
Danke Andi
Maschinell hat meines Wissens schon Erfahrung damit, vielleicht auch andere. Kann mir wer auf die Sprünge helfen wie ich am besten eine funktionierende Crosscompiling Umgebung für diesen speziellen Zweck erstelle und welcher Toolchain passt.
Danke Andi
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: Crosscompiling für QNAP (Arm)
Ich habe bisher noch kein Cross-Compilen und kein Cross-Debuggen versucht.
Ich habe das Programm mit zunächst Lazarus auf PC-Linux erstellt und getestet.
Dafür habe ich eine ganze Anzahl "aktive" Units / Objekte geschrieben, die die eigentliche Arbeit tun. Eine davon ist die "Primäre", die beim Create alle anderen instanziiert und Events (z.B. zum Debuggen) bereitstellt und ihrerseits solche Events in den anderen Units anmeldet.
Diese Units / Objekte haben keinerlei direktes Benutzer-Interface und benutzen keine TTimer und keine Sachen wie "TThread.Synchronize" oder "QueueAsyncCall()" oder "SendMessage()", da die ja bei Lazarus ohne GUI nicht funktionieren.
Zum Testen unter Lazarus habe ich eine "GUI-Unit" geschrieben, die diverse Knöpfe sowie TTimer als Stimuli und TMemos und andere Elemente für Status-Ausgaben hat.
Diese GUI Unit kreiert eine Instanz des primären Objekts und verbindet die Events mit Ausgaben auf Memos etc. und macht entsprechende Calls und Property-Zuweisungen bei ihren TTimer-Events und Button-Clicks.
Dadurch kann man die Worker-Units in normaler Lazarus-Arbeitsweise als Larazus "GUI Application" Projekt testen.
Dann habe ich - immer noch am PC - mit Lazarus ein Kommandozeilen-Projekt erstellt, das dieselbe Worker Units verwendet und das primäre Objekt instanziiert.
Ausgaben können hier (statt auf Memos) mit writeln() gemacht werden. Es ist sinnvoll, die writeln()-Aktionen per Kommandozeilen-Parameter in verschiedenen Stufen abzuschalten, wenn das Programm später als Daemon laufen soll.
Statt TTimer kann man eine Hauptschleife mit "sleep()" schreiben, die die Aktionen in den Worker-Units zeitgesteuert aufruft.
(Meine Programm schaut jede Minute nach, ob man ihm eine Mail geschickt hat (POP3 mit Synapse) und wenn ja veranstaltet es bestimmte Aktionen entsprechend dem Mail-Inhalt.)
Das kann man dann wieder am PC testen (auch im Dauer-Betrieb als Daemon, indem man es z.B. in die /etc/initab einträgt).
Dann habe ich mir von der Free-Pascal Seite den aktuellen fpc 2.6.0 (binäre ARM-Distriubution incl. RTL und FCL) geladen und mit dem darin befindlichen .sh- Script auf dem QNAP unter /opt/fpc installiert (vorher hatte ich bereits Optware installiert. Ob das für fpc nötig ist, weiß ich nicht.) Man muss dann noch symlinks in /usr/bin und /usr/lib machen. (Die sind nach einem Neustart des QNAP weg. Wenn man das vermeiden will, muss man in die Startup-Routinen eingreifen. Das habe ich noch nicht versucht.)
Mit einem richtig eingestellten fpc.cfg und/oder einer passenden Kommandozeile übersetzt fpc dann mein Programm (inklusive Synapse). Und es läuft auch (bis auf einen sporadischen - vermutlich - Synapse-Bug in deren HTTP-Client).
Ich würde gerne irgendwie auf dem QNAP debuggen, das habe ich aber noch nicht versucht.
Möglichkeiten wären:
- ein SSH-Remote X (z.B. VNC) und ein Widget Set installieren und Lazarus auf dem QNAP laufen lassen (auf RPi soll das tatsächlich funktionieren)
- Lazarus für cross-Compile und Remote-Debugging via SSH einrichten (muss gehen, Remote-Debugging hat aber anscheinend noch nie jemand versucht)
- Kommandozeilen - GDB auf dem QNAP verwenden (Keine Ahnung wie die GDB-Kommanndozeile mit fpc-Code klarkommt...)
Gruß,
-Michael
Ich habe das Programm mit zunächst Lazarus auf PC-Linux erstellt und getestet.
Dafür habe ich eine ganze Anzahl "aktive" Units / Objekte geschrieben, die die eigentliche Arbeit tun. Eine davon ist die "Primäre", die beim Create alle anderen instanziiert und Events (z.B. zum Debuggen) bereitstellt und ihrerseits solche Events in den anderen Units anmeldet.
Diese Units / Objekte haben keinerlei direktes Benutzer-Interface und benutzen keine TTimer und keine Sachen wie "TThread.Synchronize" oder "QueueAsyncCall()" oder "SendMessage()", da die ja bei Lazarus ohne GUI nicht funktionieren.
Zum Testen unter Lazarus habe ich eine "GUI-Unit" geschrieben, die diverse Knöpfe sowie TTimer als Stimuli und TMemos und andere Elemente für Status-Ausgaben hat.
Diese GUI Unit kreiert eine Instanz des primären Objekts und verbindet die Events mit Ausgaben auf Memos etc. und macht entsprechende Calls und Property-Zuweisungen bei ihren TTimer-Events und Button-Clicks.
Dadurch kann man die Worker-Units in normaler Lazarus-Arbeitsweise als Larazus "GUI Application" Projekt testen.
Dann habe ich - immer noch am PC - mit Lazarus ein Kommandozeilen-Projekt erstellt, das dieselbe Worker Units verwendet und das primäre Objekt instanziiert.
Ausgaben können hier (statt auf Memos) mit writeln() gemacht werden. Es ist sinnvoll, die writeln()-Aktionen per Kommandozeilen-Parameter in verschiedenen Stufen abzuschalten, wenn das Programm später als Daemon laufen soll.
Statt TTimer kann man eine Hauptschleife mit "sleep()" schreiben, die die Aktionen in den Worker-Units zeitgesteuert aufruft.
(Meine Programm schaut jede Minute nach, ob man ihm eine Mail geschickt hat (POP3 mit Synapse) und wenn ja veranstaltet es bestimmte Aktionen entsprechend dem Mail-Inhalt.)
Das kann man dann wieder am PC testen (auch im Dauer-Betrieb als Daemon, indem man es z.B. in die /etc/initab einträgt).
Dann habe ich mir von der Free-Pascal Seite den aktuellen fpc 2.6.0 (binäre ARM-Distriubution incl. RTL und FCL) geladen und mit dem darin befindlichen .sh- Script auf dem QNAP unter /opt/fpc installiert (vorher hatte ich bereits Optware installiert. Ob das für fpc nötig ist, weiß ich nicht.) Man muss dann noch symlinks in /usr/bin und /usr/lib machen. (Die sind nach einem Neustart des QNAP weg. Wenn man das vermeiden will, muss man in die Startup-Routinen eingreifen. Das habe ich noch nicht versucht.)
Mit einem richtig eingestellten fpc.cfg und/oder einer passenden Kommandozeile übersetzt fpc dann mein Programm (inklusive Synapse). Und es läuft auch (bis auf einen sporadischen - vermutlich - Synapse-Bug in deren HTTP-Client).
Ich würde gerne irgendwie auf dem QNAP debuggen, das habe ich aber noch nicht versucht.
Möglichkeiten wären:
- ein SSH-Remote X (z.B. VNC) und ein Widget Set installieren und Lazarus auf dem QNAP laufen lassen (auf RPi soll das tatsächlich funktionieren)
- Lazarus für cross-Compile und Remote-Debugging via SSH einrichten (muss gehen, Remote-Debugging hat aber anscheinend noch nie jemand versucht)
- Kommandozeilen - GDB auf dem QNAP verwenden (Keine Ahnung wie die GDB-Kommanndozeile mit fpc-Code klarkommt...)
Gruß,
-Michael
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: Crosscompiling für QNAP (Arm)
P.S.:
Ich bin ziemlich sicher, dass Optware installiert werden muss, damit fpc funktionieren kann.
Zu Optware:
Das orginale QNAP Linux ist "embedded" in dem Sinne, dass es keine Festplatte verwendet. Die eingebauten Platten sind nur für die User-Daten.
Das Linux bootet aus einem Flash-Speicher und richtet sich dabei ein Root-Filesystem in einem RAM-Disk-Device ein. Deshalb kann man nicht so leicht zusätzliche Software installieren. (Nach dem Booten ist alles wieder weg.)
Optware ist als "QPKG"-Paket verfügbar (lässt sich also mit den eingebauten QNAP-Mitteln leicht installieren). Es richtet auf der Platte ein Directory ein, das durch ein Symlink "/opt" erreicht werden kann. Unter /opt sind dann weitere Verzeichnisse wie "bin" und "lib", in die neue Software permanent (bis zum Austausch der Platte) relativ normal installiert werden kann.
Die Optware Installation verändert die Boot-Scripts, so dass die nötigen Symlinks und Environment-Variablen gesetzt werden. Es werden auch scripts unter /opt aufgerufen. So dass später installierte Software nicht das Flash verändern muss um eigene Voreinstellungen zu machen.
Optware kommt mit einer eigenen Paketverewaltung "ipkg" (funktioniert ähnlich wie Debian "apt-get"). Über ipkg sind diverse Software-Pakete leicht auf dem QNAP installierbar (nicht aber fpc und Lazarus) .
Wenn ich das richtig sehe, installiert Optware diverse libraries (*.so's) die von fpc benötigt werden.
-Michael
Ich bin ziemlich sicher, dass Optware installiert werden muss, damit fpc funktionieren kann.
Zu Optware:
Das orginale QNAP Linux ist "embedded" in dem Sinne, dass es keine Festplatte verwendet. Die eingebauten Platten sind nur für die User-Daten.
Das Linux bootet aus einem Flash-Speicher und richtet sich dabei ein Root-Filesystem in einem RAM-Disk-Device ein. Deshalb kann man nicht so leicht zusätzliche Software installieren. (Nach dem Booten ist alles wieder weg.)
Optware ist als "QPKG"-Paket verfügbar (lässt sich also mit den eingebauten QNAP-Mitteln leicht installieren). Es richtet auf der Platte ein Directory ein, das durch ein Symlink "/opt" erreicht werden kann. Unter /opt sind dann weitere Verzeichnisse wie "bin" und "lib", in die neue Software permanent (bis zum Austausch der Platte) relativ normal installiert werden kann.
Die Optware Installation verändert die Boot-Scripts, so dass die nötigen Symlinks und Environment-Variablen gesetzt werden. Es werden auch scripts unter /opt aufgerufen. So dass später installierte Software nicht das Flash verändern muss um eigene Voreinstellungen zu machen.
Optware kommt mit einer eigenen Paketverewaltung "ipkg" (funktioniert ähnlich wie Debian "apt-get"). Über ipkg sind diverse Software-Pakete leicht auf dem QNAP installierbar (nicht aber fpc und Lazarus) .
Wenn ich das richtig sehe, installiert Optware diverse libraries (*.so's) die von fpc benötigt werden.
-Michael
- af0815
- Lazarusforum e. V.
- Beiträge: 6209
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Re: Crosscompiling für QNAP (Arm)
Danke für die Infos.
Das mit dem Autostart auf der QNAP ist gar nicht so kompliziert. Am einfachsten ist es über einen Eintrag in der Steuerdatei von Optware. Hat den riesigen Vorteil das es erst startet wenn das System wirklich up ist und auch alle Treiber vorhanden sind. Somit kann man auch zb das Programm aus einem Share starten. Ich habe mich in die QNAP für solche Sachen schon eingearbeitet.
Wo man aufpassen muss ist mit den Bibliotheken und Anpassungen von QNAP.
Das mit dem Autostart auf der QNAP ist gar nicht so kompliziert. Am einfachsten ist es über einen Eintrag in der Steuerdatei von Optware. Hat den riesigen Vorteil das es erst startet wenn das System wirklich up ist und auch alle Treiber vorhanden sind. Somit kann man auch zb das Programm aus einem Share starten. Ich habe mich in die QNAP für solche Sachen schon eingearbeitet.
Wo man aufpassen muss ist mit den Bibliotheken und Anpassungen von QNAP.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: Crosscompiling für QNAP (Arm)
af0815 hat geschrieben:Das mit dem Autostart auf der QNAP ist gar nicht so kompliziert. Am einfachsten ist es über einen Eintrag in der Steuerdatei von Optware.
Klar. Sobald man Optware installiert hat, braucht man nicht mehr im Flash rumzubasteln. Aber erst dann .
Dann darf man aber die Platten nicht mehr einfach ausbauen und durch leere ersetzen.
-Michael
- af0815
- Lazarusforum e. V.
- Beiträge: 6209
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Re: Crosscompiling für QNAP (Arm)
Was mich am meisten interessiert ist, Änderungen am Dateisystem mitgeteilt zu bekommen und darauf zu reagieren.
Hast du ein Beispiel für mich, wie du es jetzt zum Testen löst.
Hast du ein Beispiel für mich, wie du es jetzt zum Testen löst.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: Crosscompiling für QNAP (Arm)
Ein Beispiel nicht gerade, aber ein paar Tips.
- Mitteilungen:
per Mail mittels Synapse habe ich das bereits problemlos laufen.
- Änderungen im Dateisystem überwachen:
Dafür gibt es in Linux entsprechende System-Aufrufe. In C habe ich das schonmal getestet. Man macht damit eine Zuweisung der Überwachung eines Directories auf eine virtuelle Datei (Stream). Auf die kann man einen blocking oder nonblocking Read oder einen select oder einen epoll machen. Dann erhält das Programm eine Mitteilung, wenn sich in diesem Directory irgendetwas ändert und kann dann nachschauen, was los ist.
- Programm installieren:
Ich habe für solche Sachen auf meinem PC-Server sowohl die angesprochene simple Methode mit initab verwendet als auch die modernere mittels rc-Script. Aud meinem Linux-Server hatte ich dann sogar die Möglichkeit eingebaut das Programm mit "rcmyprogram" ganz "Suse-offiziell" zu steuern (""rcmyprogram start", ""rcmyprogram stop", "rcmyprogram status"). So etwas ähnliches gibt es vermutlich mit optware auch.
-Michael
- Mitteilungen:
per Mail mittels Synapse habe ich das bereits problemlos laufen.
- Änderungen im Dateisystem überwachen:
Dafür gibt es in Linux entsprechende System-Aufrufe. In C habe ich das schonmal getestet. Man macht damit eine Zuweisung der Überwachung eines Directories auf eine virtuelle Datei (Stream). Auf die kann man einen blocking oder nonblocking Read oder einen select oder einen epoll machen. Dann erhält das Programm eine Mitteilung, wenn sich in diesem Directory irgendetwas ändert und kann dann nachschauen, was los ist.
- Programm installieren:
Ich habe für solche Sachen auf meinem PC-Server sowohl die angesprochene simple Methode mit initab verwendet als auch die modernere mittels rc-Script. Aud meinem Linux-Server hatte ich dann sogar die Möglichkeit eingebaut das Programm mit "rcmyprogram" ganz "Suse-offiziell" zu steuern (""rcmyprogram start", ""rcmyprogram stop", "rcmyprogram status"). So etwas ähnliches gibt es vermutlich mit optware auch.
-Michael
- af0815
- Lazarusforum e. V.
- Beiträge: 6209
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Re: Crosscompiling für QNAP (Arm)
Nachdem du einen fpc auf der QNAP laufen hast, werd ich mal sehen ob ich nicht einen Toolchain fürs chrosscompiling finde, den man verwenden kann. Crosscompiling und crossdebuggen wäre schon schön.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: Crosscompiling für QNAP (Arm)
af0815 hat geschrieben: Crosscompiling und crossdebuggen wäre schon schön.
+1
Ich bin ein großer Fan davon. Ich mache das mit C und embedded Controllern (für die es gar keinen nativen Compiler gibt) den ganzen Tag.
Sollte eigentlich alles gehen:
- FPC kann man mit der Cross Option mit make aus den normalen svn Sourcen übersetzen.
- Lazarus bleibt wie es ist.
- der gdb (remote-) "stub" für das Zielsystem sollte mit-installiert worden sein, wenn man gdb installiert.
- Lazarus benutzt (anders als "fp", das mit dem fpc kommt) den normalen Kommandozeilen-gdb.
- der gdb auf dem PC kann mit einer entsprechenden Kommandozeilen-Option (die die TCP/IP-Adresse enthält) für remote-debgging konfiguriert werden und verbindet sich dann mit dem "stub". (Habe ich mit Eclipse vor einigen Jahren schonmal gemacht).
- Nun muss Lazarus so konfiguriert werden, dass es den gdb mit entsprechenden Optionen aufruft. Das soll theoretisch möglich sein.
Hat nur anscheinend noch nie jemand gemacht.
Vielleicht sollte man zur Übung zunächst 'mal remote-Debugging mit Lazarus zwischen zwei Linux PCs probieren....
Gruß,
-Michael
- af0815
- Lazarusforum e. V.
- Beiträge: 6209
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Re: Crosscompiling für QNAP (Arm)
Bin gerade dabei mir eine neue VM mit Debian Wheezy aufzubauen, nur für das Crosscompiling.
Den Toolchain habe ich, so nehme ich an, gefunden. Jetzt mal ein sauberes System hochziehen und einrichten.
Was hast du für eine Version auf der QNAP-NAS
Ist das etwa gleich mit meiner ?
Den Toolchain habe ich, so nehme ich an, gefunden. Jetzt mal ein sauberes System hochziehen und einrichten.
Was hast du für eine Version auf der QNAP-NAS
Code: Alles auswählen
[~] # cat /proc/version
Linux version 2.6.33.2 (root@VMBuildEnv001) (gcc version 4.2.1) #1 Wed Dec 5 19:17:53 CST 2012
[~] # strings /lib/libc* | grep GCC | uniq
GCC: (GNU) 4.2.1
[~] # strings /lib/libc.so.6 |grep 'GNU C'
GNU C Library stable release version 2.5, by Roland McGrath et al.
Compiled by GNU CC version 4.2.1.
[~] #
Ist das etwa gleich mit meiner ?
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: Crosscompiling für QNAP (Arm)
Sieht ziemlich gleich aus:
Code: Alles auswählen
[~] # cat /proc/version
Linux version 2.6.33.2 (root@VMBuildEnv001) (gcc version 4.2.1) #1 Wed Dec 5 11:46:33 CST 2012
[~] # strings /lib/libc* | grep GCC | uniq
GCC: (GNU) 4.2.1
[~] # strings /lib/libc.so.6 |grep 'GNU C'
GNU C Library stable release version 2.5, by Roland McGrath et al.
Compiled by GNU CC version 4.2.1.
- af0815
- Lazarusforum e. V.
- Beiträge: 6209
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Re: Crosscompiling für QNAP (Arm)
Infos zum Toolchain hier ein Thread im Deutscvhen QNAP Club.
Für die TS 212 und TS-259PII sollte es diese Datei sein arm-2007q3-51-arm-none-linux-gnueabi.bin. Auf Codesourcery hat es Änderungen gegeben, seither ist das ganze nur mehr direkt per Link erreichbar.
Baue mir mal einen FPC aus den SVN und schau dann weiter.
Für die TS 212 und TS-259PII sollte es diese Datei sein arm-2007q3-51-arm-none-linux-gnueabi.bin. Auf Codesourcery hat es Änderungen gegeben, seither ist das ganze nur mehr direkt per Link erreichbar.
Baue mir mal einen FPC aus den SVN und schau dann weiter.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
- af0815
- Lazarusforum e. V.
- Beiträge: 6209
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Re: Crosscompiling für QNAP (Arm)
Noch ein paar Infos zu dem verwendeten EABI etc. auf den QNAP NAS TS212
gibt u.a. folgende Infos Preis
Code: Alles auswählen
readelf -a /bin/busybox
gibt u.a. folgende Infos Preis
Code: Alles auswählen
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0xc578
Start of program headers: 52 (bytes into file)
Start of section headers: 451016 (bytes into file)
Flags: 0x5000002, has entry point, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 27
Section header string table index: 26
.....
Notes at offset 0x00000148 with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM10TDMI"
Tag_CPU_arch: v5TE
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align8_needed: Yes
Tag_ABI_align8_preserved: Yes, except leaf SP
Tag_ABI_enum_size: int
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: Crosscompiling für QNAP (Arm)
Falls Du das wissen möchtest, dasselbe aus meinem QNAP 219 II P scheint identisch zu sein, obwohl das 219, soweit ich weiß, eine andere CPU hat:
Code: Alles auswählen
# cat /proc/cpuinfo
Processor name : Feroceon 88F6282 rev 1 (v5l) @ 2 GHz
BogoMIPS : 1985.74
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1
Hardware : Feroceon-KW ARM
Revision : 0000
Serial : 0000000000000000
Code: Alles auswählen
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0xc578
Start of program headers: 52 (bytes into file)
Start of section headers: 451016 (bytes into file)
Flags: 0x5000002, has entry point, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 27
Section header string table index: 26
...
Notes at offset 0x00000148 with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM10TDMI"
Tag_CPU_arch: v5TE
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align8_needed: Yes
Tag_ABI_align8_preserved: Yes, except leaf SP
Tag_ABI_enum_size: int
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: Crosscompiling für QNAP (Arm)
P.S.:
Das "Features: swp " und "(v5l)" kann bei fpc ein Problem sein.
Wenn ich das richtig durchschaue:
Die ARM Architektur "v5 und v6" hat (u.a.) den Befehl "swp" um atomische Operationen durchzuführen (Architektur v4 (oder noch früher ?) konnte das wohl gar nicht).
Der swp - Befehl ist aber mit Architektur v7 (z.B. Cortex A, wie im Beagle-Bone verbaut) aber anscheinend abgeschafft und wird für User-Land-Programme bei Linux fürchterlich aufwendig (über einen Trap) vom Betriebssystem emuliert.
v7 hat für atomische Operationen den sehr viel besseren "read locked - store conditional" - Mechanismus (LDREX / STREXNE). -> http://www.doulos.com/knowhow/arm/Hints ... emaphores/ "ARM has created the SWP (SWaP) instruction, which is available on all ARM architectures prior to version 7. "
Die "ARM11" CPU im Raspbery Pi ist ein "v6" und bezüglich swp vernutlich genau wie unsere "v5" CPU zu behandeln.
Wenn das User (fpc-) Programm also atomische Operationen macht (ist nur bei Programmen mit mehreren Threads sinnvoll und notwendig), muss es für die richtige ARM-Architektur übersetzt werden. Das geht in fpc vermutlich durch eine Kommando-Zeilen-Option.
Ein weiteres Feature, dass die CPU haben kann oder auch nicht ist Floating Point. Wenn ich das richtig sehe, geht das immer, aber wenn das Programm Floating Point Instruktionen macht und die CPU sie nicht hat, werden sie vom Betriebssystem (über einen Trap) emuliert. Da ist es schneller, im User-Land-Programm direkt eine Floating-Point Emulations-Library einzubinden und den Trap mit Wechsel in den Kernel-Space zu vermeiden.
-Michael
Das "Features: swp " und "(v5l)" kann bei fpc ein Problem sein.
Wenn ich das richtig durchschaue:
Die ARM Architektur "v5 und v6" hat (u.a.) den Befehl "swp" um atomische Operationen durchzuführen (Architektur v4 (oder noch früher ?) konnte das wohl gar nicht).
Der swp - Befehl ist aber mit Architektur v7 (z.B. Cortex A, wie im Beagle-Bone verbaut) aber anscheinend abgeschafft und wird für User-Land-Programme bei Linux fürchterlich aufwendig (über einen Trap) vom Betriebssystem emuliert.
v7 hat für atomische Operationen den sehr viel besseren "read locked - store conditional" - Mechanismus (LDREX / STREXNE). -> http://www.doulos.com/knowhow/arm/Hints ... emaphores/ "ARM has created the SWP (SWaP) instruction, which is available on all ARM architectures prior to version 7. "
Die "ARM11" CPU im Raspbery Pi ist ein "v6" und bezüglich swp vernutlich genau wie unsere "v5" CPU zu behandeln.
Wenn das User (fpc-) Programm also atomische Operationen macht (ist nur bei Programmen mit mehreren Threads sinnvoll und notwendig), muss es für die richtige ARM-Architektur übersetzt werden. Das geht in fpc vermutlich durch eine Kommando-Zeilen-Option.
Ein weiteres Feature, dass die CPU haben kann oder auch nicht ist Floating Point. Wenn ich das richtig sehe, geht das immer, aber wenn das Programm Floating Point Instruktionen macht und die CPU sie nicht hat, werden sie vom Betriebssystem (über einen Trap) emuliert. Da ist es schneller, im User-Land-Programm direkt eine Floating-Point Emulations-Library einzubinden und den Trap mit Wechsel in den Kernel-Space zu vermeiden.
-Michael