Retrouvez cet article dans : Linux Magazine Hors série 25

Le monde de l’embarqué sur base x86 est sans doute le plus accessible pour le hobbyiste. Cependant, il existe un certain nombre de plateformes non x86 accessibles moyennant un investissement raisonnable. Les kits à base de Coldfire 528x produits par la société SSV en font partie.

Comme vous avez pu le lire dans le précédent hors-série, il existe un grand nombre de plateformes et d’architectures pour l’embarqué où Linux occupe une place importante. Cependant, s’il s’agit de faire ses premiers pas en dehors de la classique architecture PC/Intel x86, le nombre de ces solutions se réduit de manière importante. L’investissement en termes financiers devant rester dans les limites acceptables pour un passionné, les solutions SoC, ARM9 ou PXA sont souvent les premières écartées. Heureusement, un certain nombre de fabricants proposent des kits destinés aussi bien aux professionnels qu’aux hobbyistes éclairés et passionnés. SSV Embedded System est une société allemande produisant des kits à base de microcontrôleurs/processeurs StrongARM et Motorola/Freescale.

 Fig. 1 - Source : SSV embedded System

Régulièrement, SSV propose des offres à tarif réduit lors de manifestations comme Linux Tags ou ponctuellement sur des périodes d’un ou deux mois. Dernièrement, le kit DNP/SK14L intégrant un DNP5280, très proche du matériel utilisé dans cet article, était " soldé " pour moins de 200 euros. Il faut, bien entendu, ajouter des frais de port (UPS), mais cela reste très accessible pour qui souhaite s’initier.

1.Le Coldfire 5282

Le processeur au cœur du kit utilisé ici est un Motorola/Freescale Coldfire 5282. Il s’agit d’un processeur RISC 32-bit cadencé à 66 Mhz. Ceci peut paraître ridicule par rapport à la puissance des processeurs équipant les ordinateurs personnels, mais nous sommes dans un tout autre monde. Le Coldfire 5282 a ceci d’important qu’il ne dispose ni de FPU ni de MMU. L’absence de FPU pose un problème dans certains cas. En effet, si vous devez, dans votre application faire des calculs sur des flottants, vous serez vite limité. Bien qu’une émulation reste possible (au niveau noyau ou libc), les performances obtenues n’ont rien de comparable avec une véritable FPU.
Du fait que le Coldfire 5282 ne dispose pas de MMU, le gestionnaire de mémoire est bien plus important. En effet, dans les architectures x86 " classiques ", par exemple, c’est la MMU qui empêche souvent l’effondrement du système. En son absence, tous les programmes ont accès (ou presque) à l’ensemble de la mémoire, qu’elle leur appartienne ou non. Comme la majorité des applications embarquées sont codées en C, inutile de vous dire de réviser les chapitres importants sur les pointeurs et l’allocation mémoire dans votre manuel de C préféré. Cependant, le 5282 dispose d’un mode protégé. En d’autres termes, l’accès à l’ensemble des ressources n’est pas possible depuis l’espace utilisateur. Ceci offre un minimum de sécurité en termes de développement.

2.Le Kit PNP5280 de SSV

Le kit utilisé ici est un DNP/EVA8-N. Celui-ci comprend un module PNP5280 (figure 1). Il s’agit d’un ensemble Coldfire 5282 + 16 Mo de SDRAM + 8 Mo de Flash + un jeu de bus (i2c, Ethernet, CAN, etc.), le tout au format PGA 169 broches (figure 2).

Fig. 2

Le kit complet intègre également une carte mère disposant d’un support PGA et de la connectique (DB9, RJ45), un bloc d’alimentation et un câble de liaison série pour la connexion au PC. On notera qu’une autre version, plus récente, utilise un module DNP5280 bien plus facile d’exploitation. Le " D " signifiant DIL (Dual In Line) et se rapporte au support utilisé par le module : deux lignes parallèles de 32 broches (DIL-64) au pas de 2.54mm (1/10 de pouce).
Voici quelques caractéristiques précises :

