Crosscompiling für QNAP (Arm)

[af0815]

Die beiden Modelle sind bis auf die CPU Geschwindigkeit und das Memory aus der Sicht der Programm gleich.

Code: Alles auswählen

Model 	TS-212	TS-219P II
Segment 	Home/SOHO	Home/SOHO
OS 	Embedded Linux	Embedded Linux
CPU 	Marvell 1.2 GHz   	Marvell 2.0 GHz
Memory 	256MB RAM	512MB RAM
Flash 	16MB	              16MB

Die 259 kann noch WOL, Hotswap,.... aber nichts was ich benötige. Ich habe mir vor dem Kauf schon sehr genau angesehen was ich benötige bzw. kaufe. Deshalb habe ich auch 2 Stk. gekauft, eine als produktives System und eine zu herumtesten. Hat sich schon bewährt Ich könnte es mir einfach machen und die NAS auf Debian-arm umstellen. Habe das schon überlegt, denn dann könnte ich daraus einen Samba 4 AD Controller machen. Denn die Stromaufnahme (nachgemessen !!) ist relativ gering. Das System selbst benötigt in etwa 5W, dazu muß man noch die Platten berücksichtigen 2* 5W. Man kommt je nach Betriebszustand auf 8W (Platten IDLE) bis ca. 16 W (Platten im Betrieb). Der Strom ist für mich das Argument, ein alter PC als Server benötigt viel mehr an Leistung.

[af0815]

Ich habe das Paket von CodeSourcery installiert und folgendes eingegeben

Code: Alles auswählen

 
root@VMDEBPASCAL:/home/andi/fpc# make crossinstall CPU_TARGET=arm OS_TARGET=linux CROSSBINDIR=/home/andi/CodeSourcery/Sourcery_G++_Lite/bin BINUTILSPREFIX=arm-none-linux-gnueabi- OPT=-dFPC_ARMEL INSTALL_PREFIX=/usr/local PP=/home/andi/fpc/compiler/ppc386
 

Wichtig ist das BINUTILSPREFIX=arm-none-linux-gnueabi-, das sorgt dafür das die Tools auch gefunden werden trotz prefix im Dateinamen.

Das Ergebnis ist der ppcrossarm, mal sehen ob es auch Code erzeugt der auf der QNAP läuft.

Code: Alles auswählen

 
root@VMDEBPASCAL:/home/andi/fpc/compiler# ./ppcrossarm -i
Free Pascal Compiler version 2.7.1
 
Compiler Date      : 2013/02/03
Compiler CPU Target: arm
 
Supported targets:
  Linux for ARMEL
  WinCE for ARM
  GameBoy Advance
  PalmOS
  Nintendo DS
  Embedded
  Symbian OS for ARM
  Darwin for ARM
 
Supported CPU instruction sets:
  ARMV3,ARMV4,ARMV4T,ARMV5,ARMV5T,ARMV5TE,ARMV5TEJ,ARMV6,ARMV6K,ARMV6T2
  ARMV6Z,ARMV7,ARMV7A,ARMV7R,ARMV7M,ARMV7EM
 
Supported FPU instruction sets:
  SOFT,LIBGCC,FPA,FPA10,FPA11,VFPV2,VFPV3,VFPV3_D16,FPV4_S16
 
Supported ABI targets:
  DEFAULT
  SYSV
  AIX
  EABI
  ARMEB
  EABIHF
 
Supported Optimizations:
  REGVAR
  STACKFRAME
  LOOPUNROLL
  TAILREC
  CSE
  ORDERFIELDS
  FASTMATH
 
Supported Whole Program Optimizations:
  All
  DEVIRTCALLS
  OPTVMTS
  SYMBOLLIVENESS
 
