Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/clearbricks/common/lib.http.php on line 222

Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/clearbricks/common/lib.http.php on line 224

Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/public/lib.urlhandlers.php on line 65

Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/clearbricks/common/lib.http.php on line 247
Embedded weblog - page 5

Embedded weblog

Aller au contenu | Aller au menu | Aller à la recherche

jeudi, septembre 25 2008

nothing is as easy as it looks

Alors que je suis en pleine galère de portage uClinux sur ma carte (toujours la même, actuellement j'arrive à charger et lancer un kernel, mais manifestement il boucle en reboot à l'initialisation, au niveau du deflate et de _setup_mmu, ce qui est étrange pour un uClinux configuré sans support de la MMU, vous en conviendrez), je tombe sur le peu de doc disponible sur le net, et notamment sur cette présentation/conférence à propos d'un portage de Linux sur plateforme LPC de Philips. Morceaux choisis :

Preparing to program Linux
  Since our U-boot can not program, we need to create a .hex file so JTAG can program it.
  objcopy does not support changing base address of result Intel hex file.
  Wrote our own program to convert from binary to Intel hex file supporting different base address.
  Built u-boot images and converted them to Intel hex.

Programming and Running?
  Used JTAG again to program Linux and the file system
  Running, asking U-boot to run Linux
  No response from kernel...
  We have no symbolic debugging, but tried a breakpoint using JTAG debugger
  We are nowhere near a valid address...
  Seems we programmed the wrong file...
  But this was the file according to the AP...

Les galères s'enchaînent...

Running init
  Searching for help on the Internet did not help (first time in my life...)
  Contacting Philips and after a lot of effort (since they officially do not support Linux) we found a contact person in China...
  He looked at our kernel configuration and found that we did not include support for flat binaries, no one told us to do so...
  Added support for flat binaries and...
  Let there be light...

Is our work done?
  Our work is far from being done, we ran uClinux on an evaluation board only
  Hardware guys never build a similar board...
  We need to modify U-boot for our new board
  Board specific code is coded in ARM assembly so we had to learn ARM assembly.

Au final :

Returning to evaluation board
  Retrying to run on evaluation board...
  No success...
  We should minimize our changes in Linux code...
  Ok, it runs but it is unstable...
  Took us about 3 weeks to find out a minor change in Linux configuration (ARM clock).

Conclusion de l'aventure :

Summary
  This talk contains only the highlights, we had much more problems, some of them our our mistakes.
  What do we learn from this?
  Nothing is as easy as it looks.
  Try to avoid changing the Linux kernel, the kernel programmers know what they are doing.
  Do not attempt porting if you are not absolutely familiar with target architecture.

La fois où j'ai expliqué longuement à un non informaticien les particularités du métier, il a trouvé ça désespérant. C'est vrai. Mais bon, quand on a trouvé au détour d'un pdf paumé que faire un "set $sp=<load_address>" dans gdb avant de faire son load peut éviter des mésaventures quant au chargement de code envoyé via j-tag, et que effectivement on passe d'une erreur mystérieuse dont on a finit par comprendre au détour d'une ML lorsque le patch contenant le message d'erreur a été soumis qu'on est en train de jardiner dans la RAM dans des adresses fantaisistes, à un linux qui certes ne dit rien mais manifestement tourne (ok, dans le vide, mais quand même), on est presque heureux. Forcément, le type qui fait du web, à côté, il paraît bizarre...

mercredi, septembre 24 2008

"je ne vous le fais pas dire !"

BTW, actually writing code for OKL4 feels rather scary: there seems to
be a real C library in there. After working with platforms like Nucleus
and an unnamed mobile phone OS that I can't talk about, this makes a
nice change. It's amazing how much you miss printf() if you can't get it...

