Comment surmonter les obstacles de développement Linux dans les systèmes à ressources limitées

La technologie open-source offre aux développeurs de systèmes électroniques la possibilité de réduire les coûts, d'accélérer la mise sur le marché et d'étendre le cycle de vie des produits en éliminant les obstacles liés aux solutions propriétaires et en favorisant la collaboration. Aujourd'hui, les opportunités open-source couvrent l'ensemble de la pile système, depuis les systèmes d'exploitation jusqu'au matériel des ordinateurs monocartes (SBC) et à la propriété intellectuelle des semi-conducteurs.

Cependant, pour l'exécution de Linux sur des dispositifs à ressources limitées, tels que les systèmes d'IoT industriel (IIoT) et les systèmes robotiques, des exigences de calcul élevées, des risques de sécurité et des défis de latence déterministe subsistent.

Cet article aborde brièvement les défis auxquels sont confrontés les concepteurs lors du déploiement de Linux dans les systèmes à ressources limitées. Il présente ensuite l'ordinateur monocarte BeagleV-Fire de BeagleBoard.org, en combinaison avec Linux, et explique comment il peut optimiser la flexibilité des conceptions futures. Une démonstration de l'utilisation des BSP (Board Support Packages) open-source de Microchip Technology pour créer une configuration Linux initiale est incluse.

Défis du développement open-source dans les systèmes embarqués

L'adoption des technologies open-source dans le développement embarqué est bien établie. La conception matérielle et l'intégration logicielle sont accélérées par des ressources prêtes à l'emploi fournies par un vaste écosystème de fabricants et d'ingénieurs indépendants. Grâce à sa flexibilité, Linux est devenu une solution logicielle de premier plan pour les systèmes exigeant une connectivité réseau, des infrastructures d'applications de haut niveau et l'intégration de l'intelligence artificielle (IA).

Cependant, le déploiement de Linux sur des dispositifs à ressources plus limitées soulève des considérations supplémentaires :

• Exigences de calcul : les microcontrôleurs (MCU) traditionnels peinent à répondre aux exigences de mémoire et de stockage, même pour les distributions Linux minimales. À mesure que les développeurs ajoutent des services en arrière-plan pour prendre en charge les applications, les sous-systèmes et les frameworks d'espace utilisateur (USF), ces sous-systèmes consomment davantage de ressources, rendant les piles logicielles volumineuses non viables.
• Latence : les applications haute précision telles que la robotique et l'automatisation industrielle exigent une synchronisation prévisible pour la coordination des systèmes et la sécurité opérationnelle. Bien que la fonctionnalité PREEMPT_RT du noyau Linux améliore le déterminisme, les systèmes d'exploitation en temps réel (RTOS) dédiés offrent une latence et une surcharge moindres pour le matériel à ressources limitées.
• Sécurité : les systèmes embarqués déployés dans les environnements publics sont exposés à un risque d'accès non autorisé, rendant indispensables des mesures de sécurité standard telles que le démarrage sécurisé, l'inviolabilité et la racine de confiance (RoT) matérielle. De plus, des réglementations telles que le règlement sur la cyberrésilience (CRA) de l'UE imposent que les produits comportant des éléments numériques soient sécurisés dès leur conception.
• Alimentation : les dispositifs périphériques fonctionnent souvent dans des environnements distants avec des ressources énergétiques limitées. Un meilleur rendement énergétique peut étendre la durée de vie des batteries ou permettre un fonctionnement à partir de sources d'énergies ambiantes. De même, un meilleur rendement énergétique peut simplifier la gestion thermique et améliorer les performances par watt, favorisant ainsi le traitement périphérique avancé.
• Gestion du cycle de vie : le règlement CRA exige que les dispositifs numériques soient pris en charge pendant au moins 5 ans, bien que de nombreux déploiements industriels requièrent une disponibilité des produits de 10 à 15 ans. Ainsi, pour garantir une prise en charge constante du noyau Linux, les développeurs doivent prévoir la capacité de mise à niveau et la disponibilité du matériel.

