Je travaille avec une debian Sqeeze Grip (6.0). Les “pseudos” systèmes de fichiers /proc et /sys sont bien montés au démarrage. Le framebuffer est bien géré par le noyau. Le “touchscreen” est détecté dans /devices/virtual/input/input0. Un petit tour dans /dev que udev a peuplé pour trouver “fb0″ et “input/event0″. La gestion du touchscreen sera assuré par la librairie tslib. Celle-ci a été installé avec les paquets standards de debian (voir les autres articles). La base semble correct…En fait lors des premières compilations de Qt j’ai eu des soucis avec la librairies tslib qu’il ne trouvait pas même en ayant installé les paquets de développement. J’ai donc choisi de recompiler complètement la librairie et les utilitaires qui l’accompagne. La procédure est décrite ci-dessous.

1
2
3
4
5
6
7

root@casimir:~/qt-everywhere/# git clone http://github.com/kergoth/tslib.git
root@casimir:~/qt-everywhere/# cd tslib/
root@casimir:~/qt-everywhere/tslib# aptitude install dh-autoreconf
root@casimir:~/qt-everywhere/tslib# ./autogen.sh
root@casimir:~/qt-everywhere/tslib# ./configure --host=arm-linux-gnueabi --prefix=/usr/local/tslib --enable-static --enable-shared
root@casimir:~/qt-everywhere/tslib# make -j2
root@casimir:~/qt-everywhere/tslib# make install

La librairie tslib nécessite autoconf, d’où l’installation de autoreconf. Ensuite on compile en dynamique et en statique et enfin on installe dans /usr/local/tslib. Ce répertoire est ensuite copié intégralement sur la SDCard qui contient le ‘rootfs’ pour la carte TQ6410. On monte la carte et on copie le tout :

1
2
3

root@casimir:~/qt-everywhere/tslib# mount -t auto /dev/sdd1 /mnt
root@casimir:~/qt-everywhere/tslib# copy -R /usr/local/tslib /mnt/usr/local
root@casimir:~/qt-everywhere/tslib# sync; umount /mnt

On passe maintenant à la compilation de Qt. Sur notre machine de développement, on créée un nouveau répertoire puis on télécharge à l’aide de wget la dernière archive en date (qt-4.7.3 : 204Mo) de qt-everywhere enfin on désarchive le tout:

1
2
3
4

root@casimir:~# mkdir qt-everywhere
root@casimir:~# cd qt-everywhere
root@casimir:~/qt-everywhere# wget http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.7.3.tar.gz
root@casimir:~/qt-everywhere# tar xzvf qt-everywhere-opensource-src-4.7.3.tar.gz

On rentre dans le répertoire puis on modifie le mkspec pour un arm v6 (arm11 sur le S3C36410):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

root@casimir:~/qt-everywhere# cd qt-everywhere-opensource-src-4.7.3
root@casimir:~/qt-everywhere/qt-everywhere-opensource-src-4.7.3# vi mkspecs/qws/linux-armv6-g++/qmake.conf 
 
## qmake configuration for building for ARMv6 devices with arm-linux-g++#
 
include(../../common/g++.conf)
include(../../common/linux.conf)
include(../../common/qws.conf)
 
# modifications to g++.conf
QMAKE_CC                = arm-linux-gnueabi-gcc
QMAKE_CXX               = arm-linux-gnueabi-g++
QMAKE_LINK              = arm-linux-gnueabi-g++
QMAKE_LINK_SHLIB        = arm-linux-gnueabi-g++
QMAKE_CFLAGS           += -march=armv6
QMAKE_CXXFLAGS         += -march=armv6
 
# modifications to linux.conf
QMAKE_AR                = arm-linux-gnueabi-ar cqs
QMAKE_OBJCOPY           = arm-linux-gnueabi-objcopy
QMAKE_STRIP             = arm-linux-gnueabi-strip
 
QMAKE_INCDIR += /usr/local/tslib/include/
QMAKE_LIBDIR += /usr/local/tslib/lib/
QMAKE_LFLAGS += -Wl,-rpath-link=/usr/local/tslib/lib
 
load(qt_config)

On adapte l’existant pour faire pointer vers notre chaine de cross-compilation (ici arm-linux-gnueabi-xxxx), on rajoute les lignes QMAKE_INCDIR, QMAKE_LIBDIR pour qu’il utilise les includes et librairies de la TSLIB. La ligne QMAKE_LFLAGS permet d’éviter une erreur à l’édition de lien (voir ce lien). On lance ensuite la création des ‘makefiles’ puis la compilation et l’installation avec les commandes suivantes:

1
2
3

root@casimir:~/qt-everywhere/qt-everywhere-opensource-src-4.7.3# ./configure -embedded arm -xplatform qws/linux-armv6-g++ -prefix /usr/local/Qt -qt-mouse-tslib -little-endian
root@casimir:~/qt-everywhere/qt-everywhere-opensource-src-4.7.3# make -j2
root@casimir:~/qt-everywhere/qt-everywhere-opensource-src-4.7.3# make install

Dans la ligne ‘configure’ on génère tous les exemples, démos, docs, librairies, etc…Je l’ai laissé pour être sur de tout avoir correctement cependant la durée de compilation sur ma machine est énorme (plus de 6H : attention c’est un athlon et un disque ide de 40Go). Si une erreur apparaît en disant qu’il ne trouve pas la tslib, passez l’argument ‘-v’ à la commande configure puis regarder les logs. Dans la plupart des cas c’est qu’il ne trouve pas le compilateur : mettre dans le qmake.conf le nom et le chemin complet du cross-compilateur. Le ‘make install’ n’est pas strictement nécessaire car il va copier dans /usr/local/Qt l’ensemble des fichiers. Ca fait un peu doublon mais ensuite je vais transférer ce répertoire directement sur la carte SD qui contient ma debian lenny Grip (procédure identique à la copie de la tslib, ici le répertoire source est /usr/local/Qt).

Du coté de la carte TQ6410, je désinstalle les paquets que j’avais installé auparavant et qui risque de gêner quand je vais installer Qt: nodm, matchbox et libts:

1
2
3

root@TQ6410-Iris:~# aptitude remove --purge matchbox
root@TQ6410-Iris:~# aptitude remove --purge nodm
root@TQ6410-Iris:~# aptitude remove --purge libts-0.0-0

On installe ensuite la tslib que l’on a compilé auparavant sur notre machine de développement et on informe que l’on a de nouvelles librairies en créant un fichier /etc/ld.so.conf/tslib.conf qui contient le chemin vers les nouvelles librairies. Dans mon cas ce sera: /usr/local/tslib/lib. On met à jour la configuration en lançant ldconfig. Ensuite éditez le fichier /usr/local/tslib/etc/ts.conf pour décommenter la ligne qui contient ‘module raw’. Faire ensuite tous les exports de la tslib en faisant bien attention aux chemins et en laissant TSLIB_CALIBFILE= vide.

1
2
3
4
5
6
7
8

export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_CALIBFILE=
export TSLIB_CONFFILE=/usr/local/tslib/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/local/tslib/lib/ts
export QWS_MOUSE_PROTO=tslib:/dev/input/event0

On lance ensuite la calibration de l’écran avec:

1

root@TQ6410-Iris:~#/usr/local/bin/ts_calibrate /usr/local/tslib/etc/ts.calib

Vous appuyez sur les croix qui apparaissent…vous obtenez alors un fichier de calibration de l’écran. Vous pouvez alors faire l’export de TSLIB_CALIBFILE correctement:

1

export TSLIB_CALIBFILE=/usr/local/tslib/etc/ts.calib

Pour tester lancez : /usr/local/tslib/bin/ts_test. Si c’est bon vous pouvez tester les applications Qt que vous avez compilé précédemment. Elles sont disponibles dans /usr/local/Qt/examples et demos. Quand vous lancez une application, il faut faire:

./nom_appli -qws pour la lancer en mode embarqué. Si les caractères sont illisibles à l’écran, il faut rajouter deux variables aux précédentes:

1
2

export QWS_SIZE=800x600
export QWS_DISPLAY="LinuxFb:mmWidth=160:mmHeight=100"

Ces variables correspondent bien sur à mon écran (ici un 7”). J’ai ensuite récupéré une démonstration de ‘widget’ pour l’embarqué pour les compiler. J’ai suivi la procédure de pobot mais j’ai désarchivé dans /usr/local/Qt. J’ai donc un nouveau répertoire du nom de ‘embedded-widgets-1.1.0′. Pour compiler ces nouveaux exemples, j’ai tapé ces lignes dans le répertoire précédemment cité:

1
2
3

export PATH=/usr/local/Qt/bin:$PATH
/usr/local/Qt/bin/qmake -spec qws/linux-armv6-g++
make

J’ai ensuite transféré ce répertoire sur ma carte SD et testé sur la carte TQ6410. Cela fonctionne très bien et les widgets sont réellement impressionnants.

Le démarrage de la carte à froid (cold boot) se déroule dans cet ordre :

1. Lancement du chargeur intégré à la puce SoC (chez TI : X-Loader, chez Samsung ?) qui charge U-Boot depuis la flash NAND
2. Démarrage de U-Boot qui s’occupe du chargement de l’image noyau depuis la flash NAND en RAM
3. Décompression du noyau et démarrage de celui-ci
4. Montage du système de fichiers racine puis passage à INIT
5. Fin de l’initialisation : “UserLand” : vos applications

Le chargeur de la puce ne m’est pas accessible donc pas d’optimisation la dessus ! Nous allons donc commencer par U-Boot. Mais pour optimiser le temps de chargement, il faut pouvoir mesurer le temps de chaque étape. J’ai choisi d’utiliser GrabSerial (présentation et installation ici) pour faire les mesures de temps car il n’apporte pas de surcharge du coté système embarqué. GrabSerial utilise Python et necessite un module python à installer avec la commande suivante:

1

root@casimir:~# aptitude install python-serial

Il faut ensuite télécharger le script python GrabSerial, le rendre exécutable (chmod +x) et enfin le lancer avec une commande du style:

1

root@casimir:~# ./grabserial.py -v -t -m "Starting kernel.*"

qui va permettre d’intercepter les caractères arrivant sur la voie série ttyS0 et qui remet à 0 le compteur de temps lorsque “Starting kernel” apparaitra… Vous avez un exemple d’une trace issu de GrabSerial en fin d’article sur la personnalisation de la carte TQ6410.

Optimisation de U-Boot

Nous allons commencer par les optimisations simples (sous entendu sans recompilation du code) :

1. Le ‘u-Boot’ fourni avec la carte attend pendant 3s que vous tapiez sur une touche pour arrêter le chargement. On peut réduire ce temps à ‘0s’ et ainsi gagner 3s mais vous n’aurez plus accès au menu de U-Boot. Il faudra alors reflasher le U-Boot d’origine depuis la flash NOR. Pour fixer ce temps à ‘0′, quitter le menu de U-Boot pour passer à l’interpréteur de commande : Quit to shell (lettre ‘q’) puis tapez ’set bootdelay 0′. Si vous souhaitez conserver cette option, tapez ’saveenv’.
2. Vérifiez que la vitesse de transmission du port série est à 115200. Toujours depuis le shell de U-Boot, tapez ‘printenv’ puis vérifiez que la variable ‘baudrate’ est à 115200 sinon la fixer avec ’set baudrate 115200′.
3. U-Boot effectue une somme de contrôle sur le noyau qu’il charge. On peut désactiver cette option en tapant ’set verify no’.
4. Toutes les sorties vers la voie série ralentissent énormément U-Boot. Pour désactiver les sorties il faut que le code soit compiler avec ‘#define CONFIG_SILENT_CONSOLE’ et mettre à 1 la variable silent: ’set silent 1′. J’ai essayé de recompiler le code fourni avec la carte avec l’option ci-dessus mais cela n’a rien changé sur le fait qu’il m’affiche les messages de lecture de la flash NAND lors du chargement du noyau. Il faut donc que je trouve dans le code ou est ce “printf” qui ralentit énormément la lecture en flash NAND…
5. Par défaut si on ne touche pas au menu de U-Boot, au bout de 3s, la commande ‘bootcmd’ est exécutée. Or cette commande lit  0×500000 octets soit 5 242 880 octets avec le U-Boot fourni par le vendeur de la carte. Ceci même si votre noyau fait 1,2Mo. Il faut donc modifier cette commande pour ne lire que ce qui est nécessaire en flash NAND pour démarrer le noyau. Par exemple, un des noyaux (uImage) que j’ai compilé pour cette plateforme fait 1 246 156 octets qu’il faut aligner sur la flash NAND (padder en anglais) sur des secteurs de 2 048 octets donc on fait 1 246 156/2 048 = 608,47. On prend 609+1=610 et on remultiplie par 2048, on obtient 1 249 280 octets soit 0×13 100 en hexadécimal. On tapera donc la commande suivante pour fixer ‘bootcmd’ : set bootcmd ‘nand read.i c0008000 80000 13100; bootm c0008000′. On charge en RAM (0xc000800) à partir de l’adresse 0×80000 de la flash NAND (adresse ou l’on télécharge  le noyau en flash avec la lettre ‘k’ du menu) 0×131000 octets. On gagne ainsi un temps précieux. Remarquez que si vous tapez la lettre ‘b’ du menu, c’est toujours 5Mo qui seront lu depuis la flash car la commande est codé en “dur” dans le code.

On obtient la trace suivante:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

[    0.000003]
[    0.289005]
[    0.289216] U-Boot 1.1.6 (Aug  5 2011 - 11:50:17) for TQ6410
[    0.293653]
[    0.293860]
[    0.294013] CPU:     S3C6410@532MHz
[    0.296218]          Fclk = 532MHz, Hclk = 133MHz, Pclk = 66MHz, Serial = CLKUART (SYNC Mode)
[    0.303626] Board:   TQ6410
[    0.305115] DRAM:    128 MB
[    0.306488] Flash:   0 kB
[    0.307700] NAND:    256 MB
[    0.399982] In:      serial
[    0.401473] Out:     serial
[    0.402932] Err:     serial
[    0.483943] MAC: 08:90:90:90:90:90
[    0.486062] Hit any key to stop autoboot:  3  2  1  0
[    3.468708]
[    3.468897] NAND read: device 0 offset 0x80000, size 0x131000
[    3.473340]
[    3.473511] Reading data from 0x80000 --   0% complete.Reading data from 0x83000 --   1% complete.Reading data from 0x86000 --   2% complete.Reading data from 0x89000 --   3% complete.Reading data from 0x8c000 --   4% complete.Reading data from 0x8f000 --   5% complete.Reading data from 0x92000 --   6% complete.Reading data from 0x95000 --   7% complete.Reading data from 0x98000 --   8% complete.Reading data from 0x9b000 --   9% complete.Reading data from 0x9e000 --  10% complete.Reading data from 0xa1800 --  11% complete.Reading data from 0xa4800 --  12% complete.Reading data from 0xa7800 --  13% complete.Reading data from 0xaa800 --  14% complete.Reading data from 0xad800 --  15% complete.Reading data from 0xb0800 --  16% complete.Reading data from 0xb3800 --  17% complete.Reading data from 0xb6800 --  18% complete.Reading data from 0xb9800 --  19% complete.Reading data from 0xbc800 --  20% complete.Reading data from 0xc0000 --  21% complete.Reading data from 0xc3000 --  22% complete.Reading data from 0xc6000 --  23% complete.Reading data from 0xc9000 --  24% complete.Reading data from 0xcc000 --  25% complete.Reading data from 0xcf000 --  26% complete.Reading data from 0xd2000 --  27% complete.Reading data from 0xd5000 --  28% complete.Reading data from 0xd8000 --  29% complete.Reading data from 0xdb000 --  30% complete.Reading data from 0xde800 --  31% complete.Reading data from 0xe1800 --  32% complete.Reading data from 0xe4800 --  33% complete.Reading data from 0xe7800 --  34% complete.Reading data from 0xea800 --  35% complete.Reading data from 0xed800 --  36% complete.Reading data from 0xf0800 --  37% complete.Reading data from 0xf3800 --  38% complete.Reading data from 0xf6800 --  39% complete.Reading data from 0xf9800 --  40% complete.Reading data from 0xfd000 --  41% complete.Reading data from 0x100000 --  42% complete.Reading data from 0x103000 --  43% complete.Reading data from 0x106000 --  44% complete.Reading data from 0x109000 --  45% complete.Reading data from 0x10c000 --  46% complete.Reading data from 0x10f000 --  47% complete.Reading data from 0x112000 --  48% complete.Reading data from 0x115000 --  49% complete.Reading data from 0x118000 --  50% complete.Reading data from 0x11b800 --  51% complete.Reading data from 0x11e800 --  52% complete.Reading data from 0x121800 --  53% complete.Reading data from 0x124800 --  54% complete.Reading data from 0x127800 --  55% complete.Reading data from 0x12a800 --  56% complete.Reading data from 0x12d800 --  57% complete.Reading data from 0x130800 --  58% complete.Reading data from 0x133800 --  59% complete.Reading data from 0x136800 --  60% complete.Reading data from 0x13a000 --  61% complete.Reading data from 0x13d000 --  62% complete.Reading data from 0x140000 --  63% complete.Reading data from 0x143000 --  64% complete.Reading data from 0x146000 --  65% complete.Reading data from 0x149000 --  66% complete.Reading data from 0x14c000 --  67% complete.Reading data from 0x14f000 --  68% complete.Reading data from 0x152000 --  69% complete.Reading data from 0x155000 --  70% complete.Reading data from 0x158800 --  71% complete.Reading data from 0x15b800 --  72% complete.Reading data from 0x15e800 --  73% complete.Reading data from 0x161800 --  74% complete.Reading data from 0x164800 --  75% complete.Reading data from 0x167800 --  76% complete.Reading data from 0x16a800 --  77% complete.Reading data from 0x16d800 --  78% complete.Reading data from 0x170800 --  79% complete.Reading data from 0x173800 --  80% complete.Reading data from 0x177000 --  81% complete.Reading data from 0x17a000 --  82% complete.Reading data from 0x17d000 --  83% complete.Reading data from 0x180000 --  84% complete.Reading data from 0x183000 --  85% complete.Reading data from 0x186000 --  86% complete.Reading data from 0x189000 --  87% complete.Reading data from 0x18c000 --  88% complete.Reading data from 0x18f000 --  89% complete.Reading data from 0x192000 --  90% complete.Reading data from 0x195800 --  91% complete.Reading data from 0x198800 --  92% complete.Reading data from 0x19b800 --  93% complete.Reading data from 0x19e800 --  94% complete.Reading data from 0x1a1800 --  95% complete.Reading data from 0x1a4800 --  96% complete.Reading data from 0x1a7800 --  97% complete.Reading data from 0x1aa800 --  98% complete.Reading data from 0x1ad800 --  99% complete.Reading data from 0x1b0800 -- 100% complete.
[    4.672055]  1249280 bytes read: OK
[    4.678741] ## Booting image at c0008000 ...
[    4.679811]    Image Name:   Linux-2.6.28.6-IRIS-Turgot-O.Dar
[    4.684310]    Image Type:   ARM Linux Kernel Image (uncompressed)
[    4.686018]    Data Size:    1246092 Bytes =  1.2 MB
[    4.688032]    Load Address: 50008000
[    4.692227]    Entry Point:  50008000
[    4.999951] OK
[    5.000117]
[    5.000197] Starting kernel ...