(extrait de la ML d'OKL4, thread "[okl4-developer] Platform recommendations", vendredi dernier : un débutant découvre la magie d'OKL4, j'avais effectivement été tout aussi surpris de cette disponibilité du debug au printf de kernel en environnement paravirtualisé...)

mardi, septembre 16 2008

et personne ne m'a rien dit !

Scandale ! SquashFS a été inclus au noyau au moins depuis le 2.6.25, et je n'étais pas au courant ! C'est en décochant les supports pour AmigaFS et autres machins-bidules totalement inutiles et pourtant activés par défaut (faudra m'expliquer pourquoi...) que je suis tombé dessus (à noter : c'est désactivé par défaut, contrairement à JFFS2) : LE meilleur système de fichier compressé read-only de tous les temps immémoriaux est à présent inclus dans le kernel Linux vanilla ! Youhou ! Fini les séances de patches !

Mais mieux encore : cela permettra certainement de répandre cette tuerie ambulante qui permet par exemple, avec les outils complémentaires aussi merveilleux qu'introuvables il y a à peine un an, de créer un système de fichier à partir d'un répertoire (donc sans loop device, JFFS2 sait le faire aussi -- pour ext2, il faut regarder du côté de debugfs, au secours !) en pouvant exclure certains paterns (par exemple les fameux .svn qui cassent toujours les pieds, ou les *~ qui ne sont jamais mieux), de changer les permissions à la volée (plus besoin de fakeroot), mais aussi de pouvoir créer des devices à la volée (plus besoin d'être root et sous Linux, et de faire des tambouilles à coup de mknod, MAKEDEV, et autres cp -a). Et SquashFS, ça compresse rudement mieux que CramFS, y compris la table des fichiers (alors que sous Cram, on peut retrouver le nom des fichiers, et donc potentiellement les modifier -- oui, parano, mais bon...). Bref, ce bonheur est enfin disponible facilement pour tous (un rapide sondage au dernier salon RTS montrait que le système de fichier magique était radicalement oublié ou méconnu), adieu Cram, et bonjour Squash !  :)

mardi, septembre 9 2008

la macro comique du jour

C'est dans la compilation du kernel Linux, section "Device Drivers"->"Memory Technology Device (MTD) support" :

Enable chip ids for obsolete ancient NAND devices (MTD_NAND_MUSEUM_IDS)

lundi, septembre 8 2008

roooohhh, boulets !

$ echo "toto" | openssl dgst -md5 -verify public_key -signature thesig.sig
Error opening key file public_key
26004:error:02001002:system library:fopen:No such file or directory:bss_file.c:352:fopen('public_key','r')
26004:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:354:
unable to load key file
$ echo $?
0

No comment...

vendredi, septembre 5 2008

le Tux de Linagora victime de la canicule

Et pourtant, il ne faisait pas bien chaud, cet été. Mais il est bien connu que le manchot pygmée est habitué à des températures bien plus basses... Voilà donc deux photos de lui avant, très fier et dans le faste :


Et le voilà à présent, tout fondu :


Pour cause de restriction budgétaire (une demande d'achat a tout de même été émise), le cahier de condoléances est ouvert en commentaires.




update 17h26: C'est un miracle !! Mieux que J-C, Tux n'aura mis que 30 minutes à ressusciter !!


Bon, va falloir réussir à le sortir, maintenant...  :)

lundi, septembre 1 2008

bien choisir sa grammaire de fichier de conf

Ce n'est pas vendredi, mais aujourd'hui je suis un Saint, donc a priori, je suis au dessus de tout soupçon de trollage. OpenBSD est un système contestable à beaucoup de points de vue (admirez l'euphémisme), mais il y a des choses insupportables. C'est par exemple le cas du hostname.*. Ce fichier dont l'extension est le nom d'une interface réseau (nom qui change en fonction du driver employé : "contestable", disais-je), renferme les informations nécessaires à la bonne configuration de ladite interface : IP fixe ou dhcp, alias divers, activation (mais manifestement, pas de désactivation), et d'autres choses dont je n'ai pas la moindre idée de ce à quoi ça sert ("rtsol" ; les bridges quant à eux sont configurés par des fichiers spécifiques, comme l'indique un echo au cas où le mot clef serait rencontré). Prenons un exemple, avec une IP fixe :

$cat /etc/hostname.xl0
inet 192.168.20.201 255.255.255.0 192.168.20.255 description "Reseau Labo"
inet alias 192.168.20.202
inet alias 192.168.20.203
inet alias 192.168.20.204
inet alias 192.168.20.205

Comme on peut le voir, il n'y a qu'une seule ligne d'IP fixe, logique, en tête, suivie de plusieurs IP d'alias, toujours logique. On remarque que l'on commence par le mot clef "inet", à distinguer de "up", ou "dhcp" : jusqu'ici, tout va bien. Là où ça va mal, c'est le second token : soit une adresse IP, soit le mot clé "alias", qui sera alors suivi... d'une adresse IP. Ca ne sent pas bon. Déjà, on peut se dire qu'il y a plutôt intérêt à ce que l'adresse reste toujours indéfiniment sous forme de chiffres, car le jour où l'on veut puiser la correspondance lettrée dans /etc/hosts, et qu'un malin crée une machine "alias", ça risque de mal se passer.

Mais dans l'absolu, nous avons déjà un problème de parsing : "alias" or not "alias", that is the question. Et les gens de BSD ne se tracassent pas beaucoup, ils commencent leur parsing dans le script d'activation des interfaces /etc/netstart par un magnifique :

read af name mask bcaddr ext1 ext2

Ce qui, on l'admettra, est un peu bourrin. Car rien ne dit que le premier argument sera une adresse d'interface (AF), le second un nom (name), le troisième un masque (mask), etc. Résultat des courses, quelques lignes plus tard...

read dt dtaddr
if [ "$name"  = "alias" ]; then
   # perform a 'shift' of sorts
alias=$name
name=$mask
mask=$bcaddr
bcaddr=$ext1
ext1=$ext2
ext2=
else
alias=
fi
cmd="ifconfig $if $af $alias $name"

Oui, ça fait mal aux yeux...

dimanche, août 31 2008

développement habile (ou l'ôde à la moulinette et à l'enjoyment)

Yannick nous parle beaucoup de développement Agile (souvent très tôt le matin ou très tard le soir, et sans tricher je pense : je me sens donc obligé de répondre un dimanche :)  ). C'est très fashion, à tel point que ça contamine (heu, prophylaxise ?... À voir) même l'embarqué, ce joyeux monde d'électroniciens ratés, mais j'ai un très gros problème avec l'une de ses composantes qui s'applique à moi, ingénieur développeur/intégrateur : l'eXtreme Programming. Par exemple, on se souvient d'un tandem qui a essayé d'introduire la chose chez Thales il y a deux ans et demi, et qui a gagné le trophée de l'innovation pour ça (l'un des deux étant épitéen, et l'autre joueur d'échec, et tous deux bossant juste derrière moi, à Colombes). Mais surtout, j'ai souvenir d'avoir dû y passer moi-même, plus tard : et là, c'est moins drôle.

Mais commençons par un autre bout : oui, il faut des développeurs experts pour pondre les nombreux tests par fonction (heu, procédure : c'est surtout pour les langages pourris type C/Java qu'il est intéressant d'effectuer de tels tests -- mais c'est tellement répandu qu'on en oublie presque que le monde pourrait être parfait et en Caml  :)   ). Et c'est ici que vient s'insérer une anecdote d'un projet réalisé l'année dernière, dans mon ancienne boîte d'électroniciens (80% électronique / 20% informatique -- j'ironise à peine :)  ). Nous prenions pour réaliser les tests des gens en intercontrat, histoire de rentrer dans les coûts, parce que le client veut quelque chose qui marche avec une équipe, pas avec deux. Un jour, nous voyons un des deux développeurs de tests (sur la même machine, XP oblige) commencer à suer gravement : il était depuis deux jours sur un bug, qui arrivait de temps à autre sans prévenir. Et ce n'était pas que le programme à tester était mauvais, enfin, il ne savait pas trop : de temps en temps, segfault sans prévenir. Ciel ! Nous prenons un gdb, et effectivement, quand ça plante, ce n'est pas à moitié : la pile est totalement corrompue. Ça sent le scanf pourri.

Parce que lorsque l'on fait du test de ce genre, on utilise la libc à outrance, et on ne recode pas son parseur ("how many divisions ?"), alors on utilise des choses immondes comme scanf (il faudrait légiférer pour l'interdire définitivement). Bref, nous allons voir le code, et ma foi, il n'y a rien d'extraordinaire. C'est alors que vint l'idée : et si le tableau utilisé n'était pas forcément très ben alloué ? Et la réponse ne se fit pas attendre : "c'est quoi malloc ?". Ne riez pas : lorsque l'on est habitué à faire de l'informatique sur PIC et sans MMU, ça se comprend (enfin, presque, parce qu'un pointeur reste un pointeur, MMU ou pas, il vaut mieux s'assurer que ça ne pointe pas n'importe où). Et ils étaient deux à coder la même horreur côte à côte sur le même PC. Évidemment le bug du test absolument fatal fut rapidement corrigé. On pourra au passage se poser la question d'un bug encore plus mesquin (par exemple tableau alloué à un élément près) qui aurait pu avoir un effet de bord sur les résultats des autres tests (par exemple les déclarer faux alors qu'ils sont exacts, ou pire, les déclarer juste alors qu'ils sont incorrects).

Donc, il nous faut un ingénieur encore plus cher que le développeur, pour faire les tests. Déjà, trouver un développeur à peu près compétent par les temps qui courent, cela relève de l'exploit, et ce n'est pas gratuit ; mais en plus de ça, il faudra plus-que-doubler le coût final pour avoir quelque chose de potable. En ces temps de soldes permanentes que connaît le métier, j'ai comme un doute quant à la pertinence du business model (il va sans dire que le testeur ne doit jamais être la même personne que le développeur, c'est l'évidence même).

Ce que je n'aime pas avec la méthode agile, c'est qu'il s'agit d'une méthode. Ce qui dans le milieu veut dire : un dogme, avec ses gourous. Avant, c'était le cycle en V, que l'on louait beaucoup, malgré les 20% de projets réussis, et 80% de perte en ligne (lors d'une conférence, un commercial vantait son entreprise de génie logiciel qui arrivait au chiffre record de 35% de réussite dans ses projets -- et il était sérieux). Pourtant, le "bon sens" indique que ce système est digne d'un HEC pas bien dégrossi ne connaissant rien à l'informatique, et encore moins à la programmation. Calquer des modèles ne marche pas. Pourquoi ?

Parce que le métier de développeur relève de l'artisanat, et le concepteur d'un programme est un artisan. Il s'agit bien d'un art manuel. C'est pour cela qu'une armée de chinois ne prendra pas notre boulot (et une armée d'indiens non plus), sauf à ce que le travail ne relève plus de l'art, mais du "pissage de code", bête et méchant. De la robotisation, du travail automatique, taylorisé, déshumanisé. Le développement est une discipline artistique (avec des notions de beauté), il ne s'agit pas seulement d'être prompt et aisé dans ses mouvements. J'aime développer pour le vertige du kwrite blanc (contrairement aux chercheurs je ne développe jamais sur feuille : aucun moyen de compiler du papier n'a pour l'instant été trouvé) : il n'y a rien, l'immensité vierge, et il va falloir aller par touches successives mettre en place une cathédrale (à partir d'un bazar, c'est bien connu), échafauder un système complet et suffisant qui pourra effectuer des actions, qui aura des sorties voulues en fonction des ses entrées déterminées.

Tiens, du déterminisme ! Eh oui, à moins de développer le système du Deep Thought (qui est le nom de mon PC portable sur lequel j'écris, d'ailleurs), auquel cas un "return 42;" sera plus rapide, un programme informatique a des entrées attendues, et des sorties associées (en ce sens, on peut faire l'analogie avec une application mathématique : ne jamais oublier aussi que l'informatique est une branche les plus complexes des mathématiques, et dès lors que l'on sort de ce cadre, on fait de la peinture rupestre si l'on veut -- désolé pour les "développeurs" html --, mais certainement pas de la programmation !). Et nous pouvons donc tester directement en fonction de ces entrées et sorties depuis l'extérieur en mode "boîte noire" : c'est ce que l'on appelle une "moulinette de test", par exemple un script shell géant gérant toutes sortes d'appels (y compris devant générer des erreurs), et scannant la sortie pour nous répondre des OK ou des KO.

Il y a deux restrictions à cela : tout d'abord, le procédé peut paraître "grossier", en ce sens qu'il n'a pas la même profondeur de détail que le "test unitaire" (dont le nom est ambigu, d'ailleurs). On pourra répondre par la modularité nécessaire des grosses applications, par la nécessité de toujours mettre des hooks de debug sous macro (un "#if TEST", tout simplement), faisant des printf ou autres joyeusetés qui vont bien (attention cependant aux applications temps réel), et par le fait qu'empiler des briques préjugées correctes ne garantit pas non plus que le résultat final sera bon (pour répondre au présupposé agile). Ensuite, la limite de la moulinette se situe dans la programmation graphique.

Que l'on ne s'y trompe pas : l'XP a été créé pour et par des "génie logiciel" (attention aux acceptions de "génie" :)   ). Et l'on connaît les classeurs de centaines de page de test du style "cliquer ici, là, re-ici, etc, vous devez alors trouver blabla dans la zone de texte à droite". Sauf que c'est ici un faux problème : tout bon développement se fait en ligne de commande, et la partie graphique ne doit être qu'une interface qui... s'interface (c'est donc pour ça le nom ? :)   ). C'est exactement de cette manière que sont codés la plupart des applications sous KDE, ne serait-ce que parce que Qt est conçu dans cette optique précise.

L'habileté d'un programmeur ne se situe donc pas dans sa capacité à répondre à un schéma préétabli, dans lequel on le forcer d'entrer. Il est très politiquement incorrect en ces temps gouvernés par le seul aspect commercial ("combien de temps pour faire ceci ou cela", avec comme prérequis "le temps, c'est de l'argent") de déclarer cela, mais il ne faut pas oublier que le métier de développeur est celui de l'artisan. On peut tout à fait faire des choses et des bidules correspondant à des exigences précises mais que l'on qualifiera aisément d'usine à gaz tout de même (on en a quelques exemples dans le logiciel libre, et pour ne pas froisser Sophie on se contentera de citer Firefox). Un programme n'est pas une somme de fonctionnalités, c'est un tout, c'est une oeuvre (au sens juridique aussi, un bon indice !), une sculpture numérique, une composition (la musique, cette autre branche artisitque des mathématiques), ou une toile du XIXème (qui se fait par ajout successifs de couleur, par dégrossissement : il n'y a rien de mal à ne pas terminer immdiatement le codage d'une fonction quand cela s'avère nécessaire !) (je précise "XIXème" car je ne voudrais pas que l'on compare mon travail à du Picaso, Miro, ou autre horreur du genre commis le siècle suivant -- et qui se vendent aussi cher que cela aura pris peu de temps à faire, mais n'a pas son siège social à Redmond qui veut !).

Il fut un temps où la mode passa au tout-objet (en tant que méthode technique de développement, cette fois). Dijkstra avait alors déclaré : "Object-oriented programming is an exceptionally bad idea which could only have originated in California." Et pour nous convaincre qu'il n'aurait certainement pas trop aimé la tournure des choses actuelles : "Program testing can be used to show the presence of bugs, but never to show their absence!" Nous sommes toujours orientés dans cette optique, malheureusement.

Que l'on ne s'y trompe pas : le bon sens de la méthode Agile est à suivre (comme tout véritable bon sens), et l'on peut très bien arriver à des conclusions justes (du genre "on livre un programme qui marche, et dans les temps" -- qui est d'ailleurs aussi pris en hypothèse, méthode de raisonnement habituellement chère à la chimie, cette branche obscure de la cuisine) à partir d'hypothèses fausses ("la programmation n'est pas de l'artisanat et soumise à des méthodes fixes", ou autre), avec un raisonnement juste (table de vérité par ici). C'est incroyable, mais le "Release early, release often. And listen to your customers." ressemble très fortement à "Customer satisfaction by rapid, continuous delivery of useful software". Eh oui, le modèle du logiciel libre se fait pomper ! C'est peut-être parce que le logiciel libre marche extrêmement bien, non ? (dans une SSLL, ce serait un comble que de devoir convaincre son lectorat :)  ) Et que donc la méthode appliquée est certainement la meilleure qui soit ! C'est moins vendeur, c'est certain : du bazar  :). On pourrait peut-être renommer ça en "recuit simulé" ? (ah non, c'est déjà pris)

