Linux wird auf einer viel breiteren Palette von Geräten eingesetzt, als Linus Torvalds erwartet hatte, als er in seinem Schlafsaal daran arbeitete. Die Vielfalt der unterstützten Chiparchitekturen ist erstaunlich und hat zu Linux in großen und kleinen Geräten geführt; von riesigen IBM-Mainframes bis hin zu winzigen Geräten, die nicht größer als ihre Anschlussports sind, und alles dazwischen. Es wird in großen Unternehmensrechenzentren, Internetinfrastrukturgeräten und persönlichen Entwicklungssystemen verwendet. Es versorgt auch Unterhaltungselektronik, Mobiltelefone und viele Internet-of-Things-Geräte mit Strom.
Beim Erstellen von Linux-Software für Desktop- und Unternehmensgeräte verwenden Entwickler normalerweise eine Desktop-Distribution wie Ubuntu auf ihren Build-Maschinen, um eine Umgebung zu haben, die der Umgebung, in der die Software bereitgestellt wird, so ähnlich wie möglich ist. Tools wie VirtualBox und Docker ermöglichen eine noch bessere Abstimmung zwischen Entwicklungs-, Test- und Produktionsumgebungen.
Was ist ein eingebettetes System?
Wikipedia definiert ein eingebettetes System als:"Ein Computersystem mit einer dedizierten Funktion innerhalb eines größeren mechanischen oder elektrischen Systems, oft mit Echtzeit-Computing-Einschränkungen."
Ich finde es einfach genug zu sagen, dass ein eingebettetes System ein Computer ist, den die meisten Menschen nicht als Computer betrachten. Seine Hauptaufgabe besteht darin, als eine Art Appliance zu dienen, und es wird nicht als Allzweck-Computing-Plattform betrachtet.
Weitere Linux-Ressourcen
- Spickzettel für Linux-Befehle
- Spickzettel für fortgeschrittene Linux-Befehle
- Kostenloser Online-Kurs:RHEL Technical Overview
- Spickzettel für Linux-Netzwerke
- SELinux-Spickzettel
- Spickzettel für allgemeine Linux-Befehle
- Was sind Linux-Container?
- Unsere neuesten Linux-Artikel
Die Entwicklungsumgebung bei der Programmierung eingebetteter Systeme unterscheidet sich normalerweise stark von den Test- und Produktionsumgebungen. Sie können unterschiedliche Chiparchitekturen, Software-Stacks und sogar Betriebssysteme verwenden. Entwicklungsworkflows sind für Embedded-Entwickler ganz anders als für Desktop- und Web-Entwickler. Typischerweise besteht die Build-Ausgabe aus einem vollständigen Software-Image für das Zielgerät, einschließlich Kernel, Gerätetreibern, Bibliotheken und Anwendungssoftware (und manchmal dem Bootloader).
In diesem Artikel werde ich einen Überblick über vier allgemein verfügbare Optionen zum Erstellen von eingebetteten Linux-Systemen geben. Ich werde einen Vorgeschmack darauf geben, wie es ist, mit jedem zu arbeiten, und genügend Informationen bereitstellen, um den Lesern bei der Entscheidung zu helfen, welches Tool sie für ihr Design verwenden möchten. Ich werde Ihnen nicht beibringen, wie man sie benutzt; Es gibt viele ausführliche Online-Lernressourcen, sobald Sie Ihre Auswahl eingegrenzt haben. Keine Option ist für alle Anwendungsfälle geeignet, und ich hoffe, Ihnen genügend Details präsentieren zu können, um Ihre Entscheidung zu lenken.
Yokto
Das Yocto-Projekt ist definiert als „ein Open-Source-Kooperationsprojekt, das Vorlagen, Tools und Methoden bereitstellt, um Sie bei der Erstellung benutzerdefinierter Linux-basierter Systeme für eingebettete Produkte unabhängig von der Hardwarearchitektur zu unterstützen.“ Es ist eine Sammlung von Rezepten, Konfigurationswerten und Abhängigkeiten, die verwendet werden, um ein benutzerdefiniertes Linux-Laufzeitabbild zu erstellen, das auf Ihre spezifischen Anforderungen zugeschnitten ist.
Vollständige Offenlegung:Der größte Teil meiner Arbeit mit eingebettetem Linux konzentrierte sich auf das Yocto-Projekt, und mein Wissen und meine Neigung zu diesem System werden wahrscheinlich offensichtlich sein.
Yocto verwendet Openembedded als Build-System. Technisch gesehen sind die beiden getrennte Projekte; In der Praxis müssen Benutzer die Unterscheidung jedoch nicht verstehen, und die Projektnamen werden häufig synonym verwendet.
Die Ausgabe eines Yocto-Projektbuilds besteht grob aus drei Komponenten:
- Ziellaufzeit-Binärdateien: Dazu gehören Bootloader, Kernel, Kernel-Module, Root-Dateisystem-Image. und alle anderen Hilfsdateien, die zum Bereitstellen von Linux auf der Zielplattform benötigt werden.
- Paket-Feed: Dies ist die Sammlung von Softwarepaketen, die zur Installation auf Ihrem Zielgerät verfügbar sind. Sie können das Paketformat (z. B. deb, rpm, ipk) basierend auf Ihren Anforderungen auswählen. Einige von ihnen können in den Binärdateien der Ziellaufzeit vorinstalliert sein, es ist jedoch möglich, Pakete für die Installation in einem bereitgestellten System zu erstellen.
- Ziel-SDK: Dies ist die Sammlung von Bibliotheken und Header-Dateien, die die auf Ihrem Zielgerät installierte Software darstellen. Sie werden von Anwendungsentwicklern beim Erstellen ihres Codes verwendet, um sicherzustellen, dass sie mit den entsprechenden Bibliotheken verknüpft sind
Vorteile
Das Yocto-Projekt ist in der Branche weit verbreitet und wird von vielen einflussreichen Unternehmen unterstützt. Darüber hinaus hat es eine große und lebendige Entwickler-Community und ein Ökosystem, die dazu beitragen. Die Kombination aus Open-Source-Enthusiasten und Unternehmenssponsoren trägt zum Vorantreiben des Yocto-Projekts bei.
Es gibt viele Möglichkeiten, Support bei Yocto zu erhalten. Es gibt Bücher und andere Schulungsmaterialien, wenn Sie es selbst tun möchten. Viele Ingenieure mit Erfahrung in Yocto stehen zur Verfügung, wenn Sie Fachwissen einstellen möchten. Und viele kommerzielle Organisationen bieten schlüsselfertige Yocto-basierte Produkte oder dienstbasierte Implementierung und Anpassung für Ihr Design an.
Das Yocto-Projekt lässt sich einfach durch Ebenen erweitern, die unabhängig voneinander veröffentlicht werden können, um zusätzliche Funktionen hinzuzufügen, auf Zielplattformen, die in den Projektversionen nicht verfügbar sind, oder um individuelle Anpassungen für Ihr System zu speichern. Ebenen können zu Ihrer Konfiguration hinzugefügt werden, um einzigartige Funktionen hinzuzufügen, die nicht ausdrücklich in den Lagerfreigaben enthalten sind; Beispielsweise enthält die „Meta-Browser“-Schicht Rezepte für Webbrowser, die einfach für Ihr System erstellt werden können. Da sie unabhängig verwaltet werden, können Layer einen anderen Release-Zeitplan haben (abgestimmt auf die Entwicklungsgeschwindigkeit der Layer) als die Standard-Yocto-Releases.
Yocto hat wohl die breiteste Geräteunterstützung aller in diesem Artikel besprochenen Optionen. Aufgrund der Unterstützung vieler Halbleiter- und Platinenhersteller wird Yocto wahrscheinlich jede von Ihnen gewählte Zielplattform unterstützen. Die direkten Yocto-Releases unterstützen nur wenige Boards (um ordnungsgemäße Test- und Release-Zyklen zu ermöglichen), ein Standardarbeitsmodell besteht jedoch darin, externe Board-Support-Layer zu verwenden.
Schließlich ist Yocto extrem flexibel und anpassbar. Anpassungen für Ihre spezifische Anwendung können in einer Schicht zur Kapselung und Isolierung gespeichert werden. Anpassungen, die nur für einen Feature-Layer gelten, werden im Allgemeinen als Teil des Layers selbst gespeichert, sodass dieselben Einstellungen gleichzeitig auf mehrere Systemkonfigurationen angewendet werden können. Yocto bietet auch eine klar definierte Ebenenpriorität und Überschreibungsfunktion. Dadurch können Sie die Reihenfolge definieren, in der Ebenen angewendet und nach Metadaten durchsucht werden. Es ermöglicht Ihnen auch, Einstellungen in Layern mit höherer Priorität zu überschreiben; Beispielsweise werden viele Anpassungen an bestehenden Rezepten in Ihren privaten Ebenen hinzugefügt, wobei die Reihenfolge genau durch die Prioritäten gesteuert wird.
Nachteile
Der größte Nachteil beim Yocto-Projekt ist die Lernkurve. Es erfordert viel Zeit und Mühe, das System zu erlernen und wirklich zu verstehen. Abhängig von Ihren Anforderungen kann dies eine zu große Investition in Technologien und Kompetenzen sein, die für Ihre Anwendung nicht zentral sind. In solchen Fällen kann die Zusammenarbeit mit einem der kommerziellen Anbieter eine gute Option sein.
Die Build-Zeiten und -Ressourcen für die Entwicklung sind für Yocto-Projekt-Builds ziemlich hoch. Die Anzahl der Pakete, die erstellt werden müssen, einschließlich der Toolchain, des Kernels und aller Laufzeitkomponenten des Ziels, ist erheblich. Entwicklungsarbeitsplätze für Yocto-Entwickler sind in der Regel große Systeme. Die Verwendung eines kompakten Notebooks wird nicht empfohlen. Dies kann durch die Verwendung von Cloud-basierten Build-Servern gemildert werden, die von vielen Anbietern erhältlich sind. Darüber hinaus verfügt Yocto über einen integrierten Caching-Mechanismus, der es ermöglicht, zuvor erstellte Komponenten wiederzuverwenden, wenn festgestellt wird, dass sich die Parameter zum Erstellen eines bestimmten Pakets nicht geändert haben.
Empfehlung
Die Verwendung des Yocto-Projekts für Ihr nächstes Embedded-Linux-Design ist eine gute Wahl. Von den hier vorgestellten Optionen ist dies die am weitesten verbreitete, unabhängig von Ihrem Zielanwendungsfall. Die breite Branchenunterstützung, die aktive Community und die breite Plattformunterstützung machen dies zu einer guten Wahl für Must-Designer.
Buildroot
Das Buildroot-Projekt wird als „ein einfaches, effizientes und benutzerfreundliches Tool zum Generieren eingebetteter Linux-Systeme durch Cross-Compilation“ definiert. Es hat viele der gleichen Ziele wie das Yocto-Projekt, konzentriert sich jedoch auf Einfachheit und Minimalismus. Im Allgemeinen deaktiviert Buildroot alle optionalen Einstellungen zur Kompilierzeit für alle Pakete (mit einigen bemerkenswerten Ausnahmen), was zu einem möglichst kleinen System führt. Es obliegt dem Systemdesigner, die Einstellungen zu aktivieren, die für ein bestimmtes Gerät geeignet sind.
Buildroot erstellt alle Komponenten aus der Quelle, unterstützt jedoch keine zielgerichtete Paketverwaltung. Daher wird es manchmal als Firmware-Generator bezeichnet, da die Images zum Zeitpunkt des Erstellens weitgehend festgelegt werden. Anwendungen können das Zieldateisystem aktualisieren, aber es gibt keinen Mechanismus, um neue Pakete in einem laufenden System zu installieren.
Die Buildroot-Ausgabe besteht grob aus drei Komponenten:
- Das Root-Dateisystem-Image und alle anderen Hilfsdateien, die zum Bereitstellen von Linux auf der Zielplattform benötigt werden
- Kernel, Bootloader und Kernelmodule, die für die Zielhardware geeignet sind
- Die Toolchain, die zum Erstellen aller Zielbinärdateien verwendet wird.
Vorteile
Der Fokus von Buildroot auf Einfachheit bedeutet, dass es im Allgemeinen einfacher zu erlernen ist als Yocto. Das Core-Build-System ist in Make geschrieben und kurz genug, um es einem Entwickler zu ermöglichen, das gesamte System zu verstehen, während es erweiterbar genug ist, um die Anforderungen von Embedded-Linux-Entwicklern zu erfüllen. Der Buildroot-Kern behandelt im Allgemeinen nur allgemeine Anwendungsfälle, ist aber per Skript erweiterbar.
Das Buildroot-System verwendet normale Makefiles und die Kconfig-Sprache für seine Konfiguration. Kconfig wurde von der Linux-Kernel-Community entwickelt und wird häufig in Open-Source-Projekten verwendet, wodurch es vielen Entwicklern vertraut ist.
Aufgrund des Designziels, alle optionalen Build-Time-Einstellungen zu deaktivieren, erstellt Buildroot im Allgemeinen die kleinstmöglichen Images mit der Standardkonfiguration. Die Build-Zeiten und Build-Host-Ressourcen werden im Allgemeinen ebenfalls kleiner sein als die des Yocto-Projekts.
Nachteile
Der Fokus auf Einfachheit und minimal aktivierte Build-Optionen impliziert, dass Sie möglicherweise erhebliche Anpassungen vornehmen müssen, um einen Buildroot-Build für Ihre Anwendung zu konfigurieren. Darüber hinaus werden alle Konfigurationsoptionen in einer einzigen Datei gespeichert, was bedeutet, dass Sie bei mehreren Hardwareplattformen jede Ihrer Anpassungsänderungen für jede Plattform vornehmen müssen.
Jede Änderung an der Systemkonfigurationsdatei erfordert eine vollständige Neuerstellung aller Pakete. Dies wird durch die minimalen Bildgrößen und Build-Zeiten im Vergleich zu Yocto etwas gemildert, kann aber zu langen Builds führen, während Sie Ihre Konfiguration optimieren.
Das Zwischenspeichern des Paketstatus ist standardmäßig nicht aktiviert und nicht so gründlich wie die Yocto-Implementierung. Das bedeutet, dass der erste Build zwar kürzer sein kann als ein äquivalenter Yocto-Build, nachfolgende Builds jedoch die Neuerstellung vieler Komponenten erfordern können.
Empfehlung
Die Verwendung von Buildroot für Ihr nächstes Embedded-Linux-Design ist für die meisten Anwendungen eine gute Wahl. Wenn Ihr Design mehrere Hardwaretypen oder andere Unterschiede erfordert, sollten Sie es aufgrund der Komplexität der Synchronisierung mehrerer Konfigurationen vielleicht noch einmal überdenken, aber für ein System, das aus einem einzigen Setup besteht, wird Buildroot wahrscheinlich gut für Sie funktionieren.
OpenWRT/LEDE
Das OpenWRT-Projekt wurde gestartet, um benutzerdefinierte Firmware für Consumer-Router zu entwickeln. Viele der kostengünstigen Router, die bei Ihrem örtlichen Händler erhältlich sind, können ein Linux-System ausführen, sind aber möglicherweise nicht sofort einsatzbereit. Die Hersteller dieser Router stellen möglicherweise keine häufigen Updates zur Abwehr neuer Bedrohungen bereit, und selbst wenn dies der Fall ist, sind die Mechanismen zum Installieren aktualisierter Images schwierig und fehleranfällig. Das OpenWRT-Projekt erstellt aktualisierte Firmware-Images für viele Geräte, die von ihren Herstellern aufgegeben wurden, und haucht diesen Geräten neues Leben ein.
Die primären Ergebnisse des OpenWRT-Projekts sind binäre Images für eine große Anzahl kommerzieller Geräte. Es gibt über das Netzwerk zugängliche Paket-Repositories, die es Endbenutzern von Geräten ermöglichen, neue Software zu ihren Systemen hinzuzufügen. Das OpenWRT-Build-System ist ein Allzweck-Build-System, das es Entwicklern ermöglicht, benutzerdefinierte Versionen zu erstellen, um ihre eigenen Anforderungen zu erfüllen und neue Pakete hinzuzufügen, aber sein Hauptaugenmerk liegt auf Ziel-Binärdateien.
Vorteile
Wenn Sie nach Ersatz-Firmware für ein kommerzielles Gerät suchen, sollte OpenWRT auf Ihrer Liste der Optionen stehen. Es ist gut gewartet und kann Sie vor Problemen schützen, die die Firmware des Herstellers nicht kann. Sie können auch zusätzliche Funktionen hinzufügen, um Ihre Geräte nützlicher zu machen.
Wenn Ihr eingebettetes Design netzwerkorientiert ist, ist OpenWRT eine gute Wahl. Netzwerkanwendungen sind der primäre Anwendungsfall für OpenWRT, und Sie werden wahrscheinlich viele dieser Softwarepakete darin finden.
Nachteile
OpenWRT erlegt Ihrem Design wichtige Richtlinienentscheidungen auf (im Vergleich zu Yocto und Buildroot). Wenn diese Entscheidungen nicht Ihren Designzielen entsprechen, müssen Sie möglicherweise nicht triviale Änderungen vornehmen.
Das Zulassen paketbasierter Updates in einer Flotte bereitgestellter Geräte ist schwierig zu verwalten. Dies führt per Definition zu einer anderen Softwarelast als die, die Ihr QA-Team getestet hat. Darüber hinaus ist es schwierig, atomare Installationen mit den meisten Paketmanagern zu garantieren, und ein unpassender Zeitpunkt des Ein- und Ausschaltens kann Ihr Gerät in einen unvorhersehbaren Zustand versetzen.
Empfehlung
OpenWRT ist eine gute Wahl für Bastlerprojekte oder für die Wiederverwendung kommerzieller Hardware. Es ist auch eine gute Wahl für Netzwerkanwendungen. Wenn Sie eine erhebliche Anpassung der Standardkonfiguration benötigen, bevorzugen Sie möglicherweise Buildroot oder Yocto.
Desktop-Distributionen
Ein gängiger Ansatz zum Entwerfen von eingebetteten Linux-Systemen besteht darin, mit einer Desktop-Distribution wie Debian oder Red Hat zu beginnen und nicht benötigte Komponenten zu entfernen, bis das installierte Image in den Fußabdruck Ihres Zielgeräts passt. Dies ist der Ansatz für die beliebte Raspbian-Distribution für die Raspberry Pi-Plattform.
Vorteile
Der Hauptvorteil dieses Ansatzes ist die Vertrautheit. Häufig sind Embedded-Linux-Entwickler auch Desktop-Linux-Benutzer und mit der Distribution ihrer Wahl bestens vertraut. Die Verwendung einer ähnlichen Umgebung auf dem Ziel kann es Entwicklern ermöglichen, schneller loszulegen. Abhängig von der gewählten Distribution können viele zusätzliche Tools mit Standard-Packaging-Tools wie apt und yum installiert werden.
Möglicherweise können Sie ein Display und eine Tastatur an Ihr Zielgerät anschließen und Ihre gesamte Entwicklung direkt dort durchführen. Für Entwickler, die neu im Embedded-Bereich sind, ist dies wahrscheinlich eine vertrautere Umgebung und beseitigt die Notwendigkeit, ein kniffliges entwicklungsübergreifendes Setup zu konfigurieren und zu verwenden.
Die Anzahl der für die meisten Desktop-Distributionen verfügbaren Pakete ist im Allgemeinen größer als die für die zuvor besprochenen embedded-spezifischen Builder. Aufgrund der größeren Benutzerbasis und der größeren Vielfalt an Anwendungsfällen finden Sie möglicherweise alle Runtime-Pakete, die Sie für Ihre Anwendung benötigen, bereits erstellt und einsatzbereit.
Nachteile
Die Verwendung des Ziels als primäre Entwicklungsumgebung ist wahrscheinlich langsam. Das Ausführen von Compiler-Tools ist ein ressourcenintensiver Vorgang und kann, je nachdem, wie viel Code Sie erstellen, Ihre Leistung beeinträchtigen.
Mit einigen Ausnahmen sind Desktop-Distributionen nicht für Systeme mit geringen Ressourcen ausgelegt, und es kann schwierig sein, Ihre Zielimages angemessen zuzuschneiden. Ebenso ist der erwartete Arbeitsablauf in einer Desktop-Umgebung für die meisten eingebetteten Designs nicht ideal. Auf diese Weise eine reproduzierbare Umgebung zu erhalten, ist schwierig. Das manuelle Hinzufügen und Löschen von Paketen ist fehleranfällig. Dies kann mithilfe von Distributions-spezifischen Tools, wie z. B. debootstrap für Debian-basierte Systeme, per Skript ausgeführt werden. Um die Reproduzierbarkeit weiter zu verbessern, können Sie ein Konfigurationsverwaltungstool wie CFEngine verwenden (das, vollständige Offenlegung, von meinem Arbeitgeber Mender.io erstellt wird). Sie sind jedoch immer noch der Gnade des Distributionsanbieters ausgeliefert, der Pakete aktualisiert, um seine Bedürfnisse zu erfüllen, nicht Ihre.
Empfehlung
Seien Sie vorsichtig mit diesem Ansatz für ein Produkt, das Sie auf den Markt bringen möchten. Dies ist ein feines Modell für Bastleranwendungen; Bei Produkten, die Unterstützung benötigen, wird dieser Ansatz jedoch wahrscheinlich Probleme bereiten. Auch wenn Sie vielleicht schneller starten können, kann es Sie auf lange Sicht Zeit und Mühe kosten.
Weitere Überlegungen
Diese Diskussion hat sich auf die Funktionalität von Build-Systemen konzentriert, aber normalerweise gibt es nicht funktionale Anforderungen, die Ihre Entscheidung beeinflussen können. Wenn Sie Ihr System-on-Chip (SoC) oder Board bereits ausgewählt haben, wird Ihre Wahl wahrscheinlich vom Anbieter vorgegeben. Wenn Ihr Anbieter ein Board Support Package (BSP) für ein bestimmtes System bereitstellt, spart die Verwendung normalerweise einiges an Zeit, aber prüfen Sie bitte die Qualität des BSP, um Probleme später in Ihrem Entwicklungszyklus zu vermeiden.
Wenn Ihr Budget es zulässt, sollten Sie einen kommerziellen Anbieter für Ihr Zielbetriebssystem in Betracht ziehen. Es gibt Unternehmen, die eine validierte und unterstützte Konfiguration vieler der hier besprochenen Optionen anbieten, und wenn Sie keine Erfahrung mit eingebetteten Linux-Build-Systemen haben, ist dies eine gute Wahl und ermöglicht es Ihnen, sich auf Ihre Kernkompetenz zu konzentrieren.
Alternativ können Sie eine kaufmännische Ausbildung für Ihre Entwicklungsmitarbeiter in Betracht ziehen. Dies ist wahrscheinlich billiger als ein kommerzieller Betriebssystemanbieter und ermöglicht es Ihnen, unabhängiger zu sein. Dies ist ein schneller Weg, um die Lernkurve für die Grundlagen des von Ihnen gewählten Build-Systems zu überwinden.
Schließlich haben Sie möglicherweise bereits einige Entwickler mit Erfahrung mit einem oder mehreren der Systeme. Wenn Sie Ingenieure haben, die eine Präferenz haben, lohnt es sich, dies bei Ihrer Entscheidung zu berücksichtigen.
Zusammenfassung
Es gibt viele Möglichkeiten, eingebettete Linux-Systeme zu erstellen, jede mit Vor- und Nachteilen. Es ist wichtig, diesen Teil Ihres Designs zu priorisieren, da es extrem kostspielig ist, das System später im Prozess zu wechseln. Neben diesen Optionen werden laufend neue Systeme entwickelt. Hoffentlich bietet diese Diskussion etwas Kontext für die Überprüfung neuer Systeme (und der hier erwähnten) und hilft Ihnen, eine solide Entscheidung für Ihr nächstes Projekt zu treffen.