J’ai laissé volontairement la ‘longuuuuue’ chaine qui indique la progression de la lecture en flash. Je pense que cette sortie vers la voie série ralentit énormément le boot. Je recherche donc dans les codes sources comment supprimer cette sortie… Je viens de trouver ! C’est dans le fichiers drivers/nand/nand_util.c…faire une recherche avec “Reading” et commenter la ligne : printf(”\rReading data from…percent);.  Je recompile le tout et je fais un test avec et sans cette sortie avec GrabSerial:

• avec la sortie “Reading…” : 1,204s pour charger le noyau (1,2Mo) depuis la flash NAND
• sans la sortie “Reading….” : 0,832s pour charger le noyau (1,2Mo) depuis la flash NAND

Conclusion : prêt de 30% de temps de gagner ! Dans la plupart des cas limiter les sorties vers l’écran ou la voie série permet de gagner du temps (voir plus loin pour le noyau avec le ‘printk’ et l’option ‘quiet’). J’obtiens un temps de 1,6s depuis le démarrage à froid jusqu’au message ‘Starting kernel’ et 14,4s jusqu’à l’affichage du login avec un rootfs en ext3 sur carte SD.

Optimisation du noyau Linux

J’ai modifié la configuration de base fourni par le vendeur pour qu’elle corresponde à nos besoins. En clair moins vous mettez de ‘choses’ dans votre noyau, plus celui-ci est petit et plus il charge vite. Actuellement j’ai gardé le nécessaire pour faire tourner la carte correctement, cependant comme je n’ai pas encore choisi le système de fichiers du ‘rootfs’ j’ai gardé le support du ext3, de yaffs, de jffs2 avec tous les systèmes de compression et ubifs. Une fois que j’aurais décidé lequel je garde j’éliminerai les autres et je gagnerai du temps au boot. De plus afin d’avoir des indication de temps par le noyau j’ai compilé celui-ci avec le support du “printk”, on pourra l’éliminer par la suite.

Pour l’instant on peut appliquer des modifications à la ligne de commande du noyau Linux. Comme précédemment, limiter les sorties vers l’écran ou la voie série permet de gagner du temps. Donc la première chose à changer et de rajouter le paramètre ‘quiet’. Un petit test avec GrabSerial et on obtient :

• messages du noyau affichés : de “Starting kernel” au lancement de INIT : 2,255s
• messages du noyau cachés :  de “Starting kernel” au lancement de INIT : 1,707s

Conclusion: on gagne 548ms rien qu’avec ce paramètre !

A chaque démarrage, on recalibre la durée d’une boucle appelée ‘loop_per_jiffy’ ou LPJ associée au BogoMips. Or le noyau nous donne la valeur de la calibration pendant le boot. Il suffit donc de passer ce paramètre au noyau pour éviter cette calibration. Dans mon cas, la ligne qui nous interesse est la suivante:

1

Calibrating delay loop... 353.89 BogoMIPS (lpj=884736)

A priori cette opération dure 110ms mais la sortie ‘printk’ du noyau n’est sans doute pas assez précise. Faisons un test avec GrabSerial. J’obtiens:

• avec boucle de calibrage: de “Starting kernel” au lancement de INIT : 1,707s
• sans boucle de calibrage: de “Starting kernel” au lancement de INIT : 1,599s

Conclusion: environ 110ms de gagner ! Dans les messages noyau on obtient:

1

Calibrating delay loop (skipped) preset value.. 353.89 BogoMIPS

On obtient actuellement un temps de 13,184s pour l’arrivée jusqu’au login mais surtout on met 3,228s jusqu’à INIT.

La décompression du noyau au départ prend 560ms, ce qui est loin d’être négligeable. J’ai testé avec un noyau non compressé mais c’est plus défavorable donc il faudrait que la décompression soit plus rapide. Dans la version de mon noyau (2.6.38), l’image est compressé avec ZLIB et je n’ai pas d’autres choix. Apparemment si vous pouvez choisir votre système de décompression, il faut prendre LZO !

Choix du système de fichiers racine parmi ext3, JFFS2, YAFFS2 et UBIFS

Pour continuer à optimiser le temps de boot, je me suis dit que l’on pouvait certainement gagner sur le temps de montage du rootfs. Pendant tous les tests précédents on monte le rootfs depuis une carte SD formatée en ext3. Le paramètre ‘rootwait’ du noyau permet d’attendre le système de fichiers. Cette attente est donnée dans les messages du noyau, ici elle vaut (du message ‘Waiting for root device /dev/mmcblk0p1…’ à ‘VFS: Mounted root (ext3 filesystem)’) 435ms.

Au boot 3 “pseudos” partitions sont créées aux adresses indiquées ci-dessous dans la flash NAND, on le voit avec les messages du noyau suivant:

1
2
3
4
5
6
7

S3C NAND Driver, (c) 2008 Samsung Electronics
S3C NAND Driver is using hardware ECC.
NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":
0x00000000-0x00080000 : "Bootloader"
0x00080000-0x00580000 : "Kernel"
0x00580000-0x10000000 : "File System"

On va donc s’interresser à la troisième partition “File System” qui va contenir le système de fichiers racine. Comme on démarre actuellement sur la carte SD, on peut effacer sans problème cette “partition”. Pour cela vous devez disposer des outils de manipulation des Flashs NOR et NAND. Ceux-ci s’installent avec la commande suivante depuis le système embarqué et nous allons tester quelques commandes :

1
2
3
4
5
6
7
8
9
10
11

