Buchempfehlung Buildroot / Yocto / Uboot / Busybox

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.

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

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.

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.