Allez, gardons le dernier mot pour feu notre Grand Gourou Dijkstra (dont il faudrait presque citer l'intégralité) :

The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus.


update (30/10): après discussion avec Yannick, je suis totalement convaincu du bien fondé de la méthode (surtout qu'il existe à présent de vrais outils pour la mettre en place et coordonner, contrairement à ce que j'avais vécu il y a plusieurs années), même si je reste toujours sceptique vis-à-vis d'un gros développement en C, surtout embarqué/système. Mais je suis totalement ouvert à la méthode Agile en tant que gestion de projet, hors eXtreme Programming on l'aura compris  :). Ayant pu depuis tester le talent de son plus ardant défenseur à Linagora, je m'avouerais même fort intéressé : c'est bien connu, il n'y a que les imbéciles qui ne changent pas d'avis ! :)  ("cette pirouette rhétorique vous a été offerte par...")

vendredi, août 29 2008

J-TAG sur carte Embest SBC244*

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...).


notre kit de dev



la carte Embest


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).


la mini-sonde JTAG sur USB



l'adaptateur maison : maniement du fer à souder requis !

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...).

Le wiggler, cette brave bête incomprise

É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  :).

jeudi, juillet 24 2008

choisir son file system

Je range ce billet dans la catégorie "Linux embarqué" même si cela concernait plutôt "Linux" tout court à la base : en effet, me rendant hier dans un magasin à l'enseigne au nom de corsaire (mais de pirate, la nuance est d'importance par les temps qui courent), j'ai pu regarder les entrailles d'un Acer One exposé (faute de pouvoir en acheter un : la bestiole a eu tellement de succès que la rupture de stock ne s'est pas faite attendre, il faudra attendre une semaine avant d'en revoir). Il s'agit donc d'un mini-portable, que l'on nomme à présent "Netbook" ; pas grand chose d'embarqué a priori, mais à y regarder de plus près, il n'y a pas de disque dur mais une mémoire flash. Comme dans l'embarqué.

