embedded weblog

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

linux embarqué

Linux Embarqué, ou Embedded Linux, soit le pingouin multifontion enfoui dans les p'tites boîtes

Fil des billets - Fil des commentaires

dimanche, décembre 27 2009

revue de presse

Il faut bien avouer qu'avec la masse de boulot de ces derniers temps, la revue de presse est quelque peu passée à l'as. Pourtant, bien des choses intéressantes peuvent être trouvées en tant que parfaite transition avec le billet précédent. Et déjà, comme je me demandais ce que devenais l'architecture SuperH, chez Renesas (qui possède la licence), la branche SH-mobile (sous SH4-A) tourne à présent sous Linux par défaut -- leur site peu prolixe en terme de software, il n'est pas précisé si le "RTOS" remplacé est cette horreur de la nature de OS20/0S21, reliques d'un autre temps. 35% moins cher.

Ensuite, parlons Android, alors qu'une "alliance" Google-Intel prend implicitement forme avec la décision par WindRiver de lancer une offre comerciale Android. A considérer les concepts de programmation mêlant java, html et javascript, je reste quelque peu dubitatif. Et l'API mouvante autant que la dépendance au SDK ne me rassure guère. Pis encore, la licence permissive Apache recèle de désagréables surprises, et c'est à se demander au final quel est donc ce bordel made by Google que l'on hérite là. Quant à Chromium, machin plutôt mal défini déjà sujet à bouts de scotch, la cible visée serait finalement assez réduite -- bien plus en tout cas que ce que prés(s)entait ARM sur son salon. J'ai peur de faire une présentation trop pessimiste, et invite donc à la lecture des différents (et fournis) articles ; pour ma part, j'en garde une impression de prudence à montrer vis-à-vis de ce nouvel engouement. Peut-être deviens-je moi aussi un vieux barbu ayatollah sur les bords, allez savoir.

En tout cas, côté interface web, la fonera 2.0n basée sur du OpenWRT est très sexy. Et le Nokia N900, sur Maemo5, est absolument formidable, avec cependant deux bémols : la weberie est basée sur un navigateur mystère (Firefox allégé ?) et un Firefox-bloatware, et le framework n'a pas encore migré sur Qt, donc toujours du GTK. N'empêche, bavez donc comme moi sur les vidéos, c'est impressionnant, et l'ouverture de la plate-forme est bien plus assurée que lors des premières releases en 2006 (quelle galère pour trouver le code !), avec des applications par lots qui ne nécessite pas d'avoir un avocat (Adroid) ou une carte blueue (iPhone) sous la main. Bref, si Google n'avait pas un gros rouleau-compresseur commercial, je parierais plutôt sur Maemo6 avec Cortex-A9 (pour l'instant, le N900 est sur du A8, il rame manifestement moins qu'un iPhone, mais ce n'est pas encore parfait à voir les vidéos de tests indépendants) avec une sortie d'ici 9 mois. Mais avec le peu de vague soulevée par un concurrent pourtant très sérieux au machin d'Apple (à l'intégration toujours très réussie, mais aussi pénible à délocker qu'un Android à rooter : ce n'est pas ouvert pour un sou !), je crois que je vais redevenir pessimiste...  :/   (d'un autre côté, Nokia reste leader et compte remplacer définitivement sa branche haut de gamme avec le N97 par du Linux/Maemo, sachant que son public habituel n'est pas forcément habitué à verser 650€ pour un téléphone ; il faut aussi considérer que la concurrence ayant été longtemps dépendante de Symbian -- quand bien même Motorola et RIM proposait des alternatives sérieuses --, un détachement de Nokia pour autre chose, même moins libre, mais "apparemment indépendant" pourrait se comprendre)

Pour finir, et parce que c'est Noël, un excellent article de démystification des SSDs, qui dépasse un peu le cadre "NAND avec contrôlleur" pour parler Flash d'une manière plus générale.

mardi, décembre 22 2009

ARM European Technical Conference 2009