• 63 MIPS (Dhrystone 2.1) ;
• deux ports série asynchrones (dont un configuré par défaut pour une console) ;
• I2C Interchip Bus Interface ;
• une interface SPI (Serial Peripheral Interface) bufferisée ;
• une interface CAN ;
• GPIO (General Purpose Parallel I/O) 18 bits haute vitesse ;
• un bus d’extension 32 bits ;
• une source d’interruption ;
• cinq sorties CS (Chip Select) ;
• timers programmables ;
• watchdog programmable ;
• une interface Motorola BDM (Background Debug Mode) ;
• basse consommation (350 mA en 3.3 volts à 66 MHz).

L’interfaçage de circuits logiques nécessite de prendre en compte cette tension spécifique. Ainsi en entrée, on utilisera par exemple des circuits 74AHC244 (octal buffer) alimentés sous 3.3 volts. Ceux-ci acceptent alors en entrée des tensions entre -0.5 et +7 volts, largement de quoi supporter une logique TTL. Les familles 74HC, 74HCT et 74LS ne conviennent pas, en raison soit d’une tension en entrée entre 0 et Vcc (ici seulement 3.3 volts), soit des tensions d’alimentation excluant nos 3.3 volts (4.5 à 5.5 volts).
En sortie, le PNP5280 est beaucoup plus souple car les signaux à 3.3 volts peuvent très facilement être utilisés avec des circuits courants alimentés sous 5 volts et considérant 3.3 volts comme un état logique haut. Enfin, signalons l’utilisation sur la carte mère du composant HALO TG110-S050N2. Celui-ci permet la connexion du kit à un réseau Ethernet en convertissant les tensions, garantissant l’isolation et pouvant supporter un débit Ethernet de 100 Mbps. L’achat du module PNP5280 ou DNP5280 seul (sans carte mère) nécessitera l’utilisation de ce type de composant et la consultation des quelques références et documentations techniques mises à disposition par SSV. Le kit est livré avec uCLinux préinstallé.

Fig. 3

Il suffit de connecter le câble null-modem fourni (figure 3) et le bloc d’alimentation sur la carte mère. Un outil comme minicom ou cu (Call Up) configuré sur le port série de la machine hôte pour une liaison en 115200/8N1, vous permettra de contrôler un shell root sur le système cible. Vous avez ainsi accès directement au système sans aucune forme de manipulation supplémentaire (figure 4).

Fig. 4 - Source : SSV embedded System

Dans sa configuration de base, le système uCLinux installé est monté en lecture seule. Le répertoire /var est un RAMdisk et /home est un système de fichiers JFFS monté en lecture/écriture. Ainsi, pour les premiers essais, il vous est déjà possible d’installer des fichiers dans /home sans reconstruire le système.

3.dBUG

dBug est un ROM monitor/debugger. Il s’agit d’un minuscule programme permettant de déboguer des codes et, dans le cas du kit Coldfire de SSV, de configurer un certain nombre d’éléments du système. C’est également dBUG qui vous permettra de vous sortir d’un faux pas en vous permettant de réinstaller entièrement uCLinux dans la mémoire flash depuis une image compilée par vos soins ou fournie sur le CD SSV. L’activation de dBUG est relativement aisée puisqu’il suffit de placer un cavalier sur 0-1 de J10 (Interface BDM, voir figure 5).

Fig. 5 - Source : SSV embedded System

Dès le prochain reset du kit, ce n’est plus uCLinux qui démarrera mais dBUG. Avec minicom ou cu, vous verrez alors apparaître le message d’accueil suivant :

ColdFire MCF5282 on the DNP/5280-3V - RCMCFG1
Firmware v3b.1a.10 (Build 7 on Jul 13 2004 11:22:22)
Copyright 1995-2003 Motorola, Inc.  All Rights Reserved.
SSV Embedded Systems GmbH
Enter ‘help’ for help.
dBUG>

Depuis la ligne de commande, un certain nombre d’opérations peuvent être effectuées. Vous pouvez, par exemple, afficher la configuration en cours avec show :