Supported Microcontroller types:
  LPC2114,LPC2124,LPC2194,LPC1754,LPC1756,LPC1758,LPC1764,LPC1766,LPC1768
  AT91SAM7S256,AT91SAM7SE256,AT91SAM7X256,AT91SAM7XC256,STM32F100X4
  STM32F100X6,STM32F100X8,STM32F100XB,STM32F100XC,STM32F100XD,STM32F100XE
  STM32F101X4,STM32F101X6,STM32F101X8,STM32F101XB,STM32F101XC,STM32F101XD
  STM32F101XE,STM32F101XF,STM32F101XG,STM32F102X4,STM32F102X6,STM32F102X8
  STM32F102XB,STM32F103X4,STM32F103X6,STM32F103X8,STM32F103XB,STM32F103XC
  STM32F103XD,STM32F103XE,STM32F103XF,STM32F103XG,STM32F107X8,STM32F107XB
  STM32F107XC,LM3S1110,LM3S1133,LM3S1138,LM3S1150,LM3S1162,LM3S1165
  LM3S1166,LM3S2110,LM3S2139,LM3S6100,LM3S6110,LM3S1601,LM3S1608,LM3S1620
  LM3S1635,LM3S1636,LM3S1637,LM3S1651,LM3S2601,LM3S2608,LM3S2620,LM3S2637
  LM3S2651,LM3S6610,LM3S6611,LM3S6618,LM3S6633,LM3S6637,LM3S8630,LM3S1911
  LM3S1918,LM3S1937,LM3S1958,LM3S1960,LM3S1968,LM3S1969,LM3S2911,LM3S2918
  LM3S2919,LM3S2939,LM3S2948,LM3S2950,LM3S2965,LM3S6911,LM3S6918,LM3S6938
  LM3S6950,LM3S6952,LM3S6965,LM3S8930,LM3S8933,LM3S8938,LM3S8962,LM3S8970
  LM3S8971,LM3S5951,LM3S5956,LM3S1B21,LM3S2B93,LM3S5B91,LM3S9B81,LM3S9B90
  LM3S9B92,LM3S9B95,LM3S9B96,SC32442B,THUMB2_BARE
 
This program comes under the GNU General Public Licence
For more information read COPYING.v2
 
Please report bugs in our bug tracker on:
                 http://bugs.freepascal.org
 
More information may be found on our WWW pages (including directions
for mailing lists useful for asking questions or discussing potential
new features, etc.):
                 http://www.freepascal.org
 

[af0815]

Ein kurzes Programm für einen Test erstellt mit dem Namen hello.pp

Code: Alles auswählen

program Hello;
begin
WriteLn('Hello World');
end. 

Kompiliert mittels

Code: Alles auswählen

root@VMDEBPASCAL:/home/andi/prj# ppcrossarm -Tlinux -O- -XP -Fu/home/andi/fpc/rtl/units/arm-linux/ -XParm-none-linux-gnueabi- -FD/home/andi/CodeSourcery/Sourcery_G++_Lite/bin /home/andi/prj/hello.pp

hat eine Datei Hello erzeugt, anschliessend auf die QNAP kopiert

Auf der NAS kommt folgendes auf der Konsole heraus

Code: Alles auswählen

[/share/Public] # readelf -a hello
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:               0x80a0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          40216 (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:         3
  Size of section headers:           40 (bytes)
  Number of section headers:         8
  Section header string table index: 7
 
.....
 
Attribute Section: aeabi
File Attributes
  Tag_CPU_arch: v5TE
  Tag_ARM_ISA_use: Yes
[/share/Public] # ./hello
Hello World
[/share/Public] #

[mschnell]

Der Strom ist für mich das Argument, ein alter PC als Server benötigt viel mehr an Leistung.

Same here
Momentan habe ich einen gar nicht so alten (ATOM) PC als Server und das QNAP als Gehäuse für die Backup-Platten. Ich plane aber den Server durch ein zweites QNAP zu ersetzen. Dann muss aber auch meine Software darauf laufen....

-Michael

[mschnell]

[/share/Public] # ./hello
Hello World
[/share/Public] #

Super !
Glückwunsch.

Habe ich richtig verstanden, dass Du das Sourcery Zeug brauchst, um die ARM-Libraries zu haben ?

Ich habe beim nativen compilieren auf dem QNAP gesehen, dass der linker alle so-files finden muss, die nachher dynmisch vom Programm geladen werden könnten. Dazu musste ich de fpc mit -FL den Ort dieser Dateien angeben:
fpc -Fl/opt/arm-none-linux-gnueabi/lib/ -Fu./synapse heiz.lpr

Das sollte beim Cross-Compilieren wohl ebenfalls nötig sein.

Was Dir aber geholfen hat den fpc selbst (also ein x86-Programm) zu erzeugen, habe ich nicht verstanden. Im anderen Thread hattest Du ja geschrieben, dass das nicht funzt)

