Programmation embarquée sur Raspberry Pi sans sonde JTAG

En situation de développement embarqué, la Raspberry Pi (RPi) est appelée « système cible » (target), tandis que le poste de travail est appelé « système hôte » (host). L’hôte doit donc programmer le système cible à distance (remote) via un moyen de communication dédié. À noter également que nous sommes dans une situation de développement croisé : la RPi, bare-metal et architecture ARM, ne correspond pas au système hôte, couramment muni d’une architecture Intel avec un système d’exploitation (OS). Il convient donc d’utiliser une chaîne d’outils croisés pour produire et manipuler un programme cible depuis un système hôte.

Pour ce faire, nous déploierons d’abord sur le poste de travail la chaîne d’outils GNU croisés, arm-none-eabi, incluant le compilateur GCC et le débuggeur GDB, puis embarquerons le serveur GDB freemium Alpha directement sur la RPi, et l’utiliserons comme moyen de développement afin de développer et d’embarquer, avec la seule aide de GDB, une série d’exemples de programmes C standards allant du simple Hello World sur la sortie standard, au plus avancé raytracer utilisant le processeur graphique (GPU) pour produire des images sur la sortie HDMI de la RPi. Nous finirons enfin par embarquer le raytracer directement sur la RPi, pour qu’il soit démarré par son bootloader, comme si nous passions en production une fois le développement terminé.

1. Installation

1.1 Poste de travail

Un poste de travail POSIX (GNU/Linux, Cygwin, OS X...) est nécessaire. Il exécutera la compilation croisée ARM pour RPi, ainsi que le client GDB. Les droits de lecture et écriture sont également nécessaires sur l’interface de communication employée et décrite plus bas.

