Utilisateur:Pini

De openmoko-fr.

Ingénieur Informaticien. La quarantaine passée.

Debian GNU/Linux à la maison depuis 1998, et au boulot depuis 2002.

Heureux possesseur d'un FreeRunner depuis fin août 2008. C'est bien entendu une Debian qui le fait tourner, sur une carte microSDHC de 8Go.


Archives des notes : 2008.


Sommaire

Journal

12/02/2010

Toujours le son - Retour à 'Mic 2'

Suite à quelques échanges sur la liste community, je suis revenu à mon ancienne config, en réduisant significativement le gain géré par control.12. Résultat, qualité audio de même niveau qu'avec la config QtMoko, tout en ayant une config plus en ligne avec les recommandations des développeurs.

J'en ai profité pour mettre à jour la page wiki de réglage du son.

Pour résumer

Ancienne config (qualité nulle avec un fond sonore) 

control.48 = 1
control.12 = 6
control.63 = 'Mic 2'
control.5  = 127

Config inspirée de QtMoko (OK) 

control.48 = 1
control.12 = 6
control.63 = 'Right PGA'
control.5  = 127

Config actuelle (OK) 

control.48 = 1
control.12 = 1
control.63 = 'Mic 2'
control.5  = 110

05/02/2010

Enfin un son correct

J'ai récemment fait buzzfixer mon FR. Petit test rapide, à la maison : c'est nettement mieux, plus de buzz. \o/

Mais... il y a un "mais" : en extérieur ou avec un bruit de fond (gare, centre commercial, bistro) même léger, son ho-rri-ble pour l'interlocuteur. 90% du temps la conversation tenait principalement du "hein ? on comprend rien avec ton téléphone !". Mega frustrant... :(

Heureusement, grâce à ce thread sur le forum, j'ai eu l'idée d'aller chercher du côté de QtMoko voir s'il n'y avait pas un paramétrage ALSA plus pertinent à récupérer. Et bingo ! Après quelques jour d'essai de la nouvelle config, mon FR revit et j'ai à nouveau des conversations téléphoniques sereines.

Il n'y a plus qu'à pousser cette config dans Debian.

28/01/2010

Xorg.conf et udev

Cette semaine j'ai passé un peu de temps à résoudre un problème curieux et très gênant. En gros, depuis l'upgrade de mon FR du week-end dernier, le touchscreen se comportait très bizarrement. Après quelques tâtonnement, j'ai vu que chaque action était reproduite à un autre endroit de l'écran. Par exemple, si je tire le curseur graphique sur le côté gauche en faisant glisser mon doigt sur l'écran, le curseur se balade aussi sur le haut de l'écran. Le tout avec une parfaite symétrie :

  • gauche -> haut
  • bas -> gauche
  • droite -> bas
  • bas -> gauche

Le pire est que cela faisait aléatoirement - mais très rapidement - planter X dès que je voulais utiliser le clavier matchbox :(

J'ai questionné la liste smartphones-userland et on m'a donné une piste de réponse : utiliser le driver evdev en lieu et place de tslib.

Je n'en suis pas resté là, et après analyse des logs Xorg et des paquets xserver-xorg-input-tslib et xserver-xorg-input-evdev, j'ai enfin compris ce qu'il se passait : Le paquet du driver evedev installe un fichier rules pour udev qui joue le rôle de catchall pour la plupart des périphériques d'entrée X. Et le paquet du driver tslib n'en installe pas. Avec pour conséquence :

  • chargement du pilote evdev déclenché par udev
  • chargement du pilote tslib spécifié dans xorg.conf

=> deux drivers qui se tirent la bourre pour gérer les évènements du touchscreen :/

Solution :

  • ajouter un fichier rules udev dans le paquet du driver tslib
  • supprimer la référence à tslib dans xorg.conf (sinon Xorg verra un deuxième touchscreen au lieu de modifier la configuration de celui détecté par udev).

Le fichier xorg.conf est quasiment réduit à sa plus simple expression : 

pini@debian-gta02:~$ cat /etc/X11/xorg.conf 
# Xorg configuration for an Openmoko FreeRunner
Section "Device"
	Identifier	"Configured Video Device"
	Driver		"glamo"
EndSection

Dernier problème à régler : plus possible de configurer le clic droit dans xorg.conf (sinon X voit deux touchscreens). J'ai donc ajouté un fichier rules udev perso dans /etc/udev/rules pour le configurer via udev : 

pini@debian-gta02:~$ cat /etc/udev/rules.d/67-tslib-right-clic.rules 
ACTION!="add|change", GOTO="xorg_tslib_end"
KERNEL!="event*", GOTO="xorg_tslib_end"

ENV{x11_driver}=="tslib", ENV{x11_options.EmulateRightButton}="1"

LABEL="xorg_tslib_end"

Et voilà :)