Un petit coup d'oeil dans /proc/mount (via l'explorateur de fichier, faute de console disponible) montre alors de bien étranges idées. D'abord, la présence d'une partition swap : 1Go réservé en fin de flash. Ciel ! Quelle idée ! Mettre une partition swap sur de la flash, c'est une des question du partiel que je donne à mes étudiants : c'est une très mauvaise idée. En embarqué, on peut déjà justifié ça par le fait que le système doit de toute façon être dimensionné, et donc la RAM doit correspondre à l'usage que l'on fait de l'appareil. Mais avec l'apparition d'éléphants comme Firefox ou OOo, les 512Mo (mon dieu, et dire que j'ai travaillé sur 12Mo...) peuvent ne pas suffirent dès que le multi-tâche est en jeu. Sauf que voilà : des écritures répétées à des endroits spécifiques de la Flash peuvent l'user jusqu'à rupture des secteurs. Souvent, c'est 100.000 cycles, et ceux qui ont fait de la javacard en stockant des données de capteurs en Flash se mordent souvent les doigts assez rapidement dès que les signes de vie commencent à manquer. Pour la peine, quand on sait à quel point les applications suscitées consomment de mémoire, et que l'on imagine quelqu'un switchant d'une appli à l'autre, forçant les échanges RAM-swap en permanence, on sent bien que d'ici quelques années pas bien nombreuses la Flash va tout simplement rendre l'âme, ce qui est dramatique, puisque c'est soudé dans la machine.

Une bonne idée aurait été de copier sur Nokia, et de se servir de la carte SD que l'on peut insérer comme espace de stockage supplémentaire (l'Acer One dispose de deux lecteurs de cartes SD, une d'extension de stockage, l'autre de lecteur de média amovible) avec un petit coup de dd et de mkswap pour monter une partoche de swap dessus, qui au pire si elle fusille des secteurs, sera changeable facilement. Mais il aurait fallu un peu de dev (un jour pour une personne...).

