Zaurus http://artisan.karma-lab.net/taxonomy/term/47/atom/feed 2008-10-08T15:31:48+02:00 Bloc-note 'ZaurusFr' http://artisan.karma-lab.net/node/1301 2007-12-15T16:50:11+01:00 2007-12-15T17:46:37+01:00 Ulhume Trucs en vrac sur la distribution Zaurus Francisée initiée par Dab.

]]> Trucs en vrac sur la distribution Zaurus Francisée initiée par Dab.

Création de l'environnement

Le plus simple est de créer avec debootstrap un environnement chrooté spécifique. De créer un utilisateur une fois dans le chroot (ex. gaston) et de faire le checkout suivant :

root#apt-get install subversion
root#useradd gaston
root#visudo
Editer ici le sudo pour ajouter gaston avec une ligne du genre
gaston ALL=(ALL) NOPASSWD:ALL
et faire CTRL-X Y pour sortir
 
root#mkdir -p /home/gaston/tmp
root#chown gaston:gaston /home/gaston -Rc
root#su - gaston
gaston$svn co http://artisan.karma-lab.net/dev/zaurusfr/trunk/zaurusfr/construct
gaston$cd construct
gaston$./oe build
Faire quelque prière ici pour que tout fonctionne
gaston$ 

Lorsque le build est terminé, une archive contenant tout ce qu'il faut pour flasher le zaurus sur trouve dans le dossier /home/rober/construct/stuff/zaurusfr/tmp/deploy/glibc/images/akita sous le nom poétique de Angstrom-zaurusfr-gpe-image-glibc-ipk-2007.9-test-YYYMMDD-akita-installkit.tgz. Il suffit de décompresser cette archive à la racine d'une carte SD, et d'installer la nouvelle ROM.

Faire un patch kernel

Si si, c'est toujours utile Smiling

gaston$cd stuff/zaurusfr/tmp/work/akita-angstrom-linux-gnueabi/linux-rp-2.6.23-r100
gaston$# on fait une copie des sources du kernel
gaston$rsync -a linux-2.6.23 linux-2.6.23-new
# on modifie le kernel sur la copie et on fait un patch que l'on stoque directement au bon endroit
gaston$patch -Naur linux-2.6.23 linux-2.6.23-new > ../../../../myoe/packages/linux/linux-rp-2.6.23/mon-patch.patch
gaston$ 

On modifie ensuite le fichier ../../../../myoe/packages/linux/linux-rp_2.6.23.bb en rajoutant dans SRC_URI une ligne du style :

file://mon-patch.patchpatch=1 \

Ensuite, soit on utilise oe pour faire un clean de linux-rp puis un build. Soit on veut tester et on va alors passer bitbake en mode interactif :

gaston$cd /home/gaston/construct/stuff/zaurusfr
gaston$. oe.env
gaston$bitbake -i
gaston$clean linux-rp
gaston$fetch linux-rp
gaston$unpack linux-rp
gaston$patch linux-rp
gaston$build linux-rp
gaston$ 

USB mode host/slave

Pour l'instant, l'Angstrom ne détecte pas correctement le changement de câble. Il faut donc charger le module correspondant au mode "host" à la main :

#!/bin/sh
# Stop possible USB networking to release g_ether lock
ifconfig usb0 down 2>/dev/null
# Remove USB client modules
rmmod g_file_storage g_ether pxa27x_udc 2>/dev/null
# Load USB master module
modprobe ohci-hcd

Soucis d'installation sur la partition /home

Lors de l'utilisation de la syntaxe ipkg install -d home abiword, ipkg installe bien abiword sur la seconde partition mais l'utilitaire ipk-link n'est pas appelé pour créer les liens avec le système racine. Et pour cause, il n'est pas présent... Donc en attendant que ce soit inclus par défaut, voici le source de l'utilitaire à utiliser après ipkg, sous la forme ipk-link add abiword :

