Linux est déployé sur une gamme d'appareils beaucoup plus large que ne l'avait prévu Linus Torvalds lorsqu'il y travaillait dans son dortoir. La variété des architectures de puces prises en charge est stupéfiante et a conduit à Linux dans des appareils petits et grands; des énormes mainframes IBM aux minuscules appareils pas plus gros que leurs ports de connexion et tout le reste. Il est utilisé dans les centres de données des grandes entreprises, les dispositifs d'infrastructure Internet et les systèmes de développement personnel. Il alimente également les appareils électroniques grand public, les téléphones portables et de nombreux appareils de l'Internet des objets.
Lors de la création de logiciels Linux pour les ordinateurs de bureau et les appareils de classe entreprise, les développeurs utilisent généralement une distribution de bureau telle qu'Ubuntu sur leurs machines de construction pour avoir un environnement aussi proche que possible de celui où le logiciel sera déployé. Des outils tels que VirtualBox et Docker permettent un meilleur alignement entre les environnements de développement, de test et de production.
Qu'est-ce qu'un système embarqué ?
Wikipédia définit un système embarqué comme :"un système informatique doté d'une fonction dédiée au sein d'un système mécanique ou électrique plus vaste, souvent avec des contraintes de calcul en temps réel."
Je trouve assez simple de dire qu'un système embarqué est un ordinateur que la plupart des gens ne considèrent pas comme un ordinateur. Son rôle principal est de servir d'appareil en quelque sorte, et il n'est pas considéré comme une plate-forme informatique à usage général.
Plus de ressources Linux
- Aide-mémoire des commandes Linux
- Aide-mémoire des commandes Linux avancées
- Cours en ligne gratuit :Présentation technique de RHEL
- Aide-mémoire sur le réseau Linux
- Aide-mémoire SELinux
- Aide-mémoire sur les commandes courantes de Linux
- Que sont les conteneurs Linux ?
- Nos derniers articles Linux
L'environnement de développement dans la programmation de systèmes embarqués est généralement très différent des environnements de test et de production. Ils peuvent utiliser différentes architectures de puces, des piles logicielles et même des systèmes d'exploitation. Les flux de travail de développement sont très différents pour les développeurs embarqués par rapport aux développeurs de bureau et Web. En règle générale, la sortie de construction consistera en une image logicielle complète pour le périphérique cible, y compris le noyau, les pilotes de périphérique, les bibliothèques et les logiciels d'application (et parfois le chargeur de démarrage).
Dans cet article, je présenterai une étude de quatre options couramment disponibles pour la construction de systèmes Linux embarqués. Je vais donner une idée de ce que c'est que de travailler avec chacun et fournir suffisamment d'informations pour aider les lecteurs à décider quel outil utiliser pour leur conception. Je ne vais pas vous apprendre à utiliser l'un d'eux; il existe de nombreuses ressources d'apprentissage en ligne approfondies une fois que vous avez restreint vos choix. Aucune option ne convient à tous les cas d'utilisation, et j'espère présenter suffisamment de détails pour orienter votre décision.
Yocto
Le projet Yocto est défini comme "un projet de collaboration open source qui fournit des modèles, des outils et des méthodes pour vous aider à créer des systèmes Linux personnalisés pour les produits embarqués, quelle que soit l'architecture matérielle". Il s'agit d'un ensemble de recettes, de valeurs de configuration et de dépendances utilisées pour créer une image d'exécution Linux personnalisée adaptée à vos besoins spécifiques.
Divulgation complète :la plupart de mon travail sur Linux embarqué s'est concentré sur le projet Yocto, et mes connaissances et mes préjugés envers ce système seront probablement évidents.
Yocto utilise Openembedded comme système de build. Techniquement, les deux sont des projets distincts ; en pratique, cependant, les utilisateurs n'ont pas besoin de comprendre la distinction, et les noms de projet sont fréquemment utilisés de manière interchangeable.
La sortie d'un build de projet Yocto se compose en gros de trois éléments :
- Cibler les fichiers binaires d'exécution : Ceux-ci incluent le chargeur de démarrage, le noyau, les modules du noyau, l'image du système de fichiers racine. et tout autre fichier auxiliaire nécessaire pour déployer Linux sur la plate-forme cible.
- Flux de packages : Il s'agit de la collection de packages logiciels disponibles pour être installés sur votre cible. Vous pouvez sélectionner le format du package (par exemple, deb, rpm, ipk) en fonction de vos besoins. Certains d'entre eux peuvent être préinstallés dans les binaires d'exécution cibles, cependant, il est possible de créer des packages à installer dans un système déployé.
- SDK cible : Il s'agit de la collection de bibliothèques et de fichiers d'en-tête représentant les logiciels installés sur votre cible. Ils sont utilisés par les développeurs d'applications lors de la construction de leur code pour s'assurer qu'ils sont liés aux bibliothèques appropriées
Avantages
Le projet Yocto est largement utilisé dans l'industrie et bénéficie du soutien de nombreuses entreprises influentes. De plus, une communauté de développeurs et un écosystème importants et dynamiques y contribuent. La combinaison de passionnés de l'open source et de sponsors corporatifs contribue à faire avancer le projet Yocto.
Il existe de nombreuses options pour obtenir de l'aide avec Yocto. Il existe des livres et d'autres supports de formation si vous souhaitez le faire vous-même. De nombreux ingénieurs ayant une expérience de Yocto sont disponibles si vous souhaitez faire appel à une expertise. Et de nombreuses organisations commerciales fournissent des produits clés en main basés sur Yocto ou une implémentation et une personnalisation basées sur des services pour votre conception.
Le projet Yocto est facilement étendu à travers des couches, qui peuvent être publiées indépendamment pour ajouter des fonctionnalités supplémentaires, pour cibler des plateformes non disponibles dans les versions du projet, ou pour stocker des personnalisations propres à votre système. Des couches peuvent être ajoutées à votre configuration pour ajouter des fonctionnalités uniques qui ne sont pas spécifiquement incluses dans les versions de stock ; par exemple, la couche "méta-navigateur" contient des recettes pour les navigateurs Web, qui peuvent être facilement construites pour votre système. Parce qu'elles sont maintenues indépendamment, les couches peuvent avoir un calendrier de publication différent (adapté à la vitesse de développement des couches) que les versions standard de Yocto.
Yocto a sans doute le support d'appareil le plus large de toutes les options discutées dans cet article. En raison du soutien de nombreux fabricants de semi-conducteurs et de cartes, il est probable que Yocto prendra en charge n'importe quelle plate-forme cible que vous choisirez. Les versions directes de Yocto ne prennent en charge que quelques cartes (pour permettre des cycles de test et de publication appropriés), cependant, un modèle de travail standard consiste à utiliser des couches de support de carte externes.
Enfin, Yocto est extrêmement flexible et personnalisable. Les personnalisations pour votre application spécifique peuvent être stockées dans une couche pour l'encapsulation et l'isolement. Les personnalisations propres à une couche d'entités sont généralement stockées dans le cadre de la couche elle-même, ce qui permet d'appliquer simultanément les mêmes paramètres à plusieurs configurations système. Yocto fournit également une priorité de couche bien définie et une capacité de remplacement. Cela vous permet de définir l'ordre dans lequel les couches sont appliquées et recherchées pour les métadonnées. Il vous permet également de remplacer les paramètres dans les calques avec une priorité plus élevée ; par exemple, de nombreuses personnalisations de recettes existantes seront ajoutées dans vos couches privées, l'ordre étant précisément contrôlé par les priorités.
Inconvénients
Le plus gros inconvénient avec le projet Yocto est la courbe d'apprentissage. Il faut beaucoup de temps et d'efforts pour apprendre le système et vraiment le comprendre. Selon vos besoins, il peut s'agir d'un investissement trop important dans des technologies et des compétences qui ne sont pas essentielles à votre application. Dans de tels cas, travailler avec l'un des fournisseurs commerciaux peut être une bonne option.
Les temps et ressources de build de développement sont assez élevés pour les builds de projets Yocto. Le nombre de packages qui doivent être construits, y compris la chaîne d'outils, le noyau et tous les composants d'exécution cibles, est important. Les postes de travail de développement pour les développeurs Yocto ont tendance à être de gros systèmes. L'utilisation d'un ordinateur portable compact n'est pas recommandée. Cela peut être atténué en utilisant des serveurs de build basés sur le cloud disponibles auprès de nombreux fournisseurs. De plus, Yocto dispose d'un mécanisme de cache intégré qui lui permet de réutiliser des composants déjà construits lorsqu'il détermine que les paramètres de construction d'un paquet particulier n'ont pas changé.
Recommandation
Utiliser le projet Yocto pour votre prochaine conception Linux embarqué est un choix fort. Parmi les options présentées ici, il s'agit de la plus largement applicable, quel que soit votre cas d'utilisation cible. Le large support de l'industrie, la communauté active et le large support de plate-forme en font un bon choix pour les concepteurs incontournables.
Buildroot
Le projet Buildroot est défini comme "un outil simple, efficace et facile à utiliser pour générer des systèmes Linux embarqués par compilation croisée". Il partage bon nombre des mêmes objectifs que le projet Yocto, mais il est axé sur la simplicité et le minimalisme. En général, Buildroot désactivera tous les paramètres de compilation facultatifs pour tous les packages (à quelques exceptions notables près), ce qui se traduira par le système le plus petit possible. Il appartiendra au concepteur du système d'activer les paramètres appropriés pour un appareil donné.
Buildroot construit tous les composants à partir de la source mais ne prend pas en charge la gestion des packages sur la cible. En tant que tel, il est parfois appelé générateur de micrologiciel puisque les images sont en grande partie corrigées au moment de la construction. Les applications peuvent mettre à jour le système de fichiers cible, mais il n'existe aucun mécanisme pour installer de nouveaux packages dans un système en cours d'exécution.
La sortie Buildroot se compose en gros de trois composants :
- L'image du système de fichiers racine et tout autre fichier auxiliaire nécessaire pour déployer Linux sur la plate-forme cible
- Le noyau, le chargeur de démarrage et les modules du noyau appropriés pour le matériel cible
- La chaîne d'outils utilisée pour créer tous les binaires cibles.
Avantages
L'accent mis par Buildroot sur la simplicité signifie qu'en général, il est plus facile à apprendre que Yocto. Le système de construction de base est écrit en Make et est suffisamment court pour permettre à un développeur de comprendre l'ensemble du système tout en étant suffisamment extensible pour répondre aux besoins des développeurs Linux embarqués. Le noyau Buildroot ne gère généralement que les cas d'utilisation courants, mais il est extensible via des scripts.
Le système Buildroot utilise des Makefiles normaux et le langage Kconfig pour sa configuration. Kconfig a été développé par la communauté du noyau Linux et est largement utilisé dans les projets open source, ce qui le rend familier à de nombreux développeurs.
En raison de l'objectif de conception de désactiver tous les paramètres de construction facultatifs, Buildroot produira généralement les images les plus petites possibles en utilisant la configuration prête à l'emploi. Les temps de build et les ressources de l'hôte de build seront également plus petits, en général, que ceux du projet Yocto.
Inconvénients
L'accent mis sur la simplicité et les options de construction activées minimales impliquent que vous devrez peut-être effectuer une personnalisation importante pour configurer une construction Buildroot pour votre application. De plus, toutes les options de configuration sont stockées dans un seul fichier, ce qui signifie que si vous disposez de plusieurs plates-formes matérielles, vous devrez apporter chacune de vos modifications de personnalisation pour chaque plate-forme.
Toute modification du fichier de configuration système nécessite une reconstruction complète de tous les packages. Ceci est quelque peu atténué par les tailles d'image et les temps de construction minimaux par rapport à Yocto, mais cela peut entraîner de longues constructions pendant que vous peaufinez votre configuration.
La mise en cache de l'état des packages intermédiaires n'est pas activée par défaut et n'est pas aussi complète que l'implémentation Yocto. Cela signifie que, si le premier build peut être plus court qu'un build Yocto équivalent, les builds suivants peuvent nécessiter la reconstruction de nombreux composants.
Recommandation
L'utilisation de Buildroot pour votre prochaine conception Linux embarquée est un bon choix pour la plupart des applications. Si votre conception nécessite plusieurs types de matériel ou d'autres différences, vous voudrez peut-être reconsidérer en raison de la complexité de la synchronisation de plusieurs configurations, cependant, pour un système composé d'une seule configuration, Buildroot fonctionnera probablement bien pour vous.
OpenWRT/LEDE
Le projet OpenWRT a été lancé pour développer un micrologiciel personnalisé pour les routeurs grand public. La plupart des routeurs à bas prix disponibles chez votre revendeur local sont capables d'exécuter un système Linux, mais peut-être pas prêts à l'emploi. Les fabricants de ces routeurs peuvent ne pas fournir de mises à jour fréquentes pour faire face aux nouvelles menaces, et même s'ils le font, les mécanismes d'installation des images mises à jour sont difficiles et sujets aux erreurs. Le projet OpenWRT produit des images de firmware mises à jour pour de nombreux appareils qui ont été abandonnés par leurs fabricants et donne à ces appareils une nouvelle vie.
Les principaux livrables du projet OpenWRT sont des images binaires pour un grand nombre d'appareils commerciaux. Il existe des référentiels de packages accessibles par le réseau qui permettent aux utilisateurs finaux d'ajouter de nouveaux logiciels à leurs systèmes. Le système de construction OpenWRT est un système de construction à usage général, qui permet aux développeurs de créer des versions personnalisées pour répondre à leurs propres besoins et d'ajouter de nouveaux packages, mais son objectif principal est les fichiers binaires cibles.
Avantages
Si vous recherchez un micrologiciel de remplacement pour un appareil commercial, OpenWRT devrait figurer sur votre liste d'options. Il est bien entretenu et peut vous protéger contre des problèmes que le micrologiciel du fabricant ne peut pas. Vous pouvez également ajouter des fonctionnalités supplémentaires, rendant vos appareils plus utiles.
Si votre conception embarquée est axée sur la mise en réseau, OpenWRT est un bon choix. Les applications réseau sont le principal cas d'utilisation d'OpenWRT, et vous y trouverez probablement bon nombre de ces packages logiciels.
Inconvénients
OpenWRT impose des décisions politiques importantes sur votre conception (vs. Yocto et Buildroot). Si ces décisions ne répondent pas à vos objectifs de conception, vous devrez peut-être apporter des modifications non triviales.
Autoriser les mises à jour basées sur des packages dans une flotte d'appareils déployés est difficile à gérer. Ceci, par définition, entraîne une charge logicielle différente de celle testée par votre équipe d'assurance qualité. De plus, il est difficile de garantir des installations atomiques avec la plupart des gestionnaires de packages, et un cycle d'alimentation intempestif peut laisser votre appareil dans un état imprévisible.
Recommandation
OpenWRT est un bon choix pour les projets amateurs ou pour réutiliser du matériel commercial. C'est également un bon choix pour les applications réseau. Si vous avez besoin d'une personnalisation importante de la configuration par défaut, vous préférerez peut-être Buildroot ou Yocto.
Distros de bureau
Une approche courante de la conception de systèmes Linux embarqués consiste à commencer par une distribution de bureau, telle que Debian ou Red Hat, et à supprimer les composants inutiles jusqu'à ce que l'image installée corresponde à l'empreinte de votre périphérique cible. C'est l'approche adoptée pour la populaire distribution Raspbian pour la plate-forme Raspberry Pi.
Avantages
Le principal avantage de cette approche est la familiarité. Souvent, les développeurs Linux embarqués sont également des utilisateurs Linux de bureau et connaissent bien la distribution de leur choix. L'utilisation d'un environnement similaire sur la cible peut permettre aux développeurs de démarrer plus rapidement. Selon la distribution choisie, de nombreux outils supplémentaires peuvent être installés à l'aide d'outils de packaging standard tels que apt et yum.
Il peut être possible de connecter un écran et un clavier à votre appareil cible et d'y effectuer tout votre développement directement. Pour les développeurs novices dans l'espace embarqué, il s'agira probablement d'un environnement plus familier et supprimera le besoin de configurer et d'utiliser une configuration délicate de développement croisé.
Le nombre de packages disponibles pour la plupart des distributions de bureau est généralement supérieur à celui disponible pour les constructeurs spécifiques à l'embarqué évoqués précédemment. En raison de la base d'utilisateurs plus large et de la plus grande variété de cas d'utilisation, vous pourrez peut-être trouver tous les packages d'exécution dont vous avez besoin pour votre application déjà créés et prêts à l'emploi.
Inconvénients
L'utilisation de la cible comme environnement de développement principal risque d'être lente. L'exécution d'outils de compilation est une opération gourmande en ressources et, selon la quantité de code que vous construisez, peut nuire à vos performances.
À quelques exceptions près, les distributions de bureau ne sont pas conçues pour s'adapter aux systèmes à faibles ressources et il peut être difficile de découper correctement vos images cibles. De même, le flux de travail attendu dans un environnement de bureau n'est pas idéal pour la plupart des conceptions intégrées. Obtenir un environnement reproductible de cette manière est difficile. L'ajout et la suppression manuels de packages sont sujets aux erreurs. Cela peut être scripté à l'aide d'outils spécifiques à la distribution, tels que debootstrap pour les systèmes basés sur Debian. Pour améliorer encore la reproductibilité, vous pouvez utiliser un outil de gestion de configuration, tel que CFEngine (qui, en toute transparence, est réalisé par mon employeur, Mender.io). Cependant, vous êtes toujours à la merci du fournisseur de distribution, qui mettra à jour les packages pour répondre à ses besoins, pas aux vôtres.
Recommandation
Méfiez-vous de cette approche pour un produit que vous envisagez de commercialiser. C'est un bon modèle pour les applications amateurs; Cependant, pour les produits nécessitant une assistance, cette approche posera probablement problème. Bien que vous puissiez démarrer plus rapidement, cela peut vous coûter du temps et des efforts à long terme.
Autres considérations
Cette discussion s'est concentrée sur la fonctionnalité des systèmes de construction, mais il existe généralement des exigences non fonctionnelles qui peuvent affecter votre décision. Si vous avez déjà sélectionné votre système sur puce (SoC) ou votre carte, votre choix sera probablement dicté par le fournisseur. Si votre fournisseur fournit un package de support de carte (BSP) pour un système donné, son utilisation vous fera normalement gagner un peu de temps, mais veuillez rechercher la qualité du BSP pour éviter les problèmes plus tard dans votre cycle de développement.
Si votre budget le permet, vous pouvez envisager de faire appel à un fournisseur commercial pour votre système d'exploitation cible. Il existe des entreprises qui fourniront une configuration validée et prise en charge de la plupart des options discutées ici, et, à moins que vous n'ayez une expertise dans les systèmes de construction Linux embarqués, c'est un bon choix et vous permettra de vous concentrer sur votre compétence principale.
Comme alternative, vous pouvez envisager une formation commerciale pour votre personnel de développement. Cela sera probablement moins cher qu'un fournisseur de système d'exploitation commercial et vous permettra d'être plus autonome. C'est un moyen rapide de surmonter la courbe d'apprentissage des bases du système de construction que vous choisissez.
Enfin, vous avez peut-être déjà des développeurs expérimentés avec un ou plusieurs des systèmes. Si vous avez des ingénieurs qui ont une préférence, cela vaut certainement la peine d'en tenir compte lorsque vous prenez votre décision.
Résumé
Il existe de nombreux choix disponibles pour construire des systèmes Linux embarqués, chacun avec ses avantages et ses inconvénients. Il est crucial de donner la priorité à cette partie de votre conception, car il est extrêmement coûteux de changer de système plus tard dans le processus. En plus de ces options, de nouveaux systèmes sont constamment développés. Espérons que cette discussion fournira un contexte pour examiner les nouveaux systèmes (et ceux mentionnés ici) et vous aidera à prendre une décision solide pour votre prochain projet.