Développement noyau sur e60

Comme j’ai accès à la console série sur liseuse Samsung e60 compilons un nouveau noyau linux.

Le processeur de la liseuse e60 est un ARM, pour compiler le noyau pour ce processeur il nous faut une chaine de compilation croisée.
La première option est d’utiliser celle fournie par samsung avec le reste des sources. A priori ça fonctionne mais utiliser des binaires de sources inconnue ne m’enchantait guerre.
La seconde solution serait de recompiler la chaine nous même, c’est souvent la seule solutions pour des systèmes exotiques nécessitant quelques patchs.
Ici, a bien regardé les fichiers de Samsung, les binutils viennent d’une version entre 2.17 et 2.18 (leur version est nommée 2.17.50 mais ne correspond pas tout à fait à se snapshot non plus…) mais il ne semble pas y avoir de patch ‘maison’. Quand a gcc j’ai pas pris le temps de vérifier.
J’ai opté pour la chaine de compilation croisée du projet emdebian dans sa version lenny (Tout comme le propose le magazine Open Silicium n°1 dans son article sur FriendlyARM).

Installation de la chaine de compilation croisée sur debian

Tout d’abord les clef des l’archive:


sudo apt-get install emdebian-archive-keyring

Ensuite nous ajoutons un fichier /etc/apt/sources.list.d/emdebian.list avec le contenu suivant:


deb http://ftp.uk.debian.org/emdebian/toolchains lenny main
deb-src http://ftp.uk.debian.org/emdebian/toolchains lenny main

Puis une mise à jours des liste des paquets afin d’installer les paquets nécessaires:


sudo apt-get update
sudo apt-get install libc6-armel-cross libc6-dev-armel-cross libstdc++6-armel-cross binutils-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

Voila, nous disposons maintenant d’une chaine de compilation croisée installée avec des paquets, donc facile à mettre à jour ou à désinstaller.

Les sources du noyau

Samsung fournit une version modifiée du 2.6.29.4, en récupérant la branche git 2.6.29.y du noyau, j’ai rapidement vu que leur changement s’appliquait à la version 2.6.29.6 (dernière de cette branche).

Afin de mieux trier les changements michel.s avait déjà séparé les changements de Samsung en plusieurs patchs (les patchs sur le projet e60-open). Après quelques essai j’ai concocté un fichier series qui permet d’appliquer ces patchs avec quilt ou mieux encore de des importer dans une branche git avec git quiltimport. L’ordre que j’ai choisit permet en particulier de se débarrasser facilement des quelques patchs (les derniers).

