Développer sur microcontrôleur sans microcontrôleur : les émulateurs

Il est bien connu que les développeurs de matériel n’aboutissent jamais à temps à faire fonctionner leur circuit. Que ce soit une erreur de routage, un problème d’approvisionnement ou de réalisation de circuit, le matériel n’est jamais disponible à temps. En attendant, le développeur de logiciel attend... ou pas. Nous allons présenter quelques émulateurs de processeurs, dans un contexte un peu plus serein que la lutte fratricide des hardeux contre les softeux : un émulateur permet de sonder l’état de registres difficilement accessibles sinon (traceur de signaux dans l’émulateur ATmega), voire de conseiller le développeur dans sa stratégie d’initialisation des signaux (horloges dans l’émulateur qemu appliqué au STM32). Cependant, un émulateur n’est jamais aussi bon que sa capacité à convenablement émuler les signaux du microprocesseur, et l’open source prend une fois de plus tout son sens pour corriger des dysfonctionnements : nous corrigerons un signal mal implémenté, qui se traduit par le blocage d'une bibliothèque populaire pour les programmeurs sur processeur ARM. Finalement, nous verrons que l’émulateur permet d’appréhender des architectures encore balbutiantes (RISC-V) ou moins courantes (MIPS) que les x86/ARM dont nous sommes abreuvés quotidiennement.

L’objectif de cet article est d’illustrer l’utilisation d’émulateurs, pour permettre au lecteur ne possédant pas de matériel de se familiariser avec le développement sur microcontrôleurs. Les trois cibles logicielles sont la programmation bas-niveau en C (baremetal), la surcouche FreeRTOS, qui permet d’appréhender les concepts de gestion de tâches et de la cohérence de l’accès concurrent aux ressources et finalement GNU/Linux, embarqué sur cibles MIPS et ARM. Nous suivons ainsi une évolution « logique » des niveaux d’abstraction, en partant du plus bas niveau pour élever l’abstraction vers les environnements exécutifs, puis le système d’exploitation.

Appréhender une nouvelle architecture prend un peu de temps et de patience, pour se familiariser avec les divers registres et subtilités d’une architecture donnée. Alors qu’un petit microcontrôleur 8-bits, tel que le Atmel (maintenant Microchip) ATmega n’a pas beaucoup de surprise à livrer autre que son architecture Harvard, un ST Microelectronics STM32 est bien plus surprenant, avec sa granularité fine de distribution d’horloges désactivées par défaut. RISC-V vient d’exploser aux yeux du grand public, tandis que ARM continue à lutter avec MIPS et SPARC : maîtriser ces architectures est gage de liberté et de capacité à sélectionner la meilleure plateforme pour un objectif donné. Ces diverses architectures peuvent se tester sur émulateur avant d’investir dans du matériel, tel que nous le verrons ici.

1. Microcontrôleur 8 bits ATmega32U4

1.1 Le simulateur simavr