L'autre mauvaise idée d'Acer est d'avoir mis le système sur la même partition par défaut que le home (si mes souvenirs sont bons), et surtout (là j'en suis sûr), le tout sur du ext2. Oui, un système non prévu pour de la flash (derrière un contrôleur ? On espère), et surtout non journalisé. Embêtant pour un système sur batterie (ne tenant que 3h, le miracle de l'Atom n'est pas arrivé -- tant mieux, ça ne rognera pas trop sur le marché de ARM comme ça, moins il y a de x86 et mieux on se porte), qui peut donc lâcher à n'importe quel instant, corrompant alors le système de fichier ! Si l'on suspecte que c'est pour économiser de l'espace disque (dont on ne dispose que 8Go, moins les 1Go de swap), un arrêt brutal n'est clairement pas conseillé... Et pour la peine, j'ai essayé (la mise en veille semble un peu foireuse...), et après un fsck au démarrage (silencieux, pas moyen de virer le frame buffer d'attente), suivi d'un redémarrage (oh, un BIOS, quelle horreur... Oui, le redémarrage est aussi une spécialité complètement inutile de Nokia, soyons bourrin, d'ailleurs ces derniers ont un bug sur le N770 puisqu'il peut arriver que la machine reboote jusqu'à épuisement des batteries), OOo n'a pas pu rattraper la perte de document (il ne trouvait même plus le fichier, qui pourtant n'avait pas changé de place, si quelqu'un sait d'ailleurs comment virer le rattrapage au démarrage de l'application, qui se lance à chaque fois pour échouer autant de fois, ça m'intéresse), une preuve indéniable de la mauvaise idée que cela représente.

Entre JFFS2 ou YAFFS (pour rester RW, même si je recommande toujours d'avoir un coeur de système RO, et les applis supplémentaires à part sur une partition RW, pour une sécurité optimale), ils auraient pu faire un effort. Il y a encore du chemin à parcourir avant que les constructeurs-intrégateurs fassent attention à ce qu'ils bidouillent... (mais ils peuvent faire appel à Linagora, ce n'est pas interdit :)  )

vendredi, juillet 11 2008

J-TAG sous Linux

C'est un peu mon fil rouge ces temps-ci. Une sonde ICE/J-TAG, c'est le bien, c'est même très nécessaire dès que l'on veut toucher à de l'embarqué. Mais c'est toujours un bordel innommable avec les fournisseurs de cartes de dev, et ensuite pour la faire marcher, ça ressemble souvent à de la technique Vaudou (notamment le passage de l'initialisation, savoir parler couramment l'hexadécimal est plus appréciable, à initialiser des registres à la main). Du coup, le non-connaisseur peut rapidement vous regarder étrangement lorsque vous lui expliquez l'inextricable situation dans laquelle vous êtes fourrés, pour des bouts de câbles qui coutent quand même parfois un bras (maintenant, ça dépend de ce que l'on veut, ça part de 500€, pour culminer à quelques dizaines de milliers d'Euros).

Au détour d'une recherche, je tombe sur ces slides de la conférence de Mike Anderson sur l'utilisation du J-Tag sous Linux, et plus largement du debug kernel, donnée au Consumer Electronics Linux Forum (CELF) de Santa Clara. Morceaux choisis :

When the hardware folks say the board works, what does that mean ?
   -> Frequently, it simply means that the magic blue smoke doesn't escape the chips when they powered it up
The assertion that the board works is often based on simulating the board
   -> Errors in the manufacturing process, board layout bugs, bad solder joints, etc. will come into play as you start testing

Having the reference board allows you to test how the board should work for comparison to yours

Les slides sont très didactiques (y compris pour quelqu'un qui n'y connaît pas grand chose), pleines d'humour vis-à-vis de cette relation étrange avec les gars de l'électronique (ces informaticiens ratés :D ) et surtout fort complètes (comment débugger un module au J-TAG, par exemple). A lire !

mardi, juillet 8 2008

était-ce du second degré ?

S'il y a bien une ML qui tend régulièrement vers le grand n'importe quoi, c'est celle d'OpenBSD. Perle de ce matin (échange d'hier en fait) :

Subject: "How to undelete?"

I deleted a directory from an OpenBSD slice from my 2nd HD, and I need
to recover a single file.

I tried : http://myutil.com/2008/1/15/undelete-unrm-for-openbsd-4-2-with-dls
but  failed :

# dls /dev/wd1x > /xxx/xx/undelete.bin
Sector offset supplied is larger than disk image (maximum: 0)

Première réponse :

You use a backup.

UNIX != Windows != OSX

Très utile, n'est-ce pas ? Mais le plus drôle est à venir :

Just open your disk in a hex editor and look for your data, it should be here.

Là, c'est très fort. Finalement, la première réponse n'était pas si mauvaise que ça... Mais notre gars manifestement trouve cette idée plutôt à son goût :

Which hex editor do you advise?
Should I have to umount the partition before?
the partition is 40 GB size on a secondary disk, OpenBSD old slice,
should I need at least such space (/tmp ?) to open it on the hex editor
from my OpenBSD 4.3?

Thanks!

Pour rappel, sous Linux, y'a entre autres (et surtout) Photorec, et c'est plus classe que l'ancêtre debugfs. Attaquer à l'éditeur hexadécimal, c'est tellement du grand n'importe quoi que je ne pense même à avoir à rappeler comment marche la fragmentation... (en revanche, si votre Firefox plante alors que vous écriviez un mail, je vous recommande un grep -a sur /dev/mem, mais c'est pas pareil)

lundi, juillet 7 2008

on a enfin trouvé une utilité à Perl !


Oh le joli cale meuble que voilà !

vendredi, juillet 4 2008

salon RTS 2008

Voici donc que l'ouverture des blogs linagoresques (?) me permet enfin de faire partager mon compte-rendu du salon RTS (comme Real Time System) que j'ai arpenté au tout début d'avril, sur un jour et demi, en compagnie tout d'abord de mon stagiaire Rémy le premier après-midi (pour une conférence sur son sujet de stage, la paravirtualisation avec OKL4), tandis que le lendemain était consacré à une visite des stands et à la conférence sur le libre dans l'embarqué, en compagnie de l'autre stagiaire du pôle embarqué, Johana Bodard.

Le salon du Temps Réel de cette année 2008 était donc de retour à la porte de Versailles après un passage prolongé plusieurs années de suite (deux ou trois) au CNIT ; mais cela ne pouvait pas masquer un très net ralentissement, toujours plus en progression : cette fois, les deux salons Display (affichage numérique) et M2M (Machine to Machine, communication entre matériels distants) étaient totalement fusionnés, alors qu'en 2005, on pouvait voir des imprimantes 3D dans un hall bien séparé. À cela, plusieurs explications comme le coût des stands de plus en plus inabordable, surtout en comparaison des retombées, mais aussi peut-être le fait que le secteur se stabilise, ou plutôt se cristallise. En ce sens, certains acteurs du temps réel comme Dolphin ou Concurrent Computer n'étaient présents qu'à Solutions Linux, et plus à RTS. Une seule enseigne majeure était de retour, Montavista, tandis que beaucoup d'autres ont disparu ou fusionné : Polyspace (vérification formelle de code) a été englobé par Matlab ; Systerel (sécurité et certification) se trouvait sur le stand de Sysgo. Trolltech (venant d'être racheté par Nokia pour sa technologie Qt parfaitement adaptée à l'embarqué), Jungo (et ses piles horribles), ou WindRiver (qui a apporté... un flipper) se trouvaient sur un second mini-stand du revendeur de cartes embarquées Neomore, qui avait oublié d'apporter son produit pas cher pour démo, la gamme Embest.

Les stands n'étaient pas bien folichons non plus : fini les animations chez Ecrin, qui n'a pas même apporté ses cartes VME (le concurrent Gaci était tout simplement absent, pourtant l'année dernière les offres groupées hardware et software fleurissaient), WindRiver ne distribue plus de chocolat (et les sacs distribués à l'entrée sont à l'effigie de SFR/3G+), même Arion a laissé tombé sa démo très visuelle de l'année dernière. Seul Greenhills tire son épingle du jeu : immense stand, présentations interactives de leurs différents produits avec mini-conférence toutes les deux heures, distribution de documentation papier et clé usb (256mo, avec cordon !), le luxe comme à la belle époque, image très dynamique renvoyée que l'on aurait aimé plus voir.

La visite du salon s'est faite en deux temps : lundi après-midi, et jeudi entièrement. Première étape en compagnie de mon stagiaire : conférence paravirtualisation et embarqué, avec présents et dans l'ordre Trango VP, Virtual Logix, puis Greenhills et son IntegrityPC, et enfin Sysgo avec PikeOS. Les premiers sont bien connus de ma personne : j'ai travaillé pour eux, et bien avant l'ingénieur qui a fait une présentation honnête, mais assez peu précise, quant aux mérites techniques de la solution (certains points sont très commerciaux et masquent une réalité plus simple, inversement) ; les seconds peuvent se vanter d'être les premiers à équiper une solution commercialisée "grand public" (comprendre : pour développeurs...), avec le Purple phone, sur base hardware de chez NXP (fork de Philips ; à noter une citation de RTK-e, apparemment le nom de leur noyau interne n'est plus tabou, on se rappelle que j'avais voulu le rajouter à la liste des OS sur wikipedia sans succès il y a deux ans) ; Sysgo fait son chemin, comme ses "camarades" précédents, la recherche de certification EAL de plus haut niveau possible (on parle plutôt de EAL5, voire 6) est dans les tuyaux ; Greenhills attaque fort, en revanche, certifications à gogo, expérience sur IntegrityOS (qui équipe les avions depuis de nombreuses années) oblige, mais si la solution marche par exemple déjà sur de la radio militaire portable, elle n'en reste pas moins réservée à du x86 (avec techno VT/Pacifica) ou PPC (voire PowerQUICC). Idée glanées par-ci par-là pour mon stagiaire (comme l'exécution sans recompilation d'application Linux virtualisée dans une sandbox émulée), qui travaille sur la seule solution majeure non ici présente, et Open Source (licence BSD) : OKL4 d'OK-Labs (base noyau L4).

La seconde conférence intéressante était le jeudi matin, Open Source et embarqué, assistance nombreuse, plus que pour la paravirtualisation, et un rapide coup d'oeil dans les salles d'à côté montre le succès très large de ces deux prestations contrairement à toutes les autres, prouvant de facto où se porte toujours l'intérêt du Consumer Electronic (CE) à l'heure actuelle, puisque l'année dernière c'était la conférence Linux qui remportait le plus de succès, et la partie paravirtualisation le plus d'intérêt porté. Mandriva ouvre le bal avec son PDG, au franc parler et à la fluidité sans pareille, mais au discours assez éloigné de ce que l'on entend trouver à un salon comme RTS ; puis Montavista avait des choses à dire, mais le sympathique orateur avait du mal à s'exprimer, dommage, informations intéressantes en tout cas, quoique non révolutionnaires ; CIO informatique, la sympathique petite boîte du Sud qui ne fait plus que du Linux embarqué (et croûle sous les demandes... à leur échelle), a recentré le débat sur ce qui en est effectivement au coeur, les attentes des industriels, les erreurs à ne pas commettre, l'importance du juridique. Sur ce point, Adacore (je demandais justement l'année dernière à l'un de mes amis comment il se faisait qu'ils n'étaient pas là) se permet de corriger, notamment sur le fait que même condamné après une violation de GPL, il n'y a pas obligation à redistribuer les sources internes ; le point est fin (mais l'exposition à la limite du troll), et la présentation aussi dynamique que commerciale cache les raisons jusqu'à la séance des questions : l'obligation est de faire cesser le litige, c'est-à-dire qu'il reste toujours le choix de retirer le produit et ne rien diffuser, et assumer le coût que cela implique. Il faut relever le grand mérite de cet éclaircissement : une licence libre n'est pas plus ni moins complexe qu'une licence propriétaire (enfin si, elle est souvent plus claire), du moins elle comporte comme toujours des possibilités et des obligations ; prendre ce qui intéresse (gratuité et disponibilité des sources, absence de royalties à la distribution du produit), et ignorer les contre-parties demandées (redistribuer les sources GPL avec les binaires par exemple) est équivalent à pirater n'importe quel logiciel propriétaire, ni plus ni moins ; et si l'on n'est pas content, il n'y a qu'à voir ailleurs, le monde est assez vaste. J'applaudis des deux mains cette position, que j'exposerai encore plus précisément et avec appui à mes élèves, qui prennent la question beaucoup trop à la légère (et pourtant avais-je déjà bien insisté), comme tous les ingénieurs déjà en poste, dont le hobby principal est de se tirer des balles dans le pieds.

Sur les stands, on peut voir une démonstration impressionnante d'un outil de débug par génération automatisée de test cases unitaires dans la suite Rational d'IBM (l'outil provient en réalité d'un rachat d'une société Française, tandis que le reste de la suite, de Lotus à Clearcase, est toujours aussi moche). Dspace montre quelque chose de similaire dans l'idée, mais pour Matlab. Ces derniers ont enfin une vraie version Linux potable, et Simulink marche aussi, enfin, il n'y a rien pour le prouver sur le stand. Anticyp et Neomore sont les seuls vendeurs de cartes à base ARM ou xscale. WindRiver (qui nous parle du dernier Intel consommant 4W, mais dont la carte de dev comporte un ventilo, paraît-il vraiment inutile) ne fait plus la publicité de Linux à grands coups de pingouins, mais Sysgo non plus, alors que cela reste leur principal produit d'appel ; d'ailleurs le système de navigation de BMW (contenu dans la radio, chip PPC) a migré sous Linux récemment, et est déjà commercialisé ; les autres produits chez les différents constructeurs, toujours sous VxWorks, devraient suivre (depuis, on l'a vu, c'est le chemin de la paravirtualisation qui a été choisi par WindRiver). Trolltech a fait venir deux Français de Norvège faire la promotion de Qt for Embedded, nouveau nom de la branche Qtopia sans le support téléphone (mais présenté sur... des téléphones Neo en place d'OpenMoko, Milo de Sony toujours sous Linux, et HTC sur WinCE), et distribuait les goodies aux gens sympas tels que nous (du chauffe-tasse usb à la house pour portable). Très intéressantes discussions, surtout que notre deuxième stagiaire du pôle embarqué (une fille, en plus ! ;)  ) travaille (ou veille technologiquement) sur OpenMoko, Android, et la téléphonie mobile sous Linux en général. Et en se promenant entre les stands, le logiciel libre d'émulation qemu a très clairement le vent en poupe, impressionnant lorsque l'on connaît ses conditions de développement !

Cela contredit tout de même quelqu'avis de professionel des coprocesseur et ancien professeur (trolleur dans l'âme, à vrai dire) nous affirmant sur son stand que Linux, bien du monde en était revenu ; non pas qu'il soit en faveur de WinCE (complètement disparu, cette fois, juste une ou deux mentions sur l'ensemble des stands, l'époque de l'espace de formation gratuite dédié est manifestement révolu), mais c'est que sa vision du Temps Réel (et a fortiori de l'embarqué, qu'il assimile facilement, tandis que sa distinction "temps contraint" va même englober des applications pourtant critiques du militaire...) se limite à ce qui est "pur et dur", et comporte au finalement l'automobile (côté calculateur de bord), l'avionique, le spatial, et les communications ou calculs particuliers en interne aux industries, soient effectivement des milieux où Linux était pressenti sans que l'on sache trop pourquoi, et dont le retour à la raison n'est pas si étonnant. Ignorés sont de sa personne toutes les problématiques du CE : modems, routeurs, téléphones, etc. "Que ça"...

En réalité, Linux est entré dans le paysage, on ne se pose plus trop de questions à son sujet, il s'agit d'une solution tout à fait envisageable, parmi d'autres. Plus de folie ambiante, il semble au moins que sur ce point, la raison soit de rigueur. Reste à savoir le pourquoi exact de ce sentiment mitigé. La proximité avec les salons de bien plus grande envergure comme Barcelone (GSM) ou le CES de Las Vegas ne doit pas y être pour rien, RTS n'a décidément pas encore bien pris le tournant CE, ce que l'on peut d'ailleurs remarquer au niveau de nos grandes entreprises françaises (Sagem, Thales, et... heu...), qui peinent à se recycler et sortir d'un milieu purement industriel qui ne rapporte plus rien (vive les salaires dans le spatial, à Toulouse : division par 5 à 10 du facteur temps nécessaire à l'évolution du traitement). Reste des problèmes d'engorgement et de tâtonnement, toujours, sur ce sujet ; c'est ici que pourrait se jouer la bataille, et notamment la prise de positions stratégiques dans le milieu de l'embarqué sous Linux. En espérant que Linagora s'engouffre dans la brêche :).

Toute la documentation glanée est disponible à mon bureau (ou plutôt en dessous), dans le grand sac rouge. On peut se prendre à rêver aussi d'une participation un jour de Linagora en tant qu'éditeur (ou simple intégrateur) de solutions Linux embarqué innovantes, et pourquoi pas, montrer notre savoir faire et notre envie de se positionner sur ce marché, en compagnie des acteurs OpenSource déjà implantés (Trolltech, Sysgo, CIO informatique, AdaCore, Montavista étaient tout de même bien présents), qui finalement se complètent tous plus qu'ils ne se concurrencent réellement, alors que la demande ne cesse d'augmenter, mais plus discrètement qu'avant, et surtout, de manière toujours aussi désorganisée, à l'image de ceux pouvant y répondre, lorsqu'on y pense. A présent que l'on a le bazar, il serait de bon ton de construire une cathédrale  :).

retours d'expérience positifs sur la migration des députés

L'ami Bertrand Lemaire a interviewé trois députés (choisis comment ?) pour le compte de CIO Onlines, et les retours sont plutôt très positifs ! Trois positifs sur trois interrogés, qui reflètent le ressenti général , apparemment (j'essaierai de questionner quelques assistants parlementaires de ma connaissance, pour confirmation). L'APRIL a écrit une retranscription complète. On peut regretter que le nom de Linagora ne soit pas cité, tout de même ; un p'tit effort de com' à faire ?

