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

Dans les entrailles du Libre

dim., 10/12/2017

Compte rendu des JM2L 2017

Le samedi 25 novembre dernier, j'ai représenté avec Nicolas Chauvet l'association Borsalinux-fr dans le cadre de la Journée Méditerranéenne du Logiciel Libre.

JM2L-Stand.jpg

Bien qu'il y avait moins de visiteurs que lors de la précédente édition en 2015, nous avons pu discuter ou aider avec une quinzaine de personnes à propos de Fedora. Que ce soit des utilisateurs de longue date, ou de simples curieux.

Le matin nous avons été interrogé par France 3 Côte d'Azur (dont la diffusion a été le dimanche 26 au soir au JT local) à propos des Logiciels Libres en général. Je précise que contrairement à ce qui est indiqué sur l'image, je ne suis pas un employé de Red Hat. C'est une erreur de la journaliste en question. De même, l'équipe de Nice-Matin a couvert l'évènement avec une belle photo de groupe des participants.

L'après-midi nous avons continué le stand et j'ai présenté ma conférence à 15h sur Les apports de Fedora Workstation à l'écosystème du Logiciel Libre. Elle a été suivie par une quinzaine de personnes. L'ensemble du contenu sera disponible bientôt sur quelques sites web francophones dont mon blog.

C'était une chouette journée, bravo aux organisateurs et à dans deux ans pour une prochaine édition !

dim., 22/10/2017

Changement de pâte thermique sur mon ordinateur portable

Il y a parfois des tâches d'entretien d'un ordinateur qu'on oublie de faire et qui pourtant sont essentielles.

Le changement de pâte thermique en fait parti. La pâte thermique est ce qui permet d'améliorer la conductivité thermique entre le processeur (ou le GPU) et le radiateur dédié à évacuer cette chaleur. Il permet de gommer les aspérités des deux surfaces pour augmenter la surface de contact et éviter la présence d'air qui est un bon isolant.

Mais la pâte thermique n'est efficace que quelques années, ensuite il commence à se fissurer, à se décoller et donc à ne plus remplir correctement sa fonction. Il est nécessaire de le remplacer.

Mon ordinateur est un HP Elitebook 8560w qui vient de fêter ses 6 ans d'utilisation. Depuis quelques semaines / mois, la température était constamment entre 80 et 100°C, même si je ne faisais rien de particulier. C'est bien trop chaud. Du coup le processeur se mettait en économie d'énergie pour éviter la surchauffe ce qui dégradait les performances.

Je me suis décidé à régler le problème, ne prévoyant pas de changer de machine avant quelques mois.

Matériel

Coût total, moins de 30€.

En effet, ma machine possède beaucoup de vis Torx, puis pour éviter d'abimer la machine j'ai préféré avoir un outil très fin pour séparer les éléments et avoir de quoi gratter la pâte thermique. D'où l'achat des deux sets qui permettent globalement de démonter pas mal de machines en théorie.

Une petite pince est assez appréciable pour manipuler les petits connecteurs.

Opérations

Avant de commencer, pour éviter de faire des erreurs, j'ai préféré consulter une vidéo du démontage avant.

Comme beaucoup d'ordinateurs portables, accéder à la carte graphique et au processeur n'est pas évident. Il faut pratiquement tout retirer de la partie basse de la machine : clavier, touchpad, disque dur, lecteur CD... En fait il ne reste qu'une partie du châssis et la carte mère.

On retire donc l'ensemble du module de refroidissement qui est commun pour le processeur et la carte graphique. En effet, chacun a son radiateur qui communique la chaleur à un ventilateur et à un radiateur externe commun. Cela rend l'opération un peu plus pénible.

Vous pouvez voir le module démonté :

IMG-20171020-WA0001.jpg

Et la carte mère, avec le CPU sur la gauche, la carte graphique sur la droite :

IMG-20171020-WA0000.jpg

Bien entendu il faut ensuite tout remonter, sans se planter sur les vis. Essayer de bien réintégrer les éléments (ce dont j'ai échoué la première fois, notamment le connecteur pour les touches de la souris qui n'a pas été bien enfiché). Allumer la bête et tester que tout va bien. Et ouf tout fonctionne.

Résultats

Maintenant mon ordinateur au repos fonctionne entre 60 et 80°C. Les 100°C ne sont atteints que lors d'une activité intensive. C'est quand même bien plus sympa, à l'usage j'ai moins de ralentissements, l'utiliser sur les genoux est possible sans se brûler.

Pour un peu moins de 30€ et près de 3h à s'en occuper le résultat est très appréciable. N'hésitez pas à le faire si votre machine chauffe trop (et si bricoller un peu ne vous fait pas peur). ;-)

mar., 17/10/2017

Un processeur qui perd le nord

Retour trois années en arrière quand je me penchais sur la gestion du stockage de masse d'un projet professionnel. C'est toujours avec le fameux processeur 8148 de Texas Instrument, le même projet que pour l'épisode 1.

Le stockage de masse est assuré par une mémoire flash NOR. En réalité l'implémentation n'était pas le principal problème, je vais raconter à nouveau un bogue assez délicat à identifier.

Mais d'abord, contexte !

Contexte

Choix de la mémoire

Donc sur ce projet, comme tout projet avec un système embarqué, se pose la question du stockage du système d'exploitation, des données et de comment charger le tout.

Il y a en général plusieurs possibilités pour un tel système : une mémoire NAND, NOR, une carte SD, une mémoire eMMC (une carte SD soudée), une clé USB voire via Internet. Bien entendu, chaque support a son lot d'avantages et inconvénients, voici pourquoi le NOR a été choisi :

  • Il est très fiable sur la durée (bien plus que les flashs NAND ou les mémoires SD/eMMC) ;
  • Sa lenteur n'était pas impactant pour notre système (c'est en effet de tous la méthode d'accès la plus lente) ;
  • Son espace de stockage (256 Mio) pour son prix était suffisant, sachant que la NOR est plus cher au Gio que les autres dispositifs ;
  • Il est possible d'exécuter le système en place (c'est le mécanisme XIP pour eXecute In Place) ce qui économise de la RAM et simplifie la conception.

Le dernier point est une propriété intéressante. En fait le processeur est capable d'adresser directement dans la mémoire NOR, les instructions machine du genre exécuter la fonction de cette adresse n'a pas besoin d'être chargé en RAM, le processeur peut accéder à cette adresse depuis la NOR et exécuter la dite fonction sans charger le code au préalable.

Préparation

Cependant, la dite technique XIP nécessite d'être précautionneux. Tout d'abord, le processeur au départ n'a pas accès à tout l'espace de stockage que propose notre mémoire.

