Comment survivre à Linux embarqué – Partie 1 Le Processus de développement de Linux embarqué
Le Processus de développement de Linux embarqué
Le noyau Linux peut fonctionner sur de nombreuses architectures informatiques différentes, dont la plupart sont très populaires dans le monde embarqué. Tous les paquets de base permettant au système d’exploitation d’effectuer les tâches de base conviennent à la compilation croisée, Linux peut donc être aussi omniprésent que les microcontrôleurs et les systèmes sur puce (SOC).
Une distribution Linux est un système d’exploitation fabriqué à partir d’une collection de logiciels, qui est basée sur le noyau Linux et – souvent – un système de gestion de paquets. La distribution peut se présenter sous forme de binaires et de paquets pré-compilés assemblés
par les responsables de la distribution, ou sous forme de sources associées à des instructions sur la façon de les (compiler).
Dans le domaine embarqué, la plate-forme matérielle étant généralement sur mesure, le concepteur du système d’exploitation préfère généralement générer la distribution à partir de zéro, à partir des sources. Cela donne au concepteur un contrôle absolu de ce qui se retrouve dans le produit
. En outre, l’ingénieur BSP (Board Support Package) modifie le code de bas niveau afin de faire fonctionner les fonctionnalités de base du système d’exploitation sur le produit matériel spécifique.
Rassembler tous les composants logiciels nécessaires pour générer la distribution Linux pour un produit embarqué particulier était un cauchemar, mais heureusement ce n’est plus le cas.
Beaucoup ont partagé avec la communauté open source les sources de systèmes de construction capables de récupérer tous les composants logiciels sur Internet, de les compiler et de les relier entre eux, jusqu’à la génération d’images d’installation de systèmes d’exploitation à part entière. Quelques entreprises développent et maintiennent leur propre système de construction, d’autres ne compilent que quelques-uns des composants principaux, puis prennent des binaires prédéfinis pour finaliser le système d’exploitation.
En 2010, un groupe de travail de la Fondation Linux a commencé à traiter des outils et des processus permettant la création de distributions Linux pour les logiciels embarqués (alias Linux embarqué). Un tel groupe de travail, connu sous le nom de projet Yocto, s’alignait sur Open Embedded, un framework aux objectifs similaires.
Le projet Yocto est un projet open source dont l’objectif est d’améliorer le processus de développement de logiciels pour les distributions Linux embarquées. Le projet Yocto fournit des outils, des métadonnées et des processus interopérables qui permettent le développement rapide et reproductible de systèmes embarqués basés sur Linux.
Le projet Yocto alimente actuellement les distributions Linux les plus populaires pour les systèmes embarqués, à un point tel que parfois les termes « Linux embarqué » et » Projet Yocto » sont facilement confondus comme synonymes. Yocto ce n’est pas une distribution Linux embarquée, elle en crée une personnalisée pour vous.
Disposition des méta-couches de Yocto
La version moderne de l’architecture de Yocto est basée sur des méta-couches, qui sont des répertoires contenant des fichiers de configuration et des règles sur la façon de compiler et d’assembler des distributions Linux pour les systèmes embarqués.
Habituellement, mais pas toujours, une méta-couche vit sur son propre référentiel git, et fournit:
- ses propres paquets (définis par des recettes, des fichiers .bb),
- modifications des paquets fournis par d’autres méta-couches (.fichiers bbappend),
- machines (.fichiers de configuration),
- fichiers de configuration (.fichiers conf),
- code commun (.fichiers bbclass),
- licences,
- et autres éléments mineurs.
Une seule méta-couche répond normalement à un objectif spécifique. Par conséquent, pour obtenir un système pleinement fonctionnel, plus de méta-couches doivent être combinées ensemble.
Sélection et correspondance des versions
Lors de l’assemblage de différents composants logiciels, il faut être attentif à la version de chaque composant, car la mauvaise version peut ne pas fonctionner correctement avec les autres composants ou même casser le système.
Le projet Yocto fournit des versions de composants connus pour bien fonctionner ensemble, mais ce n’est que le point de départ de votre produit.
Le noyau Linux est un gros morceau de code qui doit exposer les bonnes interfaces à l’espace utilisateur, et doit contenir les bons pilotes, pour que le système fonctionne correctement. Par conséquent, le rôle du fournisseur de silicium est devenu de plus en plus important de nos jours, car ils ont généralement leurs propres dépôts de développement pour le noyau Linux et le chargeur de démarrage, ce sont donc les meilleures personnes pour mettre en place un système de base de travail basé sur leur technologie.
Repo de Google
Initialement développé pour faire face à la multitude de dépôts Git dans un projet Android, repo est également devenu très populaire parmi les développeurs Yocto.
Repo est un outil construit sur Git; il utilise un « fichier manifeste » pour cloner et extraire un ensemble de dépôts Git en même temps.
Un manifeste de dépôt est un .document xml contenant des références aux référentiels git (ainsi que leurs versions), repo peut utiliser le manifeste pour remplir un répertoire avec toutes les sources provenant des différents référentiels Git nécessaires à la construction d’un projet.
De plus, le même manifeste peut être utilisé par repo pour contrôler (synchroniser) les sources du projet lorsque l’amont apporte des modifications.
De nos jours, quelques fournisseurs de silicium fournissent des manifestes pour leurs branches de développement et de publication, afin que les concepteurs puissent facilement vérifier le point de départ de leurs propres produits.
Développement de produit basé sur Yocto
L’ingénieur BSP part généralement du manifeste du dépôt du fournisseur de silicium pour vérifier la version du logiciel pour le design de référence (qui est un design fourni par le fournisseur de silicium lui-même ou l’un de ses partenaires, contenant le même SoC ou similaire à celui sur lequel le nouveau produit est basé). L’ingénieur apporte des modifications au chargeur de démarrage et au noyau Linux pour s’assurer que le matériel sélectionné par l’ingénieur en électronique dispose d’un support logiciel de bas niveau approprié (par exemple, pilotes de périphériques, arborescence de périphériques, configuration du noyau, etc.).
Le but du produit est d’exécuter une ou plusieurs applications, par conséquent, l’ingénieur BSP/OS s’assure que toutes les dépendances de la ou des applications sont en cours de construction pour le système. Les ingénieurs qui développent l’application ont besoin d’un Kit de développement Logiciel (SDK) pour compiler et relier l’application, donc l’ingénieur BSP/OS
leur fournira un tel kit, et grâce à Yocto c’est devenu assez simple.
Bonne pratique pour Linux embarqué
Les manifestes de dépôt utilisés pour le développement contiennent généralement une référence aux branches de développement, ce qui signifie que le dépôt récupérera le dernier commit pour ces branches.
Si vous utilisez le même manifeste pour récupérer le projet à une date ultérieure, vous pouvez récupérer une version différente du code! C’est parfaitement bien pour le développement car vous souhaitez vous en tenir à la dernière version de votre projet, mais l’une de vos versions de développement finira par devenir une version, et vous devez donc « prendre une photo » de cette version précise des sources utilisées pour générer la version logicielle qui va sur le projet. Ne pas le faire peut vous exposer à des problèmes juridiques car vous ne pourrez pas régénérer la même version à partir des sources, vous ne pourrez donc pas apporter de modification au-dessus d’une version spécifique, obligeant le client à tester à nouveau l’ensemble du système car vous serez obligé de corriger le bogue ou d’ajouter la nouvelle fonctionnalité au-dessus de la dernière version du logiciel.
De plus, si vous ne prenez pas ces instantanés, vous ne pouvez pas exécuter une coupure sur les sources du projet pour savoir quel commit a cassé la fonctionnalité dont vous avez si désespérément besoin. Lors de la conception de votre processus de développement, trouvez un moyen de générer automatiquement des manifestes de dépôt contenant des validations précises, afin que vous puissiez les enregistrer aux côtés des versions pour récupérer les mêmes sources à une date ultérieure, et faire tout ce que vous êtes payé pour faire.
Copiez les sources en interne
Gardez également à l’esprit que 99,9% des sources qui entrent dans votre produit proviennent de la communauté open source, ce qui signifie que vous n’avez aucune garantie que les mêmes sources seront à nouveau disponibles en téléchargement. En tant que designer, vous devez vous protéger contre les changements et les erreurs commises en amont. Conservez une copie de toutes les sources pertinentes en interne et trouvez un moyen de les rebrancher dans votre système de construction. De plus, vous voudrez peut-être mettre en miroir certains des référentiels que vous utilisez le plus, car les serveurs git en amont peuvent parfois devenir soudainement indisponibles. Si vous n’avez pas de copie interne, vous serez bloqué jusqu’à ce que les serveurs reviennent en ligne.
Chez ByteSnap, nous avons une façon entièrement automatisée de publier des projets basés sur Yocto, de sorte que nous pouvons récupérer les sources qui entrent dans une version, et aussi, reconstruire la même version à une date ultérieure. Nous conservons des copies de paquets open source de manière automatique, afin que nous ne subissions aucun temps d’arrêt causé par des serveurs défectueux dans le monde entier. De plus, nous sauvegardons tout chaque jour afin de garantir qu’aucun travail ne sera perdu même en cas de catastrophe sur le site.
Fabrizio Castro
Fab est ingénieur logiciel senior. Il a obtenu son baccalauréat et sa maîtrise au Politecnico di Milano, à Milan, en Italie. Il a 20 ans d’expérience dans le développement de logiciels tous azimuts (services, bases de données, applications, logiciels scientifiques, micrologiciels, RTOS, pilotes de périphériques, noyau Linux, etc.), passé à travailler dans le milieu universitaire et l’industrie. Fab a co-écrit des articles scientifiques et des livres, et a travaillé sur des brevets. En plus de la recherche et du développement, il est spécialisé dans le développement de Linux embarqué – fournissant des conceptions de pointe alimentant des produits scientifiques, industriels, commerciaux et militaires à succès. Fab a également été conférencier et a enseigné à des étudiants de premier cycle dans certaines des universités les plus prestigieuses d’Europe. Pour plus d’informations sur la conception de ByteSnap, visitez http://www.bytesnap.co.uk.