jeudi, juillet 3 2008

mini-conf

J'ai décidé de monter le google rank de ce blog pour la recherche "linux embarqué" au plus haut niveau  :). Je ne suis déjà à titre personnel pas trop loin, puisque ma conférence de janvier dernier pour Parinux est franchement très bien classée en 4ème position. Reste à battre les habituels Ficheux (enfin, Eyrolles pour être exact) et autres Kadionik (qui blogue aussi), mais ça ne devrait pas prendre trop de temps, en renommant cette section "linux embarqué", par exemple  ;).

Voici donc les slides de ma conférence, annoncée en son temps sur linuxfr, et en bonus, les mêmes slides en version keynote plus jolie. Bonne lecture !

WindRiver paravirtualise

Certains le savent peut-être déjà, mais le sujet de la paravirtualisation me tient tellement à coeur, que j'ai même un gentil-stagiaire qui ne s'occupe que de ça, sur le projet libre OKL4. WindRiver, on ne les présente plus. Enfin, peut-être que si, si l'on ne connaît pas du tout le monde merveilleux de l'informatique industrielle : en une quinzaine d'années à peine, ces gens ont tout révolutionner grâce à leur OS (c'est vite dit... kernel, plutôt) temps réel dur (et même très dur) VxWorks, aux temps de latence exceptionnels, à tel point que le marché est dominé par eux depuis. Sentant le vent tourner depuis quelques temps, ils se sont mis à Linux il y a environ quatre ans, et leur solution commerciale RTCore propose depuis environ un an à présent une technologie Linux vanilla ou Linux temps réel hérité de RTLinux de FSMLabs, qui a été racheté (et sui sont des vilains, parce qu'ils ont breveté leur système qui consiste à faire fonctionner le kernel par dessus l'ordonnanceur).

