Retrouvez cet article dans : Linux Magazine Hors série 25
Vaste sujet que l’embarqué sous Linux. Après les différents articles d’introduction du précédent hors série et de celui-ci, nous n’avons toujours pas fait le tour des questions qui se posent souvent. Voici donc l’occasion de, en quelques questions/réponses, de revenir sur un certain nombre de points importants.
Existe-t-il un réel avantage à utiliser un Linux 2.6 plutôt qu’un 2.4 en embarqué ?
Oui. En utilisant un noyau de la série 2.6, on profite d’un ordonnanceur amélioré en O(1). Cela garantit que les performances de l’ordonnanceur restent indépendantes de la charge système. Globalement, il reste réactif avec un grand nombre de tâches.
Les noyau 2.6.x ont un HZ de 1000 au lieu de 100 pour la série 2.4 non patchée. En d’autres termes, la valeur du timer minimal est plus courte et la granularité des timers utilisés par les applications plus importante.
Enfin, les patches préemptifs sont maintenant inclus dans la distribution officielle, ce qui permet, après une simple reconfiguration des sources et recompilation du noyau, de faire du Temp Réel mou parfait pour la vidéo.
Quel matériel dois-je prendre pour débuter dans l’embarqué avec Linux ?
La question est classique mais ne se pose pas ainsi. En embarqué, il faut choisir le matériel et le logiciel en fonction de ses besoins et non l’inverse (se demander ce qu’on peut faire avec tel matériel).
Néanmoins, si le but est de découvrir un nouvel univers technique, choisissez une carte avec un processeur non x86 pour l’exotisme et disposant d’un grand nombre de ports et d’interfaces (assurance de la durée de vie, l’intérêt pour la carte).
Tout l’intérêt pédagogique réside ensuite dans l’exploitation maximale de votre investissement. Quel que soit le kit ou le module utilisé, essayez de l’exploiter au maximum en contournant ses limitations.
L’intérêt pédagogique d’une carte tient autant dans ses fonctionnalités que dans l’absence de fonctionnalité. Le développement dans un environnement sans MMU peut être très instructif.
 Obtenir une console série sur un routeur WRT54G nécessite un peu de bricolage (source : http://jdc.parodius.com/wrt54g/serial.html)
Le seul point important qu’il ne sera pas intéressant de contourner est le manque de connectivité. Si l’on prend l’exemple d’un achat d’un Gumstix Basix 200f seul (moins de 100 euros), l’intérêt est très limité.
Vous ne serez pas en mesure de pallier le manque de connectivité si vous n’investissez pas quelques autres dizaines d’euros dans un module d’extension.
Un budget de départ vous permettant de découvrir le domaine se situe entre 160 et 300 euros pour des architectures basées sur des processeurs Coldfire, ARM7 ou Etrax. Il s’agira, le plus souvent, de puces sans MMU et donc destinées à être utilisées avec uCLinux.
On trouve également, pour moins de 200 euros, des kits supportant un noyau Linux classique. Choisissez, de préférence, un kit disposant au minimum d’une interface réseau, d’un port série et des GPIO. Les interfaces SPI, i2c ou autres ne sont pas strictement nécessaires et pourraient, au besoin, être émulées.
En dehors des kits de développement, existe-t-il d’autres solutions pour s’initier à l’embarqué sous Linux ?
Les kits tels que ceux présentés dans ce magazine ou ceux listés par http://www.linuxdevices.com/ constituent, sans le moindre doute, la meilleure solution pour s’initier.
 Cependant, il est compréhensible que l’investissement financier ne soit pas possible pour tout le monde.
Reste le monde x86 où il est possible de faire quelques expérimentations autour de matériels de type PC. L’article sur la construction d’un système sur carte CompactFlash dans le présent magazine vous donnera une base de travail, tout comme les explications données par P. Ficheux dans son livre paru chez Eyrolles.
Bien entendu, rester dans le monde du compatible Intel x86 ne permet pas de faire connaissance avec les problématiques d’autres architectures.
La dernière solution est donc de vous tourner vers des produits manufacturés. Les deux exemples les plus connus sont :
- Le Linksys NSLU2, un système de stockage réseau construit autour d’un Intel IXP420 (base ARMv5TE) avec 8Mo de mémoire flash et 32Mo de SDRAM. Disponible en France pour moins de 100 euros, le NSLU2 regroupe une importante communauté d’utilisateurs, de développeurs et de hackers (au sens strict du terme). Ainsi a vu le jour le projet NSLU2-Linux (http://www.nslu2-linux.org) consistant à proposer des firmwares complètements différents, ouverts et surtout modulaires. Le NSLU2 est devenu une plateforme très riche en fonctionnalités, mais également un environnement de développement très bien documenté.
Notez que les développements autour du NSLU2 ont conduit le projet à s’intéresser à d’autres produits comme le routeur Asus WL-500g ou le Synology DS-101 (au firmware original tristement excentrique, voir article dans GNU/Linux Magazine France 76).
- Toujours par Linksys, les routeurs WiFi de la série WRT54G/GS constituent une intéressante base de travail grâce au projet OpenWrt. A l’instar de NSLU2-Linux, le but est d’offrir bien plus de fonctionnalités au périphérique que n’en avait originellement prévu le fabriquant. Là encore, comme avec le NSLU2, le projet a pris de l’ampleur et est devenu portable sur un grand nombre de périphériques, dont la liste peut être consultée sur http://wiki.openwrt.org/TableOfHardware. Les WRT54G neufs se trouvent pour quelques 65 euros chez tous les distributeurs.
 http://www.nslu2-linux.org
www.linuxdevice.com, le site de référence pour l’actualité de l’embarqué sous Linux
Ces solutions sont séduisantes, car en plus d’être des plateformes d’expérimentation, elles ont une réelle utilité. En contrepartie, il ne faut pas oublier qu’il s’agit de produits normalement destinés à un marché grand public.
Le fait qu’il s’agisse de productions en série limite grandement l’étendue des possibilités. Les différents bus normalement utilisables pour telle ou telle architecture, par exemple, peuvent être inaccessibles du fait de la conception du produit.
Il est alors nécessaire d’adapter son cahier des charges ou d’attaquer le matériel directement au risque de le détruire.
Si je dispose de suffisamment de mémoire, dois-je de préférence utiliser un initrd ou un initramfs pour le démarrage de mon système ?
Comme souvent en embarqué, la réponse dépendra du projet concerné. Pour répondre, la seule profusion de mémoire n’est pas suffisante. L’utilisation d’une image initrd ou initramfs sur le modèle de ce qui se fait avec un système GNU/Linux classique n’est pas intéressante.
En effet, le seul intérêt de ces images est de permettre le chargement de modules et l’exécution de certaines tâches avant le passage sur le système devant être booté.
Dans le cas d’un système embarqué, on configurera le noyau Linux et le support du matériel en fonction de la plateforme. Celle-ci ne risque pas de changer une fois en production et le système n’aura pas à s’adapter.
Si une évolution matérielle doit survenir, il faudra revoir la configuration du système. Nous n’avons donc pas besoin que le système réponde à une configuration changeante.
Le seul intérêt est donc de faire fonctionner l’intégralité du système en mémoire sans jamais basculer sur le support de stockage. L’avantage est certain, l’intégrité des données est presque garantie.
Circuit principal d’un NSLU2 (source : http://www.nslu2-linux.org)
En contre-partie, en cas d’arrêt brutal du système, les données dynamiques (mesures, journaux, etc.) seront perdues et le système reviendra à un état initial prédéfini.
Bien entendu, il pourra être envisagé de protéger matériellement le système embarqué en lui fournissant une source d’énergie annexe ou en mettant en œuvre un enregistrement des données sur un support de stockage différent de celui utilisé (en lecture seule) pour l’image du système.
En conclusion, l’utilisation de ce type de systèmes n’est intéressante que pour des besoins spécifiques. A vous de voir si c’est le cas pour votre projet.
Quelles différences y a-t-il entre uC-libc et uClibc ?
uC-libc et uClibc, comme la GNU libc, sont des bibliothèques C standard. Elle se distinguent toutefois par leur faible empreinte mémoire et sont spécialement destinées aux systèmes embarqués.
On retrouve, par exemple, le choix entre ces trois bibliothèques dans la configuration des sources d’uCLinux.
uC-libc est la bibliothèque originale d’uCLinux basée sur la bibliothèque C Linux-8086 du projet ELKS portée sur l’architecture m68k. uC-libc est considérée comme une implémentation relativement complète.
Une partie de l’API n’est pas standard et un certain nombre de routines habituellement classiques ne sont pas incluses. uC-libc est disponible pour les architectures m68k/ColdFire et ARM sans MMU. Elle est stable, robuste et légère.
uClibc, pour sa part, est une évolution de uC-libc. L’objectif est de standardiser l’API et d’ajouter les routines manquantes.
L’objectif secondaire du projet est plus ambitieux puisqu’il s’agit de se rapprocher au maximum de la glibc (GNU Libc) afin de faciliter de travail de portage des développeurs. Ainsi, porter une application de GNU/Linux avec uClibc est relativement aisé.
uClibc peut être utilisée aussi bien sur un Linux disposant d’un VM que sur uCLinux. Ainsi, sur une MMU est disponible le support des bibliothèques partagées, qui peut être activé, réduisant ainsi la consommation de mémoire.
Les architectures supportées sont bien plus nombreuses qu’avec la vieillissante uC-libc : m68l/Coldfire, ARM, MIPS, v850, x86, i960, Sparc, SuperH, Alpha, PowerPC et Hitachi 8.
Le choix entre uC-libc et uClibc dépendra de vos besoins en termes de compatibilité et de fonctionnalités. Dans bien des cas, c’est uClibc qui sera choisi.
Quelles sont les implications légales de l’utilisation de GNU, Linux et d’un système sous GPL dans l’embarqué ?
La question n’est pas spécifique aux systèmes embarqués, mais l’intégration (enfouissement) importante des solutions semble donner à réfléchir.
L’utilisation d’un système en logiciel Libre comme uCLinux, Linux ou les outils GNU dans l’embarqué ne pose aucun problème légal autre que ceux déjà présents avec un système GNU/Linux classique. La distribution ou la vente d’un système embarqué incluant du code GPL (GNU General Public License) est une diffusion du code. En cela, la mise à disposition des sources sous GPL devient obligatoire selon les termes de la licence.
Il en va de même pour toute version modifiée de code GPL. Ainsi, si votre solution embarquée intègre du code GPL modifié ou adapté par vos soins, vous ne pouvez pas restreindre sa diffusion ou la diffusion des sources.
Il faut bien comprendre qu’il s’agit là de code GPL distribué à l’identique ou en version modifiée. Ceci n’est absolument pas valable pour une application intégrée dans le système.
Il est parfaitement légal de vendre une solution embarquée basée sur uCLinux, par exemple, incluant des applications ou des outils propriétaires. Vous ne serez pas obligé de diffuser les sources de vos applications en raison de leur intégration dans le système. C’est un point qu’il est important de préciser car l’aspect " contaminant " de la GPL est souvent mal interprété et décrié à tort par certains.
On notera que les problèmes de licences sont monnaie courante dans le monde de l’embarqué. Le projet Busybox, par exemple, tient à jour une liste de sociétés qui ne respectent pas les termes de la licence GPL ou qui refusent de mettre à disposition les sources de Busybox modifiées ou non.
Dans quelques cas, il s’avère qu’il s’agit bien d’une violation de la GPL. De la même manière, des précédents existent également avec le projet VLC dont du code modifié a été intégré dans les solutions embarquées propriétaires.
Mémoire flash NAND ou NOR. De quoi s’agit-il ?
Il est vrai que l’on retrouve ces désignations de plus en plus souvent dans les caractéristiques des architectures destinées à l’embarqué. Cela nécessite un minimum d’explications.
 La carte Fox d’ACME System intégrant un processeur Axis ETRAX 100LX, 16 Mo de RAM et 4 Mo de Flash, mais surtout un contrôleur USB et des I/O pouvant fonctionner comme contrôleur IDE. Le tout pour moins de 200 euros.
Les mémoires NAND et NOR reposent sur le même principe de fonctionnement : le stockage de charge dans la grille flottante d’un transistor. Passons sur le cours d’électronique pour en venir à la différence principale entre les deux types, résidant dans l’organisation de leurs réseaux mémoire.
La mémoire NOR connecte les cellules mémoire en parallèle avec les lignes de bits. Avec les NAND cette connexion est faite en série. En ce qui concerne le domaine de l’embarqué, la différence est de taille car, les NOR étant adressées de manière linéaire, elles permettent l’exécution directe du code (fonctionnalité XiP, pour eXecute in place).
Cependant, le principal grief qu’on porte généralement contre les NOR concerne leur lenteur en écriture et en effacement. Les dernières versions de composants flash NOR règlent partiellement le problème via des astuces consistant à partitionner la mémoire en banc (entre 4 et 32).
L’accès aux bancs se faisant indépendamment, cela permet d’accélérer l’ensemble.La mémoire NAND est une concurrente importante pour la NOR. Les cellules mémoire sont environ 30% à 40% plus petites, réduisant de manière significative le coût des composants.
Les circuits NAND sont à accès séquentiel et ne se prêtent pas au XiP. Ceci impose donc systématiquement la copie du code depuis la mémoire flash dans une SDRAM par exemple. Vous comprendrez maintenant pourquoi certains kits se composent souvent de 8 fois plus de mémoire flash NAND que de NOR (lorsqu’elle est proposée). Du point de vue du développeur de systèmes embarqués, NOR est tout simplement synonyme de XiP et NAND de réduction des coûts.
Quelle est la place de Linux dans l’embarqué ?
La question a été partiellement soulevée dans le précédent hors série. Cependant, à l’heure où sont écrites ces quelques lignes, les évènements confirment sans cesse les prédictions.Linux progresse à une vitesse impressionnante dans le milieu de l’embarqué et celui de l’industrie en général.
La profusion de solutions disposant d’un support Linux n’explique pas à elle seule le phénomène.
Le milieu de l’industrie n’est pas celui de la micro personnelle où les modes jouent un rôle important (on constate à quelle vitesse la distribution Ubuntu a réussi à se placer dans le top 3).
Sans pour autant parler d’inertie, mais plutôt de prudence, on constate que certains milieux sont moins propices que d’autres à la propagation de " l’effet Linux ".
Heureusement, un certain nombre de points qui caractérisent Linux et le logiciel libre ont fortement influencé le marché :
- Le fait qu’il s’agisse d’un système UNIX répondant à un certain nombre de standards permet d’unifier le développement et autorise le transfert de compétences ;
- L’ouverture des sources permet une adaptation à quasiment n’importe quelle plateforme ou architecture ;
- Les ressources en termes de compétences sont importantes. Les développeurs maîtrisant les solutions GNU/Linux sont loin d’être rares et ce nombre ne cesse d’augmenter. La similitude entre Linux/x86 et d’uCLinux permet de rapidement former n’importe quel développeur au domaine de l’embarqué, augmentant d’autant le potentiel en ressources humaines ;
- La communauté Linux embarqué est importante, très productive et motivée. Il suffit de faire quelques recherches sur Internet pour constater l’importance des ressources disponibles aussi bien en termes de documentations que de code sources.
Bien entendu, il existe également des points négatifs parmi lesquels le fait que le partage des informations techniques et du code est loin d’être entré dans les mœurs des milieux industriels.
C’est pourtant cette diffusion qui permet de garantir la dynamique du développement autour du Libre. Malheureusement, il faudra du temps pour que les habitudes changent.
A l’heure actuelle, même les fabricants de puces graphiques refusent encore de diffuser les sources de leurs pilotes sous prétexte que cela poserait problème en termes de secret industriel.
C’est une remarque qu’on entendait tantôt il y a quelques années lorsque les fabricants de périphériques informatiques refusaient de créer des pilotes Linux.
La mauvaise compréhension des licences Libres est également un problème. Dans un milieu où le secret est omniprésent, difficile de faire comprendre les intérêts d’une ouverture et encore plus le fonctionnement de licences qui la permettent.
Quoi qu’il en soit, Linux et le Logiciel Libre ont un brillant avenir dans l’embarqué et l’investissement en temps et en ressource, aussi bien pour un développeur que pour une entreprise, ne sera pas vain.
Retrouvez cet article dans : Linux Magazine Hors série 25
