Logiciel on Silicone's web

Crée un CD d’installation d’une debian spécialisée

Tue, 18 Jun 2013 18:16:21 +0100

Cet article a été rédigé a l’origine pour linuxembedded.fr : Crée un CD d’installation d’une debian spécialisée.

Parfois un système embarqué se résume à un serveur spécifique et quelques applicatifs. Dans ce cas l’utilisation d’une distribution standard peut être préférable à un buildroot ou autre openembedded. Ici nous avons fait le choix de debian et nous voudrions avoir un CD d’installation complet de notre système.

Développement noyau sur e60

Sun, 03 Apr 2011 20:52:14 +0100

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.

Triage X Bugs of the Week (TXBW18)

Mon, 14 Mar 2011 11:17:27 +0100

Better later than never, I restarted to triage last week, here is the report for it.

#526095 ping & close – KVM switch change makes mouse stop working.
#495139 upstream – cleanlinks: warning in “find” usage.
#550308 ping – x11-apps: xedit search dialog shows garbage.
#555647 ping – x11-xserver-utils: xrandr -o left leaves xdm, after I logout, unresponsive, with no login prompt.

In the mean time, Cyril has been triaging a lot of bugs see Debian XSF News #7.
But there are still 533 bugs to triage.

Mike Hommey recently wrote about graphs for the Debian Bug Tracking System. In particular there is now a per maintainer graph, so here it the X Strike Force bug graph ! (Note: the graph does not filter out some bugs as we do on UDD.

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.

Premiers pas en développement noyau

Tue, 08 Mar 2011 21:34:09 +0100

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:

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

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:

/dev/hello_world: A Simple Introduction to Device Drivers under Linux par Valerie Henson
Writing a Simple USB Driver de Greg Kroah-Hartman

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 the Week (TXBW12)

Fri, 11 Feb 2011 15:02:12 +0100

This report is 2 week late… It was delayed by an important event, not the release of squeeze, but the birth of my first child: Célestine is born Monday the 31th of January.

My wife and Célestine are both fine now but the firsts days were not that easy. I’m starting to recover from the lack of sleep, but I’m still very late on my debian tasks 😉 So I guess I just drop Triaging for week 13, 14 and maybe 15…

Now the bugs I triaged just before :

#509489 ping & merge with #492783 – Switching from tty to X by pressing Alt+cursorkey pass cursorkey keypress to X. OK for this user, waiting for more responses on other merged bugs…
#515546 ping & closed – keys stick when switching consoles.
#369202 ping – randomly activated ‘access keys’.
#547143 ping, it’s udev now, not hal – xorg/evdev/HAL versus serial mouse – submitter said serial devices should be handled using inputattach. I think It’s been added to some docs but didn’t take time to look at it.
#547888 ping & closed by submitter thanks! – high CPU usage in X.org server after some time.
#489996 mail error, closed – problem auto-detecting / selecting some modes.
#550124 ping & closed – some modes aren’t recognized.

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.

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

Sat, 22 Jan 2011 10:51:11 +0100

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.

Triaging bugs is not that hard !

Mon, 17 Jan 2011 18:13:28 +0100

There is a big thread on -devel that started about Forwarding bugs upstream, the idea is that it should be the maintainer’s job. While it’s true in general, some understaffed teams are so flooded by bugs that they just can’t do it.
I’ve seen more than once the X Strike Force asking a user to report upstream (pointing to the relevant BTS) and come back with the tracking URL to be attached to the bug. This was mostly for driver issue if I remember well.
And most users did it, so thanks!

Then the thread evolved in lots of directions, I’m not following all of it, but there was the question of the bug triaging and as I’m doing it for the X packages, I want to share about my experience here.

The available triaging docs

The debian wiki already have a general Bug Triage page.
The thread pointed to the KDE Bug triaging page.
The X Strike Force has some pages, one on the wiki and a new one more specific to bug triaging on the alioth project’s doc.
And when it comes to closing bugs with version information, there is a good read on the wiki: Bugs Version Tracking.
Finally don’t hesitate to reopen the BTS documentation whenever you need to write to control@b.d.o !

Now if all those docs don’t help you, then try to improve the docs as a first step ! 😉

Talk with the maintainer(s)

Well I did met Julien Cristau and Cyril Brulebois in person during mini-DebConf Paris/2010 that certainly helped. But we exchanged several mails, or met on IRC channel #debian-x.
But the triaging rules of the X Strike Force (linked above) were pretty clear anyway.

My current process

This process has evolved over time with the response of several contributors either to help or to fix to my mistakes, thanks!

List bug from UDD: XSF unstable bugs sorted by date.
Pick an old bug (once you answer and UDD runs, the bug moves down the list, so there are always old bugs on the top).
Read the report, don’t be afraid by the subject, it might be unrelated, the bug might be merged with other bugs, then reading the other bugs can help.
If relevant try to reproduce it. (most bugs in X are hardware related or specific to one setup, so it’s not that often that I have something to test).
Decide what to do, most of the time, I will ‘ping’ the submitter.
I’m a mutt user, and to my help the bts command as a way to open the bug mbox in mutt, that makes it really easy to answer the bug.
So I launch bts -m show $n where $n is the bug number, and I can then answer the bug from mutt.
The triaging procedure suggest to ping -submitter, but using mutt it’s easier to just reply and add a -quiet to the bug number (this avoid spamming the debian-x with all my pings).
In the message, always try to be kind and helpful, most of the time ask to test newer versions.
Keep track of the pinged bugs, well I do it for my blog but it will be useful anyway, see below.
When the submitter answers, just react accordingly, if the bug can be closed, then close it ! 😉
If after some time, the bug are still not answered, consider closing them (I haven’t started that yet, but this will probably get the bug number down faster:) ).