root@TQ6410-Iris:~# aptitude install mtd-utils
root@TQ6410-Iris:~# mtdinfo /dev/mtd2
mtd2
Name:                           File System
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          2004 (262668288 bytes, 250.5 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  unknown
Bad blocks are allowed:         true
Device is writable:             true

On remarque bien que la flash NAND s’efface par blocs de 128Ko et que l’unité de base est de 2048octets.

Système de fichiers JFFS2 sur flash NAND

On va commencer par tester le système de fichiers JFFS2. Pour mémoire dans la configuration du noyau, j’ai activé toutes les méthodes de compression avec une préférence pour LZO (compression plus faible que ZLIB ou BZip2 mais vitesse de décompression trés rapide). On va donc initialiser cette partition pour qu’elle acceuille un système de fichiers JFFS2:

1
2
3
4
5
6
7
8

root@TQ6410-Iris:~# flash_eraseall -j /dev/mtd2
Erasing 128 Kibyte @ 62c0000 -- 39 % complete. Cleanmarker written at 62c0000.
Skipping bad block at 0x062e0000
Erasing 128 Kibyte @ 8e60000 -- 56 % complete. Cleanmarker written at 8e60000.
Skipping bad block at 0x08e80000
Erasing 128 Kibyte @ 95e0000 -- 59 % complete. Cleanmarker written at 95e0000.
Skipping bad block at 0x09600000
Erasing 128 Kibyte @ fa80000 -- 100 % complete.Cleanmarker written at fa60000.

On remarque que la flash NAND a des erreurs. Le système de fichiers en tiendra compte ! On monte notre “pseudo” partition dans /mnt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

root@TQ6410-Iris:~# mount -t jffs2 /dev/mtdblock2 /mnt
root@TQ6410-Iris:~# mount
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rootfs on / type rootfs (rw)
/dev/mtdblock2 on /mnt type jffs2 (rw)
root@TQ6410-Iris:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
/dev/mtdblock2        251M  5.9M  245M   3% /mnt

Nous disposons donc d’un espace conséquent pour le stockage de notre système de fichiers racine (prés de 245Mo avant compression). Pour installer le système de fichiers racine dans cette espace, j’ai créé auparavant une archive tar.bz2 de mon système qui tourne actuellement sur la carte SD. Comment faire ? Trés simple, sur votre système de développement montez cette carte SD avec une commande du style : mount -t auto /dev/sdd1 /mnt puis créez l’archive avec tar jcf rootfs-debian-squeeze-grip-for-TQ6410.tar.bz2 /mnt/*. Vous obtenez alors une archive de votre système de fichiers racine (chez moi cette archive fait 22Mo) que vous allez copier sur la carte SD avec cp rootfs-debian-squeeze-grip-for-TQ6410.tar.bz2 /mnt pour ensuite le désarchiver vers la NAND Flash. Démontez votre carte SD avec umount /mnt. On admet que l’on reprend la suite des commandes ci-dessus et que vous disposez de l’archive à la racine de la carte SD Au fait si vous n’arrivez pas à désarchivez l’archive c’est que vous n’avez probablement pas bzip2 d’installé…un petit aptitude install bzip2 réglera l’affaire !

On désarchive donc notre système de fichiers racine vers /mnt qui représente le mtd2 de la flash NAND (attention soyez patient) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

root@TQ6410-Iris:~# cd /mnt
root@TQ6410-Iris:/mnt# tar jxf /debian-squeeze-grip-OD.tar.bz2 .
root@TQ6410-Iris:/mnt# ls /mnt
bin   dev  home  lost+found  mnt  proc  sbin     srv  tmp  var
boot  etc  lib   media       opt  root  selinux  sys  usr
root@TQ6410-Iris:/mnt# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
/dev/mtdblock2        251M   42M  210M  17% /mnt
root@TQ6410-Iris:/mnt# du -h --max-depth=1 /mnt
3.9M    /mnt/bin
512     /mnt/dev
361K    /mnt/etc
7.3M    /mnt/lib
0       /mnt/mnt
0       /mnt/opt
0       /mnt/srv
0       /mnt/tmp
0       /mnt/sys
8.3M    /mnt/var
40M     /mnt/usr
0       /mnt/boot
0       /mnt/home
0       /mnt/proc
3.3M    /mnt/sbin
14K     /mnt/root
0       /mnt/media
0       /mnt/selinux
0       /mnt/lost+found
63M     /mnt

On vérifie le contenu de la flash NAND avec un ‘ls’. On regarde combien on a mangé de place (ici 42Mo) et combien on occupe effectivement de place (ici 63Mo). On travaille donc bien sur un système de fichiers compressé mais adapté au mémoire flash (c’est à dire que l’on réparti les écritures pour moyenner l’usure (wear-levelling)) et relativement résistant au coupure électrique brusque puisque journalisé ! Reste à savoir le temps de montage au boot. Redémarrez puis arrêtez U-Boot car il nous faut modifier la ligne de passage d’arguments au noyau (lettre ’s’) :

1

console=ttySAC0,115200 root=/dev/mtdblock2 rootfstype=jffs2 init=/sbin/init quiet noswap lpj=884736

Je retire la carte SD puis on fait donc le test du temps de boot avec GrabSerial. J’obtiens un temps de 18,383s depuis la mise sous tension jusqu’a l’obtention du login. Mais ce n’est pas vraiment ce qui m’interesse. Il faut fouiller les messages du noyau pour tenter de repérer le temps de montage :

1
2
3
4
5
6
7

[21474536.705000] TCP cubic registered
[21474536.705000] NET: Registered protocol family 17
[21474536.705000] VFP support v0.3: implementor 41 architecture 1 part 20 varia5
[21474536.710000] s3c2410-rtc s3c2410-rtc: setting system clock to 2011-08-08 2)
[21474539.275000] s3c64xx_clk_doutmpll_get_rate: parent is 532000000
[21474539.560000] VFS: Mounted root (jffs2 filesystem).
[21474539.560000] Freeing init memory: 96K

On passe de 36.71s à 39.275s or ce n’est pas la synchronisation de l’horloge système avec la RTC qui prend aussi longtemps. J’estime donc que le temps de montage est 39.56 - 36.71 = 2,85s pour monter les 250Mo de cette partition. Si vous cherchez un peu sur Internet vous verrez que le reproche fait à JFFS2 est son temps de montage or ici il est loin d’être catastrophique…bon j’ai triché un peu :-). Il existe un paramètre pour le système de fichiers JFFS2 qui permet de monter beaucoup plus vite le système de fichiers dans le noyau :  [*] JFFS2 summary support. J’ai fait le test sans ce paramètre et le temps de montage sur la même partition est alors de 14s ! Bon on s’éloigne de notre but : démarrez plus vite mais on s’est rapproché de coté ‘clair’ de la force : on a un système rootfs sur une flash NAND et pas sur une SD.

Conclusion: globalement on va moins vite mais on s’est rapproché d’un ‘vrai’ système embarqué…de plus la compression, la jounalisation et le wear-levelling sont interessants.

Système de fichiers YAFFS2 sur flash NAND

On va recommencer un peu la même chose que précédemment avec un système de fichiers YAFFS2. Cette fois-ci je commence par la capture d’écran des paramètres noyau pour le système de fichiers YAFFS2:

Donc on redémarre sur notre carte SD pour pouvoir manipuler sans problème la flash NAND. On enchaine donc les commandes suivantes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

root@TQ6410-Iris:~# flash_eraseall /dev/mtd2
Erasing 128 Kibyte @ 62c0000 -- 39 % complete.
Skipping bad block at 0x062e0000
Erasing 128 Kibyte @ 8e60000 -- 56 % complete.
Skipping bad block at 0x08e80000
Erasing 128 Kibyte @ 95e0000 -- 59 % complete.
Skipping bad block at 0x09600000
Erasing 128 Kibyte @ fa80000 -- 100 % complete.
root@TQ6410-Iris:~# mount -t yaffs2 /dev/mtdblock2 /mnt
[21474611.890000] yaffs: dev is 32505858 name is "mtdblock2"
[21474611.890000] yaffs: passed flags ""
[21474611.895000] yaffs: Attempting MTD mount on 31.2, "mtdblock2"
[21474612.095000] yaffs_read_super: isCheckpointed 0
root@TQ6410-Iris:~# mount
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rootfs on / type rootfs (rw)
/dev/mtdblock2 on /mnt type yaffs2 (rw)
root@TQ6410-Iris:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
/dev/mtdblock2        251M  1.5M  249M   1% /mnt
root@TQ6410-Iris:~# cd /mnt
root@TQ6410-Iris:/mnt# tar jxf /debian-squeeze-grip-OD.tar.bz2 .
root@TQ6410-Iris:/mnt# ls /mnt
bin   dev  home  lost+found  mnt  proc  sbin     srv  tmp  var
boot  etc  lib   media       opt  root  selinux  sys  usr
root@TQ6410-Iris:/mnt# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
/dev/mtdblock2        251M   81M  170M  33% /mnt
root@TQ6410-Iris:/mnt# du -h --max-depth=1 /mnt
532K    /mnt/etc
2.0K    /mnt/boot
18K     /mnt/root
2.0K    /mnt/home
2.0K    /mnt/mnt
2.0K    /mnt/srv
41M     /mnt/usr
3.3M    /mnt/sbin
2.0K    /mnt/tmp
2.0K    /mnt/opt
2.0K    /mnt/selinux
2.0K    /mnt/media
3.9M    /mnt/bin
8.4M    /mnt/var
2.0K    /mnt/proc
92K     /mnt/dev
2.0K    /mnt/sys
7.3M    /mnt/lib
2.0K    /mnt/lost+found
64M     /mnt

Quelques remarques sur ce qui précède : on efface d’abord la flash NAND, puis on monte cette partition en YAFFS2, on voit que trés peu de place est occupé au montage (à peine 1,5Mo). On désarchive le ‘rootfs’. Puis on regarde la place occupée sur le support : prés de 80Mo !! sur 64Mo effectif…on perd donc beaucoup de bloc mémoire. Le système de fichiers n’est pas compressé. On redémarre sur ce système de fichier avec les paramètres suivants:

1

console=ttySAC0,115200 root=/dev/mtdblock2 rootfstype=yaffs2 init=/sbin/init quiet noswap lpj=884736

A nouveau on regarde ce que ça donne au point de vue temps de boot avec GrabSerial. J’obtiens un temps de 13,215s depuis la mise sous tension jusqu’à l’obtention du login. Ce n’est pas mal du tout puisque l’on est au même niveau que le boot sur la SD en ext3. Fouillons les messages du noyau pour tenter de repérer le temps de montage :

1
2
3
4
5
6

[21474536.710000] yaffs: dev is 32505858 name is "mtdblock2"
[21474536.710000] yaffs: passed flags ""
[21474536.710000] yaffs: Attempting MTD mount on 31.2, "mtdblock2"
[21474536.960000] yaffs: restored from checkpoint
[21474536.960000] yaffs_read_super: isCheckpointed 1
[21474536.960000] VFS: Mounted root (yaffs2 filesystem).

On obtient un temps de 36.96 - 36.71 = 250ms ce qui est assez remarquable…à moins que je me sois trompé quelque part mais là je vois pas où car j’ai suivi la même procédure que pour le JFFS2.

Conclusion: on est au même niveau que la carte SD en ext3 mais avec un système de fichier pour flash NAND journalisé. On est aussi plus ’système embarqué’. Le seul souci c’est qu’il ne compresse pas à la volée. Je n’ai pas cherché si cela est possible…En tout cas cela semble être un bon choix comme futur système de fichiers pour notre système.

Système de fichiers UBIFS sur flash NAND

C’est sans doute le système de fichiers le plus compliqué à mettre en place avec une méthode identique aux précédents. Les paramètres du noyau sont les suivants:

Pour mémoire on travaille sur la MTD2 qui doit contenir le rootfs.On va donc commencer par effacer la flash NAND puis formater le MTD avec ubiformat:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

root@TQ6410-Iris:~# flash_eraseall /dev/mtd2
Erasing 128 Kibyte @ 62c0000 -- 39 % complete.
Skipping bad block at 0x062e0000
Erasing 128 Kibyte @ 8e60000 -- 56 % complete.
Skipping bad block at 0x08e80000
Erasing 128 Kibyte @ 95e0000 -- 59 % complete.
Skipping bad block at 0x09600000
Erasing 128 Kibyte @ fa80000 -- 100 % complete.
root@TQ6410-Iris:~# ubiformat /dev/mtd2
ubiformat: warning!: your MTD system is old and it is impossible to detect sub-page size. Use -s to get rid of this warning
ubiformat: assume sub-page to be 2048
ubiformat: mtd2 (nand), size 262668288 bytes (250.5 MiB), 2004 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 2003 -- 100 % complete
ubiformat: 2001 eraseblocks have valid erase counter, mean value is 0
ubiformat: bad eraseblocks: 791, 1140, 1200
ubiformat: formatting eraseblock 2003 -- 100 % complete

J’essaye alors “d’attacher” ce mtd au système (paramètres -m 2 ci-dessous) :

1
2
3
4
5
6
7
8
9
10
11
12
13

oot@TQ6410-Iris:~# ubiattach /dev/ubi_ctrl -m 2
[  748.290000] UBI: attaching mtd2 to ubi0
[  748.290000] UBI: physical eraseblock size:   131072 bytes (128 KiB)
[  748.295000] UBI: logical eraseblock size:    129024 bytes
[  748.300000] UBI: smallest flash I/O unit:    2048
[  748.305000] UBI: sub-page size:              512
[  748.310000] UBI: VID header offset:          512 (aligned 512)
[  748.315000] UBI: data offset:                2048
[  748.330000] UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512
[  748.330000] UBI error: validate_ec_hdr: bad EC header
[  748.335000] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0
ubiattach: error!: cannot attach mtd2
           error 22 (Invalid argument)

Bon il y a un soucis…Aprés une petite recherche sur internet, je trouve la réponse sur ce site : http://www.linux-mtd.infradead.org/faq/ubifs.html#L_mount_ubifs. Il faut reformatter la MTD en précisant la taille des “sous-pages” puis on retente d’attacher :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

root@TQ6410-Iris:~# ubiformat /dev/mtd2 -s 512
ubiformat: mtd2 (nand), size 262668288 bytes (250.5 MiB), 2004 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 2003 -- 100 % complete
ubiformat: 2001 eraseblocks have valid erase counter, mean value is 1
ubiformat: bad eraseblocks: 791, 1140, 1200
ubiformat: warning!: VID header and data offsets on flash are 2048 and 4096, which is different to requested offsets 512 and 2048
ubiformat: use new offsets 512 and 2048? (yes/no)  yes
ubiformat: use offsets 512 and 2048
ubiformat: formatting eraseblock 2003 -- 100 % complete
root@TQ6410-Iris:~# ubiattach /dev/ubi_ctrl -m 2
[ 1443.140000] UBI: attaching mtd2 to ubi0
[ 1443.140000] UBI: physical eraseblock size:   131072 bytes (128 KiB)
[ 1443.145000] UBI: logical eraseblock size:    129024 bytes
[ 1443.150000] UBI: smallest flash I/O unit:    2048
[ 1443.155000] UBI: sub-page size:              512
[ 1443.160000] UBI: VID header offset:          512 (aligned 512)
[ 1443.165000] UBI: data offset:                2048
[ 1444.270000] UBI: attached mtd2 to ubi0
[ 1444.270000] UBI: MTD device name:            "File System"
[ 1444.275000] UBI: MTD device size:            250 MiB
[ 1444.280000] UBI: number of good PEBs:        2001
[ 1444.285000] UBI: number of bad PEBs:         3
[ 1444.290000] UBI: max. allowed volumes:       128
[ 1444.295000] UBI: wear-leveling threshold:    4096
[ 1444.300000] UBI: number of internal volumes: 1
[ 1444.305000] UBI: number of user volumes:     0
[ 1444.305000] UBI: available PEBs:             1977
[ 1444.310000] UBI: total number of reserved PEBs: 24
[ 1444.315000] UBI: number of PEBs reserved for bad PEB handling: 20
[ 1444.320000] UBI: max/mean erase counter: 2/2
[ 1444.345000] UBI: background thread "ubi_bgt0d" started, PID 1727
UBI device number 0, total 2001 LEBs (258177024 bytes, 246.2 MiB), available 1977 LEBs (255080448 bytes, 243.3 MiB), LEB size 129024 bytes (126.0 KiB)

On vient d’attacher un périphérique ‘ubi0′ à notre système, il faut maintenant créer un volume sur celui-ci (le paramètre ‘-m’ permet d’utiliser la totalité de l’espace disponible dans ‘ubi0′ et -N spécifie le nom : ici ‘rootfs’ qui sera utilisé plus tard):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

root@TQ6410-Iris:~# ubimkvol -h
ubimkvol version 1.0 - a tool to create UBI volumes.
 
Usage: ubimkvol <UBI device node file name> [-h] [-a <alignment>] [-n <volume ID>] [-N &lt;name&gt;]
                        [-s &lt;bytes&gt;] [-S &lt;LEBs&gt;] [-t &lt;static|dynamic&gt;] [-V] [-m]
                        [--alignment=&lt;alignment&gt;][--vol_id=&lt;volume ID&gt;] [--name=&lt;name&gt;]
                        [--size=&lt;bytes&gt;] [--lebs=&lt;LEBs&gt;] [--type=&lt;static|dynamic&gt;] [--help]
                        [--version] [--maxavsize]
 
Example: ubimkvol /dev/ubi0 -s 20MiB -N config_data - create a 20 Megabytes volume
         named "config_data" on UBI device /dev/ubi0.
 
-a, --alignment=&lt;alignment&gt;   volume alignment (default is 1)
-n, --vol_id=&lt;volume ID&gt;      UBI volume ID, if not specified, the volume ID
                              will be assigned automatically
-N, --name=&lt;name&gt;             volume name
-s, --size=&lt;bytes&gt;            volume size volume size in bytes, kilobytes (KiB)
                              or megabytes (MiB)
-S, --lebs=&lt;LEBs count&gt;       alternative way to give volume size in logical
                              eraseblocks
-m, --maxavsize               set volume size to maximum available size
-t, --type=&lt;static|dynamic&gt;   volume type (dynamic, static), default is dynamic
-h, -?, --help                print help message
-V, --version                 print program version
 
The following is a compatibility option which is deprecated, do not use it
-d, --devn=&lt;devn&gt;             UBI device number - may be used instead of the UBI
                              device node name in which case the utility assumes
                              that the device node is "/dev/ubi&lt;devn&gt;"
root@TQ6410-Iris:~# ubimkvol /dev/ubi0 -N rootfs -m
Set volume size to 255080448
Volume ID 0, size 1977 LEBs (255080448 bytes, 243.3 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs", alignment 1

On regarde si ‘udev’ a créé les périphériques concernés dans /dev:

1
2

root@TQ6410-Iris:~# ls /dev/ubi*
/dev/ubi0  /dev/ubi0_0  /dev/ubi_ctrl

On est prêt à monter ce périphérique dans notre système et prendre quelques renseignements dessus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

root@TQ6410-Iris:~# mount -t ubifs ubi0:rootfs /mnt
[ 2589.845000] UBIFS: default file-system created
[ 2589.950000] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[ 2589.950000] UBIFS: file system size:   253532160 bytes (247590 KiB, 241 MiB, 1965 LEBs)
[ 2589.955000] UBIFS: journal size:       12644352 bytes (12348 KiB, 12 MiB, 98 LEBs)
[ 2589.960000] UBIFS: media format:       4 (latest is 4)
[ 2589.965000] UBIFS: default compressor: LZO
[ 2589.970000] UBIFS: reserved for root:  5182151 bytes (5060 KiB)
root@TQ6410-Iris:~# mount
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rootfs on / type rootfs (rw)
ubi0:rootfs on /mnt type ubifs (rw)
root@TQ6410-Iris:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
ubi0:rootfs           227M     0  223M   0% /mnt

On continue donc comme les autres systèmes de fichiers. On désarchive le rootfs dans /mnt et on regarde la place occupé.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

root@TQ6410-Iris:~# cd /mnt
root@TQ6410-Iris:/mnt# tar jxf /debian-squeeze-grip-OD.tar.bz2 .
root@TQ6410-Iris:/mnt# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                1.9G  477M  1.4G  26% /
ubi0:rootfs           227M   47M  176M  21% /mnt
root@TQ6410-Iris:/mnt# du -h --max-depth=1 /mnt
4.0M    /mnt/bin
4.0K    /mnt/dev
896K    /mnt/etc
8.0M    /mnt/lib
0       /mnt/mnt
0       /mnt/opt
0       /mnt/srv
0       /mnt/tmp
0       /mnt/sys
11M     /mnt/var
48M     /mnt/usr
0       /mnt/boot
0       /mnt/home
0       /mnt/proc
3.5M    /mnt/sbin
24K     /mnt/root
0       /mnt/media
0       /mnt/lost+found
0       /mnt/selinux
75M     /mnt

La compression utilisée ici est LZO. On peut la changer en le spécifiant sur la commande mount. On a bien affaire à un système de fichiers compressés 47Mo utilisé sur 227Mo disponible et 75Mo de fichiers réels. Notez au passage que c’est un peu moins bien que JFFS2. On va pouvoir tester le démarrage sur ce système de fichier. Il faut encore une fois modifié la ligne d’arguments passé au noyau par U-Boot:

1

console=ttySAC0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs init=/sbin/init quiet noswap lpj=884736

A nouveau on regarde ce que ça donne au point de vue temps de boot avec GrabSerial. Fouillons les messages du noyau pour tenter de repérer le temps de montage :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

[21474536.690000] UBI: attaching mtd2 to ubi0
[21474536.690000] UBI: physical eraseblock size:   131072 bytes (128 KiB)
[21474536.690000] UBI: logical eraseblock size:    129024 bytes
[21474536.690000] UBI: smallest flash I/O unit:    2048
[21474536.690000] UBI: sub-page size:              512
[21474536.690000] UBI: VID header offset:          512 (aligned 512)
[21474536.690000] UBI: data offset:                2048
[21474537.760000] UBI: attached mtd2 to ubi0
[21474537.760000] UBI: MTD device name:            "File System"
[21474537.760000] UBI: MTD device size:            250 MiB
[21474537.760000] UBI: number of good PEBs:        2001
[21474537.760000] UBI: number of bad PEBs:         3
[21474537.760000] UBI: max. allowed volumes:       128
[21474537.760000] UBI: wear-leveling threshold:    4096
[21474537.760000] UBI: number of internal volumes: 1
[21474537.760000] UBI: number of user volumes:     1
[21474537.760000] UBI: available PEBs:             0
[21474537.760000] UBI: total number of reserved PEBs: 2001
[21474537.760000] UBI: number of PEBs reserved for bad PEB handling: 20
[21474537.760000] UBI: max/mean erase counter: 3/2
...
[21474537.915000] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[21474537.915000] UBIFS: file system size:   253532160 bytes (247590 KiB, 241 Mi
B, 1965 LEBs)
[21474537.915000] UBIFS: journal size:       12644352 bytes (12348 KiB, 12 MiB,
98 LEBs)
[21474537.915000] UBIFS: media format:       4 (latest is 4)
[21474537.915000] UBIFS: default compressor: LZO
[21474537.915000] UBIFS: reserved for root:  5182151 bytes (5060 KiB)
[21474537.920000] VFS: Mounted root (ubifs filesystem).

On remarque qu’il y a deux parties distinctes dans les message du noyau: la partie association du MTD avec le système UBI qui prend 37.76-36.69=1,07s et le montage du système de fichiers UBIFS qui prend 0,005s. Pour comparer aux autres systèmes de fichiers, le temps de démarrage global est de 16,8s. C’est donc un peu plus lent que YAFFS2 et du même niveau que JFFS2. Cependant UBI et UBIFS semble être promis à un bel avenir comme on peut le voir sur ces tests.

Conclusion: c’est un bon compromis entre yaffs2 et jffs2. De plus il semble que ce système se développe dans les noyaux récents. De plus il a de trés bonne performance en lecture/écriture par rapport à YAFFS2. La mise en oeuvre est juste un peu plus délicate….

Conclusion sur les systèmes de fichiers

Pendant la phase de développement, je dirais que le plus simple est de travailler avec une carte SD : c’est pas cher, vous avez des capacités énormes mais “ca fait pas embarqué” comme dirais Denis Bodor dans ces articles. Au niveau du choix du système de fichiers sur la flash NAND il faudra tester à l’utilisation YAFFS2 et UBIFS. YAFFS2 a pour lui l’ancienneté et une trés bonne stabilité, UBI quand à lui est plus récent et évolue encore assez fortement.

Lectures enrichissantes voire obligatoires !!

Non vous n’êtes pas seul, des dizaines de personnes sur Internet ont déjà rédigé des tutoriaux sur la mise en place d’un noyau personnalisé ou la réalisation d’un ‘rootfs’. Pour ma part je livre les liens qui m’ont réellement permis d’avancer sur cette carte :

• Le forum du vendeur de la carte et en particulier les sections S3C6410, S3C2440 et Linux,
• Les forums du site FriendlyARM,
• Le blog de Bill (Bill’s Blog) : très bon ‘HowTo’ et un excellent forum. Bill se définit lui même comme un ‘installeur’ et pas comme un ‘programmeur’,
• Le site de la distribution Emdebian : Debian facilite énormément la création d’un ‘rootfs’ pour l’embarqué !,
• Un bon tutoriel sur la mise en place d’emdebian sur une mini6410 ainsi que le site voisin pour une mini2440,
• Le site BoundaryDevice qui m’a permis de régler une bonne fois pour toute mes problèmes de calibration du touchscreen sous Xorg !
• Et enfin je réserve la place d’honneur pour l’article en FRANÇAIS qui m’a donné envie de travailler avec cette carte : l’article de Denis Bodor dans le magazine OpenSilicium N°1 : Plateforme FriendlyARM Mini2440

Les étapes de la personnalisation de la carte TQ6410

1. Installation d’une chaine de cross-compilation sur une station de développement fonctionnant de préférence sous GNU/Linux Debian Squeeze,
2. Compilation et installation d’un ‘bootloader’ : dans notre cas U-Boot,
3. Compilation et installation d’un noyau linux personnalisé,
4. Génération, installation et configuration d’un système de fichiers racine (rootfs en anglais). Dans notre cas, ce rootfs sera basé sur emdebian squeeze Grip,
5. Développement d’applications sur la plateforme…

1. Installation d’une chaine de cross-compilation

Avant de poursuivre, on considère que votre machine de développement est fonctionnelle et que vous avez un minimum de connaissance d’un système GNU/Linux. La distribution choisie est, comme indiqué ci-dessus, une debian 6.0 (Squeeze). La carte est équipée d’un SoC Samsung S3C6410. C’est donc un cœur ARM11 qui équipe cette puce. La chaine de compilation sera donc une chaine arm-linux-gnueabi. Pour installer cette chaine de cross compilation, il faut tout d’abord importer les clés des archives emdebian :

1

root@casimir:~# aptitude install emdebian-archive-keyring

il faut ensuite rajouter le dépôt suivant et mettre à jour la base des paquets:

1
2

root@casimir:~# echo "deb http://www.emdebian.org/debian/ squeeze main" >> /etc/apt/sources.list
root@casimir:~# aptitude update

on installe alors les paquets suivants:

1
2
3
4
5
6
7
8
9
10
11
12

root@casimir:~# aptitude install linux-libc-dev-armel-cross libc6-armel-cross libc6-dev-armel-cross binutils-arm-linux-gnueabi gcc-4.4-arm-linux-gnueabi g++-4.4-arm-linux-gnueabi
Les NOUVEAUX paquets suivants vont être installés :
  binutils{a} binutils-arm-linux-gnueabi cpp-4.4-arm-linux-gnueabi{a}
  g++-4.4-arm-linux-gnueabi gcc-4.4-arm-linux-gnueabi
  gcc-4.4-arm-linux-gnueabi-base{a} gcc-4.4-base-armel-cross{a}
  libc-bin-armel-cross{a} libc-dev-bin-armel-cross{a} libc6-armel-cross
  libc6-dev-armel-cross libgcc1-armel-cross{a} libgomp1-armel-cross{a}
  libstdc++6-4.4-dev-armel-cross{a} libstdc++6-armel-cross{a}
  linux-libc-dev-armel-cross
0 paquets mis à jour, 16 nouvellement installés, 0 à enlever et 2 non mis à jour.
Il est nécessaire de télécharger 23,8 Mo d'archives. Après dépaquetage, 56,5 Mo seront utilisés.
Voulez-vous continuer ? [Y/n/?]  y

Après l’installation des différents paquets vous disposez alors d’une chaine de compilation croisée pour processeur ARM. Une petite vérification pour la route:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

root@casimir:~# arm-linux-gnueabi-
arm-linux-gnueabi-addr2line  arm-linux-gnueabi-gcov-4.4
arm-linux-gnueabi-ar         arm-linux-gnueabi-gprof
arm-linux-gnueabi-as         arm-linux-gnueabi-ld
arm-linux-gnueabi-c++filt    arm-linux-gnueabi-nm
arm-linux-gnueabi-cpp        arm-linux-gnueabi-objcopy
arm-linux-gnueabi-cpp-4.4    arm-linux-gnueabi-objdump
arm-linux-gnueabi-g++        arm-linux-gnueabi-ranlib
arm-linux-gnueabi-g++-4.4    arm-linux-gnueabi-readelf
arm-linux-gnueabi-gcc        arm-linux-gnueabi-size
arm-linux-gnueabi-gcc-4.4    arm-linux-gnueabi-strings
arm-linux-gnueabi-gcov       arm-linux-gnueabi-strip
root@casimir:~# arm-linux-gnueabi-gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.4.5 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-sjlj-exceptions --enable-checking=release --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --build=i486-linux-gnu --host=i486-linux-gnu --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)

Cela semble correct ! La première étape est complétée… Nous allons pouvoir compiler pour notre carte TQ6410.

2. Compilation du chargeur U-Boot et installation sur la carte TQ6410

Pour mémoire la carte dispose de deux types de mémoire : Flash NOR et Flash NAND. Ces deux mémoires contiennent à l’achat le chargeur U-Boot. En particulier, si pour une raison ou une autre, le chargeur de la flash NAND est défectueux, vous pouvez le réinstaller en démarrant sur la flash NOR. Donc normalement vous ne pouvez pas bloquer la carte (la ‘bricker’). Dans tous les cas, on peut réinstaller le chargeur U-Boot avec un programmateur type OpenOCD par le port JTAG mais je ne dispose pas d’une sonde JTAG. Le boot de la carte sur la flash NOR ou NAND se fait par l’intermédiaire des mini-interrupteurs présents dans le coin inférieur gauche de la carte. On dispose de trois choix pour le boot:

La version de U-Boot livrée sur le DVD fourni avec la carte est nommé ‘u-boot-tq6410-20100829.tar.gz’ ce qui me parait un peu ancien. Je décide donc de me rendre sur le site de U-Boot et de télécharger une version plus récente. La gestion des sources se fait avec Git et de plus il y a un dépot pour les SoC de Samsung. On va donc rapatrier tout ça et en profiter pour jeter un coup d’oeil au ‘README’:

1
2
3
4
5
6
7
8
9
10
11
12

root@casimir:~# aptitude install git
root@casimir:~# mkdir u-boot-TQ6410
root@casimir:~# cd u-boot-TQ6410/
root@casimir:~/u-boot-TQ6410# git clone git://git.denx.de/u-boot-samsung.git
Cloning into u-boot-samsung...
remote: Counting objects: 146388, done.
remote: Compressing objects: 100% (36699/36699), done.
remote: Total 146388 (delta 118824), reused 135758 (delta 108242)
Receiving objects: 100% (146388/146388), 38.18 MiB | 30 KiB/s, done.
Resolving deltas: 100% (118824/118824), done.
root@casimir:~/u-boot-TQ6410# cd u-boot-samsung/
root@casimir:~/u-boot-TQ6410/u-boot-samsung# more README

Dans ce README, vous aurez la liste de tous les paramètres de configuration ainsi que la méthode de compilation (entre autres). En fouillant dans la liste des cartes, je ne trouve qu’une carte SMDK6400, je vais donc compiler pour cette cible…

Je n’ai pas d’installer ni la commande ‘make’, ni les compilateurs gcc et g++, donc on installe le tout:

1

root@casimir:~/u-boot-TQ6410/u-boot-samsung# aptitude install make gcc g++

On configure la génération de code pour une carte smdk6400 et on lance la cross-compilation:

1
2

root@casimir:~/u-boot-TQ6410/u-boot-samsung# make smdk6400_config
root@casimir:~/u-boot-TQ6410/u-boot-samsung# make CROSS_COMPILE=arm-linux-gnueabi-

Au bout de quelques minutes, on obtient un fichier u-boot.bin. Je démarre ensuite la carte sur la flash NAND et je choisis l’option ‘Download u-boot.bin’ (lettre ‘v’) dans le menu de U-Boot. Par l’intermediaire du logiciel DNW sous Windows je télécharge le u-boot.bin fraichement compilé dans la NAND de la carte. Je redémarre la carte et… cela ne fonctionne pas !!

Ce n’est pas très étonnent en soi car on a compilé pour un s3c6400 et pas s3c6410. Pour revenir à une situation normale, il faut démarrer sur la flash NOR, choisir la lettre ‘v’ dans le menu de U-Boot puis transférer le fichier u-boot.bin du DVD fourni avec la carte grace au logiciel DNW. Ouf…Situation redevenu normale !

Je ne peux pas compiler directement un u-boot à partir du site, donc je me rabat sur l’archive fournie sur le DVD du nom de ‘u-boot-tq6410-20100829.tar.gz’ dans le répertoire ‘linux’. Je copie cette archive dans le répertoire u-boot-TQ6410 sur ma machine de travail puis je désarchive l’ensemble et enfin je rentre dans le répertoire ‘u-boot-tq6410:

1
2
3

root@casimir:~/u-boot-TQ6410# cp /multimedia/Electronique/TQ6410/DVD/linux/u-boot-tq6410-20100829.tar.gz .
root@casimir:~/u-boot-TQ6410# tar xzvf u-boot-tq6410-20100829.tar.gz
root@casimir:~/u-boot-TQ6410# cd u-boot-tq6410

Avant de me lancer dans la compilation de u-boot, je parcours les répertoires de cette archive…Ce qui est rassurant c’est de trouver un changelog de chez Samsung, dans le Makefile on trouve des entrées pour smdk2440, smdk6410, tq6410,etc…On nettoie l’ensemble puis on lance la compilation:

1
2
3

root@casimir:~/u-boot-TQ6410# make CROSS_COMPILE=arm-linux-gnueabi- distclean
root@casimir:~/u-boot-TQ6410# make CROSS_COMPILE=arm-linux-gnueabi- tq6410_config
root@casimir:~/u-boot-TQ6410# make CROSS_COMPILE=arm-linux-gnueabi-

Au bout de quelques minutes, vous obtenez un nouveau fichier u-boot.bin qu’il faut transférer sur la carte avec l’utilitaire DNW. Au lancement de la carte, le menu est identique seul la date de compilation à changer (dans mon cas Aug 1 2011). Le menu de U-Boot est personnalisé, j’aimerai modifier ce menu, je cherche donc dans les codes sources. En fait il faut éditer le fichier ‘common/main.c’ et modifier la fonction ‘FriendlyARMMenu’. Je fais juste une modification cosmétique pour vérifier que l’on peut modifier ce menu. Je recompile le tout et j’obtient:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

##### U-Boot 1.1.6 B01 for 6410, by esky-sh #####
##### Modif. par O. DARTOIS pour BTS IRIS   #####
 
[f] Format the nand flash
[v] Download u-boot.bin
[k] Download Linux/Android kernel
[y] Download root yaffs2 image
[a] Download Absolute User Application
[n] Download Nboot.nb0 for WinCE
[w] Download WinCE NK.nb0
[s] Set the boot parameter of Linux
[b] Boot Linux
[q] Quit to shell
NAND Flash size: 256 MiB
Enter your Selection:

Cela semble correct, si vous devez modifier de manière plus conséquente le menu, vous pourrez donc le faire…

Conclusion: même si l’on a réussi à compiler et à installer un nouveau U-Boot sur la carte, je ne suis qu’à moitié satisfait. J’aurais voulu pouvoir compiler les nouvelles versions de U-Boot pour cette carte. De plus malgré ma demande sur le site de samsung pour obtenir un accès au code opensource de leurs SoCs, je n’ai pas eu de réponse de leur part. Donc je ne sais pas si Samsung maintient toujours un ‘U-Boot personnalisé’ pour leurs cartes SMDK. Je passe donc maintenant à la troisième étape : la compilation d’un noyau linux personnalisé.

3. Compilation d’un noyau linux personnalisé pour la carte TQ6410

Cette carte sera utilisée dans un milieu industriel, nous ne nous servirons donc pas de toutes ces capacités ‘multimédia’ et de supports externes (USB, carte SD,etc…). Par contre il faut impérativement garder les GPIOs, l’ethernet  et les ports séries.

Cette fois-ci je prends le noyau linux livré sur le DVD. Le fichier s’appelle “linux-2.6.28.6-20110319.tar.gz” dans le répertoire linux. Je créé un répertoire ‘Noyau_Linux’ puis je désarchive le noyau:

1
2
3
4
5

root@casimir:~# mkdir Noyau_Linux
root@casimir:~# cd Noyau_Linux
root@casimir:~/Noyau_Linux# cp /multimedia/Electronique/TQ6410/DVD/linux/linux-2.6.28.6-20110319.tar.gz .
root@casimir:~/Noyau_Linux# tar xzvf linux-2.6.28.6-20110319.tar.gz
root@casimir:~/Noyau_Linux# cd linux-2.6.28.6

Dans le répertoire vous trouverez les configurations du vendeur de la carte (config_tq6410_xx avec xx fonction de la taille de l’écran tactile). Nous disposons de l’écran 7 pouces donc la configuration à prendre sera config_tq6410_a70 et nous allons la prendre comme configuration par défaut. Pour configurer votre noyau, nous allons utiliser l’interface texte (menuconfig), il faut donc installer les paquets suivants:

1
2
3
4

root@casimir:~/Noyau_Linux/linux-2.6.28.6# aptitude install ncurses-bin
root@casimir:~/Noyau_Linux/linux-2.6.28.6# make mrproper
root@casimir:~/Noyau_Linux/linux-2.6.28.6# cp config_tq6410_a70 .config
root@casimir:~/Noyau_Linux/linux-2.6.28.6# make arch=arm menuconfig

Choix dans la configuration du noyau:

• Pas de “ramdisk” initial
• Désactivation du chargements des modules : noyau monolitique
• Dans “System type” prendre le SoC Samsung S3C64XX
• Dans “Floating Point Emulation” je prends l’option VFP car le S3C6410 dispose d’une telle unité de calcul
• Désactivation du convertisseur analogique numérique du SoC car erreur de compilation
• Désactivation complète du support SCSI
• Désactivation du “S3C Keybord” : les boutons poussoirs sur la carte
• Désactivation du support SPI et I2C
• Désactivation de la partie “Multimédia” : V4L
• Dans la gestion du framebuffer du S3C6410, je met le nombre de framebuffer à 1
• Pas de support pour les cartes sons, pas de support HID, pas de support de l’USB
• Support du système de fichier ext3, yaffs2, ubifs (pas de support ext4, dos, vfat)
• Pas de support de NFS car le système racine ne sera pas exporté par ce moyen, en conséquence je désactive aussi l’IP Kernel autoconfiguration’
• Diverses optimisations pour réduire la taille du noyau…(allocation mémoire par SLUB)

Cette configuration minimum est disponible au téléchargement en fin d’article sous le nom ‘config_TQ6410_OD_mini’.

U-Boot nécessite un noyau spécialement préparé pour lui, il faut donc installer la commande ‘mkimage’ puis lancez la compilation pour une image ‘uImage’:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

root@casimir:~/Noyau_Linux/linux-2.6.28.6# aptitude install uboot-mkimage
root@casimir:~/Noyau_Linux/linux-2.6.28.6# make CROSS_COMPILE=arm-linux-gnueabi-
ARCH=arm CFLAGS="-march=armv6" CXXFLAGS="-march=armv6" uImage
...
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready
  UIMAGE  arch/arm/boot/uImage
Image Name:   Linux-2.6.28.6-IRIS-Turgot-O.Dar
Created:      Wed Aug  3 11:43:54 2011
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1478116 Bytes = 1443.47 kB = 1.41 MB
Load Address: 0x50008000
Entry Point:  0x50008000
  Image arch/arm/boot/uImage is ready

Le noyau est disponible dans le répertoire arch/arm/boot/ sous le nom uImage. Il faut maintenant transférer ce noyau dans la flash NAND de la carte. Lancez minicom, arrêtez U-Boot puis choisissez l’option ‘Download Linux/Android Kernel’ (lettre ‘k’) puis transférer le noyau avec l’utilitaire DNW:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Enter your Selection:k
Downloading Linux/Android Kernel from USB...
Insert a OTG cable into the connector!
OTG cable Connected!
Download address 0xc0000000
Download Done!! Download Address: 0xc0000000, Download Filesize:0x168e24
Checksum is being calculated..
Checksum O.K.
Downloading Linux/Android Kernel successed
Writing Linux/Android Kernel into NAND...
Erasing at 0x560000 -- 100% complete.
 
Writing data at 0x1ff800 -- 100% complete.
Writing Linux/Android Kernel successed

Il faut maintenant démarrer ce nouveau noyau même sans système de fichiers racine pour le tester. Pour cela on va modifier la ligne de paramètres que l’on passe au noyau avec l’option ‘Set the boot parameter of Linux’ (lettre ’s’). Tapez alors la ligne suivante pour obtenir la sortie du noyau vers la voie série, préciser le futur ‘root-fs’ (ici sur une carte SD) et attendre que celui-ci soit prêt lors du montage de la carte (rootwait), l’exécutable à lancer aprés le noyau (ici /sbin/init).

1

console=ttySAC0,115200 root=/dev/mmcblk0p1 init=/sbin/init rootwait

Normalement tout doit bien se passer. La taille, après optimisation, de mon noyau est de 1,1Mo. Cette petite taille permet un chargement rapide depuis la flash, une décompression rapide et un boot du noyau jusqu’au passage à INIT en moins de 4s. Si j’ai le temps je ferais un article sur l’optimisation du boot. Ci-dessous les messages de boot du noyau:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146

Starting kernel ...
 
Uncompressing Linux............................................................................. done, booting the kernel.
Linux version 2.6.28.6-IRIS-Turgot-O.Dartois (root@casimir) (gcc version 4.4.5 (Debian 4.4.5-8) ) #10 PREEMPT Thu Aug 4 10:53:55 CEST 2011
CPU: ARMv6-compatible processor [410fb766] revision 6 (ARMv7), cr=00c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: SMDK6410
Memory policy: ECC disabled, Data cache writeback
CPU S3C6410 (id 0x36410101)
S3C24XX Clocks, (c) 2004 Simtec Electronics
S3C64XX: PLL settings, A=532000000, M=532000000, E=24000000
S3C64XX: HCLKx2=266000000, HCLK=133000000, PCLK=66500000
div1: 00000555
mout_apll: source is fout_apll (1), rate is 532000000
mout_epll: source is fout_epll (1), rate is 24000000
mout_mpll: source is mpll (1), rate is 532000000
mmc_bus: source is dout_mpll (1), rate is 44333333
mmc_bus: source is dout_mpll (1), rate is 44333333
mmc_bus: source is dout_mpll (1), rate is 44333333
usb-host-bus: source is mout_epll (0), rate is 24000000
uclk1: source is dout_mpll (1), rate is 66500000
spi-bus: source is mout_epll (0), rate is 24000000
spi-bus: source is mout_epll (0), rate is 24000000
audio-bus0: source is mout_epll (0), rate is 24000000
audio-bus1: source is mout_epll (0), rate is 24000000
audio-bus2: source is mout_epll (0), rate is 24000000
irda-bus: source is mout_epll (0), rate is 24000000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttySAC0,115200 root=/dev/mmcblk0p1 rootwait int=/sbin/init printk.time=1
[    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[21474536.480000] Console: colour dummy device 80x30
[21474536.480000] s3c24xx_serial_init_ports: initialising ports=4...
[21474536.480000] console [ttySAC0] enabled
[21474536.485000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[21474536.495000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[21474536.510000] Memory: 128MB = 128MB total
[21474536.510000] Memory: 127216KB available (2132K code, 286K data, 96K init)
[21474536.515000] SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[21474536.520000] Calibrating delay loop... 353.89 BogoMIPS (lpj=884736)
[21474536.635000] Mount-cache hash table entries: 512
[21474536.635000] CPU: Testing write buffer coherency: ok
[21474536.640000] net_namespace: 288 bytes
[21474536.645000] NET: Registered protocol family 16
[21474536.670000] S3C6410: Initialising architecture
[21474536.670000] S3C DMA-pl080 Controller Driver, (c) 2006-2007 Samsung Electronics
[21474536.675000] Total 32 DMA channels will be initialized.
[21474536.720000] NET: Registered protocol family 2
[21474536.765000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[21474536.765000] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[21474536.770000] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[21474536.775000] TCP: Hash tables configured (established 4096 bind 4096)
[21474536.780000] TCP reno registered
[21474536.800000] NET: Registered protocol family 1
[21474536.825000] yaffs Aug  4 2011 10:49:48 Installing.
[21474536.830000] msgmni has been set to 248
[21474536.830000] io scheduler noop registered (default)
[21474536.835000] S3C_LCD clock got enabled :: 133.000 Mhz
[21474536.850000] LCD TYPE :: LTE480WV will be initialized
[21474536.850000] Window[0] - FB1: map_video_memory: clear ff000000:000bb800
[21474536.855000]             FB1: map_video_memory: dma=57100000 cpu=ff000000 size=000bb800
[21474536.860000] Window[0] - FB2: map_video_memory: clear ff05dc00:0005dc00
[21474536.865000]             FB2: map_video_memory: dma=5715dc00 cpu=ff05dc00 size=0005dc00
[21474536.880000] Console: switching to colour frame buffer device 100x30
[21474536.890000] fb0: s3cfb frame buffer device
[21474536.895000] backlight	initialized
[21474536.900000] backlight: 60
[21474536.940000] leds	initialized
[21474536.940000] buttons	initialized
[21474536.940000] pwm	initialized
[21474536.940000] s3c6400-uart.0: s3c2410_serial0 at MMIO 0x7f005000 (irq = 16) is a S3C6400/10
[21474536.945000] s3c6400-uart.1: s3c2410_serial1 at MMIO 0x7f005400 (irq = 20) is a S3C6400/10
[21474536.950000] s3c6400-uart.2: s3c2410_serial2 at MMIO 0x7f005800 (irq = 24) is a S3C6400/10
[21474536.955000] s3c6400-uart.3: s3c2410_serial3 at MMIO 0x7f005c00 (irq = 28) is a S3C6400/10
[21474536.960000] dm9000 Ethernet Driver
[21474536.965000] dm9000: dm9000_probe, init GPIO/EINT.
[21474536.970000] dm9000: dm9000_probe2
[21474536.975000] dm9000: dm9000_probe3
[21474536.980000] eth0: dm9000 at f7b00300,f7b00304 IRQ 108 MAC: 08:90:90:90:90:90
[21474536.985000] S3C NAND Driver, (c) 2008 Samsung Electronics
[21474536.990000] S3C NAND Driver is using hardware ECC.
[21474536.995000] NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
[21474537.000000] Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":
[21474537.005000] 0x00000000-0x00080000 : "Bootloader"
[21474537.015000] 0x00080000-0x00580000 : "Kernel"
[21474537.020000] 0x00580000-0x10000000 : "File System"
[21474537.065000] mice: PS/2 mouse device common for all mice
[21474537.065000] S3C Touchscreen driver, (c) 2008 Samsung Electronics
[21474537.070000] S3C TouchScreen got loaded successfully : 12 bits
[21474537.080000] input: S3C TouchScreen as /class/input/input0
[21474537.125000] S3C24XX RTC, (c) 2004,2006 Simtec Electronics
[21474537.125000] s3c2410_rtc: tick irq 34, alarm irq 92
[21474537.130000] s3c2410-rtc s3c2410-rtc: rtc disabled, re-enabling
[21474537.135000] s3c2410-rtc s3c2410-rtc: rtc core: registered s3c as rtc0
[21474537.140000] S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics
[21474537.145000] s3c2410-wdt s3c2410-wdt: watchdog inactive, reset disabled, irq enabled
[21474537.150000] sdhci: Secure Digital Host Controller Interface driver
[21474537.155000] sdhci: Copyright(c) Pierre Ossman
[21474537.155000] s3c-sdhci s3c-sdhci.0: clock source 0: hsmmc (133000000 Hz)
[21474537.160000] s3c-sdhci s3c-sdhci.0: clock source 1: hsmmc (133000000 Hz)
[21474537.165000] s3c-sdhci s3c-sdhci.0: clock source 2: mmc_bus (44333333 Hz)
[21474537.170000] [SDHCI]to add external irq as a card detect signal......
[21474537.175000] [SDHCI]if (pdata->cfg_ext_cd)......
[21474537.180000] mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA
[21474537.185000] [SDHCI]request_irq......
[21474537.190000] sdhci: card inserted.
[21474537.205000] TCP cubic registered
[21474537.205000] NET: Registered protocol family 17
[21474537.205000] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
[21474537.225000] s3c2410-rtc s3c2410-rtc: setting system clock to 2011-08-04 09:50:52 UTC (1312451452)
[21474537.225000] Waiting for root device /dev/mmcblk0p1...
[21474537.250000] mmc0: new high speed SD card at address 0007
[21474537.250000] mmcblk0: mmc0:0007 SD02G 1.83 GiB
[21474537.255000]  mmcblk0: p1
[21474537.340000] EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
[21474537.340000] kjournald starting.  Commit interval 5 seconds
[21474537.475000] EXT3 FS on mmcblk0p1, internal journal
[21474537.475000] EXT3-fs: mounted filesystem with ordered data mode.
[21474537.480000] VFS: Mounted root (ext3 filesystem).
[21474537.485000] Freeing init memory: 96K
INIT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
Activating swap...done.
Cleaning up ifupdown....
Setting up networking....
Activating lvm and md swap...done.
Checking file systems...fsck from util-linux-ng 2.17.2
done.
Mounting local filesystems...done.
Activating swapfile swap...done.
Cleaning up temporary files....
Configuring network interfaces...[21474550.970000] eth0: link down
done.
Cleaning up temporary files....
Setting kernel variables ...done.
INIT: Entering runlevel: 2
Using makefile-style concurrent boot in runlevel 2.
Starting enhanced syslogd: rsyslogd.
Starting periodic command scheduler: cron.
Starting system message bus: dbus.
 
Debian GNU/Linux 6.0 TQ6410-Iris s3c2410_serial0
 
TQ6410-Iris login:

Remarque: vous pouvez voir que le boot noyau prend environ 1s aprés décompression ! Ici le ‘rootfs’ existe c’est pour cette raison que l’on arrive à un ‘login’. Toutes les optimisations de temps de boot ne sont pas exploitées ici…

Puisque l’on parle de système de fichiers racine, voyons comment le réaliser…

4. Création du système de fichiers racine (ou ‘rootfs’) basé sur Debian Squeeze  Grip

On part d’une distribution Debian pour la stabilité et le système de gestion des paquets. Dans un premier temps, on ne va pas faire de l’embarqué pur, on va faire en sorte d’avoir une plateforme de test assez souple. Par la suite on pourra optimiser le ‘rootfs’ en travaillant avec BusyBox. Tout commence sur la machine de développement, on va construire le système de fichiers racine avec l’utilitaire ‘Debootstrap’. En résumé on va :

• formater en ext3 une carte SD de 2Go
• créer sur cette carte un système de fichier racine avec debootstrap
• effectuer quelques modifications pour démarrer sur ce système
• démarrer sur cette carte SD depuis la carte TQ6410 et terminer l’installation
• faire les modifications finales sur le système

Les traces de ces étapes sont présentés ci-dessous (sdd est à remplacer avec le bon périphérique : affichez les messages du  noyau avec dmesg et lisez les dernières lignes après avoir inséré votre carte) :

1
2
3
4
5
6
7
8
9
10
11
12
13

root@casimir:~# fdisk /dev/sdd
...création d'une partition primaire de type linux non bootable de la taille de la carte SD
root@casimir:~# mkfs.ext3 -L rootfs -m 0 /dev/sdd1
root@casimir:~# tune2fs -c 200 -C 0 /dev/sdd1
root@casimir:~# tune2fs -l /dev/sdd1
root@casimir:~# mount /dev/sdd1 /mnt
root@casimir:~# aptitude install debootstrap
root@casimir:~# debootstrap --arch=armel --foreign squeeze /mnt http://www.emdebian.org/grip/
root@casimir:~# echo "deb http://www.emdebian.org/grip/ squeeze main" >> /mnt/etc/apt/sources.list
root@casimir:~# echo "proc /proc proc none 0 0" >> /mnt/etc/fstab
root@casimir:~# echo "TQ6410-Iris" > /mnt/etc/hostname
root@casimir:~# mkdir -p /mnt/usr/share/man/man1/
root@casimir:~# umount /mnt

Maintenant insérez la carte SD sur la TQ6410, démarrez puis arrêtez U-Boot. Changez les paramètres de chargement du noyau (lettre ’s’) pour démarrer sur la carte SD avec un shell minimum pour terminer l’installation:

1

ttySAC0,115200 root=/dev/mmcblk0p1 rootwait init=/bin/sh

On passe à la deuxième phase d’installation du système de fichiers racine, cette fois ci directement sur la carte:

1
2
3
4
5
6
7

# /debootstrap/debootstrap --second-stage
[... ...]
#echo s3c2410_serial0 >> /etc/securetty
#printf "T0:123:respawn:/sbin/getty 115200 s3c2410_serial0\n" >> /etc/inittab
#printf "auto eth0\niface eth0 inet dhcp\n" >> /etc/network/interfaces
#passwd
#reboot

Explications des commandes qui précèdent : suite de l’installation des paquetages (second stage install) soyez patient…puis on rajoute à securetty (terminaux sur lesquels on peut se connecter)  le port série par lequel on va se logger. Ici vous n’avez plus ttySAC0 car udev est passé par là et à donc changer les noms des ports séries (regardez les messages du noyau). On rajoute aussi dans /etc/inittab une ligne qui permet de lancer automatiquement une console sur le port série dans les niveaux d’exécution 1,2 et 3. On configure le réseau en mode automatique (DHCP) en rajoutant les lignes dans le fichier /etc/network/interfaces. On fixe le mot de passe root et enfin on redémarre.

Encore une fois il faudra modifier la ligne de commande que U-Boot passe au noyau en:

1

console=ttySAC0,115200 root=/dev/mmcblk0p1 init=/sbin/init rootwait

Vous allez observer les messages du noyau, puis le lancement de INIT qui va amorcer le système jusqu’à l’obtention d’un login. Identifiez-vous ‘root’ avec le mot de passe que vous avez saisi précédemment. Si pendant le démarrage noyau le démon udevd se plaint que le répertoire .udev/ existe déjà dans le répertoire /dev, il faudra redémarrer avec init=/bin/sh puis supprimer ce répertoire.

Vous avez donc maintenant une plateforme debian qui fonctionne sur un système embarqué. Ce système de base utilise près de 80Mo (ce qui est déjà lourd) mais vous avez toutes les fonctionnalités d’une debian classique. Le système est donc facilement administrable par la suite, l’ajout/suppression de paquets se fera très simplement avec aptitude.

Pour mémoire, cette carte doit être utilisé dans le cadre du développement d’une application graphique pour superviser un process industriel. Dans un premier temps, on facilite donc la tache des programmeurs en ayant une plateforme ressemblant à une station de travail avec de l’espace disque (on travaille avec une carte SD de 2G0). Une fois l’application développée et testée, on optimisera le système (utilisation de busybox, binaire statique, rootfs réduit au minimum sur flash NAND).

Pour terminer cette partie, une trace complète du boot de la carte réalisé avec GrabSerial pour faire des tests de temps de démarrage:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178

Opening serial port /dev/ttyS0
115200:8N1:xonxoff=0:rtcdtc=0
Printing timing information for each line
Matching pattern 'Starting kernel.*' to set base time
Use Control-C to stop...
[    0.000004]
[    0.288957]
[    0.289171] U-Boot 1.1.6 (Aug  5 2011 - 11:50:17) for TQ6410
[    0.293743]
[    0.293901]
[    0.294050] CPU:     S3C6410@532MHz
[    0.296300]          Fclk = 532MHz, Hclk = 133MHz, Pclk = 66MHz, Serial = CLKUART (SYNC Mode)
[    0.303853] Board:   TQ6410
[    0.305418] DRAM:    128 MB
[    0.306917] Flash:   0 kB
[    0.308178] NAND:    256 MB
[    0.403949] In:      serial
[    0.405456] Out:     serial
[    0.406855] Err:     serial
[    0.483983] MAC: 08:90:90:90:90:90
[    0.486081] Hit any key to stop autoboot:  3  2  1  0
[    3.471948]
[    3.472140] NAND read: device 0 offset 0x80000, size 0x140000
[    3.476632]
[    3.476805] Reading data from 0x80000 --   0% complete....
[    4.712153]  1310720 bytes read: OK
[    4.714419] ## Booting image at c0008000 ...
[    4.717525]    Image Name:   Linux-2.6.28.6-IRIS-Turgot-O.Dar
[    4.722157]    Image Type:   ARM Linux Kernel Image (uncompressed)
[    4.727189]    Data Size:    1246092 Bytes =  1.2 MB
[    4.730954]    Load Address: 50008000
[    4.733404]    Entry Point:  50008000
[    5.039941] OK
[    5.040271]
[    5.040459] Starting kernel ...
[    0.001796]
[    0.007486] Uncompressing Linux................................................................................. done, booting the kernel.
[    0.567520] [    0.000000] Linux version 2.6.28.6-IRIS-Turgot-O.Dartois (root@casimir) (gcc version 4.4.5 (Debian 4.4.5-8) ) #23 PREEMPT Sun Aug 7 13:22:45 CEST 2011
[    0.581501] [    0.000000] CPU: ARMv6-compatible processor [410fb766] revision 6 (ARMv7), cr=00c5387f
[    0.589758] [    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.597419] [    0.000000] Machine: SMDK6410
[    0.600475] [    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.606403] [    0.000000] CPU S3C6410 (id 0x36410101)
[    0.614901] [    0.000000] S3C24XX Clocks, (c) 2004 Simtec Electronics
[    0.616787] [    0.000000] S3C64XX: PLL settings, A=532000000, M=532000000, E=24000000
[    0.621468] [    0.000000] S3C64XX: HCLKx2=266000000, HCLK=133000000, PCLK=66500000
[    0.627644] [    0.000000] div1: 00000555
[    0.628648] [    0.000000] mout_apll: source is fout_apll (1), rate is 532000000
[    0.635804] [    0.000000] mout_epll: source is fout_epll (1), rate is 24000000
[    0.640155] [    0.000000] mout_mpll: source is mpll (1), rate is 532000000
[    0.647749] [    0.000000] mmc_bus: source is dout_mpll (1), rate is 44333333
[    0.652045] [    0.000000] mmc_bus: source is dout_mpll (1), rate is 44333333
[    0.657073] [    0.000000] mmc_bus: source is dout_mpll (1), rate is 44333333
[    0.664213] [    0.000000] usb-host-bus: source is mout_epll (0), rate is 24000000
[    0.671772] [    0.000000] uclk1: source is dout_mpll (1), rate is 66500000
[    0.676240] [    0.000000] spi-bus: source is mout_epll (0), rate is 24000000
[    0.683605] [    0.000000] spi-bus: source is mout_epll (0), rate is 24000000
[    0.688184] [    0.000000] audio-bus0: source is mout_epll (0), rate is 24000000
[    0.695644] [    0.000000] audio-bus1: source is mout_epll (0), rate is 24000000
[    0.700284] [    0.000000] audio-bus2: source is mout_epll (0), rate is 24000000
[    0.707533] [    0.000000] irda-bus: source is mout_epll (0), rate is 24000000
[    0.712576] [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
[    0.720433] [    0.000000] Kernel command line: console=ttySAC0,115200 root=/dev/mmcblk0p1 rootwait init=/sbin/init
[    0.731529] [    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[    0.745040] [21474536.480000] Console: colour dummy device 80x30
[    0.746652] [21474536.480000] s3c24xx_serial_init_ports: initialising ports=4...
[    0.752795] [21474536.480000] console [ttySAC0] enabled
[    0.754150] [21474536.485000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.760837] [21474536.490000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.771485] [21474536.505000] Memory: 128MB = 128MB total
[    0.775965] [21474536.505000] Memory: 127088KB available (2276K code, 286K data, 96K init)
[    0.780887] [21474536.510000] SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.791570] [21474536.515000] Calibrating delay loop... 353.89 BogoMIPS (lpj=884736)
[    0.896457] [21474536.625000] Mount-cache hash table entries: 512
[    0.900846] [21474536.625000] CPU: Testing write buffer coherency: ok
[    0.908049] [21474536.630000] net_namespace: 288 bytes
[    0.911823] [21474536.635000] NET: Registered protocol family 16
[    0.916045] [21474536.645000] S3C6410: Initialising architecture
[    0.920419] [21474536.645000] S3C DMA-pl080 Controller Driver, (c) 2006-2007 Samsung Electronics
[    0.928430] [21474536.650000] Total 32 DMA channels will be initialized.
[    0.947479] [21474536.675000] NET: Registered protocol family 2
[    0.991496] [21474536.720000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.996502] [21474536.720000] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    1.004716] [21474536.725000] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[    1.013681] [21474536.730000] TCP: Hash tables configured (established 4096 bind 4096)
[    1.021195] [21474536.735000] TCP reno registered
[    1.031494] [21474536.755000] NET: Registered protocol family 1
[    1.043492] [21474536.765000] JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
[    1.049080] [21474536.770000] yaffs Aug  7 2011 00:09:52 Installing.
[    1.057092] [21474536.775000] msgmni has been set to 248
[    1.058617] [21474536.775000] io scheduler noop registered (default)
[    1.063791] [21474536.780000] S3C_LCD clock got enabled :: 133.000 Mhz
[    1.068993] [21474536.795000] LCD TYPE :: LTE480WV will be initialized
[    1.075952] [21474536.795000] Window[0] - FB1: map_video_memory: clear ff000000:000bb800
[    1.080818] [21474536.800000]             FB1: map_video_memory: dma=57100000 cpu=ff000000 size=000bb800
[    1.091572] [21474536.805000] Window[0] - FB2: map_video_memory: clear ff05dc00:0005dc00
[    1.099483] [21474536.810000]             FB2: map_video_memory: dma=5715dc00 cpu=ff05dc00 size=0005dc00
[    1.123509] [21474536.825000] Console: switching to colour frame buffer device 100x30
[    1.131343] [21474536.835000] fb0: s3cfb frame buffer device
[    1.137452] [21474536.840000] backlight	initialized
[    1.143489] [21474536.845000] backlight: 60
[    1.144485] [21474536.860000] leds	initialized
[    1.148332] [21474536.860000] pwm	initialized
[    1.151957] [21474536.860000] s3c6400-uart.0: s3c2410_serial0 at MMIO 0x7f005000 (irq = 16) is a S3C6400/10
[    1.160224] [21474536.870000] s3c6400-uart.1: s3c2410_serial1 at MMIO 0x7f005400 (irq = 20) is a S3C6400/10
[    1.168514] [21474536.875000] s3c6400-uart.2: s3c2410_serial2 at MMIO 0x7f005800 (irq = 24) is a S3C6400/10
[    1.176715] [21474536.880000] s3c6400-uart.3: s3c2410_serial3 at MMIO 0x7f005c00 (irq = 28) is a S3C6400/10
[    1.186421] [21474536.885000] dm9000 Ethernet Driver
[    1.190548] [21474536.885000] dm9000: dm9000_probe, init GPIO/EINT.
[    1.197018] [21474536.890000] dm9000: dm9000_probe2
[    1.201072] [21474536.895000] dm9000: dm9000_probe3
[    1.202422] [21474536.900000] eth0: dm9000 at f7b00300,f7b00304 IRQ 108 MAC: 08:90:90:90:90:90
[    1.208523] [21474536.905000] S3C NAND Driver, (c) 2008 Samsung Electronics
[    1.215927] [21474536.915000] S3C NAND Driver is using hardware ECC.
[    1.220201] [21474536.915000] NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
[    1.230312] [21474536.920000] Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":
[    1.236422] [21474536.925000] 0x00000000-0x00080000 : "Bootloader"
[    1.241708] [21474536.930000] 0x00080000-0x00580000 : "Kernel"
[    1.247327] [21474536.935000] 0x00580000-0x10000000 : "File System"
[    1.287488] [21474536.980000] S3C Touchscreen driver, (c) 2008 Samsung Electronics
[    1.293536] [21474536.980000] S3C TouchScreen got loaded successfully : 12 bits
[    1.299182] [21474536.985000] input: S3C TouchScreen as /devices/virtual/input/input0
[    1.311489] [21474537.005000] S3C24XX RTC, (c) 2004,2006 Simtec Electronics
[    1.318452] [21474537.005000] s3c2410_rtc: tick irq 34, alarm irq 92
[    1.324809] [21474537.010000] s3c2410-rtc s3c2410-rtc: rtc disabled, re-enabling
[    1.332221] [21474537.015000] s3c2410-rtc s3c2410-rtc: rtc core: registered s3c as rtc0
[    1.340306] [21474537.020000] S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics
[    1.347792] [21474537.030000] s3c2410-wdt s3c2410-wdt: watchdog inactive, reset disabled, irq enabled
[    1.357097] [21474537.035000] sdhci: Secure Digital Host Controller Interface driver
[    1.364903] [21474537.040000] sdhci: Copyright(c) Pierre Ossman
[    1.370816] [21474537.045000] s3c-sdhci s3c-sdhci.0: clock source 0: hsmmc (133000000 Hz)
[    1.379047] [21474537.050000] s3c-sdhci s3c-sdhci.0: clock source 1: hsmmc (133000000 Hz)
[    1.387309] [21474537.055000] s3c-sdhci s3c-sdhci.0: clock source 2: mmc_bus (44333333 Hz)
[    1.395645] [21474537.060000] [SDHCI]to add external irq as a card detect signal......
[    1.403593] [21474537.065000] [SDHCI]if (pdata->cfg_ext_cd)......
[    1.409657] [21474537.070000] mmc0: SDHCI controller on samsung-hsmmc [s3c-sdhci.0] using ADMA
[    1.418297] [21474537.075000] [SDHCI]request_irq......
[    1.423347] [21474537.080000] sdhci: card inserted.
[    1.428779] [21474537.085000] TCP cubic registered
[    1.434598] [21474537.090000] NET: Registered protocol family 17
[    1.436263] [21474537.095000] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
[    1.441529] [21474537.105000] s3c2410-rtc s3c2410-rtc: setting system clock to 2011-08-07 20:03:34 UTC (1312747414)
[    1.446252] [21474537.115000] Waiting for root device /dev/mmcblk0p1...
[    1.839493] [21474537.520000] mmc0: new high speed SD card at address 0002
[    1.844010] [21474537.520000] mmcblk0: mmc0:0002 00000 1.86 GiB
[    1.847723] [21474537.525000]  mmcblk0: p1
[    1.859526] [21474537.545000] kjournald starting.  Commit interval 5 seconds
[    1.867483] [21474537.550000] EXT3 FS on mmcblk0p1, internal journal
[    1.872305] [21474537.550000] EXT3-fs: mounted filesystem with ordered data mode.
[    1.879762] [21474537.555000] VFS: Mounted root (ext3 filesystem).
[    1.885848] [21474537.560000] Freeing init memory: 96K
[    2.135521] INIT: version 2.88 booting
[    2.335501] Using makefile-style concurrent boot in runlevel S.
[    2.951538] Starting the hotplug events dispatcher: udevd.
[    3.439497] Synthesizing the initial hotplug events...done.
[    3.843493] Waiting for /dev to be fully populated...done.
[    5.083503] Activating swap...done.
[    7.415484] Cleaning up ifupdown....
[    7.523493] Setting up networking....
[    8.247491] Activating lvm and md swap...done.
[    8.287498] Checking file systems...fsck from util-linux-ng 2.17.2
[    8.403493] done.
[    8.455494] Mounting local filesystems...done.
[    8.487493] Activating swapfile swap...done.
[    8.563490] Cleaning up temporary files....
[    8.935547] Configuring network interfaces...[21474544.705000] eth0: link down
[    9.119495] done.
[    9.211492] Cleaning up temporary files....
[    9.531489] Setting kernel variables ...done.
[    9.807515] INIT: Entering runlevel: 2
[    9.875529] Using makefile-style concurrent boot in runlevel 2.
[   10.495507] Starting enhanced syslogd: rsyslogd[21474546.705000] eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
[   11.647491] .
[   11.715496] Starting periodic command scheduler: cron.
[   13.063506]
[   13.067494] Debian GNU/Linux 6.0 TQ6410-Iris s3c2410_serial0
[   13.072671]
[   13.079498] TQ6410-Iris login:

On remarquera que le compteur de temps est remis à 0 lorsque la chaine “Starting Kernel” apparait. Le boot de noyau (décompression comprise) jusqu’au passage à INIT prend 2,1s. Le login apparait lui après 13s. Dans ce cas la configuration IP était fixé donc pas de requête DHCP.

5. Développement d’applications graphiques sur plateforme TQ6410

Comme je ne sais pas encore avec “quoi” on va programmer pour faire une application graphique, je reste une fois de plus générique : on va compléter l’installation précédente par l’installation de X.org et de l’écran tactile. Peut-être X ne sera pas utilisé et on travaillera directement avec le framebuffer sous Qt Embedded…

Il existe sous GNU/Linux deux manières de gérer les écrans tactiles evtouch et tslib. Comme je n’ai jamais pu faire fonctionner correctement evtouch, nous allons installer tslib. Il faut juste installer un paquetage, exporter une variable qui indique le périphérique qui pointe vers l’écran tactile (ici /dev/input/event0 car les boutons poussoirs de la carte sont désactivés) et enfin on lance l’utilitaire de calibration puis de tests:

1
2
3
4

root@TQ6410-Iris:~# aptitude install libts-bin
root@TQ6410-Iris:~# export TSLIB_TSDEVICE=/dev/input/event0
root@TQ6410-Iris:~# ts_calibrate
root@TQ6410-Iris:~# ts_test

On se lance alors dans l’installation de X.org par la commande suivante (attention pas du tout optimisé on installe en ‘gros’) puis on installe le gestionnaire de l’écran tactile pour X, on lance le client X à l’ancienne mode (fond d’écran ‘hachuré’) et un petit xeyes pour la route :

1
2
3
4

root@TQ6410-Iris:~# aptitude install xorg
root@TQ6410-Iris:~# aptitude install xserver-xorg-input-tslib
root@TQ6410-Iris:~# X -retro &;
root@TQ6410-Iris:~# xeyes -display :0.0

Si vous voulez directement lancer l’interface graphique, il faut installer le paquetage nodm :

1

root@TQ6410-Iris:~# aptitude install nodm

Puis faire les modifications suivantes dans son fichier de configuration /etc/default/nodm:

1
2
3

NODM_ENABLE = true
NODM_FIRST_VT=2 car j'ai désactivé les autes terminaux virtuels dans /etc/inittab
NODM_X_OPTIONS = 'vt2 -nolisten tcp'

Redémarrez et vous allez obtenir au bout de quelques secondes un écran ‘graphique’ avec un terminal qui prend tout l’écran. Donc ca fonctionne correctement mais c’est pas top…il faudrait installer un gestionnaire de fenêtre voire de bureau…

Alors je ne vous encourage pas à installer gnome ou kde mais plutôt matchbox…et exporter la variable DISPLAY=:0.0 !

Déballage

En déballant le paquet de la TQ6410 vous trouvez:

• La carte électronique TQ6410
• Un écran LCD TFT de 7 pouces de marque Innolux AT070TN92 avec dalle tactile résistive et cadre de fixation
• un câble série droit équipé avec des connecteurs DB9
• un câble ethernet droit
• un câble USB
• un DVD-R gravé avec les ressources logiciels (cross-compilateur, source du noyau linux, “rootfs” linux, android,WinCE, exemples de codes,etc…)
• une alimentation à découpage 12V-1A (livrée avec une fiche américaine !). Cette alimentation est insuffisante pour assurer un fonctionnement correct de la carte et de l’écran 7 pouces. Il faudra donc faire l’acquisition d’un autre bloc d’alimentation.

Si vous voulez des “visuels” de cette carte, faites une recherche avec un moteur de recherche !

Découverte de la carte

Pour faire quelques tests sur la carte, je câble l’ensemble:

• Connexion de l’écran sur la carte (attention les connecteurs sont TRÈS fragiles)
• Connexion de l’alimentation après changement de la fiche d’origine pour une fiche française
• Connexion du câble série sur la carte et sur un PC fonctionnant sous GNU/Linux
• Connexion du câble USB sur la carte en vu d’une connexion ultérieure sur un PC fonctionnant sous Microsoft Windows7

Avant d’alimenter le tout en basculant l’interrupteur M/A sur le coté de la carte, je lis quelques documentations du DVD. Vous y apprendrez que :

• le chargeur de démarrage est U-Boot aussi bien dans la FLASH NAND que NOR (normalement il est donc impossible de bloquer la carte en écrasant le chargeur de démarrage : on démarre toujours depuis la NAND, si problème on démarre depuis la NOR et on réinstalle U-Boot sur la NAND).
• le noyau linux est un 2.6.28 patché pour supporter le S3C6410 de Samsung
• le système pré-installé dans la NAND est un GNU/Linux avec un environnement QTExtended (Qtopia)

Pour avoir quelques informations supplémentaires, nous allons observer la voie série. L’environnement de développement sera une machine sous GNU/Linux Debian 6 (Squeeze). Pour interagir avec la voie série, nous allons utiliser Minicom. Il faut donc l’installer :

root@casimir:~#aptitude install minicom

puis le configurer :

root@casimir:~#minicom -s

La rubrique qui nous intéresse est “Configuration du port série”. Dans cette rubrique il faut régler le port série sur “/dev/ttyS0″ si vous utilisez le premier port série (COM1: sous Microsoft Windows) (remarque: si vous utilisez un adaptateur USB-Série son nom sera vraisemblablement ttyUSB0), le “Débit/Parité/Bits” sur 115200 8N1, le “Contrôle de flux matériel et logiciel” sur “Non”. Sauvegardez vos réglages en revenant au menu principal et en choisissant l’option “Enregistrer config. sous dfl”. Sortez de minicom puis relancez-le en ignorant l’initialisation du modem avec:

root@casimir:~#minicom -o

Minicom attend alors du trafic sur la voie série…

Amorçage par défaut : Noyau Linux et environnement QTopia

Allumez alors la carte, vous devriez voir des messages du chargeur U-Boot. Appuyez sur la touche ‘entrée’ pour interrompre le chargement ! Vous devriez avoir les messages suivants:

OK

U-Boot 1.1.6 (Aug 29 2010 - 16:56:31) for TQ6410

CPU:     S3C6410@532MHz
         Fclk = 532MHz, Hclk = 133MHz, Pclk = 66MHz, Serial = CLKUART (SYNC Mode)
Board:   TQ6410
DRAM:    128 MB
Flash:   0 kB
NAND:    256 MB
In:      serial
Out:     serial
Err:     serial
MAC: 08:90:90:90:90:90
Hit any key to stop autoboot:  3     <= Appui sur la touche entrée
##### U-Boot 1.1.6 B01 for 6410, by esky-sh #####
[f] Format the nand flash
[v] Download u-boot.bin
[k] Download Linux/Android kernel
[y] Download root yaffs2 image
[a] Download Absolute User Application
[n] Download Nboot.nb0 for WinCE
[w] Download WinCE NK.nb0
[s] Set the boot parameter of Linux
[b] Boot Linux
[q] Quit to shell
NAND Flash size: 256 MiB
Enter your Selection:

La carte dispose donc de U-Boot en version 1.1.6. On retrouve bien les quantités de mémoire prévues (pas de NOR car on démarre pour l’instant depuis la NAND). On arrête le chargement et on se retrouve avec le menu de U-Boot préparé par le revendeur esky-sh. Nous utiliserons centaines de ces options pour changer le noyau à charger ou encore le système de fichier racine. Pour continuer le chargement, appuyez sur la lettre ‘b’. Le noyau linux préparé par FriendlyARM démarre puis le système de fichier racine est chargé…On peut alors tester l’environnement QTopia préparé par FriendlyARM après avoir calibré l’écran tactile…Je ne détaille pas plus pour l’instant, ci-dessous deux photographies de l’écran sous QTopia :

Remarque: si l’interface est en chinois, il faut aller sur le deuxième onglet et cliquez sur le drapeau pour passer la langue en anglais (voir la capture d’écran de droite ci-dessus).

Amorçage sur un système Android

La carte est vendu comme étant compatible avec un système Android 2.1. Il faut donc charger le noyau et le “rootfs” android précompilé fourni sur le DVD. Il faut démarrer sur la NAND flash, interrompre U-Boot puis dans le menu proposé, choisir l’option “Download Linux/Android kernel” (lettre ‘k’) pour le noyau ou “Download root yaffs2 image” (lettre ‘y’) pour le système de fichier racine. U-Boot attend alors la connexion du cable USB. Le transfert du noyau ou du système de fichier racine s’effectue avec l’utilitaire DNW.exe disponible dans le répertoire ‘Tools’ du DVD. Ce logiciel fonctionne sous Windows et nécessite l’installation d’un pilote lors de la première insertion du câble (disponible lui aussi sur le DVD dans ‘Tools’). Si la carte est reconnu par le logiciel DNW, vous verrez dans la barre de titre [USB:OK]. Vous pouvez alors transférer votre noyau ou votre système de fichiers racine avec le menu ‘USB Port’ puis ‘Transmit/Restore’. Sous Linux, il existe un logiciel du nom de USBPUSH qui a les mêmes fonctionnalités mais je ne l’ai pas utilisé.

Dans notre cas le noyau Linux s’appelle zImage_a70_New et le système de fichier racine rootfs_android.img. La trace de ces opérations est présenté ci-dessous :

##### U-Boot 1.1.6 B01 for 6410, by esky-sh #####
[f] Format the nand flash[v] Download u-boot.bin
[k] Download Linux/Android kernel
[y] Download root yaffs2 image
[a] Download Absolute User Application
[n] Download Nboot.nb0 for WinCE
[w] Download WinCE NK.nb0
[s] Set the boot parameter of Linux
[b] Boot Linux
[q] Quit to shellNAND
Flash size: 256 MiB
Enter your Selection:k
Downloading Linux/Android Kernel from USB...
OTG cable Connected!
Download address 0xc0000000
Download Done!!
Download Address: 0xc0000000, Download Filesize:0x2b6c0c
Checksum is being calculated...
Checksum O.K.
Downloading Linux/Android Kernel successed
Writing Linux/Android Kernel into NAND...
Erasing at 0x80000 --   2% complete.Erasing at 0xa0000 ... -- 100% complete.

Writing data at 0x80000 --   0% complete.
Writing data at 0x87000
...
Writing data at 0x33f800 -- 100% complete.
Writing Linux/Android Kernel successed

##### U-Boot 1.1.6 B01 for 6410, by esky-sh #####
[f] Format the nand flash
[v] Download u-boot.bin
[k] Download Linux/Android kernel
[y] Download root yaffs2 image
[a] Download Absolute User Application
[n] Download Nboot.nb0 for WinCE
[w] Download WinCE NK.nb0
[s] Set the boot parameter of Linux
[b] Boot Linux[q] Quit to shell
NAND Flash size: 256 MiB
Enter your Selection:y
Downloading yaffs2-image from USB...
Insert a OTG cable into the connector!
OTG cable Connected!
Download address 0xc0000000
Download Done!!
Download Address: 0xc0000000, Download Filesize:0x5ae7b40
Checksum is being calculated.......
Checksum O.K.
Downloading yaffs2-image successed
Writing yaffs2-image into NAND...
Erasing at 0x580000 --   0% complete.Erasing at 0x800000
...
99% complete.Erasing at 0xffe0000 -- 100% complete.

Writing data at 0x580000 --   0% complete.Writing data at 0x661800
...
Writing data at 0x5da6000 -- 100% complete.
Writing yaffs2-image successed

Remarques:

• On voit que le chargement des noyaux ou des images ‘rootfs’ ce fait en mémoire vive à l’adresse 0xC0000000 donc la taille du noyau ou du rootfs ne pourra excéder 128Mo même si l’on dispose de plus en mémoire NAND. Il faudra donc passer par une étape intermédiaire pour flasher un rootfs plus gros que 128Mo dans la NAND (indice: passer par une mémoire SD).
• On note aussi l’adresse dans la NAND à laquelle est stocké le noyau: adresse de début: 0×80000 et adresse de fin:0xA0000 soit un espace de XX octets. Pour le rootfs on a: adresse de début: 0×580000 et adresse de fin: 0xFFE0000 soit un espace de XX octets.
• On retrouvera ces valeurs lors du boot du noyau linux lors de la découverte des “partitions” de la NAND

On lance alors le système avec l’option “Boot linux” (lettre ‘b’). Si ça ne démarre pas, fixez les paramètres à passer au noyau avec “Set the boot parameter of Linux” (lettre ’s’) comme suit:

root=/dev/mtdblock2 rootfstype=yaffs2 init=/linuxrc console=ttySAC0,115200

On obtient les messages suivants:

NAND read: device 0 offset 0x80000, size 0x500000
Reading data from 0x80000 --   0% complete
...
Reading data from 0x57f800 -- 100% complete. 5242880 bytes read:
OK
Boot with zImage
Starting kernel ...
Uncompressing Linux......................................................................
Done. Booting the kernel.Linux version 2.6.28.6 (root@NX-W-3) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) )
#3 Sat Mar 19 18:36:33 CST 2011CPU: ARMv6-compatible processor [410fb766] revision 6 (ARMv7), cr=00c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: SMDK6410
Memory policy: ECC disabled, Data cache writeback
CPU S3C6410 (id 0x36410101)
...
yaffs_read_super: isCheckpointed
0xres = 800, yres = 480Took 62 samples...
Top left : X = 3268 Y = 1504Took 50 samples...
Top right : X =  762 Y = 1522Took 42 samples...
Bot right : X =  760 Y = 2731Took 49 samples...
Bot left : X = 3282 Y = 2746Took 43 samples...
Center : X = 2031 Y = 2124959.654785
-0.278430 0.001384-419.278076 0.000
pointercal_ioctl: -18247 90 62891936 11 20317 -27477808 65536180 0.310019
init: cannot open '/initlogo.rle'
eth0: link down
sh: can't access tty; job control turned off
# warning: `rild' uses 32-bit capabilities (legacy support in use)
eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
# uname -a
Linux localhost 2.6.28.6 #3 Sat Mar 19 18:36:33 CST 2011 armv6l GNU/Linux
# free
              total         used         free       shared      buffers
Mem:       106952        38028        68924            0            0
Swap:            0            0            0
Total:       106952        38028        68924
# free
              total         used         free       shared      buffers
Mem:       106952       104704         2248            0            0
Swap:            0            0            0
Total:       106952       104704         2248
# reboot

Remarques:

• Le noyau utilisé ici est un 2.6.28 compilé pour un SoC SMDK6410
• L’écran tactile n’étant pas calibré vous passez par cette étape (lignes Top Left, Top Right, etc…)
• La mémoire vive utilisé avant lancement de l’interface graphique d’android est de 38Mo, lorsque l’environnement est complètement chargé on est à 104Mo sur 106Mo utilisé ! D’où trés certainement les problèmes de lenteur…

Après 1 minute vous avez l’écran d’accueil d’Android puis on vérifie la version du noyau :

Android fonctionne donc sur cette plateforme cependant la dalle tactile n’est pas très réactive et globalement le fonctionnement est très lent. Selon moi, il n’est donc pas utilisable dans l’état, le peu de mémoire vive est très certainement la cause de cette lenteur (voir remarques ci-dessus). Cela peut donc servir ponctuellement de plateforme de développement android mais sans plus. Cependant un accès shell ‘root’ est disponible par le biais de la voie série.

Les tests préliminaires s’arrêtent ici…Je ne teste pas Windows CE sur cette plateforme car nous n’avons pas de projet dans l’immédiat avec celui-ci. Je passe donc maintenant à la partie la plus intéressante pour nous : la personnalisation de cette plateforme pour nos besoins spécifiques.

Cette carte est réalisable avec des moyens classiques. Les deux circuits CMS et les deux petits condensateurs CMS sont soudables “à la main” sans trop de problèmes. Le circuit imprimé est en simple face avec des straps du coté composants. Tous les composants sont disponibles chez Farnell sauf le connecteur ethernet chez RS (RadioSpares).

Cette carte permet les connections suivantes:

• Sur connecteur HE10-10 ou barrette mâle: Port A sur 8 bits, Port B sur 8 bits, Port C sur 4 bits, Alimentation 3,3V et Masse
• Ports série: le port série complet (tous les signaux sont gérés matierellement, COM1) est disponible sur une barrette mâle au niveau 3,3V ou sur un connecteur DB9 au niveau RS232. Le deuxième port série (COM2) ne dispose que des signaux TX/RX matériellement, il est possible de piloter les signaux RTS/CTS et DSR/DTR logiciellement, encore une fois en 3,3V ou RS232 sur le deuxième connecteur DB9.
• USB Host et USB Device
• Port ethernet 10/100 Mb/s
• Support de pile pour la RTC embarqué (pile CR2032)
• Connecteur pour carte SD/MMC
• Alimentation 3,3V protégé jusqu’à 500mA et alimentation 5V jusqu’à 100mA

Cette carte est exploitée dans le cadre de projet de fin d’étude de BTS IRIS avec comme thème “Linux Embarqué”.

Si vous souhaitez obtenir le circuit imprimé de cette carte ou une version complète assemblée (sans le module DNP9200), merci de me contacter par mél. Les documents de fabrication sont disponibles ci-dessous au format Proteus Isis et Ares 7.8, ainsi qu’au format PDF.

Le cahier des charges était le suivant:

• l’ensemble doit rester à un prix abordable
• le réglage de la température se fait à l’aide de deux boutons plutôt qu’un potentiomètre
• la température de consigne et la température mesurée doivent être visualisées
• la régulation de température doit se faire à +/- 0.2°C prés
• la partie commande de puissance doit être isolée de la partie basse tension
• le tout doit tenir dans un boitier plastique pour éviter le contact avec le secteur

Les solutions retenues sont donc les suivantes:

• utilisation de composants standards facilement disponibles: un PIC16F886, un afficheur LCD 16×2 standard, un capteur de température bon marché mais suffisamment précis sur bus I2C, un triac pour la commande de puissance
• deux boutons poussoirs, un rouge et un bleu, serviront à régler la température de consigne ainsi que l’hystérésis
• la visualisation de la température mesurée, de la température de consigne et de l’hystérésis se font à l’aide d’un afficheur LCD alphanumérique 2 lignes de 16 caractères (afficheur 16×2). Le contraste est réglable par un potentiomètre
• la sonde de température sera un DS1621 sur bus I2C. On utilisera un mode de mesure particulier pour obtenir une meilleure précision (de l’ordre de +/- 0.1°C)
• l’isolation entre la partie basse tension et haute tension se fera à l’aide d’un optotriac MOC3021
• une DEL visualisera la mise en et hors tension de la résistance chauffante
• le tout tient dans un boitier plastique transparent de chez Hammond
• enfin la régulation se fera par hystérésis et non sous forme d’un PID
• l’alimentation se fera à l’aide de n’importe quel bloc secteur du commerce pouvant fournir une tension alternative ou continu de 9V sous 200mA
• les connections se font à l’aide de bornier à vis

J’obtiens donc le schéma électrique suivant:

Première remarque: le capteur de température analogique LM35 du schéma n’est pas câblé sur le prototype final. C’était juste “au cas où” je n’aurais pas été satisfait du capteur I2C. En adaptant le code C, on peut supprimer le capteur I2C et le remplacer par ce capteur. La précision par contre sera bien moindre.

Deuxième remarque: la résistance R9 du schéma est un résistance de rappel au plus. Elle n’est pas câblée dans le prototype final car la sortie RA4 du PIC16F886 n’est pas une sortie à collecteur ouvert. Par contre si vous changez de PIC, par exemple pour un 16F876, cette résistance est indispensable pour piloter correctement l’afficheur LCD.

Troisième remarque: le réseau R7-C7 permet au triac d’encaisser un “dV/dT” important, c’est-à-dire une montée rapide de la tension. Il est surtout utile si le triac commande une charge inductive. Suivant le modèle de triac employé (”snubberless” ou non: voir dans la documentation constructeur du triac) ce réseau est nécessaire ou non. Ici on pourrait le supprimer car on doit commander un élément purement résistif mais comme on ne sait jamais ce circuit protègera le triac.

Quatrième remarque: les fusibles FU1 et FU2 sont en fait des fusibles “polyswitch”. Le fusible polyswitch s’ouvre lorsque sa température interne dépasse 110°C. Cette augmentation de température peut être du à un courant fort le traversant. Lorsque le polyswitch refroidi, il retrouve sa conductivité. Il remplace donc un fusible classique. Par contre le temps de réaction de ces fusibles peut être assez long (de l’ordre de la seconde) donc s’il faut protéger un système de manière très rapide, le fusible rapide reste la meilleure solution.

Un exemple de routage et une réalisation du typon sont présentés ci-dessous:

Remarque: Sur le typon ci-dessus, il manque trois composants: les fusibles FU1, FU2 et la diode zener de protection D2. Sur le routage Ares présenté à la fin de cet article, ces composants sont bien implantés.

Le prototype final se présente de la manière suivante:

	Dans la photographie ci-contre, vous voyez les boutons de réglage de l’hysteresis et de la consigne : bouton bleu (-) et bouton rouge (+). L’écran LCD est visible à travers le capot du boitier. Sur le coté droit, vous avez l’arrivée du 220V et la sortie vers la charge résistive. Sur le coté gauche, vous avez le fil d’alimentation de l’électronique basse tension issu d’un “bloc secteur” de récupération et le fil qui part vers le capteur I2C de température (cordon de souris usagé). Le porte fusible à l’intérieur n’est pas câblé, c’était juste un essai d’encombrement
	Sur le coté droit du boitier, on voit les câbles “secteur” : l’arrivée 220V à gauche et le départ vers la charge résistive à droite. Les fils sont introduits dans des borniers à vis et le boitier est percé en conséquence.
	Sur le coté gauche du boitier vous trouvez le bornier pour l’alimentation continue issue d’un bloc secteur quelconque fournissant une tension de 7V à 20V continu ou alternatif sous 200mA. Le fil blanc du capteur de température a été récupéré sur une vieille souris.
	Les composants sont visibles sur le dessous du boitier. Vous reconnaitrez le PIC16F886, le régulateur linéaire 5V au dessus de lui, le triac sur la droite. Le CI blanc est l’optotriac. Enfin si vous êtes observateur (la photographie est relativement floue), vous verrez que le boitier est percé pour utiliser un tournevis plat pour serrer les câbles dans les différents borniers ainsi que pour le réglage du contraste de l’afficheur LCD.

Un petit test avant de mettre le tout dans son boitier plastique :

Je met en pièce jointe le schéma électrique ainsi que le routage au format Proteus 7.4 (Isis et Ares). Le code C de l’application a été développé avec CCS et est disponible sur demande.

Comme d’habitude si vous êtes intéressé par cette réalisation, vous pouvez obtenir un kit complet ou partiel en me contactant. Le prix du kit complet pour ce montage (CI percé et composants : PIC programmé) s’élève à 60euros.

Module Pinguino avec le module à DELs

Bien sur la petite vidéo qui va bien :

En fin d’article vous trouverez trois programmes :

• le premier programme montre comment faire un BarGraph
• le deuxième simule un analyseur de spectre
• le troisième est celui de la vidéo ci-dessus

Si vous souhaitez un module pinguino ou le circuit imprimé (percé ou non) n’hésitez pas à me contacter.

Bonne lecture et bon test !

Module DELs 32x8

Je vais commencer par des vidéos de présentation de mon prototype, cela remplacera les discours de présentation Notez bien cependant que ce que vous voyez est “minable” par rapport au rendu réel avec le vrai panneau à DELs. La faute a ma pauvre webcam et des conditions d’éclairage pas optimale du tout !!

Le module est équipé de deux connecteurs HE10-16. L’un d’eux sert à la connexion avec le microcontrolleur, l’autre sert à chainer un autre module. Vous pouvez piloter ainsi quatre modules. Le brochage complet du connecteur HE10-16 est donné dans la documentation constructeur fourni par SureElectronics. Pour notre part, nous avons juste besoin des lignes suivantes:

• Broches 12, 14 et 16 : alimentation +5V
• Broches 8,11,13 et 15 : masse
• Broche 5 : entrée d’horloge pour écrire dans le module (WR dans la documentation)
• Broche 7 : entrée/sortie des données (DATA dans la documentation)
• Broche 3 : entrée Chip Select 1. Sélection du module active à l’état bas. Ne pas oublier de mettre tous les interrupteurs  DIP à OFF sauf celui concernant CS1 à ON à l’arrière du module

Une fois le cablage matériel réalisé, il faut initialiser le module en lui envoyant des codes de commande. La documentation officielle du HT1632 (disponible en fin d’article) préconise la séquence d’initialisation suivante avec entre parenthèse l’ordre en binaire à envoyer:

• SYS DIS : Coupe l’oscillateur local intégré et le générateur PWM du HT1632 ( 100 0000 0000 X).
• COMMONS OPTIONS : Choix du mode de pilotage des DELs (100 0010 abXX X). Dans notre cas ab=10 car on est dans le cas “P-MOS open drain output and 8 common option”.
• Pour l’instant notre module est seul, il faut donc le positionner en mode “MASTER”. Cela sélectionne l’oscillateur RC local comme source d’horloge principale et envoie ce signal sur la broche OSC pour les modules en mode esclave (100 0001 01XX X).
• SYS EN : Activation de l’oscillateur local RC (100 0000 0001 X).
• LED ON : Activation du générateur PWM qui commande l’intensité lumineuse des DELs (100 0000 0011 X)
• PWM Duty : Sélection de l’intensité lumineuse sur 16 niveaux (100 101X abcd X) avec abcd évoluant de 0001 à 1111.

Ne vous inquiétez pas, aucune DEL n’est encore allumée après l’initialisation. C’est normal car nous n’avons pas encore envoyé de données au module juste des commandes. La séquence d’initialisation se présente donc de la manière suivante en langage C:

1
2
3
4
5
6
7
8
9
10
11

void ht1632_init(void)
{
   // D'apres doc officiel :
   // sequence init: SYS DIS,COMMONS OPTION,MASTER MODE,SYS EN,LED ON, PWM DUTY
   init_command(0b100000000000); // SYS DIS
   init_command(0b100001010000); // COMMONS OPTION : P-MOS open drain and 8 common
   init_command(0b100000101000); // MASTER MODE
   init_command(0b100000000010); // SYS EN
   init_command(0b100000000110); // LED ON
   init_command(0b100101011110); // PWM DUTY : 16/16
}

Comme vous pouvez le remarquer, nous passons en paramètre notre commande à une fonction “init_command”. Dans la documentation officielle nous avons le chronogramme suivant:

Chronogramme - Envoi d'une commande

On remarque que la lecture de la donnée se fait sur le front montant du signal d’horloge (transition 0 vers 1). Afin de réaliser ces chronogrammes et de rester le plus générique possible, nous allons utiliser la technique du “bit-banging“. C’est à dire que nous allons créer nos propres signaux seulement en mettant à 0 ou 1 la sortie concernée. Nous n’utiliserons donc pas les modules SPI matériel. On obtient alors le code C suivant:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

void init_command(int16 command_data)
{
   int8 i;                             // entier non signé codé sur 8 bits
   int16 j;                            // entier non signé codé sur 16 bits
 
   command_data=command_data&0x0fff;   // On ne garde que les 12 bits de poids faible
   command_data=command_data>>4;       // On décale de 4 rang vers la gauche pour
                                       // avoir les 12 bits précédents sur les poids fort
   ht1632_cs=1;                        // Ligne CS du HT1632 à 1 : HT1632 désactivé
   ht1632_cs=0;                        // Ligne CS du HT1632 à 0 : HT1632 activé
 
   for(i=0;i>12;i++)                   // On doit envoyer les 12 bits précédents
   {
      ht1632_sclk=0;                   // Ligne WR (ici SCLK) à 0
      j=command_data&0x8000;           // on récupère uniquement le bit de poids fort
      command_data=command_data<<1;    // on décale d'un rang vers la gauche pour le prochain bit
      j=j>>15;                         // on décale de 15 rang vers la droite pour mettre
                                       // le bit sur lequel on travaille en bit de poids faible
      ht1632_sda=j;                    // On positionne la ligne DATA (ici SDA) à 0 ou 1
                                       // en fonction du bit j
      delay_cycles(2);                 // Pour respecter les timing de la doc (pas forcement nécessaire)
      ht1632_sclk=1;                   // On crée le front montant sur la ligne WR
      delay_cycles(2);                 // On laisse un peu de temps à l'état haut (timing)
   }
   ht1632_cs=1;                        // Ligne CS du HT1632 à 1 : HT1632 désactivé
}

J’utilise comme compilateur C CCS. La définition des broches se fait de la manière ci-dessous. Il faudra très certainement adapter cette partie à votre compilateur :

1
2
3
4
5
6
7
8

#use fast_io(B)            // On gère nous même le port B
 
#byte pb   = 0x06           // Adresse du port B 16F876A/16F886
//#byte pb = 0xF81         // Adresse du port B 18F2520
 
#bit ht1632_sclk   =pb.0   // PIN_B0
#bit ht1632_sda   =pb.1   // PIN_B1
#bit ht1632_cs     =pb.2   // PIN_B2

Il faut maintenant envoyer des données à notre afficheur pour voir enfin s’allumer des DELs. Dans la documentation constructeur, vous trouverez le chronogramme suivant pour transmettre une donnée (3 bits) à une adresse précise de l’afficheur (sur 6 bits) :

Chronogramme envoi d'une donnée sur 3 bits à une adresse donnée sur 6 bits

Cette fois encore la donnée est prise en compte sur le front montant de l’horloge WR. Notez bien que l’adresse est donnée du bit de poids fort (A6) vers le bit de poids faible (A0). Par contre la donnée qui suit part du bit de poids faible (D0) vers le bit de poids fort (D3). Pour allumer les 8 DELs d’une colonne il faudra donc envoyer 4 bits de données à l’adresse N et 4 bits de données à l’adresse N+1. Le codage en C de ce chronogramme est donnée ci-dessous :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

void ht1632_write_address_data(int16 command_data)
{
   int8 i;
   int16 j;
 
   command_data=command_data&0x3fff;
   command_data=command_data<<2;
   ht1632_cs=1;
   ht1632_cs=0;
 
   for(i=0;i<10;i++)                   // Cette boucle envoie le code de commande
   {                                   // suivi de l'adresse
      ht1632_sclk=0;
      j=command_data&0x8000;
      command_data=command_data<<1;
      j=j>>15;
      ht1632_sda=j;
      ht1632_sclk=1;
   }
   command_data=command_data>>12;      // On décale pour obtenir les 4 bits de données
   for(i=0;i<4;i++)                    // Puis on les envoie en série bit de poids faible
   {                                   // en premier
      ht1632_sclk=0;
      j=command_data&0x0001;
      command_data=command_data>>1;
      ht1632_sda=j;
      ht1632_sclk=1;
   }
   ht1632_cs=1;
}

Ce qui nous conduit à la réalisation du premier exemple vu en video ci-dessus le “BarGraph”. La boucle principale se présente de la manière suivante:

1
2
3
4
5
6
7
8
9
10

while (true) {
      donnee = 0b10100000000000|(cpt<<4)|del;
      ht1632_write_address_data(donnee); // Ecriture : 101 à l'adresse 'cpt' de la donnée 'del'
      cpt+=sens;
      if (cpt==64) {
         fade();
         sens=-1; del=0; cpt--; }
      if (cpt==0)  { sens=+1; del=15; }
      delay_ms(5);
   }

Le code C complet pour le compilateur C CCS est disponible en fin d’article. Pour les autres exemples il fallait optimiser la transmission des données vers le module en se positionnant à l’adresse 0 puis en envoyant les données les unes derrière les autres. Cette méthode est décrite dans le chronogramme suivant:

Pour ma part j’ai choisi d’avoir un tableau d’entier dans mon code C qui représente l’état de l’écran à DELs. Je transmet la totalité de ce tableau à chaque changement dans celui-ci. La fonction “update_screen()” présente cette solution dans le code ci-dessous. Le tableau “Screen” est un tableau d’entier non signé sur 8 bit de 32 cases ce qui correspond exactement au nombre de DELs du module (32×8) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

void ht1632_update_screen()
{
   int8 i,j,temp;
 
   ht1632_cs=1;         // Debut mode Ecriture continu
   ht1632_cs=0;
 
   ht1632_sclk=0;
   ht1632_sda=1;        // Envoi d'un '1'
   ht1632_sclk=1;
 
   ht1632_sclk=0;
   ht1632_sda=0;        // Envoi d'un '0'
   ht1632_sclk=1;
 
   ht1632_sclk=0;
   ht1632_sda=1;        // Envoi d'un '1'
   ht1632_sclk=1;
 
   for(i=0;i<7;i++)     // Envoi de l'adresse, ici à 000000
   {
      ht1632_sclk=0;
      ht1632_sda=0;
      ht1632_sclk=1;
   }
 
   for (j=0;j<32;j++)   // Envoi des données de l'écran : tableau 'Screen'
   {
      temp = Screen[j];
      for(i=0;i<8;i++)
      {
         ht1632_sclk=0;
         ht1632_sda=temp&0x01;
         ht1632_sclk=1;
         temp=temp>>1;
      }
   }
   ht1632_cs=1;
}

C’est cette solution que j’ai employé pour réaliser la simulation de visualisation de spectre et l’affichage défilant. Je met en pièce jointe le code pour la simulation de l’analyseur de spectre. Par contre je vous laisse chercher comment faire un message défilant. Contactez-moi si vous ne trouvez pas la solution.

La prochaine expérience autour de ce module sera le chainage de trois modules “esclaves” à ce module “maitre” pour réaliser un panneau défilant beaucoup plus long (128×8) ou un panneau d’affichage (32×32). La suite bientôt j’espère….

J’ai donc regarder du coté des afficheurs alphanumériques LCD à commande sériel. Vous en trouverez chez Lextronic par exemple. Cependant je trouvais le kit un peu cher et j’ai donc décidé de réaliser mon propre afficheur à commande série.

Il se présente de la manière suivante:

photo Afficheur

Le cahier des charges

Cet afficheur à commandes sériels doit répondre aux critères suivants :

• Alimentation du module soit de manière autonome (alimentation extérieure), soit par le connecteur de la voie série. Les lignes d’alimentations nécessaires sont du 5V régulé et la masse.
• Une ligne de réception de la voie série (RX) compatible avec des niveaux TTL (0V-5V). Une ligne TX peut être disponible pour renvoyer des informations (acquittement par exemple).
• La vitesse de transmission de la voie série peut être fixe (par ex. 1200bauds/s) ou détecté de manière automatique (jusqu’à 115200bauds/s).
• La carte doit pouvoir gérer plusieurs types d’afficheurs alphanumériques (16×2 à 20×4) avec ou sans rétroéclairage.
• Le jeu de commande doit être complet (effacement écran, positionnement X et Y, redéfinition des caractères personnalisables, BarGraphs verticaux et horizontaux, polices de caractères sur 2 ou 4 lignes, réglage du rétroéclairage,etc…) mais rester simple à comprendre et à utiliser.

Les solutions technologiques retenues

Pour répondre au cahier des charges précédent, j’ai adopté les solutions suivantes:

• utilisation d’un µC PIC18F2520 : voie série matériel, détection automatique de la vitesse de transmission, sortie MLI matériel pour piloter le rétroéclairage, entrée analogique pour capter la luminosité, suffisamment de mémoire de programme (mémoire flash) pour stocker des tables de caractères, suffisamment d’entrées/sorties pour piloter l’afficheur LCD, compatible avec les compilateurs C que j’utilise (Microchip C18 ou CCS C).
• utilisation d’une LDR pour capter la luminosité et ainsi piloter le rétroéclairage par MLI à l’aide d’un transistor MOSFET canal N.
• alimentation autonome réalisée autour d’un régulateur 7805 (prévoir un radiateur si le rétroéclairage est utilisé en permanence) ou alimentation par le biais du connecteur de la voie série. Ces alimentations sont sélectionnables par cavaliers.
• La connexion de l’afficheur LCD se fait sur des supports tulipes afin de changer facilement d’afficheur.
• Le connecteur voie série sera un HE10-10 mais la liaison peut se faire aussi en soudant des fils. Les configurations suivantes sont possibles:
  - 2 fils : RX et masse si l’alimentation est réalisée par le régulateur de la carte
  - 3 fils : RX, 5V et masse si l’alimentation vient par le connecteur de la voie série
  - 3 fils : RX, TX et masse si l’alimentation est réalisée par le régulateur de la carte et que vous souhaitez recevoir les acquittements ou messages de la carte
  - 4 fils : RX, TX, 5V et masse si l’alimentation vient par le connecteur de la voie série et que vous souhaitez recevoir les acquittements ou messages de la carte
• Toutes les commandes comprises par cette carte commencerons par le caractère @. Le jeu de commande est décrit ci-dessous.

Schéma électrique et routage

Le schéma électrique correspondant aux solutions précédentes est le suivant :

Image schéma

Le routage associé au schéma précédent est présenté ci-dessous. La carte a au départ été prévu pour un afficheur LCD alphanumérique rétroéclairé 2 lignes de 16 caractères (16×2) :

Image routage

Les fichiers Proteus Isis et Ares (version 7.4) de cette carte ainsi que des fichiers au format PDF sont disponibles en fin d’article.

Cet article est en cours de rédaction, je le termine très bientôt…merci !

Photographies du robot

Pour débuter je vous donne un aperçu du robot final, cela aiguillera peut-être votre curiosité…

Assemblage mécanique du robot

Le châssis du robot a été dessiné par Y. Mergy (Voir le site d’Électronique Pratique). J’ai numérisé en DXF les fichiers TIFF. Ceux-ci ont ensuite été importé dans Proteus Ares pour être retouché et enfin exporté, toujours depuis Ares, en fichier HPGL pour la machine à commande numérique. Un facteur d’échelle a été appliqué sur le châssis d’origine, la taille actuelle du robot sans les pattes est de 108mm x 55mm. Les fichiers Proteus Ares 7.4 du châssis et des pattes ainsi que les fichiers HPGL sont disponibles en fichier joint à la fin de l’article. Je réalise donc une à une les pièces du robot à l’aide d’une machine GravoGraph IS400.

• Tout d’abord les pattes avant et arrière :
• Le châssis supérieur du robot :
• Le châssis inférieur du robot :
• Les pattes centrales du robot :
• L’assemblage du chassis supérieur et inférieur s’effectue en quatre points à l’aide d’entretoises filetées de 20mm et de vis de 3mm :
• La rotation des pattes avant et arrière est assurée en soudant des entretoises en laiton sur la partie haute de la patte, une vis de 3mm réalise l’axe de rotation :
• La motorisation des pattes est assurée par trois servomoteurs de petite taille. Ceux-ci ont été acheté sur E-Bay au prix de 15 euros les 8 :

L’assemblage du châssis se fait en suivant les étapes suivantes:

1. Mettez en place les servomoteurs dans les châssis supérieur et inférieur, agrandissez si besoin à la lime puis repérez les trous de fixation de chacun des servos. Percez (dans mon cas à 2mm), faites un essai d’assemblage des servos avec écrous et vis. Retirez les servos.
2. Assemblez le châssis supérieur avec le châssis inférieur à l’aide des quatre entretoises et de huit vis. A partir de ce moment le châssis est rigide.
3. Découpez quatre morceaux d’époxy double face de taille identique (sur ce robot : xx mm x xx mm) et percer en leur centre un trou de diamètre 3,2mm. Ensuite il faut souder ces rectangles sur le châssis. Ils vont servir de support à l’axe des pattes centrales (se reportez à l’image ci-dessous).
4. Il faut ensuite souder un écrou laiton sur chacune des pattes centrales en face du trou (se reportez à l’image ci-dessous).
5. Soudez les entretoises laiton sur les pattes avant et arrière (se reportez à l’image ci-dessous).
6. Assemblez le tout sur le châssis du robot avec des vis de 3mm.

Carte électronique de commande

Le cahier des charges que je me suis fixé est le suivant :

• Micro-contrôleur PIC 18F avec une mémoire flash importante,
• Commande de 4 servomoteurs (3 pour les pattes et 1 supplémentaire),
• Trois entrées analogiques et/ou numériques pour des capteurs,
• Communication sans fil avec un PC pour la supervision du robot,
• Programmation à distance du robot avec cette même communication sans fil,
• Deux DELs pour les yeux, deux pour la communication sans fil et une pour un usage général,
• Une photorésistance pour détecter la luminosité,
• Deux interrupteurs pour détecter des obstacles,
• Sonoriser le robot (paroles et/ou bruitages),
• Alimentation par accus,
• La platine doit correspondre aux dimensions du robot.

J’ai donc choisis les solutions technologiques suivantes :

• Le micro-contrôleur choisi sera un PIC18F46K20 en boitier CMS pour limiter la place occupée sur la plaque finale. Il possède 64Ko de mémoire flash ce qui permettra de stocker non seulement le programme mais aussi les sons. L’oscillateur interne réglable évite l’emploi d’un quartz externe. Il est programmable in-situ et est compatible avec le bootloader TinyBootLoader. Il fonctionne en 3,3V ce qui permet d’avoir une alimentation et des niveaux logiques compatibles avec le module XBee pour réaliser une voie série sans fil. Enfin il génèrera les signaux des servomoteurs, la numérisation des capteurs (photorésistance, surveillance tension des accus, capteurs tout ou rien,etc…) et la restitution des sons. Dans un premier temps, le compilateur C utilisé sera celui de CCS mais j’espère par la suite faire une version du firmware avec le compilateur C C18 de MicroChip que vous pouvez obtenir gratuitement.
• La liaison sans fil sera réalisée avec deux modules XBee série 2. L’un sera le coordinateur branché coté PC interfacé avec un FTDI FT232RL pour être connecté sur un port USB, l’autre un “end-device” coté robot. Cette liaison sans fil permettra le pilotage du robot en ouvrant un “port série virtuel” du coté PC grâce au FT232RL mais aussi à la programmation en implantant le bootloader TinyBootLoader dans le PIC. Pour fiabiliser cette liaison sans fil, une vitesse relativement basse de transfert a été choisi : 9600bauds/s.
• L’alimentation sera assuré durant le temps de développement par un accu rechargeable de 9V puis ensuite par un accu LiPo de petite dimension pouvant être mis dans le châssis du robot.
• La sonorisation du robot n’engendre pas de surcout car elle n’utilise pas de circuit spécialisé, tout sera réalisé par le PIC18. Seul un amplificateur audio sera utilisé pour pouvoir connecter un haut-parleur de 8 Ohms. Celui-ci sera en boitier CMS SOIC et sera un LM386. La technique employé pour la restitution sonore est celle décrite sur le site de Roman Black et utilise juste une voire deux résistances et un condensateur.
• Les signaux de commandes des servomoteurs suivront l’exemple du Fribotte.
• Enfin l’encombrement de la plaque est de 39mm de large sur 102mm de long pour être monté sur le robot.

Le schéma électrique réalisé sous Proteus Isis 7.4 est disponible en cliquant sur l’image ci-dessous. Le fichier natif et un fichier PDF sont disponibles en fin d’article.

Quelques précisions sur le schéma :

• Autour du micro-contrôleur: R1 est une résistance de rappel au +Vcc pour que le niveau sur la broche MCLR (Master Clear = Reset du PIC active à l’état bas) reste au niveau haut. Dans cette application j’ai choisi de garder la broche MCLR en tant que Reset mais on peut aussi la configurer en tant qu’entrée. Le condensateur C4 doit être placé au plus prés du PIC pour filtrer les parasites.
• Autour du module XBee vous trouvez deux diodes électroluminescentes avec leur résistance de limitation de courant (R5 et R6 de 100 ohms). La diode L1 en clignotant 2 fois par seconde indique que la pile ZigBee a été correctement initialisé et qu’un coordinateur a été trouvé. La diode L2 s’allumera à chaque caractère reçu et son intensité dépendra du niveau de réception.
• Le connecteur J10 reçoit la tension issu de l’accu puis U2 régule la tension de sortie à 3,3V. Les condensateurs C1,C2 et C3 sont des condensateurs de filtrage.
• Les connecteurs J1, J2, J3 et J11 sont destinés à recevoir des servomoteurs. La broche 1 est la masse. La broche 2 est la tension d’alimentation du servomoteur directement relié à l’accumulateur donc au 4,8V. La broche 3 reçoit le signal de commande issu du PIC. Le connecteur J11 n’est pas utilisé pour l’instant mais pourrait l’être si un quatrième servomoteur était utilisé (pour piloter une camera miniature par exemple).
• Les connecteurs J7, J8 et J9 servent à connecter des capteurs supplémentaires ou des organes de commande supplémentaires (par exemple d’autres servomoteurs si vous en avez besoin). Les capteurs peuvent être analogiques ou numériques en fonctions des besoins. Il suffit de configurer le PIC pour mettre ces entrées en mode analogique ou numérique. Par exemple vous pouvez mettre un capteur de température analogique ou un capteur de distance à ultrasons. La broche 1 est la masse. La broche 2 est relié au 3,3V. La broche 3 est relié au PIC. Si vous utilisez un capteur, celui doit pouvoir fonctionner en 3,3V.
• Les connecteurs J5 et J6 ont un double rôle. Ils servent à connecter une del à travers les résistances de limitation R2 et R3 pour faire les “yeux” du robot (broche 1 du connecteur et la masse broche 3). Ils servent aussi à relier des interrupteurs normalement ouvert afin de réaliser des détecteurs de chocs. Il n’y a pas de résistances de rappel au +Vcc sur ces interrupteurs car on utilisera les résistances internes du PIC sur le port B. De plus ces interrupteurs étant reliés au port B, il sera possible de détecter un choc “sous interruption” (changement d’état sur une broche du port B).
• La del L3 est un témoin lumineux. Dans l’application elle servira à indiquer un niveau de tension trop bas au niveau des accus. Si elle est allumée, la tension des accus est trop faible, il faut les recharger.
• Le bouton poussoir K3 et sa résistance de rappel R9 peuvent être utilisé pour des tests. Lorsque K3 est relâché, le PIC voit un niveau logique 1, lorsque K3 est enfoncé il voit un niveau logique 0.
• La luminosité est capté par une photorésistance (LDR1). Celle-ci est monté dans un pont diviseur de tension. Plus la luminosité est forte, plus la résistance de la LDR est faible. On conclut que si la luminosité est faible (forte résistance de la LDR), alors la tension sur l’entrée analogique du PIC sera proche de 3V. Au contraire, quand la luminosité est forte, la résistance de la LDR est faible donc la tension sera proche de 0V.
• La tension des accumulateurs est surveillée par l’intermédiaire du pont diviseur R7/R8. La tension Vcapt_batt vaut (R8/R7+R8)*Vbatt. On numérise cette tension par l’entrée AN1 du PIC. On peut donc retrouver la tension Vbatt et informer l’utilisateur si cette tension devient trop faible (par exemple en faisant clignoter la del L3).
• Le connecteur J4 est le connecteur de programmation in-situ du PIC. Son brochage est compatible avec les programmateurs les plus courants: PicKit2 et PicKit3, ICD de Microchip ou de CCS. Ce connecteur sera utilisé une fois lors de la programmation du bootloader TinyBootLoader. Les autres programmations se feront par le logiciel TinyBootLoader par la voie série sans fil.
• Les résistances R10 et R12 et le condensateur C7 servent à la reconstruction de l’onde sonore suivant le principe décrit sur le site de Roman Black. Ces trois composants sont montés sur des picots pour pouvoir être interchangeable afin de trouver le meilleur compromis qualité sonore / occupation mémoire en fonction de la méthode de compression utilisée.
• R13, C8 et R14,C9 forment deux filtres passe-bas du premier ordre. La mise en série de ces deux filtres permet d’obtenir un filtre passif du second ordre (-40dB par décade). La fréquence de coupure de ce filtre est donné par fc=1/(2*PI*R*C) soit dans notre cas fc=1/(2*PI*10K*10nF)=1600 Hz. Cela permet d’éliminer le “sifflement” généré lors de la reconstruction du son. Notez que du coup on atténue aussi beaucoup les aigus.
• L’amplificateur audio est un LM386. Dans cette configuration il amplifie d’un facteur 20. C5 est un condensateur de liaison, il élimine la composante continue du signal issu du PIC. P1 permet de régler le niveau sonore. C10 est un condensateur de liaison positionné juste avant le haut-parleur de 8 Ohms. Le haut parleur a été récupéré dans un ordinateur portable et fixé sous le robot (se reporter aux photos en début d’article).

Réalisation de la carte

Le schéma électrique étant prêt, il faut passer au routage de cette carte. Au moment de la réalisation de cette carte, je ne disposais que de plaque simple face. J’ai donc choisi de faire quelques straps et des pistes TRÈS fines (15th) pour obtenir une carte qui remplisse les contraintes d’encombrements. Le résultat de ce routage est visible en cliquant sur l’image ci-dessous. Pour obtenir le typon à l’échelle 1 ainsi que l’implantation et la liste du matériel, je vous conseille de télécharger les fichiers originaux pour Proteus Isis et Ares 7.4 ou d’imprimer le fichier PDF disponibles en fin d’article. Ci-dessous vous avez une plaque pour ce robot sans composant. J’ai du juste passé quelques coups de cutter sur un coté de la plaque pour bien séparer quelques pistes, le reste est sorti tout à fait correctement. Ensuite j’ai soudé les composants CMS et les straps. On obtient alors la plaque suivante : Enfin la plaque finale est la suivante:

“Dongle” USB pour XBee

Pour pouvoir dialoguer avec le module XBee du robot, j’ai réalisé un “dongle” à brancher sur un port USB d’un PC. L’interface entre le bus USB et le module XBee est réalisé avec un FTDI FT232RL. Le schéma électrique et le typon sont présentés ci-dessous :

Ce qui donne la réalisation suivante:

Reportez-vous à cet article pour plus de précisions.

Programmation

Pour tester la carte, je compile tout d’abord le bootloader TinyBootLoader pour un PIC18F4620 (le 46K20 n’existe pas mais ils ont tous les deux la même quantité de mémoire flash) pour un oscillateur interne à 16MHz et une vitesse de 9600 bauds/s. Pour avoir plus de renseignements sur TinyBootLoader, merci de lire cet article sur le site de l’académie de Limoges et cet article sur ce site. Le fichier HEX est disponible en fin d’article. La programmation s’effectue avec un PicKit2 (Voir cet article). Pour tester la connexion sans fil les deux modules XBee sont configurés avec le logiciel X-CTU comme indiqué dans cet article.

Téléchargements