Pour surmonter ces défis, les développeurs peuvent s'appuyer sur des ressources supplémentaires issues des écosystèmes Linux embarqué et open-source, et tirer parti des combinaisons matériel-logiciel rationalisées de Linux pour les applications périphériques en évolution rapide.

Implémentation Linux avec SBC ouverts et RISC-V

Bien que les distributions Linux à usage général permettent de préparer rapidement les applications, elles incluent souvent des paquets et des services qui ne sont pas nécessaires pour le projet en question. À l'inverse, le projet Yocto, basé sur OpenEmbedded, permet aux développeurs de créer des images Linux personnalisées adaptées à des cas d'utilisation spécifiques. Cela élimine les fonctionnalités inutiles, permettant ainsi à des distributions légères de fonctionner sur du matériel aux ressources limitées tout en conservant des capacités avancées, telles que la vision par ordinateur assistée par IA ou la maintenance prédictive via des outils standard.

De plus, le projet Yocto offre aux développeurs les capacités suivantes :

• Versions reproductibles pour maintenance à long terme
• Configuration de noyau personnalisée pour améliorer les performances, la sécurité et la réactivité
• Intégration de couches spécifiques à la carte pour garantir la compatibilité matériel-logiciel et réduire le temps de développement

L'intégration simple avec des mécanismes de mise à jour OTA (Over-The-Air) tels que SWUpdate, RAUC et Mender aide également les développeurs à améliorer régulièrement les performances et la sécurité des dispositifs tout au long de leur cycle de vie. De ce fait, le projet Yocto est désormais devenu la norme pour les systèmes Linux embarqués.

De même, les ordinateurs monocartes open-source sont utilisés depuis longtemps pour accélérer le développement d'applications Linux, fournissant une plateforme de référence prête à l'emploi qui combine des ressources de traitement, de mémoire, de stockage et d'E/S dans un facteur de forme autonome. Grâce aux SBC ouverts, les développeurs peuvent rapidement prototyper un système, valider leur pile logicielle, puis passer à un matériel personnalisé avec un minimum de modifications.

L'architecture de jeu d'instructions (ISA) à norme ouverte RISC-V va encore plus loin en permettant aux concepteurs de systèmes de créer des plateformes de traitement personnalisées sans frais de licence coûteux. Avec RISC-V, les concepteurs peuvent choisir les parties du jeu d'instructions à inclure et même les étendre pour répondre à leurs cas d'utilisation spécifiques. Les conceptions originales ayant été créées sous licence BSD (Berkeley Software Distribution), les projets dérivés peuvent être soit ouverts et gratuits, soit fermés et propriétaires.

Pour les développeurs et les architectes, le projet Yocto, les SBC ouverts et RISC-V réduisent la dépendance aux feuilles de route d'un seul fournisseur, augmentant ainsi la flexibilité de conception à long terme. De plus, le soutien en amont croissant pour RISC-V dans Linux et l'adhésion Platinum de RISC-V dans le projet Yocto soulignent l'intérêt de la communauté Linux embarqué.

SBC RISC-V hautes performances pour intégration Linux compacte

L'ordinateur monocarte BeagleV-Fire open-source de BeagleBoard.org (Figure 1) offre une plateforme compacte et riche en E/S pour relever ces défis. Avec un système sur puce (SoC) FPGA PolarFire de Microchip, il fournit un fonctionnement écoénergétique, des fonctionnalités de sécurité matérielle et un ensemble de processeurs RISC-V cohérent prenant en charge les applications Linux exécutant des charges de travail en temps réel. Les développeurs peuvent utiliser le SBC pour prototyper des contrôleurs robotiques, des passerelles industrielles, des accélérateurs Edge AI et des plateformes E/S personnalisées reposant sur Linux embarqué.

Figure 1 : Le BeagleV-Fire de BeagleBoard.org offre une plateforme SBC compacte permettant d'intégrer des technologies open-source dans des systèmes embarqués. (Source de l'image : BeagleBoard.org)