Car dans le monde ARM (ce qui suit reste plus ou moins valable avec d'autres architectures, potentiellement avec d'autres noms), quand nous appuyons sur le bouton d'alimentation de la carte, l'alimentation démarre le processeur qui lance un petit chargeur de démarrage située dans sa ROM et qui a été conçu par le fabricant de la puce, ici Texas Instrument. Il va initialiser le minimum nécessaire dans le SoC et essayer de charger du code depuis un espace de stockage (notre mémoire NOR bien entendu ici, mais cela peut être par Ethernet, USB, mémoire NAND, carte SD ou autre). Dans notre cas, nous avons configuré (matériellement, en mettant des pins du processeur à 1 et d'autres à 0) de sorte que ce chargeur de démarrage cherche notre système sur la carte SD (car durant le développement, nous avons une carte SD), et si rien n'est trouvé, charger depuis la NOR.

Ce sont des mécanismes assez simples derrière. Pour le démarrage SD, le processeur détecte si une carte est présente, essaye de trouver un fichier nommé MLO dans un système de fichier FAT de la première partition pour le charger. Pour la NOR, il vérifie si les 4 premiers octets (situés à l'adresse 0x08000000) sont non nuls (donc différents de 0xFFFFFFFF ou 0x00000000). Si le chargement est effectué mais que cela n'aboutit sur rien, le processeur sera bloqué. Donc il faut veiller à charger quelque chose de correct.

Et pour charger le code initial (dans notre cas notre propre chargeur de démarrage U-boot, qui chargera Linux, qui chargera le reste des applications), le chargeur de démarrage de Texas Instrument n'a pas besoin de tout charger. Essentiellement car c'est plus simple, mais aussi parce que c'est plus générique, toute mémoire NOR pourra être chargée à priori quelque soit sa taille réelle.

Donc il ne charge que les 4 premiers kiloctets disponibles. Ces premières instructions de U-boot vont servir principalement à initialiser le nécessaire pour accéder au reste de la mémoire NOR, initialiser également la pile, la vitesse du processeur, etc.

C'est pour cela que nous avons le code suivant situé dans les 4 premiers kiloctets. Puis il y a une subtilité technique à prendre en compte. Nous allons changer les paramètres d'accès à la mémoire NOR. Cela se fait par l'écriture sur 7 registres différents dans le processeur. Non seulement nous allons dire au processeur d'activer des lignes d'adresses supplémentaires (permettant l'accès à toute la mémoire disponible), mais en plus nous allons modifier la vitesse d'accès pour améliorer les performances globales.

Les paramètres d'accès à la NOR sont situés dans les registres GPMC (adresses 0x51000060 à 0x51000078). Nous pouvons indiquer au processeur, pour chaque caractéristique du signal pour dialoguer avec la NOR, le nombre de cycles d'horloge nécessaires. Ces valeurs dépendent donc de la vitesse d'un cycle d'horloge et des caractéristiques de la mémoire NOR.

Attention, quand je parle de la vitesse d'un cycle d'horloge, ce n'est pas directement celui du processeur lui même. En général au sein d'un circuit, il y a une chaîne d'horloge qui se met en place pour alimenter chaque sous-système avec une vitesse qui lui convient. Ainsi le réseau, le multimédia, l'USB, le PCIe ou le processeur lui même ont des horloges propres. Ces horloges sont construits à partir de quartz qui générèrent un signal entre 15 et 25 MHz. Ensuite une PLL va amplifier ce signal pour moduler sa vitesse afin d'atteindre parfois plusieurs GHz. Dans notre cas, le quartz OSC0 (à 20 MHz) alimente la DPLL L3 (jusqu'à 220 MHz) qui alimente l'horloge GPMC qui divise par quatre le signal précédent (jusqu'à 55 MHz donc). Je ferais sans doute un article complet sur le sujet des horloges. :-)

Et comme nous allons changer la vitesse d'accès à la mémoire, alors que nous exécutons le code depuis la NOR elle même, vous pouvez deviner un problème. Entre le changement du premier et du dernier registre, les temps d'accès à la NOR ne seront plus cohérents, le système va se bloquer faute de pouvoir lire les instructions suivantes. Du coup il est nécessaire de copier le bout de code qui fait ce changement dans la SRAM (une petite zone de mémoire interne au processeur à l'adresse 0x40400000, qui n'est pas impactée par nos changements) afin de l'exécuter depuis celle-ci avant de revenir exécuter le code dans la NOR une fois l'opération faite.

Cela est fait via les lignes suivantes (l'essentiel du code employé provient du code de Texas Instrument qu'il a fallu adapter à notre cas) :

 /**************************************************************************
  * cpy_nor_gpmc_code: relocates nor gpmc init code into ocmc0 where its
  * safer to execute
  * R2 is loaded wtih size of data to be copied, this should be calculated
  * if we are modifying nor_gpmc_init()
  *************************************************************************/
 .global cpy_nor_gpmc_code
 cpy_nor_gpmc_code:
         stmfd sp!, {r0 - r10}
         /* Copy NOR GPMC init code into SRAM */
         adr r0, nor_gpmc_init     /* get addr of nor gpmc init code */
         mov r2, #640    /* r2 <- copy size(% by 32 bytes:r3-r10 (8) regs used) */
         ldr r1, sram_pc_start     /* r1 <- dest address (passed in) */
         add r2, r2, r0      /* r2 <- source end address */
 next2:
         ldmia   r0!, {r3 - r10}     /* copy from source address r0 */
         stmia   r1!, {r3 - r10}     /* copy to   target address r1 */
         cmp r0, r2          /* until source end address r2 */
         bne next2
         ldmfd sp!, {r0 - r10}
         mov pc, lr          /* back to caller */

Ce code fonctionne comme attendu, les premières cartes venant de la série A fonctionnent tous sans encombres.

Les problèmes arrivent

Quelques mois plus tard, un second jeu de cartes électroniques arrive avec une révision matérielle pour corriger les premiers défauts relevés. Et au bout de quelques heures, nous détectons un problème fondamental : sur certaines de ces cartes, le démarrage depuis la NOR ne fonctionne pas du tout, sur d'autres c'est aléatoire (de 1 fois sur 2 à 1 fois sur 100) et sur un exemplaire, aucun problème.

C'est pourtant, à ce stade, le même code qui est exécuté que sur les premières cartes qui ne bronchent toujours pas dans cet exercice. Notons également que sur ces nouvelles cartes, le démarrage depuis une carte SD ne pose aucun problème. D'ailleurs charger U-boot depuis la carte SD et le reste depuis la NOR ne présente aucun problème non plus.

La première piste est évidemment de vérifier tous mes calculs pour les registres d'accès à la NOR. Nous tombons tous d'accord sur le fait que ces valeurs sont correctes. Nous vérifions également l'ensemble des changements matériels autour du processeur et de la NOR et il n'y a rien. Tout au mieux, le responsable du routage de la carte (celui qui est responsable de transformer les liaisons logiques entre les composants en un circuit avec les pistes dessinées sur le plan final) note une différence de quelques micro/millimètres sur la longueur de ces fils entre les deux versions.

Mais rien de très intéressant, le module n'a pas beaucoup bougé sur ces fonctions et pourtant, le comportement est aléatoire. Nous prenons donc la JTAG pour en savoir plus afin de voir à quel endroit le démarrage échoue. Sur la plupart des modèles, cela tourne autour des registres du Watchdog. Mais si on supprime cette section du code, cela apparaît plus loin. Il semble donc que les échecs se produisent autour d'un certain nombre d'instructions constant depuis le démarrage plutôt que sur une instruction particulière. La JTAG nous montre que à l'instruction de trop, il va charger l'instruction suivante à une adresse délirante avant de retomber sur le vecteur d'exceptions du processeur pour avoir accédé dans une zone mémoire invalide.

Pour essayer d'identifier la cause de l'échec, le concepteur de la carte prend son oscilloscope à bras le corps et fait les mesures pendant que j'exécute le logiciel avec la JTAG pas à pas. Il semble que par moment le processeur fasse des signaux d'accès à la NOR d'environ 10 nanosecondes (oui, nanosecondes) trop courts. Pourtant les valeurs des registres que nous avons indiqué sont bons.

La solution

Une première solution est d'abaisser significativement les performances d'accès à la NOR et cela semble fonctionner. Mais si la NOR n'était pas un soucis niveau performances, nous avons une exigence contractuelle de démarrer l'ensemble du système en moins d'une minute. Et avec ces réglages, ce n'était plus possible. Puis nous ne comprenons toujours pas la cause du problème ce qui est gênant.

Il me faudra près d'une semaine de recherche dans la documentation de Texas Instrument pour comprendre la cause du problème et ainsi comment le résoudre. Je tombe en effet sur l'information suivante (page 1027 du document technique de référence) :

Horloge-boot-NOR.png

Or, si on prend le document de référence condensé page 183, on a :

Horloge-OPP.png

Vous ne voyez pas ? Il y a pourtant une incohérence pour une source d'horloge : la DPLL L3 qui est pour l'OPP 100 de 220 MHz et de l'autre de 200 MHz.

Or, tous mes calculs ont été conçus pour un signal d'entrée de 50 MHz et non de 55 MHz, ce qui donne un temps d'accès par cycle respectivement de 18 à 20 nanosecondes, soit bien sûr 2 nanosecondes d'écart. Quand on sait que la quasi-totalité de la configuration du signal d'accès tourne autour de 4 à 6 cycles par élément du signal, on retombe sur les 10 nanosecondes environ plus court constatés plus haut.

