Häufig gestellte Fragen

Einen Überblick finden Sie in diesem Blogbeitrag: Die Leistungsfähigkeit des Yocto Project® nutzen: Ein umfassender Leitfaden zum Erstellen benutzerdefinierter Linux-Distributionen.
Für einen tieferen Einblick können Sie unseren Kurs buchen: Das Yocto Project® – Ein umfassender Überblick.

Für Unternehmen, die ihre Teams in Yocto schulen und so langfristig selbst Support leisten möchten, bietet Robert Berger umfassende Schulungen und Beratung an. Mit über 30 Jahren Erfahrung in Embedded Linux und Yocto können Teams so ausgestattet werden, dass sie Yocto-Projekte nachhaltig betreiben und weiterentwickeln können.
Für individuelle und professionelle Beratung zu Yocto in der Industrie empfehle ich, sich zunächst an Robert Berger (Reliable Embedded Systems) zu wenden, da hier Schulung und Beratung eng miteinander verzahnt sind und langjährige Erfahrung vorliegt.
Schauen Sie sich gerne unsere Kunden und deren Erfahrungsberichte an.

Siehe Antwort oben. Nach der Teilnahme an unseren Kursen erhalten Sie außerdem ein Zertifikat.

Wir bieten private und öffentliche Schulungsveranstaltungen vor Ort und online an.

Heutzutage bieten die meisten Anbieter Embedded OpenEmbedded/Yocto Project-kompatible Layer an. Fragen Sie uns gerne.

Das Yocto-Projekt führt die meisten seiner Tests und Builds mit QEMU durch. Solange Sie keine spezielle Hardware benötigen, um Ihre Sachen zu testen, sollte das in Ordnung sein.
Lesen Sie diesen Blogbeitrag: Der poky-Repository-Master-Zweig ist weg & qemux86-64 - whinlatter

Lesen Sie diesen Blog-Beitrag: Wie man Teil unserer Yocto Project® Gemeinschaft wird

Ich würde empfehlen, eine "stabile" Version Ihres Projekts zu erstellen, aber parallel dazu auch eine "Master"-Version.
Im Megahandbuch können Sie dies sehen. Es beschreibt allgemeine Migrationsüberlegungen und was sich von einer Version zur vorherigen geändert hat.

Quilt wird intern von Bitbake und Metadaten verwendet, um Patches anzuwenden. Wir werden es nicht direkt verwenden, aber ein Arbeitsablauf mit diesem Werkzeug ist hier beschrieben: https://docs.yoctoproject.org/dev/dev-manual/quilt.html. Ich ziehe es vor, git und stgit zu verwenden, je nachdem, was ich gerade tue. Quilt könnte nützlich sein, um Patches auf Verzeichnissen zu erstellen und anzuwenden, die nicht unter Versionskontrolle stehen.

Laut dem BitBake-Handbuch gibt die Variable PERSISTENT_DIR das Verzeichnis an, in dem BitBake Daten speichert, die zwischen den Builds erhalten bleiben sollen. Insbesondere handelt es sich bei den gespeicherten Daten um die Daten, die BitBakes persistente Daten-API verwenden, sowie um die Daten, die von PR Server und PR Service verwendet werden.

Kurz gesagt: nein.
Dieses Verzeichnis sollte nicht von verschiedenen Builds gemeinsam genutzt werden. Das Standardverzeichnis der Hash-Äquivalenz-Datenbank ist dieses Verzeichnis, wenn BB_HASHSERVE auf auto gesetzt ist. Wenn Sie die Hash-Äquivalenz-Datenbank zwischen Builds teilen müssen, geben Sie dieses Verzeichnis nicht frei, sondern lesen Sie im Yocto Project Development Tasks Manual nach, wie Sie den Hash-Äquivalenz-Server einrichten.

Das Yocto Mega Handbuch erklärt dies hier.
Kurz gesagt: IMAGE_FEATURES += "read-only-rootfs"

