Hallo, Ich habe auf einem STM32 ein Embedded Linux mit Busybox laufen und möchte jetzt gerne ein C-Programm darauf ausführen. Jetzt habe ich ein einfaches "Hello world!"-Programm kompiliert und die Binärdatei in das Dateisystem des Embedded Linux kopiert (unter usr/bin). Sobald ich das Programm ausführen möchte bekomme ich die Fehlermeldung "applet not found" von Busybox. Nach einiger Recherche habe ich herausgefunden, dass ich das Programm wohl erst Busybox "hinzufügen" muss. Dabei verzweifle ich allerdings momentan etwas. Vielleicht hat ja jemand Erfahrungen in dem Bereich und kann mir helfen. Gruß
:
Bearbeitet durch User
In Busybox muss nur hineinkompiliert werden, wass Du auch davon benötigst. Busybox schaut sich an, mit welchem "Namen" (argv[0)) es aufgerufen wurde und macht dann das entsprechende. In deinem Dateisystem gibt es einen Haufen symbolische Links, die alle auf busybox verweisen. Wenn nun aber ein symbolischer Link "xyz" auf busybox verweist und als ausführbare Datei aufgerufen wird, busybox aber "xyz" nicht kennt, kommt Deine Fehlermeldung. Da Dein Programm ja erstmal nichts mit busybox zu tun haben sollte, liegt der Fehler mit Sicherheit woanders. Zeig doch mal, was in Deinem Programm steht und was "ls -la" in dem Verzeichnis Deines Programms ausgibt...
Mir fallen da gerade 2 Sachen ein: 1. Kompiliertst du für STM32 oder ausversehen für X86? 2. Der aktuelle Pfad ist nicht im suchpfad für Programme. Setz mal ein ./ vor deinen aufruf (aus "xyz" sollte dann ein "./xyz" werden)
"ls -l" reicht natürlich auch... ggf. könntest Du auch noch die Ausgabe von "file xyz" herzeigen (statt xyz natürlich den Dateinamen Deines Programms).
mh schrieb: > Zeig doch mal, was in Deinem Programm steht und was "ls -la" in dem > Verzeichnis Deines Programms ausgibt... Das angehängte Bild zeigt die Ausgabe von ls-l wobei mein Programm den Namen "hello" hat. Der Quelltext ist einfach:
1 | #include<stdio.h> |
2 | |
3 | int main() { |
4 | printf("Hello World\n"); |
5 | return 0; |
6 | }
|
yesitsme schrieb: > 2. Der aktuelle Pfad ist nicht im suchpfad für Programme. Setz mal ein > ./ vor deinen aufruf (aus "xyz" sollte dann ein "./xyz" werden) Das hatte ich bereits versucht. Dabei kommt immer die Meldung "Permission denied". yesitsme schrieb: > 1. Kompiliertst du für STM32 oder ausversehen für X86? Das könnte natürich sein. Ich hab das Programm einfach mit "gcc hello.c" unter Ubuntu kompiliert und dann die Binärdatei auf mein Board gebracht.
:
Bearbeitet durch User
du musst dein Programm Cross-Compilieren, also mit sowas wie arm-xxx-gcc hello.c und dann auch ausführbar setzen mit chmod 755 hello
user schrieb: > du musst dein Programm Cross-Compilieren, also mit sowas wie arm-xxx-gcc > hello.c Für die "xxx" muss ich doch sicher die Toolchain einsetzten oder? Wenn ich arm-2010q1-gcc hello.c ausführe bekomme ich immer "command not found".
F. J. schrieb: > Das könnte natürich sein. Ich hab das Programm einfach mit "gcc hello.c" > unter Ubuntu kompiliert und dann die Binärdatei auf mein Board gebracht. Auf einer x86/amd64 Maschine? Dir ist schon klar, dass ein STM32 Prozessor kein x86/amd64 Binary ausführen kann? Du musst den gcc des embedded Linux als cross compiler nehmen, sprich, du musst die eine Toolchain installieren. > Ich habe auf einem STM32 ein Embedded Linux mit Busybox laufen und > möchte jetzt gerne ein C-Programm darauf ausführen. Welches Embedded Linux? http://elinux.org/STM32 (älter:) http://www.st.com/content/ccc/resource/technical/document/application_note/d3/20/2d/12/cf/b4/44/0e/CD00242717.pdf/files/CD00242717.pdf/jcr:content/translations/en.CD00242717.pdf
2⁵ schrieb: > Welches Embedded Linux? µCLinux in der Version 2.6.33. Ich hab das ganze hier nach gemacht: https://github.com/AdrianHuang/stm32f429-linux-builder 2⁵ schrieb: > Auf einer x86/amd64 Maschine? Dir ist schon klar, dass ein STM32 > Prozessor > kein x86/amd64 Binary ausführen kann? Inzwischen schon. Aber wie genau ich das Ganze cross kompilieren muss weiß ich noch nicht so ganz.
:
Bearbeitet durch User
Ein schneller Blick in das dortige Makefile besagt, dass der passende Compiler arm-uclinuxeabi-gcc heissen müsste...
mh schrieb: > Ein schneller Blick in das dortige Makefile besagt, dass der passende > Compiler arm-uclinuxeabi-gcc heissen müsste... Sorry, das wollte ich eigentlich noch dazu geschrieben haben. Der Aufruf "arm-uclinuxeabi-gcc hello.c" hat den selben Effekt wie "arm-2010q1-gcc hello.c"
Ich denke, der TO hat einfach den Pfad nicht in seine .bashrc aufgenommen. Führe doch mal "export PATH=`pwd`/arm-2010q1/bin:$PATH" in der shell aus. Danach sollten der arm-gcc im Pfad sein. Welches Linux verwendest du auf deinem PC? Wohin hast du den arm-gcc entpackt?
Nochwas: Normalerweise benötigt man zwei gccs, einen bare-metal, der der linux kernel compiliert und dann einen für das uCLinux ABI. Keine Ahnung, ob der genannte arm-2010q1-189-arm-uclinuxeabi-i686-pc-linux beides kann. Nachdem ich ein stm32f4 discovery hier habe, habe ich mir mal die Dateien runtergeladen und ein make angestoßen.
2⁵ schrieb: > Ich denke, der TO hat einfach den Pfad nicht in seine .bashrc > aufgenommen. > Führe doch mal "export PATH=`pwd`/arm-2010q1/bin:$PATH" in der shell > aus. Das bringt leider auch keine Besserung. 2⁵ schrieb: > Welches Linux verwendest du auf > deinem PC? Wohin hast du den arm-gcc entpackt? Ich nutze die Version 16.04 von Xubuntu (als VM). Der arm-gcc befindet sich im Home Verzeichnis.
2⁵ schrieb: > Nachdem ich ein stm32f4 discovery hier habe, habe ich mir mal die > Dateien runtergeladen und ein make angestoßen. Hm... natürlich ist der cross compiler ein ia32 System. Ich habe hier (leider) amd64. Will jetzt eigentlich nicht das ganze ia32 Sub-System installieren. Deine Vm ist ein 32bit System?
Nachdem ich die arm-uclinuxeabi-gcc Datei in den selben Ordner wie das C-Programm kopiert habe kann ich erfolgreich kompilieren! Daher erst einmal vielen Dank für Eure Hilfe! Leider stehe ich nun vor dem nächsten Problem. Wenn ich das Programm ausführe kommt es zu einem "SEGV" (Segmentation Fault, richtig?). Da das Programm so simpel ist, kann ich mir nur vorstellen, dass ich nicht genügend Rechte auf dem Betriebsystem habe. Außerdem habe ich schon öfter eine Meldung bekommen mit "Read only filesystem". Könnte das vielleicht das Problem sein? Gruß
F. J. schrieb: > Nachdem ich die arm-uclinuxeabi-gcc Datei in den selben Ordner wie das > C-Programm kopiert habe kann ich erfolgreich kompilieren! Na, dann war das Verzeichnis, in dem "arm-uclinuxeabi-gcc" liegt, nicht im pfad. Geb doch mal "export PATH=/home/pfad/zum/bin/verzeichnis/armgcc:$PATH" ein. Aus /home/pfad/zum/bin/verzeichnis/armgcc muss du halt den richtigen Pfad machen...
2⁵ schrieb: > Na, dann war das Verzeichnis, in dem "arm-uclinuxeabi-gcc" liegt, nicht > im pfad. Geb doch mal "export > PATH=/home/pfad/zum/bin/verzeichnis/armgcc:$PATH" > ein. Aus /home/pfad/zum/bin/verzeichnis/armgcc muss du halt den > richtigen Pfad machen... Genau an der Stelle lag mein Fehler. Danke!
F. J. schrieb: > Leider stehe ich nun vor dem nächsten Problem. Wenn ich das Programm > ausführe kommt es zu einem "SEGV" (Segmentation Fault, richtig?). Das liegt daran, dass du dem arm-uclinuxeabi-gcc sagen musst, welchen ARM du hast und wie der ld linken soll (aus dem µCLinux Makefile):
1 | arm-uclinuxeabi-gcc -march=armv7-m -mtune=cortex-m4 -mlittle-endian -mthumb -Os -ffast-math -ffunction-sections -fdata-sections -Wl,--gc-sections -fno-common --param max-inline-insns-single=1000 -Wl,-elf2flt=-s -Wl,-elf2flt=16384 helloworld.c -o helloworld |
Das fertige binary kopierst du dann in dein rootfs nach usr/bin und baust anschließend dein rootfs neu mit "make build-rootfs". Das neue rootfs.bin kannst du dann flashen mit
1 | openocd -f board/stm32f429discovery.cfg -c "init" -c "reset init" -c "flash write_image erase romfs.bin 0x08120000" |
Dann klappts auch mit dem hello world!
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.