Tag : git

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.

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

Triage X Bugs of 2011 first Weeks (TXBW9-10-11)

I’ve been lasy about the reporting lately, so this is a 3 weeks update at once !

The bug count according to udd is down to 818. I guess this is due to Kibi‘s triaging on input related bugs, but I helped to close a few one too !

I kept my week numbering as before, so now I know the first bugs I pinged are more that 11 weeks old. I guess if some submitter did not answer in that delay, they will probably never do it. I think the bug count will go down again ! 😉

  • #451708 ping & close – xserver-xorg-input-synaptics: Option “GuestMouseOff” “true” not working.
  • #424743 ping & forwarded – X11 pen driver doesn’t work on tabletPC Fujitsu Stylistic 2300 (fix included).
  • #499664 ping, try nouveau – X fails to start with xserver-xorg-video-nv 1:2.1.12-1.
  • #512614 confirmed & upstream – xset dpms rejects reasonable values as illegal.
  • #512711 ping and later closed – All keypresses repeated roughly three times each, makes login impossible.
  • #513128 ping – X server crashes every time when gnome-screensaver starts.
  • #486356 merge with #482592 – numlock led is inversed (using numlockx) .
  • #515737 ping & closed – After upgrading from Etch to Lenny, mouse pointer is very slow and keys don’t repeat.
  • #515840 ping – Desktop is not using full screen after upgrade from etch to lenny.
  • #516860 closed after looking at the git history – Xorg with ‘-sharevts’ use almost 100% of the CPU.
  • #362434 ping & closed, suggested to try nouveau – nv has problems with xcursor-themes.
  • #502131 ping & closed – System gets into a `state’ and fails to process modifier keys.
  • #453296 closed (old ping unanswered) – MacBook: cannot assign right mouse click to lower Enter key.
  • #504537 ping – X server eats CPU on sparc.
  • #502313 ping – Applications are getting “ghost” Alt keypress events, but I press no keys.
  • #527118 ping – autoadded input devices kill X server.
  • #270887 forwarded – startx and xinit do not preserve client arguments.
  • #542542 closed after looking at the git history – non-VGA compatible graphics devices won’t run X.
  • #492888 ping – xorg ignores keystrokes.
  • #543210 merge with #492783 – Alt-F7 to return to X, passes F7 key to top focus’d window.
  • #524413 closed – xauth fails with xorg 7.4, this was actually an xinit bug and the git log lead to #549377 being closed…

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

New Projects pages and Gengo update.

I’ve been adding pages for my Projects. Previously this kind of data was on Trac, but I’ve never been using it actively. And I’m mostly using git for my new development instead of subversion.

I could have used Trac with git, but for project presentation WordPress pages are good enough.

But I wanted to have comments on some pages, which meant a theme update and another Gengo fix. Also I’ve done a big history rewrite by moving my version of gengo to git. If ever Jamie Talbot is really seriously considering starting development again. Then I hope he can pick some patches from my version 😉

Trial and errors with git branches

I’ve recently learned to use git (for my xorg adapted packages) and used it later for netsed.

In order to develop UDP in netsed, I had to try several stuff, my network programming experience in C is back to some school time, so this was really trial and errors. And here git really helps, all I had to do is create branches for each trial, so I don’t loose any tracks I’ve taken, then when I found the right way to do it, I could just merge or cherry pick from the branches (or even just copy past from gitk to my favorite editor gvim) and that was it !

Of course I can now delete the trial branches, but those were really helpful during development time.

This meant abusing of git commit --amend, git merge ( --squash ) and git cherry-pick commands, but well you cannot build a clean code without effort.

I should probably give another look at git stash which seams to fill similar needs.

Taking over Netsed

Netsed, the network packet stream editor, is a program originally written by Michal Zalewski .

While the program idea is good, it’s implementation had some lack, and nobody seamed to care enough to fix it.

I did already hack it some years ago, and it appeared that my changes was fixing a debian RC bug (#586037) so I took netsed maintenance as one of my new projects!

For now only my changes and patches proposed by Mats Erik Andersson are integrated.

But I will start working on a test suite (still have to find the right tools for that, would ruby be nice ?), and of course implement UDP support.

Also I’d like to really thank Mats Erik Andersson and Tim Retout for their answers and support.

Resources:

Building xserver 1.6 for Xorg 7.5

Update: As explained in other posts, I’m no longer using this xserver version myself. So this stays here, but I’m not planning to update it in any manner.

The goal of the xserver downgrading is to run intel IEGD drivers on recent GNU/Linux distribution (debian squeese in my case). This seams to be the only maintained driver for the US15W GMA500 (poulsbo) chipset.

Continuer la lecture →