Implémentation de Linux sur Altera EPXA1

Résumé du document

De manière générale, puissance fiabilité flexibilité et extensibilité sont quatre idées fortes du monde Linux. L'autre facteur déterminant dans les récents succès de Linux dans le monde industriel est son support poussé à l'extrême d'une multitude d'architectures matérielles et logicielles. Des montres au super computers clustérisés en passant par les firewalls, on ne compte plus les déclinaisons des portages de Linux. Parce que gratuit et librement distribuable, de multiples variations du noyau de Linus Torvalds auquel se sont greffés de nombreux projets GNU ont fait leur apparition pour satisfaire à tous les besoins particuliers que l'on peut rencontrer dans le marché. Cependant, notre recherche d'une "distribution" Linux ne s'est pas révélée aussi fructueuse que l'utilisateur d'une Mandrake ou d'une Debian pourrait croire. Dans le secteur de l'embarqué ARM, les solutions clé en main existent bien, mais elles sont commerciales. Outre les considérations philosophiques sur le choix d'une distribution commerciale, nous devions faire de ce travail un projet, pas une pseudo maîtrise d'une solution déjà disponible par une demo utilisable limitée de quelque façon. Nous sommes parvenu à déterminer une configuration à quasi 100% free. Le seul ingrédient commercial subsistant réside en l'utilisation de la librairie de boot libboot xa ads.a. (...)

Extraits

[...] Ceci fournit de nombreux problèmes. A chaque fois que le système subit un reset, toute la programmation PLD est perdue et ainsi le noyau MAC disparaît. Ce problème peut être résolu en reprogrammant le PLD après un reset. Un problème plus important subsiste : étant donné que le noyau MAC réside dans le PLD, toutes les fonctionnalités Ethernet seront temporairement perdue lors de la reprogrammation du PLD Linux pour les systèmes embarqués à base d'ARM Bien qu'il existe de nombreuses solutions pour choisir un système d'exploitation pour un système embarqué l'utilisation des Streams-C exige l'utilisation de Linux. [...]

[...] En particulier, nous avons insisté sur certains points pratiques tels la mise en place des outils de développement (sur une machine d'architecture typiquement différente de l'architecture ciblée), leur utilisation ainsi que les étapes de transfert de données et l'utilisation finale du système embarqué. Nous avons également pensé utile d'écrire quelques scripts automatisant certains processus répétitifs courant. Préambule Ce TEP se voulait d'abord être un projet de terminal multimedia portatif. Celui-ci aurait du être un assemblage de composants aussi que possible, c'est à dire limitant au maximum l'utilisation de microcomposants généralistes. Cela n'allait pas durer. Devenu plus ambitieux, le projet voulait emprunter son architecture à la GP32 (terminal 3 multimédia basé sur un ARM9) en implantant un smdk2400. [...]

[...] Nous avons ainsi modifier le code du projet Armboot spécifique à Quartus pour faire fonctionner la carte avec une cadence processeur de 300Mhz, un fonctionnement de la SDRAM fixée à 150Mhz et un accès à 32Mo de mémoire SDRAM. Localisation des fichiers spécifiques à Quartus Les fichiers spécifiques à Quartus sont localisés dans le répertoire board epxa1db quartus. Les fichiers à modifier se nomment excalibur.h, excalibur.s, excalibur.sbd. Ils permettent de configurer le fonctionnement de chacun des éléments constituant la carte ainsi que le mapping memory. [...]

[...] Sh insmod, depmod, modprobe, lsmod dans le noyau mkdir, mknod, rm, cat, echo, mount, umount, ls, cp le système de fichiers nano or pico or vi or emacs Fonction Le programme d'initialisation du System-V ; Un shell interactif (bash, ash, tcsh, etc.) Utilitaires pour utiliser des modules Outils basiques pour manipuler Un éditeur basique de fichier texte Il existe des distributions linux qui fournissent une interface avec script pour créer un système d'exploitation à l'aide de fichiers sources. Une option souvent utilisée, et spécialement pour les systèmes embarqués, est ucLinux. Malheureusement, aucun port pour l'EPXA n'existe actuellement. [...]

[...] Pour de nombreux systèmes embarqués, le protocole TFTP (Trivial File Transfer Protocole) est souvent utilisé pour récupérer l'image du noyau depuis un serveur distant. Néanmoins, comme l'EPXA1DB ne dispose que d'un contrôleur MAC dans un noyau logiciel, booter une image de noyau supposerait en premier lieu de programmer dans le contrôleur MAC le noyau logiciel. Une autre solution consiste à une utiliser localement une image du noyau l'enregistrant dans la mémoire FLASH puis en le copiant dans la RAM. Cette méthode locale est supportée par la plupart des bootloaders. [...]