simavr (http://github.com/buserror/simavr, aussi disponible en paquet Debian, mais d’un intérêt discutable si on n’en consulte pas les sources) est un simulateur de microcontrôleurs Atmel d’architecture Harvard (ATmega) incluant l’ATmega32U4, qui équipe les plateformes Olimexino32U4 que nous utilisons pour l’enseignement introductif aux microcontrôleurs en Licence3. Ainsi, l’émulateur offre un outil pédagogique indéniable, car sans prétendre pallier la manipulation sur plateformes expérimentales open hardware au coût modeste (13 euros/unité), il permet de reproduire chez soi les travaux pratiques ne faisant pas appel à une interaction avec le matériel. simavr est de plus capable de générer des traces exactes en temps pour suivre l’évolution de signaux internes au microcontrôleur – fonction supportée par les sondes JTAG pour les microcontrôleurs équipés de cette fonction (broches partagées avec le port F sur l’ATmega32U4), mais avec une souplesse additionnelle de pouvoir intercepter une manipulation erronée de registres non initialisés, par exemple.

Prenons un programme trivial chargé de faire clignoter une LED connectée à une broche de port d’entrée-sortie généraliste (GPIO), ici la broche 5 du port C :

Générer les traces indiquant l’évolution d’un signal interne nécessite l’ajout, dans le code source du programme à destination du microcontrôleur, d’un en-tête déclarant les signaux à observer de la forme :

Ceci ne sera pas compilé dans le binaire final à destination du microcontrôleur. Ces lignes de code informent simavr que nous désirons observer le port C et effectivement, la simulation du programme proposé auparavant au moyen de la commande simavr -f 16000000 -m atmega32u4 programme.out se traduit par un chronogramme, dans lequel le port C change périodiquement d’état (voir figure 1). Les arguments de simavr sont -f, pour définir la fréquence du processeur et -m, pour le type de processeur.

À chaque simulation, un fichier trace_file.vcd est généré. Ce fichier s’analyse au moyen de gtkwave (tout comme les chronogrammes de simulation du comportement d’un code VHDL sur FPGA). Une fois gtkwave lancé, cliquer sur logic pour faire apparaître les signaux acquis dans la fenêtre en dessous. Faire glisser chacun des signaux dans la fenêtre principale des chronogrammes et cliquer sur la loupe munie d’un carré, pour se placer pleine échelle.

1.2 Communications asynchrones (RS232)

Une liaison USB est complexe et requiert une bibliothèque gourmande en ressources pour déclarer ses interfaces de communication (endpoints). Néanmoins, tout circuit électronique numérique comportant un microcontrôleur est muni d’une interface de communication très simple et facile à déverminer, bien que plus lente que l'USB, implémentant le protocole série asynchrone compatible RS232 [1], qui permet de démarrer le système embarqué, avant qu’un système d’exploitation ou une bibliothèque lourde ne donne accès aux protocoles de communication rapides, mais complexes. Nous nous proposons donc d’observer les transactions selon le protocole RS232 pour quelques applications de communication de base, et ce, non sur microcontrôleur physique, mais sur émulateur. En effet, simavr émule le comportement d’un ATmega(32U4) et fournit, en plus des ressources disponibles sur le « vrai » composant, accès à l’état de ses registres internes.

Ces premières lignes, en plus de définir quelques fonctions fournies par avr-libc, indiquent à simavr d’exporter la trace représentant le registre de transmission de données de l’interface asynchrone UDR1, situé à l’adresse 0xCE [2, p. 388] : écrire une valeur dans ce registre se traduit par l’activation de la machine à états, qui va générer les niveaux successifs sur la broche TXD1 (PD3), pour transmettre la donnée sans supervision explicite du logiciel.

Suivent les fonctions de communication : comme tout protocole asynchrone, nous devons déterminer le débit de transfert (baudrate), que nous sélectionnerons entre deux valeurs standard que sont 57600 bauds ou 9600 bauds :

Le port série est configuré pour communiquer 8 bits/donnée, sans bit de parité et 1 bit d’arrêt, auquel on pensera à ajouter le bit implicite de départ, soient au total 10 bits par donnée transmise. Nous devrions donc attendre 1000/960=1,042 ms (9600 bauds) ou 1000/5760=0,174 ms (57600 bauds) par donnée transmise.

simavr sauve donc l’évolution du registre, dont le chronogramme est tracé en figure 2. Le point intéressant ici est le respect des contraintes temporelles de la communication, considérablement plus lente que tout calcul sur le microcontrôleur. Nous constatons qu’à 9600 bauds, un octet est transmis en 1,234 ms (soit près de 20000 cycles d’horloge du processeur cadencé à 16 MHz) ou à 57600 bauds à 0,188 ms. Ces durées correspondent à 874 octets/seconde (contre 960 octets/seconde en théorie) ou 5313 octets/seconde (contre 5760 octets/seconde en théorie), un résultat tout à fait acceptable, compte tenu des activités annexes de maintenance exécutées par ailleurs par le microcontrôleur.

1.3 Pointeur de pile

Simuler un GPIO est un peu trivial et sans intérêt pratique. Simuler un port de communication est mieux. Plus intéressant encore, les microcontrôleurs de la gamme ATmega ont la propriété de stocker le pointeur de pile dans deux registres (deux registres 8 bits, pour pointer sur une adresse de 16 bits, pour adresser plus de 256 octets de mémoire) qui peuvent donc être observés par simavr, comme tout port. Pour rappel, la pile est la zone mémoire utilisée comme brouillon par le processeur, et la corruption de pile est un problème classique de plantage de programme, ne serait-ce que parce que le processeur empile l’adresse de retour du compteur de programme, pour se rappeler où continue l’exécution d’un programme qui a sauté dans une fonction ou une procédure. Comme la pile sert aussi au stockage des variables locales aux fonctions (au contraire du tas, qui stocke les variables globales ou à portée de la durée de l’exécution du programme – préfixe static lors de la déclaration), une pile qui sort de l’espace adressable de mémoire se traduira par un plantage irrémédiable du programme : connaître l’état de sa pile est donc un élément clé pour garantir le bon fonctionnement d’un programme.

Nous nous intéressons désormais au pointeur de pile sur 16 bits, défini comme deux registres de 8 bits situés aux adresses 0x3D et 0x3E [2, p. 388]. Ainsi, nous modifions la configuration de la sauvegarde des traces par simavr, en complétant le code d’initialisation par :

Ceci ajoute à UDR1 les deux octets du pointeur de pile (stack pointer) STACKL (octet de poids faible) et STACKH (octet de poids fort). Nous observons (voir figure 3) que la pile est initialisée en haut (fin) de RAM, puisqu’empiler une variable correspond à décrémenter le pointeur de pile.

Un exemple classique d’occupation de pile qui explose est un programme récursif, dans lequel une fonction est appelée une multitude de fois, par exemple dans le cas du calcul du factoriel d’un nombre :

Une telle fonction factoriel() est implémentée dans le programme qui suit. À titre pédagogique, nous attendons un peu entre deux itérations (_delay_ms()), pour bien séparer les appels de la fonction dans les chronogrammes et allouons un tableau inutilisé, pour illustrer l’occupation de la pile pour conserver les variables temporaires locales à une fonction :

Afin d’interdire à gcc d’éliminer le tableau inutilisé, nous préfixons sa définition du mot clé volatile, qui interdit au compilateur de faire une hypothèse sur l’utilisation de cette variable et nous compilons avec l’option d’optimisation -O0, pour interdire à gcc de transformer la fonction récursive en une itération au sein de la même fonction (remplacement de l’appel à la fonction par call, qui empile l’adresse du pointeur de programme par une boucle, itérée par un simple saut jmp par gcc, lors de son optimisation du code). Nous passons outre le message avertissant que la fonction _delay_ms() ne sera pas exacte en durée avec cette option d’optimisation, ce point n’étant pas le sujet de la démonstration.

Les chronogrammes des premières itérations sont fournis en figure 4. Chaque appel à la fonction factoriel() se traduit par un décrément du pointeur de pile de 0xD7-0x95=66 octets, un peu plus que les 0x32=48 octets nécessaires à stocker le tableau inutile. Cette allocation se répète au cours des trois premières itérations de l’appel à factoriel(), occupant petit à petit la RAM disponible (l’ATmega32U4 ne propose que 2,5 KB de RAM compris entre 0x100 et 0xAFF, figure 3). À la quatrième itération de factoriel(), l’octet de poids fort du pointeur de pile est décrémenté de 0x0A à 0x09.

Finalement, les sources de simavr sont limpides et leur manipulation est aisée pour ajouter ses propres fonctionnalités. Par exemple, pour imposer un rythme plus soutenu de communication, qui ne se contente pas d’afficher les messages transmis sur port de communication asynchrone à chaque retour chariot ou lorsque le tampon est plein, nous avons décidé de modifier simavr/sim/avr_uart.c avec des instructions du type if ((v>' ') && (v<127)) printf("%c",v); else printf("0x%02x",v); fflush(stdout); dans les fonctions avr_uart_udr_write() et avr_uart_write(). De la même façon, si on ne veut pas passer par l’analyseur de chronogrammes, mais afficher l’état des GPIOs en cours d’exécution, on manipulera simavr/sim/avr_ioport.c dans avr_ioport_write() avec printf("\nSIMAVR: IOPORT @0x%02x<-0x%02x\n",addr,v);fflush(stdout); pour fournir l’état du GPIO. Ce faisant, l’exécution de la simulation dans simavr se traduit par :

La solution 0x9d80=40320 est bien 8! tandis que l’état du port B – dont l’emplacement est à l’adresse 0x25 – est immédiatement indiqué en cours d’exécution du simulateur, sans devoir passer par gtkwave. Le lecteur peut ainsi agrémenter le simulateur de diverses conditions de validité du programme, par exemple vérifier qu’une broche a bien été configurée en sortie, si son état est manipulé ou vérifier que le débit de communication a été configuré, si une liaison asynchrone est engagée.

simavr est donc parfaitement fonctionnel pour simuler le comportement de petits microcontrôleurs 8-bits d’architecture Harvard. Il s’agit là de cas bien particuliers ne proposant pas beaucoup de fonctionnalités au-delà de petits automates relativement simples. Plus général et surtout supportant des architectures bien plus puissantes, qemu ouvre un horizon bien plus vaste d’activités.

2. qemu pour STM32

L’émulateur simavr est fort sympathique pour un petit microcontrôleur 8 bits tel que la série des ATmega, mais manque de généralité : qemu supporte multitude d’architectures, dont le STM32 de ST Microelectronics grâce à l’effort d’André Beckus. Nous avons déjà largement présenté cette version de qemu – et sa déclinaison pour Eclipse – dans [3] et ne le mentionnons ici que pour insister sur le fait que la qualité d’un émulateur ne vaut que par le détail de son émulation. Nous avons récemment rencontré une erreur d’implémentation du convertisseur analogique numérique qui avait pourtant toujours donné satisfaction, mais dont l’émulation ne répondait pas aux attentes de la bibliothèque libre pour ARM Cortex libopencm3. Ce dysfonctionnement fut l’occasion de corriger qemu en conséquence : http://github.com/beckus/qemu_stm32/issues/24.

Notre attrait pour qemu porté au STM32 tient dans les messages d’erreurs inclus lors de l’utilisation de périphériques non initialisés. En effet, le STM32 désactive par défaut l’horloge cadençant tout périphérique, et une erreur classique de débutant sur cette plateforme est d’oublier d’initialiser la source d’horloge adéquate, se traduisant par un plantage du programme tentant de sonder le statut d’un bit, qui ne changera jamais d’état si le périphérique n’est pas cadencé. L’analyse du code de l’instrument commercialisé par la société SENSeOR sur qemu a ainsi permis de corriger un certain nombre d’erreurs d’ordre d’initialisation de périphériques qui finissaient par tout de même fonctionner, mais au risque de rencontrer un dysfonctionnement si un événement se déclenchait au cours de cette initialisation. Prenons de nouveau un exemple très simple pour STM32F103 qui se lie avec libopencm3 (http://github.com/libopencm3/libopencm3), que nous découpons étape par étape pour faire le lien avec l’émulateur.

2.1 C avec libopencm3

Après bien des évolutions de son arborescence, compte tenu de la multitude de plateformes ARM-Cortex supportées (M3, mais aussi M4), une solution stable semble avoir été trouvée, dans laquelle les fonctions associées aux divers périphériques sont annoncées en préfixant le chemin du répertoire par le nom du processeur concerné :

L’initialisation des GPIO est classique, mais doit répondre aux broches simulées dans qemu. Le STM32 exécutera :

Ceci fait le pendant, dans qemu, à la déclaration d’un GPIO par (http://github.com/beckus/qemu_stm32/blob/stm32/hw/arm/stm32_p103.c#L122) :

Il est ainsi extrêmement aisé de rajouter ses propres GPIO et les messages associés indiquant leur état. De la même façon, l’initialisation des ports de communication asynchrone par libopencm3 est :

Ces lignes font le pendant de l’initialisation des ports de communication dans qemu (http://github.com/beckus/qemu_stm32/blob/stm32/hw/arm/stm32_p103.c#L129) par :

Ce qui permet donc ici encore de facilement déclarer des ports de communication additionnels, si nécessaires. Quelques fonctions de base sur le microcontrôleur simplifieront les échanges entre le programme et le terminal chargé d’afficher les messages :

Finalement, le périphérique le plus intéressant, mais qui a posé le plus de soucis dans son émulation : le convertisseur analogique numérique. Son initialisation dans libopencm3 se fait sans grande surprise :

Pourtant, le convertisseur analogique numérique n’est pas explicitement instancié par la plateforme stm32-p103, mais fait partie intégrante du cœur du microcontrôleur décrit dans http://github.com/beckus/qemu_stm32/blob/stm32/hw/arm/stm32.c par stm32_create_adc_dev(stm32_container, STM32_ADC1, 1, rcc_dev, gpio_dev, 0x40012400, 0);. Nous avons fait le choix, dans http://github.com/beckus/qemu_stm32/blob/stm32/hw/arm/stm32_adc.c#L700, d’émuler divers comportements de convertisseur analogique numérique selon le canal sélectionné, par exemple en fournissant une sinusoïde qui se veut exacte en période d’échantillonnage, grâce à l’utilisation de la représentation du temps par qemu (qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL)).

Notre contribution récente à qemu pour STM32 a porté sur l’analyse du code de conversion analogique numérique proposé par libopencm3, implémenté sous la forme :

Ce qui ne rendait jamais de résultat de mesure. En effet, dans notre implémentation initiale de l’émulation du convertisseur, nous nous étions contenté d’annoncer la fin de conversion (s->ADC_SR&=~ADC_SR_EOC;), mais avions omis de relever le drapeau testé par libopencm3 pour respecter les consignes du manuel d’utilisateur du STM32F103 [4, p. 231], à savoir s->ADC_CR2&=~ADC_CR2_SWSTART;. Ce faisant, nous respectons bien le test de libopencm3, qui vérifie la fin de conversion non pas en testant le bit du même nom (EOC), mais par (http://github.com/libopencm3/libopencm3/blob/master/lib/stm32/common/adc_common_v1.c#L695) :

Le programme sur le microcontrôleur se conclut par l’initialisation des horloges des périphériques utilisés – problème classique de plantage d’un programme sur STM32, qui par défaut ne cadence pas ses périphériques :

Ce programme se traduit lors de sa simulation par :

Ceci démontre bien l’émulation du convertisseur analogique numérique, de la communication asynchrone et d’une broche de GPIO. Si cependant, nous sommes suffisamment maladroits pour compléter la fonction principale par un affichage sur le second port de communication asynchrone usart_send_blocking(USART2, ’a’); nous nous faisons insulter par :

Ces lignes nous indiquent donc que nous tentons de manipuler les registres d’un périphérique dont l’horloge n’est pas initialisée, puis que nous tentons de communiquer par un port asynchrone qui n’a pas été configuré.

De la même façon, omettre l’initialisation du convertisseur analogique numérique en commentant adc_setup(); se traduit par :

Ce message est suffisamment explicite pour corriger le problème. L’émulateur peut donc amener un réel bénéfice d’analyse de code en sondant l’état des registres, par rapport à JTAG qui se contente de fournir le statut du matériel, sans en analyser le comportement.

2.2 NuttX

Nous avions présenté NuttX [5] comme environnement exécutif visant la compatibilité POSIX, avec une empreinte mémoire compatible avec les plus petits STM32. La vidéo de http://www.youtube.com/embed/4t5pO8cJU9k présente l’émulation de NuttX dans qemu, qui s’avère simple à mettre en œuvre sur une plateforme ne requérant pas le support de l’horloge temps réel (RTC). En effet, nous constatons qu’en clonant le dépôt git de NuttX à la date de rédaction de cette prose :

Et en configurant pour une version minimaliste du STM32F103 :

L’exécution dans la version d’André Beckus de qemu se solde immédiatement par une invite de commande du Shell nsh :

En l’état, nous ne pouvons pas fournir de commande à nsh en l’absence de gestion des entrées du clavier, mais le principe de base fonctionne.

3. qemu pour RISC-V

Alors qu’il semblait acquis que l’architecture ARM allait dominer le monde de l’électronique numérique embarquée avec sa panoplie de processeurs répondant aux besoins allant du petit automate aux téléphones mobiles, 2018 s’avère peut-être marquer la fin de cette hégémonie, avec la mise sur le marché d’une architecture qui couvait depuis 8 ans à Berkeley. Cette architecture libre (sous licence BSD), initialement proposée comme softcore sur FPGA, a été présentée dans une puce silicium contrôlant un ordinateur pour la première fois au FOSDEM en 2018 (http://archive.fosdem.org/2018/schedule/event/riscv/) par SiFive, et a donné lieu à une session dédiée en 2019 (http://fosdem.org/2019/schedule/track/risc_v/). Non content de remettre en cause l’hégémonie d’ARM en lui imposant de libérer l’implémentation de certains de ses cœurs (www.arm.com/resources/designstart/designstart-fpga), cette nouvelle architecture libre impose à d’autres architectures de suivre la tendance, en particulier MIPS (http://wavecomp.ai/mipsopen). Les années à venir promettent donc une compétition excitante entre les « anciennes » architectures (ARM, MIPS, SPARC) et les nouveaux venus de la gamme RISC-V (figure 5) [6], avec laquelle il est certainement judicieux de se familiariser, d’autant plus qu’une version combinant CPU et FPGA, dans la lignée du Zynq, est proposée par Microsemi (ex-Lattice : http://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga).

En l’absence de circuit matériel implémentant un des cœurs RISC-V, nous allons nous familiariser avec le travail sur cette architecture sur l’émulateur qemu. RISC-V est évidemment supporté par gcc. Bien que GNU/Linux soit supporté sur cette architecture, nous nous focaliserons dans un premier temps sur sa programmation en C (baremetal) et au moyen de FreeRTOS (figure 6).

3.1 Programmation en C (baremetal)

L’utilisation en C d’un microcontrôleur nécessite d’accéder directement aux registres de communication pour interagir avec l’utilisateur, puisque les bibliothèques de plus haut niveau telles que newlib ne peuvent pas savoir quel périphérique une instruction de type printf() vise : cette fonction fait appel à write() qui est implémentée, dans le cas de newlib, par les stubs qui font pointer les écritures vers le bon périphérique.

En l’absence de ces stubs, une bibliothèque se charge pour nous de transmettre les écritures et lectures vers le périphérique émulé par l’entrée-sortie standard (stdio) : libfemto, disponible sur http://github.com/michaeljclark/riscv-probe. L’implémentation des fonctions d’entrée-sortie permettra notamment d’interagir avec le programme émulé par qemu, qui supporte officiellement (http://github.com/qemu/qemu) RISC-V lors de la compilation par
./configure –enable-debug –target-list=“riscv64-softmmu riscv32-softmmu” –disable-gtk –disable-sdl –disable-werror.

À titre d’échauffement, on pourra valider l’exécution de l’exemple « Hello World », nommé hello dans riscv-probe/build/bin/rv32imac/qemu-sifive_e, en fournissant comme format de machine à qemu l’option -M sifive_e et en prenant soin de demander -nographic, afin que l’affichage s’effectue sur le terminal courant. Une fois l’exécution achevée, nous quitterons l’émulateur du terminal comme nous le ferions depuis minicom par <Ctrl> + <a> puis <x>, nous rappelant ainsi que qemu affiche les liaisons sur le port série et non sur un écran qui pourrait équiper le système embarqué. On s’en rappellera lors de l’émulation de GNU/Linux, pour lequel nous redirigerons la console sur un port série virtuel.

Le résultat s’obtient en se plaçant dans le répertoire riscv-probe et en compilant toute l’arborescence :

Ce qui se traduit par :

Basés sur cet exemple, nous pouvons commencer à analyser le comportement de la nouvelle architecture avec, par exemple, la taille d’un long et l’organisation des octets en mémoire :

Après compilation, dont nous avons identifié les options en exécutant make V=2 pour rendre le Makefile verbeux :

Ceci donne le résultat qu’un long est codé sur cette architecture 32 bits sur 4 octets, tandis que l’affichage des octets individuels compris dans un mot codé sur plusieurs octets indique que, puisque 0x78 apparaît en premier, l’octet de poids faible est à l’adresse la plus faible. Nous sommes donc dans un modèle de processeur little endian, organisation des données similaires de celles adoptées par Intel sur architecture x86, afin de charger en premier les octets de poids faible et donc, calculer lors des opérations arithmétiques les retenues, en même temps que les octets de poids plus fort sont chargés dans l’unité arithmétique et logique. Cependant, en compilant en 64 bits par (noter les options -march= et -mabi) :

 Nous obtenons sous la version 64 bits de qemu le résultat suivant :

Ceci indique cette fois qu’une variable de type long occupe 8 octets (64 bits), mais l’organisation reste évidemment little endian.

3.2 FreeRTOS

La version V10.2.0 de FreeRTOS, dont les évolutions sont décrites sur http://www.freertos.org/History.txt, publiée le 25 février 2019, supporte officiellement l’architecture de processeur RISC-V et en particulier, sa déclinaison 32 bits.

L’archive se télécharge sur http://sourceforge.net/projects/freertos/files/latest/download et la démonstration pour plateforme RISC-V se trouve dans le répertoire FreeRTOS/Demo/RISC-V-Qemu-sifive_e-FreedomStudio. Nous y trouvons les scripts nécessaires pour compiler un exemple, qu’il faut cependant modifier un peu pour les adapter à la chaîne de compilation fournie par http://github.com/riscv/riscv-gnu-toolchain – la chaîne de compilation s’obtient par make newlib, pour éviter de compiler toutes les dépendances inutiles. Nous remplaçons en effet dans BuildEnvironment.mk l’appel à riscv32-unknown-elf par riscv64-unknown-elf et ajoutons dans Makefile l’ordre de lier le binaire sur la version 32 bits de la bibliothèque libc, en ajoutant LDFLAGS += -march=rv32imac -mabi=ilp32 après la première occurrence de la variable d’environnement LDFLAGS autour de la ligne 128. En effet, le nom du compilateur ne présume pas de la taille des registres de la cible, mais c’est l’option -march qui détermine la nature de la cible (tout comme pour ARM, lorsque nous choisissons entre Cortex M3 ou M4). Le fichier résultant de la compilation de FreeRTOS est bien un binaire à destination d’un RISC-V :

Lors de son exécution sous qemu, ce programme affiche périodiquement le même message :

Au-delà de cet exemple trivial de démonstration de la capacité à compiler et exécuter un programme lié à l’ordonnanceur fourni par FreeRTOS, nous avons ici l’opportunité de découvrir les subtilités du développement collaboratif et en particulier, le partage des ressources. D’une part, la mémoire est une denrée rare, qu’il faut partager efficacement en l’absence de gestionnaire de mémoire capable de virtualiser les domaines d’adresses accessibles par chaque tâche et d’autre part, plusieurs tâches peuvent vouloir accéder à la même ressource, qu’il faut arbitrer par le mécanisme classique des MutEx (accès Mutuellement Exclusif aux ressources).

L’exemple qui suit reprend intégralement le code source fourni dans [3, section 4], pour faire appel à une émulation des accès aux ressources matérielles et ainsi rendre les codes portables – une méthode classique de séparation de la partie algorithmique du code (portable) et de la partie accédant aux périphériques (dépendante de chaque architecture). Dans notre cas, common.c et common.h, qui implémentent ces fonctions, sont disponibles sur http://github.com/jmfriedt/tp_freertos/tree/master/common et se contentent d’afficher un message sur la console pour indiquer qu’une ressource matérielle est sollicitée. Nous ne reproduisons pas ici le code dans son intégralité (voir [3]), mais précisons qu’il faut penser à fournir les diverses fonctions de maintenance requises par le portage au RISC-V de FreeRTOS :

Ces diverses fonctions appelées pour gérer les interruptions et nécessaires à l’ordonnanceur FreeRTOS sont reprises des exemples fournis dans l’archive de l’environnement exécutif, sans modification. L’exécution de ce programme dans qemu se traduit par le résultat escompté, à savoir (après avoir légèrement modifié la règle d’origine du Makefile, pour ajouter l’option -nographic et avoir retiré les directives de connexion à gdb, que sont -s -S) :

De la même façon, nous reprenons intégralement le code permettant l’exploration des mutex de [3, section 4.3]. Pour rappel, nous avions proposé de protéger l’affichage de messages longs par mutex, afin d’en garantir l’intégrité.

En l’absence de mutex, nous obtenons parfois un message corrompu sur l’affichage :

Ceci ne survient jamais si nous prenons soin de protéger les appels à uart_puts() par les mécanismes appropriés, implémentés au niveau de l’ordonnanceur par xSemaphoreTake() et xSemaphoreGive().

Finalement, FreeRTOS permet d’afficher la liste des tâches, leur état et leur occupation de mémoire volatile sous forme d’allocations sur la pile, ainsi que de placer une signature (watermark) en fin de pile, pour en détecter la corruption. Ces fonctionnalités sont évidemment toujours opérationnelles sur architecture RISC-V, tel que nous nous en convainquons en activant les fonctions d’affichage de la liste des tâches par (en pensant à retirer l’option par défaut, qui désactive ces fonctions (#define configUSE_TRACE_FACILITY 0)) :

Une fois FreeRTOS configuré de cette façon (make clean && make), l’appel à la fonction vTaskList(c); affiche la liste des fonctions et leur statut :

Ainsi, tous les exemples proposés dans [3] sont reproductibles sur émulateur, sans avoir besoin d’acquérir le matériel correspondant.

4. GNU/Linux sur ARM, MIPS, et RISC-V

Nous ne pouvons conclure ce survol des émulateurs sans mentionner le support de GNU/Linux sur des architectures que nous ne possédons pas. Ainsi, le processeur ARM inclus dans le Zynq qui équipe la Redpitaya est émulé par qemu-system-arm, si nous exécutons qemu-system-arm -append “console=ttyPS0,115200 root=/dev/mmcblk0 rw earlyprintk” -M xilinx-zynq-a9 -m 1024 -serial mon:stdio -dtb zynq-red_pitaya.dtb -nographic -kernel uImage -sd rootfs.ext4 lorsque nous compilons une image de GNU/Linux au moyen de buildroot, tel que décrit sur http://github.com/trabucayre/redpitaya.

Au-delà de l’aspect pédagogique d’exécuter GNU/Linux sur une plateforme exotique, cette approche permet d’exécuter des firmwares disponibles uniquement sous forme binaire, pour en sonder les vulnérabilités. C’est l’approche sélectionnée par [8] pour analyser les logiciels embarqués des caméras communiquant sur IP et détecter les failles de sécurité. Ainsi, http://www.devttys0.com/2011/09/exploiting-embedded-systems-part-3/ décrit comment exécuter un logiciel embarqué de routeur wi-fi basé sur un processeur MIPS.

Finalement, RISC-V est officiellement supporté par buildroot : la configuration par make qemu_riscv64_virt_defconfig permet de générer une série de fichiers pour exécuter GNU/Linux sur qemu. L’ordre d’exécution est un peu verbeux avec
qemu-system-riscv64 -M virt -kernel output/images/bbl -append “root=/dev/vda ro console=ttyS0” -drive file=output/images/rootfs.ext2,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -device virtio-net-device,netdev=vmnic -netdev tap,id=vmnic,ifname=vnet0 -nographic en supposant que nous lançons qemu-system-riscv64 depuis le répertoire buildroot, puisque tous les fichiers générés par la compilation sont supposés être situés dans output/images. Le fichier bbl est le Berkeley Boot Loader.

Nous pourrons rapidement nous convaincre que l’architecture cible est la bonne, en consultant le contenu de /proc/cpuinfo, qui indique rv64imafdcsu : nous sommes sur la bonne voie.

Alors que la programmation en espace utilisateur ne présente aucune difficulté autre que d’identifier le compilateur dans output/host/usr/bin de buildroot comme nommé riscv64-linux-gcc, la partie module noyau est toujours un peu plus intéressante. En effet, nous constatons après avoir exécuté GNU/Linux sur qemu que le devicetree contient un certain nombre de nœuds, tel que décrits dans /sys/firmware/devicetree/base/ et en particulier, le périphérique virtio_mmio. Bien que l’outil devmem permette de sonder l’état des divers registres de ce périphérique depuis l’espace utilisateur et de vérifier la cohérence de leur contenu avec la documentation technique de http://docs.oasis-open.org/virtio/virtio/v1.0/csprd01/virtio-v1.0-csprd01.html, qui dit que le premier registre (adresse 0x00 lue par devmem 0x10001000) contient l’identifiant 0x74726976, il est toujours plus satisfaisant d’accéder aux ressources matérielles depuis un module noyau. Dans notre cas, l’exemple trivial d’accès au périphérique matériel depuis le noyau est implémenté par :

Ce code utilise ioremap() pour convertir l’adresse physique en adresse virtuelle et se compile par :

Pour finalement donner :

Nous pourrons donc sereinement tester nos développements noyau sur cette nouvelle architecture, sans avoir accès au matériel.

5. Séparation de l’algorithme et accès au matériel

Nous avons mentionné l’utilisation de qemu pour auditer le code d’un système embarqué commercialisé par SENSeOR et qualifier la bonne initialisation des divers périphériques. Une architecture de développement, qui allège considérablement le portage d’un logiciel embarqué (firmware) d’une architecture à une autre, est une séparation rigoureuse de la partie algorithmique (portable) de la partie accédant aux périphériques matériels (fortement dépendante de chaque cible). Ce faisant, nous bénéficions par ailleurs de la capacité à fournir des signaux synthétiques aux diverses entrées simulées et ainsi tester des configurations difficiles à reproduire expérimentalement, voire rejouer des scénarios de mesure enregistrés sur du matériel afin d’observer le comportement de divers algorithmes. À titre d’exemple de la conversion analogique numérique, sachant que le code pilotant les convertisseurs sur du matériel s’écrit sous la forme :

Son émulation, par exemple sur PC, exploitera le même prototype de fonction, mais fournira des données synthétiques, par exemple par :

Nous constatons dans cet exemple que nous renvoyons la réponse bruitée attendue par le dispositif sondé lors d’une mesure, et tentons de respecter les contraintes temporelles par une temporisation de la durée de la programmation par SPI du périphérique émettant un signal (registres FTW0 dans l’implémentation matérielle) et recevant la réponse du dispositif sondé (readADC12()). Ce faisant, nous pouvons aussi profiter des tests unitaires sur la partie algorithmique du code, puisque cette partie ainsi que l’émulation des accès aux périphériques (mock pour nommer l’émulation de l’accès aux périphériques matériels) seront compilables sur PC.

Conclusion

Même si le coût du matériel pour s’approprier les techniques de développement sur système embarqué ne cesse de chuter, pour n’être plus que de quelques euros pour nombre de cartes d’évaluation, il est parfois souhaitable de tester une nouvelle architecture sans acquérir le matériel associé, ne serait-ce que pour les architectures encore difficiles à acquérir. Par ailleurs, nous avons montré comment un émulateur, en donnant accès au cœur du processeur, propose des fonctionnalités additionnelles aux debuggers logiciels ou matériels (JTAG), en permettant d’introduire des messages liés aux initialisations erronées de périphériques. Enfin, les émulateurs sont devenus tellement performants que même un système d’exploitation aussi complexe que GNU/Linux peut y être exécuté, par exemple pour analyser des logiciels fournis sous forme de binaire sur une plateforme exotique.

Remerciements

La référence bibliographique qui n'est pas librement disponible sur le Web a été acquise auprès de Library Genesis à http://gen.lib.rus.ec depuis le réseau universitaire Renater, une gare SNCF, au travers de TOR ou en exploitant comme DNS 9.9.9.9. Le tribunal qui s'est abaissé à légitimer l'attaque des éditeurs commerciaux contre cette ressource indispensable à nos activités quotidiennes de recherche et développement, en imposant de bloquer les DNS des fournisseurs d’accès internet, aurait pu se poser la question de l'applicabilité de sa décision.

Références

[1] GTVHACKER, « Hack All The Things – 20 Devices in 45 Minutes », DEFCON 22, 2014 : http://www.youtube.com/watch?v=u2aKrgDtfoI

[2] « ATmega16U4/ATmega32U4 8-bit Microcontroller with 16/32K bytes of ISP Flash and USB Controller » : http://ww1.microchip.com/downloads/en/devicedoc/atmel-7766-8-bit-avr-atmega16u4-32u4_datasheet.pdf version Atmel-7766J-USB-ATmega16U4/32U4-Datasheet 04/2016

[3] Q. MACÉ et J.-M FRIEDT, « FreeRTOS : application à la réalisation d’un analyseur de réseau numérique sur STM32 », GNU/Linux Magazine France n°207, 2017 : https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-207/FreeRTOS-application-a-la-realisation-d-un-analyseur-de-reseau-numerique-sur-STM32

[4] RM0008 Reference Manual : http://www.st.com/resource/en/reference_manual/cd00171190.pdf

[5] G. GOAVEC-MEROU et J.-M. FRIEDT, « Un environnement exécutif visant la compatibilité POSIX : NuttX pour contrôler un analyseur de réseau à base de STM32 », GNU/Linux Magazine France n°210, décembre 2017 : http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-210/Un-environnement-executif-visant-la-compatibilite-POSIX-NuttX-pour-controler-un-analyseur-de-reseau-a-base-de-STM32

[6] D.A. PATTERSON et J.L. HENNESSY, « Computer organization and design – the hardware/software interface », RISC-V Edition, Elesevier-Morgan Kaufmann, 2018.

[7] R. BARRY, « FreeRTOS on RISC-V – Running the FreeRTOS kernel in RISC-V emulators and RISC-V hardware », FOSDEM 2019 RISC-V devroom : http://fosdem.org/2019/schedule/event/riscvfreertos/

[8] C. HEFFNER, « Exploiting Network Surveillance Cameras Like a Hollywood Hacker », Black Hat, 2013 : http://www.youtube.com/watch?v=B8DjTcANBx0 et le résumé disponible sur http://media.blackhat.com/us-13/US-13-Heffner-Exploiting-Network-Surveillance-Cameras-Like-A-Hollywood-Hacker-WP.pdf qui mentionne « Analysis and extraction of these firmware images was accomplished using Binwalk and the Firmware-Mod-Kit, while disassembly, emulation and debugging of code was performed using IDA Pro and Qemu. [...] It is worth noting that such tools allow attackers to identify and exploit vulnerabilities in embedded systems without ever purchasing a target device for testing. »