WindRiver se met donc à la paravirtualisation. Temps-Réel, évidemment, on ne parle pas de bousin du genre Xen ou VMware, ici le code fait dans les 10 à 20000 lignes (on annonce 5 à 10 pour notre cas, ce qui indique qu'il ne doit pas y avoir beaucoup de features...), et il est vérifié et re-vérifié pour répondre à des critères élevés de stabilité et sécurité (même s'il est possible parfois de patcher, dans l'embarqué : on se souvient du robot envoyé sur Mars et victime d'une inversion de priorité... sous VxWorks justement).

Le marché est toujours très porteur (dans l'avenir ?), et pour preuve encore l'exemple typique qui nous est annoncé dans la dépêche de linuxdevices (la Bible) : on parle de PPC et de CAN. Que l'on ne s'y trompe pas : la cible (on l'élude gentiment dans l'article, mais ne soyons pas dupe) est l'automobile, et plus exactement tout ce qui va être géré par le microcontrolleur en charge des actions "multimédias". Tout se passe dans... l'autoradio ! Nous avons un PowerPC, qui à la base ne devait servir qu'à diffuser ses chaînes préférées (mais un 68k suffit pour faire ça !), et qui a pris en charge naturellement l'affichage de bord "utilisateur" (la température, l'horloge, etc -- pas le niveau d'essence, évidemment), puis le GPS, et qui va vers du multi-fonctions de plus en plus (on peut penser à de la diffusion de contenu vidéo sur les sièges passagers). Outre le processeur PPC, qui peut paraître un choix saugrenu si je n'avais pas déjà rencontré sur un salon ce type d'application, sur le stand de WindRiver, l'interfaçage avec le protocole de communication réseau CAN (qui est bidon, donc utilisé partout), typique de l'automobile, nous trahit complètement le but de l'opération.

Le but en effet est de faire tourner simultanément VxWorks et Linux. Car il faut faire un choix, sinon : mettre l'historique VxWoks et toutes ses applis durement codées dessus, mais qui ne peut pas bien évoluer vers des applicatifs complexes, ou mettre du Linux tout neuf qui sait faire plein de choses, mais manque d'applicatifs métiers (outre l'aspect temps réel à réétudier). Jusqu'ici, c'était dur : pour gagner de l'argent, on préférait payer l'horrible licence avec royalties de VxWorks plutôt que de payer un dev complet sous Linux, quitte à sacrifier des fonctionnalités ; mais sous la dernière BMW de la mort qui tue, c'était du Linux (parce que de toute façon, vu le prix de la bagnole, on n'est plus à ça près...). A présent, plus la peine de se poser des questions métaphysiques : on peut mettre les deux, et utiliser la puissance de l'existant et de la nouveauté évolutive simultanément. Au passage, WindRiver vend deux produits au lieu d'un, sont pas fous. Et tout le monde est content.

Petite anecdote pour finir : la (para)virtualisation VxWoks/Linux existait déjà du temps de la... livebox ! Et oui, mais bon, c'était pas très beau à voir, je n'en dirai pas plus  :)  (apparemment, les linablogs sont publics) (indice quand même : mmuberk).

jeudi, juin 26 2008

First time

Mais pas first timer pour autant (chouette, l'ami dotclear, y'a vraiment des gens bizarres qui utilisent wordpress ?). Peu importe, lancement de mon nouveau blog à la mode. Mais c'est qu'on ne m'avait rien dit ! On fait des barcamps où ça ne parle pas technique (au secours !! :) ), ça décide des trucs hyper-chouettes (une plate-forme de blogs ? Un planet ? Pas tout compris à ce niveau, j'espère qu'on pourra m'éclairer, je n'ai pas trouvé non plus des archives correctes remontant à plus d'un mois), et.... bah comment ça se fait qu'on n'est pas au courant, par ici ? (je veux dire : au fin fond du couloir, à gauche, au fond encore)

Du coup, je ne sais même pas si les écrits sont publics, s'il y a une ligne éditoriale, rien rien rien (mis à part que j'ai accepté des conditions d'utilisation qui se résumaient à.... "conditions d'utilisation", me voilà bien avancé). Je ne sais pas si je peux insulter un client psychédélique (mais nooooon, ça n'existe pas voyons), si je peux parler de mon chat (ouf, j'en ai pas), ou juste traiter de la migration des manchots (libres, s'entend). On essaiera de donc de faire quelque chose de sympa et geeky -- pour être super-original.

J'ai donc pondu quatre catégories au pif : "Linagora", qui traitera de la boîte en général ; "linux", qui parlera manchot (parce que les démons de toute façon, c'est le mal) ; "bons plans", qui pourra renseigner par exemple sur les sorties culturelles à ne pas manquer (sous peine de devenir plus bête, ou de le rester, au choix) ; et finalement, "nawak", soit le garbage collector de service (on pourra y parler de démon, donc, rien n'est perdu !). A voir si d'autres catégories plus générales ("informatique", "libre", que sais-je) ne seront pas crées plus tard.

On l'aura compris peut-être déjà plus haut, ici, ça trollera. Parce que c'est le bien. Des études scientifiques ont montré les bienfaits du troll sur le fonctionnement naturel de l'organisme, c'est comme le bifidus actif, ça vide (hum, le bon goût sera aussi optionnel). Sauf si les conditions d'utilisation l'interdise, auquel cas la censure sera impitoyable, et toute personne disant du bien d'Ubuntu, de BSD, de Solaris, ou du mal de SuSE sera châtié et réduite au silence. Qui a parlé d'informatique ''libre'' ? :)

page 5 de 5 -