DD

Grâce à Navit, me voici entré dans le sacro-saint cercle des DD.

/me est pas mal fier :D

18/10/2009

navit 0.2.0~svn2663+dfsg.1-1 dans Debian unstable

Un nouveau snapshot de Navit (svn2663) est entré dans Debian unstable il y a quelques jours. Pas grand'chose à signaler sur cette version, si ce n'est que lors d'une recherche de ville l'affichage n'est plus limité à deux lignes. Ça améliore beaucoup l'utilisabilité quand on cherche des noms composés comme "Pont de Vaux".

05/10/2009

Keyboard autorepeat = off

Pourquoi n'y ai-je pas pensé plus tôt ?!

Ça fait des mois que le clavier matchbox m'agace avec sa mauvaise habitude de bloquer une touche quand il est un poil chargé en CPU. Et depuis mon passage à xserver-xorg-video-glamo, c'est pire...

J'ai enfin eu l'idée de désactiver l'autorepeat du clavier pour contourner le problème. Et ça change la vie ! \o/

fso-usaged - fso-abyss

Aujourd'hui j'ai migré ma configuration FSO pour utiliser les nouvelles implémentations en Vala du gestionnaire de ressources (usaged) et du muxer GSM (abyss). Pour cela je me suis appuyé sur ces deux mails de la liste pkg-fso-maint. Soit : 

$ sudo apt-get install fso-abyss fso-usaged

Dans /etc/frameworkd.conf :

  • Ajouter : 
[fsousage]
disable = 0
lowlevel_type = openmoko

[fsousage.controller]
[fsousage.lowlevel_openmoko]
  • Désactiver l'ancien ousaged : 
[ousaged]
disable = 1
sync_resources_with_lifecycle = always
  • Sélectionner abyss comme muxer GSM : 
[ogsmd]
ti_calypso_muxer = fso-abyss
...

Ensuite redémarrage de FSO via D-Bus : 

$ sudo invoke-rc.d dbus restart

Puis redémarrage de Zhone...

Test avec quelques coups de fil... Ça marche !

04/10/2009

xserver-xorg-video-glamo

Cela fait quelque temps maintenant que xserver-xorg-video-glamo est disponible en remplacement de Xglamo. Je viens de le tester, et pour l'instant je le garde :

  • le clic droit fonctionne, et ce sans bricolage spécifique
  • les raccourcis claviers fonctionnent également

En revanche je ne saurai vraiment pas dire si les performances de l'affichage sont meilleures par rapport à fbdev. Si c'est le cas ce n'est pas flagrant pour un usage standard.

Voir les instructions d'installation sur la page DebianOnTheFreeRunner.

uboot-envtools

Fin 2008 j'avais pondu un script pour modifier l'environnement u-boot du FR. Quelque temps après j'ai eu vent du package uboot-envtools qui fait beaucoup mieux.

Je n'avais encore jamais eu l'occasion de l'utiliser jusqu'à aujourd'hui... et je regrette de ne pas l'avoir fait plus tôt ! Il permet, grâce à ses commandes fw_printenv et fw_setenv, à utiliser directement sur le FR, de modifier l'environnement u-boot sans rebooter.