Jeder Versuch des Zielgeräts, während der Laufzeit in das Root-Dateisystem zu schreiben, schlägt fehl. Daher müssen Sie sicherstellen, dass Sie Prozesse und Anwendungen, die diese Art von Schreibzugriff versuchen, nur auf Verzeichnisse mit Schreibzugriff zugreifen lassen (z. B, /tmp oder /var/run). Ein Overlay-Dateisystem könnte auch eine gute Idee sein, z. B. für /etc.

1) unterschiedliche Distributionen - Release vs. Bleeding Edge (nächtlicher Integrations-Build, z.B. poky vs. poky-bleeding)
Die Yocto-Referenzimplementierung unterscheidet zwischen der poky-Distro und der poky-bleeding-Distro. poky.conf ist die stabile Version, in der nur feste Commid-Ids verwendet werden (SRCREV). poky-bleeding.conf enthält andererseits eine Datei namens poky-floating-revisions.inc. Mit dieser Variable werden verschiedene Repositories in "schwebenden" Versionen herangezogen: POKY_AUTOREV_RECIPES über AUTOREV.

2) unterschiedliche Rezepte - stabil vs. Entwicklung ( DEFAULT_PREFERENCE = "1" )
Mit einer guten alten Yocto-Version (morty) haben wir zwei Rezepte für busybox. Nämlich busybox_1.24.1.bb und busybox_git.bb. busybox_git enthält PV = "1.25.0+git${SRCPV}" was bedeutet, dass es eine größere Version als 1.24.1 ist. Aber busybox_git enthält auch DEFAULT_PREFERENCE = "-1". Siehe DEFAULT_PREFERENCE. Das bedeutet: BitBake wählt nicht busybox_git, sondern busybox_1.42.1.bb. Das ist der Mechanismus, der verwendet werden kann, wenn Sie an einer neuen Version arbeiten und nicht wollen, dass andere Benutzer standardmäßig die Entwicklungsversion Ihres Rezepts verwenden. Nur bei PREFERRED_VERSION_busybox = "1.25.0%" in einer Konfigurationsdatei, wird die Entwicklungsversion von BitBake anstelle der stabilen Version verwendet.

3) unterschiedliche Rezepte - stabil vs. aktuell (devupstream.bbclass)
Im Mega-Handbuch steht: Die devupstream Klasse verwendet BBCLASSEXTEND um eine Variante des Rezepts hinzuzufügen, die von einer alternativen URI (z. B. Git) anstelle eines Tarballs abruft. Ein vollständig ausgearbeitetes Beispiel ist simple-hello-world-git-devupstream_git.bb.

Ja.

1) Sie müssen buildhistory in einer conf-Datei aktivieren.

INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"

2) Führen Sie im Build-Verzeichnis Folgendes aus buildhistory-collect-srcrevs

tree -L 1
.
├── bitbake-cookerdaemon.log
├── bitbake.lock
├── buildhistory
├── Cache
├── conf
├── init-build-env
├── README
└── tmp

$ buildhistory-collect-srcrevs

dies zeigt:

#phyboard_pollux_imx8mp_3-phytec-linux
SRCREV_machine:pn-linux-yocto-dev = “b8892e24935e21dc9257f1beabceb88aaa6f7ce8”
SRCREV_meta:pn-linux-yocto-dev = “1f7e5229027dcd871f872478f5cbc8047626cac3”
SRCREV:pn-u-boot-master = “2bc0715b558fa1ac5c88b11e250740b16a905837”

Anmerkung: buildhistory-collect-srcrevs -a zeigt alle SRCREV und nicht nur diejenigen mit AUTOREV.

Das ist nicht ohne Weiteres möglich, denn aufgrund der AUTOREV: Bitbake muss zum Upstream-Repository gehen und den letzten Commit des von Ihnen definierten Zweigs ziehen und BB_NO_NETWORK = "1" wird es nicht zulassen. Aber Sie können etwas wie dies versuchen:

1) Baugeschichte + buildhistory-collect-srcrevs
Siehe oben, wie man alle Daten extrahiert SRCREV / AUTOREV. Schreiben Sie sie in eine .inc-Datei, die Sie z. B. in Ihre Distro-Konfiguration aufnehmen.

