L'UTBM, vraiment fini ... ou presque !
Il y a deux semaines, je suis retourné à Belfort pour passer ma soutenance de projet de fin d'études, la dernière étape avant l'obtention du tant attendu diplôme d'ingénieur. J'ai donc traversé la France depuis Toulouse pour 10 minutes de soutenance, heureusement que la soutenance était suivie d'un week-end sympathique avec des amis de Belfort !
Durant la soutenance, il a donc été question de ce que j'ai fait en stage à Mitsubishi Electric ITE TCL, un laboratoire de recherche en télécommunications situé à Rennes, de septembre 2004 à mi-février 2005. Je n'ai pas eu le temps d'en parler sur mon blog, c'est donc l'occasion !
L'équipe dans laquelle je travaillais développait une plateforme matérielle pour le traitement de trafic réseau à haut-débit, de l'ordre du gigabit par seconde. S'agissant d'un laboratoire de recherche, cette plateforme est uniquement un prototype, destiné à réaliser des expérimentations. Les traitements à appliquer sur le traffic réseau peuvent être du simple filtrage, ou bien de la réservation de bande passante pour garantir une certaine qualité pour de la vidéo-conférence, ou d'autres choses plus complexes. Pour cela, l'équipe a entièrement conçu une plateforme matérielle spécifique : la plateforme
FlexNP?. En son sein, on trouve plusieurs composants importants :
- un processeur réseau de type ARM/Xscale disposant de mécanismes spécifiques pour traiter à très haute vitesse des paquets réseau. Ce processeur est chargé de réaliser les traitements de base sur les paquets réseau, effectuer une première sélection des paquets intéressants, etc... ;
- un processeur de type MIPS à double coeur, chaque coeur opérant à une fréquence de 1 Ghz. Ce processeur est chargé des traitements de plus haut niveau sur les paquets réseau remontés par le processeur ARM ;
- un FPGA de très haute capacité (plusieurs millions de portes) pour permettre le développement de fonctionnalités cablées, et donc très rapide à exécuter.
Tous ces composants sont reliés par de nombreux bus, afin d'obtenir une architecture la plus souple possible. Ils sont reliés au monde extérieur par l'intermédiaire de contrôleurs Ethernet Gigabit ou de contrôleurs ATM Gigabit. L'architecture
FlexNP? est donc très spécifique, et n'a rien à voir avec un ordinateur classique. Au niveau logiciel, le processeur ARM fait tourner un noyau Linux 2.4, et le processeur MIPS fait tourner un autre noyau Linux 2.4.
Mon stage s'est décomposé en trois étapes :
- mise en place d'un système de génération automatisée de chaînes de cross-compilation et de ramdisk. Une chaîne de cross-compilation permet depuis sa machine de développement (en général une machine d'architecture x86) de compiler du code pour une machine cible (ici d'architecture ARM ou MIPS). Le ramdisk est un système minimal chargé depuis une mémoire Flash ou depuis le réseau au démarrage de la plateforme, celle-ci ne disposant pas de disque dur. Pour effectuer tout cela, j'ai utilisé l'excellent outil BuildRoot, réalisé par les développeurs de uClibc. J'ai d'ailleurs rédigé la documentation de cet outil, disponible sur http://buildroot.uclibc.org/buildroot.html ;
- portage du noyau 2.6 sur le processeur MIPS. Le noyau Linux 2.6 existe déjà pour l'architecture MIPS, mais pas pour la plateforme FlexNP?. Mon travail a consisté à intégrer le support de cette plateforme, c'est-à-dire à réaliser le code d'initialisation du noyau, un pilote pour le contrôleur série et une adaptation du pilote pour le contrôleur Ethernet ;
- mise en place du fonctionnement multi-coeur du processeur MIPS. Jusqu'ici, seul le premier coeur était utilisé pour faire fonctionner le noyau Linux, et l'équipe souhaitait mettre à contribution le second coeur. Au départ, nous avons pensé faire fonctionner le processeur en Linux SMP standard, c'est-à-dire avec des processus Linux qui s'exécutent sur les deux coeurs. Toutefois, nous avons jugé qu'il serait plus intéressant de conserver le second coeur pour exécuter du code personnalisé, sans système d'exploitation : cela permet de conserver une grande maîtrise sur le code exécute, et donc sur l'optimisation de celui-ci. Ainsi, le premier coeur faisant fonctionner le noyau Linux peut effectuer les tâches de monitoring ou de fond, tandis que le second coeur peut par exemple être utilisé pour communiquer à haute vitesse avec le processeur ARM et effectuer des traitements lourds. L'utilisation exacte de la plateforme n'est pas connue, puisqu'il s'agit d'un prototype et d'expérimentation. Notre décision d'avoir un fonctionnement asymétrique des deux coeurs était juste basé sur des spéculations sur les utilisations futures. Au final, mon travail a été de développer : 1) le code d'initialisation du second coeur en assembleur MIPS, 2) un module noyau implémentant un périphérique caractère qui permet à une application utilisateur de charger du code pour le second coeur, de le démarrer et de l'arrêter, ainsi qu'un mécanisme de transmission de messages texte entre les deux coeurs, 3) l'application utilisateur correspondant avec le module noyau au travers du périphérique caractère.
Le stage était donc orienté sur du développement très bas-niveau, très proche du matériel. Le déboguage était donc particulièrement délicat : en cas de problème, le matériel n'affiche pas gentiment une erreur, mais refuse tout simplement de fonctionner, sans en dire plus. Il a fallu parfois plusieurs jours pour arriver à configurer correctement certains matériels, notamment le second coeur. On est parfois un peu désemparé face au peu de moyens de déboguage existants. De plus, la plateforme utilisait des composants très récents et donc très peu utilisés. Chercher de l'aide sur Internet était le plus souvent illusoire. La seule technique de déboguage possible était une sonde JTAG, c'est à dire une sonde qui contrôle matériellement ce que fait le processeur. Malheureusement, le logiciel propriétaire fourni avec la sonde était complètement buggé, et il était difficile d'en tirer quelque chose.
Un autre détail amusant est la mise au point du code d'initialisation du second coeur. Au démarrage, le second coeur commence à exécuter du code à une adresse fixe, qu'on ne peut changer. Or cette adresse est située dans la Flash, ce qui signifie qu'à chaque test du code d'initialisation, il fallait reflasher la mémoire. Et si, malencontreusement, les modifications apportées au code d'initialisation empêchait le premier coeur de démarrer, alors il n'était plus possible de reflasher la mémoire puisqu'on n'avait pas accès au logiciel permettant de le faire. La seule solution était de passer par la sonde JTAG, au fonctionnement assez aléatoire. Ainsi, il m'a une fois fallu deux jours pour reprendre le contrôle de la plateforme suite à un flashage foiré. Amusant, n'est-ce pas ?
Globalement, le stage était très intéressant, j'ai beaucoup appris sur l'architecture matérielle. L'ambiance au sein de l'équipe était vraiment très sympathique. L'équipe était assez diversifiée en termes de compétences : des ingénieurs
hard, qui réalisaient l'électronique de la carte, et des ingénieurs
softs, surtout spécialisés dans les télécoms et les réseaux. Cette diversité a permis des échanges très intéressants, beaucoup plus que si j'étais resté dans une équipe qui ne faisait que du système. Un grand merci à David, Romain, Laurent, Mathieu, Luc, Hervé et Christophe !
Documents :