dBUG> show
        base: 16
        baud: 115200
      server: 192.168.0.10
      client: 192.168.0.126
     gateway: 0.0.0.0
     netmask: 255.255.255.0
    filename: image.bin
    filetype: Image
     ethaddr: 02:80:AD:20:93:6D
    watchdog: off

C’est ainsi que nous pouvons configurer l’adresse du kit, celle du serveur TFTP pour le téléchargement d’images ou encore la vitesse du lien série. Dans un premier temps, ce qui nous intéresse concerne les deux premiers points. L’adresse IP du kit se configurera avec set client AAA.BBB.CCC.DDD et celle du serveur avec set server AAA.BBB.CCC.DDD. dBUG permet bien plus que cela, c’est une véritable interface de débogage. Pour en savoir plus, consultez le manuel de dBUG et essayez la commande help. Une fois la configuration en place, vérifiez-la à l’aide de show, retirez le cavalier de J10 et faites un reset de la carte.

4.Échanges entre cible et hôte

Deux méthodes de transfert de fichiers sont possibles avec le kit SSV et le système uCLinux installé par défaut. Le premier et le plus simple est également celui qui vous sera le plus utile lorsque vous développerez des applications pour cette plate-forme : NFS. Le système uCLinux est configuré, de base, pour être en mesure de monter un système de fichiers NFS mis à disposition par un hôte (de préférence la machine du développeur). Si votre système hôte est Debian, un simple apt-get install nfs-kernel-server fera l’affaire. Il ne vous restera plus, ensuite, qu’à configurer le partage NFS via /etc/exports. Exemple :

/mnt/SSV  192.168.0.126(ro,sync)

Si vous n’avez jamais configuré de serveur NFS, sachez que cette ligne permet l’accès depuis 192.168.0.126 à l’arborescence présente dans /mnt/SSV en lecture seule. L’option sync permet de respecter le protocole NFS ou, actuellement, d’éviter l’affichage d’un avertissement lors du démarrage du serveur (sync est, pour l’instant, la valeur par défaut, mais sans garantie pour l’avenir). L’option inverse, async, permet d’accélérer les échanges. Le serveur répond alors avant la fin de l’écriture des données. Le coût de cette performance est le risque de corruption des données en cas d’arrêt brutal du serveur. Ceci ne nous intéresse pas ici, le partage est en lecture seule. L’accès depuis uCLinux est d’une simplicité enfantine, puisqu’il suffit de monter le partage NFS :

# mkdir /home/devel
# mount -oro 192.168.0.10:/mnt/SSV \
  /home/devel

On comprend alors tout l’intérêt puisqu’il devient possible de tester des applications de manière transparente : compilation croisée sur le système hôte, copie dans le répertoire partagé via NFS et exécution sur le système cible. L’autre solution est presque indispensable. Il ne s’agit pas d’une simple facilité pour le développeur comme l’est le support NFS. Les échanges TFTP (Trivial FTP) permettent non seulement le transfert de fichiers entre le système de fichiers R/W d’uCLinux et l’hôte mais également la mise à jour sur système en lecture seule. En d’autres termes, pour " reflasher " le système uCLinux du kit SSV, le transfert se fera en TFTP. Côté client, uCLinux contient un binaire nommé tftp et dBUG prend en charge le protocole directement. Côté serveur, il faudra installer, par exemple, HPA’s TFTP server (paquet tftpd-hpa pour Debian). Celui-ci sera lancé depuis Xinetd (ou Inetd) via la configuration suivante :

 service tftp
{
  disable         = no
  socket_type     = dgram
  protocol        = udp
  wait            = yes
  user            = root
  server          = /usr/sbin/in.tftpd
  server_args     = -s /mnt/TFTP
}

Le seul argument à passer au serveur est -s suivi de la racine du serveur TFTP. Un redémarrage du super serveur Xinetd et le tour est joué. Depuis la cible, il suffit alors de se servir du client TFTP pour récupérer un fichier :

 # tftp -g -r /fsource \
  -l /home/fdest 192.168.0.10