2) BB_SRCREV_POLICY
Einstellung BB_SRCREV_POLICY = "cache" in Ihrer Konfiguration. Dabei wird die letzte zwischengespeicherte Revision verwendet. (Der Nachteil dieser Methode ist, dass es etwas schwieriger ist, die festgelegten Revisionen zu erhalten oder mit anderen zu teilen).

Beachten Sie, dass Sie in beiden Fällen, wenn Sie später die neueste Version erneut erstellen möchten, müssen Sie natürlich die Konfigurationsänderungen rückgängig machen.

The only thing I could imagine is, that the update-alternatives class is involved. This means both binaries are installed, but only one is used via a symlink. That’s a standard Linux mechanism and you can read more about it in the man page update-alternatives(1).

1) Use buildhistory to find out what’s in the image
cd <whatever>/buildhistory/images/multi_v7_ml/glibc
grep -r ‘/bin/ls ‘ .
./core-image-sato-sdk/files-in-image.txt:lrwxrwxrwx root root 17 ./bin/ls -> /bin/ls.coreutils
./core-image-minimal/files-in-image.txt:lrwxrwxrwx root root 19 ./bin/ls -> /bin/busybox.nosuid

grep -r ‘/bin/df ‘ .
./core-image-sato-sdk/files-in-image.txt:lrwxrwxrwx root root 21 ./bin/df -> /usr/bin/df.coreutils
./core-image-minimal/files-in-image.txt:lrwxrwxrwx root root 19 ./bin/df -> /bin/busybox.nosuid

2) update-alternatives
inherit update-alternatives
ALTERNATIVE_PRIORITY = “100”
ALTERNATIVE:${PN} = “…df”
ALTERNATIVE:${PN}-doc = “…df.1”
…
ALTERNATIVE_LINK_NAME[df] = “${base_bindir}/df”
ALTERNATIVE_TARGET[df] = “${bindir}/df.${BPN}”
ALTERNATIVE_LINK_NAME[df.1] = “${mandir}/man1/df.1”
…

A fully worked example is here.

Sie könnten eine Klasse dafür schreiben. Vielleicht so etwas wie diese oder Sie könnten die Klasse insane erweitern.

Sie erstellen ein neues Kernel-Rezept.

1) Kernel vs. gcc
Mit unterschiedlichen Poky-Versionen erhält man typischerweise auch unterschiedliche gcc-Versionen. Patches können notwendig sein, damit ein alter Kernel mit einem neuen gcc kompiliert werden kann und umgekehrt.

2) Code, der mit Kernel-Quellen geliefert wird
Perf ist ein Werkzeug, das mit Kernel-Quellen geliefert wird, und Sie möchten vielleicht auch sein Rezept entsprechend aktualisieren, ebenso wie andere Rezepte, die aufgrund von Kernel-Quellabhängigkeiten brechen.

3) Unterstützte Kernel-Versionen
bitbake -e | grep ^OLDEST_KERNEL=
OLDEST_KERNEL="5.15″

Die Klasse kernel-devicetree, die von der Klasse kernel geerbt wird, unterstützt die Erzeugung eines Gerätebaums aus den Quelldateien des Gerätebaums, die Teil des Kernelbaums sind. Sie wird verwendet, um "stabile" Gerätebäume zusammen mit dem Kernel zu erstellen.
Wenn Sie nur den Gerätebaum erstellen wollen, ohne den Kernel zu erstellen, um einen neuen Gerätebaum zu erhalten, sollten Sie die devicetree-Klasse verwenden. Die devicetree-Klasse erlaubt es, ein Rezept zu erstellen, das Quelldateien des Gerätebaums kompiliert, die nicht im Kernel-Tree enthalten sind.

Beginnen Sie hier.

Memory Overcommit ist die Entscheidung, mehr Speicher zuzuweisen, als physisch verfügbar ist, und Swap ist die Technologie, die diese Entscheidung ohne sofortigen Systemausfall ermöglicht, wenn auch auf Kosten der Leistung. Siehe Overcommit Accounting.