#!/bin/sh
COMMAND=$1
PACKAGE=$2
setdest () {
        for i in `grep dest /etc/ipkg.conf | cut -d ' ' -f 3`; do
                if [ -f $i/usr/lib/ipkg/info/$PACKAGE.list ]; then
                        DEST=$i
                fi
        done
        if [ "x$DEST" = "x" ]; then
                echo "Can not locate $PACKAGE."
                echo "Check /etc/ipkg.conf for correct dest listings";
                echo "Check name of requested package: $PACKAGE"
                exit 1
        fi
}
addlinks () {
        setdest;
        cat $DEST/usr/lib/ipkg/info/$PACKAGE.list | while read LINE; do
                SRC=$LINE
                DST=`echo $SRC | sed "s|$DEST||"`
                DSTNAME=`basename $DST`
                DSTDIR=`echo $DST | sed "s|$DSTNAME\$||"`
                test -f "$SRC"
                if [ $? = 0 ]; then
                        test -e "$DST"
                        if [ $? = 1 ]; then
                                mkdir -p $DSTDIR
                                ln -sf $SRC $DST
                        else
                                echo "Not linking $SRC to $DST"
                                echo "$DST Already exists"
                        fi
                else
                        test -d "$SRC"
                        if [ $? = 0 ]; then
                                test -e $DST
                                if [ $? = 1 ]; then
                                        mkdir -p $DST
                                else
                                        echo "directory already exists"
                                fi
                        else
                                echo "Source directory $SRC does not exist"
                        fi
                fi
        done
}
removelinks () {
        setdest;
        cat $DEST/usr/lib/ipkg/info/$PACKAGE.list | while read LINE; do
                SRC=$LINE
                DST=`echo $LINE | sed "s|$DEST||"`
                DSTNAME=`basename $DST`
                DSTDIR=`echo $DST | sed "s|$DSTNAME\$||"`
                test -f $DST
                if [ $? = 0 ]; then
                        rm -f $DST
                        test -d $DSTDIR && rmdir $DSTDIR 2>/dev/null
                else
                        test -d $DST
                        if [ $? = 0 ]; then
                                rmdir $DST
                        else
                                echo "$DST does not exist"
                        fi
                fi
        done
}
mountdest () {
        test -d $PACKAGE
        if [ $? = 1 ]; then
                echo "Mount point does not exist"
                exit 1
        fi
        for i in $PACKAGE/usr/lib/ipkg/info/*.list; do
                $0 add `basename $i .list`
        done
}
umountdest () {
        test -d $PACKAGE
        if [ $? = 1 ]; then
                echo "Mount point does not exist"
                exit 1
        fi
        for i in $PACKAGE/usr/lib/ipkg/info/*.list; do
                $0 remove `basename $i .list`
        done
}
case "$COMMAND" in
  add)
        addlinks
  ;;
  remove)
        removelinks
  ;;
  mount)
        mountdest
  ;;
  umount)
        umountdest
  ;;
  *)
        echo "Usage: $0 <cmd> <target>"
        echo "       Commands: add, remove, mount, umount"
        echo "       Targets: <package>, <mount point>"
        echo "Example:  $0 add kismet-server"
        echo "Example:  $0 remove kismet-server"
        echo "Example:  $0 mount /mnt/usb"
        echo "Example:  $0 umount /mnt/usb"
        exit 1
        ;;
esac
exit 0
/usr/bin/ipkg-link

Et pour installer tous les paquets d'un coup :

#! /bin/sh
cd /
for package in $(cat /home/packages/usr/lib/ipkg/status | grep Package | cut -d" " -f2) ; do
  ./ipk-link add $package
done
/usr/bin/ipkg-link-all

]]> Installer une nouvelle ROM sur le Zaurus http://artisan.karma-lab.net/node/1098 2007-11-06T18:07:53+01:00 2008-10-01T14:33:19+02:00 Ulhume Les installations de nouvelles ROM sont chose courante sur le Zaurus et pourtant les processus sont loin d'être simples à mettre en œuvre pour quelqu'un qui ne connaît pas encore bien cette machine. J'ai essayé dans ce tutorial de regrouper l'ensemble des modes d'emploi pour la majorité des ROM existantes sur le Zaurus.

]]> Les installations de nouvelles ROM sont chose courante sur le Zaurus et pourtant les processus sont loin d'être simples à mettre en œuvre pour quelqu'un qui ne connaît pas encore bien cette machine. J'ai essayé dans ce tutorial de regrouper l'ensemble des modes d'emploi pour la majorité des ROM existantes sur le Zaurus.

ROM ? kézako ?

Tout d'abord, il est important de comprendre un peu comment se structure la ROM du Zaurus. En réalité, ROM ne veut pas dire grand chose, il s'agit de mémoire Flash (appelé aussi mémoire NAND). Sur un SL-C1000, il y a 128mo de mémoire flash à ne pas confondre avec les 64mo de mémoire vive. Sur tous les Zaurus, hors la série des SL-C3100/3200, la mémoire Flash est utilisée comme un disque dur. D'ailleurs, pour les SL-C3100/3200, il y a très peu de mémoire flash car il y a ... un disque dur. Pour l'instant je n'ai pas une vue bien précise de ce qui se trouve dans cette fameuse Flash. Plutôt que d'écrire des bêtises, je vais donc aborder cela d'un point de vue fonctionnel.

Nous avons une zone contenant le bootoader (le bout de logiciel qui démarre le Zaurus) ainsi que le menu de maintenance, c'est celui qui s'affiche avec un Zaurus d'origine lorsque vous pressez la touche OK ou ON en démarrant. Il permet la mise à jour du linux et l'installation d'une bonne partie des ROM alternatives (cacko, pdaXrom avant la béta 4, etc.).

Ensuite nous avons le menu de Diagnostic. C'est celui qui s'affiche en pressant D et M avant de brancher le Zaurus. Ce menu permet de vider toute la mémoire flash (sauf les 14mo dont nous parlons ici), de recharger une copie de la flash à partir d'une carte SD ou CF, faire une copie de la flash vers une carte CF ou SD, et plein d'autre chose que vous pouvez expérimenter à vos risques et périls...

Puis nous avons une copie de sauvegarde du menu diagnostic. Elle a toute son importance quant le Zaurus ne boot plus car elle, elle fonctionne toujours. Elle s'active en pressant Fn D et M avant de brancher le Zaurus.

Quelles ROM existent ?

Pour faire simple, la réponse est... beaucoup mais il est possible de la classifier un peu pour pouvoir s'y retrouver.

Tout d'abord les ROM basées sur Qt/Qtopia et celles sur X11. Pour un béotien, la grosse différence entre ces deux modes d'affichage graphique, est que X11 permet d'utiliser sur le Zaurus virtuellement toutes les applications écrites pour les unix (y compris FireFox, AbiWord, etc) et Qt implique d'utiliser des applications spécifiquement conçues pour lui. Qt est censé être plus rapide que X11 en affichage et est souvent préféré pour l'utilisation d'un Zaurus en mode PDA. Il existe cependant un "pont", un logiciel permettant d'émuler un serveur X11 sous Qt.

L'autre différence entre les ROM se situe au niveau du kernel. La ROM d'origine de SHARP utilise un kernel 2.4 et la société a écrit un certain nombre de pilotes spécifiques pour le Zaurus qui n'existent pas dans le monde libre (ex. pilotes rapide pour les cartes SD). Une distribution basée sur un kernel 2.4 peut donc utiliser ces pilotes tandis que les kernels 2.6 ne le peuvent plus, ce sont des distributions totalement dé-corrélées de ce qu'avait fabriqué SHARP.

ROM SHARP

C'est le point de départ, la ROM d'origine rêvée pour ceux qui veulent bosser leur japonnais, un enfer pour les autres qui ne comprennent rien au moindre menu. Cette ROM est basée sur un kernel 2.4 et sur un affichage Qt. Tous les pilotes sont écrits par les développeurs de SHARP et sont plutôt bien fait. C'est particulièrement vrai pour le pilote du lecteur de carte SD qui est 4 fois plus rapide que son homologue libre. La raison en est que le développeur qui a créé le pilote libre n'utilise qu'un bit sur 4 pour accéder au média.

J'en connais peu qui utilisent cette ROM, le but est généralement d'en changer le plus vite possible pour commencer à utiliser le Zaurus. Il est cependant parfois utile de l'utiliser pour "remettre à zéro" le Zaurus et ainsi repartir sur la version d'origine.

L'installation de cette ROM passe par la procédure de "restauration de la NAND" (voir plus bas).

Trisoft

C'est ici le distributeur Allemand de feu Zaurus qui propose ce remplacement de la ROM d'origine Japonaise par une version en Anglais en y ajoutant quelques logiciels (agenda, organizer, etc...). Ces ajouts exclus, cette ROM est strictement la même que celle d'origine.

L'installation de cette ROM passe par la procédure de "restauration de la NAND" (voir plus bas).

cacko

La ROM cacko est un petit bijou. Comme la TriSoft, elle est basée sur la version originale de Sharp (Kernel 2.4/Qt) mais s'en éloigne par une meilleur ergonomie, et une foule d'amélioration et d'applications bonus (netfront, opéra, etc.). En plus, en cherchant bien, il existe à travers le net un nombre important de paquet provenant de divers contributeurs pour cette distribution quasi-mythique.

La fonction de mise en veille marche parfaitement sous la cacko, comme avec la trisoft et utilisant le pilote SD de SHARP, ce média est à plein capacité. C'est une distribution que je conseil à tous ceux qui débute avec un Zaurus et qui cherche plus un PDA qu'un micro-laptop ou encore ceux qui veulent quelque chose de simplement fonctionnel où tout marche sans se poser de question. L'inconvénient de la cacko, comme de la Trisoft d'ailleurs, est que les logiciels inclus commencent à vieillir un peu.

La cacko s'installe simplement par la procédure de mise à jour "classique" (voir plus loin).

pdaXrom (jusqu'à la béta 3 incluse) et pdaXii13

Il s'agit là d'une ROM bien différente des précédentes car elle n'est plus basée sur Qt mais sur un petit serveur X11 transformant le Zaurus un véritable micro-laptop. En revanche cette distribution utilise un kernel 2.4 et bénéficie donc des pilotes SHARP. pdaXrom est passé en kernel 2.6 à partir de sa beta 4 mais la beta 3 garde ses aficionados qui ont décidé de créer leur propre distribution à partir de celle-ci, la pdaXii13. Il s'agit essentiellement d'une version debuggée de la beta 3, avec le même kernel mais utilisant le pilote SD libre, ce qui monte la capacité des cartes à plus de 2GO au détriment de la vitesse. Originellement conçue pour le SL-C3100 (Zaurus avec disque dur), cette distribution a été portée avec plus ou moins de succès sur le SL-C1000 (akita). Personnellement j'ai eu "quelques" soucis avec comme une mise en veille qui ne fonctionne pas...

La pdaXrom beta 3 comme la pdaXii13 s'installent simplement par la procédure de mise à jour "classique" (voir plus loin).

pdaXrom béta 4 et plus

Cette ROM est la même que la précédente avec beaucoup d'améliorations liées à son passage au kernel 2.6. En contrepartie, cette mise à niveau la rend bien sur totalement incompatible avec les pilotes SHARP. Certains la trouvent moins stable que la béta 3 mais je la préfère pour sa robustesse en terme de gestion d'énergie. Cette mouture est globalement plus réactive que les distributions basées sur une 2.4, la raison en étant une meilleur gestion des processus (mode préemptif). A noter que certains outils wifi sont cassés en 2.6, il est par exemple devenu impossible avec ma Symbol d'énumérer les réseaux disponibles, un peu gênant.

La pdaXrom beta 4 et plus s'installe par la procédure de mise à jour "avancée" (voir plus loin).

Ångström

A l'origine il y avait OpenZaurus, une distribution issue du plus vase projet OpenEmbeded. Puis OpenZaurus est mort pour donner naissance à Ångström, une distribution générique à un grand nombre de plate-formes de poches, dont le Zaurus évidement. C'est une plate-forme très ambivalente fonctionnant sur un noyau linux 2.6. Elle existe en version X11/GPE (la version PDA de Gnome), Qt/OPIE (version pda de Kde) et même Enlightenment E17, le futuriste gestionnaire de fenêtre (Ceci dit, il existe aussi des paquets E17 sous pdaXrom). D'un point de vue fonctionnel, cette distribution est très proche de pdaXrom en se voulant plus professionnelle, et plus proche des dernières évolutions. La contrepartie est qu'elle est constamment en béta et souffre de bugs assez gênant, notamment dans les gestions des périphériques USB (les mode câble host n'est pas détecté), la gestion du plein écran impossible (dur pour les vidéos dans le métro), et une mise en veille parfois mortelle... Intéressante, pas sèche mais un avenir certain. A surveiller.

Ångström s'installe par la procédure de mise à jour "avancée" (voir plus loin).

Debian pour Zaurus

Non testé

Gentoo pour Zaurus

Non testé. Le projet ne semble pas très actif.

OpenBSD pour Zaurus

Non testé. Ne fonctionne que sur les modèles à disque dur.

Pokylinux

Non testé. Il s'agit là d'une autre distribution orientée PDA et basée sur Ångström. Un test peut être consulté ici.

OpenMoko

Non testé. Encore une distribution basée sur Ångström originellement crée en tant qu'OS libre pour les SmartPhones.

Installation de la nouvelle ROM

Les règles de base

Tout d'abord les règles d'OR pour que les mises à jour se passent le mieux possible :

Ne jamais, lors d'une mise à jour, avoir en même temps une carte SD et CF (mémoire ou pas). Faites un choix et tenez-y vous. Si vous utilisez une SD, enlever la CF pour tout le reste du processus, et vice versa.

Le media choisi (CF ou SD) doit être impérativement formaté en FAT16. Rien ne marchera sans cela. Vous pouvez formater une carte une fois pour toute et n'aurez pas à le faire à chaque fois mais il faut que ce soit ce formatage là et pas un autre (pas de FAT32 par exemple, ni NTFS).

Prenez plutôt une petite carte SD/CF de 256/512 mo car dans ces phases délicates de mise à jour, le Zaurus a quelques problèmes à comprendre les grosses cartes (ma Transcend SD 1Gb ne passe par exemple pas !).

Avant de commencer, sauvegardez vos données personnelles sur une carte, à l'abri. Les procédures de mise à jour qui suivent (notamment la restauration de la flash) détruisent TOUTES les données du Zaurus. Vous êtes prévenu...

Les combinaisons de touches sont un peu surprenantes mais la manière simple de les effectuer est simplement de poser le Zaurus sur une table, de presser les touches avec les doigts d'une main, ce qui maintient le Zaurus contre la table, et d'insérer le câble d'alimentation de l'autre main. C'est peut-être idiot comme conseil mais j'aurais aimé que l'on me le donne avant d'attraper des crampes Wink

Toutes les manipulations qui suivent se font batterie éjectée, alimentation externe débranchée, toutes les cartes éjectées (CF et SD). Vous ne remettrez la batterie que lorsque tout fonctionnera.

Backup de la mémoire NAND

Ce processus n'a en soit que l'intérêt de mettre une configuration à l'abri avant de faire une mise à jour un peu rodéo. Personnellement je n'ai jamais fait de sauvegarde autre que pour ce tutorial. J'utilise directement les backups existants pour remettre mon Zaurus à l'état d'origine. Je part du principe que toutes les règles de bases citées plus haut sont respectées : formatage en Fat16, batterie éjectée, alimentation externe débranchée, etc.

  1. Le Zaurus est éteint, batterie retirée, alimentation retirée et aucune carte n'est insérée (CF ou SD)
  2. Insérez la carte qui contiendra le backup dans votre Zaurus.
  3. Presser les touches Fn, D et M en même temps, et insérez la prise d'alimentation externe. Le menu de diagnostic doit apparaître. Vous pouvez relâcher les touches.
  4. Avec les flèches Haut et Bas, allez sur la page SERVICE(3/3)
  5. Avec les flèches Gauche et Droite allez dans le menu BACKUP RESTORE MENU. Pressez OK
  6. Descendez sur NAND Flash Backup, pressez OK.
  7. Le menu affiche Execute Backup? Pressez OK. Cela devrait afficher Backup... avec une barre de progression pouvant aller de 10 à 30 minutes.
  8. Une fois fini, le menu affiche OK. Vous pouvez débrancher l'alimentation. Remettez la batterie et pressez On pour redémarrer le Zaurus.

Restauration de la NAND

Revenir à la ROM d'origine du Zaurus peut avoir plusieurs raisons. Tout d'abord pour repasser d'un version >4 de pdaXrom à une version plus ancienne. Mais aussi s'il l'on décide finalement que la ROM d'origine nous convient mieux (du moins sa version traduite en anglais).

Une autre raison pouvant vous amener à restaurer une ROM d'origine est simplement que le Zaurus ne boot plus du tout. En effet, il est normalement toujours possible d'effectuer ce qui suit. J'utilise exprès la procédure d'urgence, c'est à dire la copie de sauvegarde du menu de maintenance qui est toujours sensé fonctionner.

Tout d'abord pour restaurer une image d'origine, il faut en posséder une. Des images sont disponibles sur le site de Trisoft à l'adresse http://www.trisoft.de/en_c1000howto.htm. Je vous conseille de télécharger celle qui correspond à votre Zaurus et de la garder précieusement dans un coin. C'est une archive Zip qui doit contenir un seul fichier SYSTC100.DBK.

  1. Le Zaurus est éteint, batterie retirée, alimentation retirée et aucune carte n'est insérée (CF ou SD)
  2. Copier sur la carte, à la racine, le fichier de backup qui doit se nommer SYSTC100.DBK
  3. Insérez la carte dans le Zaurus
  4. Presser les touches Fn, D et M en même temps, et insérez la prise d'alimentation externe. Le menu de diagnostic doit apparaître. Vous pouvez relâcher les touches.
  5. Avec les flèches Haut et Bas, allez sur la page SERVICE(3/3)
  6. Avec les flèches Gauche et Droite allez dans le menu BACKUP RESTORE MENU. Pressez OK
  7. Descendez sur NAND Flash Restore, pressez OK.
  8. Presser OK à la question Execute restore?
  9. Puis encore OK à la question Delete all flash data?
  10. Le menu affiche Restore...La restauration devrait s'effectuer avec une barre de progression verte en bas de l'écran.
  11. Une fois fini, le menu affiche OK. Vous pouvez débrancher l'alimentation. Remettez la batterie et pressez On pour redémarrer le Zaurus.

Mise à jour "classique"

Le Zaurus est donc à son état d'origine (voir chapitre précédent). Nous allons installer la rom ancienne génération pdaXrom béta 3 (La procédure pour OpenZaurus est à peu près la même). Il faut d'abord télécharger sur le site de pdaXrom le fichier kathrin-1.1.0beta3-akita.zip. Il contient trois fichiers : initrd.bin tools.tar updater.sh.

  1. Le Zaurus est éteint, batterie retirée, alimentation retirée et aucune carte n'est insérée (CF ou SD)
  2. Copier à la racine de la carte les fichiers initrd.bin tools.tar et updater.sh
  3. Insérez la carte dans le Zaurus
  4. Insérez la batterie (et la verrouiller) et insérez l'alimentation externe
  5. Pressez la touche OK et en la maintenant appuyée, pressez le bouton ON.
  6. Le menu de maintenance doit apparaître (en Japonais).
  7. Descendez avec les touches haut et bas sur la ligne n°4 et pressez OK
  8. Si vous avez inséré une carte CF, restez sur la ligne n°1, sinon, allez sur la ligne n°2. Pressez OK
  9. En japonais, le menu vous demande poliment si vous êtes sûr de ce que vous faites. Pressez la touche Y.
  10. Le processus de mise à jour démarre.
  11. L'installateur de pdaXrom vous propose son menu, sélectionnez Install a new ROM puis pressez OK.
  12. L'installateur commence à flasher la ROM.
  13. L'installateur vous demande s'il doit flasher la zone utilisateur, pressez OK
  14. Une fois son travail terminé, l'installateur vous re-propose son menu, descendez jusqu'à Reboot, pressez OK
  15. Si tout c'est bien passé, le Zaurus boot correctement et affiche au bout d'un temps l'invite de connexion pdaXrom 1.1.0r3 "Kathrin".
  16. Tapez root puis OK. Vous êtes connecté, une invite s'affiche #
  17. Pour démarrer le mode graphique tapez startx puis OK. La serveur graphique démarre, et vous demande de calibrer le stylet. C'est terminé.

Mise à jour "étendue" (pdaXrom beta 4 et plus)

Attention, ce qui suit ne fonctionne pas avec une carte Compacte Flash !!!
  1. Le Zaurus est éteint, batterie retirée, alimentation retirée et aucune carte n'est insérée (CF ou SD)
  2. Télécharger le fichier pdaXrom-1.1.0r121-Kathrin-u-boot-akita-current.zip (4/5mo) qui se trouve ici.
  3. Vider le contenu de votre carte SD et décompressez à sa racine le contenu de l'archive téléchargée : autoboot.sh emergenc.img u-boot.bin updater.pro updater.sh
  4. Insérez la carte SD dans votre Zaurus.
  5. Presser les touches C et D en même temps, et insérez la prise d'alimentation externe.
  6. Les leds verte et jaune vont s'allumer en même temps. Vous pouvez relâcher les touches. Les leds vont rester allumer pendant une vingtaine de secondes. Attention l'écran ne dis rien et c'est normal ! Si les deux leds ne s'éteignent jamais, vérifier que vous n'avez pas une CF de type WIFI (ou autre) dans le Zaurus en même temps que la SD. Si les deux Leds se mettent à clignoter c'est que quelque chose ne va pas avec votre carte, que vous n'avez pas formaté en FAT16 ou encore que vous avez laissé insérée une CF et une SD, il faut faire un choix Wink.
  7. Lorsque les Leds s'éteignent, débranchez l'alimentation. C'est terminé.

Le bootloader et le menu emergency sont installés. Notez qu'une fois ceci fait, l'installation d'une ROM d'ancienne génération est impossible car il n'y a plus de menu de maintenance. Vous devez donc passez par la restauration de la ROM d'origine. Ceci dit, si vous n'installez plus que des ROM nouvelle génération, l'installation que vous venez de faire n'est pas à recommencer à chaque fois. C'est fait une fois pour toute, du moins jusqu'à ce que u-boot change de version ou soit remplacé par autre chose...

Une chose importante à comprendre au sujet du menu emergency est qu'il s'agit d'un vrai linux. EN fait, lorsque vous passez en mode emergency (en pressant ON avant allumage du Zaurus), le bootloader (u-boot) va démarrer non pas sur le kernel standard, mais sur ce kernel emergency de secours. Une fois que celui-ci a démarré, il va regarder le lecteur SD (et seulement lui !!) s'il existe un fichier nommé autoboot.sh. Si ce fichier existe, il va être exécuté, sinon, le linux de maintenance donne la main à l'utilisateur pour saisir des commandes d'urgence. Il s'agit donc à la fois d'un système de mise à jour et d'un système de "démarrage sans échec" en cas de gros problème.

Maintenant que le bootloader est installé, il faut passer à l'installation de pdaXrom lui-même.

  1. Le Zaurus est éteint, batterie retirée, alimentation retirée et aucune carte n'est insérée (CF ou SD)
  2. Télécharger l'archive pdaXrom-1.1.0r121-Kathrin-akita-current.zip (45/50mo)
  3. Effacer tous les fichiers sur votre carte SD.
  4. Décompresser à la racine de la carte mémoire le contenu de l'archive : autoboot.sh kernel.img rootfs.img
  5. Insérez la carte dans votre Zaurus.
  6. Presser les touches OK et en même temps, insérez la prise d'alimentation externe.
  7. Lorsque quelque chose s'affiche à l'écran, vous pouvez relâcher la touche OK. Au bout d'un temps, le menu pdaXrom emergency system apparaît et s'arrête sur une question Proceed with pdaxrom installation or boot to emergency system.
  8. Tapez y puis OK
  9. L'installateur procéde au flashage de la nouvelle ROM
  10. L'installateur va rebooter le Zaurus.
  11. Si tout c'est bien passé, le Zaurus boot correctement et affiche au bout d'un temps l'invite de connection pdaXrom 1.1.0r121 "Kathrin".
  12. Tapez root puis OK. Vous êtes connecté, une invite s'affiche #
  13. Pour démarrer le mode graphique tapez startx puis OK. La serveur graphique démarre, et vous demande de calibrer le stylet. C'est terminé.
]]> Fabriquer sa rom pdaXrom http://artisan.karma-lab.net/node/1110 2006-12-06T23:16:41+01:00 2008-10-01T02:19:24+02:00 Ulhume Je voulais depuis un certain temps déjà construire ma propre ROM, basée sur la distribution pdaXrom. Pourquoi faire ? pour y inclure mes paquets préférés, ne pas avoir à tout reconfigurer à chaque installation, mais aussi être plus indépendant vis à vis des auteurs de la distribution et par exemple construire des ROM intermédiaires avant les sorties officielles. La procédure normale pour reconstruire une ROM est de booter sur l'iso de pdaXrom pour i86 et d'utiliser un outil, appelé builder. Le problème est que je n'ai aucune envie de booter sur un CD, de dédier une machine à cela, ni même perdre de la ressource et du temps à utiliser vmware. Ce tutorial est donc une manipulation du processus d'origine pour utiliser ces deux mêmes outils mais directement sous Mandriva...

]]> Je voulais depuis un certain temps déjà construire ma propre ROM, basée sur la distribution pdaXrom. Pourquoi faire ? pour y inclure mes paquets préférés, ne pas avoir à tout reconfigurer à chaque installation, mais aussi être plus indépendant vis à vis des auteurs de la distribution et par exemple construire des ROM intermédiaires avant les sorties officielles. La procédure normale pour reconstruire une ROM est de booter sur l'iso de pdaXrom pour i86 et d'utiliser un outil, appelé builder. Le problème est que je n'ai aucune envie de booter sur un CD, de dédier une machine à cela, ni même perdre de la ressource et du temps à utiliser vmware. Ce tutorial est donc une manipulation du processus d'origine pour utiliser ces deux mêmes outils mais directement sous Mandriva...

Création du mini-linux

La première phase consiste à extraire de l'image ISO de pdaX86, un l'environnement de compilation complet pour pdaXrom. L'idée est de créer dans un dossier, un mini-linux chrooté à partir du contenu de l'image ISO originale. Attention cependant, compiler une ROM prends beaucoup de place, et il faut prévoir au minimum 10Go à l'endroit que vous choisissez de travailler (/home dans mon cas).

mkdir ~/zaurus
cd  ~/zaurus

La première chose à faire est donc de télécharger la dernière version de pdaXrom.iso.

wget http://www.pdaxrom.org/download/1.1.0r121/pdaX86/pdaXrom.iso

Ceci fait, nous allons monter cette image iso. Elle contient un fichier nommé boot/rootfs.bin. C'est un fichier formatté en squashfs qu'il va falloir monter à son tour pour obtenir les fichiers de notre mini-linux.

mkdir tmp.iso
sudo mount pdaXrom.iso tmp.iso -o loop
mkdir tmp.rootfs
sudo mount -t squashfs tmp.iso/boot/rootfs.bin tmp.rootfs -o loop

Nos fichiers sont maintenant dans tmp.rootfs. Nous alors les transférer sur le disque dur physique pour créer le mini-linux. J'utilise sudo car certains fichiers contenus dans rootfs ne sont manipulables que par root.

mkdir pdaXrom
sudo rsync -av tmp.rootfs/* pdaXrom/*

Les fichiers ainsi copiés, il ne nous reste plus qu'à démonter nos images et à enlever les points de montage :

sudo umount tmp.rootfs
sudo umount tmp.iso
rm -rf tmp.rootfs tmp.iso

Nous allons avoir besoin d'internet dans notre chroot. Il faut donc configurer le fichier pdaXrom/etc/resolv.conf comme celui du linux hôte (ce fichier est responsable de la résolution des noms de domaine et son contenu pointe sur vos serveurs DNS) :

sudo cp /etc/resolv.conf pdaXrom/etc/resolv.conf

Il va maintenant falloir récupérer la dernière version du builder de pdaXrom. En effet, si pdaXrom.iso contient un pdaXrom pour i86, il ne contient pas pour autant l'outil capable de fabriquer pdaXrom. Cet outil c'est le builder et l'on peut simplement le récupérer via la commande svn (subversion) :

svn co https://mail.pdaXrom.org/svn/pdaXrom-builder/trunk
sudo mv trunk pdaXrom/root/builder

Notez le numéro de release subversion logiquement supérieur à 121 (dans mon cas, 165). En effet, depuis la béta 121 de pdaXrom, les numéros de version sont justement les numéros de release qui s'affiche ici. Cela nous indique donc qu'il a eu 44 modifications depuis la dernière béta. Si subversion ne vous plaît pas (ou ne marche pas), vous pouvez toujours vous rabattre sur un téléchargement d'une version tar.bz2 sur le site de pdaXrom.

Il est maintenant temps de lancer notre mini-linux. La commande utilisé est bien évidement chroot auquel nous passons en paramètre le dossier racine (pdaXrom) ainsi que le nom du shell à lancer (bash). Les options accolées à bash permettent d'ouvrir un shell interactif qui va avant de vous donner la main, exécuter le script pdaXrom/etc/profile. Ceci nous permet d'avoir les bonnes variables d'environnement. Le chroot est quant à lui lancé via la commande su -c pour que ce soit l'utilisateur root qui soit utilisé. En effet, pdaXrom a été ainsi développé que tout se passe en tant que root. Enfin, la commande su est lancée via la commande sudo pour vous éviter de vous logger en tant que root. Ouf ! Cela nous donnes :

sudo su -c "chroot pdaXrom /bin/bash --rcfile /etc/profile -i"

Correction de l'environnement

Normalement vous êtes maintenant dans pdaXrom. Il reste cependant quelques bidules à paufiner. Tout d'abord un bug (en tout cas sous mandriva) dans le builder. Très simple à régler, il s'agit de modifier ligne 46 le fichier ~/builder/configure pour remplacer f0 par f1. Ceci fait, il faut aussi générer un fichier manquant en lançant la commandes suivante :

gdk-pixbuf-query-loaders > /etc/gtk-2.0/gdk-pixbuf.loaders
# pour plus tard : pango-querymodules > /etc/pango/pango.modules

Construction de la tool-chain

Une tool-chain, c'est un ensemble d'utilitaires permettant de construire un linux à partir de rien. Cela comprends bien évidement gcc, mais aussi flex, bison, automake, etc... Bref, tout ce qu'il faut pour compiler du code binaire pour le Zaurus (processeur ARM). Le builder va faire cela pour nous très simplement. Il suffit tout d'abord de lui demande ce qu'il est capable de fabriquer :

cd ~/builder
./configure | grep xtools

Là, on découvre que pdaXrom ne se limite pas au Zaurus. Pour mieux décrypter cela il faut connaitre les races de Zaurus (en effet, chaque modèle de zaurus est désigné par une race de... chien Wink :

ModèleRace
SL-5000DCollie
SL-5600Poodle
SL-C700Corgi
SL-C750Shepherd
SL-C760Husky
SL-C860Boxer
SL-6000Tosa
SL-C3000Spitz
SL-C1000Akita
SL-C3100Borzoi
SL-C3200Terrier

Si vous ne trouvez pas votre modèle dans les configurations, tentez la plus proche. Dans mon cas, c'est akita, je vais donc rechercher les configuration pour cette machine :

./configure | grep akita
#   akita-kernel-2.6-rom
#   akita-kernel-2.6-rom_no_gui
#   akita-kernel-2.6-xtools
#   akita-kernel-2.6-initrd-rom
#   akita-kernel-2.6-initrd-xtools

Deux configurations nous intérèssent particulièrement : xtools (c'est la fameuse tool-chain) et rom (c'est pdaXrom installable). Nous allons donc demander à configure de nous créer une tool-chain pour akita :

./configure akita-kernel-2.6-xtools ~/myAkita http://mail.pdaXrom.org/src

Lorsque ./configure a terminé, il a crée un dossier ~/myAkita qui sera notre environnement de travail à partir de maintenant. Nous lui avons aussi spécifié une url pour trouver les sources des paquets à compiler, nous y reviendrons. Maintenant, nous pouvons aller dans notre nouvel environnement pour construire notre tool-chain :

cd ~/myAkita
make virtual-xchain_install

Au fur et à mesure de la progression, le builder va télécharger les sources de chacun des éléments à compiler (gcc, automake, etc...). Ces sources sont stockés dans ~/myAkita/src. Le problème est que parfois... souvent... le site de pdaXrom tombe en panne. Le téléchargement ne peut donc se faire. Pour régler cela, il suffit d'indiquer au builder de ne plus aller chercher les tarballs sur le site de pdaXrom mais sur l'URL d'origine. Pour se faire, il suffit de supprimer le fichier ~/myAkita/.clone et de relancer le make world.

Si cependant, même le site d'origine ne fonctionne pas, la solution ultime consiste simplement à copie le nom du fichier que lui builder tente de télécharger (par exemple, gcc-3.4.6.tar.bz2), de coller ce nom dans google qui doit logiquement vous renvoyer une page où trouver le paquet (par exemple http://gcc.fyxm.net/releases/gcc-3.4.6/gcc-3.4.6.tar.gz). Il suffit alors d'arrêter le builder (CTRL-C) et de taper :

cd src
wget http://gcc.fyxm.net/releases/gcc-3.4.6/gcc-3.4.6.tar.gz
cd ..
make virtual-xchain_install

Et la compilation peut alors se poursuivre...

Au bout d'une bonne demi-heure (sur un Sempron 2400+ qui ne fait pas que cela), la tool-chain est compilée. Cela veut dire que dans votre dossier pdaXrom/opt a été créé un dossier cross qui contient toute la tool-chain de compilation pour le Zaurus. Pour éviter d'avoir à refaire cela, nous pouvons demander à créer une archive de cette toolchain :

make archive-toolchain

Cela ne va rien enlever de ce qui a été fait mais juste faire un fichier .tar.bz2 à la racine du compte (en ~ donc).

ls ~
# armv5tel-cacko-linux-3.4.6-2.16-2.2.5-softfloat-10.20_06.12.06.tar.bz2  builder  myAkita

Nous allons maintenant passer à la compilation de la ROM, mais avant, un peu de ménage s'impose. Cela va juste enlever les artefacts de compilations (dans le dossier build). Cela n'enlève ni les sources (qui ne seront donc plus à télécharger), ni la toolchain (en /opt/cross).

make clean

Compilation de la ROM

Le builder de pdaXrom est en réalité un projet développé par la société pengutronix. Il est basé sur des fichiers de configuration (comme vu plus haut) qui fonctionnent un peu comme ceux d'un kernel linux. Pour compiler la toolchain, nous avons chargé la configuration akita-kernel-2.6-xtools en spécifiant un dossier de travail ~/myAkita et une url pour les sources. Nous avons pour cela utilisé le ./configure du dosser builder (celui récupéré de SVN). Nous allons maintenant reproduire cette procédure pour changer de configuration mais cette fois à partir du dossier ~/myAkita. Comme tout a déjà été configuré, nous n'avons besoin de donner à ./configure que le nom de la configuration à exécuter. Tout d'abord, pour connaitre ce nom pour un modèle akita :

  cd ~/myAkita
  ./configure | grep akita | grep rom
#    akita-kernel-2.6-rom
#    akita-kernel-2.6-rom_no_gui
#    akita-kernel-2.6-initrd-rom

C'est la première configuration qui nous interesse

   ./configure akita-kernel-2.6-rom
#    Setup for SHARP ZAURUS SL-C1000/C3100 pdaXrom with kernel 2.6, target rom

Maintenant, nous pouvons faire une chose très interessante, à savoir personnaliser pdaXrom. Dans un premier temps, je vous conseil de ne pas le faire et de sauter cette étape. Sinon, il suffit, comme pour un kernel, de taper :

make menuconfig

Là, s'affiche un menu très conviviale en mode texte. La partie la plus intéressante se trouve dans Ipk packages qui nous permet de choisir les packages que l'on cherche à compiler et si oui ou non, ces paquets doivent être installés par défaut. Faites bien attention à ce que vous faites Wink Une fois terminé, il suffit de sortir en demandant à sauvegarder la configuration. Cette configuration est un fichier texte stocké en ~/myAkita/.config. Vous pouvez donc en faire une sauvegarde pour la prochaine fois.

Maintenant il est temps de compiler notre ROM et d'aller voir s'il fait beau dehors....

make world

Une fois que la compilation est terminée, l'ensemble des nouveaux paquets sont dans le dossier bootdisk/feed. Nous pouvons maintenant créer l'image de la ROM :

make image

Lorsque c'est fini, il suffit de prendre les fichiers autoboot.sh, kernel.img et rootfs.img qui se trouvent dans le dossier bootdisk et de les mettres, comme d'habitude sur une carte SD. De rebooter le Zaurus, maintenir OK pressé pour passer en mode emergency, répondre y et regarder avec angoisse les blocks défiller. Ensuite le système reboote, et miracle, ça marche !! Je me logue sans souci, lance X sans soucis, et je n'ai plus de bluetooth (le retirer était ma seule modification à la configuration) preuve que je suis bien sur MA rom Wink

Paramétrage du kernel

Paramétrer le kernel permet de comprendre quelques aspects interne du builder. Jusqu'à maintenant nous avons compiler world, mais là, nous n'allons compiler QUE le kernel en le modifiant pour nos besoins. Dans la mesure où tout est déjà compilé, le builder ne cherchera pas à reconstruire le reste. La première chose à faire est donc de modifier la configuration du kernel, pour cela, aller dans le dossier /root/myAkita/build/linux-2.6.16 et taper :

make ARCH=arm menuconfig

Là s'affiche le menu classique de configuration d'un kernel. Pour notre test, nous allons ajouter le logo linux au boot du Zaurus. Pour cela, aller dans la section Device Drivers, puis Graphics Support, Logo Configuration, et appuyez sur Espace. Une étoile devrait apparaître ainsi que des sous-options pré-activées. Maintenant faites exit plusieurs fois jusqu'à ce que vous soit proposé la sauvegarde, et dites yes. Dans la mesure où l'on cherche à compiler un kernel pour ARM et que menuconfig vient de compiler des choses pour i86, il est sage à ce stade de taper un make clean. Ensuite, il faut retourner dans ~/myAkita pour relancer une compilation, mais pas de world cette fois, du kernel seulement.

cd ~/myAkita
touch state/kernel.prepare
make kernel_compile

la commande touch est utilisé ici pour mettre à la date et à l'heure courante le fichier state/kernel.prepare. Cela indique au builder que toutes les étapes suivantes doivent être refaite. Ensuite la commande make demande au builder de construire (compile) spécifiquement le kernel. C'est un aspect très intéressant du builder car il permet d'effectuer sur un paquet spécifique une action spécifique sans toucher à ce qui a déjà été fait. La syntaxe générale est make PAQUET_ACTION. Pour avoir une liste des paquets utilisable, tapez simplement make help.

Une fois la construction terminée, il suffit de reprendre la procédure au make image et installer notre nouvelle ROM dans le Zaurus. Et normalement, au démarrage, le logo devrait apparaître.

Personnellement j'utilise ce type de paramétrage pour réduire la taille du noyau à ce qui m'intéresse réellement. PdaXRom a été conçu pour un maximum de gens, moi par exemple je n'utilise pas l'ipv6, je peux donc l'enlever et alléger ainsi le kernel (idem pour bluetooth, irda, etc...). Après chacun peut faire à peu près ce qu'il désire.

Monter la nouvelle ROM

Avant de l'installer sur le Zaurus, il peut être utile de monter la ROM "à la main" pour vérifier qu'elle contient bien ce que nous y avons voulu. Cette même technique peut être appliquée à une version non custom de la ROM. Pour cela nous allons simuler la mémoire flash du Zaurus sur notre PC et y monter notre fichier rootfs.img fraîchement créé dans le dossier bootdisk. Les manipulations qui suivent peuvent être réalisée au sein du chroot mis à part les modprobe qui ne fonctionneront qu'à l'extérieur.

Nous allons maintenant créer une "fausse" mémoire flash pour simuler celle du Zaurus et y transférer le fichier initrd.bin. Une sorte de flashage en quelque sorte Wink

Pour info, mtd veut dire Memory Technology Device. Le module mtdblock est là pour offrir une vision périphérique de type "block" à la mémoire flash (qui n'est ni block, ni caractère). On va donc commencer par fabriquer ce périphérique (version majeur 31, si quelqu'un sait pourquoi ?).

cd bootdisk
modprobe mtdblock  
mknod fausse_flash b 31 0

Maintenant nous allons allouer 64m de ram à notre périphérique, la valeur est donc 64*1024=65535

modprobe mtdram total_size=65535

Ensuite nous allons recopier notre fichier initrd.bin dans la fausse flash

dd if=rootfs.img of=fausse_flash bs=16 skip=1

Une fois la copie effectué, il suffit juste de monter notre nouveau disque en jffs version 2

mkdir rootfs
mount -t jffs2 fausse_flash rootfs

Et voilà, un petit ls pour vérifier que tout est bien là

ls rootfs

Bon, une fois les vérifications terminées, un peu de ménage s'impose

umount rootfs
rmmod jffs2
rm -rf rootfs
rmmod mtdram mtdblock
rm -rf fausse_flash

Conclusion

Pour l'instant notre nouvelle ROM n'est n'est ni plus rapide, ni plus belle, ni plus quoi que ce soit que l'originale. Elle présente cependant deux avantages. Déjà elle nous rends indépendant des releases de pdaXrom du kernel aux applications. De plus, le builder permet d'ajouter d'autres applications et donc d'étendre les paquets générés dans bootdisk/feed. Cela permet de ne plus ré-inventer la roue (comme jel'ai fait jusqu'à maintenant) et donc de bénéficier d'un outil qui semble à première vue aussi puissant que bitbake pour openZaurus. A creuser...

]]> Comprendre les paquets IPK http://artisan.karma-lab.net/node/60 2006-11-24T12:57:00+01:00 2008-10-01T14:05:46+02:00 Ulhume ipkg est le gestionnaire de package utilisé sur toutes les ROM que j'ai eues entre les mains. C'est une version light de dpkg à ce que j'en ai compris (je ne suis pas sous debian). techniquement ce sont des archives tgz qui contiennent elles-mêmes des archives tgz Smiling

]]> ipkg est le gestionnaire de package utilisé sur toutes les ROM que j'ai eues entre les mains. C'est une version light de dpkg à ce que j'en ai compris (je ne suis pas sous debian). techniquement ce sont des archives tgz qui contiennent elles-mêmes des archives tgz Smiling

Philosophie de base

Comme tous les systèmes d'installation de logiciels dans le monde *nix, ipkg est bas sur un système de paquets et de sources. Les paquets sont des fichiers archive qui contiennent les binaires à installer pour une application donnée. Généralement dans le nom d'un tel fichier est indiqué le nom de l'application, son numéro de version, l'architecture pour laquelle elle a été compilée et éventuellement une notion de sous-paquet.

Dans le monde Zaurus, les paquets sont des fichiers .ipk. Sans rentrer dans le détail de leur structure, ce sont basiquement des archives tar compressées. Si l'on prend l'exemple d'abiword, son paquet ipk sera par exemple nommé abiword-plugins_2.4.5_armv5tel.ipk. abiword pour le nom de l'application, 2.4.5 pour sa version et armv5tel pour indiquer que ce paquet est compilé pour un processeur ARM (et marchera donc difficilement sur un PC Smiling

C'est le paquet "principal" d'AbiWord, celui qui contient le coeur de l'application. Mais il peut y avoir aussi des sous-paquets qui dépendent du paquet principal, par exemple abiword-plugins-wikipedia_2.4.5_armv5tel.ipk qui est le plugin wikipedia d'AbiWord 2.4.5.

Le concept de dépendance a son importance car si les paquets sont bien faits (les miens le sont rarement Wink ils contiennent une série d'informations qui indique s'ils dépendent d'un autre paquet. Ainsi, lorsque vous installez un logiciel A qui dépend de B qui lui-même dépend de C, l'installateur va télécharger les 3 paquets et les installer. Avouez que c'est un peu plus pratique que les installations à la mode Windows... La question que l'on se pose alors c'est "où l'installateur va chercher B et C" ? C'est là qu'interviennent les sources (les feeds en langage Zaurus).

Une feed est un dossier local ou distant contennant de nombreux paquets .ipk et un fichier nommé Packages. Ce fichier est en quelque sorte le botin de la feed, il contient la liste de tous les paquets .ipkg disponibles dans ce répertoire. Ainsi, il est facile pour l'installateur, une fois que nous lui avons proprement indiqué le chemin d'une feed, de télécharger ce fichier en premier lieu pour lui servir d'index. C'est grâce à lui qu'il est capable de résourdre les dépendances manquantes. Vous pouvez vous convaincre de l'existence de ce fichier "caché" en allant directement le regarder dans une feed standard de pdaXrom b121.

Bien évidemment, un installateur digne de ce nom est capable de connaître un nombre illimité de sources différentes. Et s'il est très bien fait (ce qui n'est pas le cas d'ipkg Wink, il est capable de mettre à jour votre système avec les versions les plus récentes.

En bref, pour notre Zaurus, ipkg doit être configuré pour y ajouter toutes les sources/feed dont nous avons besoin. Ce qui n'est pas le cas lorsque pdaXrom vient d'être installé, malheureusement...

Paramétrage de ipkg

Même s'il existe un frontal graphique à ipkg, il est formateur de savoir l'utiliser en ligne de commande pour en comprendre le fonctionnement. Et la première chose qui va donc nous intéresser est de modifier la liste des feeds pour ajouter des sources nouvelles ou simplement réparer les sources éronnées.

Le fichier de configuration d'ipkg est /etc/ipkg.conf. Prenez votre éditeur de texte préféré (vi évidement Wink et regardez à quoi il ressemble. Vous verrez deux sections distinctes. Tout d'abord la liste des feeds. Une ligne par source au format suivant :

src NOM URL

Le prefix src indique que ce qui suit est une feed. NOM est n'importe quel nom de votre choix, tant qu'il est utilisé une et une seule fois, par exemple maSource. URL est l'adresse du dossier contenant les fichiers .ipk et le fameux fichier Packages (voir plus haut). Comme je le disais, la feed peut être locale, en ce cas l'URL est de la forme http://un.site.web/dossier/feed ou local, en écrivant file:///chemin/vers/ma/feed/locale. Ce qui nous donne les deux exemples suivants, le premier est la feed standard de pdaXrom pour la béta 121 modèle CX00, le second une feed locale sur ma carte compact flash :

src pdaXrom http://www.pdaxrom.org/download/1.1.0r121/Zaurus-Cxx00/feed
src maFeed  file:///mnt/cf/maFeed

Une fois que les feeds sont configurées, nous pouvons regarder la deuxième section d'ipkg.conf concernant les destinations. En effet, la commande ipkg installe par défaut les applications à la racine. Mais pour des raisons évidentes de place, il est parfois intéressant de stoquer les grosses applications (kdepimpe, firefox, etc..) sur une carte SD par exemple. Le format de chaque ligne est le suivant :

dest NOM CHEMIN

Le prefix dest indique que ce qui suit est une destination d'installation. NOM est n'importe quel nom de votre choix, comme pour les feeds. Attention cependant, autant prendre un nom facile à taper car vous l'utiliserez à chaque fois que vous voulez installer quelque chose sur cette destination. CHEMIN est quant à lui le chemin local (interne au Zaurus) où ipkg doit installer le binaire. Cela peut être un autre dossier de la racine (ex. /opt pour les possesseurs de disque dur), une carte SD (/mnt/SD/mesInstallations), etc...

Une fois les modifications effectuées, vous pouvez sauver le fichier ipkg.conf et mettre à jour la base des paquets par la commande :

ipkg update

L'utilitaire va alors télécharger chaque fichier Packages de chaque feed que vous lui avez indiquée. Ensuite pour installer une application la syntaxe est la suivante :
ipkg -dest DESTINATION install PAQUET

Si l'argument -dest DESTINATION est ommis, c'est la première destination du fichier ipkg.conf qui sera utilisée (généralement la /). PAQUET quant à lui est le nom du paquet ipk à installer, sans numéro de version, architecture et .ipk à la fin. Par exemple pour installer AbiWord sur la carte SD :

ipkg -dest SD install abiword

Fonctionnement d'ipkg

Lorsque vous lancez un ipkg update, l'ensemble des fichiers Packages de chaque feed lue par ipkg est sauvée sous le nom de la feed que vous avez indiquée via /etc/ipkg.conf dans le dossier /usr/lib/ipkg/lists.

Quant vous lancez une installation, ipkg, écrit une entrée dans le fichier /usr/lib/ipkg/status indiquant le nom du paquet et la mention not-installed. C'est intéressant à savoir car si vous arrêtez une installation en cours de route (ou si vous essayer d'installer un paquet qui n'existe pas), cette entrée est conservée et du coup ipkg vous redemande à chaque appel s'il doit retenter l'installation. S'il s'agit d'une erreur, il suffit au préalable de modifier le fichier /usr/lib/ipkg/status et d'enlever les enregistrements marqués not-installer. C'est le contenu de ce fichier qui est lu lorsque vous tapez ipkg status.

Ensuite ipkg va écrire ses fichiers dans un dossier temporaire tmp placé en dessous du dossier de destination. Par exemple en /home/tmp (pour une destination par défaut) ou /mnt/sd/tmp (pour la destination SD). C'est important à savoir lorsqu'une install plante et que l'on doit virer les packets téléchargés et non installés.

Lorsque vous installez dans une destination qui n'est pas la racine, ipkg va tricher avec Linux en créant un lien symbolique entre le fichier réel (par exemple /mnt/car/usr/bin/monApplication) et le dossier où Linux s'attend à trouver un tel fichier (/usr/bin).

Enfin, une fois l'installation terminée, la liste, par paquet, des fichiers installés est stockée par ipkg dans le dossier /usr/lib/ipkg/infos sous le nom nom_paquet.list. Par exemple pour abiword, sera crée un fichier /usr/lib/ipkg/infos/abiword.list. Il va aussi mettre à jour le fichier /usr/lib/ipkg/status en remplaçant not-installed par installed.

Utilisation de frontal graphique qpkg

ipkg est un outil en ligne de commande qui dispose d'un frontal graphique nommé qpkg. Cet outil permet visuellement d'obtenir la liste des paquets disponibles, de rajouter des feeds et de faire des mises à jour.

Pour plus de confort, il est aussi possible d'utiliser qpkg) via SSH avec redirection X11 (voir Installation du réseau USB). Pratique pour voir les paquets en plein écran et se balader avec la roulette Wink

Créer son propre paquet IPK

Pour distribuer notre magnifique binaire fraîchement compilée un peu de packaging s'impose. Il nous faut donc le mettre dans un fichier .ipk.

Structure des fichiers ipk

Un fichiers .ipk est une simple archives tar compressée par gzip qui contient elle-même 2 autres archives : data.tar.gz et control.tar.gz.

Le fichier data.tar.gz contient les fichiers à décompresser dans le Zaurus, à partir de la racine. Dans notre cas, il contiendra de tous les fichiers contenus dans le dossier dist que nous avons créé par make install.

Le fichier control.tar.gz peut contenir quatre scripts et deux fichiers de contrôles.

Les scripts sont optionnels et seront lancés au court de la vie du paquet :

preinst
Exécuté avant la décompression
postinst
Exécuté après la décompression
prerm
Exécuté avant la désinstallation
postrm
Exécuté après la désinstallation

Les deux fichiers sont de contrôle quant à eux :

control
Fichier obligatoire contenant la description du package. Dans le cas de xinetd, ce serait :
Package: xinetd<strong> (Le nom du paquet)</strong>
Installed-Size: 332K <strong>(La taille une fois installé)</strong>
Filename: ./xinetd_2.3.14_arm.ipk<strong> (Le nom du fichier ipk)</strong>
Version: 2.3.14 <strong>(La version du paquet)</strong>
Depends: <strong>(Les éventuelles paquets dont dépends ce paquet)</strong>
Priority: optional <strong>(Je n'en sais rien du tout)</strong>
Section: system <strong>(La catégorie du paquet)</strong>
Maintainer: Mukti <strong>(La personne en charge de la mise à jour de ce paquet)</strong>
Architecture: arm <strong>(L'architecture de ce paquet, ARM pour le Zaurus)</strong>
Description: xinetd has access control mechanisms, extensive logging capabilities,
the ability to make services available based on time, can place limits on the number of
servers that can be started, and has deployable defence mechanisms to protect against port
scanners, among other things.
conffiles
Optionnel. Une liste de fichier ne devant pas être écrasée lors d'une mise à jour

Préparation de la distribution

Tout d'abord ne pas oublier que les Zaurus n'ont pas de ressources illimitées. Un des premiers travaux à faire dans le dossier dist est d'enlever tout ce qui ne sert "à rien" : documentations, exemples, tests, etc... jusqu'à obtenir quelque chose de minimum.

Une fois ceci fait, il faut créer dans dist un dossier CONTROL qui va contenir l'ensemble des fichiers de contrôle dont nous avons parlé plus haut et donc, au minimum, le fichier control. Pensez à bien renseigner ce fichier et y indiquer les dépendances avec d'autres paquets.

Création de l'ipk

Le meilleur moyen pour fabriquer rapidement un fichier .ipk est d'utiliser l'utilitaire mkipkg fourni avec le cross-compiler.

mkipkg dist
pour produire le fichier .ipk correctement formé et vérifié. Il ne reste plus qu'à l'envoyer dans le Zaurus pour le tester.

Mettre de l'ordre dans les dépots

ipkg est l'outil utilisé pour installer des paquets sur pdaXrom. C'est aussi lui qui est utilisé par qpkg, sa version graphique. Or, quelles que soient les versions de pdaXrom, le fichier de configuration d'ipkg est faux. Il faut donc commencer par le remettre en place...

Pour cela, en tant que root, utilisez Office/Leafpad ou plus simple vi et ouvrez le fichier /etc/ipkg.conf que vous remplacerez par le contenu suivant (décommentez ce qui correspond à votre version) :

# à décommenter si vous êtes en béta 3
# src main http://mail.pdaxrom.org/download/1.1.0beta3/Zaurus-Cxx00/feed/
# src 7x0 http://mail.pdaxrom.org/contrib/1.1.0beta3/Zaurus-7x0-860/feed/

# à décommenter si vous êtes en béta 3
# src main  http://mail.pdaxrom.org/download/1.1.0beta4/Zaurus-Cxx00/feed/
# src karmaLab http://www.karma-lab.net/zaurus
# src old http://mail.pdaxrom.org/download/1.1.0beta1/Zaurus-C1000-C3100/feed/

# à décommenter si vous êtes en béta 121
# src karmaLab http://www.karma-lab.net/zaurus/stable
# src karmaLab-lab http://www.karma-lab.net/zaurus/not-tested
# src main  http://www.pdaxrom.org/download/1.1.0r121/Zaurus-Cxx00/feed
# src other  http://www.pdaxrom.org/download/1.1.0r121/Zaurus-7x0-860/feed
# src old http://mail.pdaxrom.org/download/1.1.0beta1/Zaurus-C1000-C3100/feed
# src beta4 http://mail.pdaxrom.org/download/1.1.0beta4/Zaurus-7x0-860/new/feed


dest root /
dest cf /mnt/cf
dest sd /mnt/card
dest net /mnt/net
dest user /mnt/user
dest ide /mnt/ide
dest ide2 /mnt/ide2
dest ide3 /mnt/ide3
dest usbstorage /mnt/usbstorage
dest tmpinst /home/tmp/ipkg/inst
Sauvez puis fermez leafPad. Cette opération donne les bonnes sources de paquets à ipkg en ajoutant les deux sources de paquets de la béta 2.

Il faut maintenant mettre à jour la base de paquets soit en ligne de commande

ipkg update
soit via System Tools/Package Manager et pressez le bouton update (le 2ième). Au bout d'un temps, les descriptions de paquet seront téléchargées.

]]> Contrôler le Zaurus avec VNC http://artisan.karma-lab.net/node/63 2006-11-18T20:56:26+01:00 2008-10-01T01:35:11+02:00 Ulhume VNC permet la prise à distance d'une machine et, dans le cas du Zaurus, c'est très pratique pour effectuer du travail de fond sur la machine.

]]> VNC permet la prise à distance d'une machine et, dans le cas du Zaurus, c'est très pratique pour effectuer du travail de fond sur la machine.

Installation

Le paquet est disponible dans le feed stable. Pour l'installer (une fois ipkg configuré) il suffit de taper :

ipkg install x11vnc

Ensuite, il suffit de taper dans une console du Zaurus :

x11vnc -nopw -forever

L'argument nopw demande juste au serveur d'arrêter de nous casser les pieds avec les mots de passe (pas très utile pour contrôler le Zaurus). -forever permet quant à lui d'empécher le serveur de terminer son travail dès que le client s'est déconnecté.

Pour se connecter au Zaurus, il vous faut un client VNC. Par exemple tight VNC (pour les linuxiens le paquet est disponible dans toutes les distros) ou krdc sous KDE. Si l'on utilise tightVnc, les meilleurs performances sont obtenues par la commande :

vncviewer -encodings 'copyrect tight zrle hextile' zaurus

Où zaurus correspond à l'adresse IP du .. zaurus Smiling

Intégration dans xinetd

Le paquet contient un fichier de configuration pour xinetd. Pour l'activer, modifier donc /etc/xinetd.d/xinetd-vnc pour changer la valeur disabled=yes par no. Il suffit ensuite de relancer xinetd (/etc/rc.d/init.d/xinetd restart) pour que l'utilitaire prenne le contrôle du port 5900 et lance automatiquement x11vnc à chaque demande de connection client.

]]> Changer le click droit et central sous pdaXrom http://artisan.karma-lab.net/node/1100 2006-11-09T11:18:02+01:00 2008-02-05T08:15:47+01:00 Ulhume Une petite surprise qui m'a fait perdre pas mal de temps est que le menu contextuel (click droit) de la béta 121 qui était jusqu'à maintenant accessible par la touche Fn + tap_ecran a été déplacé sur la touche "shift". Croyant à un bug, j'ai chercher à savoir quel fichier régissait ce comportement.

]]> Une petite surprise qui m'a fait perdre pas mal de temps est que le menu contextuel (click droit) de la béta 121 qui était jusqu'à maintenant accessible par la touche Fn + tap_ecran a été déplacé sur la touche "shift". Croyant à un bug, j'ai chercher à savoir quel fichier régissait ce comportement.

Il s'agit en fait du fichier /etc/sysconfig/x11mousebutts qui ne contient que deux lignes bien explicites pour le bouton du millieu et le bouton droit. La deuxième colonne correspond au scancode de la touche concernée. Il suffit donc de modifier ces valeurs pour placer ces deux comportements sur n'importe quelle touche. Par exemple pour revenir au comportement d'origine (Fn pour droit, et Shift pour Milieu) :

middle_button 50
right_button 69

Voilà, prochaine étape, si quelqu'un a une idée, transformer tous les double-clicks en clicks simples, autrement plus maniable avec un stylet...

]]> Lorsque gnuMeric part en vrille... http://artisan.karma-lab.net/node/1096 2006-11-09T10:52:43+01:00 2007-09-19T09:16:16+02:00 Ulhume Là il s'agit peut être là d'une malédiction (en béta 3) qui m'est propre mais lorsque j'installe gnumeric, l'ensemble des liens (symlinks) sur les librairies a été zappé... Du coup, voici le petit bout de code qui m'a permis de fixer cela (désolé, pas de version graphique Wink

]]> Là il s'agit peut être là d'une malédiction (en béta 3) qui m'est propre mais lorsque j'installe gnumeric, l'ensemble des liens (symlinks) sur les librairies a été zappé... Du coup, voici le petit bout de code qui m'a permis de fixer cela (désolé, pas de version graphique Wink

ln -s libgoffice-1.so libgoffice-1.so.1
ln -s libgsf-1.so libgsf-1.so.113
ln -s libgnomeui-2.so libgnomeui-2.so.0
ln -s libbonobo-2.so libbonobo-2.so.0
ln -s libbonoboui-2.so libbonoboui-2.so.0
ln -s libgnome-2.so libgnome-2.so.0
ln -s libgnomevfs-2.so libgnomevfs-2.so.0
ln -s libgconf-2.so libgconf-2.so.0
ln -s libgconf-2.so libgconf-2.so.4
ln -s libbonobo-activation.so libbonobo-activation.so.4
ln -s libORBit-2.so libORBit-2.so.0
ln -s libgsf-gnome-1.so libgsf-gnome-1.so.113
ln -s libbz2.so libbz2.so.1.0
ln -s libgnome-keyring.so libgnome-keyring.so.0
ln -s libORBitCosNaming-2.so libORBitCosNaming-2.so.0

]]> Développer en Java sous pdaXrom http://artisan.karma-lab.net/node/61 2006-10-21T19:21:00+02:00 2007-10-20T00:35:54+02:00 Ulhume Dans la mesure où Java est mon langage fétiche, il fallait que je vois ce que cela donne avec le Zaurus... L'objectif (il en faut toujours un) est déjà bien sur de voir si Java est compatible avec cette petite plate-forme et, dans un second temps, tenter de faire un petit lecteur de média en combinant une interface graphique et l'excellent mplayer.

]]> Dans la mesure où Java est mon langage fétiche, il fallait que je vois ce que cela donne avec le Zaurus... L'objectif (il en faut toujours un) est déjà bien sur de voir si Java est compatible avec cette petite plate-forme et, dans un second temps, tenter de faire un petit lecteur de média en combinant une interface graphique et l'excellent mplayer.

Trois mots sur Java

Il en va de java pour le monde embarqué comme des autres langages. Il est possible soit de compiler directement sur la plateforme (le Zaurus), soit d'effectuer ce travail sur une machine plus puissante (une machine de bureau) et de n'exécuter que le binaire sur le module embarqué. Pour info, il existe un compilateur de bytecode java que l'on trouve dans les contributions (jikes) mais j'avoue ne pas bien voir l'intérêt et de loin préférer tout compiler sur une machine plus puissante. Cette stratégie est d'autant plus crédible que l'aspect multi-plateforme de Java permet d'oublier facilement à quelle machine le binaire est destiné.

Pour comprendre comment fonctionne Java il faut distinguer trois aspects : Le langage Java , La machine Virtuelle Java (ou JVM) et les librairies de fonctions Java (ou JDK).

Le langage Java est un langage Objet. Tout ou presque en Java est objet. Sa syntaxe est héritée du C (et pas de C++) et a été conçue pour un maximum de lisibilité. Tout ce que l'on imagine d'un langage moderne est présent dans Java : héritages, interfaçage, exceptions,prototypes, etc... Les seules choses qui ont été exclues sont celle qui, de l'avis des concepteur du langage, compromettent la stabilité de la structure (ex. héritages multiples).

La machine virtuelle Java exécute le bytecode issue de la compilation du langage. Pour comprendre à quel point cette machine est indépendante du langage il suffit de regarder du côté de dotNet. Si C# est le langage de prédilection sur cette plateforme, l'éditeur propose aussi un compilateur Java qui fournit un bytecode exécutable sur une machine virtuelle dotNet. Il existe aussi des traducteurs qui permettent de lancer le bytecode dotNet sur une machine virtuelle Java. On peut même imaginer écrire en assembleur JVM sans passer par Java. Ces deux choses sont donc bel et bien indépendantes.

Les librairies java, appelé le JDK. Ce sont l'ensemble (très volumineux) de classes utilitaires fournis au développeur pour accéllerer son oeuvre. Il y a de tout là dedans, de l'interface graphique (nous y reviendrons) aux structures de stockages (tables de hashage, vecteurs, etc.) en passant par la gestion de la vidéo, de la 3D, du réseau, etc...

Sun étant en quelque sorte le mainteneur de Java, les 3 composants que je viens de citer sont généralement marqués d'un numéro de version commun. Par exemple Java 1.5 fait référence à l'évolution 1.5 du langage (apportant les prototypes et les annotations), l'évolution 1.5 de la machine virtuelle et de son langage bytecode (beaucoup plus rapide) et l'évolution du JDK 1.5 avec de nouvelles fonctions et librairies.

Mais comme, et c'est ce qui va nous intéresser pour le Zaurus, ces composants sont indépendant, on peut fort bien imaginer utiliser les librairies d'un éditeur tiers, la JVM d'un autre en compilant notre code Java avec le compilateur de Sun. Tant que chacun respecte les numéros de version et les spécifications associées, tout doit bien se passer.

Donc si nous allons, sur notre PC, compiler nous sources avec les paquets de Sun, sur le Zaurus, il seront exécuté par la machine virtuelle libre JamVM et les librairies libres GNU/Classpath. Et tout ce petit monde, nous allons le voire, va marcher en cadence.

Discussion sur les performances

Java joui d'une mauvaise réputation en terme de performances, ce qui est sommes toute ridicule. Java se classe dans la catégorie des langages semi-interprétés (bytecode exécuté dans une JVM). Ce n'est donc pas lent comme du Basic qui est interprété à partir du source lui-même mais évidement plus lent (en encore Wink que du C compilé directement assimilable par le micro processeur.

Dans la catégorie des langages semi-interprétés nous avons d'autres concurrents comme Python (en mode pyc) et dotNet. Et étant de la même catégorie, n'en déplaise aux esprits chagrins, les performances sont en moyenne les mêmes. Par exemple une application lancée avec un jdk 1.5 est exactement la même qu'une dotnet 2.0 équivalente (c'en est troublant d'ailleurs). En revanche, une fois lançée, une application Java est, d'experience, beaucoup plus rapide qu'une application Python mais consomme un peu plus de mémoire. Enfin une application Java sera en moyenne toujours, 2.5 fois plus lente qu'une appli en C compilée avec GCC (optimisation O2) mais aura exactement les mêmes performances qu'une application en C sans optimization.

En terme d'occupation mémoire aussi les choses sont comparables. J'ai comparé avec pmem une application python et son équivalent Java et l'occupation se bat à 1Mo près (en faveur de Python).

Bref, utiliser un semi-interprété présente l'avantage d'un langage souvent plus évolué (dit langages managés), de plus de facilités de développement, mais aussi a un coût en performances quel que soit le langage choisi. Une fois ceci dit, j'avoue largement préférer un langage Java que je trouve plus mature qu'un dotnet (je n'ai pas testé dotNet après la 1.1) ou Python. Mais ce n'est qu'une histoire de goûts.

Préparation du PC

La première chose à installer est donc le J2EE (pour Java 2 Entreprise Edition) 1.5 release 6 à partir du site JavaSoft (Sun) ainsi que l'excellent EDI, Eclipse 3.2.

Nous pourrions évidement écrire nos applications Java avec un simple NotePad mais ce n'est pas bien pratique et la plate-forme de développement Eclipse semble plus indiqué pour ce type d'opération. Pour ceux qui ne connaissent pas, Eclipse est un projet libre initié (et offert) par IBM, destiné à construire un environnement de développement ultra-complet. Et même si ce projet était originellement destiné à Java, il est aujourd'hui capable de prendre en charge à peu prés tous les langages : C, Python, php, dotnet, etc... Eclipse peut aussi être mis en oeuvre facilement sur de nombreuses plate-formes (y compris macOS).

Une fois le J2EE et Eclipse installés, il suffit de lancer Eclipse et de créer le nouveau projet ZaurusJava.

  1. File/New/Project/JavaProject, Appelezle Zaurus puis Finish
Avant d'aller plus loin, il convient de modifier les propriétés du projet pour qu'il utilise le JDK 1.4 et non pas le 1.5 qui nous sert à lancer Eclise :
  1. Sélectionner le projet dans l'explorateur et clique-droit Properties
  2. Aller en section Java Build Path, onglet Source
  3. Cliquer sur Add Folder et tapez Sources puis valider
  4. Changer la valeur de Default Output Folder pour zaurus/classes
  5. Aller dans l'onglet Libraries, SSélectionnezle JDK 1.5 puis Remove
  6. Cliquez sur Add Library, puis Next, puis Alternate JRE, Installed JRE, Add, et Browse
  7. Sélectionner le chemin où se trouve le jdk 1.4 (sous linux en /usr/java/jdk1.4.2)
  8. Changer la valeur jre Name en jdk14 puis OK et encore OK
  9. De retour sur Alternate JRE, sélectionnez le nouveau jdk14 puis Finish
  10. Aller dans la section Java Compiler
  11. Cliquer sur Enable Project Specific Settings
  12. Modifier Compiler Compliance Level à la valeur 1.4
  13. Valider par OK
Voilà qui en fait, il suffit maintenant faire un click-droit dans l'explorateur Java sur la branche sources et sélectionner new/Class. Taper dans la zone name le nom HelloWolkd et cliquer sur Finish.

A ce stade, vous avez un squelette de la classe HelloWorld dans l'éditeur. On va le modifier pour afficher la bienvenue chère à nos vieux amis Kernighan et Ritchie. Pour corser la tache de la JVM et vérifier par le fait la compatibilité avec les dernières extension du langage Java, nous allons faire le HelloWord le plus idiot du monde, sous forme de prototype :

    public class HelloWorld
    {
  public static class SayWhatEver<E>
  {
    private E content;
    public SayWhatEver(E value)
    {
      content=value;
    }
    public void sayIt()
    {
      System.out.println(content);
    }
  }
  public static void main(String[] args)
  {
    SayWhatEver<String> t = new SayWhatEver<String>("Hello World!!");
    t.sayIt();
  }
    }
Pour vérifier que tout fonctionne, dans l'explorateur Java, cliquer droit sur le fichier HelloWorld.java et sélectionnez run as puis Java Application. Le message de bienvenue doit s'afficher dans la console en dessous de l'éditeur. Fin de la première étape.

Paramétrage du Zaurus

Côté Zaurus, un contributeur, Cortez, que je félicite au passage, a compilé pour pdaXrom la librairie GNU/Java Classpath et la machine virtuelle JamVM. Classpath est un projet GNU qui c'est fixé comme objectif de fournir une implémentation libre de l'ensemble des classes de base du JDK de Sun. Cela peut paraître idiot de tout refaire ainsi mais c'est loin d'être le cas pour des raisons de licences que je n'approfondirais pas ici.

JamVM est quant à elle une extraordinaire petite machine virtuelle Java dont la taille d'exécutable frise le ridicule (110ko sur une plateforme Intel).

Ceci fait vous pouvez vérifier que la vm est installé en tapant

jamvm -h

Tout vas bien donc, sinon, il faut me prévenir car j'aurais surement fait une erreur dans la création du paquet Wink

Il faut maintenant remonter le binaire HelloWorld compilé par Eclipse sur le Zaurus pour tester tout cela. Comme nous l'avons paramétré, tous les binaires compilés par Eclipse sont sur votre PC dans le dossier zaurus/classes. Il suffit donc de recopier ce dossier sur une SD et de la mettre dans le Zaurus. Une autre méthode plus rapide consiste à utiliser ssh en tapant :

scp -r /home/mon_home/workspace/zaurus/classes root@zaurus:/mnt/card
Cela me permet de recopier rapidement tous les fichiers compilés sur la SD insérée dans le le Zaurus.

D'une manière ou d'une autre, votre dossier classes est sur la SD en /mnt/card/classes. Normalement il y a un deux fichiers dans ce dossier, le java compile HelloWorld.class et celui de sa classe interne. Pour l'exécuter tapons "simplement" :

/usr/java/jamvm/bin/jamvm -cp /mnt/card/classes HelloWorld 
Hello World !!!
C'est gagné Smiling Un premier pas de fait et la vérification au passage de la compatibilité avec la norme 1.5 du langage, en tout cas pour les prototypes ce qui est déjà plus que pas mal !

Maintenant ajoutons la couche graphique à cet édifice bien prometteur...

Premier essai en SWING

Il y a 3 toolkit graphique sous Java. AWT, l'ancêtre dont le crédo est "le plus petit dénominateur commun". AWT ne connaît donc que les composants qui existent sur toutes les platef-ormes (X11, Windows et Mac OS). N'y cherchez par exemple pas de composant "arborescence", il n'y en a pas. En revanche c'est très rapide car ce sont directement les composants natif qui sont affichés.

Fort de cette pauvreté est apparu JFC (Java Foundation Classes) qui jette les bases de composants graphiques entièrement écrits en Java. Cela va s'appeler plus tard SWING et être intégré aux J2EE 1.3. C'est très beau, très très riche et complet mais aussi très lent. Car chaque pixel de chaque bouton est écrit en Java, en bytecode donc, en interprété quoi... Au fil des versions Swing a prodigieusement gagné en vitesse. Aujourd'hui, sans sa version 1.6, Swing est très abouti et parfaitement utilisable pour une machine un tant soit peu puissante. Mais il reste à mon sens un peu trop lourd pour notre pauvre Zaurus.

Dernière arrivé, SWT se veut la synthèse, le meilleur des deux mondes. Son crédo c'est utiliser le natif à chaque fois que possible, sinon, au pire cas, émuler en java. L'IHM d'Eclipse est écrite en SWT. Les SWT reposent sur des wrappers qui encapsulent des toolkits natif comme Win32, GTK ou Quartz. C'est très léger et c'est surtout très rapide.

Commençons donc par SWING, pour déjà voir si notre VM sais ce que c'est qu'une fenêtre. Nous allons modifier notre HelloWorld sous Eclipse :

import java.awt.Dimension;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.JButton;
import javax.swing.JFrame;

public class HelloWorld
{
  public static void main(String[] args)
  {
    JFrame frame = new JFrame("Hello World");
    JButton button = new JButton();
    button.setText("Quitter"