Linux auf ARM - cross Kompilierung

[Peterle A. (Firma: keine) (wanderameise)]

Ich habe auf meinem AT91 ein Linux zum laufen bekommen 
(http://www.at91.com/linux4sam/bin/view/Linux4SAM/GettingStarted#Demo9263). 
Via UART kann ich die shell remote bedienen. Jetzt wollte ich ein 
einfaches "hello world" auf die Konsole zaubern. Dazu habe ich die GCC 
toolchain für ARM auf meinem Ubuntu eingerichtet und ein einfaches hello 
word geschrieben. Kompiliert hat er ohne Probleme. Jedoch hat das binary 
auf meinem embedded Linux ein segmentation fault hervorgerufen. Jetzt 
versuche ich natürlich herauszufinden woran es liegen könnten: Am 
kompiliervorgang? Am Linux selbst?
Ich fange mal mit dem code und dem GCC aufruf an:

#include <stdio.h>
int main(int argc, char *argv[])
{
printf("hallo");
return 0;
}

 arm-elf-gcc -Wall -mcpu=arm9 test.c -o test

ich bin für jeden tip dankbar

[Tobi (Gast)]

Hi,

ich kompiliere inzwischen direkt auf meinem Pandaboard. Das ist deutlich 
stressfreier als die Verwendung eines Cross Compilers. Das sollte mit 
deinem Board auch gehen.

Gruss,
Tobi

[ozo (Gast)]

Aus deinem Text geht für mich nicht hervor, ob du die mitgelieferte 
Toolchain oder eine eigene benutzt hast. Unbedingt die mitgelieferte 
benutzen!

[Peterle A. (Firma: keine) (wanderameise)]

@Tobi: sprich gcc für ARM besorgen (bauen) und nativ kompilieren? Mh ist 
das nicht recht ressourcen hungrig? Hast du vll ein howto, damit ich mir 
das mal anschauen kann? Wobei ich cross kompilieren eingentlich 
bevorzuge... Müsste man mal testen.

@ozo: Also die toolchain habe ich mir komplett selbst gebaut, sprich die 
Quellen (gabs hier http://www.gnuarm.com/) genommen und für die ARM 
Architektur gebaut. Mitgeliefert gabs keine (http://www.at91.com).

[ozo (Gast)]

Ok, verstanden. Und dein "hello world" wird mit der toolchain, welche 
auch das System übersetzt hat, gebaut?
Ich frag so blöd, weil ich gerne in so Fallen reintappe.
Laut der Seite aus deinem Link gibts aber Buildroot für die Platform, 
oder?

[Werner B. (werner-b)]

Das ist vergleichbar mit amerikanischen Mars-Sonden ;-)

Der Sensor liefert Messwerte in Feet.
Gerechnet wird mit Meter.
(oder wars andersherum 8-D)

Das macht Löcher in die Oberfläche des Ziels.

[Rolf M. (rmagnus)]

Peterle Anonym schrieb:
> arm-elf-gcc -Wall -mcpu=arm9 test.c -o test

Probier's mal mit arm-linux-gnueabi-gcc.

[Peterle A. (Firma: keine) (wanderameise)]

Werner B. schrieb:
> Das ist vergleichbar mit amerikanischen Mars-Sonden ;-)
>
> Der Sensor liefert Messwerte in Feet.
> Gerechnet wird mit Meter.
> (oder wars andersherum 8-D)
>
> Das macht Löcher in die Oberfläche des Ziels.

ein wenig genauer und ich könnte anfangen zu suchen! der Compiler ist 
der falsche?!

@Rolf Magnus: habe ich auch schon überlegt, benutze diesen in meiner 
cygwin umgebung, wobei ich dort ohne linux auskomme. könntest du mir 
sagen wieso ich lieber diesen probieren soll?

[Futel (Gast)]

Tobi schrieb:
> ich kompiliere inzwischen direkt auf meinem Pandaboard. Das ist deutlich
> stressfreier als die Verwendung eines Cross Compilers. Das sollte mit
> deinem Board auch gehen.

distcc wäre ein Ansatz um sich den Crosscompile Nerv zu sparen und 
trotzdem nicht ewig zu warten.

[Rolf M. (rmagnus)]

Peterle Anonym schrieb:
> @Rolf Magnus: habe ich auch schon überlegt, benutze diesen in meiner
> cygwin umgebung, wobei ich dort ohne linux auskomme. könntest du mir
> sagen wieso ich lieber diesen probieren soll?

Ich denke, daß der, den du probiert hast, dafür gedacht ist, Programme 
zu generieren, die ohne Betriebssystem direkt auf dem Prozessor laufen.

[Werner B. (werner-b)]

Du musst rausfinden mit welcher Compiler "Spielart" der Kernel gebaut 
worden ist.

~# cat /proc/version

auf dem Zielsystem gibt da üblicherweise Auskunft.

[Tobi (Gast)]

@wanderameise,

>@Tobi: sprich gcc für ARM besorgen (bauen) und nativ kompilieren? Mh ist
>das nicht recht ressourcen hungrig? Hast du vll ein howto, damit ich mir
>das mal anschauen kann? Wobei ich cross kompilieren eingentlich
>bevorzuge... Müsste man mal testen.

Ich habe hier eine aktuelle Ubuntu Version auf dem Desktop Rechner 
laufen. Damit kannst du für ARM ein Image mit dem Befehl rootstock 
erzeugen. Das Image enthält ein komplettes Ubuntu System für ARM. Wenn 
das Board Internet Zugang hat, kannst du mittels "sudo apt-get install 
build-essential" den GCC installieren.

Gruss,
Tobi

[Peterle A. (Firma: keine) (wanderameise)]

Rolf Magnus schrieb:
> Peterle Anonym schrieb:
>> @Rolf Magnus: habe ich auch schon überlegt, benutze diesen in meiner
>> cygwin umgebung, wobei ich dort ohne linux auskomme. könntest du mir
>> sagen wieso ich lieber diesen probieren soll?
>
> Ich denke, daß der, den du probiert hast, dafür gedacht ist, Programme
> zu generieren, die ohne Betriebssystem direkt auf dem Prozessor laufen.

Das war die erste frage die ich mir gestellt habe - kann ich code den 
ich für meine MCU ohne OS geschrieben habe, genauso mit OS ausführen? 
Also, die Zielarchitektur ist schonmal die selbe. jedoch habe ich ein 
linker file, das mir sagt wohin der code kommt. das fällt doch bei einem 
OS weg, da ja dieses die Speicherverwaltung organisiert. Kann es also 
sein, dass mein binary auf eine Adresse schreiben will, die dem Linux 
gar nicht mehr zur verfügung steht, da da zB Uboot liegt?! Oder erkennt 
das das OS und fügt einen offset ein, damit mein code im user space 
landet?
Das würde bedeuten, das man einen kompiler benutzen muss, der weiss, 
dass der code für Linux geschrieben wird. Das könnte auch zu Werner B.'s 
anspielung passen...

[Peterle A. (Firma: keine) (wanderameise)]

/proc/version info:

Linux version 2.6.30 (nferre@bendor) (gcc version 4.2.4) #1 Tue Mar 9 
23:50:53

habe aber aus den kernel configs erfahren, dass der kernel mittel ARM 
EABI gebaut wurde, evtl sollte ich das auch in Betracht ziehen?!

[Rolf M. (rmagnus)]

Peterle Anonym schrieb:
> Das war die erste frage die ich mir gestellt habe - kann ich code den
> ich für meine MCU ohne OS geschrieben habe, genauso mit OS ausführen?

Nein. Unter Linux greift dein Programm auf sämtliche Ressourcen über 
Linux-Systemcalls zu. Ohne OS muß es das alles direkt tun.

> Also, die Zielarchitektur ist schonmal die selbe. jedoch habe ich ein
> linker file, das mir sagt wohin der code kommt. das fällt doch bei einem
> OS weg, da ja dieses die Speicherverwaltung organisiert.

Da kann aber der Linker trotzdem sagen, wo das OS den Code in den 
Adressraum mappen soll.

> Kann es also sein, dass mein binary auf eine Adresse schreiben will, die
> dem Linux gar nicht mehr zur verfügung steht, da da zB Uboot liegt?!

Unter Linux hast du Speicher-Virtualisierung. Das heißt, dein Programm 
greift nie direkt auf realen Speicher zu. Es greift auf Segmente zu, die 
der Kernel dann irgendwie auf den echten Speicher (oder auf irgendwas 
anderes) mappt.

[Peterle A. (Firma: keine) (wanderameise)]

Rolf Magnus schrieb:
> Peterle Anonym schrieb:
>> Das war die erste frage die ich mir gestellt habe - kann ich code den
>> ich für meine MCU ohne OS geschrieben habe, genauso mit OS ausführen?
>
> Nein. Unter Linux greift dein Programm auf sämtliche Ressourcen über
> Linux-Systemcalls zu. Ohne OS muß es das alles direkt tun.
>

ja ich weiss, ich meinte damit, ob ich ein binary für ARm linux mit 
derselben toolchain bauen kann wie ohne Linux.

>> Also, die Zielarchitektur ist schonmal die selbe. jedoch habe ich ein
>> linker file, das mir sagt wohin der code kommt. das fällt doch bei einem
>> OS weg, da ja dieses die Speicherverwaltung organisiert.
>
> Da kann aber der Linker trotzdem sagen, wo das OS den Code in den
> Adressraum mappen soll.
>

ok aber mein output sagt ja erstmal, starte ab adresse 0x0 im NAND, das 
ist ja unfug, da dort ja zB Uboot liegt und nicht der user space. oder 
juckt es das OS nicht und es schiebt den code einfach in den richtigen 
Addressbereich?!

>> Kann es also sein, dass mein binary auf eine Adresse schreiben will, die
>> dem Linux gar nicht mehr zur verfügung steht, da da zB Uboot liegt?!
>
> Unter Linux hast du Speicher-Virtualisierung. Das heißt, dein Programm
> greift nie direkt auf realen Speicher zu. Es greift auf Segmente zu, die
> der Kernel dann irgendwie auf den echten Speicher (oder auf irgendwas
> anderes) mappt.

ich weiss, es geht nicht um Adresszugriffe, sondern um die Adressen, die 
im executable stehen, also da wo der code hin soll, und die liegen was 
weiss ich wo.

[Rolf M. (rmagnus)]

Peterle Anonym schrieb:

>> Unter Linux hast du Speicher-Virtualisierung. Das heißt, dein Programm
>> greift nie direkt auf realen Speicher zu. Es greift auf Segmente zu, die
>> der Kernel dann irgendwie auf den echten Speicher (oder auf irgendwas
>> anderes) mappt.
>
> ich weiss, es geht nicht um Adresszugriffe, sondern um die Adressen, die
> im executable stehen, also da wo der code hin soll, und die liegen was
> weiss ich wo.

Das Executable bestimmt nicht, wo es hingeladen wird, sondern der 
Kernel. Der gibt deinem Prozess einen virtuellen Adressraum, und dessen 
Adresse 0 hat nichts mit der Adresse 0 des realen Speichers zu tun. Und 
das gilt auch schon beim Laden des Programms.

[asd (Gast)]

Peterle Anonym schrieb:
> ja ich weiss, ich meinte damit, ob ich ein binary für ARm linux mit
> derselben toolchain bauen kann wie ohne Linux.

Ich glaube die Antwort lautet: nein.

[Peterle A. (Firma: keine) (wanderameise)]

Rolf Magnus schrieb:
> Peterle Anonym schrieb:
>
>>> Unter Linux hast du Speicher-Virtualisierung. Das heißt, dein Programm
>>> greift nie direkt auf realen Speicher zu. Es greift auf Segmente zu, die
>>> der Kernel dann irgendwie auf den echten Speicher (oder auf irgendwas
>>> anderes) mappt.
>>
>> ich weiss, es geht nicht um Adresszugriffe, sondern um die Adressen, die
>> im executable stehen, also da wo der code hin soll, und die liegen was
>> weiss ich wo.
>
> Das Executable bestimmt nicht, wo es hingeladen wird, sondern der
> Kernel. Der gibt deinem Prozess einen virtuellen Adressraum, und dessen
> Adresse 0 hat nichts mit der Adresse 0 des realen Speichers zu tun. Und
> das gilt auch schon beim Laden des Programms.

ok danke!

@asd: also gcc explizit für ARM linux bauen?!