Embedded weblog

Hier soir, Basile Starynkevitch (j'arrive à écrire son nom d'une seule traite maintenant ! :)  ) nous a présenté GCC, ou du moins sa partie propre à la compilation (nous n'avons donc pas abordé (ld, objcopy ou gdb, par exemple : nous n'avions qu'une heure trente !), dans le cadre d'une conférence libre pour Parinux (et l'APRIL aussi, si l'on veut). L'organisation, tant sociale que technique du projet, a été au coeur de cette descente dans les entrailles du compilateur libre le plus célèbre. Et ce qui tombe bien, c'est que Basile est passionné par la même chose que nous : l'embarqué !

J'insiste souvent dans mes slides de cours ou de conférence sur le fait que GCC est le pendant sous-estimé de "Linux Embarqué" : non seulement ce logiciel libre sous copyright de la FSF et de facto sous GPLv3 est utilisé dans tous les projets Linux existant (je ne vois pas quel projet ne le ferait pas, on peut supposer que ça existe, mais j'attends de voir...), mais en plus il fait partie intégrante depuis des années des SDK d'OS temps réels bien propriétaires, tel celui de VxWorks ! De fait, GCC n'étant soumis à aucune licence restrictive, on l'utilise partout au moins pour faire des tests. Aussi, si l'on a un compilateur propriétaire sur un projet (RVDS, ObjectAda, Intel Compiler, etc), la licence étant restrictive à un certain nombre d'utilisateurs, on voit les développeurs utiliser GCC en temps de développement, et n'utiliser que le compilateur propriétaire pour le logiciel à réellement embarqué.

Et encore : le compilateur propriétaire est une espèce en voie d'extinction. Qui a entendu récemment parler des compilos de Thomson ou de ST ? Avant, la mode était de créer un CPU et son compilateur associé ; avec le resserrement de l'offre des architectures (certaines puces Thomson ont disparu depuis quelques années, et le CNES fait appel à ses réserves pour équiper ses satellites !), et l'omni-présence de GCC grâce à son organisation permettant d'attaquer toutes sortes de matériels, il n'est plus rentable d'investir dans des compilateurs fermés. Pis encore : il est absolument évident qu'un "méta"-compilateur tel que GCC, capable d'avaler bien des langages, de compiler ou cross-compiler pour bien des architectures, avec une modularité, des options et des extensions de langage à un niveau jamais atteint ne sera jamais plus dépassé. Microsoft est encore le seul à lutter (et pourquoi pas Borland ?), mais il n'y a qu'à compiler du C++ un peu complexe pour se rendre compte que l'on est loin du niveau de GCC.

De fait, les équipes d'Intel ou AMD sont investies dans le projet, à présent. La collaboration de ces entreprises pourtant  concurrentes par nature est même exemplaire. Mais le succès de GCC serait encore bien supérieur à ce que j'imaginais. On m'a parlé de versions certifiées, en DO-178B, que ça, et un membre du public (ingénieur en informatique embarquée dans une grande société concernée) m'a même assuré que du code sur la ligne 13 était compilé par GCC (cependant, est-ce le navigateur ou les freins, ou est-ce l'éclairage clignotant de la loupiotte à l'approche d'une station ? Ce n'est pas pareil ! Dans l'absolu, il y a du code compilé par GCC dans les avions, il y a même du Linux dans les derniers, mais c'est pour du multimédia : quid du navigateur de bord ? Je doute toujours). J'essaierai de faire parler des contacts, mais ce n'est pas facile : la complexité des solutions actuelles, de leur organisation logistique, et le mutisme du milieu industriel, empêchent d'avoir une visibilité fiable et globale des utilisations des logiciels libres en général, et la question du compilateur employé reste définitivement délicate.

J'espère que les slides seront bientôt disponibles, la conférence était très intéressantes, et il semblerait qu'elle peut-être eu plus de succès que la mienne (cependant, je doute un peu, on va dire ex-aequo :)   ). Le sujet était pourtant fortement technique a priori, et les digressions dans les HIR et MIR internes à GCC en ont perdu quelques uns, qui ont tout de même été ravis d'en apprendre autant. Pour ma part, j'étais ravi de retrouver une application de mes vieux cours de compil (on sait qu'à l'EPITA le sujet majeur de première année est la conception d'un compilateur Tiger). A ce propos, j'ai partagé ma consternation avec Basile d'apprendre que les 4 millions de lignes de code de GCC sont écrites en C majoritairement (un peu de C++, ou de langages qui en génère comme celui de notre conférencier), et pas en Caml, ce qui aurait pu au moins diviser le nombre de lignes nécessaires par 100, sans compter la visibilité ; s'il est vrai que l'auto-compilation de GCC par lui-même est l'un des meilleurs tests qui soit, se serait en réalité une question de culture américaine de formation universitaire à la base de ce (non-)choix technique : dommage.

Terminons sur un mot très positif : GDB dans sa prochaine version aura la possibilité d'intégrer des scripts Python, de telle sorte que ce ne sera plus la peine de lutter avec des copies de lignes de commande pour mettre en place des registres, ou de mettre ses breaks à la main avant de les retirer pour les décaler etc (on se rappelle qu'avec un J-TAG, on n'a droit qu'à deux breakpoints/watchpoints hardware !), ou encore d'arrêter le code, dumper les registres et la pile, faire un step, etc, à la main, ce qui est très fastidieux pour le moment. On peut même rêver dès à présent à un équivalent de Time Machine de Greenhills, c'est-à-dire d'avoir la possibilité de jouer un retour en arrière dans l'exécution du code. Et ça, se serait une très grande nouvelle ! (qui ferait économiser 20.000€, hum... Mais il va falloir du temps)

Remercions encore une fois Basile Starynkevitch pour sa fort bonne prestation, et sa bonne humeur naturelle.

On voit cela comme une grande nouvelle : une boîte déclare qu'il n'y a pas besoin d'antivirus pour Android. Il faut dire qu'une autre entreprise jouait déjà du FUD pour proposer sa propre solution de sécurité. Décidément, on vit dans un monde infecté par le Desktop et l'ignorance qui va avec (surtout pour les utilisateurs windowsiens, formés à l'assainissement régulier d'OS). Tout d'abord, tordons le cou à une assertion débile du second acteur sécuritaire : l'OpenSource impliquerait l'apparition de virus, théorie fort chère à Microsoft (la sécurité est impliquée uniquement par l'obscurantisme du code, il n'y a qu'à considérer leurs produits pour s'en convaincre), dont on peut évidemment vérifier la vérité tous les jours à l'aide de son Linux ou de son BSD. Très sérieusement : c'est n'importe quoi. Et du côté des obscurs, on ira voir RIM (qui ne cache pas certaines failles alarmantes du passé), ou on se penchera sur la réponse d'Apple et de son système de signature d'applications autorisées qui a rapidement été outrepassé.