La plateforme compacte mesure 86,38 mm × 54,61 mm × 18,8 mm et elle est architecturée autour du SoC PolarFire écoénergétique MPFS025T-FCVG484E. Elle est dotée d'une architecture multicœur cohérente avec quatre cœurs d'application RV64GC pour exécuter Linux et un cœur de surveillance RV64IMAC pour gérer les fonctions de bas niveau.

Pour maximiser les performances et garantir la précision des données entre les cœurs, le SoC PolarFire fournit un cache L2 partagé, un sous-système de mémoire cohérent et un contrôleur de mémoire DDR intégré pour prendre en charge 2 Go de mémoire LPDDR4 embarquée. Les applications complexes sont en outre prises en charge par le stockage eMMC de 16 Go et la mémoire Flash SPI de 128 Mb du BeagleV-Fire.

Outre le sous-système de processeur RISC-V, le SoC PolarFire intègre une structure FPGA (Figure 2) qui permet aux développeurs de créer des chemins de traitement déterministes pour les applications en temps réel à faible latence et d'implémenter une accélération matérielle personnalisée pour les pipelines d'inférence IA. En tant que partie intégrante du système complet, cette structure abrite 23 000 éléments logiques et ses propres ressources supplémentaires, lui permettant de fonctionner indépendamment des cœurs de traitement principaux.