On notera dans ces patchs la présence de quelques fichiers binaires:

  • fs/rfs/*.o une couche de journalisation propriétaire sur la fat. Si vous voulez mon avis, elle n’est pas nécessaire, après tout nous disposons de systèmes de fichiers journalisé libre, et linux est capable de monter autre chose que de la FAT par USB…
  • drivers/usb/gadget/file_storage.o le fichier .c correspondant a de plus été retiré, la licence BSD/GPL de l’original autorise une distribution binaire (toutefois, je n’ai pas vérifié si Alan Stern est cité dans la doc) mais j’aurais bien apprécié que Samsung fournisse le source.

U-Boot

Avant de compiler le noyau, il nous faut l’utilitaire mkimage fourni par U-Boot. Ici, pas de chichis, nous compilons la version de U-Boot fournie par Samsung, et nous copions tools/mkimage dans notre path (c’est la seule méthode d’installation que j’ai pu trouver).


make smdkc100_config 
make CROSS_COMPILE=arm-linux-gnueabi-

cp tools/mkimage ~/bin/

Compilation de linux

Pour la configuration un des patch fourni un .config qui est une copie de config_rfs donc même sans appliquer ce patch, nous pouvons récupérer la config de samsung.

Ensuite, on compile enfin !


make CROSS_COMPILE=arm-linux-gnueabi- CFLAGS="-march=armv4t -mtune=cortex-a8" CXXFLAGS="-march=armv4t -mtune=cortex-a8" ARCH=arm uImage


Nous pouvons charger notre noyau en suivant la procédure de test de noyau du projet e60-open la commande pour changer le noyau sera alors


sudo dnw arch/arm/boot/uImage

Voila, ça marche ! Enfin presque, le noyau ne trouve pas ses modules. Ceux présents dans nos sources ne sont pas un vrai problème (mais le sujet d’un prochain article) en revanche les modules /lib/modules/max14540.ko et lib/modules/dhd.ko ne sont pas présent dans les sources alors qu’ils présentent une licence GPL au noyau.

Les sources manquants

Le site Samsung Open Source Release Center possède une interface pour les contacter, mais elle ne semble pas bien fonctionner (j’ai même booter mon netbook sous windows pour essayer avec IE8 sans succes!). En fouillant le forum e60 j’ai retrouvé leur adresse email et leur ai écrit, pas de réponse jusqu’à présent (pas même automatique…). Patience …

Conclusion

Nous pouvons compiler le noyau de la liseuse e60 sans utiliser la chaine de compilation fournie par Samsung.
Il reste du travail pour le changement des modules car ceux présent sur la liseuses sont compilé pour la version 2.6.29.4 du noyau et notre noyau refuse de les charger. (J’ai déjà fait quelques tests mais ça sera le sujet d’un prochain article.)
Et surtout sans les sources manquants nous allons avoir du mal a exploiter au mieux notre liseuse e60.

Mise à jours: Je viens de recevoir une réponse de Samsung, ils ont mis a jours leur archive. Il faut encore que je test ça.

Console série sur liseuse Samsung E60

Les bons plans Samsung de janvier avait déjà fait le tour du web, et je n’en reparlerais pas (sauf pour dire que j’en ai profiter pour acquérir une liseuse Samsung E60).

Une communauté s’est formée autour d’un forum (e60 sur hardware.fr) et d’un espace google code (e60-open).

On y trouve pas mal d’infos et en particulier la console série. De mon coté je dispose d’un adaptateur USB vers série en LVTTL 3.3V (à base de FTDI FT2232C) donc j’ai opté pour la connexion sur R232 et R233. Or RDX (R232) est déjà connecté au circuit MAX232 qui converti les niveau LVTTL vers les niveaux série, et apparemment ce petit gars était plus fort que mon FTDI… J’ai donc retiré R232 et connecté mon FTDI à la palace. Restait à savoir quel pad de R232 allait vers le CPU… Coup de pot, le premier que j’ai essayé était le bon: le coté le plus proche de la batterie.

Une petite photo de mes belles soudures :
mes belles soudures

Et voila, j’ai ensuite suivi la procédure pour tester un kernel en chargeant le kernel fourni sur le SVN du projet. Et ça à marché (à ceci prêt que j’ai dû déchargé le module secbulk, donc soit j’ai pas compris, soit il ne sert pas).

Prochain épisode, compilation et test d’un noyau Linux.

Test comparatif de microSD

Bon pour commencer, je n’ai pas demandé aux fabricants de m’offrir des cartes pour les tester, donc ce test est loin d’être exhaustif. En fait je ne compare que deux cartes !
Voila mon frère et moi avons acheté quelques cartes microSD SDHC 16G : une de marque SanDisk et une de marque Kingstone. Nous avons choisi des marques pour être à peu près sûrs d’avoir des performances correctes.

Méthode de test

J’ai cherché à définir un protocole de test, copier des fichiers de différentes tailles… puis je suis tombé sur ce blog: MicroSD class 6 Performance Benchmarks. Il propose d’utiliser un outil présent dans le bureau GNOME: palimpsest.
Bon alors cet outil ne veut pas tester la carte si il y détecte une table des partitions, le blog cité précédemment propose d’effacer toute la flash avec la commande suivante:

dd if=/dev/zero of=/dev/sdb

Brutaliser de la sorte une carte SD n’est peut être pas ce qu’il y a de mieux à faire. Surtout quand l’on sait que l’état « effacé » d’une flash est avec tous ses bits à 1, écrire 0 partout revient en fait à la remplir plus qu’à l’effacer…
Mais bon j’y ai pas trop réfléchit quand j’ai fait le test, donc je suis parti la dessus:

sync; date; sudo time dd if=/dev/zero of=/dev/sdb; sync; date

Les appels à date permettent d’avoir une première estimation du temps d’écriture, en fait, dd donne aussi quelques statistiques donc c’était pas nécessaire.

Puis le test proprement dit:

LANG=C palimpsest

Attention au port USB utilisé pour le lecteur SDHC, si les traces du noyau (dmesg) contiennent la ligne suivante, il faut trouver un autre port !

not running at top speed; connect to a high speed hub

Bon, assez de blabla…

Les résultats

Kingston microSD 16G SDHC Classe 4

Résultats de dd: 15997075456 octets (16 GB) copiés en 6491,87 s (1h48) soit 2,5 MB/s.

Performance en lecture (courbe bleue):

  • Débit de lecture minimal: 18,6 MB/s
  • Débit de lecture maximal: 20,9 MB/s
  • Débit de lecture moyen: 18,9 MB/s

Performance en écriture (courbe rouge):

  • Débit d’écriture minimal: 1,7 MB/s
  • Débit d’écriture maximal: 4,7 MB/s
  • Débit d’écriture moyen: 2,4 MB/s

Temps d’accès moyen: 2,2ms (courbe verte)

kingstone microSD 16G - graphique de performance

SanDisk microSD 16G SDHC Classe 4

Résultats de dd: 15931539456 octets (16 GB) copiés en 4934,48 s (1h22) soit 3,2 MB/s

Performance en lecture (courbe bleue):

  • Débit de lecture minimal: 20,6 MB/s
  • Débit de lecture maximal: 21,1 MB/s
  • Débit de lecture moyen: 21,0 MB/s

Performance en écriture (courbe rouge):

  • Débit d’écriture minimal: 1,3 MB/s
  • Débit d’écriture maximal: 5,7 MB/s
  • Débit d’écriture moyen: 2,4 MB/s

Temps d’accès moyen: 1,6ms (courbe verte)

SanDisk microSD 16G - graphique de performance

Conclusion

Ces deux cartes se valent à peu prés, avec un léger avantage pour la carte SanDisk.

Premiers pas en développement noyau

Je voulais me mettre au développement noyau, mais je ne savais pas par où commencer, alors un sage m’a dit: « pour apprendre rien de tel que de le faire: vous achetez un petit périphérique USB et vous en écrivez le driver. »
Ma réponse a été: « effectivement, je n’y avais pas pensé, en général on utilise la libusb pour ce genre de choses. »

Un périphérique USB

Et voila que quelques jours après, sans avoir trouvé de périphérique sympa je me suis dit, mais pourquoi pas le faire aussi ?
Comme je vous l’ai déjà raconté, j’ai déjà bricolé un périphérique USB: l’USBtinyISP, donc je suis allé rechercher le code original de usbtiny et je me suis monté un petit prototype avec 4 LED et 2 boutons:

Photo de mon prototype

Bon plutôt que d’utiliser un ATtiny, j’ai pris un ATmega8 histoire d’avoir un peu de place pour y ajouter du code plus tard ;-) (l’ATtiny2313 est déjà super plein pour l’USBtinyISP).

Et voila le schéma (en image, les sources gschem sont sous git dans le répertoire sch):

Le schéma

Une fois le montage prêt, quelques lignes de code basées sur l’exemple de tinyusb et hop un firmware pour l’ATmega (à la racine du projet).

Qu’il a fallut tester, hop la première méthode évoquée plus haut, quelques lignes de code avec libusb, disponible dans le répertoire test, m’ont permis de parfaire le firmware ;-)

Voila, tout marche, on va pouvoir entrer dans le vif du sujet.

Le gestionnaire de périphérique Linux

En fait j’ai tout simplement suivi et adapté les tutoriels suivants:

En regardant la version de usbled.c présente dans les sources de Linux afin de mettre à jour les derniers détails.

Cela donne un driver qui ajoute les pseudo-fichiers leds et keys dans le répertoire du périphérique déjà créé dans /sys/bus/usb/ par le noyau Linux.

Voila ! Vous je sais pas mais moi j’ai appris plein de choses ! ;-)

Tout le code est disponible sous GPL2 et GPL2+ sur mon gitweb: jvdg_usbgadget.git

Pour le nom un peu égocentrique, c’était surtout pour éviter tout risque de conflit, comme de toutes façons ceci n’a pas vocation à être intégré dans Linux (le périphérique utilise un ID USB réservé aux prototypes, donc inutilisable en grande série…)

déménagement … serveur compris

En fait ce serveur est hébergé à la maison, sur notre ligne ADSL, donc il a déménagé avec le reste !

Ceci explique la semaine d’interruption il y a deux semaine environ, si toutefois quelqu’un l’a remarqué (mis à part google).

Le déménagement à pris pas mal de mon temps, j’ai du tout emballer, en particulier mes bricolages électronique donc le projet n’a pas beaucoup avancé…

De plus je me suis offert un EeePC 1201HA, je voulais un écran 12 pouces pour avoir quelque chose d’un peu plus utilisable que le 701p. Il est livré avec Windows 7 et le chipset est un GMA500 (poulsbo) ce qui ne facilite pas l’installation de linux, mais bon j’ai installé debian (il reste encore à faire, mais ça sera le sujet d’un autre billet).

Mises à jour de WordPress et des plugins

À la suite des déboires d’hier, je viens de mettre à jours tous mes plugins.

Le changement des URI par le plugin Gengo, qui ajoutait les code des langues m’embarquait dans une redirection infinie (en ajoutant des fr+en/ à l’URI) j’ai du le désactiver. Mais ce faisant, j’ai cassé les URI existante de vos marque-pages (si vous en aviez) et surtout de Google…
Donc j’ai encore modifié gengo, maintenant les URI qui se terminent par un code de langue sont redirigé vers l’URI sans.
Une lecture récente: Cool URIs don’t change exprime ce besoin de conserver les URI, ici je redirige, c’est mieux que rien et vous évite le 404 ;)

J’ai trouvé ce lien sur le Blog de Peter Eisentraut. Je lisait sont article a propos de Remove et Purge. Je fut séduit par l’idée, je l’ai même appliqué quelques jours. Puis j’ai lut les commentaires, j’en reste à la méthode l~c pour crée une vue dans aptitude ;) . Par le passé, j’utilisais synaptic pour purger les résidus restant…

ça fait un bail…

Bon, en fait je lis plus que je n’écris depuis que j’ai syndiqué Planet Debian dans mon aggrégateur de flux, gregarious.

J’ai aussi fait quelques changement sur le thème, mis a jours wordpress sans gros soucis. Merci à wordpress et debian.

Pour finir, ce blog est sous titré « electronics » et je n’ai jamais parlé d’électronique jusqu’ici. En revanche j’ai pratiqué. ;)

J’ai cherché des soft pour tracé des schéma et garder un trace de mon travail, dans un premier temps pour moi, puis pour les publier sur ce blog quand il seront prèt.
Un projet qui m’a semblé intéressant: Fritzing mais il semble trop instable, Je ne veux pas dire qu’il plante mais que le format de fichier n’est pas figé. Ce qui signifie que des projets enregistré avec la version d’aujourd’hui ne s’ouvriront peut être plus avec la version de demain.

Donc je me suis tourné vers les outils du gEDA project. À commencer par gschem pour tracer les schéma électronique puis je me suis mis à PCB pour préparer mes cartes.
Je ne fait pas de vrai PCBs, je préfère utiliser des cartes à prototype et y souder pleins de petits fils, mais utiliser PCD avec une grille à 100mil (1mil c’est 1/1000 de pouces soit 0,0254mm) facilite grandement le placement des composants.

J’ai commencer à bricoler avec des micro-contrôleurs AVR de Atmel en utilisant avr-gcc et avr-libc. J’ai commencer par me faire un programmateur d’avrpar usb, l’USBtinyISP. Je publierais les fichiers gschem et PCB un des ces quatres. (ou plus vite si vous me le demandez).

J’allais oublié, J’ai retrouvé un vieux liens sur le Chip Directory. C’est une collection de ficher decrivant le brochage de beaucoup de vieux circuits tels les séries TTL 74xx et les séries MOS 40xx.

Configuration SSL et hôtes virtuels : Certificat multivalué

  1. Configuration SSL et hôtes virtuels (31 mai 2009)
  2. Configuration SSL et hôtes virtuels : Certificat multivalué (30 juillet 2009)

Le premier article reprenait les bases de la configuration SSL, maintenant nous pouvons vraiment nous attacher au cas des hôtes virtuels par nom, c’est à dire sur la même adresse IP.

Serait-il possible d’avoir deux noms de domaine en accompagnement pour le plat du jour ?

Pour établir la connexion SSL, le serveur présente son certificat, celui-ci doit donc être valide pour tous les noms de domaine qu’il représente. L’idée consiste donc à lister les différents domaines dans le certificat.

Ainsi quelque soit l’hôte virtuel contacté, le serveur répond par le même certificat qui est valide pour tous, et la connexion SSL s’établit.

Continue reading

Déclaration de revenu 2009 sous debian testing

J’ai simplement installé le paquet « sun-java6-plugin », j’avais déjà mon certificat (importé de firefox sous windows), et je n’ai eu aucune difficulté pour la signature.

En revanche j’ai eu droit à quelques erreurs de segmentations de iceweasel.

Et évidement le site ne reconnais pas iceweasel, mais ça passe.

Un dernier point, j’ai remarqué un problème d’affichage sur la page de résumé, et les boutons de signature/envoi, peut être dû aux onglets Adblock… ou a un bug…

Sinon avant de m’y mettre j’ai constater que certains avait eu plus de difficulté que moi l’an dernier, (en fait j’ai même commencé par installer sun-java5-plugin, mais ça ne marchait pas!).
Les détails
ici sur le blog d’Olivier Berger.

Configuration SSL et hôtes virtuels

  1. Configuration SSL et hôtes virtuels (31 mai 2009)
  2. Configuration SSL et hôtes virtuels : Certificat multivalué (30 juillet 2009)

La mise en place de certificats SSL pour les différents services (https, smtp-tls, pops, imaps…) d’un serveur est relativement bien documentée. En revanche si l’on a affaire à des hôtes virtuels sur la même adresse IP, c’est une autre histoire !

Je compte présenter ma configuration et mes quelques investigations sur le sujet en plusieurs articles :

  • Dans cet article, je reprendrais la configuration de l’autorité de certification, et la création de certificats pour un hôte simple (un seul nom de domaine).
  • Dans un second article, nous aborderons le vif du sujet avec la création d’un certificat multivalué (un certificat pour plusieurs noms de domaine).
  • Un troisième article sera consacré à la gestion de la révocation des certificats afin de parfaire notre autorité de certification.

D’autres articles viendront sûrement compléter ce dossier. En particulier pour évoquer : une autre méthode pour les hôtes virtuels sous apache (utilisant le SNI), les certificats à validation étendue (EV) ou encore la gestion des certificats sous firefox 3…

Continue reading