En quoi la documentation / implémentation de Texas Instrument est étrange ? En fait il faut expliquer brièvement ce qu'est un OPP. Un OPP pour OPerating Point est une méthode pour gérer l'énergie. Il consiste à fixer les fréquences maximales des différentes horloges du système par rapport à la tension d'alimentation du processeur. Plus le processeur consomme d'énergie (avec une tension élevée), plus les fréquences peuvent être élevées, mais plus la température peut monter également. En général on utilise le terme Dynamic Voltage Frequency Scaling pour décrire ce mécanisme.

Ce qui est curieux est que lors du démarrage NOR, par défaut, la ROM de Texas Instrument utilise l'OPP100 (celui de base) pour toutes les fréquences... sauf la L3 dont on se sert où c'est un OPP120 qui est employé. Cela n'est pas très cohérent comme choix et c'est ce qui nous a induit en erreur dans les calculs. Dans notre cas, pour éviter d'avoir besoin d'une ventilation active de la chaleur, nous souhaitons avoir une OPP100 durant le fonctionnement de l'appareil.

Pourquoi ce caractère aléatoire ?

Jusqu'ici j'ai expliqué le cadre général, l'origine du bogue a été trouvée, mais je n'ai pas expliqué pourquoi sur certaines cartes cela fonctionne, d'autres pas. Pourtant le code et le problème devrait se manifester partout.

Tout d'abord le démarrage SD fonctionne car dans U-boot, je changeais manuellement la fréquence des différentes horloges pour fixer le tout à l'OPP100 (et pour démarrer certaines horloges pour le processeur multimédia dont j'ai parlé dans le précédent article, chose qui n'est pas fait par le chargeur de démarrage de Texas Instrument). Du coup je supprimais le problème dans ce cas.

Le caractère aléatoire vient des différences minimes entre les différentes cartes. Comme je l'ai dit plus haut, les nouveaux modèles étaient plus sensibles à cause de la longueur des pistes qui avait changé, mais aussi parce que les composants ne sont pas identiques (numéros de série différentes, modèles différents pour les quartz, etc.). Étant donné la différence minime dans les temps d'accès, ces variations mineurs en temps normal peuvent avoir des impacts importants sur la longue.

D'autant que je changeais les fréquences d'horloge peu après la configuration du GPMC. Du coup, certains modèles avaient parfois la possibilité de régler le problème en abaissant la fréquence d'horloge finale en accédant à ces instructions à temps et sans encombre, d'autres pas.

Conclusion

Nous avons pu voir un problème qui survient parfois dans le domaine, des cartes qui se comportent différemment. Cela montre la nécessité de tester chaque modèle même si à priori c'est le même code, le même circuit. Chaque carte est unique. Il est nécessaire de documenter au maximum les petits changements qui peuvent être opérés. une collaboration forte entre l'équipe matérielle et logicielle est également fondamentale, il est probable que la cause n'aurait pas été retrouvée si vite sans cela. Chaque équipe ayant pu apporter des informations cruciales dans la résolution du problème.

Ensuite, bien entendu, la lecture de la documentation est importante, il faut tout vérifier, tout contrôler. Même ce qui paraît évident / logique. Il aurait été aussi appréciable que Texas Instrument choisisse une voie de moindre surprise en adoptant un choix cohérent dans les valeurs initiales de ses fréquences.

Et j'espère que vous aurez appris au sujet du démarrage sur les plateformes ARM et de la gestion des horloges. :)

mar., 10/10/2017

Une erreur… bien cachée

J'avais dit que je parlerais un peu des systèmes embarqués et de mes aventures dans le milieu. Aujourd'hui je voudrais relater un problème que j'avais dû résoudre au travail et qui n'était pas évident. Le prochain article sera plus générique (et celui d'après à propos d'un autre problème au boulot). Je vais essayer de varier un peu. ;-)

Ce sera sûrement un peu long, et je vais donner mon cheminement intellectuel autour de ce problème. Je respecte la chronologie des éléments dont j'avais connaissance à chaque étape.

Présentation du matériel et contexte

Pour situer un peu, je travaillais sur une plateforme Texas Instrument 8148 qui est un processeur ARM Cortex-A8 couplé avec un processeur M3 et des accélérateurs vidéos / DSP en son sein. Cette plateforme exploitait un noyau Linux 2.6.37 patchée à mort par Texas Instrument pour son processeur.

Le but du jour était d'exploiter le composant TVP5158 de… Texas Instrument encore (ce module a été conçu pour ce processeur en même temps). Pour décrire rapidement, ce composant permet de fusionner jusqu'à 4 flux vidéo analogiques (PAL / NTSC principalement) dans un seul numérisé que le processeur peut exploiter.

En soit le composant avait déjà un pilote fonctionnel pour Linux. Mais cela ne nous convenait pas. En effet, nous utilisons le TVP dans une chaîne de traitement vidéo où on faisait des décodages, redimensionnements, des remplacements d'images ou encore des encodages. Pour faire cela, non seulement il faut de la performance mais il faut aussi utiliser une API plutôt unifiée.

La performance est offerte par les accélérateurs vidéos qui sont dans les co-processeurs du système. On peut les exploiter via un firmware (dont le code source est confidentiel, désolé) et on peut communiquer avec ces accélérateurs via le noyau Linux et l'API OpenMax (OMX). Cette API est standard, éditée par le même groupe et dans les mêmes conditions qu'OpenGL, mais plutôt que de s'occuper de la 3D, il s'occupe des codecs vidéos. C'est souvent la référence libre dans ce domaine, avec GStreamer couplé avec libav.

Cette API est disponible dans le firmware de TI, cela tombe bien. Mais là où cela ce corse c'est pour récupérer des informations. En effet, il faut que durant notre traitement vidéo que nous sachions la résolution détectée par TVP du flux vidéo, et s'il existe (sur les 4 flux, des caméras peuvent être en pannes ou absentes pour diverses raisons).

Et TVP se configure via un bus assez standard et typique I2C qui est assez simple à mettre en place et largement suffisant pour lire / écrire des registres sur un composant. Il est par exemple souvent utilisé dans les cartes mères / graphiques de nos ordinateurs pour les capteurs de températures. Le soucis est que ce bus ne peut être géré par le firmware de TI (pour configurer le flux) et par le noyau Linux (pour récupérer les infos sur le flux pour l'application). Si on fait cela, il y aura conflit et le bus sera inutilisable. Modifier le firmware pour renvoyer les informations à l'espace utilisateur ou que le noyau gère la configuration du flux vidéo est plutôt complexe. Le mieux est d'utiliser un canal de communication existant entre le noyau et le firmware pour faire ceci, le firmware a donc la main sur le bus I2C et le noyau fera ses requêtes a travers lui.

On code

Partie intéressant du travail, coder. Et réfléchir à comment faire aller / revenir les informations voulues. Le noyau et le firmware, comme dans la quasi-totalité des systèmes à processeurs asymétriques, communiquent entre eux par mémoire partagée. Une partie de la RAM est allouée pour les messages, une autre pour les buffers vidéos, etc. Ceci est configurable (avec des limites) dans le code des deux côtés. Bien évidemment, les deux doivent être d'accord sur les adresses de base de chaque fonction, sinon ils ne retrouveront plus leurs petits. Cela est plutôt bien pris en charge par l'environnement de compilation fourni par TI. Vous pouvez consulter l'adressage mémoire entre les deux ici.

Dm8148-ezsdk-sw-arch.png

Bon, et le code alors ? La communication entre ces deux modules se faisant par mémoire partagée, il y a un certain protocole qui a été conçu par TI et qui s'exploite à travers une API maison nommée FVID2. Elle est déjà partiellement implémentée mais pas celle concernant le fameux TVP (qui est pourtant décrite dans l'API en question). J'ai donc écrit un pilote Linux pour combler cela. Aspect amusant, TI à la pointe de la technologie fournissait la doc de cette API dans un document .chm, un vieux format propriétaire dont le seul lecteur sous Linux potable est une application de l'ère de KDE3 : Kchmviewer. Quand je vous dis que l'embarqué c'est moderne !

