Embedded weblog

Les cartes du constructeur Embest représentent une solution pour les petites bourses désireuses de s'essayer au développement embarqué sur processeur ARM : d'un coût compris entre 180 et 250€ environ (HT), et présentant de nombreuses interfaces (RS232, ports USB host et device, Ethernet, entrée/sortie son, lecteur SDCard, sortie écran LCD, entrée caméra, et plein de GPIO), les cartes réellement professionnelles, comme celles vendues par Freescale, et du même acabit, seront au moins trois à quatre fois plus chères. Cependant, on paie ce moindre coût de chinoiserie au niveau essentiellement du support : celui-ci laisse réellement à désirer, et la documentation du processeur Samsung S3C2440 est soit pauvre, soit sibylline. L'unique revendeur français Neomore a d'ailleurs fait preuve de beaucoup de patience en essayant de nous aider pour nous dépatouiller avec ce qui est fourni par défaut, et très windows-centré (à noter que même sous windows, l'installation du driver USB pour communiquer avec le bootloader a échoué, mais on sait que deux XP ne sont pas pareils, et que la compatibilité avec win2000 est scabreuse) : pour faire du Linux embarqué, c'est toujours gênant.

Quelques petites illustrations de notre matériel (on remarquera un joli écran touchscreen, qui coûte plus cher que la carte...).

Louons dès à présent fortement mon stagiaire Rémy Gottschalk, qui a pu à mes côtés démêler toute cette histoire, et surtout trouver tout seul (il faut bien prendre vacances parfois -- sauf quand on est stagiaire, c'est bien connu) les ressources pour se sortir d'affaire, et arriver à faire ce que l'on voulait.

Sous Linux, la gestion du J-TAG se fait via l'incontournable OpenOCD, qui communique ensuite avec telnet ou gdb. Suivant les indications d'un développeur irlandais manifestement aguerri et ayant soumis un patch pour OpenOCD quant à la gestion du S3C2440, le choix d'une sonde J-TAG s'est portée sur l'Amontec J-TagKey Tiny sur port USB. Celle-ci a l'avantage de ne coûter que 29€ (les frais de port -- depuis la Suisse -- sont d'ailleurs supérieurs à ceux de la sonde), et une centaine dans sa solution professionnelle (qu'il vaut mieux choisir, rétrospectivement : cela évite au moins de devoir souder un adaptateur folklorique entre des broches d'espacement 2mm et 2.5mm -- 2.5 étant la norme, et 2mm étant introuvable, sauf par lot de 100 sur site spécialisé...). Oui, on est loin des 2500€ habituels pour un tel matériel (Hors Taxe, toujours :)  ), mais il y a une raison à cela : nulle partie software embarquée, nul port Ethernet à l'horizon, cette sonde est très minimaliste, et il faut donc se taper toute la conf' derrière, en ayant au final bien moins de souplesse et de fonctionnalité (comptez donc que si vous avez un prestataire pour ce boulot, mieux vaut mettre le prix que de le payer une semaine dans le vent).

Cette clé va permettre bien des choses, une fois configurée (et installée) : mais pas de programmer la flash. Car une sonde J-TAG a deux fonctionnalités majeures : celle de pouvoir débugger les instructions qui passent par le processeur (ce qui veut dire interrompre le code et afficher des registres tout autant que de charger du code et de modifier les registres), et celle de flasher, c'est-à-dire d'écrire sur la flash (qui rappelons-le est soudée sur la carte). En attendant, voici la configuration (openocd.cfg) qu'il faut donner à OpenOCD (dans la dernière version du SVN -- révision 888 --, qui supporte le processeur sans aucun patch supplémentaire à appliquer) :

interface ft2232
jtag_speed 0
jtag_ntrst_delay 100
jtag_nsrst_delay 100

ft2232_vid_pid 0x0403 0xcff8
ft2232_layout "jtagkey"
ft2232_device_desc "Amontec JTAGkey"

jtag_device 4 0x1 0xf 0xe

#daemon_startup attach
target arm920t little 0 arm920t

reset_config trst_and_srst combined

working_area 0 0x33F00000 0x4000 nobackup

#run_and_halt_time 0 500

#nand device <nand_controller> [controller options]
nand device s3c2440 0


#script
init
reset
halt
#nand probe 0
#arm7_9 sw_bkpts enable
arm7_9 force_hw_bkpts enable

Concernant la Flash, c'est le support NAND par OpenOCD qui pêche, et cela devrait être en théorie corrigé (ou plutôt implémenté) bientôt. En attendant, comme le but de l'opération était de paravirtualiser, et qu'OKL4 n'arrivait pas à se lancer directement depuis la RAM (pour des raisons plus ou moins mystérieuses), un bootloader s'avérait indispensable à mon valeureux stagiaire, qui a donc cherché une autre solution. A noter que l'on pourrait tout de même espérer faire booter un uClinux avec partition root en NFS, et flasher depuis celui-ci avec un simple dd (c'est une méthode que j'ai moi-même employé lorsque je travaillais sur les STB d'un célèbre intégrateur/constructeur néerlandais). Pour lancer une commande (après avoir tout bien branché niveau hard, lancé la carte, et démarrer OpenOCD qui redémarre la carte suivant les indications donnés dans le ficher de conf), il suffit de taper dans un gdb (celui pour arm dans la crosstool chain) lancé à côté (et se connectant à OpenOCD en local -- à noter que l'on peut envoyer des commandes à celui-ci directement soit par Telnet, soit par la commande "remote" de gdb) :

target remote localhost:3333
file <le nom de l'exécutable>
load

C'est ici qu'une enquête palpitante débute.Indiana Jones, à côté, ça fait pitié ; heureusement, grâce au net et le Dieu Google (qui souvent décède sur de tels cas de recherche), on économise sur les billets d'avion. Nous éluderons cependant les étapes scabreuses du voyage, dont je ne pourrais retracer exactement toutes les circonstances palpitantes. Tout d'abord, direction la Corée, afin de trouver (enfin !) une documentation digne de ce nom sur le processeur et ses satellites (la Flash associée K9F1208U0B) : ce grâce à la carte de développement de référence de Samsung. Original samsung resource for S3C2440A(SMDK2440), donc (le jour où ce lien ne marche plus, mailez-nous...). Et puis l'Italie, où l'on trouve enfin un guide "complet" d'utilisation de Linux pour cette carte. On passera sur la Chine, car Embest est chinois, nous l'avons déjà dit (connaissance de l'Anglais chinois requis aussi pour communiquer sur le forum).

On apprend ici que pour flasher, il va falloir se servir... du wiggler ! Cette sonde du super-pauvre est en effet branchée sur le port parallèle (bonjour les perf !), et pilotable via un protocole évidemment obscur, implémenté uniquement pour Windows et fourni sur CD (le programme est fort moche, on s'en doute), marchant difficilement, mais marchant quand même (au point où on en est...). Du moins c'est ce que l'on croyait, jusqu'au passage en Corée : car l'implémentation pour Linux non seulement existe, mais en plus le code source est disponible, et... sans licence (apparemment)  [ update : on trouve aussi le programme avec sources sur certains CDs fournis avec les cartes, dans un dossier Jtag ; non documenté, et inconnu de Neomore, d'ailleurs... ]. Bref, on branche le bidule, et on suit le guide italien à la page 23 : la commande à exécuter est "Jflash-s3c2440 vivi -t=5", lorsque l'on veut mettre vivi, le bootloader miniature tout pourri-qui-sert-à-rien fourni par défaut (fermé nous avait-on dit, mais on arrive à trouver les sources...) ; attention, c'est bien "-t" et non "/t" comme écrit dans le guide et l'Usage du programme (manifestement adapté de windows à la hâte). A la question "Select the function to test :" ("n'ayez pas peur", comme disait Jean-Paul), il faut répondre "0" (ie "K9S1208 NAND Flash"), puis indiquer l'Input target block à 0 (pour écrire en tête de flash, c'est plus pratique pour booter...).

Évidemment, ce n'est pas vivi que l'on veut flasher, c'est le brave u-boot. Oui, mais un qui marche (sur la carte, s'entend). En théorie, cela devrait être disponible, puisque le S3C2440 est utilisé par le projet OpenMoko sur leur nouvelle plateforme FreeRunner (enfin, c'est le 2442B, pour être exact, mais pour ce qui nous intéresse cela ne change pas grand chose). Las ! Non seulement le projet mené par DENX n'a jamais accepté un patch pour le support de ce processeur (manifestement, la propreté légendaire du code aurait sinon été mise en danger), mais en plus le SVN semble tellement bordélique qu'y trouver une information utile relève de la gageure (à noter qu'OpenMoko n'a pas de problème pour la partie flash : ils disposent de 2Mo de flash NOR pour booter, et OpenOCD supporte l'écriture sur NOR -- qui coûte beaucoup plus cher). En attendant, il faudra donc se contenter d'un u-boot antédiluvien 1.0.0 compatible, fourni dans le SDK de la SMDK2440 coréen dont nous avons parlé au dessus. Fort heureusement, le cross-compilateur gcc de l'an 40 (2.95.3, de mars 2001, soyons précis) nécessaire pour compiler pareille vieillerie est aussi fourni dans le package.

Attention encore une fois : ça ne marche pas totalement tel quel. En effet, vous n'aurez aucune possibilité d'entrer des commandes via le port série, et donc d'obtenir la fameuse ligne de commande d'u-boot capable, par exemple, de faire booter un système (ce qui peut être utile, on en conviendra). Pour cela, il faudra activer une macro obscure, dans include/configs/smdk2440.h : #define CONFIG_HWFLOW (cela permettrait de modifier le protocole concernant les bitrates d'entrée/sortie).

Bref, flashons : compter 8 minutes pour u-boot (taille : 87Ko), non ce n'est pas une blague. Utilisation du CPU : de l'ordre de 80%, ça sent le bug niveau interruptions (mais c'est juste une hypothèse). Consolation : ça marche à tous les coups. Autant dire que si un jour la méthode de faire booter uClinux directement en RAM depuis la sonde JTAG USB via OpenOCD, puis flasher depuis, marche, ça devrait être plus sympa  :)  (mais il va me falloir un autre stagiaire, le mien est trop grand maintenant !).

Fin de nos aventures palpitantes dans le merveilleux pays de l'embarqué. Le u-boot marche (vraiment), et a pu faire booter notre hyperviseur de paravitualisation OKL4, avec même un Linux dessus (la classe !). Grands remerciements aussi à Rémy, pour son dernier jour de stage (eh oui, déjà !), qui aura fait un vrai boulot d'investigation internationale  :).