Die Speicherüberbindung ohne Swap kann in erster Linie verwendet werden, um die Reaktionsfähigkeit des Systems bei starkem Speicherdruck zu verbessern und Leistungseinbußen durch langsame Festplatten-E/A zu verhindern, wenn Swapping stattfindet. Diese Konfiguration ändert das Verhalten, wenn dem System der physische Arbeitsspeicher ausgeht: Anstatt durch Swapping langsamer zu werden, ruft das System sofort den Out-Of-Memory (OOM)-Killer auf, um einen Prozess zu beenden. Auch um "Thrashing" und Leistungseinbußen zu vermeiden. Für ein vorhersehbares Verhalten in Speichererschöpfungsszenarien (OOM-Killer anstelle eines langsamen, schleifenden Systems). Als Optimierung für bestimmte Arbeitslasten wie spärliche Arrays. Für eine bessere Anwendungsstabilität durch die Deaktivierung von Swap und die Festlegung spezifischer Speichergrenzen, die einen sofortigen Ausfall der Speicherzuweisung verursachen (ENOMEM) und den Fehler elegant behandeln (z.B. die aktuelle Transaktion stoppen), anstatt abrupt vom OOM-Killer beendet zu werden.

Vorausgesetzt, U-Boot bootet, können Sie dies an der U-Boot-Eingabeaufforderung tun:

32 it ARM:

=> bdinfo
boot_params = 0x10000100
DRAM-Bank = 0x00000000
-> Start = 0x10000000
-> Größe = 0x40000000
Blitzstart = 0x00000000
flashsize = 0x00000000
flashoffset = 0x00000000
Baudrate = 115200 bps
relocaddr = 0x4ff5c000
verlagern = 0x3875c000
Aufbau = 32-Bit
aktuell eth = ethernet@2188000
ethaddr = 50:2d:f4:09:cf:54
IP-Adresse = 192.168.42.126
fdt_blob = 0x4f750980
lmb_dump_all:
memory.count = 0x1
memory[0] [0x10000000-0x4fffffff], 0x40000000 bytes, Flags: keine
reserved.count = 0x2
reserved[0] [0x4e74d000-0x4e74ffff], 0x3000 Bytes, Flags: no-notify, no-overwrite
reserved[1] [0x4e750960-0x4fffffff], 0x18af6a0 bytes, Flags: no-overwrite
Gerätestamm = getrennt
arch_number = 0x00000000
TLB-Adresse = 0x4fff0000
irq_sp = 0x4f750970
sp start = 0x4f750960
Frühe Verwendung von malloc: 650 / 2000

64 Bit ARM:

u-boot=> bdinfo
boot_params = 0x00000000000000000000
DRAM-Bank = 0x00000000000000000000
-> Start = 0x0000000040000000
-> Größe = 0x000000003e000000
DRAM-Bank = 0x0000000000000001
-> Start = 0x0000000080000000
-> Größe = 0x0000000040000000
flashstart = 0x00000000000000000000
flashsize = 0x00000000000000000000
flashoffset = 0x00000000000000000000
Baudrate = 115200 bps
relocaddr = 0x000000007decf000
verlagern = 0x000000003dccf000
Aufbau = 64-Bit
aktuell eth = ethernet@30be0000
ethaddr = 50:2d:f4:3a:4e:18
IP-Adresse =
fdt_blob = 0x000000007bebbc20
lmb_dump_all:
memory.count = 0x2
memory[0] [0x40000000-0x7dffffff], 0x3e000000 bytes, Flags: keine
memory[1] [0x80000000-0xbfffffff], 0x40000000 Bytes, Flags: keine
reserved.count = 0x3
reserved[0] [0x7aeb2000-0x7aebafff], 0x9000 bytes, Flags: no-notify, no-overwrite
reserved[1] [0x7aebbc10-0x7dffffff], 0x31443f0 bytes, Flags: no-overwrite
reserved[2] [0x80000000-0xbfffffff], 0x40000000 Bytes, Flags: no-overwrite
Gerätestamm = getrennt
arch_number = 0x00000000000000000000
TLB-Addresse = 0x000000007dfe0000
irq_sp = 0x000000007bebbc10
sp start = 0x000000007bebbc10
Frühzeitige Verwendung von malloc: d8d0 / 10000

Suchen Sie im obigen Beispiel nach relocaddr und reloc off. Sie müssen Ihre Symbole in gdb entsprechend anpassen.