Note: Sometime I don’t send the bug to -quiet so that other debian-x subscriber can have a look at the bug. They then can give me advices, or close the bug directly with a stronger reason than any I could have found. 😉

To submitters, please keep the bug CCed when you answer, thanks.

For the skeptics

Yes as a newbie I did some mistakes, but I was always corrected in a nice way, with explanations. Also I try to have a conservative approach, I don’t close bugs if I’m not sure, I ask if I can close them, so it might take longer, but in the end the effect is the same for the bug, but not the same to the submitter ! 😉

Also this work might look boring, but it’s actually rewarding, most of the answers I received included a cheerful message thanking me for following up on the bug. Not to mention all I’ve learned on Xorg.

Conclusion

As long as I have time for it, I’ll continue to triage bugs and I’d love to see others coming to help me on X or probably better go and help some other teams that also need help, and flood the planet with bug triaging reports ! 😉

Get involved !

Triage X Bugs of the last 2010 Week (TXBW8)

Fri, 31 Dec 2010 18:29:38 +0100

Happy new year !

#440495, #437255 ping – Keyboard steal after stopping touchpad.
#476143 Closed: submitter never answered Brice’s request – xserver-xorg-video-nv: Driver reports wrong display size.
#468331 ping – xserver-xorg-input-kbd: xorg.conf okay, no AltGr though but “setxkbmap -variant nodeadkeys de” works.
#498210 ping – xserver-xorg-input-kbd: ctrl:nocaps keycode 66 is on both the control and shiftlock modifier list.
#488685 ping & close: hardware not available anymore – xserver-xorg-input-kbd: Acer TravelMate 2303M : the ‘Fn’ key is inverted.
#511910 ping – xserver-xorg-input-evtouch 0.8.7-3 does not work with HAL.
#513297 close – x11-xkb-utils: When I use the setxkbmap command i get the following error: Error loading new keyboard description.

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.

Triage X Bugs of the Christmas Week (TXBW7)

Thu, 23 Dec 2010 12:46:54 +0100

For some reason¹ bug #607242 did not make it to the debian-x@d.o mailing list, I got aware of it only by the message shirish sent to my blog.
If he didn’t write to me, this bug will have waited for what… about 3 years until I got all the 800+ bugs triaged ? So please you can help triaging X bugs, first subscribe to the debian-x mailing list so you can get the feeling of what to respond to some bugs, and join the TXBW effort 😉

#607242 reassign & give+ask moreinfo.
#403350 ping & try nouveau – xserver-xorg-video-nv: xset dpms force off does not turn off the backlight.
#469104 config suggestions & close – xserver-xorg-video-tdfx: screen resolution too low.
#476198 closed – xserver-xorg-video-radeonhd: Cannot turn on a secondary screen without restarting X (xrandr-related problem).
#492783 ping, unreproducible – vt switch key combination leaks to clients.
#496150 ping – xserver-xorg-core: shutting off monitor messes up display.
#504104 ping & closed – xserver-xorg-input-mouse: Emulate3Buttons stops working from time to time.

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.

Note 1: The Xorg.0.log file was so huge that the mailing list did not accept the mail. ↩︎

Triage X Bugs of the Week 6 (TXBW6)

Fri, 17 Dec 2010 17:41:15 +0100

An other week, a few more bugs looked, unfortunately in the mean time the number of bug grew to 875…

#471423 ping – ati driver ignore Option “Enable” “false” in monitor section, but accept the undocumented Option “Disable” “true”.
#468561 ping & closed – vesa: switching resolution with xrandr after suspend-to-ram.
#447526 ping – memory leaks.
#475534 closed – as reported said, oclock seams to work correctly…
#466044 ping – xserver-xorg-core: internal screen of laptop with external screen attached not blanked when laptop closed but still in use.
#482317 ping – libxt6: scroll list overflow in gv.
#425814 ping – xserver-xorg-video-ati: Xv broken on Mach64 3D Rage LT Pro AGP-133.

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.