les solutions libres pour les systèmes embarqués

1Logiciels libres et SE

Solutions libres pour les systèmes embarqués

Pierre FICHEUX ([email protected])

Mars 2015


Programme

● Présentation● Rappels sur les systèmes embarqués et temps réel● Le logiciel libre● Linux comme système embarqué● Extensions temps réel de Linux● Android « embarqué »● eCOS et RTEMS● Les outils libres pour l'embarqué● Open hardware● Co-design


Présentation Open Wide

● Société d'ingénierie créée en septembre 2001 avec le concours de THALES et Schneider Electric

● Rachat d'ESG-France (automotive) en 2014● Environ 160 salariés sur Paris, Lyon, Toulouse et

bientôt Grenoble● Industrialisation de composants open source

– Développement

– Conseil / Formation

● Trois activités :– OW Système d'Information (Java/PHP)

– OW Outsourcing: hébergement

– OW Ingénierie: informatique industrielle


Présentation PF

● Ingénieur Arts et Métiers + Sup'Aéro● Utilisateur de logiciels libres depuis 1989● Utilisateur de Linux depuis 1992● Auteur des 4 éditions de l'ouvrage « Linux embarqué »

(Eyrolles), 4ème édition parue en juin 2012 avec E. Bénard● Auteur GNU Linux Magazine et Open Silicium● CTO Open Wide Ingénierie, enseignant EPITA, ENSEIRB


Rappels sur les systèmes embarqué


Système / logiciel embarqué

● Un système est l'association matériel + logiciel● Logiciel utilisé dans un équipement industriel ou un

bien de consommation● On dit aussi logiciel dédié ou intégré → embedded

software● L'équipement est valorisé pour son coté fonctionnel et

non pas pour le logiciel !● Un bon logiciel embarqué doit savoir se faire oublier !● On parle parfois de logiciel enfoui ou profondément

enfoui → « deeply embedded »


Domaines d'application

● 1960-70 : remplacer / compléter des systèmes analogiques (spatial)

● 1980 : RTOS (Real Time OS) génériques● 2000 : OS libres, grand public● Domaines historiques/industriels

– Militaire, spatial (RTOS/360, VRTX sur Hubble)

– Contrôle de processus industriel

– Transport : AUTOSAR/OSEK, ARINC 653 → certification (DO-178)

– Internet/Telecom : routeurs, PABX

● « Nouveaux » domaines– Multimédia

– automobile (IVI), objets connectés

– médical


Les nouveaux domaines

● Équipement grand public (multimédia, domotique, …)● Téléphonie → 1+ milliards de téléphones Android !● Infotainment transport: automobile, aéronautique

– Ajout de fonctions communicantes → utilisation de protocoles standards de type IP et dérivés (HTTP, DHCP, etc.)

– Difficile d'intégrer ces couches dans des logiciels embarqués propriétaires → utilisation d'un OS

● « Boite noire » dédiée à un ensemble de fonctions (passerelle médicale, set-top box avec services étendus)

● Internet des objets → #iot :-)


Avantages d'un OS

● Affranchit le développeur d'un travail d'adaptation au matériel pour les interfaces de base (PCI, USB, Ethernet...)

● Permet de bénéficier des dernières avancées technologiques et de faire évoluer le système: protocoles réseau, multimédia, etc.

● Recrutement aisé de développeurs (Linux, Android) !● Utilisation de matériel « standard »● Focalisation sur le métier de l'entreprise


Inconvénients d'un OS

● Empreinte mémoire● Performances● Consommation d'énergie (nombreux travaux en cours)● Criticité (sauf OS spécialisés)● Perte de maîtrise du système


Les systèmes temps réel

● Les applications embarquées historiques étaient temps réel

● Les systèmes d'exploitation embarqués propriétaires sont TR (VxWorks, LynxOS, VRTX, ...) → RTOS

● La progression des OS libres dans l'industrie et dans l'embarqué en général modifie la donne !

– Linux est utilisable dans l'industrie

– Linux n'est pas TR

– Linux peut être modifié pour être TR (PREEMPT-RT, Xenomai)