Und nun bin ich gespannt auf Deine Ergebnisse zum remote-Debuggen mit Lazarus. Wenn das klappt, steige ich auch um.

-Michael

[af0815]

Was Dir aber geholfen hat den fpc selbst (also ein x86-Programm) zu erzeugen, habe ich nicht verstanden. Im anderen Thread hattest Du ja geschrieben, dass das nicht funzt)

Der Bootstrap von absolut Null weg ist nicht ganz sauber. Ein Tool hat ein Henne <-> Ei Problem. Also nichts was nicht mit einem Symlink zum Beheben geht.

Lazarus kompiliert auch schon nachdem ich die fpc.cfg für das Crosscompiling geändert habe, das allerdings nicht 100% sauber.

Bezüglich Debuggen habe ich noch einen weiten Weg vor mir. Auf den Grundsystem habe ich noch keinen GDB. Mein Problem ist, welchen nehme ich auf dem System - ich habe ja keine Pakete verwendet. Darf ich den standard GDB verwenden ? Wie funktioniert bei Lazarus das Remote debugging ?!

Also jede Menge an Fragen.

Edit: der gdbserver ist mal nicht in den ipkg's vorhanden. Schaut nicht so easy aus.

[mschnell]

Bezüglich Debuggen habe ich noch einen weiten Weg vor mir. Auf den Grundsystem habe ich noch keinen GDB. Mein Problem ist, welchen nehme ich auf dem System - ich habe ja keine Pakete verwendet. Darf ich den standard GDB verwenden ? Wie funktioniert bei Lazarus das Remote debugging ?!

Soweit ich das verstehe brauchst Du den Standard - gdb auf beiden Systemen. Auf dem PC den ganz normalen, auf dem Target gdbserver.

siehe http://davis.lbl.gov/Manuals/GDB/gdb_17.html

Der Standard - gdb verbindet sich mit einem gdbserver, wenn man ihm den entsprechenden Befehl mit TCP/IP-Adresse und Port gibt : "(gdb) target remote the-target:2345".

Das habe ich mit Eclipse vor Jahren schon mal gemacht. Wie es mit SSH geht, weiß ich allerdings nicht (dabei sollte der gdbserver auf dem Target automatisch gestartet werden und muss nicht dort von Hand vorher angestartet sein, weil SSH zuerst immer einen Kommandoozeilen login macht und dann beliebige Kommandos ausführen kann <so funktioniert z.B. SCP>.)

Bei Eclipse gibt es ein Fenster in dem man direkt manuell mit gdb kommunizieren kann. Wie man Lazarus dazu veranlasst, den passenden Befehl an gdb zu geben, weiß ich noch nicht. Vielleicht sollte man dazu in der Englischen Mailing Liste eine Frage stellen....

der gdbserver ist mal nicht in den ipkg's vorhanden.

Ich habe - bevor ich das "TAR-Paket" kannte - den fpc (2.2 oder so) aus einem Debian ("apt-get") Pakt "von hand" extrahiert. Das war mit "ar" und dann "mc" gar kein Problem. Wenn Du also das Debian Paket mit gdbserver für die richtige CPU findest, sollte es gehen.

Oder vielleicht hier: http://gnutoolchains.com/android/


-Michael

[af0815]

Also das Crosscompilieren des gdbservers ist eine harte Nuß, ich bekomme ja einen gdbserver, nur für die falsche Plattform

Edit: Done !!

Wenn man sich das configure Log und das Makefile genau ansieht, dann sieht man (eventuell) was schief läuft. Geht doch.

Meldung auf der TS-212

Code: Alles auswählen

[/share/Public] # ./gdbserver --version
GNU gdbserver 6.8
Copyright (C) 2007 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public License.
This gdbserver was configured as "arm-none-linux-gnueabi"
 

Der Rest wird auch noch funktionieren

[mschnell]

SUPER !!!!

Die Sourcen cross-compilieren muss ja gehen, war aber klar, dass es nicht einfach ist Deshalb hatte ich nach binär-Versionen gesucht (s.o.). Aber so ist es natürlich sportlicher.