Exemple d'utilisation : 

pini@debian-gta02:~$ sudo fw_printenv
boot_1=setenv bootargs ${bootargs_base} ${glamo} ${mtdparts}; nand read.e 0x32000000 kernel 0x200000; bootm 0x32000000
boot_6=setenv bootargs ${bootargs_base} ${glamo} ${mtdparts} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5; mmcinit; ext2load mmc 1 0x32000000 uImage-fso.bin; bootm 0x32000000
boot_8=setenv bootargs ${bootargs_base} ${glamo} ${mtdparts} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5; mmcinit; ext2load mmc 1 0x32000000 uImage-Om.bin; bootm 0x32000000
boot_menu_timeout=65000
...
pini@debian-gta02:~$ sudo fw_setenv boot_1 'setenv bootargs ${bootargs_base} ${glamo} ${mtdparts} quiet; nand read.e 0x32000000 kernel 0x200000; bootm 0x32000000'
pini@debian-gta02:~$ sudo fw_printenv boot_1
boot_1=setenv bootargs ${bootargs_base} ${glamo} ${mtdparts} quiet; nand read.e 0x32000000 kernel 0x200000; bootm 0x32000000
pini@debian-gta02:~$

18/05/2009

libgarmin dans Debian/unstable

Mon package libgarmin vient d'entrer dans Debian/unstable.

Prochaine étape activer le plugin Garmin dans le package navit.

23/03/2009

Wifi - Debian - Noyau 2.6.28

Avec le noyau 2.6.28 le wifi n'est plus activé par défaut. L'avantage c'est que la batterie s'en porte mieux. L'inconvénient c'est qu'il faut scripter un peu...

Activation: 

echo 1 > /sys/bus/platform/drivers/gta02-pm-wlan/gta02-pm-wlan.0/power_on
echo s3c2440-sdi > /sys/bus/platform/drivers/s3c2440-sdi/bind

Désactivation: 

echo 0 > /sys/bus/platform/drivers/gta02-pm-wlan/gta02-pm-wlan.0/power_on
echo s3c2440-sdi > /sys/bus/platform/drivers/s3c2440-sdi/unbind

Le device ethO n'est présent et visible qu'en mode activé.

09/03/2009

Flash de la puce GSM

Aujourd'hui c'est décidé, je me lance dans le flashage de la puce GSM du FR. J'en ai marre qu'on me dise que mon téléphone a un son pourri. Avec un peu chance il y aura un mieux !

Je commence donc à dépiler les infos :

Puis je vais chercher le firmware up-to-date. Il y a dans ce lien un répertoire moko11. Allons voir. Bon... Le firmware a l'air d'être le fichier calypso-moko11.m0. Mais qu'est-ce donc que ce flash-moko11_uSD-image.tar.gz ? Par curiosité je récupère cette tarball et je l'inspecte. Elle contient deux fichiers : 

$ tar tvzf flash-moko11_uSD-image.tar.gz 
-rw-r--r-- root/root 283115520 2009-02-28 20:53 flash-moko11-2.image
-rw-r--r-- jr/users        493 2009-02-28 20:56 README.txt

Et le README.txt nous dit : 

dd if=flash-moko11-2.image of=<your_uSD_device>; #this is NO partition
# for a transcend microSD reader USB dongle this is /dev/sdb on my system
# YMMV

insert uSD, we recommend you don't insert SIM, boot from uSD via U-Boot
wait until "green", usually takes some 6min

tested with NOR U-Boot 1.3.2-moko12 (May 9 2008 - 10:28:48) 
and with NAND U-Boot 1.3.2-dirty-moko12 (Aug 25 2008 - 00:18:23)

Please report any problems as well as U-Boot versions it doesn't boot with to
joerg@openmoko.org