– Il existe des RTOS libres (RTEMS, FreeRTOS, ...)


Le logiciel libre dans l'embarqué


Historique

● Modèle économique du marché informatique → du matériel vers le logiciel

● Projets logiciels libres majeurs (chronologie)– UNIX BSD

– X Window System (X11)

– GNU (tout d'abord sur UNIX propriétaire)

– Linux → GNU/Linux

– Apache

● Apparition de licences libres (vs « freeware »)– BSD

– GPL (dérivation et « contamination »)

– ASL


Quelques éléments sur le LL

● A peu près équivalent à la notion d'open source, voir http://www.opensource.org

● Libre ne veut pas dire gratuit● La confusion vient de la signification anglaise

– free = libre / gratuit

● Différents types de logiciels– Le freeware : gratuit mais sources non disponibles, pas

forcément de licence (abandon de la « paternité » du code)

– Le shareware : sources non disponibles, coût modique, licence souvent propriétaire

– Le logiciel libre: sources disponibles, licence open source, non liée à la notion de gratuité (on peut vendre un logiciel libre)

http://www.opensource.org/


Importance du logiciel libre

● Le logiciel libre est important dans le SI (serveurs)● Le logiciel libre a pris un part importante dans les

systèmes embarqués– OS (Linux, Android)

– Outils de base (compilateur, éditeur, débogueur, ...)

– « build systems » (Buildroot, Yocto/OE)

– IDE (Eclipse)

● La plupart des éditeurs ont au catalogue des composants basés sur du logiciel libre (Wind River, Adacore, LynuxWorks, ...)


Avantages/inconvénients du LL

● Avantages– Disponibilité du code source → maîtrise et

maintenabilité dans le temps

– Redistribution sans « royalties »

– Outils de développement souvent « gratuits » !

– Support de la communauté

● Inconvénients– Méfiance vis à vis d'un modèle décentralisé (support)

– Contraintes de certaines licences (GPL, LGPL)

– Support de certains matériels (?)

– Outils moins « ciblés »

– Documentation (?)


Les OS libres pour l'embarqué


Linux comme (RT)OS

● Réservé aux systèmes complexes– 32 bits minimum

– Gestion complexe de la mémoire (MMU, pagination + segmentation)

– Empreinte mémoire importante: 2 Mo pour µCLinux (sans MMU), 4 Mo pour Linux

– Consommation mémoire vive : 16 Mo minimum

● Problème de migration de anciens RTOS car Linux n’est pas TR → évolution avec les extensions PREEMPT-RT et Xenomai

● Incompatible avec les systèmes critiques/certifiés● Souvent utilisé pour les outils, les simulateurs et

architectures « mixtes » (banc de test)


Linux et le TR, ooops :(


Extensions TR pour Linux

● L'utilisation de Linux comme RTOS est souvent intéressante

– POSIX

– Approche hybride avec quelques tâches TR

– On conserve le confort d'un système classique

● Deux approches possibles :– Modifier le noyau Linux afin d'améliorer ses

performances TR (PREEMPT-RT)

– Ajouter un « co-noyau » TR qui partage le matériel avec le noyau Linux (RTLinux, RTAI, Xenomai) → approche « virtualisation »


PREEMPT-RT

● Branche expérimentale pour le noyau 2.6, voir https://rt.wiki.kernel.org

● Initié par Ingo Molnar, contributeur majeur du noyau● Maintenu par Thomas Gleixner● Surtout utilisé sur x86 et des processeurs performants

(TSC = Time Stamp Counter)● Fonctionne également sur ARM (11 ou plus), Nios II,

Microblaze, ...● Nécessite un noyau « mainline » (ou proche) mais ne

sera probablement jamais intégré à la branche officielle● Mise en place très simple (application d'un patch)● Mêmes API de programmation que Linux standard

https://rt.wiki.kernel.org/


PREEMPT-RT, caractéristiques

Utilisation d'un thread noyau (interruptible) pour le traitement de chaque interruption 4 2 root SW< 0 0% 0% [sirq-high/0]

5 2 root SW< 0 0% 0% [sirq-timer/0]

6 2 root SW< 0 0% 0% [sirq-net-tx/0]

● Prévention des inversions de priorité (par héritage)● Timers noyau haute précision (HRTIMER)● Amélioration des mécanismes de synchronisation● Le résultat est un noyau (presque) « préemptif », mais

reste un noyau Linux


PREEMPT-RT, résumé

● Changements significatifs du code noyau– Verrouillage des sections critiques

– Volume du patch important

● Utilisation de mlockall() → verrouillage des pages mémoire en RAM

● Le coût de la préemption peut être important si le nombre de tâches TR augmente

● Temps de latence maximum nettement amélioré– dépend largement de la plate-forme matérielle (TSC)

– dépend de la configuration logicielle

– Bons résultats sur x86 depuis de nombreuses années

● Permet de garantir moins de 50 µs de jitter (x86)● Risque sur la maintenance (financement) ?


Linux avec co-noyau

● Ajout d'un « co-noyau » pour la gestion du temps-réel– Sous-système temps-réel intégré à un module noyau

– Patch de « virtualisation » des interruptions

● Différents modèles de programmation– Noyau uniquement (RTLinux, version libre)

– Noyau et espace utilisateur, semi-intégration Linux (RTAI, www.rtai.org)

– Noyau & espace utilisateur, intégration Linux complète (Xenomai, www.xenomai.org)

http://www.rtai.org/

http://www.xenomai.org/


Linux avec co-noyau

● Séparation entre le composant temps-réel et Linux– Ordonnanceur temps-réel spécifique

– Pas de dépendance sur les sections critiques Linux :-)

● Virtualisation de la gestion d'interruptions Linux– Routage prioritaire des IRQs vers le co-noyau

● Linux comme tâche idle du co-noyau● Volume du patch noyau plus faible qu'avec PREEMPT-

RT● Se rapproche de la technique de « para-virtualisation »

des hyperviseurs (adaptation de l'OS)


Linux + co-noyau, suite

● Peu de modifications sur le noyau Linux– patch de virtualisation (très bas niveau)

– notion de domaine d'exécution (temps-réel / normal)

● Pas d'impact sur l'écriture de code noyau classique● Impact sur l'écriture de code temps-réel !

– utilisation des API fournies par le co-noyau

● Excellentes performances TR– ordonnanceur spécifique indépendant

– sous-système temps-réel bien délimité

– jitter maximal de l’ordre de 10 µs sur Atom/x86 !


RTLinux

● Projet universitaire (NMT) développé par Victor Yodaiken et Michael Barabanov en 1999

● Produit commercial développé par FSMLabs● Dépôt d’un brevet logiciel → conflit avec la FSF● Vendu à WIND RIVER en 2007● Développement en espace noyau (?)● Version GPL obsolète (2.6.9) retirée par WIND RIVER


Architecture initiale RTLinux


RTLinux en 2002


RTAI

● Real Time Application Interface● Un « fork » de RTLinux développé au DIAPM de l’école

polytechnique de Milan → Dipartimento di Ingegneria Aerospaziale (Paolo Montegazza)

● Utilisé au DIAPM pour des travaux d’enseignement et de recherche

● Quelques utilisations industrielles● Position douteuse / brevet logiciel FSMLabs● Toujours actif mais peu d’évolution → version 3.8 en

février 2010, 3.9 en août 2012


Xenomai

● Xenomai est un sous-système temps-réel de Linux– Programmation de tâches en espace utilisateur

– API d'application et de pilotes temps réel (RTDM) dédiées

● Intégré au noyau Linux → « Real-time sub-system »● Supporte de nombreuses architectures● Dispose de « skins » permettant d'émuler des API

temps réel (POSIX, VxWorks, VRTX, uITRON, ...)● Plus complexe à mettre en œuvre que PREEMPT-RT

mais performances 5 à 10 fois supérieures● Licence GPL (cœur), LGPL (interfaces, espace

utilisateur)


Architecture générale

● Xenomai utilise un micro-noyau (ADEOS) pour partager le matériel avec le noyau Linux

● Un processus contient des threads TR et TP (Linux)

micro-noyau

noyau TR

API TR

pilote TRProcessus Linux


Répartition sur les deux domaines

Hardware

VFS/FS ...

Pile réseau Xenomai RTOS

Adeos I-Pipe

Noyau

Code applicatif VxWorks

glibcXenomailibvxworks

Code applicatif POSIX

Xenomailibpthread

Appels système

glibc

libpthread_rt

Noyau Linux


Linux/Xenomai et le TR :)


Android

● Android = un système d'exploitation basé sur un noyau Linux

● Un « framework » fournissant des applications et permettant d'en ajouter facilement

● Basé sur Dalvik (puis ART), une machine virtuelle Java (très) optimisée pour le mobile

● Navigateur web basé sur Webkit puis Chrome● Graphique optimisé en 2D ou 3D basé sur OpenGL/ES● Nouvel environnement de développement « Android

Studio » compatible avec Android « wear » (#IoT)● Partiellement open source mais pas réellement du

logiciel libre...


Android et l'industrie

● Linux fournit des API graphiques (Qt, EFL) mais « difficiles » à programmer

● Android est avantageux si le projet utilise une IHM● Base importante d'applications Android !● Android est conçu pour la téléphonie et les tablettes

mais des BSP Android sont fournis pour les cartes (ARM) récentes (BB Black, i.MX6, ...)

● Android utilise un noyau Linux :-)● Assez peu de projets pour l'instant● Concurrence de Yocto !


Avantages/inconvénients

● Avantages– Programmation Java (simple et répandue) + IHM

– Communauté importante

– Fait rêver les managers (tablette = grand public → bon marché)

● Inconvénients– Compatibilité POSIX partielle

– Système de « build » statique assez rudimentaire par rapport à ceux de Linux (Buildroot, OE)

– Qualité des BSP variable mais portage « simple »

– Pas réellement un projet libre ni communautaire :-(

– Google fait peur !

– Interfaces matérielles industrielles non supportées (CAN, I2C, SPI, …)


eCOS

● embeddable Configurable OS (CYGNUS 1997)● Supporte de nombreux CPU (16), 32 et 64 bits● Empreinte mémoire de 10 à 100 Ko● Outils de configuration avancé, gestion de «paquets»● Version « pro » par ● Utilisé dans le multimédia :

– http://www.ecoscentric.com/ecos/examples.shtml


RTEMS

● RTEMS = Real Time Executive for Multiprocessor Systems

● Initialement « Missile Systems » puis « Military Systems »

● Exécutif temps réel embarqué diffusé sous licence libre (GPL avec exception)

● Ce n'est pas exactement un système d'exploitation car l'application est « liée » au noyau → un seul processus mais plusieurs « threads »

● Programmation C, C++, Ada● Plus de 100 BSP disponibles pour 20 architectures● API RTEMS « classique » ou POSIX● Utilisé par EADS Astrium, ESA, NASA, etc.


RTEMS, suite

● RTEMS est un exécutif TR :– Un seul processus

– Beaucoup plus petit qu'un OS → en sélectionnant les composants on peut arriver à une taille de quelques dizaines de Ko :-)

– Pas (peu) de support MMU

– De nombreuses fonctionnalités sont optionnelles : réseau, système de fichiers, etc.

– Configuration statique de l'application

● Permet d'ajouter « facilement » API, ordonnanceur● Léger, environ 600K lignes pour la version 4.11 (15 M

pour le noyau Linux)


Les outils libres


Typologie des outils

● Outils de base → « toolchain » + mise au point → GCC, GDB, LLVM

● IDE → Eclipse (?)● Construction de distribution → Buildroot, Yocto/OE● Émulation / simulation → QEMU● Gestion de version (Git, SVN)

→ Les meilleurs de ces outils existent dans le monde du logiciel libre :-)


Production de distribution (Linux)

● Un outil crée la distribution à partir des sources des composants adaptés en appliquant des « patch »

● Il ne s'agit pas de distribution mais d'outil de création de distribution

● L'outil ne fournit pas les sources mais les règles de production et prend en compte les dépendances

● L'outil peut produire la chaîne de compilation croisée● L'outil produit les différents éléments de la distribution

– Image du bootloader

– Noyau Linux

– Images du root-filesystem

● Meilleure solution qu'une distribution « générique »– sécurité

– traçabilité


Les principaux outils disponibles

● Yocto/OpenEmbedded– Moteur écrit en Python

– Très puissant mais lourd

– Basé sur des fichiers de configuration

● Buildroot– Basé sur la commande « make »

– Au départ un démonstrateur pour uClibc

– Désormais un véritable outil, bien maintenu !

– Approche statique (pas de paquets)

● OpenWrt– Dérivé de BR

– Orienté vers les IAD (Internet Access Device)

– Gère les paquets binaires


Buildroot


Buildroot

● Lié au projet uClibc (micro-C-libc) = libC plus légère que la Glibc

● But initial: produire des root-filesystem simples pour tester uClibc

● Moteur uniquement basé sur des fichiers Makefile et quelques scripts-shell →utilisation de GNU-Make

● Outil de configuration utilise le langage Kconfig● Peut produire la chaîne de compilation (uClibc, Glibc,

Eglibc, ...) ou importer une chaîne existante ● Approche statique● Pas de version « officielle » avant 2009 (2009.02)


Buildroot aujourd’hui

● Repris en 2009 par Peter Korsgaard et Thomas Petazzoni

● Une version officielle tous les 3 mois: 2009.02, ... 2012.11, ..., 2015.02

● Projet géré sous Git : http://git.buildroot.net/buildroot● Bonne documentation :

http://buildroot.uclibc.org/docs.html● Plus de 1200 composants adaptés (2015.02)● Support CPU x86, ARM, PowerPC, SH4, ...● Il est désormais simple d’ajouter un support de carte

par des fichiers de configuration● Projets très dynamique !

http://git.buildroot.net/buildroot

http://buildroot.uclibc.org/docs.html


Yocto / OE

● Similaire à BR mais plus évolué et modulaire● Utilisé par les éditeurs pour leurs produits commerciaux

→ Wind River● Utilisé par les fabricants de matériel pour les BSP

(Board Support Package) → Freescale, Gumstix, TI, ...● Yocto n'est pas une distribution mais fournit des

« templates » et outils pour créer des distributions → « méta données » organisées en couches (layers)

– Support matériel (meta-intel, meta-raspberrypi)

– Distributions (meta-yocto, meta-angstrom)

– Composants « métier » (meta-ivi) → GENIVI

http://layers.openembedded.org/layerindex

It's not an embedded Linux distribution

– it creates a custom one for you

http://layers.openembedded.org/layerindex


Principe des « layers »


« Workflow » OE


Émulateur QEMU

● Émulateur de matériel initialement développé par Fabrice Bellard, diffusé sous GPL v2

● Exécuté dans l'espace utilisateur de Linux● Permet d'émuler diverses architectures: x86, PowerPC,

ARM, etc.● Émulation de carte complète → outil de

développement, mise au point, test automatique● Outil de certification DO-178 (Adacore/Couverture)

http://www.open-do.org/projects/couverture● Désormais, large communauté avec dépôt Git sur

http://git.savannah.gnu.org/cgit/qemu.git

http://www.open-do.org/projects/couverture

http://git.savannah.gnu.org/cgit/qemu.git


Open Hardware


(R)évolution du matériel

● Évolution du x86 vers ARM● Création d'un marché autour des « hobbyistes » en

électronique– Arduino, Raspberry Pi & friends

– Adafruit, Snootlab & friends

● Les professionnels utilisent parfois ces plate-formes ou du moins profitent de la baisse des coûts → attention au choix !

● Développement et conception simplifiés– généralisation d'un open-hardware pragmatique

– utilisation de modules CPU

– nouveaux langages (HTML5, Python)

● Nouveaux canaux de distribution et plate-formes de financement (kickstarter, ...)


Versatile PB and sons !

€€€€ !

< 20 €

< 30 €

< 25 €

< 15 €


Cependant...

● Certaines plate-formes génériques permettent de créer une « maquette » mais difficilement la version définitive → qualité insuffisante

● La connectivité nécessaire n'est pas toujours disponible– Wi-Fi

– BT

– Capteurs divers

● Un créateur n'est PAS un développeur logiciel et encore moins un intégrateur système → « fusion » art / design / technologie

● Quelques plates-forme dédiées sont désormais disponibles → WeIO (démo!)

● Pour l'industrie ne pas oublier la durée de maintenance !


Module WeIO


Co-design


Situation actuelle

● Les systèmes embarqués deviennent de plus en plus complexes

– Hier → RTOS mono-tâche (1 seule application)

– Aujourd'hui → système multitâche proche d'un OS classique (Linux, Android, …)

● Exemples de systèmes :– Encodeur / décodeur vidéo HD

– Système « mixte » temps réel et traitement des données (banc de test)

● Le CPU n'est pas forcément capable de répondre aux exigences fonctionnelles du système

● L'utilisation du multi-cœur améliore les choses mais décale le problème (et augmente prix + consommation)


Évolution de la conception

● On travaille maintenant au niveau système (ou fonctionnalité) et non au niveau porte logique

● Les fonctionnalités peuvent être implantées dans des composants spécifiques de type ASIC (Application Specific Integrated Circuit). On parle alors de Système sur Silicium « SoC » (System on Chip).

● Les fonctionnalités peuvent être implantées dans des composants logiques programmables de type FPGA (Field Programmable Gate Array). On parle alors de système « SoPC » (System on Programmable Chip).

● Le plus souvent le système dispose d'un CPU (avec OS) + d'un accélérateur matériel pour des tâches dédiés (compression, génération de signal, …)

● L'association des deux parties correspond au « co-design »


Exemple de système● Le processeur est en général externe→ SoC associé à

un FPGA ● Exemple de SoC : i.MX (Freescale), AM335x (TI)● Exemple de FPGA : Altera Cyclone, Xilinx

Spartan/Virtex ● Système hybride : Armadeus, Zynq


Avantages du co-design

● L'OS – et donc le CPU - est déchargé de tâches très coûteuses (voire inaccessibles) en calcul logiciel

● L'approche FPGA permet de garantir la souplesse → utilisation d'un langage de programmation (Verilog ou VHDL) → portabilité sur plusieurs modèles de FPGA

● Cette même approche garantit la propriété intellectuelle dans le cas de licences parfois contraignantes

– La fonctionnalité « métier » dans le FPGA

– Le pilote (GPL si Linux) est une simple interface

● On trouve des bibliothèques fonctionnelles (des « IP ») comme avec le logiciel classique → €€€ !

● Le co-design peut également concerner l'association µP (CPU) / micro-contrôleur reliés – par exemple - par un bus de type SPI


Association µC / Linux

● Cette approche « hybride » assure un faible coût en garantissant les performances


Système Linux « pur »

● Cette approche nécessite souvent un adaptation coté noyau → temps réel (Xenomai, PREEMPT-RT, …)


Choix du matériel

● Solution 1 :– Module type SoC

– FPGA ajouté à la carte finale

– Nécessite un design matériel

● Solution 2 :– Module SoC intégrant directement un FPGA

– Xilinx (Zynq), Altera, Armadeus APF27/APF51

– Pas (ou peu) de design matériel

– La demande du marché pousse ce type de solution


Cas d'exemple

● Un système nécessite une horloge de synchronisation (période = 1 ms)

– Réalisable sur certains systèmes (tâche périodique sur un GPIO) → Raspberry Pi/ARM + Linux-TR

– Impossible à réaliser sur d'autres architectures (x86) sans 1 carte PCI dédiée (€€€)

● Une solution hybride utilise :– Un système sous Linux (architecture x86, ARM, …) non

TR

– Un contrôleur matériel FPGA sur bus USB

– Simple à mettre en place en langage HDL

– Le calculateur Linux pilote le contrôleur par message USB mais ne gère pas le TR → insensible aux variations de charge


Raspberry Pi + FPGA

KNJN DragonPCI-E

Bugblat sur bus local

USB


Questions ?

les solutions libres pour les systèmes embarqués

Technology