Aber warum musstest Du es cross-compilieren ? Bei mir läuft gcc problemlos und sollte den gdbserver nativ übersetzen, wenn man alle Sourcen und das Makefile hat.

-Michael

[af0815]

Aber warum musstest Du es cross-compilieren ?

Du brauchst einen gdbserver (arm) der nativ passen muss und einen gdb am Host der zwar X86 ist ABER mit dem Arm gdbserver kommunizieren kann. Deshalb der Aufwand, noch dazu ist es meiner Erfahrung gesünder wenn alles aus dem selben Release kommt.

Was ich jetzt nochmals prüfen muss ist, ob der gdb in ersten Versuch wirklich sauber ist. Anschließend natürlich das ganze mit Lazarus auch.

Ich habe das ganze natürlich auch mitdokumentiert, nur noch nicht in einer Form die ich so einfach publizieren will. So wie es aussieht haben auch noch nicht allzuviele Personen Interesse daran Wobei es eigentlich egal ist, für welches Armgerät man sich das baut. Wichtig ist ja, das man einmal den richtigen Toolchain findet. Wobei mir hier geholfen hat, das ich das mit dem Kompilieren für die Qnap schon fast ein Jahr mitverfolge. Der Vorgang ist für alle NAS von QNAP mit ARM Prozessor IMHO gleich.

Ich kann dir gerne vorweg meine Schritte zukommen lassen, wenn du auch das ganze direkt bei Dir testen willst.

[mschnell]

Ich habe das ganze natürlich auch mitdokumentiert,

Super ! Danke.

So wie es aussieht haben auch noch nicht allzuviele Personen Interesse daran

Da hast Du vermutlich recht. "Embedded" ist nicht in....

Wobei es eigentlich egal ist, für welches Armgerät man sich das baut. Wichtig ist ja, das man einmal den richtigen Toolchain findet.

So ist es ! (Die meisten wollen eine eine Cross-Toolchain nur bei "Headless" Geräten benutzen. Ich finde es aber immer sehr sinnvoll.) In der Firma will ich mittelfristig auch unsere Steuerungen auf ARM/Linux umstellen. Die Hardware ist aber momentan noch zu teuer in der (relativ kleinen) Serie zu bauen. Wenn endlich Prozessor-Chips mit genügend eingebautem RAM rauskommen, wird sich das schlagartig ändern. Da will ich natürlich vorbereitet sein.

Ich kann dir gerne vorweg meine Schritte zukommen lassen, wenn du auch das ganze direkt bei Dir testen willst.

Ich hab's momentan nicht eilig (mein zweites QNAP ist nicht vor der 2. Jahreshälfte geplant) , bin aber gerne bereit bereit, alles mitzumachen, was Du vorschlägst.

Gruß und Dank,
-Michael

[mschnell]

Du brauchst einen gdbserver (arm) der nativ passen muss und einen gdb am Host der zwar X86 ist ABER mit dem Arm gdbserver kommunizieren kann.

Hmm. Beim korrekten Cross-kompilieren (mit den richtigen Libraries) sollte binär dieselbe Datei herauskommen, wie beim nativen compilieren mit derselben gcc Version auf dem Target.
-Michael

[af0815]

Gemeint ist damit ein gdb der auf X86 läuft, aber Arm spricht. Das ist die Kombination die man nur für das Crossdebuggen benötigt.

[mschnell]

Gemeint ist damit ein gdb der auf X86 läuft, aber Arm spricht. Das ist die Kombination die man nur für das Crossdebuggen benötigt.

Das ist klar. Aber:
- die Datei "gdb" musst Du auf dem X86 mit normalem kompilieren erzeugen.
- die datei gdbserver kannst Du auf (aus denselben Sourcen) dem X86 mit cross-Compilieren erzeugen oder auf dem ARM mit nativen Compilieren. Das Ergebnis sollte dasselbe sein. Du sparst Dir nur das Einrichten von gcc als Cross-Compiler (gcc-arm auf dem X86).

-Michael

[mschnell]

Ich habe Martin Friebe gebeten, hier 'mal vorbeizuschauen.

Er hat mir schonmal dieses Link geschickt: : http://wiki.lazarus.freepascal.org/Remote_Debugging

-Michael