Analysons objectivement la sécurité des systèmes embarqués : c'est effectivement un soucis qu'il faut prendre au sérieux, j'en parle d'ailleurs dans les cours que je dispense. En informatique, rien n'est magique, il faut donc déjà passer outre les images d'Epinal de "bestioles" rampantes qui s'incrustent dans les appareils et les rendent fou, ou en tirent des informations secrètes (on admet que par "virus" on désigne un peu tout ce qui concerne les failles de sécurité, notamment -- et surtout -- les vers). Déjà, pour les appareils communicants (ce ne sont que ceux-là qui sont concernés, sinon comment s'introduire ?), il faut déjà filtrer les entrées et les sorties : firewall, chiffrage, voire analyse de détection sur des données manifestement mal formattées (les réseaux GSM de SFR limitent par exemple de façon tout à fait arbitraire la taille des URL). Ensuite, il ne faut pas écarter l'apparition de code malveillant, et ici il faut se pencher sur la seule et unique question : comment fait-il pour s'exécuter, et quelle réponse y apporter ?

Plusieurs cas. On peut faire du buffer overflow avec des données corrompues : il suffit de protéger la pile, des solutions comme PaX font cela très bien, en marquant les zones hors piles comme non exécutables. Il y a aussi l'option -fstack-protector-all de GCC, qui met en place des canaris : comme dans les mines où les volatiles jaunes révélaient la présence de gaz en mourant et donc en arrêtant de piailler, la technique consiste à mettre aux extrémités de la pile d'exécution des bouts de données qui, si elles sont écrasées (par un shellcode, au hasard), provoquent l'arrêt immédiat du programme. Et cela sans compter que Android est basé sur du Java, ce qui constitue déjà en soi une boîte à sable pouvant se révéler très efficace (pour avoir programmé en J2ME en 2004 sur téléphone portable, je peux même assurer que l'accès aux données physiques est fortement contrôlé, mais effectivement on peut de plus en plus accéder à des fonctionalités du téléphone, afin d'être plus user-friendly).