Un dépôt git est mis à disposition : il contient les éléments nécessaires pour la suite (et pour échanger sur https://github.com/farjump/raspberry-pi en cas de problème). Les commandes ci-dessous permettent de le cloner :

Optionnellement, les plus modernes d’entre nous apprécieront certainement la commande make shell qui produit directement le poste de travail attendu dans un container docker basé sur Debian 9, puis y lance un terminal dans lequel peut s’exécuter de manière garantie la suite de l’article.

1.1.1 Chaîne de compilation croisée ARM

ARM distribue la chaîne de compilation croisée pour les principaux systèmes d’exploitation au format 64 bits uniquement [1]. Le script scripts/install-toolchain.sh, fourni dans le dépôt, télécharge et décompresse la version Linux 64 bits de la chaîne :

Compte tenu du succès de l’architecture ARM, les distributions les plus courantes (Debian, Archlinux, Fedora, etc.) la mettent aussi directement à disposition dans leurs gestionnaires de paquets, toujours en partie nommée avec le triplet arm-none-eabi. Pour OS X et Windows, il convient d’adapter les étapes précédentes à la distribution officielle ARM [1] en la déployant dans votre environnement.

1.2 Raspberry Pi

1.2.1 Carte microSD

La RPi démarre le programme qu’elle trouve sur sa carte microSD suivant les directives contenues dans le fichier de configuration config.txt. Le serveur GDB Alpha doit donc être copié sur la carte microSD pour être démarré à l’allumage de la RPi.

L’étape décrite ici simplifie au maximum la préparation de la carte microSD pour la RPi et son bootloader. Elle suppose une carte microSD vierge compatible avec la RPi. Un script d’aide à son installation est fourni, mais l’étape de formatage en FAT32, attendu par le firmware et le bootloader de la RPi, est laissée explicite afin d’insister sur le caractère irréversible de cette opération destructrice pour la carte microSD. Enfin, le script scripts/install-rpi-boot.sh installe le firmware, le bootloader et Alpha sur la carte microSD :

La carte microSD est alors prête à l’emploi et la RPi y trouvera tout le nécessaire pour démarrer le serveur GDB. À son prochain démarrage, le firmware, ayant pour tâche d’initialiser le processeur et sa carte, lira les directives contenues dans le fichier config.txt indiquant que le programme Alpha.bin doit être copié à l’adresse d’exécution 0x7F0_8000, point d’entrée du serveur.

1.2.2 Interface de communication GDB

Une fois le serveur GDB en cours d’exécution, celui-ci attend la connexion d’un client GDB et ses commandes, en écoutant une interface de communication. Le serveur GDB Alpha utilise l’interface série Mini-UART, car commune à toutes les versions de la RPi. Le port de cette interface n’étant pas disponible tel quel sur un poste de travail standard, il est nécessaire d’interposer un convertisseur entre les deux.

Du coté poste de travail, les ports séries sont les ports USB (et RS232 pour les plus anciens). Du côté RPi, l’interface Mini-UART, présente sur le connecteur GPIO (figure 3), se décompose en trois broches TTL 3.3 Volts. Il est donc nécessaire d’utiliser un convertisseur UART TTL 3.3V vers USB. Attention à bien utiliser un modèle 3.3V.

Une fois relié au poste de travail par un câble USB, le convertisseur est géré par l’OS et son driver de périphériques série, dont les points de montage possibles sont /dev/ttyUSBx ou bien /dev/ttyACMx pour Linux, COMx pour Windows, ou encore /dev/cu.usbserial-xxxxxx pour OS X. Pour la suite de cet article, /dev/ttyUSB0 désignera notre port série de communication GDB.

Le coût total du montage avoisine les 9€ et nécessite l’achat d’un convertisseur [2], de trois câbles jumper femelle [3] ainsi que d’un câble USB [4]. Des montages complets, couramment nommés « câbles TTL », plus compacts et incluant les câbles, sont aussi disponibles, mais à des prix beaucoup plus aléatoires [5].

2. Éditer, compiler & débugger

Nous sommes désormais prêts à utiliser GDB comme moyen de développement embarqué. Mais contrairement à une utilisation classique de GDB, dite « native », où le programme à exécuter et débugger est au préalable préparé par le système d’exploitation, il est nécessaire ici d’effectuer explicitement ces mêmes étapes préliminaires : téléchargement du programme sur la cible une fois la connexion distante établie. Le mode client/serveur de GDB offre en effet au serveur la possibilité de supporter la commande load qui prend alors directement en charge le format d’exécutable ELF et en télécharge les sections de code et de données sur la cible, puis place finalement le pointeur sur instruction sur son point d’entrée. Les sections de debug sont quant à elles lues et chargées par le client GDB et lui permettent d’apporter les fonctionnalités de debug de code et de données depuis le code source (source-level debugging).

Une session de debug d’un logiciel embarqué commence donc souvent par :

Il est ensuite possible de profiter des fonctionnalités élémentaires de debug de code et de données. Les fonctionnalités plus avancées dépendent quant à elles du serveur. Par exemple, la version freemium d’Alpha, le serveur GDB utilisé, n’implémente pas les tracepoints [6], mais implémente l’extension File I/O [7] (dont l’utilité sera révélée par la suite). GDB signalera au final son incapacité à exécuter une commande si le serveur n’en est pas capable.

De plus, Alpha met en place un environnement d’exécution permettant un développement bare-metal plus simple et dont le programme embarqué via GDB peut alors profiter. Alpha initialise en effet le processeur plus vastement que le bootloader de la RPi en activant, par exemple, l’unité flottante ou encore en programmant un espace mémoire (figure 7). Ceci doit donc être pris en considération lorsque GDB n’est plus utilisé pour charger le programme, qui doit alors lui-même effectuer les initialisations dont il a besoin. Il en est de même pour toutes les fonctionnalités nécessaires et en dehors du périmètre de cet environnement d’exécution.

Enfin, il ne sera pas nécessaire de redémarrer manuellement la RPi entre chaque session de debug puisqu’Alpha effectue un reset du processeur lorsque GDB lui transmet la commande kill. Cette commande est aussi induite par toutes celles impliquant, en debug natif, l’arrêt du processus, et notamment celle de connexion distante target remote <interface>, ainsi que la commande quit lorsque GDB est quitté. Relancer l’un des scripts GDB qui suit ou bien quitter GDB (correctement) implique donc un reset de la RPi, permettant ainsi de repartir depuis l’état zéro du processeur et d’éviter les effets de bord indésirables d’une session à une autre. À noter que le reset est observable grâce aux LED situées sur la RPi.

Toutes les sessions de debug présentées par la suite utilisent exclusivement l’interface ligne de commandes de GDB (CLI). Il est toutefois conseillé de profiter de son interface texte, TUI [8], et ce à tout moment, grâce à la commande tui enable (figure 8).

2.1 Hello World

2.1.1 Compilation

Soit le programme :

Malgré les apparences, ce programme n’est en rien anodin. Il fait en effet appel à des fonctions de la bibliothèque C standard alors qu’elles nécessitent normalement un système d’exploitation, absent dans le cas présent. Il y a d’une part l’initialisation de l’environnement d’exécution (runtime) C préalable à l’appel de la fonction main() (initialisation de la pile et des données), et d’autre part l’écriture sur la sortie standard par printf().

Pour ce faire, les fonctions et appels systèmes nécessaires sont implémentés dans la mesure du possible dans le contexte bare-metal. GDB bénéficie d’une fonctionnalité peu connue que le serveur GDB peut optionnellement implémenter pour transmettre et déléguer au client les appels système, alors exécutés sur le poste de travail sur lequel le client GDB s’exécute. Ainsi, printf()utilise l’appel système write() qui est communiqué et délégué au client tel quel, pour écrire donc finalement sur la sortie standard du client GDB, sur le poste de travail.

Cette astuce n’est possible qu’avec un nombre restreint d’appels systèmes [9] dont les capacités sont parfois limitées par GDB (ex. : ouvrir un fichier spécial), tandis que d’autres pourront être implémentés très simplement sans aucune aide d’un système d’exploitation ou de GDB (ex. : brk() pour malloc()).

Cette fonctionnalité de GDB s’appelle File I/O [7] et est implémentée par Alpha. Nous l’interfaçons avec la bibliothèque C newlib en remplaçant ses appels systèmes par des appels à Alpha (figure 9). Cette bibliothèque C est la seule, avec la bibliothèque C GNU glibc, à s’intégrer officiellement dans la chaîne de compilation GCC, ce qui en rend l’utilisation aussi aisée qu’en compilation native : compiler un programme est aussi simple et direct que arm-eabi-none-gcc <cppflags> <cflags> <ldflags> -o main.elf main.c <libs>. Le résultat final est la possibilité d’embarquer n’importe quel programme C standard.

Pour compiler le programme :

L’option –gN permet d’activer la génération des informations de debug du programme, où N est le niveau d’informations souhaité allant de   (désactivation) à 3 (maximum). L’option -ggdb permet quant à elle d’activer les extensions spécifiques à GDB.

2.1.2 GDB

Il est conseillé d’écrire ces commandes, préalables à toute les prochaines sessions de debug, dans un fichier que GDB pourra alors lire et exécuter via l’option de lancement -x <fichier>, ou la commande source <fichier>. Le fichier run.gdb, dont le TTY doit être ajusté selon le cas, est à ce titre fourni à la racine du dépôt.

Ou encore :

Nous pouvons alors le laisser s’exécuter et observer la sortie standard sur la console GDB :

Ou encore l’exécuter au pas-à-pas :

Les fonctionnalités de GDB se classent en deux grandes catégories : le debug de code et le debug de données. Entre autres, il est possible de visualiser la pile d’appel, de lire/écrire les données, les registres et la mémoire. Mais aussi d’insérer des breakpoints, d’intercepter des appels de fonctions à l’aide de breakpoints conditionnels…

Il est également possible d’envoyer des commandes spécifiques au serveur GDB via la commande monitor <commande>, lui permettant d’implémenter ses propres commandes. Par exemple, ici, la capture d’exceptions :

Cet exemple de programme constitue donc un point de départ idéal pour une exploration plus approfondie des possibilités de GDB et/ou du développement embarqué sur RPi. Le lecteur peut laisser libre cours à son imagination pour exploiter d’autres fonctions de la bibliothèque C (ex. : scanf(), fopen()...) ou en utilisant d’autres exemples de programmes C standards à embarquer sur la RPi en se reposant sur la bibliothèque C fournie (ex. : la runtime C++).

2.2 Raytracer

Cet exemple est une nouvelle illustration des concepts vus jusqu’à présent et appliqués cette fois-ci à un programme exploitant de manière plus avancée la RPi. Il utilise en effet son unité flottante ainsi que son GPU. Nous finirons avec sa « mise en production » sur la carte microSD de la RPi pour qu’il démarre de manière autonome, sans aucune intervention de GDB.

2.2.1 Compilation

Ce raytracer affiche sur la sortie HDMI les images calculées par l’algorithme de raytracing (figure 10), contrôlé par le GPU, lui-même commandé par le processeur ARM à travers des requêtes échangées par mailbox [10]. Le calcul se fait pixel par pixel et les résultats sont écrits dans le framebuffer alloué par le GPU. Le fichier VC.c contient le code source des fonctions d’affichage graphiques : une fonction pour demander au GPU de préparer un framebuffer, et une seconde fonction pour récupérer son adresse. Le framebuffer consiste alors en une matrice de pixels à écrire au format 32 bits ARGB.

Pour le compiler :

Cet exemple introduit aussi le niveau d’optimisation g avec l’option -Og qui permet d’optimiser le programme tout en conservant une qualité de debug du programme acceptable. Elle évite donc les optimisations les plus agressives qui entraînent trop de perte de traçabilité entre le code objet et son code source. L’expérience de debug est quoi qu’il en soit dégradée (par exemple, impossibilité de lire certaines variables, exécution au pas-à-pas du code réordonnancé, etc.) par rapport à un programme compilé sans aucune optimisation.

2.2.2 GDB

Nous allons utiliser GDB afin d’observer le fonctionnement de l’algorithme de raytracing en employant les moyens de modification dynamique des données du programme.

Démarrer d’abord la session de debug :

Les temps de traitement longs du raytracer et sa boucle infinie de rendu vidéo sont de parfaits candidats à la fonctionnalité d’interruption asynchrone de l’exécution de la cible, c’est-à-dire tandis qu’elle exécute le raytracer, lorsque le client reçoit le signal <Ctrl> + <c> (SIGINT). Cette fonctionnalité repose sur une interruption matérielle qui nécessite donc de démasquer les interruptions externes du processeur. Pour ce faire, nous utilisons les fonctionnalités de modification des registres ainsi que de scripting GDB, dont la syntaxe des expressions est identique à celle du langage C. Le registre en question est en plus l’un des registres superviseurs, absents du mode GDB « natif », mais ici communiqué par Alpha :

Nous sommes désormais en mesure d’interrompre à tout moment l’exécution du raytracer sur la RPi :

Nous reprenons alors la main avec GDB où le programme a été interrompu. Voici donc un exemple modifiant successivement la couleur d’une sphère :

2.2.3 Embarquement

Nous souhaitons finalement embarquer le programme et qu’il s’exécute automatiquement au démarrage de la RPi sans avoir besoin d’utiliser GDB pour le charger. Nous allons donc l’interfacer avec le bootloader de la RPi qui charge puis exécute le contenu de la carte microSD, selon les directives contenues dans le fichier config.txt. En l’absence de ce fichier, le comportement par défaut copie le fichier kernel.img dans la RAM à l’adresse 0x8000 et lance l’exécution à cette adresse.

Il est avant tout nécessaire de prendre en compte les dépendances avec l’utilisation de GDB (ex. : File I/O) ou du serveur Alpha (ex. : mapping mémoire). Si nécessaire, il convient alors de les implémenter. Ainsi, nous avons fait le choix arbitraire de profiter du comportement par défaut du bootloader pour placer à l’adresse 0x8000 un second point d’entrée contenant le code d’initialisation, puis invoquant le point d’entrée de la runtime C _start. D’autres solutions sont parfaitement envisageables et le code source de cette implémentation est fourni à titre d’exemple dans sdk/CPU_start.S.

Pour générer kernel.img et le copier sur la carte microSD :

Insérez à nouveau la carte microSD dans la RPi. Celle-ci démarre directement avec le raytracer sans plus aucune intervention de GDB.

Enfin, le fichier kernel.img, forme purement binaire de l’exécutable raytracer.elf, ne contient plus aucune information de debug. Il n’est donc plus possible de le débugger depuis le code source en tant que tel, mais uniquement sous forme binaire désassemblée par GDB (layout asm). Il est toutefois possible d’obtenir les informations de debug dans un fichier séparé. Le fichier kernel.dbg généré à ses côtés par la commande de compilation précédente contient toutes les informations de debug de kernel.img. Pour finir, voici comment les utiliser :

Dans cet exemple, nous faisons manuellement ce que la commande load effectuait pour nous depuis le fichier ELF raytracer.elf. Les deux méthodes sont d’ailleurs strictement équivalentes dans le cas présent qui ne comporte aucune autre distinction que les formats des fichiers raytracer.elf et kernel.img: tous deux contiennent le même programme binaire.

Ce dernier exemple est un moyen de distribuer le programme tout en conservant les informations de debug. Il constitue le point de départ d’une possible stratégie de support et maintenance d’une distribution binaire d’un programme embarqué.

Conclusion

Nous nous sommes donc totalement affranchis du coût et de la complexité que peut représenter une sonde JTAG. Maîtriser un tel équipement est une tâche complexe, souvent attribuée aux professionnels les plus aguerris. L’utilisation de GDB, couplée à une implémentation du serveur entièrement logicielle, facilite la démocratisation et la simplification du développement embarqué au quotidien. L’effort nécessaire pour mettre en œuvre le serveur relève strictement des mêmes compétences que celles du développement embarqué. GDB est en plus le débugger bénéficiant de la plus large communauté en ligne, et tout étudiant en informatique sait par exemple l’utiliser après avoir débuggé son premier programme C ou C++. Depuis les choix d’architecture en phases amont de R&D jusqu’à la vérification et la validation d’un logiciel embarqué complet en phase de production, chacun peut trouver son compte parmi les fonctionnalités de GDB. Les sondes restent néanmoins nécessaires dans certains cas bien précis, comme le debug des firmwares, le debug spécialisé de certaines unités processeur (ex. : lire/écrire des caches internes) ou encore le debug temps réel de bus rapides (ex. : debug PCIe).

Les opportunités sont désormais nombreuses sur ce terrain de jeu RPi. Comprendre le mode superviseur ARM, développer du logiciel bare-metal haute performance, ou encore découvrir les interfaces SPI ou USB, sont tout autant de sujets bas niveaux et universels à explorer.

Références

[1] Distribution ARM officielle de la toolchain GNU sur https://developer.arm.com/open-source/gnu-toolchain/gnu-rm

[2] Exemple de convertisseur seul sur http://amzn.eu/3H5FIx9

[3] Exemple de câbles jumper sur http://amzn.eu/jiuRBbi

[4] Exemple de câble USB pour le convertisseur [1] sur http://amzn.eu/ihFNmFf

[5] Exemple de convertisseur format « câble » sur http://amzn.eu/flbbyHF

[6] Documentation des tracepoints sur https://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html

[7] Documentation de l’extension File I/O de GDB sur https://sourceware.org/gdb/onlinedocs/gdb/File_002dI_002fO-Remote-Protocol-Extension.html

[8] Documentation de l’interface texte sur https://sourceware.org/gdb/onlinedocs/gdb/TUI.html

[9] Liste des appels système supportés sur https://sourceware.org/gdb/onlinedocs/gdb/List-of-Supported-Calls.html

[10] Documentation du framebuffer du SoC BCM2835 sur http://elinux.org/RPi_Framebuffer