Figure 2 : La gamme de SoC PolarFire de Microchip combine plusieurs cœurs de traitement RISC-V avec une structure FPGA polyvalente pour les charges de travail déterministes. (Source de l'image : Microchip Technology)

Avec de multiples options de démarrage sécurisé, les fonctionnalités de sécurité matérielle intégrées du SoC PolarFire permettent aux développeurs de mettre en œuvre un modèle de sécurité en profondeur, ce qui en fait une plateforme utile pour répondre aux exigences de cybersécurité modernes. Ces fonctionnalités incluent les suivantes :

• Racine de confiance matérielle immuable via une fonction physique inclonable (PUF)
• Stockage sécurisé des clés avec mémoire programmable une seule fois (OTP) ou stockage non volatil sécurisé utilisant des UDS (Unique Device Secrets) et un contrôle d'accès aux clés basé sur le matériel
• Module inviolable

En outre, le BeagleV-Fire intègre plusieurs ports physiques pour créer un système prêt pour les applications dans lequel des distributions Linux personnalisées peuvent être vérifiées et testées (Figure 3). Ces ports incluent un port RJ45 Gigabit Ethernet, un port USB Type-C pour l'alimentation et la connectivité, un connecteur M.2 clé E, deux embases Cape compatibles BeagleBone à 46 broches pour une extension supérieure de l'écosystème et une interface CSI (Camera Serial Interface) pour une intégration directe. Une empreinte JTAG TAG-CONNECT est fournie pour le débogage, et le BeagleV-Fire prend également en charge l'extension compatible SYZYGY pour les périphériques orientés FPGA.

Figure 3 : Malgré son empreinte compacte, le BeagleV-Fire de BeagleBoard.org offre plusieurs ports physiques pour l'interfaçage immédiat d'applications. (Source de l'image : BeagleBoard.org)

Comment créer une configuration Linux initiale sur le SBC BeagleV-Fire

Lors de la création d'une distribution Linux légère pour le BeagleV-Fire, les développeurs doivent d'abord obtenir une couche BSP appropriée du projet Yocto. Elle fournit la configuration U-Boot, la configuration de noyau Linux par défaut, les arborescences de dispositifs pour la prise en charge de la carte et les définitions de prise en charge des périphériques. Un référentiel GitHub prend en charge tous les BSP des kits d'évaluation SoC PolarFire, y compris le BeagleV-Fire.

Une fois toutes les dépendances requises du projet Yocto installées, les couches suivantes fournissent la base de la version et devront être clonées :

• bitbake
• meta-openembedded-core
• meta-yocto (pour la distribution de référence Poky)
• meta-mchp-common
• meta-mchp-polarfire-soc/meta-mchp-polarfire-soc-bsp
• meta-mchp-polarfire-soc/meta-mchp-polarfire-soc-community
• Couches supplémentaires requises par le projet

Ensuite, une image minimale peut être créée en utilisant la cible de MACHINE = "beaglev-fire" et un fichier de configuration kas. La Liste 1 présente une configuration d'exemple :

Copier
header:
  version: 19
 
repos:
  openembedded-core:
    url: git://git.openembedded.org/openembedded-core.git
    # yocto-5.0.15
    commit: 6988157ad983978ffd6b12bcefedd4deaffdbbd1
    layers:
      meta:
 
  bitbake:
    url: git://git.openembedded.org/bitbake.git
    # yocto-5.0.15
    commit: 8dcf084522b9c66a6639b5f117f554fde9b6b45a
    layers:
      bitbake: disabled
 
  meta-yocto:
    url: git://git.yoctoproject.org/git/meta-yocto.git
    # yocto-5.0.15
    commit: 9bb6e6e8b016a0c9dfe290369a6ed91ef4020535
    layers:
      meta-poky:
      meta-yocto-bsp:
 
  meta-mchp:
    url: https://github.com/linux4microchip/meta-mchp.git
    branch: scarthgap
    path: layers/third-party/meta-mchp
    layers:
      meta-mchp-common:
      meta-mchp-polarfire-soc/meta-mchp-polarfire-soc-bsp:
      meta-mchp-polarfire-soc/meta-mchp-polarfire-soc-community:
 
machine: beaglev-fire
 
 
local_conf_header:
  Users: |
    EXTRA_IMAGE_FEATURES = "allow-empty-password empty-root-password \
allow-root-login"

Liste 1 : Exemple de fichier de configuration créant tous les artefacts requis pour le démarrage du BeagleV-Fire dans un shell simple. (Source de la liste : Microchip Technology)

L'exécution de "kas build core-image-minimal" crée ensuite tous les artefacts requis pour le démarrage du BeagleV-Fire dans un shell simple, y compris les binaires U-Boot et une image FIT contenant le noyau Linux et les modules, l'arborescence de dispositifs et le système de fichiers racine.

Après avoir créé une image Linux minimale pour le BeagleV-Fire à l'aide du projet Yocto, il est alors possible de suivre les procédures standard pour créer une image personnalisée et adapter la version aux exigences exactes du projet. En robotique et dans les systèmes industriels, par exemple, Linux est souvent utilisé conjointement avec un système d'exploitation en temps réel plus traditionnel, tel que FreeRTOS ou Zephyr, pour permettre un traitement avancé parallèlement à des opérations critiques en termes de temps. Cette fonctionnalité est bien prise en charge par le SoC PolarFire de BeagleV-Fire, qui peut être configuré pour exécuter simultanément plusieurs systèmes d'exploitation ou applications sans système d'exploitation.

Étant donné que de nombreux dispositifs embarqués requièrent une durée de vie de 10 ans ou plus, la combinaison de l'architecture ISA RISC-V ouverte, de Linux et de la reproductibilité basée sur Yocto permet aux plateformes basées sur des SoC PolarFire de s'adapter aux menaces de sécurité émergentes et aux nouvelles exigences applicatives grâce à des mises à jour OTA ou locales régulières. C'est pourquoi le SBC BeagleV-Fire constitue un excellent point de départ pour l'adoption open-source, en renforçant la flexibilité et la longévité des systèmes périphériques intelligents.

Conclusion

Les limites de calcul, les exigences de latence déterministe, l'exposition aux risques de sécurité et les exigences de cycle de vie étendu peuvent présenter des défis légitimes lors de l'exécution de Linux dans les systèmes embarqués à ressources limitées. Le SBC BeagleV-Fire de BeagleBoard.org fournit une architecture hybride qui combine les capacités RISC-V Linux avec une logique déterministe basée sur FPGA et des fonctionnalités de sécurité matérielle pour surmonter ces défis. Associée au projet Yocto et aux couches BSP open-source de Microchip, cette plateforme permet aux développeurs de créer des distributions Linux sur mesure et traçables, optimisées pour les applications d'edge computing, IIoT et de robotique à longue durée de vie.