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:
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
@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).
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?
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.
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?
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.
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.
@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
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...
/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?!
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.
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.
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.
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.
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?!