Mais cela reste un peu moche, l'application en espace utilisateur demande au firmware HDVPSS de configurer le TVP. Mais, pour faire cela, il instancie le pilote interne de TVP du firmware qui ne doit pas être instancié deux fois et dont on ne peut récupérer la référence pour notre API FVID2… J'utilise donc une référence d'un autre composant dont le noyau a la référence (car il l'instancie) et j'envoie mes messages avec, le firmware a été modifié pour comprendre la situation et rediriger le message ensuite à bon port. Je n'avais pas trouvé mieux dans le délai imparti.

Et le bogue arrive… parfois

Et après le code, on teste. Après plusieurs essais difficiles, cela fini par passer. Youhou. Champomy dans les bureaux.

Mais, quand mes collègues vont tester leur application avec mon travail, cela ne fonctionne pas toujours. Le module noyau qui fait les échanges avec le coprocesseur nous signifie que certaines requêtes, en quantité variables, mettent trop de temps à revenir. On était à une moyenne de 1 à 10 échecs par minute (pour 24 requêtes). Mais il arrivait malgré tout que sur 30 minutes / 1 heure cela n'arrive pas, avant de revenir. C'est beaucoup trop problématique, et ce qui est étonnant c'est que mes tests ne présentaient aucune erreur.

Du coup, comme pour toute chaine de communication, on va déboguer étape par étape pour identifier où cela coince. Je précise que la seule section dont je pouvais difficilement déboguer c'est l'échange des messages entre Linux et le firmware qui est assez mal documenté et le code assez obscur en plus d'être gros.

Matériel

Le plus simple à tester, c'est le matériel (recompiler le firmware vidéo pour y ajouter du débogue c'est 40 minutes de compilation, c'est pénible et long, on évite au maximum de le faire). Je vérifie donc que le TVP reçoit les bonnes requêtes et y répond. Le bus I2C étant très simple, un petit oscilloscope sur un fil et on peut rapidement conclure que les signaux sont bons dans les deux sens que la requête échoue ou non à la fin.

Mais je me dis que le temps d'attente côté Linux pour recevoir ce message est trop court, je l'allonge volontairement à un délai absurde comme 30 secondes, cela ne change rien. Soit ça réussi vite, soit au bout des 30 secondes j'ai l'erreur. Pas d'entre deux, pas de hausse ou baisse de ces erreurs.

Du coup on sait que la chaîne d'envoi est bonne, et le matériel aussi, le soucis se situe bien au retour.

Firmware vidéo

Donc forcément je remonte un peu la chaîne côté firmware vidéo et à chaque étape en son sein, l'information est correcte à tous les coups. Comme le soucis n'est pas côté Linux après l'API FVID2, le soucis se situe forcément dans le transfert des messages entre les deux mondes comme on dit. Côté retour uniquement.

Plongeons au cœur de la mémoire

À ce stade là, cela devient assez étrange. Comment cela peut planter de cette manière là ? J’émets quelques hypothèses, manque de place pour l'échange de messages (il y a d'autres messages que ceux du TVP là dedans) ou éventuellement un conflit de lecture / écriture simultanée par les deux sur un même message.

Pendant que je cherchais comment l'ensemble fonctionnait, des collègues m'ont rapporté des informations pertinentes (bah oui, ils continuent de testeur leur travail de leur côté et disent ce qui est pertinent quand ils constatent le problème). Il y a une corrélation entre le nombre de caméras branchées au TVP (et exploitées par notre programme) et la fréquence du bogue. Plus il y a avait de caméras, moins cela plantait. Cela paraît contre intuitif.

J'ai maintenant une idée plus claire de ce qui semble être le cas, mais je dois vérifier. J'essaye de voir donc comment l'échange de message fonctionne, et la fonction que j'appelle a quelques lignes intrigantes dont je copie la boucle intéressante :

while (fctrl->fctrlprms->returnvalue == VPS_FVID2_M3_INIT_VALUE) {
       usleep_range(100, 300);
       if (vps_timeout) {
              do_gettimeofday(&etime);
              td = time_diff(stime, etime);
              if (vps_timeout < td) {
                    VPSSERR("contrl event 0x%x timeout\n",  cmd);
                     return -ETIMEDOUT;
               }
        }
}

En gros, Linux initialise une valeur précise à une adresse précise dans la RAM. Quand le firmware a fini son boulot et renvoie les infos demandés, il signifie au noyau qu'il a fini en changeant la valeur initialisée précédemment. Le noyau regarde sa valeur régulièrement par tranches de 100 à 300 microsecondes pendant 2 secondes maximum.

