Entretien avec Gwenhaël Goavec-Merou, créateur d'OpenFPGAloader

L'apprentissage est plus aisé lorsqu'il est ludique. N'importe quel parent ou (bon) enseignant sait ça, et c'est tout autant vrai à l'âge adulte, en particulier dans le domaine qui est le nôtre. Et quoi de plus ludique que de jouer au gendarme et au voleur, pour comprendre comment des « vilains méchants à capuche » font pour se ménager une porte d'entrée une fois un système corrompu. La petite exploration qui va suivre est assez naïve par rapport aux techniques modernes de dissimulation, mais sera parfaite pour se mettre le pied à l'étrier, en particulier si vous n'avez jamais mis votre nez dans les appels système ou les outils de diagnostic et de débogage intégrés au noyau Linux.

Dans le précédent article [1], nous avons affiné notre configuration pour supporter pleinement toute la richesse de ce que le langage C et la chaîne de compilation peuvent offrir en termes d'adressage mémoire, et sommes même allés jusqu'à utiliser ces mécanismes pour piloter une série de 64 LED adressables WS2812. Mais tout ceci se passe depuis « l'intérieur » du SoC lui-même et il est temps à présent d'accéder à cet espace depuis le monde extérieur.

À l'heure où j'écris ceci, le « Digital ID » anglais défraye la chronique avec presque 3 millions de signatures sur une pétition visant à refuser son adoption [1].

Durant mes pérégrinations dans le petit monde du développement FPGA avec LiteX s'est posée une problématique intéressante, consistant à devoir écrire un support pour une interface série (UART) en n’ayant à disposition rien d'autre qu'une poignée de registres où lire ou écrire. Cet exercice, pour moi, était une phase préalable à l'implémentation d'un pilote pour un système d'exploitation, mais serait transposable à n'importe quel type d'interface reposant sur des mécanismes similaires, et ce, sur n'importe quel MCU ou SoC, actuel ou ancien. Faisons donc connaissance avec l'UART LiteX, voulez-vous ?