Ce serait donc un kit de flashage prêt à l'emploi. Je décide de tester :

  1. Copie de l'image sur la carte uSD 512 Mo Transcend que j'ai en stock
  2. Arrêt du FR
  3. Insertion de la carte uSD dans le FR
  4. Retrait de la carte SIM
  5. Reboot sur la carte uSD par le menu NOR
  6. Scrutation de la console du FR en serrant les fesses...

Le FR commence par booter normalement, puis au bout d'un moment la console passe en fond bleu. C'est assez difficile à lire, mais on perçoit que le flashage effectif commence avec une barre de progression en ***.

Cela dure quelques minutes. Au premier tiers la progression est interrompue par des messages console. Aïe... En lisant bien on voit que ce sont des messages relatifs au bluetooth, et la barre de progression reprend plus loin. Ouf !

Quand c'est terminé, il y a une pause de 30 secondes environ, puis la console passe en fond vert avec affichage du logo Angström puis invite de login.

Il n'y a plus plus qu'à rebooter sur la Debian puis à tenter un coup de fil. Ça marche !

Quant à dire si le son s'est amélioré pour mes interlocuteurs, on verra ça après un rex de quelques jours.

update du lendemain
Aucune amélioration rapport au son :(

04/03/2009

Navit uploadé dans la file NEW de Debian

Une grosse étape vient d'être franchie avec l'upload de mon package Navit dans la file NEW de Debian. Il doit être encore être traité par ftp-master. D'expérience ça peut prendre quelques jours comme plusieurs semaines.

Si ça passe, Navit sera alors disponible officiellement dans Debian, dans l'archive experimental pour l'instant.

Nous viserons unstable dès que le package sera un peu plus stable (il reste en particulier des problèmes d'endianness à régler pour que cela marche correctement sur toutes les architectures et pas seulement sur les little-endian.

27/02/2009

Stabilité de Debian / FSO M5 - Mon record d'uptime

Un petit billet pour manifester ma satisfaction quand à la stabilité de la dernière mouture de Debian / FSO.

Jusqu'à présent je n'avais jamais réussi à atteindre 3 jours d'uptime avec mon FR. Sachant que le temps de veille n'est pas comptabilisé, ça correspond à 4 à 7 jours d'utilisation (pour mon usage).

Aujourd'hui mon FR s'est arrêté pour cause de batterie vide. Il avait atteint un uptime de 4 jours et 8 heures environ. J'avais regardé la date de boot hier justement : eh bien ça fait pile poil 10 jours d'utilisation, tout ça en étant bien stressé : compilations / tests / segfaults / sigbus de Navit.

Dommage que la batterie se décharge aussi vite...

17/02/2009

Navit en cours d'intégration dans Debian

Je me suis porté volontaire pour l'intégration de Navit dans Debian. J'ai créé mon compte sur alioth.debian.org et on m'a donné accès au dépôt git qui a supporté la première tentative de packaging officiel. Cette nuit j'ai remonté mes premières modifs. Le package compile sur mon PC. Mais il reste un maximum de travail, en particulier au niveau des copyrights.

Les prochaines versions du package qui atterriront sur mon dépôt debian seront issues de ces builds.

12/02/2009

Kernel 2.6.28

Le kernel 2.6.28 de MSO M5 vient d'atterrir dans les dépôts debian. La mise à jour n'est pas immédiate...

Tout d'abord, s'assurer que /dev/mmcblk0p1 est bien monté sur /boot. Si ce n'est pas le cas, l'ajouter au fichier /etc/fstab : 

/dev/mmcblk0p1  /boot   auto    defaults                                0 0

Puis : 

# mount -a

Ensuite, il faut supprimer à la main le lien /boot/uImage.bin qui pointe sur l'ancien kernel : 

#  ls -l /boot/uImage.bin 
lrwxrwxrwx 1 root root 35 déc 17 19:28 /boot/uImage.bin -> vmlinuz-2.6.24-20081103.git7172ec57
# rm /boot/uImage.bin

Enfin on peut mettre le kernel à jour : 

# apt-get update
# apt-get install linux-image-2.6.28-openmoko-gta02

Vérifier que le lien dans /boot est réapparu et pointe sur le bon kernel : 

# ls -l /boot/uImage.bin 
lrwxrwxrwx 1 root root 35 fév 12 01:28 /boot/uImage.bin -> vmlinuz-2.6.28-20090105.git69b2aa26

Reboot en serrant les fesses... Ça marche !

Tiens, et du coup le témoin de charge sur POWER remarche.

05/02/2009

\o/ Navit - J'ai trouvé ! \o/

Je vais enfin pouvoir faire mes nuits ;)

En réfléchissant un peu je me suis dit qu'il y avait une chance que ça se passe dans la configuration dynamique du noyau (/proc ou /sys). J'ai donc adapté en conséquence mes requêtes google sur le sujet, et je suis tombé sur la réponse que j'attendais : 

# on arm, enable kernel fixups on alignement errors:
echo 2 > /proc/cpu/alignment

En vérifiant sur Om2008.12 on trouve la valeur 3 (fixup+warn) : 

root@om-gta02:~# cat /proc/cpu/alignment 
User:           0
System:         0
Skipped:        0
Half:           0
Word:           0
Multi:          0
User faults:    3 (fixup+warn)

Mais je vais rester sur 2, histoire de ne pas encombrer les logs.

Mon mystérieux bug Navit - Ça se précise

Après de longues soirées de gdb sur Navit (pfiouuu ! ça fait longtemps que je n'ai pas fait de C), je crois bien avoir trouvé - en partie - de quoi il retourne. C'est tout bêtement un problème d'alignement qui ne se manifeste que sur Debian :/

Les fichiers des maps MG sont mappés en mémoire. Les données sont ensuite accédées directement par des pointeurs sur les structures ad'hoc. Et les fichiers sont faits de telle façon que les données ne sont pas alignées du tout. Du coup, au moment de lire un unsigned short (par exemple) sur une adresse impaire, ça plante.

La curiosité du jour c'est que c'est spécifique à Debian. Le même binaire exécuté sur Om2008.12 se comporte parfaitement bien.

Cas test

J'ai gratté vite-fait un petit cas test représentatif de la chose : 

$ cat test.c 
#include <stdio.h>
#include <stdlib.h>

struct test {
  unsigned short s4;
  char s1;
};

unsigned char buffer[6] = { 0 };

void test_align(unsigned char ** p) {
  unsigned short copy;
  struct test *current = (struct test *)(*p);
  printf("*p = %p => 0x%02x 0x%02x 0x%02x\n", *p, **p, *(*p+1), *(*p+2));
  copy = current->s4;
  printf("s4 = %d %d %d\n", **p+*(*p+1)*256, current->s4, copy);
  (*p) += 3;
}


int main(int argc, char * argv[]) {
  printf("unsigned short = %d\n", sizeof(unsigned short));
  printf("char = %d\n", sizeof(char));
  printf("struct test = %d\n", sizeof(struct test));
  printf("buffer = %p\n", buffer);
  buffer[0] = buffer[3] = 1;
  buffer[1] = buffer[4] = 2;
  buffer[2] = buffer[5] = 3;

  unsigned char *p = buffer;
  test_align(&p);
  test_align(&p);

  exit(0);
}

Ça se compile bêtement par : 

$ gcc -o test test.c

Exécution sous Debian

$ ./test
unsigned short = 2
char = 1
struct test = 4
buffer = 0x107cd
*p = 0x107cd => 0x01 0x02 0x03
s4 = 513 256 256
*p = 0x107d0 => 0x01 0x02 0x03
s4 = 513 513 513

En théorie (enfin... pour que Navit fonctionne correctement) les lignes "s4" devraient toutes deux être de la forme 513 513 513. Là on constate que quand *p est impair, c'est raté, la lecture se calant apparement sur l'octet pair précédent.

Exécution sous Om2008.12 installé en chroot sous Debian

$ schroot -c OM ./test
I : [chroot Om2008.12] Exécution de la commande : « ./test »
unsigned short = 2
char = 1
struct test = 4
buffer = 0x107cd
*p = 0x107cd => 0x01 0x02 0x03
s4 = 513 256 256
*p = 0x107d0 => 0x01 0x02 0x03
s4 = 513 513 513

=> même problème

Sous Om2008.12 natif

root@om-gta02:~# mount /dev/mmcblk0p2 /mnt
root@om-gta02:~# cd /mnt/home/pini/debian/navit-debug/
root@om-gta02:/mnt/home/pini/debian/navit-debug# ./test
unsigned short = 2
char = 1
struct test = 4
buffer = 0x107cd
*p = 0x107cd => 0x01 0x02 0x03
s4 = 513 513 513
*p = 0x107d0 => 0x01 0x02 0x03
s4 = 513 513 513

Ça marche ! Et c'est bien le même binaire que sous Debian. Je n'ai rien recompilé sous Om2008.12.

Sous Debian, booté avec le noyau d'Om2008.12

Ça ne marche pas.

Sous Om2008.12 installé en chroot de Debian bootée avec le kernel d'Om2008.12

Ça ne marche pas non plus.

Alors quoi ?

  • Ce n'est pas une question de libc6, sinon ça devrait marcher en chroot Om2008.12.
  • Ce n'est pas une question de noyau, sinon ça fonctionnerait en Debian + Kernel Om2008.12
  • Ce n'est pas les deux combinés, sinon ça fonctionnerait en Debian + Kernel 0m2008.12 + chroot sous Om2008.12

Si un bienveillant lecteur a une idée...!

Update
\o/ J'ai trouvé ! \o/

03/02/2009

FSO Milestone 5

Installation ce jour de FSO Milestone 5 par apt-get dist-upgrade.

Premiers constats à chaud :

  • Rien de révolutionnaire.
  • La mise en veille est beaucoup plus rapide.
  • La gestion des DTMF est plus simple : les touches sont prises en compte au fur et à mesure de la frappe; plus besoin de valider à chaque fois.
  • Le témoin de charge sur POWER ne marche plus (mais ça charge quand même).
  • J'ai dû modifier sensiblement IdleBlocker en utilisant une connexion à org.freesmartphone.odeviced au lieu de org.freesmartphone.frameworkd qui répond maintenant un truc genre permission denied. Pour le reste du programme ça marche pareil.

17/01/2009

Réinstallation complète

Je suis enquiquiné depuis 10 jours par un plantage de navit que je n'arrive pas à reproduire ailleurs. Je suis même allé jusqu'à refaire une installation sous qemu. Rien !

C'est donc décidé : je réinstalle complètement ma debian. On verra bien si c'est la faute à un inode pas étanche de ma carte microSD...


Update (tard, dans la nuit)
C'était pas ça. Le gros vilain bug est toujours là. Dégouté :(

Update-1
Après 24h d'utilisation je constate que le recamping bug est toujours présent.

05/01/2009

Marco Polo Grosser Reiseplaner

J'ai reçu hier l'un de mes cadeaux de Noël : une carte d'Europe en DVD compatible avec Navit.

L'installation est relativement simple, mais assez longue (2,5 Go à transférer sur le FR).

Le seul prérequis est l'outil unshield heureusement disponible sous debian : 

$ sudo apt-get install unshield

Je n'ai pas encore testé en navigation, mais les quelques coups d'oeil jetés sur les cartes me permettent de dire que la qualité est largement meilleure - incomparable - que celle d'OSM (pour la france du moins). Je ne regrette pas mes 25,90€ !

Localisation fr_FR sous Debian

$ sudo apt-get install locales
$ sudo dpkg-reconfigure -plow locales

Choisir fr_FR.utf8. Et ajouter : 

export LANG=fr_FR.utf8

dans ~/.profile

Récupérée de « http://openmoko-fr.org/wiki/index.php/Utilisateur:Pini »