Ceci téléchargera (-g) le fichier fsource présent à la racine du serveur (-r définit le fichier distant) dans /home en le nommant fdest (-l pour spécifier le fichier local). Bien entendu, cette syntaxe est un peu lourde et peut être abrégée en tftp -g -r monfichier 192.168.0.10 et vous obtiendrez alors un fichier monfichier dans le répertoire courant.

5.Environnement de développement

Un CD-R gravé par SSV accompagne les kits Coldfire. Celui-ci inclut plusieurs éléments dont des codes sources exemples et de la documentation en PDF. On y retrouve également la chaîne de compilation archivée dans le fichier auto désarchivable m68k-elf-tools-20030314.sh. Il ne s’agit, ni plus, ni moins que de l’archive des outils ELF mise à disposition sur le site officiel uClinux (http://www.uclinux.org/pub/uClinux/m68k-elf-tools/). L’installation est d’une extrême simplicité puisqu’il suffit de rendre le fichier exécutable avec un chmod et de lancer son exécution en tant que super-utilisateur root. L’ensemble des bibliothèques, des fichiers en-têtes et des binaires s’installeront dans /usr/local. Bien entendu, si vous ne faîtes pas suffisamment confiance au contenu de l’archive, il vous est possible de désarchiver manuellement l’ensemble :

$ tail -n 64998 ../m68k-elf-tools-20030314.sh | \
  tar xfzv -

Une autre solution est d’installer l’ensemble dans un environnement chrooté. Avec un système Debian, par exemple, on utilisera :

$ mkdir /mnt/chrooted
$ sudo debootstrap sarge /mnt/chrooted
$ cp m68k-elf-tools-20030314.sh /mnt/chrooted/tmp
$ sudo chroot /mnt/chrooted /bin/bash
# cd /tmp
# sh m68k-elf-tools-20030314.sh

Cette solution nécessitera davantage de travail : installation des outils complémentaires (éditeurs, serveurs, autres), création des utilisateurs, etc. En contrepartie, l’installation de chaînes de compilation pour différentes plateformes pourra se faire dans différents environnements chrootés, assurant ainsi l’absence de conflit et une isolation quasi parfaite.

6.Premiers pas, premiers codes

Vous n’y couperez pas ! Qui dit " premier code ", dit forcément " Bonjour Monde ! ". Nous allons faire cela rapidement et sans trop de douleur. Après tout, uCLinux est tellement proche d’un GNU/Linux classique qu’il n’y a pas de raison de s’en faire. Voici le source :

#include <stdio.h>
#include <stdlib.h>
int main (int argc, char **argv, char **envp)
{
  printf("Coucou monde\ndepuis uClinux sur Coldfire\n");
  return(0);
}

Et voici le Makefile :

PROJ   = hello
CC     = m68k-elf-gcc
CFLAGS = -Wall -m5307 -Wl,-elf2flt -Os
all: $(PROJ)
$(PROJ): $(PROJ).c Makefile
	$(CC) $(CFLAGS) -o $(PROJ) $(PROJ).c -lc
	chmod 755 $(PROJ)
clean:
	rm -f $(PROJ) $(PROJ).o $(PROJ).gdb

La commande make provoquera la construction des binaires hello et hello.gdb (à condition d’avoir installé la chaîne de développement bien sûr). La commande file nous en apprend un peu plus sur le type de binaire ainsi produit :

% file hello
hello: BFLT executable - version 4 ram

Le format BFLT ou Binary Flat format est un dérivé du format a.out simplifié et allégé (figure 6). Celui-ci est l’équivalent du format ELF pour uCLinux. Le fichier est créé par un appel de m68k-elf-gcc à elf2flt. La tradition ayant été respectée, nous pouvons passer à un second code bien plus en rapport avec la nature de la plate-forme.

 Fig. 6

Celui-ci a pour but de faire s’allumer et s’éteindre quelques LED connectées au port GPIO A du kit (attention au calcul des résistances ! Nous sommes en 3.3 volts). L’accès au matériel est facilité par la présence dans l’uCLinux préinstallé d’un module noyau spécifique appelé ssvhwa. Initialement développé pour faciliter le travail des développeurs portant leurs applications depuis des plateformes Coldfire plus anciennes, il permet, à notre échelle, d’avoir un accès simplifié. L’autre solution permettant d’accéder aux différents ports, bus et fonctionnalités matérielles est d’écrire un module noyau (voir les différents articles sur le Coldfire déjà parus dans GNU/Linux Magazine). Si vous avez un cahier des charges contraignant en termes de rapidité, mieux vaudra oublier l’espace utilisateur et ssvhwa et vous attaquer directement à la programmation noyau. Notez que les sources du module ssvhwa sont fournis par SSV et sont sous licence GPL.
La première étape consiste à inclure le fichier en-tête ssvhwa.h qu’on aura préalablement placé dans le répertoire du projet et à définir quelques adresses utiles.

#include <unistd.h>
#include <stdio.h>
#include "ssvhwa.h"
#define MCFBAR  0x40000000
#define PORTQA   (MCFBAR + 0x00190006)
#define PORTQB   (MCFBAR + 0x00190007)
#define DDRQA    (MCFBAR + 0x00190008)
#define DDRQB    (MCFBAR + 0x00190009)

Nous nous empressons ensuite de créer une fonction wrapper simplifiant l’écriture sur le port A :

void write_portA(unsigned char data)
{
  ssvhwa_write8(PORTQA,
    ((data & 0x0c) << 1) | (data & 0x03));
  ssvhwa_write8(PORTQB, (data >> 4));
}

Comme vous pouvez le constater, l’écriture d’une valeur en utilisant simplement les adresses mappées en mémoire n’est pas aussi simple qu’on pourrait le penser. Heureusement, les différents codes exemples fournis sur le CD du kit fournissent une excellente base de travail pour les travaux les plus simples. Malheureusement, si vous décidez de pousser plus loin, il vous faudra impérativement vous plonger dans le datasheet du Coldfire (816 pages) et dans le manuel du programmeur Coldfire (206 pages). Nous passons ensuite directement au cœur du programme en vérifiant tout d’abord l’UID en cours et en ouvrant l’accès au matériel via ssvhwa_open :

int main(void)
{
   unsigned char i;
   int loop;
   if(getuid()!=0) {
      printf("Not root... exiting !\n");
      exit(1);
   }
   if(ssvhwa_open() < 0) {
      perror("ssvhwa_open");
      exit(-1);
   }

Si tout se passe bien, nous pouvons passer les huit bits du port A en sortie :

   // Port A[0-3] output
  ssvhwa_write8(DDRQA, 0x1b);
  // Port A[4-7] output
  ssvhwa_write8(DDRQB, 0x0f);

Enfin, nous pouvons nous attacher à la boucle principale et à notre version disco de la classique " Blinking Led " :

   for(loop=100; loop>0; loop--) {
    for (i=1; i<=32; i=i*2) {
       write_portA(i);
       usleep (10000);
       write_portA(0);
     }
     for (i=32; i>0; i=i/2)
     {
       write_portA(i);
       usleep (10000);
       write_portA(0);
     }
  }

En sortie de boucle, nous n’oublions pas de refermer l’accès avant de quitter proprement :

  ssvhwa_close();
  return(0);
}

Bien entendu, ce code est délibérément simpliste et ne couvre en rien toutes les fonctionnalités offertes par le Coldfire. Il ne s’agit que d’une simple version embarquée du " Bonjour Monde ! ". Vous trouverez sur le CD du kit et sur Internet des exemples plus poussés mettant en œuvre la RTC du Coldfire, l’accès aux ports série, l’utilisation des ports en entrée ou encore le développement d’un module apportant le support du RS485.

7.Personnalisation d’uClinux

Après ce bref aperçu du développement sur Coldfire, nous allons maintenant nous tourner vers le système uClinux lui-même. SSV met à disposition une version modifiée de l’archive du 9 septembre 2003. Un patch sur cette version est également disponible. Nous continuerons nos expérimentations dans un environnement chrooté. Dans un premier temps, il conviendra d’installer les éléments complémentaires permettant le lancement de la configuration des sources uClinux (toujours avec Debian) :

% cp /cdrom/CD_SSV/uCLinux/Source/uClinux-dist-20030909-SSV20040610.tgz \
  /mnt/six2/chrooted/tmp/
% sudo chroot /mnt/six2/chrooted /bin/bash
# apt-get install build-essential \
  libncurses5-dev zlib1g zlib1g-dev
# mkdir /tftpboot
# chmod 777 /tftpboot

 Notez la création du répertoire /tftpboot à la racine du système chrooté. Celui-ci est destiné à recevoir l’image du système au terme de la construction de ce dernier. A ce stade, il est préférable de créer un utilisateur dans l’environnement chrooté afin d’éviter d’éventuelles conséquences graves suite à une erreur de manipulation. Ici, cet utilisateur sera denisch. Ceci fait, nous pouvons passer à la suite :

# su denisch
# cd
# mkdir uClinux
# cd uClinux
# tar xfzv /tmp/uClinux-dist-20030909-SSV20040610.tgz
# cd uClinux-dist-20030909-SSV20040610
# make menuconfig

La configuration des sources est quelque peu atypique. Celle-ci se compose, en effet, de deux étapes. La première présente une interface Curses permettant de choisir sa plate-forme cible (figure 7), ici SSV/DNP5280, la version du noyau Linux et le type de bibliothèque C à utiliser entre uC-Libc, glibc et uClibc (voir article FAQ). Trois checkbox permettent ensuite respectivement de :

• Default all settings : Remettre toutes les options à leur valeur par défaut en utilisant les informations fournies par le constructeur de la plate-forme sélectionnée.
• Customize Kernel Settings : Activer l’interface de configuration du noyau.
• Customize Vendor/User Settings : Activer l’interface de configuration des applications et utilitaires.
• Update Default Vendor Settings : Mettre à jour la configuration par défaut enregistrée pour le constructeur avec les valeurs actuellement définies (à utiliser avec prudence).

Nous choisirons ici de configurer le noyau et les applications avant de quitter l’interface. Conséquence directe de ces choix, nous arrivons dans l’interface de configuration du noyau Linux. On y retrouve la configuration par défaut choisie par SSV incluant le choix du processeur et de la mémoire (figure 8), le support des périphériques MTD (voir article d’introduction), etc. Certains choix ne sont pas configurés par défaut comme le support de l’API cryptographique ou le support de certains systèmes de fichiers qui pourraient s’avérer utiles (comme FAT, cf. article sur le développement de module bloc pour MMC). Dans tous les cas, configurez le noyau en ajoutant les fonctionnalités dont vous aurez besoin avant de quitter et validez l’enregistrement de la configuration.

 Fig. 7

 Fig. 8

 Fig. 9

 Nous arrivons ensuite dans l’interface de configuration des applications (figure 9). C’est ici que vous choisirez les outils dont vous pourrez avoir besoin lors du fonctionnement normal du système embarqué. SSV a activé par défaut un certain nombre d’applications qui ne vous seront pas forcément nécessaires. C’est le cas, par exemple, du serveur HTTP Boa. On retrouve dans l’interface, la configuration de Busybox où les fonctionnalités choisies feront simplement l’objet de liens symboliques. Là encore, configurez l’ensemble selon vos besoins. Notez cependant que tous les choix ne sont pas valables ou peuvent poser problème. Je n’ai malheureusement pas pu compiler uCLinux avec le support Perl activé. Faute de temps pour le présent article, le problème est resté insoluble. En se baladant dans la configuration, il est amusant de remarquer que certaines applications puissent étrangement trouver leur place dans uCLinux, comme celles de la section Games par exemple. Notez également qu’il faut prendre garde à ne pas créer de conflit entre les fonctions mises à disposition par Busybox et les versions binaires des commandes. Ne préférez, bien sûr, les versions binaires indépendantes qu’en cas de problème d’utilisation de Busybox.
Une quantité non négligeable de bibliothèques vous permettront de faciliter le développement d’applications embarquées. N’en oubliez pas pour autant les limitations dues à l’absence de MMU. Il ne s’agit pas de bibliothèques partagées. Cette partie de la configuration ne sert qu’à forcer la construction de ces bibliothèques. En temps normal, elles sont construites au besoin sans intervention de votre part. Dans tous les cas, ne vous y trompez pas, les binaires des applications uCLinux sont compilés statiquement et les bibliothèques font partie intégrante du binaire. Enfin, pensez à consulter l’aide à votre disposition. Dans la quasi-totalité des cas, celle-ci indique une taille approximative du binaire généré. Ici, en guise d’exercice, nous désactiverons simplement la compilation de Boa. Une fois les choix établis, vous pouvez quitter l’interface et enregistrer les changements. La succession des commandes make dep puis make se chargera de la construction de l’ensemble. Dans les lignes qui défilent à l’écran, vous remarquerez sans doute les options -DNO_MM -DNO_FPU -m5307 qui se passent d’explications. Au terme de la compilation, vous trouverez dans /tftpboot le fichier image.bin destiné à être installé sur le système embarqué. Copiez ce fichier à la racine de votre serveur TFTP, puis passez la carte SSV en mode dBUG. Après reset, dans l’interface de dBUG, assurez-vous que le serveur et le nom de l’image correspondent, puis téléchargez l’image en mémoire en utilisant la commande dn -i. Patientez quelques temps, le téléchargement des quelques 2 Mo peut être long. Une fois après avoir repris la main, vous pouvez flasher l’image dans la mémoire avec :
Là encore, patientez ! Au terme de l’écriture, l’image du système est utilisable. Vous pouvez alors retirer le cavalier et faire un reset du système. Bienvenue dans votre uCLinux fraîchement compilé !
Bien entendu, un problème se pose (il faut avouer que c’était un peu délibéré). Le système init tente désespérément de lancer /bin/boa, le serveur HTTP que nous avons décidé de ne pas compiler. En effet, les choix faits dans la configuration d’uCLinux n’influent pas sur les fichiers de configuration définis par SSV. Pour corriger le problème, il faut à nouveau se tourner vers les sources dans l’environnement chrooté.
Dans l’arborescence, vous trouverez un répertoire romfs. Celui-ci regroupe l’ensemble des fichiers qui constitueront le système de fichiers final. C’est là que vous trouverez le etc/inittab non à jour. Éditez simplement ce fichier pour en retirer la ligne concernant le serveur HTTP. Inutile de relancer la procédure de construction du système dans son ensemble (au contraire). Il vous suffira de générer une nouvelle image en utilisant make image. make romfs pour sa part reconstruira le contenu du répertoire du même nom en utilisant les paramètres et fichiers par défaut.

8.Conclusion

Ce bref tour d’horizon n’avait pour but que de donner les bases permettant de faire vos premiers pas dans le monde de l’embarqué avec uCLinux. Les explications données pourront être, pour la plupart, transposées à n’importe quelle architecture utilisant uCLinux. Parmi des précautions d’usage, veillez toujours à consulter les documentations du fabricant avant tout ajout ou modification matériels. Contrairement aux problèmes logiciels, une maladresse sur le matériel peut conduire à une perte sèche de votre investissement en temps et en argent. Cette remarque est valable dans une moindre mesure pour les applicatifs et le système. Notez cependant, qu’une erreur de manipulation peut effacer ou corrompre le contenu de la mémoire flash, ceci incluant dBUG. Dans ce cas, la seule solution sera de réinstaller l’ensemble via BDM, solution d’autant plus pénible qu’elle peut être évitée avec un peu de prudence.
Si vous désirez poursuivre sur l’environnement Coldfire et en particulier avec le matériel distribué par SSV, je vous conseille la lecture des différents articles de JM. Fried et S. Guinot parus dans GNU/Linux Magazine, ainsi que l’article présent dans ce numéro.

Retrouvez cet article dans : Linux Magazine Hors série 25