Könnt ihr zu den genannten Stichworten gute Bücher empfehlen? Ich merke gerade, dass das Thema Embedded Linux eine ganz andere Welt ist als µC ohne bzw. mit einfachem Betriebssystem (RTOS) und man sich das nicht ganz so einfach via "Learning by Doing" beibringen kann. Grüße
Busybox ist nur eine Eingabeaufforderung die ohne weitere Dateien auskommt. Das kannst du mit der command.com von DOS vergleichen, falls du sie kennst. Im Gegenzug dazu verwenden normale Linux Systeme (auch Raspberry Pi) eine Bash Shell. Diese enthält nur wenige integrierte Befehle, die meisten Befehle werden als separates Programm nachgeladen. Ich denke dass du Linux am Besten Kennenlernen kannst, indem du ein normales Linux benutzt. Das kann gerne auch in Form eines Raspberry Pi passieren, oder eine Virtuelle Maschine innerhalb von Windows mit Oracle VirtualBox oder dem Windows Subsystem für Linux (VirtualBox ist die einfachste Option). Bei Linux wird immer zuerst ein Bootloader gestartet. Seine Aufgabe ist, den Kernel in den Speicher zu laden und zu starten. Die Datei die den Kernel enthält heißt typischerweise vmlinuz. Wenn der Kernel von dynamischen Modulen abhängt, die schon zum Start gebraucht werden, dann gibt es noch eine zweite Datei namens initrd, die der Bootload ebenfalls in den Speicher laden muss. Bei einem PC findet man darin zum Beispiel die Treiber für den Mainboard-Chipsatz und die Festplatte (bzw. SSD). Man kann Kernel-Module aber auch statisch linken, dann befinden sie sich in der Datei vmlinuz. Da diese nicht beliebig groß werden darf, hat man das irgendwann mal auf zwei Dateien aufgeteilt. Beim Start öffnet der Kernel das "root" Dateisystem von einem Speichermedium. Alle dazu nötigen Treiber müssen entweder statisch im Kernel enthalten sein, oder in der initrd. Alle weiteren Treiber, die jetzt noch nicht gebraucht werden, können im root Dateisystem liegen. Zum Beispiel Grafiktreiber. Das erste Programm das der Kerne immer automatisch startet ist "/sbin/init". Interessanterweise muss das nicht zwingend ein ausführbares Programm sein, sondern es kann auch ein Shell Script sein. Dann muss der entsprechende Script-Interpreter allerdings auch im root Dateisystem liegen. Die erste Zeile im init Script gibt den Pfad des Interpreters an. Alles was danach passiert bestimmt das init Programm bzw. Script. Detaillierte Doku zu diesen Vorgängen findest du am besten auf den Webseiten von SuSE und Arch Linux.
Hallo, kein Buch und nicht mehr aktuell, aber es gibt die Ausgaben vom embedded-projects.net Journal noch als pdf zum download: http://journal.embedded-projects.net/downloads/EPJ_01_web.pdf http://journal.embedded-projects.net/downloads/EPJ_02_web.pdf ... http://journal.embedded-projects.net/downloads/EPJ_25_web.pdf Die Seite http://journal.embedded-projects.net/ ist abgeschaltet und auf http://journal.embedded-projects.net/downloads/ gibt es keinen Zugriff, aber man kann sich die pdfs einzeln anschauen bzw. herunterladen oder das auch mit wget automatisieren.
Ich kann mit deiner Antwort ehrlich gesagt nicht so viel anfangen (trotzdem danke). Worum es mir vor allem geht: 1) Wie modifiziere ich Uboot so, dass es auf neuer Hardware läuft für die es kein bereits fertiges Uboot gibt (DRAM-Initialisierung, Flash-Initialisierung, serielle Konsole, Display Initialisierung)? 2) Wie erstelle ich mit Buildroot / Yocto eine lightweight Linux-Umgebung? 3) Wie bekomme ich ein möglichst schnelles Entwicklungssystem (schnell im Sinne von automatisiert) bei dem ich meine Anwendungen einfach auf das Linux-System übertragen und ausführen ggf. debuggen kann (sofern ich diese Cross-kompilieren muss / möchte)?
Danke Alex, das sieht auf den 1. Blick schon mal sehr interessant aus.
Hast Du denn schon eine Hardware im Auge? Die Yocto-Lernkurve ist ziemlich steil, aber im Prinzip wäre es günstig die Grundlagen (aus welchen Teilen besteht Dein embedded System: kernel, devicetree, rootfs, bootloader) zu verstehen. Wie Du richtig schon bemerkt hast, ist Yocto dazu da um dir diese Teile zu "bauen" d.h. auf einem Host-System kompilierst Du die Programme / den Code, der dann auf der Hardware laufen soll. Dann brauchst Du halt noch die Art, wie Du das Paket auf Dein Board bekommst (SD-Karte? Nand?) Vielleicht ist es eine gute Idee, Dir ausgehend von der Hardware ein Buildsystem aufzubauen. In Yocto gibt es poky - eine Beispieldistribution und wenn Du Glück hast dann liefert der Hersteller Deines Boards gleich noch Doku und Layer für Yocto mit, unter Nutzung derer Du gleich starten kannst. Buch .. naja ich finde die Yocto-Doku ( https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html ) immer hilfreich. Ich hatte mir damals das Buch hier geholt: "Embedded Linux Systems with the Yocto Project " von Rudolf J. Streif Viel Erfolg ... und lass' Dich nicht entmutigen!
Danke Sascha. Geht um ein STM32MP1 Dev-Board. Ich habs geschafft, das Board mit einem fertigen Image von STM zu booten aber beim selbstkompilierten mit einer buildroot-Vorlage aus dem Internet bricht der Bootprozess irgendwann ab. Generell würd ich mehr über Uboot verstehen wollen aber ich weiß nicht, wo man da ansetzt.
Etwas älter - aber lesenswert. https://www.oreilly.com/library/view/building-embedded-linux/059600222X/ Pinguin
Naja, ich weiß nicht, ob es Dir hilft ... oder ob das für Dich eine Motivation ist... aber: BLEIB' DRAN! Der erste Schritt mit Dev-Board und fertigem Image hat geklappt. Der nächste Versuch mit Buildroot schlug fehl. Entscheide nun: Bleibst Du auf dem Weg oder suchst Du vielleicht nach Alternativen? Du kannst genau herausfinden, an welcher Stelle der Bootvorgang abgebrochen ist. Und dann weiterhangeln... was die Ursache sein könnte... Ich habe mit dem Board noch nichts gemacht, aber schnell ein paar Links gefunden, hast Du die schon gesehen? https://st-onlinetraining.s3.amazonaws.com/STM32MP1-Ecosystem-OpenSTLinux_Distribution/index.html https://wiki.st.com/stm32mpu/wiki/STM32MP1_Distribution_Package Wow: Schau mal hier: https://bootlin.com/blog/yocto-project-training-course-available-on-stm32mp1-platform/ dort gibt es richtig Futter (PDF: slides, labs genau mit dem Board) - das würde ich als geeignet sehen, um einen Fuß in die Tür zu bekommen... Also wenn Dich das Thema wirklich interessiert, kann ich Dir nur empfehlen, hartnäckig dran zu bleiben. Der Einstieg ist nicht so leicht wie "Arduino-IDE installieren und LED blinken lassen" - aber es warten viele spannende Konzepte und Möglichkeiten auf Dich... Viele Grüße, Sascha
Stefan ⛄ F. schrieb: > Busybox ist nur eine Eingabeaufforderung die ohne weitere Dateien > auskommt. Das kannst du mit der command.com von DOS vergleichen, falls > du sie kennst. Naja, Busybox ist schon ein wenig mehr. Man kann Shell Befehle wie z.B. cd, mkdir, pwd, chmod, und so gut wie alle andere Befehle, die für ein Embedded Linux nützlich sein können, in busybox rein kompilieren und hat dann ein Binary mit vielen eingebauten Befehlen. Ein korrektes build baut symlinks und stellt damit auf der Shell die kompilierten Befehle bereit. Da busybox dabei viele Sachen mehrfach benutzen kann, spart es jede Menge Overhead ein und man hat nur ein kompaktes Binary.
Ggf findest du mir etwas suchen die Trainingsunterlagen zu den Seminaren/Workshops von Robert Berger.
Matthias S. schrieb: > Naja, Busybox ist schon ein wenig mehr > ... und hat dann ein Binary mit vielen eingebauten Befehlen Habe ich das nicht geschrieben? Zumindest war es meine Absicht, genau dieses besondere Merkmal hervor zu heben.
Hi, ich habe die Bücher "Embedded Linux Systems with Yocto Project" Rudolf J. Streif und "Embedded Linux Development Using Yocto Project Cookbook" von Alex González auf dem Schreibtisch liegen. Yocto ist schon nicht so ohne. Viel Erfolg! Daniel
Moin, Billiglohnland schrieb: > 1) Wie modifiziere ich Uboot so, dass es auf neuer Hardware läuft für > die es kein bereits fertiges Uboot gibt (DRAM-Initialisierung, > Flash-Initialisierung, serielle Konsole, Display Initialisierung)? Indem du die Infos aus dem Datenblatt deines neuen Prozessors und ueber den Aufbau deiner neuen Hardware sinnvoll in die uboot sourcen reinbaust...Sinnvollerweise faengst du mit einer HW an, die schon im uboot existiert und kuemmerst dich dann um die Unterschiede, die deine HW gegenueber der im uboot existierenden HW hat. > 2) Wie erstelle ich mit Buildroot / Yocto eine lightweight > Linux-Umgebung? Keine Ahnung, das ist eben jeweils spezifisch fuer's Buildsystem - ich bin kein grosser Fan von all diesen "ich mach dir alles klar mit einem Haufen scripten" und "hinten faellt ein Image-mit-alles-und-scharf raus"-Buildsystemen. Meine Erfahrung ist: Wenn nicht alles 100% genau so passt, wie der Buildsystementwickler es sich ausgedacht hat, dann bleibt der Kack irgendwo mit irgendeiner eigenartigen Meldung stecken und das wars dann erstmal. Dann verzettelt man sich im nachvollziehen was da wohl passiert sein koennte... Ich persoenlich bin eher ein Fan von LFS/BLFS und dem darin vermittelten Wissen, aus was fuer Brocken man sich ein GNU/Linux System selber zusammenstricken kann. > 3) Wie bekomme ich ein möglichst schnelles Entwicklungssystem (schnell > im Sinne von automatisiert) bei dem ich meine Anwendungen einfach auf > das Linux-System übertragen und ausführen ggf. debuggen kann (sofern ich > diese Cross-kompilieren muss / möchte)? Ich arbeite gerne mit einem NFS-Server auf dem EntwicklungsPC. Das Target kann dann per nfs mount auf Zeugs vom PC zugreifen; z.b. direkt frische auf dem PC crosscompilierte binaries ausfuehren. Dazu muss auf dem Target halt schonmal ein Kernel+Busybox laufen. Netzwerk kann auch nicht schaden. Ich hab' aber auch schon vor Jahren nfs mounts via serieller Schnittstelle (ppp auf beiden Seiten) so genutzt. Ist halt nix fuer eilige Zeitgenossen, aber deutlich besser als nix. Gruss WK
Stefan ⛄ F. schrieb: > Zumindest war es meine Absicht, genau > dieses besondere Merkmal hervor zu heben. Du hast es mit command.com verglichen, und das ist im Gegensatz zu busybox ja strohdumm. Das hat keine Befehle eingebaut, sondern kann nur externe Befehle aufrufen, denn es ist ja nur die 'Shell' von DOS gewesen. Das schöne bei busybox ist ja, das du z.B. auch eine Shell drin haben kannst und dazu alle Befehle, die man so braucht, auch die, um das FS im RAM zu bauen und die Struktur. (expand, mkdir, cp, etc.) Deswegen kann ein unvollständiges busybox durchaus verhindern, das so ein Embedded Linux richtig startet und ein lauffähiges System aufbaut. Ich habe das meiste damals durch den uCSimm und die mitgelieferte CD gelernt.
:
Bearbeitet durch User
Matthias S. schrieb: > Das hat keine Befehle eingebaut, sondern kann nur > externe Befehle aufrufen, denn es ist ja nur die 'Shell' von DOS > gewesen. Vielleicht irre ich mich, aber die command.com enthält nach meiner Erinnerung eine ganze Menge Befehle. "Die folgenden MS-DOS-Befehle sind in COMMAND integriert: Break Echo Rem Call Exit Rename (Ren) Chcp For Rmdir (Rd) Chdir (Cd) Goto Set Cls If Shift Copy Loadhigh (Lh) Time Ctty Mkdir (Md) Type Date Path Ver Del (Erase) Pause Verfiy Dir Prompt Vol" https://www.i8086.de/dos-befehle/command.html Ich hoffe, diese Liste stimmt.
Stefan ⛄ F. schrieb: > Vielleicht irre ich mich, aber die command.com enthält nach meiner > Erinnerung eine ganze Menge Befehle. Ja, DOS kennt interne und externe Befehle.
Ja, da hast du recht. Ist einfach zu lange her.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.