2009-11-13T22:01:43Z

Pini : /* 13/11/2009 */ Trois semaines d'uptime

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 : [[User:Pini/2008|2008]].

=Journal=
==13/11/2009==
===Trois semaines d'uptime===
Oui, trois semaines. Enfin, presque : 20 jours.

Sans relancer une seule fois frameworkd ni même zhone. C'est dire que la stabilité de la Debian commence à être satisfaisante sur le FR.

J'ai finalement dû rebooter car - seul bemol - le système devient imperceptiblement de plus en plus lent. Et au bout de 20 jours j'ai commencé à perdre des appels car je n'avais pas le temps de décrocher avant que la messagerie vocale ne se déclenche.

Le plus dur dans tout ça c'est de bien penser à recharger le FR une fois par jour :/

==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 à <tt>xserver-xorg-video-glamo</tt>, 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 [http://lists.alioth.debian.org/pipermail/pkg-fso-maint/2009-September/001893.html deux] [http://lists.alioth.debian.org/pipermail/pkg-fso-maint/2009-October/002072.html mails] de la liste pkg-fso-maint. Soit :
$ sudo apt-get install fso-abyss fso-usaged
Dans <tt>/etc/frameworkd.conf</tt> :
* Ajouter :
[fsousage]
disable = 0
lowlevel_type = openmoko

[fsousage.controller]
[fsousage.lowlevel_openmoko]
* Désactiver l'ancien <tt>ousaged</tt> :
[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 <tt>xserver-xorg-video-glamo</tt> est disponible en remplacement de <tt>Xglamo</tt>. 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 à <tt>fbdev</tt>. Si c'est le cas ce n'est pas flagrant pour un usage standard.

Voir les instructions d'installation sur la page [http://wiki.debian.org/DebianOnFreeRunner#Graphics.28SmediaGlamo3362.29 DebianOnTheFreeRunner].
===uboot-envtools===
Fin 2008 j'avais pondu un [[Utilisateur:Pini/2008#Configurer_l.27environnement_u-boot|script]] pour modifier l'environnement u-boot du FR. Quelque temps après j'ai eu vent du package '''<tt>uboot-envtools</tt>''' 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 <tt>fw_printenv</tt> et <tt>fw_setenv</tt>, à 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''' [http://packages.qa.debian.org/libg/libgarmin.html 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 :
* la page [http://wiki.openmoko.org/wiki/GSM/Flashing GSM/Flashing] sur le wiki officiel
* le récent [http://openmoko-fr.org/forum/viewtopic.php?pid=4477 fil de discussion] sur openmoko-fr

Puis je vais chercher le [http://people.openmoko.org/joerg/calypso_moko_FW/ 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 :
# Copie de l'image sur la carte uSD 512 Mo Transcend que j'ai en stock
# Arrêt du FR
# Insertion de la carte uSD dans le FR
# Retrait de la carte SIM
# Reboot sur la carte uSD par le menu NOR
# 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 [http://ftp-master.debian.org/new.html 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 [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451561#62 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/ [[Utilisateur:Pini#Mon_myst.C3.A9rieux_bug_Navit_-_.C3.87a_se_pr.C3.A9cise|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 (<tt>/proc</tt> ou <tt>/sys</tt>). J'ai donc adapté en conséquence mes requêtes google sur le sujet, et je suis tombé sur [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501231#17 la réponse que j'attendais] :
<pre># on arm, enable kernel fixups on alignement errors:
echo 2 > /proc/cpu/alignment</pre>
En vérifiant sur Om2008.12 on trouve la valeur 3 (fixup+warn) :
<pre>root@om-gta02:~# cat /proc/cpu/alignment
User: 0
System: 0
Skipped: 0
Half: 0
Word: 0
Multi: 0
User faults: 3 (fixup+warn)</pre>
Mais je vais rester sur 2, histoire de ne pas encombrer les logs.

===Mon mystérieux [[Utilisateur:Pini#R.C3.A9installation_compl.C3.A8te|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 <tt>unsigned short</tt> (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 :
<pre>$ 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);
}</pre>
Ça se compile bêtement par :
<pre>$ gcc -o test test.c</pre>
====Exécution sous Debian====
<pre>$ ./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</pre>
En théorie (enfin... pour que Navit fonctionne correctement) les lignes "s4" devraient toutes deux être de la forme <tt>513 513 513</tt>. Là on constate que quand <tt>*p</tt> 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====
<pre>$ 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</pre>
=> même problème
====Sous Om2008.12 natif====
<pre>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</pre>
Ç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/ [[Utilisateur:Pini#.5Co.2F_Navit_-_J.27ai_trouv.C3.A9_.21_.5Co.2F|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 [http://openmoko-fr.org/wiki/index.php/FSO#Ma_premi.C3.A8re_application_-_Activation_.2F_d.C3.A9sactivation_de_l.27.C3.A9conomiseur_d.27.C3.A9cran_via_une_applet 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 [http://trac.navit-project.org/ticket/272 plantage de navit] que je n'arrive pas à reproduire ailleurs. Je suis même allé jusqu'à refaire une [http://openmoko-fr.org/forum/viewtopic.php?pid=3830#p3830 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 [[Utilisateur:Pini#Contournement_du_recamping_bug|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 [http://www.amazon.de/o/ASIN/3829731434/navit-21 carte d'Europe en DVD] [http://wiki.navit-project.org/index.php/European_maps#Marco_Polo_Grosser_Reiseplaner 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'''