Comme l'année dernière, et certainement celles d'avant (j'avoue ne pas connaître les origines exactes de l'événement), avait lieu en ce jeudi 10 décembre passé l'ARM European Technical Conference (AETC pour les intimes) 2009, au même lieu que l'année dernière, CAP15 près de la tour Eiffel. J'arrive très tôt (pour moi) mais manifestement, beaucoup de monde a son rythme de vie câlée sur nos amies aviaires, et la grande salle de conférence est déjà bien garnie. On y parle Anglais, comme toujours dans les conférences de cet événement réellement européen -- comprendre qu'il y a quantité d'Allemands (patron, ma formation de langue !), d'Anglais, et quelques Russes --, mais la langue véhiculaire laisse plus souvent que l'année dernière au vernaculaire sur les stands du forum voisin -- je n'ai pas pris de photo, mais l'organisation était tout aussi semblable qu'en 2008. Pour les personnes présentes qui passeraient sur ce compte-rendu, puisque chez Anticyp on m'a dit être déjà venu me lire, et qui ne me remettrait pas, j'étais tout de gris et violet vêtu, un chapeau sur la tête (quelques commentateurs, mais pas des plus fins, s'inquiétant régulièrement sur ce point).

Comme je ne pense jamais trop aux mékeskidi, et que chez Linagora, certains administrent des réseaux ou mettent en place des messageries, bref n'ont rien à voir avec l'embarqué mais trouvent peut-être ma prose intéressante, je rappelle donc que ARM est la société anglaise à l'origine du microprocesseur du même nom, que l'on trouve décliné sous différentes gammes depuis une vingtaine d'années dans tellement d'appareils embarqués, qu'il ne fait aucun doute qu'ils dominent le marché (et x86/Intel, me direz-vous ? Comptez le nombre de téléphones portables par foyer ; puis le nombre d'ordinateurs ; vous y êtes). ARM possède cependant une spécificité : ils ne sont pas fondeurs, comprendre qu'ils ne vendent pas directement des puces ni aucune sorte de hardware, mais seulement de la R&D pure, autrement dit pour les fondeurs que sont ST, NXP, TI ou ATMEL, pour parler des présents, il s'agit de récupérer des plans -- pour simplifier. La cible est néanmoins déterminée : il ne s'agit pas de grosses infrastructures réseautiques (plus propices à être sous PowerQUICC/PPC voire x86), ni de microcontrôleurs extrêmement simples de style PIC/68k (qui cèdent, certes, devant le Coldfire, dont on peut se demander si ARM ne gourmande pas par anticipation les parts de marché avec son dernier né, le Cortex-M3, mais je m'avance), mais il n'empêche que d'une cible de CE (Consumer Electronic), représentée sur le diagramme final par le "1 milliard de téléphones", la compagnie lorgne du côté des nouveaux mini-PCs (tout une histoire marketting, ce machin-là) avec 100 millions d'unités visées, et vers les "specialized devices" à hauteur de 10 milliards d'unités (une paille). Le démarrage en flèche du Cortex-M3, tout minuscule qu'il est (visible sur l'un des nombreux stands éparpillés d'ARM), destiné par exemple à être embarqué dans des montres, tendrait à soutenir cette espérance.

Malgré la crise, ARM va bien, et le fait savoir (quand bien même il n'y avait plus de fontaine au chocolat cette année -- mais le buffet était excellent, mes compliments au traiteur et à son équipe dévouée). Une slide montrant le foisonnement des microprocesseurs disponibles il y a une bonne quinzaine d'années, et de ce qu'il en reste en comparaison, fait l'impasse sur SH4 (pourtant très présent dans les STB et autres lecteurs en tout genre), sur SPARC (pourtant certaines archi intéressent le spatial -- ok, ça n'a pas empêché les CPUs de Thomson de défunter) ou sur PPC, montrant une promptitude à enterrer la concurrence qui m'a quelque peu amusé -- je n'ai pas eu le temps de demander sur le stand de ST ce qu'ils en pensaient... En fait, le concurrent principal Atom n'a pas droit de cité non plus. Et ça c'est vraiment méchant -- et pas forcément pertinent, mieux vaut prendre l'adversaire à bras le corps que de l'ignorer, en tout cas dans la bataille on sait où mon coeur va.

Il est beaucoup question de communauté, non pas libre mais autour de ARM, naturellement : par exemple, pour l'extension 3D Mali, le site malideveloper.com partage les informations plus simplement entre développeurs (le marché étant assez récent de ce côté, mais néanmoins à pente rapide comme on peut le constater en considérant les consoles de jeu video portables ; le vrai challenge pour ARM est clairement désigné : le multimédia et notamment la télévision, en concurrence frontale avec SH4) ; on évoque mbed.org, "rapid prototyping for microcontrollers" ; ou encore le projet plugcomputer, qui se donne d'agréger (le concept est un peu flou, je trouve) les idées de serveur miniature de "domotique" (le mot est devenu quelque peu tabou, à force), dans le style DLNA, connectivité centralisée à but applicatif, etc. En fait, remplacez le fameux "developers developers developers" de Ballmer par "community community community" : c'est le nouveau maître-mot. Désenclaver le développeur, mais aussi le décideur (cf la multiplication des blogs pro), voilà une idée qui a l'air aussi bête qu'évidente, mais qu'aucun ne s'était attelé à mettre en oeuvre jusqu'à présent. Si l'on considère la récente communauté autour de Montavista (meld), on voit bien que le mouvement est amorcé : c'est à qui fédèrera le plus autour de lui, en offrant comme valeur ajoutée un partage de connaissance. Ça ne vous dit rien, comme fonctionnement ? Linux embarqué, ce n'est pas seulement un OS gratuit qui entre dans le paysage, je ne cesse de le répéter, c'est l'arbre qui cache la forêt du libre dans l'embarqué, techniquement et dans la pratique : c'est une nouvelle façon de penser, de concevoir, par le partage (d'information pour le moment, mais le code commence à venir, voyez la suite), mot totalement inconnu jusqu'alors dans le monde industriel. Ça fait du bien.

Linux est un mot qui revient souvent, et que l'on trouve décliné sous les formes "Ubuntu" ou "Mozilla" (bon, on sait ce que j'en pense...). Mais ce qui revient encore plus, c'est Android, et Chrome. Le premier, on commence à le connaître, son succès, surtout depuis la dernière version, est impressionnant, et il ne faut pas s'étonner de le voir partout où l'environnement est pensé pour du fenêtrage simple, c'est-à-dire une application à la fois sur l'écran. Pour le multi-fenêtrage, ARM nous parle de Chrome : et là, j'avais raté un épisode. ChromeOS a été montré le 19 novembre dernier, et en fait, c'est l'une de mes prophéties qui se réalise (je suis meilleur que St-Jean le Baptiste, d'une manière générale, je fais donc attention à ne pas perdre la tête) : la migration de l'OS vers du tout-web, ie l'interface graphique utilisateur entièrement conçue à base de technologie web de type html/javascript, rendues par un navigateur puissant mais léger. C'est une question de logique : le but (dans lequel s'inscrit parfaitement Linux, qui est d'ailleurs le kernel sous ce ChromeOS) est d'abaisser le ticket d'entrée dans le monde de l'embarqué, et de le rendre plus fonctionnel ; fini les interfaces toutes pourries et obscures en assembleur et en frame buffer ! La montée en puissance (phénoménale) du hardware pour une consommation en énergie toujours meilleure sert exactement ces intérêts. À travers le logiciel, c'est l'utilisateur qui est remis au centre du problème. D'où la conclusion que je retiens : "Software is all about now", "software ecosystem decides !". La fin annoncée de l'électronicien raté, et l'arrivée du monde logiciel en position de force.

Après toutes ces bonnes nouvelles, place est laissée pour l'orateur suivant, qui nous parle d'un consortium rapidement identifié par mes soins comme du lobbying de hardeux, ce qui ne m'intéresse guère (on sait le milieu assez doué en la matière, parfois trop). Je migre donc vers les stands : passage chez -- ne riez pas -- Windows Embedded Business Group Microsoft France (toujours sur son WinCE 6.1, qui commence à dater, mais se voit affublé de service packs -- c'est une manie !), qui me donne gentiment une version de Windows Embedded 2011 (3cd : 32bit, 64bit et le toolkit), qui contrairement à XP standard est encore supporté quelques années ; entretien chez Montavista, qui distribue de la belle documentation sur son tout nouveau MontaVista Linux 6 (j'ai raté Maxime Petazzoni, dont je n'ai été au courant de la présence qu'à son appel en fin de journée pour gagner une mini-console de jeu, mais il était déjà parti !) ; et puis Ubuntu, qui présentait un petit PC de poche à clavier et écran tactile (dans les deux cas, mes doigts de pianistes étant déjà un peu trop gros : c'est pour le marché japonais, aussi...), de chez Sharp il me semble, sympathique mais à mon avis beaucoup trop geek, il n'y a qu'à considérer les parts de marché du N800, plus sexy quoique moins fonctionnel (mais plus réactif, en échange) -- côté software, en revanche, l'intégration est très bonne, mais firefox bouffe presque toute la mémoire, le menu convivial sur le bureau buggue encore un peu (ce n'est pas une version définitive qui était montrée), et parfois la machine freeze...

Tout le long de la journée, il y a aussi les sessions de conférences, quasiment toutes données par des gens de ARM, ou plus vastement de Keil, la partie software rachetée il y a maintenant un bon bout de temps : il ne faut alors pas s'étonner que lors du track32 "Advanced Debug and Optimization of Cortex-M processor-based Systems", on ne parle uniquement de la sonde J-Tag et des outils Keil, et nullement du JtagX ou autre sonde WindRiver que l'on vante tout aussi bien sur les stands d'Anticyp ou de Neomore. J'avoue sur la journée avoir moins assisté aux conférences que l'année précédente, ayant privilégié cette fois les stands -- sans pour autant avoir pu tout visiter, de ce qui aurait pu m'intéresser. C'est ainsi que je découvre MVD Training, dont le site affreux prouve bien qu'il s'agit de barbus de l'embarqué très bas niveau, et si l'on se fait concurrence sur les formations Linux embarqué/drivers, le reste est tout à fait complémentaire (notamment en terme de programmation), et l'offre assez unique à ma connaissance sur les formations très bas niveau (microprocesseur particulier, programmation, et au milieu : VHDL) me fait penser que mon DIF est plein à craquer (message subliminal).

Et puis je passe beaucoup de temps sur le stand Texas Instrument (Angleterre et Allemagne), pas seulement parce qu'ils possèdent la plus charmante des communicantes qui m'ait été de rencontrer (ciel, une Anglaise blonde -- immigrée en Allemagne --, je n'aurais jamais cru, si on peut lui donner mon URL, puisqu'elle doit manifestement savoir lire le Français, que l'on n'hésite surtout pas !), mais parce que ce sont des personnes extrêmement agréables et Elizabete De Freitas (TI serait-il un avant-goût du paradis ? Des femmes aussi sympathiques que belles...) ne met pas longtemps, alors que je lui explique un projet, pour m'offrir une beagle board ! (que j'ai failli me faire dérober à la station Tour Eiffel, mais après avoir piqué une gueulante monumentale sur les pickpockets, ils ont bizarrement fini par retrouver mon objet) Autant dire que ce geste me touche beaucoup, et à présent, je cherche du temps pour m'impliquer dans le support de la bête, le problème principal étant pour le moment de chercher comment en sortir une console (c'est très bête, mais brancher un video proj sur la sortie S-Video me semble un peu compliqué pour bosser, et monter un RS232 va nécessiter un passage en magasin d'électronique et une séance de soudage : autant dire que ça attendra après les fêtes, puisque je serai... en Allemagne).

J'arrête ici mon compte-rendu par anticipation de bonne résolution pour l'année prochaine : faire plus synthétique. Et puis surtout, parce que je suis en vacances dès demain. Enfin, parce que je n'ai pas encore reçu les slides (par mail, nous a-t-on dit, attention, ça veut dire "courrier" en anglais -- en ricain, ça aurait donné "snail mail", désambigüisé --, on se laisse toujours avoir...  :)   ), de fait il est plus difficile de tout se rappeler (et comme l'année dernière je m'étais ruiné la santé à prendre un maximum de notes, alors que j'avais ensuite reçu le CD complet...). Bref, je vous souhaite de bonnes fêtes, plein de beagle boards sous le sapin (non, je ne suis pas sponsorisé, juste un peu corrompu -- et puis la concurrence n'est pas facile à débusquer, alors même qu'on m'en a parlé), et j'espère bien me rendre à l'AETC 2010 l'an prochain !

jeudi, novembre 12 2009

conférence Paris8, deuxième

Pile poil un an après ma conférence à Paris 8, me revoilà au même lieu, toujours sous le regard d'Isis Truck, et celui d'une assemblée assez nombreuse et hétéroclite. Début de conférence retardé pour cause de câble manquant (ma faute, c'était dans mon sac, en plus...) et de projo à aller chercher à l'autre bout de St-Denis l'université, j'aurai tout de même bien parlé deux bonnes heures, ce qui me fait penser que je devrais peut-être songer à une version "light" -- pas gagné. Voici en tout cas les slides de la conférence Paris 8 2009 remis à jour (c'est-à-dire sans coquille).

Encore une fois, je remercie l'équipe de Paris 8 pour m'avoir si sympathiquement accueilli.

jeudi, octobre 15 2009

conférence April/Eyrolles : le debrief

La conférence April/Eyrolles de samedi dernier a finalement été bien remplie en un temps record (on peut l'avouer, maintenant : il n'y avait aucun inscrit le samedi précédent !), grâce à une politique d'annonce active -- notamment sur Toolinux, merci au patron. Entre quarante et cinquante personnes, à la louche (je n'ai pas eu de stat' officielle), un bon tiers d'amphi rempli en tout cas. Il paraît que c'était très bien, avec une durée de deux heures au lieu d'une annoncée -- non, les compliments n'étaient pas obligatoires pour accéder à la buvette. Ravi aussi de la présence d'un ancien chef de projet, et de personnes qui avaient déjà assisté à ma conf' Parinux très similaire, ou même à mon cours complet à l'INSIA : au moins, on sait qu'on est apprécié, pour se faire ainsi des redif'.

Comme promis, voici donc conférence April/Eyrolles, mises à jour pour éliminer les deux ou trois coquilles trouvées. Jean-Luc Ancey de Parinux a aussi capté l'ensemble de la conférence, à l'exception des cinq premières minutes -- mais c'est bien connu, ce qui compte, ce sont les cinq dernières. Problème, je ne sais pour l'instant pas où l'uploader, je mettrai à jour ce billet dès qu'une solution convenable sera trouvée.

Pour finir, si je suis désolé pour la démonstration abandonnée (faute de câble RS232 femelle-femelle : après une bataille de trois heures à en trouver un, pas de bol, il ne marchait pas...), même si de toute façon on aurait manqué de temps (il fallait rendre l'amphi), vous pourrez vous référer aux deux billets de présentation du matos et de portage de Linux sur ce blog. Vous avez aussi le droit de lire le reste, après tout -- notamment les comptes-rendus de RTS 09 et des assises franco-allemandes de l'embarqué, puisque j'y ai fait allusion.

Je remercie évidemment la librairie Eyrolles et l'April pour l'organisation (même si c'était bénévole, faudrait pas que ça devienne une habitude, le libre n'est pas gratuit !  :)  ), notamment Eva Mathieu de l'April qui a même été imprimer des flyers de bibliographie, avec une page web de CR sur le site de l'asso.


PS: après écoute rapide du fichier de J-L, je tiens à m'excuser :
   * de bouffer des mots de temps en temps (mais je me soigne)
   * de dire "bein" et "bah" trop souvent
   * auprès des Indiens et des développeurs Java    (en fait, non)

mercredi, septembre 23 2009

conférence Eyrolles à venir

      Oyez oyez,

samedi 10 octobre 2009 aura lieu à 15h une conférence de votre serviteur sur le thème "Linux Embarqué", pour le compte de l'APRIL, sur hébergement d'Eyrolles. L'annonce complète se trouve sur l'APRIL. Attention, une erreur s'est glissée : c'est bien à l'ENSTP, qui prête son grand amphi, juste au dessus de la librairie Eyrolles de St-Germain (métro Maubert-Mutualité) qu'il faudra se rendre.

Réservation : conferences@eyrolles.com, tél. 01 44 41 11 31, ou à la librairie.

Évidemment, c'est galère, ce qui expliquerait peut-être qu'il y a aussi peu de personnes qui se sont déjà ainsi dénoncées (ou peut-être que cette remarque ne concernait que le premier de volet de conf' du 3 octobre, en concurrence avec l'OpenSource machin de la cité des sciences, ce qui n'est pas bien heureux). Mais essayez de le faire tout de même. Du moins, si vous souhaitez m'entendre.


update: attention, l'adresse d'inscription est "conference@eyrolles.com", sans "s" à "conference", et il vraiment, vraiment important de s'y inscrire, quitte à préciser que l'on n'est pas à 100% sûr de venir.

vendredi, juin 5 2009

le choc avant le week-end

WindRiver est racheté par Intel ! Je suis allé vérifier ailleurs, ça semble bien vrai... (et l'annonce de dater d'hier)

J'en reste sans voix.

lundi, mai 18 2009

photos libres

Jusqu'ici, les OS étaient essentiellement maison, ou alors on mettait du ThreadX. Mais il semblerait que les temps changent parmi les constructeurs d'appareils photos numériques. Certes, il existe déjà un projet libre pour Canon, mais il s'agit d'exécuter un code qui ajoute des fonctionalités à l'appareil. Ici, je parle de l'OS constructeur, à base de Linux embarqué : Sony (dont les téléviseurs étaient déjà tous linuxisés depuis quelques années) équipe à présent ses gammes de Linux embarqué, sur les Cybershots par exemple. Et ça, c'est nouveau, impensable il y a encore peu de temps (entre les prix de la flash et de la RAM, forcément très supérieures en quantité que pour du ThreadX, l'investissement, sans compter le coût du portage, ne se justifiait certainement pas), et un nouveau marché pour Linux embarqué qui s'ouvre !

Décidément, où la conquête de Tux s'arrêtera-t-elle ? (à noter que mon titre est forcément abusif et racoleur -- toujours cette histoire de future carrière commerciale -- : le soft qui fait interface et le traitement numérique via DSP sont forcément toujours fermés...)

mercredi, avril 22 2009

Alcatel migre vers Linux

Au début je me suis "certes, what else ?", mais j'ai tout de même cliqué. En fait, c'est d'embarqué qu'il s'agit : les appareils de networking d'Alcatel-Lucent qui migrent de VxWorks vers Linux. Ouais, apparemment, ça tourne sous VxWorks, ça fait un peu peur pour la peine (ils sont sympathiques, chez WindRiver, mais leur pile IP a une réputation qui n'est plus à refaire, dans le milieu...). En VO, ça donne :

"There are great packages that are available on Linux and a lot of new packages we can integrate into our switches if we decide to do so," Nikolova said. "VxWorks is old and doesn't have a lot of movement in it. The packages that VxWorks provides really aren't the latest and greatest. But basically everyone is moving toward Linux."

VxWorks is old, ça m'a fait un peu tiqué : un peu d'histoire, et on trouve bien que l'origine de l'OS remonte à du framework VRTX en 83, recodé de manière indépendante au niveau de son kernel (on touche à l'équivalence de ce qu'est Linux en terme fonctionnel) en 87. Or, Linux, ça date de 1991. Et après tout, on en fait depuis 2000, en embarqué. Et le plus drôle, c'est que les projets viables et utilisés les plus anciens que j'ai pu retrouver datent de cette époque, et c'était du poste téléphonique chez.. Alcatel ! Presque 10 ans, quand même... :)

En tout cas, cette réaction est totu à fait typique du moment fatidique dit du "ça ne va plus, le patchodrôme, il faut migrer" ; je croyais que tout le monde l'avait déjà fait (regardez votre *box ADSL en même temps), apparemment, non, il en reste. Linagora est là pour vous aider, si vous êtes retardataire.  ;)

mercredi, avril 8 2009

salons RTS et Solutions Linux 09

Les salons Real Time System et Solutions Linux se tenaient en même temps, cette année, porte de Versailles tout deux. J'avais déjà évoqué les bons et très mauvais points de cette connivence de dates et de lieux il y a six mois environ, et comme je le craignais, les seuls avantages que pouvait amener cette situation ont été annihilés par la distance assez élevée entre les bâtiments 8 et 2.2 : combien de fois n'ai-je entendu les uns et les autres avoir hésité entre les deux salons (WindRiver), ou promettre de passer sur l'autre (SFR) sans qu'on les y voie faute de temps, et en tout cas se plaindre de cette situation ? D'une manière générale, peu de société de Linux embarqué ont choisi Solutions Linux plutôt que RTS ; on pourra citer Concurrent Computer, tandis que Sphinx, habituellement présent sur les deux, a préféré RTS. Linagora était évidemment sur Solutions Linux, mais pas sur RTS. Avantage cependant de ces dates simultanées pour Linagora : pouvoir dépêcher sur RTS un commercial/avant-vente dès lors que j'avais repéré une affaire potentielle ; en l'occurrence, Sébastien Bahloul aura fait quelques allers-retours (compter un peu plus de dix minutes de déplacement pour l'opération...). Mais voilà : parfois, le simple temps d'alerter d'un bon, et le temps d'arriver (parfois le lendemain, quand on a repéré quelque chose d'intéressant la veille au soir), les intervenants sur les stands ont changé, et plus que répéter le travail d'approche, il est arrivé plusieurs fois où le bon interlocuteur, le seul qui pouvait faire interface, avait disparu. C'est ainsi qu'une fois une société me dit avoir grandement besoin de services Linux, et le temps de revenir, tout autre son de cloche, très peu de Linux en vue : en fait, les deux personnes adressaient des marchés totalement disjoints.

Cela fait cinq ans que je reviens sur le salon RTS, et six pour Solutions Linux. D'expérience, le premier est bien plus intéressant que le second, en ce qui concerne Linux embarqué, mais il n'est pas impertinent de choisir le second plutôt que le premier dès lors que l'on propose du software, surtout s'il s'agit de temps-réel pouvant avoir vocation à des applications de type serveurs. C'était cependant SL qui ouvrait le bal avec une conférence dès le premier jour (31 mars) au matin sur le sujet : Sébastien Dinot comme modérateur, et des gens connus ou reconnus comme intervenant ; citons donc le traditionnel Christian Charreyre de de CIO informatique (nos concurrents marseillais), et les plus nouveaux David Chabal (toulousain dont j'ai relu l'excellente documentation sur Xenomai, que je n'arrive toujours pas à trouver en diffusion publique, mais je suis dans les remerciements), Lucas Bonnet (monsieur OpenMoko France) et Etienne Juliot (Obeo). Pour un compte-rendu très complet, il suffit d'aller lire l'excellent rapport de Thomas Petazzoni. Il se trouve que j'ai décidé de sécher cette conférence : déjà, parce qu'elle était payante, et qu'il fallait donc magouiller un pass' conférencier sur notre stand (perte de temps, quand tu nous tiens), et ensuite parce que j'ai préféré arpenter RTS sur le peu de temps imparti, qui ne me semblait pas justifier de sacrifier une demi-journée. Je pense avoir eu raison : même si je n'avais pas assisté à la session RMLL 08, j'avais lu les slides, et il se trouve que le Chabal et le Bonnet ont fait de la redif' ; la conf' plus généraliste de CIO m'aurait certainement un peu ennuyé ; et celle d'Obéo a été rediffusée sur le salon RTS, où je n'ai d'ailleurs pas été plus avancé que Thomas (on y reviendra). Il ne m'étonne en tout cas que moyennement que seuls une dizaine de personnes y étaient présentes.

C'est ce que l'on appelle "un beau gâchis". J'avais moi-même pré-postulé il y a bien longtemps pour donner une conférence sur le portage Linux embarqué sur architecture ARM non supportée, mais le temps de confirmer (ie d'avoir réellement porté le bestiaux), les trois autres intervenants étaient retenus. Quatre, c'est bien peu, d'ailleurs. J'avais alors prévu de présenter le même sujet sous un angle différent pour la conf' RTS "les outils open source dans l'embarqué", qui a été annulée silencieusement (mais j'ai appris à la fin du salon que François Gauthier avait regardé les activité de Linagora suite à mon mail, et que c'est ainsi qu'il contacta Benjamin Jean, notre juriste, pour la session "la jungle des licences logicielles"). Je donnerais a priori cette conférence (dont l'université Paris 8 a pu avoir un court extrait) au RMLL 09, à Nantes, finalement. Il se trouve, en tout cas, que j'ai par le plus pur des hasards prédestiné, rencontré Francis Mantes, au sortir du salon RTS avec Sébastien, après être allé rencontré des gens intéressants : allumant sa pipe, j'aperçois son badge, et vais donc immédiatement à sa rencontre. Nous avons discuté un bon moment (il se souvenait par ailleurs du court échange que nous avions eu par mail), et avons déploré la distance des deux salons mis ainsi en concurrence (si Groupe Solutions organisait les deux auparavant, il semble que SL soit passé sous l'égide de Tarsus) : il a été décidé de prévoir une semi-journée Linux l'année prochaine, avec force ateliers et conférences à but technique plus que commercial ; non seulement j'abonde, mais je salue la pré-initiative (en outre, puisque l'on m'a invité à rappeler par mail cet échange, je ne manquerai pas de lier ce compte-rendu, et j'en profite donc pour saluer le travail organisationnel de notre hôte).

Mais revenons-en à nos hardeux. Car le salon RTS c'est avant tout du silicium et de l'époxy, il faut bien l'avouer. Les "softeux" (ça sonne plus mal) sont peu nombreux, on compte les gros WindRiver, GreenHills Software ; il y a Sysgo, mais nul LynuxWorks cette année, et pas de Montavista non plus. Bref, on fournit du BSP (Board Support Package, pour les n00bs), mais pas de service informatique à proprement parler : un seul concurrent -- et de taille, quoique, il faut considérer que l'informatique embarquée représente aussi chez eux une partie seulement de leurs activités --, possédant un stand, côté M2M, à savoir Teamlog. À noter au passage qu'outre RTS, il est de tradition depuis plusieurs années de lier M2M (Machine to Machine, toujours pour les n00bs) et Display (affichages numériques) ; il y a cinq ans, le second connaissait un succès monstre avec force téléviseurs, imprimantes 3D ou autres, mais il doit être concurrencé par un autre événement non identifié, car il n'y a plus que quelques sociétés proposant des affichages digitaux (on reste néanmoins admiratif devant des écrans cristaux liquides d'une qualité impressionnante).

Ma mission a donc consisté à aller démarcher les vendeurs de hard et de BSP, pour nous faire connaître : oui, nous, Linagora, société de services en informatique libre (et éditeur, sur d'autres parties), partant d'un concept généralisé mais experts dans notre partie, à l'originalité indéniable notamment concernant notre interfaçage privilégié avec la communauté (aka "le monde du libre"), et disposant depuis un an et demi d'une équipe aguerrie d'ingénieurs informaticiens rompus aux techniques de l'embarqué, du temps réel, de l'industriel.

Il faut reconnaître un certain succès a priori (a posteriori, on verra si des affaires nous reviennent, il faut attendre un certain temps pour cela) : premier bon point, j'ai l'habitude de ce salon, certains intervenants me connaissent fort bien à force, je suis donc à l'aise ; second bon point, et de taille, la démarche est fort originale, et répond à un besoin déjà identifié par les acteurs. En effet, les vendeurs de matériel électronique (le "hard"), qui peuvent aller de la puce à la carte, du module au PC durci, n'ont que très peu de connaissances logicielles, et lorsque des clients viennent les voir avec une idée de développement logiciel derrière la tête, les fameux "applicatifs métiers", ce n'est pas forcément en ayant déjà à disposition l'expertise technique suffisante. Or, acheter un bien matériel que représente une carte de développement, une carte industrielle, ou un module de communication M2M est une autre paire de manches que dégoter l'ingénieur expert pouvant concevoir le système software qui va faire d'un hardware inanimé monts et merveilles. J'ai assez assuré de prestations chez des grands comptes qui cherchaient une personne qualifiée depuis six mois ou plus pour le savoir. Le positionnement de Linagora est alors simple : vous savez faire le hard, nous savons faire le soft, nous existons, faîtes-le savoir à vos clients !

Aussi, nous n'entrons pas en concurrence frontale avec les autres acteurs comme Sysgo, Montavista ou autres, qui ont déjà des accords pour fournir des BSP ou autres solutions de Linux embarqué/RT "clef en main" : nous construisons au dessus, nous intégrons, nous apportons la plus-value sur mesure, du "bespoke (free) software solution", en somme (la fashion victime qui sommeille en moi va copyrighter cette expression, tiens). À noter aussi que Linagora n'est pas un ayatollah du libre : notre société promeut le libre mais n'y oblige pas ses clients, et si le sujet est sensible dans l'industrie, j'en suis tout aussi conscient ; cependant, nous pouvons concevoir du logiciel propriétaire à la demande par dessus du logiciel libre (notre spécialité se situant ici, ce qui comprend les problématiques de licences), et ce de l'avant-vente jusqu'au support OSSA (Open Source Software Assurance : le service après-vente de luxe par Linagora), tout en vous proposant de reverser les parties de modifications de logiciels libres utiles à la communauté selon votre bon vouloir (mais croyez-moi : mieux vaut participer, gagner en plus l'estime du public averti, et éviter de redévelopper les mêmes patches à chaque fois que l'on veut effectuer une mise-à-jour interne du produit ; bien des coûts cachés sommeillent dans le logiciel libre, il est de notre devoir de proposer de les optimiser pour le bien de tous).

Voilà pour la communication externe, toutes mes excuses aux collaborateurs qui se seraient ennuyés...

La pêche fut très bonne : il est envisageable de rassembler la masse de cartes de visite (sachant qu'il faut parlementer un minimum pour en obtenir une : pas tout le monde n'avait un stock à disposition, loin de là) en un jeu des sept familles, mais il sera plutôt préférable de faire du business avec. Je ne dirais donc pas que le salon était vide, à l'instar de Thomas dans son compte-rendu sus-lié, les allées étant peuplées et les stands quasiment toujours occupés ; de plus, trois ou quatre conférences se tenaient constamment en même temps, avec plus ou moins succès -- mais au moins, elles y sont gratuites. J'ai fait le constat inverse concernant SL dès lors que l'on s'éloignait des stands Linagora-Novell-Canonical (ces derniers exposant, juste en face de nous, leur réussite sur les migrations Assemblée Nationale et Gendarmerie, et ce sans nous citer ! Incroyable mais vrai), comme quoi ça devait dépendre de l'heure. Car finalement, je n'ai passé que peu de temps sur le salon linuxien, en fin de journée ou à la pause déjeuner essentiellement, histoire de voir un peu de monde, de passer sur notre stand, ou de saluer des amis d'associations de libristes. Et puis aussi participer au cheese'n'wine du second jour, le soir -- du moins au début des festivités, un pré-Wagner m'attendait au théâtre du Châtelet.

Puisque je réserve un retour détaillé des différents intervenants très intéressants à recontacter en interne (non, je ne donnerai pas des pistes à la concurrence, il ne faut pas pousser non plus  :)  ), passons donc aux comptes-rendus des différentes conférences. J'ai commencé par une première session de 14h00 à 16h00 consacrée à la certification logicielle : le sujet m'intéresse beaucoup, j'ai justement contacté quelqu'ami chef de centre de Systerel (associé l'année dernière à Sysgo par un stand commun, mais pas cette fois) à ce sujet, car il n'existe aucune formation dans l'absolu. Différents intervenants au programme : Lionel Burgaud de GreenHills a parlé d'organisation collaborative, parce que spécifier chacun dans son coin des bouts de code similaires est passablement contre-productif ; GHS a fait certifier sa solution Integrity EAL6+, après trois ans de torture (les développeurs sont aussi passés à la question) par la NSA. Lionel Burgaud m'avait, peu de temps avent cette présentation, fait un exposé sur son stand de l'attachement de GHS à la sécurité (il a montré une vidéo de turbine piratée à distance poussée à son extrême limite : de quoi attirer l'attention sur les failles de sécurité qui émaillent le code des développeurs de l'industriel) : c'est clairement le positionnement marketting de la société à présent. La vague sécuritaire touche d'ailleurs aussi la solution concurrente (mais à l'architecture différente : virtualisation vs paravirtualisation) de Sysgo, et c'est l'habituel mais toujours intéressant José Almeida (cinq ans que l'on se voit, alors à la pause, on devise ensemble, forcément) qui cette fois ne nous parle plus Linux ou PikeOS, mais DO178B (du niveau E au A, pour l'avionique), Common Criteria avec EAL/MILS (du niveau 1 à 7), IEC61508/ENSO128 (de SIL 0 à 4, par un positionnement parallèle à la DO-178B, mais pour le ferroviaire cette fois), ou encore ECSS (espace), FDA (médical) et que sais-je encore : un vrai fouillis ! Les prédispositions communes sont la fiabilité, la disponibilité et la réutilisation, à mettre en corrélation avec le Time to Market ; d'autres concept sont encore abordés : certification incrémentale, méthode formelle, mélange de niveaux indépendants, utilisation en redondance (pas facile de relire ses notes, d'autant qu'il faut effectuer une traduction à la volée...). On évoque aussi des différences dans les habitudes de codage avec l'apparition d'APIs POSIX/ARINC. Enfin, on parle d'ESA, dont le projet est la convergence de certifications (ECSS, DO178B et CC/EAL5+), en recoupant les similitudes pour gagner du temps.

C'est ensuite à Matteo Bordin, d'AdaCore (tiens, un intervenant que je ne connais pas, uniquement anglophone d'ailleurs), "toward a lean approch of certification", qui parle d'open-do.org. Ce projet recoupe ce qui avait été abordé justement par GHS (mais ils ne se connaissaient pas tous les deux, un comble pour des prôneurs du coopératif !), à savoir la collaboration et la mise en commun pour accélérer les certifications, selon un nouveau moyen hérité des méthodes Agile. On remarque en premier que la certification actuelle se fait d'un seul bloc : on écrit entièrement le code, puis on le fait certifier, on attend quelques années, et voilà. Mais rajouter du code ensuite fait automatiquement sauter la certif', et il faut alors recommencer le cycle depuis le début : dans le cadre d'un logiciel communautaire (au hasard un compilateur pour langage Ada), on comprend que ce soit passablement gênant. L'idée est alors de recouper le libre, l'agile, et la certification High Assurance ; on voit une potentialité dans le militaire, l'espace et le ferroviaire pour une communauté HA, on compare la méthode de certif' DO178 vs Lean/Agile, et on expose enfin le but d'OpenDO : communauté ouverte, partage, base de connaissance, apprentissage méthodologique (education, en anglais dans le texte) et de l'Agile dans les process. Why not ? Comme "bootstrapping" (on reste parmi des techos, on a le droit au détournement d'expression -- quoique) : FP7 en Europe et DARPA aux USA. Bref, ça démarre...

C'est au tour d'Olivier Charrier de WindRiver, sur le sujet de l'avionique modulaire intégré (IMA), partant du concept qu'en avionique comme en automobile, l'augmentation des fonctionnalités s'observe parallèlement à la baisse du nombre de CPUs embarqués, qui deviennent multicoeurs, déjà qu'ils avaient tendance (oh my god tout ça) à avoir de la MMU, du DMA, et on en passe des meilleures qui imposent (attention puristes, ça va vous faire mal) l'utilisation d'un OS. Résultat : des problèmes de synchronisation dans les développement hardware, software, l'intégration des deux, le tout avant certification. On attire l'attention sur le point d'achoppement principal que constituent le debuggage et le testing. Thomas Cenni de MathWorks (éditeur de Matlab, évidemment) parle de tout autre chose : génération de code certifié, instrumentation simulink et le tout sous couvert de Polyspace, racheté il y a plus d'un an à présent (différence entre Polyspace et Coverty : le premier indique quelles sont les zones totalement fiables et certifiables, le second indique les bugs potentiels : chacun prend le problème par un bout, cependant à 45K€ la solution -- sans compter la prise en main que cela implique --, mieux vaut ne pas se tromper d'approche ou être riche !). Enfin, Luc Coyette d'Esterel entretient des problèmes de spécification et de tests, impliquant la détection tardive de bugs, faisant exploser les coûts (jusqu'à devenir intolérablement haut dans certains cas) ; sa solution : SCADE, aliant langage formel, générateur de code certifié, simulateur et vérification de compilation. Il annonce que 8 millions de lignes de codes générés pour 40 modules sont embarqués dans l'A380, au niveau A de la DO-178B ! En séance de questions, quelqu'un demande pourquoi on n'applique pas les même normes draconniennes à l'automobile (extrait du magazine "Electronique" : " 'le standard DO-254 [ndlr: certif' de systèmes un peu plus complexes que pour la 178], quant à lui, est très jeune puisque le document date d'avril 2000', explique Lionel Burgaud (GreenSys)", ça donne une idée du niveau) : réponse, parce que ça coûterait trop cher pour quatre morts de temps à autre, sans que l'on sache trop (et à vrai dire, on ne cherche pas trop à savoir) si c'est le régulateur de vitesse ou la mauvaise conduite qui en est à l'origine ; un avion de 240 personnes qui se crache, c'est une catastrophe qui passe au JT, mais effectivement, il y a bien 50 fois moins de morts par accident d'avion en France que par voiture, c'est juste que le coût par vie est moins rentable tout considéré. On apprécie la franchise.

Seconde conférence : tests et sécurisation en milieu embarqué, le second jour au matin (10h à midi). Le propos était fort semblable, et si l'on y ajoute que le magazine "Electronique", distribué gratuitement (au lieu de 12,20€ les 65 pages pubs nombreuses comprises, sacré pouvoir d'achat chez les hardeux !), consacrant un dossier en couverture de cinq pages sur le sujet (et deux à l'amélioration du temps de boot de Linux, au passage), cela montre l'intérêt porté à la question, d'autant que l'audience comportait encore trente à quarante personnes. Bref, sous l'égide de François Gauthier, de ladite revue électronique (mensuel arrivé au numéro 200, quand même), le premier intervenant est encore de chez GreenHills, le fort connu Serge Plagnol : il nous parle d'hyperviseurs (tendances, techniques et applications), comparant para et full (ainsi que l'hybride) virtualisation (notamment par rapport au portage de drivers, inutile dans le premier), mais aussi de type 1 (à la ESX) vs type 2 (à la VMW workstation) ou hybride, comme  c'est le cas de, KVM mais aussi d'Integrity, qui peut ainsi aussi exécuter des applications. On considère ensuite les différentes architectures : monolythique (ESXi, VLX -- VirtualLogix était d'ailleurs absents, tout comme Trango et OKL4), Dom0 (Xen par exemple, mais le TCB est encore trop gros, on compte plusieurs mégas de code !) et enfin à base de microkernel, comme OKL4 (que l'on connaît assez bien par ici : mon ancien stagiaire a passé six mois sur le sujet) et Integrity, qui présentent un très petit TCB. On parle rapidement de ce que propose l'architecture x86 en terme d'aide à la virtualisation : VT-x (niveaux de privilèges) et VT-d (I/O virtualisés, dont la DMA, plus quelques autres joyeuseries) ; pour l'instant, l'Atom ne propose que du VT-x, mais une évolution prochaine est à attendre ; de son côté, ARM propose TrustZone, une double partition de fiabilité. Si l'on rappelle (page de pub) qu'Integrity est certifié à présent EAL6+, on insiste sur le fait que la virtualisation n'implique pas en soi la sécurité, bien au contraire ! Enfin, les applications de ce type de sécurisation par hyperviseurs seraient la téléphonie, les PC portables d'entreprise, les terminaux de paiement, le jeu avec transaction financière, et tout ce qui implique à la fois une communication (militaire notamment) et la présence simultanée d'une IHM.

Après cette longue présentation, c'est au tour de Jean Philippe Dehaene de présenter AUTOSAR, l'outil de simulation de VECTOR, les spécialistes en solutions logicielles (notamment sur bus de comm' CAN et LIN) pour l'automobile ; c'est intéressant pour qui est du milieu (très particulier, et qui ne va pas forcément bien en ce moment : passons). Didier Vidal d'ISIT expose les mérites de LDRA, l'analyseur statique de code ; c'est que la relecture manuelle de code trouve sa limite à 10 pages par jour, même si elle corrige 80% des bugs fonctionnels. La relecture automatisée, à l'inverse, ne peut pas trouver les erreurs fonctionnelles mais relève 80 des bugs techniques. À l'aide de règles de codage (MISRA-C 2004), de graphes d'appels, d'étude de code, de statistiques, de commentaires automatisés (ça j'aime !), de suivi de variables et d'exports des résultats dans des formats divers et variés dont le web (ça dépasse la simple relecture automatisée !), la société entend nous faire économiser bien de la sueur (contre un gros chèque, certainement). Fait très amusant, dans le contexte : alors que l'on passe rapidement les très nombreux slides, et que le transparent 60/60 concerne la détection de buffer overflow et d'overrun, on continue la présentation jusqu'à la slide 67/60 !

Ben Chelf, CTO de Coverty (et anglophone only, sorry) parle d'une nouvelle solution d'analyse de compilation : ça c'est fort ! Le problème du build est l'effet "boîte noire" (black barrier), peu importe si le compilateur est est libre ou non, à la rigueur, étant donné la complexité actuelle. L'analyse de build construit une carte du système de compilation complet en s'interfaçant entre les outils et l'OS ; un exemple est alors donné en utilisant... OpenOffice.org ! Ça ne s'invente pas, et évidemment, le graphe peut servir à faire peur aux petits enfants le soir. À noter que d'une manière générale, les outils libres sont implantés partout : on s'en sert directement (gcc et eclipse en star, encore plus que Linux) ou indirectement, comme base de proof of concept ; coverty s'est fait une spécialité de découvrir les bugs de logiciels libres pour à la fois se faire de la pub à peu de frais sur une base de code énorme, et tester leur outil en même temps (ce qui me fait penser que je leur ai parlé du bug de ifstated sur bagotage d'interface réseau : arriveront-ils à le trouver ?). Leur logiciel explore les différentes phases de la compilation : le make clean, les macros DEBUG ou RELEASE, les options de sécurité, etc ; fini les peurs bleues d'avoir un fichier objet non regénéré à la suite d'une modification de .h ! (ça peut faire très, très mal, sur du code militaire mal foutu, surtout quand ça fait plusieurs dizaines voire centaines de milliers de lignes -- souvenirs douloureux). Outre l'analyse, un "build management" est proposé.

L'après-midi, je m'étais inscrit à la conférence sur la virtualisation, mais j'avais mal compris : c'était la virtualisation de la machine de développement dans le but d'émuler des plate-formes exotiques pouvant aller jusqu'à l'ARM OMAP ; comme j'avais déjà discuté assez en profondeur à mon goût de ce sujet avec les principaux intervenants, ECSI (attention ! web 0.2), je me suis enfui ; cependant, le sujet est extrêmement intéressant, pour avoir eu l'occasion de développer sur OMAP, justement, et donc de goûter aux 25 minutes de flashage intégral à chaque fois que l'on veut tester la solution (quant au développement par NFS, autant oublier : il n'y a pas d'Ethernet, voyons !) ; je crois donc sans problème le consortium européen (avec notamment une université lettone dans le lot, oui ça étonne) lorsqu'ils affirment pouvoir réduire par deux le TTM (Time to Market, si vous débarquez de Mars). J'ai donc opté pour l'autre conférence simultanée pouvant être intéressante : Agile dans le milieu industriel, encore introduit par François Gauthier qui avoue à la fois intérêt grandissant (ce que semble confirmer le monde présent) et la nouveauté de l'approche dans le milieu. Mauvaise pioche : Philippe Soulard (remplaçant Yves Lebeaupin) de Sodius me fait mal à la tête avec son exposé "Multi-tool & multi-model integration using IBM rules composer" : trop de sigles et concepts abstraits, c'est à se demander si l'on parle bien de méthodes Agile, en tout cas je ne suis pas ; Etienne Juliot d'Obeo (voir au dessus) prend la relève et commence par un remerciement à son prédécesseur d'avoir introduit autant de concept (ouille), avant de nous parler de ses outils de modélisation, avec du temps-réel et de la génération embarqués sous Eclipse (c'est ce que disent mes notes) ; je reste malgré le micro qui rend l'âme (embêtant, ces micros, vraiment) parce que ça parle OpenSource (j'ai appris plus tard que Linagora a un peu travaillé avec Obéo pour le ministère des finances, association qui n'a pu aboutir faute d'avoir obtenu le marché : je confirme que nous n'étions pas mentionné parmi les partenaires), mais au bout d'un moment, je finis par craquer (au bout d'une heure, en fait).

Dernier jour et dernière conférence : "la jungle des licences logicielles". L'intitulé a pas mal évolué, l'apparition de cette conférence le dernier jour (moins peuplé et terminant à 17h30) n'a pas non plus aidé au remplissage de la salle : seulement une dizaine de personnes présentes, ce qui a déçu François Gauthier (décidément, je n'ai pas fait exprès, mais nous partageons les mêmes goûts apparemment). L'année dernière, la salle était comble, et les intervenants clairement techniques et peu juridiques : cette année, tout le contraire, de vrais juristes et avocats, mais des erreurs techniques dans le discours (netfilter, le module Linux de firewall, est ainsi de venu "netfiles", logiciel). Pour l'année prochaine, il serait de bon ton de mêler les deux milieux, et je me propose dores et déjà, tant le sujet me passionne (le juridique d'une manière générale, en fait, et je devise régulièrement avec avocats et professeurs de droit, de surcroît) ; d'ailleurs, j'ai pu parler à la fin de l'affaire Guillermito, fort importante mais inconnus de mes interlocuteurs (pour ma part, j'avais tout simplement pris deux après-midi pour assister au procès et au délibéré). Les deux premiers intervenants sont Cendrine Claviez et Vincent Pollard du cabinet TAJ, mais arrivant en retard (pour cause de prospection), j'ai raté le début de l'intervention de la première, pour arriver au moment de la considération des effets héréditaires/viraux, classant GPL, EUPL, CeCILL A d'un côté, MPL, LGPL, Eclipse et CeCILL C de l'autre, et enfin MIT, BSD, ASF et CeCILLB ensemble. La volonté d'organisation de cette "jungle" est manifeste. On continue sur les résiliations, automatique pour la GPLv2 et l'EUPL, il y a un délai pour la GPLv3 : en cas de constatation de violation, on peut ainsi avoir le droit de continuer d'utiliser le logiciel en attendant la rectification, alors que pour les autres, la sanction est immédiate, avec l'injonction de cesser immédiatement l'utilisation ; pour la peine, la GPLv3 est bien plus favorable à l'industriel distrait ! (évidemment, nous considèrerons la bonne foi a priori de celui-ci) On parle de l'EUPL, versions 1.0 et 1.1, la licence libre européenne pensée pour agir dans la juridiction du licenceur en Europe, et selon le droit belge sinon, et comportant une clause de compatibilité avec la GPLv2, la CeCILL ou encore Eclipse (attention cependant à la GPLv3 ou tout autre licence rédigée après l'EUPL, et de facto non mentionnée : il faut rajouter en annexe). On rappelle que le relicenciement autorisé par la BSD implique de pouvoir rendre le code GPL.

C'est ensuite au tour d'Hervé Guyomard de présenter son outil phare de Black Duck Software, et il nous injective : "Know your code" ! Prenons un exemple : Cisco rachète Linksys pour 500M$, Linksys embarque dans son WRT54G du code de Broadcom, que lui a fourni son sous-traitant Cybertran ; pas de bol, c'est bourré de GPL, et la FSF intente un procès à Cisco. L'histoire va plus loin encore : le WRT54G à 60$ voit son code libéré pour respecter la licence, code qui se voit grandement amélioré par la communauté, et réembarquable dans le même appareil, concurrençant dès lors des solutions professionnelles de Cisco valant... 600$ ! Cette histoire bien connue des milieux libristes de l'embarqué illustre le propos de notre intervenant : avec 1400 licences OpenSource recensées (évidemment, la plupart sont des adaptations de licences bien connues : il suffit de rajouter des annexes ou de modifier des paragraphes -- on recense par exemple une GPL interdisant les usages militaires : il faut noter que cette licence n'est alors plus considérée comme libre, quoique toujours OpenSource), il n'est pas inhabituel de se prendre les pieds dans le tapis, et d'embarquer sans le savoir du code soumis à des termes de licences non pris en compte, et pouvant avoir de fâcheuses conséquences. Protex est une moulinette sur-évoluée de code basée sur une base de données et de métadonnées complète, pouvant dès lors détecter à l'aide de génération de fingerprint (inutile de ne changer que le nom des variables et des procédures : ce sera détecté) les composants OpenSource lors d'un audit de code ; l'outil sait même reconnaître les conflits de licences. Dans l'industrie mobile, Intel, Samsung, Siemens, Motorola, Nec, RIM, LG, Qualcomm, Palm, Cisco, Xerox, Sega ou encore NTT ont fait appel à leur service : c'est dire si le problème est largement pris au sérieux ! Hervé Guyomard affirme par ailleurs que toutes ces entreprises intègrent d'une manière ou d'une autre des produits OpenSource dans leurs appareils.

Le dernier intervenant est bien connu à Linagora, puisqu'il s'agissait de Benjamin Jean, notre juriste. Pris dans le marasme des transports (RER D ?), il est arrivé bien en retard et a totalement raté les premières interventions : sans filet et sans slides, il essaie de faire original en pointant les sujets les plus importants : droits et obligations, extension de la licence (jusqu'où la licence couvre-t-elle ?), l'élément déclencheur aussi (souvent, il s'agit de l'utilisation, donc de l'exécution, mais il peut s'agir du simple téléchargement !). Il indique qu'un groupe de réflexion est actuellement monté au sein du SYNTEC informatique. Et qu'il a donné une conférence complète dont les slides peuvent être trouvées sur le net (sauf que je n'ai rapidement pas trouvé, il faut mettre son blog à jour, Ben ! ;)  ). Il en oublie de citer le groupe dédié aux problèmes de licences libres qu'il anime, Veni Vidi Libri, on sent la fatigue après trois conférences sur le sujet en trois jours ! On passe à la séance de question, qui tournent toujours autour des mêmes points, le plus crucial étant : où commence et où s'arrête ce qui est couvert par la licence ? (dans le public, un représentant de Vector présente son activité : c'est surprenant de voir ça sur le salon RTS ! On a totalement changé de monde) C'est que le problème est pernicieux, sur des systèmes embarqués dont la limite avec le userland est parfois assez floue (WindRiver vient d'ailleurs d'en implémenter un sur VxWorks : je parie que c'est pour répondre à ce genre de problématiques), et je discute après la conférence avec un ingénieur s'occupant de l'interfaçage juridique (on se demande d'ailleurs comment on pourrait nommer ce nouveau métier, que j'ai déjà rencontré chez Philips : je ne sais pas trop, mais ça m'intéresse comme évolution de carrière) de la possibilité de jouer avec les share memory, via une couche logicielle libre mais plus permissible, y pour interfacer des modules GPL avec du propriétaire (technique quelque peu utilisée par les hyperviseurs de paravirtualisation, après tout -- et j'ai déjà croisé un projet réel pour cela lorsque j'ai travaillé pour Trango). Mais il est vrai que la GPL parle d'un "tout logiciel" : nulle technique, au juge d'apprécier en cas de litige, donc au meilleur expert ès enfumage (et vulgarisation) de montrer ses prouesses, nous voilà fortement rassurés... Notons pour finir que les brevets n'ont pas été abordés (sujet connexe aux licences), et donc que l'affaire Tomtom n'a pas été évoquée, ce qui est dommage.

C'est ainsi que s'acheva la dernière conférence : j'en avais bien prévu une autre, sur les standards logiciels, mais manifestement elle a été annulée, certainement faute d'audiance, le dernier jour étant effectivement largement plus vide. J'ai pour ma part pu observer que le VME vivait toujours et plutôt bien, même s'il partage à présent l'affiche avec toutes sortes de PCI industriels. Côté processeurs, les nouveaux ARM Cortex ont évidemment la côte, occultant ARM9 et 11, d'autant que de nouveaux OMAP sur base Cortex apparaissent (les ARM7 étant remplacés par les M8, les autres étant A8, avec une évolution en faisant monter les chiffres à côté de chaque lettre -- la nommenclature ARM est toujours très sportive, seul Intel fait mieux) ; la puissance de ces processeurs fait apparaître des solutions à base de Java, où pour une simple application en stand alone, un OS est inutile (certains abandonnent de fait Linux), la VM faisant office de tout, y compris de scheduler entre les différents threads. Côté PPC, on trouve du PowerQUICC III, qui se porte toujours aussi bien dès qu'il s'agit de faire de la communication. Et puis la star, l'Atom, que l'on retrouve partout : il faut qu'Intel a enfin corrigé les énormes pertes d'énergie qui font que les netbooks meurent de fatigue au bout de deux heures seulement, et qu'à présent, on peut réellement concurrencer du ARM, avec moins d'automie mais plus de puissance, dit-on ; en tout cas, la solution étant viable depuis environ quatre mois à présent, le temps de concevoir des cartes et l'on a pu constater que l'engouement était très, très récent ; le PC104 et le Geode ont en tout cas totalement disparu ! Les nouvelles techniques de virtualisation en cours d'implémentation devraient aussi pousser dans ce sens, et Intel promet l'arrivée d'un adressage direct de la flash, sans passer par un contrôleur (ce qui est, rappelons-le, la lose totale) : on pourra ainsi, comme sur ARM, considérer flash et RAM de manière contigüe, et avec la promesse de pouvoir outrepasser le BIOS (ils travaillent avec Microsoft, me dit-on, car actuellement nul OS ne supporte cela : il faut dire que le BIOS -- pour l'instant incontournable sur l'archi x86 -- ne fait pas grand chose, il initialise principalement des périphériques PCI avant de lancer le bootloader, mais il est bien connu que Linux outrepasse depuis longtemps le paramétrage du BIOS, et que le projet FreeBIOS s'appelait avant LinuxBIOS car il s'est basé sur du code d'amorçage de Linux). Bref, Intel va inventer ce qui existe depuis 20 ans, on s'en félicite. En fait, je ne sais jamais trop si c'est une bonne nouvelle de voir débarquer en force une architecture aussi mal foutue que le x86 dans le monde de l'embarqué, déjà que près de la moitié des projets l'utilisent (pourquoi ? Parce que c'est connu, effet "j'ai le même dans mon PC", psychologie commerciale basique...). Cependant, Linagora se fera une joie de développer vos applications sur ce type de processeur, nous avons d'ailleurs achevé un projet majeur sur plate-forme à base de Pentium M (qui, s'il n'avait tenu qu'à moi, tournerait sur PowerQUICC III).

Je n'ai malheureusement rencontré que fort peu de monde connu dans les allées de RTS, j'ai eu la joie de tomber par le plus pur hasard (je revenais de SL alors qu'il s'en allait) sur mon ancien chef de projet chez Sagem, à qui j'ai donc enfin pu demander des nouvelles de notre bébé, le MO300e (module Neptune avec Nucleus+Linux) : eh bien c'est une totale déception commerciale, les clients potentiels préfèrent une implémentation à deux CPUs, un OMAP très simple et rigide allié à un ARM9 très souple comportant son propre Linux customisable. Moralité : peu importe la dose de technique que l'on met dans un projet (en l'occurrence, le MO300e c'est de la virtualisation maison, une interface web pour administrer le Linux et notamment gérer ses propres applications additionnelles, une sécurité parfaite, un SDK facile à mettre en oeuvre où j'ai même incorporé un système facilité d'émulation, etc) tant qu'on n'adresse pas le bon marché, et que l'on ne répond pas aux attentes des clients. De peur de ne pas pouvoir faire face aux demandes de support Linux, le périmètre a été fortement réduit, avec notamment l'impossibilité de charger des modules personnels dans le noyau, figé au 2.6.18 : la solution étant fortement industrialisée, il n'y avait pas vraiment le choix, et la mise à jour de firmware est une plaie, puisque nous sommes sur des LU, les Logical Units, entièrement chiffrées puisqu'ayant accès au réseau GSM (je pense cependant qu'une solution pouvait être envisagée pour mettre à jour à chaud, mais la demande en mémoire flash aurait été trop coûteuse) : comme quoi mettre un seul chip est plus économique mais trop spécifique dans ce cas pour adresser un large marché aux besoins très divers. Bien dimmensionner veut aussi dire d'étudier le marché, et de ne pas ignoré -- comme cela avait été le cas à l'époque -- les demandes pressantes des clients sur certains points techniques ; une récente discussion par mail à ce propos avec une société de M2M autrichienne a confirmé cette tendance (après avoir testé durant quelques semaines le produit -- ils m'ont demandé quelqu'aide par mail, car la réactivité de Sagem n'était pas terrible --, les dernières nouvelles étaient que leur avis sur la viabilité du produit était de plus incertaine, et que Wavecom semblait être, à regret, de nouveau la "meilleure" solution).

J'aurais en tout cas bien voulu échanger quelques mots avec mes collègues de l'APRIL Sébastien Dinot et Thomas Petazzoni, recontrer enfin David Chabal, croiser Patrice Kadionik et Pierre Ficheux qui j'en suis sûr connaissent plus mon visage que mon nom (ou l'inverse, allez trop savoir, mais il y a un manque certain de corrélation :)  ), deviser avec Denis Bodor de Linux Mag' (mais il était tout le temps occupé, je lui enverrai un mail), ou me faire présenter au pôle édition d'Eyrolles (parce que finalement, à part un peu "Embedded Linux Primer", dont l'auteur a d'ailleurs écrit dans le "Electronique" du mois de mars distribué gratuitement, il n'y a jamais de technique pure et concrète de "comment embarque-t-on du Linux", ce qui est un peu un comble pour des bouquins de Linux embarqué au nombre de quatre ou cinq, qui restent pourtant très bons ! Bref, je caresse une certaine idée...). Il y avait du monde sur SL, mais il était difficile de le rencontrer. Patrick Sinz était en tout cas sur le stand de Emtec (ex-BASF), pour présenter le Gdium (il bosse maintenant pour Gdium SA, basé au... Luxembourg, hum), et d'autres STB/disques durs multimédias de la marque.

Pour conclure (comment ça, "enfin" ?), mon avis sur les deux salons est positif mais avec une petite réserve sur un sentiment diffus d'essoufflement ; comme je fais la même remarque chaque année, ça ne doit pas être si grave (et puis, c'est la crise). Mon principal regret est la disjonction des deux salons. Un workshop géant pour Linux embarqué me semble être la meilleure idée, à la condition que les deux salons soient très proches (il aurait été possible d'avoir une continuité physique, les locaux sont prévus pour à la porte de Versailles !), ou alors qu'ils ne tombent pas aux mêmes dates, comme avant. Dans ce workshop (sur le salon RTS, s'entend, il faut que cela reste gratuit), il serait idéal d'adresser toute sorte d'intervenants, de milieux divers (industriels, CE, M2M, comm', etc), des enseignants et formateurs (quelques uns se baladaient sur le salon, ai-je appris sur le stand de Neomore), des libristes (pourquoi pas aussi des gens du monde BSD, eux aussi ont des choses à apporter à l'embarqué ! Soekris était d'ailleurs présent cette année encore sur SL), des entreprises de type intégrateur ou de service (c'est ici que peut entrer Linagora, outre l'aspect formation et juridique), en plus des habituels éditeurs, et enfin, élargir le scope avec du juridique (licences et brevets) ; je rêve d'un village associé à un cycle de conférence techniques ; et de retours d'expériences qui forgent des liens entre visiteurs (et pas seulement entre exposants et visiteurs), d'autant que Linux s'embarque sur des appareils tellement divers et spécifiques qu'il est toujours très intéressant d'en embrasser une vue la plus globale possible.

Concernant la diffusion de Linux et bien plus encore celle du logiciel libre dans l'embarqué (on pense aux méga-stars que sont gcc et Eclipse : on les trouve partout, soit bien plus encore que notre kernel favori), on peut dire que l'évolution atteint une sorte de vitesse de croisière : ceux qui attendaient pour migrer l'ont presque tous fait, et les nouveaux projets peuvent choisir parmi une gamme de solutions complète, où Linux prend une place importante, mais en dehors de tout effet de mode et de tout engouement irréfléchi. De nombreux partenariats ont été formés avec les principaux éditeurs de BSP, Montavista, WindRiver et Sysgo, de telle sorte que les fournisseurs de hardware peuvent répondre aux attentes de leurs clients, manifestement mieux informés qu'auparavant (cinq ou six ans que l'on évangélise, aussi). Cependant, le logiciel s'est trouvé de fait dans un certain recul -- je compte de tête cinq stands dédiés au soft "génériques", c'est-à-dire outre le spécifique de contrôle-commande ou d'analyseurs --, assez important même par rapport aux années précédentes, de telle sorte que j'ai bien peur que les acquis des années précédentes ne se perdent, d'autant que l'évolution du libre et du monde du CE est rapide. Sur les stands, on a souvent avoué un manque d'expertise dans les domaines que nous adressons, et il faut ajouter à cela les demandes en formation comme en renseignements juridiques solides. Il faut cependant bien se rendre compte de l'inertie toujours flagrante du milieu, fonctionnant selon une certaine logique de "cercles de confiance", et même si les accueils reçus étaient toujours chaleureux et intéressés (y compris à des endroits que je ne soupçonnais pas, comme le concepteur de fonds de panier PolyRack), nous verrons combien d'affaires peuvent nous être adressées...

J'espère cependant qu'elles seront assez nombreuses pour me permettre de justifier de nouveau deux jours et demi de visite sur les salons, mais aussi faire exploser le chiffre d'affaire du pôle embarqué, dont une commission me sera évidemment reversée (pas vrai patron ? ;)  ). Plus sérieusement, les retours seront certainement à mesurer d'ici les six prochains mois (j'ai déjà reçu un coup de fil, mais pas d'affaire sur le court terme), espérons simplement de leur positivité, en attendant de se faire encore mieux connaître. À noter cependant une évolution des mentalités avec une attention particulière portée au TTM, pour lequel Linux peut battre des records pour peu que l'on soit bien entouré ; cela rejoint clairement le sentiment dégagé lors du salon ARM. J'ai oublié de prendre des photos, cette fois-ci, d'ailleurs. On attend à présent les slides des conférences, pour information ARM m'a envoyé celles de leur salon sur CD-Rom, disponible à mon bureau.

Il n'y a plus qu'à remercier encore une fois les différents organisateurs des deux salons pour cette édition 2009, et donner rendez-vous à tous pour l'année prochaine !

lundi, décembre 15 2008

le libre contre-attaque

Ouch, coup sur coup, une attaque de trois développeurs (avec la FSF France en sous-main, n'en doutons pas trop) contre Free, ce qui leur pendait au nez depuis un bon bout de temps, suivi juste ensuite d'un attaque de la FSF (tout court) contre Cisco (via Linksys) : mêmes raisons, mêmes effets et même milieu. Celui de l'embarqué, bien sûr. Deux box, l'une de type modem/Set Top Box (Freebox), l'autre de type routeur évolué de maison (WRT54), comprenant de manière certaine des Linux (avec Netfilter), des busybox, des libC, et que sait-on d'autre, mais pas de code redistribué en contre-partie. Pour l'instant, les deux parties sont présumées innocentes (je précise, parce qu'à 6h30, je dors, et que je tiens à mon intimité -- et mon bon PDG, responsable de ma publication même s'il ne doit me lire que bien peu, certainement aussi, d'ailleurs je précise au cas où un Capital aurait été raté qu'il est pilier au rugby !), mais que se passera-t-il en cas de condamnation ?

Eh bien c'est simple : outre les dommages et intérêts à déterminer (pour Free, on demande 10 millions d'Euros, soit grosso modo pour chacun des trois 1€ par box, ce qui est fort peu : certaines royalties tapent dans les 5$, pour des softs franchement bidons que nous ne citerons pas pour des raisons évidentes), il faut faire cesser le litige (sous peine d'astreinte) : deux choix s'offrent alors. Soit on écoute la bonne licence et on libère le code, c'est-à-dire que l'on fait disposer à tout un chacun le demandant (et pouvant s'en prévaloir : il faut avoir acheté l'appareil concerné) un CDrom les contenant, ou alors on ne s'embête pas et l'on tient un ftp public (regardez comme ils sont sympas chez Sony : Linux, busybox, uClibc, cross-gcc, et p'têtre deux ou trois autres trucs, pour chaque appareil, tout simplement, d'ailleurs ils devraient mettre en toute rigueur les scripts de compil, mais ils ne le font même pas). Soit, deuxième solution, on rapatrie les box et on change tout le logiciel, mais je crois que ça risque de coûter assez cher (c'est mon petit doigt qui me le souffle), et que ça ne vaut pas vraiment le coup (sinon, Linagora se propose de tout vous faire migrer sous BSD, on peut vous faire un prix d'ami je pense, c'est bientôt les soldes).

Ou alors on paie l'astreinte, mais tout le monde n'est pas Microsoft (heu, c'est de notoriété commune, c'est pas de la diffamation, hein chef ?). On ne badine pas avec la GPL, à bon entendeur... Pour ma part, j'ai vécu aussi des choses assez ubuesques, comme des demandes explicites de ne surtout pas changer une seule ligne de code d'un programme libre (même pour quelque chose de très bête, qu'il a fallu contourner à grands coups de scotch et de ficèle), pour ne pas avoir à la redistribuer ensuite (on ne parle même pas de faire l'effort de la réintégrer auprès de la communauté, comme s'engage Linagora à le faire plusieurs fois par jour !). Ce n'est pas pour rien que j'insiste toujours sur le côté juridique de mon cours, partie qui assomme régulièrement mes étudiants, pressés de brancher leur premier câble RS232 (pour avoir... un prompt, c'est qu'on est heureux avec peu, lorsqu'on est jeune).

Et Linagora dans tout ça ? Eh bien... notre projet de logiciel embarqué, qui nous occupe depuis un bon bout de temps, est sous BSD (OpenBSD). Forcément, ça fait moins de problèmes juridiques à l'arrivée (mais juste juridiques... Et à vrai dire, ce n'était pas pour une question de licence que cela a été choisi ainsi : embarqué ne veut pas dire accessible à tout un chacun ! Seul le client peut se prévaloir de la licence et réclamer les sources couvertes par la GPL). Sinon, nous dispensons aussi des cours en Droit Individuel à la Formation, par Benjamin Jean, une pointure vous dis-je, et si ce n'est certes pas donné, il faut bien se dire que des conférences pleines au salon RTS il n'y en a qu'une par an (et... il n'y avait pas vraiment de juriste présent, d'après mes souvenirs), et puis que ça peut faire économiser potentiellement un procès et 10 millions d'Euros pour couvrir à tout prix (c'est le cas de le dire) des NDAs ou une sécurité foireuse que l'on n'avait pas pas bien considérés avant, en fait...

vendredi, novembre 14 2008

pourquoi le "GNU/" de GNU/Linux revêt toute son importance dans l'embarqué

On connaît la bataille de clochers entre libristes, ou du moins entre fervents libristes de l'église de St-GNU et ceux qui promeuvent le libre uniquement pour supériorité technique -- tels Linus Torvalds : faut-il dire "Linux" ou "GNU/Linux" ? Pour ma part, je me sers de l'expression "GNU/Linux" dans mes interventions afin de bien différencier ce qui relève du noyau "Linux" de ce qui relève du système libre "GNU". Car on peut fort bien utiliser GNU sans Linux, par exemple avec des environnements Cygwin, gcc, gdb, OpenOCD, Eclipse, pour des systèmes propriétaires tels que VxWorks, LynxOS ou QNX (qui ont tous trois des SDK basés sur les logiciels libres précédemment cités ! Et peuvent en partie utiliser des logiciels libres, sans que cela constitue l'intégralité du système hors noyau). La question d'utiliser Linux sans GNU se pose aussi : certains diront que le projet Busybox ou que la uClibc n'en font pas partie, cependant on peut pondérer cette assertion sur le fait que la licence est la GNU/GPLv2, et qu'à vrai dire je ne suis pas convaincu du tout qu'un projet comme la busybox ne soit amusé à recoder les plus de 200 logiciels regroupés qui la composent, notamment des aussi complexes que vi ; quelque part, tout est issu plus ou moins du projet GNU.

Mais peu importe à vrai dire, car le message technique associé pour l'embarqué et la redéfinition des relations associés à l'emploi de (GNU/)Linux est le suivant : le système d'exploitation hors noyau est indépendant dans une large mesure du noyau lui-même. C'est-à-dire qu'il a été conçu certes en utilisant par exemple des IOCTL propres à Linux, d'une manière marginale, mais surtout sur une base POSIX la plus indépendante possible, puisque le projet de noyau de GNU reste avant tout le Hurd. Et que donc même la libC (glibC) est fondé dans cette optique-là. Ceci est une différence fondamentale avec le projet libre OpenBSD, par exemple : ne désignant pas seulement le noyau mais l'ensemble du système d'exploitation complet, même si le noyau /bsd est bien délimité (contrairement à Windows, par exemple, où l'on ne sait jamais très bien où ça commence et où ça finit), le système forme un tout homogène et surtout inséparable dans ses versions. C'est-à-dire que non seulement il est bien spécifié que l'on ne doit pas s'amuser à mélanger les versions de logiciels, car sinon aucun support ne sera assuré par la communauté, mais en plus de cela il y a réellement des problèmes dans la réalité (on aurait pu croire à un simple warning anti-n00bs, comme le découragement de recompiler à partir des sources).

Sur un projet récent j'embarquais de l'OpenBSD 4.2 ; manque de chance, le support de la carte flash était très lent sur cette version, alors que sur la version 4.3 sorti entre temps, cela allait beaucoup mieux. Nul problème quant à une mise en production (le gain est faible sur de petites tailles à écrire, et aucune échéance de temps n'était à respecter absolument), mais gros problème quant à la mise en place usine de master complet sur une mémoire d'un giga octets : la décision fut prise d'utiliser en interne, pour l'opération de flashage, le noyau d'OpenBSD 4.3 sur le système 4.2 longuement mis au point. Et un problème arriva rapidement : le but étant de flasher une image téléchargée sur le réseau via notre ramdisk hybride 4.2/4.3 (opération très classique inspirée par la méthode de gestion de parcs via PXE), une configuration réseau via ifconfig était nécessaire, et autant un ifconfig <interface> <ip> passe très correctement, autant un ifconfig tout court renvoie les pires erreurs imaginables, au lieu de lister les interfaces et leurs propriétés. On ose imaginer ce que cela donnerait pour des programmes plus complexes dont il faudrait retester toutes les options possibles pour s'assurer du bon fonctionnement complet du système : ce n'est pas envisageable !

Fort heureusement, cette éventualité d'impossibilité de pouvoir changer le noyau seul sans le reste du système, ou inversement, avait été évoqué dès le début, et cela ne pose aucun problème à notre projet (il n'est pas impossible de patcher manuellement des logiciels particuliers et d'en assurer la rétrocompatibilité, cependant, mais on ne saurait changer totalement de version). Cependant, ce genre de problématique est à prendre à compte dès lors que l'on souhaite obtenir un système pouvant être mis à jour de manière massive, par exemple lorsque Nokia décide de changer l'interface complète de son système basé sur Maemo (incluant une mise à jour de la libC) ; en l'occurrence, leur choix de reposer sur un ramdisk pour Linux a eu pour avantage la possibilité de mettre à jour le noyau pour activer au passage le support de l'EABI (ce qui impliquait à l'époque du noyau 2.6.16 une recompilation totale du système ; il existe à présent une fonctionalité de rétrocompatibilité avec/sans EABI marquée expérimentale dans le kernel), mais cela ne saurait être toujours le cas (notamment parce que cette solution de ramdisk implique un temps de boot allongé, c'en est même indécent sur le N770) : comme nous le disions la dernière fois, ne serait-ce que pour des questions de sécurité, positionner le noyau en flash au dehors de tout file system est pratique extrêmement courante (on remarquera d'ailleurs l'option "-kernel" de qemu qui permet de faire booter un système de fichier en utilisant un kernel Linux externe). Il est donc souvent inenvisageable de mettre le noyau à jour (on peut toujours faire des dd avec seek pour écrire dans /dev/mem en raw, en calculant de ne pas déborder et en serrant les fesses... Je ne conseille pas !), alors que le système peut être appelé à évoluer (la mode est au reflashage de firmware ajoutant et corrigeant des fonctionnalités, les téléphones proposent cela, toutes les STB des FAI du marché aussi).

On peut élargir cette vision ultra-modulaire des choses au noyau Linux lui-même, qui hérite en sa conception intrinsèque de cette philosophie : alors que le noyau BSD forme un tout dont on déconseille très fortement de toucher à quelque option que ce soit (et il n'y a qu'à voir le fichier de configuration pour s'en convaincre), le mode de compilation de Linux se base sur une interface (en ligne -- make config --, en curses -- make menuconfig --, en Qt -- make xconfig --, ou en GTK -- make gconfig), où l'on coche et décoche ce que l'on souhaite (avec quasiment toujours la possibilité de mettre un support kernel en module chargeable et déchargeable à chaud), et uniquement cela, on peut même penser à activer le support des modules et tout mettre en dur, en prévision du jour où l'on voudra supporter des matériels brachés sur un hypothétique USB, et que l'on voudra alors supporter en ajoutant un driver au système (y compris rajouter le support d'un système de fichier : je suis bien content de pouvoir brancher mon disque dur en XFS sur mon disque dur multimédia, et j'aimerais bien que ce support revienne comme avant sur ma Freebox). La configuration de Linux supporte en outre la gestion des dépendances des modules les uns aux autres, et au final, alors que le projet OpenBSD dont la cible est l'informaticien expérimenté est peu propice au bidouillage, les sites pour utilisateur débutant de Linux proposent des tutoriels de (re)compilation du noyau !

Lorsque l'on voit sur distrowatch l'hétérogénéité des versions logicielles utilisées pour de mêmes kernels Linux (qui eux-mêmes ont un nombre de versions différentes très important, et non une release chaque semestre), ou inversement d'ailleurs (de mêmes versions logicielles pour des kernels différents), on voit bien que le problème ne se pose pas pour GNU/Linux : sa conception modulaire puisqu'agrégative de projets différents (GNU, Linux, autres projets de l'embarqué greffés sans pouvoir préjuger des autres logiciels employés, la Busybox marchant tout aussi bien avec la glibC qu'avec l'uClibc), assure une supériorité technique indéniable. Si l'on considère que les autres projets propriétaires de l'embarqué ont toujours été conçus comme le sont les projets BSD (incompatibles entre eux par ailleurs), on peut donc préjuger là encore d'un avantage majeur de l'emploi du noyau Linux et des projets libres utilisés pour consituer un système d'exploitation complet, dans la droite ligne de ce qui est attendu d'un système embarqué moderne gérant la communication, et donc potentiellement la mise à jour, tout autant que la possibilité de faire "librement" son marché entre les versions logicielles, amenant au problème du packaging (il faut choisir des versions logicielles compatibles entre elles, bref gérer la problématique propre à toute distribution Linux, qu'elle s'appelle Debian, OpenSUSE ou OpenEmbedded), mais aussi à sa puissance incomparable et jamais égalée par aucune autre solution logicielle existante.

jeudi, novembre 13 2008

formats ouverts dans l'embarqué

J'espère m'être bien fait comprendre sur ce point dans ma dernière conférence -- j'ai plus le temps d'insister dessus en cours --, mais Linux embarqué ne fait pas tout, et ouvre même à de nouveaux problèmes afférents à ce genre d'appareils pour lequel on a besoin d'un système si complet : le stockage des données. On peut considérer (c'est plus simple pour se le figurer) une problématique de lecteur audio ou vidéo, qu'il soit portable ou du genre Set Top Box, en passant par l'à présent inévitable smartphone. Lorsque l'on est sous Linux dans l'embarqué, on peut avoir tendance à se laisser emporter, et mettre trop de choses dans la boîte : je veux parler de logiciels pouvant être victimes des brevets américains. Evidemment, tout dépend du marché, mais on sait que sur ce point-là, les étasuniens se sont fait une spécialité d'embêter le monde, mondialisation oblige, justement. Parfois, ça se retourne contre eux : Alcatel assigne en justice Microsoft qui s'arrogeait des droits sur le brevet du MP3 (et donc en retirait fortes sommes d'argent), alors que la société française venant d'acheter Lucent soutenait que c'était cette dernière boîte américaine à qui la redevance revenait de droit ; quelques milliards d'Euros plus tard, nos vaillant concurrents de Linux perdirent cher (mais le procès est toujours en appel, me semble-t-il).

Le MP3 est ainsi la bête noire à ne pas sous-estimer. Certaines distributions européennes (comme la Mandriva) ont même décidé de ne pas supporter MP3 ou autre MPEG2 par défaut, et de laisser le soin aux utilisateurs de prendre leurs responsabilités en fonction du pays où ils habitent (civilisé ou non) afin d'installer les logiciels libres nécessaire au déchiffrement de ces formats. Contrairement aux DVD chiffrés, les MPEG sont pourtant documentés, mais voilà, les lire expose à payer des droits, et des entreprises à l'origine de leur découverte -- comme Philips -- traquent littéralement les contrevenants. On les aura vu s'illustrer sur un stand, lors d'un salon, de Sandisk, où tous les lecteurs furent retirés. Voilà donc qu'à présent, le projet libre OpenMoko serait lui aussi menacé (je ne trouve en revanche rien à ce sujet chez eux, si ce n'est ceci, qui montre à quel point tout cela est ubuesque). Tout support du MP3 (et toute mention aussi) a pour l'instant été retiré.

Il y a une conclusion morale à tout cela, et la chance étant avec nous, grâce au libre. Car il existe un format ouvert pour l'audio particulièrement adapté à l'embarqué, puisqu'il compresse beaucoup, beaucoup mieux que le MP3, tant en terme de taille (compter moitié moins) que de qualité (bien meilleur sur tous les plans !) : c'est le ogg Vorbis.

Tout serait bien alors, mais il existe encore une subtilité pour ces lecteurs : les protocoles de communication, eux aussi dans le même esprit que les formats. Aussi, certains lecteurs Samsung (pas le mien, j'ai fait attention, justement) qui lisent du ogg ne sont pas forcément si ouvert que cela : ils utilisent le MTP, protocole fermé développé par Microsoft (encore et toujours...) qui aura été patiemment reverse-engineeré pour son support sous Linux. Le chemin sera long avant l'ouverture totale des systèmes, Linux Embarqué n'est qu'une pièce du puzzle, l'enjeu est bien plus grand que cela, mais la tendance actuelle visant à embarquer du Linux (et donc du libre, dans une optique d'éviter les royalties ou autres redevances à la limite du racket) ouvre les esprits sur ces problèmes fondamentaux. Avant l'abandon, espérons-le, des brevets logiciels, absurdes au possible, et du non-sens de ces protocoles de communication fermés (c'est un oxymore, n'est-ce pas ?), en n'oubliant aussi les DRM de toutes formes.

En attendant, n'oubliez pas de mettre du ogg pour l'audio, du theora pour la vidéo, et des png pour les images, le tout communicant par direct storage access, ou par FTP.

mercredi, novembre 12 2008

embedded virus

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.

mardi, novembre 11 2008

conférence Paris8

Dans le cadre des conférences menées au sein du département d'informatique de l'Université Paris 8 (Master professionnel Informatique des Métiers et des Applications), j'ai pu mener auprès des étudiants de Master (et notamment les M2 spécialisés en Informatique et Systèmes Embarqués), une conférence sur Linux embarqué. Sujet qui recouvre toujours plus que Linux mais le libre en général, même si notre kernel favori constitue évidemment l'essentiel du sujet. Voici donc les slides sous licence libre FDL, au format OpenOffice.org (3,2mo) et au format pdf (1mo). J'ai aussi effectué une démonstration avec la carte SBC2440, dont on trouvera des détails par là.

Je tiens à chaleureusement remercier Isis Truck pour avoir organisé cette rencontre avec un public nombreux (une quarantaine ou cinquantaine d'étudiants, dirais-je). La séance de questions fut assez brève, mais il est tout à fait possible d'en poser ici-même en commentaire. Mon attention a été attirée sur QNX, microkernel (Neutrino) et système d'exploitation complet certes très connu (de nom du moins) dans le milieu industriel, mais pas si répandu que cela, du moins pas autant qu'il ne devrait l'être si l'on considère ses performances objectives ; après avoir pris connaissance de la licence prise de tête pour une utilisation non-commerciale, je pense qu'il ne faut pas chercher plus loin l'explication du succès de Linux sur QNX, pourtant présent sur le marché depuis le début des années 80, et ayant commencé à s'ouvrir trop tardivement, après la montée en puissance constatée de Linux (virage qu'ont dû aussi prendre WindRiver ou LynuxWorks, ce dernier ayant changé de nom pour l'occasion en ajoutant un "y").

C'est ainsi qu'encore une fois, malgré les incertitudes qui règnent dans les esprits à son sujet, la licence GNU/GPL se montre supérieure : le même constat peut en effet être observé avec le système BSD, longtemps tout à fait meilleur que Linux sur tous les points, mais qui n'arriva jamais à percer, malgré plus de 10 ans (si ce n'est 15) d'avance dans le développement. Aussi, le micronoyau L4, projet universitaire lancé en 99 et dont la version 1.0 date de 2003, a déjà été récupéré plusieurs fois, notamment par l'équipe d'OpenKernel-Labs pour OKL4, le projet de paravirtualisation temps-réel pour l'embarqué courroné de succès. Son secret ? L4, outre qu'il est intelligemment et efficacement conçu, est sous GNU/GPLv2 (additionné d'une licence commerciale, comme Qt) depuis son lancement, tout simplement.

jeudi, octobre 30 2008

portage Linux 2.6.25 et 2.6.27 sur carte Embest 2440, via J-Tag

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\n",
                               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\n");
                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...).

mercredi, octobre 29 2008

Linux Device Driver en ligne

Je ne le savais point jusqu'à hier, c'est ici, et c'est sous GNU/FDL. C'est la seconde édition de Alessandro Rubini et Jonathan Corbet, juin 2001, ça date un peu, mais ça évite toujours de transporter son propre exemplaire (et pour faire des recherches, c'est plus rapide aussi :)  ).

lundi, octobre 27 2008

regrouper pour moins régner

Quelle idée ! Quelle mauvaise idée ! Les salon RTS et le salon Solutions Linux seront aux mêmes dates, les 31 mars, 1er avril et 2 avril. Petite consolation, ils seront au même endroit, de telle sorte qu'il sera possible de s'inscrire aux deux (qui ne marchent pas de concert, RTS est toujours associé à DISPLAY et M2M, mais c'est tout), et naviguer de l'un à l'autre, mais quand on sait que des exposants étaient communs, des conférences recoupaient les mêmes thèmes, de telle sorte que l'on avait une petite vision de l'évolution entre février et avril, l'occasion de voir des personnes différentes, ou encore de pouvoir se rattraper sur l'un ou l'autre en cas d'indisponibilité, voilà qui est à présent impossible, et va concentrer sur une date unique (ne rêvons pas, combien d'entreprises vont permettre à leurs employés de faire deux jours de salon d'affilée, avec parfois des conférences payantes ?) deux visions différentes (et forcément incomplètes de chaque côté, puisque complémentaires entre elles) de Linux embarqué. Aïe ! J'espère que les dates évolueront, mais comme le CNIT est fermé et que la porte de Versaille a des réservations très strictes, je crois que c'est mort.

OKL4 et Android

OKL4 attaque le marché des téléphones portables, et pas qu'un peu : voilà annoncé sur CNBC (étrangement, la page officielle sur OK-labs a disparu) la partitipation à l'élaboration du premier téléphone portable basé sur Android de google, comprendre que le Linux est paravirtualisé par la solution australienne (au côté d'un Nucleus ?), celle-la même sur laquelle mon ancien stagiaire travaillait, et a participé en tant que membre très actif de la communauté (mailing list, wiki d'aide, etc). Sur un marché bien différent de celui de Linagora, mais dont on peut espérer un certain recoupement et même, qui sait, une collaboration dans des domaines de compétences complémentaires, voilà une société du libre (le code est sous double licence, sur un modèle de Qt de Trolltech) qui réussit !

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

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

- page 1 de 2