On peut ensuite avoir tout simplement un programme tiers téléchargé et exécuté à la main, par l'utilisateur. A ce niveau, il faut évidemment responsabiliser l'utilisateur (ne pas exécuter cette application manifestement malveillante). Notons que l'argument consistant à évoquer la multplicité des OS sur plate-formes mobiles n'est pas recevable, puisqu'accéder au répertoire téléphonique, SMS, ou autres données sensibles de la carte SIM, tout comme le fait de lancer des appels, se fait par commandes AT à un second kernel, très souvent du Nucleus ; et entre Symbian, RIM OS, WinCE/Mobile, Linux et Darwin, on voit mal ce que l'on appelle "grande multiplicité" (surtout que Symbian est toujours majoritaire). Dans tous les cas, éviter de lancer un programme en root, sandboxer (en Java, c'est quasiment natif), filtrer des commandes interdites (ce que fait nativement un BSD avec jail, en somme), et déjà je souhaite une grande chance aux pirates pour s'en sortir.

Il y a en outre la possibilité, pour les appareils communicants, de se mettre à jour. Il faut bien faire attention à la procédure (notamment il faut doubler les OS présents : l'un, très minimal, doit toujours être présent au cas où la mise à jour aurait échoué, afin de pouvoir la reprendre), mais tous les appareils modernes supporte ce genre de fonctionnalité. Cependant, mettre à jour le noyau lui-même peu s'avérer très périlleux, si ce n'est impossible. En effet, pour des raisons pratiques mais aussi de de sécurité, le noyau Linux est placé "en dur", en dehors de tout file system, dans le firmware : c'est une pratique extrêmement courante qui a énormément d'avantages. Le problème est que son remplacement n'est alors pas si aisé, voire inenvisageable. J'ai travaillé, il y a plus d'un an, sur une solution avec un noyau qui s'est avéré six mois plus tard être frappé de la faille sur la mémoire virtuelle qui permet de prendre les droits "kernel" (plus que root, on se retrouve en kernel land) ; pourtant, j'ai continé à bien dormir (sachant que c'est une solution dont le marché prévu recoupait des choses aussi diverses que la gestion de terminaux bancaires).

Car il existe une excellente solution de protection pour Linux : RSBAC. Je vous laisse découvrir la chose, la première fois que l'on se fait jeter d'un "su" alors que l'on est root est une expérience étrange. La faille est donc peut-être présente, mais le mode opératoire pour arriver à en profiter est totalement hors de portée. De même, les solutions de paravirtualisation embarquée sont là pour répondre à cette problématique : un OS se charge de ce qui est sensible, et l'autre de ce qui est pour "le fun" ; l'imperméabilité totale est assurée au niveau électronique, la communication se fait par des canaux très définis, limités et filtrés, et en cas de problème sur le second OS, le premier n'est pas atteint.

Bref, pour peu que l'on réfléchisse avant, des solutions libres pour une parfaite sécurité dans l'embarqué existent, et ne sont pas bien difficile à mettre en oeuvre (l'option de stack protector de GCC n'est pas activée par défaut dans OpenEmbedded, et certains programmes compilent mal avec, mais c'est juste une question de jours pour résoudre les divers problèmes, quant à RSBAC il faut bien le configurer, et une option de démarrage est là pour se mettre en "mode apprentissage automatique"). J'ose croire que les concepteurs de téléphonie mobile (et j'y ai quelque peu travaillé, je peux donc assurer qu'ils ont très paranoïaques) prennent le problème très au sérieux. Et même, que ce que l'on reproche à RIM et son Blackberry, à savoir le manque de transparence sur le trasit des données, ne pourrait être reproché à une solution libre. Les clients de Linagora, qui font le choix de Linux ou BSD pour des opérations très sensibles, pourront sans doute aucun confirmer.

Suite de nos aventures avec la carte chinoise faisant figurer le S3C2440. Ce fut long et laborieux (surtout à essayer de trouver du temps pour les tests), mais ça boote ! Et avec des logs consoles en ASCII, aussi (la précision a son importance), et un driver de carte réseau qui marche... Il n'y a peut-être pas encore tout de fonctionnel, mais en tout cas on a une console et des programmes qui tournent à la fin, c'est déjà beaucoup quand on sait d'où l'on part à la base (au début, il n'y avait rien...). Notamment une traversée des sites tous chinois, coréens et quelques uns japonais, expliquant plus ou moins comment faire marcher le bestiaux, avec une traduction google très approximative (voire franchement comique), et en réalité, il s'agit plus de la bidouille que de la vraies explications sur les problèmes rencontrés. En ayant eu marre de ramer dans ces sites-là (qu'il faut tout de même remercier, mais c'est dingue, n'y-a-til donc personne parlant Anglais ou Français et pouvant faire le même boulot ?), je me suis finalement attelé tout seul comme un grand au code noyau de A à Z, depuis l'init (problèmes de boot, il faut trouver la bonne config, puis de décompression, trouver la bonne adresse) jusqu'à celui des drivers, en passant par la console qui crachait n'importe quoi. J'ai donc tout d'abord essayé de porter un uClinux, mais ça ne marche pas ; je suis donc reparti avec le même code du 2.6.25 avec MMU, et j'ai vérifié que ce que j'ai écrit dans la suite de ce billet marche bien pour un 2.6.27 (j'ai bidouillé tellement de choses dans le kernel que même les logs font peur à voir  :)   ).

Tout d'abord, la compilation : on ne trouve aucun .config correct sur le Net, voici donc configuration kernel pour carte Embest2440. Comme vous le verrez, j'avais décidé de partir sur un uClinux, mais manifestement l'initialisation de la mémoire se vautre lamentablement (outre un bug impliqué par le numéro de machine écrasé, cf plus tard). Donc retour à l'utilisation normale de la MMU (en réalité, sur ARM, il n'est pas possible de se passer du coproc' P15, d'après une thèse lyonnaise de normal sup' que j'ai trouvée : la MMU est donc initialisée à l'identité, ie  @phys = @log ).

Première étape : compilation du kernel Linux. Avec le .config fourni, le kernel devrait faire à peine plus d'1,3Mo. Les flags de debug sont activés, le kernel avec symboles (environ 50Mo) se trouve à la racine ./S3C2440/linux-2.6.25/vmlinux.

make ARCH=arm xconfig
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage

Notez bien la ligne de commande :

root=/dev/nfs nfsroot=192.168.1.1:/home/gblanc/S3C2440/root_default ip=192.168.1.2:192.168.1.1::255.255.255.0:Linagora_board::none ro init=/linuxrc console=ttySAC0,115200

Ici on boote en NFS en utilisant l'IP 192.168.1.2, le serveur étant à l'IP 192.168.1.1, pour le reste, configuration standard. Avec ceci, vous risquez de voir apparaître beaucoup de garbage sur le minicom, même en réglant bien convenablement les options (qui sont celles par défaut, en fait) : c'est un problème de clock pour la carte SMDK2440 (censée être compatible avec la carte Embest, je commence à penser qu'il vaut peut-être mieux créer une nouvelle archi par copie avec un nouveau numéro... D'ailleurs un "find . -name '*sbc*'" sur le kernel fourni par Embest montre qu'ils ont patché dans tous les sens), il faut la passer en 12Mhz (c'est fait convenablement pour quasiment tous les IDs de machines similaires, mais pas pour la SMDK, or notre carte Embest est en 12Mhz). Dans le fichier arch/arm/mach-s3c2440/mach-smdk2440.c, replacer comme suit :

static void __init smdk2440_map_io(void)
{
        s3c24xx_init_io(smdk2440_iodesc, ARRAY_SIZE(smdk2440_iodesc));
//      s3c24xx_init_clocks(16934400);
        s3c24xx_init_clocks(12000000);
        s3c24xx_init_uarts(smdk2440_uartcfgs, ARRAY_SIZE(smdk2440_uartcfgs));
}

Ca devrait aller mieux tout à coup (on remarque aussi que s3c24xx_init_clocks appelé avec "0" met l'horloge à la valeur par défaut, qui est... 12*1000*1000). Reste le problème de la carte réseau, la CS8900. Un driver est fourni avec la carte, mais pour le noyau 2.6.13 : depuis, tellement d'eau a coulé sous les ponts qu'il n'est pas aisé de faire un portage. Et une fois fait, le nombre de bugs et autres Oops à débugger est assez scandaleux (je dirais même que l'architecture du chargement des drivers réseau a franchement changé, il faut réécrire l'init, remettre la section privée de la structure device au bon endroit, etc). En réalité, il y a un driver générique pour les cartes Cirrus qui a été écrit, depuis : CS89x0. Sauf qu'il n'est pas activé, et pire, pas activable par défaut. Il faut donc patcher le Kconfig qui va bien, et mettre les bonnes adresses de lecture/écriture de registres (sur ports I/O) et initialiser la MMU pour qu'elle pointe au bon endroit, histoire de ne pas Oopser (@phys sur 0x19000000, c'est fichtrement plus lisible dans u-boot que dans Linux pour retrouver cette adresse ! Evidemment, rien dans les doc, sinon regarder dans./include/asm-arm/arch-s3c2410/sbc2440v3-map.h du kernel 2.6.13 fourni par Embest !). Donc tout d'abord, dans drivers/net/Kconfig, aller à la section "Config CS89x0", et rajouter "|| ARCH_S3C2410" (ne faisons pas dans le détail ! Le but est de bypasser la dépendance sur NET_PCI et les cartes associées). Puis dans le code du driver, il va falloir taper sur une adresse logique qui va bien ; celle du code de la carte QT2410 (en 0xE0000300 -- il faut ajouter "300" aux adresses pour taper dans le réseau, ne me demandez pas d'où ça sort, cékomsa) est bien, mais j'ai finalement opté pour celle du vieux driver CS8900 de Embest, à l'adresse 0xD0000000, ce qui marche sur 2.6.25, mais pas sur 2.6.27, je suis donc retourné à la 0xE0000000. Dans arch/arm/mach-s3c2440/mach-smdk2440.c (puisque l'on décide d'adapter la SMDK2440), ajouter dans le tableau smdk2440_iodesc :

static struct map_desc smdk2440_iodesc[] __initdata = {
        /* ISA IO Space map (memory space selected by A24) */

        {
                .virtual        = (u32)S3C24XX_VA_ISA_WORD,
                .pfn            = __phys_to_pfn(S3C2410_CS2),
                .length         = 0x10000,
                .type           = MT_DEVICE,
        }, {
                .virtual        = (u32)S3C24XX_VA_ISA_WORD + 0x10000,
                .pfn            = __phys_to_pfn(S3C2410_CS2 + (1<<24)),
                .length         = SZ_4M,
                .type           = MT_DEVICE,
        }, {
                .virtual        = (u32)S3C24XX_VA_ISA_BYTE,
                .pfn            = __phys_to_pfn(S3C2410_CS2),
                .length         = 0x10000,
                .type           = MT_DEVICE,
        }, {
                .virtual        = (u32)S3C24XX_VA_ISA_BYTE + 0x10000,
                .pfn            = __phys_to_pfn(S3C2410_CS2 + (1<<24)),
                .length         = SZ_4M,
                .type           = MT_DEVICE,
        },
        { 0xE0000000, __phys_to_pfn(S3C2410_CS3+0x01000000), SZ_1M, MT_DEVICE }
};

Ainsi, l'adresse 0x18000000 + 0x01000000 (soit 0x19000000) sera mappée sur 0xE0000000 (avec une taille de SZ_1M, ce qui me semble un peu grand, mais c'est ce qui est "recommandé", alors...). Petit intermède à propos de ce mapping : dans la 2.6.27, on a la macro VMALLOC_END dans arch/arm/mach-s3c2410/include/mach/vmalloc.h (fichier qui n'existe pour 2.6.25) qui vaut 0xE0000000. Or, dans la mise en place des zones de I/O map, on vérifie que l'on n'écrase pas une zone allouée au mallocage : fonction  de /arch/arm/mm/mmu.c, et message "BUG: mapping for 0x19000000 at 0xd0000000 overlaps vmalloc space" si l'on met 0xD0000000 à la place de 0xE0000000.

Dans le même fichier, il faut "enregistrer" le driver réseau comme faisant partie de la configuration matérielle à activer :

static struct platform_device *smdk2440_devices[] __initdata = {
        &s3c_device_usb,
        &s3c_device_lcd,
        &s3c_device_wdt,
        &s3c_device_i2c,
        &s3c_device_iis,
        &s3c_device_cs89x0,
};

Cette structure est à déclarer dans arch/arm/plat-s3c24xx/devs.c (personnellement, j'ai inséré ce code avant la partie propre au 2440 marquée par "#ifdef CONFIG_CPU_S3C2440" autour de la ligne 500) :

/* CS8900 */

static struct resource s3c_cs89x0_resource[] = {
        [0] = {
                .start  = 0x19000000,
                .end    = 0x19000000 + 16,
                .flags  = IORESOURCE_MEM,
        },
        [1] = {
                .start  = IRQ_EINT9,
                .end    = IRQ_EINT9,
                .flags  = IORESOURCE_IRQ,
        },
};

struct platform_device s3c_device_cs89x0 = {
        .name           = "cirrus-cs89x0",
        .num_resources  = ARRAY_SIZE(s3c_cs89x0_resource),
        .resource       = s3c_cs89x0_resource,
};

EXPORT_SYMBOL(s3c_device_cs89x0);

On y trouve l'IRQ qui va bien, l'@ phys à attaquer pour les registres du device aussi (Si vous obtenez en sortie console quelque chose comme "cs89x0: request_region(0xd0000300, 0x10) failed", c'est que votre mapping s'est mal passé, et le driver ne marchera évidemment pas). Pour que l'utilisation du symbole s3c_device_cs89x0 se passe bien, il faut dans include/asm/plat-s3c24xx/devs.h () rajouter une ligne "extern struct platform_device s3c_device_cs89x0;". A présent dans drivers/net/cs89x0.c (le code du driver réseau), ajouter :

#elif defined(CONFIG_ARCH_PNX010X)
// blablabla
#elif defined(CONFIG_ARCH_S3C2410)
#include <asm/arch/irqs.h>  // copie de asm-arm/arch-s3c2410/irqs.h dans 2.6.25 ; attention, dans 2.6.27 se sera <mach/irqs.h> qui pointe vers arch/arm/mach-s3c2410/include/mach/irqs.h ; il faut trouver où est IRQ_EINT9
#include <linux/irq.h>
static unsigned int netcard_portlist [] __initdata = { 0xD0000300, 0 };
static unsigned int cs8900_irq_map[] = { IRQ_EINT9, 0, 0, 0 };
#define NO_EPROM
#else
static unsigned int netcard_portlist[] __used __initdata =
   { 0x300, 0x320, 0x340, 0x360, 0x200, 0x220, 0x240, 0x260, 0x280, 0x2a0, 0x2c0, 0x2e0, 0};
static unsigned int cs8900_irq_map[] = {10,11,12,5};
#endif

On indique donc que le port sera sur l'adresse virtuelle 0xD0000300 (c'est la base, ensuite les additions pour trouver les bons registres de lecture/écriture/contrôle sont toujours les mêmes). On indique aussi l'IRQ (ce sera la 53). Et qu'il n'y a pas d'EEPROM ; sinon il se passera des choses étranges -- de fait, il faudra entrer l'adresse mac à la main (oui, c'est très moche) :

printk(" IRQ %d", dev->irq);

dev->dev_addr[0] = 0x00;
dev->dev_addr[1] = 0x00;
dev->dev_addr[2] = 0xc0;
dev->dev_addr[3] = 0xff;
dev->dev_addr[4] = 0xee;
dev->dev_addr[5] = 0x08;
set_mac_address(dev, dev->dev_addr);

A mettre dans le driver, dans la fonction cs89x0_probe1  (qui fait l'initialisation du device), vers la ligne 930 sur le 2.6.25 (ou 831 pour un 2.6.27), après la section macroïsé par "#ifndef MONO_IRQ_MAP" et avant celle de "#if ALLOW_DMA". A présent, ça arrêtera de Oopser. On peut aussi juste au dessus (aux environs de la ligne 910, 805 sur 2.6.27) mettre en place la bonne méthode d'enregistrement de l'IRQ dans la structure device :

                if (lp->chip_type == CS8900) {
#if defined(CONFIG_MACH_IXDP2351) || defined(CONFIG_ARCH_IXDP2X01) || defined(CONFIG_ARCH_PNX010X) || defined(CONFIG_ARCH_S3C2410)
                        i = cs8900_irq_map[0];
#else

Mais à l'exécution, ça va merder sur l'IRQ, tout de même :

irq 53: nobody cared (try booting with the "irqpoll" option)
[<c0027d68>] (dump_stack+0x0/0x14) from [<c00602a4>] (__report_bad_irq+0x38/0x88)
[<c006026c>] (__report_bad_irq+0x0/0x88) from [<c00605a4>] (note_interrupt+0x2b0/0x308)
 r4:00000000
[<c00602f4>] (note_interrupt+0x0/0x308) from [<c0061380>] (handle_edge_irq+0x11c/0x1a4)
[<c0061264>] (handle_edge_irq+0x0/0x1a4) from [<c0032cd4>] (s3c_irq_demux_extint8+0x98/0xa8)
 r8:00000000 r7:00000001 r6:00000038 r5:c02c0ee8 r4:00000000
[<c0032c3c>] (s3c_irq_demux_extint8+0x0/0xa8) from [<c0023044>] (asm_do_IRQ+0x44/0x60)
[<c0023000>] (asm_do_IRQ+0x0/0x60) from [<c00235f8>] (__irq_svc+0x38/0xb0)
Exception stack(0xc0345e0c to 0xc0345e54)
5e00:                            00000000 fb000000 00000001 00000000 c02c1a80
5e20: 40000013 00000035 c0d223e0 c016811c c0ccb000 c0ccb000 c0345e70 c0345e30
5e40: c0345e54 c006074c c005fda0 a0000013 ffffffff
 r6:00000020 r5:f4000000 r4:ffffffff
[<c005fc00>] (setup_irq+0x0/0x230) from [<c005fed4>] (request_irq+0xa4/0xd0)
 r7:00000000 r6:00000000 r5:00000035 r4:c0d223e0
[<c005fe30>] (request_irq+0x0/0xd0) from [<c0167af8>] (net_open+0xe4/0x4b8)
[<c0167a14>] (net_open+0x0/0x4b8) from [<c01d7abc>] (dev_open+0x84/0xdc)
 r6:00001002 r5:c0ccb02c r4:c0ccb000
[<c01d7a38>] (dev_open+0x0/0xdc) from [<c01d684c>] (dev_change_flags+0xb0/0x178)
 r5:00001003 r4:c0ccb000
[<c01d679c>] (dev_change_flags+0x0/0x178) from [<c001d0a4>] (ip_auto_config+0x168/0xcb8)
 r7:00001002 r6:00000001 r5:c0ccb000 r4:c02f9ecc
[<c001cf3c>] (ip_auto_config+0x0/0xcb8) from [<c000890c>] (kernel_init+0xb8/0x278)
[<c0008854>] (kernel_init+0x0/0x278) from [<c0040524>] (do_exit+0x0/0x620)
handlers:
[<c016811c>] (net_interrupt+0x0/0x3cc)
Disabling IRQ #53

Oui, ça fait peur. Le résultat, c'est que l'on émet bien des paquets sur l'interface réseau, mais à la réception de la réponse, l'IRQ a été désactivé faute d'avoir trouvé un handler correct, et donc le driver n'est pas notifié de l'arrivée des nouveaux paquets : c'est un dialogue de sourds :

eth0: Attempting TP
eth0: 10Base-T (RJ-45) has no cable
eth0: using half-duplex 10Base-T (RJ-45)
cs89x0: net_open() succeeded
IP-Config: Complete:
     device=eth0, addr=192.168.1.2, mask=255.255.255.0, gw=255.255.255.255,
     host=Linagora_board, domain=, nis-domain=(none),
     bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.1
eth0: sent 42 byte packet of type 806
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, IRQ conflict ??
eth0: sent 42 byte packet of type 806
cs89x0: Tx buffer not free!
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, IRQ conflict ??
eth0: sent 42 byte packet of type 806

Il va donc falloir aussi corriger cela. Après avoir bien lutté, il s'avère que c'est la "déclaration" de l'IRQ qui manque, avant son enregistrement comme correspondant au bon handler (via request_irq). Donc dans le fichier ./drivers/net/cs89x0.c, dans la procédure net_open(), on ajoute :

#if !defined(CONFIG_MACH_IXDP2351) && !defined(CONFIG_ARCH_IXDP2X01) && !defined(CONFIG_ARCH_PNX010X) && !defined(CONFIG_ARCH_S3C2410)
                if (((1 << dev->irq) & lp->irq_map) == 0) {
                        printk(KERN_ERR "%s: IRQ %d is not in our map of allowable IRQs, which is %x ",
                               dev->name, dev->irq, lp->irq_map);
                        ret = -EAGAIN;
                        goto bad_out;
                }
#endif

                set_irq_type(dev->irq, IRQ_TYPE_EDGE_RISING);   // IRQT_RISING dans les vieux kernels
/* FIXME: Cirrus' release had this: */
                writereg(dev, PP_BusCTL, readreg(dev, PP_BusCTL)|ENABLE_IRQ );
/* And 2.3.47 had this: */
#if 0
                writereg(dev, PP_BusCTL, ENABLE_IRQ | MEMORY_ON);
#endif
                write_irq(dev, lp->chip_type, dev->irq);
                ret = request_irq(dev->irq, &net_interrupt, 0, dev->name, dev);

Et voilà le travail !  :)  Si vous obtenez ceci (juste avant "Looking up port of RPC 100003/2 on 192.168.1.1"), c'est que vous vous êtes planté quelque part :

eth0: EEPROM is configured for unavailable media
IP-Config: Failed to open eth0
IP-Config: No network devices available.

Par exemple, sur la 2.6.27, ce n'est pas votre faute : la macro NO_EPROM n'existe plus, résultat, c'est la cata, plus rien ne marche. C'est très bête (euphémisme). Après le commentaire "/* First check to see if an EEPROM is attached. */" (ligne ~730), il faut donc insérer :

#ifdef NO_EPROM
        if (1) {
                printk(KERN_NOTICE "cs89x0: No EEPROM ");
                lp->adapter_cnf = A_CNF_10B_T | A_CNF_MEDIA_10B_T;
                lp->auto_neg_cnf = EE_AUTO_NEG_ENABLE | IMM_BIT;
        } else
#endif

Et tout à coup, ça va beaucoup mieux :

eth0: 10Base-T (RJ-45) has no cable
eth0: using half-duplex 10Base-T (RJ-45)
IP-Config: Complete:
     device=eth0, addr=192.168.1.2, mask=255.255.255.0, gw=255.255.255.255,
     host=Linagora_board, domain=, nis-domain=(none),
     bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.1

Il faut bien entendu avoir un serveur NFS correctement configuré, on peut utiliser aussi wireshark pour observer les trames passer (attention au firewall et au contrôle d'accès par wilcard -- ici il n'y en a aucun, c'est la fête, heureusement qu'on est en réseau local entre ami, mais ce sont les joies de l'embarqué, *il faut* ne pas squasher root, et avoir un bon dossier /dev avec devices console, null, zero et random au minimum, en root) :

# cat /etc/exports
/home/gblanc/S3C2440/Linux/rootarm/     (rw,no_root_squash,async,anonuid=0,anongid=0)
/home/gblanc/S3C2440/root_default       (rw,no_root_squash,async,anonuid=0,anongid=0)

Je vous ai fait une archive avec les fichiers modifiés aux bons endroits pour une 2.6.27.4 (pour la 2.6.25, il faudrait trop nettoyer de choses :)   ). Le voici : linux-2.6.27.4-emb2440.tar.gz.

Seconde étape : bien brancher son câble J-TAG Amontec-à-30€, ne pas oublier de monter l'usbfs et d'exécuter openOCD en root (ou de bidouiller son udev), sinon ça démarre mal. Bonne nouvelle : on peut faire ce que l'on veut avec le câble, j'ai même trouvé des gens sur le net qui ont fait marcher le Flash programmer, mais je ne m'en suis pas servi personnellement. En revanche, la limitation pour les breakpoints/watchpoints (qui ne marchent pas super bien, en fait) est de seulement deux, donc dès que l'on veut faire du stepping sous gdb, la limite tombe à un : comment passer son temps à faire des del et des b*0x... pour changer au fur-et-à-mesure de points d'arrêts hardware, dommage. En ce qui concerne le gdb, celui de codesourcery marche convenablement, je n'ai pas compris pourquoi celui de buildroot était buggué (dans l'accès aux registres, ça retourne des erreurs ou fait n'importe quoi), j'ai seulement trouvé que le bug avait été repéré il y a quelques années par... un développeur de codesourcery sur gdb. Bref, démarrons notre OpenOCD avec ce fichier de conf :

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

On remarque une partie "script" avec "init", "reset" et "halt" ; "reset" sert à redémarrer la carte automatiquement quand on lance OpenOCD (ça évite d'appuyer sur le bouton), si l'on veut se brancher à chaud sans redémarrer la carte, il suffit de le commenter (ça marche très bien) ; "halt" met le CPU sur "pause", idem on peut s'en passer si l'on ne veut pas avoir à entrer "continue" sous gdb (on retrouvera plus tard cet état de la carte avec la commande "mon poll"). Puis on lance arm-none-linux-gnueabi-gdb :

target remote localhost:3333
load ./S3C2440/linux-2.6.25/arch/arm/boot/compressed/vmlinux 0x33D50000
set $r0=0
set $r1=362
set $r2=0
set $sp=0x33D50000
set $pc=0x33D50000
set $lr=0x33D50000

Le Linux compressé (vmlinux) peut être charger à l'adresse 0x33D50000, c'est calculé à la louche (sur une base d'un kernel ne dépassant pas les 2Mo et quelques) pour ne pas être en problème de réécrasement de mémoire lorsque le kernel va se décompresser à l'adresse 0x30008000, et pour éviter d'écraser aussi le u-boot en mémoire à l'adresse 0x33F80000, sait-on jamais, il pourrait resservir. Attention : ne pas charger en 0x0, ça boote mais crashe au bout d'un court moment : la mémoire mappée en 0x0 est bien de la RAM, mais c'est normalement le SteppingStone (copie des 4 premiers Kb de la flash NAND en RAM pour booter dessus, faute d'avoir de la flash NOR, cf paragraphes 6 et 5 de la documentation du S3C2440), de telle sorte qu'au bout d'un certain temps toute la mémoire après 0x1000 est remise à 0. Donc avec un uClinux, il ne faut pas utiliser load tel quel, mais bien préciser une adresse de chargement (je me suis bien fait avoir, surtout que ça avait l'air de marcher... jusqu'à ce que ça parte n'importe où en mémoire, et que ça reboote cycliquement tout seul).

Il ne faut pas oublier de mettre les trois premiers registres dans un état que normalement le boot loader devrait gérer, et qui seront recupérés plus tard au démarrage du noyau : r0 doit être à 0 ; r1 doit contenir l'ID de la machine (on récupère ça dans arch/arm/tools/mach-types, SMDK2440 est 1008, s3c2440 est 362, a9m2440 est 698, et QT2410 est 1108, etc) ; r2 doit pointer sur la ligne de commande, le mettre à 0 revient à utiliser celle compilée en dur par l'option CMDLINE. Il n'y a plus qu'à mettre sp, pc et lr (normalement seul sp suffit, mais bon...) pour pointer sur l'adresse mémoire de chargement du noyau compressé, lancer évidemment un minicom à côté, et entrer "c" comme "continue" dans gdb : c'est parti ! Attention : parfois l'initialisation de sp/pc/lr échoue silencieusement (et parfois bruyamment : sp peut s'être transformé en r13), si l'on retombe sur le boot loader après avoir entré "c", il faut faire un ctrl-C et réaffecter les six registres ci-dessus ; ça méritera un coup de debugging du débugger un de ces quatre... (apparemment ça arrive surtout quand on appelle gdb avec un argument -- cf en dessous)

Pour débugger votre noyau, il faut lancer gdb comme suit :

arm-none-linux-gnueabi-gdb ./S3C2440/linux-2.6.25/vmlinux

Il ne faut pas utiliser add-symbol file : c'est malheureusement buggué, les symboles sont décalés au bout d'un certain temps (la commande "file" semble en revanche saine). Attention : ça utilisera les bonnes adresses après chargement de la MMU. On peut s'en rendre compte avec

arm-none-linux-gnueabi-objdump -D vmlinux | less

Tout est calé sur 0xC0008000. Pour débugger Linux avant décompression, on peut en revanche faire appel à :

add-symbol-file ./S3C2440/linux-2.6.25-uc/arch/arm/boot/compressed/vmlinux 0x33D50000

Ca chargera les symboles (ils ne sont pas bien nombreux) avec comme référence notre adresse de chargement du dessus (attention aux doublons, notamment en terme d'initialisation d'UART !). On peut ensuite mettre des break sur les symboles, faire des print, et des disassemble ; pour arrêter le kernel on peut toujours faire Ctrl-C n'importe quand, bien entendu. On peut aussi passer directement des commandes à OpenOCD :

(gdb) mon poll
target state: halted
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x40000053 pc: 0x33d50000
MMU: disabled, D-Cache: enabled, I-Cache: enabled
(gdb) mon reg
(0) r0 (/32): 0x00000000 (dirty: 1, valid: 1)
(1) r1 (/32): 0x0000016a (dirty: 1, valid: 1)
(2) r2 (/32): 0x00000000 (dirty: 1, valid: 1)
//etc//

"mon help" permet de toutes les obtenir. On peut ainsi modifier directement les registres ("mon reg r1 0x0", par exemple), et gérer le coprocesseur P15 (mon arm920t cp15), cependant mes tentatives pour désactiver la MMU et rebooter manuellement sans avoir à réinitialiser la carte (et donc passer par un rechargement du noyau compressé, ce qui prend un peu de temps) se sont soldés par des échecs (la carte est en carafe, impossible de la mettre en état halt). Attention aussi : le "step" de gdb en assembleur n'est parfois pas terrible (il n'exécute pas une instruction), auquel cas il vaut mieux faire appel au step de OpenOCD via "mon step" ; à ce moment-là, seul "mon reg" donne un état correct des registres, "info registers" semble connaître des problèmes de cache/synchronisation lorsqu'on n'utilise pas les routines de gdb, de telles sortes que les valeurs communiquées sont obsolètes.

Sur le noyau 2.6.27, ttySAC0 ne donne rien comme affichage (après le message de décompression du kernel, plus rien ne s'affiche sur le minicom), en fait la console n'est pas initialisée. C'est un bon moyen de voir comment on peut débugger avec notre J-TAG. Après le chargement en mémoire, et avant de lancer le kernel, on récupère l'adresse virtuelle de printk :

> grep " printk$" System.map
c003deac T printk

On met alors un breakpoint dessus dans gdb :

(gdb) b *0xc003deac
Breakpoint 1 at 0xc003deac
(gdb)

Je n'utilise pas la commande file pour charger les fichiers ici : on pourrait le faire, mais en l'occurrence un bug m'en empêche, gdb segfaulte ! (il faudra vraiment débugger le débugger à un moment :)  ) Il faut dire qu'on le pousse là dans ses derniers retranchements. Il n'y a plus qu'à lancer le kernel avec "c". Lorsqu'on arrive sur printk, voici ce que l'on peut faire :

(gdb) c
Continuing.

Breakpoint 1, 0xc003deac in ?? ()
(gdb) printf "%s",$r0
Linux version 2.6.27.4linagora (gblanc@deepblue) (gcc version 4.2.0 20070413 (prerelease) (CodeSourcery Sourcery G++ Lite 2007q1-10)) #4 PREEMPT Wed Oct 29 19:33:38 CET 2008
(gdb) c
Continuing.

Breakpoint 1, 0xc003deac in ?? ()
(gdb) printf "%s",$r0
CPU: %s [%08x] revision %d (ARMv%s), cr=%08lx
(gdb) c
Continuing.

Breakpoint 1, 0xc003deac in ?? ()
(gdb) printf "%s",$r0
Machine: %s
(gdb) printf "%s",$r1
SMDK2440(gdb) c
Continuing.

Ceci s'affiche avant même l'initialisation de la console ! (cf la fonction register_console dans printk.c, pour ça) On peut ainsi voir où l'on en est : en l'occurrence, on trouve que les printk sautent ce qui devrait normalement s'afficher,

Console: colour dummy device 80x30
selected clock c02c9bf0 (pclk) quot 26, calc 117187
console [ttySAC0] enabled

Le "selected clock" et le "enabled" sont absents. Voilà qui est gênant. Un breakpoint sur la fonction strcmp utilisée dans register_console pour trouver la bonne console à activer montre que "ttySAC" n'est jamais testé ! On cherche donc dans notre ancien kernel 2.6.25 comment cela marchait avant, ie où était inscrit en dur la châine de caractère "ttySAC" : on trouve une macro dans./drivers/serial/s3c2410.c  et quelque chose dans ./drivers/serial/Kconfig : regardons dans 2.6.27, la macro n'existe plus, mais on a quelque chose dans le Kconfig. On fait un xconfig et on active : SERIAL_SAMSUNG et SERIAL_SAMSUNG_CONSOLE, ainsi que SERIAL_S3C2440, tous marqués comme "(NEW)". Tadam, ça marche !  :)

Uncompressing Linux..............................................................................................
done, booting the kernel.
Linux version 2.6.27.4linagora (gblanc@deepblue) (gcc version 4.2.0 20070413 (prerelease) (CodeSourcery Sourcery G
++ Lite 2007q1-10)) #14 PREEMPT Thu Oct 30 15:14:11 CET 2008
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
Machine: SMDK2440
Warning: bad configuration page, trying to continue
Memory policy: ECC disabled, Data cache writeback
CPU S3C2440A (id 0x32440001)
S3C244X: core 405.000 MHz, memory 101.250 MHz, peripheral 50.625 MHz
S3C24XX Clocks, (c) 2004 Simtec Electronics
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4064
Kernel command line: root=/dev/nfs nfsroot=192.168.1.1:/home/gblanc/S3C2440/Linux/rootarm ip=192.168.1.2:192.168.1
.1::255.255.255.0:Linagora_board::none rw init=/bin/sh console=ttySAC0,115200
irq: clearing pending ext status 00000200
irq: clearing subpending status 00000002
PID hash table entries: 64 (order: 6, 256 bytes)
timer tcon=00500000, tcnt a4ca, tcfg 00000200,00000000, usec 00001e57
Console: colour dummy device 80x30
console [ttySAC0] enabled
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 16MB = 16MB total
Memory: 13100KB available (2688K code, 277K data, 112K init)
Calibrating delay loop... 201.93 BogoMIPS (lpj=504832)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 288 bytes
NET: Registered protocol family 16
S3C2410 Power Management, (c) 2004 Simtec Electronics
S3C2440: Initialising architecture
S3C2440: IRQ Support
S3C24XX DMA Driver, (c) 2003-2004,2006 Simtec Electronics
DMA channel 0 at c1800000, irq 33
DMA channel 1 at c1800040, irq 34
DMA channel 2 at c1800080, irq 35
DMA channel 3 at c18000c0, irq 36
S3C244X: Clock Support, DVS off
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP reno registered
NET: Registered protocol family 1
NetWinder Floating Point Emulator V0.97 (double precision)
JFFS2 version 2.2. (NAND) �© 2001-2006 Red Hat, Inc.
msgmni has been set to 25
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Console: switching to colour frame buffer device 30x40
fb0: s3c2410fb frame buffer device
Serial: 8250/16550 driver4 ports, IRQ sharing enabled
s3c2440-uart.0: s3c2410_serial0 at MMIO 0x50000000 (irq = 70) is a S3C2440
s3c2440-uart.1: s3c2410_serial1 at MMIO 0x50004000 (irq = 73) is a S3C2440
s3c2440-uart.2: s3c2410_serial2 at MMIO 0x50008000 (irq = 76) is a S3C2440
brd: module loaded
loop: module loaded
nbd: registered device at major 43
cs89x0:cs89x0_probe(0x0)
cs89x0.c: v2.4.3-pre1 Russell Nelson <nelson@crynwr.com>, Andrew Morton <andrewm@uow.edu.au>
eth0: cs8900 rev K found at 0xe0000300
cs89x0: No EEPROM
cs89x0 media RJ-45, IRQ 53eth0: Setting MAC address to c0:ff:ee:08:00:00.
, programmed I/O, MAC c0:ff:ee:08:00:00
cs89x0_probe1() successful
cs89x0:cs89x0_probe(0x0)
cs89x0: request_region(0xe0000300, 0x10) failed
cs89x0: no cs8900 or cs8920 detected.  Be sure to disable PnP with SETUP
Uniform Multi-Platform E-IDE driver
S3C24XX NAND Driver, (c) 2004 Simtec Electronics
s3c2440-nand s3c2440-nand: Tacls=3, 29ns Twrph0=7 69ns, Twrph1=3 29ns
NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)
Scanning device for bad blocks
Creating 8 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x00000000-0x00004000 : "Boot Agent"
0x00000000-0x00200000 : "S3C2410 flash partition 1"
0x00400000-0x00800000 : "S3C2410 flash partition 2"
0x00800000-0x00a00000 : "S3C2410 flash partition 3"
0x00a00000-0x00e00000 : "S3C2410 flash partition 4"
0x00e00000-0x01800000 : "S3C2410 flash partition 5"
0x01800000-0x03000000 : "S3C2410 flash partition 6"
0x03000000-0x04000000 : "S3C2410 flash partition 7"
aoe: AoE v47 initialised.
usbmon: debugfs is not available
s3c2410-ohci s3c2410-ohci: S3C24XX OHCI
s3c2410-ohci s3c2410-ohci: new USB bus registered, assigned bus number 1
s3c2410-ohci s3c2410-ohci: irq 42, io mem 0x49000000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
mice: PS/2 mouse device common for all mice
S3C24XX RTC, (c) 2004,2006 Simtec Electronics
i2c /dev entries driver
s3c2440-i2c s3c2440-i2c: slave address 0x10
s3c2440-i2c s3c2440-i2c: bus frequency set to 98 KHz
s3c2440-i2c s3c2440-i2c: i2c-0: S3C I2C adapter
S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics
s3c2410-wdt s3c2410-wdt: watchdog inactive, reset disabled, irq enabled
Registered led device: led4
Registered led device: led5
Registered led device: led6
Registered led device: led7
Advanced Linux Sound Architecture Driver Version 1.0.17.
ALSA device list:
  No soundcards found.
TCP cubic registered
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
eth0: using half-duplex 10Base-T (RJ-45)
IP-Config: Complete:
     device=eth0, addr=192.168.1.2, mask=255.255.255.0, gw=255.255.255.255,
     host=Linagora_board, domain=, nis-domain=(none),
     bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.1
Looking up port of RPC 100005/1 on 192.168.1.1
VFS: Mounted root (nfs filesystem).
Freeing init memory: 112K
sh-3.00#
sh-3.00#
sh-3.00# ls
bin  etc   lib      lost+found  opt   root  tmp  var
dev  home  linuxrc  mnt         proc  sbin  usr
sh-3.00# bin
bin/  bind
sh-3.00# bin/
addgroup   chmod      ed         hostname   mv         sleep      vi
adduser    chown      egrep      kill       netstat    stty       zcat
arch       cp         false      ln         pidof      su         zcmp
ash        date       fgrep      login      ping       sync       zdiff
bash       dd         g++        ls         ps         tar        zegrep
bashbug    delgroup   gcc        mkdir      pwd        touch      zfgrep
busybox    deluser    getopt     mknod      rm         true       zforce
c++        df         grep       mktemp     rmdir      umount     zgrep
cat        dir        gunzip     more       run-parts  uname      zless
cc         dmesg      gzexe      mount      sed        usleep     zmore
chgrp      echo       gzip       mt         sh         vdir       znew
sh-3.00# bin/echo toto
toto
sh-3.00# ps
Error, do this: mount -t proc none /proc
sh-3.00# mount -t proc none /proc
sh-3.00# ps
  PID TTY          TIME CMD
    1 ?        00:00:01 sh
    2 ?        00:00:00 kthreadd
    3 ?        00:00:00 ksoftirqd/0
    4 ?        00:00:00 watchdog/0
    5 ?        00:00:00 events/0
    6 ?        00:00:00 khelper
   64 ?        00:00:00 kblockd/0
   69 ?        00:00:00 ksuspend_usbd
   75 ?        00:00:00 khubd
   78 ?        00:00:00 kseriod
   85 ?        00:00:00 kmmcd
  108 ?        00:00:00 pdflush
  109 ?        00:00:00 pdflush
  110 ?        00:00:00 kswapd0
  111 ?        00:00:00 aio/0
  112 ?        00:00:00 nfsiod
  796 ?        00:00:00 mtdblockd
  852 ?        00:00:00 kpsmoused
  878 ?        00:00:00 rpciod/0
  891 ?        00:00:00 ps
sh-3.00#

Ceci est l'ensemble des logs obtenus avec un noyau 2.6.27. On remarque que certaines choses ne marchent pas encore, comme la carte son (à moins de se planter dans le mapping mémoire, ce qui fait sortir de la carte un son extrêmement strident de ce qui s'avère être un buzzer, mais ça n'a rien à voir avec la carte son), ou la RTC (qui sur un 2.6.27, fait ramer le démarrage, alors que ça se passe sans problème sur le 2.6.25) ; le LCD n'a pas encore été testé. Ici, j'utilise un autre config.emb2440-2.6.27eabi avec l'EABI d'activé : ça marche ! :) Il faudra aussi penser à virer le mapping de la flash en dur (berk), et mettre quelque chose de propre avec mtdparts, par exemple (en réalité, on s'en moque, le but maintenant va être de pouvoir écrire sur la flash où l'on veut quand on veut depuis le réseau et non le J-TAG tout lent ou le u-boot tout imprédictible). A voir dans un prochain épisode, certainement (si j'ai le temps...).

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

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

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

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