Et comme par hasard, si je mets dans la boucle un printk de débogue (l'équivalent de printf pour le noyau, pour afficher des chaînes de caractères visibles en espace utilisateur, cette fonction est plutôt grosse), le bogue disparaît. Quelques soient les conditions.

Cela me renforce dans mon hypothèse : nous sommes face à un soucis d'accès à la valeur de cette variable. Le noyau Linux relit la variable depuis le cache ou le registre du processeur qui bien sûr ne change pas (car le processeur n'a pas changé cette valeur, c'est au coprocesseur de le faire !), du coup il voit éternellement la variable comme au départ et il croit que le firmware vidéo ne fout rien. Le printk ou l'activité du système (plus il y a de caméras, moins cela arrive, n'oublions pas) permettant à Linux de bien voir la véritable valeur en la rechargeant depuis la RAM.

Le problème vient du fait que ce genre de vérification ne doit pas se faire directement, surtout que la zone mémoire concernée a été allouée avec "ioremap()".

Il suffit donc de remplacer la ligne

 while (fctrl->fctrlprms->returnvalue == VPS_FVID2_M3_INIT_VALUE) {

Par

 while (ioread32(&fctrl->fctrlprms->returnvalue) == VPS_FVID2_M3_INIT_VALUE) {

Les accès par "ioread*()" mettent des barrières mémoires et indiquent que la variable peut être modifiée de l'extérieur. Obligeant donc une nouvelle lecture de la valeur en toute circonstance.

Conclusion

Je suis tombé sur ce bogue après quelques mois dans la vie active seulement. C'était un défi intéressant, je n'avais pas trouvé cela évident. C'est vraiment le genre de choses que l'on a tendance à oublier, on accorde trop de confiances aux couches d'en dessous (matériel / noyau / compilateur / bibliothèque / langage) qu'on en oublie qu'ils peuvent présenter des problèmes et qu'on doit faire attention en les utilisant.

Après, cela met en évidence un énième bogue / oubli stupide de la part de Texas Instrument (ils en font du code horrible, je vous le dis) qui aurait pu être évité s'ils travaillaient un peu plus avec le noyau officiel. Nul doute qu'avec plus de relecteurs de leur code, quelqu'un l'aurait vu. Mais bon, tant pis, je me suis bien amusé. :-)

ven., 07/04/2017

Les systèmes embarqués

Cela faisait un moment que je réfléchissais à parler des systèmes embarqués, en particulier autour de Linux. Cela fait quelques temps que je suis dedans, et les ressources francophones étant plutôt rares dans le secteur, j'aimerais partager mon expérience, mes pensées, mes trucs et astuces potentiels.

Bien sûr cela ne remet nullement en cause la communication de l'actualité autour de Fedora. :-)

Pour commencer cette catégorie, je pense qu'il est bon de définir ce que j'entends ici par systèmes embarqués afin que ce soit clair et raconter un peu ma vie sur pourquoi je travaille dedans.

Mon parcours

Mon intérêt pour les systèmes embarqués vient de loin, mais reste flou. Globalement j'ai toujours apprécié manipuler un produit, un objet. Cela s'est confirmé durant mon cursus dans le supérieur, je n'éprouve pas une grande satisfaction à faire tourner mon bout de programme sur un serveur dont j'ignore même sa localisation. Ce besoin de concret est très important pour moi. J'ai toujours été très excité de lancer le résultat de mon travail préliminaire sur une nouvelle carte électronique qui vient de débarquer. Et constater que cela ne fonctionne pas du premier coup bien entendu.

Ensuite, il y a également l'intérêt d'apprendre le fonctionnement de nos ordinateurs. J'ai toujours été fasciné par le fonctionnement des processeurs, de la RAM ou des systèmes d'exploitation. Sans doute l'émerveillement devant leur complexité et l'ingéniosité de leur conception (si on met sous le tapis les horreurs également présentes). Dans ce domaine, il faut connaître les caractéristiques du circuit, du processeur, lire la documentation associée, comprendre l'état de la mémoire, comment l'OS va gérer les entrées/sorties et les processus pour donner accès à la fonction voulue. Impossible de se reposer sur une machine virtuelle ou un interpréteur qui nous cache ces détails (ce qu'ils font à raison, mais cela ne m'intéresse pas).

Enfin, je trouve que c'est un domaine omniprésent. Cela permet de côtoyer de nombreux secteurs d'activités différents comme: télécommunication, aéronautique ou spatial, automobile, agriculture, sécurité bancaire, multimédia, l'électronique, etc. Et comme le produit doit répondre aux contraintes de chaque secteur, il faut étudier, comprendre et analyser les caractéristiques du secteur considéré. Cela permet de varier l'environnement d'étude et donc les choses à en apprendre. Or j'adore apprendre.

Qu'est-ce qu'un système embarqué ?

Cela peut paraître absurde, mais il y a probablement autant de définitions que d'acteurs dans le domaine. D'autant plus qu'avec le temps et l'évolution technique, la définition de ce qui entre ou pas dans ce cadre peut varier. Typiquement, un téléphone aujourd'hui est radicalement différent par rapport aux débuts des années 2000. Pour certains un smartphone n'en est plus un, pour d'autres, cela continue.

Du coup on va dégager les tendances ou les points communs pour le définir. Globalement nous pouvons résumer cela en tout système programmé qui n'est pas d'architecture x86 ou qui présente une contrainte spécifique.

La puissance disponible

La première chose qui vient à l'esprit, ce sont les performances matérielles. Un processeur pas très puissant, voire ancien, peu de RAM ou de stockage et une connectique souvent un peu spéciale pour en tirer parti. Grâce aux progrès de la miniaturisation et de l'économie d'énergie, c'est de moins en moins vrai. Des processeurs tels que les nVidia Tegra TK1/TX1 ne consomment pas grand chose. Pour moins d'une dizaine de watts, et une surface raisonnable, nous avons un couple GPU/CPU pouvant atteindre le TFLOPS en puissance de calcul brut. Qu'on peut facilement épauler de quelques Gio de RAM et de mémoire de stockage.

À titre de comparaison, 1 TFLOPS (en admettant cette unité de mesure comme pertinente, ce qui est discutable) c'est l'ordinateur le plus puissant du monde déclaré (donc pas militaire ou top secret) en 1997. 20 ans après un téléphone ou une voiture en ont un voire plusieurs sur quelques millimètres carré. Nous sommes très loin d'un simple microcontrôleur ou d'un processeur peinant à gérer plusieurs processus à la fois. Cela est également proche de ce qu'on peut retrouver dans un ordinateur personnel normal.

Donc si la puissance disponible est un critère souvent retenu, programmer un microcontrôleur est de fait un système embarqué, il est possible aujourd'hui de faire des systèmes embarqués avec une puissance de calcul très élevée.

Les contraintes d'un système peu puissant c'est qu'il demandera sans doute une économie des ressources, la renonciation à certaines technologies et à certaines fonctionnalités. Ce n'est pas pour rien que le C et le C++ règnent encore en maître dans le domaine, même si Python ou Java prennent de plus en plus de place, grâce justement à l'amélioration des performances.

L'énergie

Pour enchaîner avec le point précédent, nous pouvons relever la consommation énergétique. Tous les systèmes embarqués n'ont pas cette contrainte, mais cela reste assez commun. En effet, un système sur batterie devra faire attention à la consommation énergétique pour limiter l'apport d'énergie (en fréquence comme en puissance) par exemple pour augmenter son autonomie.

Le lien avec la puissance est évidente, malgré les progrès, plus de puissance de calcul demandera plus de ressources électriques. C'est ce qui a limité pendant longtemps la possibilité de faire des systèmes embarqués avec des performances élevées. La mise à disposition de processeurs modernes avec une consommation faible permet le contournement de ce problème mais pas complètement. Cela se vérifie avec l'Internet des Objets qui remet au centre du secteur des processeurs très minimalistes et très peu gourmands pour exécuter uniquement la fonction demandée.

L'énergie va avoir plusieurs contraintes sur le système. Il peut en effet limiter la puissance disponible. Il peut aussi être une contrainte car l'énergie fournie est non fiable. Nous pouvons penser à des systèmes en aéronautique ou aérospatiale dont certains composants ont une puissance électrique allouée maximale et que dans certains cas l'engin peut couper l'alimentation de composants secondaire (par exemple le multimédia à bord des avions).

Il faut donc tenir compte de cela, par exemple certaines communications peuvent être coupées brutalement, le système aussi. Cela a un impact fort sur le design électronique et logiciel. Il faut réfléchir à comment gérer le cas d'une coupure de courant lors d'une mise à jour du système (dans quel état le système va être retrouvé ?). Les fonctions qui doivent être maintenues en vie et d'autres pas. Si ces questions existent pour l'ordinateur personnel, cela reste moins problématique et beaucoup plus rare que dans le cas des systèmes embarqués. On peut en effet présumer que dans les pays développés le réseau électrique est plutôt fiable (ce qui n'est pas sans poser de soucis pour ceux ne vivant pas dans de tels pays mais passons).

L'autonomie

Ici je ne parlerai pas d'autonomie électrique, bien que ce soit liée, mais plutôt d'autonomie en terme d'isolement du système. Un système où l'accès au réseau n'existe pas forcément, où il n'y a pas un technicien disponible pour le réparer en cas de besoin rapidement.

Cela a un impact bien entendu très fort sur le système. Cela signifie que le système doit être robuste aux pannes ou bogues divers. Certains processus devront être très fiables, comme la mise à jour. Si on envoie un nouveau logiciel à un satellite dans l'espace et que cela échoue, le satellite doit rester opérationnel dans tous les cas. On ne va pas envoyer une fusée pour réparer ce genre de choses.

En terme d'architecture du système, il va falloir penser à beaucoup de choses pour minimiser l'intervention humaine. Il faut forcément automatiser le lancement pour que l'application métier soit lancée toute seule. Mais aussi programmer des tâches récurrentes, prévoir des solutions en cas de coupure du réseau ou de l'électricité.

Par exemple, pour que le système soit auto-entretenu dans un tel contexte, il est courant de recourir à un système sans état. Ce type de système fait qu'en cas de redémarrage, la fonction recommence comme si de rien n'était, le système pouvant être en lecture seule. On couple cela avec un watchdog pour que le système redémarre matériellement tout seul si jamais l'application ou le noyau ont planté.

Les entrées/sorties limitées ou spéciales

De part les contraintes énoncées plus haut, il en ressort qu'on n'interagit pas avec un système embarqué comme avec son ordinateur personnel. Il n'y a pas forcément d'écran, encore moins souvent de clavier complet ou de souris. Si écran il y a, c'est souvent du mono applicatif donc sans bureau. Le système doit être minimal, pour économiser en coût de composants, en risque de problèmes matériels ou logiciels et simple d'utilisation pour un utilisateur non formé. En effet il serait malvenue que le distributeur de billet de votre quartier soit complexe à prendre en main ou qu'il tombe en panne régulièrement.

Cela va induire par effet de bords des choix en terme d'interface utilisateur pour présenter le moins de choix possibles d'un coup, en restant clair et complet. Et que tout ceci soit sélectionnable sans difficulté ou ambiguïté pour tous les utilisateurs (comme les personnes âgées ou les handicapées). Ceci explique souvent les interfaces un peu vieillottes avec de gros boutons que ce soit bien visible et clair. Les interfaces riches peuvent être sources de confusion dans ce genre de situations en plus de demander plus de ressources matérielles et de temps de développement.

En terme d'entrées/sorties spécifiques, nous avons ceux du développement et en environnement de production. Pour le développement, comme nous utilisons notre ordinateur, nous devons communiquer avec la bête. Très souvent cela se fait par le réseau (par SSH et NFS), par port série voire USB pour l'accès à la console (quand le SSH n'est pas possible) et JTAG pour déboguer en stoppant le processeur par exemple pour analyser la situation à n'importe quel moment. Parfois pour flasher la JTAG sert encore mais cela est de moins en moins le cas. Il faut souvent jongler avec tout ceci ce qui encombre pas mal le poste de travail.

Les normes et l'environnement

Encore un sujet assez vaste et pourtant au combien important. Les systèmes embarqués sont très souvent employés dans des secteurs industriels où les normes sont omniprésentes pour des raisons de sécurité, de compatibilité, de respect de l'environnement, etc. Et cela n'est pas sans incidence sur le développement.

Des secteurs sont par exemple très très réglementés comme l'aéronautique, le médical, le spatial, l'automobile ou le ferroviaire. Ce sont des secteurs où des défauts peuvent engendrés la perte de vies humaines ou avoir des coûts matériels très important en cas de défaut. Il est impératif de respecter des normes afin de limiter au maximum les risques.

Je vais parler de l'aéronautique, secteur que j'ai pu côtoyer durant deux ans. Tout logiciel (et matériel) embarquant dans un avion doit être certifié conformément aux directives des agences continentales et internationales. Pour être certifié, l'écriture du logiciel doit suivre une procédure précise qui dépend bien sûr de la criticité du système.

En effet, tout système se voit attribué un DAL qui est un niveau d'exigence noté de A à F, plus la note est élevée, plus l'exigence et les limitations seront fortes. Dans tous les cas il faudra documenter le design, rédiger des cahiers de tests et communiquer les résultats. Il faut également facilement faire le lien entre le code / commit et un test ou une exigence du design.

Et là où cela se corse, c'est par exemple des logiciels pour les DAL A ou B, il faut impérativement que tout soit contrôlé. Tout le chemin d'exécution du code, de même que le déterminisme du processeur en dessous. C'est pourquoi il est fréquent d'utiliser des code très léger sur microcontrôleur dans ce cas, on ne peut se fier à la complexité d'un noyau Linux complet sur un processeur x86. La communication avec les autres composants doit être réduite au strict nécessaire, la consommation électrique est plafonnée. Il y a aussi des interdictions plus concrètes comme le respect d'un code couleur pour les interfaces (le rouge est par exemple réservé aux erreurs sévères et strictement définies).

Concernant les normes, il y a aussi les standards comme le bus CAN pour l'automobile ou l'A429 pour l’aéronautique qui sont incontournables pour interagir avec le reste de l'appareil sans réinventer la roue systématiquement. D'ailleurs l'analyse de ces normes mettent en évidence les contraintes de l'environnement pour expliquer ces choix de design et le maintient de ces normes anciennes sur des systèmes modernes. Cela fera l'objet d'un autre article.

En somme, il faut respecter les contraintes du secteur d'activités qui peuvent être importantes car il y a de fortes responsabilités derrière. Et cela influe forcément le design de l'application et du matériel et de fait du produit qui sera réalisé.

Conclusion

C'est un article un peu long qui se veut être une introduction générale. Par la suite je compte présenter quelques petites choses :

  • Étude d'une norme comme le bus CAN ou A429, qui sont assez simples, et comprendre leur intérêt dans les systèmes actuels et les raisons d'une telle conception ;
  • Présenter des projets liés aux systèmes embarqués comme Yocto, buildroot, U-boot ou le noyau Linux et expliquer le boulot d'un développeur sur ces projets ;
  • Expliquer certaines pratiques industrielles ou technologies dans le secteur, pour comprendre certaines décisions qui peuvent paraître aberrantes mais qui finalement le sont moins. Typiquement pourquoi il est rare qu'Android soit mis à jour décemment sur la plupart des modèles vendus ? Pourquoi il est difficile de faire un OS compatible avec tous les systèmes ARM ?
  • Présenter certains bogues ou designs que j'ai rencontré dans le cadre de mon travail.

Cela s'étendra dans le temps, je ne compte pas tout rédiger maintenant. Les humeurs, les envies, les idées, tout ça.

N'hésitez pas si vous avez des suggestions, des corrections, des questions ou de signifier si cela vous plaît / déplaît. Merci.

lun., 06/02/2017

Retour du FOSDEM

Et voilà, le FOSDEM c'est terminé. Pour une fois que l'occasion se présente d'y assister, il fallait que je vive sur place. :-)

De manière générale c'est un très bel évènement, bravo aux organisateurs car malgré la complexité de l'emploi du temps et du monde présent, cela s'est bien passé selon moi. Pour avoir déjà organisé des évènements de taille modeste en comparaison (maximum 100 visiteurs), j'imagine la quantité de travail nécessaire pour aboutir à ce résultat.

C'est d'ailleurs le caractère frustrant de ce type d'évènements. Trop peu de temps pour tant de choses à faire ou à voir.

Conférences

Pour ma part, le programme des conférences était celui-ci (dans le désordre) :

Dans l'ensemble c'était intéressant, de quoi collecter des noms, liens ou idées pour approfondir ces sujets. Comme cela peut se voir, j'ai plutôt privilégié les systèmes embarqués / systèmes d'exploitation, en lien avec mon travail et ma spécialité. J'ai regretté de ne pas avoir pu assister à celle sur RedoxOS, salle déjà comble à mon arrivée (pourtant j'étais en avance !).

Petit bémol sur la conf pour la modularité (qui provient de Fedora.next avec premier jet pour F26 Server), si cela a bien expliqué l'architecture de la chose, j'ai un peu de mal concrètement à saisir ses répercutions pour l'utilisateur et comment il va l'exploiter. Va falloir que je teste un peu pour l'annonce de F26. :-)

Des rencontres...

Avec un évènement de cette taille, il est évident que l'on retrouve du beau monde et on passe du temps à discuter.

Cela a bien sûr été l'occasion de retrouver la communauté de Fedora-fr : Emmanuel, Haikel, Pierre-Yves, Nicolas, Marianne, Michael dont on a partagé un repas le vendredi soir très agréable. De rencontrer des membres du projet Fedora ou de Red-Hat que je ne connaissais pas personnellement comme spot ou Benjamin Tissoires.

Hélas j'ai manqué Jean-Baptiste (malgré nos tentatives de se fixer un rendez-vous dans la journée) et Kévin dont j'ai appris son passage après l'évènement (via la page des badges de l'évènement pour les contributeurs de Fedora). Mais bon, vu la taille et le monde, c'est difficile de voir tout le monde facilement.

J'ai aussi pu enfin voir un membre de Zeste de Savoir (et du feu Site du Zér0) : Thomas Citharel. Ou encore des membres de la communauté de mon téléphone Jolla et de son système Sailfish OS.

Bien entendu j'ai pu croiser des collègues de ma nouvelle entreprise Essensium - Mind.

Cela a bien sûr été l'occasion de discuter auprès de certains projets ou d'en découvrir. Comme GRUB, OpenAutomotive Linux ou encore Mozilla. Mozilla qui a récupéré gentiment mon ZTE Open C sous Firefox OS qui traînait dans un tiroir. Et me voilà armé pour apprendre Rust, en projet.

... et des bogues !

Et oui, être sous Rawhide réserve son lot de surprises. C'est une aventure constante, même aux moments où on en a le moins envie car on n'a pas le temps ou le matériel pour réparer. Effet démo / loi de Murphy sans doute.

Et cela est arrivé lors de la conf... de la modularité de Fedora. C'est sans doute fait exprès. C'est LUKS qui au lancement de la machine refusait de déchiffrer mes partitions. Pourtant j'ai testé plein de fois le mot de passe, en QWERTY, AZERTY ou BÉPO au cas où, rien n'y faisait. J'ai également essayé avec un noyau plus ancien. Il a fallut un LiveCD (merci Emmanuel) et monter les partitions avec pour que la situation revienne à la normale. Bogue assez gênant dont je ne comprends pas l'origine. Je vais devoir creuser.

Conclusion

Ce fut un week-end très sympathique avec deux amis. Je comprends mieux la réputation de cet évènement, et très clairement j'en serai l'année prochaine.

Peut être que j'irais moins aux conférences cette fois pour plus profiter des gens encore, je ne sais pas. Après tout certaines conférences seront disponibles sur Internet (du moins je l'espère).

sam., 21/01/2017

Petit bilan de Rawhide, 2 mois après

Comme vous le savez, il y a deux mois je suis passé à Rawhide. Pour la première fois je vais vivre entièrement le cycle de développement d'une version de Fedora. L'objectif étant bien entendu de découvrir des choses et d'aider à détecter des problèmes plus tôt. Afin que la Fedora 26 soit la plus stable possible.

Les problèmes rencontrés

Il n'y a pas à dire, à ce stade il y a du boulot ! J'ai rencontré en 2 mois quelques bogues plutôt importants. Je m'y attendais, et il y a eu de grands progrès par rapport à la situation d'il y a quelques années.

En premier lieu, un bogue de Firefox que j'avais peu avant la sortie de F25 qui continue à me poursuivre. Les vidéos sur les pages Web parfois tournent en boucle sur 1 seconde de buffer. Rendant illisible la lecture, obligeant de relancer Firefox.

Ensuite, un bogue qui continue toujours, GNOME Shell a une erreur obligeant à relancer la session, sans raison à son lancement. C'est plutôt aléatoire. Mais si la session se lance bien, ce problème ne surgit plus avant le prochain lancement.

Un bogue apparemment qui a concerné aussi F25 et F24, avec Firefox impossible d'aller sur des sites tels que Google ou Wikipédia. Un problème dû à HTTPS sur HTTP2 apparemment. Cela a été corrigé rapidement, mais pourrait revenir pour Thunderbird et SeaMonkey à l'avenir, à cause de la mise à jour de NSS (la bibliothèque de sécurité de Mozilla) et le manque de correctif pour ces programmes. C'est en discussion sur la manière d'aborder la chose.

Un nouveau bogue apparu hier, qui semble venir du logiciel lui même. Ouvrir des onglets dans Epiphany rend l'écran noir ou gèle le système. Plutôt ennuyeux, mais au moins Epiphany n'est pas mon navigateur principal donc cela ne me gêne pas trop.

Enfin, dernier bogue qui vient d'être résolu. GNOME Shell, GDM et d'autres programmes plantaient, à cause d'un écart de version entre la bibliothèque harfbuzz de Fedora et de FreeType dans RPMFusion. Le mainteneur dans RPMFUsion a rapidement corrigé le tir.

Bref, 5 bogues que je considère comme importants et que j'ai rencontré en 2 mois. Ce n'est pas beaucoup. Dont 2 qui ont touché aussi la version stable de Fedora par ailleurs. Cela demande quand même un peu de patience et de bidouilles pour corriger la situation mais rien d'insurmontable. :-)

Cependant, il y a eu discussion il y a quelques temps sur Rawhide. Un empaqueteur a jugé bon de pousser un paquets qui ne fonctionnait pas sur Rawhide dans les dépôts (car pas testé par ses soins avant). Selon lui Rawhide doit être un dépôt poubelle où la stabilité ne compte pas car cela pourrait ralentir ses développements. Je trouve que de manquer ici de respect aux testeurs est dommageable. Rawhide par définition doit être utilisable et un paquet doit être testé par son mainteneur avant. Cela paraît être le minimum à faire.

Heureusement que cette mentalité a fortement régressé. Il n'y a plus beaucoup d'empaqueteurs qui tiennent encore de tels propos.

Les changements

Forcément l'intérêt de passer à Rawhide ou à une version de tests, c'est aussi découvrir et profiter des changements en avance. Pour l'instant pas de grands bouleversements. GNOME Shell et LibreOffice sont en avance d'une version par rapport à Fedora 25 (mais sont toujours en développement). Comme souvent leurs améliorations sont par petite touche et l'ensemble est plus agréable.

Le plus grand changement visible vient de GNOME Builder je pense, dont une bonne partie de l'interface a été changée. C'est l'IDE que j'utilise depuis une année maintenant et il évolue vraiment dans le bon sens, c'est très appréciable.

Après nous ne sommes qu'au début du développement de ce que deviendra Fedora 26. Les fonctionnalités ne sont pas encore toutes définies, et encore moins mises en place. Et les logiciels upstream aussi ont beaucoup à faire, GNOME n'a pas encore fini de changer (sa sortie étant dans 2 mois) par exemple.

J'espère que ce genre de billets vous plairont, je compte en faire mensuellement. Quand j'aurais des changements plus visibles je ferais des captures d'écran associés. Si cela intéresse les gens d'aller à l'aventure de Rawhide, n'hésitez pas, il y a très peu de testeurs mais beaucoup de besoins ! Et c'est grâce à cette activité que la Fedora stable est stable.

lun., 07/12/2015

Compte rendu des JM2L 2015

Me voici de retour de cette nouvelle édition de la Journée Méditerranéenne du Logiciel Libre placée sous le signe récurrent du soleil mais aussi du thème Do It Yourself.

Contrairement aux éditions précédentes, la journée du vendredi n'a pas eu lieu faute de moyens. Les locaux de l'école Polytech'Nice ont enfin terminé leurs travaux ce qui a facilité la découverte des lieux. Cette fois, le bâtiment des stands / install party était dissocié de celui des conférences. Ce n'était pas forcément un problème, si ce n'est que durant certaines plages horaires le bâtiment qui m'était affecté était plutôt vide.

La journée s'est très bien passée, l'affluence était habituelle probablement aux alentours de 150-200 visiteurs/participants. C'était l'occasion de revoir la communauté locale des environs de Toulon/Sophia-Antipolis que je ne vois plus beaucoup depuis mon déménagement. Bien entendu lors de la tenue du stand j'ai été amené à rencontrer du monde.

Contrairement à d'habitude, la plupart des visiteurs semblaient connaître Fedora de nom ce qui a facilité un peu la présentation. Beaucoup ont encore des difficultés à assimiler la différence par exemple entre le projet Fedora et Ubuntu. Ce rappel n'est pas un problème. J'en ai profité pour faire une démonstration d'une Fedora 23 sous Gnome-Shell en fonctionnement ce qui a intéressé de nombreux curieux. Des personnes plus connaisseurs se sont intéressées à la question des spins de Fedora notamment la version ARM dans un cadre d'une box domotique. La connexion n'était hélas pas suffisante pour télécharger sur place une telle image afin d'effectuer un essai.

DSC_0256_b.JPG

Les membres du stand d'OpenSuse sont également venus échanger quelques mots à propos d'OpenQA, projet pour automatiser les tests dont la distribution au caméléon est d'origine et que le projet Fedora met en place de son côté actuellement.

Les quelques DVDs de Fedora 22 que j'avais ont pu en partie s'écouler. Cela est devenu difficile avec la Fedora 23 disponible depuis près d'un mois. Quelques goodies ont également été distribués / vendus. Borsalinux-fr accueille également un nouvel adhérent.

C'est donc au plaisir de vous revoir à ce genre d'évènements. Un grand merci à Emmanuel Seyman pour le matériel et aux organisateurs des JM2L pour leur hospitalité et leur organisation. À l'année prochaine, et cette fois-ci je tiendrais une conférence !

dim., 08/11/2015

Présence de Borsalinux-fr aux JM2L 2015 à Sophia-Antipolis le 28 novembre

Après une année sans édition, les Journées Méditerranéennes du Logiciel Libre reviennent le samedi 28 novembre 2015 à Sophia-Antipolis. Cet évènement majeur local qui se déroule habituellement chaque année change de format. Abandonnant la journée du vendredi dédiée aux élèves de la région, pour se concentrer sur la journée du samedi et l'activité plus communautaire.

Cette édition est toujours animée par l'équipe ensoleillée de Linux-Azur. Elle aura pour thème le Do it Yourself. Cela se déroulera comme d'habitudes avec des conférences liées à la thématique, des ateliers et des stands pour présenter différents projets ou activités. Si vous êtes amateur du Logiciel Libre, simple curieux ou personne désirant assistance, il ne faut pas louper cette occasion.

Pour ma part je serais sur place pour défendre les couleurs de Borsalinux-fr avec un stand afin de présenter Fedora et sa communauté francophone aux visiteurs et assister ceux qui le désirent. Je pourrais fournir des images ISO fraîchement disponibles de Fedora 23 (qui est sorti le 3 novembre dernier), faire une démonstration de certains changements et aussi transformer votre clé USB en média de test et d'installation de Fedora 23.

Je serais également disponible pour toute discussion. Venez nombreux !

mar., 14/07/2015

Compte rendu du week-end des RMLLs à Beauvais

Comme le mentionnait mon billet précédent, Borsalinux-fr était présent aux RMLLs de cette année à Beauvais. Je vais vous compter le déroulement du week-end auquel j'ai participé.

C'est ainsi, après avoir vagabondé sur Paris le vendredi, que je me retrouve sur Beauvais le samedi 4 juillet au matin. Après une averse courte et abondante, et le stand monté, je me retrouve sur la place devant la superbe cathédrale à devoir discuter de Fedora aux passants curieux, amateurs voire plus expérimentés. Ce jour là était aussi l'occasion de la découverte du lieu et des autres participants. Situés entre LibreOffice et Mageia, on a eu l'occasion d'échanger d'un point de vue technique ou de communication autour de nos projets mais aussi nos expériences. Échanges sympathiques et enrichissantes sous ce soleil accablant.

Concernant les visiteurs, on a pu voir un peu de tout. De nombreux habitants de Beauvais se sont montrés curieux concernant la manifestation du moment et ont posé des questions sur ce qu'on faisait. D'autres sont sortis de leurs propres stands pour discuter de Fedora, troller un peu, demander des informations pour les aider sur une migration récente ou à venir. Les échanges furent agréables avec environ 20 personnes s'étant sérieusement arrêtées pour discuter.

20150705_001b.jpg

Après un aller-retour sur Paris, le dimanche fut assez différent. Si la chaleur était toujours présente, le vent s'est levé ce qui a nécessité de ranger notre panneau de présentation. Qu'importe, les visiteurs étaient toujours là. Épaulé par Michael Scherer, nous avons pu tenir des discussions plus approfondies que la veille, notamment au sujet de Gnome Logiciels et des fameux fichiers .appdata. Une professeur d'université suisse nous a expliqué son travail et ses difficultés à migrer au sein de son activité. Les communautés LOLICA de Champagne et d'autres plus sur les Ardennes sont venus discuter de leur rapport à Fedora voire demander un coup de main sur quelques détails comme DNF, Gnome Logiciels ou encore RPMFusion.

C'était également l'occasion de troller discuter avec un membre de Ubuntu-fr sur Secure Boot et sur les possibles conséquences quand les constructeur n'auront plus l'obligation d'autoriser sa désactivation. Un contributeur Debian nous a demandé de participer et de relancer le projet de la compilation reproductible. Le principe étant qu'un utilisateur ou une distribution puisse vérifier qu'un paquet binaire correspond bien au code source pointé par le paquet RPM en question. Cela impose en effet de pouvoir fixer des éléments aléatoires lors de la compilation pour vérifier la correspondance exacte des fichiers. Ce principe permet notamment de détecter un paquet généré à partir d'une clé GPG volée.

20150705_004b.jpg

Cette journée a été également l'occasion de voir tout le monde attentif au discours de RMS mais aussi à l'attraction du jour à savoir un R2D2 fonctionnel.

C'est ainsi que l'évènement se termine pour ma part, pour laisser place à une série de conférence et notre stand tenu par Emmanuel Seyman. Durant le week-end, l'association a pu collecter 41.5€ de dons et de la vente de goodies, merci à vous. Deux bulletins d'adhésion ont été distribuées, en espérant la transformation de l'essai.

Je tiens à remercier Michael Scherer pour m'avoir donné un coup de main le dimanche, mais aussi Emmanuel Seyman pour la gestion du matériel et pour avoir tenu le stand en semaine. Sans oublier Guillaume Dondero pour avoir monté le matériel sur Beauvais mais également les organisateurs et les participants qui ont rendu cet évènement possible.

À la prochaine fois !

jeu., 21/02/2013

Venez à la Journée de l'Informatique Libre ce samedi 23 mars à Toulon !

Ce samedi 23 mars 2013, se tiendra la Journée de l'Informatique Libre pour sa troisième édition. Cette fois encore, elle sera à la Maison des Technologies à Toulon, dans le bâtiment de l'école d'ingénieurs ISEN Toulon et de La Cantine de Toulon qui nous prêteront les locaux. Cet évènement est planifié de 9h à 17h.

Programme

La journée sera l'occasion pour la communauté locale de tenir des conférences sur les sujets de l'informatique libre. Pour cela les thèmes principaux sont : la culture libre, l'OpenData, les Logiciels Libres et tous les mouvements associés. Des ateliers sont proposés à côté ; cela donnera un côté plus pratique à la libéralisation de l'informatique pour l'utilisateur, avec l'apprentissage du maniement d'un logiciel libre par exemple.

Plus précisément, le programme abordera les points suivants :

  • Introduction aux Logiciels Libres de Véronique Fritière
  • Les formats ouverts de Thierry Stœhr
  • Les licences libres comme un acte de résistance de Laurent Paoletti
  • Comment devenir éditeur de logiciel libre quand on est une entreprise ? de Hybird
  • Creative Commons de Guillaume Perocheau
  • LaTeX de Thierry Stœhr
  • OpenERP de Jean-Marc Le Goff
  • OpenPGP de Jean-Jacques Brucker
  • CaspWiki de Guy Lebègue
  • Inkscape de Véronique Fritière

Durant la journée, il y aura une install-party. Elle est destinée à apprendre aux visiteurs à installer des logiciels libres sur les ordinateurs qu'ils apportent ou de les dépanner sur des problèmes du quotidien par rapport à leurs utilisations. L'objectif est de favoriser l'adoption des logiciels libres avec l'aide de la communauté toulonnaise et de son expérience.

À côté de cela, il y aura la possibilité de réaliser des ateliers et mesures pour OpenStreetMap pour apprendre à contribuer à ce projet de cartographie. Il y a également la possibilité de venir pour signer vos clés numériques PGP !

Informations complémentaires

Si vous souhaitez obtenir plus d'information sur cette journée, son déroulement ou le plan d'accès, merci de visiter le site officiel de la JIL 2013.

Cette journée est organisée par les associations le Club de l'ISEN sur les Logiciels Libres avec la participation notable de Linux-Azur, ToulonuX et Gullivar. Cet évènement est parmi les plus importants de la région sur ces thèmes et reste l'occasion de resserrer les liens de la communauté régionale.

Nous remercions également le soutien financiers ou logistiques des entreprises suivantes : TVT, Hybird, Editions Diamons et Eyrolles.

mer., 01/10/2008

Présentation

Quoi de plus original d'avoir pour premier billet une petite présentation rapide ? Vous m'avez sûrement déjà vu sur le Forum sous le doux pseudonyme de Renault. Utilisateur de Fedora depuis la version 3, j'ai utilisé de manière continue chaque version depuis et ce avec une grande joie.

Tout ce temps passé sous Fedora m'a appris beaucoup de choses dont le fonctionnement interne du projet. Ça sera en effet l'un des objectifs de ces billets, savoir ce qu'il retourne de Fedora et des manières de contribuer et des actualités. Testeurs de Fedora Rawhide non stop, on pourra plonger dans le merveilleux monde des bogues du jour et fonctionnalités du siècle ! Sans oublié l'actualité du Libre, les coups de gueule du soir et d'autres choses dont on verra ensemble et des trolls...

J'espère que ça vous sera utile (ou pas) et que vous prendrez plaisir à lire mes écrits immanquablement mauvais et pas drôle.